fanout-cli 0.7.0 → 0.9.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fanout-cli",
-  "version": "0.7.0",
+  "version": "0.9.0",
   "description": "Let Claude Code lead the other coding-agent CLIs you already pay for.",
   "license": "MIT",
   "type": "module",
@@ -18,27 +18,31 @@
   },
   "exports": {
     ".": {
-      "types": "./dist/main.d.ts",
-      "default": "./dist/main.js"
+      "default": "./dist/cli.js"
     }
   },
   "files": [
     "dist",
+    "plugin",
     "README.md",
     "LICENSE"
   ],
   "dependencies": {
     "@modelcontextprotocol/sdk": "1.30.0",
-    "fanout-adapter-claude": "0.7.0",
-    "fanout-adapter-codex": "0.7.0",
-    "fanout-core": "0.7.0",
-    "fanout-adapter-grok": "0.7.0",
-    "fanout-mcp": "0.7.0",
-    "fanout-adapter-fake": "0.7.0",
-    "fanout-daemon": "0.7.0"
+    "ws": "8.21.3",
+    "zod": "4.6.2"
+  },
+  "devDependencies": {
+    "fanout-adapter-claude": "0.9.0",
+    "fanout-adapter-codex": "0.9.0",
+    "fanout-core": "0.9.0",
+    "fanout-adapter-grok": "0.9.0",
+    "fanout-adapter-fake": "0.9.0",
+    "fanout-daemon": "0.9.0",
+    "fanout-mcp": "0.9.0"
   },
   "scripts": {
     "typecheck": "tsc -p tsconfig.json",
-    "build": "tsc -p tsconfig.build.json"
+    "build": "node ../../scripts/bundle-cli.mjs"
   }
 }

package/plugin/.claude-plugin/plugin.json

@@ -0,0 +1,12 @@
+{
+  "name": "fanout",
+  "description": "Lead a crew of the coding-agent CLIs you already pay for: plan, fan out into isolated git worktrees, watch, and review before anything merges.",
+  "version": "0.6.0",
+  "author": {
+    "name": "elberacasa"
+  },
+  "homepage": "https://github.com/elberacasa/fanout",
+  "repository": "https://github.com/elberacasa/fanout",
+  "license": "MIT",
+  "keywords": ["agents", "orchestration", "codex", "grok", "worktrees", "local-first"]
+}

package/plugin/.mcp.json

@@ -0,0 +1,10 @@
+{
+  "mcpServers": {
+    "fanout": {
+      "type": "stdio",
+      "command": "node",
+      "args": ["${CLAUDE_PLUGIN_ROOT}/bin/fanout", "mcp"],
+      "env": {}
+    }
+  }
+}

package/plugin/README.md

@@ -0,0 +1,44 @@
+# The Fanout plugin for Claude Code
+
+Claude Code becomes the lead: it plans a mission, fans it out to the other agent CLIs on your machine, watches them
+work in isolated git worktrees, and reviews every diff. Nothing merges without you.
+
+## What you get
+
+| | |
+|---|---|
+| `/fanout <goal>` | Plan a mission, check it against the safety gate, launch it, and watch it |
+| `/fanout:crew` | Which CLIs are installed, signed in, and ready |
+| `/fanout:watch [mission]` | Subscribe to the live feed and review each run as it finishes |
+| The `fanout` skill | The lead's judgment: when to fan out, how to write a prompt an agent can follow, how to review what comes back |
+| Hooks | The crew at the start of a session; a warning if runs are still going when you stop |
+| Seven MCP tools | `seats`, `repo_overview`, `plan_check`, `launch`, `mission_status`, `run_diff`, `cancel_mission` |
+
+## Installing
+
+The plugin runs `fanout mcp`, so the `fanout` command must be on your `PATH`.
+
+**From a clone**, while the package is not yet published:
+
+```sh
+git clone https://github.com/elberacasa/fanout.git && cd fanout
+corepack enable && pnpm install
+pnpm --filter fanout-cli link --global   # puts `fanout` on your PATH
+claude --plugin-dir "$PWD/plugin"          # try it in one session
+```
+
+Check it before you rely on it:
+
+```sh
+fanout status        # your crew
+claude plugin validate plugin
+```
+
+## What it will not do
+
+- **It will not merge.** It reads a run's diff from the workspace and hands you the decision. The merge gate, with
+  review, your project's checks and proof that a fix fails on the old code, is the next milestone.
+- **It will not work around a usage limit.** A seat that is out of quota is out; the lead says so and uses another.
+- **It will not hand an agent your secrets.** Workspaces exclude ignored and deny-listed files, and a run gets an
+  allowlisted environment only — never your shell's.
+- **It sends nothing anywhere.** The daemon listens on `127.0.0.1` with a token only you can read.

