P1 retention vs drain cohort receipt (authoritative)

[gunbai-bot]

Summary

Authoritative measurement receipt for the floor prep-tax program's P1 leaf (dashboard node://adhoc-9af14fee-a7f): does schedule-derived retention/eviction (#7129) cause the ~1-2s per-entry "tax" observed on the real floor discovery path, or does it persist independent of eviction?

Ran a fixed 50-entry cohort (src/v1/stage0/src/bin/p1_cohort_roster.txt, sourced from the slice-2 representative-50 receipt) through the real production entrypoint (run_discovery_corpus_with_options, DiscoveryWidthPolicy::Adaptive — the only branch where schedule-retention arms) via a new thin probe binary, p1_cohort_probe, in two modes:

• Mode A — default eviction ON (production default).
• Mode B — GUNBC_SCHEDULE_RETENTION_EVICT=0, the retain-all measurement pole (arming/counting only, evicts nothing, loud diagnostic confirmed).

ACCEPT criterion (parent-stated): entries 2..N sharing the module universe stop repaying ≈2s tax under Mode B.

Result: REJECT. Mode B was OOM-killed at entry 34/50 after unbounded RSS growth (1.7 GB → 5.3 GB, honestly reported, not backfilled), but for the valid overlapping range (entries 2..34) mean/median wall_ms/resolve_ms are statistically indistinguishable between Mode A and Mode B — disabling eviction does not collapse the tax. Full data, per-entry table, and verdict: docs/plans/p1-retention-vs-drain-cohort-receipt.md.

Per the parent's routing, this redirects the floor prep-tax program toward assembly/materialization reuse as the tax's actual source — arrived at by measurement, not assumption. No retention mechanism change lands here; no assembly/materialization work starts from this leaf (that's parent-sequenced).

cli_run.rs diff — instrumentation-only

The only production-code diff is diagnostic: a new resolved_graph_evictions counter field on IndexRetentionSnapshot (pure observation, no eviction-logic change) and a new [p1-cohort] per-entry-group log line gated on its own env var GUNBC_P1_COHORT_RECEIPT (never folded into the existing GUNBC_FLOOR_DRAIN_RETENTION switch — two distinct facts, two distinct toggles). index_arm_schedule_retention's call site and the eviction decision itself are untouched. Default (env var unset) behavior is byte-identical to before this PR.

This is a declared scaffold with a named dissolution trigger (in-code comment on p1_cohort_receipt_enabled): once P1 is banked and no other lane needs cohort-scoped A/B retention receipts, the instrumentation + p1_cohort_probe binary delete together. p1_cohort_probe is not a second permanent floor driver — it front-ends the identical production entrypoint claim_executor uses, scoped to a fixed cohort purely for this measurement's entry-by-entry comparability, and is probe-only scaffolding, not a durable second harness.

Test plan

• cargo fmt --all --check — clean.
• cargo build -p v1-compiler --bin p1_cohort_probe --release — builds clean.
• Mode A run: 50/50 entries completed, 414 witness rows, 1 pre-existing unrelated failure (witness_observed_hostname_reads_typed_op_hermetic, environment-specific hostname check, identical failure in both modes — not a retention/timing concern).
• Mode B run: 34/50 entries completed before OOM-kill (exit 137), fully captured and reported honestly; no data fabricated for entries 35-50.
• Full reproduction commands, raw logs, and quantitative comparison: docs/plans/p1-retention-vs-drain-cohort-receipt.md §0/§3.

[gunbai-bot]

Addressed review 47754 (REQUEST_CHANGES) in f333e6a:

1. Fixed cited reproduction SHA (was b53aec1, which predates p1_cohort_probe.rs; corrected to dddc795 where the probe first lands).
2. Renamed the mislabeled schedule_cache_hit field to typecheck_cache_hit (it measured typecheck-memo movement, not schedule-retention cache occupancy) — code, doc comment, and receipt all updated; raw logs left unedited as captured evidence with a note explaining the rename.
3. Reworded the receipt's artifacts section to match the in-code scaffold/dissolve-on framing instead of promising indefinite reuse.

No measurement data or the REJECT verdict changed.

— sent from valiant-deer-205

[gunbai-bot]

CI failure on 286332a (run 30785110919) is not a defect in this PR's diff.

The build job fails on cargo check -p v1-compiler-tests --tests with E0061 (v1_generic_params_needing_clone_bound called with 6 args, needs 9) at src/v1/stage0/src/v1_compiler_emit_rust.rs:14088. That call site is correct (9 args) on this branch's own head — git show 286332a:src/v1/stage0/src/v1_compiler_emit_rust.rs has no such bug. main's current tip (bad325547e8) has the identical break, and pull_request CI checks out github.sha, which resolves to the PR's auto-merge-with-main commit, not the branch head — so main's breakage leaks into every open PR's build job right now, independent of each PR's own diff.

Two PRs are already in flight fixing this on main: #7733 and #7734. I won't duplicate that fix here (this leaf is scoped to the P1 retention receipt, not v1 emitter repair). Once main is green again, this PR's CI should pass on the next re-run/merge-ref refresh with no further changes needed here.

— sent from valiant-deer-205

[gunbai-bot]

Review 47844 verified and fixed: group_wall_start/typecheck_compute_count() timing and the resolved_graph_hit subject-set scan (p1_cohort_seen_subjects insert/any) ran on every width-1 inline discovery-drain group regardless of GUNBC_P1_COHORT_RECEIPT — only the eprintln emission at the end was gated. Fixed in 131de86: the timing pair now uses p1_cohort_detail.then(...) and the subject-scan/hit computation is wrapped in the same if p1_cohort_detail gate as its emission, so the default production floor path (env unset) does none of this scaffold's work. Verified: cargo check -p v1-compiler --lib clean, cargo fmt --all --check clean. — sent from valiant-deer-205