oficina / suite Public

OK, what's next?

I need the decisions asked much more plainer, with maybe an example. Also maybe a Fable or Alpha suggestion on each?

<task-notification> <task-id>a27ebfc49ecbf1847</task-id> <tool-use-id>toolu_01L74sBL2jz4UTF7iuWwQKvN</tool-use-id> <output-file>/home/paulca/.cache/tmp/claude-1001/-home-paulca-amadan-net-oficina-suite/df6721cd-97ce-45b2-b664-3fea70beada0/tasks/a27ebfc49ecbf1847.output</output-file> <status>completed</status> <summary>Agent "Fable recommendation on three rulings" finished</summary> <note>A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once.</note> <result>I've read all three documents and checked the load-bearing citations against the home spec on the trunk worktree (`5a42f2d`), the memoria spec, the Docs spec, the activity design and Pegamento's doctrine. Recommendations follow. ## A. Membership gets its own write authority (finding 1) **Recommendation.** Membership is a record of its own at the home: `(team, person, role)`, written only at the directory origin by a team owner behind step-up, or by the drain when it provisions the first owner. A directory row says where a person has things and never grants or revokes team standing; call 2 cannot write membership, and call 8 reads only the membership record. Ruling 4 holds; §5.1's derivation is retracted. **Why.** §5.1's "smaller than it reads" was my economy in revision 1, and it was a false one. I chose to derive the roster from existing directory rows because it added no table and let gate 8 keep the home §0 claim untouched. Verifying it now, it fails on three counts, not one: - The write path GPT-6 names is real. Home §9 call 2 is instance → home under a consumer token, via the outbox, and Docs §9.1 confirms the instance supplies `kind`. Pegamento §10.3 and home ruling 9 make that safe precisely because the row is a hint. §5.1 changed the reader without changing the writer. - The row cannot carry what call 8 returns. Home §6's directory row is `(person ref, app, team sqid, host, kind)` with `kind ∈ {member, guest}`. There is no owner role anywhere in the home's model; home §7 says outright "Who counts as an owner is the instance's business... the home never learns the answer." So `role: owner|member` in §5.3's wire shape has no source row. - The row is per `(team, app)`; the roster is per team. Under ruling 1 a member of Acme is a member of every Acme instance, so "member of acme.docs but not acme.sheets" is not a state the roster can express, but it is exactly what a projection of directory rows produces. §5.4 also needs the home to know who an owner is before it can gate a write on one. That is circular without an owner record the home itself holds. The bootstrap is already in home §7: the first owner arrives as sealed queue payload and the drain seeds it. **Rejected alternatives.** (1) Derivation from call-2 rows, revision 1's own choice, for the three reasons above. (2) Keeping call 2 as the membership write but requiring an owner step-up on each upsert: the home cannot verify "this instance's caller is an owner" without the roster it is trying to build, and it turns a consumer token plus a relayed person into a write capability over identity, which is the on-behalf-of shape ruling 9 rejected on the write side. (3) Instance-side rosters reconciled by asking siblings: already rejected in ruling 4 and by memoria decision 11's failure. **What it costs.** A `memberships` table at the home. Owner role is a new plaintext information class: publishing the database now identifies each team's owners, so home §0 and gate 8 change rather than stay "unchanged" (this is also finding 13). Adding a teammate becomes a home-origin act, not a Sheets or Docs share-dialog act, which is a product change every app spec must consume. A migration when call 8 lands: each instance's current member table becomes the proposed initial roster, confirmed by an owner, then demoted to a hint. Home §7's sentence that ownership is the instance's business is amended, so A.1 grows. Tests GPT-6 names: member upsert, revoke and delayed replay under an instance token, none of which may touch the roster; instance-scoped revoke deletes directory rows only. **Is GPT-6 right?** Yes, and it understates: the design was not only unguarded, it could not have been built as written, because the row lacks the role and the scope. ## B. What a compromised home means (finding 2) **Recommendation.** §5.5 names three compromises and concedes each. 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; the directory row and the notification are what honest code leaves, not what a compromise must. A compromised credential origin can sign in as anyone, owners included, and no instance can tell; that has been true since home ruling 1 put every credential on one origin, and ruling 4 adds nothing to it. What a compromised home still cannot do: read an individually granted or guest-only item, write as a person, or grant a per-item right. **Why.** I wrote "cannot read a document, cannot grant a sheet" by lifting home §2's "a compromised *directory* grants nothing... does not cost a document" and widening it to "home". Home §2 is careful to say directory; home §5 says "Sign-in is an authority, and says so"; home §3.1 keeps two threat models apart and records that its own first draft collapsed them and was wrong to. I repeated the collapse. Three specific corrections: - "Cannot read content" is false the moment a member can be added: the added account reads everything team-visible through every instance's ordinary front door. §9 item 1 already concedes this for a sibling; §5.5 has to concede it for the home. - "Cannot act silently" counts as evidence what honest code writes. Home §3.3 has the right idiom, "said plainly rather than counted as a fix", and the activity design §2.2(b) already concedes that after call 7 an exfiltrating home is indistinguishable from a working one. - Impersonation of an existing owner needs no membership row. The signing key is in platform config on the credential origin (home §5.3), and the instance's grants join is keyed on the `sub` the home asserted; home §5.4 says a hostile `sub` is account takeover. The instance's own grants are a bound on *what Ana may see*, never on *whether this is Ana*. Even a passkey does not help, because it also lives at the credential origin. The Pegamento filing changes shape with this. It is not "§5.5 diverges from §10.3 on membership"; it is that the home was never a §10.3 glue. §10.3's "a compromised glue grants nothing" is written for a registry, and the home is an identity authority by home ruling 1. Ruling 4 widens the *directory* origin's blast radius from the graph to membership, and that is the honest delta. **Rejected alternatives.** (1) Keep §5.5 and say step-up bounds it: step-up is performed by the compromised authority. (2) An independent audit mechanism, such as an instance-side rule that refuses a membership change or a call-7 arrival for a person with no recent session, or an owner countersignature on roster changes: real, but a new mechanism no spec has designed, and the activity design already says it belongs to instances. Record it in §13 with a trigger, not as a bound. (3) Retreat to Pegamento §10.3 by dropping ruling 4: returns to four unreconciled tables and the sentence memoria decision 11 could not write. **What it costs.** No code; honesty. Home §0's publish-the-database sentence gains "and who owns each team". §9 item 4 is rewritten to the three-tier form, and the Pegamento filing is refiled as "the home is an identity authority and §10.3 does not hold for one". The suite loses the comfortable sentence that a compromised home "does not cost a document". **Is GPT-6 right?** Yes on every point. The one thing to hold: the impersonation risk is not a defect *of this doctrine*. It is home ruling 1's known cost, and the correction is to cite it, not to design against it here. ## C. §0's "inside" test (finding 6) **Recommendation.** Custody is bounded at acquisition and retired by the feed; it is not enforced by erasure. Publish what a team's instance holds and the worst anyone learns is what that team could read in the owning app when the copy was taken. An honest consumer retires a copy within one feed pull plus its snapshot retention, and revocation never reaches a compromised one; that is §9 item 7 one layer down, stored bytes instead of a rendered page. **Why.** I wrote the inside test as an instantaneous statement because I wanted the one rule to be one clean sentence, and I knew better: §4.2 defines departure from visibility as a `gone` row a consumer pulls later, and §9 item 7 already concedes that revocation never reaches a rendered page. I did not carry that lag into §0. Home §0 records the identical mistake and its fix: "never stores your address" was "a claim the schema could not keep", so it became "never stores a *readable* address" with §3.2 carrying the window. The precedent was in the family and I did not follow it. The window is real and memoria already says so. memoria §7.4: "A snapshot is not a cache; it is a durable copy that outlives the deletion it predates", with retirement waiting out the backup retention window. memoria §3.2: a downgraded chunk "has already left" (to the provider). So a memoria bucket published with its DEK reveals content that Docs made private an hour ago, with no bug anywhere. And the compromised-consumer case is ruling 1's own meaning: a trust domain does not un-share. **Rejected alternatives.** (1) Making custody an erasure rule, with source-driven tombstone push or synchronous purge on `gone`: push is rejected on three grounds in memoria §6.1, no channel reaches a hibernating instance, and erasure cannot be enforced across a process boundary, which is exactly why ruling 1 made the team the boundary and not the process. (2) Sealing pulled content under a source-held key so revocation is key destruction: a consumer that has indexed has content in another costume (memoria §3.1, embeddings are content), so the key buys nothing against the copy that matters, and it is a new mechanism. (3) Keeping the sentence and calling it aspirational: §0 says falsifiable, and a test that is false for a window is not a test. **What it costs.** The clean sentence. Every consumer states its retirement bound by citation (memoria §7.4 already holds the number: snapshot retention plus the backup window), and the contract module carries that reason with its other constants. One gate: ingest, privatise at source, pull `gone`, advance a fake clock past the bound, assert the bytes are retired. §9 item 1 gains "or was team-visible when it was ingested", and memoria's README claim (§3.6) gains a sentence for sibling content matching the one it already has for connectors. The "across" half of §0 should also be scoped to paths the suite provides, as GPT-6 asks; a person exporting a file and uploading it elsewhere was never something the suite could prevent, and the sentence should not read as if it were. **Is GPT-6 right?** Yes on the window and on the compromised consumer. Slightly overstated in one place: "a compromised consumer retains permanently" is not a new leak class, it is §9 item 1 restated with a tense, and the fix is a clause, not a mechanism. The point that `gone` cannot erase knowledge that an item existed is true and minor; the id and revision history remain, never the body. ## One note across all three Each of these is a place where revision 1 borrowed a comforting sentence from a sibling spec and dropped the qualifier that made it true: home §2's "directory" became "home", home §0's "readable" became nothing, and ruling 9's "hint" became "authoritative" without changing who writes. The findings are right in each case, and the corrections are all in the direction the family's own specs already took.</result> <usage><subagent_tokens>104761</subagent_tokens><tool_uses>25</tool_uses><duration_ms>210229</duration_ms></usage> </task-notification>

Yes, sounds good. I'm agreeing with these calls.

We want any document to be: - private to me - shared with specific individuals - shared with the whole team - anyone with the link can [view|edit] etc.