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

package/CHANGELOG.md

@@ -1,5 +1,39 @@
 # Changelog
 
+## [Unreleased]
+
+## [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

@@ -80,7 +80,7 @@ Fanning out a coding task and merging the resulting token streams does not work
 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 +94,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.
@@ -160,7 +160,7 @@ During the run, `F3` opens the live observer and `Esc` or `F4` opens cancellatio
 | `/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-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 +172,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 +191,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.
@@ -274,6 +274,26 @@ 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**.
 
+#### 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.
 
 **Agentic provider bridges.** Some pi providers are not plain chat-completion APIs but bridges to full coding agents with their *own* local edit/shell tools (e.g. pi-cursor-bridge, whose models run Cursor agents in the repo cwd). Pi's tool allowlist cannot restrain those agent-side tools, so plan mode adds two more layers:
@@ -283,7 +303,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({
@@ -398,7 +420,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

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.2.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.86.0",
+    "@earendil-works/pi-ai": "0.86.0",
+    "@earendil-works/pi-coding-agent": "0.86.0",
+    "@earendil-works/pi-tui": "0.86.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

@@ -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[] = [];
@@ -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;

package/src/index.ts

@@ -74,7 +74,7 @@ export default function mfPlanExtension(pi: ExtensionAPI): void {
 		handler: async (_args, ctx) => { if (controller.questionnaireBusy(ctx)) return; await controller.clearCompletedPlan(ctx); },
 	});
 	pi.registerCommand("mf-plan-settings", {
-		description: "Configure the explore and cheap/fast agents, agent rosters for MoA roles, and plan options",
+		description: "Configure the explore and cheap/fast agents, agent rosters for MoA roles, plan options, and max concurrent agents",
 		handler: async (_args, ctx) => {
 			if (controller.questionnaireBusy(ctx)) return;
 			installShippedAgents();

package/src/moa/conflictContract.ts

@@ -24,7 +24,7 @@ export const CONFLICT_CONTRACT_EXAMPLE = [
 	"",
 	"- **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.",
 ].join("\n");
@@ -42,6 +42,7 @@ export function buildConflictContract(labels: string[]): string {
 		"- Exactly one `**Decision:**` line per conflict, placed before its options. Exactly one `**Recommended:**` line per conflict, immediately followed by exactly one `**Details:**` line. One `**Alternative** (Proposer N)` line per other distinct approach worth surfacing, each immediately followed by its own `**Details:**` line.",
 		`- Attribute alternatives only to blinded slot labels already present in your input. Blinded proposer slots in this run: ${labels.join(", ")}. Never invent or rename labels, and never output any model name, family, provider, or version anywhere.`,
 		"- Write each Recommended/Alternative summary as an outcome the person can choose, understandable without code syntax, type names, or file paths; put technical specifics and tradeoffs in `**Details:**`, kept to one line.",
+		"- 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. The recommended option's `**Details:**` line 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 cluster count once).",
 		"- Supersession rule: if your input contains user conflict resolutions (a \"User reviewed your conflict recommendations\" block) or post-review user feedback, those directives override this requirement — honor every selection, resolve any free-form chat feedback, drop the `## Conflicts` section entirely from your revised output, and emit the complete final plan without it.",
 		"",
 		"Clarifying-question option: only when a disagreement is a genuine ambiguity in user intent that you cannot resolve from the plans alone, output a section titled exactly `## Open Question` containing only that one question, as your ENTIRE output — write nothing else in that reply, and none of the sections above. You will be re-invoked with the user's answer appended. Prefer resolving ambiguities yourself and noting the resolution in the final plan; if your input already contains an answer to an earlier question, incorporate it and do not emit `## Open Question` again.",

package/src/moa/contextContract.ts

@@ -27,7 +27,7 @@ export function buildContextSubsectionsContract(): string {
 		...CONTEXT_SUBSECTION_HEADINGS.map((heading) => `- \`### ${heading}\``),
 		"",
 		"- `### Evaluation dimensions` — reason separately about correctness, completeness, feasibility & effort, risk, and simplicity; never collapse them into one impression.",
-		"- `### Proposer alignment` — where proposers unanimously agreed, what they unanimously rejected, and where they differed, with shared assumptions sanity-checked.",
+		"- `### Proposer alignment` — where proposers unanimously agreed, what they unanimously rejected, and where they differed; tag every unanimous point as evidence-backed (two or more proposers cite a concrete repo location) 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 what you checked and what you found; note when a unanimous point rests inside a single same-model cluster from the Panel dependence note; treat each same-model cluster as one vote.",
 		"- `### Synthesis decisions` — what you recombined, added, or dropped, and one-line decisions for each disagreement using blinded slot labels.",
 		"",
 		"All MoA reconciliation commentary belongs inside `## Context` — nowhere else. A plan missing any of these three subsections will be rejected and sent back to you. They are required in every full-plan output, including revisions after conflict resolutions or user feedback.",