@underactive/pi-topping-moa-fusion 0.1.0 → 0.3.0

package/CHANGELOG.md

@@ -1,5 +1,59 @@
 # Changelog
 
+## [Unreleased]
+
+## [0.3.0]
+
+### Added
+
+- Added `/mf-spec`, an in-process requirements-clarification flow that asks up to five focused questions, reviews and saves approved `__spec.md` planning briefs, and prepares a `/mf-plan` handoff without exposing specs to `/mf-plan-implement`.
+- A hidden `mf-plan-verification-pending` session marker now records when an approved implementation is expected to enter independent verification. Resuming before a verifier result is recorded warns that the implementation is still unverified.
+
+### Changed
+
+- Updated all four pi development dependencies from 0.86.0 to 0.87.0.
+- The pi 0.87 settle-boundary context-edit and verification-marker integrations are capability-gated and remain inert on older hosts, which retain the existing request-time filtering and verification dispatch behavior.
+
+### Fixed
+
+- An assigned slot in the MoA Fusion Pre-flight overview can now be cleared back to `(none)` with Backspace or Delete. Previously a slot could only be reassigned to another model, never emptied.
+- Reusable `[PLAN MODE ACTIVE]` and `[PLAN MODE RE-ENTRY]` instruction entries are now durably omitted with settle-boundary null context edits after plan-mode exit, preventing later compaction from carrying stale plan instructions into implementation.
+- Custom OpenAI-compatible endpoints used by proposers and verifiers now benefit from pi 0.87's upstream strict-schema capability fix: unknown endpoints no longer receive strict tool schemas unless they explicitly advertise support.
+- Saving or deleting an agent roster now takes effect immediately, without requiring a second save from the main settings overlay.
+- A failed agent's error is now readable in full without widening the terminal. Provider failures were cut to 80 characters before reaching the progress table and then truncated again at the ACTIVITY column edge, hiding the part naming the cause. The message is now kept whole and word-wrapped beneath its row — breaking the JSON payload mid-token when it has no spaces to break on — while a short error stays inline as before.
+
+## [0.2.0]
+
+### Added
+
+- A `Naming the plan`/`Naming the opinion`/`Naming the debate` working overlay while the cheap/fast model summarizes a submitted prompt into its slug, so the TUI no longer sits unresponsive during that call. Press **Esc** to skip naming and fall back to a name derived from the prompt.
+- Panel dependence note in the synthesizer input: a blinded summary of proposal count, distinct models, and same-model clusters so agreement is weighted by dependence, not vote count alone.
+- Pre-flight and replacement-time diversity warning when proposer slots share a model or provider, reminding that agreement between them is not independent evidence.
+- Evidence-backed vs asserted tags in synthesizer `### Proposer alignment`, plus distinct-model support counts on conflict recommendation Details lines.
+- Configurable `maxConcurrentAgents` setting (1–8, default 1) for MoA, opinion, debate, and plan subagent fan-outs.
+- Configurable `maxVerificationRepairs` setting (0–5, default 2) for verifier-driven implementation repairs. When repairs are exhausted or disabled, a `.pi/mf-plan/<slug>__verification-handoff.md` file is written with every criterion's status, the full frozen checklist, gaps, and guidance to continue verification manually — and its path is named in the exhaustion notification.
+- Cancelling a single proposer from the MoA cancel overlay now prompts, once the fan-out settles, to replace that slot with a different model or continue without it, instead of silently dropping the proposal and proceeding with the survivors. **Cancel ALL** (including during a replacement run) still aborts the run.
+
+### Fixed
+
+- Resuming, forking, or `--continue`-ing a session saved mid-plan no longer leaves the implementer with a read-only tool loadout after approval. The pre-plan-mode loadout is now persisted with the plan state.
+- Subagent runs no longer log two spurious `event parse error: invalid session event` lines per run. pi 0.86.0's `system` wire messages are accepted instead of leading every failure report.
+- Typechecking against pi 0.84.3 and newer declarations.
+- Remove trailing ellipses from status labels.
+- Correct progress timing and running counts for agents waiting in the concurrency queue.
+- Show concurrency-limited fan-out agents as queued until they acquire a process-pool slot.
+- Use success colors for positive verification notices instead of warning colors.
+
+### Changed
+
+- Child-agent concurrency default drops from the previous hard-coded limit of 5 to **1** via the new `maxConcurrentAgents` setting.
+- Plan naming now uses `ctx.modelRegistry.streamSimple()` instead of the temporary `pi-ai/compat` entry, so proxy and OAuth base-URL overrides are honored.
+- The subagent `CTX` column can now advance mid-turn from `message_update` usage, so one-long-turn provider bridges that report streaming usage are no longer forced to sit at `0.0%` until the run ends. A malformed usage reading is ignored without discarding the subagent's output.
+
+### Removed
+
+- The unfiled `docs/upstream-issue-live-usage.md` draft for a change that has shipped upstream.
+
 ## [0.1.0]
 
 - Initial commit

package/README.md

