carlos / platform Public

Closes discussion #16's first ask.

What was wrong

carlos secrets set --environment relay succeeds, the merged bundle is materialized to /data/<host>.config.env, carlos secrets list confirms the key, and the process on the other end goes on serving the old values until somebody restarts it by hand. Nothing in the loop says so. The reporter's symptom was an OAuth provider silently not offered, and they had the missing step written down twice in their own runbook, in bold, with "nothing will remind you" beside it.

This is the cheapest of their three asks: say it in the output. It is not a request to have CARLOS own the restart, and this does not: a TCP-addr exec route's lifecycle stays the app's. The post-delivery hook and the running-generation readback are untouched.

What it does

appconfig.AwaitingRestart answers, for one write, which of a box's routes were handed a file that nothing will bounce. It sits beside execAddrCandidate and resolves the exec_delivery opt-in through the same resolveExecDelivery that SyncExec's checkOptedIn now uses, so the notice and the sweep cannot disagree about who gets a file.

Three states, not two: hosts delivered to, hosts nothing could be determined about (their bundle would not read, or the bundle they are bound to is missing), and, at the console and CLI layer, "no claim was made" for a console that predates the field or a laptop with no registry near it. Rendering "could not tell" as "all clear" is the reported bug; reproducing it inside the fix would be a poor joke.

A default-bundle write is narrowed by the keys it touched: a bound route whose own bundle shadows every one of them resolves to a byte-identical manifest, syncExecHost writes nothing, and naming it would send someone to restart a process for a value it was never going to see.

Route.Unit is carried through because it decides the REMEDY. An addr route naming its own unit (issue #110's consoles) is the one addr shape carlos restart can cycle; for a plain one the agent's restart leg skips it and the activator has no child for it, so pointing an operator at that command would be a second silent failure answering the first.

Also the aside from the same report: secrets set stored an empty value without complaint. Values arrive as "$(op read ...)", and op read on a missing field prints nothing and exits 0, so a typo delivered two empty strings and reported success. Refused now on BOTH sides of the seal: in the CLI on the plaintext, and at the console door on the envelope's LENGTH, since AES-GCM is length-preserving and an envelope at exactly ephLen+nonceLen+16 sealed nothing. My first design claimed the door could not enforce this; a review against crypto.go showed that was wrong, and the door enforces it now because a door must not depend on its client's manners.

carlos env sync's line is corrected in passing: it promised that "exec-backed instances converge within seconds", which is true of the file and false of the program reading it for exactly the route shape this was filed about.

Notes for review

• Wire shape is additive: restart is absent from an older console and ignored by an older CLI. apiConfigApplyResult.Restart is a pointer so that "console said nothing" stays distinct from "console said none".
• accountFlagsWithRegistry exists so the five config verbs read the registry --registry actually names, not defaultRegistry(), which would answer "which routes did this reach" from the wrong box.
• SCOPE: the console reads its own box's registry, so a multi-box fleet's other boxes are not represented. Same #145 blind spot apiroutes.go documents; the output says so rather than letting a short list read as a complete one.
• All user-facing strings went through copy review; tests assert structure, never wording.
• Pre-existing test failures on this machine (TestAccountsList*, TestResolveMode*, activator exec-backend, edge listen-purge) reproduce identically on pristine HEAD.