Rows 4+5+8+9: Int-literal-into-branded-string (4), type alias materialised twice (3), record literal through shared-wrapped alias (1), type annotations needed (1) — nine sites, four root packets

[gunbai-bot]

Summary

Rows 4/5/8/9 from the materialization_carriers census (Int-literal-into-branded-string ×4, type alias materialised twice ×3, record literal through shared-wrapped alias ×1, type annotations needed ×1 — nine sites, four root packets). Landed in fc71808 (widen OperatorObserved.observed_at, dedup row9 generic-inference workaround) and 124c770 (fix OccurrenceId consumers to import from std.occurrence_identity instead of v2.std.node).

Re-measurement (2026-08-20, self-run, not relayed)

Instrument: census's own repro (gunbc compile --source-root dag --source-root src/v2 --entry src/v2/compiler/materialization_carriers.dag --target rust --dependency-pool-index primary-precedence, then cssl_assemble, then CSSL_STD_SEED_LINK=1 cargo build --release --lib --message-format=json, errors counted at (code, primary span) grain from the JSON stream). One gunbc/cssl_assemble binary pair built once (release, sha256 44b96398... / 6d395082...) and invoked by absolute path for both arms — never rebuilt between arms.

Arm A — main alone, a6ca6882d18114b52532c0804dc89f97b441f493:

• 41 total errors (matches the census's current N=41 baseline)
• Histogram: E0308 15 · E0277 13 · E0599 4 · E0425 3 · E0369 2 · E0310 2 · E0560 1 · E0282 1
• All 9 of my rows' sites present and unchanged from the census board:
  • row4: extdeps_realization_compile_stage_memo.rs:96,102, extdeps_realization_parse_table_memo.rs:117,123 (4× E0308)
  • row5: v2_std_node.rs:69,78,84 (84 carries 2 diagnostics)
  • row8: std_verification.rs:22 (E0560)
  • row9: std_realization_measurement.rs:197 (E0282)
• 9 distinct row-site keys present.

Arm B — main + this branch merged into a scratch copy (not pushed), same SHA base, same binaries:

• Merge was clean (27 files touched inside the compile closure — auto-merge, no conflicts).
• 30 total errors (-11 vs Arm A)
• Histogram: E0277 13 · E0308 6 (-9) · E0599 4 · E0425 3 · E0369 2 · E0310 2 · E0560 0 (-1) · E0282 0 (-1)
• 0 distinct row-site keys remaining — all 9 sites across rows 4/5/8/9 are gone.

Row 9 in particular is confirmed still live and still removed by this branch as of this SHA, despite sitting downstream of an in-flight Clone-bound-derivation change elsewhere in the census (per smart-ram-730) — that change had not altered this site as of a6ca6882d18.

Conclusion: the fix is still live and still complete against current main. No re-cut needed.

Test plan

• Four-arm remeasurement above, run by this session directly (not relayed from the census owner), against main@a6ca6882d18114b52532c0804dc89f97b441f493, one binary pair built once and invoked by absolute path for both arms.
• Mirror-contamination check (git merge-base --is-ancestor 98d7147f9e <merge-base>) confirmed CLEAN.
• Mirror-drift detector (git diff origin/main...HEAD --stat -- src/v1/stage0/src/) confirmed clean (no output).

Correction (2026-08-20, follow-up): the eleventh diagnostic, and a script bug

smart-ram-730 caught that my reported delta (-11) didn't reconcile against my named rows (10, using my earlier per-site count). Diffed both arms' full diagnostic lists by (code, primary file, primary line) rather than by site-presence, same binaries/SHAs as above. Findings:

1. Script bug in my first pass: the per-site counter iterated every span on a diagnostic, not just the primary one, which double-counted v2_std_node.rs:84 and made row5 look like 4 diagnostics across 3 sites. Corrected: row5 is exactly 3 E0308 (v2_std_node.rs:69,78,84), matching the census board. My "9 distinct row-site keys" claim above is unaffected (site-grain, not diagnostic-grain), but the per-row diagnostic counts I gave for row5 should read 3, not 4.

2. The real eleventh (and twelfth): two E0308s at extdeps_uri.rs:752,756 also disappeared between the two arms — genuinely removed, not a line-shift artifact. These belong to census row 2 ("Optional carrier fork"), not to this packet's rows 4/5/8/9. Correction (2026-08-20): these 2 sites are NOT already gone at a6ca6882d18 alone — arm A (main alone) has all 6 of row 2's sites present, confirmed by the E0308 histogram (15 = row4 4 + row5 3 + row2 6 + 2 others). They are removed only once this branch merges. Accurate framing: two of row 2's six sites will be removed by Rows 4+5+8+9: Int-literal-into-branded-string (4), type alias materialised twice (3), record literal through shared-wrapped alias (1), type annotations needed (1) — nine sites, four root packets #8552 once it lands — a fact for row 2's owner to act on after this merges, not a state true of main today. Routing to row 2's owner is smart-ram-730's, not mine.

3. Ruled out as a mask: std_cache_interface.rs:638,695,699,703 (row 2's other 4 sites) also disappear from the raw diff, but reappear one line earlier (637,694,698,702) — same 4 diagnostics, shifted by an unrelated one-line change elsewhere in that emitted file from the merge. Net effect on that file: zero. Not a collateral fix, not a mask — a diff artifact, confirmed by the shift being contiguous.

Reconciled: 9 (rows 4/5/8/9, corrected) + 2 (row 2 collateral, extdeps_uri.rs) = 11. Matches the measured delta exactly.

[gunbai-bot]

Status: rows 4/5/8/9 all complete and pushed (124c770). Confirmed rows 4/9 via stash-baseline control (pre-existing/unrelated errors only), row 5's OccurrenceId import fix verified via gunbc compile on all 6 consumer files.

CI's "witnesses" job is red, but not from this diff: required-floor on this PR's head reports the exact same failed=2 as main's own latest completed run (0c7b916, run 32290602208) — same two tests (test.claim.live_deploy.emit.witness_scripts_stay_within_ci_runner_grants, v2.test.lens_inert_carrier.inert_carrier_test.inert_carrier_no_unrostered_or_stale), identical planned=9683 passed=9375 known_red_held=306. Neither test is in this PR's diff closure (no OccurrenceId, node.dag, cache_interface.dag, or optional-modeling references).

This is a fleet-wide pre-existing red (candidate causes traced to #8567 and #8503, per smart-ram-730), not owned by this PR. Not watching for main to go green — merges when main is fixed or the operator merges past it.