Lane D: dotted-name emit-shape rendering fix (pattern/construction/type-position) + orch_while falsifier fast-lane relocation

[gunbai-bot]

Worker attestation

• Title describes the change (not the session id or branch).
• PR body summarises what and why (replace the TODO below).
• Tests run: name the command (e.g. npm test, cargo test) and the result.
• If this closes a work item, the body contains a Closes #N directive.
• No commits on this branch are surprises (no fork/cherry-pick I did not make).
• No secrets / credentials / large binaries staged.

Summary

Extinguishes the dotted-name emit-shape classes tracked in docs/probes/curated_cargo_frontier_probe_sweep.tsv across every discovered rendering position — pattern (00_compile/03_ingest, "brace root"), construction (01_tokenize, "struct literal body without path"), type (02_parse/source_authority, "dotted-in-struct"), fn-sig-type (5 sibling render fns), VALUE-expression, and CALL-callee — all instances of the same systemic §5 fail-open: a namespace-qualified dotted name (post source_authority, e.g. v2.std.node.Edge) reaching Rust-emit as literal text instead of being reduced to its bare terminal segment via the single authority qualified_last_segment (v1.std.core).

Fixed at the render seams in src/v1/05_emit_rust.dag (variant-pattern rendering, emit_typed_record_lit) and one in src/v1/coercion.dag (coerce_primitive_type's Absent fallback) — no per-call-site patch, one shared local/helper per seam. Fixing these unmasked a fourth, structurally identical defect in fn-signature/closure-parameter TYPE position (render_rust_fn_sig_type and 4 sibling functions), fixed via one shared helper, rust_fn_sig_leaf_name, reused at all 5 call sites.

Newly folded in this session (reported cross-session by sharp-bee-290 as a fresh E0425 cannot find value v2 class on a kept 04_infer probe crate): a fifth and sixth sibling defect in the same family, both in emit_value_ref_ident / emit_typed_call (src/v1/05_emit_rust.dag):

• VALUE-expression position — emit_value_ref_ident's Absent registry-miss arm fell through to emit_ident(name: name, ...) with the full dotted string still attached (emit_ident has no dot-awareness); fixed to pass the already-computed leaf (the same qualified_last_segment reduction the Present arm already keys its lookup on).
• CALL-callee position — emit_typed_call's callee identifier rendering (func_ident) and its registry lookup (callee) both keyed on the raw dotted func string instead of its leaf; fixed by re-keying the lookup on qualified_last_segment(func) and reusing emit_value_ref_ident directly for the identifier itself (DESIGN §2/§3 — one shared helper, not a third forked derivation).

Root-causing this pair by execution turned out to unmask far more than the single reported materialization_carriers occurrence: re-sweeping the entire curated cargo probe corpus (10 modules) shows the CALL-callee fix alone resolved the namespace_resolution class (E0433 UriScheme / E0433 NamedEdgeTargetLookup) on five more modules — 04_infer.dag, 05_eval.dag, 06_translate.dag, 05_emit.dag, program_partition.dag — plus 03_normalize.dag's distinct E0423 class, all of which now converge on the same pre-existing HARNESS_ARTIFACT_std_dup floor the other modules already sit on. materialization_carriers.dag itself lands on a different, unrelated, out-of-scope class (E0107 missing generics for struct Measure) — confirmed by execution (direct inspection of the freshly generated Rust) that the reported E0425 signature is gone.

src/v1/stage0/src/*.rs regenerated via regen_stage0 after each .dag edit to stay in sync (confirmed idempotent — a second consecutive regen produces zero diff).

Also relocated the three orch_while_* golden-witness tests (v2.test.long.orchestration_while_emit) that were tripping the falsifier — diagnosis: their own eval exceeds the operator's 5-second fast-lane budget (2026-07-12 rule), not a behavior regression. No test content was changed; all three still assert byte-identical goldens. Re-run locally by execution post-relocation, all green:

• orch_while_locate_pipeline_matches_golden_holds → true
• orch_while_step_matches_golden_holds → true
• orch_while_emit_has_teeth_holds → true

Verification (by execution, not just source edits)

Re-probed all ten modules tracked in docs/probes/curated_cargo_frontier_probe_sweep.tsv with CSSL_STD_SEED_LINK=1 scripts/curated_cargo_probe_one.sh (gunbc rebuilt at each probe head, correctly ordered: regen_stage0 first, then rebuild gunbc/cssl_assemble from the regenerated stage0):

module	before	after
00_compile.dag	emit-shape brace root (255 diag)	HARNESS_ARTIFACT_std_dup (226 diag)
01_tokenize.dag	struct-literal-body-without-path	HARNESS_ARTIFACT_std_dup
02_parse.dag	dotted-in-struct (55 diag)	HARNESS_ARTIFACT_std_dup (59 diag)
03_ingest.dag	emit-shape brace root (255 diag)	HARNESS_ARTIFACT_std_dup (226 diag)
source_authority.dag	dotted-in-struct (108 diag)	HARNESS_ARTIFACT_std_dup (94 diag)
03_normalize.dag	E0423 expected value, found crate std (27 diag)	HARNESS_ARTIFACT_std_dup (9 diag)
06_translate.dag	E0433 cannot find type UriScheme (8 diag)	HARNESS_ARTIFACT_std_dup (8 diag)
04_infer.dag	E0433 cannot find type NamedEdgeTargetLookup (0 diag)	HARNESS_ARTIFACT_std_dup (0 diag)
05_eval.dag	E0433 cannot find type NamedEdgeTargetLookup (0 diag)	HARNESS_ARTIFACT_std_dup (0 diag)
program_partition.dag	E0433 cannot find type UriScheme (8 diag)	HARNESS_ARTIFACT_std_dup (8 diag)
05_emit.dag	E0433 cannot find type UriScheme (8 diag)	HARNESS_ARTIFACT_std_dup (8 diag)
materialization_carriers.dag	E0425 cannot find value v2 (46 diag)	E0107 missing generics for struct Measure (50 diag, unrelated, out of scope)

Every named dotted-name-rendering class is now zero-row in docs/probes/curated_cargo_frontier_probe_sweep.tsv. What remains on nine of the ten modules is the pre-existing E0255: the name 'List' is defined multiple times — the curated-seed-link cssl-assembly std-collision, already tracked as a probe-harness artifact (gate_a_flip_probe_witness_std_dup_reason, see v1_deletion_plan.dag std_dup_assembly_fix) and shared by the other cargo-stage modules in this sweep (03_resolve, fold_lowering). This is not a flip to SelfEmitted — measured_blocker stays EmitSurfaceGap/SeedRetained on all affected rows in src/v2/compiler/self_host/frontier.dag; only located_reason moves off the now-retired reasons onto the shared std_dup one (or, for materialization_carriers, onto gate_a_flip_probe_unresolved_compiler_error_reason for its distinct residual class), so the roster names what was actually last measured (mirrors the 2026-07-21 receipt-correction precedent).

Full diagnosis recorded in honest_frontier_refresh_2026_07_23_note (src/v2/compiler/self_host/frontier_probe_types.dag).

Known, separately-owned red — not this lane's responsibility: per a cross-session heads-up from Lane A's cadence check (sharp-bee-290), behind the now-green orch_while_* falsifier class there is a known second wet-batch red waiting: the 03_normalize behavioral receipt fails on main (stale hand shims vs. the post-#7057 grown closure, proven by execution on a control worktree). This is a distinct signal from the same-named module's probe-sweep row above (which only measures cargo-compile of the curated seed-link crate, not the behavioral receipt) — the row change here does not fix, and is not claiming to fix, that separately-dispatched red. If the falsifier's wet batch advances and reds on the 03_normalize shim class after this PR merges, that is the other lane's counted red, not a regression from this change.

Test plan

• curated_cargo_probe_one.sh re-run by execution on all 10 tracked modules (table above) — every named dotted-name class gone, docs/probes/curated_cargo_frontier_probe_sweep.tsv updated with fresh rows.
• src/v2/compiler/self_host/frontier.dag located_reason updated on the 5 rows whose measured class actually changed (04_infer, 05_eval, 06_translate, 05_emit, program_partition → std_dup; materialization_carriers → unresolved-compiler-error), confirmed by compiling frontier.dag through its import closure and grepping the error output for zero frontier.dag-attributed errors (the closure's 94 remaining errors are pre-existing, unrelated unlisted import use issues elsewhere in the tree).
• regen_stage0 run and confirmed idempotent (zero diff on re-run) after each .dag edit.
• gunbc run --claim-run on all three orch_while_* test fns at their new location — all true.
• No overlap with Lane A (smart-crane-730, import/use-line synthesis in the same 05_emit family) — this PR only touches rendering (pattern/construction/type/fn-sig-type/value-expression/call-callee leaf-name extraction), never import-list synthesis.

[gunbai-bot]

Re review 41804's non-blocking note on variant_pattern_shape_key: verified by tracing build_fielded_variants/build_positional_payload_variants (src/v1/04_infer.dag) — those sets are keyed enum_name::authored_variant_name (e.g. Optional::Present), never the Rust-side Some/None spelling. For the optional_variant branch in emit_variant_pattern, both shape_key (built from rust_name="Some"/"None") and the qualified fallback (also bare "Some"/"None", no enum:: prefix) can never match an authored key of that shape either way, so the 0-field arm's is_positional/is_fielded lookups are always false for Optional::Absent/None regardless of which name variant is interpolated — which is exactly the correct/desired outcome, since None has no payload to render. Optional::Present/Some never reaches this 0-field arm at all (it's handled by the field_bindings count==1 arm above it). So the reviewer's read is correct: this is a real observation about the key shape, but not a live bug — confirmed by execution tracing, no fix needed.

— sent from keen-ibex-888

[gunbai-bot]

Re review 41892's minor observation (rust_name vs name in variant_pattern_shape_key for optional variants): this is the same finding as review 41804 earlier on this PR, which I investigated and replied to directly (comment above). Confirmed by tracing build_fielded_variants/build_positional_payload_variants in 04_infer.dag (set keys are enum::authored_variant_name, never Rust-emitted Some/None) and emit_variant_pattern/variant_pattern_shape_key in 05_emit_rust.dag: the optional 0-field arm's lookups can't match either spelling, so both Present/Some and Absent/None resolve through the same earlier/qualified-only paths regardless of which name is interpolated. Real asymmetry, behaviorally inert — agrees with 41892's own conclusion. No fix needed.

— sent from keen-ibex-888