# Independent review — Remozio plan, revision 26 (full-plan pass)

## Scope assessed

I reviewed the complete plan, including all post-revision-5 additions: audit/journal epochs (§12), request age and dual-deadline handling (§13), presence routing (§14), required push (§15), LAN/relay and gateway control plane (§16), code identity and Sparkle updates (§17), and protocol evolution/mixed versions (§18), cross-checked against the earlier invariants (§§1–9) and the round-19 disposition.

Specific contradiction and downgrade/replay checks performed:

- **Authority vs. audit recovery (§12/§16/§17):** The revision-26 split (per-action crash-consistent local commits; witness anchoring only at epoch creation and trust/floor/replay-control changes) is internally consistent. Automatic recovery for history-only loss, closed admission on genuine mismatch, memory-only pending payloads, and no-resurrection rules agree across all three sections. The round-19 disposition matches the plan text; I found no unresolved scenario in it.
- **Key separation:** biometric, decision, transport, authority, credential, gateway-control, management, and push credentials are distinct purposes with distinct custody (§3, §6, §7, §16 table). Decision-key purposes (once-decisions, routing, update scheduling) are explicitly barred from target-action, enrollment, release-signing, and mapping authority in every place they appear; both root and adapter re-derive key class from retained semantics, not caller/phone labels.
- **Decision-key verification chain (§6):** once-decisions bind full digest/challenge/scope and are verified at root and adapter; the permit ledger is consumed before any dialog mutation including Deny/Cancel (§9). Allow-once stays confined to the captured Little Snitch alert, with second-attempt validation scheduled.
- **Downgrade resistance:** authenticated negotiation transcript binding (§18), persisted floors independent of replaceable binaries (§17/§18), external installation-boundary anti-rollback, per-RPC generation checks, and the combined trust-generation witness gate (§16) form a coherent stack. Backup-restore and floor-rollback scenarios have explicit acceptance tests.
- **Update path vs. remote UX:** automatic activation only at quiescence; drain is optional and decision-key-authorized without biometrics; `Update installing` is pre-admission, so the required "fresh decision" on resubmission is the normal approval, not a repeated one; on-disk bundle replacement is correctly treated as activation; indefinite-command deferral is disclosed rather than killed.
- **Routing/push consistency (§14/§15):** no pushes while kept local, handoff preserves age/deadline/identity, first-decision-wins across phones and surfaces, resolution pushes are best-effort with authoritative fetch-before-action. The gated local command-approval path prevents "At my Mac" from silently stranding commands.
- **Command binding (§8):** capture-before-approval, stdin source classification with uncaptured-content disclosure, no-extra-shell execution, caller-exit boundary distinguishing no-effect vs. started/unknown, and the relocation/copy prohibition are mutually consistent.
- **Audit metadata exclusions (§12):** closed metadata classes vs. memory-only full payloads are consistently applied to journal, cache, sync, diagnostics, and retention.

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

- 30-second draft idle interval and 5-minute expiry default (§14, §5) — flagged in-plan as pending preferences.
- Audit retention duration/storage budget (§12) — deferred to implementation with the user.
- Migration ceremony cost and one-time phone interaction (§3) — gated user choice.
- FCM as provider and 1Password ~60s estimate (§15, §13) — to be validated.

These are recorded as pending decisions/gates with consultation paths; per the review rules they are not planning defects.

## Remaining implementation verification limits

This is a plan-only review. Nothing here establishes: Secure Enclave/Keychain pre-login behavior, a working monotonic trust witness (the plan itself disclaims SEP counters and gates this), 1Password/Little Snitch AX stability, descriptor-based execution atomicity on macOS, Android background/Doze delivery in practice, Sparkle/service-management protected-placement satisfaction, or Cloudflare Access noninteractive renewal cost. Each has a defined feasibility gate with evidence requirements and a failure/consultation path; failure of any gate must produce a user decision, not a silent UX or security regression.

## Conclusion

NO SUBSTANTIVE FINDINGS