feat(brainstorm): swarm-simulated discovery replacing the serial interview

Replace brainstorm's ~10 serial user round-trips with a parallel
populate-then-triage: enumerate the load-bearing forks, populate them with a
grounded synthetic-user swarm (mandatory per-answer citation), and triage — a
fork the swarm settles on a cited shared ground is decided (user vetoes), a
split or ungrounded-consensus is a direction fork the user settles. A
cross-check surfaces any fork the orchestrator's own enumeration held open but
the swarm closed. A fire-check + grounding floor skip the swarm when it would
be ceremony.

Under /boss the swarm runs autonomously: convergent forks are decided and
recorded on the reference issue, only a divergent direction fork (or a
sub-floor greenfield design) bounces. Retires trigger-4's "fresh brainstorm is
too high-context to run autonomously" rationale — the swarm is the compaction.

- brainstorm/agents/synthetic-user.md: new read-only swarm agent
- brainstorm/SKILL.md: full rewrite to the swarm flow + new Iron Law
- boss/SKILL.md: autonomous swarm-brainstorm (Iron Law, trigger 4, asymmetry,
  notifications, rationalisations, red flag)
- docs/pipeline.md: brainstorm phase description
- specify/SKILL.md: brainstorm characterised as swarm discovery, not interview

closes #19

boss/SKILL.md

@@ -56,7 +56,9 @@ re-enters by typing `/boss` again.
 NO AUTONOMOUS DISPATCH OUTSIDE A `/boss` SESSION.
 DONE-STATE = QUEUE EMPTY, NOT SUB-GOAL COMPLETE.
 BOUNCE-BACK ONLY ON THE FOUR NAMED TRIGGERS.
