amadan
Cite the suite doctrine once, and stop asserting what another repo's main is
Paul's coordination work, plus two review passes on it. It is about citations and a repository hazard rather than design, and it caught the sharpest thing of the day by turning its own rule on itself. The doctrine had been cited two ways and neither could be confirmed. Two commits after revision 4 had changed normative text — §4.3's call-7 carve-out and §5.3's epoch scoping, both consumed here — without bumping the revision, which that document's own gate 9 forbids. It is revision 7 at 2b78680 now, cited identically in this spec's §1.1, in the home spec's §13a and in the status block, and verified rather than assumed: the doctrine's §1 rulings table is byte-identical between revision 4 and revision 7, so every ruling either spec consumes is unchanged across all three bumps. §1.1 moved off revision 5 because an "is main" assertion had gone false, and then made the same assertion about revision 6. That one held for fifty-three seconds. A citation of "revision N at commit X" is a fact about history and keeps; "X is main" is a claim about another repository's present tense that no document can hold, and chasing it defeats the one-revision grace gate 9 exists to give. Both specs say "reachable from main" now, and present-tense observations carry dates. The second instance was mine and is worse. The review reported that a second such claim was "already false when written", and I wrote that in on report. It was true by forty-five seconds and went false twenty-six minutes later — checked at source only afterwards, in a paragraph whose entire subject is not doing that. The record says what happened and where the wrong version came from. Also records why the repository on disk was lying: for most of the day every merge reached the remote and nothing fast-forwarded the shared checkout, which sat at 291d957 with an empty specs directory, so a reader going to the repository found no document at all. The rule that came out of it lives in oficina/suite's AGENTS.md and is cited here rather than copied. Three upstream items filed rather than absorbed: the doctrine's call-7 row cites this spec's gates as 10-20 where they run 11-21, and its §14 calls ruling 15 unruled while its own §1 attributes it to Paul. Reviewed by Fable 5.1 across two passes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PsPrUY5B4wtAZHGZJ3PJyS
2 files changed,
+294
−25
docs/superpowers/specs/2026-08-30-home-design.md+1 −1docs/superpowers/specs/2026-09-05-activity-pull-design.md+293 −24
CI passed — run details
diff --git a/docs/superpowers/specs/2026-08-30-home-design.md b/docs/superpowers/specs/2026-08-30-home-design.md| index dca7ddf..4883df7 100644 |
| --- a/docs/superpowers/specs/2026-08-30-home-design.md |
| +++ b/docs/superpowers/specs/2026-08-30-home-design.md |
| @@ -1417,7 +1417,7 @@ ships**, because call 2's person ref is what their grant rows key on. |
| ## 13a. Consumed suite rulings |
| The suite sharing doctrine (`oficina/suite`) binds this spec. Read against |
| -**revision 4, commit `210312f` — with §5.4 here consuming a revision-5 rule (the epoch exception's call-8 scoping), which gate 9's one-revision grace allows and which is named rather than glossed**. Ruling 23 adopts it. |
| +**revision 7, commit `2b78680`**, reachable from that repository's `main`. (An earlier version of this line cited revision 4 at `210312f` under gate 9's one-revision grace; three revisions later that grace is spent, and the cited revision now contains §5.3's epoch scoping outright rather than by grace. **Every ruling this spec consumes is textually unchanged from revision 4 through 7** — 5 changed the status block and A.1's note; 6 and 7 scheduled S6 and added §6 paragraphs, and the doctrine's §1 rulings table is byte-identical between 4 and 7.) `design-activity-pull` §1.1 carries the same citation and the fuller account.. Ruling 23 adopts it. |
| | # | What it settles for the home | |
| |---|---| |
diff --git a/docs/superpowers/specs/2026-09-05-activity-pull-design.md b/docs/superpowers/specs/2026-09-05-activity-pull-design.md| index aab6362..75b303d 100644 |
| --- a/docs/superpowers/specs/2026-09-05-activity-pull-design.md |
| +++ b/docs/superpowers/specs/2026-09-05-activity-pull-design.md |
| @@ -1,7 +1,15 @@ |
| # 🤖 Activity on the front door — design |
| -**Status:** design, 2026-09-05, revised three times the same day. |
| +**Status:** design, 2026-09-05, revised three times the same day and once |
| +again to coordinate with the suite sharing doctrine (see below). |
| Drafted by the activity-stream session (`claude-opus-5`). |
| +**The coordination revision was reviewed 2026-09-05 by Fable 5.1**, which |
| +returned CHANGES NEEDED on two blocking findings — both of them §1.1's own |
| +rule turned against it: an "is `main`" assertion that held for fifty-three |
| +seconds, and a second that was true for forty-five seconds and went false |
| +unnoticed. Both are fixed, |
| +and the wording moved to reachability. The four passes below predate that |
| +revision and are recorded separately. |
| **Review passes: three, all by Fable 5.1, all returning CHANGES NEEDED.** |
| The first found six blocking (a superseded §11, §7 contradicting itself on |
| @@ -24,6 +32,16 @@ and one claim in §5 was falsified by §5.3's own last line. That session |
| wrote enough of the resulting argument to no longer be independent, and it |
| says so itself. **A fresh reviewer is still required.** |
| +**Coordinated with the suite sharing doctrine, 2026-09-05.** `oficina/suite`, |
| +`docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md`, revision 7 at |
| +`2b78680`, adopts this design as **suite contract call 7** (its ruling 11). Five points |
| +were settled with that session and are reflected below: the doctrine's §4.3 |
| +now carves out call 7 explicitly, the wire shape stays here rather than moving |
| +into the contract module, the `roster_epoch` invalidation exception is scoped |
| +away from call 7, §1.1 records what this spec consumes, and §3 stops |
| +restating a clause the doctrine's Appendix A.1 owns. What changed here, and |
| +what changed there, is listed at §1.1. |
| + |
| **Scope:** how the home's front door (§11 of the home design) shows a person |
| what has been happening in the team they are looking at, across that |
| team's apps that they personally have rows in, without the home |
| @@ -86,6 +104,111 @@ load-bearing test in the document. |
| --- |
| +## 1.1 Consumed suite rulings |
| + |
| +The suite sharing doctrine's gate 9 requires a consuming spec to name the |
| +document, its commit **and its revision**, and to list the rulings it takes — |
| +and to *cite* rather than restate them, because a second copy of a boundary is |
| +the drift the doctrine exists to stop. This section is that citation. Nothing |
| +below is restated here in its own words. |
| + |
| +**Document:** `oficina/suite`, `docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md`, |
| +**revision 7**, commit **`2b78680`**, **reachable from `main`** in that |
| +repository. (Its checkout resolved the file when this was written on |
| +2026-09-05; that is an observation with a date on it, not a standing claim, |
| +for the reason the next paragraph gives.) |
| + |
| +**"Reachable from `main`", not "is `main`" — and that wording is the point.** |
| +An earlier draft of this section wrote "that commit is `main`", moved the |
| +citation *because* such an assertion had gone false, and then made the same |
| +assertion again: it was true for **fifty-three seconds** before revision 7 |
| +landed. A second such claim, about the suite's own `AGENTS.md` at |
| +`47ae0e8`, was **true when it was written — by forty-five seconds — and went |
| +false twenty-six minutes later, unnoticed.** (An earlier draft of this |
| +paragraph said it was already false when written. It was not: the claim was |
| +made at 18:02:07Z and `47ae0e8` had been `main` since 18:01:22Z. That |
| +correction came from the review, was taken on report, and is only right here |
| +because it was checked at source afterwards — in a section about exactly that |
| +failure.) A present-tense claim about |
| +another repository's tip cannot survive in a document, and chasing it defeats |
| +gate 9's one-revision grace outright. **Reachability is durable** — true |
| +until somebody force-pushes — so that is what this spec asserts. Where a |
| +present-tense observation is genuinely wanted, it is dated and past tense. |
| + |
| +**Why the revision moved twice in an evening, when it did not have to.** |
| +Gate 9 lets a consumer sit one revision behind so it is not chased on every |
| +edit, and **every ruling this spec consumes is textually unchanged from |
| +revision 4 through 7** — verified step by step: revision 5 changed the status |
| +block and A.1's note; revision 6 gave S6 its own §12 step and added a §6 |
| +paragraph and A.4's cite-as-specification note; revision 7 moved S6 and gave |
| +it a reason. **The doctrine's §1 rulings table is byte-identical between |
| +revision 4 and revision 7**, so none of it reaches §1.1's list. The citation moved |
| +for the wrong reason (chasing an "is `main`" assertion) and now sits at |
| +revision 7 for the right one: it is the current text, and the wording no |
| +longer makes a promise that expires. |
| + |
| +| Suite ruling | What this spec takes from it | |
| +|---|---| |
| +| 1 | The team is the boundary; a team's instances across apps are one trust domain. This is why ruling 6's per-team scoping is the correct shape and not a narrowing. | |
| +| 3 | Custody and authorization are two rules, and authorization is never cached. §7 is the one carve-out, and §4.3 of the doctrine now writes it. | |
| +| 4 | The home owns identity, the team and the membership roster, and never a per-item grant. §5.1's argument is re-derived against this. | |
| +| 7 | One contract, one module, fixtures as the interface, and a consuming spec cites rather than restates. This section exists because of it. | |
| +| 8 | Two credentials chosen by what the call proves. Call 7 carries an assertion because it must prove *which person the call is for*, which a consumer token cannot (§5). | |
| +| 11 | Activity is pulled at render and held nowhere at rest — this design, adopted as call 7. | |
| +| 15 | Three rungs and a read-only link. Only the `team` rung is team-visible. Relevant to §5.2's guests, and the reason call 7 never needs a visibility flag. | |
| + |
| +**What this spec gave back, recorded so the direction of each borrowing is |
| +legible:** the doctrine's §4.3 call-7 carve-out is this §7's two ages, |
| +reconciled with that session; the epoch scoping in its §5.3 was raised from |
| +here; and its leak-list item 11, a cacheable call-7 response as a |
| +*cross-person* leak at the platform edge, is gate 16, credited there. Its §6.3 |
| +sentence — *"a reliably slow sibling is a suite health problem the consumer |
| +surfaces, never one it routes around by caching authorization"* — is ruling 5 |
| +generalised, and is cited in §8 as the doctrine's wording of it. |
| + |
| +**Why the number was 5 and not 4 — history, kept because it explains the hazard. This spec's first coordination revision |
| +cited 4.** Two commits after revision 4 changed normative text without bumping |
| +the revision: `574cc84` and `bf0eeb8`, the second carrying the §4.3 carve-out |
| +and the §5.3 epoch scoping that this spec consumes. The doctrine's own gate 9 |
| +requires a bump on any normative change, so revision 4 was being cited while |
| +its text moved underneath the citation. Raised from here after this spec was |
| +handed one commit for revision 4 while this repository's `suite-amendment` |
| +branch carried another, `210312f`, and neither could be confirmed; the doctrine |
| +session bumped to revision 5 and recorded the reason in its status block. |
| + |
| +**`210312f` was not an error where it appeared, and now it is.** Revision 4 |
| +was correct when those citations were written and sat inside gate 9's |
| +one-revision grace. That grace has since been spent twice over: the home |
| +spec's own ruling 23 landed on `main` citing revision 4, and the Docs and |
| +Sheets amendments — unmerged, on their `suite-amendment` branches — still do. |
| +**Three revisions behind fails gate 9**, which allows one. This spec and the |
| +home spec move together in this commit; the other two are named here so they |
| +are not forgotten. |
| + |
| +**What made this hard to see, recorded because it will recur.** For most of |
| +2026-09-05 the doctrine existed only on that repository's origin and in its |
| +worktrees: every merge went to the remote, and nothing updated the shared |
| +checkout, which sat at `291d957` with an **empty specs directory**. A reader |
| +going to the repository on disk found no document at all, and the only |
| +readable text was a worktree — which is why the first coordination revision |
| +cited a working tree rather than a commit and said so. The checkout is now |
| +fast-forwarded and the file resolved when this was written on 2026-09-05 — |
| +dated, for the reason two paragraphs up. |
| + |
| +**The rule this produced now lives in `oficina/suite`'s `AGENTS.md`** (merged |
| +`47ae0e8`, reachable from that repository's `main`): fetch before reading a spec |
| +you did not just write, and fast-forward the shared checkout after you merge. |
| +It is cited here rather than restated, for the same reason §1.1 exists — this |
| +paragraph records why the citation in this spec was hard to get right, and |
| +that file records what everyone must now do about it. What the rule guards |
| +against is not the empty directory, which is loud, but the quiet version: a |
| +session reading a file a few commits behind, citing a hash that resolves, and |
| +being wrong about the text. Gate 9 checks that a citation's revision belongs |
| +to its commit; **nothing checks that the reader read the commit**, and that |
| +gap is open. |
| + |
| +--- |
| + |
| ## 2. Why pull, and what it inherits from a parked design |
| **This shape was proposed before, in the other direction, and parked.** On |
| @@ -334,26 +457,37 @@ the honest version: "it never learns what is in anything" now has to be read |
| as *never retains*. That reading belongs in §0's own gloss rather than left |
| for the two documents to disagree about. |
| -§2.2's first never-do changes, and only its verb: |
| - |
| -> ~~**Never renders content from an instance.** No previews, no thumbnails, |
| -> no cell values.~~ |
| -> |
| -> **Never *stores* content from an instance.** No previews at rest, no |
| -> thumbnails, no cell values, no titles in a database, a log, an error |
| -> string, a metric label or an on-disk cache. It **may render**, transiently |
| -> and per request, **and only to that person**, what an instance hands it for |
| -> the person it hands it for. |
| - |
| -**On approval, seven places change, listed so nobody hunts:** this design's |
| -status block and §12's first bullet; home spec §0's gloss and §2.2's verb |
| -with its "until then" note; §11's "No activity feed yet"; §13 step 10's |
| -"must be revised"; §15's open bullet; and `AGENTS.md`'s "The one rule", which |
| -quotes §0 verbatim, and its four-things list. The same edit lands in `AGENTS.md`'s "four things this service never does" — |
| -**on approval, not now.** That file is binding and says the spec wins where |
| -they disagree, but a binding file must not be rewritten to follow a spec |
| -whose review has not run (§12). Until then, `AGENTS.md` is correct as written |
| -and this document is a proposal against it. |
| +§2.2's first never-do changes, and only its verb: *never renders* becomes |
| +***never stores***. |
| + |
| +**The replacement text is not reproduced here, and that is deliberate.** It |
| +lives in the home spec's §2.2 and in the suite doctrine's Appendix A.1, which |
| +owns the amendment as part of home ruling 23. An earlier revision of this |
| +section quoted the new clause in full; the doctrine's Appendix A preamble |
| +names exactly that as the defect — *"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"* — and it is right. **What this document owns is the |
| +argument for the change, below. What it does not own is the wording.** Read |
| +the clause where it is binding. |
| + |
| +**Landed, not proposed.** An earlier revision said "on approval, seven places |
| +change" and listed them. The approval came, and `main` carries the amendment |
| +at `2b68301`: the home spec's §2.2 and §0 gloss, and `AGENTS.md`'s "the one |
| +rule" and its four-things list, all read *never stores* as of 2026-09-05. The |
| +future tense is retired rather than merely updated, because a list of places |
| +still to edit, in a document whose edits have landed, is a reader's trap. |
| +`AGENTS.md` is no longer a binding file this design contradicts; it agrees. |
| + |
| +**§2.2's other two never-dos also change, and neither is this design's to |
| +land** — noted so the count in this section's title is not read as the count |
| +of changes to §2.2. §2.2's *never federates* |
| +becomes *never crosses a team*, and *never holds an authorization model* |
| +becomes *never holds a per-item grant* with the roster held explicitly — |
| +suite rulings 1 and 4, arriving as home ruling 23 on branch |
| +`suite-amendment`, not as part of this work. It is named here only because |
| +§5.1 rests on the old wording and had to be re-derived against the new (see |
| +§5.1), and because a reader comparing §2.2 against this document should know |
| +which of its changes came from where. |
| **Why the amendment is small rather than a hole in the doctrine:** |
| @@ -439,6 +573,28 @@ bug on its most public page. |
| with no grant gets, and what a quiet team gets. It is **not** what a broken |
| team gets — see §7, which is the entire point of ruling 5. |
| +**This spec owns the wire shape, and the suite contract module does not |
| +duplicate it.** Suite ruling 7 puts every inter-app call in one Go module with |
| +golden fixtures as the interface, which raised the question of whether call 7 |
| +moves there. Settled with the doctrine session on 2026-09-05: **it does not.** |
| +Call 7 is absent from the module's first step, which builds the |
| +sibling-to-sibling calls only, and the doctrine's contract table records that |
| +this section owns the shape. When call 7 is built, **the module's fixtures |
| +cite gates 11 to 21 rather than restate them** — the reason being the one |
| +suite §2 is about, that a restatement is a second copy free to drift, and a |
| +fixture that has drifted from the gate it was written for is worse than no |
| +fixture because it passes. |
| + |
| +Two consequences worth stating. **Gate 16's cacheable-response case is now a |
| +suite-level concern**, recorded as item 11 on the doctrine's leak list, |
| +because the failure lives in the platform edge *between* two apps and neither |
| +app's own tests would ever see it — the home's tests do not run the edge, and |
| +the instance's tests do not know a second person exists. And **an instance |
| +implementing call 7 is conforming to this document**, not to a module, until |
| +that module carries it; a spec is a poorer interface than a fixture, which is |
| +§12's problem and not a reason to move the shape somewhere it would be |
| +restated. |
| + |
| --- |
| ## 5. Authentication, and why it needs nothing new |
| @@ -494,6 +650,24 @@ and it is an answer precisely because the home does not participate in it. |
| activity assertion for `acme.sheets` is not valid at `bigco.sheets`, so no |
| shared store is needed — §5.3's reasoning carries over untouched. |
| +**The assertion will carry `roster_epoch`, and call 7 must decide nothing from |
| +it.** Home ruling 23 adds the epoch to §5.3's claims table as a narrow |
| +exception to §5.4's boundary test — narrow because the epoch is not a closed |
| +enumerated set and does not fail cosmetically, and admissible because 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. |
| + |
| +Call 7 rides the same §5.3 assertion, so it **inherits the claim whether it |
| +wants it or not**. The rule for this path is therefore explicit: an instance |
| +answering call 7 must not withhold, include, filter or reorder a single row on |
| +the strength of the epoch. Refetching a roster is not a decision; withholding |
| +an activity row is. An instance that let the epoch change its answer would be |
| +an instance making a trust decision from a home-supplied claim, which is the |
| +exact thing §5.4 forbids and the reason the exception is written narrowly. |
| +The suite doctrine's §5.3 scopes the exception to the call-8 path and nothing |
| +else. **Gate 21.** |
| + |
| **Rate limiting is the instance's.** The home is one caller and a |
| well-behaved one, but an instance must not assume that; a compromised home is |
| in scope for every instance's own limits. |
| @@ -518,6 +692,25 @@ Call 7 is a narrower shape, and the narrowness is deliberate: |
| - **Errors carry no detail.** "Not for you" and "no such thing" are one |
| response, per §12's gate 4 pattern of 404 rather than 403. |
| +**Re-derived against home ruling 23, because the ground it stood on moved.** |
| +§2.2 used to say the home *never holds an authorization model*, and an earlier |
| +reading of this section leaned on that: the home cannot be an oracle about |
| +who may see what, because it knows nothing about who may see what. Ruling 23 |
| +replaces that clause with *never holds a per-item grant*, and gives the home a |
| +membership roster — so the home now does hold a fact about standing, and an |
| +argument from the home's ignorance is no longer available. |
| + |
| +The conclusion survives, on the two grounds above and only those: **the caller |
| +supplies no refs, and the subject is not caller-chosen.** Neither mentions |
| +what the home knows. This is a better footing than the one it replaces, not a |
| +weaker one — the old argument depended on a property the home might later |
| +acquire, and then the home acquired it. What the roster does add is a separate |
| +disclosure, priced in the suite leak list's item 9 and in home §0's amended |
| +gate rather than here: publishing the home's database now identifies each |
| +team's owners. That is a fact about *team standing*, which the home is now |
| +the record for; it is still not a fact about any item, and call 7 asks about |
| +items. |
| + |
| **What a leaked home does yield**, said plainly: an attacker holding the |
| signing key can mint an assertion for any person ref and read that person's |
| recent titles from any instance they have a grant on. That is strictly less |
| @@ -677,6 +870,31 @@ hard maximum.** Past it, the rows go and the gap is rendered (§8), because |
| that the grant may be gone. Gate 20 drives the hard maximum, not the refresh |
| TTL — a test against the refresh TTL proves the easy half. |
| +**This section is the suite doctrine's one carve-out from "never cached", and |
| +the carve-out is worded the way it is because of what it costs.** Suite ruling |
| +3 holds that authorization is never cached at any scope — not per session, not |
| +per page, not for the life of a warm process. Revision 4 of that document |
| +reached the opposite verdict about this section in two different places, and |
| +the reconciliation, settled with the doctrine session on 2026-09-05, is in its |
| +§4.3: the rule governs an authorization **answer**, and an S2 `VISIBLE` held |
| +past its request is a standing capability that *grows*, because the holder |
| +re-uses it against items and people the app of record never spoke about. This |
| +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. |
| + |
| +**The distinction is real and it is not free, and both documents say so rather |
| +than resting on it.** Inside the cache's life a person removed from a team |
| +still sees titles; calling that "not cached authorization" would be word-play. |
| +That is what the hard maximum is for, and why the doctrine requires the bound |
| +to exist while refusing to carry the number — the number is a property of the |
| +consumer, and **this section is where the consumer states it**, which is why |
| +§12 lists it as one of the four that must be settled before this ships. |
| + |
| +**What this closes.** The doctrine listed *"the activity path's cached |
| +authorization after revocation"* among the things it openly had not answered. |
| +It is not open. It is bounded, the two ages are the bound, and the remaining |
| +work is a number rather than a rule. |
| + |
| --- |
| ## 8. What the front door renders, including when it cannot |
| @@ -701,6 +919,16 @@ empty list, not an error*. A feed that silently drops what it could not fetch |
| is the worst available shape, because it looks exactly like a slow week and |
| nobody files a bug against a slow week. |
| +**The suite doctrine generalises this to every inter-app pull**, and its |
| +wording is worth having here because it names the pressure that breaks the |
| +rule rather than just the rule: *"a reliably slow sibling is a suite health |
| +problem the consumer surfaces, never one it routes around by caching |
| +authorization"* (suite §6.3). The temptation ruling 5 exists to resist is not |
| +laziness, it is kindness — an honest gap looks like a defect, a silent |
| +omission looks like a clean page, and the second one ships. That sentence is |
| +this ruling read back from the doctrine, and §7's hard maximum is the same |
| +principle applied to time rather than to a missing instance. |
| + |
| So each instance that failed to answer gets a row of its own, in words: |
| - `acme · sheets — waking, refresh` (deadline missed; likely cold) |
| @@ -816,6 +1044,15 @@ being no-store (ruling 22), so these start at 11. |
| because the pull failed. A test against the refresh TTL proves the easy |
| half; this is the half that bounds the lie (§7). |
| +21. **`roster_epoch` changes no call-7 answer** (§5). Run the same pull twice |
| + against the same instance with the same grants, once with a matching |
| + epoch claim, once with an epoch far ahead of what the instance holds, and |
| + once with an unparseable one. All three responses must be byte-identical. |
| + An instance that filters, withholds or reorders on the epoch fails — |
| + that is a trust decision from a home-supplied claim, and §5.4 forbids it. |
| + The exception the epoch rides on is scoped to call 8; this gate is what |
| + keeps it there. |
| + |
| --- |
| ## 10. Sequencing, and what blocks it |
| @@ -880,7 +1117,10 @@ is **a gap**, rendered as one, and gate 12 covers that case. |
| - **The review pass.** AGENTS.md requires the highest-capability model |
| available, recorded by name. **Run — four passes by Fable 5.1, the fourth |
| approving.** The three that returned CHANGES NEEDED are summarised in the |
| - status block. What remains open below is design, not review. |
| + status block. What remains open below is design, not review. **Reopened in |
| + one respect:** all four passes predate the coordination revision, so §1.1, |
| + §3's retirement of the future tense, §4's module paragraph, §5's epoch rule, |
| + §5.1's re-derivation, §7's carve-out and gate 21 carry no review at all. |
| - ~~`AGENTS.md` is stale against the home spec on three counts.~~ |
| **Closed 2026-09-05:** `main` carries all three retractions at `5a42f2d`, |
| and `AGENTS.md` there is current. |
| @@ -899,13 +1139,42 @@ is **a gap**, rendered as one, and gate 12 covers that case. |
| The fan-out budget's *number* can wait; its behaviour at the limit is |
| specified in §6 and is not open. |
| +- **An upstream discrepancy to file on `oficina/suite`.** Its call-7 row |
| + says fixtures cite this spec's gates **10–20**; this spec's gates run |
| + **11–21** — there is no gate 10 here (the home spec owns it) and gate 21 |
| + is new. §4's "gates 11 to 21" is right; the doctrine's row is not. |
| +- **Two upstream stalenesses, also to file.** The doctrine's §14 first |
| + bullet still calls ruling 15 unruled while its own §1 attributes it to |
| + Paul; and §1.1 consumes 15 as settled. |
| - **Whether the credential and directory origins are one process.** §5 |
| assumes they are, and the signing-key story depends on it. Nothing on |
| main says either way. |
| - **Two platform facts** the "in RAM" claim leans on and which were not |
| established: whether swap is configured, and whether core dumps are |
| - disabled. Both must be answered before this ships (§2.1). |
| - , not a guess in a spec. |
| + disabled. Both must be answered before this ships (§2.1). Both are |
| + questions for the platform, not a guess in a spec. *(An orphaned fragment |
| + of this bullet, left by an earlier edit, is repaired here rather than |
| + deleted, since deleting it would have silently dropped the clause.)* |
| +- ~~**Which commit revision 4 of the suite doctrine is.**~~ **Closed |
| + 2026-09-05.** It was neither of the two named. Revision 4 was `210312f`; |
| + **`574cc84` then changed a §14 open item and A.1's ruling number 22→23, |
| + and `bf0eeb8` changed §4.3's call-7 carve-out and §5.3's epoch scoping** |
| + — the second of those is squarely normative and this spec consumes it — |
| + **all without bumping the revision, which that document's own gate 9 |
| + forbids.** It became revision 5 at `f627359`, and is revision 7 at |
| + `2b78680` as this lands; **§1.1 carries the current citation** rather |
| + than this bullet, which is why this bullet no longer names one. Verified against that |
| + repository's `main` and its checkout rather than taken on report. The |
| + cause is recorded in §1.1 because it is a repository hazard rather than a |
| + spec one. Checked and clear on this spec's side: its only memoria reference |
| + is a general one in §11 and does not touch memoria decisions 13 or 14, its |
| + gate 26 or its §8.4 — the four the doctrine found resolving only on an |
| + unmerged worktree, and which remain open at `oficina/memoria` discussion 1. |
| +- **When call 7 joins the suite contract module** (§4). It is deliberately |
| + absent from the module's first step, so until it arrives an instance |
| + implementing call 7 conforms to a document rather than to a fixture. That is |
| + a worse interface, accepted for now because the alternative was restating |
| + the shape in two places. |
| - **Front-door layout** is the other session's. This spec deliberately does |
| not draw it. |
| - **Whether `actor` is worth having at all.** It is the field most likely to |