/nw-throughput

name: nw-throughput
description: Evidence-led orchestration for maximizing delivery throughput with independent fan-out, capacity-bounded local test runs, long runs batched off the box, and concise whole-value evidence.
user-invocable: true

nw-throughput

Before diagnosing or assigning corrections, load `nw-cross-cutting-invariants` and apply `delivery:trustworthy-baseline-and-repair-scope`. A blocking observation requires attention; it does not alone authorize an independent repair.

Load `nw-cross-cutting-invariants` and apply `flow:findings-go-to-the-owner-directly` when dispatching or coordinating roles.

Constraint

The bottleneck is usually the shared machine or a causal boundary, not the number of available agents. Keep cloud reasoning busy; the local constraint is usually machine capacity (often memory, then CPU), not exclusivity. Measure which resource saturates, and stop adding lanes when contention increases end-to-end wall time.

Strategy

1. Select the nearest measurable constraint and shortest falsifier. 2. Fan out only independent work with disjoint ownership in detached worktrees; apply the worktree lifecycle below when creating or inheriting a lane. A pending owner answer blocks only the work that depends on it; see nw-auto §4. 3. Admit local test runs by capacity, not by one exclusive lock. Before each admission, the operator checks current box-wide load, including launchers outside the queue, and the headroom of any existing shared process, container or scope cap that bounds the lanes. Gate on `MemAvailable`, not `MemFree` or load: judge whether current capacity covers the run about to be admitted alongside work already running on the box. A shared cap gets the same judgement: its current headroom must comfortably cover the run. Admission is a judgement on current capacity and observed contention, not arithmetic over recorded peaks; there is no recorded floor to consult. A single run passes the same check. Check the measured binding resource too: defer CPU-saturating work when it would increase end-to-end wall time or starve focused runs. This is operator practice, not atomic reservation accounting: no box-wide reservation mechanism exists here, and per-worktree locks cannot provide one. One operator coordinates admissions across lanes; independent operators must coordinate before launch because a load snapshot alone cannot prevent races. Keep exclusivity only for a resource shown to be shared and mutable. Never run the whole suite locally; keep reproductions bounded and respect Git-write restrictions. When test-impact selection (rule 5) selects the whole suite, including when it cannot decide and so selects every test, or local capacity forbids running the selected set, dispatch the complete selected set to CI instead; never silently narrow the selection to fit, and report the change as unverified until that run returns, or for as long as no CI capacity can run it. Starving the box can kill other lanes' work and can corrupt `.git`. An OOM-killed run is INDETERMINATE, never a red. 4. The operator orders waiting runs shortest first (RED, GREEN, focused tests before broad runs), with aging: after a broad run waits 1200 s (Ale's chosen bound), it goes next and nothing behind it starts until it fits. Never preempt a running test. This is a manual queue policy, not an implemented gate. 5. Minimize broad local runs. Do not rerun a broad scope locally once per commit or per slice. Commit with the focused checks and batch related slices. The focused checks are the tests a reliable test-impact analysis selects over the change (dependency-affected tests), run locally within rule 3 or, when rule 3 forbids the selected set, as one complete CI run; the default CI suite (300 s unless a repository ADR sets another) and each feature's infrastructure suite at its declared trigger run the rest (`test:feedback-loop-budget` in `nw-cross-cutting-invariants`). In existing Request context, state a maximum batch size before accumulating commits; close the batch at that limit or at the end of the Request, whichever comes first. The operator then dispatches one broad run by hand on CI capacity outside the contended machine before publication. Self-hosted CI on the same box is local capacity, not off-box capacity. If no off-box capacity exists, run the batch's impact-selected tests once locally as the only broad run, subject to rules 3 and 4; a selection rule 3 sends to CI never runs locally and the batch stays unverified until CI capacity runs it. A red broad run names its failing tests. Keep the other work moving. Keep CI/CD health a standing responsibility: for each red batch open one short-lived CI-recovery lane with a stated deadline in existing task context. Classify every failure first, fix pipeline and test-infrastructure defects there, and route a product or oracle regression to the Request that owns it. Keep that owner reachable until batch verification; a closed Request must be reopened or receive an explicit successor owner, not silently lose the defect. Close the recovery lane when the batch is green or its deadline is reached; at the deadline transfer unresolved work with preserved evidence and a named owner under the worktree lifecycle below. Transfer is not resolution. A red broad run never ends by being ignored: promoting a build to a release requires the whole broad run green on that exact build. The batch run attests the batched candidate, not each commit inside it. 6. Fan in on the whole delivered value. Keep the final whole-candidate review, source-blind EXAMINE, integration, observation and cleanup; the orchestrating LLM chooses and invokes them, while nwdes constructs the canonical handoff and briefs. 7. Measure wall time, queue wait versus service time per run class, peak memor