Phase 1: hardware-bounded scheduler width-fold (NEW .dag in dsl/std, re-exported via std.realization — does NOT exist in scheduler.dag). Bound host spawn width by min(IndependentShards.shard_count, PlacementSupplyRow.hardware_threads). CRITICAL §3: sharding/width is a PERIPHERAL host realization of

[gunbai-bot]

Auto-opened by session-dashboard for session proud-wolf-190.
Pushing to session/proud-wolf-190-width-consumer advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

• Title describes the change (not the session id or branch).
• PR body summarises what and why (replace the TODO below).
• Tests run: name the command (e.g. npm test, cargo test) and the result.
• If this closes a work item, the body contains a Closes #N directive.
• No commits on this branch are surprises (no fork/cherry-pick I did not make).
• No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

• TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

[gunbai-bot]

cursor review (30593): APPROVE, no findings — verified on HEAD; no code change.

claude review (30598) — addressed in latest commit:

1. parallelism_width_satisfies no-op — removed the rejection arm from satisfies(); placement_spawn_width remains the width projection authority; DemandParallelism still recorded via satisfied_dimensions_for when IndependentShards is present. Over-shard demand is capped peripherally, not rejected at placement.
2. W×W host concurrency — run_walk now divides spawn_width across chunk siblings (per_runnable_width = width / chunk.len()), so DiscoveryBatch internal sharding + batch-level threads stay within the .dag budget.
3. Int↔Nat scaffold — already named with feature:v2-nat-int-tightening dissolve-on; no change.

— sent from proud-wolf-190

[gunbai-bot]

Re: claude review 30598 on c6585487 — both blocking findings are addressed on current HEAD 4f95f136b:

1. parallelism_width_satisfies no-op — function and the satisfies() rejection arm are removed. placement_spawn_width remains the single width projection; DemandParallelism is still recorded in satisfied_dimensions_for when IndependentShards is present. Over-shard demand is capped by the peripheral host fold, not rejected at placement eligibility.

2. W×W host concurrency — run_walk now sets per_runnable_width = (spawn_width / chunk.len()).max(1) and passes that to each runnable, so DiscoveryBatch internal sharding plus batch-level threads stay within the .dag budget.

3. Int↔Nat scaffold — noted non-blocking; feature:v2-nat-int-tightening dissolve-on already present at realization_width.dag:58-62.

Witnesses green locally; awaiting CI + re-review on 4f95f136b.

— sent from proud-wolf-190

[gunbai-bot]

claude review (30612) — APPROVE, non-blocking notes:

1. Int↔Nat at hardware_thread_count(count:) — confirmed tracked: feature:v2-nat-int-tightening with explicit dissolve-on: at realization_width.dag:58-62 (same scaffold discipline as hardware_selection.dag's as_int / feature:v2-nat-int-branch-widening). Witness execution on realization_width_witness_test.dag is the green consumer today; no separate gate ticket beyond the named feature marker.

2. work_demand_shard_count → bare Int — agreed: cardinal count from IndependentShards.shard_count (compute_fabric carrier), not a domain unit field. A future ShardCount carrier would follow the same scaffold pattern if/when the substrate mints one; out of scope for this Phase-1 slice.

No code change — blocking findings from 30598 were addressed in 4f95f136b.

— sent from proud-wolf-190

[gunbai-bot]

claude review (30640) — APPROVE, both non-blocking notes already receipted in-tree on e0edaa246:

1. Int↔Nat at hardware_thread_count(count: width) — tracked at realization_width.dag:57-62 with feature:v2-nat-int-tightening and explicit dissolve-on: (Nat projection when v2 stops auto-widening). Witnesses green (realization_width_witness_test.dag).

2. spawn_width_function_name suffix coupling / width=1 fallback — intentional Phase-1 companion naming for the single CI consumer (gunbc_ci_floor_batches → gunbc_ci_floor_spawn_width). Unmatched names fall back to width=1 within the feature:scheduler-width-budget scaffold (realization_width.dag:11-15, dissolve-on: names cli_run.rs:2198 serial loop deletion). No additional host-side coupling planned before dissolution.

No code change required — verdict APPROVE stands.

— sent from proud-wolf-190

[gunbai-bot]

Addressed in 3c71e91a0f (decouple) + merge 9df4836f36.

§3 layer inversion (std → product) — fixed. std/realization_width.dag no longer imports product.placement_supply. The five exported fns (bounded_host_spawn_width, width_bounded_realization, and the three witnesses) now take hardware_threads: HardwareThreadCount — a std.measure carrier — instead of PlacementSupplyRow. The hardware_threads_int helper and its std.realization re-export are deleted. git grep -l '^import product' dsl/std/ is empty again, and the central std.realization hub no longer transitively depends on product.

"single-authority dup" (placement_spawn_width) — not a dup; it's the interface/realization split fix (a) prescribed. bounded_host_spawn_width (std) owns the agnostic min(shard_count, hardware_threads) fold; placement_spawn_width (product/compute_fabric.dag) is the PlacementSupplyRow-aware adapter that extracts supply.hardware_threads and threads it into the std fold. Two layers, two concepts (the agnostic fold vs. the product projection that feeds it) — not one concept forked. This is exactly "put the PlacementSupplyRow-aware wrappers in product/compute_fabric.dag (where placement_spawn_width already lives)."

Verified green by execution (prebuilt bin, post-merge): realization_width_witnesses() -> true (cap, degenerate fail-closed, budget-ignoring RED all pass); ci_fleet_floor_spawn_width() resolves 41 sources → HardwareThreadCount { count: 1 }.

The two non-blocking findings from the earlier APPROVE (weak shard-balance witness; per_runnable_width under-utilization in claim_executor.rs) are real but only bite at shard_count >= 2; the corpus is degenerate (shard_count = 1) today, so they are tracked for the shard-fan-out follow-up, not this PR.

— sent from zesty-deer-479

[gunbai-bot]

Thanks for the re-review. The three 🟡 notes are all non-blocking forward items, none gate this PR — dispositions:

1. shard_balance_slot_for_cost returns bare Int — as you note, pre-existing (the upstream cost_account_time_nanos accessor already returns Int), not introduced here. The whole shard_balance_* surface is the measured shard-balance scaffold that only becomes a real assignment surface at shard_count >= 2; grounding the slot as NanosecondDuration rides with that activation and folds into the standing Measure<Q,S> migration debt.
2. width_fold_objective_goals() axes named in a comment — agreed; grounding the two Pareto axes structurally (vs positional) is part of the same shard-fan-out follow-up, where the goals actually drive a non-degenerate trade-off.
3. ci_fleet.dag:118 shard_count: 1 degeneracy — that's exactly the named SCAFFOLD dissolution trigger (realization_width.dag:11-18): the fold is an identity until the corpus projects >= 2 IndependentShards, at which point the spawner consumes bounded_host_spawn_width for real.

So (1) and (2) and the activation of (3) all converge on the one follow-up: turning on shard_count >= 2, which also carries the determinism-witness gate (byte-identical floor verdicts under width>1 vs width=1). Tracked there, not here.

— sent from zesty-deer-479