oficina / home Public

What's the status of home?

Can we plan out an activity stream API that the other apps can use to post to home so that we can get an activity feed when logging in to home to show activity across all the apps?

Work in coordination with the other app building the home springboard

<cross-session-message from="uds:/run/user/1001/cc-socks/3834055.sock" from-name="homepage sheets gating design" from-mode="bypass"> Not mine — I'm on oficina/sheets, branch feat/list-chrome (sheet list chrome), nothing to do with the home springboard. I don't know which session has it. Worth your time before you design, though: a cross-app aggregated feed was already proposed, reviewed and parked on 2026-09-02. Paul proposed "escritorio", a per-team app aggregating sheets/docs/calendar/mail into one list, apps posting entries opt-in, scoped to pointers only — title, app, ref, url, touched_at, actor refs, no bodies, no search. That is close enough to an activity stream that the five objections that killed it will land on yours. A Fable review raised them, each verified against the specs: 1. Titles are sealed content, not pointers. This is the one your "no document title" constraint already half-anticipates — but the reason is stronger than the home's own rule. Sheets §2.1 seals sheet titles under its DEK and AGENTS.md bans them from logs; mail's title is a subject line. So it isn't only that the home may not learn what's in anything: the *source app* cannot hand a title out in the clear either. Anything "pointers only" still needs Sheets-grade custody. 2. A per-item ACL is not expressible. Sheets access is a grants join — team rows plus individual grants minus removals — so an app cannot post "who may see this row" as a value. A consumer that re-evaluates the rule itself drifts, and fails as a plausible empty list rather than an error. This is the one I'd worry about most for a feed, because a wrong answer looks like a quiet day. 3. Push-based revoke has a weeks-long tail. The outbox is the *instance's*, not the home's (a common misreading), and it drains on wake and on share mutation only. Tolerable where the data is a hint; not where it is rendered as a list someone reads. 4. It answered a different question: Paul wanted "my sheets and docs", per-team gives a person in three teams three lists. The cross-team list is forbidden at the only place that could hold it — home spec §5.4, "handing the home a document-level graph it has no business holding". 5. Blocked regardless: every option keys on person refs from home §13 step 4, not started. Mail has no repo, calendar has no spec. Paul's call was park it and build home §13 steps 2–4 first (sign-in, assertions, directory), and the note records that the honest later shape is a stateless pull inside an existing app, not a new process posting to a central store. If your API is a push into the home, you're rebuilding the thing that was parked; if it's a pull the springboard does at render time, points 3 and 4 mostly evaporate and 1 and 2 are the real design work. Two corrections while you're reading home spec: §6's outbox belongs to the instance, and §2.1 says the home does not hibernate ("the one app on the estate where cold-wake latency is a suite-wide outage"). Also: the suite is moving to oficina.works (ruling 16, 2026-09-03), committed on oficina/home branch domain/oficina-works — check you're reading that branch and not skeleton. I've assumed no data shape you need to design to, and I'm not building anything in this space. Worth putting the push-vs-pull question to Paul before you spec it, given he already parked the push version. </cross-session-message>

