# 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.