Affected-set CI scoping: Move C (exclusion model) + Move B (execution corpus)

[briansrls]

Summary

Three moves to scope the CI floor's discovery so heavy execution witnesses run in a parallel-capped pool instead of serializing in the main corpus:

Move C (done): Migrate `FLOOR_DISCOVERY_EXCLUDES` to the `.dag` model as `witness_exclusion_substrings` in `dsl/gunbc/ci_layer_roots.dag` — the single authority for path exclusions. The Rust constant is now a named SCAFFOLD with a dissolution trigger. Added `ci_exclusion_proof_test.dag` (always-false sentinel) to prove the plan's exclusion path actually gates.

Move B (done): Split all 21 execution-class witnesses (classified by behavior: they execute programs/the compiler through the v2 pipeline) into `src/v2/test/claim/execution/` and expose them as a separate `execution_corpus_node` with `spawn_width_cap` derived from available headroom. Extended `RunnableDiscoveryBatch` with `exclude_substrings`, `discovery_scope_dirs`, and `spawn_width_cap` fields; updated the generated `std_realization_schedule.rs` to match.

Move A (tracked follow-on): Affected-set skip predicate — when the diff ∩ witness import closure is empty, skip the witness entirely. Separate PR after this merges.

Execution corpus scheduling and memory provisioning

`execution_corpus_node` runs after `floor_corpus_node` (not co-resident): a `ResourceDependsOn(floor → execution)` edge is added in `floor_corpus_exclusion_resource_edges`. Heavy gates (emit_host, regen_verify, source_root_ingest) depend on both corpus nodes, so they land in batch 3.

Batch structure:

• batch 0: compile gate
• batch 1: floor corpus (width capped by floor memory formula)
• batch 2: execution corpus (sequential after floor)
• batch 3: heavy gates + source_root_ingest (after both corpora)

`gunbc_ci_execution_corpus_available_width` computes headroom for execution running alone (no floor co-residency): (8589934592 − 1610612736) / 2147483648 = spawn_width_cap = 3.

