# Findings on the suite sharing doctrine, revision 3

Reviewed by **GPT-6 (Codex), 2026-09-05**, independently of the draft and revision-3 authors. These are findings and proposed corrections, not rulings. The doctrine has not been edited.

Scope: the entire doctrine at `76bdc26` (doctrine text last changed in `99a8838`), the change from `0c4f098`, commit messages, the original sixteen findings, and the local sibling sources identified below. P1 means a broken or unenforceable trust guarantee; P2 means a contract, adoption, or verification defect that needs correction before implementation. Findings describe specified behavior, not demonstrated vulnerabilities in deployed applications.

## 1. The sixteen original findings

“Closed” means the original failure sequence has a specified answer. It does not mean the implementation or its tests exist. A new problem in the replacement is identified separately.

| Original | Status | Reason |
|---|---|---|
| 1. Directory writes bypass roster step-up | **Closed** | Ruling 12 and §§5.3–5.4 explicitly separate membership from call-2 hints; upsert, revoke and delayed replay cannot change the roster. The rejected-alternative argument still overclaims: R3-11. |
| 2. Compromised-home bound is false | **Partial** | Ruling 13 correctly concedes impersonation, but §5.5 and §9 immediately deny its consequences; §9 now expressly applies the false bound to all three compromises. Worse in that respect: R3-1. |
| 3. Writes lose source authority | **Partial** | The envelope and refusal of unverifiable sources are real changes, but its S3/link-reader checks cannot be made as specified, and passage removal lacks a safe unit: R3-4 and R3-5. |
| 4. Unprotected confirmation commit and late destination check | **Closed** | §7.1 now fixes the body in bounded, expiring, single-use browser/person-bound pending state, separates receiver-origin commit, and validates the sending destination before transmission. Gate 7 retains a few fixture decisions. |
| 5. Expiry and rollback do not bound revocation | **Partial** | Failed refresh and lower epochs now have rules, but existing sessions survive expiry and a restored epoch can catch up without recovering removals: R3-2 and R3-3. |
| 6. Custody ignores retained copies | **Partial** | Acquisition-time custody and irrecoverable compromised copies are correctly conceded; the promised retirement bound has no target at its citation, and §0 accidentally widens its test to originals: R3-7. |
| 7. Removal silently revokes guest grants | **Closed** | Gate 5 now separates removal with no independent grants from a guest retaining its granted activity. Its failed-refresh case still needs R3-2/R3-9. |
| 8. S2 intersection falsely claimed to cost nothing | **Closed** | §4.3 explicitly describes Ana losing the ingested passage despite retaining her source grant. The transition should be an actual gate fixture, not only a parenthetical request. |
| 9. Browser policy and middleware prevent the hand-off | **Closed** | §7.1 and A.2 name the sender CSP allowance, dedicated receipt guard, pending sign-in flow and extra POST; gate 7 traverses the real stack. |
| 10. Call 8 lacks a paginated snapshot contract | **Partial** | Epoch-bound cursors and atomic publication answer mixed snapshots; the wire shape, completion marker, bounds and restart behavior remain unspecified: R3-8. |
| 11. S2 lacks the source-behind case | **Closed** | §4.3 specifies loud `UNKNOWN` for an unrecognized revision. That answers the original revision-7/source-5 case; adopting it against current memoria requires an explicit reconciliation with `AHEAD`: R3-12. |
| 12. Epoch claim does not pass home's claim test | **Partial** | A.1 now requests the right exception, but “can neither admit nor exclude” is inconsistent with a forced refresh that fails, and failure precedence remains unsettled: R3-9. |
| 13. Leak list omits roster and activity costs | **Partial** | Roles at rest and the full-roster distribution are disclosed; activity visit/traffic costs are added, but cached activity after revocation still conflicts with the universal next-request promise: R3-10. |
| 14. Amendments retain contradictions and restatements | **Partial** | Several named leftovers are covered, but Appendix A's general disclaimer conflicts with its literal replacement instructions, and new link/provenance and current-source conflicts are omitted: R3-6/R3-12. |
| 15. Docs and Sheets positions are misattributed | **Partial** | The Docs qualification is now accurate and A.3 preserves Sheets' local rule, but §§2 and 10 still repeat the rejected reading and replacement: R3-12. |
| 16. Citation currency misses normative changes | **Closed** | Gate 9 covers every normative change, verifies commit/revision agreement, and explains the one-revision grace; Appendix A requests both fields. |

