🤖 The Oficina suite — sharing doctrine

How the apps of the suite share identity, membership and content with each other, and where the line is that nothing crosses.

Status: design, revision 8, 2026-09-05.

Revision 8 records that the contract module cannot be imported, which makes §12 step 2 built rather than done. amadan.net/oficina/suite does not resolve for the Go toolchain: the hub answers ?go-get=1 with a 302 to /auth/login, so go get never sees a go-import meta tag. Verified twice, independently. The module has zero consumers today and cannot get one, and §12 steps 3 and 4 both say "against the module".

Revision 7 moves S6 to where it is actually needed and records why it has the shape it has. Revision 6 gave it a step before memoria slice 1, which was earlier than the dependency requires and implied slice 1 was blocked on it. The memoria session supplied the piece neither of the other two had: slice 1 is S1, S2, S3 and §4.1 and needs no S6 at all; the numeric and aggregate class in its §8.2 router is slice 2, and that is where S6 bites.

Revision 6 schedules S6, which had a number and no builder. It is in §6's contract table and A.4 tells memoria to cite it, and no step of §12 ever built it — so it read as settled because it had a number. That is the hole §6's S4/S5 paragraph exists to prevent, with the difference that S4 and S5 were resolved away deliberately and said so, while S6 was live and merely unscheduled. Caught by the oficina/home activity-pull session while answering a memoria status check, before memoria adopted A.4 against a fixture nobody was going to write.

Why 5 and not 4, which is this document breaking its own gate 9. Two commits after revision 4 changed rules while leaving the number alone: 574cc84 corrected A.1's ruling number and recorded memoria's citation baseline, and bf0eeb8 added §4.3's call-7 carve-out, scoped §5.3's epoch exception to the call-8 path, rewrote §6's call-7 row and added a leak-list item. Gate 9 says the revision is bumped by any normative change, wherever it lives — §4.3 and §5.3 are exactly that, and revision 4 was cited while its own text moved underneath the citation. Caught by the oficina/home activity-pull session, which was handed one commit for revision 4 while this repository's own app amendments carried another, could confirm neither, and wrote the discrepancy down rather than picking the newer number quietly.

What to cite. Revision 5 is this commit. The app amendments on oficina/docs, oficina/sheets and oficina/home cite revision 4, 210312f, which was true when each was written and is now exactly one revision behind — which gate 9's one-revision grace allows, deliberately, as a compatibility allowance and not as evidence they meet current requirements. They are correct as they stand and become stale on the next normative change. Drafted by the suite session (Fable 5.1) from a brainstorm with Paul the same day. Every ruling in §1 attributed to Paul was given in that conversation, in an earlier spec named in the row, or in the sessions that produced revisions 3 and 4.

Three review passes, by two models, none of which wrote the draft. Claude Opus 5 on revision 1: six defects. GPT-6 via Codex on revision 2: request changes, sixteen findings. GPT-6 and Fable 5.1 independently on revision 3: request changes from both, agreeing closely — 6 and 7 of the sixteen closed respectively, none still fully open, plus twelve and five new findings. All three reports are beside this file, unedited: CODEX-FINDINGS.md, CODEX-FINDINGS-R3.md, FABLE-FINDINGS-R3.md.

Revision 4 does not claim to answer everything, because revisions 2 and 3 both made that claim and both were caught. What it fixes:

• Ruling 15 is now Paul's and it cites Sheets ruling 12. Link sharing is read-only; an "edit link" is a capability to obtain a guest grant at sign-in, so every write still has a named actor. Revision 3 proposed an anonymous link editor — the actor Paul had already rejected on 2026-08-30 — without citing the ruling that rejected it. §7.3 is deleted. Recorded plainly because it is the failure §2 diagnoses and §10 exists to prevent, committed by this document.
• The provenance envelope splits by path (§7). Revision 3 required an asker on S3 and on a link read, neither of which has one. Person-less paths check custody; only person paths check S2. Withholding is whole-artefact, since no envelope can map a synthesis back to the source of a sentence.
• A stale roster stops serving existing sessions (§5.3), which is what revision 3 said it was doing and was not.
• A restored home mints a new roster generation (§5.3). Refusing a lower epoch was not enough: a restore that reissues the same numbers catches up in two writes.
• §5.5 stops denying what ruling 13 concedes. A compromised credential origin reads and writes as whoever it signs in as, and no instance-side check distinguishes it. Revision 3 conceded that and then wrote the reassuring clause back two paragraphs later.
• Ruling 12's rejected column drops its impossibility claim and keeps the three facts verified against home §§6 and 7.

Openly not answered, and deliberately left for iteration (Paul, 2026-09-05): call 8's wire encoding and completion marker; result precedence when a stale roster and a non-custodial item collide; pinning sibling baselines, since four memoria citations resolve only on an unmerged worktree; and most of the fixtures the gates now describe.

Two that were on this list are off it. The activity path's cached authorization is answered: §4.3 now carves out call 7 explicitly and requires a hard maximum age, which the activity-pull session had already priced before being asked. A.1's ruling number is resolved: home ruling 22 was indeed taken and the amendment landed as 23. These are recorded here rather than in a passing sentence so the next reader can see the edge of the work.

Revision 4 has not been reviewed.

Scope: the rules that bind every app in the suite when it talks to another app or to the home. Consumed by oficina/home, oficina/docs, oficina/sheets, oficina/memoria, oficina/calendar, and any wrapper that later joins (mail via keymail, files via slopbox). Reads on top of carlos/pegamento:docs/doctrine.md. Where it diverges, §14 says so and names the filing.

---

0. The one rule

> The team is the boundary. Inside it, the apps are one thing. Across > it, sharing is membership and nothing moves.

The falsifiable form, in two halves:

• Inside. Take a team's instances of every app. Publish what any one of them holds and the worst anyone learns is what that team could read in the owning app at the moment the copy was taken. An honest instance retires a copy that has left team-visibility within one feed pull plus the retention its own spec states — memoria §7.4 holds that number today, and a consumer that states none is not conformant. §4.2 carries the rule and deliberately carries no number, because the number is a property of the consumer's storage and not of this document. A compromised consumer never retires anything.
• Across. Take two teams. There is no path the suite provides by which a byte of one team's content reaches an instance of the other. A person in both teams reaches both through the home and carries nothing between them. A person who exports a file and uploads it by hand has left the paths the suite provides, and nothing here prevents that.

"At the moment the copy was taken" is the design, not a hedge. Custody is bounded at acquisition and retired by the feed; it is never enforced by erasure, because no app can erase from another app's process — which is precisely why ruling 1 put the boundary at the team and not at the process. §9 item 7 already concedes this one layer up, for a page a browser has rendered. This is the same sentence for bytes at rest.

Revision 1 stated the test instantaneously. That was false for the window between a source privatising an item and the consumer pulling its gone row, and false permanently against a consumer that has been broken into. The home made this same correction on its own §0: "never stores your address" was a claim the schema could not keep, so it became "never stores a readable address" with the window carried in its §3.2. The precedent was in the family and this document did not follow it. Ruling 14.

Pegamento §1 says the app declares its own boundary. The suite is the app (memoria decision 1, Paul, 2026-09-03), and it declares the team. The process is not the boundary and never was: it was where the boundary happened to fall while every CARLOS app was one process.

---