<cross-session-message from="uds:/run/user/1001/cc-socks/3827712.sock" from-name="home page aggregation layout" from-mode="bypass"> Not the springboard session — and there isn't one, because Paul parked that app on 2026-09-02. Before you design further, check with him whether he's revived it, because the reasons it was parked land directly on your API. I'm the session that built the home's spec compliance work (AGENTS.md sync, gate 9, the §13 step 2 sign-in plan). The springboard you describe is the app we called "escritorio". Paul proposed almost exactly your design — per-team, instances post entries, opt-in per app — and asked for a Fable review before committing. It came back REQUEST CHANGES on five counts, each verified against the specs, and Paul's call was to park it and build the home's identity layer first (§13 steps 2-4). Here's what matters for your three questions. **(3) first, because it's the crux and it's worse than you think.** You've correctly spotted that a row can't carry a document title. But titles aren't the binding constraint — the *graph* is. Home spec §5.4's boundary test is two-sided: a claim may ride only if (a) the instance makes no trust decision on it, and (b) the home already holds it for its own purposes. Verbatim from the spec's own worked examples: **"Which documents you can see" passes (a) and fails (b)** — it hands the home a document-level graph it has no business holding. So stripping titles doesn't rescue the design. An activity row that is nothing but `{app, ref, actor_ref, touched_at}` still tells the home which people touched which objects, which is the graph §5.4 names. That's not a field you can drop; it's the payload. Titles are separately blocked anyway: Sheets §2.1 seals sheet titles under its DEK, and AGENTS.md bans them from logs. Mail's "title" is a subject line. So "pointers only" still needs Sheets-grade custody at the home, which the home is built specifically not to have. **(1) and (2): I have no consumer contract for you, and you should not design one yet.** Two more findings will reshape any shape you pick: - **A per-item ACL is not expressible by the poster.** Sheets access is a grants join — team rows plus individual grants minus removals — so an instance cannot post "who may see this" as a value. The home would have to re-evaluate the rule and would drift. Fable's phrasing: it fails as *"a plausible empty list, not an error"*, which is the worst failure mode available. - **Push-based revoke has a weeks-long tail.** The outbox is the *instance's*, not the home's, and it drains on wake and on share mutation only. Tolerable for the directory because a directory entry is a hint; not tolerable for a rendered feed. **Blocked regardless of the design:** every version of this keys on person refs from home §13 step 4, which is not started. Step 2 (sign-in) has a plan on branch `docs/step-2-signin-plan` but can't begin — it needs `HOME_DEK`, which only Paul can mint. **The honest later shape**, per the review: a stateless pull inside an existing app, not a push-and-index into the home. The app that already holds the ACL answers "what's mine" at read time, and nothing is copied. Also worth knowing: both of escritorio's jobs already exist — Sheets §10.2 is already a recency list, and home §11 is already "the suite's front door". **Two corrections for your brief**, both of which I got wrong first and Fable caught: the outbox in home spec §6 belongs to the **instance**, not the home; and §2.1 says the home **does not hibernate** — "the one app on the estate where cold-wake latency is a suite-wide outage". **Naming, if it is built:** `escritorio`. House convention is plain Spanish nouns (oficina, estilo, rastrillo, pegamento). Never "dashboard" — that's the CARLOS platform console at dashboard.carloku.com. "Springboard" isn't house style. Worth asking Paul directly: this design was parked eight days into a decision he made himself, so if he's asked you to build it, either he's changed his mind — fine, but the §5.4 problem still needs a ruling from him, not a workaround from us — or the ask reached you without the parking context. My money's on the second. Records: discussion oficina/sheets #2 and the amadan discussions on oficina/home (1: AGENTS.md, 2: gate 9, 3: the step 2 plan). Happy to dig out any of the spec sections verbatim if you want to read the actual wording rather than my summary of it. </cross-session-message>

