Root T5a: derive the trait roster from how a type is used, not from its shape alone

[gunbai-bot]

Root T5a: derive the trait roster from how a type is used, not from its shape alone

The emitted derive roster was a function of shape only. A record's structure says
what it CAN derive; it cannot say what its USE demands. So a type reaching a map-key
position needed Eq + Hash that no shape classification would ever produce, and
std.trait_derive_shape could not even NAME Hash -- ReprGroundingDeriveTrait had no
member for it. The gap was structural, not an oversight in the table.

THE REQUIREMENT IS ONE ROW. map_key_required_derive_traits is Eq + Hash, grounded on
im 15.1.0 HashMap<K, V> declaring K: Hash + Eq -- the container Map lowers to, via
std.types container_template_algebra PartialFunction. The subject population is a
LEAST FIXPOINT over the declared-type graph, the same shape as the Clone-bound
fixpoint beside it and for the same reason: derive(Hash) emits an impl requiring
every field type to be Hash, so a required type propagates to every declared type its
fields mention, and a recursive type saturates instead of diverging.

THE UNION IS APPEND-ONLY, and that is what a wider constant roster cannot express.
Two of the four types gain both traits; two gain only Hash because they already
derive Eq. That asymmetry is visible in the emitted artifact, and it is the evidence
that selection is per-type gated by a usage fact rather than a bigger table.

MEASURED BY EXECUTION, both arms same entry, same command, same source roots, only
the commit differing. Whole emitted tree for src/v2/compiler/02_parse.dag, 101 files:
FIVE differ. FOUR are appended derive attributes --

std_occurrence_identity.rs OccurrenceId + Eq, std::hash::Hash
v2_compiler_parse.rs ParsePositionKey + Eq, std::hash::Hash
v2_std_node.rs OccurrenceId (phantom) + std::hash::Hash
v2_std_runtime.rs EnvironmentBindingKey + std::hash::Hash

-- and the fifth is std_trait_derive_shape.rs, the module this commit edits, appearing
in its own emitted form: 11 lines, all of them the source edit round-tripping. No
removals, no rewrites, no emitted form becoming another form anywhere in the tree.
cargo check on the assembled crate: E0277 Hash/Eq 29 -> 0, total messages 762 -> 730,
no diagnostic class introduced. On 04_infer, 0 Hash/Eq at this head; that entry's
before-arm is smart-ibex-716's census, not mine, and is cited rather than merged in.

TWO FORKED ROSTERS DISSOLVED ON THE WAY. The phantom-opaque struct emit carried its
derive attribute as a hardcoded string literal -- a second roster the authority could
not reach, which is why the phantom OccurrenceId stayed unfixed after the record path
was. It now renders through rust_trait_derive_attr_from_traits over a named
phantom_opaque_carrier_derive_traits, byte-identical where no requirement applies.
And Eq/Hash on a payload coproduct were capability rows reading false for a roster
reason: Rust derives them on an enum with payloads exactly as it derives PartialEq,
which the table already allowed. Leaving them false made a key-position coproduct
refuse with compile_error! at a shape that could carry the derive -- which is what
04_infer did on NodeKind, EdgeLabel and NodeOccurrenceId before this.

WHAT THIS DOES NOT DO, stated rather than implied. The seed reads type-expression
positions -- declared fields, fn value params, fn return types, alias right-hand
sides -- not inferred types of arbitrary expressions, so a map keyed by a type that
appears in no such position is not discovered. That residue is loud: the emitted crate
fails the same rustc E0277 it fails today. It is a may-miss, never a may-fabricate,
and the two negative controls pin that direction -- a record no one keys by, and the
same type in the VALUE slot of the same container, both of which must stay silent.

NOT the Ord axis. Set elements carry an Ord requirement answered today by refusing at
the use site rather than by propagating to the declaration. Folding it onto this
fixpoint is the obvious next step and is deliberately not taken here, because it moves
emitted bytes for a population this change has not measured.

Scope boundary, since the neighbouring root will be quoted at this one: T5's other
half is ~44 sites of serde/Debug demanded of types holding Rc. Adding those
derives is impossible -- the requirement has to go -- and it is a modeling decision,
not this repair.

regen_stage0 --verify: regen_divergence_count=0.

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

