# Code Review — Remozio Section 19, Revision 37 (changed clauses only)

Reviewed lines 1674, 1676, 1678, 1692, 1702 in `REVIEW-BUNDLE.md` against the five scoped areas. Sections 5 and 10 are referenced but not supplied, so cross-section consistency with those cannot be verified.

## Scoped mechanisms verified sound

**Serialized operation ledger (1676):** Single-writer service, check-and-insert of the open record under one exclusive transaction (no TOCTOU on "refuses a second open install"), crash windows explicitly covered (crash after `open` before dispatch → unknown via startup sweep; startup sweep runs before serving status or admitting installs), conditional close with "losing concurrent closers write nothing" gives correct CAS semantics for response/timeout/teardown races — consistent with the 1702 test list ("teardown racing a response, timeout racing a late response").

**Atomic audit events (1676):** Start event is committed in the same transaction as the open record before dispatch; terminal event in the same transaction as the terminal transition; orphan-sweep closures carry their audit event in the same transaction; terminal states are unreclassifiable, matching 1702's "No losing event, later observation, or later install may reclassify a terminal outcome."

**Retention (1676):** Open records never expire; bounded count/time retention only on post-closure detail fields; expiry cannot mutate an active operation or trigger an install; the "comparison unavailable" display path in 1678 correctly anticipates detail-field expiry while the terminal event survives.

**Later observation (1678):** Independent read on next session and before any same-package reinstall (even within a session); version/signing match correctly not treated as artifact equality; unknowns are never resolved by later deploys or auto-retried; no downgrade/retry advice on divergence — internally consistent and consistent with 1674's "never infer install success from ... later package state."

## Findings (minor; no substantive defect found)

1. **Line 1678 vs. line 1692 — admission-granularity enumeration mismatch (low).** 1678 requires the pending admission choice to "define whether confirmation applies per session or per install," enumerating only two granularities, while 1692 explicitly offers a third: "permit unattended installs while Ready mode is active." If the unattended option is selected, 1678's directive has no antecedent — there is no confirmation to scope per-session or per-install. The clauses don't contradict (1678's "apply that chosen rule to every deploy" degrades gracefully), but the scoped admission-granularity text is not self-consistent in its enumeration. Suggest 1678 acknowledge the unattended option or defer entirely to 1692's list.

2. **Line 1676 — refused admission attempts are outside the audit model (low).** The ledger writes a start audit event only for admitted operations; a refused "second open install" attempt leaves no record, even though the ledger is designated "the bridge audit source" such that no replay "can omit a start or terminal transition." A rejected concurrent-install attempt is a security-relevant event (it may indicate a racing local process — a scenario 1702 explicitly tests). If refusal auditing is intentionally out of scope, that should be stated; otherwise the claim of ledger-as-complete-audit-source is slightly overbroad.

## Otherwise clean

No substantive flaws found in the serialization invariants, transaction atomicity of start/terminal audit events, retention semantics, later-observation rules, or the per-session/per-install granularity handling as drafted. Dependencies on unsupplied sections (5 enrollment, 10 audit retention, "same-user Mac exposure described above") could not be validated.