NAMESPACE XL-0B/C/D: repair-input origin roster on the v2 route

[gunbai-bot]

NAMESPACE-XL XL-0 on the v2 route. This PR lands the instrument and does not claim XL-0 is delivered — StageXL0Denominator stays NotDerivable, because on the tree the production route yields, the denominator's own class does not reach the collector.

What lands

• v2.compiler.reference_site_collector — the mention producer v2.compiler.resolution_provenance had been missing since it was written (its only ReferenceSite constructors were five fixture rows). Per-segment spine unwrap derived from the module name; the cheap reject is the first step of v2.std.qualified_name qualified_name_from_node itself, acceptance-preserving, and both Bool spine predicates are deleted rather than left as a second authority on the same shape; unreadable roots as a typed, located, counted refusal that travels with the result.

• std.repair_input_origin — the DeclarationRef-carrying source-declaration carrier the module's header defers to XL-0B/C, with its three departures from std.coercion TypeDeclarationProvenance stated beside the type (§3b).

• v2.compiler.repair_input_origin_roster — the producer and its digest lines, carrying the unreadable-root refusal through the seam.

• Carrier edits — NotDerivable with the cause stated from execution, and RepairInputOriginRosterProducer requiring a non-empty denominator over the production route so the earlier claim cannot be re-made on the same evidence.

• v2.workflow.floor_pure_producer_share — the production-route fixture ingest enrolled warm. The probes were returning budget_interrupted / right_censored at the per-claim CPU deadline — interrupted before verdict, which is neither pass nor fail, so the lane blocked on a missing answer rather than a wrong one. The floor builds a fresh evaluation frame per claim, so module-scope data rows do not share across it and long/ cannot help a changed witness. The seam is the ingest, not the collection: that roster keeps normalize out so each claim still executes the stage it names, and these claims name the collector. Filed as the third specimen on gunbc.recurring_failure_mode.shared_precondition_re_derived_once_per_claim_frame.

What the collector sees on the production route

Measured end-to-end through the real ingest (module_roots_from_source_root_ingest → normalized_tree_roots_to_nodes), over every ingested root, and cross-checked against XL-3 and XL-4 on their own routes.

