# Remozio plan review: revision 23 (full plan)

**Input:** `reviews/round-17-plan.md` (revision 23), with `reviews/round-16-disposition.md` as context. This is a plan-only review. No tools, testing, browsing or source inspection were used. Earlier convergence does not carry over to this revision.

## Findings

No substantive planning defects found.

### Round-16 fix (§12 "Sync and offline cache")

The revision 23 change resolves the Opus finding as described:

- **Epoch creation:** a fresh random epoch is created before the first write on every root start, and after journal replacement or recovery.
- **No sequence resumption:** the writer never continues allocating sequences in a persisted older epoch.
- **Head check:** the writer verifies the expected head before each append.
- **Epoch-scoped cursors:** cursors are bound to their epoch, so repeated sequence numbers from a restored journal cannot be confused with, or overwrite, cached records.

The fix does not depend on the trust witness in §16 "Feasibility gate: restored trust state". It adds no user step, biometric or network prerequisite. It also cannot become a source of authority, because:

- Pending payloads stay memory-only (§6 "Crash and uncertain-outcome handling").
- A root restart cancels unconsumed requests.
- Phone reports cannot rewrite history or trust.

A restored ledger therefore cannot revive a signed decision, since the request it binds no longer exists in memory.

### Non-blocking clarification (not a finding)

This concerns §12 "Sync and offline cache". "Link a new epoch to the authenticated prior head when available" could be read as a continuity claim.

- **Scenario:** after an audit-only restore, the "prior head" is the restored, stale head. A phone with no later cached evidence would then see an ordinary restart linked to that head.
- **Suggested wording:** state that the link attests only "records up to H existed". It does not attest that nothing followed H.
- **Limitation to document:** without the trust witness, audit-only truncation is detectable only through phone-held cursors or receipts.

This matches the plan's existing rule not to claim a continuous chain without evidence. It needs a wording change only, with no UX impact.

## Assessed without findings

- **Security boundaries (§3):** root-only authority, and XPC peer validation per request that is tied to a committed generation floor (§17).
- **Key roles and relay resistance (§§3, 6, 15, 16):**
  - Transport, decision, biometric, credential and management keys are separated.
  - Relay, gateway and Access credentials hold no action authority.
- **Scope classification (§1, §6 "Both verifiers enforce scope", §9 "Classify the actual one-time effect"):**
  - Biometric-free handling applies only to Little Snitch cancel, deny-once and allow-once, where the effect is confined to the current request.
  - Command execution and 1Password always require biometrics.
  - Reusable rules, including timed, session and the default Forever, always require biometrics.
  - Unknown compatibility contracts cannot inherit one-time classification.
- **Command binding (§8):** covers argv and environment capture, stdin-source disclosure, and the Request too large result. Execution races and sudoers compatibility are properly gated.
- **Android flows (§7):** the no-keyguard flow and immutable request selection are specified. Single-biometric credential release is properly gated.
- **UI races (§9):** consumed-permit handling with Unknown outcomes and no retry, and scope mutation performed under one permit.
- **Timing, routing and push (§§13–15):**
  - Timing separates two clocks and does not treat estimated expiry as authority.
  - Routing controls under the decision key are revision-bound and idempotent.
  - Push token registration uses a possession challenge.
- **Updates and protocol evolution (§§17–18):**
  - Update drain, the protected activation boundary, and floor commit are consistent with §3 placement rules.
  - Retry after Update installing is limited to authenticated no-admission responses.
  - Contract selection across mixed phones cannot re-encode an existing request into a weaker schema.
- **Recovery and UX:** remote admin recovery is preserved and no silent UX regressions were found.
- **Flux licensing (§4):** Flux is used as a design reference only, with no copying of its code.

## Pending product decisions (not defects)

- The Mac migration ceremony (§3) remains pending the user's choice.
- The idle interval (§14) and history retention (§12) are deferred preferences.

## Remaining implementation verification limits

All the declared feasibility gates still need evidence. These are:

- key custody and non-exportability
- pre-login transport
- restored-trust witness
- protected placement and anti-rollback
- updater staging isolation
- descriptor-based execution
- sudoers compatibility
- AX fixtures for Little Snitch and 1Password
- true one-time effect
- secure-field targeting
- single-biometric release
- Access background authentication
- Cloudflare credential scoping
- presence and brightness signals
- Android delivery under Doze

None of these is proven by this plan.

**NO SUBSTANTIVE FINDINGS**