package/plugin/bin/fanout

@@ -0,0 +1,48 @@
+#!/usr/bin/env node
+/*
+ * Run as `node bin/fanout`, never relied on as an executable. npm strips the executable bit from every file it
+ * does not list in `bin`, so the published copy of this arrives at mode 644 and spawning it directly fails with
+ * EACCES on a stranger's machine and nowhere else. Going through `node` removes the whole question, along with
+ * the same question on Windows.
+ */
+import { existsSync } from "node:fs";
+import { fileURLToPath } from "node:url";
+
+/*
+ * Finding the CLI from inside the plugin, whichever way Fanout was installed.
+ *
+ * The plugin's `.mcp.json` and hooks used to point straight at `${CLAUDE_PLUGIN_ROOT}/../packages/cli/src/cli.ts`,
+ * which is the layout of a git checkout and of nothing else. Anyone who installed from npm got a plugin whose
+ * every entry point resolved to a file that was not there — and the README's first sentence calls this a Claude
+ * Code plugin, so the published package delivered half of what it claimed.
+ *
+ * There are two real layouts and this script is the one place that knows the difference:
+ *
+ *   published   <package>/plugin/bin/fanout  →  <package>/dist/cli.js
+ *   checkout    <repo>/plugin/bin/fanout     →  <repo>/packages/cli/src/cli.ts
+ *
+ * Ordered with the published layout first: that is the one a stranger has, and the one nobody here would notice
+ * was broken.
+ */
+
+const here = new URL(".", import.meta.url);
+const candidates = ["../../dist/cli.js", "../../packages/cli/src/cli.ts"];
+
+const cli = candidates.map((path) => fileURLToPath(new URL(path, here))).find((path) => existsSync(path));
+
+if (cli === undefined) {
+  process.stderr.write(
+    "fanout: this plugin cannot find the Fanout CLI beside it.\n" +
+      "  Looked for dist/cli.js and packages/cli/src/cli.ts next to the plugin directory.\n" +
+      "  If you installed from npm, reinstall fanout-cli; if this is a checkout, run pnpm install first.\n",
+  );
+  process.exit(69);
+}
+
+/*
+ * Imported rather than spawned. A second process would double the startup and, more importantly, put a pipe
+ * between Claude Code and an MCP server that speaks over stdin and stdout — the one place an extra hop can
+ * silently reorder or buffer a conversation.
+ */
+process.argv = [process.argv[0] ?? "node", cli, ...process.argv.slice(2)];
+await import(cli);

package/plugin/commands/crew.md

@@ -0,0 +1,11 @@
+---
+description: Show which agent CLIs are installed, signed in and ready to work
+---
+
+Call the `seats` tool and report the crew in one short table: seat, version, and whether it is ready.
+
+Be exact about what is not known. A CLI with no way to report sign-in is **unknown**, never "ready". If a seat is
+installed but signed out, say the command that fixes it (`codex login`, `cursor-agent login`, and so on). If a seat
+is an unsupported version, say which versions this build was verified against rather than guessing that it works.
+
+Then, in one line, say what the crew could take on right now.

package/plugin/commands/fanout.md

