# Round 10 review — sections 1, 2, 17 (revision 16)

## Round-9 correction verification (in-scope items)

- **Opus 2 (on-disk replacement as activation):** Present and coherent. "On-disk replacement of a bundle containing a running role is activation too. Defer Sparkle installation of that bundle, not merely its process relaunch" is reinforced by separate staging, the protected-placement invariant reference, and the symlink-race feasibility check.
- **Opus 3 (submissions at the update boundary):** Present and coherent. Transparent wait applies only to an authenticated, submission-bound response explicitly confirming no admission; timeout/lost/unknown results never trigger automatic resubmission; resubmission is fresh capture with a fresh decision; stdin/PTY preservation and the distinct `Update installing` status are specified. This matches the disposition's claim that nothing admitted or possibly admitted is repeated.
- **Opus 1 (cloudflared credential custody):** Resides outside the scoped sections; nothing in sections 1, 2, or 17 contradicts it ("No VPN or WARP client is required" remains accurate).

## Independent checks

- **Binding UX:** Biometric table matches the user contract exactly (allow-once/deny-once/cancel/dismiss/decline: none; every reusable rule including session/timed: biometric; Forever default preserved; no silent Once downgrade). Phone update-scheduling controls require no extra biometric and are not target-app actions, so this adds no friction and no bypass (purpose-separated, challenge-bound, one-use, scheduling-only authority). No forced physical access, re-pairing, or added confirmation dialogs; consultation gates are correctly framed as pending decisions, and the feasibility gates as planned work.
- **Boundary interactions:** Atomic quiescence check/admission close vs. racing submissions, GUI-capture rejection and post-recovery recapture, drain (`Update waiting`, retryable) vs. automatic boundary (`Update installing`, bounded transparent wait) are distinct and internally consistent. Late approvals, refresh, and late biometric results cannot revive expired authority in any path.
- **Restart/consumption matrix:** Permit-consumption boundary aligns across section 17's table, section 6's unknown-after-consumption rule, and section 9's one-attempt scope mutation. Automatic recapture after root restart is correctly limited to ledger-established never-consumed identities with fresh challenges; consumed/unknown follow evidence-or-unknown.
- **Floor mechanics:** Generation checks on every privileged RPC, OS-validated build identity, cert/receiving-key generation binding, floor commit only via the activation transaction, anti-rollback independent of the candidate binary, and the key-custody failure/consult path form a closed loop with no ordering gap.
- **Cross-section consistency:** State machine terminal branches, journal-consumption-before-dispatch, expiry/disappearance distinction (`Expired` vs. `No longer available · reason unknown` vs. observed `Resolved by target timeout` with expiry source retained), and requester-exited-before-execution as a consumed no-effect outcome do not conflict with section 17's update lifecycle.

No correction is needed; nothing identified would worsen UX.

NO SUBSTANTIVE FINDINGS