oficina / home Public

Adopt the suite doctrine: membership becomes a record of the home's own

Appendix A.1 of the suite sharing doctrine (oficina/suite, revision 4,
commit 210312f). The largest of the four app amendments, because the
doctrine's ruling 12 gives this spec a table it did not have.

Numbered ruling 23, not 22. The doctrine's appendix said "add ruling 22" and
22 is taken by the team-selection ruling; a review of the doctrine caught
the collision before it landed.

The roster gets its own record. The doctrine's first revision proposed
deriving it from call-2 directory rows, and that was wrong three ways, all
checkable against this spec: §6's row has no owner role, since kind is
member or guest; §7 said outright that the home never learns who an owner
is; the row is scoped per (team, app) where a roster is per team, so a
projection could express "a member of acme.docs but not acme.sheets", which
the doctrine's ruling 1 forbids. And any instance can write a row under its
own consumer token, so reading team standing from one would let a
compromised instance announce a member straight around §14's owner step-up.
Changing the reader without changing the writer is not a design.

So: a memberships table, (team, person_ref, role), written only at the
directory origin by an owner behind step-up, or seeded by the drain with the
team's first owner from the sealed queue payload §7 already carries — the
circularity of gating a membership write on an owner has to break outside
the roster. Call 8 reads it; call 2 cannot write it. Guests are not on it
and nothing about guests changes.

§7 is amended rather than contradicted. The home now learns who owns a
*team*, because the record carries a role. Who owns an *item* is still the
instance's business and the home never asks.

§0 costs a sentence. Publishing the database now identifies each team's
owners, which the old directory row could not express. The doctrine assumed
the roster added no column class; it was wrong, and suite gate 8 tests the
corrected sentence against the persisted schema rather than a fixture.

§2.2's "never federates — data does not cross an instance boundary" becomes
"never crosses a team". The word instance carried a process assumption
nobody had examined. "Never holds an authorization model" becomes "never
holds a per-item grant", because the home does now hold the roster, and the
line is between a fact about its own records and a decision belonging to the
app of record.

§5.4 gains one narrow exception. The roster epoch rides the assertion and
fails the closed-enumerated-set half of the test as written. It is
admissible on a different argument, which is now stated rather than assumed:
the instance decides nothing from it — an unparseable claim is ignored, a
differing one buys exactly one call-8 refetch, and call 8's answer is what
gets enforced. A hostile claim costs one request and can neither admit nor
exclude anybody.

§10 corrects "losing this database loses credentials, not access". True of
the directory, false of the roster: call 2 cannot rebuild it and no channel
reaches a hibernating instance. Recovery is the instances' copies plus an
owner's confirmation. And a restore mints a new roster generation, because
refusing a lower epoch alone is not enough — a restored home reissues the
same numbers and two writes later an instance accepts an epoch it thinks is
fresh, carrying members that were removed.

New §13a lists the consumed rulings and writes out what the doctrine makes
this spec concede: a compromised credential origin can sign in as anyone,
which is not new and ruling 23 did not cause it, but §2's careful sentence
about a compromised *directory* does not cover it and should not be read as
if it did. The Pegamento filing is reshaped too — the divergence is not
about the roster, it is that this home was never a §10.3 glue.

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