**Seven closed, nine partial, none wholly unanswered.** Several partial findings now contain useful mechanisms; acknowledgment alone is not the reason they remain partial.

## 2. Findings against revision 3

### R3-1. P1 — The new compromise disclosure contradicts itself at the point of the guarantee

**Where:** doctrine §5.5, lines 486–512; §6.1, lines 573–575; §9 item 4, lines 815–825; ruling 13.

**What is wrong:** after conceding that the credential origin can sign in as anyone, §5.5 says a compromise of the home cannot reach an individually granted item. §9 goes further: none of the three compromises can read private/granted/link-only items, write as a person, or grant a per-item right. These statements directly contradict the new ruling.

**Why:** mint an assertion for Ana, redeem it for an ordinary instance session, then read Ana's private document or exercise her actual edit/share rights. The instance correctly evaluates its own grants and authorizes the impersonated Ana. Home §5.3–§5.5 and activity design §5.1 explicitly support this sequence. A local grants join is not an independent identity check. “No trust in the home's word” in §6.1 makes the same error.

The directory-only case also needs a narrower statement: adding an attacker-controlled account does not impersonate an existing person, but that account can exercise whatever ordinary write or share rights team membership/ownership actually confers. The membership record includes `owner`; compromising its writer is not inherently limited to inserting `member`.

**Confidence:** high; the credential-origin counterexample is explicit in both cited contracts.

**Smallest correction:** remove the universal residual bound, distinguish impersonation from rights acquired by an attacker-controlled member/owner, and make §§5.5, 6.1 and 9 cite ruling 13 consistently. A role-specific directory compromise bound must name the receiving app's role policy. No new security mechanism is required to disclose the existing exposure accurately.

### R3-2. P1 — Failed refresh restores a session-length revocation tail

**Where:** doctrine §5.3, lines 403–412 and 427–449; §5.4, lines 470–473; gate 5.

**What is wrong:** after roster expiry, the instance keeps serving already-admitted people for their session lifetime. It nevertheless promises removal everywhere within the roster TTL. Gate 5 checks new admission and S2, leaving the existing browser session out.

**Why:** admit Ana against epoch 10, remove her at epoch 11, then make call 8 unavailable through expiry. Her existing session keeps reaching team content under the explicit stale policy. Making sibling S2 return `UNKNOWN` does not stop an ordinary Docs read or memoria-owned material. Home §2.1 specifies sliding session renewal; the doctrine neither forbids renewal in this case nor defines an absolute session cutoff. “For the length of their session” is therefore not even necessarily a fixed additional bound.

This is an availability choice the document can make, but it has not priced or consistently stated that choice. “Within one epoch” is still not an elapsed-time condition. Call 7 and S6 also lack an explicit stale-membership treatment.

**Confidence:** high; an unexpired session alone exceeds the claimed bound, without relying on sliding renewal.

**Smallest correction:** either stop using stale team standing on every protected request at a hard maximum age, preserving independently evaluable grants, or specify an absolute, nonrenewable grace and change the revocation promise to include it. Define when age starts for a multipage fetch and whether request deadlines extend the bound. Exercise an already-live session, ordinary reads, memoria-owned reads, S2, S6 and call 7 through failed refresh. Choose the security bound explicitly; cold-wake measurement alone cannot choose it.

### R3-3. P1 — Rejecting a lower epoch does not make restore safe

**Where:** doctrine §5.3, lines 439–445; gate 5; A.1.

**What is wrong:** the receiver rejects lower numbers until the home passes a high-water mark, but no restore-safe record preserves either the mark or the membership changes it represents.