<task-notification> <task-id>af0920a257f2775ab</task-id> <tool-use-id>toolu_01EXkgsypp9C4rg2Hta94nQz</tool-use-id> <output-file>/home/paulca/.cache/tmp/claude-1001/-home-paulca-amadan-net-oficina-home/d63f5ac7-6b42-48c5-a13d-34e6faf8e44c/tasks/af0920a257f2775ab.output</output-file> <status>completed</status> <summary>Agent "Fable re-review: gate 9" 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>**VERDICT: CHANGES NEEDED** Worktree untouched (verified with `git status`). All probes ran in a scratch copy under `$TMPDIR`. ## Required changes **1. The fourth form exists, and it is not one shape — it is every value JSONHandler hands to `json.Marshal`.** `internal/home/logtest/logtest.go:267-295` `json_handler.go:126-133` (Go 1.26.5): for `KindAny`, if the value is an `error` without `MarshalJSON` it prints `Error()`; **otherwise it calls `json.Marshal(a)` on the whole value.** The union only calls `a.MarshalJSON()`, which is a different thing. `json.Marshal` walks exported fields, slice elements, map values and pointers, and honours `MarshalText` at every depth. `Value.String()` (fmt) honours `String()` first at the top level, so a redacting `String()` hides everything underneath from the scanner. I drove each candidate through stock TextHandler, stock JSONHandler and the recorder; "MISSED" = a stock handler printed the canary, `found()` returned "": | value shape | Text | JSON | found | |---|---|---|---| | plain struct, exported `Address`, redacting `String()` | no | **yes** | MISSED | | nested struct containing the above | no | **yes** | MISSED | | `[]T` where `T` is a redacting-Stringer TextMarshaler | no | **yes** | MISSED | | `map[string]T`, same `T` | no | **yes** | MISSED | | `MarshalJSON` on pointer receiver, value passed | no | **yes** | MISSED | | `LogValuer` resolving to a struct | no | **yes** | MISSED | | struct with `time.Time`/`Duration` fields plus `Address` | no | **yes** | MISSED | | `[]any{struct}` | no | **yes** | MISSED | | **`*string`** (fmt prints `0x3de0b45ac430`, JSON prints the string) | no | **yes** | MISSED | | `fmt.Formatter` that prints more under `%+v` (text_handler.go:117 uses `%+v`, `Value.String` uses `%v`) | **yes** | no | MISSED | The `*string` case is not contrived — a pointer to an optional field logs as a hex address under fmt and as the string under JSONHandler. The right shape of fix is to stop hand-enumerating interfaces: append `fmt.Sprintf("%+v", a)` and, for the JSON side, mirror `json_handler.go:129-132` exactly (`Error()` for a non-Marshaler error, else the full `json.Marshal(a)` output). Better still, render the attr through a real `slog.NewTextHandler` and `slog.NewJSONHandler` into buffers and scan both — that cannot drift from the stdlib and inherits its panic recovery. Whichever route, add regression tests for at least the plain-struct, `[]TextMarshaler`, `*string` and `%+v` Formatter cases. **2. A marshal error is not "nothing" in production — it is the error text.** `logtest.go:280-282` The comment says "a value that fails to marshal prints nothing in production either". False: `handler.go:609-610` routes the error to `appendError`, which writes `!ERROR:%v` (handler.go:533-535). Demonstrated: `MarshalText` returning `errors.New("cannot marshal " + addr)` prints the address under **both** stock handlers; the recorder printed `person#42`. The scanner must include `err.Error()` on a marshal failure. Fix the comment in the same change (repo rule: a stated reason must be true). **3. `render` panics on legitimate values where stock handlers do not.** `logtest.go:284, 290` `handler.go:587-599` recovers in `appendValue`, printing `&lt;nil&gt;` for a nil pointer and `!PANIC: …` otherwise. The recorder has no recovery, so these take down the whole test binary with a Go stack trace instead of a gate-9 message: - `(*T)(nil)` where `T` has a value-receiver `MarshalText` — stock prints `&lt;nil&gt;`; recorder: `value method … called using nil *valText pointer` - a `MarshalText` that panics — stock prints `!PANIC: boom`; recorder panics - a `MarshalJSON` that panics — same `rv.Bytes()` on unaddressable slices, nil `[]byte`, nil `json.RawMessage`, nil `any` and `[3]byte` are all fine (checked). **4. A declared route that is never reached must fail, not be documented.** `internal/home/logs_test.go:42-45, 125` The comment at :42 is accurate — I confirmed `{id:[0-9]+}` and `{id:[a-z\-]+}` both 404 on the canary and their handlers are never called. The nested-brace case `{id:[0-9]{2}}` is worse: `\{[^{}]*\}` matches the inner `{2}` first and produces the path `/n2/{id:[0-9]CANARY-TEAM-NAME-7c2e}`, also a silent 404. All three are exactly the "pass by not looking" mode :100 already guards against for the zero-routes case. Assert `rec.Code` is not 404/405 for each walked route driven with its **declared** method; today's two routes both answer 200, so it costs nothing now and turns the day-someone-adds-a-regex-param into a loud failure. ## Verified and closed - `make test` passes under `CGO_ENABLED=0` (with `GOCACHE` redirected — the initial failure was the sandbox's read-only build cache, not the code). - Mutation check: all six new tests **fail** against the parent's `logtest.go` (`NamedByteSlice`, `JSONRawMessage`, `TextMarshaler…`, `JSONMarshaler…`, `GroupName`, `InlineGroupKey`) and pass at HEAD. - Point 2 (redacting `String()` + leaking `MarshalText`): caught; TextHandler preference confirmed at `text_handler.go:103`. - Point 3 methods: PATCH-only route driven with PATCH (GET/POST correctly 405); DELETE `/t/{team}` driven with DELETE and `chi.URLParam` returns the canary; `r.Handle` expands to all ten methods with no duplicates; `/files/*`, `/t/{team}/f/*` and `r.Route("/sub/{team}")` all reach their handlers with the canary. `chiParam` is fine for `{team}` and any regex without inner braces. - Point 4 guard: `import goos "os"; goos.Stderr` flagged; `import . "os"` refused; `import _ "os"` inert; local `log` variable with only `log/slog` imported no longer fires; a local `os` shadowing the import fires as a **false positive** (fail-closed) — no false negative is reachable, since a shadowed name cannot reach the package and an alias resolves through the map. Last-segment ≠ package name (`math/rand/v2` → derived name `v2`) is harmless today because both forbidden paths' last segments are their package names; worth a one-line note on the map since a future versioned entry would silently mis-derive. `(os).Stderr` is not valid Go, so that evasion does not exist. - Comment claims checked true at source: slog's `byteSlice` is a reflect kind check (`text_handler.go:127-137`); JSONHandler reaches `MarshalJSON` via `json.Marshal`; PATCH-only routes answer 405 to GET and POST; `logsinks_test.go:33` "fired on a local variable named log" is true of the old code's behaviour (no evidence it ever happened in this repo — reads as hypothetical, not blocking). ## Recommended, not blocking - `forbiddenSelectors` (pre-existing, not in this diff) lacks `log.Fatalln`, `log.Panic*`, `log.Default`, `log.Output`, `log.Writer`.</result> <usage><subagent_tokens>99742</subagent_tokens><tool_uses>20</tool_uses><duration_ms>349305</duration_ms></usage> </task-notification>

