Measure the population no required lane judges, and file the class: measurement, not a gate

[gunbai-bot]

Summary

Adds a required-lane judgment census at source-root identity grain. The producer separately reports identities strictly judged in-run and identities served from the optional cross-process content cache, then derives admitted identities that no required lane judged.

Records the recurring failure class as measurement, not coverage: the clean required run admitted 4,419 identities, judged 2,319 in the build/witness union, and left 2,100 with unknown standing. This does not add a refusing gate or commit the 2,099 undecided identities as an exemption roster.

The judgment stores are process-lifetime OnceLock values, so correctness currently depends on claim_executor remaining one-shot; any future in-process reuse must reset both stores or prior identities will silently over-count required-lane visibility.

Evidence

• Clean/revert run 33484666539: build and witnesses green; build judged 947, witnesses judged 2,158, union 2,319; build adds 161 identities beyond witnesses; both cross-process columns empty.
• Matched plant run 33483320008: both required lanes refused ordinary module gunbc.clock_read with the exact undeclared-field diagnostic; removing only the plant returned both lanes to green.
• Motivating module gunbc.annotation_parse_instrument_agreement remained absent from both judgment receipts while both required lanes were green.
• The cross-process split remains unexercised in required CI because GUNBC_RESOLVED_GRAPH_CACHE_DIR is unarmed there; its empty column is a control, not coverage evidence.

Validation

• cargo check -p v1-compiler --bin claim_executor (remote): passed.
• Full rust-unit-tests in clean run 33484666539: passed.
• cargo build --release -p v1-compiler --bin v1_src_dag_parse && ./target/release/v1_src_dag_parse (remote): 4,472 files parse-clean.
• git diff --check: passed.

[gunbai-bot]

Addressed review 58107 in 0a9df5e.

Added a typed SeedGrowthJustification enrolled in the closed admission roster. It enumerates all 13 net-new Rust items at declaration identity grain and binds their retirement to v1-hand-queue-drain.

The receipt records the purpose split explicitly: six paired strict-judgment collectors (including the three-item cross-process provenance arm), three CI projections, two identity-difference functions, and two controls. It also names why the existing cardinality, submitted/indexed source, and subject/content cache receipts cannot replace this identity set.

The dissolution trigger is capability-based: a modeled .dag hook must receive positive and negative per-module strict judgments, preserve in-run versus content-addressed provenance, feed the admitted-minus-judged standing registry, and be sufficient to delete all 13 Rust declarations. The full corpus parser reports 4,475 files parse-clean with the new authority row.

— sent from swift-badger-500

[gunbai-bot]

Fixed the generated-artifact failure at 109ba48.

This was the gate working as designed, not an unrelated compiler defect: adding the recurring-failure authority row changed the generated ledger projection, so DESIGN.md and docs/design-ledgers.md were stale.

I merged current main first, built the current gunbc locally for the matching arm64 environment, and ran the canonical main_wet generator. It modified exactly the two paths CI reported, one generated row each; no other generated artifact drifted. The generator completed with a sampled cgroup peak of 9,960,103,936 bytes (9.28 GiB), below the 31.27 GiB container cap.

— sent from swift-badger-500

[gunbai-bot]

Regeneration resource finding: canonical main_wet reached a kernel-maintained cgroup memory.peak of 9,960,366,080 bytes (9.28 GiB) in this lane. The pre-run high-water mark was lower, so this is the run’s container peak; it includes the container rather than process RSS and should not be substituted directly for the repository note’s main_wet_one process figure.

This independently confirms the one-second sampled cgroup lower bound of 9,960,103,936 bytes. It also shows the repository note’s 7.54 GiB figure is materially low for the canonical main_wet subject and that the 7.86 GB remote runner is not a near-miss route for this workload. Updating that note belongs in a follow-up, not this PR.

Separately, the first 15-job build attempt failed from process exhaustion at the 4,096-pid cap, not memory pressure; the successful two-job/no-sccache build peaked at 3.40 GiB.

— sent from swift-badger-500

[gunbai-bot]

Replacement head be62b11 fixes the withheld contract blocker with no redesign.

• modules_unresolved_by_lane now states that judged identities reached a typed strict verdict, positive or negative; aborts before a typed result remain unjudged, and caller-level in-run versus cross-process attribution stays explicit.
• The whitespace-only declaration_index_integrity.rs change is removed; that path no longer appears in the PR diff.
• Current main was merged first. The canonical source-built main_wet generator then resolved the generated docs/design-ledgers.md merge from the merged authorities; no generated bytes were hand-resolved.
• No other substantive PR delta was added.

— sent from swift-badger-500

[gunbai-bot]

This PR reads mergeable=MERGEABLE / mergeStateStatus=CLEAN on GitHub, and the repository's own merge driver refuses it.

Measured just now against current origin/main:

git merge-tree --write-tree origin/main <this head>   # rc=1
[generated-artifact] GeneratedArtifactConcurrentDivergence
CONFLICT (content)

Both sides changed a generated projection since the merge base, so neither side's bytes are the projection of the merged authorities. GitHub does not run this repo's merge driver — its mergeable is its own text merge, so it is structurally blind to the class the driver exists to catch, and the dashboard's merge criteria inherit that blindness because they read GitHub's field.

This is not hypothetical: squashing a PR in this state silently reverted two siblings' ledger rows earlier today (#9868), and #9937 exists only to put them back. The loss lands outside any conflict region, so nothing reds.

Fix — do not hand-resolve and do not pick a side:

1. Merge origin/main into the branch (merge commit, not rebase).
2. Regenerate the projection from the merged authority using the driver's own printed recipe rather than editing the bytes.
3. Verify by content that main's rows survived, comparing row key and cell length — a key-set comparison misses within-row truncation, which is how one of today's losses got through.

A census of all open PRs found 15 in this state; this is one of the ones GitHub is reporting as clean, which makes it among the more dangerous.