The formal workflow has never run, and my count of the converter keys was wrong in both directions

[gHashTag]

Three things, and the first is that the gate I added yesterday has still never run

1. formal-yosys.yml has never executed. Not once.

Yesterday I found the harness self-check sitting in a job that never installs
Zig, and fixed that. The fix was to a workflow that does not run at all:

default branch:                 master
formal-yosys.yml on origin/master:   ABSENT
triggers:                       pull_request/push, branches: [master]
gh api .../actions/workflows:   not known to Actions

A workflow absent from the default branch, whose only triggers name a branch it
is not on, cannot fire. GitHub has no record of it ever running. The missing Zig
was the second reason it could not work.

Auditing all 26 workflows in the tree, 2 are absent from master:
formal-yosys.yml and formal-mutation.yml — both the formal ones, both
unknown to Actions, neither ever run. The other 24 are on master.

The branch holding them is 1213 commits ahead of master, so opening a PR to
land them is not a call I should make unilaterally. Flagging rather than doing.

2. My own count of the converter keys was wrong, in both directions

Published yesterday: "union: and cases: carry nested maps per case, which
the flat field grammar cannot express." Measured structurally across all 366
ancestors — classifying each bullet as bare / tag: Type / nested map:

key	blocks	bare	payload	nested map
enum:	31	162	0	0
variants:	43	204	12	0
union:	2	0	15	0
cases:	2	10	0	0

There is not one nested map anywhere. cases: is the same bare-name list as
enum: under a third spelling. union: is a tagged union, which the emitter
has supported since the union(enum) work.

And a shape-count of union: reports 6 blocks / 27 pairs, which is what I
would have published had I not dumped the blocks verbatim first. Four of those
blocks are a function named union in tri_bitset.tri and
tri_disjoint_set.tri — union: at indent 2 with params:/returns: — and
12 of the 27 "payloads" are its parameters (- a:, - b:, - allocator:).
The original "2 blocks" was right; my correction to 6 was the error.

This is the fourth time in this loop that a count has been the reach of a
query rather than a count of a thing. The new twist is that the collision was
a homonym: same key, different section.

3. The fix has no routed input, so it is proved by test or not at all

get_route is a hardcoded table. 206 of 366 ancestors have no entry, and
every skip is the same message. Of the 38 files carrying a variant key at type
level, 13 are routed; the 25 unrouted ones include both union: blocks
(dashboard_agent.tri) and the only file whose variants: carry payload types
(tracer.tri).

So on the real corpus the payload branch emits zero union(enum)
declarations — a green conversion says nothing about it. Five unit tests now
exercise the shapes directly, and one of them immediately caught a hole: a
quoted right-hand side was stripped of its quotes, so - status: "OK" read as
the type OK and would have emitted status : OK as a union payload.

Regression check

Built HEAD's converter and mine, converted the whole ancestor tree with each,
diffed:

files:  HEAD 215   mine 215   new 0   lost 0
routed files whose output CHANGED: 1

The one change is an improvement to something already broken —
exit_codes.t27 emitted - success : 0, with the YAML dash glued to the field
name. Now success : 0. Still not valid Zig, but wrong in one way instead of
two.

Also: the self-check leaks a cache directory per run

harness_selfcheck.py sets ZIG_*_CACHE_DIR to /tmp/t27_selfcheck_<key> and
never removes it. Nine directories, ~45 MB each. Disk went under the working
floor twice this session and this was part of it.

[gHashTag]

The buffer that claims 1024 bytes needed three language features, and two of them fail silently

message_buffer_create was left red on purpose: it reported whatever capacity
it was asked for and backed it with .data = "". The honest signature takes an
allocator and returns an error union. Writing that revealed three emitter gaps,
and the two worst produce wrong Zig that looks deliberate.

1. !T on a return type is parsed and thrown away

// parse_fn_decl
let has_error_union = self.current.kind == TokenKind::Bang;
if has_error_union {
    self.advance(); // consume !
}

has_error_union is never read again. The ! is consumed and discarded, so

