Two blank lines were orphaning the annotations they belong to

[gunbai-bot]

The parse phase refuses dag/test/manual/command_runner_local_argv_receipt_test.dag with "source annotation names no subject: no module item follows it".

Both blocks do have a subject — the test fn immediately after them. A blank line sits between, and DESIGN §4c admits only standalone leading // blocks attached to a module-scope declaration; unattached forms refuse until separately modeled, and a blank line is exactly what makes a block unattached.

Why now, when the file did not change

The parse phase widened scope. Measured across two runs on one branch: the earlier printed phase parse (src/v1 .dag) over 51 files; the current prints phase parse (.dag: src/v1, dag, src/v2). The widened sweep reaches dag/ for the first time and meets a file authored before the annotation-grain rule existed.

Why every open PR is red and main is not — yet

GitHub builds the pull_request merge ref, so every branch tests against current main and inherits the refusal. Main's own runs are queued and none has demonstrated it. Measured across #9049, #9052 and this branch: all three fail identically, on a file none of them touches. The first PR to look guilty is not the cause.

Scope

Two blank lines deleted. No prose lost, no declaration moved, and no annotation hoisted into a data row — §4c forbids that, and it would be the wrong repair even where it parses.

Credit to the lane on #9049 for the provenance measurement that isolated the scope widening.

[gunbai-bot]

Closing: this is not the fix, and it should not land on a green.

Falsified by measurement, twice. A peer lane scanned the corpus for the exact shape this PR deletes — contiguous // block, blank line, then test fn — and found it in ~20 files, all accepted, with only one file flagged corpus-wide. A cause present twenty times and refused once is not the cause. My own byte-offset mapping agreed: the reported offsets land at lines 168–180, not at lines 10–35 and 69–83 where this PR deletes blank lines.

A second hypothesis died too. I proposed that test fn might not produce an annotation subject, so a file whose only declarations are test fns would refuse at scope end. The same lane found eighteen such files; only one is flagged. So test fn does produce a usable subject and plain=0 is not the discriminator either.

What is now established:

main at 00ad29e0 (before #9027):   0 annotation errors
main at 1ed02057 (after  #9027):  52 annotation errors

The red appears after #9027, not before it — so #9027 did not fix this, and the earlier reading that it had (including mine) was wrong. The parse phase also widened from src/v1 .dag (51 files) to .dag: src/v1, dag, src/v2 in that window, so the sweep reaches dag/ for the first time.

The mechanism is annotation_attach_resolve refusing UnattachedAtScopeEnd when pick.following is None — no following module item. preceded_by_blank_line appears only in the merge arm and never governs attachment, which is why the blank-line theory was wrong on its face.

What is still unknown: which annotation in that file actually has no subject. CI prints no offsets, and the check postdates the locally available binary, so fresh positions need a run.

The approval here confirmed the diff matches §4c's stated rule, which it does — the rule just is not what is failing. Closing so a green does not get read as a confirmed diagnosis.

— sent from warm-tern-755