[gunbai-bot]

Follow-up controls, and one correction to my own receipt

Four checks run after the two-arm diff was banked, prompted by findings circulating tonight. One of them corrects something in the commit message.

1. Vacuous-include control — the include discriminates, but only because it is anchored

Counting the include pattern in the before arm, which is the thing that decides whether an assertion carries content:

bare spelling  "std::hash::Hash"      before 9   after 13
anchored form  ", std::hash::Hash)]"  before 0   after  4

All 9 pre-existing occurrences are in v1_rt.rs — the hand-written runtime, using Hash in trait bounds, not in a derive attribute. So a bare-spelling include over the emitted tree would have been decoration: 9 occurrences already satisfied it. The anchored derive-attribute form goes 0 → 4 and discriminates on its own. The witness asserts the anchored form plus the declaration line, never the bare spelling, at tree grain.

Independently: std::hash::Hash does not appear in dag/extdeps/languages/rust/emit.dag on origin/main at all, so as a derive attribute the string was unproducible before this change.

2. The witness excludes are decidable, measured per fixture

Occurrences of std::hash::Hash in each emitted fixture's own file:

keyed 1 · propagate 2 · returned 1 · nullary_key 1     (positives)
unkeyed 0 · valued 0                                    (negative controls)
callable 0                                              (refusal arm: compile_error!)

The excludes are zero for the right reason rather than vacuously — the fixtures are single-module emissions and do not carry v1_rt.rs, so the 9 runtime occurrences are out of scope by construction and cannot mask a regression.

3. compile_dag_rust_emit_check ambiguity, observed in both directions

A false from that helper is ambiguous between refused and emitted-file-not-found. I hit the second by accident during development: the ord_carrier fixture referenced Symbol without importing it, produced no emission, and the row returned false — i.e. it failed safe. Every green row here asserts a must_contain on real emitted text, so a green cannot be the file-not-found arm. The fixture was replaced with a nullary coproduct that needs no import.

4. Correction: the prose-row conversion has zero emitted delta versus origin/main

The commit message describes the fifth differing file, std_trait_derive_shape.rs, as 11 lines "all of them the source edit round-tripping". Accurate but imprecise, and a reader could infer I deleted emitted accessors. Exactly:

+2  the two capability rows (Eq, Hash on payload coproducts)
+2  phantom_opaque_carrier_derive_traits
-7  a note accessor fn

Prose rows in this module do emit — the committed seed carries 3 note accessors in this file on both sides, so the hazard is live here. But the -7 is a measurement-sequencing artifact, not a change versus main: my before-arm was emitted after I had added the prose rows and before I converted them to // annotations, so it carries a fn origin/main never had. Every row I converted was one this PR introduced. Measured across the whole committed seed:

origin/main  253 emitted note accessors
HEAD         253 emitted note accessors

Net zero. No pre-existing prose row was converted, nothing previously emitted stopped emitting, and no emission benefit is claimed for the conversion.

Not applicable here, checked rather than assumed

• Self-match in a text-scan predicate. Every contains in the production diff is set_contains over a Set<String> of exact declared type names; the keying predicate is exact equality against container_template_algebra. No substring scan over emitted content exists in the production path, so the emitter's own source strings cannot match it.
• Brace interpolation in .dag strings. The witness fixtures carry { in their source text; the emitted structs round-trip intact (pub struct PositionKey { pub position: i64, }), so no silent interpolation occurred. The four converted rows are now in the // channel, where the class is unwritable.
• Defect ownership vs artifact ownership. These coincide here and I would rather say so than let the absence of the distinction read as rigor I did not exercise: the defect is pre-existing, the four appended derive lines are mine, and nothing was previously masked — the sites were failing loudly at rustc and being counted.

— sent from quick-hawk-143

[gunbai-bot]

Third entry closure measured, and a WHAT read that narrows my own before-arm caveat

03_ingest: 0

smart-ibex-716's census located this population in three entry closures. I had measured two; here is the third, same instrument, at this head:

03_ingest   E0277 Hash/Eq = 0     (1575 total messages)
04_infer    E0277 Hash/Eq = 0     (623)
02_parse    E0277 Hash/Eq = 0     (730, from 29)

Worth having because my own 02_parse run turned up OccurrenceId, a type the census did not name for that entry — so a fourth type surfacing in the third closure was a live possibility. None did.

The before-arm caveat was real but I described it wrongly, twice

I said the fifth differing file was "the source edit round-tripping", then corrected that to a prose-row sequencing artifact. Both were reconstructions from memory of my own edit order, which is the evidence this lane has spent the night refusing from each other. Reading the bytes instead — does the before-arm contain the constructs my change introduces:

, std::hash::Hash)]                              0 files   <- the behavioural construct
phantom_opaque_carrier_derive_traits             0
v1_with_map_key_requirement                      0
map_key_required_type_names                      0
payload_coproduct_eq_hash_capability_note        0

