Review brief — the Oficina suite sharing doctrine, revision 3

You are reviewing this document for the second time. Be adversarial. Your job is to find what is wrong, not to confirm that your last review was acted on.

What to review

docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md in this worktree, at revision 3. Read all of it.

History

• Revision 1, drafted by Fable 5.1 from a brainstorm with Paul, the repository owner.
• Revision 2, revision 1 plus a review pass by Claude Opus 5: six defects, corrected in the text.
• Your own review of revision 2 returned request changes with sixteen findings. It is CODEX-FINDINGS.md in this directory, unchanged.
• Revision 3 claims to answer all sixteen, and adds a product requirement Paul gave afterwards. git diff 0c4f098..HEAD is the whole change; git log has the reasoning per commit.

What matters most

1. Are your sixteen findings actually answered, or only acknowledged? Go through them one at a time. A finding is answered when the document would now survive the failure sequence you described, not when it cites your finding number beside a paragraph. Say plainly which are closed, which are half-closed, and which are worse than before. Four became rulings (12, 13, 14 from findings 1, 2 and 6; 15 is new) — check the ruling text does the work its finding asked for, and that its rejected alternative column is honest.

2. The new material has had no review at all. Look hardest at:

• Ruling 12 and §5.1, the membership record. It asserts three defects in the old derivation, two of them factual claims about the home spec (the directory row has no owner role; it is scoped per app, not per team). Verify both against the home spec. Then ask what the new table breaks: A.1 amends home §7, home §6 and home §0, and the roster is now a thing the home holds that it did not before.
• Ruling 15 and §4.2, the sharing ladder. This is the one row of §1 that is a proposal, not Paul's ruling. Four product states: private, granted, team, and "anyone with the link can view or edit". The claim is that a link is a capability beside the ladder, never a rung on it, so custody keys on the rung. Test that against §0, against the change feed, against S2 and S3, and against §7's write paths. Does a link-shared item behave coherently everywhere? Is "link-shared and team-shared" handled? What about a link created after ingest, or revoked after ingest?
• §7's provenance envelope and §7.3's link-holder writes, both new.
• §7.1's receipt/commit split, which answers your finding 4.
• §5.3's failed-refetch, rewind and paging rules, which answer your findings 5, 10 and 12. Check the availability trade in the stale case is actually stated coherently and that UNKNOWN there does not collide with another meaning of UNKNOWN.

3. The gates, §11, all nine rewritten. §11's own first line says a gate that cannot be written as stated is a spec bug. Can each now be written and run? Gate 6b is new.

4. Verify citations rather than trusting them. The sibling repos are on disk read-only at /home/paulca/amadan.net/oficina/{home,docs,memoria, sheets-core,calendar}. Your last review found the home checkout on a stale branch and used home/.claude/worktrees/trunk instead; do that again. Revision 3 added many new claims about sibling specs — every one is a place a mistake could hide.

What to produce

Write CODEX-FINDINGS-R3.md in this worktree. Structure it as:

1. A table of your sixteen original findings, each marked closed, partial or open, with one line saying why.
2. New findings against revision 3's new material, ordered by severity, each with: what is wrong, why, your confidence, and the smallest correction.
3. A verdict: approve, or request changes.
4. The gate-by-gate table, refreshed.

Do not edit the doctrine. Findings only.