carlos / platform Public

Addresses discussion #13 — carlos deploy reporting live over an old binary.

The root cause turned out to be narrower and more fixable than the report assumed. The platform ALREADY has the mechanism #13's first suggestion asks for: an app can declare a build probe, and the deploy watch then polls the app's own process instead of the X-Carlos-Version header. oficina/docs serving /api/version is exactly the shape it wants.

The defect is that SetAppBuildProbe had one caller — the app CLAIM door. So an app created before the flag existed could never acquire a probe, and the fix was unreachable by exactly the apps that had the bug.

• carlos apps build-probe --app <a> </path|->, and the console door behind it, registered with an empty role set (a credential that could repoint the probe could make its own deploys report success — it is in policyDoors with that reason).
• A deploy with no probe now says, while it waits, that the header reports the release adopted rather than the build running, and names the command that fixes it.
• carlos deploy --label/--notes, the smaller thing filed in the same issue.

Left for a decision rather than fixed, and it is the part I would not change unattended: adoptHost stamps Version after the restart callback returns nil, and two of the three restart arms (carlos-app@ tenants, exec children) swallow their errors on purpose — so that one tenant's failed cycle cannot poison a release for the rest of the pass. Right for the pass, wrong for the stamp. The activator's 90s convergence sweep is the only backstop, and it has two silent failure modes: a persistent symlink read error and a backend without LiveVersion both return "do not cycle" forever, with no log line. Details in the reply on #13.