**Why:** a receiver applied epoch 11, which removed Ana. Restore the home to epoch 10, which includes her. One unrelated membership change produces 11 again; two produce 12. The receiver eventually accepts a number that passes the prescribed comparison while Ana's removal remains lost. Requiring strictly greater rather than greater-or-equal merely adds one mutation to the counterexample. Restoring both receiver and home makes refresh-before-admission insufficient too: both can agree on the same obsolete roster.

**Confidence:** high as a missing restore contract. An implementation with an independently durable membership journal could prevent it, but none is specified.

**Smallest correction:** make roster history/restore recovery authoritative independently of the restored database, or quarantine a restored authority until membership has been reconciled through a defined recovery procedure. Preserve epoch identity across history forks; a larger counter alone is not evidence of recovery. Add both numerical catch-up and joint-restore fixtures, not only `11 → 10` rejection. Memoria §7.4's independent tombstone journal is a relevant precedent, not an already inherited roster mechanism.

### R3-4. P1 — The provenance check requires an asker on paths that have none

**Where:** doctrine §7, lines 615–637; §6 S3; §§4.2 and 7.3; gate 6b.

**What is wrong:** every disclosure of a derived item, explicitly including an onward S3 fetch, must ask S2 whether its sources authorize the asker. S3 has no asker. An anonymous holder of a link to the derived item has none either, and §7.3 forbids using a link holder for sibling calls.

**Why:** save a Sheets-derived answer into Docs, then let memoria ingest the new Doc through S3. There is no subject with which Docs can perform its required source S2. Substituting the saver caches a person's authority; inventing a member authorizes the wrong reader; skipping the check permits a newly acquired copy after a source downgrade. Making the Doc `team` does not independently settle the source's current custody or revision.

Likewise, link-sharing the saved Doc does not grant the link holder access to its Sheets sources. The app cannot both promise that anyone with the URL can read this Doc and require a person-bound S2 result for every source. No safe refusal or restricted link-sharing case is stated. Team-sharing plus link-sharing still leaves this problem for the anonymous request, even if member requests work.

**Confidence:** high; the incompatible signatures and requirements are explicit. Memoria §6.1 already records why adding a person to S3 was the wrong earlier fix.

**Smallest correction:** define derived-item custody separately from person authorization, preserving source identities/revisions on onward acquisition and checking every source on person disclosures. Specify how a source's custody change invalidates a derived item's S1/S2/S3 eligibility. Until a no-person authorization mechanism exists, explicitly refuse unsupported derived-item S3/link disclosures or creation of such links. Do not invent an owner asker to make the call fit. Gate 6b needs a successful initial no-person acquisition as well as subsequent refusal.

### R3-5. P1 — A source list cannot justify removing only one passage from a synthesis

**Where:** doctrine §7, lines 615–629; gate 6b, lines 939–943; memoria §5.2 and gate 9.

**What is wrong:** the envelope records only app/id/revision per source, but the outcome says the saved item “loses that passage.” Gate 6b asks for the same result across reads, exports and S3. The cited memoria contract requires withholding the whole derived artefact if any source fails.

**Why:** an answer synthesized from sources A and C can express A's information in its conclusion, title or comparison with C, without quoting an identifiable A passage. A flat source list cannot locate every dependent span. Removing a quote while serving the synthesis leaves the revoked information in the output. Nor does the envelope specify how a newly edited or onward-copied Doc retains dependency coverage.

There is a second output conflict: gate 6b always demands naming the app after revocation, while §4.3 permits silent `NOT_VISIBLE` and S3's custody denial must remain indistinguishable from absence. A source-specific diagnostic in that S3 denial would expose the dependency of an otherwise hidden item.

**Confidence:** high for the insufficient mapping and cited whole-artefact rule; “lose that passage” is ambiguous enough that two implementers could choose opposite behavior.

**Smallest correction:** make whole-artefact withholding the default when any source fails, with unchanged non-disclosure behavior at S3. If independently removable passages are wanted, first define independently authorized units and complete dependencies for each; do not infer them from quotations. Bound and validate the envelope, including transitive expansion, unknown authorities, duplicates and cycles. Gate a synthesized conclusion, title/activity output, changed revision, and an actual second write hop. The present gate performs one write with two sources, not two-hop propagation.