Effective width today = min(plan_spawn_width=1, spawn_width_cap=3) = 1. `claim_executor` receives `spawn_width = gunbc_ci_floor_spawn_width` which currently returns the floor-only derived width (1). Wiring `gunbc_ci_floor_spawn_width` to `max(floor_width, exec_width)` — so the plan permits width 3 during the execution phase — is tracked as follow-up: plan-width binding for execution-corpus width-3 (node://adhoc-e188369a-643). That follow-up also renames `gunbc_ci_floor_spawn_width → gunbc_ci_plan_spawn_width` (misnomer: it returns the cross-corpus max, not the floor's width) and replaces `witness_floor_derived_width_at_runner_cap` with a real per-corpus memory-safety guard.

Move B standalone value: (a) enabling Move A's affected-set skipping on an isolated corpus node; (b) honest fail-closed provisioning with named dissolution trigger; (c) OOM prevention from sequential scheduling (no exit-137).

Witnesses moved to execution/

4 already there (self_host/, fold_assembly/) + 17 newly moved from manual/:
`add_arrow_eval_by_execution`, `bind_eval_by_execution`, `bind_round_trip`, `branch_eval_by_execution`, `branch_if_then_else_round_trip`, `dag_add_emit_round_trip`, `effect_io_eval_by_execution`, `emit_ingest_grammar_relation_round_trip`, `emit_ingest_python_same_language_round_trip`, `emit_ingest_type_decl_round_trip`, `emit_ingest_typescript_same_language_round_trip`, `loop_eval_by_execution`, `loop_round_trip`, `match_bool_round_trip`, `typescript_closure_emit_by_execution`, `typescript_enum_union_emit_by_execution`, `typescript_import_emit_by_execution`

Module paths updated from `v2.test.manual.` → `v2.test.execution.`. Importers in manual/ (bind_emit, branch_if_then_else_emit, loop_emit, match_bool_emit) and in execution/ (self_host_candidate_generation) updated.

Test plan

• CI floor: `claim_executor --source-root src/v2 --source-root dsl --plan-entry src/v2/workflow/ci_floor_plan.dag --plan-function gunbc_ci_floor_batches` — execution corpus runs as separate batch-2 node with spawn_width_cap=3 (effective=1 pending plan-width follow-up node://adhoc-e188369a-643); no exit-137 from sequential scheduling
• `regen_verify_gate`: `std_realization_schedule.rs` updated to match 8-field `RunnableDiscoveryBatch`; confirmed by CI batch-4
• `ci_exclusion_proof_test.dag` always-false sentinel proves exclusion path is live

[gunbai-bot]

Two fixes landed in d27f0cf in response to the §3/§5 checks:

1. None fallback removed — constant is now inert on the plan path

In claim_executor.rs, the None => FLOOR_DISCOVERY_EXCLUDES.iter()... fallback in runnable_from_value was the remaining live read of the constant on the floor path. Changed to None => vec![]: if a plan's RunnableDiscoveryBatch omits exclude_substrings, no exclusions apply (the plan author chose none — not a fallback to the Rust constant). The import of FLOOR_DISCOVERY_EXCLUDES was also removed from claim_executor.rs entirely, so the constant is structurally unreachable from the plan-driven path.

Remaining live reads of the constant: claim_batch.rs (pre-push hooks only, not the floor runner), DiscoveryCorpusOptions::default() (test call sites in pipeline.rs and wet_hermetic_equivalence_test.rs). These are non-floor paths; the SCAFFOLD dissolution covers them.

2. Discriminating probe — §5 by-execution proof that model is the authority

Added "ci_exclusion_proof_test.dag" to witness_exclusion_substrings in ci_layer_roots.dag (NOT added to FLOOR_DISCOVERY_EXCLUDES). Created dsl/test/claim/ci_exclusion_proof_test.dag with test fn ci_exclusion_proof_sentinel() -> Bool = false — a test that always fails if discovered.

The two authorities now intentionally differ on one entry. CI green-by-execution is the proof: the probe is excluded (→ CI passes) only because the model is doing the exclusion. If the constant were the authority (it lacks the sentinel), the probe would be discovered and CI would fail red.

Removing "ci_exclusion_proof_test.dag" from the .dag would re-include the probe and red CI — this is the RED control. The probe file is now a permanent fail-closed sentinel for the exclusion mechanism.

— sent from merry-fox-653

[gunbai-bot]

Addressing the cursor/composer-2.5 review findings:

Finding 1 (sentinel not in FLOOR_DISCOVERY_EXCLUDES): Valid. Added \"ci_exclusion_proof_test.dag\" to FLOOR_DISCOVERY_EXCLUDES in this commit so the claim_batch pre-push path doesn't enroll and run the always-false sentinel. The discriminating proof for the plan path is carried structurally by the None => Vec::new() change in claim_executor.rs (not by the sentinel being absent from the Rust mirror). The sentinel proves the .dag model is the authority for the plan path because it's excluded there; the Rust mirror stays in sync as a SCAFFOLD.

Finding 2 (fields without consumers): The reviewer was reading the WIP commit where corpus_runnable() hadn't yet been extended with discovery_scope_dirs / spawn_width_cap. Both fields now have consumers: corpus_runnable() sets discovery_scope_dirs: [] and spawn_width_cap: 0; execution_corpus_runnable() sets discovery_scope_dirs: [\"src/v2/test/claim/execution\"] and spawn_width_cap: execution_corpus_spawn_width(); runnable_from_value in claim_executor.rs reads both; run_batch_unit applies the cap; run_discovery_corpus_with_options passes options.discovery_scope_dirs.

Finding 3 (discover_floor_corpus_rows_scoped no call sites): Already addressed before the cursor review — run_discovery_corpus_with_options calls it at cli_run.rs:3311.

— sent from merry-fox-653

[gunbai-bot]

Both findings are valid — fixed in 57a5487.

Finding 1 (OOM / co-resident memory math): The exit-code-137 CI failure confirms it. gunbc_ci_execution_corpus_available_width was subtracting floor_per_shard_peak to account for co-residence, but both corpus nodes were in the same batch-2 and ran concurrently at full parallelism inside claim_executor, which broke the assumption. Fix: add ResourceDependsOn(source: floor_corpus_node, dependent: execution_corpus_node) in floor_corpus_exclusion_resource_edges so execution runs sequentially after floor. With sequential scheduling the floor shard is done before any execution witness starts — no subtraction needed. Updated formula: available = runner_cap - executor_base = 8 GiB - 1.5 GiB = 6.5 GiB → width = floor(6.5 / 2) = 3.

Finding 2 (gate resource exclusion gap): runnable_excludes_corpus_co_residence gates only had a ResourceDependsOn edge from floor_corpus_node. With the new sequential ordering they'd still co-run with the execution corpus. Fix: floor_corpus_exclusion_resource_edges now emits two edges per qualifying gate — one for floor_corpus_node and one for execution_corpus_node. Heavy gates now wait for both corpora before starting.

— sent from merry-fox-653