# Independent plan review — Remozio revision 5

**Verdict: NO SUBSTANTIVE FINDINGS**

## What was assessed

This was a plan-only review; no source, device, or network behavior was inspected or tested. I traced concrete attack and failure scenarios against the plan text rather than restating it:

- **Scope classification and the Little Snitch once-exception** (§1, §6, §9). The once/rule boundary is drawn from retained action semantics and adapter capability mapping, not caller or phone assertions; both verifiers (root service and GUI adapter) independently enforce it; reusable timed/session rules are classified as rule-setting; second and concurrent connection attempts inheriting a once-decision are explicitly tested (§10). The confirmed biometric-free allow-once is not widened to commands or 1Password, and both verifiers reject decision-key authority for those purposes. Unknown compatibility contracts cannot inherit one-time classification, with no biometric override path. I could not construct a scope-confusion scenario that survives these controls.
- **Key separation and relay resistance** (§3, §5, §6). Authority, transport, biometric, decision, and credential keys have distinct purposes; purpose asserted in a message grants no authority; decisions bind the full request digest, challenge, action, scope, expiry, and phone identity; the relay sees only E2E-encrypted payloads and cannot mint decisions, alter digests, or substitute credential recipients (all in acceptance tests). The pre-login transport key fallback is correctly excluded from credential/authority custody, with an explicit blocker-and-consult path rather than silent degradation.
- **Command binding** (§8). Capture-before-approval of argv/env/cwd/credentials/stdin classification; uncaptured caller-controlled input is disclosed without implying provenance; verified requester identity is separated from unverified rationale/ancestry; the execution-recheck race, sudoers policy parity, and descriptor-based execution are all defined feasibility gates with evidence-plus-consultation paths, not silent assumptions.
- **UI race handling** (§6, §9). One-time ledger permits consumed before dialog mutation; revalidation of identity, dialog instance, semantic fields, scope, and control; scope-mutation failure → unknown with no retry/restore; refresh labels potentially modified defaults; consumed permit without acknowledgment reaches unknown and cannot act later; reordered/replaced dialogs tested for Deny/Cancel. The permit being obtained from the root ledger immediately before acting also closes the revocation race for UI decisions.
- **Android biometric and credential release** (§7). Per-tuple keys, CryptoObject binding to an immutable displayed request, transition tests, no keyguard approval surface per the user's clarification, decision-key rules mirroring the immutable-selection rule. The single-biometric credential-release question is a defined spike with a consult-on-failure path.
- **Recovery and remote-coding UX** (§5, §8). Multi-phone consumption, revocation serialization, and cancel-when-no-authorized-phone match disposition F2; target timeout/default capture and observed-vs-unknown resolution match F1; remote-administrator recovery does not require the old phone; pairing preservation after biometric change is a gate with an authenticated fallback, not a promise. Coding-tool timeouts are surfaced, not silently shortened; no UX-worsening change (extra confirmations, restricted commands, shorter windows) is silently adopted anywhere in the revision.
- **Prior disposition** (round 4). F1 and F2 are verifiably implemented in §9 and §5 respectively; the sudoers gate is correctly framed as evidence-plus-user-choice, not a pre-made policy selection. No unresolved scenario from it remains.

## Tentative choices explicitly deferred to the user (not defects)

These remain open but each has a defined evidence-and-consultation path: relay/push-wake delivery; sudoers integration vs. administered Remozio policy; atomic execution mechanism options; single-biometric vs. dual-operation credential release; unlocked-device constraint on the decision key; biometric-invalidation policy for the biometric key; synthetic-typing fallback for 1Password; StrongBox/TEE minimum assurance; optional detached execution mode; any environment restriction that breaks a workflow. Per the review instructions these are gates, and convergence is not claimable over them as settled policy.

## Remaining implementation verification limits

Convergence here means the plan is internally consistent and complete at the planning level only. Still unverified and reserved to the feasibility stage: real 1Password/Little Snitch AX structure and true once-semantics, Keystore invalidation behavior across Android versions, pre-login key custody, sudoers parity, descriptor-based execution, background delivery under Doze, and macOS 14+ service-management behavior. No code, signatures, or privileged boundaries exist yet to audit; this review cannot and does not attest to implementation security.