### R3-6. P2 — Anonymous editing changes existing rulings, and actor identity is underspecified

**Where:** ruling 15; doctrine §§7.2–7.3; A.1–A.3. Docs §8.2; Sheets ruling 12 and §8.3; home §5.5.

**What is wrong:** §7.3 presents capability-attributed editing as preserving the existing attribution rule, but those sources explicitly require sign-in to write and mint a guest grant then. Sheets ruling 12 expressly rejects anonymous link editing. Appendix A never identifies these clauses for replacement.

**Why:** a receiver following the amended sibling spec still refuses the new edit link. A receiver following §7.3 writes without the guest grant the sibling's attribution rule requires. Paul's new product requirement can justify changing that decision; the change must be recorded as such, and ruling 15 remains explicitly a proposal.

The new actor also exposes an ambiguity in S8: eligibility is checked against “the item's actor,” while §7.3 attributes each revision to a link. After a link edits an S8-created Doc, does its actor become the link and permanently bar the creating sibling, or stay the sibling and misattribute the revision? The document needs distinct creation authorship and revision attribution. A link identifier in history must also be a non-secret identifier, not the bearer value; Sheets §8.3 already requires hashed token storage.

**Confidence:** high for the sibling contradiction; high for the missing distinction between item creator and revision actor.

**Smallest correction:** record the deliberate supersession of Docs §8.2, Sheets ruling 12/§8.3, and any affected home pending-grant text. Define immutable creator identity separately from each revision's actor and state the S8 policy after person/link edits. Add view-link write refusal, edit-link revision attribution, revocation, and mixed-actor S8 tests. Cite the existing token-storage boundary or replace it explicitly.

### R3-7. P2 — Ruling 14 promises a retirement bound at a section that contains none

**Where:** doctrine §0, lines 65–81; ruling 14; §4.2; §9 item 1.

**What is wrong:** §0 promises retirement within one feed pull plus “its stated retention (§4.2).” Section 4.2 states neither retention nor a restore obligation. Ruling 14's requirement that retirement be “stated and timed” is therefore still unfulfilled.

**Why:** memoria pulls on wake and questions, and §7.4 preserves snapshots while restorable backups reference them. A sleeping consumer or repeated failed enumeration can postpone a successful pull indefinitely. A feed-log TTL is not a cache/snapshot retirement deadline. The text must distinguish time to the next successful observation from time to retirement after that observation, including backups and the circuit breaker. The acquisition-time concession correctly limits malicious consumers, but does not specify honest retirement.

There is also a new scope error: revision 2 tested what an instance held **about the others**. Revision 3 deletes that qualification and tests everything it holds. A Docs instance legitimately holds an original private Doc under ruling 15. Publishing that instance reveals content the team could never read; changing the acquisition timestamp does not cure this counterexample.

**Confidence:** high; the retirement citation has no target, and the private-original counterexample follows from the new ladder.

**Smallest correction:** restore the test's scope to sibling-acquired copies; distinguish originals from those copies. Cite a concrete consumer retirement/snapshot/restore policy, require its stated bounds, and explicitly disclose any unbounded delay before successful synchronization. Ruling 14 may reject push and source-held keys as complete recall mechanisms; it should not imply those alternatives have no possible effect on an honest consumer's retirement window.

### R3-8. P2 — Call 8's snapshot rule is useful, but no interoperable page can yet be encoded

**Where:** doctrine §5.3, lines 379–382 and 414–425; gate 5; A.1.

**What is wrong:** the only wire example still contains just `epoch` and `members`. It has no continuation/completion field or cursor request parameter. No page cap, total staging bound, invalid-cursor response shape or restart action is given. “An empty response is never read as nobody is a member” also fails to distinguish a malformed/absent response from a valid completed empty snapshot.