@@ -0,0 +1,30 @@
+---
+description: Plan a mission, fan it out to your other agent CLIs, and watch it
+argument-hint: "[what you want done]"
+---
+
+The user wants this done by the crew: **$ARGUMENTS**
+
+You are the lead. Work in this order, and do not skip the parts that keep it safe.
+
+1. **Look before planning.** Call `repo_overview` and `seats`. If no seat is ready, say so and stop: there is no
+   crew to lead.
+2. **Split the work honestly.** One line per piece that can stand alone, each with:
+   - a **write scope** narrow enough that no two lines that run at once can touch the same file;
+   - a **prompt** that names the exact files, the expected behaviour with an example, the project's check commands,
+     and "do not commit";
+   - a **seat**: give the risky or subtle piece to the strongest seat, the mechanical piece to the cheapest, and
+     read-only work to an auditor. Claude is opt-in; prefer the other subscriptions.
+   Dependent work goes in `dependsOn` rather than in one big line.
+3. **Check before launching.** Call `plan_check`. Fix what it blocks; do not argue with it. Show the user the plan
+   as a short list (line, seat, scope) and the dry run if they ask.
+4. **Launch** with `launch`, then tell the user the mission id and what each line is doing.
+5. **Watch** with `mission_status`. While runs are going, do not start unrelated work in this session: you are the
+   lead, and reviewing is your job.
+6. **Review each finished run** with `run_diff`. Read the risky lines yourself. Anything written outside its scope
+   is the first thing you look at. Then tell the user, per run: what it changed, what you would keep, what you would
+   not, and what you could not verify.
+7. **Merging is the user's call, and it is not automatic.** Apply a diff yourself only when they say so, run the
+   project's real checks afterwards, and never present an agent's "tests pass" as your own verification.
+
+If something fails, say which line, why, and what you propose — never "it didn't work".

package/plugin/commands/watch.md

@@ -0,0 +1,20 @@
+---
+description: Watch a running mission and review each run as it finishes
+argument-hint: "[mission id]"
+---
+
+Watch the mission **$ARGUMENTS** (if no id is given, use the most recent one you launched).
+
+Subscribe to the live feed rather than polling in a loop: start a Monitor on the daemon's WebSocket, which only
+sends the events a lead acts on.
+
+```
+ws://127.0.0.1:<port>/events?for=lead&missionId=$ARGUMENTS&token=<token>
+```
+
+The port is in `~/.fanout/daemon.json` and the token in `~/.fanout/token`. Read both; never print the token.
+
+When a run finishes, review it straight away with `run_diff` while the rest are still going: read what it changed,
+look first at anything written outside its declared scope, and tell the user in two or three lines what you would
+keep and what you would not. When every run has finished, give the mission summary: what succeeded, what failed and
+why, and what you recommend merging.

package/plugin/hooks/hooks.json

@@ -0,0 +1,28 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node",
+            "args": ["${CLAUDE_PLUGIN_ROOT}/bin/fanout", "status"],
+            "timeout": 20
+          }
+        ]
+      }
+    ],
+    "Stop": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "node",
+            "args": ["${CLAUDE_PLUGIN_ROOT}/bin/fanout", "owed"],
+            "timeout": 20
+          }
+        ]
+      }
+    ]
+  }
+}

