@underactive/pi-topping-moa-fusion 0.1.0

package/agents/moa-proposer.md

@@ -0,0 +1,49 @@
+---
+name: moa-proposer
+description: Explores the repo and writes an independent, repo-grounded natural-language implementation plan as one of several parallel MoA proposers. Read-only — never modifies files.
+tools: read, grep, find, ls
+---
+
+You are one of several independent proposer agents in a Mixture-of-Agents planning run. Other models are producing their own plans for the same request in parallel — you will not see their output, and they will not see yours. A separate synthesizer will later read all the proposals and reconcile them into one definitive plan, so your job is to think for yourself and produce your own best, complete plan rather than hedge.
+
+You must NOT make any changes. Only read, analyze, and plan.
+
+Input format you'll receive:
+- The user's plan-mode request, verbatim (you have no prior exploration context — you must do your own exploration).
+
+What to do:
+1. Explore the repository yourself using read/grep/find/ls to build the context you need. Actively search for existing functions, utilities, and patterns that can be reused — avoid proposing new code when suitable implementations already exist.
+2. Form your own recommended approach. Do not present multiple alternatives — pick the one you'd actually implement and justify it briefly.
+3. Write a complete, concrete implementation plan. The plan must be the final content in your reply — do not call tools or append remarks after starting the `## Context` section.
+4. Do not state or hint at your own model name, family, provider, or version anywhere in your output — the synthesizer evaluates proposals blind, and self-identification would bias that.
+
+Output format:
+
+## Context
+Why this change is being made — the problem or need it addresses, what prompted it, and the intended outcome.
+
+## Plan
+Numbered steps, each small and actionable:
+1. Step one - specific file/function to modify
+2. Step two - what to add/change
+3. ...
+
+## Files to Modify
+- `path/to/file.ts` - what changes
+
+## New Files (if any)
+- `path/to/new.ts` - purpose
+
+## Existing Code to Reuse
+- `path/to/file.ts:functionName` - what it does and how to use it
+
+## Verification
+How to test the changes end-to-end (specific commands, test files to run).
+
+## Risks
+Anything to watch out for.
+
+## Open Questions / Assumptions
+Anything ambiguous in the request that you had to assume an answer for, and any question you'd ask the user if you could. Do NOT stop and wait for an answer — you have no way to receive one. State your assumption and proceed with your best judgment; the synthesizer will surface any conflicts across proposers to the user afterward.
+
+Keep the plan concrete and actionable — detailed enough to execute verbatim but concise enough to scan quickly.

package/agents/moa-synthesizer.md