**Why:** atomic replacement solves mixed epochs only if a client can recognize completion and restart after invalidation. Two implementations can both claim to stage all pages while disagreeing about whether the first response is complete. Repeated epoch changes or a failed middle page must not extend the previous snapshot's usable age or leave unlimited staged data.

The new claim that call 8 is the first response whose size the caller does not control is also inaccurate: S1 enumerates server-owned changes and call 7 has server-selected activity. That does not undermine the need to page the roster.

**Confidence:** high.

**Smallest correction:** provide one bounded request/response schema, explicit terminal marker, invalidation response and discard-and-restart rule. Define valid empty completion separately from fetch failure, and do not reset freshness on incomplete work. Add concurrent mutation, failed-middle-page, empty-completion and repeated-restart fixtures to gate 5. Choose the first client's constants with reasons, as the repository requires.

### R3-9. P2 — Stale authority needs result precedence, and an epoch hint can cost admission

**Where:** doctrine §4.3, lines 292–294; §5.3, lines 389–401 and 427–434; gates 3 and 5; A.1.

**What is wrong:** stale-roster S2 is unconditionally `UNKNOWN`, whereas §4.3 and gate 3 unconditionally demand `NOT_VISIBLE` for non-custodial/deleted items. The document also says a differing epoch hint can neither admit nor exclude anybody, while requiring admission against a fresh roster after that hint.

**Why:** ask about a deleted item while the roster is stale. Its nonexistence is locally determinate; an unreachable membership authority has not made it uncertain. A client needs one specified answer when both clauses apply. Returning `UNKNOWN` for the whole call can be a conservative availability choice, but it must be scoped as an exception; selectively returning it only for existing private items would violate indistinguishability.

For the hint, start with a still-usable cached roster and an assertion carrying a different parseable epoch. Let the triggered call-8 fetch fail. Requiring freshness now refuses admission that the old cache would otherwise allow; accepting the old cache contradicts the fresh-roster sentence. The hint does not directly assert a role, but it can affect availability. “Exactly one request” also needs qualification once call 8 takes several pages.

**Confidence:** high for the incompatible unconditional rules; the hint's availability effect depends on the failure policy that remains to be specified.

**Smallest correction:** define validation and result precedence for unsupported subjects, local non-custody/nonexistence, stale membership, independent grants and revision mismatch. Retain indistinguishability in each case. Specify whether a hint invalidates an otherwise-usable copy and price that availability effect accurately. Test the combined states, including hint-triggered partial/failing refresh before the TTL. `UNKNOWN` remains a useful failure class; the defect is when it overrides a determinate denial and what the consumer is told failed.

### R3-10. P2 — Activity still serves cached authorization despite the strengthened universal rule

**Where:** ruling 3; doctrine §4.3, lines 278–284; §7's activity disclosure check; §9 items 5, 7 and 10; adopted activity design §7.

**What is wrong:** revision 3 says authorization is never cached at any scope and that live authorization bounds the next request on every surface, explicitly including home activity. The adopted activity design permits a last-good response to render on later requests, through failed pulls until a hard maximum age.

**Why:** cache a title, revoke the source or its grant, then render the home again before that maximum expires while the pull fails. The title is newly disclosed from the cache without a current check. This is not merely a browser retaining its previous page. For derived items, checking provenance when the instance first answers call 7 does not recheck the home's later render.

**Confidence:** high; activity §7 expressly describes the removed-person failure case and its cache-age bound.

**Smallest correction:** explicitly resolve the scope conflict: either record activity's bounded cached-disclosure exception by citation and disclose the revocation tail, or change the adopted behavior to require a current check before redisclosure. Do not claim both. Reuse activity gate 20's failed-pull/hard-maximum test, and include a derived item's source revocation. The new cost disclosure should also follow activity §2.2's per-refresh-window emission rather than imply every browser load necessarily produces an instance request.

### R3-11. P2 — Ruling 12's rejected alternative mixes verified facts with an unsupported impossibility claim

**Where:** status lines 21–25; ruling 12's rejected column; doctrine §5.1, lines 341–359.

