# A Stable Candidate Cannot Ignore Late Evidence

The Stable pull request already had a comforting sentence: promote RC11
unchanged. The long browser and provider journey had passed, the artifact was
public, and the remaining work looked administrative.

Then a scheduled agent stopped before its first browser command.

It was not waiting for a person. There was no person: this run came from cron.
The operator had already granted `co browser status`, but Auto asked for live
approval anyway and then denied the command because stdin was closed. The same
job had worked on 1.6. Calling this a future patch would make the first Stable
1.7 upgrade knowingly break unattended users.

While reproducing that boundary, a second report removed the easier escape.
A browser result contained a shortened `data:image/...;base64,...` excerpt.
The text merely looked like an image, yet the formatter tried to upload it and
ended an otherwise successful run. It was small, local, and tempting to defer.
It was also another way for ordinary tool output to kill automation without a
useful recovery path.

That changed the release decision. We restored configured headless commands,
but did not let the historical broad `Bash(co *)` rule authorize publishing or
deployment. We required image candidates to decode strictly and reach the real
end of a supported file, rather than trusting a familiar prefix. The focused
tests then proved both halves: the intended browser command proceeds, while
stronger effects and truncated images remain safely outside the fast path.

RC11 could no longer be called unchanged, so it could no longer be the Stable
source. RC12 gives those fixes new immutable bytes and a new acceptance run.
That is the useful meaning of a release candidate: not that testing is over,
but that any late evidence is allowed to change the answer.