@@ -16,6 +16,7 @@ A Pi extension built around **Mixture of Agents (MoA)** planning: several models
   - [The MoA Fusion table](#the-moa-fusion-table)
   - [Opinions (`/mf-opinion`)](#opinions-mf-opinion)
   - [Debates (`/mf-debate`)](#debates-mf-debate)
+  - [Specs (`/mf-spec`)](#specs-mf-spec)
 - [Commands](#commands)
   - [Cancelling running subagents](#cancelling-running-subagents)
 - [Plan Mode](#plan-mode)
@@ -74,13 +75,13 @@ Fanning out a coding task and merging the resulting token streams does not work
 ### How a run works
 
 1. After you submit your plan prompt, a picker opens on a mode screen (**Mixture of Agents** or **Single model**). Single model — or Esc — runs the 5-phase workflow on the current model.
-2. MoA opens the **MoA Fusion Pre-flight** overview with all eight slots — five proposer slots plus a synthesizer, an implementer, and a verifier — starting empty at `(none)`, plus a **Load Roster** row above **Start fan-out** that applies a saved agent roster to every slot at once (see [Agent rosters](#agent-rosters)). Selecting any slot row opens a two-pane model/thinking picker for that one slot and returns to the overview; cancelling leaves the slot unchanged. **Start fan-out** stays disabled until you assign at least two proposer slots and all three required roles (the minimum roster; the same model may fill several slots, and the extra proposer slots are optional). Thinking levels come from the model's pi registry metadata, which is authoritative for every model the registry lists; the generic `off`/`low`/`medium`/`high` list applies only to models it doesn't. Your saved choices and active model only pre-highlight a slot's picker — they never count as assignments until you confirm them — and confirmed selections are remembered in `~/.pi/agent/mf-plan/settings.json`.
+2. MoA opens the **MoA Fusion Pre-flight** overview with all eight slots — five proposer slots plus a synthesizer, an implementer, and a verifier — starting empty at `(none)`, plus a **Load Roster** row above **Start fan-out** that applies a saved agent roster to every slot at once (see [Agent rosters](#agent-rosters)). Selecting any slot row opens a two-pane model/thinking picker for that one slot and returns to the overview; cancelling leaves the slot unchanged, and Backspace (or Delete) on a slot row clears it back to `(none)`. **Start fan-out** stays disabled until you assign at least two proposer slots and all three required roles (the minimum roster; the same model may fill several slots, and the extra proposer slots are optional). Thinking levels come from the model's pi registry metadata, which is authoritative for every model the registry lists; the generic `off`/`low`/`medium`/`high` list applies only to models it doesn't. Your saved choices and active model only pre-highlight a slot's picker — they never count as assignments until you confirm them — and confirmed selections are remembered in `~/.pi/agent/mf-plan/settings.json`.
 3. Proposers run in parallel as isolated `moa-proposer` subprocesses. Each ends with an "Open Questions / Assumptions" section rather than pausing — proposers never block waiting on input.
 4. `moa-synthesizer` reads every successful proposal (at least 1 must succeed) plus the original request, and writes one merged plan.
 5. If the proposers substantively disagreed, a conflict-review overlay opens first: one tab per conflict, plain-language options, the synthesized pick tagged **(Recommended)**, and a **Chat about this** box for free-text feedback. Your resolutions are fed back for re-synthesis. Esc cancels the whole run.
 6. The plan opens in the same review overlay `exit_plan_mode` uses, where you can inspect any proposer's original plan, edit the synthesized one, or send the synthesizer feedback for a revised version (up to five rounds).
 7. On approval, the synthesizer makes one read-only pass to create a frozen observable checklist at `.pi/mf-plan/<slug>__criteria.md`, then plan mode exits and implementation begins in the current session using the implementer you already picked — there is **no** second picker (the single-model flow picks its implementing model up front when you choose **Single model**, and neither flow shows a model picker after approval — one appears only via `/mf-plan-implement`, or when an MoA run is resumed without a saved roster). If implementation fails (for example, auth expiration or provider error), an automatic recovery dialog prompts to retry, switch to a different model, or continue manually. You can also run `/mf-plan-implement` anytime to resume the approved plan.
-8. Once the implementation turn settles, the **verification phase** runs when a verifier is configured: the project's own `check` / `lint` / `test` scripts run first, then a read-only `moa-verifier` subprocess judges the working tree against the frozen approved plan and scores every frozen criterion pass/fail/cannot-verify. The overall verdict is derived from those scores. If criteria are unavailable, it falls back to judging plan steps directly. If it finds gaps (or a check fails), the repair prompt shows a short Simplified Technical English summary, then the verifier summary, unmet criteria or gaps, and failing project checks, followed in the TUI by three choices in order: *View full findings*, *Send verifier findings to the implementer* (a bounded **repair round**, up to two), and *Accept implementation as-is*. *View full findings* opens the complete verifier report in a read-only, scrollable popup and, when closed, returns to the same three choices, so viewing never consumes a repair round. A repair round sends the findings back to the implementer and re-verifies. The raw verdict is saved next to the plan as `<slug>__verification.md`. A user-cancelled implementation is never verified.
+8. Once the implementation turn settles, the **verification phase** runs when a verifier is configured: the project's own `check` / `lint` / `test` scripts run first, then a read-only `moa-verifier` subprocess judges the working tree against the frozen approved plan and scores every frozen criterion pass/fail/cannot-verify. The overall verdict is derived from those scores. If criteria are unavailable, it falls back to judging plan steps directly. If it finds gaps (or a check fails), the repair prompt shows a short Simplified Technical English summary, then the verifier summary, unmet criteria or gaps, and failing project checks, followed in the TUI by three choices in order: *View full findings*, *Send verifier findings to the implementer* (a bounded **repair round**, up to the [max verification repairs](#max-verification-repairs) setting — two by default), and *Accept implementation as-is*. *View full findings* opens the complete verifier report in a read-only, scrollable popup and, when closed, returns to the same three choices, so viewing never consumes a repair round. A repair round sends the findings back to the implementer and re-verifies. The raw verdict is saved next to the plan as `<slug>__verification.md`. Once the repair budget is spent, a handoff file is written as `<slug>__verification-handoff.md` and named in the exhaustion notification. A user-cancelled implementation is never verified.
 
 Before building the full verification task, MoA Fusion runs a cheap verifier preflight that asks for a one-word response. Auth, quota, model, and liveness problems therefore surface quickly with an actionable child error instead of after the full audit attempt.
 
@@ -94,8 +95,8 @@ Several safeguards target known LLM judging biases:
 
 - **Identity blinding** — proposals arrive headed `### Proposal from Proposer N`; real model names never appear in its input. This counters *self-preference bias*, where a model favors output it recognizes as its own. Enforcement runs both ways: proposers must not hint at their own model name, family, or provider, and the synthesizer must not infer or emit one — including in its own output, which keeps re-synthesis rounds blind too.
 - **Separate evaluation dimensions** — proposals are judged on correctness, completeness, feasibility, risk, and simplicity as distinct dimensions rather than one overall impression. The prompt states outright that confidence, detail, and length are not evidence of quality, guarding against *verbosity bias*.
-- **Agreement is signal, not proof** — where proposers agree, the synthesizer still sanity-checks the shared assumption against the repo, since independent models can share the same error.
-- **Auditable reasoning** — the plan opens with a Context section recording dimension reasoning, proposer alignment, and synthesis decisions, so recombination choices are inspectable. Reconciliation commentary is confined there; the rest reads as one coherent plan. The orchestrator verifies all three subsections are present and rejects a first plan that omits them (one corrective retry, then a warning), the same way it enforces `## Proposer Verdicts`.
+- **Agreement is signal, not proof** — where proposers agree, the synthesizer still sanity-checks the shared assumption against the repo, since independent models can share the same error. A blinded `Panel dependence:` note in the synthesizer input names how many distinct models contributed and which slots share one model, and the pre-flight picker warns when assigned slots repeat a model or provider.
+- **Auditable reasoning** — the plan opens with a Context section recording dimension reasoning, proposer alignment, and synthesis decisions, so recombination choices are inspectable. `### Proposer alignment` labels support as evidence-backed or asserted, and conflict recommendation Details lines include distinct-model support counts. Reconciliation commentary is confined there; the rest reads as one coherent plan. The orchestrator verifies all three subsections are present and rejects a first plan that omits them (one corrective retry, then a warning), the same way it enforces `## Proposer Verdicts`.
 - **Disagreements go to the user** — every substantive disagreement must be emitted as a `## Conflicts` block, even when the synthesizer is confident, so its judgment is a default you can override rather than a decision made for you. Genuine ambiguity about *your intent* instead produces a single `## Open Question`, and the synthesizer is re-run with your answer.
 
 **Protocol-internal, always current at runtime.** The proposer, synthesizer, and verifier prompts are tightly coupled to this extension's parsers and UI (e.g. the `## Conflicts` markup, and the verifier's `**Verdict:**`/`### Gaps` markup). A hand-edited copy under `~/.pi/agent/agents/` is still written for inspection, but MoA runs always use the bundled definition from the installed extension, so a protocol update can never desync from what the subprocess runs. `moa-explore` and `mf-plan` remain fully user-customizable.
@@ -152,6 +153,19 @@ During the run, `F3` opens the live observer and `Esc` or `F4` opens cancellatio
 
 During the run, `F3` opens the live observer and `Esc` or `F4` opens cancellation controls. The prompt and combined transcript are saved under `.pi/mf-debate/` as `<slug>__debate-prompt.md` and `<slug>__debate.md`.
 
+### Specs (`/mf-spec`)
+
+`/mf-spec` follows a separate requirements workflow: rough request → clarification → approved planning brief → a user-started `/mf-plan`.
+
+1. Enter a request directly (`/mf-spec add dark mode`) or use the prompt editor.
+2. It asks up to five adaptive clarifying questions, stopping early when it has enough context. Each question names the area it affects: scope, UX, architecture, acceptance criteria, or testing.
+3. Press **Esc** during clarification to choose whether to draft from the answers so far or cancel; cancelling saves nothing.
+4. Review the draft and approve and save it, edit it directly, or revise it with feedback. Nothing is written before approval.
+5. The approved brief is saved as `.pi/mf-plan/<slug>__spec.md`. `/mf-plan-implement` ignores these files because they are specifications, not approved `__plan.md` implementation plans.
+6. After saving, a ready-to-run `/mf-plan …` handoff is placed in the input box when it is empty; review it and press Enter to start planning. Existing input is never overwritten, and `/mf-spec` refuses to run while plan mode is active.
+
+Clarification and drafting run in-process on the active session model with no tools or repository access. Repo-grounded planning begins only when you run the prepared `/mf-plan` command.
+
 ## Commands
 
 | Command | Shortcut | Description |
@@ -159,8 +173,9 @@ During the run, `F3` opens the live observer and `Esc` or `F4` opens cancellatio
 | `/mf-plan` | — | Toggle plan mode on/off |
 | `/mf-opinion` | — | Ask 1–5 models for independent read-only opinions about the repository |
 | `/mf-debate` | — | Run a read-only multi-round debate between up to 5 models |
+| `/mf-spec` | — | Clarify a rough request into an approved planning brief and prepare a `/mf-plan` handoff |
 | `/mf-preview` | — | Toggle the inline/live preview of streamed agent output |
-| `/mf-plan-settings` | — | Configure the explore and cheap/fast agents, named agent rosters for the MoA roles, and plan options |
+| `/mf-plan-settings` | — | Configure the explore and cheap/fast agents, named agent rosters for the MoA roles, plan options, and max concurrent agents |
 | `/mf-plan-implement` | — | Retry implementation of the last approved MoA plan, optionally with a different model |
 | `/mf-plan-clear` | — | Clear completed plan state so the next `/mf-plan` starts a fresh round; approved plans stay in `.pi/mf-plan/` and remain re-implementable |
 | `--mf-plan` | — | Start pi with plan mode enabled |
@@ -172,7 +187,7 @@ On Mac laptops the top row may send brightness/media keys by default. Enable the
 
 ### Cancelling running subagents
 
-During an MoA fan-out or synthesis, **Esc** opens a cancel overlay. Enter kills the selected agent — its siblings keep going and synthesis proceeds with the surviving proposals; **Cancel ALL** aborts the run and reopens the prompt editor prefilled with your original prompt. Each agent's live tool call is highlighted the same way as the Fusion table's ACTIVITY column.
+During an MoA fan-out or synthesis, **Esc** opens a cancel overlay. Enter cancels the selected agent — its siblings keep going, and once the fan-out settles you are asked, for each cancelled agent, to select a replacement model or continue without it; **Cancel ALL** (including during a replacement run) aborts the run and reopens the prompt editor prefilled with your original prompt. Each agent's live tool call is highlighted the same way as the Fusion table's ACTIVITY column.
 
 During the single-model workflow's `mf_plan_subagent` runs, plain Esc keeps pi's default abort-the-turn behavior; use **F4** to kill an individual agent instead. A cancelled agent reports "cancelled by user" back to the model, which continues with the other agents' results.
 
@@ -191,7 +206,7 @@ Both modes share the same plan-mode container. While it is active:
    - **Phase 5: Exit** — call `exit_plan_mode` for user approval
 
    This is the **single-model workflow**: the model you pick drives all five phases. [MoA](#mixture-of-agents-moa) replaces phases 1–2 with the proposer fan-out.
-3. **Per-session plan file** — one slug per session, persisted across `/resume`.
+3. **Per-session plan file** — one slug per session, persisted across `/resume`. Submitting a prompt shows a `Naming the plan` card while the cheap/fast model summarizes it into that slug; press **Esc** to skip straight to a name derived from the prompt instead of waiting.
 4. **User approval** — `exit_plan_mode` prompts to approve or keep planning. Approving restores full tool access and hands the plan back to the model.
 
 - A `● MoA Fusion (plan mode)` indicator sits in the footer while planning, and stays as `● MoA Fusion` through implementation and verification. Green: agents are working. Yellow: waiting for you (a prompt, an overlay, a questionnaire, or an idle plan-mode session). Red: a flow stopped with nothing left to try; it clears on your next turn or when you leave plan mode.
@@ -272,7 +287,27 @@ Rosters persist in `~/.pi/agent/mf-plan/settings.json`:
 }
 ```
 
-Names are 1–24 alphanumeric characters, unique case-insensitively, up to 20 rosters. The roster manager stages every edit in memory — nothing is written until the settings overlay's **Save and Close**.
+Names are 1–24 alphanumeric characters, unique case-insensitively, up to 20 rosters. Slot edits remain drafts until **Save roster** is selected; that action persists the completed roster immediately, without requiring **Save and Close** in the parent settings overlay.
+
+#### Max concurrent agents
+
+The **max concurrent agents** row in `/mf-plan-settings` controls how many child-agent subprocesses may run at once during MoA proposer fan-out (including retries), opinion fan-out, debate rounds (including retries), and `mf_plan_subagent` parallel mode. Use ←/→ to pick a value from 1 to 8. The setting persists in `~/.pi/agent/mf-plan/settings.json`:
+
+```json
+{ "maxConcurrentAgents": 1 }
+```
+
+The default is **1** — several local models running in parallel are usually unusably slow, so keep this at 1 for local agents and raise it for cloud models. Out-of-range values clamp to 1–8; malformed values fall back to 1. The limit is read once when a run starts, so edits apply to the next run rather than one already in flight.
+
+#### Max verification repairs
+
+The **max verification repairs** row in `/mf-plan-settings` controls how many automatic verifier-driven repair rounds a single implementation may consume after verification finds gaps. Use ←/→ to pick a value from 0 to 5. The setting persists in `~/.pi/agent/mf-plan/settings.json`:
+
+```json
+{ "maxVerificationRepairs": 2 }
+```
+
+The default is **2**. Set **0** to disable automatic repair offers — verification still runs, but gaps go straight to an exhaustion notification. When repairs are exhausted or disabled, MoA Fusion writes `.pi/mf-plan/<slug>__verification-handoff.md` with each criterion's pass/fail status, the full frozen criteria checklist, gaps, and failing project checks so you can continue the fix/verification loop manually (for example via `/mf-plan-implement`). The exhaustion notification includes the handoff file path.
 
 **First run.** Until the setup overlay has been saved once, `/mf-plan` opens it — set up agents and rosters before planning — instead of the plan prompt. Only interactive TUI sessions are gated; headless plan mode is unaffected.
 
@@ -283,7 +318,9 @@ Names are 1–24 alphanumeric characters, unique case-insensitively, up to 20 ro
 
 ### Parallel execution
 
-In the single-model flow, Phase 1 launches up to **3 moa-explore agents in parallel** and Phase 2 up to **1 mf-plan agent**. Concurrency is capped at 5 simultaneous processes, with a per-task output cap of 50KB.
+In the single-model flow, Phase 1 launches up to **3 moa-explore agents in parallel** and Phase 2 up to **1 mf-plan agent**. Child-agent concurrency is configurable from 1 to 8 in `/mf-plan-settings` (default **1**); it applies to MoA proposer fan-out, opinion fan-out, debate rounds, and `mf_plan_subagent` parallel mode, including every retry batch. The separate **8-task submission cap** per batch is unchanged. Per-task output is capped at 50KB.
+
+**Cache warming.** pi 0.86.0 defaults `cacheWarming` to `"streaming"`. On Anthropic models, long `mf_plan_subagent` or MoA tool executions can therefore trigger paid cache refreshes while an agent is working. Set `cacheWarming` to `"off"` in your pi config if you would rather not pay for those.
 
 ```
 mf_plan_subagent({
@@ -306,7 +343,7 @@ The slug is a generated adjective-adjective-noun triple (e.g. `happy-mellifluous
 
 ## Non-Interactive Behavior
 
-In non-interactive modes (`pi -p`, `--mode json`), `exit_plan_mode` is rejected unless `MOA_PLAN_AUTO_APPROVE=1` is set. With that explicit opt-in, it exits plan mode and hands the plan back without prompting. The plan file is still written to disk.
+In non-interactive modes (`pi -p`, `--mode json`), `exit_plan_mode` is rejected unless `MOA_PLAN_AUTO_APPROVE=1` is set. With that explicit opt-in, it exits plan mode and hands the plan back without prompting. The plan file is still written to disk. `/mf-spec <request>` likewise requires `MOA_PLAN_AUTO_APPROVE=1`; with it, the command skips questions and review, generates and saves the brief, and prints the `/mf-plan` handoff, while without it no model call or file write occurs.
 
 ## How It Works (Architecture)
 
@@ -348,6 +385,9 @@ src/
 │   ├── debateRounds.ts      # Survivor/early-stop/next-round bookkeeping
 │   ├── debateResults.ts     # Outcome collection and debate transcript markdown
 │   └── debateFile.ts        # Repo-local debate artifacts
+├── spec/
+│   ├── specContract.ts      # Clarification/brief contracts, parsing, and handoff helpers
+│   └── runSpec.ts           # Interactive/headless /mf-spec state machine
 ├── planning/
 │   ├── planMode.ts          # Plan-mode state transitions and lifecycle handlers
 │   ├── modeState.ts         # Persisted state shape, byte cap, append deduplication
@@ -398,7 +438,8 @@ src/
     ├── promptEditor.ts         # File-path/@name completion editor
     ├── shimmer.ts
     ├── toolActivity.ts
-    └── verificationFindingsOverlay.ts
+    ├── verificationFindingsOverlay.ts
+    └── workingOverlay.ts      # Blocking-work overlay (plan/opinion/debate naming)
 
 agents/                      # Shipped agent definitions
 ├── moa-explore.md
@@ -414,7 +455,7 @@ agents/                      # Shipped agent definitions
 - **Custom `write_plan` tool** instead of path-guarded `edit`/`write` — guarantees the single-writable-file invariant.
 - **Subprocess subagents** (not in-process) — each agent runs in an isolated `pi --mode json -p --no-session` subprocess with an enforced read-only tool allowlist.
 - **State via `appendEntry`** — plan mode state (enabled, slug, tools snapshot) persists in the session for `/resume` and `/reload`.
-- **Context injection via `before_agent_start`** — the 5-phase instructions are injected as a user message every turn while plan mode is active; the `context` hook strips stale plan-mode messages once it is off.
+- **Context injection and lifecycle cleanup via `before_agent_start` + `context`** — the 5-phase instructions are injected as a user message every turn while plan mode is active, and the `context` hook strips stale plan-mode messages once it is off. On pi 0.87+, the settle boundary also persists null context edits for reusable plan-instruction entries once plan mode is off, so later compaction cannot carry those instructions forward. When an approved implementation is expected to enter verification, the same boundary persists a hidden `mf-plan-verification-pending` marker so a resumed session can warn that verification is still outstanding.
 - **MoA proposers never pause mid-run** — subprocess subagents are one-shot, so a proposer that hits an ambiguity records it as an assumption and keeps going. Only the synthesizer, which sees every proposal, asks the user anything — keeping fan-out fully parallel.
 
 ## Porting Notes
@@ -430,6 +471,7 @@ Ported from Claude Code's plan mode, adapted to pi's extension primitives:
 | `FileEditTool`/`FileWriteTool` guarded | Custom `write_plan` tool | Safer single-writable-file invariant |
 | Subscription-tier agent counts | Hardcoded constants (3/1) | Bumpable via code change |
 | Plan-length A/B experiment | Standard Phase 4 | Experiment noise skipped |
+| Spec Kit / brainstorming | `/mf-spec` | Requirements clarification only |
 | Interview phase variant | Standard 5-phase workflow | Variant skipped |
 
 ## License

package/agents/moa-synthesizer.md

@@ -12,6 +12,8 @@ You must NOT make any changes. You may use read/grep/find/ls to verify a propose
 
 **Blinding notice.** Proposer identities are intentionally blinded in your input: each proposal is headed `### Proposal from Proposer N` (where N is the proposer's slot order, deterministic for this run) instead of naming the model. This prevents self-preference bias — proposals must be judged purely on merit. Do not attempt to infer, attribute, or guess which model wrote which proposal, and never output any model name, family, provider, or version anywhere in your plan.
 
+**Panel dependence note.** Your input opens with a one-paragraph `Panel dependence:` note giving the number of proposals, distinct models, and providers, plus which `Proposer N` slots share one model. It carries no model names by design. Read it before weighing agreement: proposals inside one same-model cluster are one vote, and the shared prompt template means even distinct models are not fully independent.
+
 ## Verification criteria task
 
 After a plan is approved, you may be re-invoked solely to write a `## Verification Criteria` checklist. Emit only that section, with binary observable `- **C<n>:** condition — how to check` bullets. Every item must be checkable through repository reading, not execution. Cover plan steps, named call sites, and implied regression/scope constraints. The orchestrator retries once if no criteria can be parsed.
@@ -26,7 +28,7 @@ Guidelines:
   - Simplicity: does it avoid unnecessary complexity?
 - Build a new plan by recombining the best compatible ideas across proposals. Only synthesize prose/structure, never code — you are merging natural-language plans, not diffs.
 - Do not mechanically hybridize mutually incompatible alternatives. Where two or more proposers take genuinely different approaches to the same decision, decide which approach is best on the merits — clear repo evidence, unambiguous engineering judgment, or a direct match with the user's stated request — and use it in the synthesized plan. This surfacing is unconditional and mandatory: state the choice and why in one line in the Context section AND emit it in a `## Conflicts` section (format below) so the user can confirm or override it before the plan is finalized. Repo evidence or confident engineering judgment may justify your recommended pick — it never excuses omitting the conflict block. Never include a conflict the user has no realistic alternative for (e.g. only one proposer covered the point at all). You may choose one incompatible approach while still incorporating compatible strengths, safeguards, verification steps, or sequencing from other proposals.
-- Where proposers agree, treat agreement as useful signal but still sanity-check it; shared assumptions can be shared errors.
+- Where proposers agree, treat agreement as useful signal but still sanity-check it; shared assumptions can be shared errors. Weight agreement by the `Panel dependence` note — count each same-model cluster as one vote — and treat an uncited unanimous point as an untested claim until you check it against the repo.
 - If no proposal handles something the user goal requires, add the missing piece yourself and note it in Context. If a proposal suggests something actively wrong, risky, or unnecessary, drop it and say so briefly.
 - Always begin the final plan with a **Context** section (see Output format). This is the one place you may — and must — describe the MoA reconciliation process: how proposals scored on the evaluation dimensions, what they agreed on, what was missing or rejected, where they differed, and how you resolved disagreements.
 - If a disagreement is a genuine ambiguity in user intent that you cannot resolve from the plans + repo alone, ask the user ONE clarifying question. To do this, output a section titled exactly `## Open Question` containing only that question, and STOP — do not write the rest of the plan yet. You will be re-invoked with the user's answer appended, at which point you should incorporate it and produce the full plan below instead of the question section.
@@ -43,7 +45,7 @@ When two or more proposers substantively disagree on one or more decision points
 
 - **Decision:** <ASD-STE100 Simplified Technical English Issue 9 plain-language explanation of what the person is choosing and why it matters>
 - **Recommended:** <short, non-technical outcome summary>
-- **Details:** <one-line technical implementation details and tradeoffs>
+- **Details:** <one-line technical implementation details and tradeoffs; for the recommended option, end with `backed by K of N proposals (M distinct models)`>
 - **Alternative** (Proposer N): <short, non-technical outcome summary>
 - **Details:** <one-line technical implementation details and tradeoffs>
 - **Alternative** (Proposer M): <short, non-technical outcome summary>
@@ -59,7 +61,7 @@ Worked example (matches the parser exactly — one `-` bullet per line, with `De
 
 - **Decision:** Choose where sign-in information is stored; this affects both security and how much of the existing sign-in flow can stay unchanged.
 - **Recommended:** Keep the current sign-in experience
-- **Details:** Store session IDs in `Secure`, `HttpOnly` cookies so the existing middleware stays compatible and page scripts cannot read them.
+- **Details:** Store session IDs in `Secure`, `HttpOnly` cookies so the existing middleware stays compatible and page scripts cannot read them; backed by 2 of 3 proposals (2 distinct models).
 - **Alternative** (Proposer 2): Make sign-in data available to browser code
 - **Details:** Store JWTs in `localStorage`; this can simplify cross-service access but lets an injected page script read the token.
 ```
@@ -70,10 +72,11 @@ Rules:
 - Exactly one `**Recommended:**` line per conflict, using a short, non-technical summary of your synthesized outcome, immediately followed by exactly one `**Details:**` line.
 - One `**Alternative**` line per other distinct approach worth surfacing, each attributed to a blinded `Proposer N` slot label already present in your input — never invent or rename labels, and never leak real model names here either. Immediately follow every alternative with its own `**Details:**` line.
 - Write each recommended or alternative summary as an outcome the person can choose, not an implementation mechanism. It is displayed as the primary selectable line, so it must be understandable without code syntax, type names, file paths, configuration keys, or unexplained acronyms.
-- Use `**Details:**` for the technical implementation specifics, rationale, benefits, drawbacks, and tradeoffs. It is displayed dimmed beneath the summary, may name concrete types, files, or configuration when helpful, and must stay to one line.
+- Use `**Details:**` for the technical implementation specifics, rationale, benefits, drawbacks, and tradeoffs. It is displayed dimmed beneath the summary, may name concrete types, files, or configuration when helpful, and must stay to one line. The recommended option's `**Details:**` must end with `backed by K of N proposals (M distinct models)`, where K = proposals backing that option, N = proposals received, and M = distinct models among the K (slots in one same-model cluster count once).
+- The `**Recommended:**` pick must be justified on the merits — repo evidence, engineering judgment, or a direct match with the user's request — and a majority of proposers is not by itself a reason, especially when that majority sits inside one same-model cluster named in the Panel dependence note.
 - If you are re-invoked with the user's conflict resolutions appended (see below), honor their selections, resolve any free-form chat feedback, drop the `## Conflicts` section entirely, and emit the complete final plan. If the chat feedback introduces a genuine new ambiguity you cannot resolve yourself, fall back to the `## Open Question` mechanism (one question) and stop, exactly as you would on first pass.
 - When the input contains post-review user feedback, treat it as binding revision directives. Answer clarifying questions where possible, incorporate the requested changes, and return the complete revised plan rather than a description of changes. Omit both `## Conflicts` and `## Open Question` from that revised output.
-- **Self-check before finalizing:** review every disagreement you described in Context and verify each has a matching `### Conflict:` block; add any missing ones now. Then verify Context contains all three subsections (`### Evaluation dimensions`, `### Proposer alignment`, `### Synthesis decisions`). Finally verify `## Proposer Verdicts` contains one bullet for every proposal you received.
+- **Self-check before finalizing:** review every disagreement you described in Context and verify each has a matching `### Conflict:` block; add any missing ones now. Then verify Context contains all three subsections (`### Evaluation dimensions`, `### Proposer alignment`, `### Synthesis decisions`), that every unanimous point in `### Proposer alignment` carries an evidence-backed or asserted tag with each asserted point's repo check recorded, and that every Recommended `**Details:**` line ends with its support count. Finally verify `## Proposer Verdicts` contains one bullet for every proposal you received.
 
 Output format (when not asking a question):
 
@@ -89,7 +92,7 @@ Then include these three subsections. They are MANDATORY in every full-plan outp
 Briefly reason about correctness, completeness, feasibility & effort, risk, and simplicity as separate dimensions. Do not collapse them into one overall impression, and do not reward verbosity.
 
 ### Proposer alignment
-Summarize where the proposers **unanimously agreed**, what they **unanimously rejected** (shared dead ends or dismissed ideas), and where they **differed**. Be specific — name files, approaches, or tradeoffs, not vague generalities. Even when every proposer agrees on the same approach, state how you sanity-checked that shared assumption.
+Summarize where the proposers **unanimously agreed**, what they **unanimously rejected** (shared dead ends or dismissed ideas), and where they **differed**. Be specific — name files, approaches, or tradeoffs, not vague generalities. For every unanimous point (agreed or unanimously rejected), tag it **evidence-backed** (two or more proposers cite a concrete repo location — file path, symbol, or line) or **asserted** (no citation, or all citations identical and unverified). Sanity-check every asserted point against the repo with read/grep/find/ls *before* relying on it, stating the location checked and what was found, and drop or downgrade it if it does not hold. Note explicitly when a "unanimous" point rests inside a single same-model cluster from the Panel dependence note.
 
 ### Synthesis decisions
 State what the final plan recombines from multiple proposers, what required pieces you added because no proposer covered them, and what actively wrong, risky, or unnecessary ideas you dropped. Where proposers disagreed, use the blinded slot labels from each `### Proposal from …` heading (e.g. `Proposer 1`, `Proposer 2`) and give a one-line decision for each disagreement: which approach you chose and why, citing repo evidence, engineering tradeoffs, or alignment with the user's request. These disagreements must also appear in `## Conflicts` for user review.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@underactive/pi-topping-moa-fusion",
-  "version": "0.1.0",
+  "version": "0.3.0",
   "description": "Pi extension implementing /mf-plan — Claude Code-style 5-phase plan mode with a Mixture-of-Agents proposer/synthesizer pipeline.",
   "keywords": [
     "pi-package",
@@ -50,10 +50,10 @@
     "typebox": "*"
   },
   "devDependencies": {
-    "@earendil-works/pi-agent-core": "0.84.1",
-    "@earendil-works/pi-ai": "0.84.1",
-    "@earendil-works/pi-coding-agent": "0.84.1",
-    "@earendil-works/pi-tui": "0.84.1",
+    "@earendil-works/pi-agent-core": "0.87.0",
+    "@earendil-works/pi-ai": "0.87.0",
+    "@earendil-works/pi-coding-agent": "0.87.0",
+    "@earendil-works/pi-tui": "0.87.0",
     "@types/node": "^24.0.0",
     "typebox": "^1.3.3",
     "typescript": "^5.8.0"

package/src/config/planName.ts

@@ -2,10 +2,9 @@
  * LLM-based 4-word plan name generation for repo-local plan files.
  */
 
-import { completeSimple } from "@earendil-works/pi-ai/compat";
 import type { ExtensionContext } from "@earendil-works/pi-coding-agent";
 import { loadMoaConfig } from "./settings.ts";
-import { fallbackPlanName, generateWordSlug, trySlugifyPlanName } from "../planning/planFile.ts";
+import { generateWordSlug, slugifyPlanName, trySlugifyPlanName } from "../planning/planFile.ts";
 
 function buildSummarizePrompt(prompt: string): string {
 	return [
@@ -18,10 +17,14 @@ function buildSummarizePrompt(prompt: string): string {
 	].join("\n");
 }
 
+export interface PlanNameOptions {
+	/** Caller cancellation — esc from the working overlay. */
+	signal?: AbortSignal;
+}
+
 /** Call the active model to summarize a plan prompt into a 4-word slug. */
-export async function summarizePlanPromptName(ctx: ExtensionContext, prompt: string): Promise<string> {
-	const promptSlug = trySlugifyPlanName(prompt);
-	const fallback = () => promptSlug ?? fallbackPlanName();
+export async function summarizePlanPromptName(ctx: ExtensionContext, prompt: string, options?: PlanNameOptions): Promise<string> {
+	const fallback = () => slugifyPlanName(prompt);
 
 	const config = loadMoaConfig();
 
@@ -34,31 +37,33 @@ export async function summarizePlanPromptName(ctx: ExtensionContext, prompt: str
 		: ctx.model;
 	if (!model) return fallback();
 
-	const auth = await ctx.modelRegistry.getApiKeyAndHeaders(model);
-	if (!auth?.ok || !auth.apiKey) return fallback();
+	// Short-circuit before registry streaming so an already-aborted signal costs nothing.
+	if (options?.signal?.aborted) return fallback();
 
 	try {
 		// Naming a plan file is not a reasoning task, and the cheap/fast model is
 		// chosen to be cheap. Omitting `reasoning` is how pi's simple-stream API
 		// spells "thinking off" (its ThinkingLevel type has no "off" member), so
 		// providers send their disabled-reasoning mapping rather than a default.
-		const response = await completeSimple(
-			model,
-			{
-				messages: [
-					{
-						role: "user",
-						content: [{ type: "text", text: buildSummarizePrompt(prompt) }],
-						timestamp: Date.now(),
-					},
-				],
-			},
-			{
-				apiKey: auth.apiKey,
-				headers: auth.headers,
-				env: auth.env,
-			},
-		);
+		const response = await ctx.modelRegistry
+			.streamSimple(
+				model,
+				{
+					messages: [
+						{
+							role: "user",
+							content: [{ type: "text", text: buildSummarizePrompt(prompt) }],
+							timestamp: Date.now(),
+						},
+					],
+				},
+				{ signal: options?.signal },
+			)
+			.result();
+
+		// An aborted request can resolve with stopReason "aborted" and empty text
+		// rather than throwing — fall back explicitly instead of slugifying a stub.
+		if (response.stopReason === "aborted") return fallback();
 
 		const text = response.content
 			.filter((part): part is { type: "text"; text: string } => part.type === "text")

package/src/config/settings.ts

@@ -21,6 +21,35 @@ import { parseRosters, type PlanRoster } from "./rosters.ts";
 
 export type MoaMode = "single" | "moa";
 
+export const MIN_CONCURRENT_AGENTS = 1;
+export const MAX_CONCURRENT_AGENTS = 8;
+export const DEFAULT_MAX_CONCURRENT_AGENTS = MIN_CONCURRENT_AGENTS;
+
+export const MIN_VERIFICATION_REPAIRS = 0;
+export const MAX_VERIFICATION_REPAIRS_LIMIT = 5;
+export const DEFAULT_MAX_VERIFICATION_REPAIRS = 2;
+
+/**
+ * Sanitize verifier-driven repair rounds: missing or malformed values fall back
+ * to the default; finite numbers are rounded and clamped into [0, 5]. Zero
+ * disables automatic repair offers after verification gaps.
+ */
+export function normalizeMaxVerificationRepairs(value: unknown): number {
+	if (typeof value !== "number" || !Number.isFinite(value)) return DEFAULT_MAX_VERIFICATION_REPAIRS;
+	return Math.min(MAX_VERIFICATION_REPAIRS_LIMIT, Math.max(MIN_VERIFICATION_REPAIRS, Math.round(value)));
+}
+
+/**
+ * The one place a loaded/passed concurrency value becomes safe: missing,
+ * non-numeric, NaN and infinite values fall back to the default; finite
+ * numbers are rounded to an integer and clamped into [MIN, MAX], so a
+ * fractional or out-of-range value can never reach the runner.
+ */
+export function normalizeMaxConcurrentAgents(value: unknown): number {
+	if (typeof value !== "number" || !Number.isFinite(value)) return DEFAULT_MAX_CONCURRENT_AGENTS;
+	return Math.min(MAX_CONCURRENT_AGENTS, Math.max(MIN_CONCURRENT_AGENTS, Math.round(value)));
+}
+
 export interface MoaConfig {
 	mode: MoaMode;
 	proposers: ModelRef[];
@@ -28,6 +57,10 @@ export interface MoaConfig {
 	debateModels: ModelRef[];
 	/** Round ceiling for /mf-debate, clamped to the picker's 2–5 range. */
 	debateRounds: number;
+	/** Child agents allowed to run at once in any fan-out, clamped to 1–8. Defaults to 1 — parallel local agents are unusably slow. */
+	maxConcurrentAgents: number;
+	/** Verifier-driven repair rounds after implementation, clamped to 0–5. Defaults to 2; 0 disables automatic repairs. */
+	maxVerificationRepairs: number;
 	synthesizer?: ModelRef;
 	implementer?: ModelRef;
 	verifier?: ModelRef;
@@ -56,6 +89,8 @@ function emptyConfig(): MoaConfig {
 		opinionModels: [],
 		debateModels: [],
 		debateRounds: 3,
+		maxConcurrentAgents: DEFAULT_MAX_CONCURRENT_AGENTS,
+		maxVerificationRepairs: DEFAULT_MAX_VERIFICATION_REPAIRS,
 		synthesizer: undefined,
 		implementer: undefined,
 		verifier: undefined,
@@ -89,6 +124,8 @@ function parseSettingsFile(path: string): MoaConfig {
 		const debateRounds = typeof parsed.debateRounds === "number" && Number.isFinite(parsed.debateRounds)
 			? Math.min(5, Math.max(2, Math.round(parsed.debateRounds)))
 			: 3;
+		const maxConcurrentAgents = normalizeMaxConcurrentAgents(parsed.maxConcurrentAgents);
+		const maxVerificationRepairs = normalizeMaxVerificationRepairs(parsed.maxVerificationRepairs);
 		const synthesizer = isModelRef(parsed.synthesizer) ? parsed.synthesizer : undefined;
 		const implementer = isModelRef(parsed.implementer) ? parsed.implementer : undefined;
 		const verifier = isModelRef(parsed.verifier) ? parsed.verifier : undefined;
@@ -113,7 +150,7 @@ function parseSettingsFile(path: string): MoaConfig {
 		const agentDefaultsConfigured = parsed.agentDefaultsConfigured === true;
 		const rosters = parseRosters(parsed.rosters);
 
-		return { mode, proposers, opinionModels, debateModels, debateRounds, synthesizer, implementer, verifier, cheap, thinkingOverrides, rosters, autoResolveConflicts, useSummaryName, agentDefaultsConfigured };
+		return { mode, proposers, opinionModels, debateModels, debateRounds, maxConcurrentAgents, maxVerificationRepairs, synthesizer, implementer, verifier, cheap, thinkingOverrides, rosters, autoResolveConflicts, useSummaryName, agentDefaultsConfigured };
 	} catch (err) {
 		console.error("mf-plan: failed to parse settings, using defaults:", err);
 		return emptyConfig();

package/src/debate/debateFanout.ts

@@ -4,7 +4,7 @@ import type { AgentConfig } from "../agents/discovery.ts";
 import { modelExtensionOptions, resolveContextWindow, resolveModelCost } from "../moa/modelRuntime.ts";
 import type { CancelSession } from "../runtime/cancelRun.ts";
 import { CancelRun } from "../runtime/cancelRun.ts";
-import { getFinalOutput, getResultOutput, isFailedResult, type SingleResult } from "../runtime/results.ts";
+import { getFinalOutput, getResultOutput, isFailedResult, statusDetail, type SingleResult } from "../runtime/results.ts";
 import { runParallelAgentsWithModels, type ModelParallelAgentTask } from "../runtime/runner.ts";
 import { modelRefLabel, type ModelRef, type ThinkingLevel } from "../shared/modelRefs.ts";
 import { activityLoopCount } from "../ui/agentStatus.ts";
@@ -34,6 +34,7 @@ export interface DebateFanoutOptions {
 	session: CancelSession;
 	widget: MoaProgressWidget;
 	agents: AgentConfig[];
+	maxConcurrency: number;
 }
 
 export type DebateFanoutResult =
@@ -53,7 +54,7 @@ interface CumulativeUsage {
  * accumulate across rounds per slot.
  */
 export async function runDebateRounds(options: DebateFanoutOptions): Promise<DebateFanoutResult> {
-	const { host, ctx, topic, models, thinking, rounds: totalRounds, session, widget, agents } = options;
+	const { host, ctx, topic, models, thinking, rounds: totalRounds, session, widget, agents, maxConcurrency } = options;
 	const alive = models.map(() => true);
 	const positions: (string | undefined)[] = models.map(() => undefined);
 	const completedRounds: DebateRound[] = [];
@@ -116,7 +117,7 @@ export async function runDebateRounds(options: DebateFanoutOptions): Promise<Deb
 							if (observed) observed.state = "cancelled";
 						} else if (isFailedResult(result)) {
 							currentRun.settle(batchIndex, "error");
-							widget.update(debateIndex, "error", getResultOutput(result).slice(0, 80));
+							widget.update(debateIndex, "error", statusDetail(getResultOutput(result)));
 							if (observed) observed.state = "error";
 						} else {
 							currentRun.settle(batchIndex, "done");
@@ -146,6 +147,15 @@ export async function runDebateRounds(options: DebateFanoutOptions): Promise<Deb
 							observed.partial = result.partialAssistant;
 						}
 					},
+					{
+						maxConcurrency,
+						onStart: (batchIndex) => {
+							const debateIndex = entries[batchIndex].index;
+							widget.update(debateIndex, "working");
+							const observed = observe.agents[debateIndex];
+							if (observed) observed.state = "working";
+						},
+					},
 				);
 			} finally {
 				unsubscribe();
@@ -179,7 +189,7 @@ export async function runDebateRounds(options: DebateFanoutOptions): Promise<Deb
 			}
 		};
 
-		widget.startFanout(models, thinking);
+		widget.startFanout(models, thinking, maxConcurrency);
 
 		let stoppedEarly: string | undefined;
 		for (let round = 1; round <= totalRounds; round++) {
@@ -193,7 +203,7 @@ export async function runDebateRounds(options: DebateFanoutOptions): Promise<Deb
 			if (round > 1) {
 				for (const entry of entries) {
 					// Re-activates the settled row and resets its transcript.
-					widget.update(entry.index, "working", `round ${round}/${totalRounds} · responding`);
+					widget.update(entry.index, "queued", `round ${round}/${totalRounds} · responding`);
 					const observed = observe.agents[entry.index];
 					if (observed) {
 						observed.state = "working";
@@ -233,7 +243,7 @@ export async function runDebateRounds(options: DebateFanoutOptions): Promise<Deb
 				session.title = `Debate agents — round ${round}/${totalRounds} (retry)`;
 				session.getExtras = makeGetExtras(retryEntries);
 				for (const entry of retryEntries) {
-					widget.update(entry.index, "working", "retrying: no position produced");
+					widget.update(entry.index, "queued", "retrying: no position produced");
 					const observed = observe.agents[entry.index];
 					if (observed) {
 						observed.state = "working";

package/src/debate/runDebate.ts

@@ -3,16 +3,17 @@ import type { ExtensionAPI, ExtensionContext } from "@earendil-works/pi-coding-a
 import { installShippedAgents, shippedAgentsDir, withAuthoritativeMoaAgents } from "../agents/authoritative.ts";
 import { discoverAgents } from "../agents/discovery.ts";
 import { summarizePlanPromptName } from "../config/planName.ts";
+import { slugifyPlanName } from "../planning/planFile.ts";
 import { loadMoaConfig, saveMoaConfig } from "../config/settings.ts";
 import type { OpinionHost } from "../opinion/runOpinion.ts";
 import { resolveContextWindow } from "../moa/modelRuntime.ts";
 import { type CancelSession, subscribeCancelOverlayOnEsc } from "../runtime/cancelRun.ts";
 import { formatMutationWarning, MutationTripwire } from "../runtime/mutationTripwire.ts";
-import { type SendUserMessageOptions, type ThinkingLevel } from "../shared/modelRefs.ts";
+import { type SendUserMessageOptions } from "../shared/modelRefs.ts";
 import { MoaProgressWidget } from "../ui/moaProgressWidget.ts";
-import type { ObserveSession } from "../ui/observeOverlay.ts";
 import { showDebateModelPicker } from "../ui/debateModelPicker.ts";
 import { showPromptEditor } from "../ui/promptEditor.ts";
+import { planNamingOverlay, withWorkingOverlay } from "../ui/workingOverlay.ts";
 import { repoDebateDisplayPath, saveRepoDebateFile } from "./debateFile.ts";
 import { runDebateRounds } from "./debateFanout.ts";
 import { collectDebateOutcomes, formatDebateMarkdown } from "./debateResults.ts";
@@ -69,7 +70,11 @@ export async function runInteractiveDebate(
 				thinkingOverrides: { ...settings.thinkingOverrides, ...thinkingSelections },
 			});
 
-			const slug = await summarizePlanPromptName(ctx, topic);
+			const slug = await withWorkingOverlay(
+				ctx,
+				planNamingOverlay("debate", () => slugifyPlanName(topic)),
+				(signal) => summarizePlanPromptName(ctx, topic, { signal }),
+			);
 			try {
 				saveRepoDebateFile(topic, ctx.cwd, slug, "debate-prompt");
 			} catch {
@@ -101,7 +106,7 @@ export async function runInteractiveDebate(
 			host.setRunningProgressWidget(widget);
 			let outcome;
 			try {
-				outcome = await runDebateRounds({ host, ctx, topic, models, thinking, rounds, session, widget, agents });
+				outcome = await runDebateRounds({ host, ctx, topic, models, thinking, rounds, session, widget, agents, maxConcurrency: settings.maxConcurrentAgents });
 			} finally {
 				host.setRunningProgressWidget(undefined);
 				widget.stopWidget();
@@ -126,6 +131,10 @@ export async function runInteractiveDebate(
 			} catch {
 				saved = false;
 			}
+			// `sendUserMessage` routes to prompt() and ignores triggerTurn (only
+			// sendCustomMessage honors it), so this report does start a model turn.
+			// Genuinely append-only delivery needs pi.sendMessage({ customType, … },
+			// { triggerTurn: false }) plus a message renderer — a UX change, not made here.
 			const appendOnly: SendUserMessageOptions = { triggerTurn: false };
 			await pi.sendUserMessage(markdown, appendOnly);
 			const active = outcomes.filter((item) => item.finalStatus === "active-at-close").length;