# Independent plan review — Remozio revision 21

## Scope assessed

I reviewed the complete plan with emphasis on the post-revision-5 additions and their interaction with earlier invariants:

- **Rev 21 change (trust-generation witness, §16)** against the round-14 disposition. The combined generation covers enrollment keys/tombstones, security floors, authenticated policy revisions, installed generations, lifecycle epochs, and control replay state; continuity is validated at the installation boundary before loading code and at the root before accepting phone operations. I checked the consumption-ledger rollback scenario specifically: pending sensitive payloads are memory-only and a restore implies a root restart that cancels unconsumed requests (§6, §17 restart matrix); consumed requests are expired and decisions are single-use challenge-bound, so a pre-consumption restore cannot re-enable re-execution; journal rollback surfaces as detectable sequence gaps in §12 sync. The disposition's reasoning holds; I found no concrete unresolved scenario.
- **Consumption/race safety** (§6): first-valid-decision ledger, permit-before-mutation for scope changes (§9), crash-after-dispatch → unknown with no retry, permit acknowledgment watchdog, and revocation/consumption serialization. Consistent with the multi-phone race table and the §12 atomic journal transaction.
- **Scope classification and key separation** (§1, §6, §7, §9): the narrow decision key's purposes (one-time UI decisions, cancellation, routing control §14, update scheduling §17) grant no target-action, enrollment, or release authority; both verifiers derive biometric requirement from retained semantics; the Little Snitch allow-once exception is not widened to commands/1Password; unknown compatibility contracts cannot inherit one-time classification (§9). Routing and scheduling controls were checked for authority escalation: worst case is availability impact, cancelable, and consistent with the confirmed unlocked-phone-operator tradeoff.
- **Update/anti-rollback paths** (§3, §16, §17, §18): per-request generation floors on privileged XPC, floor commit only at quiescence, transparent resubmission restricted to the authenticated no-admission race response (unknown admission → reconcile, never auto-resubmit), deferred bundle replacement for live roles, downgrade rejection independent of candidate binaries, gateway epoch/revision/tombstone reconciliation requiring Mac-signed receipts before counter repair.
- **UX invariants**: full command rendering, no truncation (oversized → distinct result), streaming stdin preserved, no added confirmations/biometrics/manual steps anywhere in the new sections; the "Update waiting" drain is user-initiated, visible, and cancelable; native dialogs and manual sudo remain as fallback surfaces.

## Tentative UX choices (explicitly deferred, not defects)

The 30-second draft idle interval, audit retention duration, FCM provider selection, biometric-invalidation policy, and the ~60s 1Password lifetime estimate remain pending product preferences or gated evidence items. They are framed with consultation paths and do not block convergence.

## Items verified as feasibility gates rather than defects

Single-biometric credential release (§7), descriptor-based/atomic execution (§8), sudoers compatibility (§8), secure-field targeting (§9), 1Password/Little Snitch fixtures (§9), Access background auth (§16), the trust-generation witness mechanism with explicit failure/consultation path (§16), and protected-placement/anti-rollback enforcement (§3, §17) each have required evidence and a defined consult-the-user failure path. Per the review protocol, these are planned work, not findings.

## Remaining implementation verification limits

This review establishes plan-internal consistency only. It does not establish: that macOS 14+ exposes the required connection-bound code-requirement and service-management APIs; that a non-migrating installation key plus witness can actually distinguish same-Mac rollback while preserving offline operation; that one CryptoObject operation can cover credential release; that 1Password/Little Snitch AX structures match the compatibility contracts; or that push/background delivery meets practical latency. All of these remain contingent on the scheduled feasibility evidence, and several may trigger mandatory user consultation if they fail.

## Conclusion

NO SUBSTANTIVE FINDINGS. The revision-21 extension of the restoration gate to floors, policy, generations, epochs, and replay state is internally consistent with the consumption ledger, activation boundary, and offline-operation requirements, and the post-revision-5 subsystems (audit, expiry, routing, push, relay/gateway, identity, updates, protocol evolution) introduce no contradictions, downgrade/replay gaps, or silent UX regressions against the earlier invariants. Convergence here means no unresolved *planning* findings on this revision; it does not assert platform feasibility, which remains gated as designed.