# Remozio plan review: revision 24

## Findings

### 1. Medium: the fail-closed journal state does not survive a service restart

**Where:** §12 "Atomic journal writes", together with §6 "Crash and uncertain-outcome handling" and the §17 "State across restarts" matrix.

**The rules as written:**
- A head mismatch stops appending and closes admission until recovery proves exclusive ownership and ledger continuity.
- The same subsection requires a fresh epoch "on every root-service start."
- It also says "a normal restart alone is not evidence of rollback."
- The only startup validation specified is for lock identity, not ledger continuity.
- The expected head that detects a mismatch appears to exist only in the live writer.

**Failure scenario:**
1. A concurrent maintenance path, or a live replacement, swaps in an older journal. That journal lacks the consumption records for actions already dispatched.
2. The live writer detects the mismatch and closes admission, as intended.
3. launchd KeepAlive, a crash, or a reboot restarts the service.
4. On startup the service acquires the lock and finds an internally consistent journal. It creates a fresh epoch, labels it a normal restart, and reopens admission.
5. The lost dispatched actions are never reported as Unknown. This violates §12 ("Keep unknown outcomes visible"), the §17 matrix row "Root-authority restart after consumption", and §12's "label the cause accurately".

The trust witness does not cover this case, because §12 explicitly does not rely on it for audit-only rollback. The random epoch prevents sequence reuse, but it does not detect lost consumption records.

**Minimal correction:**
- Persist a recovery-required marker in protected storage before closing admission. Startup must honor it.
- On every start, validate ledger continuity against a protected head record before reopening admission. This record should be written with each committed append, or covered by a witness-like mechanism.
- Otherwise, label the new epoch as a possible loss rather than a normal restart.
- Add "head mismatch, then restart" to the §12 test list.

**UX impact:** None in normal operation. Recovery already uses the existing repair path.

### 2. Low: rejected decisions from the network are durably journaled with no bound

**Where:** §12 "Events to retain" ("decisions received and accepted or rejected"), together with §12 "Atomic journal writes" and "Retention and replay safety".

**The rules as written:**
- A journal transaction failure blocks dispatch.
- Retention is bounded by a storage budget.

**Failure scenario:**
1. A network attacker or compromised relay (in scope per §2) floods forged or invalid decisions.
2. If each rejection is a durable audit event, the journal consumes its storage budget.
3. One of two things follows:
   - Retention prunes legitimate history early.
   - Journal writes fail, which blocks all new actions, including local command approvals that never touch the relay.

Dropping relay traffic already denies remote service. This attack goes further and degrades local operation and history integrity.

**Minimal correction:**
- Journal individual rejected decisions only when they authenticate to a currently or previously enrolled key for that Mac/account.
- Record unauthenticated rejects as rate-limited aggregate counters.
- Reserve journal capacity for consumption and outcome events.

**UX impact:** None.

## Prior disposition (round 17)

Both K3 fixes are correctly reflected in the §12 text:
- the exclusive writer lock with compare-and-set;
- the immutable epoch-creation trust generation, which does not reset history on revocation.

Finding 1 is a gap left by the first fix, in how it interacts with restart. Opus's note about unprovable absence of later events remains adequately covered.

## Assessed without further findings

- **Scope and authentication:** the action/scope biometric table and dual-verifier enforcement; decision-key purpose separation for routing and update scheduling; relay/gateway authority limits and token-possession binding.
- **Lifecycle and restarts:** multi-phone first-decision consumption; update quiescence, floor commit, and the restart matrix; protocol negotiation and downgrade rules; timing and expiry separation; presence routing and handoff.
- **Remaining gates:** these are properly defined with failure and consultation paths:
  - key custody and restored trust;
  - single-biometric credential release;
  - descriptor execution and sudoers compatibility;
  - AX fixtures and allow-once validation;
  - local command approval;
  - migration ceremony.

Actual platform feasibility is still unverified.

**SUBSTANTIVE FINDINGS REMAIN**