# Code Review — Remozio Section 19, Revision 35 Scope reviewed: interrupted-install outcome handling, evidence lifecycle, later package observations, same-session subsequent installs, self-update. Three findings. --- ## Finding 1: No reconciliation path for operations orphaned by Mac-side failure **References:** REVIEW-BUNDLE.md lines 1674, 1676 Every outcome-classification path requires the Mac command to survive until it observes the result: > "If the response is lost, interrupted, or times out, close the operation as **outcome unknown** and write that status durably to the metadata-only audit" (1676) If the Mac command process crashes, is killed, or the Mac sleeps/reboots/powers off mid-install, the pre-install record (operation ID, package ID, expected signing identity, version, artifact digest) is left in an implicit third state: never acknowledged, never closed as unknown, and no durable unknown status is ever written to the audit. The later-observation rules (1678: "show the observed state and the earlier unknown outcome side by side") key off an *unknown* outcome, so they do not apply to an orphaned open operation either — a subsequent install to the same package would have no classified historical outcome to display or protect. The self-update teardown rule (1678) covers only phone-side termination, not Mac-side death. The bundle needs a reconciliation rule: on command startup or next session, any stored operation lacking a terminal outcome must be closed as **outcome unknown** and written durably to the audit before any new install proceeds. --- ## Finding 2: Unconditional "mark unknown at teardown" can reclassify an already-acknowledged self-update **References:** REVIEW-BUNDLE.md lines 1676, 1678 Line 1678 states unconditionally: > "Updating the Remozio app that hosts this bridge terminates its own foreground service and connection… Mark that install unknown at teardown." But teardown is not ordered relative to response delivery. The phone-side process is killed when Android replaces the package, and the ADB install success response travels back through the same relay the dying process carries. Depending on timing, the Mac may receive the "completed, authenticated ADB install success response" and close the operation as **acknowledged** (1676) *before* the teardown signal arrives. An unconditional teardown marking would then overwrite a terminal acknowledged outcome — contradicting 1676's terminal-state semantics and the bundle's own core principle that no later event changes a historical command outcome (1676, 1702). If teardown wins the race instead, unknown is correct. The plan should state an ordering rule (e.g., the first recorded terminal outcome wins; teardown only closes operations still open) rather than mandating unknown at teardown regardless of prior acknowledgment. --- ## Finding 3: Same-session subsequent deploys bypass a prompt model that the deferred admission policy may require **References:** REVIEW-BUNDLE.md lines 1678, 1692 Line 1678 hard-codes: > "A user-requested subsequent deploy can proceed without another approval prompt" while line 1692 explicitly defers the admission policy: > "either require a phone confirmation for each Mac request, or permit unattended starts while Ready mode is active… Neither policy is assumed by this plan; select and test one before implementation." These interact badly. If the selected policy is per-request phone confirmation and "each Mac request" encompasses install requests (not just session starts), then 1678's blanket exemption for subsequent deploys contradicts it. The phrase "another approval prompt" also presupposes a first-install prompt, yet the plan elsewhere insists ADB operations never involve Remozio approvals (1672, 1674), leaving unspecified which prompt, if any, gates the *first* deploy in a session. The interaction between the not-yet-selected admission policy and the same-session subsequent-install exemption must be resolved before the exemption can be implemented as written. --- ## Areas found clean - **Evidence lifecycle** (1676): bounded count/period retention, durable unknown status with package/operation identifiers after expiry, and the explicit "do not imply that later verification remains possible" are internally consistent and covered by acceptance tests (1702). - **Later package observations** (1678): independent re-read before each same-package install including within a session, side-by-side display, refusal to treat version/signing match as artifact-equality proof, "current state, not which command produced it," and the unavailable-verification disclosure are sound. - **Retry discipline** (1678): new operation ID per deploy, never resolving the earlier operation, never auto-retrying an unknown command, and no automatic downgrade/retry advice on divergent or externally changed state are correctly specified.