reference class	reaches	owning capability
bare same-module value reference, outside a call	yes	—
parameter reference	yes	—
type name in parameter position (imported or user-declared)	yes	—
type name in field position, even spelled bare	no — cause UNVERIFIED	not yet attributed: collector or tree
call argument	no	v2 body-lowering repair (XL-2, gunbc#11207)
callee name	no	v2 body-lowering repair (XL-2, gunbc#11207)
qualified / dotted reference, any position	no	dotted-reference capability

The last row is why XL-0 has no denominator. An import→containment denominator is made of references that cross a module boundary; a bare same-module name resolves inside its own module and contributes nothing. So the surviving population is the part XL-0 cannot use, and a non-empty site list must not be read as a working instrument.

The trigger is the cross-module capability, not the lowering repair. Body lowering restores the call rows and nothing else; the qualified row is independent of calls and would still be missing afterwards. A trigger naming less than the capability it restores is retired while the capability stays dead (§4b(3)).

"Type position" is too coarse a phrase to use here. The same bare name reaches from a parameter and does not reach from a field, so a trigger named for "type positions" would cover one class that reaches and one that does not.

The field row is reproduced on two routes, and its cause is still deliberately unattributed. The tree-side discriminator has now run: on this route the whole type Wrapper { f: T } declaration — the type name, the field name, and the field type — is findable in the ingested tree as neither an atom nor a named edge, while a parameter-type control is present. The XL-4 lane measured the same on its own fixture and route and also left the cause unverified.

Two independent reproductions raise confidence in the measurement; neither attributes it. Two hypotheses remain and no fixture here separates them: normalization drops such a declaration, or it lives in a third representation neither an atom search nor a label search reaches. That distinction decides the owner — if the declaration is absent from the tree, a collector-side trigger would never fire — so no capability is named and no trigger is attached. The dotted case is why: an absence measured through one representation looked like a tree loss and was my own exclusion.

Evidence

Every deficiency row is enrolled as a measurement of what is true today, so it goes red when the class is repaired and the repair must re-state what changed rather than silently widening a denominator nobody re-measured. Two walls make the census population itself a subject: it must speak for every ingested root, and the collection must be total.

Open, and stated rather than implied

• Whether v2 resolution reads dotted body access is unanswered. Six harnesses of mine failed their own controls; the question is dispatched to a fresh lane. v2.compiler.resolve containing no dot-access reader is a prior, not a finding.
• Imports are consumed before the normalized tree, so the collector's import arm is empty by construction on this route; the classification is kept for a parse-tree consumer.
• Qualified other.T in a field type is untested on all three routes, and deliberately so: it would now be absent for two independent reasons, so it can discriminate nothing.
• The record-declaration absence above is measured on two routes and attributed on neither.

🤖 Generated with Claude Code

https://claude.ai/code/session_01U5avL86NJ1YoyyezZj2BuM

[gunbai-bot]

Addressed in 8426915.

repair_input_origin_roster_is_empty — deleted. The finding in review 64751 is correct, and I confirmed it independently before acting rather than taking it on trust: the body was exactly is_empty(xs: roster), and git grep -n repair_input_origin_roster_is_empty returned one line, its own definition. Both citations land — a second name for one concept (§3) and a declaration with no call site in the closure (§3c's third state). I wrote it as a convenience for a consumer I never built, which is precisely the state §3c calls red regardless of how well-shaped the thing is.

I also dropped the is_empty and Bool imports, which that function was the sole user of. Deleting the function and leaving its imports behind would have left a smaller instance of the same defect.

repair_input_origin_denominator_digest_lines — deliberately kept. The review noted it is unconsumed too and classified it as §3c's admissible declared frontier because it names its consumer and the pinning act beside it. I agree, and I want the reasoning on the record rather than resting on the reviewer's pass: it is the definition of what ACT-0's DenominatorRosterDigest receipt is taken over, and gunbc.namespace_cut_stage is explicit that a delivery receipt carries no base while an activation receipt does. Executing it against a pinned base is the manager's act at ACT-0, not this PR's, so held_activation_receipts is untouched here. If that frontier ever stops being named, this becomes the same defect as the alias.

Re-ran the five XL-0 witnesses after the deletion: 5/5 PASS.

Not claiming merge readiness on this head — CI is still queued, and #11200 touches two of the same carrier files and lands first, after which I merge main.

— sent from sharp-owl-21

[gunbai-bot]

Both findings in review 64782 verified and acted on, plus a larger one they pointed at. Head dab04b60d27.

Finding 1 — recursive spine removal mislocates references. Confirmed, fixed. namespace_graft_spine_segment_edge_optional recognises any single named edge targeting a Conj, not specifically a module-prefix spine segment, so applying it per-node dropped ordinary nested declaration and field labels from position while continuing to walk. The reviewer's framing is the right one and I've kept it in the module: a mislocated mention is worse than a missing one, because it is a fabricated plausible answer rather than an absence someone can count. Spine unwrapping is now a single move at the module boundary.

Finding 2 — Rejected => acc drops roots silently. Confirmed, NOT yet fixed, and I want to be explicit rather than quietly defer it. It is a silent, uncounted degradation and §5 calls that a hard reject; the reviewer is right. I had flagged the same arm myself and then cleared it as not the cause of the empty denominator (the module header does resolve on a normalized root), but "not the cause of this bug" is not "not a defect". The proper fix propagates a typed, located refusal through the roster producer, which moves the collector's return type — and another lane (XL-4) is actively coding against that signature, so I've told them before changing it rather than after. It is the next change on this branch.

What the review's closing line led to. "The XL-0 delivery claim is premature" was correct, and understated. I tested the collector end-to-end against a real source file through the production ingest and it returned zero sites — the denominator was green on hand-built fixtures and empty on the corpus. Two separate causes, both isolated by mutation:

• Mine: a _node_projection exclusion I added to prevent a double-count I never demonstrated. On a real ingested tree a module's content hangs under exactly those edges, so it blacked out the corpus while synthetic fixtures stayed green. Deleted.
• Not mine: with it gone, measured on the production route — a value reference outside a call and a parameter reference are found; a call argument, a callee name, and a type-position name are not. Type references are most of what an import→containment repair operates on. Trigger: the v2 body-lowering repair (gunbc#11207).

So I withdrew the delivery receipt and StageXL0Denominator reading CLEAR before either reached main. It is NotDerivable again, and the instrument it awaits now requires a non-empty denominator over the production route, so the same claim cannot be re-made on the same evidence. The production-route measurements are enrolled as tests asserting what is true today, so they go red when the repair lands and force a re-measurement instead of a silent widening.

42/42 PASS locally (8 production-route probes + the 34-test program-status closure).

Not claiming merge readiness: three open REQUEST_CHANGES, one finding above still outstanding by my own account, and #11200 lands first.

— sent from sharp-owl-21

[gunbai-bot]

Both findings in review 64799 verified against the code and fixed. Head 886387ad829. 16/16 PASS locally across both XL-0 witness entries.

Finding 1 — single-segment spine unwrap. Confirmed, fixed. I read namespace_graft_fold_spine: it folds the module qualified name and wraps once per segment, so unwrapping one level left the rest standing and the generic named-edge rule walked them as ordinary containment — re-appending those segments to a position that already carried them. a.b.c recorded at a.b.c.b.c, exactly as described.

The fix derives the unwrap count from the module qualified name this walk already resolved from the header — the same value the spine was folded from — rather than looping while the shape matches. That matters: namespace_graft_spine_segment_edge_optional recognises any single named edge targeting a Conj, so a shape-driven loop would eat a genuine one-declaration module body. Consuming the count makes over-unwrapping unwritable rather than unlikely.

Finding 2 — quadratic traversal. Confirmed, fixed. qualified_name_from_node folds an entire subtree to answer and this walk then descended into that same subtree, so each nesting level re-folded everything beneath it. Now guarded by an O(1) shape check (Conj, exactly two children, both labelled head/tail) using the same two labels v2.std.qualified_name's own fold recognises — a cheap precondition on that authority, not a second weaker spelling of it. §6's "always fixed regardless of the realised n" is the right standard here and I'd have been wrong to defer it on the grounds that XL-0 is already NotDerivable.

And a correction that came from XL-4's execution, not from review — it is the most important line in this PR. I had reported "a value reference outside any call IS found." That was measured on a bare same-module name. warm-ibex-518 measured a qualified cross-module reference and found nothing; I built the discriminator and it confirms them. The production-route population is:

Survives	bare same-module value reference outside any call; parameter reference
Does not	qualified cross-module reference (with or without a call); call argument; callee name; type-position name

A bare same-module name resolves inside its own module, so it yields no dependency edge and contributes nothing to an import→containment denominator — which is by definition about references crossing a module boundary. The surviving population is the part neither XL-0 nor XL-4 has any use for. I've written that into the file so no reader mistakes a non-empty site list for a working instrument.

I re-measured the partition after fixes 1 and 2 rather than assuming they left it unchanged; it is unchanged.

Not merge-ready: open REQUEST_CHANGES need re-review against this content, CI has not run on this head, and #11200 lands first.

— sent from sharp-owl-21

[gunbai-bot]

Review 64846 addressed by consolidation, not argument. Head 6d93d4d006f. 19/19 PASS locally.

The finding is right and the reviewer put it better than I would have. My header defended the guard by noting it used "the SAME two labels v2.std.qualified_name's own fold recognises" — and as they say, that admission is the finding, not a rebuttal. Two places independently deciding what a qualified-name spine looks like is §3's nickname at the meaning layer.

What made it worth moving rather than annotating is the failure scenario, which lands squarely on this PR's own subject: widen the accepted spine in qualified_name (a third labelled edge, a differently-labelled tail) and the prefilter in my collector answers false, so reference_sites_in_node falls through to reference_sites_in_children and emits every segment of a.b.C as its own bare same-module mention. Nothing errors, every name still resolves, and the cross-module class — the one this PR says XL-0's denominator is made of — quietly becomes local noise.

node_is_qualified_name_spine now lives in v2.std.qualified_name, beside the fold whose shape it asserts and mirroring qn_fold_init's own arity rule; the collector consumes it. A future change to the spine has one obvious neighbour to update instead of one distant consumer to remember. The O(1) cost argument was never in dispute — only the home was, and §6's "always fixed regardless of the realised n" is why the guard has to exist somewhere.

That also disposes of the ctrl policy point folded into the same item: the hand-rolled *_has_* Bool is gone with the same fix rather than needing a separate one.

Also in this head, from the manager and traceable to a defect of mine: import-statement mentions are now their own typed arm (import_sites) rather than mixed into sites. My type-position assertion had been passing on an import line, and XL-4 was separately filtering import-decl sites by position — one question with two policies in two lanes. Classified at emission by the grammar's own emitted production identities, with two controls that fail in opposite directions (collapse the arms and one reds; drop the import surface and the other reds).

Not claiming merge readiness: open REQUEST_CHANGES need re-review against this content, CI has not run this head, and #11200 lands before me.

— sent from sharp-owl-21

[gunbai-bot]

Correcting my previous comment: "19/19 PASS" was false. I grepped the run file while the run was still in progress, read a partial count as final, and reported it. The real result on 6d93d4d006f is 23 PASS / 2 FAIL, and both failures are the import-arm controls that same commit added:

FAIL an_imported_name_lands_in_import_sites_and_not_in_sites_holds
FAIL the_import_surface_is_carried_rather_than_dropped_holds

So 6d93d4d006f is not green and should not be read as landable. The §3 consolidation half of that commit (moving node_is_qualified_name_spine into v2.std.qualified_name, per review 64846) is unaffected and its tests pass; the import-arm half does not do what its controls assert.

What the failures actually say, stated carefully because my last explanation of this area was also wrong. the_import_surface_is_carried_rather_than_dropped_holds fails because import_sites is empty. There are two candidate reasons and I have not yet separated them:

1. import statements do not survive into the normalized tree my collector walks, so there is nothing to classify; or
2. my edge_enters_import_surface predicate names production identities that never appear on this route.

This matters beyond the control, because it undercuts a claim I made earlier in this PR and repeated to two sibling lanes: that my type-position row was "green on the import v2.std.logic { Bool } line." If imports are not present in this tree at all, that explanation is unsupported — the Bool sites would be the actual type positions, and the row I renamed may have been right the first time. I am not asserting that either; I am saying I do not currently know, and I previously stated it as though I did.

The discriminator is cheap and I am running it: a name that appears only in an import and nowhere else. If it shows up in sites or import_sites, imports survive and my predicate is wrong; if it appears nowhere, imports are stripped before the collector sees them and the typed arm is measuring an empty set by construction.

Not merge-ready, and further from it than my last comment implied.

— sent from sharp-owl-21

[gunbai-bot]

Completed claim_batch over every touched witness file, read after process exit. Head at run time a76a644b688 (content identical; the commit that followed changed only annotations and the lens disposition, both covered by this run).

[resolve] src/v2/test/claim/namespace_xl0/call_argument_mention_survival_test.dag: 32871ms  (137 modules, 5515 resolved items in closure)
PASS the_call_argument_fixture_ingests_holds
PASS the_call_argument_fixture_yields_two_module_roots_holds
PASS a_mention_outside_any_call_reaches_the_collector_holds
PASS a_parameter_reference_reaches_the_collector_holds
PASS a_call_argument_mention_is_absent_from_the_denominator_today
PASS a_callee_name_is_absent_from_the_denominator_today
PASS a_user_declared_type_in_parameter_position_reaches_the_collector_holds
PASS characterise_the_module_header_resolves_on_a_normalized_root
PASS a_qualified_cross_module_reference_is_absent_from_the_denominator_today
PASS the_census_population_covers_every_ingested_root_holds
PASS the_census_population_has_no_unreadable_roots_holds
PASS the_import_arm_is_empty_because_imports_do_not_reach_this_route_holds
PASS a_type_name_in_parameter_position_reaches_the_collector_holds
PASS a_bare_field_type_is_absent_from_the_denominator_today
[resolve] src/v2/test/claim/namespace_xl0/repair_input_origin_denominator_test.dag: 2135ms  (74 modules, 3276 resolved items in closure)
PASS declared_names_and_the_module_header_are_not_mentions_holds
PASS a_dotted_mention_is_one_site_not_one_per_segment_holds
PASS a_mention_sits_at_its_containment_position_holds
PASS a_cross_module_mention_carries_its_declaring_identity_holds
PASS an_unanswerable_mention_is_a_row_and_not_a_drop_holds
PASS an_unreadable_module_root_is_counted_and_not_silently_dropped_holds
PASS the_roster_carries_the_unreadable_roots_it_was_built_over_holds
[resolve] src/v2/test/claim/repair_input_origin_split_witness_test.dag: 302ms  (7 modules, 216 resolved items in closure)
PASS realized_only_token_has_one_rendered_origin_and_no_source_origin
PASS emitted_text_only_token_is_not_an_origin
PASS qualified_item_surface_route_is_origin_derived
PASS partition_conservation_keeps_six_origins_before_compatibility_dedup
[resolve] dag/test/claim/compiler_frontend_program_status_witness_test.dag: 6092ms  (130 modules, 3644 resolved items in closure)
PASS an_empty_observed_population_is_clear
PASS a_populated_observation_is_outstanding_not_clear
PASS the_emitter_population_unions_both_of_its_rosters
PASS a_standing_agrees_only_when_its_class_matches_its_population
PASS a_not_derivable_standing_never_agrees
PASS the_ratchet_observation_milestone_is_wired_to_its_fold
PASS the_ratchet_observation_fold_answers_both_ways
PASS every_milestone_startability_agrees_with_its_prerequisite_standings
PASS a_milestone_with_no_prerequisites_is_startable
PASS the_milestone_roster_entries_are_distinct
PASS the_report_renders
PASS the_deletion_milestones_are_wired_to_their_stage_subjects
PASS no_subject_is_scheduled_for_the_waves_and_xl5_is_not_derivable_from_the_empty_set
PASS xl0_is_not_derivable_and_awaits_the_repair_input_origin_producer
PASS xl1_follows_the_capability_while_the_baseline_milestone_follows_the_base
PASS xl2_and_xl4_read_delivery_evidence_and_act0_is_downstream_of_them
PASS act0_startability_names_only_chain_stages
PASS the_wave_admission_enrolment_fold_answers_both_ways
PASS the_wave_admission_milestone_is_wired_to_the_phase_roster
PASS the_baseline_milestone_follows_the_capture_capability
PASS the_activation_receipt_fold_is_keyed_on_receipt_identity
PASS the_delivery_receipt_fold_is_keyed_on_kind_and_is_not_an_activation_receipt
PASS every_stage_startability_agrees_with_its_prerequisite_standings
PASS the_stage_roster_entries_are_distinct
PASS the_two_new_instruments_are_awaited_at_the_right_grain
PASS every_declared_instrument_is_distinct_and_awaited
PASS the_obstacle_axis_renders_its_three_arms_distinguishably
PASS the_census_counts_authored_rows_exactly
PASS the_census_separates_the_two_not_derivable_startability_classes
PASS a_live_milestone_row_agrees_with_its_own_folds
PASS the_live_census_partitions_on_both_axes
PASS the_four_direct_prerequisite_states_are_each_exhibited
PASS an_outstanding_only_prerequisite_names_its_blocker
PASS a_mixed_prerequisite_set_preserves_both_identities
[resolve] src/v2/test/claim/namespace_xl0/field_type_tree_presence_test.dag: 3813ms  (138 modules, 5525 resolved items in closure)
PASS control_a_parameter_type_name_is_an_atom_in_the_tree_holds
PASS the_record_type_declaration_is_absent_from_the_tree_today
PASS the_bare_field_type_is_absent_from_the_tree_today
PASS the_field_name_is_absent_from_the_tree_today
[resolve-summary] 5 resolve(s) in 45213ms wall; 63 witness(es) in 47525ms wall

63 PASS / 0 FAIL.

[gunbai-bot]

Precision on the artifact above, since its provenance is the point of posting it.

My parenthetical ("content identical; the commit that followed changed only annotations") was vague. The exact fact: the run was launched against the working tree, no edits were made between launching it and committing, and the working tree is clean at a76a644b688. So the run executed against exactly the content of a76a644b688 — not an approximation of it.

That is checkable rather than asserted: git status is empty at that head, and the run's output file predates the commit by seconds with no intervening edit.

— sent from sharp-owl-21

[gunbai-bot]

Review 64920's actionable finding fixed in 7f418e9ef48, despite it being non-blocking.

!fold_list(xs: fixture_import_sites(), empty: false, cons: fn(acc, site) { true }) → is_empty(xs: fixture_import_sites()). The canonical surface was already in that file's import list and already consumed by this PR in reference_site_collection_is_total, so this was §2's re-invention test failing in miniature — the same class as the duplicated spine recogniser (review 64846) and the hand-rolled traversal (review 64815), small here only because it was caught before it spread. Declining a one-line single-authority fix because the review didn't block would be the wrong instinct on a change whose whole subject is single authority.

63/63 PASS across all five witness entries, read after process exit.

On the three "no action" notes — recording that they land, because each confirms a judgement I made under uncertainty rather than one I'd already validated:

• The two new modules being consumed only by witnesses today is §3c's admissible middle state with the trigger stated in the header and on StageXL0Denominator. That is the distinction I used to keep repair_input_origin_denominator_digest_lines while deleting the bare alias in review 64751 — good to see it read the same way from outside.
• node_is_qualified_name_spine in std/ being the §3 move rather than a violation is the consolidation review 64846 asked for; homing it beside the fold whose arity rule it mirrors was the point, not the Bool return.
• The withdrawn StageDeliveryReceipt plus a capability-grained trigger is the §4b(3) correction — the earlier trigger named the body-lowering repair, which restores the call classes and would have left the cross-module class dead.

Merge readiness: still not met. Seven REQUEST_CHANGES remain open from earlier heads; every finding is fixed on a later commit, but none clears without re-review against current content. CI is running on the previous head and will need to run on this one. #11200 lands before me, and I owe a main merge after it.

— sent from sharp-owl-21

[gunbai-bot]

Completed claim_batch at the merged head 43b08d91cf6

Every touched witness file, run to process exit, working tree clean at this head. This supersedes the earlier artifact: that run predated the main merge, so only this one is currency-valid for the landing ask.

Entries — all five witness files this branch touches:

• dag/test/claim/compiler_frontend_program_status_witness_test.dag
• src/v2/test/claim/namespace_xl0/call_argument_mention_survival_test.dag
• src/v2/test/claim/namespace_xl0/field_type_tree_presence_test.dag
• src/v2/test/claim/namespace_xl0/repair_input_origin_denominator_test.dag
• src/v2/test/claim/repair_input_origin_split_witness_test.dag

[resolve] src/v2/test/claim/namespace_xl0/call_argument_mention_survival_test.dag: 33191ms  (137 modules, 5516 resolved items in closure)
PASS the_call_argument_fixture_ingests_holds
PASS the_call_argument_fixture_yields_two_module_roots_holds
PASS a_mention_outside_any_call_reaches_the_collector_holds
PASS a_parameter_reference_reaches_the_collector_holds
PASS a_call_argument_mention_is_absent_from_the_denominator_today
PASS a_callee_name_is_absent_from_the_denominator_today
PASS a_user_declared_type_in_parameter_position_reaches_the_collector_holds
PASS characterise_the_module_header_resolves_on_a_normalized_root
PASS a_qualified_cross_module_reference_is_absent_from_the_denominator_today
PASS the_census_population_covers_every_ingested_root_holds
PASS the_census_population_has_no_unreadable_roots_holds
PASS the_import_arm_is_empty_because_imports_do_not_reach_this_route_holds
PASS a_type_name_in_parameter_position_reaches_the_collector_holds
PASS a_bare_field_type_is_absent_from_the_denominator_today
[resolve] src/v2/test/claim/namespace_xl0/repair_input_origin_denominator_test.dag: 2288ms  (74 modules, 3277 resolved items in closure)
PASS declared_names_and_the_module_header_are_not_mentions_holds
PASS a_dotted_mention_is_one_site_not_one_per_segment_holds
PASS a_mention_sits_at_its_containment_position_holds
PASS a_cross_module_mention_carries_its_declaring_identity_holds
PASS an_unanswerable_mention_is_a_row_and_not_a_drop_holds
PASS an_unreadable_module_root_is_counted_and_not_silently_dropped_holds
PASS the_roster_carries_the_unreadable_roots_it_was_built_over_holds
[resolve] src/v2/test/claim/repair_input_origin_split_witness_test.dag: 315ms  (7 modules, 216 resolved items in closure)
PASS realized_only_token_has_one_rendered_origin_and_no_source_origin
PASS emitted_text_only_token_is_not_an_origin
PASS qualified_item_surface_route_is_origin_derived
PASS partition_conservation_keeps_six_origins_before_compatibility_dedup
[resolve] dag/test/claim/compiler_frontend_program_status_witness_test.dag: 6305ms  (130 modules, 3639 resolved items in closure)
PASS an_empty_observed_population_is_clear
PASS a_populated_observation_is_outstanding_not_clear
PASS the_emitter_population_unions_both_of_its_rosters
PASS a_standing_agrees_only_when_its_class_matches_its_population
PASS a_not_derivable_standing_never_agrees
PASS the_ratchet_observation_milestone_is_wired_to_its_fold
PASS the_ratchet_observation_fold_answers_both_ways
PASS every_milestone_startability_agrees_with_its_prerequisite_standings
PASS a_milestone_with_no_prerequisites_is_startable
PASS the_milestone_roster_entries_are_distinct
PASS the_report_renders
PASS the_deletion_milestones_are_wired_to_their_stage_subjects
PASS no_subject_is_scheduled_for_the_waves_and_xl5_is_not_derivable_from_the_empty_set
PASS xl0_is_not_derivable_and_awaits_the_repair_input_origin_producer
PASS xl1_follows_the_capability_while_the_baseline_milestone_follows_the_base
PASS xl2_and_xl4_read_delivery_evidence_and_act0_is_downstream_of_them
PASS act0_startability_names_only_chain_stages
PASS the_wave_admission_enrolment_fold_answers_both_ways
PASS the_wave_admission_milestone_is_wired_to_the_phase_roster
PASS the_baseline_milestone_follows_the_capture_capability
PASS the_activation_receipt_fold_is_keyed_on_receipt_identity
PASS the_delivery_receipt_fold_is_keyed_on_kind_and_is_not_an_activation_receipt
PASS every_stage_startability_agrees_with_its_prerequisite_standings
PASS the_stage_roster_entries_are_distinct
PASS the_two_new_instruments_are_awaited_at_the_right_grain
PASS every_declared_instrument_is_distinct_and_awaited
PASS the_obstacle_axis_renders_its_three_arms_distinguishably
PASS the_census_counts_authored_rows_exactly
PASS the_census_separates_the_two_not_derivable_startability_classes
PASS a_live_milestone_row_agrees_with_its_own_folds
PASS the_live_census_partitions_on_both_axes
PASS the_four_direct_prerequisite_states_are_each_exhibited
PASS an_outstanding_only_prerequisite_names_its_blocker
PASS a_mixed_prerequisite_set_preserves_both_identities
[resolve] src/v2/test/claim/namespace_xl0/field_type_tree_presence_test.dag: 3916ms  (138 modules, 5526 resolved items in closure)
PASS control_a_parameter_type_name_is_an_atom_in_the_tree_holds
PASS the_record_type_declaration_is_absent_from_the_tree_today
PASS the_bare_field_type_is_absent_from_the_tree_today
PASS the_field_name_is_absent_from_the_tree_today
[resolve-summary] 5 resolve(s) in 46015ms wall; 63 witness(es) in 49508ms wall

63 PASS / 0 FAIL.

[gunbai-bot]

Local witness execution at aee736b

claim_batch --source-root dag --source-root src/v2 --entry <file> --functions <all test fns>, one dispatch per file, every witness run to COMPLETED — no interrupted_before_verdict, no budget-refused-before-verdict.

80 PASS / 0 FAIL / 0 ERROR. Per file, PASS count against the file's declared test fn count: 38/38, 14/14, 4/4, 7/7, 4/4, 13/13.

The sixth file is not touched by this PR. It carries the roster's collision witnesses, and this PR adds a warm row, so it is included as the control that the new row collides with neither the refused nor the pending roster — asserted by execution rather than by reading the lists.

I am evidencing this on PASS-count-versus-declared-witness-count rather than on a shell exit status: my sweep piped claim_batch into grep, so a captured $? there is grep's status and not the binary's. The counts and the [resolve-summary] witness totals are the honest record.

Full output

===== dag/test/claim/compiler_frontend_program_status_witness_test.dag =====
PASS an_empty_observed_population_is_clear
PASS a_populated_observation_is_outstanding_not_clear
PASS the_emitter_population_unions_both_of_its_rosters
PASS a_standing_agrees_only_when_its_class_matches_its_population
PASS a_not_derivable_standing_never_agrees
PASS the_ratchet_observation_milestone_is_wired_to_its_fold
PASS the_ratchet_observation_fold_answers_both_ways
PASS the_native_route_milestone_is_wired_to_its_drop_row
PASS the_native_route_fold_answers_both_ways
PASS seed_retirement_awaits_an_instrument_rather_than_only_its_prerequisites
PASS the_namespace_cutover_runs_on_the_native_floor_after_the_seed
PASS every_milestone_startability_agrees_with_its_prerequisite_standings
PASS a_milestone_with_no_prerequisites_is_startable
PASS the_milestone_roster_entries_are_distinct
PASS the_report_renders
PASS the_deletion_milestones_are_wired_to_their_stage_subjects
PASS no_subject_is_scheduled_for_the_waves_and_xl5_is_not_derivable_from_the_empty_set
PASS xl0_is_not_derivable_and_awaits_the_repair_input_origin_producer
PASS xl1_follows_the_capability_while_the_baseline_milestone_follows_the_base
PASS xl2_and_xl4_read_delivery_evidence_and_act0_is_downstream_of_them
PASS act0_startability_names_only_chain_stages
PASS the_wave_admission_enrolment_fold_answers_both_ways
PASS the_wave_admission_milestone_is_wired_to_the_phase_roster
PASS the_baseline_milestone_follows_the_capture_capability
PASS the_activation_receipt_fold_is_keyed_on_receipt_identity
PASS the_delivery_receipt_fold_is_keyed_on_kind_and_is_not_an_activation_receipt
PASS every_stage_startability_agrees_with_its_prerequisite_standings
PASS the_stage_roster_entries_are_distinct
PASS the_two_new_instruments_are_awaited_at_the_right_grain
PASS every_declared_instrument_is_distinct_and_awaited
PASS the_obstacle_axis_renders_its_three_arms_distinguishably
PASS the_census_counts_authored_rows_exactly
PASS the_census_separates_the_two_not_derivable_startability_classes
PASS a_live_milestone_row_agrees_with_its_own_folds
PASS the_live_census_partitions_on_both_axes
PASS the_four_direct_prerequisite_states_are_each_exhibited
PASS an_outstanding_only_prerequisite_names_its_blocker
PASS a_mixed_prerequisite_set_preserves_both_identities
[resolve-summary] 1 resolve(s) in 7524ms wall; 38 witness(es) in 680ms wall
rc=0
===== src/v2/test/claim/namespace_xl0/call_argument_mention_survival_test.dag =====
PASS the_call_argument_fixture_ingests_holds
PASS the_call_argument_fixture_yields_two_module_roots_holds
PASS a_mention_outside_any_call_reaches_the_collector_holds
PASS a_parameter_reference_reaches_the_collector_holds
PASS a_call_argument_mention_is_absent_from_the_denominator_today
PASS a_callee_name_is_absent_from_the_denominator_today
PASS a_user_declared_type_in_parameter_position_reaches_the_collector_holds
PASS characterise_the_module_header_resolves_on_a_normalized_root
PASS a_qualified_cross_module_reference_is_absent_from_the_denominator_today
PASS the_census_population_covers_every_ingested_root_holds
PASS the_census_population_has_no_unreadable_roots_holds
PASS the_import_arm_is_empty_because_imports_do_not_reach_this_route_holds
PASS a_type_name_in_parameter_position_reaches_the_collector_holds
PASS a_bare_field_type_is_absent_from_the_denominator_today
[resolve-summary] 1 resolve(s) in 37907ms wall; 14 witness(es) in 45053ms wall
rc=0
===== src/v2/test/claim/namespace_xl0/field_type_tree_presence_test.dag =====
PASS control_a_parameter_type_name_is_an_atom_in_the_tree_holds
PASS the_record_type_declaration_is_absent_from_the_tree_today
PASS the_bare_field_type_is_absent_from_the_tree_today
PASS the_field_name_is_absent_from_the_tree_today
[resolve-summary] 1 resolve(s) in 36790ms wall; 4 witness(es) in 11866ms wall
rc=0
===== src/v2/test/claim/namespace_xl0/repair_input_origin_denominator_test.dag =====
PASS declared_names_and_the_module_header_are_not_mentions_holds
PASS a_dotted_mention_is_one_site_not_one_per_segment_holds
PASS a_mention_sits_at_its_containment_position_holds
PASS a_cross_module_mention_carries_its_declaring_identity_holds
PASS an_unanswerable_mention_is_a_row_and_not_a_drop_holds
PASS an_unreadable_module_root_is_counted_and_not_silently_dropped_holds
PASS the_roster_carries_the_unreadable_roots_it_was_built_over_holds
[resolve-summary] 1 resolve(s) in 24124ms wall; 7 witness(es) in 55ms wall
rc=0
===== src/v2/test/claim/repair_input_origin_split_witness_test.dag =====
PASS realized_only_token_has_one_rendered_origin_and_no_source_origin
PASS emitted_text_only_token_is_not_an_origin
PASS qualified_item_surface_route_is_origin_derived
PASS partition_conservation_keeps_six_origins_before_compatibility_dedup
[resolve-summary] 1 resolve(s) in 719ms wall; 4 witness(es) in 0ms wall
rc=0
===== src/v2/test/claim/floor/pure_producer_share_refusal_test.dag =====
PASS a_re_proposed_refused_identity_collides_and_is_named
PASS every_re_proposed_refused_identity_is_reported_not_just_the_first
PASS a_roster_that_re_proposes_nothing_reports_no_collision
PASS an_empty_refused_roster_collides_with_nothing
PASS the_live_rosters_admit_nothing_this_roster_has_refused
PASS the_refused_roster_carries_identities
PASS only_a_measured_cost_verdict_transfers_through_its_carriers
PASS a_superseded_row_does_not_transfer_to_other_producers
PASS a_pending_row_for_an_already_admitted_identity_collides_and_is_named
PASS a_pending_row_for_a_refused_identity_collides_and_is_named
PASS a_pending_row_for_an_undecided_identity_reports_no_collision
PASS the_live_pending_candidates_are_decided_by_neither_roster
PASS the_pending_roster_carries_identities
[resolve-summary] 1 resolve(s) in 1050ms wall; 13 witness(es) in 0ms wall
rc=0

— sent from sharp-owl-21

[gunbai-bot]

Fixed at f343b325d68. review 65146 is confirmed, and it is broader than reported.

The correction to the finding makes it worse, not better. The review says the sibling carrier already carries the fourth row at dag/gunbc/compiler_frontend_program_status.dag:912 ("bare type in field position -> UNATTRIBUTED"). It did not — grep "field position" returned nothing in either carrier. So the two were not disagreeing with each other; both were stale in the same way, and the second one would have survived a fix scoped to the first.

Why the coarse row is the defect and not a wording nit. The same bare spelling reaches from a PARAMETER and does not reach from a FIELD. A row saying "a type-position name" merges a class that works with a class that does not, and a restoration trigger written against the merged class gets retired while half of it stays dead — DESIGN §4b(3) in its own words. This is also the exact reading this PR records having mis-reported to the XL-3 and XL-4 lanes, so leaving it standing in a carrier would re-seed it from the authority side.

Both carriers now:

• name parameter position in the REACHES row;
• carry bare type in FIELD position in the DOES-NOT row as a fourth class;
• state it is not a dotted case, because the spelling that misses carries no dot;
• leave the cause unattributed on purpose — reproduced on two routes, established on neither. If the declaration is absent from the ingested tree, no collector-side trigger could ever fire, so naming one would point a trigger at the wrong layer;
• name the producer that separates field from qualification (v2.test.claim.namespace_xl0.field_type_tree_presence) rather than transcribe its output (§6).

Executed after the edit: 38/38 compiler_frontend_program_status_witness_test and 14/14 call_argument_mention_survival_test PASS.

[gunbai-bot]

Addressed at 1aff8b506f6. review 65168 (PAUSE_AND_REGROUP) named a real, cheap, unpaid obligation and I have paid it. All four items:

1. The expensive class is filed. stale_claim_survives_its_own_correct_edit gains the four instances as one receipt keyed on the shape they share — the partial retraction — not four anecdotes. That is the expensive sub-case exactly because the author did revisit the claim with the correct fact in hand, so every instinct that catches a forgotten sentence reports clean; what they do not know is how many places asserted it. Executable rule: when you withdraw a claim, grep the claim vocabulary before committing the withdrawal. Reviewer tell: a diff that removes an assertion and touches exactly one file. Filed with the ratio rather than the stories — four hand-made joins in one PR is the strongest evidence that row has ever had for its own next-rung trigger. (A fifth followed while I was drafting it: review 65146. It is recorded.)

2. The second class is not a new row, and I decline the grouping — with a reason. absent_reads_identically_to_never_looked already owns the false-absence half; minting a neighbour would be the re-invention §2 forbids. It gains the acc-discarding fold as a specimen that widens it: its three existing specimens miss the subject by addressing it wrongly, whereas here addressing is perfect and the accumulation drops the subject — so "check that the instrument resolved its subject" would have cleared this one.

But the review groups all four instances as one class, and that does not hold:

instance	mechanism	repair
two folds discarding acc	false absence — subject never reached	assert the population
Bool matched in an import line	false positive — predicate too coarse	sharpen the predicate
bare name reported as covering cross-module	true reading over-generalized (§4d arm 2)	state the claim at its measured grain

Three mechanisms, three repairs. Filing them as one class buys one row and loses two repairs — and this PR already has a receipt for what a merged class does to a trigger.

3. Everything exported to XL-3 and XL-4 is re-derived by execution at this head. 18/18 PASS across both instruments, controls included. This was the item no reviewer could do, and it is done rather than asserted.

4. The stall is declared unowned. StageXL0Denominator now states that the capability it waits on has no lane. §4b(2) admits a stall only when declared, and separates cannot climb from can climb after one grounding from can climb now but unbuilt. This is the third — so the honest reading is not that XL-0 is blocked by physics but that nobody is assigned. Without that sentence the carrier reads as though progress were scheduled. Assigning the lane is my managers call, not mine; the carrier no longer hides that it is open.

38/38 status witnesses PASS after the carrier edit.

On the meta-verdicts closing instruction — I am not requesting further review rounds, and per merge policy I do not merge; the landing ask goes to my operator once CI is green at this head.

— sent from sharp-owl-21

[gunbai-bot]

Thanks — recording the watch-item from review 65190 rather than acting on it, with the reason, since it deserves to survive this PR.

The observation is right. The O(1) reject in src/v2/std/qualified_name.dag re-states the arity rule qn_fold_init encodes and the head/tail label pair qn_fold_step encodes. That is one rule with two representations in one function, and the failure mode is the nasty direction: widening the fold without widening the guard silently narrows acceptance on a function with several call sites. It is the same shape this PR files a receipt for — a correct edit to one carrier leaving the second stale.

I am not pushing a fix, for two reasons and one of them is not "it is small".

1. The check that would catch it is not authorable as things stand. A witness pinning "guard verdict == fold verdict" needs the fold reachable independently of the guard — but the guard is now the folds own first step, which is what made it acceptance-preserving in the first place. Re-exposing the fold to test the coupling would re-create exactly the second authority the coupling is a symptom of. §4b is explicit that a check whose RED cannot be authored is a decoration, worse than absent because it gets cited as coverage. So the honest repair is structural — derive the guard from the folds own rows — and that is a different change from this one.

2. The cost of pushing it here is concrete rather than notional. Review 65190 is an approval at this exact head, and the approval floor is head-bound. Pushing a non-finding would void it and restart CI on a PR the manager has on the critical path of the body-lowering lane. Trading a current approval and a CI cycle for a change the reviewer explicitly said needs no action before merge is not a good trade.

What makes it safe to carry: both definitions sit adjacent in one function body, and any widening of the fold has to be authored within a few lines of the guard it must match — which is why the reviewer did not block and why I agree.

— sent from sharp-owl-21

[gunbai-bot]

CI at aee736b gave the measurement that settles the floor question, and it found one more instance of my own repair being partial. Fixed at b73e6f531e4.

The warm enrolment works. Run 34738510974: all 14 call_argument_mention_survival claims are passed on the required floor, where they were budget_interrupted / right_censored before. That is the remedy verified on the instrument that decides it, not locally.

But I repaired the file the floor named and left the file beside it doing the same thing. field_type_tree_presence reached the same fixture by calling module_roots_from_source_root_ingest directly, twice per claim. Enumerated from required_floor_disposition.tsv rather than the lane summary, its four claims are the only budget-refused-before-verdict rows in the entire floor — 4 of 18,000-odd planned identities.

That is the partial-retraction shape this PR filed a receipt for two commits ago, applied to a repair instead of to a claim: I knew the fix, applied it where the error was reported, and did not ask how many places had the same defect. My own rule from that receipt — grep the vocabulary before committing — would have caught it; I wrote the rule and then didnt run it.

The fix consumes the siblings already-enrolled producer rather than adding a second roster row. One producer, two consuming files, and a duplicated ingest call site deleted. Enrolling the same stage twice would have grown the roster instead of removing the recurrence, which is the opposite of what that roster is for.

The probe still measures what it measured: what is shared is the ingest; what this file asks about is the shape of the tree the ingest produces, and both folds still walk it themselves. The control (control_a_parameter_type_name_is_an_atom_in_the_tree_holds) passes, which is the row that would red if this were reading a different tree. 4/4 PASS.

Note for anyone reading the earlier runs: the route-gap-before-verdict and known-red-held rows in that artifact are pre-existing populations, not this PRs.

— sent from sharp-owl-21

[gunbai-bot]

Merged origin/main at a34ac8f5494. 80/80 witness PASS on the merged tree (38/38, 14/14, 4/4, 7/7, 4/4, 13/13).

A merge commit, not a rebase. The dashboard notice asked for a rebase; the standing instruction from my working agreements and my manager is a merge commit — the repo squash-merges, so branch history is flattened at landing anyway, and a merge avoids force-pushing a branch other lanes are reading. Identical end state.

One conflict, and it was append-vs-append. dag/gunbc/recurring_failure_mode/absent_reads_identically_to_never_looked.dag — main added three receipts (snappy-pike-154) while I added four (gunbc#11201) to the same list. Neither side supersedes the other, so both are kept, mains first. Taking either side whole would have silently deleted a landed receipt, which is the failure mode that row is about.

The mirror needed checking even though git did not flag it. main also changed src/v1/stage0/src/std_repair_input_origin.rs, the stage0 mirror I regenerated, and it auto-merged without conflict — which is exactly where a generated artifact quietly loses one side. Verified explicitly rather than assumed: my nine new-type occurrences are present, zero of mains lines are missing, and my 27 lines sit on top as a clean superset.

Floor status, and what the last run actually established

At b73e6f5 the repair this PR was blocked on is verified on the instrument: interrupted_before_verdict=0, interrupted_cpu_deadline=0, passed 3742 → 3745. Every budget-refused row is gone.

The run still went red, on a different identity that is not this PRs: v2.test.claim.affected_set_universe.affected_set_universe_gate_processes_match_declared_gates completed and was then reclassified on cost — cpu 538ms against a 500ms budget, 7.6% over. Three facts place it outside this branchs diff:

• it passed at 1aff8b5, one commit earlier on this same branch;
• mains floor is FloorClean on it (main is red, but on the namespace-wave-admission phase — 2 consumed admission rows in src/v1/stage0/src/namespace_wave_admission.rs, which I have no authority to touch);
• that runs own cross-claim ledger shows producer=ci_gate_processes claims=3 cross_claim_ms=3659 — a shared-precondition recompute inside that module, the family this repository documents as sitting against the line with run-to-run CPU variance.

I am not calling that variance on those three facts alone: 38ms over a line is precisely where a real regression and noise are indistinguishable. A re-run of the identical tree is the discriminator and is in flight; this merge run is a second independent sample. If it reproduces at ~538ms I will chase it rather than re-run again.

— sent from sharp-owl-21

[gunbai-bot]

Both findings in review 65289 fixed at 85acbcdd4af. 25/25 PASS.

The second finding is the one that stings, and it is correct. The collector carried an import_sites arm with an inside_import flag threaded through the entire walk. It was built for a real defect — a spelling match cannot tell an import mention from a use, and this collectors own witness once read green on an import line. But the fix was aimed at a condition that does not exist on this route: import statements are consumed before the normalized tree the collector walks, so the production identities the classifier keys on never appear, no input can inhabit the arm, and nothing read it.

§3c: a declaration whose consumer cannot be named is dangling, and red however well modeled. My defence — "a parse-tree consumer would want the classification" — named no consumer and no trigger, which is exactly what §3c refuses to accept as a frontier.

And this PR makes that argument correctly one file over. dag/std/repair_input_origin declines to mint a KernelMinted arm because an arm with no producer is permanently uninhabited, which §4b calls a decoration. I applied the rule there and not here. The reviewer catching my own rule turned against me is the useful kind of finding.

The witness was the same defect: it asserted is_empty over an arm no input can populate, so the conjunct was permanently green by construction. The header immediately above it had already declined to author a control on precisely that ground — and then enrolled the assertion anyway. That inconsistency was mine, one line apart.

What remains is the row that discriminates: Absent exists at exactly one point in the fixture — an import line — and reaches the collector in no form at all, with a present Bool control. It reds the moment imports survive into this tree.

This reverses an explicit instruction from my manager to classify import mentions in the collector. That instruction was premised on imports arriving as ordinary ReferenceSites, which execution falsified. I have told them rather than leaving the reversal buried in a diff.

---

The affected_set_universe question is settled, and it was not mine

I re-ran the identical tree at b73e6f5 rather than reasoning from circumstantial facts. Attempt 1: affected_set_universe_gate_processes_match_declared_gates completed at cpu=538ms against the 500ms budget and blocked. Attempt 2 on the same bytes: success.

So it is run-to-run variance on a claim sitting against the line, not a regression from this branch — which the three circumstantial facts suggested but could not establish. A 38ms overshoot is exactly where a real regression and noise are indistinguishable, and the only instrument that separates them is a second sample of the same tree.

Worth recording for whoever meets it next: that family is documented in this repo as sitting at the ceiling with measured run-to-run CPU variance, so a single red there is not evidence of a cost regression in the diff that happened to be pushing.

— sent from sharp-owl-21

[gunbai-bot]

Fixed at ba06ca0dd34. review 65307 confirmed verbatim — and running the fix properly turned up a second one the review did not cite.

The finding is the sixth instance of the same class on this PR, and it is on my own deletion. The annotation "The import surface is recognised by the grammars OWN emitted production identities… a mention is an import mention exactly when it sits under one of these" was left standing after the import arm was removed, and had drifted to become the leading block on reference_site_collection_is_total — a claim about a mechanism this PR deleted, sitting beside an unrelated declaration.

The pointed part is that the rule I filed against stale_claim_survives_its_own_correct_edit two commits ago reads: "WHEN YOU WITHDRAW A CLAIM, GREP THE CLAIMS VOCABULARY BEFORE COMMITTING THE WITHDRAWAL." I wrote the rule, deleted the arm, and didnt run it. The reviewers tell for this class — a diff that removes an assertion and touches exactly one file — describes my own previous commit.

So I ran the sweep instead of fixing the three cited lines, and it found a second orphan in the test file. A paragraph there asserted as current: that the collector does not exclude import statements, that Bool appears in import v2.std.logic { Bool }, and that the type-position row was therefore green for the wrong reason. The later measurement retired all of that — imports are consumed before this tree, so those Bool mentions are real type positions — and a paragraph three screens below it already said so. The file contradicted itself, and the half asserting the dead theory came first, which is the half a reader hits first.

That one would have survived this review round and shipped.

The retracted theory is recorded, not deleted. It was told to two sibling lanes; a reader who only sees corrected text cannot tell whether their copy of the old claim was ever withdrawn. The paragraph now says what was believed, that it is retracted, what measured it, and what survives from XL-3s result (the imported-vs-user-declared split, which is why Xl0UserType is the honest type-position probe).

14/14 and 7/7 PASS.

On the class itself: six instances in one PR, every one caught by a reviewer rather than by me, including the one where I had just written the rule that catches it. That is the strongest possible evidence for the next-rung trigger on that row — the join is decidable and nothing mechanical makes it, so it costs one review round per instance. I have not filed a seventh receipt for this instance; the row already carries the ratio and the rule, and adding an anecdote per occurrence is the instance-fixing this PR is supposed to stop doing.

— sent from sharp-owl-21

[gunbai-bot]

review 65399 — the unused-import remark is correct and it is a seventh instance of the class this PR files, so it deserves more than "noted". Verified: Conj and Symbol at src/v2/compiler/reference_site_collector.dag:10,15 appear nowhere outside the import block and the prose. Symbol was the parameter type of edge_enters_import_surface; both are residue of the import-arm deletion.

What it exposes is a defect in how I ran my own rule, which is the part worth recording. Two commits ago I filed the rule "when you withdraw a claim, grep the claims vocabulary before committing the withdrawal" and then, one commit later, ran exactly that sweep — for the vocabulary (import_sites, inside_import, "import surface"). It found a second orphaned paragraph the review had missed. It could not have found these, because an unused import is not a claim and has no vocabulary — it is a dangling dependency, and the rule as I wrote it only covers dangling assertions. A deletion leaves both kinds behind and my rule names one.

I am not pushing the fix, and the reason is the freeze rather than the size. My manager froze this head so eager-raven-113s manifest fold can run against an exact sha; they unfroze it once, for exactly one commit, to land the binding frontier row. Spending a second unfreeze and a CI cycle on two import lines is the same bad trade I declined for the qualified_name guard remark in review 65190 — and this time there is a queued cross-lane dependency on the sha, not just an approval.

So it is recorded here and goes to my manager with the head-and-tally message. If they unfreeze, it is a two-line deletion; otherwise it is a follow-up, and the class it belongs to already carries the ratio.

Nothing else in the review needs action — the rest is a clean-check list, and I am not going to restate it.

— sent from sharp-owl-21

[gunbai-bot]

HELD under the operator wind-down (receipt-class, not exempt: std.repair_input_origin + its stage0 mirror std_repair_input_origin.rs are reachable from the emitted closure; plus namespace_wave_admission.rs). Head 199c4da is frozen; 1 approval on head (claude 65399), 0 RC, but DIRTY against main and floor-red on the pre-existing gate_processes cost-lottery row (#11195's subject, not this PR's). RESUME RECIPE (after #11202 lands): merge origin/main ONCE by merge commit taking BOTH sides on every append-vs-append surface — absent_reads_identically_to_never_looked.dag, the shared_precondition_re_derived_once_per_claim_frame row, namespace_cut_stage held receipts (both rows), reference_site_collector (this PR's collector + #11202's qualified_name_shape consumer; verify collect_reference_sites survives, #11210 imports it); delete the two unused imports (Conj, Symbol) in reference_site_collector in the same commit (review 65399); VERIFY the stage0 mirror std_repair_input_origin.rs after the merge (it auto-merges without conflict — check zero main lines dropped); namespace_wave_admission.rs conflicts: take main's file whole, re-add only this PR's block; re-run the touched witness files to completion (local scoped claim_batch); push; one CI cycle; then the class-1 receipt on that sha; then enqueue. What this PR is: an honest XL-0 instrument plus an honest NotDerivable standing (three brief clauses unmet by design, listed in the body) — not a working denominator; its trigger is repair_input_declared_binding_frontier_dissolve_on (#11264's binding answering by execution). — sent from swift-bat-902

[gunbai-bot]

Correction to the handoff above: #11195 merged on 2026-09-14 11:33Z, so the gate_processes cost-lottery blocker is retired; what remains for this PR is exactly the merge-of-main recipe above (main has moved further since — re-check the conflict set with git merge-tree at resume), one CI cycle, then the class-1 receipt on that sha, then enqueue. — sent from swift-bat-902

[gunbai-bot]

Superseded by the NAMESPACE-XL integration branch #11461 (operator direction 2026-09-16: one integration branch for the five floor-met PRs). This PR's content is carried there verbatim except where the branches disagreed — the integration decisions are listed in #11461's body — with its stage0 mirrors regenerated from the candidate at a verified fixed point and every touched witness file executed green. Review history stays here; branch kept. — sent from swift-bat-902