Slice 1: emit per-shard roster_closure — the missing CI-floor calibration datum

[gunbai-bot]

What

Emit roster_closure_nodes — the distinct modules typechecked in a shard's union closure (typecheck_compute_count(), the once-per-node receipt), max-merged across shards — on the [measurement] discovery corpus line. Every floor run now records the pair (roster_closure, per_shard_rss).

Why

The floor's per-shard memory authority is a hand constant (gunbc_ci_floor_per_shard_peak_max, 4.56 GB) that is wrong in two independent ways: it is a width-1 whole-process misattribution (the entire process RSS charged to a single shard), and it was measured on the pre-enrollment-flip ~1000-witness corpus, not the current 8-witness enrolled floor. One constant can't be right because per-shard memory is a function of input size — and today no run records that input size. Per-shard RSS is already emitted in two bases; the node count (the missing half of the calibration pair) was not.

This is Slice 1 of flipping the floor's memory model from predict-a-peak-and-hope to declare-a-limit-and-construct (design: docs/plans/could-we-plan-out-*.md). It ships the sensor everything downstream needs — the decomposed space fit, the contended host→slot→swap budget tree, and admission-by-construction — and it turns "how does contention behave under saturation" from a guess into recorded data.

Safety (DESIGN §5)

Additive and behavior-preserving. No constant is lowered — lowering per-shard memory is the OOM-risk direction, so it waits on a trustworthy current-corpus reading from this sensor plus the Slice-2 fit, never a guess. The stale 4.56 GB constant is re-annotated on its own carrier as debt (gunbc_ci_floor_per_shard_rss_source) with the explicit re-grounding path.

Discriminating RED

merge_discovery_summaries_takes_max_roster_closure — fails if the merge sums the field (would double-count the shared std/spec prefix), drops the merge line (stays 0), or reverts the carrier. Max-merge is correct because parallel shards share the prefix and the heaviest single shard's closure governs the per-shard peak.

Note on the failing checks

The earlier CI red (42bfc38) was an auto-committed mid-implementation snapshot — the DiscoverySummary struct field landed before its three constructor initializers, so the seed didn't compile. The complete change (da3f0ac575) adds the initializers, the per-shard count read, the merge, the emit, and the test; it builds, tests green, and is fmt-clean locally.

[gunbai-bot]

This PR is intentionally held in draft at the operator's request — not abandoned.

It is awaiting sign-off on a model reconciliation for the operator-signed bounded_input_cost_envelope_scheduling.dag (predicted→allowable ceiling; one authored size dimension; std.measure as the concrete byte evaluator; decomposed per-shard fit base + W·shared_prefix + bytes_per_node·roster), plus the Slice 2 implementation that retires the hand-calculated gunbc_ci_floor_per_shard_peak_max constant.

It will be flipped ready once the reconciled doc and Slice 2 land together as one coherent unit ('fully done'). Slice 1 (the roster_closure sensor) is complete and already approved on this branch.

— sent from merry-owl-649

[gunbai-bot]

Fixed in 5838dba (and the commits it builds on). The core finding was right and I've taken it: roster_closure_nodes is no longer read from typecheck_compute_count(). It is now the union of authored module names across the graphs each shard actually resolves — its prefix contexts plus each roster entry — via collect_typed_module_names. That is a property of the source closure, so it is independent of cache warmth, resolve order, and the diff under test.

Three corrections to the diagnosis, because they change what the fix has to be.

The stated mechanism doesn't hold. Finding 1 says the width == 1 path "runs on the same executor thread that already paid typechecks for earlier floor batches (compile-clean gate, single-claim gates, etc.)". It doesn't. run_walk (claim_executor.rs:1419–1452) partitions batch units: only SharedClaims go to the main-thread memo path, and everything else — including BatchUnit::Discovery — is dispatched with thread::spawn. The compile-clean gate is a memo unit on the main thread; discovery gets a fresh thread with a cold counter and a cold thread-local typed cache. I chased this exact hypothesis first and falsified it.

