# Independent plan review — Remozio revision 19 (full plan)

**Verdict: NO SUBSTANTIVE FINDINGS**

## What was assessed

**Round-12 disposition challenged with concrete scenarios:**
- *Gateway counter recovery (§16):* I traced both drift directions. Root-stale: gateway's authenticated head plus the rule "advance to max(local, acknowledged)+1 and sign *current trusted desired state*" avoids renumbering old mappings. The more dangerous case — root restored from a backup predating a phone revocation — is closed by two independent mechanisms: gateway revocation tombstones reject re-adding a phone under its old epoch via an ordinary mapping update, and the local rule that restored backups must confirm trust from non-rolled-back records or authenticated recovery *before* republishing mappings or enabling actions. Neither mechanism adds steps to normal approvals. No unresolved scenario found.
- *Token-possession challenge (§16):* Candidate creation is root-signed and cannot alter the active mapping; only the gateway delivers the nonce to the candidate token, so a token string alone cannot redirect wakes; the proof binds candidate ID, nonce, token digest, and enrollment epoch and is consumed once with expiry; revocation invalidates pending candidates per epoch; rotation races and transport-initiated probes are explicitly excluded and scheduled as acceptance tests. The proof's value depends on the nonce reaching the phone *only* via the provider push, which the text's "only the gateway sends the opaque provider challenge to that candidate token" establishes. No defect.

**Cross-section contradiction checks (earlier invariants vs. later additions):**
- Memory-only sensitive payloads (§6) vs. durable journal (§12): consistent — audit stores closed metadata classes; pending payloads die with root restart and unconsumed requests cancel.
- §13 target-deadline display vs. §6 monotonic Remozio expiry vs. §14 idle-delayed handoff: original age/deadline preserved across handoff and recapture; short-lived 1Password prompts are explicitly not extended.
- §14 routing control and §17 update-scheduling control both ride the narrow decision key with distinct signed purposes, revision/one-use binding, and no biometric — consistent with §6 purpose separation and the confirmed biometric-free UX tradeoff (§1, §9).
- §15 push vs. §14 presence: no new pushes while requests are kept local; handoff sends only still-valid requests with original age.
- §17 restart matrix vs. §6 crash rules: consistent, including the UI-only automatic recapture constrained to never-consumed requests with fresh challenges; command resubmission after unexpected restart is caller-visible, which preserves the no-auto-retry invariant.

**Downgrade/replay gaps:** §18 negotiation is transcript-bound to pairing identity, floors come only from trusted local software/authenticated release policy, no weaker re-encoding of signed requests for older phones, no retry after signature failure. §17 anti-rollback correctly places enforcement *outside* the candidate binary (external activation boundary), with old-adapter certification invalidation and receiving-key generation binding on floor raise. Gateway control plane is epoch/revision/operation-ID monotonic with tombstones. Decision, routing, scheduling, and token-candidate replays each have explicit single-use bindings.

**Privileged update paths:** Protected-placement invariant (§3) is carried through cloudflared, the setup controller, and Sparkle activation (§16–17); the bundle-replacement-during-live-permit case is handled by deferring on-disk installation, not just relaunch. Floor commit is a single durable transaction with admission closed until one compatible set validates.

**Scope classification and key separation:** Once-decision authority is confined to the captured attempt set (§9); both verifiers independently reject decision-key reusable-rule effects regardless of button labels; the confirmed allow-once exception is not widened to commands or 1Password.

**UX preservation:** No new confirmations, biometrics, or manual steps introduced anywhere in the additions; remote functionality, full command rendering, and all three adapters remain in scope.

## Tentative UX choices (deferred, not defects)

Idle interval (30 s draft, §14), five-minute expiry (§5), retention duration (§12), biometric-invalidation policy (§5/§7), sudoers integration choice (§8), and the local command approval path (§14) are explicitly deferred preferences or gated decisions with consultation paths — correctly not treated as findings per the review protocol.

## Remaining implementation verification limits

This is a plan-only review. Convergence here does not establish: macOS service-management protected placement and anti-rollback enforcement, 1Password/Little Snitch AX fixtures and true once-semantics, single-biometric credential release, descriptor-based execution, sudoers policy compatibility, Android background/Doze delivery, background Access authentication, or Sparkle/service-management update continuity — all are defined feasibility gates with evidence and failure/consultation paths. Flux licensing remains unresolved; independent reimplementation is correctly mandated. Deferred product preferences still need user selection before implementation.

**NO SUBSTANTIVE FINDINGS**