# Independent plan review — Remozio revision 25

Scope: complete plan, with attention to post-revision-5 additions (audit journal, expiry/age, presence routing, push, LAN/relay, code identity, Sparkle updates, protocol evolution, mixed versions) and their interaction with earlier invariants. Plan-only review: no testing, browsing, or source inspection performed or claimed.

## What was assessed

**Command binding (sections 6, 8).** Canonical immutable capture of argv/cwd/UID/env/stdin-classification before approval; digest recomputed by both phone and acting authority; direct exec without a shell; stdin/PTY disclosure rules; caller-liveness recheck at the execution boundary with distinct requester-exited outcome; executable-recheck race and sudoers compatibility are explicit feasibility gates with disclosure/consultation paths rather than assumed guarantees. No contradiction found with the no-truncation rule (oversize → distinct "Request too large" result).

**Biometric and decision-key separation (sections 1, 6, 7, 14, 17).** Purpose-separated keys with verifier-side derivation of required key class from retained semantics; the narrow decision key cannot reach commands, 1Password, credentials, enrollment, or reusable rules; both verifiers independently reject scope escalation. Routing and update-scheduling controls under the decision key are bounded (revision/operation-ID idempotency, no artifact supply, no floor alteration) and grant no action authority — deferring a security update does not weaken the already-committed floor. The confirmed Little Snitch allow-once exception is not widened.

**Android biometric/credential handling (section 7).** Immutable request binding across switching/rotation/backgrounding; lock-screen behavior matches the clarified UX (no over-keyguard surface); single-biometric credential release is a properly-scoped gate with an explicit two-biometric consultation path. Deferred biometric-invalidation policy is documented as a gate, not an assumption.

**UI race handling (sections 6, 9, 13).** One-time ledger permit covering scope mutation + final click as one attempt; mutation failure → Unknown, no retry; refresh-with-fresh-challenge model; observed-timeout vs. disappearance distinction; revalidation immediately before action including during an open biometric prompt; Once-vs-reusable classification based on validated effect, not button labels. Internally consistent.

**Replay/downgrade resistance (sections 5, 12, 16, 17, 18).** Serialized revocation vs. consumption; per-start random journal epochs with checkpoint/recovery marker outside the replaceable journal (round-18 Opus-1 fix is correctly integrated, including "restart cannot clear" and crash-consistent commit as a gate); bounded rejection telemetry with reserved lifecycle capacity (Opus-2 fix integrated without per-packet attacker-controlled writes); authenticated negotiation transcript binding; gateway control epochs/revisions/tombstones with signed-receipt reconciliation that cannot resurrect revoked authority; floor-commit transaction independent of the candidate binary.

**Update path (section 17).** Quiescence-gated activation; no killing of active commands or replaying approvals; frontend resubmission only on authenticated no-admission results with fresh capture/decision; restart matrix consistent with section 6 invariants; floor enforcement per-XPC-request against OS-validated build identity.

**Recovery and remote UX.** Remote-administrator recovery path preserved throughout (pairing, trust continuity, gateway registration); no added confirmations, biometrics, shortened windows, or removed remote functionality introduced by the reviewed revisions. Offline/LAN operation is preserved when the gateway is unreachable, and routing controls carry no hidden authority.

**Flux reuse (section 4).** Architecture-only reference pending license resolution; no copying. Acceptable as stated.

## Remaining verification limits (not findings)

These are explicitly scheduled gates or deferred product preferences, correctly not treated as defects: Secure Enclave pre-login/custody feasibility, atomic command execution, sudoers compatibility, 1Password/Little Snitch AX fixtures and true one-time semantics, single-biometric credential release, protected update placement/anti-rollback enforcement, the trust-generation witness mechanism, background Access authentication, idle-interval default, retention duration, and the migration ceremony UX. Plan convergence cannot be claimed for these; each has a defined failure/consultation path. Process note: per the round-18 disposition, K3's result was pending when that snapshot froze — review-protocol convergence for revision 25 remains conditional on reconciling it; this is a process state, not a plan defect.

## Conclusion

**NO SUBSTANTIVE FINDINGS**

Revision 25 is internally consistent across the earlier security invariants and the later audit, routing, transport, update, and protocol-evolution additions. I found no downgrade, replay, or privilege-boundary gap that is not already bounded by an explicit mechanism or a defined feasibility gate with a failure/consultation path, and no reviewed change silently degrades the confirmed UX contract. Remaining risk is concentrated in unproven platform feasibility (key custody/anti-rollback, atomic execution, dialog semantics, background delivery), all of which the plan itself defers to gated spikes; this review makes no claim those gates will pass.