# Independent review — revision 16 (round 10)

## Scope assessed

Full plan, with attention to the post-revision-5 additions and their interaction with earlier invariants:

- **Key separation and purpose binding** (§5–7, §17): biometric key, narrow decision key, transport keys, adapter receiving keys, update-scheduling purpose. Decision-key purposes are explicitly enumerated in §6 and the §17 extension (update scheduling) is acknowledged there rather than silently widening authority. Scheduling controls bind Mac/account, phone, update ID, generation, challenge, expiry, and one-use state; they cannot supply artifacts, alter floors, or authorize target actions. No path found where the decision key, relay keys, or push tokens can mint target-action authority.
- **Consumption and replay safety** (§6, §12, §17): ledger consumption precedes side effects; revocation is serialized with consumption; GUI permits are one-use, watched, and invalidated on adapter death; the §17 admission boundary is closed atomically with request creation/permit dispatch, so the authenticated "Update installing — no admission" response cannot race an actual admission. The revision-16 correction (transparent bounded wait + fresh capture/decision on resubmission, never on lost/unknown acknowledgment) is internally consistent with §8's "never automatically rerun" and stdin/PTY preservation rules.
- **Update and anti-rollback path** (§3, §17): placement/protected-staging invariants, generation floors enforced per-RPC and bound into adapter-key certification, floor commit only after full quiescence and checks, interrupted-activation recovery keeping admission closed, no rollback below committed floor, on-disk bundle replacement treated as activation (revision-16 fix). The starvation case (continuous work indefinitely deferring auto-activation) is a deliberate, surfaced design choice with an explicit drain action and blocker visibility — not a hidden failure.
- **Presence routing vs. request integrity** (§13–15): routing changes never grant or revoke authority; handoff preserves identity/age/deadline; already-delivered requests remain resolvable with first-decision-wins; unknown detector state fails toward phone delivery without authorizing anything; expired local requests cannot later produce actionable notifications.
- **Audit and timing** (§12–13): journal/ledger single authority, memory-only sensitive payloads, exclusion rules, retention independent of trust records, monotonic-clock expiry including sleep, observed-vs-estimated target expiry kept distinct, refresh never revives expired authority.
- **Protocol evolution** (§18): authenticated negotiation with bound transcripts, no re-encoding to weaker schemas, envelope/request verification separated, floor handling independent of negotiation, stale capability records unable to weaken verification.

## Consistency checks on the round-9 disposition

The three accepted corrections (tunnel/push-submission credential custody under the dedicated transport account, on-disk replacement as activation, admission-boundary resubmission rules) are correctly integrated and introduce no contradiction with §3 custody rules, §6 crash semantics, or §8 caller-lifetime handling. No unresolved scenario found in their reasoning.

## Items checked and not found to be defects

- Idle interval, retention duration, biometric-invalidation policy, and Access/FCM/provider selections are explicitly deferred preferences or feasibility gates with defined evidence and consultation paths — per instructions and §1, not findings.
- Phone-initiated update scheduling without biometrics is a stated, narrowly-scoped policy decision bound to already-verified releases; it does not widen the decision key into target actions.
- Signed-feed support contingent on a supporting Sparkle release retains EdDSA archive verification as the core control; acceptable as written.
- Relay/tunnel compromise is bounded to delay/drop and metadata; end-to-end payload encryption and authority-signed requests are preserved on both LAN and relay paths.

## Remaining verification limits (implementation-stage, not plan defects)

This review cannot validate: actual AX stability of 1Password/Little Snitch dialogs, Secure Enclave/Keystore behavior across OS versions, descriptor-based execution feasibility, XPC code-requirement API behavior on macOS 14+, Sparkle staging-boundary behavior, real-device Doze/FCM latency, or sudoers-policy integration. These are all assigned to feasibility gates with explicit failure/consultation paths, which is the correct disposition for a plan.

## Conclusion

**NO SUBSTANTIVE FINDINGS**

Assessed: custody and purpose separation of all key classes, atomic consumption and crash/unknown handling, relay and push trust boundaries, presence routing invariants, audit/timing semantics, privileged update anti-rollback and activation quiescence, and protocol downgrade/replay resistance, including all revision-6–16 additions and their cross-section interactions. Remaining risk lives in the scheduled feasibility gates and real-device validation, which the plan correctly treats as evidence obligations with user-consultation fallbacks rather than assumed guarantees.