carlos / platform Public
- P1 — Rollback can leave the rejected process running. §2.2 adds failures where the unit remains active—for example, readiness never succeeds. The existing rollback restores the symlink and invokes
start(adopt.go:1194);systemctl startexplicitly does nothing to an already-running unit (agent.go:3208). Consequently, the rejected binary keeps running, the rollback settle check fails, and the refusal prevents recovery attempts. Require rollback to replace a still-running rejected process before checking the restored build.
- P1 — Shared-unit adoption can reject a healthy console indefinitely. §2.2 assumes the first host’s restart runs the new build. Adoption processes hosts alphabetically (registry.go:800), moves only that host’s link, then restarts (adopt.go:1045, adopt.go:1101). If
ExecStartuses a later host’s link, the restart runs the old build; D1 rejects it and poisons the later host before its link moves. This exact binding problem is already documented in the console design §4c. Require either verifiedUnit/ExecStartbinding or adoption and rollback coordinated across the shared unit before removing the script’s final restart.
- P1 — D3 can certify bytes that never ran. §4.3 takes SHA256 from the staged manifest and checks only the executable’s directory. Version-name reuse after pruning is supported (release.go:632). An older binary can remain staged without its manifest; backfill then fetches the reused version’s new manifest without checking the existing binary (adopt.go:1402). The mint conditions can therefore sign proof for new bytes while the old bytes are running. Existing staged binaries also bypass download verification (adopt.go:1317). Require verified agreement between the proof digest and the actual running/staged artifact, including cache hits and manifest backfills.
- P2 — The pre-restart
NRestartsbaseline rejects healthy restarts. §2.2 requires the counter to remain unchanged acrosstry-restart. Systemd resets this counter on a manual stop/start; seeservice_enter_dead,service_start, andservice_stopin systemd’s implementation. A healthy unit with a previous automatic restart can move fromNRestarts=1to0, which the proposed rule declares failed. Conversely, a new automatic restart could return it to the old baseline. Track restarts within the new invocation rather than comparing against the previous invocation’s counter.
- P2 — “At most once per build” can lose the proof trigger. §4.3 promises minting shortly after the bake period through a single relay request. The existing relay explicitly loses changes made while
carlos-stage.serviceis running (agent.go:1207). If that pass does not mint the proof, or its proof write fails, the agent never asks again for that build; minting falls back to the hourly pass. Require bounded retries until proof publication is observed, or an acknowledged pending request.
- P2 — Editing host.env does not update the running agent’s proof policy. §4.5’s break-glass procedure and §6’s rollout only change the file. The agent receives it through
EnvironmentFileat process start (carlos-edge.service:18); newly launched root passes receive the new values (carlos-stage.service:30). After removal, the existing agent can continue rejecting unproven builds before requesting root, delaying break glass until the hourly pass. After enabling proving, it will not know to request minting. Specify how configuration changes reach both processes and how break glass triggers immediate adoption.
- P2 — An intentional program change prevents rollback to the previous program. §3.2 checks
program_changeonly on the incoming manifest. After an authorized A→B main-package change, promoting the old A release back fails because A’s immutable manifest lacks that flag. D3’s healthy-history exception in §4.5 does not bypass D2. Define the rollback behavior for previously accepted program identities so recovery does not require shipping another release.
- P2 — The rollout requires a proof before configuring its producer. §6 step 3 rolls the console using the new recipe, but that recipe refuses flagship shipping without a dev proof (§5.2). Dev’s proving key and configuration are not installed until step 4. Reorder bootstrap so the first required proof exists before invoking the flagship recipe.
- P2 — The prescribed D2 rehearsal explicitly disables D2. §6 step 5 ships the CLI with
--program-changeand expects adoption to refuse it. §3.1 records that override, and §3.2 explicitly honors it. Following the rehearsal therefore permits the wrong binary to reach restart and tests D1 instead. Exercise adoption’s D2 refusal with a mismatched artifact whose manifest has no override.
Verdict: reject.