## Review of revision 13 (complete plan)

I reviewed the full plan, including the post-revision-5 sections (12–18) and the round-6 disposition, checking specifically for contradictions between early invariants and later additions, downgrade/replay gaps, privileged update paths, and remote-UX preservation.

### Assessed areas

**Cross-section consistency.** The new sections hold up against the core invariants:

- **Audit (12)** vs **§6**: memory-only pending payloads, journal transaction committed with consumption before dispatch, and metadata-only retention are mutually consistent. The "full request contents were not retained" explanation in history does not conflict with §1's full-command display rule, which applies to active requests.
- **Expiry (13)** vs **§6/§9**: target deadline vs Remozio deadline separation, monotonic-clock authority, refresh-creates-fresh-challenge, and revalidation before action compose without contradiction. Refresh preserves age/deadline without reviving expired authority.
- **Routing (14)** vs **§3/§15**: requests kept local while active produce no phone pushes; handoff forwards only still-valid requests with original identity/age; presence changes do not invalidate in-flight biometrics; expired local requests never become actionable notifications. The unimplemented local-command path is an explicit feasibility gate with a caller-visible explanation, not a silent stall.
- **Push/LAN/relay (15–16)** vs **§5–6**: opaque wake identifiers, authenticated fetch before actionable display, pinned identities on both paths, consumption state preserved across path changes, and relay inability to mint decisions are consistent with the signature model.
- **Updates (17)** vs **§3**: the disposition's protected-placement fix is present — root-launched code, staging, registrations, and containing directories must resist same-user replacement, with the "prove equivalent platform launch-time signature enforcement" escape hatch (e.g., SMAppService) deferred to the feasibility gate. The drain policy, restart matrix, and "never replay a consumed permit" rule integrate cleanly with §6.
- **Protocol evolution (18)**: contract selection is constrained by security floor and required action features, so "maximize eligible phones" cannot downgrade below a safe contract. Domain separation by purpose/version, authenticated negotiation transcripts, rejection of re-encoding to weaker schemas, and per-delivery support rechecks close the downgrade/replay surface I probed (stale pushes, replayed audit batches, replayed negotiation, replayed policy, permit reuse, credential-package substitution). Each is either explicitly rejected or covered by an acceptance test.
- **Disposition verification**: all four round-6 corrections appear in the text as described. I found no concrete unresolved scenario that challenges their reasoning.

**Threat-model boundaries.** Malicious unprivileged caller coverage (audit-token/XPC validation, caller-identity capture, stdin classification, decision-key narrowness, both-verifier scope enforcement) is intact, and the confirmed allow-once tradeoff is not widened to commands or 1Password. Key separation (authority/transport/adapter/decision/credential) survives the new negotiation and push sections.

**UX preservation.** No new findings in revision 13 silently add confirmations, biometrics, manual steps, or shortened windows. The idle interval, retention duration, recurring update authorization, and local-command path are explicitly deferred preferences or gated decisions with consultation paths, which per the review protocol are not defects. All three adapters remain in scope with staged delivery.

### Remaining verification limits

This is a plan-only review. Unverified by definition: macOS 14 API availability (XPC peer requirements, service management, protected placement), 1Password/Little Snitch AX contracts, single-biometric credential release, monotonic-clock-including-sleep behavior, descriptor-based execution, background Access authentication, push delivery under Doze, and update-drain continuity. All are scheduled as feasibility gates with evidence requirements and consultation paths; none are claimed as proven.

NO SUBSTANTIVE FINDINGS