# Independent review — Remozio plan, revision 29

## Assessment of the revision 29 changes (busy-state admission contract)

The round-22 K3 finding appears resolved without introducing new defects:

- The four busy reasons (Update installing, Mac authority starting, Update waiting, Storage unavailable) are defined once in §8 and referenced consistently from §12 (witness/journal startup failure → "Mac authority starting / storage unavailable"), §16 (live witness faults follow the same policy), and §17 (Update installing at the replacement boundary, Update waiting during explicit drain). I found no fifth unclassified busy state: recovery-required is correctly excluded from automatic retry classes and routed to the administrator repair path.
- The submission-bound, authenticated no-admission proof closes the ambiguity hole: lost acknowledgments, timeouts, unknown reason codes, and generic health hints never trigger resubmission (§8, §17, §18 acceptance cases). Replay of a prior no-admission result fails because it is nonce- and submission-identity-bound.
- The single non-resetting caller deadline across retries and reason changes, with indefinite drain never producing indefinite caller wait, is internally consistent and preserves cancellation, caller liveness, and unconsumed stdin/PTY input. It does not shorten an admitted request's approval lifetime.
- GUI capture parity is preserved: automatic recapture only after authority recovery, only while the same dialog remains, preserving first-seen age and target deadline per §13, with observed expiry/unknown disappearance reported honestly. Short-lived 1Password prompts during a long drain degrade to the already-defined expiry/disappearance paths, not to silent loss.
- The disposition's rejection of K3's "immediate manual-only retry" alternative is sound; the adopted bounded automatic resubmission adds no manual step, so no UX-consultation tripwire is crossed.

## Cross-section consistency checks performed

- §6 consumption-before-side-effect, §12 journal transaction + checkpoint, and §16 witness anchoring compose coherently: per-action commits use the crash protocol; epoch creation and trust/floor/replay-control changes anchor the witness; restrictive-ahead intents roll forward automatically. Whole-backup rollback cannot un-consume a request because pending payloads are memory-only and restarts cancel unconsumed requests.
- §17 floor commit, adapter-key certification invalidation, and §16's inclusion of floors in the combined trust generation agree; the activation transaction and witness intent protocol both cover floor activation, with matching acceptance tests.
- Key-purpose separation (decision key: one-time UI decisions, cancellation, routing control, update scheduling; authority key: gateway control; biometric key: protected actions) holds across §6, §14, §16, §17; the allow-once exception remains scoped to the captured Little Snitch request, with §9's reusable-effect validation including timed/session rules.
- Multi-phone first-valid-decision consumption, revocation serialization, and push reconciliation (§5, §6, §15) show no downgrade or replay gap I could construct at plan level.

## Tentative UX choices and documented observations (not defects)

- Migration ceremony cost, idle interval (30s draft), retention duration/budget: explicitly deferred product preferences.
- After an unexpected root-authority restart, admitted command requests are cancelled and require manual fresh submission (§17 matrix); the disposition records the automatic-retry suggestion as a non-adopted observation. This is a disclosed limitation, not a silent UX regression.
- Busy-state deadline exhaustion for commands ends in a distinct nonzero status requiring a manual rerun — error reporting, not an added confirmation step.

## Remaining implementation verification limits

This is a plan-only review. The key-custody/witness availability, single-biometric credential release, descriptor-based execution, local command approval surface, 1Password/Little Snitch AX contracts, background Access authentication, and service-management placement protections remain feasibility gates with defined evidence and consultation paths; none has been validated against a real platform. Wire vectors, race tests, and acceptance cases are specified but unexecuted.

## Conclusion

**NO SUBSTANTIVE FINDINGS**

I assessed internal consistency of the revision 29 busy-state/retry contract against §§5–9, 12–18; downgrade/replay resistance of the witness, epoch, gateway-control, and floor mechanisms; privileged update paths including same-user replacement and staging races; key separation and the Little Snitch once-exception scope; and preservation of the confirmed remote UX (no added biometrics, confirmations, lock-screen surfaces, or shortened windows). The prior disposition's reasoning withstands challenge; I found no concrete unresolved scenario. All findings above are either explicitly scheduled feasibility work or flagged tentative choices, and all three adapters remain in scope.