# Remozio plan review: revision 19

## Finding 1 (Medium): Restore-rollback detection has no mechanism, and gateway revocation evidence is not applied locally

**Sections:** §16, "Synchronize lifecycle changes and cleanup"; §17, "Failure and recovery"; §5, "Revocation and pairing recovery".

**What the plan says now:**
- A restored backup "must not silently restore revoked phone authority locally or remotely."
- The Mac must confirm current trust "from protected non-rolled-back records or authenticated recovery evidence."
- "The gateway is never an enrollment authority for local actions."

**What is missing:**
- The plan never says how the root detects that its own enrollment store was rolled back.
- It schedules no feasibility gate for that detection.
- The new counter recovery handles only the gateway side. The root advances the counter and "signs its current trusted desired state." But after an undetected restore, that state is the stale one.

**Failure scenario:**
1. The user revokes a lost phone. The gateway records a revocation tombstone at revision N.
2. Later, the user restores the Mac from Time Machine or Migration Assistant. The restored root records predate the revocation, and ordinary on-disk state cannot reveal this.
3. The Mac reconciles the gateway head. It sees revision N and the tombstone, then re-signs a mapping at N+1 that includes the lost phone. The gateway correctly rejects re-adding it.
4. Nothing in the plan makes that rejection, or the unexplained higher revision, affect local authority.
5. The lost phone reconnects over LAN or the tunnel. Its decision key regains local authority for allow-once, routing, and update-scheduling decisions.
6. If the phone is still unlocked in a thief's hands, those decisions can be used. Biometric actions still need the owner's biometric, but the revoked enrollment has been silently revived locally.

This is not covered by an existing gate. §3 and §17 gate the placement and anti-rollback of *code*. Rollback of *trust state* has only a requirement, with no mechanism and no failure path.

**Minimal correction:**
1. Treat gateway evidence as restrictive-only rollback evidence. A gateway head can prove the Mac previously signed a higher revision or epoch than it holds locally, or can carry a tombstone for a locally enrolled phone. In either case the root must:
   - mark its trust state as possibly rolled back;
   - suspend the affected phones' authority, and suspend new mapping publication;
   - route the user to the existing independently authenticated administrator recovery.
   This does not make the gateway an enrollment authority, because it can only remove authority, never grant it.
2. Add a feasibility item for local detection of trust-store rollback, such as a protected monotonic marker, if the platform offers one. It needs a documented failure path for the case where the gateway is unreachable at startup.
3. Add an acceptance case: revoke a phone, restore the pre-revocation state, and confirm the revoked phone cannot act locally over LAN or relay.

**UX impact:** None in normal operation. After a detected restore, the user goes through the already-specified administrator recovery. That is an exceptional manual step, not a new routine confirmation. It should still be disclosed to the user.

## Prior disposition (round 12)

- **Opus 2 (token challenge sequencing):** The candidate → challenge → proof → activation sequence is sound. Candidates cannot change the active mapping. Revocation invalidates pending candidates. No biometric or approval notification is added.
- **Opus 1 (gateway counter recovery):** This correctly fixes the stale-counter liveness problem. Its trust-restoration half depends on Finding 1 above.

## Other areas assessed (no further findings)

- **Scope classification:** Biometric-free use is limited to cancel, deny-once, and Little Snitch allow-once. No widening to command execution or 1Password was found.
- **Key separation:** The decision key's purposes stay confined to one-time decisions, routing, and update scheduling.
- **Relay resistance:** Relays and transport credentials cannot mint decisions or read request contents.
- **Update activation:** Activation waits for quiescence and commits floors atomically. A failed update does not interrupt running work. The transparent resubmit applies only to authenticated no-admission responses.
- **Mixed versions:** A signed request cannot be re-encoded for an older phone, and negotiation is authenticated so downgrades fail.
- **Routing:** Routing is delivery-only. It keeps revision control and has an explicit gap state until local command approval exists.
- **Audit and expiry:** Audit data minimization and the separation of target expiry from Remozio expiry are consistent.

Deferred preferences (idle threshold, retention duration) and the existing feasibility gates are not treated as defects. Platform feasibility remains unverified.

**SUBSTANTIVE FINDINGS REMAIN**