# Independent plan review — revision 28

Scope reviewed: full plan, with attention to the revision 27→28 additions (live witness-fault ordering, retryable no-admission responses) and their interactions with sections 8, 12, 16, and 17. Prior disposition reasoning was checked against the revised text; F1 and F2 appear correctly and minimally resolved (typed intent with prepared/anchored/finalized phases, restrictive-live/permissive-held split, submission-bound no-admission proof with no replay on ambiguity). No tools were used; this is a consistency review of the plan text only.

## Finding

### L1 — The authenticated no-admission contract covers only two of the four pre-admission rejection states

**Sections:** 17 "Automatic activation and optional drain"; 12 "Atomic journal writes" (storage-condition rejection); 8 "Process I/O and terminal outcomes".

**Scenario:** Revision 28 correctly establishes that an ambiguous admission result is dangerous (a caller cannot distinguish "never admitted" from "maybe admitted", so only an authenticated, submission-bound no-admission proof may trigger transparent wait and resubmission). But that contract is specified only for `Update installing` and `Mac authority starting`. Two other states reject admission pre-dispatch without the same treatment:

1. **Update waiting** (§17 drain): "return Update waiting with a retryable status". The text does not state that this response is authenticated and submission-bound, and does not define caller behavior. A drain may be indefinite (a long-lived command defers activation indefinitely), so the bounded transparent wait rightly cannot apply — but the plan never says what the frontend does instead. An implementer could reasonably either transparently wait (stalling a coding tool for hours behind an explicit drain, contradicting "show the caller that approval is waiting"/"useful errors") or treat it as terminal (losing the retryability the plan promises). A forged unauthenticated `Update waiting` from the relay is availability-only, but the ambiguity itself is the defect class F2 just fixed.
2. **Storage-condition rejection** (§12): "If essential recording cannot be guaranteed, reject new admission before dispatch and expose the storage condition." No statement that this is a submission-bound no-admission result, no distinct status in §8's list, and no defined caller/frontend behavior (retryable like the witness-starting state, or terminal?). §12's own witness-starting state gets the full retry contract; the journal-capacity rejection right next to it does not.

**Minimal correction (no UX change):** In §17 and §12, state that all pre-dispatch admission rejections — `Update installing`, `Mac authority starting`, `Update waiting`, and storage-condition — use the same authenticated, submission-bound no-admission proof, and classify each in §8's distinct-status list. Define caller behavior per state: bounded transparent wait only for states that are inherently bounded (`Update installing`, `Mac authority starting`); an immediate distinct terminal status with visible drain/storage state and manual retry for `Update waiting` and storage-condition. This adds no confirmations, biometrics, or manual steps beyond what the plan already shows in the menu/phone status surfaces.

## Tentative UX choices remaining (not defects)

- The authority-key **migration ceremony** (§3) remains an explicitly unresolved user-choice gate — correctly carried as pending, per the disposition.
- **Indefinite drain semantics**: an explicit "Install when current work finishes" plus a long-lived command suspends *all* new admissions (including 1Password/Little Snitch) until the drain completes or is cancelled. The plan discloses this and provides defer/cancel on both surfaces, so it is a designed tradeoff — but it is worth explicit user confirmation at implementation time, since it is the one path where a user-initiated action can silently-feeling block unrelated approvals for an unbounded period.
- Deferred preferences (idle interval, retention budget, macOS 14 floor, FCM choice) are explicitly gated and not findings.

## What was assessed and found sound

- **Witness-fault ordering (§16/§12):** restrictive-live/permissive-held split, operation-ID reconciliation, no claim that unanchored operations survive whole-backup restore, and fail-closed-on-persistent-fault are internally consistent with §5 revocation, §17 floor commit, and §12 epoch anchoring. Per-request consumption correctly retains the separate §12 crash protocol.
- **No-admission retry (§17/§8):** fresh capture + fresh decision on resubmission, stdin/PTY non-consumption, caller-lifetime retention, and the explicit "timeout/lost ack is not proof of rejection" rule close the original F2 hole for the two covered states.
- **Command binding (§8):** capture-before-approval, verified-requester vs. caller-label separation, stdin-source disclosure, no atomicity claim without descriptor-based execution (gated), sudoers compatibility gated.
- **Biometric/credential (§7):** one-CryptoObject operation remains a properly bounded feasibility gate; key separation (biometric vs. narrow decision key vs. routing/scheduling purposes) is consistently enforced at both verifiers (§6, §9).
- **UI races (§9, §6):** permit-before-mutation, one bounded attempt, unknown-on-failure, no retry, one-time scope validation for Little Snitch; the confirmed allow-once tradeoff is not widened to commands or 1Password.
- **Recovery/routing/push/relay/update/evolution (§12–§18):** epoch model, first-valid-decision consumption, gateway control plane with possession proofs, activation/floor transaction, and mixed-version rules show no contradictions with the §3/§5/§6 invariants. Relay cannot mint decisions; downgrade floors are anchored in the trust witness.
- **Remote UX preserved:** no new mandatory confirmations, lock-screen surfaces, or delivery guarantees were introduced by the revision 28 changes.

Remaining verification limits: this review cannot validate the feasibility gates themselves (witness availability pre-login, one-biometric credential release, descriptor-based execution, 1Password/Little Snitch AX contracts, local command-approval path); those are scheduled work with defined failure/consultation paths, not plan defects.

## Conclusion

SUBSTANTIVE FINDINGS REMAIN — one low-severity finding (L1): extend the authenticated, submission-bound no-admission contract and defined caller behavior to the `Update waiting` and storage-condition admission rejections (§17, §12, §8). The correction is spec-completing only and introduces no UX regression.