package/plugin/skills/fanout/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: fanout
+description: Lead a crew of agent CLIs (Codex, Grok, Claude) through the Fanout tools - plan a mission, fan it out into isolated git worktrees, watch it, and review every diff before anything merges. Use when a task splits into independent pieces that can run in parallel, or when the user asks for the crew, a fan-out, or a mission. Not for a single edit you can make yourself.
+---
+
+# Leading a crew with Fanout
+
+The Fanout MCP server runs the other agent CLIs on this machine. You stay the lead: you plan, you review, and the
+user decides what merges. The tools do the mechanics — worktrees, launching, limits, the ledger — so that your
+judgment is the only thing that has to be good.
+
+## Before you say anything is done
+
+This part applies to **your own** code, not only to work you fanned out. Most of the code in a session is written
+by you and read by nobody else, and your own reasoning is exactly what makes your mistakes invisible to you: you
+know why it is right, so it looks right.
+
+So before telling the user work is finished, call `check_claims` with two to four things you believe about your own
+uncommitted changes. Another vendor's CLI reads them cold — no plan, no justification, just the diff — and tries to
+falsify each one.
+
+**Write claims that can be proven false.**
+
+| Write this | Not this |
+|---|---|
+| "No caller of `total()` passes fewer than two arguments" | "The refactor is safe" |
+| "Nothing outside `src/api/` changed behaviour" | "It works" |
+| "Every new branch in `parse()` has a test" | "Well tested" |
+| "A symlink cannot lead the reviewer outside the copy" | "Isolation is handled" |
+
+Half the value arrives before the tool runs: a claim you cannot phrase falsifiably is usually one you have not
+actually checked.
+
+**Read the verdicts as written.** `confirmed` means it was actively checked. `unclear` means the reader could not
+tell — which is *not* a pass, and is worth a second look at whether the claim was answerable. `refuted` means stop:
+fix it, and when you fix it, add the test that would have caught it, so it cannot come back.
+
+State the refutations to the user in the reader's own words. A second opinion that you summarise into agreement is
+not a second opinion.
+
+## When this is worth it
+
+Fan out when the work splits into pieces that touch **different files** and can be described precisely. Two lines
+that need the same file are one line, or two lines in sequence. A single edit you can make in a minute is not a
+mission; making it yourself is faster and better.
+
+Good shapes:
+
+| Shape | Seat | Scope |
+|---|---|---|
+| Map a system, find bugs, write a spec | auditor (read-only) | no write scope |
+| Implement a well-specified change with tests | builder | the files it owns |
+| Write tests for a rule before it exists | tester | the test files |
+| One server contract, several clients | builders in parallel | one area each |
+
+## The loop
+
+1. `repo_overview` and `seats` before planning. No ready seat, no mission.
+2. Write the plan. Per line: a narrow write scope, a prompt that names files, an example, the project's check
+   commands and "do not commit", and the seat that suits the work. Risky or subtle work goes to the strongest seat;
+   mechanical work to the cheapest. Claude is opt-in, because the lead already spends that subscription.
+3. `plan_check`. It refuses overlapping scopes, missing seats, dangerous flags and uncommitted work inside a scope.
+   Fix the plan rather than arguing with the gate.
+4. `launch`. Tell the user the mission id and what each line will do.
+5. `mission_status` while it runs; review each run with `run_diff` as it finishes rather than all at the end.
+6. Report per run: what changed, what you would keep, what you would not, what you could not verify. The user
+   decides what merges.
+
+## Writing a prompt an agent can actually follow
+
+Name the files. Give one example of input and expected output. State the invariants it must not break. Give the
+exact check commands. Say "do not commit, do not create branches". Ask for a final message that lists what changed,
+what it deliberately left alone, and the test counts — and say plainly when a sandbox could not run a check.
+
+Agents do better with a checklist than with a goal.
+
+## Reviewing what comes back
+
+- Read the diff, not the report. `run_diff` reads the workspace itself; the report is the agent's own account.
+- Look first at anything written **outside its declared scope**. That is where the surprises are.
+- Check the invariants yourself: money, auth, migrations, anything that picks a default value, anything that could
+  leak a real value into a test.
+- A bug fix needs a test that fails on the old code. If it does not have one, that is the rework.
+- Never present an agent's "tests pass" as your own verification. Run the project's checks yourself after applying.
+
+## Bringing a run home
+
+When an agent finishes, the gate is four tools in order, and each one records the revision it judged. If the work
+changes between any two of them, the later ones refuse — which is the point.
+
+1. **`run_diff`** — read it yourself, line by line, before anything else. An agent's report is what it believes it
+   did.
+2. **`review_run`** — your verdict, and *what you actually checked*. "Looks fine" is not a review. `rework` sends
+   it back to the same session; `reject` ends the line.
+3. **`rework_run`** if you asked for changes — it continues the same conversation in the same worktree, so the
+   agent still has its own reasoning about the code. Running the line again instead throws that away and costs the
+   same. Two rounds; after that, decide rather than asking a third time.
+4. **`run_checks`** — the project's own commands, run by the gate rather than reported by the agent. A line that
+   declared no checks comes back **unverified**, which is not the same as passing.
+5. **`prove_fix`** — only for a line the plan marked `fixesBug`. The test goes onto the *old* code and must fail
+   there. If it passes, it would have passed before the fix.
+6. **Ask the user**, in the chat, in their own words. Then **`merge_run`** with what they said.
+
+You cannot merge your own way past any of this: `merge_run` asks a pure function over recorded facts, and reports
+the refusals rather than working around them. Read them out to the user as written.
+
+**Never call `merge_run` without having asked.** The tool records the user as the authority, and a replay months
+from now will show that. Putting words in their mouth there is the worst thing you can do with these tools.
+
+## The claim loop, in full
+
+```text
+claim  →  refuted  →  failing test  →  fix  →  checked again  →  confirmed
+```
+
+The middle step is the one people skip. A refutation you fix without a test is a bug you will write again; a
+refutation you fix *with* a test that fails on the old code is the project's fourth non-negotiable, satisfied
+without anybody having to be reminded of it.
+
+## What this skill will not do
+
+- It will not merge. Applying a diff is the user's decision, and the merge gate (with review, checks and proof)
+  arrives in a later milestone.
+- It will not work around a seat's usage limit. A seat that is out of quota is out; say so and use another.
+- It will not hand an agent your secrets: workspaces exclude ignored and deny-listed files, and a run gets an
+  allowlisted environment only.