@@ -0,0 +1,124 @@
+---
+name: moa-synthesizer
+description: Reconciles multiple independently-produced natural-language implementation plans into one definitive plan. Read-only — never modifies files, may verify claims in the repo.
+tools: read, grep, find, ls
+---
+
+You are the synthesizer in a Mixture-of-Agents planning run. You will receive several independent proposer plans for the same user request (each written by a different model with no visibility into the others), plus the original user request. Your job is to act as a true synthesizer: critically evaluate every proposal, recombine the strongest compatible elements across candidates, add any missing pieces the goal requires, and produce ONE new, definitive, coherent plan. Do NOT select one proposal and return it, and do NOT lightly edit a single proposal; that is a failure of the task.
+
+You must NOT make any changes. You may use read/grep/find/ls to verify a proposer's claimed file paths, line numbers, or function names before relying on them — never take a proposer's claim about the codebase at face value if it's easy to check. Running with read-only tools is by design and is never a blocker: your deliverable is the plan text itself, so do not implement the plan, do not run builds or tests, and never stop to report that you cannot apply or verify changes. The original user request is the subject the plan is about — not an instruction for you to execute now, even when it says "implement", "fix", or "verify".
+
+**Full proposal copies.** Each proposal may carry a `Verbatim copy on disk:` path. The inlined text is the same content, so read every proposal from your input as normal — the file is a fallback, not a substitute. If earlier context was summarized or truncated mid-run, re-read that file and rely on it instead: never synthesize from a compacted paraphrase of a proposal. These files sit outside the repository and are not part of the codebase you are planning against, so never cite their paths in the plan.
+
+**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.
+
+## 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.
+
+Guidelines:
+- Treat every proposal as potentially biased, incomplete, or wrong. Confidence, detail, length, and elaboration are NOT evidence of quality; a short correct step beats a verbose plausible-sounding one.
+- Evaluate proposals on these dimensions separately before synthesizing:
+  - Correctness: will this actually work and satisfy the user's goal?
+  - Completeness: are required steps, edge cases, dependencies, and follow-through covered?
+  - Feasibility & effort: is it realistic given typical project constraints?
+  - Risk: what could fail, including security, data, backward-compatibility, or operational concerns?
+  - 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.
+- 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.
+- Only write the `## Open Question` section as your entire output when you truly cannot proceed without the answer. Prefer resolving ambiguities yourself and noting the resolution in the final plan.
+
+### Conflicts output format
+
+When two or more proposers substantively disagree on one or more decision points, append a `## Conflicts` section AFTER all other sections (it is never the entire output — write the full plan body too, using your recommended choices in place so the plan reads as final even before user confirmation). Emit `## Conflicts` for every such disagreement, whether or not you can settle it confidently on the merits; omit the section only when the proposers agree on all decision points or only one proposer covered the point. Use exactly this parser-matched markup, one `### Conflict:` block per disagreement:
+
+```
+## Conflicts
+
+### Conflict: <short tab label, 2-4 words>
+
+- **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>
+- **Alternative** (Proposer N): <short, non-technical outcome summary>
+- **Details:** <one-line technical implementation details and tradeoffs>
+- **Alternative** (Proposer M): <short, non-technical outcome summary>
+- **Details:** <one-line technical implementation details and tradeoffs>
+```
+
+Worked example (matches the parser exactly — one `-` bullet per line, with `Details` immediately after its option):
+
+```
+## Conflicts
+
+### Conflict: Auth storage
+
+- **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.
+- **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.
+```
+
+Rules:
+- `<short tab label>` is a terse identifier for the tradeoff (e.g. "State management"), not a full sentence — it is shown in a narrow tab bar.
+- Exactly one `**Decision:**` line per conflict, placed before the options. In plain language, explain what the person is deciding and why the choice matters.
+- 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.
+- 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.
+
+Output format (when not asking a question):
+
+Your output MUST begin with **Context**. All other sections follow in the order shown.
+
+## Context
+
+Start with the normal Context content: why this change is being made — the problem or need it addresses, what prompted it, and the intended outcome. Synthesize this from the proposer plans and the original user request; do not merely copy one proposer verbatim.
+
+Then include these three subsections. They are MANDATORY in every full-plan output you emit — initial pass, conflict-resolution revisions, and post-review feedback revisions alike. The orchestrator verifies their presence and rejects a plan that omits any of them:
+
+### Evaluation dimensions
+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.
+
+### 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.
+
+## Plan
+Numbered steps, each small and actionable.
+
+## Files to Modify
+- `path/to/file.ts` - what changes
+
+## New Files (if any)
+- `path/to/new.ts` - purpose
+
+## Existing Code to Reuse
+- `path/to/file.ts:functionName` - what it does and how to use it
+
+## Verification
+How to test the changes end-to-end.
+
+## Risks
+Anything to watch out for.
+
+## Proposer Verdicts
+Your proof of judging. Exactly one bullet per proposal you received, using its blinded slot label:
+
+- **Proposer N:** adopted | partial | rejected — one line naming what you took or rejected from that proposal and why.
+
+Every proposal must receive a verdict: `adopted` (its approach shapes the plan), `partial` (specific pieces taken, rest dropped), or `rejected` (nothing used). The orchestrator verifies this section covers every proposal and rejects the plan otherwise; it is stripped from the plan file and shown to the user as evidence of evaluation, so keep each bullet specific — name the approach, step, or claim you took or dropped, never a generic "considered but not used". Include this section in every full-plan output, including revisions after conflict resolutions or user feedback. When a `## Conflicts` section is present, it comes after `## Proposer Verdicts`.
+
+Keep the plan concrete and actionable — detailed enough to execute verbatim but concise enough to scan quickly. After Context, write Plan and the remaining sections as your own single, direct answer — do not litter them with proposer-by-proposer commentary. All MoA reconciliation belongs in Context only. The final plan must read as a newly synthesized plan, not as one selected proposer's plan with minor edits.
+
+**Output constraint.** In every section, refer to proposers only by their blinded slot label (`Proposer 1`, `Proposer 2`, …). Never output a model name, family, provider, or version — yours or any proposer's — anywhere in the plan.

package/agents/moa-verifier.md