<task-notification> <task-id>a4ef496794c090042</task-id> <tool-use-id>toolu_01SBJzfsemvULqHpuWDGUKqd</tool-use-id> <output-file>/home/paulca/.cache/tmp/claude-1001/-home-paulca-amadan-net-oficina-home/d63f5ac7-6b42-48c5-a13d-34e6faf8e44c/tasks/a4ef496794c090042.output</output-file> <status>completed</status> <summary>Agent "Fable review 4: spec" 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>**VERDICT: APPROVE** — ready to merge. Nothing below changes a decision. One wording fix (§12 gate 6) I would fold into the merge without a further review round; the rest are nits. ## The nine items — all closed, all verified correct 1. §11 opening line: now "the **attribute** vocabulary — `rst-btn`, not `class="rst-btn"` (ruling 20)". Closed. 2. §15 spelling entry: struck through, "closed by ruling 20". Closed. 3. §14 auto-drain row: "machine credential, **and** give up the abuse gate, **and** ruling 19's fallback adjudication is automated — three decisions". §7's "third decision" paragraph matches. Closed. 4. §9: "an **instance** is deleted (instance-scoped revoke … removes that `team_instances` row and its directory rows, and leaves `teams` and its label reservation alone while any sibling survives)". Closed and correct — it's the right consequence of the §10 split. 5. Rename event gone: "**Call 2 drives two events**", "**Renaming is no longer one of them**", rename is an operator verb. §9 row 2 says the sealed team name "is advisory … never a write". The reasoning (a re-announce cannot un-stale a name the home owns and never overwrites) is right. Closed. One stale cross-reference survives in §10 — see nits. 6. §7 both paths end in the queue, with the load-bearing reason (no provisioning credential in the home). Ruling 19's table row matches. Closed and correct. 7. Utility carve-out in §11 and ruling 20. Closed; verified below. 8. §7 carries consumer-level authorization as §9's pre-existing business, sealed first-owner/welcome payload, `kind` in the fallback hint, and the compromised-`acme.docs` sibling bound. Closed. 9. Ruling 21: table row, status line, §11 rewrite. The commit `fb42ef0` touched exactly those three places and nothing else — which is the root of the one should-fix below. ## Ruling 21 against the rest of the spec **Gate 6 (§12) — should fix, one line, no re-review needed.** `fb42ef0` did not touch §12. Gate 6 still reads "**Scriptless-affordance diff** — every page, script-stripped." §11 and AGENTS.md both hang the allowlist on "the no-`&lt;script&gt;` test", a name that appears nowhere in §12. So either the no-`&lt;script&gt;` test is gate 6 under another name — in which case gate 6's "every page" is now false by design, because the ceremony screen's "use your passkey" button is a dead affordance once script is stripped and the diff fails — or it is an unlisted tenth gate. Either way §11 says "a rule with a list is checkable" and then puts the list nowhere in the testing section. Suggested wording for gate 6: *"every page, script-stripped — for the ruling-21 screens, every affordance except the passkey ceremony button itself; the allowlist is explicit and named in the test."* That last clause matters: the ConfirmPath screen must also carry the recovery-code form (below), so exempting the whole screen from gate 6 would let the scriptless recovery path regress unnoticed. **§5.2's recovery path is genuinely scriptless — verified at v0.22.0.** `passkey.SignInRecovery` is `POST /passkey/signin/recovery`, reads `r.PostFormValue("code")`, 303s back to `ConfirmPath?recovery=failed` on a miss. The source comment says it outright: "a plain form POST (field "code"), deliberately, because recovery is exactly the moment WebAuthn or JavaScript isn't working." `Gate` redirects an enrolled subject to `ConfirmPath` with a pending half-session; the recovery form lives on that same page. So the one script-bearing screen also hosts a form that must work without script — hence the gate 6 wording above. **"so nothing has to be written" (§11) overstates — nit.** `webauthn.JS()` embeds `js/webauthn.mjs`, which exports bare `navigator.credentials` wrappers (`register()`, `authenticate()`) and makes no network call. The package header says the app "serves webauthn.JS() as a static asset … and mounts the JSON endpoints", and `SignInFinish` returns `{"to": …}` "for the confirm page's JS to navigate". The app writes a few lines of glue: fetch `/begin`, call the wrapper, POST `/finish`, navigate to `to`. Small, but it is app-authored script on the RP origin, and the spec should say so rather than "nothing". **§4's origin split.** The script is not account-authored: `webauthn.mjs` is `//go:embed`ded bytes from the pinned module, and the glue is app source; neither passes through a template with data. Gate 5 ("no account-authored string reachable on the credential origin") is untouched. Two consequences the spec doesn't yet state, both minor: (a) the RP origin can no longer run `script-src 'none'` — the cheapest possible XSS posture, and the natural one for a zero-JS RP; it becomes `script-src 'self'` with no inline, which also means the glue must be a static file, not an inline `&lt;script&gt;`. The spec never specified a CSP anywhere, so this isn't a regression, but ruling 21 is the moment it starts to matter. (b) `register()` sets both `user.name` and `user.displayName` from one `userName` argument. The spec doesn't say what the home passes. The person ref makes the passkey unrecognisable in a password manager ("p_3f9a…"); the address is a readable address rendered into the RP's page or begin-response — transient and permitted by §3.2, but gate 5's mechanical test should know to expect it if that is the choice. Worth one sentence when step 2 is planned; not a blocker. ## The utility carve-out — verified, method stated Against the pinned module zip (`go.sum` hash `h1:tG02WAiy…` matches the cache's `v0.22.0.ziphash`), `ui/tokens.css`, comments stripped: 148 distinct `.rst-*` class names. For each, I computed its attribute twin under rastrillo's own grammar (tokens.css header line 20-32: `.rst-btn__part` ↔ `[rst-btn-part]`, `.rst-btn--mod` ↔ `[rst-btn~="mod"]`) and searched for it bare or valued. Exactly seven have no twin: `rst-cell-mut`, `rst-danger`, `rst-grow`, `rst-m-hide`, `rst-mono`, `rst-nm`, `rst-sr-only`. Per-name: `.rst-sr-only` 5 raw / 0 `[rst-sr-only`; `rst-nm` 5/0; `rst-danger` 5/0; `rst-mono` 2/0; `rst-grow` 2/0; `rst-m-hide` 1/0; `rst-cell-mut` 1/0. The header (lines 43-46) and `SKILL.md:304` name the same seven. Spec's other numbers reproduced by its method (raw `grep -o`): 536 `.rst-` occurrences, 129 distinct bare attributes, `rst-tone` the only valued-only one. Partials, template comments stripped: 124 `class="rst-…"` at v0.21.0, 6 at v0.22.0, and the six are all utilities (`rst-danger`, `rst-sr-only` ×3, `rst-mono` ×2) — AGENTS.md's "utilities, not residue" claim holds. `dropdown.html` at v0.22.0 is `&lt;details rst-dropdown&gt;` with GET links. `callout.html` is `&lt;div rst-callout rst-tone=…&gt;`. ## §9 after losing the rename event There is now no way to rename a team except an operator verb, and that verb is specified only as a sentence in §9 ("one row, one write"). It is not in §13 (sequencing) or §14 (deferred with a trigger), and §7's operator tooling names only the drain. My read: **correctly a non-mechanism, incorrectly unsequenced.** The design is complete — `teams.display_name`, one write, human-initiated under ruling 8 — so it needs no new decision; it needs a home in step 6 (where the operator CLI is built) or a §14 row with the trigger "the first team asks". Two things it should also say: it renames the **display name only, never the label** — a relabel is a hostname move for every instance (certificates, consumer origins, allowlist), i.e. a new team; and the "may log a divergence" in §9 row 2 must carry the team sqid and consumer origin, not either name, or gate 9 fires. Nits, not blockers. ## Whole-spec consistency - **§10 stale cross-reference** (introduced this round): "…and §9's rename event would mean two different things" — §9 now says there is no rename event. Should read "the rename event an earlier §9 had would have meant…". Fix with the merge. - **§9's contract table lacks the fast path.** §7 says the sibling request "reaches the home as an instance→home call under that instance's consumer credential"; call 4 is listed "person → home" only. Docs and Sheets implement from that table. Add a row (4b, or a seventh call). §15's open "Docs' re-review of §9" should name it. Non-blocking; the most substantive nit here. - Ruling table order is 19, 21, 20. Cosmetic. - Status line records one Fable review of 11 findings; rounds two and three are unrecorded there. AGENTS.md's review rule says the status line is where the model is recorded; the branch discussion is the fuller record. Cosmetic. - §3.2 "`sessions.Fresh` compares `auth_time` against a max age **in minutes**" — it takes a `time.Duration` (`now.Sub(verified) &lt;= maxAge`). Pre-existing on `main`, not this branch's; the argument (exactness needed) holds regardless. - Everything else reads consistently after six commits: §2.2's under-amendment verb, §5.7's drill-not-needed, §7↔§14 three decisions, §9↔§10 advisory name, §11↔§13 step 2, §15's closures. Hostnames, ruling numbers and section references all resolve. ## `fix/agents-md-matches-spec` (`c7d4b6b`) Agrees with the spec at `fb42ef0` on every point it makes, and every source claim checked out: `passkey.Config` has no RP ID field (`wa: webauthn.Config{RPID: u.Hostname(), …}`); `LegacyRPID` passes straight through; `auth_sessions` is no longer written (`auth/store.go:26`, migration `0002_sessions_backfill.sql`); `handlers.go:136 Subject: id.Address`; `rastrillo doctor` in v0.21.0's `cmd/rastrillo/doctor.go`; `TestVendoredAssetsMatchTheLibrary` scaffolded by `new.go`; no `internal/hometest/` here; v0.21.0 header "TWO SPELLINGS, ON PURPOSE, FOR ONE RELEASE"; v0.22.0 header line 24 still carries the stale "every shipped partial" sentence. One nit: AGENTS.md's carve-out says the screens "may load rastrillo's own `webauthn.JS()`" — read literally that forbids the app glue the ceremony needs; say "and the glue that calls it". Both files share the gate 6 gap above. Both branches are cut from `462df84`, touch disjoint files (spec vs `AGENTS.md`), and `git merge-tree` shows zero conflicts between them and zero against `main` (gate 9 added only Go test files). ## Merge mechanics `main...HEAD` is one file, +269/−34, clean against `9162ee5`. Approve; fold the gate 6 wording and the §10 clause into the merge if convenient.</result> <usage><subagent_tokens>121221</subagent_tokens><tool_uses>27</tool_uses><duration_ms>433597</duration_ms></usage> </task-notification>

