# Round 8 — GLM scoped delivery pass (sections 1, 2, 15, 16)

Input: revision 14 excerpts as provided. Prior disposition (round 7) reviewed; its corrections (idle-before-drain, minimum-generation checks, update quiescence) live in sections outside this scope and are not contradicted here. Section 1's consultation clause correctly codifies the round-7 no-UX-regression guarantees, including the feasibility-gate carve-out.

Checks performed:

- **Biometric contract (§1)**: Table is internally consistent and matches binding UX — command/1Password/credential-release require one biometric; Little Snitch once/cancel/dismiss require none; every reusable rule (Forever, session, timed, create/change/remove) requires biometrics. "One explicit decision authorizes one captured action" and "signing only for the displayed request" are consistent with §15 first-valid-decision consumption and §2 signature semantics. Declining without a target action granting nothing is correctly non-sensitive.
- **Threat model (§2)**: Trusted-phone assumption explicitly covers non-biometric decisions; unprivileged relay cannot mint approvals; keys in root storage; signature scope (invocation, not transitive effects) is honestly bounded. Residual risks (Accessibility bypass, GUI scripting) are documented with consultation required before revoking grants.
- **Push delivery (§15)**: Token/identity binding, revocation semantics (stale pushes cannot revive authority), opaque payloads, fetch-before-present, notification ≠ consent, and delivery-health staging are mutually consistent. Request lifetime bounded by validity and known deadlines only; the 1Password estimate stays display guidance — no tension. Uncertain external actions are never retried for delivery, consistent with the round-7 posture.
- **Transport (§16)**: Discovery-is-not-identity, bounded direct-connect attempt against short 1Password windows, single request ID/expiry/consumption across parallel paths, Tunnel-as-live-proxy, Access as additional (never substitutive) gate, per-installation service credentials with no shared APK secret, and Remozio-level revocation winning over pending Access revocation are all coherent with §15. No forced browser login on the approval path; recurring renewal cost requires user consultation, so no forced re-pairing or physical access is introduced. Gateway/relay separation and Mac-authoritative validity/consumption hold across both sections.
- **Cross-section**: §2 deployment scope, §15 fetch paths, and §16 transport selection agree (LAN-then-relay, no VPN, push baseline, dedup across paths).

No correction identified that would worsen UX.

NO SUBSTANTIVE FINDINGS