# Independent review — Remozio plan, revision 14

Scope: full plan, sections 1–18, including post-revision-5 additions (audit, expiry, presence routing, push, LAN/relay, component identity, Sparkle updates, protocol evolution). Plan-only assessment; no testing, browsing, or source inspection performed or claimed.

## Assessment summary

I specifically hunted for the defect classes the brief calls out, and found the plan internally consistent on each:

**Cross-invariant contradictions.** Checked the new sections against earlier invariants:
- Audit (§12) vs payload minimization (§6): pending sensitive payloads stay memory-only; journal/cache exclusion list is complete and consistent; the detail view explicitly discloses non-retention.
- Routing (§14) vs delivery (§5, §15): §5's "deliver to every authorized phone" is correctly conditioned on phone routing; handoff preserves identity/age/deadline; locked/dark overrides activity timestamps; fail-to-phone on detector loss is delivery-only, not authority.
- Expiry (§13) vs state machine (§6): estimate vs observed timeout vs disappearance are kept distinct; disappearance-after-dispatch correctly falls under confirmed-result/unknown rules, not expiry.
- Updates (§17) vs permit/crash rules (§6, §9): quiescence covers pending requests, active commands, *and* live permits including the bundled GUI adapter; the restart matrix aligns with §6's crash rules; "old authority owns I/O until commands finish" is consistent with drain-then-activate.

**Downgrade/replay.** §18 binds both capability advertisements, nonces, and selection into an authenticated transcript; forbids re-encoding a request into a weaker schema; rejects replayed older policy; separates envelope version from request contract. §17's per-RPC minimum security generation bound to OS-validated signed metadata (not peer-supplied strings), generation-bound key certification, and the explicit key-custody gate for old signed builds close the round-7 gap. Contract selection ("largest eligible phone set, ties to highest") cannot go below the floor and uses authenticated capability records, so a relay cannot influence it.

**Privileged update path.** The rev-14 fixes (automatic activation only at quiescence, optional explicit drain, narrow decision-key scheduling with no target-action authority, bounded adapter wait instead of kill) resolve the round-7 findings without adding confirmations or biometrics. Staging/symlink/registration race tests are specified; scheduling controls are challenge-bound, single-use, and serialized with activation.

**Scope classification and key separation.** Decision-key purposes are enumerated and the exclusion list (commands, 1Password, credentials, enrollment, rule changes including temporary/session) is enforced at *both* verifiers from retained semantics, not caller/phone labels. Update-scheduling authority is explicitly excluded from target-action and release-signing authority. The confirmed Little Snitch allow-once exception is not widened.

**Relay resistance.** End-to-end payload encryption between root authority and phone; opaque push payloads; Access as transport-only gate; push tokens carry no authority; revoked phones rejected by the Mac independent of Access revocation timing.

**UX preservation.** No new biometric prompts, confirmations, response-window shortening, or command restrictions were introduced in the reviewed deltas. Deferred items (idle interval, retention duration, sudoers policy choice, atomic-execution semantics, local command approval surface, biometric-invalidation policy, Access credential renewal, forced-update deadline) are all recorded as pending user decisions or feasibility gates with consultation paths — per the brief, these are planned work, not defects.

## Tentative UX choices noted (not defects)

- 30s draft idle threshold vs ~60s 1Password prompt: the plan correctly refuses to extend the target window and defers the interval to the user, but the tension should be measured in feasibility.
- Biometric-free update scheduling via decision key (§17): consistent with the threat model and reversible (cancel-drain), but it is a new remote control surface worth explicit user awareness during implementation review.
- §11's review protocol names two reviewers while the round-7 disposition adds GLM as a third; a process note only.

## Remaining verification limits

This review does not establish platform feasibility: the macOS 14 floor, 1Password/Little Snitch AX contracts, service-management protected placement, old-build key-custody isolation, single-biometric credential operation, background Access authentication, and descriptor-based execution are all unproven gates with defined failure/consultation paths. No implementation exists to audit; convergence here means no unresolved *planning* defects, not security assurance.

## Verdict

**NO SUBSTANTIVE FINDINGS**