# Review: Remozio section 19, revision 36 changed clauses Reviewed lines 1674, 1676, 1678, 1692, 1702 of `REVIEW-BUNDLE.md` (1677 is blank). Verdict: **not clean — 6 findings** (1 high, 3 medium, 2 low), mapped to the five requested areas. No files were modified. --- ## Findings ### F1 — HIGH — Evidence retention scope can evict correctness-critical records (1676, evidence retention) `1676`: "Retain detailed operational evidence only within a bounded count and period; after expiry, keep the durable unknown status and package/operation identifiers…" The retention clause demonstrably reaches into the operational-state store, not just logs ("after expiry, keep the durable unknown status…" implies state detail is deleted while status+IDs survive). Two hazards follow: 1. **Open record expiry**: a stuck-open operation (e.g., Mac asleep mid-install) that outlives the retention *period* loses its digest/version/signing identity — or under a small bounded *count*, the record itself — before the startup orphan-close ("close any orphaned open install operation as unknown", 1676) can write a correct terminal transition and audit event. 2. **Replay degradation**: after expiry, "durable terminal state" is reduced to status + package/operation identifiers, so "replay the missing audit event from durable terminal state before admission" (1676) can only reconstruct an impoverished event — audit content becomes dependent on *when* replay fires. It is also unstated whether metadata-only audit events are themselves "detailed operational evidence" subject to the bound; if they expire, replay must regenerate them forever from state the same clause permits to expire. Fix direction: exempt open operations and unaudited terminal records from eviction; state whether audit events are retention-exempt; require replayed events to preserve original transition metadata. ### F2 — MEDIUM — Start audit event has no atomicity or replay requirement (1676, audit replay / Mac crash) `1676`: "Persist each terminal transition and its metadata-only audit event atomically or replay the missing audit event from durable terminal state before admission." The atomic-or-replay guarantee covers only *terminal* transitions. Line 1702 requires "metadata-only start/stop audit," but nothing ties the *start* audit event atomically to the pre-dispatch durable open record, nor requires replaying it from that record. A crash between dispatch and the start-audit write yields an audit stream containing a terminal unknown event with no matching start event — indistinguishable from tampering — and no clause requires reconstructing it, even though the open record (1676) holds all the metadata needed. ### F3 — MEDIUM — Late install response can textually reclassify a terminal outcome (1676/1678/1702, teardown/response race) `1676`: "A completed, authenticated ADB install response closes that operation as acknowledged success or acknowledged failure…" vs. "The first durable terminal outcome wins; later **teardown, package observations and installs** never reclassify it." Scenario: the response times out → the operation is durably closed as unknown; the authenticated response then arrives late on the still-open socket. The first sentence instructs closing "that operation" as acknowledged; the never-reclassify enumeration lists teardown, package observations, and installs — **not late responses** — in both 1676 and the 1702 mirror ("no later observation or install may reclassify"). Only the header "first durable terminal outcome wins" arguably saves it, and no serialization mechanism (single-writer/CAS on terminal transitions) is specified for the concurrent teardown-unknown vs. response-acknowledged write race. Line 1678 covers only the benign ordering ("an earlier acknowledged response remains acknowledged"). 1702 tests "teardown racing an acknowledged response" but not response-vs-timeout. Add "late response" to the non-reclassifying list and require first-writer-wins on terminal writes. ### F4 — MEDIUM — Subsequent-deploy admission conflates install admission with session admission (1678 + 1692, subsequent install admission policy) `1678`: "A user-requested subsequent deploy follows whichever phone session-admission policy is selected below" → `1692`: "either require a phone confirmation for each Mac request, or permit unattended starts while Ready mode is active…" 1692's policy governs *session* admission ("unattended **starts**"). A deploy dispatched inside an already-admitted, active session is not a session-admission event, so "follows the session-admission policy" is undefined for it: under the confirmation policy, "each Mac request" is ambiguous between per-session and per-install confirmation. Since 1678 makes this cross-reference the *sole* admission rule for subsequent deploys after an unknown outcome, the conflation is substantive, not editorial. Specify confirmation-per-session vs. confirmation-per-install. ### F5 — LOW/MEDIUM — Audit replay is admission-gated only; missing events can persist indefinitely (1676, audit replay) `1676`: "…or replay the missing audit event from durable terminal state **before admission**." Under the replay option (terminal state durable, audit write lost to a crash), the missing event is reconstructed only when the *next* install is admitted. If no further install ever runs, the audit trail stays permanently incomplete — there is no startup-time or periodic reconciliation requirement. Additionally, nothing requires the durable terminal state to retain a transition timestamp, so a replayed event may carry a fabricated one. ### F6 — LOW — Acceptance-test gaps in crash windows (1702, terminal status after Mac crash) 1702 covers "a Mac crash after dispatch" and "teardown racing an acknowledged response," but not: (a) crash in the window between receiving an authenticated response and persisting its terminal transition (must yield unknown, never acknowledged); (b) crash between the pre-dispatch durable store and actual dispatch (orphan record for a never-sent install must still close as unknown). Both are normatively covered by first-durable-wins + startup orphan-close (1676), but neither window is exercised by the stated tests. --- ## Areas confirmed sound - **Terminal status after Mac crash** (1676, 1678): pre-dispatch durable open record; acknowledged-only-when-durable; startup orphan-close before any new install; current-state observation never reclassifies — internally consistent, apart from F6's test gaps. - **Teardown ordering** (1678): "close as unknown only if it is still open; an earlier acknowledged response remains acknowledged" is correct for the covered ordering (defect is the uncovered one, F3). - **Unknown-outcome epistemics** (1674, 1678): never inferring success from dropped sockets or later package state; exact-match-proves-only-current-state; no auto downgrade/retry advice; verification-unavailable disclosure — all sound and mutually consistent. - **Priority lease / approval separation** (1674): pause-without-clear recovery and no payload leakage are coherent; 1702 tests them. **Overall: 6 findings; F1 should be resolved before implementation.**