**What is wrong:** both requested home facts are true, but the conclusion drawn from the second is too strong. Home §6 has `kind = member | guest`, with no owner role, and includes `app` in each directory entry. Home §7 explicitly keeps owner decisions instance-side. Those facts do not prove that projecting a team-wide roster from app-scoped rows is impossible or necessarily produces app-specific standing.

**Why:** projecting distinct `(team, person)` memberships can erase the app dimension and give one answer to every app. It would still suffer the owner-information and untrusted-writer defects, so it is not a defense of revision 1. It is a counterexample to one claimed reason for rejecting it. Ruling 1 alone also does not define every membership consequence; the common roster is established by rulings 4/12, and §3 expressly permits differing lone-instance rosters.

The sentence “Ruling 9 made a directory row a hint” is an unqualified wrong reference: suite ruling 9 concerns writes; **home** ruling 9 concerns directory hints.

**Confidence:** high for the source verification and projection counterexample.

**Smallest correction:** retain the separate owner-controlled table and its two decisive reasons. Describe app scope as an aggregation/lifecycle design problem, not proof that aggregation cannot work; qualify the roster claim by shape. Name home ruling 9. Ruling 13's rejected alternative is substantively honest, although R3-1 shows its correction is not carried through. Ruling 14's alternatives are not complete recall mechanisms, as R3-7 distinguishes. Ruling 15 correctly rejects treating possession of a URL as team-wide discoverability.

### R3-12. P2 — The new ladder and consuming amendments still leave incompatible contracts

**Where:** doctrine §§2, 4.2, 10 and 13; Appendix A; current sibling specs.

**What is wrong and why:** the following are concrete remaining adoption defects, including drift since the previous review.

- **Link lifecycle:** §4.2 correctly permits indexing `team` plus a link, but §13 says a link share that a sibling can index is never built. If Ana adds a link after team ingest, following §13 would retire a still-team item; following §4.2 would retain it. Revoking just the link must not revoke team custody. Downgrading the rung while retaining the link must produce `gone`; deleting/revoking a link alone must not expose link-only item ids or capability values through S1. Gate 3 covers only static states. Also, “a link holder is never on a roster” confuses a request's authority with a person's other rights: Ana can be both a member and a link holder.
- **Sheets' local consistency rule:** §2, lines 138–141, still attributes the cross-repository problem to its local same-commit rule. §10, lines 871–874, still says to replace that rule. A.3 now correctly says to keep it. The original `AGENTS.md`, lines 5–7, concerns that file and the Sheets design spec in the same repository.
- **Appendix A remains operationally contradictory:** its introduction says replacements are not pasteable restatements, then A.1–A.3 say to add or replace text with quoted paraphrases. A builder cannot execute both instructions. A.4 leaves memoria §2's and §8.5's unqualified no-sibling-write clauses outside the amendment list. The new provenance requirement also needs receiving-app read/export/activity/S3 adoption, not just A.2's create route.
- **Home ruling number collision:** A.1 says “Add ruling 22.” Home trunk at `2b68301` already has ruling 22 for URL-based team selection. Its §2.2 activity amendment has landed too; it is no longer a pending change to complete. Use a newly allocated ruling and the actual source baseline.
- **Memoria citation branches disagree:** decisions 13/14 and the cited gate 26 exist in `tensorx-provider` at `8dfc3c9`; they are not in the supplied primary checkout. Current main at `9464a8b` instead has a five-valued S2 with `AHEAD`, explicit reconciliation, and a different gate 26. §6 cannot say the cited calls move unchanged in substance while A.4 adopts four values without addressing that current contract. This is not a recommendation to adopt `AHEAD`: main itself records unresolved problems with it. It is a requirement to pin and reconcile the actual baseline.
- **Calendar needs an adoption change, not only a citation:** its substantive model is in `calendar-first-screens`, not the primary checkout's example `Note`. That model confirms there is no commenter role, but team access is represented by explicit per-person grants. A.5's instruction to add consumed rulings alone does not distinguish roster-derived team access from independent grants that survive removal, nor identify how the new sharing ladder applies to calendars/events. Otherwise gate 5 cannot test the intended removal semantics against this model.

