carlos / platform Public

| Round 1 finding | Sufficient? | Why | |---|---|---| | 1. Rejected process survives rollback | Yes | §2.3 requires reset-failed followed by restart, then checks the restored executable. | | 2. Shared-unit binding rejects healthy builds | Yes | §2.2 requires the unit stamp on the ExecStart host and verifies that binding before checking the restart. | | 3. Proof certifies bytes that never ran | Yes | §4.2 hashes the running executable when minting and the actual staged file when adopting, including cache hits. | | 4. Incorrect NRestarts baseline | Yes | §2.3 checks the new invocation and its counter instead of comparing counters across the manual restart. | | 5. Lost proof trigger | Yes | §4.3 retries every two minutes until publication is observed. | | 6. Running agent retains old proof policy | No | §4.5 assumes readable host.env, but the documented setup is root-owned 0600; the agent needs an accessible policy source. | | 7. D2 prevents rollback across program changes | No | §3.2 records history only for named-unit routes; ordinary exec and carlos-app@ apps still cannot roll back across an intentional program change. | | 8. Proof required before producer configured | Yes | §6 configures dev and obtains its proof before the flagship roll. | | 9. Rehearsal bypasses D2 | No | An old client in API mode still encounters §3.1’s server-side ship check; the rehearsal must explicitly select direct-bucket shipping to reach adoption’s check. |

New findings at 8535d250:

1. P1 — Rollback can repoint unrelated, healthy instances. §2.3 requires repointing every route running the rejected version of the same app to the failing host’s cur. Those routes can belong to separate processes and follow different channels (registry.go:69). For example, one instance already runs V2 successfully while another moves V1→V2 and fails its environment-specific readiness check. The prescribed rollback also moves the healthy instance’s link to V1, without restoring its own prior state or coordinating its process. Restrict rollback to the routes sharing the affected process, and preserve each affected route’s previous state.

1. P2 — Shared-host rollback leaves incorrect version headers and permits immediate re-adoption. §2.3 claims repointing earlier hosts keeps X-Carlos-Version honest. However, PointLive changes only a symlink; earlier hosts have already received their registry stamps through SetVersions, and the edge obtains the header from that registry value. Moreover, §2.5 specifies a host-shaped refusal for the failed bound route, leaving the other hosts free to re-adopt the rejected version on the next pass. Require restoration of the affected registry stamps and refusal coverage for all hosts sharing the rolled-back process.

1. P2 — Binding fallback discards restart errors that currently trigger recovery. §2.2 says a binding mismatch performs plain try-restart and returns nil. Today, the named-unit arm returns the command’s error, which activates rollback. If try-restart fails on a mismatched binding, rev 2 would suppress recovery and stamp the deployment successful, potentially leaving the unit down. Skip only the new settle check in this fallback; preserve the existing command-error propagation.

Verdict: reject.