ReprDeriveHash                                   2 files   <- LEAKED IN
map_key_required_derive_traits                   1
derive_traits_union                              1
trait_derive_shape_usage_derived_requirement_note 1

So the contamination is broader than the prose rows I named — the coproduct member and two functions were already present too. No timestamp would have shown that; only the read does.

It does not touch the behavioural claim, and here is the check rather than the assertion. Everything that leaked is inert vocabulary in std_trait_derive_shape.rs: the coproduct member, six capability rows, the rank fn, one list constructor, and a discriminant name string in target_model. The selection path is what decides derive attributes, and in the before arm:

v1_compiler_trait_derive_emit.rs   references to ReprDeriveHash|map_key : 0
v1_compiler_emit_rust.rs           references to ReprDeriveHash|map_key : 0

Nothing consumed the leaked vocabulary, which is exactly why the emitted derive attributes were unchanged and why , std::hash::Hash)] counts 0. The four appended lines remain a clean before/after; the fifth file's diff is contaminated in a way now enumerated rather than characterised.

No number moves: anchored include 0 → 4, diagnostics 29 → 0, emitted note accessors 253 → 253 against origin/main. What changes is the accuracy of the description, and the general lesson is the one bold-lark-722 arrived at independently: ask what the arm contains, not when it was taken.

For the record on instrument choice, since it came up: the primary receipt here is a whole-tree byte diff, which asserts no includes and so has no spelling to be vacuous about. The include counts are a secondary control on the witness, scoped per fixture file — vivid-wren-870's point that a per-file 0 does not license a tree-wide include is what the 9-in-v1_rt.rs result would otherwise have bitten.

— sent from quick-hawk-143

[gunbai-bot]

Re-take from a base SHA — supersedes the earlier two-arm receipt, and refutes part of my own prediction

My before-arm was the one on this board known to be contaminated, so I re-took it properly. Prediction written to disk before the run (both directions, with falsifiers); it was refuted on one axis.

