fanout-cli 0.9.1 → 0.9.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "fanout-cli",
-  "version": "0.9.1",
+  "version": "0.9.2",
   "description": "Let Claude Code lead the other coding-agent CLIs you already pay for.",
   "license": "MIT",
   "type": "module",
@@ -14,10 +14,12 @@
   },
   "homepage": "https://github.com/elberacasa/fanout#readme",
   "bin": {
-    "fanout": "./src/cli.ts"
+    "fanout": "./dist/cli.js"
   },
   "exports": {
-    ".": "./src/main.ts"
+    ".": {
+      "default": "./dist/cli.js"
+    }
   },
   "files": [
     "dist",
@@ -25,20 +27,11 @@
     "README.md",
     "LICENSE"
   ],
-  "publishConfig": {
-    "exports": {
-      ".": {
-        "default": "./dist/cli.js"
-      }
-    },
-    "bin": {
-      "fanout": "./dist/cli.js"
-    }
-  },
   "scripts": {
     "typecheck": "tsc -p tsconfig.json",
     "build": "node ../../scripts/bundle-cli.mjs",
-    "prepack": "node ../../scripts/bundle-cli.mjs"
+    "prepack": "node ../../scripts/bundle-cli.mjs",
+    "prepublishOnly": "node ../../scripts/check-publish.mjs"
   },
   "dependencies": {
     "@modelcontextprotocol/sdk": "1.30.0",

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

@@ -1,7 +1,7 @@
 {
   "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.9.1",
+  "version": "0.9.2",
   "author": {
     "name": "elberacasa"
   },

package/plugin/commands/fanout.md

@@ -7,24 +7,30 @@ 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
+1. **Say back what you heard, before anything else.** Restate the goal in one line — `Planning: <goal>` — in the
+   words you received it in. A prompt pasted into a terminal can arrive with characters missing, silently: a real
+   paste turned "fails on the old code" into "fails on the olcode" and nothing reported it. A goal that lost a
+   word still produces a confident plan, and every step after that looks reasonable, so this line is the only
+   place the input itself is ever visible. If it reads as truncated, contradictory or half a sentence, ask
+   instead of guessing.
+2. **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:
+3. **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
+4. **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
+5. **Launch** with `launch`, then tell the user the mission id and what each line is doing.
+6. **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
+7. **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
+8. **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/src/cli.ts

@@ -1,12 +0,0 @@
-#!/usr/bin/env node
-// First, and it has to stay first: it silences a warning that fires while the imports below are evaluating.
-import "./quiet.ts";
-import { main } from "./main.ts";
-
-/* The thin edge of the CLI: everything testable lives in main.ts, which takes its output as an argument. */
-
-const code = await main(process.argv.slice(2), {
-  out: (text) => process.stdout.write(text),
-  err: (text) => process.stderr.write(text),
-});
-process.exitCode = code;