package/dist/cli.d.ts

@@ -1,3 +0,0 @@
-#!/usr/bin/env node
-export {};
-//# sourceMappingURL=cli.d.ts.map

package/dist/cli.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":""}

package/dist/demo.d.ts

@@ -1,32 +0,0 @@
-import type { PlanLine } from "fanout-core";
-import type { ScenarioInput } from "fanout-adapter-fake";
-/** A small repository worth changing: three areas, one seeded bug, one commit. */
-export declare function buildDemoRepo(root: string): string;
-export declare const DEMO_GOAL = "Add CSV export and fix the December date bug";
-/**
- * Three lines that touch three different areas.
- *
- * One of them is marked `fixesBug`, which is the flag the merge gate holds to the fourth non-negotiable: that
- * line cannot merge without a test proven to fail on the old code. The demo exists partly to show that refusal.
- */
-export declare function demoLines(): PlanLine[];
-/**
- * What each simulated agent does, second by second.
- *
- * `timeScale` is the only dishonesty about time and it is the useful kind: a real run takes minutes and nobody
- * watches a demo for minutes. The phases, the tool calls and the files are what a real run of this shape does.
- */
-export declare function demoScenario(line: PlanLine): ScenarioInput;
-/**
- * The claim check the demo shows, written here rather than asked of anyone.
- *
- * Marked `simulated` all the way through to the screen. A real check needs a real second vendor and a
- * subscription; inventing one and presenting it as read would be faking the single thing this product claims to
- * do, which is worse than having no demo at all.
- */
-export declare function demoClaims(): {
-    claim: string;
-    verdict: "confirmed" | "refuted" | "unclear";
-    evidence: string;
-}[];
-//# sourceMappingURL=demo.d.ts.map

package/dist/demo.d.ts.map

@@ -1 +0,0 @@
-{"version":3,"file":"demo.d.ts","sourceRoot":"","sources":["../src/demo.ts"],"names":[],"mappings":"AAGA,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,aAAa,CAAC;AAC5C,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,qBAAqB,CAAC;AAezD,kFAAkF;AAClF,wBAAgB,aAAa,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,CAoClD;AAED,eAAO,MAAM,SAAS,iDAAiD,CAAC;AAExE;;;;;GAKG;AACH,wBAAgB,SAAS,IAAI,QAAQ,EAAE,CA2CtC;AAED;;;;;GAKG;AACH,wBAAgB,YAAY,CAAC,IAAI,EAAE,QAAQ,GAAG,aAAa,CAoF1D;AAED;;;;;;GAMG;AACH,wBAAgB,UAAU,IAAI;IAC5B,KAAK,EAAE,MAAM,CAAC;IACd,OAAO,EAAE,WAAW,GAAG,SAAS,GAAG,SAAS,CAAC;IAC7C,QAAQ,EAAE,MAAM,CAAC;CAClB,EAAE,CAkBF"}

package/dist/demo.js