1. Settled decisions (don't relitigate casually)

| # | Ruling | Rejected | Who, when | |---|---|---|---| | 1 | The team is the boundary. An instance is a process. A team's instances across every app are one trust domain at <team>.<app>.oficina.works. | One boundary per process, which left memoria holding person-initiated snapshots and made the home's activity feed a federation question | Paul, 2026-09-03 (memoria decision 1); reaffirmed suite-wide 2026-09-05 | | 2 | Sharing is membership across teams, unchanged. No data crosses a team label. A guest is a scoped member of the granting team. A link share moves nothing. | Any federation story; a "copy to my team" verb | Pegamento §3, applied | | 3 | Custody and authorization are two rules. Custody bounds what a sibling may hold: team-visible items only. Authorization is what a person may read: asked of the app of record, per person, per query, never cached. Team standing is not authorization; it is the roster, a pulled copy refreshed by epoch (§5). A copy is never an authority. | One ACL copied between apps; "is a member" as the only question | Paul, 2026-09-03 (memoria decision 3); generalised 2026-09-05 | | 4 | The home owns identity and the team, including the membership roster. It never owns a per-item grant. | Per-instance rosters as the record, reconciled by asking siblings; the home holding document-level grants | Paul, 2026-09-05 | | 5 | Two shapes, one switch. A lone instance is its own identity authority and its own roster. A suite instance takes both from the home. Membership authority follows identity authority; an instance never has one without the other. | A suite instance half-trusting its local table; a lone instance dialling a home for a roster it does not need | Paul, 2026-08-31 (Docs §8.1, two shapes); extended to the roster 2026-09-05 | | 6 | Egress is one suite sentence. Egress that is a property of the product is forbidden. Egress that is per-team opt-in, to one named recipient, disclosed, with a working floor when off, is admissible. | Two contradicting texts, Docs §11.2 and memoria §8.3 | Paul, 2026-09-03 (memoria decision 4); made suite-wide 2026-09-05 | | 7 | One contract, one Go module, both halves, fixtures as the interface. Every app imports the module, serves its server half, and passes the conformance suite in CI. An app spec cites the doctrine and lists consumed rulings. It never restates one. | Each spec restating the contract in its own words, which is what drifted | Paul, 2026-09-05 | | 8 | Two credentials, chosen by what the call proves. A home-minted assertion proves a person. A consumer bearer token proves a same-team sibling. Custody calls carry the token and no asker. Per-person reads from a sibling carry the token and a named asker. | A token exchange putting the home in the loop of every search; one credential for everything | This session, 2026-09-05 | | 9 | A write names its real actor. No sibling ever acts as a person. A person writes through their own session, carried by their browser. A sibling writes as itself, into an area the team owner designated for it, touching only what it authored. | On-behalf-of writes, where a sibling token becomes a write capability over every member's identity; browser-carried only, which forbids unattended writes | Paul, 2026-09-05 | | 10 | Separate repos. One shared repo for the doctrine and the contract. The suite is a consolidation: mail and files arrive as wrappers around keymail and slopbox, so the contract must cross repository boundaries on day one. | A core monorepo for home, docs, sheets, memoria and estilo, which buys atomic spec edits for four apps and loses the property the day mail joins | Paul, 2026-09-05 | | 11 | Activity is pulled at render and held nowhere at rest — oficina/home ruling 18 and the design-activity-pull spec, adopted as suite contract call 7. | Push into the home; a contentless heat map | Paul, 2026-09-05 (home ruling 18) | | 12 | Membership is its own record at the home, written only by an owner. (team, person, role), written at the directory origin behind step-up, or seeded by the drain with the team's first owner. A directory row says where a person has things; it never grants or revokes team standing. Call 2 cannot write membership and call 8 reads only the membership record. | Deriving the roster from call-2 directory rows, which revision 1 chose. The row has no owner role to project (home §6: kind is member or guest; home §7: who counts as an owner "is the instance's business… and the home never learns the answer"); it is scoped per (team, app) where the roster is per team, so a projection can express "member of acme.docs but not acme.sheets", which ruling 1 forbids; and any instance writes it under a consumer token, so deriving from it routes around §5.4's step-up. Those three are verified against home §§6 and 7; whether they are together unbuildable is a stronger claim than the evidence carries, and revision 3 made it | Paul, 2026-09-05, on Fable's recommendation after the GPT-6 review (finding 1) | | 13 | A compromised home is three compromises and each is conceded on its own. A leaked database reveals the graph, the roster, and who owns each team. A compromised directory origin can add a member, and a member reads everything team-visible in every instance of that team. A compromised credential origin can sign in as anyone, owners included, and no instance can tell. | One undifferentiated "compromised home" that "cannot read a document", which took home §2's careful directory and widened it to home, and counted as evidence what only honest code leaves behind | Paul, 2026-09-05, on Fable's recommendation after the GPT-6 review (finding 2) | | 14 | Custody is bounded at acquisition and retired by the feed. It is not enforced by erasure. What an instance may acquire is team-visible at the time; what it may render is live-authorized (ruling 3); what it must retire is stated and timed. Three rules, not one. | §0's inside test stated instantaneously; source-driven tombstone push (home §6: no channel reaches a hibernating instance); sealing pulled content under a source-held key, which buys nothing once a consumer has indexed, since an embedding is content in another costume (memoria §3.1) | Paul, 2026-09-05, on Fable's recommendation after the GPT-6 review (finding 6) | | 15 | Three rungs and a read-only link. An item is private, granted to named people, or team. Orthogonally it may carry a read-only link capability — view, or comment where the app has that role. Only the team rung is team-visible, so custody keys on the rung and never on the link. Every write has a named actor: a member, or a guest who signed in and took a grant. | Treating a link as team-visible because "anyone can read it", which turns a capability held by whoever has the URL into a listing every team member finds by search. And anonymous link editing, which Sheets ruling 12 rejected on 2026-08-30 and which revision 3 rebuilt without citing it. An "edit link" is a capability to obtain a guest grant at sign-in — the granted rung, and how Docs already builds its commenter link | Paul, 2026-09-05, confirming Sheets ruling 12 |

---

2. What the collision was

Nothing inter-app is built. The home is a skeleton. memoria's slice 1 is blocked. The activity pull is an unmerged worktree. So this is a spec alignment, not a migration, and it is cheap now and expensive in a month.

The collision was never five apps disagreeing about the boundary. It was five specs each restating the same rules in their own words:

• Home §2.2, Sheets PRODUCT.md principle 2 and Docs §8.2 each say data never crosses an instance boundary. memoria decision 1 says the boundary is the team. All four were written in good faith from the same Pegamento sentence, and the word "instance" carried a process assumption nobody had examined.
• Docs §9 restated the home's five-call contract and was written against a superseded draft. The home spec now has six calls and the activity design a seventh.
• Docs §11.2 and memoria §8.3 give opposite verdicts on the same egress, and memoria could only ask Docs to change (oficina/docs discussion 33) because Sheets AGENTS.md's rule that a contradiction is fixed in the same commit cannot be kept across repositories.
• Four team models exist: the home's suite-wide teams table (ruling 17), Sheets' owners list plus TeamRole, Docs' allowed-addresses list, and calendar's Kind = "team" calendar everyone holds a grant on. memoria decision 11 works around there being no roster of record by asking every sibling and admitting on any yes.

Restating is the defect. Co-location would not have fixed it; citation does. §10 is the mechanism.

---

3. Two shapes

An instance is provisioned in exactly one shape and the shape is not a runtime mode.

Lone. One team, self-hosted, no home. The instance signs people in itself with rastrillo's magic link, keeps its own owners list and member rows, and never dials a home. This is Docs §8.1's ruling and Factor VII's requirement, not a degraded tier. Seapointish is the family precedent: "none" is a supported answer to "what glue does this app need".

Suite. The instance accepts home assertions (home §5.3) and pulls its roster from the home (§5).

The switch is the presence of a home consumer token in platform config. With it, the instance is a suite instance in every respect. Without it, a lone one in every respect. Ruling 5's reason: an instance that trusted the home for identity and its own table for membership would have two rosters of record, and the test in §0 could not be written for it.

Sibling calls are a separate switch, and it is independent of shape. An instance serves and makes the sibling contract (§6) when sibling consumer tokens are in its platform config, which the drain mints without the home's involvement (memoria §6.2). So a self-hoster running Sheets and memoria with no home gets the two talking, and a suite instance always may. Two instances that talk were provisioned together and share a shape, which is what lets S2's named asker mean one thing: the subject the receiving instance keys its members on, a person ref in suite shape and a lowercased address in lone shape. A pair of lone instances has two rosters, one per instance, and that is what lone means; custody and authorization work unchanged because neither depends on the roster being shared.

The asker subject is typed on the wire — {kind: person_ref | address, value} — because its meaning is shape-dependent and nothing else in an S2 or S6 call says which shape the pair is in. "Provisioned together" is an operational habit, not an enforced property, and a mismatched pair would otherwise send a value the receiver keys nothing on and get back NOT_VISIBLE: the one value §4.3 permits to be silent, returned for a mis-provisioning. With the kind on the wire, a receiver that does not key on it answers UNKNOWN and the gap is named, which is what §4.3 requires of everything that is not a denial. (Review pass, 2026-09-05.)

---

4. Boundaries

4.1 The team

The <team> DNS label, reserved suite-wide at the home (home ruling 19). Every barrier in this document is a barrier at that label. Two of them are structural:

• A sibling's consumers row is both credential and origin allowlist.
• Every sibling client refuses a host whose <team> label differs from its own, test-enforced against a fixture of hostile hostnames, and refuses to follow redirects.

Neither is a boundary against code execution on an instance. They stop mis-provisioning and accidental cross-team dialling, and that is what they are claimed as (memoria §6.3).

4.2 Custody

What a sibling may hold a copy of. The predicate is team-visible: readable by every roster member by virtue of team standing alone. Each app defines it in one function, and the conformance suite (§11) proves that a content fetch for anything else answers 404, never 403.

The ladder every app implements (ruling 15). Four product states, three rungs and one capability:

| State | Rung | Team-visible? | |---|---|---| | Private to me | private | No | | Shared with specific people — members, or guests from outside (§5.2) | granted | No | | Shared with the whole team | team | Yes | | Anyone with the link can read | a read-only capability on any rung | No, by itself |

The product need this serves, in Paul's words: read and write with team-mates, read-only in public. Team-mates read and write by team standing or by a grant. The public reads by link and never writes. An "anyone with the link can edit" share is the granted rung wearing a convenient front door: the link carries you to sign-in, sign-in mints a guest grant, and from there you are a named actor like everyone else. Sheets ruling 12 settled this on 2026-08-30 — "link sharing is viewer-or-commenter, never editor" — and revision 3 rebuilt the actor it rejected without citing it. Ruling 15 cites it now. That failure is precisely what §2 diagnoses and §10 exists to stop, committed by the document that diagnoses it.

Custody keys on the rung, never on the link. The predicate is not "can somebody read this", it is "does team standing alone reach it". A link share is a capability held by whoever has the URL, and it is deliberately not a grant to anybody in particular.

Getting this wrong is a live leak, not a technicality. Ana keeps a document private and link-shares it with one contractor. If the link made it team-visible, memoria would ingest it, and the first teammate to search for its subject would be handed a passage from a document nobody gave them. The sharer chose "whoever I send this URL to". Treating that as "everyone on the team, findable by search" is a different decision made on their behalf. An item that is both on the team rung and link-shared is team-visible because of the rung; the link adds nothing either way.

A link share still moves nothing (ruling 2). Whoever holds the URL reads the item in the app that owns it, so no byte reaches another team's instance and §0's "across" half is untouched. A link holder is never on a roster, so no sibling ever names one as an S2 asker — siblings serve members, and a link holder is served by the owning app directly.

Individually granted items, guest-only items and link-only items are never team-visible. The change feed therefore carries no visibility flag: departure from team-visibility is gone, indistinguishable from deletion, so a sibling cannot learn that a private item exists (memoria §6.1). A move down the ladder — team to granted or private — is a departure like any other, and reads as gone.

4.3 Authorization

What a person may read. Asked of the app of record with the asker named, per query, and answered from that app's grants join. Four values, none collapsible into another: VISIBLE, NOT_VISIBLE, STALE, UNKNOWN. Only NOT_VISIBLE may be silent. Everything else that is not VISIBLE withholds loudly and names the app (memoria §4.1).

The revision may be behind in either direction, and only one is STALE. memoria §4.1 defines STALE as the source having moved past the requested revision. A source restored from backup can be behind it — the consumer holds revision 7 and the app of record now has 5. VISIBLE would authorise a revision the app of record cannot vouch for; NOT_VISIBLE files a synchronisation failure under the one value that is allowed to be silent, which is the exact mistake STALE was introduced to fix. So a revision the app of record does not recognise is UNKNOWN: withheld loudly, the app named, the consumer free to re-ingest. memoria records this defect open in its §13; A.4 closes it. (GPT-6 review, finding 11.)

Never cached, at any scope. Not per session, not per page, not for the life of a warm process. Caching authorization is what makes a stale answer a leak (memoria §6.5), and the usability pressure to cache within a session is exactly the pressure this sentence exists to resist. The one copy an instance may hold is the roster (§5.3), and the roster answers team standing, not "may this person read this item". An earlier draft of ruling 3 said "cached no longer than a session", which conflated the two; memoria's session caught it.

One carve-out, and it is call 7. The rule above governs an authorization answer: an S2 VISIBLE held past its request is a standing capability, and it grows — the consumer re-uses it against items and people the app of record never spoke about. The home's activity cache is not that. It holds rendered output for one person, the home holds no grants, and it can only ever re-serve the same rows to the same person.

That is a real distinction and it is not a free one. Inside the cache's life a person removed from a team still sees titles, and calling that "not cached authorization" would be word-play. So it is priced rather than denied: the activity cache carries two ages, a short refresh TTL saying when to try again, and a hard maximum age after which rows are discarded regardless of the pull's outcome, failure included. The hard maximum is the one that bounds the lie. Without it the tail is the hibernating fleet's wake schedule rather than a number anybody chose.

This document states that the bound must exist and refuses to carry the number, exactly as §4.2 does for retention: the number is a property of the consumer, and the consumer states it. design-activity-pull §7 holds it. (Reconciled with the activity-pull session, 2026-09-05, which found the contradiction between this section and §6's call-7 row and priced it before being asked.)

The app of record for an item is the app whose store it was created in. A copy never becomes an authority, and a derived artefact carries the provenance of every source it was built from, transitively, so two hops cannot launder what one cannot (memoria §13, now a suite rule).

S2's answer is intersected with custody. The app of record runs its grants join for the named asker, and then answers NOT_VISIBLE for any item that is not team-visible, whatever the asker's individual grants say.

Without the intersection §4.2's guarantee is false. A sibling holds ids for items it ingested, and an item that later leaves team-visibility appears in the feed as gone, which §4.2 requires to be indistinguishable from deletion. An S2 answering from the full join would distinguish them perfectly: VISIBLE for the one that went private, when a grantee is the named asker, and NOT_VISIBLE for the one that was deleted. The leak the S1 visibility flag was removed to prevent, and the leak S3's "404, never 403" was designed to prevent, would arrive on the third call.

The intersection has a cost, and it is a product cost. A consumer that ingested an item while it was team-visible, and asks about it after it went private but before gone reaches it, now gets NOT_VISIBLE where it would have got VISIBLE for a person who still holds an individual grant. Ana loses that passage in memoria, and any answer built on it, while the document itself stays open to her in the app of record. That is the price of the indistinguishability §4.2 promises; it cannot be avoided while the promise stands, and the consumer's honest move is to say which app the answer went to rather than to return a shorter one silently.

Revision 2 first wrote that the intersection cost a correct consumer nothing, reasoning from visibility at ingestion. That reasoning is wrong: a later visibility change is exactly what the defect turns on, so the case where the intersection bites is the case the argument assumed away. It costs an incorrect consumer what decision 3 says it should — custody bounds what a sibling may hold, and a sibling has no business asking about what it may not hold. (Review pass, 2026-09-05. memoria §4.1 states the join unintersected — "plus rows granted to me individually" — so A.4 carries the correction. The cost paragraph is corrected from the GPT-6 review, finding 8, which also wants a transition fixture: ingest, downgrade while keeping Ana's grant, query before the feed catches up.)

---

5. Identity and the roster

5.1 What the home owns

• The person: an opaque person ref, the assertion's sub (home §5.3).
• The team: sqid, DNS label, sealed display name (home ruling 17).
• The team's instances: team_instances, one row per (team, app).
• The roster: which person refs are on which team, as owner or member, in a membership record of its own — (team, person, role), not a projection of anything else the home holds. This is ruling 4's expansion and ruling 12's shape.

Revision 1 derived the roster from directory rows, and that was wrong three ways. It is recorded because the economy was tempting and someone will propose it again: it adds no table, and it leaves the home's publish-the-database claim untouched.

• The row has no owner role to project. Home §6's directory row is (person ref, app, team sqid, host, kind, sealed team name) and "kind is member or guest". Home §7 is explicit that who counts as an owner "is the instance's business… and the home never learns the answer". §5.3's wire shape had no source.
• The row is scoped per (team, app); the roster is per team. A projection can therefore express "a member of acme.docs but not of acme.sheets", which ruling 1 forbids outright.
• Any instance can write it under its consumer token, through call 2. Deriving team standing from it routes around §5.4's step-up completely.

Changing the reader without changing the writer is not a design. Ruling 9 made a directory row a hint on purpose; revision 1 made it authoritative and left the writer alone.

5.2 What the home never owns

A per-item grant. Which sheets a member may edit, which document a guest may comment on, which calendar a viewer sees: all instance-side, in the app's own grants table, decided from there on every request. The home answers only facts about its own records, never "may this person" (home ruling 19). "Is this person on this team" is a fact about its records. "May this person open this sheet" is not.

Guests are not on the roster. A guest grant is minted in the instance and announced to the directory as kind = guest (home call 2), exactly as today. Nothing about guests changes.

5.3 How the roster reaches an instance

Call 8, roster pull, instance → home, under the instance's consumer token, scoped to the instance's own team:

GET /roster?team=<sqid>&epoch=<n>
→ { epoch, members: [ { person_ref, role: owner|member } ] }

The home cannot push (home §6: no channel reaches a hibernating instance), so an instance pulls on wake and whenever it learns its copy is stale. It learns that from a roster epoch carried in every call-2, call-5 and call-8 response, and in the assertion as a claim.

The epoch claim is an invalidation hint, and it needs its own exception in home §5.4. Revision 2 said the claim passed that test unchanged. It does not: home §5.4 admits a non-identity claim when it is drawn from a closed enumerated set and fails cosmetically, and a monotonically rising epoch is neither of those. What makes it safe is a different argument and deserves its own words — the instance decides nothing from the claim. A claim it cannot parse is ignored. A claim that differs from what it holds buys exactly one call-8 refetch, and call 8's answer is what it enforces. So a hostile claim costs one request and can neither admit nor exclude anybody.

The exception is scoped to the call-8 path and nothing else. An instance answering call 7 sees the same assertion and therefore the same claim, and it must not invalidate anything on it — that would be an instance making a decision from a home-supplied claim, which is precisely what home §5.4 forbids and what this exception is narrow enough to avoid. Refetching a roster is not a decision; withholding an activity row would be. (Raised by the activity-pull session, 2026-09-05.)

A.1 records that exception in the home spec, which owns the test; this document cites it rather than asserting the old test already covered it. A person whose sign-in reveals a stale roster is admitted against the fresh roster, never against the claim. (GPT-6 review, finding 12.)

The copy has a maximum age. Every carrier of the epoch — call 2, call 5, call 8, the assertion — needs a person or a wake. Sibling calls carry no epoch, deliberately, since a sibling has no business knowing the roster's version. So an instance kept warm by sibling traffic alone, admitting nobody and never sleeping, has nothing to tell it that its roster moved, and §5.4's sentence would not be true of it. The copy therefore carries a TTL and is refetched on expiry. The number's reason, in the comment the contract module requires: it is the worst-case lag between a removal at the home and its effect on an instance nobody signs in to. Measured with §14's deadline rather than guessed here. (Review pass, 2026-09-05.)

Call 8 is paged, and a page is only meaningful inside one epoch. S2 and S6 cap a batch the caller supplies; call 8 is the first call whose response size the caller does not control, so it needs a cursor as well as a cap. The cursor is bound to the epoch it was issued in. Fetching page one at epoch 10 and page two at epoch 11 would otherwise compose a membership set that never existed at either — skipping a removal, or dropping an owner. So: the home refuses a cursor from a superseded epoch and says which epoch is current; the instance stages every page and replaces its roster atomically only when a complete set for one epoch has arrived; and a partial or failed fetch leaves the previous roster in place. A partial roster is never published, and an empty response is never read as "nobody is a member". (GPT-6 review, finding 10.)

A refetch that fails does not silently extend the copy. The TTL says when to refresh; it has to say what happens when refreshing does not work, or "removed within the TTL" is a promise about the happy path only. Past the TTL with no successful fetch, the roster is stale, and team standing stops being established for anybody — including people already in a session. Revision 3 let existing sessions run on, which on a 30-day sliding session is the outage-length revocation tail the paragraph claimed to reject, bought at the price of suite-wide UNKNOWN. A stale instance therefore serves only what an individual grant reaches, since a grant is instance-side and needs no roster, and answers UNKNOWN on S2 rather than NOT_VISIBLE — the gap is named, per §4.3, because an unreachable home is a synchronisation failure and not a denial.

This costs availability on purpose, and the cost is real: a team whose home is unreachable loses team-standing access until it returns. The alternative is that an unreachable home lets a removed member keep their access for as long as the outage lasts, which is the thing ruling 4 was adopted to end. (GPT-6 finding R3-2; Fable finding 5.)

A restored home gets a new roster generation, because refusing a lower epoch is not enough. Revision 3 said an instance never accepts an epoch below the one it holds. That stops the regression and not the damage: a restored home simply issues 10, 11, 12 again over the recovered roster, and two writes later the instance is accepting an epoch it considers fresh carrying members it had already removed.

So the roster carries (generation, epoch). The generation changes whenever the home cannot prove continuity with the epochs it last issued — any restore from backup. An instance seeing an unfamiliar generation holds its roster stale (above), admits nobody on team standing, and refuses to publish the new one until an owner confirms it at the directory origin. A restore is a human event and it should cost a human action; the alternative is that the recovery path is also the readmission path.

A home that loses the memberships table entirely has no rebuild path — call 2 cannot write it (ruling 12) and no channel reaches a hibernating instance. Home §10's "loses credentials, not access" is therefore false for the roster, and A.1 amends it. Recovery is the instances' copies plus an owner's confirmation, or it is re-entry by hand. (GPT-6 finding R3-3; Fable finding 4.)

The instance enforces from its own copy, on every request, exactly as it does today. What changes is where the copy comes from: the home rather than an owners list in an environment variable.

5.4 Writing the roster

At the home's directory origin, by a team owner, behind a fresh-assertion step-up (home §14 names it; this is its trigger), and nowhere else. Adding a person announces them to every team_instances row's directory entry, so their front door shows the whole team on first sign-in. Removing a person bumps the epoch, and every instance that wakes or admits anyone refetches.

Call 2 cannot write membership (ruling 12). It writes directory rows, which say where a person has things, and no directory row grants or revokes team standing however its kind reads. The membership record is the only source for call 8.

The first owner is seeded by the drain, from the sealed queue payload home §7 already carries, because gating a membership write on an owner needs an owner to exist first, and that circularity has to break outside the roster.

A member removed at the home is removed everywhere within one epoch, and on an instance that admits nobody, within the roster TTL (§5.3). That is the sentence memoria decision 11 could not write and the reason its four unreconciled tables existed.

5.5 What this costs, said plainly

Ruling 13. "A compromised home" is three different events and they cost three different things. Revision 1 ran them together, and it did so by taking home §2's careful sentence about a compromised directory and widening it to the home. Home §3.1 keeps the two apart and records that its own first draft collapsed them and was wrong to.

A leaked database reveals the graph, the roster, and — new with ruling 12 — who owns each team. It reveals no content.

A compromised directory origin can add a member. A member reads everything team-visible in every instance of that team, through each app's ordinary front door, because that is what ruling 1 means. It cannot read an individually granted or guest-only item, write as a person, or grant a per-item right. This is the delta ruling 4 and ruling 12 actually introduce.

A compromised credential origin can sign in as anyone, owners included. It holds the signing key (home §5.3), the instance's grants join is keyed on the sub the home asserted, and home §5.4 already calls a hostile sub account takeover. No membership row is needed and none is left behind. This is not new and ruling 4 did not cause it: it has been true since home ruling 1 put every credential on one origin, and a passkey does not help, because the passkey lives there too. It is cited here, not introduced here.

The step-up is not a bound on any of them, because the compromised authority is the one performing it. Neither is the directory row or the notification: those are what honest code leaves, not what a compromise must. Home §3.3's idiom applies — said plainly rather than counted as a fix.

What is left as a real bound, and it is narrower than revision 3 said. Against the directory tier: an instance's own grants decide what an admitted member may read, so adding a member does not reach an individually granted item. Against the credential tier: nothing here does. An attacker who can sign in as Ana has Ana's grants, reads what Ana reads and writes what Ana writes, and no instance-side check distinguishes them — that is what "signs in as anyone" means, and the bound has to be read as absent rather than restated in weaker words.

Revision 3 conceded the credential tier in one paragraph and then wrote the reassuring clause back in two paragraphs later, which is worse than revision 1's honest-but-wrong single bound. (GPT-6 finding R3-1.)

The Pegamento filing changes shape. It is not that this document diverges from §10.3 on membership. It is that the home was never a §10.3 glue: "a compromised glue grants nothing" is written for a registry, and home ruling 1 makes the home an identity authority. §14 files that, not the narrower claim.

5.6 Roles

The roster knows two: owner and member. Per-item roles stay the app's own. Sheets has commenter; calendar does not; Docs has none yet. The doctrine does not unify them, because a shared role type designed from three specs at once would fit none (estilo's one rule). When two apps have shipped the same per-item vocabulary, it may move to the contract module. Not before.

---

6. The suite contract

One Go module, amadan.net/oficina/suite, with a client half, a server half that mounts beside an app's own router, and golden fixtures. memoria §6 specified S1 through S7 and the activity design specified call 7; both move here unchanged in substance. The home's calls 1 to 6 stay in the home spec, which owns them, and are cited here for completeness of direction.

| Call | Direction | Credential | Proves | Notes | |---|---|---|---|---| | 1–6 | person → home, instance → home | session; consumer token | — | Home §9. Unchanged. | | 7 activity | home → instance | assertion for the person, aud = instance | who the front door is for | design-activity-pull §4–5 owns the wire shape. The home renders and holds rendered output only, under two ages (§4.3). Not in the contract module yet — §12 step 2 is S1, S2 and S3. When it arrives, the fixtures cite that spec's gates 10–20 rather than restate them, or this contract rebuilds §2's drift one layer down. | | 8 roster | instance → home | consumer token | which instance asks | §5.3. Scoped to the caller's team. Paged; the copy has a TTL. | | S1 change feed | sibling → sibling | consumer token | same-team sibling | (item_id, revision, gone, touched_at). No title, no content, no visibility flag. Per-consumer TTL; past it, full re-announce. | | S2 authorization | sibling → sibling | consumer token + named asker | same-team sibling, asking for a person | Four values, total decoder, cap 256 pairs. Never cached: a passage crosses no request boundary without an S2 VISIBLE in the request that carried it (memoria §8.4, gate 26). Asker is a typed subject (§3); the answer is intersected with custody (§4.3). | | S3 content | sibling → sibling | consumer token | same-team sibling | (id, revision), no person. Team-visible only. 404, never 403. | | S6 aggregate | sibling → Sheets | consumer token + named asker | as S2 | Enumerated function over cell refs, never expression text. Cap 64. Typed subject and the custody intersection, as S2. | | S8 write-as-self | sibling → sibling | consumer token | same-team sibling | §7.2. Into the caller's designated area only; only items the caller authored. | | hand-off | browser → instance | the person's own session | the person | §7.1. A redirect POST, the shape of home call 6. Not a server call. |

S7 membership is retired in suite shape. It existed because there was no roster of record; call 8 is that record. A lone instance never needed it. memoria decision 11 is superseded (Appendix A.4).

S6's shape is a settled decision of Paul's, not an API style. memoria decision 10 — "memoria never does arithmetic. A number comes from a cell, or from Sheets' engine via S6" — was reached by two models independently and forbids one specific failure: a model averaging numeric strings it retrieved. That failure stacks incomplete recall on wrong operand selection and arithmetic done outside the engine that owns it, and it cites its sources correctly while being wrong, which is the hardest failure in this product to catch. So S6 takes an enumerated function — SUM, AVERAGE, MIN, MAX, COUNT — over cell refs, and never expression text, because a call that accepted expression text would let a consumer grow into a formula author one release at a time.

Recorded here because §6's row said what S6 takes and not why, and a reader tidying an enumerated function into a general one would have been removing a ruling without knowing there was one. (memoria decision 10, Paul; surfaced by the memoria session, 2026-09-05.)

S6 is a call, and until its step it is a specification without a fixture. Ruling 7 says fixtures are the interface, so a call with no fixture has no interface — it has a description. §12 step 4 builds it, after memoria slice 1 and before slice 2, because Sheets is its only server and memoria its only caller and neither is useful to it alone. Until then a consumer cites S6's specification here and not a golden fixture, and A.4 says so rather than implying one exists.

S4 and S5 are not calls, and no number is reserved for them. memoria §6.1 resolved S4, the tombstone, into a feed row — gone covers deletion and departure from team-visibility indistinguishably — and S5, consumer expiry, into the per-consumer TTL, since expiry is the decommission verb. Both are settled; they are recorded here because a table that runs S1, S2, S3, S6, S8 leaves two holes, and a hole in a numbered contract is somewhere a later call falls. (Review pass, 2026-09-05.)

6.1 Why two credentials

Only the home can mint an assertion, and putting the home in the loop of every memoria search would break memoria §6.4 and its 800 ms deadline at once. So a sibling asking "may Ana see these" sends its consumer token and names Ana. The sibling is trusted to name the asker because a compromised sibling already reads everything team-visible through S3; the naming adds nothing to what it can read. It would add something to what it can write, which is why S8 takes no asker (§7).

The home does hold the signing key, so call 7 carries a real assertion and the answering instance decides from its grants with no trust in the home's word. Ruling 3 of the activity design, adopted.

6.2 Authentication and rotation

Per-consumer bearer tokens, minted by the operator drain, delivered as platform config, stored hashed by the receiver. Three-phase rotation: expand acceptance, switch the sender, contract acceptance (memoria §6.2). The home never sees a sibling token. Mutual TLS is unavailable because TLS terminates at the platform router.

6.3 Availability

Every pull carries a deadline, all siblings are called concurrently, and a sibling past its deadline is UNKNOWN: withheld loudly, the gap named with the app. Partial pages are the normal case. A cold sibling is a wake, and a wake is slower than any deadline, so a consumer pre-warms on its own wake (memoria §6.5, activity design §6). A reliably slow sibling is a suite health problem the consumer surfaces, never one it routes around by caching authorization.

6.4 What the contract does not license

Any hop across a <team> label. Any sibling presenting an assertion it did not receive from the home for its own aud. Any write except §7. Any item outside the custody predicate. The home in the loop of a sibling call. Content leaving the team's hosts except under ruling 6.

---

7. Writes

The question "may memoria write a Doc" has two answers because it is two questions.

Both answers carry the same envelope. §4.3 requires a derived artefact to carry the provenance of every source it was built from, transitively. That rule had no mechanism at the one moment it matters — when content crosses from one app's store into another's — so it is stated here, for both write paths.

A write carrying content derived from items in other apps carries a provenance envelope: per source, the app of record, the item id and the revision read. The receiver stores it as part of the item, not as metadata it may drop, and re-checks it on every disclosure path. Which check depends on whether the path has a person, because two of them do not:

| Path | Has an asker? | The check | |---|---|---| | An ordinary read, an export, an activity row | Yes | S2 to each app of record, for that person | | An onward S3 fetch | No — S3 is person-less by definition (§6) | Custody: every source still team-visible, or S3 answers 404 | | A read through a read-only link | No — a link holder is no roster subject | The item carries no link while any source is not itself link-shared |

Revision 3 wrote "the sources still authorize the asker" for all of them, naming an asker on two paths that have none and leaving gate 6b unwritable. The person-less paths fall back to the predicate that needs no person, which is the same split decision 3 has always drawn: custody for what may be held and served without an asker, authorization for what a person may read. (GPT-6 finding R3-4; Fable finding 3.)

Withholding is whole-artefact, never per-passage. If any source stops authorizing, the entire derived item is withheld and the gap is named. A synthesis carries no map from its sentences back to its sources, so an envelope that claimed to strike "the passage from the revoked sheet" would be asserting an alignment nobody computed. Removing the wrong sentences leaks; removing the right ones by luck is not a design. (GPT-6 finding R3-5.)

Two consequences, both counter-intuitive enough to state:

• A new id is not a new authority. Saving a memoria answer into Docs gives the result a Docs id; it does not give it Docs' authority over a Sheets cell it quotes. Ana's grant on the new Doc is necessary and not sufficient. Revoke the sheet and the saved answer loses that passage, in Docs, on the next read.
• A source the receiver cannot check is a source it must not accept. memoria's decision 7 and gate 17 forbid it serving a sibling-facing endpoint at all, so today a hand-off carrying memoria-owned material has no app of record to ask. Until A.4 opens that surface with its own decision and leak entry, a write whose sources include one is refused, rather than accepted with an envelope nobody can verify. A person's confirmation establishes their intent; it does not stand in for an authorization the receiver cannot make. (GPT-6 review, finding 3.)

7.1 A person is present: the hand-off

"Save this answer as a Doc" is Ana's act. memoria renders a form whose action is Docs' create endpoint on Docs' own host; Ana's browser POSTs it with her own Docs session; Docs sees Ana and Ana owns the document. memoria holds no write credential and Docs trusts nothing memoria says.

Same-site cookies make this a plain form: <team>.memoria.oficina.works and <team>.docs.oficina.works share a registrable domain, so a Lax session cookie rides the POST. Body size is capped by the receiver, with the number's reason in a comment. A person with no Docs session is sent through sign-in and returns to the pending state by nonce, the flow home §5.5 already specifies. This is scriptless and satisfies every app's zero-JS floor.

The receiver checks the origin and asks the person to commit. What makes the cookie ride the POST — same registrable domain — is also what makes this a write any same-site page can drive without the person meaning it, and a create endpoint that commits on receipt is a drive-by. Home call 6, whose shape this borrows, carries two protections this borrowed without (home §5.6): it validates hosts against the consumers allowlist, and it binds the flow to the browser that began it. So:

• The Origin header must match a row in the receiver's consumers table, which §4.1 already makes an origin allowlist. It holds the §4.1 barrier on a path that otherwise bypasses it.
• The receiver renders what it received and the person commits it. One screen, one button, the person's own session. This is what makes the document Ana's act rather than memoria's, which is the entire claim of §7.1; without it §7.2's three constraints are reachable by any sibling through §7.1, and the distinction between the two sections collapses.

Both cost more than revision 2 said they did. It claimed no new machinery and no extra round trip. Neither is true, and the third hand established it against the pinned dependencies rather than by reading the specs: memoria's rastrillo default CSP sets form-action 'self', which stops the form on the way out; Docs mounts csrf.Protect above every route and its SameOrigin check refuses a same-site cross-origin POST, measured at 204 same-origin against 403 same-site; and for a person already signed in, receipt-then-commit is a second POST where revision 1 wrote on the first. So the real bill is a narrowly scoped sender form-action allowance, a dedicated receiving route carrying its own origin guard, and one more round trip — and gate 7 has to run through that middleware, since a handler-level fixture passes while a browser does not. Still scriptless, which was the property worth protecting.

Receipt and commit are two requests with different rules, and revision 2 left the second unspecified. Split:

• Receipt. The sibling's POST arrives, its Origin is checked against the consumers allowlist, and the body is held as pending state: bounded, expiring, redeemable once, bound to the browser and — after sign-in — to the authenticated person. Nothing is created.
• Commit. The person's confirmation POST comes from the receiver's own origin, against that pending state, and what it commits is the body the server already holds. The sibling-origin rule does not apply to this request and would wrongly reject it. Because the body is fixed server-side a second POST cannot substitute a different one, and because the pending state redeems once, a replay creates nothing.

Without the split, a bare second POST carrying a confirm flag can be sent by the same allowed sibling, and a screen appearing somewhere in the flow is not evidence that this browser saw this body.

The sending side has a boundary too, and it is earlier than the receiver's. §4.1's rule that a client refuses a host whose <team> label differs governs the sibling HTTP client; an HTML form action is not that client. A form action misconfigured to another team's Docs host puts the body on the wire before any Origin check at the far end can refuse it, which breaks §0's "across" test literally: the byte arrives, and being refused on arrival is not the same as not arriving. So the destination is validated against the sender's own <team> label before the form is rendered, not after it is submitted. (GPT-6 review, finding 4.)

7.2 No person is present: write-as-self

A weekly digest. A Notion page ingested and written out as a Doc. That is memoria's act, and rastrillo already models a non-human actor. S8 lets a sibling create or modify items as itself, under its consumer token, subject to three constraints the receiver enforces and the conformance suite tests:

• Only into an area the team owner designated for that sibling. A folder, a tag, a calendar, whatever the app's own grouping is. The designation is an instance-side grant, made in the receiving app's share UI, and it is what makes S8 refusable per team.
• Only items the sibling authored. Every S8 write carries the writer's identity in the item's actor field, and an S8 modify is refused for any item whose actor is not the caller.
• Never a person-authored item. Stated separately because it is the attack the constraints exist to prevent.

The attribution rule holds: anything that writes is attributed, and "memoria" is a name a reader can act on.

7.3 What was rejected, and why it stays rejected

On-behalf-of writes: a sibling writing "as Ana" under its own token. It would make every consumer token a write capability over every member's identity, and the receiving app could not tell Ana's edit from a compromised sibling's. The read-side version of this trust (S2's named asker) is acceptable because it adds no reach; the write-side version adds all of it.

Browser-carried only: forbids unattended writes, which the product wants, and would push implementers toward a person-present pretence.

A link holder as a writer. Revision 3 built one, and it was wrong twice over: Sheets ruling 12 had already rejected it (ruling 15), and it would have put an actor on the write path that no app can name — which ruling 9 forbids and §7's provenance envelope cannot carry. A link reaches sign-in; sign-in mints a grant; the grant names a person. There is no fourth actor.

---

8. Egress

One sentence, binding on every app:

> Egress that is a property of the product is forbidden. Egress that is > per-team opt-in, to one named recipient, disclosed in the README's first > paragraph and on every artefact it produced, with a working floor when > it is off, is admissible.

Which recipient is the app's decision, never the team's. A team chooses whether, and never whom: a team-configurable endpoint would let an owner reinstate a proxy while every answer still printed "one named provider" (memoria decision 13, Paul, 2026-09-05).

Docs §11.2's rejection of conversion APIs stands under the first clause. Its own reason is that the egress sends customer documents to a third party, which is what the passage says; "unavoidable and unnamed" is this document's narrowing of it under ruling 6, not a reading of what it already meant. A per-team optional converter with one named provider could satisfy §8 and would not have satisfied Docs §11.2 as written. Ruling 6 authorises the change; the citation must not dress it as a discovery. (GPT-6 review, finding 15.) memoria §8.3's model provider stands under the second, and the comparison is like with like: memoria's embedding ingest is whole-corpus egress, comparable in volume to what Docs rejected, differing only in the three properties the second clause names (discussion 33). Both specs cite this section and delete their own wording (Appendix A).

---

9. The suite leak list

Each app keeps its own. These are the costs that exist only because the apps are a suite, and every one is a consequence of ruling 1 or 4.

1. A compromised sibling reads everything team-visible in its team, across every app, through S3, and everything that was team-visible when it was ingested. This is what "one trust domain" means and there is no version of ruling 1 without it. Custody buys two things and not a third: it cannot read an item that was never team-visible — private, granted, or link-only (§4.2) — and an honest consumer retires what leaves; a compromised one retires nothing, and no revocation reaches a copy it already holds (ruling 14).
2. A compromised sibling can name any asker on S2, and so learn which team-visible items a given member may see. Bounded by item 1: it can already read them all. The bound holds only because S2 is intersected with custody (§4.3); without the intersection it would also learn which private items exist, which item 1 does not cover and §4.2 forbids.
3. A compromised sibling can write into its own designated area as itself (S8). It cannot write as a person or touch a person-authored item.
4. A compromised home is three events (§5.5, ruling 13). A leaked database gives up the graph, the roster, and who owns each team. A compromised directory origin can add a member, and that member then reads everything team-visible in every instance of the team. A compromised credential origin can sign in as anyone, owners included, with no membership row and nothing left behind — not new, and not caused by ruling 4: it is home ruling 1's standing cost of one credential origin. The first two cannot read a private, granted or link-only item, write as a person, or grant a per-item right. The third can do all of it, as whoever it signs in as. Neither the step-up nor the notification bounds any of them, because the compromised process is the one performing them.
5. The home page holds titles and actor names in RAM for the length of a response and a short cache (activity design §7). An XSS on the directory origin reaches call 7's output, which is titles, never documents. Never at rest.
6. The hand-off puts a document body in a POST across two origins of one site, in the person's browser. It is the person's own content moving under the person's own session, and the receiver caps it.
7. A rendered page is a copy in a browser, and revocation never reaches it. True of every surface in the suite: a Docs page, a memoria result, the home's activity list. Live authorization bounds what the next request shows; nothing bounds what the last one already did. Stated so nobody argues a surface is safe because it re-checks (memoria §3.2).
8. Every instance of a team now holds the whole team's roster, with roles, rather than only the people it had heard of (§5.3). A compromised instance therefore learns the membership and the owners of its team, which under the old per-instance tables it could only partly infer.
9. Owner is a new plaintext class at the home (ruling 12). Publishing the database now identifies each team's owners. Home §0's sentence and gate 8 change to say so; the roster is not the no-op for that claim revision 1 assumed.
10. The home learns when a person visits their front door, at per-visit granularity, and tells that person's instances so they can answer call 7 (activity design §2.2). And once the home makes outbound calls to instances as a matter of course, its outbound traffic stops being a compromise signal (activity design §2.2(b)). Both were disclosed there and belong here too.
11. A cacheable call-7 response is a cross-person leak at the platform edge, not merely a slow one. The shared edge would serve one person's rows to the home's next pull for another, so a cacheable response is a failed pull rather than a fast one. design-activity-pull gate 16 tests it; recorded here because the failure is in the platform between two apps and neither app's own tests would see it.
12. A link capability is bearer-shaped (ruling 15). Whoever holds the URL reads or writes the item, the app cannot name them, and a forwarded link is a grant nobody recorded. This is what "anyone with the link" means and there is no version of it that is not this.

---

10. Where things live

Repositories stay separate (ruling 10). oficina/suite holds this doctrine and the contract module. Estilo stays the design system's home and is the precedent for a shared module every app pins.

Cite, never restate. Each app spec gains a section, Consumed suite rulings, listing ruling numbers from §1 and the doctrine commit it was read against. Where an app spec today restates a boundary, contract, or egress rule, the restatement is replaced by a citation (Appendix A). Sheets AGENTS.md's "a contradiction is fixed in the same commit" becomes "a contradiction with the suite doctrine is a bug in the app spec, fixed by citing", which can be kept across repositories, where the old rule could not.

Conformance is the interface. The contract module ships golden request and response fixtures for every call and a test each app runs in CI against the version it pins. Estilo's rule: two specs are guesses, two implementations are facts. The fixtures are what memoria's server half and Docs' server half both have to satisfy, and they are corrected by the second adoption.

The two-pins trap is the stated cost. Apps pin the contract module; the module pins nothing (it is types, fixtures and a thin client, with no rastrillo dependency), so the chain is one deep. Contract changes are additive-only, and a removed field is a new major version.

Docs moves its module path from github.com/carlosframework/docs to amadan.net/oficina/docs before it imports the contract. Every other app is already there.

---

11. Testing gates

Gates live in the contract module and each app runs them in CI. A gate that cannot be written as stated is a spec bug.

1. Fixture conformance. Every server half reproduces the golden response for every golden request, per call. A new fixture is added with the first client that needs it.
2. S2 total decoder. For any 256-pair request, the client yields exactly one result per pair or UNKNOWN for the whole call. Tested with short, duplicate, malformed and non-2xx responses, and with an asker subject of a kind the receiver does not key on, which is UNKNOWN for the whole call and never NOT_VISIBLE.
3. Custody, one fixture per rung. S3 answers 200 for a team item and 404 for private, granted, guest-only, link-shared-but-not-team (ruling 15) and deleted. The status and body are identical for "not team-visible" and "does not exist". S2 answers NOT_VISIBLE for the same item id in each state, byte for byte the answer for the deleted one — the asker holds a live grant in the private and granted states and a former grant in the deleted one, since no schema keeps a live grant against a deleted row. Add team-plus-link (team-visible because of the rung) and a link added or revoked after ingest (no change to custody either way).
4. No cross-team dial. Zero connections to a host whose <team> label differs — acme-evil, acme.docs.oficina.works.evil — and zero follow-up connections when an allowed host answers with a redirect to another label. The literal "without connecting" cannot be written for the redirect case: a client must reach the allowed host to be told to redirect. Two fixture servers, or an instrumented transport that counts connections per host. The hand-off's destination check (§7.1) runs in the same gate, before the form renders.
5. Roster, on a fake clock. A member removed at the home, holding no other grant, gets an empty call-7 list and NOT_VISIBLE on S2 from every instance after one epoch, and within the roster TTL on an instance that admits nobody. A guest fixture keeps exactly the activity its own grant reaches: losing team standing does not revoke an instance-side grant, and asserting an empty list for that person would implement a complete-offboarding policy §5.2 has not agreed to. A failed refresh past the TTL yields UNKNOWN, not NOT_VISIBLE, admits nobody new and stops serving team standing to an existing session. A home rewound — both to a lower epoch, and to the same epoch numbers under a recovered roster — readmits nobody, and an unfamiliar generation holds the roster stale until an owner confirms. A failed middle page leaves the previous roster in place. A lone instance, given a home hostname in a fixture, makes no request to it.
6. Write-as-self. S8 is refused outside the caller's designated area, refused for an item whose actor is not the caller, and refused entirely when the team has designated no area. The actor is derived from the authenticated consumer, never from the request body, and a spoofed actor field is refused. 6b. Provenance survives the hop (§7), one case per path because the paths differ. Write an item into app B derived from sources in A and C. Revoke A's source for a person: B's ordinary read and export withhold the whole artefact and name A — never a partial redaction. Make A's source non-team-visible: B's S3 answers 404, on custody, with no asker anywhere in the call. Give B's item a read-only link while A's source has none: the link is refused. Assert a write is refused when a source's app of record serves no S2 at all.
7. The hand-off, through the real middleware. A handler-level fixture passes where a browser does not, so this runs against the app's actual CSP and CSRF stack: receipt refused when Origin is outside the consumers allowlist; a POST without a session lands in sign-in and returns to the pending state by nonce; a body over the cap refused with no partial write; commit refused when forged, replayed, sent with a changed body, or sent from a different session; the absent and null origin cases decided explicitly; a foreign-team destination refused before transmission; and one successful same-team flow end to end.
8. Publish the home's database. Counts, team names, memberships — and, new with ruling 12, who owns each team. Home §0's sentence changes rather than survives; revision 1's claim that the roster added no column class was wrong. The test runs against the actual persisted schema and its failure paths, not one roster response fixture, because a fixture cannot prove what an entire database holds at rest, and a column audit alone misses new information encoded in existing columns.
9. Citation currency. Each app spec's Consumed suite rulings section names a doctrine commit and the doctrine revision it read, and the script checks the revision actually belongs to that commit. The revision is in the status block and is bumped by any normative change, wherever it lives — §§3 to 8 bind as hard as §1 and §6. Revision 2 scoped the bump to §1 and §6, which let a changed hand-off rule or stale-roster policy pass currency indefinitely. The script fails when a spec is more than one revision behind main; that grace period is a deliberate compatibility allowance and not evidence the consumer meets current requirements. ("One ruling behind" was not measurable at all — a change to §6 adds no ruling. Review pass 2026-09-05; scope corrected from the GPT-6 review, finding 16.)

---

12. Sequencing

1. ~~This spec, reviewed.~~ Done twice, 2026-09-05: Claude Opus 5, then GPT-6 via Codex. See the status block. Revision 3 answers all sixteen of the second review's findings; the third pass is §14's first open item.
2. The four amendments (Appendix A) land in home, Docs, Sheets and memoria. This closes oficina/docs discussion 33 and unblocks memoria slice 1, which its own §13 says is blocked on agreement, not code. A.1 is now the largest of the four, because ruling 12 gives the home a table it did not have and amends home §7's sentence that ownership is the instance's business.
3. The contract module — built, and not importable. The code, the fixtures and the harness are on main and their tests pass. Nothing can depend on them: go get amadan.net/oficina/suite fails because the hub redirects ?go-get=1 to a login page, so the toolchain never sees a go-import tag. Until that is fixed this step is done in the sense that the artefact exists, and not done in the sense ruling 7 means: "every app imports the module" has no consumers available to it.

Three ways out, and the choice is Paul's, because each is hub or hosting rather than doctrine: the hub serves go-import for repo paths without auth, which is the only one that works in CI and fixes every app at once; a documented GOPRIVATE=amadan.net/* with credentials CI can hold, if the hub can serve the tag behind auth; or the module moves to a resolvable host, which contradicts ruling 10 in hosting but not in structure.

What is deliberately not being done: a local replace directive, which works on one machine and breaks CI while making a go.mod a machine-local artefact, and vendoring, which is the second copy ruling 7 exists to prevent and defeats "fixtures are the interface" the first time a fixture changes. The memoria session declined both and recorded itself blocked, which is the right answer.

Types and fixtures only: S1, S2, S3, the hostile-hostname fixture, gates 1 to 4. No server half yet. Docs moves its module path.

1. memoria slice 1 against the module, with Sheets and Docs serving S1 to S3. The second adoption corrects the fixtures.
2. S6, before memoria's slice 2 and not before its slice 1. Sheets serves it, memoria calls it, and nobody else does either: an enumerated aggregate over cell refs, capped at 64, never expression text, carrying the typed asker and the custody intersection S2 carries.

Slice 1 does not need it — that is S1, S2, S3 and memoria §4.1, all of which the module already has. Slice 2 is memoria's model layer, and the numeric and aggregate class of its §8.2 router is the one query class S6 answers. Revision 6 put this step before slice 1, which implied a dependency that does not exist; revision 5 gave it no step at all, which let a numbered call read as a finished one.

1. The home's identity layer (home §13 step 4) and, on top of it, call 8 and the roster (§5). Gates 5 and 8.
2. Call 7, the activity pull, once the home can mint assertions (home §13 step 10).
3. The hand-off from memoria to Docs. Gate 7.
4. S8 and the designation UI in one receiving app. Gate 6.

Steps 2 to 4 do not wait for the home. That is deliberate: the sibling contract has no home in the loop and its tokens are a separate switch (§3), so memoria can ship against Sheets and Docs in lone shape with sibling tokens and an owners list, and the roster arrives later as a change to where the list comes from.

---

13. Deliberately not built

| Thing | Trigger | |---|---| | Cross-team anything | Never, under ruling 2 | | On-behalf-of writes | Never, under ruling 9 | | A unified per-item role vocabulary | Two apps ship the same one (§5.6) | | A core monorepo | Never while the suite is a consolidation (ruling 10) | | Home-side search or aggregation over pulled content | Never, under home §2.2 as amended | | A roster in lone shape that syncs anywhere | Never; lone means lone | | Push from an instance to the home | A hibernation model that runs timers, which the platform does not have | | A token exchange so siblings can hold assertions | The home's latency budget can afford being in every search, which §6.1 says it cannot | | Mail and files as suite apps | A wrapper around keymail or slopbox that serves S1 to S3 and takes a roster | | An instance-side check on membership changes — refusing a roster addition, or a call-7 arrival, for a person with no recent session; an owner countersignature on roster writes | A designed mechanism. Ruling 13 concedes a compromised home rather than bounding it, and this is the shape a bound would take. Recorded so it reads as absent by decision, not by oversight | | A link share that a sibling can index | Never, under ruling 15. A link is a capability, and a capability that becomes searchable by the team is a different grant than the one made |

---

14. Open

• A third review pass, on revision 3. Two models have read this and the second returned request changes; revision 3 answers all sixteen of its findings and adds four rulings, so what needs reading now is different text. Rulings 12, 13 and 14 are Paul's, taken on Fable's recommendation. Ruling 15 is this session's proposal from Paul's product requirement and he has not ruled on it — a reader should treat it as the one rung of §1 that is not yet settled.
• What the second review said, kept for the record. CODEX-FINDINGS.md is unedited beside this file; the map from its findings to revision 3 is in the status block. Its six trust-boundary findings were: finding 1, the instance-token write path into the rows §5.1 made authoritative → ruling 12; finding 2, the compromised-home bound → ruling 13; finding 6, custody as rendering rather than erasure → ruling 14 and §0; finding 3, provenance missing from both write paths → §7's envelope; finding 5, the failed refetch and the rewound home → §5.3; finding 4, the commit protocol → §7.1. The ten at P2 are answered in place and cited where they landed.
• Pegamento filing. §5.5's divergence from Pegamento §10.3, and ruling 1's application of §1 to a suite, both to carlos/pegamento.
• memoria's citation baseline. Four things this document cites — decisions 13 and 14, gate 26 and §8.4 — resolve only in memoria's unmerged tensorx-provider worktree at 8dfc3c9, not on its main at 5869e73. The doctrine was read against a branch without saying so. Asked at oficina/memoria discussion 1; when it answers, either the citations move to the commit that carries them or the claims come out. Nothing else in this document depends on them.
• The /auth/begin dial. rastrillo's sign-in classifier fetches .well-known/keymail on the typed address's domain before the admission gate, so an anonymous visitor makes any instance dial any host (memoria QUESTIONS §5). It affects every app in the suite and belongs upstream in rastrillo/auth. Recorded here because no single app owns it.
• rastrillo/rastrillo #2, the subject hook and sealed link store, still gates the home's identity layer and therefore steps 4 and 5.
• Whether calendar joins the contract in slice 1 or after its first screens merge. It has a spec and content; bodies stay off by default when it does (memoria §12).
• The deadline number. 800 ms per sibling is memoria's starting assumption, unmeasured. It becomes the contract's default once measured against a cold wake on the platform.

---

Appendix A — the consuming amendments

Each is the text an app spec adopts, replacing its own restatement. Each is one commit in its own repository, and each adds a Consumed suite rulings section naming this document's commit and revision (gate 9).

Where a replacement below still paraphrases a rule, the paraphrase is the defect, not the fix. §10 and AGENTS.md say a rule lives here once and an app spec names it. A replacement that puts a second copy of a boundary into an app spec and then adds a citation beneath it has left the second copy to drift, which is the failure §2 diagnosed. Read each amendment as delete the restatement, name the ruling; the wording given is there to identify what is being deleted, not to be pasted in as a new copy. (GPT-6 review, finding 14.)

A.1 oficina/home, spec §1 and §2.2

Add ruling 23, not 22. The home spec already has a ruling 22 — team selection is navigation state — so the number in this appendix was taken before it was ever used. Landed as 23 on oficina/home branch suite-amendment. (GPT-6 review of revision 3, finding R3-12, confirmed against the home spec on 2026-09-05.)

Ruling 23: "The suite sharing doctrine (oficina/suite) binds this spec. The team is the boundary; the home owns identity, the team and the membership roster; it never owns a per-item grant. Call 8, roster pull, is added to §9."

In §2.2 replace "Never federates. Data does not cross an instance boundary." with "Never crosses a team. Data does not cross a team label; a team's instances across apps are one trust domain (suite ruling 1)." ~~Complete ruling 18's pending change~~ — already landed at 2b68301, along with the other six places that amendment touched. A.1 said "complete" because it was written before that commit; a to-do list in a document whose edits have landed is a trap for the next reader, and the home's own spec retired the future tense rather than ticking it off. Kept here as a record of what A.1 asked for and where it went, not as work outstanding. The original wording follows.

Ruling 18's change of "never renders" to "never stores". Replace "Never holds an authorization model" with "Never holds a per-item grant. It holds the membership roster (suite ruling 4), and answers only facts about its own records (ruling 19)."

In §9 add call 8 per suite §5.3, paged with an epoch-bound cursor.

A.1 is the largest of the four, because ruling 12 gives the home a record it does not have. Add a memberships table, (team, person, role), written only at the directory origin by an owner behind step-up, and seeded by the drain with the first owner from the sealed queue payload §7 already carries. Call 8 reads only that table. Amend §7's sentence that who counts as an owner "is the instance's business… and the home never learns the answer": the home now learns it, for team standing only, and per-item roles stay the instance's. Amend §6 so a directory row is explicitly a hint that never grants or revokes team standing, whatever its kind says, and call 2 cannot write membership. Amend §0 and its gate: publishing the database now identifies each team's owners, which is a new plaintext class (suite gate 8).

Amend §10. "Loses credentials, not access" is false for the roster: a home that loses memberships cannot rebuild it — call 2 cannot write it and no channel reaches a hibernating instance — so recovery is the instances' copies plus an owner's confirmation. The roster carries (generation, epoch) and a restore mints a new generation (suite §5.3).

In §5.3's claims table add roster_epoch. In §5.4 record a narrow invalidation-hint exception rather than claiming the existing test covers it: the epoch is not a closed enumerated set and does not fail cosmetically, and what makes it admissible is that the instance decides nothing from it — an unparseable claim is ignored, a differing claim buys exactly one call-8 refetch, and call 8's answer is what is enforced. In §14 move step-up for instances to built-when: "roster writes (suite §5.4)". (GPT-6 review, findings 1, 12 and 13.)

A.2 oficina/docs, spec §8.2, §9, §11.2

§8.2: replace "'Sharing is membership' forbids data crossing the instance boundary." with "'Sharing is membership' forbids data crossing a team boundary (suite ruling 2). Same-team siblings may pull team-visible content under the suite contract (suite §6), and Docs serves S1 to S3 and S8 wherever sibling consumer tokens are configured." The sibling switch is independent of shape (suite §3): §12 steps 2 and 3 have Docs and Sheets serving lone peers before the home exists, so "in suite shape" would forbid the sequencing this document depends on.

§9: delete the restated five-call contract and the consumed rulings list. Replace with "Docs consumes the home contract as the home spec states it, and the suite contract as oficina/suite states it. See Consumed suite rulings."

§11.2: the rejection stands, and the reason changes rather than being restated. Docs' own words are that a conversion API sends customer documents to a third party. Suite §8 is narrower — a per-team optional converter with one named provider would satisfy it and would not have satisfied Docs §11.2 as written — so the amendment reads "Rejected under suite §8. Ruling 6 governs; this is a qualification of the original rejection, not a restatement of it." This closes discussion 33 by agreeing on the rule, not by claiming both specs always meant the same thing. (GPT-6 review, finding 15.)

Docs' link sharing is read-only (suite ruling 15). An "anyone with the link can edit" share is a link to sign-in that mints a guest grant, which is the shape Docs already uses for its commenter link; the writer is then a named guest and §7's envelope can carry them.

Docs is the first receiver of the hand-off, so its create endpoint takes suite §7.1 whole: the Origin check against the consumers allowlist at receipt, pending state, and a commit from Docs' own origin. Its pinned csrf.Protect refuses the receipt POST today and its route needs an explicit replacement guard; memoria's CSP needs a narrowly scoped form-action allowance for the sending side. Gate 7 is Docs' to run first, through that middleware rather than around it. (Review pass 2026-09-05; extended from the GPT-6 review, findings 4 and 9.)

A.3 oficina/sheets, PRODUCT.md principle 2, spec §8.2, §9, AGENTS.md

PRODUCT.md principle 2: "One instance per team. Sharing is membership across teams: the sheet never moves, and an outside person becomes a scoped member of the team that owns it. Within a team, Sheets is one of several apps sharing one trust domain (suite ruling 1), and same-team siblings may pull team-visible sheets under the suite contract. There is no federation story across teams and there will not be one."

§8.2: append "Team standing comes from the roster the home holds (suite §5) in suite shape, and from $SHEETS_OWNERS in lone shape. Per-sheet roles stay here."

Ruling 12 — "link sharing is viewer-or-commenter, never editor" — needs no amendment. Suite ruling 15 adopts it suite-wide and cites it; Sheets keeps it as the original. This is the direction §10 asks for, and revision 3 went the other way.

§9: as A.2's §9.

AGENTS.md: keep "a contradiction gets fixed in the same commit" and add a second rule beside it. The existing rule is about that file and the Sheets design spec, both of which live in Sheets, so it is a local consistency obligation that works and was never the thing that broke. Revision 1 read it as a cross-repository claim it does not make. Add: "a contradiction with the suite doctrine is a bug in this spec, fixed by citing the ruling." (GPT-6 review, finding 15.)

A.4 oficina/memoria, spec §1, §1.3, §4.3, §6, §8.3, §13

§1: add "Decisions 1, 3 and 4 are now suite rulings 1, 3 and 6; this spec cites them. Decision 11 is superseded: admission is the home's roster (suite §5) in suite shape and the owners list in lone shape. S7 is retired."

§1.3: correct the S3 prose to match §6.1: S3 takes no person; the fix removed the asker rather than adding one.

§4.1: intersect S2's answer with the custody predicate (suite §4.3), and type the asker subject (suite §3). The grants join as §4.1 states it — Sheets §4.5's "plus rows granted to me individually" — answers VISIBLE for an item that is not team-visible, which is the leak §6.1 closed on S3 and the S1 visibility flag, reopened on S2. (Review pass, 2026-09-05.)

§4.3: replace the body with a citation of suite §5.3 and delete the "at least one sibling says MEMBER" rule, which is what made a guest a member.

§6: move the S1 to S6 definitions to the contract module and cite them — with S6 cited as a specification rather than a fixture until §12 step 3 builds it. The module on main is S1, S2 and S3; there is no S6 fixture to conform to, and memoria's §8.7 numeric path would otherwise cite one that does not exist. Adopt the rest of A.4 without waiting for it. Replace §6.4's "Any write" with "Any write except suite §7: a person's own hand-off, and S8 as memoria itself into its designated area."

§8.3: replace the qualification of Docs §11.2 with a citation of suite §8. Decisions 13 and 14 stand unchanged: §8 adopts 13's "the recipient is the app's, never the team's", and ruling 3's "never cached" is the invariant 14 rests on.

Decision 4 widens from "named on every answer" to "named on every answer and every derived artefact", because suite §8 says "every artefact it produced" and means it. An answer is transient; a derived artefact (§5.2) outlives the query and is regenerated when a source changes, so it can carry a different provider from the one that first made it. §5.2 records the producing model alongside provenance so a regenerated artefact never inherits the wrong name. Raised by the memoria session, 2026-09-05.

§4.1 also: define the source-behind case. STALE covers a source that has moved past the requested revision; a source restored from backup can be behind it, and memoria's own §13 records this open. A revision the app of record does not recognise is UNKNOWN, withheld loudly — never VISIBLE, which would authorise a revision nobody can vouch for, and never NOT_VISIBLE, which is the silent value and the exact mistake STALE was added to fix (suite §4.3). (GPT-6 review, finding 11.)

§9.1 and gate 17: decision 7's "no sibling-facing endpoint" now blocks a hand-off whose sources include memoria-owned material, because suite §7 requires the receiver to check every source with its app of record and memoria serves nobody to ask. Either open that surface with its own decision and leak entry, as memoria §12 requires, or record that such a hand-off is refused until it is. Not an editorial change: it decides whether "save this answer as a Doc" works for answers built on memoria's own uploads. (GPT-6 review, finding 3.)

§11: memoria's person-ref and home dependency on slice 1 survives A.4 as written. Slice 1 runs in lone shape against sibling tokens (suite §3, §12 step 3), so the dependency is on the typed asker subject, not on the home. Correct it, or slice 1 stays blocked on something that is not actually in its way.

§4.3 and its admission fixtures: retiring S7 leaves the admission gate citing a call that no longer exists. Replace the fixtures too, not only the prose.

§13: close the blocker "the source apps must adopt decision 1" against A.1 to A.3 when they land.

A.5 oficina/calendar

No restatement exists to replace. Add Consumed suite rulings naming rulings 1 to 15, with the doctrine's commit and revision, when calendar's first screens merge. Calendar has no commenter role (verified in internal/calendar/models.go), so §5.6's "not before" applies to it unchanged.