# Code Review — Remozio Section 19, Revision 34 Scope: interrupted-install outcome reconciliation logic (lines 1674, 1676, 1700). Four substantive findings. --- ## Finding 1 — Reconciliation rule set has an unmatched case for third-party rollback/reinstall of the prior version **Reference:** line 1676 (the three reconciliation branches). The branches are: 1. expected ≠ prior, current == expected → **desired package state verified** 2. current package **and** update marker == prior → **requested state not applied** + retry guidance 3. expected == prior, or current differs from both → retain **unknown** The plan stores "package state **and** update marker" as distinct items (1676: "the previously observed package state and update marker"). Consider a third-party rollback or uninstall/reinstall that restores the *same prior package version* after the interrupted operation: the current package state matches the recorded prior state, but the update marker (e.g., install/update timestamp) necessarily differs. This evidence tuple matches **no branch**: - Branch 2 fails (marker does not match prior). - Branch 3 fails ("current package differs from both" is false — it matches prior). - Branch 1 fails by construction. The outcome is undefined, contradicting the plan's own guarantee that "on any new paired ADB session, [the Mac] automatically reconcile[s] each interrupted or timed-out operation for a package before another install to that package" (1676). The only reading that closes the gap — treating the marker as part of "package state" — makes branch 2's separate "and update marker" clause redundant. Either way the specification is internally inconsistent, and the uncovered case is precisely a third-party-update scenario the section claims to handle. --- ## Finding 2 — Byte-identical reinstall: branches 2 and 3 conflict, with no defined precedence **Reference:** line 1676; acceptance requirement at line 1700 ("Cover … byte-identical reinstall"). For a byte-identical reinstall, expected state == prior state. If that reinstall was interrupted and **not applied**, the current package and marker still match the recorded prior state, so: - Branch 2 fires → **requested state not applied** with retry guidance. - Branch 3 fires ("If expected and prior states were identical … retain **operation outcome unknown**"). The same evidence produces two contradictory reports, and the plan gives no ordering or precedence between the branches. This matters because branch 2 carries retry guidance while branch 3 explicitly exists to avoid misleading advice — the conflict is not cosmetic. Additionally, when an identical reinstall **does** apply, the update marker changes (a reinstall of the same APK produces a new update timestamp). That changed marker is positive evidence of application, but branch 3 unconditionally forces permanent **unknown** for identical states, discarding the one signal that disambiguates this case — even though branch 2 already relies on marker equality as decisive evidence in the opposite direction. The marker is treated as authoritative for "not applied" but ignored for "applied." --- ## Finding 3 — Evidence persistence: bounded retention can destroy reconciliation evidence before reconciliation is possible **Reference:** line 1676 ("stores … in private, user-scoped operational state with **bounded retention**"; reconciliation only "on any new paired ADB session"; "Ready mode cannot be assumed to restart silently"; "Restoring Ready mode after a bridge-hosting app update and its recurring phone action remain a pending user decision"). Reconciliation of an interrupted operation requires (a) the stored evidence (operation ID, expected digest, prior state, update marker) and (b) a future paired ADB session to re-read on-device package state. For the self-update case — explicitly the scenario where the connection is guaranteed to drop — a future session is gated on a pending *user decision* to restore Ready mode, which may happen arbitrarily late or never. The evidence, however, is under "bounded retention." If the retention window expires before the next session: - the expected-state/prior-state/marker evidence needed for verification is gone, so no branch of the reconciliation can ever run; - the plan defines no terminal handling for expiry with unreconciled operations — it does not state whether the pending **unknown** outcome is retained, surfaced, or silently dropped with the evidence. The acceptance criteria (1700) require testing interruption and reconciliation but never test retention expiry with an outstanding unknown. Retention must be bound to reconciliation completion (or expiry-with-pending-operations behavior must be specified) for the "outcome unknown until independent verification" guarantee (1674) to hold. --- ## Finding 4 — The "requested state not applied" claim and its retry guidance rest on an undefined "update marker" **Reference:** line 1676. Branch 2's claim of **requested state not applied** — the only branch that affirmatively recommends retry — is sound only if the "update marker" changes on *every* package mutation (install, reinstall, rollback, data-preserving update). The plan never defines the marker, never states that it must be monotonic per mutation, and never establishes that it is readable via the ADB path on the supported device (contrast the explicit feasibility gates for discovery, foreground service, and Access in 1698). If the marker is weak (e.g., versionName/versionCode-derived), a third-party rollback to the prior version would falsely satisfy branch 2 and emit retry guidance that reinstalls the expected version — actively overriding an external change, the exact outcome branch 3's "must not trigger downgrade advice" guard exists to prevent. Given that both the retry claim (branch 2) and the identical-reinstall handling (Finding 2) depend entirely on marker semantics, leaving it undefined is a substantive gap, not a naming detail. --- ## Notes on what checked out clean - The "never infer install success from a dropped socket" rule and "mark that install unknown at teardown" for self-updates (1674, 1676) are consistent. - The "desired package state verified" label is correctly state-based and explicitly avoids claiming acknowledgment receipt or operation attribution (1676), so a third-party install of the expected state does not produce a false success claim. - "Never use a later install's artifact as evidence for the earlier operation" (1676) correctly handles chained interrupted operations for the same package. - The "differs from both → unknown, no downgrade advice" branch (1676) is the right conservative posture for external updates — the defects are in the seams around it (Findings 1, 2), not in the branch itself.