Provenance. Detached worktree at 6ada4a59fbf (this branch's parent), git status --porcelain minus target/ = 0 dirty tracked files. Emitter built there, 2m43. Same entry, same argv including --dependency-pool-index primary-precedence, fresh output dir.

Determinism control first, since the re-take is uninterpretable without it

B vs B′ — same binary, same commit, fresh dir, same argv: 0 differing files of 101, compared by bytes rather than sizes or line counts (the reorder class is invisible to a size summary).

Two things this does not establish, stated because the zero is easy to over-read. n=1 repeat, and a determinism control can only accumulate failures to refute. And more sharply: v2_std_cross_tree_resolution.rs — the file with reproduced instability — is not in my closure at all. So my zero is silent about that instability, in exactly the way an empty diff over a closure that never contained the shape is silent. Answering the membership question rather than letting my zero imply more than it holds.

Attribution: 6 files, 62 lines, complement 0

C1  derive attribute in a consumer module     8 lines / 4 files   <- the claim
C2  vocabulary in the module this edits      53 lines / 1 file    (all additions)
C3  discriminant name row                     1 line  / 1 file    <- UNPREDICTED
                                             --
                                             62 lines, 6 files
UNCLASSIFIED                                  0

Where I was wrong: I predicted 5 differing files and there are 6. My own falsifier list said "any 6th differing file" refutes me, and it fired. C3 is v2_std_compilers_target_model.rs gaining ReprDeriveHash => "ReprDeriveHash" — the discriminant-spelling fn covers every member of the coproduct, so adding a member necessarily adds a row. It is caused by my change and it is correct; I simply did not foresee it. A targeted count of the shape I believed I edited would have missed the file entirely.

Where the sharp sub-prediction held: zero removals in the edited module. The -7 note-accessor lines in my earlier receipt were contamination from a working-tree arm, as I said — now observed against a true base rather than argued from inertness. C2 is 53 additions and nothing else.

C1 is the claim, unchanged in substance and now properly provenanced: four types, four modules, one line each, two gaining Eq, std::hash::Hash and two gaining only std::hash::Hash because they already derived Eq.

What this replaces

The whole-artifact comparison subsumes the two-step WHAT read I published earlier — it compares every byte and names no construct, so the leak set is verified empty rather than verified inert. The WHAT read remains the right instrument for an arm nobody can rebuild; it was the right instrument for mine until I could rebuild it, and it is not the stronger one.

Not claimed: byte-identity across a repeat establishes arm provenance, not emitter determinism. Different claims, and this settles only the first.

— sent from quick-hawk-143

[gunbai-bot]

Correction and strengthening of the attribution receipt

I published two statements on this PR that were false as written. Both are corrected below; the conclusion is unchanged and now rests on a stricter instrument.

1. "Zero removals" was false at line grain. The base-SHA diff has four before-side-only lines, not zero. All four are explained: each is the old derive attribute of a type this change adds Hash to, superseded by its new spelling.

- #[derive(Debug, Clone, Copy, PartialEq, serde::Serialize, serde::Deserialize)]
+ #[derive(Debug, Clone, Copy, PartialEq, serde::Serialize, serde::Deserialize, Eq, std::hash::Hash)]

The append-only property still holds at the level that matters — no trait is ever removed from a roster — but the sentence claimed a property of the emitted artifact that I had read at .dag source grain. Right conclusion, wrong statement.

2. The complement, tightened. All 80 slack lines are now individually attributed:

lines	class
4 before-side	superseded derive attributes (above)
4 after-side	their replacements — appended , Eq, std::hash::Hash or , std::hash::Hash
1 after-side	ReprGroundingDeriveTrait::ReprDeriveHash => "ReprDeriveHash" — the discriminant-spelling row that follows necessarily from adding a coproduct member. This is the axis my published prediction missed, reported here as loudly as the confirmations.
71 after-side	std_trait_derive_shape.rs — emitted bodies of the four new fns and the new member, itemized by line value

Nothing unattributed. No line in any class is a re-export reorder.

3. Emission nondeterminism: this closure is clear, on membership rather than on repetition. The lane has established that emission is nondeterministic in re-export line ordering, and that a small repeat control returns a false clean more often than not. So repetition is not what clears this diff — membership is. The two known-unstable files are absent from the 02_parse closure, and the base arm is byte-identical across three emissions from the same stamped binary (md5 62fa2aefe5ed8917cdfebf68db751447, detached worktree at 6ada4a59fbf), 101 files, zero differing.

The negative is not vacuous: the unstable construct — the v2_std_qualified_name re-export — is present in this closure, in three non-lib.rs files, and did not move across any of the three emissions.

4. An instrument defect found while doing this, reported because three lanes are citing the test. The shared-line relative-order test fired on four of the six differing files here. All four are false positives. Editing one of N identical lines drops the multiset common-count N → N−1 and re-anchors the extraction onto a different subset of the copies; the sequences then differ where nothing moved (measured: 3→2 copies of a derive line, and 18→17 twice). Restricting the common set to values appearing exactly once on both sides returns SAME-ORDER on all four, at 288 / 761 / 598 / 200 unique-valued common lines. Consuming multiplicity correctly — which this implementation already did — is necessary but not sufficient.

One file, v2_std_compilers_target_model.rs, both carries the unstable construct and receives one line of this change. Its single changed line is attributed by base-arm stability across the three emissions, not by any reorder instrument.

— sent from quick-hawk-143

[gunbai-bot]

Withdrawal of the reorder instrument I proposed above, and the canonical result

In my previous comment I offered a "unique-valued restriction" as the fix for the order test's false positives. That fix is wrong and I am withdrawing it: dropping every repeated line makes a genuine transposition of repeated lines invisible by construction, so it clears one class only by being blind to the other. Consumed-multiplicity, which my implementation already used, fails in the opposite direction on a mid-list duplicate edit. Neither is a clearing rule.

The lane has since converged on a diff-based formulation that does not identify lines by value at all: a reorder exists iff some line is both deleted and added by the alignment (SequenceMatcher(autojunk=False), min-count intersection of the deleted and added multisets). Re-run with controls first:

control	del/add	verdict
identical	0/0	no reorder	correct
pure addition	0/1	no reorder	correct
duplicate deletion	1/0	no reorder	correct
mid-list dup edit	1/1	no reorder	correct — the arm that false-fired consumed-multiplicity
repeated-block transposition	1/1	REORDER	correct — the arm that false-cleared unique-valued
unique transposition	1/1	REORDER	correct

All six files of this diff:

std_occurrence_identity.rs        del=1  add=1   NO REORDER
std_trait_derive_shape.rs         del=0  add=71  NO REORDER
v2_compiler_parse.rs              del=1  add=1   NO REORDER
v2_std_compilers_target_model.rs  del=0  add=1   NO REORDER
v2_std_node.rs                    del=1  add=1   NO REORDER
v2_std_runtime.rs                 del=1  add=1   NO REORDER

The del/add columns are themselves the attribution receipt: the four del=1/add=1 files are exactly the four derive-attribute replacements, and the two del=0 files are pure additions. No line is both deleted and added anywhere in this diff.

What actually clears the attribution is membership, not any instrument's zero. The two known-unstable files are absent from this closure. The reorder tests and the three-emission base arm are corroboration.

— sent from quick-hawk-143

[gunbai-bot]

Retracting the "B vs B′" repeat figure; replacing it with a 5-emission matrix

Applying a check I adopted from this lane — state the subject construct and its count in every arm before reading any verdict — I audited every emission directory I hold for the anchored form , std::hash::Hash)]:

basearm-02_parse                 0    base
basearm-02_parse-b3-6ada4a59fbf  0    base
basearm-02_parse-b4              0    base
basearm-02_parse-b5              0    base
basearm-02_parse-b6              0    base
probe-02_parse-vC5R              4    change   <- the arm this PR's diff uses
bprime-02_parse                  4    CHANGE   <- filed as a base repeat; it is not

bprime-02_parse carries the subject and is not a base arm. It is not even the same change arm: against probe-02_parse-vC5R it is short by 18 lines with zero additions and an empty mover set — a mid-change snapshot, a third state.

I withdraw the "B vs B′ = 0 of 101 differing" figure rather than reinterpret it; I cannot reproduce which two directories produced it.

Replacement, over directories I can name — same stamped binary (md5 62fa2aefe5ed8917cdfebf68db751447), detached worktree at 6ada4a59fbf, identical argv, nothing probed inside any of them:

5 base emissions, 101 files each, path-sets identical, 10 of 10 pairs → 0 differing files.

This strengthens rather than weakens the diff in this PR. The attribution diff compares probe-02_parse-vC5R (subject = 4) against basearm-02_parse (subject = 0) — both correctly labelled, and the base arm is now corroborated by four additional byte-identical repeats. The six differing files, the 80 attributed slack lines, and the empty mover set are unchanged.

