ftown-bridge 0.19.39 → 0.19.40

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ftown-bridge",
-  "version": "0.19.39",
+  "version": "0.19.40",
   "description": "CLI bridge for ftown — generic PTY-over-Centrifugo relay",
   "type": "module",
   "main": "dist/index.js",
@@ -10,7 +10,6 @@
     "ftown-harness": "dist/harness-cli.js",
     "ftown-env": "dist/ftown-env-cli.js",
     "ftown-sessions": "bin/ftown-sessions",
-    "ftown-workflows": "dist/workflow-runner-cli.js",
     "ftown-mcp": "dist/mcp-cli.js"
   },
   "files": [
@@ -23,7 +22,7 @@
     "skills"
   ],
   "scripts": {
-    "build": "tsc",
+    "build": "node -e \"require('node:fs').rmSync('dist', { recursive: true, force: true })\" && tsc",
     "test": "node --import tsx --test \"src/**/*.test.ts\"",
     "prepublishOnly": "npm run build",
     "start": "tsx src/index.ts",

package/skills/ftown/SKILL.md

@@ -1,33 +1,68 @@
 ---
 name: ftown
 description: >-
-  Control ftown from inside agent sessions: create/list/read/drive sibling
-  sessions, send ftown mail, and coordinate worker agent sessions. Use when a task
-  mentions ftown, ftown sessions, bridge sessions, child/sibling agents, mail/inbox,
-  orchestration, or fan-out.
+  Control ftown sessions: create/list/read/drive sibling sessions, send ftown
+  mail, and coordinate worker agents. Use for ftown sessions, child/sibling
+  agents, bridge mail/inbox, or explicitly requested orchestration.
 ---
 
 # ftown
 
-Use the local bridge CLIs installed under `~/.ftown`. They read
-`~/.ftown/bridge.json`; anyone who can read that file can control the bridge's
-sessions.
+Use `ftown sessions`, `ftown harness`, and `ftown env`. Run `ftown --help`
+for command discovery; if it is missing from PATH, use `~/.ftown/ftown`.
+The bridge installs this skill at `~/.ftown/skills/ftown`, linked from the agent
+skill directories. Start or restart ftown-bridge to update it and the CLIs.
 
-## Pick The Reference
+## Commands and references
 
-- Session control, mail, terminal output, archive/revive, or local API:
-  read `references/sessions.md`.
-- Ad-hoc multi-agent coordination from an orchestrator session:
-  read `references/orchestrator.md`.
+```bash
+ftown sessions list
+ftown sessions create --prompt "Review the auth module" --workdir "$PWD" --parent
+ftown sessions screen <session-id> --limit 200
+ftown harness mail send <session-id> --type task "review the API client"
+ftown harness mail read
+ftown env --help
+```
+
+Read `references/sessions.md` for the session, mail and terminal command
+reference. Read `references/orchestrator.md` for practical worker coordination
+examples. Each command group also has `--help`.
+
+## Identity and reporting
+
+Your id is `$FTOWN_SESSION_ID`; children also receive `$FTOWN_PARENT_SESSION_ID`.
+A child's initial briefing identifies it and its parent and explains reporting:
+
+```bash
+ftown harness mail send --parent --type result "Done; checks passed"
+ftown harness mail send --parent --type escalation "Blocked: need the API contract"
+```
+
+Mail arrives as `[ftown mail]` context through harness hooks/extensions where
+available. Cursor and shell sessions receive an idle nudge to read their inbox.
+Prefer mail for agent communication; use terminal key injection only when the
+task needs it. Inspect peers with `ftown sessions list` and
+`ftown sessions screen <id> --limit 100`.
 
-## Quick Commands
+## Cleanup
+
+Session cleanup is an explicit user or orchestrator action. Reporting a result
+does not remove a child automatically. Keep sessions available for follow-up
+until cleanup is requested or the coordinating task calls for it.
 
 ```bash
-# Sessions
-~/.ftown/ftown-sessions list
-~/.ftown/ftown-sessions create --prompt "Run tests" --workdir "$PWD" --parent
-~/.ftown/ftown-sessions screen <session-id> --limit 200
-~/.ftown/ftown-sessions tell <session-id> --type task "continue with the API client"
+ftown sessions remove <finished-session-id>
+ftown sessions archive
+ftown sessions revive <archived-session-id>
 ```
 
-Use orchestrator guidance for ad-hoc multi-agent coordination.
+Removal archives the session; revival creates a new session id and resumes its
+agent conversation when supported. Preserve useful results before cleanup.
+
+## Connection and compatibility
+
+The commands read `~/.ftown/bridge.json`. Anyone who can read that file can
+control the bridge's sessions. Existing `ftown-sessions`, `ftown-harness`, and
+`ftown-env` launchers remain compatible; use the grouped commands above in new
+instructions. ftown does not install a ticket system or provide a workflow
+runner. Independently installed coordination tools remain yours to manage.

package/skills/ftown/references/orchestrator.md

@@ -1,106 +1,29 @@
-# ftown orchestrator playbook
+# Worker coordination examples
 
-You are running inside an ftown session (your id is in `$FTOWN_SESSION_ID`) and
-can coordinate worker agent sessions on this machine using the
-`~/.ftown/ftown-sessions` CLI.
+Read `../SKILL.md` for identity, reporting and cleanup behavior, and
+`sessions.md` for the command reference. These examples add only coordination
+steps.
 
-See `references/sessions.md` for the full session CLI reference.
-
-## Spawning workers
-
-Omit `--shell` to inherit the orchestrator's current harness. Use `--shell` only
-when the user or task explicitly requests a different harness (`claude`, `cursor`,
-`codex`, `grok`, `muse`, `pi`, `kimi-code`, `shell`, `opencode`, or a Claude Code provider
-flavor such as `zai`, `kimi`, `deepseek`, `fireworks`). `--parent` sets the worker's
-parent to `$FTOWN_SESSION_ID`.
-
-```bash
-~/.ftown/ftown-sessions create \
-  --parent \
-  --workdir /path/to/repo \
-  --name review-auth \
-  --prompt "Review the auth module and summarize findings"
-```
-
-Returns JSON containing `session.id` — save it to inspect the worker later.
-Workers spawned with `--parent` are auto-briefed about reporting results and
-escalations through mail, then removing themselves when finished.
-Provider-flavored workers require a bridge-host token configured with
-`ftown env set <flavor> <token>`; the bridge supplies their endpoint/model
-environment when it spawns them.
-
-## Monitoring workers
+List existing sessions before creating another worker. Give each worker a
+bounded task, clear writable files and acceptance checks; save the returned
+`session.id` for follow-up. Omit `--shell` to inherit your current harness, or
+set it when the task calls for a different harness. Provider flavors require a
+bridge-host token configured with `ftown env set <flavor>`.
 
 ```bash
-# See what's on screen right now
-~/.ftown/ftown-sessions screen <session-id> --limit 100
-
-# Search for errors / completion markers
-~/.ftown/ftown-sessions grep <session-id> --pattern 'FAIL|done|error'
-
-# Check if the process is still alive
-~/.ftown/ftown-sessions running <session-id>
+ftown sessions list
+ftown sessions create --parent --workdir /path/to/repo --name review-auth \
+  --prompt "Review auth; read-only. Report concrete findings and validation."
+ftown sessions screen <worker-id> --limit 100
+ftown sessions running <worker-id>
+ftown harness mail send <worker-id> --type task "Check the expired-token case too"
+ftown sessions tell --children "Pause and report status"
 ```
 
-Use `screen` / `grep` to investigate a worker that has gone quiet. When waiting for
-results, end your turn and let mail wake you instead of running a polling loop.
-
-## Messaging (mail)
-
-Each session has an inbox. Claude and codex receive mail automatically at turn
-boundaries via hooks. Pi's bundled extension maintains a long-poll and wakes idle
-Pi sessions with a native follow-up turn. Muse's installed `ftown` plugin
-reports the native session id on SessionStart and pumps pending mail as
-context on Stop. None of these paths inject terminal
-keystrokes. Cursor and shell sessions have no hooks: when idle they get a one-line
-nudge telling them to run `ftown-harness mail read`, so expect slightly slower
-pickup there.
-
-```bash
-# Send work / instructions to a child
-ftown-harness mail send <child> --type task "implement the API client"
-
-# Reply in a thread, or escalate
-ftown-harness mail send <child> --thread <id> "use the v2 endpoint"
-
-# Read your own inbox on demand (you also get mail automatically)
-ftown-harness mail read
-```
-
-Children report back with `mail send --parent --type result` (or
-`--type escalation` when blocked). Fan-out works via
-`~/.ftown/ftown-sessions tell --children "pause and report status"` (now mail
-under the hood; one of `--parent | --children | --siblings`).
-
-If a worker is idle and must be woken right now, terminal keystroke injection
-(`ftown-harness send <id> "..." -s` or `tell --keys`) is the **last resort** —
-prefer mail, which arrives at the next turn boundary.
-
-## Cleanup
-
-```bash
-# Archive a finished worker (kept as a tombstone)
-~/.ftown/ftown-sessions remove <session-id>
-
-# Bring it back — resumes the agent conversation if its agent session id was
-# recorded before removal; otherwise restarts fresh with a new id
-~/.ftown/ftown-sessions revive <session-id>
-```
-
-Child briefings normally make workers report first and then remove themselves. Explicitly
-ask a worker to stay open when you need follow-up interaction; otherwise, clean up any
-worker that exits without honoring the self-removal instruction.
-
-## Practical guidance
-
-- **Parallelize** independent tasks: spawn multiple workers before waiting for any.
-- **Follow worker results**: read incoming mail and use `screen` / `grep` for diagnosis.
-- **Name workers clearly**: `--name` shows in `list` output and as the sender
-  name on incoming mail.
-- **Check `list` first**: see what's already running before spawning duplicates.
-
-## If the CLI is missing
+Use terminal output to investigate a quiet worker. Mail handles results and
+escalations; read them with `ftown harness mail read`. When waiting, let incoming
+mail resume the conversation rather than repeatedly polling. Parallel tasks need
+disjoint write ownership and serialized shared resources.
 
-Start or restart **ftown-bridge** on this machine. It installs
-`~/.ftown/ftown-sessions` and updates the unified skill under
-`~/.ftown/skills/ftown/` (linked into ~/.agents/skills and ~/.claude/skills).
+After accepting a worker's result, request any concrete follow-up before
+explicit cleanup with `ftown sessions remove <worker-id>`.

package/skills/ftown/references/sessions.md

@@ -1,9 +1,9 @@
 # ftown cross-session CLI
 
-**Prefer the CLI** — installed to `~/.ftown/ftown-sessions` whenever `ftown-bridge` is running. It reads `~/.ftown/bridge.json` automatically.
+Use `ftown sessions`, installed whenever `ftown-bridge` is running. It reads `~/.ftown/bridge.json` automatically.
 
 ```bash
-~/.ftown/ftown-sessions --help
+ftown sessions --help
 ```
 
 Unified skill wrapper: `scripts/ftown` in this skill directory delegates to the
@@ -15,40 +15,40 @@ top-level `~/.ftown/ftown` dispatcher.
 
 ```bash
 # List sessions (JSON)
-~/.ftown/ftown-sessions list
+ftown sessions list
 
 # Spawn a child agent (uses FTOWN_SESSION_ID for --parent)
-~/.ftown/ftown-sessions create \
+ftown sessions create \
   --prompt "Review the auth module and summarize" \
   --workdir /path/to/repo \
   --name auth-review \
   --parent
 
 # Metadata
-~/.ftown/ftown-sessions get <session-id>
+ftown sessions get <session-id>
 
 # Terminal output (JSON by default; add --plain for raw lines)
-~/.ftown/ftown-sessions screen <session-id> --limit 200
+ftown sessions screen <session-id> --limit 200
 
 # Search output (--offset/--limit paginate screen and grep)
-~/.ftown/ftown-sessions grep <session-id> --pattern 'error|failed' --offset 0 --limit 100
+ftown sessions grep <session-id> --pattern 'error|failed' --offset 0 --limit 100
 
 # Type into another running session
-~/.ftown/ftown-sessions keys <session-id> 'y'
+ftown sessions keys <session-id> 'y'
 
 # Liveness
-~/.ftown/ftown-sessions running <session-id>
+ftown sessions running <session-id>
 
 # Stop and remove a session (kept as a tombstone in the archive)
-~/.ftown/ftown-sessions remove <session-id>
+ftown sessions remove <session-id>
 
 # List archived (removed) sessions: id, name, removedAt, shellType
-~/.ftown/ftown-sessions archive
+ftown sessions archive
 
 # Recreate a removed session from its tombstone (resumes the agent
 # conversation when a claude/cursor/codex/Pi session id was recorded; Kimi Code
 # continues by working directory; the revived session gets a NEW id)
-~/.ftown/ftown-sessions revive <session-id>
+ftown sessions revive <session-id>
 ```
 
 ## Messaging (mail)
@@ -61,27 +61,27 @@ follow-up turn when mail arrives, including while Pi is idle. opencode's
 installed plugin delivers pending mail as a new prompt when a turn goes idle.
 Muse's installed `ftown` plugin reports the native session id on SessionStart
 and pumps pending mail as context on Stop.
-Cursor and shell sessions rely on an idle one-line nudge to run `ftown-harness
+Cursor and shell sessions rely on an idle one-line nudge to run `ftown harness
 mail read` instead.
 
 ```bash
 # Tell a specific session
-~/.ftown/ftown-sessions tell <session-id> "tests are green, ship it"
+ftown sessions tell <session-id> "tests are green, ship it"
 
 # Mail type / threading
-~/.ftown/ftown-sessions tell <session-id> --type task "implement the API client"
-~/.ftown/ftown-sessions tell <session-id> --type result --thread <id> "done, 0 failures"
+ftown sessions tell <session-id> --type task "implement the API client"
+ftown sessions tell <session-id> --type result --thread <id> "done, 0 failures"
 
 # Tell my parent / children / siblings (resolved via FTOWN_SESSION_ID)
-~/.ftown/ftown-sessions tell --parent "child finished phase 1"
-~/.ftown/ftown-sessions tell --children "pause and report status"
-~/.ftown/ftown-sessions tell --siblings "I grabbed the lock, stand by"
+ftown sessions tell --parent "child finished phase 1"
+ftown sessions tell --children "pause and report status"
+ftown sessions tell --siblings "I grabbed the lock, stand by"
 
 # Last resort: inject as terminal keystrokes instead of mail
-~/.ftown/ftown-sessions tell <session-id> --keys "wake up"
+ftown sessions tell <session-id> --keys "wake up"
 
 # Read my own inbox (requires FTOWN_SESSION_ID; alias: mail)
-~/.ftown/ftown-sessions inbox            # --peek / --limit N / --all / --json
+ftown sessions inbox            # --peek / --limit N / --all / --json
 ```
 
 Sender is resolved from `FTOWN_SESSION_ID` (omitted when unset).
@@ -110,14 +110,12 @@ Returns JSON with the new `session.id` — use that id for `screen` / `grep` / `
 ## Typical workflow
 
 ```bash
-CLI=~/.ftown/ftown-sessions
-
-$CLI list
-$CLI create --prompt "Run tests and report" --workdir "$PWD" --parent
+ftown sessions list
+ftown sessions create --prompt "Run tests and report" --workdir "$PWD" --parent
 # -> note session.id from JSON
 
-$CLI screen <child-id> --limit 100
-$CLI grep <child-id> --pattern 'FAIL|Error'
+ftown sessions screen <child-id> --limit 100
+ftown sessions grep <child-id> --pattern 'FAIL|Error'
 ```
 
 ## Environment
@@ -132,15 +130,14 @@ Spawned ftown sessions receive:
 Agent children (any `--shell` except `shell`) spawned with a parent also get an
 automatic one-paragraph briefing prepended to their first input: it states their
 name/id and parent name/id. It explains how to report via
-`ftown-harness mail send --parent --type result` (or `--type escalation` when blocked).
-After reporting the outcome, the child is instructed to remove itself as
-its final command unless the user explicitly asked it to stay open. The creator's
-`--prompt` follows after a `Task:` line.
+`ftown harness mail send --parent --type result` (or `--type escalation` when blocked).
+The creator's `--prompt` follows after a `Task:` line. Session cleanup is an
+explicit user or orchestrator action; see the ftown skill.
 
 An agent session created with `--orchestrator` additionally gets `FTOWN_ORCHESTRATOR=1`
 in its environment and a compact pointer briefing directing it to the unified
-**ftown** skill, whose `references/orchestrator.md` contains the full
-orchestrator playbook for spawning workers, monitoring them, and cleaning up.
+**ftown** skill, whose `references/orchestrator.md` adds practical
+coordination examples for spawning workers, monitoring them, and cleaning up.
 When both apply, the child paragraph comes first, then the orchestrator pointer,
 separated by a blank line.
 
@@ -175,7 +172,7 @@ back to the bridge root. Parent and child must belong to the same bridge.
 
 ## If the CLI is missing
 
-Start or restart **ftown-bridge** on this machine. It installs
-`~/.ftown/ftown-sessions`, `~/.ftown/notify.sh`, and updates the unified skill
+Start or restart **ftown-bridge** on this machine. It installs the `ftown` command, compatible launchers, `~/.ftown/notify.sh`,
+and updates the unified skill
 under `~/.ftown/skills/ftown/` (linked into ~/.agents/skills and
 ~/.claude/skills).

package/dist/claude-trust.d.ts

@@ -1,11 +0,0 @@
-/**
- * Pre-trust `dir` for Claude Code so a spawned worker does not block on the
- * interactive "Do you trust this folder?" dialog — which `--dangerously-skip-permissions`
- * does NOT dismiss. Sets `projects[dir].hasTrustDialogAccepted = true` in `~/.claude.json`,
- * preserving every other field, via an atomic temp+rename. Best-effort: never throws.
- *
- * Scoped to ftown-workflows workers (non-interactive automation). The claude config keys
- * projects by REAL path (e.g. `/private/tmp`, not `/tmp`), so we trust the realpath.
- * Mirrors the bridge's `ensureCodexWorkdirTrust`.
- */
-export declare function ensureClaudeWorkdirTrust(dir: string): void;

package/dist/claude-trust.js

@@ -1,47 +0,0 @@
-import { readFileSync, realpathSync, renameSync, writeFileSync } from 'node:fs';
-import { homedir } from 'node:os';
-import { join } from 'node:path';
-/**
- * Pre-trust `dir` for Claude Code so a spawned worker does not block on the
- * interactive "Do you trust this folder?" dialog — which `--dangerously-skip-permissions`
- * does NOT dismiss. Sets `projects[dir].hasTrustDialogAccepted = true` in `~/.claude.json`,
- * preserving every other field, via an atomic temp+rename. Best-effort: never throws.
- *
- * Scoped to ftown-workflows workers (non-interactive automation). The claude config keys
- * projects by REAL path (e.g. `/private/tmp`, not `/tmp`), so we trust the realpath.
- * Mirrors the bridge's `ensureCodexWorkdirTrust`.
- */
-export function ensureClaudeWorkdirTrust(dir) {
-    let real = dir;
-    try {
-        real = realpathSync(dir);
-    }
-    catch {
-        // Path may not exist yet; fall back to the input verbatim.
-    }
-    const configPath = join(homedir(), '.claude.json');
-    let cfg = {};
-    try {
-        cfg = JSON.parse(readFileSync(configPath, 'utf8'));
-    }
-    catch {
-        // Missing or unreadable — start fresh; claude fills in the rest on launch.
-        cfg = {};
-    }
-    if (!cfg.projects || typeof cfg.projects !== 'object')
-        cfg.projects = {};
-    const existing = cfg.projects[real];
-    if (existing && existing.hasTrustDialogAccepted === true)
-        return; // already trusted
-    cfg.projects[real] = { ...(existing ?? {}), hasTrustDialogAccepted: true };
-    const tmpPath = `${configPath}.ftw-tmp`;
-    try {
-        writeFileSync(tmpPath, JSON.stringify(cfg, null, 2));
-        renameSync(tmpPath, configPath);
-    }
-    catch {
-        // Best-effort: if we cannot persist trust the worker may hit the dialog, but the
-        // workflow run must not crash.
-    }
-}
-//# sourceMappingURL=claude-trust.js.map

package/dist/claude-trust.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"claude-trust.js","sourceRoot":"","sources":["../src/claude-trust.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,YAAY,EAAE,UAAU,EAAE,aAAa,EAAE,MAAM,SAAS,CAAC;AAChF,OAAO,EAAE,OAAO,EAAE,MAAM,SAAS,CAAC;AAClC,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAOjC;;;;;;;;;GASG;AACH,MAAM,UAAU,wBAAwB,CAAC,GAAW;IAClD,IAAI,IAAI,GAAG,GAAG,CAAC;IACf,IAAI,CAAC;QACH,IAAI,GAAG,YAAY,CAAC,GAAG,CAAC,CAAC;IAC3B,CAAC;IAAC,MAAM,CAAC;QACP,2DAA2D;IAC7D,CAAC;IAED,MAAM,UAAU,GAAG,IAAI,CAAC,OAAO,EAAE,EAAE,cAAc,CAAC,CAAC;IAEnD,IAAI,GAAG,GAAiB,EAAE,CAAC;IAC3B,IAAI,CAAC;QACH,GAAG,GAAG,IAAI,CAAC,KAAK,CAAC,YAAY,CAAC,UAAU,EAAE,MAAM,CAAC,CAAiB,CAAC;IACrE,CAAC;IAAC,MAAM,CAAC;QACP,2EAA2E;QAC3E,GAAG,GAAG,EAAE,CAAC;IACX,CAAC;IACD,IAAI,CAAC,GAAG,CAAC,QAAQ,IAAI,OAAO,GAAG,CAAC,QAAQ,KAAK,QAAQ;QAAE,GAAG,CAAC,QAAQ,GAAG,EAAE,CAAC;IAEzE,MAAM,QAAQ,GAAG,GAAG,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;IACpC,IAAI,QAAQ,IAAI,QAAQ,CAAC,sBAAsB,KAAK,IAAI;QAAE,OAAO,CAAC,kBAAkB;IAEpF,GAAG,CAAC,QAAQ,CAAC,IAAI,CAAC,GAAG,EAAE,GAAG,CAAC,QAAQ,IAAI,EAAE,CAAC,EAAE,sBAAsB,EAAE,IAAI,EAAE,CAAC;IAE3E,MAAM,OAAO,GAAG,GAAG,UAAU,UAAU,CAAC;IACxC,IAAI,CAAC;QACH,aAAa,CAAC,OAAO,EAAE,IAAI,CAAC,SAAS,CAAC,GAAG,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAC;QACrD,UAAU,CAAC,OAAO,EAAE,UAAU,CAAC,CAAC;IAClC,CAAC;IAAC,MAAM,CAAC;QACP,iFAAiF;QACjF,+BAA+B;IACjC,CAAC;AACH,CAAC"}

package/dist/install-ftown-workflows-cli.d.ts

@@ -1,3 +0,0 @@
-export declare const CANONICAL_WORKFLOWS_CLI_PATH: string;
-/** Copy CLI bundle and install ~/.ftown/ftown-workflows launcher. */
-export declare function installFtownWorkflowsCli(compiledCliPath: string): string;

package/dist/install-ftown-workflows-cli.js

@@ -1,33 +0,0 @@
-import { chmodSync, copyFileSync, mkdirSync, writeFileSync } from 'node:fs';
-import { homedir } from 'node:os';
-import { dirname, join } from 'node:path';
-export const CANONICAL_WORKFLOWS_CLI_PATH = join(homedir(), '.ftown', 'ftown-workflows');
-/** Copy CLI bundle and install ~/.ftown/ftown-workflows launcher. */
-export function installFtownWorkflowsCli(compiledCliPath) {
-    const ftownDir = join(homedir(), '.ftown');
-    const cliJsPath = join(ftownDir, 'ftown-workflows-cli.js');
-    // Resolve the launcher path from ftownDir (not the module-level constant) so the
-    // whole install is consistent with homedir() at call time and HOME-override-safe.
-    const launcherPath = join(ftownDir, 'ftown-workflows');
-    mkdirSync(ftownDir, { recursive: true, mode: 0o700 });
-    writeFileSync(join(ftownDir, 'package.json'), '{"type":"module"}\n', { mode: 0o644 });
-    copyFileSync(compiledCliPath, cliJsPath);
-    chmodSync(cliJsPath, 0o644);
-    // The compiled CLI imports sibling modules at runtime, so each local dependency
-    // must sit alongside it in ~/.ftown.
-    const engineSrc = join(dirname(compiledCliPath), 'workflow-runner.js');
-    const engineDest = join(ftownDir, 'workflow-runner.js');
-    copyFileSync(engineSrc, engineDest);
-    chmodSync(engineDest, 0o644);
-    const claudeTrustSrc = join(dirname(compiledCliPath), 'claude-trust.js');
-    const claudeTrustDest = join(ftownDir, 'claude-trust.js');
-    copyFileSync(claudeTrustSrc, claudeTrustDest);
-    chmodSync(claudeTrustDest, 0o644);
-    const launcher = `#!/usr/bin/env bash
-set -euo pipefail
-exec node "${cliJsPath}" "$@"
-`;
-    writeFileSync(launcherPath, launcher, { mode: 0o755 });
-    return launcherPath;
-}
-//# sourceMappingURL=install-ftown-workflows-cli.js.map

package/dist/install-ftown-workflows-cli.js.map

@@ -1 +0,0 @@
-{"version":3,"file":"install-ftown-workflows-cli.js","sourceRoot":"","sources":["../src/install-ftown-workflows-cli.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,SAAS,EAAE,YAAY,EAAE,SAAS,EAAE,aAAa,EAAE,MAAM,SAAS,CAAC;AAC5E,OAAO,EAAE,OAAO,EAAE,MAAM,SAAS,CAAC;AAClC,OAAO,EAAE,OAAO,EAAE,IAAI,EAAE,MAAM,WAAW,CAAC;AAE1C,MAAM,CAAC,MAAM,4BAA4B,GAAG,IAAI,CAAC,OAAO,EAAE,EAAE,QAAQ,EAAE,iBAAiB,CAAC,CAAC;AAEzF,qEAAqE;AACrE,MAAM,UAAU,wBAAwB,CAAC,eAAuB;IAC9D,MAAM,QAAQ,GAAG,IAAI,CAAC,OAAO,EAAE,EAAE,QAAQ,CAAC,CAAC;IAC3C,MAAM,SAAS,GAAG,IAAI,CAAC,QAAQ,EAAE,wBAAwB,CAAC,CAAC;IAC3D,iFAAiF;IACjF,kFAAkF;IAClF,MAAM,YAAY,GAAG,IAAI,CAAC,QAAQ,EAAE,iBAAiB,CAAC,CAAC;IAEvD,SAAS,CAAC,QAAQ,EAAE,EAAE,SAAS,EAAE,IAAI,EAAE,IAAI,EAAE,KAAK,EAAE,CAAC,CAAC;IACtD,aAAa,CAAC,IAAI,CAAC,QAAQ,EAAE,cAAc,CAAC,EAAE,qBAAqB,EAAE,EAAE,IAAI,EAAE,KAAK,EAAE,CAAC,CAAC;IACtF,YAAY,CAAC,eAAe,EAAE,SAAS,CAAC,CAAC;IACzC,SAAS,CAAC,SAAS,EAAE,KAAK,CAAC,CAAC;IAE5B,gFAAgF;IAChF,qCAAqC;IACrC,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,eAAe,CAAC,EAAE,oBAAoB,CAAC,CAAC;IACvE,MAAM,UAAU,GAAG,IAAI,CAAC,QAAQ,EAAE,oBAAoB,CAAC,CAAC;IACxD,YAAY,CAAC,SAAS,EAAE,UAAU,CAAC,CAAC;IACpC,SAAS,CAAC,UAAU,EAAE,KAAK,CAAC,CAAC;IAE7B,MAAM,cAAc,GAAG,IAAI,CAAC,OAAO,CAAC,eAAe,CAAC,EAAE,iBAAiB,CAAC,CAAC;IACzE,MAAM,eAAe,GAAG,IAAI,CAAC,QAAQ,EAAE,iBAAiB,CAAC,CAAC;IAC1D,YAAY,CAAC,cAAc,EAAE,eAAe,CAAC,CAAC;IAC9C,SAAS,CAAC,eAAe,EAAE,KAAK,CAAC,CAAC;IAElC,MAAM,QAAQ,GAAG;;aAEN,SAAS;CACrB,CAAC;IACA,aAAa,CAAC,YAAY,EAAE,QAAQ,EAAE,EAAE,IAAI,EAAE,KAAK,EAAE,CAAC,CAAC;IAEvD,OAAO,YAAY,CAAC;AACtB,CAAC"}

package/dist/workflow-runner-cli.d.ts

@@ -1,2 +0,0 @@
-#!/usr/bin/env node
-export {};