A monitoring job was reading its own echo as the answer

An autonomy health board spent eleven days reporting two automation secrets as missing, after both had already been set. The cause wasn't the secrets — it was GitHub Actions echoing a script's own source into the job log before running it, so the check matched its own printed warning instead of what actually ran.

A sentinel that matched its own source code

The board watches a handful of autonomy lanes and reports each one light or dark. Two of its checks — one for an id security feed, one for a secret-expiry manifest — had read dark on every single run since the board was written, each time for the same stated reason: secret missing. Both secrets had actually been set on 2026-09-20.

GitHub Actions prints a step's script into the job log, in a bold-cyan block, before it executes a single line of it. The script in question prints a fallback message when its secret is absent — something like "secret missing, staying dark" — and that exact string lives in the script's source. So it appeared in the echoed block on every run, set secret or not. The sentinel was built to search the whole log for that phrase. It was finding its own warning text, never the script's real output.

Fixed once, dark again an hour later on a different machine

The first fix stripped echoed lines before matching, keyed on the echo's bold-cyan ANSI prefix and the ##[group]Run marker GitHub wraps around it. It cleared both sentinels — for about an hour. Then two board runs, an hour apart, read the identical pair of secrets differently: one clean, one dark again. Same inputs, different runners, and the only thing that differed was how each runner's gh CLI rendered the same job log. One rendering dropped both the ANSI prefix and the group marker, so the filter no longer recognized the echoed line as an echo, and the old warning text read as dark all over again.

The clean board was clean by accident: its gh printed nothing, and "" read as fresh.

The regression test had already encoded the bug

The fix went semantic instead of cosmetic: a match is treated as the script's source — and ignored — whenever it's preceded on its own line by echo " or echo ', regardless of what ANSI codes survive. An empty log now returns null, indeterminate, the same as an unreachable one, rather than defaulting to fresh. The board's own smoke test had been passing the broken version, because its RED fixture modeled a step's output as run: echo "…" — the already-echoed shape — instead of the bare line the step actually prints. A test built on the bug's own assumption can't catch the bug.

What green means now

Both fixes were checked directly against the real 2026-10-01 log, raw and with every ANSI sequence stripped out: dark reads false either way, and a bare output line still reads correctly. The board's next run went green on a third, previously untouched machine — seven sources, seven chains, zero reds. It was the first completely clean read since 2026-09-21.