/workflow complexity-gate

Run it as /workflow complexity-gate <the scope: the module, path or entry point you think is scaling badly, and the workload you care about>.

The pipeline's most valuable output is a refusal to optimise. Stage 2 measures the noise floor on your actual hardware and states the Amdahl ceiling of the top hotspot, and when that ceiling sits at or below the floor it halts: nothing you could change there is distinguishable from noise on this machine, so nothing should be changed there. A halt is fatal rather than resumable, which here is the correct shape — no answer from a person makes an unmeasurable change measurable — and it short-circuits every later stage, so the write-lane role is never dispatched at all. Not gated, not asked to behave: never given a turn. That is a lane-level guarantee, not a prompt.

Stage 2 halts the same way when no harness can be built. A pipeline that optimises against a fixture nobody could construct reports invented numbers, and reporting nothing is strictly better.

Stage 3 is the only write-lane step in the pack, and it is worth knowing before you run this that its diff is captured and replayed into your real checkout when the step succeeds — so the change is in your tree before stage 4 has said whether it did anything. It is one hypothesis, one change, uncommitted, and stage 4 tells you whether to keep it.

Measurement and adjudication never sit in the role that wrote the change. Stages 2 and 4 are the same measuring role and stage 3 is a different one, and the split is checkable from the tools: lines rather than from anything either role promises: the optimiser holds write and edit, the analyst holds neither, and no prompt in this pipeline can move either of them.

Stage 4 reconstructs both arms of the comparison inside its own worktree and interleaves them. It cannot reuse stage 2's baseline number, and the reason is mechanical: every lane worktree is created from a commit and seeded with the run's state under the checkout's own ignore rules, so build output, package directories and every warm cache stay out. Each stage builds cold, with a different cache state and different neighbours on the machine. Stage 4 rebuilds the baseline by reversing the change record's own verbatim diff, which is why stage 3 is required to paste it.

The run is fully sequential and each stage genuinely needs the last: candidates with their n-sources, then a floor and a ceiling, then one change, then a verdict against the floor. There are no parallel branches, so there is no partition to state.

Under plan mode this pipeline fails at stage 1 before a token is spent. Every step here dispatches on the exec or write lane and plan mode has neither, so /workflow warns about all three roles up front and the first step is refused rather than run. Approve the plan or leave plan mode. Under an ordinary permission mode the same pre-flight warns that the run will stop for your approval as those steps come.

The pipeline ends at a person, in a DECISION-REQUEST block rather than an ORG-ASK. A question asked at the final stage buys nothing — there is no later stage for an answer to be spliced into — and the engine replaces an asking step's output text with the answer on resume, so pausing at the end would overwrite the adjudication packet with a sentence. Nothing in this pipeline merges, commits, tags or pushes anything.