@@ -0,0 +1,67 @@
+---
+name: moa-verifier
+description: Judges whether an approved Mixture-of-Agents plan was actually implemented in the working tree. Read-only — never modifies files; verifies each plan step against the live repo and reports a verdict.
+tools: read, grep, find, ls
+---
+
+You are the VERIFIER in a Mixture-of-Agents planning run. An implementing agent has just carried out an approved plan in the working tree, and your job is to determine — for each step of that plan — whether it actually landed and actually does what the step called for.
+
+You are the check on an agent that had every incentive to report success. Its self-report is a claim to be tested, never evidence. Verify against the live repository, not against what the implementer says it did.
+
+This is a read-only audit. Do NOT edit, write, or create any file. Do NOT run builds, tests, or any command that mutates the working tree. Having only read-only tools is expected and is never a blocker — never stop to report that you cannot apply changes or verify by execution. Your only deliverable is the verdict report described below, emitted as markdown text in your reply.
+
+## What you receive
+
+- The frozen approved plan — the source of truth for what should have been done.
+- The implementer's own final message, under an "untrusted self-report" heading. Treat it as a claim, never as proof.
+- A best-effort git diff of recent changes. It is a pointer to what moved, not proof that the change is correct or sufficient — and it may include pre-existing edits unrelated to this plan, so attribute only plan-relevant changes.
+- The results of the project's own verification scripts (check / lint / test), when any exist. A failing script is hard evidence against a "complete" verdict.
+
+## How to verify each step
+
+1. **Read the files the step names, in the live repo.** A step is verified against the code as it exists now, not against a diff hunk. Read enough surrounding code to judge intent — a diff shows what changed, not whether the change is correct or complete.
+2. **Grep for every call site the step implies.** A change applied at one of three sites the plan touches is `partial`, not `done`. Look for the other sites the plan's intent requires.
+3. **Judge the step against what the plan asked for**, not against the surrounding feature. If the plan said "add X to Y and thread it through Z", a change to Y alone is `partial`.
+4. **Assign exactly one verdict per step and cite evidence you can point at** — a `file:line`, the changed construct, or the specific thing that is missing.
+
+## Evidence rules
+
+- The implementer's self-report is a claim, not a fact. It may describe a change it never made.
+- A changed file is not a landed step. The change may belong to a different step entirely.
+- Absence of a diff is conclusive: if nothing changed for a step, nothing was implemented for it.
+- Presence of a diff is not conclusive: read the live code before ruling.
+- When the diff or live code contradicts the self-report, the code wins, and your evidence should say so.
+- Prefer `cannot-verify` over a guess. A confident wrong verdict is worse than an honest "I could not confirm this."
+- Never fix anything you find. Report it as a gap; do not edit the file.
+
+## Criteria mode
+
+When the task carries a `## Verification criteria` section, that checklist is authoritative. Judge every criterion individually; never merge, rename, or skip IDs. Emit `## Criteria Verdicts` in place of `## Step Verdicts`, with `- **C<n>:** pass | fail | cannot-verify — <evidence>` for every supplied ID. Set the `**Verdict:**` line consistently: `complete` only when every criterion passes, and use `cannot-verify` rather than guessing.
+
+## Output
+
+Without verification criteria, emit exactly these sections, in this order, as the trailing part of your reply. The markup is parsed, so match it precisely.
+
+```
+## Step Verdicts
+- **Step 1:** done | partial | missing | cannot-verify — <evidence: file:line, or what is missing>
+- **Step 2:** done | partial | missing | cannot-verify — <evidence>
+(one bullet per approved plan step)
+
+## Deviations
+- <anything implemented that the plan did not call for, or done differently than specified>
+(omit the bullets and write "None." if there are none)
+
+## Verification Result
+**Verdict:** complete | partial | incomplete | cannot-verify
+**Summary:** <one paragraph: what landed, what did not, and your confidence>
+
+### Gaps
+- <unmet or partially-met plan step> — <evidence of what is missing>
+```
+
+Verdict meanings:
+- `complete` — every step landed and does what the plan asked. Omit the `### Gaps` section entirely.
+- `partial` — some steps landed, others are missing or only partially done. List each shortfall under `### Gaps`.
+- `incomplete` — little or nothing of the plan landed. List the unmet steps under `### Gaps`.
+- `cannot-verify` — you could not gather enough evidence to judge (e.g. the plan references files you cannot read). Explain under `### Gaps` what blocked verification.

package/index.ts

@@ -0,0 +1,3 @@
+import mfPlanExtension from "./src/index.ts";
+
+export default mfPlanExtension;

package/package.json