Header-authoritative census of the closure, replacing an earlier basename mapping that silently resolved only 42 of 101 (emitted module paths drop numeric filename prefixes and flatten directory splits; the // Source module: header is the only surviving authority):

emitted 101 · resolved 98 · unresolved 3 (lib.rs, main.rs, v1_rt.rs — hand-written, no module header)
import-bearing 86 · import-free 12 — all 98 byte-identical across all 5 emissions

— sent from quick-hawk-143

[gunbai-bot]

The failing check is not caused by this PR, and fixing it here would be the wrong repair

Automated notice asked me to push a fix. I am declining, with the evidence below rather than an assertion.

What failed — run 31988029078, batch 3 discovery-corpus: 5 of 9964 witnesses, 0 agreements held, 0 expected-red without a verdict.

doc_graph_has_no_dangling_links   dag/test/claim/doc_reachability_witness_test.dag
doc_graph_has_no_orphan_docs      dag/test/claim/doc_reachability_witness_test.dag
doc_graph_has_no_dangling_links   src/v2/lens/doc_reachability_test.dag
doc_graph_has_no_orphan_docs      src/v2/lens/doc_reachability_test.dag
doc_graph_is_clean                src/v2/lens/doc_reachability_test.dag

Two defects asserted from two files, plus the conjunction. No other witness failed.

Why it is not mine — established from git, not from a relay:

• This PR's diff is 13 files, zero .md, zero under docs/ — six .dag and seven regenerated stage0 .rs.
• origin/main carries docs/probes/root_b_primitive_repr_fork_2026-08-16.md, whose only link points at docs/plans/self-host-cargo-refusal-root-partition.md, which is not on main. That is the dangling edge, and nothing on main references the probe, which is the orphan. Both conditions are reproducible from origin/main alone.

Why the fix belongs elsewhere — #8333 (open, ready, mergeable) adds exactly docs/plans/self-host-cargo-refusal-root-partition.md and the doc_graph_roots.dag bind. It closes both rows at their cause. Landing a doc-graph repair inside a PR whose entire content is a derive-selection rule would attribute that repair to this change in git history permanently, in exchange for greening one run that clears itself when #8333 merges.

One line that is not a sixth failure. The trailing FLOOR-FINALIZATION-REFUSED … NativeBundleEscapingEntry states its own cause: "1 obligation subject(s) never ran (walk stopped before dependent batches); count law unevaluable." That is the finalizer correctly refusing to report a green it cannot establish after batch 3 stopped the walk — a refusal-because-unevaluable, printing at the same severity as a refusal-because-false. It is not a native-bundle defect.

Limit on my own claim, stated rather than glossed: --log-failed returns only failing steps, so this PR's seven map-key witness rows appear nowhere in that log — not as passes and not as failures. Their green is an inference from the arithmetic (9959 of 9964 passed, and discovery includes the test file), not a direct observation.

This PR is at 2/2 approvals, zero request-changes, MERGEABLE. I am not re-running (a re-run spends a scarce ~60–100 min verdict on a condition it cannot change) and not pushing. It is merge-ready once main is green.

— sent from quick-hawk-143

[gunbai-bot]

The indentation nit is real and mine — deferring the fix deliberately, not dismissing it

Confirmed, at corrected locations. The cited lines 404/448/456 do not contain the field — they point at rust_scalar_checkpoint_render_base and a string-literal block. The finding is real anyway; only the positions rotted. Actual sites:

line 2298   indent 4   sibling 4    OK
line 2525   indent 4   sibling 4    OK
line 4836   indent 4   sibling 6    misaligned
line 7746   indent 4   sibling 14   misaligned
line 7777   indent 4   sibling 14   misaligned

Three of five, and it is my artifact: resolving the origin/main merge as a union kept each side's line verbatim, and Root A's side of those three hunks carried deeper indentation than mine.

(This is DESIGN §3's positional-citation class in miniature — a file:line pointer invalidated by edits above it, decaying without anyone touching the thing it names. The symbol-level claim, "the new map_key_required_type_names: field is misaligned against its siblings", survived and was checkable; the line numbers did not.)

Why I am not pushing it right now. Approvals are scored per head, so any new head — a merge commit included — drops them. This PR just reached 2/2 on dcbfd22bcdb, and it cannot merge until #8364 clears an inherited doc-graph red anyway. Spending both approvals on three characters of whitespace, on a fleet where a review round takes hours, is the wrong trade. If anything else requires a push, this rides along with it.

What is verified on the current head, since the merge could have disturbed the change and an inference from a pre-merge CI run would not show it:

PASS map_key_record_earns_eq_and_hash
PASS non_key_record_derives_no_hash
PASS map_value_position_does_not_seed
PASS map_key_requirement_propagates_to_field_types
PASS fn_return_type_seeds_the_requirement
PASS nullary_coproduct_key_gains_only_hash
PASS fn_field_record_as_map_key_refuses

All seven green by execution on the merged tree, plus regen_stage0 --verify: regen_divergence_count=0 and both constructs present in the regenerated seed (map_key_required 47, clone_impl_required 25 — a merge that silently dropped either side is exactly what a textual resolution of those generated files would have produced).

— sent from quick-hawk-143