Hoist the two body-position source annotations to module-item grain

[gunbai-bot]

DESIGN §4c admits only standalone leading // blocks attached to module-scope declarations; body forms refuse until separately modeled. Two blocks on main sit inside declaration bodies, so gunbc compile emits nine hard diagnostics against main content:

file	count	position
dag/extdeps/systems/nvidia.dag	4	inside a record literal in dgx_spark_catalog_row
dag/test/claim/generated_artifact_drift_test.dag	5	inside a fold_list closure in witness_refusal_cause_tokens_are_pairwise_distinct

Why main is green while carrying them

The witness that compiles the shard does not run there. On main run 31073226645 (head e5fafd4c7, concluded success):

[wet-witness-row-outcome] batch=4
  entry=dag/test/claim/dag_compile_clean_shard_a_witness_test.dag
  function=compile_clean_shard_a_exemplar_compile_green
  outcome=selection-skipped detail=skip-before-resolve-fast-path
[witness-row-cost-migration-disclosure] … ObservationAbsent

The gate exists and is enrolled; it was skipped on the path where it mattered. It executed on an unrelated PR whose .dag diff widened selection — gunbc#7779, run 31074919969 — and failed with all nine diagnostics, none of them from that PR content. nvidia.dag is byte-identical on main and that branch.

The remedy is confirmed by execution, not assumed

Hoisting the nvidia.dag block alone took that PR from nine diagnostics to five (run 31079190892) — exactly the four it removed — with batch 1 gates, batch 2 dag_compile_clean_gate_passes, batch 3 discovery-corpus (7,329 witnesses) and batch 4 execution-corpus all green, and the residual failure naming only generated_artifact_drift_test.dag. This PR applies the identical transformation to both blocks.

What changed

Both hoists keep the rationale verbatim and name the subject the annotation had been sitting beside, because module-item grain cannot express this field or this clause. That coarsening is the trade §4c already declares, not a loss introduced here.

No semantic change: annotations are erased before every semantic pass, so semantic graph, resolution, hashes and target bytes are identical. After this, dag/ and src/v2/ carry no body-position annotation at all.

Verification

CI is the verifier — specifically compile_clean_shard_a_exemplar_compile_green in batch 4, which is the witness that fails today. I have not run the whole-tree compile locally; the installed gunbc binary predates annotation support and is the wrong instrument for this question.

🤖 Generated with Claude Code

[gunbai-bot]

Correcting the Verification section of the description: this PR's own green does not verify it.

ci concluded success on run 31082838682, and the witness this PR exists to fix did not execute:

[wet-witness-row-outcome] batch=4
  function=compile_clean_shard_a_exemplar_compile_green
  outcome=selection-skipped detail=skip-before-resolve-fast-path
[witness-row-cost-migration-disclosure] … ObservationAbsent

batch 4 bin-witness-corpus (149 witnesses) passed with that row counted as not-failed. This is the same selection-skip the PR description reports on main, reproducing on the PR that reports it — so the green is consistent with the fix working, with it not working, and with the file being deleted.

What is actually established, by execution: on gunbc#7779 run 31079190892, hoisting the nvidia.dag block alone took that PR from 9 annotation diagnostics to 5 — exactly the 4 it removed, no more and no fewer — with batches 1–3 and execution-corpus green and the residual naming only generated_artifact_drift_test.dag.

What is not established: the generated_artifact_drift_test.dag half. It is the identical transformation applied to the identical construct, which is a strong inference and not evidence.

How it gets verified: gunbc#7779's next run after this merges. That branch's .dag diff widens selection enough to execute the exemplar — it is how the defect surfaced in the first place — so it will show either 0 diagnostics (fix confirmed for both blocks) or 5 (fix wrong). I will report that result here either way.

I attempted local verification first with the release-bins artifact from this run rather than deferring; it is linked against a newer glibc than my container provides (2.36), and the only other local gunbc predates annotation support and is the wrong instrument for this question.

— sent from loyal-ant-382

[gunbai-bot]

Closing unmerged — superseded by #7918, which landed the same fix on main first.

The reported conflict is not a rebase problem; it is two independent fixes to the same lines. Verified on main at 0b0e683db2:

• dag/extdeps/systems/nvidia.dag — 0 body-position annotations
• dag/test/claim/generated_artifact_drift_test.dag — 0 body-position annotations
• corpus-wide scan of dag/ and src/v2/ — no body-position annotation remains

#7918's version is also better than this one where they differ. Its nvidia block names dgx_spark_catalog_row's IntegratedComputeSystemCatalogRow.memory and .memory_bandwidth fields; mine said only "the memory field", and both fields derive from the cited row. Its drift-test block names the exact clause including its literal (t != "HealPushRefusalPopulationEmpty") rather than "the third clause". Since module-item grain cannot say this field or this clause, naming the subject precisely in the prose is the whole craft of the hoist, and theirs does it better.

What this PR contributed independently, recorded so it is not lost with the branch:

The remedy was proven by execution here. On gunbc#7779, hoisting the nvidia block alone moved that branch from 9 annotation diagnostics to 5 (run 31079190892) — exactly the 4 it removed — and reverting it moved it back to 9 (run 31082982050). Removed and restored, symmetric, everything else on the branch identical.

Two findings that outlive this PR, both still open:

1. compile_clean_shard_a_exemplar_compile_green is on the explicit roster (bin_wet in ci_layer_roots.dag, ExecutionWitnessKind) yet reports outcome=selection-skipped detail=skip-before-resolve-fast-path on main pushes — observed on e5fafd4c7, bb4048a5f, and on this PR's own green run 31082838682. Its work is a whole-tree gunbc compile, so its true affected set is any .dag change. That is why nine hard diagnostics sat on main for a day: the gate's coverage depends on unrelated diffs widening selection. Note v2.lens.non_fold_residue's dissolution trigger already names this class ("per-PR affected-set selection runs this receipt without predict-skip (ReadsLiveTree enrollment)"), so the invariant appears aspirational rather than implemented.

2. The scheduled affected-set-falsifier — the cold control that exists to catch exactly (1) — has been RED since 2026-08-03 under open issue falsifier is RED — 9 of 9 components not Done #7737, timing out at 170 minutes and uploading no floor-component-receipt.json. Neither of these is fixed by Fix DESIGN §4c body-position source annotation violations (2 blocks) #7918.

Branch deleted. — sent from loyal-ant-382