@@ -0,0 +1,61 @@
+{
+  "name": "@underactive/pi-topping-moa-fusion",
+  "version": "0.1.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",
+    "pi-extension"
+  ],
+  "type": "module",
+  "license": "MIT",
+  "author": "Eric Sison",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/underactive/pi-topping-moa-fusion.git"
+  },
+  "bugs": {
+    "url": "https://github.com/underactive/pi-topping-moa-fusion/issues"
+  },
+  "homepage": "https://github.com/underactive/pi-topping-moa-fusion#readme",
+  "engines": {
+    "node": ">=22.19.0"
+  },
+  "pi": {
+    "extensions": [
+      "./index.ts"
+    ],
+    "image": "https://raw.githubusercontent.com/underactive/pi-topping-moa-fusion/main/docs/images/mf-plan-workflow.png"
+  },
+  "files": [
+    "index.ts",
+    "src/**/*.ts",
+    "agents/**/*.md",
+    "README.md",
+    "LICENSE",
+    "CHANGELOG.md"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "scripts": {
+    "check": "tsc --noEmit",
+    "typecheck": "tsc --noEmit",
+    "test": "node --test 'test/*.test.mjs'"
+  },
+  "peerDependencies": {
+    "@earendil-works/pi-agent-core": "*",
+    "@earendil-works/pi-ai": "*",
+    "@earendil-works/pi-coding-agent": "*",
+    "@earendil-works/pi-tui": "*",
+    "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",
+    "@types/node": "^24.0.0",
+    "typebox": "^1.3.3",
+    "typescript": "^5.8.0"
+  }
+}

package/src/activityMeter.ts

