# Independent review — Remozio plan, revision 22

Scope: full plan, including post-revision-5 additions (audit, expiry/timing, presence routing, push, LAN/relay, gateway control plane, key custody, Sparkle updates, protocol evolution, mixed versions). Plan-only review; no testing, browsing, or source inspection claimed. Prior disposition (round 15) reviewed; its two accepted fixes (authority-key custody, epoch-bound audit cursors) are correctly integrated into revision 22 and I find no concrete unresolved scenario that reopens them.

## Assessment of the high-risk boundaries

**Authority/key custody (§3, §16).** The custody requirements are internally consistent: no ordinary-file fallback for authority or recipient-certification keys; the transport-key fallback is explicitly scoped to the transport role only; pre-login availability vs. Secure Enclave custody is an explicit blocker-and-consult gate rather than an assumed guarantee. Migration requires a new key with authenticated continuity, and the one-time-interaction cost is correctly recorded as an unresolved user-choice gate, not silently adopted.

**Decision-key separation and scope classification (§1, §6, §9).** The biometric/decision key split is coherent end to end: both verifiers derive the required key class from retained action semantics, never from caller or phone assertion; the once-exception is confined to the captured Little Snitch request; reusable/timed/session rules are classified as rule-setting regardless of label; the "second connection attempt must not inherit" test closes the most obvious widening. Routing and update-scheduling purposes under the decision key are explicitly denied action, enrollment, and release authority. No path widens biometric-free approval to commands or 1Password.

**Replay/downgrade resistance (§6, §12, §16, §17, §18).** Consumption-before-dispatch, single-use permits, epoch-bound audit cursors, gateway lifecycle epochs with monotonic revisions plus signed-receipt reconciliation (counter increase alone insufficient), rollback detection via the combined trust-generation witness, and floor enforcement independent of the candidate binary form a consistent stack. The witness gate explicitly fails closed with a consultation path rather than assuming a platform monotonic counter — correctly a feasibility gate, not a defect. The "authenticated no-admission result vs. unknown admission result" distinction in §17 correctly prevents resubmission of possibly-admitted commands while permitting resubmission of provably non-admitted ones.

**Race handling (§6, §9).** Permit invalidation on adapter death, quiesce-before-recapture, unknown-is-terminal, and scope-mutation-as-one-attempt are consistent across §6 and §9; the UX invariants (no silent Once↔Forever fallback, no silent truncation, refresh-not-replay) are preserved.

**Remote UX preservation (§1, §5, §13–15).** No added confirmations, biometrics, or shortened windows were introduced. The 1Password estimate vs. routing-idle-delay tension is disclosed, not hidden. Push remains baseline; LAN-first with bounded direct-connect attempt protects the short 1Password window. The deferred items (idle interval, retention duration, migration ceremony, biometric-invalidation policy, decision-key unlocked-device constraint) are explicitly recorded as pending user decisions — I flag them as **tentative UX choices**, per instructions, not defects.

**Flux reuse (§4).** Design-only reuse pending license resolution is correctly stated.

## Minor observations (not substantive findings)

- §16 references "fresh boot challenges" invalidating ephemeral operations without a defined mechanism; this is implementation detail within the already-gated witness work.
- Phone-initiated persistent "At my Mac" override is a delivery-only DoS surface for anyone with unlocked-phone access; the plan states the no-biometric/no-expiry choice deliberately and it grants no action authority, so it stands as a documented tradeoff under the trusted-phone assumption.

## Remaining implementation verification limits

A no-findings plan review does not establish: Secure Enclave pre-login availability and code-identity restriction; the trust-generation witness mechanism (no general monotonic counter is assumed); true one-time semantics of Little Snitch controls per version; single-BiometricPrompt credential release; Sparkle's respect for the quiescence boundary during on-disk bundle replacement; sudoers policy equivalence; background Access authentication. All are scheduled as explicit feasibility gates with failure/consultation paths. The K3 full-plan review noted as pending in the disposition remains unreconciled and is outside this pass.

## Conclusion

NO SUBSTANTIVE FINDINGS.