pub fn message_buffer_create(allocator: std.mem.Allocator, capacity: usize) !MessageBuffer

emits

pub fn message_buffer_create(allocator: std.mem.Allocator, capacity: usize) MessageBuffer

The signature compiles. Every try inside it then fails somewhere else with a
type mismatch, and nothing points back at the dropped token. The spec said
fallible, the Zig said infallible.

No spec in the corpus returns an error union today, which is why this survived:
the construct was unreachable, not unwritten.

2. defer is parsed as an identifier, and the meaning inverts

defer is not a TokenKind, so it lexes as an Ident and the expression
parser takes it as the entire statement:

const buf = try message_buffer_create(std.testing.allocator, 1024);
@"defer";
message_buffer_destroy(std.testing.allocator, buf);

The guarded call became a separate statement that runs immediately instead of
at scope exit. A defer free(x) would free x before its first use. Only the
stray @"defer"; makes it visible at all — remove that one line and you have
silently reordered code.

This is not hypothetical and not confined to the spec I was editing:
specs/api/c_api_contract.t27 generates 16 occurrences of @"defer", i.e.
16 places where cleanup that was written to run at scope exit runs at once.

3. The unused-parameter discard fires on a parameter that is used

pub fn message_buffer_destroy(allocator: std.mem.Allocator, buf: MessageBuffer) void {
    _ = allocator;
    allocator.free(buf.data);
}

error: pointless discard of function parameter — the exact error the discard
exists to prevent. mentions_identifier tests exact string equality, and
allocator.alloc is not equal to allocator, so a parameter used as a
receiver reads as unused.

Fixed by matching the head up to ., [ or (. A substring search would have
been wrong: a string literal keeps its quotes in value, so "allocator" must
not count, and it does not.

What this cost to find

The build that was supposed to prove all three reported exit code 0 with an
empty log, because it was cargo build … | grep … | head and the shell
reports the last stage's status. The build had failed with three type errors;
head exited 0. I read the previous binary's output and was one step from
reporting that three compiler fixes had no effect, when they had never been
compiled. Checking the artefact's mtime against the source is one command.

[gHashTag]

Measured per spec, and the comparison script's first answer was a lie of omission

e3cf57569. Both binaries, same corpus, compared spec by spec rather than
by totals:

specs                520 both sides, no set difference
total ast-check err  594 -> 586
valid                295 -> 296
valid LOST             0
MORE errors in         0 specs
FEWER errors in        2   lsp/protocol.t27 6->0, jit/jit.t27 6->4

No spec got worse. That is the claim a total cannot support: -8 is equally
consistent with four specs improving and four regressing.

The valid count is honest rather than flattering

protocol.t27 was already ast-check-valid before any of this work — a
failing test is a fact about execution, not about syntax, and zig ast-check
never runs anything. Editing the spec to the honest signature broke it under
HEAD's compiler (that is the 594), and the emitter fix restored it. Net valid:
unchanged.

The gain that matters is invisible to ast-check: 33 tests now run and pass
where one of them could not pass at all. check_one_spec.py is the instrument
that sees it; the corpus scan is not.

jit/jit.t27 dropping 6 → 4 was not aimed at — a side effect of the
receiver-aware mentions_identifier.

And the measurement itself failed first

The comparison script printed:

specs: before 0, after 0
valid LOST:   0
MORE errors in 0 specs

Every number zero, every number meaningless: the scan's --json is a dict
keyed by spec path, and my indexer expected a list of records, so it read
nothing. Zeros across the board looked exactly like a clean result. "Did not
measure" and "measured zero" print identically, and only one of them is
evidence.

The JSONs were already on disk, so redoing it cost nothing — which is the
argument for writing the raw output to a file before summarising it, rather
than summarising in the same pass.

Recorded

.claude/skills/measure-corpus/SKILL.md — which instrument answers which
question about this corpus (parse < import < run), and every trap that has
produced a wrong published number here: the pattern that defines its own scope,
basename matching, string-typed JSON counts, the cache that grades deleted
code, and the gate that cannot run.