# Remozio plan review: revision 18

Scope: I reviewed the complete revision 18 text on its own. Earlier convergence does not carry over. I did not run tests, browse, or inspect source code.

## Findings

### 1. Gateway revision counters can fall behind after a Mac restore (Low–Medium)

**Sections:**
- §16, *Gateway ownership and recipient authority*
- §16, *Synchronize lifecycle changes and cleanup*
- §17, *Failure and recovery*

**Failure scenario:**
1. The gateway has acknowledged mapping revision N.
2. The Mac's local state is then restored from a backup, or rolled back after a failed migration before a floor commit, to a point where it last persisted revision N−k.
3. The plan requires the gateway to reject stale revisions, so every later root-signed control is rejected. This includes phone revocation cleanup and token rotation.
4. The plan offers only two ways out:
   - Never lower the revision. This leaves the Mac permanently unable to update its mapping.
   - A fresh administrator gateway registration with a new epoch. The plan reserves this for reactivation after removal.

Either path breaks the §16 rule that repair must not need manual gateway-operator work after setup. It also leaves remote suppression of a revoked phone stuck on "pending remote cleanup" indefinitely.

The §17 statement that restoring a backup "cannot lower these protections" covers ledger and floors. It does not define how the root resynchronizes a counter that is owned remotely.

**Minimal correction:**
- A stale-revision rejection should return the gateway's authenticated last-applied revision and epoch, bound to the pinned authority and owner.
- The root should then re-sign its current desired state at `max(local, acknowledged) + 1`. It must not re-sign an older mapping.
- Add acceptance cases for backup restore and pre-commit rollback followed by revocation.

**UX impact:** None. This preserves the promise of no operator step.

### 2. The plan never says who sends the token-possession challenge (Low)

**Sections:**
- §16, *Bind phone tokens without new approval steps*
- §15, *Bind and rotate registration tokens*

**Failure scenario:** Proving possession of a new token requires sending a provider push to a token that is not yet mapped. The plan forbids a "general send-to-token endpoint through the transport credential." It also says the root signs the updated mapping only after checking enrollment. It never states the order of the two steps.

An implementer could resolve this in either of two unsafe ways:
- Let the transport send probes to arbitrary tokens. This recreates the forbidden endpoint.
- Sign the mapping first and verify possession later. A token string alone could then redirect wakes, which the plan says must not happen.

**Minimal correction:** Specify the sequence:
1. The root signs a typed "candidate token" control object bound to the enrolled phone, enrollment epoch, and token digest.
2. The gateway alone sends the opaque challenge to that candidate.
3. The phone's authenticated response lets the root sign the final mapping revision.
4. The gateway activates the token only for a matching, verified candidate.

Keep the existing per-enrollment probe bound.

**UX impact:** None. There is still no biometric and no administrator prompt.

## Assessment summary

Revision 18 closes the round-11 items coherently:
- Gateway mapping authority is separated from the submission credential.
- Service-account executables have protected placement.
- Audit scope uses closed classes rather than target values.
- Phone routing control uses a narrow revisioned purpose with no added confirmation.

Other areas checked, with no new defects found:
- **Scope classification:** consistent between §1, §6, and §9.
- **Decision-key purposes:** routing and update scheduling carry no target, enrollment, or release authority.
- **Update activation:** quiescence-based activation, floor commit, and anti-rollback are consistent with the §3 placement invariant.
- **Mixed-version protocol:** selection cannot weaken a signed request.
- **Command capture and stdin disclosure:** consistent across sections.
- **Remote UX:** preserved. Routing overrides are persistent, there are no added biometrics, and response windows are not shortened.

Remaining verification limits sit in declared feasibility gates, so they are not planning defects:
- protected placement or launch enforcement for SMAppService/Sparkle updates
- pre-login transport key custody
- single-biometric credential release
- secure-field targeting
- true one-time Little Snitch effects
- Access background authentication
- local command approval under At my Mac
- sudoers compatibility

The idle threshold and retention duration remain deferred product preferences, not findings.

**SUBSTANTIVE FINDINGS REMAIN**