# Remozio plan review: revision 27

## Findings

### F1 (Medium): Trust-changing commits have no defined behavior during a transient witness fault

**Sections:** §12 *Atomic journal writes*; §16 *Feasibility gate: restored trust state*; §5 *Revocation and pairing recovery*; §17 *Activate and commit security floors*.

**Defect.** Revision 27 defines transient witness faults only for startup and epoch creation. That state is a retryable start with admission closed. However, §12 and §16 also anchor the witness at every authenticated trust, floor, or replay-control change. Those changes happen while the service is live. The plan does not say what happens if the witness write times out or fails at that point.

**Failure scenario.** An administrator revokes a lost phone over SSH while the witness is temporarily unavailable. Two readings of the plan are both plausible, and both are bad:

- **Revocation waits for the witness.** The lost phone keeps authority until the witness recovers. This contradicts §5, which says Mac-side key removal "immediately invalidates" the phone.
- **Revocation commits locally anyway.** The local trust state is now ahead of the witness. §16 says "A partial commit must not pair newer authority with an older witness." §12 sends a genuine mismatch to administrator recovery. So a transient fault turns into a manual repair, which §12 now forbids.

The same ambiguity applies to a floor commit during update activation (§17) and to replay-control commits for routing, scheduling, and gateway controls.

**Why this is not covered by the feasibility gate.** The gate's "interrupted-write recovery" item is about mechanism. The missing piece is ordering policy: which side may lead, and whether that state is legitimate.

**Minimal correction.**

1. Make restrictive changes (revocation, tombstones, floor raises, consumption of replay controls) take effect in the live process immediately and fail closed. They retry the witness anchor with bounded backoff, as §12 already does for startup.
2. Hold permissive changes (enrollment, new mappings) until the witness commit completes.
3. Define the resulting "local restrictive state ahead of witness" condition as protocol-resolvable. On restart it should roll forward automatically, not be treated as a genuine mismatch.
4. Add tests for revocation and floor commit under an injected transient witness fault, including a crash before the retry succeeds.

**UX impact:** none. This preserves remote revocation and avoids a manual step.

### F2 (Low): Caller and adapter behavior for "Mac authority starting" is unspecified

**Sections:** §12 *Atomic journal writes* (retryable starting state); §17 *Automatic activation and optional drain* and *State across restarts*.

**Defect.** §17 gives transparent wait-and-resubmit behavior, and GUI-adapter recapture, only for an authenticated **Update installing** no-admission result. The new §12 starting state also guarantees no admission and preserves unconsumed input. However, the plan does not say whether the command frontend and GUI adapter treat it the same way.

**Failure scenario.**
- **Command frontend.** It may exit immediately. A remote coding agent's privileged command then fails during a brief witness hiccup after reboot. The user has to rerun it manually, which is a remote-UX regression.
- **GUI adapter.** It may never recapture a 1Password prompt observed during the starting window. That prompt then silently misses its roughly 60-second lifetime.

**Minimal correction.** Make the starting-state response an authenticated, submission-bound no-admission result. Apply the existing §17 bounded wait, resubmit, and recapture rules to it, with the same cancellation, caller-lifetime, and stdin/PTY guarantees. Return a distinct status when the caller's deadline is exceeded, and add this case to the §18 acceptance list.

**UX impact:** none. This improves UX and does not shorten any window.

## Prior disposition (round 20)

The Opus F1 correction is sound for startup and epoch creation. F1 above is the concrete residual case it did not reach: live trust commits.

## Tentative UX choices

These are already recorded as pending and are not defects:
- The migration ceremony.
- The idle interval.
- Retention.
- The sudoers-policy selection.
- The atomic-execution fallback.

## Assessment

I found no new contradictions in:
- scope classification or the separation between the decision key and the biometric key;
- relay or gateway authority;
- negotiation downgrade handling;
- update activation and floors;
- the multi-phone consumption ledger.

All of these remain subject to their stated feasibility gates.

SUBSTANTIVE FINDINGS REMAIN