-A NEW CYCLE NEVER STARTS AUTONOMOUSLY — IT IS A BOUNCE-BACK.
+A NEW CYCLE'S DESIGN RUNS AUTONOMOUSLY VIA THE `brainstorm` SWARM — IT DECIDES
+  THE CONVERGENT (CITED-GROUND) FORKS AND BOUNCES ONLY A DIVERGENT DIRECTION
+  FORK OR A GREENFIELD DESIGN BELOW THE SWARM'S GROUNDING FLOOR.
 ```
 
 Universal rules (only-orchestrator-commits, main-is-sacrosanct,
@@ -144,10 +146,12 @@ route(task):
   autonomously, as a bug issue already is.
 - **Forces a genuine design choice → `brainstorm`.** Writing the work
   down would force a choice between two or three plausible designs with
-  real trade-offs. Discovery must resolve it first. Starting a fresh
-  `brainstorm` cycle is itself a bounce-back per §"Direction freedom"
-  trigger 4 — green-light the cycle (and the session shape) with the
-  user first.
+  real trade-offs. Discovery must resolve it first — and `brainstorm` now
+  **dispatches autonomously**: its synthetic-user swarm decides the forks it
+  can settle on a cited shared ground (recorded on the reference issue) and
+  bounces only a genuine divergent direction fork, or a greenfield design
+  below its grounding floor, per §"Direction freedom" trigger 4. A fresh
+  `brainstorm` is no longer a blanket pre-dispatch bounce.
 - **A type/signature edit at a definition site, propagating mechanically
   → `compiler-driven`.** The positive trigger is *syntactic and
   observable*: a carrier/newtype narrowing, a constructor or field
@@ -187,13 +191,17 @@ whose handling is a new code path with new observable output — is
 which side a change falls on, that doubt is itself the signal it carries
 behaviour: route up to tdd/spec, not down to compiler-driven.
 
-The asymmetry in autonomy — `debug`, `compiler-driven`, `tdd`, and
-`specify` all dispatch autonomously, while a fresh `brainstorm` cycle
-bounces back — is **not** a ranking of the paths. It is a consequence of
-context budget: the four are bounded (no open Q&A; `compiler-driven` and
-`debug` self-settle on a run), whereas a fresh `brainstorm` is
-high-context discovery the orchestrator cannot compact on its own (see
-trigger 4). `specify` dispatched in `/boss` signs through its own Step-6
+Every entry path now dispatches autonomously — `debug`, `compiler-driven`,
+`tdd`, `specify`, and `brainstorm` — and what differs is only *what each
+bounces on*, not whether it runs. The old asymmetry (a fresh `brainstorm`
+bouncing before it starts) rested on context budget: a serial-interview
+`brainstorm` was high-context discovery the orchestrator could not compact on
+its own. The swarm retires that rationale — it IS the compaction: the
+orchestrator gets back a triaged populated space, not a 10-round interview
+transcript, so `brainstorm` decides the forks the swarm settles on a cited
+ground and bounces only a divergent direction fork (or a greenfield design
+below its grounding floor — see trigger 4). `specify` dispatched in `/boss`
+signs through its own Step-6
 gate — the Step-5 `grounding-check` `PASS`, an independent agent's
 verdict against currently-green tests, not the orchestrator's confidence;
 the run then continues to `planner` without pausing. A no-override
@@ -220,8 +228,10 @@ All entry paths are always available — none is profile-gated. The
 cascade is the order of decision: the lighter arms (`debug`,
 `compiler-driven`, `tdd`) carry positive triggers and dispatch
 autonomously, `specify` dispatches autonomously and pauses at its
-sign-off gate, and a fresh `brainstorm` is the one path that bounces
-back to the user before it starts.
+sign-off gate, and `brainstorm` dispatches its swarm autonomously —
+deciding the forks it can settle on a cited ground and bouncing only a
+divergent direction fork (or a greenfield design below its grounding
+floor).
 
 If the working tree is mid-flight (uncommitted changes left over
 from a previous session): inspect first, then resume the right
@@ -373,24 +383,28 @@ Bounce back to the user only when:
   project's direction (a fundamental design flaw, an external
   dependency failure, a discovered invariant violation).
 - The user has explicitly asked for a checkpoint.
-- **The next item on the queue is a new cycle** — i.e. a top-
-  level work container (a milestone) that has no spec file yet and
-  would require dispatching `brainstorm` to even begin.
-  Continuing an open cycle (next iteration, audit, fieldtest,
-  post-audit tidy) is autonomous; *starting* a new cycle is a
-  bounce-back.
+- **The `brainstorm` swarm surfaces a divergent direction fork.** A new
+  cycle's design runs autonomously through the `brainstorm` swarm, which
+  decides the forks it can settle on a cited shared ground and records them on
+  the reference issue. What bounces is the residue: a fork the swarm splits on,
+  or agrees on with no citable ground (ungrounded-consensus), or one the
+  orchestrator's own Step-2 enumeration held open — a genuine **direction
+  fork** only the user's preference can settle. A greenfield design *below the
+  swarm's grounding floor* (no ledger to cite against) likewise bounces,
+  because the swarm cannot run honestly and the work needs a human interview.
+  Continuing an open cycle and *starting* a new one are now both autonomous up
+  to this residue.
 
   **Why this is different from the other three triggers.**
-  Cross-cycle work is high-context work. A fresh brainstorm
-  alone routinely consumes tens of thousands of tokens on
-  grounding-check reads, design Q&A, and spec drafting — on top
-  of whatever context the just-closed cycle left behind. The
-  orchestrator cannot compact its own context window; only the
-  user can decide that the right shape for the next cycle is a
-  fresh session rather than a continuation. A new cycle is
-  therefore the natural checkpoint: stop, surface the
-  candidate, let the user pick the session shape (continue here
-  / spawn fresh / defer / pick a different backlog item).
+  This is the design-judgement checkpoint the swarm cannot discharge. The
+  swarm compacts the discovery — the orchestrator gets back a triaged
+  populated space, not a high-context interview transcript — so the old "a
+  fresh brainstorm is too high-context to run autonomously" rationale is
+  retired (the swarm IS the compaction). What stays genuinely the user's is
+  the direction fork itself: a choice no source settles, where a guessed
+  default is the reactive-overreach the discipline forbids. Surface it as a
+  vetoable problem-state notify naming, in the user's terms, the design choice
+  that needs them; the convergent decisions ride along on the reference issue.
 
 A summary of what shipped is fine and welcome — but in
 autonomous mode, follow it with the next dispatch, not a
@@ -416,8 +430,9 @@ narrow one for spec auto-sign:
    freedom" — design fork the orchestrator cannot resolve, an
    unexpected invariant violation, an external dependency
    failure, the user has explicitly asked for a checkpoint, or
-   the next backlog item is a new cycle (no spec yet) and
-   starting it would force a fresh `brainstorm`.
+   the `brainstorm` swarm surfaced a divergent direction fork
+   (or a greenfield design below its grounding floor) that needs
+   the user's call.
 
 3. **Auto-sign.** The
    orchestrator signed a spec in the user's place and is
@@ -667,13 +682,13 @@ the user wants it — there is no autonomous filing to govern.
 | "Top of the backlog has two equally good options, I'll just pick one" | If both are substantive and the choice is non-obvious, that's a real fork — bounce back. The cost of a wrong pick (working-tree discard) is higher than the cost of one short ping to the user. |
 | "User said 'until X then notify', X just completed, notify now" | Check whether X was actually the last actionable thing. If hitting X leaves an open cycle with obvious follow-up, the user's intent was "wake me when there's nothing else to do" — continue. |
 | "Notify can name the iteration code — user will figure out what it means" | No. The notify text is for the user-as-reader who did not watch the orchestrator work. Iteration codes, crate names, function identifiers, type names — all internal, all banned. |
-| "The previous cycle closed cleanly and the next backlog item is obvious — just dispatch `brainstorm` and keep going" | No. Starting a new cycle is itself a bounce-back. A fresh `brainstorm` is high-context work, and the orchestrator cannot compact its own context — only the user can decide whether the next cycle wants a fresh session or a continuation of this one. The "obviousness" of the candidate is irrelevant; the *cross-cycle hop* is the checkpoint, not the topic choice. |
-| "It's the same broad area as the cycle I just closed, that's not really a new cycle" | If there is no spec file for it yet and it would route through `brainstorm` to get one, it IS a new cycle for this rule's purposes. The rule keys on "needs a fresh spec", not on subjective continuity. |
+| "The previous cycle closed cleanly and the next backlog item is obvious — just dispatch `brainstorm` and keep going" | Dispatching `brainstorm` IS now the autonomous move — its swarm decides the forks it can settle on a cited ground and records them. What you may not do is auto-decide a *divergent direction fork* the swarm could not ground; that bounces. Dispatch the swarm, decide the convergent forks, bounce only the residue. |
+| "The swarm all converged, so I can auto-decide the whole design and move on" | Only forks converged on a *cited shared ground* are decided. Same-model stances agreeing with no citable ground is ungrounded-consensus — a direction fork that bounces, not a decision. Auto-deciding bare agreement is the false-convergence trap that ships the user's once-per-project fork past them. |
 | "Feature work, so route it to `brainstorm` — that's the safe default" | The entry paths are an ordered cascade, none the default. Routing a settled design to `brainstorm` re-litigates decided choices; routing a test-specifiable item there wastes the test path; routing a behaviour-preserving type-edit there is the heavy-path gravity well this whole reflection exists to break. Walk the cascade and take the first matching positive trigger. The only tilt toward `brainstorm` is a genuinely unresolved fork — and that is a fork, not a default. |
 | "It's just a mechanical rename across N files — run the full implement loop on it" | That is the `compiler-driven` arm's job, not the heavy loop. Route it there; the type checker enumerates the sites, and the done-signal (clean build AND suite green unchanged) is the gate. Funnelling a behaviour-preserving edit through the full per-task loop is the disproportionality the cascade was added to fix. |
 | "The compiler-driven edit built clean — that's the done-signal, commit" | Clean build is only half. The done-signal is clean build **AND suite green unchanged**. A behaviour change can build clean; the unchanged-green suite is what catches it. No suite run, no commit — and if the suite isn't green-unchanged, bounce to `debug`. |
 | "It's a bug but the fix is a one-line type edit — route it `compiler-driven`" | No. An observed bug is first in the cascade → `debug`, RED-first, regardless of how mechanical the fix looks. The bug-gate sits before the type-edit arm precisely so a regression cannot launder itself around RED-first. |
-| "The issue is exhaustive but it's a new cycle, so bounce to the user before `specify`" | `specify` direct-entry is bounded and autonomously dispatchable — it is NOT the high-context `brainstorm` cycle that trigger 4 reserves for the user. Dispatch it; it will pause at its own user-review gate for sign-off. The pre-dispatch bounce is for an *open* design that needs discovery, not for a settled one that needs only production. |
+| "The issue is exhaustive but it's a new cycle, so bounce to the user before `specify`" | `specify` direct-entry is bounded and autonomously dispatchable — a settled design needs production, not discovery; don't route it through `brainstorm` at all. And even an *open* design no longer blanket-bounces: its swarm runs autonomously and bounces only a divergent direction fork. The bounce is for an unresolved *direction*, never for "it's new". |
 | "`tdd` is the secondary skill, `brainstorm` is the real entry" | All entry paths are always available. The choice among them is the cascade, walked per item — not a habit of treating `brainstorm` as primary and the lighter arms as exceptions. The lighter arms exist to be reached; reaching past them by elimination is the failure the verification axis was added to prevent. |
 | "This spec is clearly good — I'll sign it on my judgement" | Your judgement is not the signature; the Step-5 `grounding-check` `PASS` is. Run grounding and sign on the PASS. A no-override grounding `BLOCK` routes to the human — never signed over on confidence. (The old unanimous `spec-skeptic` panel is retired; do not re-introduce it as a gate.) |
 | "There's an open fork — I'll bounce to `brainstorm` to be safe" | If you can *derive* an answer (sources, code, consistency, risk), decide it boldly and record it in the reference issue. Only a *pure-preference* fork bounces. Bouncing a derivable fork is exactly the timidity the bold stance retired; unsure if your leaning is bias, pull one ad-hoc `spec-skeptic` lens, then decide. |
@@ -692,7 +707,7 @@ the user wants it — there is no autonomous filing to govern.
 - About to autonomously dispatch in a session where the user did NOT type `/boss`.
 - About to send a notify that names a crate, an iteration code, or an agent.
 - About to bounce back at every iteration boundary "just to be safe" — that's reactive deference, not direction freedom.
-- About to dispatch `brainstorm` on a backlog issue that does not yet have a spec file, without first bouncing back to the user. New cycles never start autonomously.
+- About to *auto-decide* a divergent direction fork the `brainstorm` swarm could not ground (or could only agree on with no citable ground) instead of bouncing it — or, conversely, bouncing the whole fresh `brainstorm` "to be safe" instead of running its swarm autonomously and bouncing only the divergent residue.
 - About to route feature work to `brainstorm` without walking the Entry-path cascade — defaulting to it because it "feels safer" than the lighter arms, rather than taking the first matching positive trigger. Routing a *settled* design, a *test-specifiable* item, or a *behaviour-preserving type-edit* to `brainstorm` is as much a failure as skipping discovery on an open one.
 - About to route an observed bug to the `compiler-driven` arm because "the fix is mechanical" — a regression is `debug`, RED-first; the bug-gate is first in the cascade for exactly this reason.
 - About to route a behaviour-encoding change to `compiler-driven` because it "looks mechanical" — apply the straddle rule: if the change encodes new behaviour it is `tdd` / `spec-driven`, and doubt means it carries behaviour.