# Remozio plan review: revision 26

**Scope:** complete plan, plus the round 19 disposition. This is a plan-only review. I ran no tests and inspected no source, platforms or links.

## Findings

### F1 (Medium): the new witness write can block command approval after a reboot

**Where:**
- §12 "Atomic journal writes" (anchor the checkpoint to the witness at epoch creation)
- §12 "Sync and offline cache" (fresh epoch on every root-service start)
- §16 "Feasibility gate: restored trust state"
- §3 "Availability by session state"

**Problem:** Revision 26 creates a fresh epoch on every root-service start and anchors it to the combined witness. So every boot now needs a successful witness write before the root admits any request.

The §16 witness gate asks for crash-safe, offline, rollback-resistant behaviour. It does not ask for the witness to work before GUI login. It also does not say how a transient witness failure is classified.

§12 says that if current authority "cannot be established", admission stays closed and the existing repair path applies. That repair path is the manual administrator recovery.

**Failure scenario:**
1. The Mac reboots and nobody logs in.
2. The user opens an SSH session and runs `remozio sudo -- …`.
3. The witness uses a mechanism that is only available after login or unlock (for example, the login keychain), or its first write at boot fails transiently.
4. The root cannot anchor the new epoch, so admission stays closed.
5. A strict reading routes this to administrator repair.

The result is that remote command approval is broken after every reboot, or a routine hiccup becomes a manual repair. That contradicts the §3 requirement "command approval does not depend on GUI adapter availability / without Aqua login". It also contradicts revision 26's stated goal that routine interruptions recover automatically without an administrator. The §10 acceptance tests would catch this late, but the gate could select an incompatible witness first.

**Minimal correction:**
- Add "available and writable before GUI login, under the root/daemon context" to the §16 witness requirements and to the key-custody record.
- If this cannot be met, fail the gate explicitly and consult the user. Do not silently require login.
- In §12, classify a transient witness read/write failure at epoch creation as retryable closed admission:
  - show a visible "Mac authority starting / storage unavailable" status to the caller and the phone;
  - retry automatically;
  - use the repair path only for a genuine continuity mismatch or an unresolvable state.
- Add an acceptance case: reboot, stay at the login window, submit over SSH, and inject a witness fault at first start.

**UX impact:** none. This correction preserves the current UX and adds no confirmation, biometric or manual step.

## Assessment of the round 19 disposition

Both items appear correctly resolved:

- **Opus 1 (audit continuity vs. authority rollback):** §12, §16 and §17 now state the same model. Per-action commits stay local and crash-consistent. The witness is anchored only at epoch creation and at trust, floor or replay-control changes. History-only loss recovers automatically into a new epoch with a visible discontinuity. I found no replay path:
  - pending payloads are memory-only;
  - challenges are fresh;
  - live recovery retires pending requests and quiesces permits;
  - §17 recapture requires established never-consumed state, so ledger loss yields Unknown rather than recapture.
- **Opus 2 (routine interrupted commits):** resolvable pre-dispatch and post-dispatch interruptions are distinguished from genuine mismatch. F1 is the one remaining place where the escalation rule is ambiguous.

## Other areas assessed with no substantive issues

- **Scope classification and key separation:**
  - The decision key is limited to cancel, deny-once, true Little Snitch allow-once, routing and update scheduling.
  - Every reusable rule, including Forever and session/timed rules, requires the biometric key.
  - Both verifiers derive the required key class from retained semantics.
  - Unknown compatibility contracts cannot inherit one-time classification.
- **Relay, gateway and cloud management:** candidate-token proof, tombstones, revision reconciliation that only restricts authority, and a management controller with no network listener or approval authority.
- **Command binding:** stdin/PTY disclosure, requester-exit semantics, and the sudoers and descriptor-execution gates with consultation paths.
- **UI races:** consumed permits, scope-mutation-as-one-attempt, observed versus inferred target timeouts, and Refresh without replay.
- **Updates and versions:** automatic activation only when quiescent, protected activation independent of the candidate root, floor commit after replacement checks, and deterministic single-contract selection without re-encoding.
- **Android:** the single-biometric credential-release gate, pairing preservation on biometric change, and no keyguard surface.

## Remaining open items (feasibility gates and preferences, not defects)

- **Deferred product preferences:** idle threshold, retention duration, and the migration ceremony.
- **Feasibility gates with a defined consultation path:**
  - Little Snitch true-once semantics
  - 1Password secure-field targeting
  - service-management placement and anti-rollback
  - non-exportable authority keys
  - background Cloudflare Access authentication

**Implementation limits:** none of the platform guarantees are established by this plan. That includes Secure Enclave, pre-login custody, witness monotonicity, XPC generation isolation and Android key-invalidation behaviour. All of them still need device evidence.

**SUBSTANTIVE FINDINGS REMAIN**