# Round 7 review — GLM pass (sections 1–7, 17)

**Input:** revision 13 excerpts as provided. Checked independently against the binding UX constraints and the round-6 disposition.

## Prior-disposition verification

All four round-6 corrections are present in the current text:

- Root-code/registration/staging placement protection with attack tests (§3, "Authenticate local process boundaries") and the protected-placement invariant referenced by §17.
- Update drain, restart matrix, and Unknown-on-lost-acknowledgment semantics (§17 matrix; §6 crash handling); root restart cancels unconsumed memory-only requests; consumed requests are never redispatched.
- Mixed-phone version selection is delegated to §18 (out of this pass's scope; §6's reference is consistent).
- Last-phone revocation keeps requests pending only when a local approval surface is actually implemented; native dialogs keep their own behavior (§5).

## Checks performed

- **Biometric policy consistency:** §1 table, §5 ("session rule or timed rule is reusable and requires biometrics"), and §6 ("Both verifiers enforce scope") agree exactly with the binding UX: one biometric for commands/1Password/credential release/enrollment and every reusable-rule change (including Deny Forever and temporary rules); no biometric for deny-once, allow-once, target cancel, and Remozio-level dismiss. §7's one-biometric credential gate is correctly framed as a spike with a consultation path, not a second-biometric design.
- **Narrow decision key:** purpose-bound, enrolled per Mac/account tuple, verified end to end by both verifiers, barred from rule changes/commands/1Password/credentials/enrollment; revocation removes both keys; consumption is serialized with revocation. The "allow-once exception" sentence bounds that decision to the captured request and does not conflict with the §1 table, which §6 explicitly makes binding on both verifiers.
- **State machine and races:** single-use signatures, decision consumption persisted before the side effect, first-valid-decision-wins at the Mac ledger with reconciliation, stale results for late approvals, Unknown terminal and no automatic retry, permit invalidation with user-initiated Refresh only. Internally consistent across §6 and §17.
- **Key custody and boundaries:** transport keys separate from authority; pre-login fallback restricted to transport-only keys; credential/authority keys excluded from the fallback; adapter keys non-exportable and code-signing restricted; relay sees metadata only under E2E encryption; live audit-token validation per privileged XPC request.
- **Updates:** drain-before-replacement, no forced cancellation of active commands, security-floor visibility, no rollback below the floor, no resurrection of consumed requests via migration, Sparkle signature verification before extraction, no unsigned fallback.
- **Expiry, encoding, display:** monotonic-clock expiry on the Mac, distinct "Request too large" result, no truncation anywhere, digest recomputation on Android and at each acting authority.

## Near-misses considered and cleared

- "The allow-once exception" phrasing in §6 could be read narrowly, but §6 defers explicitly to the §1 table, so no implementable contradiction or UX regression exists.
- Environment capture is implied by §6's limit derivation and log prohibitions; §1's "full command details" requirement plus the no-truncation rule covers display, and detail-rendering specifics belong to the other passes.
- "Changed LaunchAgent registration" in §3 refers to the credential-receiving GUI adapter, which is distinct from the LaunchDaemon transport; the identity binding prevents either from being substituted.

No correction in this scope would improve security without violating the binding UX, and none of the UX-binding behaviors is contradicted anywhere in the reviewed text.

**NO SUBSTANTIVE FINDINGS**