Zig has no empty statement -- it answers "expected statement, found ';'"
-- so a bare `;` does not add noise, it kills the whole file and every
check inside it. Measured: 491 bare `;` lines across 81 generating specs.

Two source forms reach one emitted construct, and the notice now tells
them apart. 475 are a `bench` body's prose line arriving as a CHILDLESS
StmtExpr through gen_bench_block's fallback; 16 are `defer <call>;` in a
test body, arriving WITH a child that gen_expr renders as nothing. The
parser keeps that one deliberately -- "a dropped `defer` silently removes
a release, a close or a free" -- and the emitter dropped it anyway.
475 + 16 = 491: one notice for every semicolon removed.

The remedy is the one used beside it. gen_invariant_block already writes
"NOT CHECKED -- body was not lowered (T43)", and the Verilog backend
already emits benches as comments. Zig was the only backend where a bare
`;` is fatal rather than merely useless, which is why the same emission
escapes consequence in C.

Measured per spec, both directions, zig 0.16.0, no timeouts:

    zig test --test-no-exec    165 -> 190   +25   regressions 0
    zig build-obj              282 -> 308   +26   regressions 0

+25 is exactly what an adversarial sweep attributed to this line when it
split the class -- 32 for the whole remedy, 25 for this site -- so an
independent implementation reaching 25 confirms that split.

Deletion-equivalence re-derived rather than inherited: 780 bench_*
functions are defined in the generated corpus and 0 have a call site, and
`zig test` runs only test blocks, so emptying one cannot lose an executed
check.

Four mutants. M3 and M4 SURVIVED the first run, which is the useful part.
The "a statement that lowers keeps its semicolon" test used `y = x + 1`,
which reaches StmtAssign and never touches the arm under test -- a test
of an adjacent path that happens to hold; a bare CALL statement is what
goes through StmtExpr with a non-empty rendering. And nothing asserted
the two labels differ, so labelling a statement that HAS a child as
"empty" passed.

The fixture was wrong to start with too: I invented `bench "b" { measure:
... }` from the issue's prose, it does not parse, t27c exits 1, and the
test asserted on an empty string. The real spelling is `bench NAME` with
no braces. Read the construct out of the corpus, not out of the report
about it.

Closes #2974

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

An hour of work committed cleanly and then `gh pr create` answered
"No commits between master and w801" -- the branch did not exist. HEAD
had been detached, the commit landed on no branch, and nothing in the
commit path said so.

Verified in a throwaway repository rather than assumed: `git commit` on
a detached HEAD succeeds with no warning, `git branch --show-current`
returns empty, and only `git status` says it outright. `git push -u` is
silent too; the first objection comes from a tool three steps downstream,
about the wrong subject.

One command, beside the freeze check already run before every commit:

    test -n "$(git branch --show-current)" || echo DETACHED

Recovery is `git branch -f <name> <sha>`. The commit is not lost, it is
unreferenced -- which looks identical from every command that asks about
branches and nothing like it from `git log`.

What this is NOT evidence of: three background agents were running in the
same repository, and the obvious story is that one moved my HEAD. They
did not -- `git worktree list` shows each in its own worktree. The cause
is unestablished, and 'the agents did it' would have been a cause
invented to fit a symptom, which is the failure this skill records more
often than any other.

Refs #2974

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Merging master moved one spec's generated output; `tri seals drift`
read 1 and `--fix` repaired it locally -- and the repair was never
committed. `coverage` went red on exactly that, and the neighbouring
session's PR was green, which is what said the drift was mine.

This repository's own lesson, twice recorded and broken again here: the
reseal belongs in the SAME commit as whatever moved the output, not in
a later one and certainly not only in the working tree. `git status` is
the check, and it costs one command.

Refs #2974

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>