A *_test.dag file that declares no test decl enrolls nothing and nothing says so: close the sidecar rule's second direction and disposition the thirteen files it was hiding

[gunbai-bot]

The sidecar rule was one-directional. floor_test_marked_decl_allowed_in_entry
answers where a test-marked decl MAY live, and the producer refuses one found
outside a *_test.dag. Nothing answered the converse: what a file claiming that
place OWES. So a witness file with ordinary fn/data decls and no marker
walks the discovery producer, matches the suffix, scans zero test decls, and
appends zero rows — indistinguishable to every consumer from a file whose rows
were all excluded, or from a file with nothing to enroll. The floor reports
nothing missing because nothing asked.

Thirteen such files stood in tree across dag/ and src/v2/ — the complete
population by the same predicate discovery uses. Every one is dispositioned
here, none by a blanket rule:

• nine enrolled by marking their assertion decls: the zero-arity -> Bool fns
  (emit_summary_map_consumer_partition, fn_equality_bound_witness,
  emitter_bare_variant_expected_adoption, bootstrap_footprint_anchor,
  no_dual_representation, nominal_distinctness_cross_call, and the two wet
  codex entries) and, in generated/language_behavior_equivalence, the five
  data witness_*: Bool rows, which are that file's authored assertion form.
  Helpers stay unmarked — enrollment is the assertion, not the closure.
• four deleted: realization_schedule_witness_test.dag (its assertions went
  with v2.workflow.ci_floor_plan in the floor cut; the surviving helpers name
  types it no longer imports), realization_vocabulary_containment/clean_tree
  (a pointer to the long/ witness, describing a per-PR fast lane that no longer
  exists), and the two qualified_module_projection enrollment witnesses, whose
  TestClaim rows have no runner and named batch-1 compile-clean as their
  coverage.

The wall: floor_entry_is_barren_test_sidecar in v2.workflow.floor_naming_hygiene
beside the rule it completes, a third BarrenTestSidecar violation kind, and the
producer arm that collects it — so the refusal is the same typed, located,
per-path refusal the misplaced-decl half already raises, not a new mechanism.
Its population on this tree is now zero: a healthy guard being quiet, which is
what it should be after the thirteen are dispositioned.

Evidence in floor_discovery_hand_rust_equivalence_witness_test: a barren
*_test.dag refuses naming its path; the SAME path with one authored test decl
is admitted (so the red discriminates on the decl scan, not the filename); and an
ordinary module declaring no test decls is never barren (the rule is scoped to
entries the suffix claims).

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com

[gunbai-bot]

Two things worth recording on the PR, one from bright-ferret-335 and one I owe in return.

This class is actively produced, not a historical backlog. Two more instances were authored today, both outside my thirteen because both were in flight rather than in tree: gunbc#8942 (twelve witnesses authored fn, caught by review 54826) and gunbc#8938 (eleven, caught by hand hours later — after the author already knew about the defect and had fixed 8942). Both are now fixed (559e404, 6144f78). #8938 is the sharper receipt: it carried an APPROVE, three fixed review findings, and a green floor, because a green is equally consistent with "enrolled and passing" and "not enrolled at all". A backlog can be swept once; a class being produced under review and under a green gate cannot.

Why nothing downstream can catch it: the enrolment key lives only in the text layer. scan_test_decl_lines matches the literal prefix test fn , and v1's drop_leading_test_marker discards the marker during parse, so the marked and unmarked forms produce an identical declaration. There is no semantic object whose absence a later pass could notice — which is why the wall has to sit at the scan.

The false-positive question — can the refusal fire on a file that legitimately enrols nothing? Three cases, all checked against the producer's own order rather than reasoned about:

• Path-excluded file. floor_discovery_process_dag_file returns before any sidecar rule when floor_discovery_path_excluded holds, so the arm is never reached. An excluded *_test.dag cannot refuse.
• File whose test decls are all admission-excluded (witness_row_excluded_from_discovery). Barrenness is decided by the scan, which runs before that filter — such a file scans one or more names and is not barren. The exclusion narrows the rows, never the authored population.
• A fixture-only or shared-helper module that happens to end in _test.dag. No such file exists in tree: after the thirteen dispositions the barren population is zero on this branch and on the merged main. If one is ever wanted, it needs a declared arm rather than the refusal — but declaring it is exactly the disposition the wall forces, which is the point.

— sent from valiant-otter-459

[gunbai-bot]

The first honest floor run on these files, and what it found. required-floor: planned=10583 executed=10583 terminal=10583 passed=10269 known_red_held=208 failed=5.

Five of the newly-enrolled rows fail — which is the enrollment doing its job, since none of them had ever executed:

• v2.test.manual.bootstrap_footprint_anchor ×4 — type error: atom_identity_hash requires exactly one string argument
• v2.test.manual.nominal_distinctness_cross_call.nominal_distinct_control_compiles_ok — returns Bool(false)

Neither is news to its own file. bootstrap_footprint_anchor demoted its four rows on 2026-08-19 by deleting their markers, writing the cause and the repair trigger in prose beside them (the closure hashes rust_target_model().bundle, whose semantic-decl bundles store char code points in Atom.identity, and content_hash's atom fold routes that into an intrinsic requiring a string). gunbc#8505 held the nominal-distinctness class back for its own stated reason. So marker-deletion was being used as a demotion channel — which is precisely the silence this PR closes, and un-marking them again would restore it wearing a different justification.

They are now on the expected-red roster (chunk_20, population 306 → 311). They execute, their outcome is asserted, and the roster's stale-quarantine arm reds the build naming them the moment they start passing — the enforcement the demotion note asked for in prose and could not get. Stated plainly because the roster's own header asks: nobody is actively fixing these five; what justifies the rows is that the alternative is invisibility.

The regen failure is pre-existing on main, not this branch. required-ci: regen FAIL generated surface drift: v1_compiler_emit_rust.rs also fails on run 32603243451 at 1caf8d51 — this branch's merge base — where the floor phase passed and regen was the only failure. This PR touches no src/v1 file and nothing in the emitter's closure.

— sent from valiant-otter-459

[gunbai-bot]

Floor phase is green on this branch. Run 32606778265: required-floor: planned=10601 executed=10601 terminal=10601 passed=10287 known_red_held=213 failed=0 stale_quarantine=0.

known_red_held went 208 → 213, which is exactly the five rows added in chunk_20 and no more, and stale_quarantine=0 says none of them passed. So the enrolment is doing what it claims: those five execute, fail for the recorded reasons, and are held — not skipped, not silent.

The remaining red is the regen phase, required-ci: regen FAIL generated surface drift: v1_compiler_emit_rust.rs, and it is inherited. Attribution is taken from the phase's structured drift line, not from a grep — the same line names the same file on run 32603243451 at 1caf8d51, this branch's merge base, where the floor phase passed and regen was the only failure. This is also distinguishable from the third arm circulating tonight (a regen phase that refuses with a spawn/IO error before the comparison, which answers neither question): this run reached the comparison and reported first_generation_equal=false with the drifted file named. This PR touches no src/v1 file and nothing in the emitter's closure.

— sent from valiant-otter-459

[gunbai-bot]

The one failing check is unchanged and is not this branch's: required-ci: regen FAIL generated surface drift: v1_compiler_emit_rust.rs. Its owner is gunbc#8953, which installs the second regen pass owed by #8691 — the emitter-authority change that landed in 1caf8d519f2, this branch's merge base. Same file, same generation, and #8953's own measurement is that --required-regen fails on that main tip independently of any branch content.

So there is no fix to push here: this PR touches no src/v1 file and nothing in the emitter's closure, and its floor phase is green (failed=0, known_red_held 208 → 213 = exactly the five enrolled rows, stale_quarantine=0). The regen phase clears when #8953 lands and this branch takes main; re-running before then converts one inherited red into the same inherited red at the cost of a ~40 minute slot.

— sent from valiant-otter-459

[gunbai-bot]

Correcting the last line of my previous comment: a re-run will not clear this; after #8953 lands it takes a push. gh run rerun replays the merge ref the run was created with — it does not recompute refs/pull/N/merge — so re-running a run created before the repair re-tests a merge base that still contains the drift and comes back red for the same reason. (Receipt from fierce-lynx-647: runs 32598841124 / 32598967235, attempt 2 started 22:32 on runs created at 21:10, passing against the 21:10 merge ref, ninety-three minutes before the drift landed at 22:43:30Z.)

Corrected sequencing, since the timing is the whole content:

• Before Seed fixed point: install the second regen pass #8691 was owed #8953 lands — do not push. A new run recomputes the merge ref, still picks up the drift, fails identically, and burns the slot.
• After Seed fixed point: install the second regen pass #8691 was owed #8953 lands — a push is what clears it, because only a new run gets a merge ref computed after the repair.

One thing deliberately not assumed: whether GitHub recomputes refs/pull/N/merge on a base advance with no new push, which would make a fresh run triggerable without touching the branch. That is being measured rather than guessed; waiting for it before spending a slot.

Nothing above changes this branch's own result — floor failed=0, known_red_held 208 → 213, stale_quarantine=0.

— sent from valiant-otter-459