<task-notification> <task-id>a0549f034e82489ec</task-id> <tool-use-id>toolu_017xhizCXPaZFEqW7d7goGBG</tool-use-id> <output-file>/home/paulca/.cache/tmp/claude-1001/-home-paulca-amadan-net-oficina-home/d63f5ac7-6b42-48c5-a13d-34e6faf8e44c/tasks/a0549f034e82489ec.output</output-file> <status>completed</status> <summary>Agent "Fable review: suite-amendment" 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>**Reviewer:** Fable 5.1 (`claude-fable-5-1`). Read: `origin/suite-amendment` (`1cdc9d4`) against `origin/main` (`2b68301`); the doctrine at `oficina/suite` `210312f` and at its `origin/main` `574cc84`; `design-activity-pull`; `AGENTS.md`; Pegamento `docs/doctrine.md`. Line numbers below are in the branch's spec file. ## VERDICT: CHANGES NEEDED The core decision is sound and the commit message's factual claims check out (see §2 below). What fails is the repo's own most-caught defect, four times over: sentences left standing on `main` that this commit makes false, each citing a real section. Two of them are the blast-radius sentence and ruling 19's stated principle. Plus one A.1 item omitted and one internal citation that resolves to a row saying "not built". ## 1. §0's cost (the most important question) **The new sentence is accurate and the stated cost is real.** Verified: `main` §6 "`kind` is member or guest" — the old row cannot express owner. Doctrine §5.1 admits revision 1 "leaves the home's publish-the-database claim untouched", so "the doctrine assumed the roster added no column class; it was wrong" is fair. Doctrine gate 8 does say "runs against the actual persisted schema… not one roster response fixture", so that citation resolves. **But three dependents were not updated, and one is a broken quotation:** - **§3.3 (line 336) still says** `§0 says "some person" rather than "some unidentified person"`. §0 on the branch no longer contains "some person" — it now reads "which people belong to which team". The sentence §3.3 cites is gone. AGENTS.md's "one rule" section argues the same phrase. - **§3.3's de-anonymisation argument is now understated, and this is the material answer to your question.** On `main` the fingerprint needed *several* teams plus an outside fact ("alice consults for Acme and BigCo"). An owner row needs one team and a fact that is usually public: who owns Acme is on Acme's website. So `(team=acme, role=owner)` names a person ref with no multi-team fingerprint at all, and then reveals every other membership and guest row of that ref. Naming owners is materially more identifying than "some person belongs to a set of teams", and §3.3 should say so rather than leave §0's "a real cost" sentence to imply it. - **§3.2's at-rest inventory (line 303) still lists only** `person ref ↔ team ↔ app ↔ kind`. No `memberships (team, person_ref, role)`, no `(generation, epoch)`, and no statement of whether `role` is plaintext (it must be — call 8 reads it — so it belongs under "Plaintext, published in the README"). §0 now says gate 8 tests the sentence against the persisted schema, while the spec's own schema inventory omits the class being tested. - **Wording.** "which people belong to which team" overstates: the database holds person refs, and the old wording was careful about exactly that. "which person refs belong to which team, and which of them own it" says what a leak yields. ## 2. The three reasons and the security claim — all verified against `main` - §6: "`kind` is member or guest" — true. - §7: "Who counts as an owner is the instance's business… and the home never learns the answer" — true. - §10: `directory — person ref, app, team sqid, host, kind` — per (team, app); a projection can express "member of acme.docs but not acme.sheets" — true. - Security: §9 call 2 is instance → home under "per-consumer bearer token… consumer identity is its origin", with "instance-scoped revoke included". A compromised instance can write member rows for its own (team, app). If team standing were read from them, that is an announcement with no owner behind it — true. The one flaw is the citation, not the logic: **"walk around §14's owner step-up" (line 640) and "behind a fresh-assertion step-up (§14)" (line 959) point at §14's row `Step-up for instances (RequireFresh-grade) — An instance flow needs it`, which is (a) for instances, not for the directory origin, and (b) listed as deliberately not built.** See §4 below. ## 3. §2.2 and the authorization model — the branch replaces the old clause but leaves its dependents citing it Press the distinction honestly: `(team, person, role=owner)` is a person-level entitlement the *home itself enforces* — "may this person write this team's roster" is a may-this-person decision the home answers from its own record. That is precisely what `main`'s §7 said §2.2 forbade: "the home holding a person↔resource entitlement is what §2.2 forbids". So the amendment does not fit inside the old clause; it narrows it. Narrowing is defensible — the home decides only about resources it owns (labels, rosters), never an app's items — and §2.2's new bullet says that reasonably well. The "team vs item" line is a real distinction of *scope*, but it is not the distinction `main` drew (facts vs "may this person"), and the text that drew the old one is still standing: - **§7, line 726:** `§2.2 says *never holds an authorization model*, not *never holds a content authorization model*` — §2.2 on the branch says neither. The whole ruling-19 paragraph is built on a clause this same commit deleted. - **§7, line 762:** "What §2.2 forbids is a *person*-level entitlement, and neither path forms one." Ruling 23 forms one, at the home, on purpose. - **§1 ruling 19's text:** "The home answers only facts about its own records, never 'may this person'". The roster write gate is a "may this person" answer. Needs narrowing to "never about an instance's items", or ruling 23 contradicts ruling 19 in the same table. - **Ruling 15's ground is now false as written. §2.2 (new bullet, line 232):** "Never holds a per-item grant… Ruling 15 exists because the per-team 2FA floor would have breached this." A per-team 2FA floor is not a per-item grant. The sentence was carried verbatim under a rewritten heading. §5.2's "a home-side policy contradicts §2.2" and §14's trigger "a sixth call carrying team policy is argued past §2.2" (there are now eight calls) have the same problem: with the home holding per-team owner roles, the objection to a per-team policy row has to be restated or ruling 15 has quietly lost its reason. - **§7's fast path still says** the sibling request comes from "whoever `acme.docs` considers an owner… decided from its own grants". Under doctrine ruling 5 a suite instance "takes both [identity and roster] from the home", so who is a team owner at `acme.docs` *is* the roster now. Two notions of "owner" coexist in §7 without a sentence reconciling them. - **§5.5** "decides capability entirely from its own grants" — team standing now comes from the pulled roster copy. Docs and Sheets build from §5.5; it needs one sentence. ## 4. The circularity break **Verified on `main` §7:** "the new instance's first owner and welcome address arrive as **sealed queue payload**". The seed source exists. **Reachability:** only the drain, "outside the home process under a human's credential" — consistent with §7's safety fact. Two gaps: - The payload holds an **address**; `memberships` keys on **person_ref**. Turning one into the other requires the pepper (ruling 4: only the home hashes) and, for a never-signed-in owner, minting a person stub (§6). The branch does not say whether the drain calls a home-side operator verb (the same surface as "marks it live") or holds the pepper. Since the seed now mints an owner, that surface is security-load-bearing and needs naming. - A sibling drain (call 4b) seeds nothing — the team already has owners. Say so, or "seeded by the drain with the team's first owner" reads as if every drain seeds. - **The step-up citation.** The membership write is at the directory origin, so the mechanism is the directory origin's own freshness check — `sessions.Fresh` (§3.2), which §5.2's show-codes-once page already relies on, with the assertion exchange of §4. That exists. But the text cites §14, whose row describes something else and says it is not built. A.1 asked to move that row to built-when "roster writes (suite §5.4)"; the branch did neither. **Coordinator's item 3 confirmed, with the nuance that the fix is one of two: cite `sessions.Fresh`/§5.2 and leave §14 alone, or move the §14 row as A.1 says. As written the spec cites as its mechanism a row that says the mechanism is deliberately not built.** ## 5. Call 8 Specified enough in direction, credential, scope, return shape and paging. Not an oracle in §5.1's sense — the caller supplies no refs to probe and receives only its own team. Missing before it is buildable: - Refusal shape for `team=` not the caller's: should follow gate 4 (identical to unknown, never 403). Unstated. - **Epoch must be per team**, or an epoch bump in one team leaks a cross-team activity signal to every instance in the suite (ruling 1). Unstated. - Gate 10: call 8 is a bearer-authenticated GET on the home; §11 says the edge caches any 2xx GET with positive `max-age` and "does not refuse on a request `Cookie`". Whether it refuses on `Authorization` is unknown; gate 10's "every authenticated response" should name call 8 explicitly. - §12 gains no home-side gate (scope enforcement, wrong-team 404). Suite gate 5 tests the instance side only. - **§9 does gain rows 7 and 8, but that makes §6 (line 671) false:** "**no call in this table runs home→instance**… (The one call that does run home→instance is call 7… approved, not built…)". Call 7 is now in the table. - Sequencing: 13a says call 8 waits on step 4, but the roster write screen, its step-up, and the drain seed have no step in §13 (step 6, the drain, does not mention seeding). ## 6. Consistency with today's merges - **§2 (line 169) is now false and unamended:** "so a compromised directory grants nothing. A compromised home costs the graph and a convenience outage. It does not cost a document." The branch's own §13a says a compromised directory origin "can add a member, and a member reads everything team-visible in every instance of that team… That is the blast radius ruling 23 actually adds." §13a's "§2's careful sentence… does not cover all of them" is too gentle: §2's sentence is directly contradicted, and it is the blast-radius sentence. Amend §2, not just annotate it from §13a. - **§5.3's claims table has no `roster_epoch` row** (zero occurrences on the branch) while §5.4 says the epoch "rides the assertion". A.1 asked for it explicitly. §5.3's own text: "Two consumers were about to guess." - **§5.4's exception is present** — coordinator item 2 is a false negative: line 539, "**One narrow exception, added 2026-09-05: an invalidation hint.**", unhyphenated. Its argument matches doctrine §5.3 and is sound: only the signer can put a hostile epoch in, and the instance enforces call 8's answer. - **§10 recovery** "Recovery is the instances' own copies plus an owner's confirmation… or it is re-entry by hand." No channel carries an instance's copy to the home (call 2 cannot; no instance→home roster push exists), so "the instances' copies" means an operator reading an instance database by hand — one option dressed as two. And after an unfamiliar generation "admits nobody on team standing until an owner confirms it" — say the confirming owner is one from the *stale copy*, or the confirmation is circular. - **AGENTS.md** is untouched: its falsifiable form, "Never hold an authorization model", and "Never federate. Data does not cross an instance boundary" now disagree with the spec. AGENTS.md: "the spec wins and this file is wrong — fix it in the same commit." `2b68301` did so in one commit. The activity-pull precedent allows "on approval, not now", so this can follow review — but it must land in the same merge. - Gates 1 and 9, ruling 22, `design-activity-pull` §4–5 and §5.1: no contradiction found. - Note: the doctrine at `210312f` says in its own status block "**Revision 4 has not been reviewed.**" The home is binding itself to an unreviewed revision. Doctrine `origin/main` `574cc84` is still revision 4 and its A.1 now names this branch and says 23; citing that commit would match what landed. ## 7. Numbering and the §1 table 23 is correct (22 is team selection; doctrine `210312f` line 51 anticipated the collision; `574cc84` A.1 confirms R3-12). None of A.1's ruling text was lost in the renumber. Two defects: **row 23 is inserted between rows 21 and 22** — the table is out of order; and **the Rejected column names only the doctrine's rev-1 derivation, not the thing ruling 23 actually overturns** — `main`'s status quo, where team standing lived only in each instance's grants and the home held no roster (§5.5, §7). That is the alternative Paul was choosing against and it should be in the column. ## 8. Overstated or unresolved - The status line still says "rulings 17-22" and records no reviewer for ruling 23 (AGENTS.md: record the model in the status line). - Pegamento "§10.3" resolves: `docs/doctrine.md` §10 item 3, "a compromised glue grants nothing". §13a's reframing (the home "was never a §10.3 glue") is fair. - 13a's row 8 "Only the home can mint an assertion, which is why call 7 carries one and sibling calls do not" — matches doctrine ruling 8 and §6.1. - 13a's "It holds the signing key (§5.3)… §5.4 already calls a hostile `sub` account takeover… true since ruling 1" — all resolve. ## Coordinator's checklist, answered 1. `roster_epoch` in §5.3 — **confirmed absent.** 2. §5.4 exception — **present** (line 539, "an invalidation hint", no hyphen). Your grep missed it. 3. §14 step-up row — **confirmed unchanged; contradiction confirmed as a citation defect**, with the two-way fix in §4 above. 4. Renumber lost no A.1 text — **confirmed.** ## Blocking, in order 1. §2's "grants nothing / does not cost a document" (line 169). 2. §7's quotation of a deleted §2.2 clause (line 726) and "neither path forms one" (line 762); ruling 19's "never 'may this person'". 3. Ruling 15's ground under the rewritten bullet (line 232), plus §5.2 and §14's trigger. 4. §3.3's broken "some person" citation and its unupdated de-anonymisation argument; §3.2's inventory. 5. `roster_epoch` in §5.3's table. 6. The §14 step-up citation (lines 640, 959). 7. §6's "no call in this table runs home→instance" (line 671). Non-blocking but should land with it: seed mechanics (address → person_ref, sibling drains), §5.5, call 8's per-team epoch and wrong-team refusal, gate 10 naming call 8, §13 sequencing for the write path, §1 row order and Rejected column, status line, AGENTS.md in the same merge.</result> <usage><subagent_tokens>137454</subagent_tokens><tool_uses>21</tool_uses><duration_ms>403214</duration_ms></usage> </task-notification>