**Confidence:** high for the literal contradictions and checked source revisions. The required calendar implementation can take several forms; the missing adoption boundary is the finding.

**Smallest correction:** turn Appendix A into a precise list of owning sections/gates to replace with ruling-and-commit citations, with locally owned integration changes identified separately. Resolve the link lifecycle using the rung predicate, explicitly distinguish anonymous capability requests from signed-in member requests, and add creation/revocation/downgrade/edit-after-ingest fixtures. Pin the sibling baselines, allocate the home ruling without collision, and reconcile memoria's result vocabulary. Preserve Sheets' local rule everywhere the doctrine discusses it.

## 3. Verdict

**Request changes.** The protected membership record, receipt/commit split, explicit acquisition-time custody, and disclosure of S2's product cost are substantive improvements. They do not yet yield a consistent implementable contract. The main blockers are the false compromise bound, session and restore revocation failures, and the provenance rules' missing no-person and whole-artefact behavior.

Ruling 15's distinction between the sharing rung and a link capability is sound for custody of original items. Anonymous editing and link access to derived items require further decisions and consuming amendments. Its proposal status is correctly recorded; this review does not approve it on Paul's behalf.

### Sources and verification limits

All doctrine line references are to [revision 3](docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md) in this worktree. Original finding numbers refer to [CODEX-FINDINGS.md](CODEX-FINDINGS.md), which remains unchanged.

| Source | Checked location and commit |
|---|---|
| Home design | [Home trunk design](/home/paulca/amadan.net/oficina/home/.claude/worktrees/trunk/docs/superpowers/specs/2026-08-30-home-design.md), `2b68301`. The primary checkout remains at stale `462df84`. Verified §§0, 2, 5–7 and 9, owner-role absence, app scope, sealed queue bootstrap, call-2 authority, and existing ruling 22. |
| Activity | [Activity design on home trunk](/home/paulca/amadan.net/oficina/home/.claude/worktrees/trunk/docs/superpowers/specs/2026-09-05-activity-pull-design.md), `2b68301`; also located the originating worktree at `6f7e6a9`. Unlike the previous review's baseline, the design and home amendment have landed on trunk. Checked credentials, guests, response shape, cache failures and gates. |
| Docs | [Docs design](/home/paulca/amadan.net/oficina/docs/docs/superpowers/specs/2026-08-30-docs-design.md), `f6cf5c2`; sharing, pending sign-in, conversion rejection, module path, router/session middleware and rastrillo v0.22.0. |
| Sheets | [Sheets design](/home/paulca/amadan.net/oficina/sheets-core/docs/superpowers/specs/2026-08-30-sheets-design.md), `8ed3926`; ruling 12, §§8.2–8.3, `AGENTS.md`, `PRODUCT.md`, module path. |
| Memoria original baseline | [Primary-checkout design](/home/paulca/amadan.net/oficina/memoria/docs/superpowers/specs/2026-09-03-memoria-design.md), `617eb2a`; authorization, provenance, S1–S7, retirement/restore, gates, sequencing and open defects. |
| Memoria provider citations | [Provider worktree design](/home/paulca/amadan.net/oficina/memoria/.claude/worktrees/tensorx-provider/docs/superpowers/specs/2026-09-03-memoria-design.md), `8dfc3c9`; located and verified decisions 13/14, §8.4 and passage-authorization gate 26. These citations are real, but branch-specific. |
| Memoria current main | [Main worktree design](/home/paulca/amadan.net/oficina/memoria/.claude/worktrees/notion-ingest/docs/superpowers/specs/2026-09-03-memoria-design.md), `9464a8b`; compared the changed S2 vocabulary, provenance, admission, reconciliation and acknowledged open defects. |
| Calendar | [Calendar model](/home/paulca/amadan.net/oficina/calendar/.claude/worktrees/calendar-first-screens/internal/calendar/models.go), `f18898b`; team/personal kinds, explicit grants, owner/editor/viewer roles. Primary `ecb0df9` still has an example `Note` model. |

