# Independent review — Remozio plan, revision 12

Scope assessed: internal consistency of the full plan including post-revision-5 additions (§12 audit, §13 expiry, §14 routing, §15 push, §16 LAN/relay, §17 identity/Sparkle, §18 protocol evolution), checked against the earlier invariants (§5–§9). Security boundaries, key separation, scope classification, relay resistance, and downgrade handling were re-examined; I found them coherent except where noted. Feasibility gates explicitly defined with evidence/consultation paths (service installation, single-biometric credential release, sudoers compatibility, Little Snitch/1Password fixtures, local command approval, remote update continuity, background Access auth, pairing preservation) are treated as planned work, not defects.

## SUBSTANTIVE FINDINGS REMAIN

### Finding 1 (medium): Contradictory restart semantics for pending requests and consumed permits

**Sections:** §6 "Crash and uncertain-outcome handling" vs §17 "Activate a compatible component set" and §18 "Acceptance: upgrades and hostile peers".

**Contradiction:** §6 states pending sensitive payloads are memory-only and "a restart cancels unconsumed requests"; §10 acceptance requires "no execution on service restart"; §6 also requires a consumed GUI permit with lost acknowledgment/IPC to become *unknown*, be invalidated, and never act later. But §17 requires "Do not… silently discard pending requests to install an update. Defer activation when continuity cannot be guaranteed. Resume pending requests only if their original payload, version, expiry, and ledger state remain valid," and §18 acceptance requires "Update with… a pending biometric prompt… and a consumed GUI permit. Preserve the original request contract."

**Concrete failure scenario:** An update activates while a command request awaits phone approval. The payload is memory-only, so the post-restart service cannot resume it — "resume if valid" is unreachable, and "defer activation when continuity cannot be guaranteed" either deadlocks updates whenever any request is pending or silently contradicts §6 by discarding the request. Similarly, a consumed-but-unacknowledged GUI permit across a service restart must resolve to *unknown* under §6, but the §18 acceptance case as written demands its contract be preserved.

**Minimal correction:** Add an explicit restart-state matrix reconciling the sections: (a) durable pending-request *metadata* may survive restart; sensitive payloads never do, so post-restart pending requests follow the already-specified "show why the request needs a fresh submission" path (with recapture/new challenge where §9 Refresh applies); (b) consumed-unacknowledged permits always resolve to *unknown* after restart; (c) "defer activation" is scoped to protecting *active executions* only (already covered by "do not kill active commands"). Reword the §18 acceptance case to match (a)–(b). No UX worsening: this adopts behavior the plan already specifies elsewhere.

### Finding 2 (low): Last-phone revocation cancels locally-approvable requests

**Sections:** §5 "Revocation and pairing recovery" vs §14 "Menu bar modes" / §14 "Feasibility gate: local command approval".

**Contradiction:** §5 cancels a pending request "when no authorized phone remains for the Mac/account." §14 later introduces "At my Mac" mode and a planned local command-approval surface, under which a pending request never required any phone. Revoking the sole enrolled phone (e.g., a lost phone while working locally) would spuriously cancel requests that could still be resolved locally, forcing resubmission.

**Minimal correction:** Scope the cancellation to requests with no remaining authorized *approval surface* (no authorized phone and no available local path), or explicitly to requests awaiting phone resolution. This adds no steps and only removes a spurious cancellation; no consultation concern.

## Tentative UX choices (not defects, explicitly deferred in-plan)

Five-minute request expiry (§5, "provisional… UX default to validate"); 30-second draft idle interval (§14, pending preference); ~60-second 1Password lifetime estimate (§13, per-version validation planned); macOS 14 compatibility floor (§3, provisional). These have defined validation paths and are not findings.

## What was verified as consistent

- Key separation and purpose binding (§6–§7): decision key cannot authorize commands/credentials/rule changes; both verifiers derive key class from retained semantics; relay/transport keys mint nothing.
- Scope classification (§1, §9): reusable rules incl. session/timed require biometrics; once-decisions confined to the captured alert; unknown compatibility cannot inherit one-time classification; biometric-free allow-once is not widened.
- Downgrade/replay resistance (§17–§18): authenticated negotiation transcript, domain separation, security floors from trusted local policy, replayed-policy rejection, minimum-build enforcement, no hash pinning across updates.
- Push/relay privacy (§15–§16): opaque wake IDs, end-to-end payload encryption, Access as gate not authority, no shared APK secret.
- Audit invariants (§12): consumption + journal event commit atomically; secret exclusions; revoked-phone limits acknowledged honestly.
- Expiry/timing (§13) and routing handoff (§14) preserve identity, age, and first-decision-wins semantics; presence changes do not cancel in-flight biometrics.
- Confirmed UX tradeoffs (biometric-free cancel/deny-once/allow-once, Forever default with biometrics, no keyguard surface, full command rendering) are preserved throughout, including in the new sections.

**Remaining implementation verification limits:** This is a plan-only review. Platform behaviors assumed but not yet evidenced (continuous monotonic clock across sleep, descriptor-based execution, Access service-token background auth, Sparkle/SMAppService continuity, per-display brightness signals, AX stability of target dialogs) are all attached to explicit feasibility gates; none were treated as granted.