oficina / home Public

Revise against the review, and rescope to one team

The review AGENTS.md requires had never run on this design; §12 said so.
It ran, returned six blocking findings and eight corrections, and Paul
ruled the feed's scope while it was out. All of that is applied here.

The scope ruling costs this design its headline. It argued that only
the home can answer "my things" rather than "this team's things", and
per-team concedes exactly that question. §2.1 records the argument as
retired rather than deleting it, and re-justifies on what survives:
only the home knows which apps a team has instances in, and the
alternative — Sheets' home page growing a Docs section — needs Sheets
to hold Docs' grants, which is the federation the home spec forbids
outright. Per-team is also cheaper on every axis this design worries
about: the fan-out is one team's apps, the cache holds less, the oracle
surface shrinks.

§7 contradicted itself. It said the TTL bounds staleness by a number we
choose rather than by a hibernating fleet's wake schedule, and then
said a failed pull never evicts a good cached answer. Both cannot hold:
if failure preserves rows, a person removed from a team keeps seeing
its titles until that instance next answers, which is the hibernation
tail the first sentence disclaims. There are two ages now — a refresh
TTL, and a hard maximum that discards rows regardless of pull outcome —
and the new gate 20 drives the hard one, because a test against the
refresh TTL proves the easy half.

§10 said a 404 means "this app does not participate", rendered as
nothing. That is ruling 5 backwards: a participating app that loses its
route in a deploy would vanish silently from every front door.
Participation is a registry flag now, and a declared app answering 404
is a gap.

The platform edge is a shared cache sitting upstream of both ends. It
caches any 2xx GET with a positive max-age, keyed on host, path and
query, shared across every visitor, and does not refuse on a request
Cookie. So an instance answering public, max-age=60 would have the edge
serve person A's rows to the home's next pull for person B — invisible
to the home's own cache key. Call 7 now requires no-store from
instances, and a cacheable response is a failed pull.

§2.1 said the process holds "a cross-app list of titles for one
person". It holds one for every person who rendered inside the TTL — a
cross-person set, in the process that mints sessions, which §11 lists
as never licensed while this built it as a data structure. The cache is
bounded now, and the two platform facts the "in RAM" claim leans on
(swap, core dumps) are recorded as unestablished and blocking.

Two open numbers were not tunables: the hard maximum age, and the
minimum pull interval per person and instance — the second because
instance-hours bill to the instance's account, so a guest's front door
was spending someone else's money on every load. The fan-out budget's
number can wait; its behaviour at the limit cannot, because an un-asked
instance must render as its own kind of gap or ruling 5 breaks quietly.

Also: Go's http.DefaultClient has no timeout and follows redirects, so
the client is hardened explicitly — full-body deadline, no redirects
(an instance redirecting to a document URL would put that URL in a
net/http error string, which §3.4 rules is storage), bounded concurrency
so one slow instance cannot exhaust the process that serves sign-in.
`since` is named as never persisted, since a durable last-pull cursor
is the contentless activity table §11 forbids arriving as an
optimisation. §3's replacement clause binds the audience — "and only to
that person" — so the operator-view prohibition sits inside the clause
rather than in a table. §0's prose form is conceded to move: "never
learns what is in anything" now reads as never retains. The gates
renumber from 11, since main took gate 10 for no-store. And the
AGENTS.md staleness item is closed — main carries all three retractions.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>