The Docs middleware and memoria CSP claims were rechecked in local code and the installed dependencies. The previous review's numeric middleware probe was not rerun and is not presented as new test evidence. No browser flow, deployed service, contract conformance suite or persisted home membership schema was executed: the requested review is of a design and this repository has no contract module yet. No sibling files were edited and no cross-repository messages were sent. Private brainstorm attribution and discussion 33's full contents were not independently verified.

## 4. Gate-by-gate assessment

“Writable” below concerns whether the stated test has a definite expected result. It does not report a passing implementation. Gate 6b makes ten entries under the nine numbered gates.

| Gate | Can it be written and run as stated? | Required correction or coverage |
|---|---|---|
| 1. Fixture conformance | **Harness yes; complete conformance not yet.** | Declare which calls each app serves; S6 belongs to Sheets and call 8 to home. Call-8 pages and provenance/S3 outcomes still need R3-4/R3-8/R3-9. Add fixtures with their first client as instructed; do not claim every app serves every call. |
| 2. S2 total decoder | **Yes, as a decoder property.** | Short, duplicate, malformed, non-2xx and unsupported-subject responses have definite outcomes. Add source-forward/source-behind semantic fixtures and mixed stale-roster/non-custodial cases; total decoding does not establish correct authorization. |
| 3. Custody | **Static checks mostly yes; literal fixture wording still needs correction.** | “All five” includes deleted, so “does hold a grant on them” still demands a live grant to a deleted item; its clarification only repairs the `granted` fixture. Use the same id/asker in private and deleted alternative states, with a former grant where deletion removes it. Add team-plus-link and after-ingest link/rung transitions, including Ana's retained grant. Define stale-roster precedence and derived-item custody. |
| 4. No cross-team dial | **Yes.** | Correctly distinguishes an initially forbidden destination from a forbidden redirect follow-up; instrument connections per host. Check the browser form destination before rendering, with canonical host parsing and an allowed-host control. |
| 5. Roster | **Not as a complete revocation gate.** | Successful refresh, retained independent grants, lower-number rejection and lone isolation can be tested. R3-2/R3-3/R3-8/R3-9 block the claimed time/failure guarantee. Add existing-session, S6/call-7 failure, failed middle page, concurrent epoch change, numerical catch-up and joint-restore cases. |
| 6. Write-as-self | **Yes for the original access checks.** | Authenticated-consumer actor derivation and spoof refusal are now explicit. Add immutable creator versus revision actor behavior after person/link edits under R3-6; the current three denials do not settle it. |
| 6b. Provenance survives the hop | **No, as stated.** | S3 has no asker; the envelope cannot identify safe partial redaction; universal named denial conflicts with S3 absence-hiding. Resolve R3-4/R3-5. Test successful initial access, whole-artefact dependency failure, activity/title output, changed revisions, anonymous link access, and two sequential writes. Refusal when no source authorization surface exists is independently testable. |
| 7. Hand-off through middleware | **Yes for the specified receipt/commit security flow; finish the fixture parameters.** | Use the real browser CSP and receiver middleware. Explicitly choose absent/null-origin outcomes and expiry/body limits. §7.1 fixes the server-side body; ignoring an extra changed client body is safe, while the gate demands refusal—choose one wire behavior. Include expired state, concurrent replay, sign-in/session change and a successful scriptless flow. This is substantially repaired from revision 2. |
| 8. Publish home database | **Yes as a seeded disclosure test against the eventual implementation.** | Owner roles are now correctly part of the expected disclosure. Exercise actual persisted data and failure paths, including bootstrap/roster writes. Preserve home's existing no-content/no-readable-address checks; a schema-column inspection or roster fixture alone does not establish them. |
| 9. Citation currency | **Yes.** | Commit/revision agreement and normative-change scope are repaired. Keep the deliberate one-revision grace distinct from current conformance. Pin the consuming source baselines too, so the A.1 ruling collision and memoria branch differences are resolved before adoption. |