The real contamination is upstream of the width branch, on the discovery thread itself. With selection_enabled (CI's plan declares node_frontier_selection: SelectionApplied), floor_diff_edits_from_line_ranges resolves every changed file in the diff as an entry (cli_run.rs:5852), and each entry resolve bumps the counter. At width == 1, run_discovery_rows then returns on that same thread, so the reported value was |closure(changed files) ∪ closure(prefix) ∪ closure(rows)|. The damaging property isn't that it over-counts — it's that the count became a function of the PR's diff: the same roster reported a different number depending on which files the PR touched. There's a second live instance the review missed: floor_skip_discovery_witness calls run_discovery_corpus_with_options three times on one thread, so its 2nd and 3rd reads sit on a counter warmed by the 1st.

The proposed remedy would not have fixed it. "Reset at the start of run_discovery_rows (or snapshot a delta) before witness resolves" fails on set semantics. A reset-or-delta at that boundary counts misses during the row window, and any module already typechecked by the diff-attribution resolves is a cache hit during that window, so it is excluded. The count stays diff-dependent — it just flips from an over-count to an under-count, and it additionally drops the prefix modules, which are resident for the shard's lifetime and therefore belong in the pairing against per-shard RSS. Any counter-derived reading is warmth-dependent by construction; the closure has to be read off the graphs.

On finding 2: it's factually right that each shard resolves the floor runner and entry-selection entries before run_discovery_rows, but I don't think that's over-counting. Those graphs stay resident for the shard's lifetime, so their modules are part of the memory roster_closure_nodes is paired against. The fix keeps them counted — deliberately — by seeding each shard's closure with the prefix contexts.

Receipts: roster_closure_count_is_independent_of_thread_cache_warmth (union_resolve_receipts_test.rs) is the discriminating control — a prior same-thread resolve moves the compute counter (asserted, so the control cannot silently stop discriminating) while the graph-derived closure is unchanged. merge_discovery_summaries_takes_max_roster_closure still guards the max-vs-sum merge. cargo check --workspace --all-targets is clean.

One gap I'm naming rather than hiding: both controls prove the primitive and the merge, not the wiring — that run_discovery_rows reads closure_modules rather than the counter is verified by inspection, not by execution. The end-to-end control is to call run_discovery_corpus_with_options twice on one thread and assert the reported count doesn't collapse on the second call (it would go to ~0 under the old counter). That belongs with Slice 2, which is the first consumer of this datum and where the fit will actually depend on it.

— sent from merry-owl-649

[gunbai-bot]

CI is green on 5838dba2a6 (ci, ci_regen, rust_tests), and the floor run exercised the new code path. The emitted datum, from run 29094764979:

[measurement] discovery corpus: 79 witness(es) (69 skipped), resolve 9204.725ms,
  evalu 89030.495ms, ..., roster-closure 274 nodes (max shard)
[calibration] max-per-shard-peak-rss: 1632723968 bytes at spawn_width=4

So Slice 2 now has a real (roster_closure_nodes, per_shard_rss) pair at spawn_width=4: 274 nodes ↔ 1.52 GiB/shard. 274 is a sane per-shard closure — neither collapsed toward zero nor the whole ~600-module tree.

Being precise about what this receipt does and does not establish, since I named the wiring gap above: it confirms run_discovery_rows emits a plausible closure count on the shipped path, but it is not discriminating between the closure and the old counter. This run is spawn_width=4, and shards genuinely start cold (run_walk spawns them), so the counter would have reported roughly the same 274 here. The two readings only diverge on the width == 1 path and on repeat same-thread calls. The discriminating end-to-end control — invoke run_discovery_corpus_with_options twice on one thread and assert the second call doesn't collapse toward zero — still belongs with Slice 2, which is the first consumer whose fit actually depends on the datum.

Also worth flagging for Slice 2's fit: the RSS half here is VmHWM / spawn_width, a whole-process peak divided by width. At width == 1 that divisor makes the RSS reading whole-process (base included), while the node reading is one shard's closure. The two halves are on different bases at width == 1, which is independent of the counter bug this PR fixes and is exactly what the STALE-PENDING-RECALIBRATION marker in ci_floor_measurement.dag warns about. Fitting base + bytes_per_node·roster across width == 1 and width > 1 without reconciling that will push the base term into the slope.

— sent from merry-owl-649