## NO SUBSTANTIVE FINDINGS

This was a plan-only review of revision 18 and the round-11 disposition. I did not perform testing, browsing, or source inspection.

### Boundaries assessed

- **Authority and request binding:** Sections 2, 3, and 6 consistently separate caller identity, adapter assertions, transport authentication, approval authority, and biometric assurance. Requests bind the Mac/account, canonical payload, challenge, expiry, permitted choices, and exact action scope. Decision keys are purpose-limited and cannot authorize commands, credentials, enrollment, reusable rules, routing artifacts, or target actions outside their intended scope.
- **Consumption and concurrency:** Sections 5–6 and 13–18 consistently use the root ledger as the atomic consumption point. Multi-phone races, revocation, stale approvals, expiry, cancellation, permits, reconnects, and crashes do not provide an identified replay or double-execution path.
- **Command execution:** Section 8 binds argv, executable identity, working directory, target identity, environment, caller identity, I/O mode, and stdin classification. Uncaptured stdin/TTY content is explicitly disclosed rather than represented as approved content. Executable substitution, caller exit, sudoers compatibility, and process-lifetime races have defined evidence gates and failure paths.
- **UI adapters:** Sections 9 and 13 preserve request/dialog identity, semantic revalidation, one-time permits, scope binding, secure-field targeting, target deadlines, uncertain outcomes, and refresh semantics. Unknown compatibility cannot inherit one-time classification or be overridden with biometrics.
- **Android biometrics and credentials:** Sections 5 and 7 keep biometric, decision, credential, enrollment, routing, update, and transport purposes separate. Lock-screen behavior, immutable selection, overlay risks, biometric-key invalidation, pairing preservation, and credential recipient binding are addressed without adding an unauthorized lock-screen workflow.
- **Presence routing, push, LAN, and relay:** Sections 14–16 keep routing controls separate from action authority. Push payloads remain opaque, phones fetch authoritative state before acting, parallel LAN/relay paths cannot execute twice, and relay compromise remains limited to delay, loss, and metadata exposure. The round-11 gateway corrections provide owner binding, enrollment-derived mappings, possession-checked tokens, revisions, replay protection, and uninstall tombstones.
- **Audit privacy:** Section 12 uses closed action/scope classes and keeps sensitive targets memory-only. The authoritative journal commits with consumption, while sync cursors, sequence boundaries, and revocation behavior do not create approval authority.
- **Updates and protocol evolution:** Sections 17–18 preserve protected placement, authenticated component identity, anti-rollback, staged activation, quiescence, floor commitment, no-admission responses, and restart semantics. Envelope negotiation cannot rewrite signed requests, lower floors, translate decisions, or grant authority to old contracts. Mixed-phone selection is constrained by floors and required action features.

The revision-18 changes also resolve the prior gateway-mapping, `cloudflared` placement, audit-scope, and remote-routing concerns without an apparent contradiction with earlier approval or revocation invariants.

### Remaining tentative product choices—not planning defects

The plan explicitly leaves these for feasibility evidence and user decision:

- Android biometric-key invalidation and pairing-preservation behavior, §§5 and 7.
- Whether one biometric operation can safely authenticate and release a request-bound credential, §7.
- The sudoers-compatible authorization model, executable-race contract, and any workflow-affecting environment/input restrictions, §8.
- Concrete 1Password and Little Snitch behavior from real fixtures, §9.
- The local command-approval surface and draft idle interval, §14.
- Push-provider suitability and Access background-credential renewal behavior, §§15–16.
- Audit retention duration and storage budget, §12.

Any resolution that adds confirmations or biometrics, restricts commands, removes remote functionality, shortens practical response windows, or requires recurring manual steps remains subject to the consultation rule in §1.

### Remaining verification limits

This result does not establish that the required macOS service-management APIs, XPC identity checks, protected placement, Accessibility structures, Sparkle behavior, Android Keystore behavior, background delivery, Cloudflare Access flow, or credential-release operation work as assumed. Those remain explicit implementation and feasibility-gate responsibilities. It also does not validate the eventual cryptographic construction, canonical CBOR subset, protocol implementation, adapters, or privileged code; those require implementation review and testing.