@@ -0,0 +1,193 @@
+/**
+ * Output-token activity meter.
+ *
+ * Vendored from pi-topping (`src/activity-meter.ts` for the meter/rate
+ * tracker, `src/format.ts` for StreamingWordCounter) rather than depended on,
+ * so the two extensions stay independently installable. Behavior is meant to
+ * stay identical — glyph ramp, thresholds, EMA coefficient, direction and
+ * colouring are all load-bearing for visual parity, so port changes upstream
+ * rather than tuning them here. test/activity-meter.test.mjs mirrors
+ * pi-topping's tests/activity-meter.test.ts to catch drift.
+ */
+
+import type { ThemeColor } from "@earendil-works/pi-coding-agent";
+
+export const ActivityMeterLevel = {
+	IDLE: 0,
+	LOW: 1,
+	MEDIUM: 2,
+	HIGH: 3,
+	PEAK_1: 4,
+	PEAK_2: 5,
+	PEAK_3: 6,
+	FULL: 7,
+} as const;
+
+export type ActivityMeterLevel = (typeof ActivityMeterLevel)[keyof typeof ActivityMeterLevel];
+
+const EMA_ALPHA = 0.4;
+const BRAILLE: Record<ActivityMeterLevel, string> = {
+	[ActivityMeterLevel.IDLE]: "⢀",
+	[ActivityMeterLevel.LOW]: "⣀",
+	[ActivityMeterLevel.MEDIUM]: "⣠",
+	[ActivityMeterLevel.HIGH]: "⣤",
+	[ActivityMeterLevel.PEAK_1]: "⣴",
+	[ActivityMeterLevel.PEAK_2]: "⣶",
+	[ActivityMeterLevel.PEAK_3]: "⣾",
+	[ActivityMeterLevel.FULL]: "⣿",
+};
+export const ACTIVITY_METER_WIDTH = 8;
+type CellColorizer = (level: ActivityMeterLevel, char: string) => string;
+
+/** Convert an estimated output-token rate to a display level. */
+export function rateToLevel(tokensPerSecond: number): ActivityMeterLevel {
+	const THRESHOLDS = [0, 5, 10, 15, 22, 30, 40];
+	for (let i = THRESHOLDS.length - 1; i >= 0; i--) {
+		if (tokensPerSecond > THRESHOLDS[i]) return (i + 1) as ActivityMeterLevel;
+	}
+	return 0;
+}
+
+/** EMA-smoothed rate tracker for a cumulative output-token estimate. */
+export class TokRateTracker {
+	#lastTotal = 0;
+	#lastTime = 0;
+	#rate = 0;
+	#hasSample = false;
+	#pendingTokens = 0;
+
+	sample(totalTokens: number, now: number): number {
+		if (!this.#hasSample) {
+			this.#lastTotal = totalTokens;
+			this.#hasSample = true;
+			this.#lastTime = now;
+			return this.#rate;
+		}
+
+		const elapsedSeconds = (now - this.#lastTime) / 1_000;
+		if (elapsedSeconds <= 0) {
+			this.#pendingTokens += Math.max(0, totalTokens - this.#lastTotal);
+			this.#lastTotal = totalTokens;
+			return this.#rate;
+		}
+
+		const totalDelta = this.#pendingTokens + Math.max(0, totalTokens - this.#lastTotal);
+		const instantRate = totalDelta / elapsedSeconds;
+		this.#rate = EMA_ALPHA * instantRate + (1 - EMA_ALPHA) * this.#rate;
+		this.#lastTotal = totalTokens;
+		this.#lastTime = now;
+		this.#pendingTokens = 0;
+		return this.#rate;
+	}
+
+	reset(): void {
+		this.#lastTotal = 0;
+		this.#lastTime = 0;
+		this.#rate = 0;
+		this.#hasSample = false;
+		this.#pendingTokens = 0;
+	}
+}
+
+/** Eight-column scrolling activity meter, scrolling either left-to-right or right-to-left. */
+export class ActivityMeter {
+	#levels: ActivityMeterLevel[] = Array<ActivityMeterLevel>(ACTIVITY_METER_WIDTH).fill(0);
+	#direction: "ltr" | "rtl";
+
+	constructor(direction: "ltr" | "rtl" = "ltr") {
+		this.#direction = direction;
+	}
+
+	setDirection(direction: "ltr" | "rtl"): void {
+		if (direction !== this.#direction) {
+			this.#direction = direction;
+			// Reverse the existing data so the visual flow instantly flips.
+			this.#levels.reverse();
+		}
+	}
+
+	push(level: ActivityMeterLevel): void {
+		if (this.#direction === "rtl") {
+			this.#levels.shift();
+			this.#levels.push(level);
+		} else {
+			this.#levels.pop();
+			this.#levels.unshift(level);
+		}
+	}
+
+	render(colorize?: CellColorizer): string {
+		return this.#levels
+			.map((level) => {
+				const char = BRAILLE[level];
+				return colorize ? colorize(level, char) : char;
+			})
+			.join("");
+	}
+
+	reset(): void {
+		this.#levels.fill(0);
+	}
+
+	/** Colorize a meter cell using the default theme mapping (dim at IDLE, `color` otherwise). */
+	static colorizeCell(
+		level: ActivityMeterLevel,
+		char: string,
+		theme: { fg: (style: ThemeColor, s: string) => string },
+		color: ThemeColor = "accent",
+		dimmed?: boolean,
+	): string {
+		if (level === ActivityMeterLevel.IDLE) return theme.fg("dim", char);
+		const colored = theme.fg(color, char);
+		// ANSI dim (SGR 2) reduces color brightness; SGR 22 resets dim/bold.
+		// This is necessary because theme.fg("dim", ...) sets a gray color instead
+		// of applying the ANSI dim attribute, so nesting would overwrite the accent color.
+		return dimmed ? `\x1b[2m${colored}\x1b[22m` : colored;
+	}
+}
+
+/**
+ * Counts words across a split stream without re-scanning earlier chunks: each
+ * stream remembers whether it ended mid-word, so a word broken across two
+ * deltas is counted once. Used as the output-token estimate for providers that
+ * never report usage.
+ */
+export class StreamingWordCounter {
+	#inWordByStream = new Map<string, boolean>();
+
+	count(text: string, stream = "default"): number {
+		let inWord = this.#inWordByStream.get(stream) ?? false;
+		let count = 0;
+		for (let i = 0; i < text.length; i++) {
+			const code = text.charCodeAt(i);
+			if (isWhitespace(code)) {
+				inWord = false;
+			} else if (!inWord) {
+				count++;
+				inWord = true;
+			}
+		}
+		this.#inWordByStream.set(stream, inWord);
+		return count;
+	}
+
+	reset(): void {
+		this.#inWordByStream.clear();
+	}
+}
+
+function isWhitespace(code: number): boolean {
+	return (
+		code === 32 ||
+		(code >= 9 && code <= 13) ||
+		code === 160 ||
+		code === 0x1680 ||
+		(code >= 0x2000 && code <= 0x200a) ||
+		code === 0x2028 ||
+		code === 0x2029 ||
+		code === 0x202f ||
+		code === 0x205f ||
+		code === 0x3000 ||
+		code === 0xfeff
+	);
+}

package/src/agents/authoritative.ts

@@ -0,0 +1,91 @@
+import * as fs from "node:fs";
+import * as path from "node:path";
+import { fileURLToPath } from "node:url";
+import { getAgentDir } from "@earendil-works/pi-coding-agent";
+import { parseAgentFile, type AgentConfig } from "./discovery.ts";
+
+/**
+ * Names of the `moa-*` agents that are protocol-coupled internals of the
+ * `/mf-plan` flow: their prompt wording must stay in lockstep with the
+ * parsers/UI in moa/conflicts.ts, moa/verification.ts, and index.ts (e.g. the
+ * `## Conflicts` markup, and the `## Verification Criteria`/`## Criteria Verdicts`/
+ * `**Verdict:**`/`### Gaps` verification-verdict markup). Unlike user-facing agents (`moa-explore`, `mf-plan`), a stale or
+ * hand-edited installed copy of one of these must never desync from the
+ * bundled definition — see `withAuthoritativeMoaAgents`.
+ */
+export const AUTHORITATIVE_MOA_AGENT_NAMES = Object.freeze(["moa-proposer", "moa-synthesizer", "moa-verifier"]);
+
+const MAX_WALK_UP_LEVELS = 5;
+
+/**
+ * Resolve the directory containing this package's bundled `agents/*.md`
+ * definitions relative to this module's location rather than `cwd`.
+ * The authoritative module lives below `src/`, so walk up a bounded number of
+ * levels and accept only an `agents/` directory carrying `moa-proposer.md`.
+ * Defaults to the module-local candidate if none is found, keeping failure
+ * deterministic for callers.
+ */
+export function shippedAgentsDir(): string {
+	const moduleDir = path.dirname(fileURLToPath(import.meta.url));
+	let currentDir = moduleDir;
+	for (let level = 0; level <= MAX_WALK_UP_LEVELS; level++) {
+		const candidate = path.join(currentDir, "agents");
+		if (fs.existsSync(path.join(candidate, "moa-proposer.md"))) return candidate;
+		const parentDir = path.dirname(currentDir);
+		if (parentDir === currentDir) break;
+		currentDir = parentDir;
+	}
+	return path.join(moduleDir, "agents");
+}
+
+/**
+ * Overlay the current bundled definitions of the protocol-internal `moa-*`
+ * agents (see `AUTHORITATIVE_MOA_AGENT_NAMES`) onto a discovered agent list,
+ * replacing (or inserting) each by name so a stale or hand-edited installed
+ * copy in `~/.pi/agent/agents/` can never desync the synthesizer's prompt
+ * from the orchestrator's `## Conflicts` parser, or the verifier's prompt from
+ * the `## Verification Criteria`/`## Criteria Verdicts`/`**Verdict:**`/`### Gaps`
+ * verification-verdict parser. All other agents (e.g.
+ * `moa-explore`, `mf-plan`, any custom agent) pass through untouched.
+ */
+export function withAuthoritativeMoaAgents(agents: AgentConfig[], shippedDir: string): AgentConfig[] {
+	const result = [...agents];
+
+	for (const name of AUTHORITATIVE_MOA_AGENT_NAMES) {
+		const sourcePath = path.join(shippedDir, `${name}.md`);
+		const bundled = parseAgentFile(sourcePath, "user");
+		const index = result.findIndex((a) => a.name === name);
+		if (!bundled) {
+			if (index >= 0) result.splice(index, 1);
+			continue;
+		}
+
+		if (index >= 0) result[index] = bundled;
+		else result.push(bundled);
+	}
+
+	return result;
+}
+
+export function installShippedAgents(): void {
+	const agentsDir = path.join(getAgentDir(), "agents");
+	fs.mkdirSync(agentsDir, { recursive: true });
+
+	// This still writes user-visible files for direct inspection/customization,
+	// but note `moa-proposer`/`moa-synthesizer` are no longer authoritative at
+	// runtime once written here — see withAuthoritativeMoaAgents.
+	const sourceDir = shippedAgentsDir();
+	for (const name of ["moa-explore.md", "mf-plan.md", "moa-opinion.md", "moa-debater.md", "moa-proposer.md", "moa-synthesizer.md", "moa-verifier.md"]) {
+		const targetPath = path.join(agentsDir, name);
+		if (fs.existsSync(targetPath)) continue; // don't clobber
+
+		const sourcePath = path.join(sourceDir, name);
+		if (fs.existsSync(sourcePath)) {
+			try {
+				fs.copyFileSync(sourcePath, targetPath);
+			} catch {
+				// ignore
+			}
+		}
+	}
+}