@@ -1,207 +0,0 @@
-import { execFileSync } from "node:child_process";
-import { mkdirSync, rmSync, writeFileSync } from "node:fs";
-import { join } from "node:path";
-/*
- * A whole mission, on a machine with no accounts on it.
- *
- * Everything here is the real thing except the thinking. Real git worktrees, the real safety gate, the real
- * append-only ledger, real diffs collected from real files — driven by the `fake` seat, which is a genuine CLI
- * speaking the genuine protocol and taking a script instead of a model. Nothing is stubbed out inside the daemon,
- * because a demo that exercised a special path would be a demo of something nobody ships.
- *
- * It is honest about the one thing it cannot do. A cold reader's verdicts need a real second vendor; the demo's
- * are written here, and every surface that shows them says `simulated` out loud. Faking the one claim the product
- * makes would be the single most dishonest thing this repository could contain.
- */
-/** A small repository worth changing: three areas, one seeded bug, one commit. */
-export function buildDemoRepo(root) {
-    rmSync(root, { recursive: true, force: true });
-    mkdirSync(join(root, "src", "api"), { recursive: true });
-    mkdirSync(join(root, "src", "ui"), { recursive: true });
-    mkdirSync(join(root, "docs"), { recursive: true });
-    writeFileSync(join(root, "src", "api", "orders.ts"), "export interface Order {\n  id: string;\n  total: number;\n}\n\n" +
-        "export function ordersFor(customer: string): Order[] {\n  return [];\n}\n");
-    writeFileSync(join(root, "src", "api", "dates.ts"), "/** Formats a day. Off by one in December: the bug this demo fixes. */\n" +
-        "export function monthOf(date: Date): number {\n  return date.getMonth();\n}\n");
-    writeFileSync(join(root, "src", "ui", "table.ts"), "export const columns = ['id', 'total'];\n");
-    writeFileSync(join(root, "docs", "orders.md"), "# Orders\n\nThe orders API.\n");
-    writeFileSync(join(root, "package.json"), `${JSON.stringify({ name: "demo-shop", private: true, scripts: { check: "echo ok" } }, null, 2)}\n`);
-    const git = (args) => {
-        execFileSync("git", args, {
-            cwd: root,
-            stdio: "ignore",
-            env: { PATH: process.env["PATH"] ?? "", HOME: process.env["HOME"] ?? "", GIT_CONFIG_NOSYSTEM: "1" },
-        });
-    };
-    git(["init", "--quiet", "-b", "main"]);
-    git(["config", "user.email", "demo@example.invalid"]);
-    git(["config", "user.name", "Fanout demo"]);
-    git(["add", "-A"]);
-    git(["commit", "--quiet", "-m", "the shop, before the crew arrives"]);
-    return root;
-}
-export const DEMO_GOAL = "Add CSV export and fix the December date bug";
-/**
- * Three lines that touch three different areas.
- *
- * One of them is marked `fixesBug`, which is the flag the merge gate holds to the fourth non-negotiable: that
- * line cannot merge without a test proven to fail on the old code. The demo exists partly to show that refusal.
- */
-export function demoLines() {
-    return [
-        {
-            id: "api",
-            title: "CSV export endpoint",
-            role: "builder",
-            prompt: "Add GET /orders.csv, streaming rows and escaping quotes.",
-            seat: { id: "fake", model: "demo" },
-            // Narrowed to the file it writes. `src/api/**` swallowed the dates line's scope, and the safety gate
-            // refused the plan — on the product's own demo, which is the best argument for the check there is.
-            scope: { write: ["src/api/csv.ts"] },
-            dependsOn: [],
-            checks: ["npm run check"],
-            fixesBug: false,
-        },
-        {
-            id: "dates",
-            title: "Fix the December month bug",
-            role: "builder",
-            prompt: "monthOf() is off by one in December. Fix it and prove it with a test.",
-            seat: { id: "fake", model: "demo" },
-            scope: { write: ["src/api/dates.ts", "src/api/dates.test.ts"] },
-            dependsOn: [],
-            checks: ["npm run check"],
-            fixesBug: true,
-        },
-        {
-            id: "ui",
-            title: "Export button",
-            role: "builder",
-            /*
-             * The one line that asks for a seat this machine does not have. Nothing here fakes the consequence: the
-             * demo's crew really is the simulated seat alone, so the router really does move this line and really does
-             * say why — which is the behaviour worth showing, and the only honest way to show it offline.
-             */
-            prompt: "Add the export column and a button that hits the new endpoint.",
-            seat: { id: "codex", model: "gpt-5-codex" },
-            scope: { write: ["src/ui/**"] },
-            dependsOn: [],
-            checks: ["npm run check"],
-            fixesBug: false,
-        },
-    ];
-}
-/**
- * What each simulated agent does, second by second.
- *
- * `timeScale` is the only dishonesty about time and it is the useful kind: a real run takes minutes and nobody
- * watches a demo for minutes. The phases, the tool calls and the files are what a real run of this shape does.
- */
-export function demoScenario(line) {
-    const scenarios = {
-        api: {
-            steps: [
-                { phase: "reading", delayMs: 900 },
-                { tool: "read", summary: "src/api/orders.ts", delayMs: 700 },
-                { phase: "coding", delayMs: 600 },
-                {
-                    tool: "edit",
-                    summary: "add the csv writer",
-                    delayMs: 1400,
-                    write: {
-                        "src/api/csv.ts": "import type { Order } from './orders.ts';\n\n" +
-                            "/** One row per order. A quote inside a field is doubled, per RFC 4180. */\n" +
-                            "export function toCsv(orders: Order[]): string {\n" +
-                            "  const rows = orders.map((order) => `${quote(order.id)},${order.total}`);\n" +
-                            "  return ['id,total', ...rows].join('\\n');\n}\n\n" +
-                            "function quote(value: string): string {\n" +
-                            "  return value.includes(',') || value.includes('\"')\n" +
-                            '    ? `"${value.split(\'"\').join(\'""\')}"`\n    : value;\n}\n',
-                    },
-                },
-                { phase: "testing", delayMs: 900 },
-                { tool: "shell", summary: "npm run check", delayMs: 1100 },
-                { usage: 3 },
-                { phase: "reporting", delayMs: 400 },
-            ],
-            report: "Added toCsv() with RFC 4180 quoting. Streaming is left for a follow-up.",
-            timeScale: 1,
-        },
-        dates: {
-            steps: [
-                { phase: "reading", delayMs: 800 },
-                { phase: "coding", delayMs: 900 },
-                {
-                    tool: "edit",
-                    summary: "months are zero-based",
-                    delayMs: 1200,
-                    write: {
-                        "src/api/dates.ts": "/** Formats a day. getMonth() is zero-based, which is where December went wrong. */\n" +
-                            "export function monthOf(date: Date): number {\n  return date.getMonth() + 1;\n}\n",
-                        "src/api/dates.test.ts": "import { monthOf } from './dates.ts';\n\n" +
-                            "// Fails on the old code: it returned 11 for December.\n" +
-                            "test('December is the twelfth month', () => {\n" +
-                            "  expect(monthOf(new Date('2026-12-01'))).toBe(12);\n});\n",
-                    },
-                },
-                { phase: "testing", delayMs: 1000 },
-                { tool: "shell", summary: "npm run check", delayMs: 900 },
-                { usage: 2 },
-                { phase: "reporting", delayMs: 400 },
-            ],
-            report: "monthOf() was zero-based. Fixed, with a test that fails on the old code.",
-            timeScale: 1,
-        },
-        ui: {
-            steps: [
-                { phase: "reading", delayMs: 1000 },
-                { phase: "coding", delayMs: 1500 },
-                {
-                    tool: "edit",
-                    summary: "export column and button",
-                    delayMs: 1600,
-                    write: {
-                        "src/ui/table.ts": "export const columns = ['id', 'total', 'export'];\n",
-                        "src/ui/export-button.ts": "export function exportButton(): string {\n" +
-                            "  return '<button data-href=\"/orders.csv\">Export CSV</button>';\n}\n",
-                    },
-                },
-                { usage: 4 },
-                { phase: "reporting", delayMs: 600 },
-            ],
-            report: "Added the column and the button.",
-            timeScale: 1,
-        },
-    };
-    const scenario = scenarios[line.id];
-    if (scenario === undefined)
-        throw new Error(`the demo has no script for line "${line.id}"`);
-    return scenario;
-}
-/**
- * The claim check the demo shows, written here rather than asked of anyone.
- *
- * Marked `simulated` all the way through to the screen. A real check needs a real second vendor and a
- * subscription; inventing one and presenting it as read would be faking the single thing this product claims to
- * do, which is worse than having no demo at all.
- */
-export function demoClaims() {
-    return [
-        {
-            claim: "The December fix comes with a test that fails on the old code",
-            verdict: "confirmed",
-            evidence: "dates.test.ts expects 12; the old monthOf returned 11 · src/api/dates.ts:3",
-        },
-        {
-            claim: "Nothing outside the three declared scopes was touched",
-            verdict: "confirmed",
-            evidence: "every changed path falls inside a declared write scope",
-        },
-        {
-            claim: "toCsv escapes every field that needs it",
-            verdict: "refuted",
-            evidence: "a field containing a newline is not quoted · src/api/csv.ts:10",
-        },
-    ];
-}
-//# sourceMappingURL=demo.js.map