# Remozio plan review: revision 29 (round 23)

**Input:** `reviews/round-23-plan.md`, revision 29, the complete plan (sections 1–18), plus `reviews/round-22-disposition.md`.
**Method:** plan-only reading. I ran no tests, did no browsing and inspected no source.

## Revision 29 changes

**Section 8, "Process I/O and terminal outcomes" (busy-state table and retry rules)**

- All four busy reasons share one authenticated, submission-bound no-admission proof.
- Each reason has a distinct deadline status.
- One caller deadline covers all retries and does not reset when the reason changes.
- Automatic resubmission is permitted only for negotiated retry classes.
- Lost or ambiguous acknowledgments never trigger resubmission.

This closes K3 L1 without adding a manual rerun.

I checked for a replay path and found none:
- Resubmission creates a fresh capture and needs a fresh decision.
- A forged busy response from an untrusted same-user caller can at worst cause a harmless fresh request, because it cannot carry a valid authority binding.
- Input is left unconsumed until admission.

**Cross-section consistency**

- Section 12 ("Retention and replay safety" and "Atomic journal writes") returns Storage unavailable before dispatch.
- The section 12 witness-fault path maps to Mac authority starting.
- Section 17 ("Automatic activation and optional drain" and "State across restarts") applies the same four classes to command resubmission and to GUI recapture. Recapture preserves the original age and target expiry.
- Section 18's acceptance list covers deadline exhaustion, reason changes, indefinite drain, storage exhaustion and unverified health hints.

**Round 22 disposition**

Rejecting the manual-only retry for Update waiting and Storage unavailable is sound. A bounded automatic wait avoids a needless rerun, and the fixed deadline prevents an indefinite stall. I found no concrete scenario where this weakens authority or hides state.

## Rest of the plan

I found no new contradictions in the rest of the plan.

**Scope and key separation**
- The biometric-free exception is still confined to cancel, deny-once and Little Snitch allow-once whose actual effect is limited to the current request.
- Every reusable rule and the Forever default requires biometrics.
- Decision-key purposes (routing, update scheduling) grant no target, enrollment or release authority.
- The command and 1Password paths never inherit the exception.

**Relay and transport**
- The relay and transport cannot mint decisions or read payloads.
- Tunnel, push-gateway and Cloudflare-management credentials are separated.
- Gateway recipient changes require root-signed controls plus proof of token possession.

**Command binding**
- Argv, environment and stdin source are captured with disclosure.
- The atomic-exec and sudoers questions are explicitly gated.

**Android biometric credential release**
- The single-operation question is a gate with a consultation path.

**UI race handling**
- There is a one-use permit ledger.
- A failed scope mutation is reported as Unknown.
- The GUI permit acknowledgment path is defined.

**Recovery, updates and mixed versions**
- Protocol-resolvable journal interruptions recover automatically.
- History-only loss is separated from authority rollback.
- A restrictive witness intent can roll forward; a permissive one waits.
- Rollback protection is enforced outside the candidate binary.
- Negotiation cannot downgrade below a floor, and existing requests are never re-encoded into a weaker schema.

## Non-blocking observation

In section 12, "Atomic journal writes", the caller-facing string "Mac authority starting / storage unavailable" for witness faults sits beside the separate section 8 Storage unavailable status used for audit-reserve exhaustion. Implementation should map witness faults to exactly one reason code so exit statuses stay deterministic. This is a naming precision issue, not a planning defect.

## Pending choices (not defects)

- Migration ceremony
- Idle interval
- Retention duration and storage budget, including what happens when the budget is reached
- Outcomes of the explicit feasibility gates:
  - key custody and the trust witness
  - service placement and anti-rollback
  - atomic exec
  - sudoers compatibility
  - single-biometric credential release
  - 1Password and Little Snitch fixtures and true one-time effects
  - background Access authentication
  - local command approval
  - Android biometric-change continuity

## Remaining implementation verification limits

Several things are not verified:
- Platform guarantees are unproven, notably protected placement against the same-user administrator, pre-login witness availability, and Secure Enclave custody under pre-login conditions.
- Accessibility atomicity and the target-app effect semantics still depend on real fixtures.
- Delivery on Doze, OEM and FCM devices needs real-device measurement.
- Correctness depends on careful implementation of the commit, witness-intent and ledger protocols under fault injection, as the plan itself states.

**NO SUBSTANTIVE FINDINGS**