gsxdsm a74b77cec5 fix(engine): auto-recover from squash-merge orphan rebase failures
Adds a layered recovery cascade to the merger's pre-rebase stage so tasks
no longer get stuck in in-review when their declared dependency was
squash-merged to main and left orphan raw commits in the dependent's
history. Also prevents the orphan situation at the source for new tasks.

Why:
- 13 tasks were stuck in in-review for hours, all hitting the same
  pre-merge rebase abort because they shared 6 raw commits inherited
  from FN-2729's branch (declared baseBranch). FN-2729 was then
  squash-merged to main, turning those raw commits into orphans whose
  content is in main but in a different commit shape, conflicting with
  later-merged tasks. The merger's `smart-prefer-main` strategy
  correctly refused -X ours (which would silently re-introduce main's
  deletions), but the only escape hatch was a 30-min cooldown loop
  that retried the same impossible rebase forever.

Recovery cascade (merger.ts pre-rebase stage):
- Layer 1: surgical `git rebase --onto <main> <dep-tip> <branch>` when
  task.baseBranch is set. Resolves the dep tip from the live branch ref
  or recorded baseCommitSha; peels off the dep's inherited commits
  cleanly. Captures the squash-merge-of-dep case end-to-end.
- Layer 2: generic patch-id duplicate-content stripping. Walks the last
  500 main commits, computes patch-ids, then drops branch commits whose
  patch-id matches and cherry-picks the remainder onto main. Captures
  manual cherry-picks, double-merges, and any other duplicate-content
  variant Layer 1 doesn't see. Restores the branch's pre-mutation SHA
  on partial-failure so worst case leaves the worktree no worse than
  before the recovery attempt.
- Layer 3: AI arbitration fall-through. If Layers 1+2 fail, log the
  situation and proceed to the existing 3-attempt AI merge cascade
  instead of throwing. The deterministic post-merge verification
  (test + build) gates whatever the AI produces — that gate is what
  enforces prefer-main's safety contract under fall-through (no silent
  re-introduction of main's deletions).
- Critical: the unsafe `-X ours` Attempt 3 is suppressed under
  fall-through. AI Attempts 1+2 are the only paths that can complete
  the merge; if both fail and verification rejects them, the task
  bounces back to in-progress via the existing engine path rather than
  silently merging.

Prevention (executor.ts worktree creation):
- When a task declares a non-main `baseBranch`, branch the worktree
  off main (origin/<defaultBranch> when worktreeRebaseBeforeMerge is
  enabled and a remote is resolvable; otherwise local rootDir HEAD)
  and `git merge --squash` the dep's content as a single import commit.
  The dependent branch then carries main's history + 1 commit instead
  of inheriting the dep's raw commits, so a future squash-merge of the
  dep produces patch-id-matching content that rebases cleanly.
- Honors settings: respects `worktreeRebaseBeforeMerge`,
  `worktreeRebaseRemote`, and falls back to local HEAD when no remote
  is resolvable. Fully fail-soft: any squash-import error falls back to
  the legacy fork-from-dep behavior so worktree creation still works
  for setups where the squash flow can't run.

Engine-side last-retry fix (project-engine.ts):
- Changed conflict-retry condition from `currentRetries < MAX` to
  `currentRetries + 1 < MAX` so the bounce-to-in-progress code fires
  in the same engine tick as the failing attempt, rather than relying
  on a setTimeout-scheduled Nth attempt that dies on engine restart.
  Without this, a dev-time engine restart between the 3rd and 4th
  retry left the task with mergeRetries=MAX and only the 30-min
  cooldown sweep could try again.

Tests:
- New "Layer 1 recovery" test asserts the surgical --onto rebase fires
  when baseBranch is set and primary rebase aborts, and that Layer 3
  fall-through is NOT triggered when Layer 1 succeeds.
- Updated the "no silent fall-through to -X ours" test to cover the
  new fall-through path: even after Layers 1+2 fail and the merge
  cascade proceeds, -X ours must not run, and the task log must record
  both the Layer 3 fall-through entry and the Attempt 3 suppression.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 07:06:13 -07:00
2026-04-28 22:02:56 -07:00
2026-04-28 22:02:56 -07:00

Fusion

Fusion

From rough idea to production code — automatically.

Multi-node agent orchestrator — tasks, agents, missions, git, files, and worktrees, with any model, local or cloud.

runfusion.ai → · Docs · GitHub · npm · Discord

License: MIT npm Discord Status Shipping


Fusion reel: from rough idea to production code

Fusion dashboard: Planning, Todo, In Progress, In Review, Done kanban columns with active task cards

Your entire dev environment. On a single pane of glass.

Describe a task in plain language. A planning agent reads your project, understands context, and writes a full PROMPT.md plan — steps, file scope, acceptance criteria. Then Fusion plans, reviews, executes, and reviews again, in an isolated git worktree, with a human approval gate wherever you want one.

One board. Controlled from anywhere. Laptop, Mac mini, Linux server, cloud VM, phone — all connected.

Like Trello, but your tasks get specified, executed, and delivered by AI — powered by pi. Built on the great work of dustinbyrne/kb.


The flow

  ①  Describe          ②  Planning             ③  The board           ④  Isolated worktree
  ─────────────        ─────────────         ─────────────          ─────────────────────
  "Add dark mode   →   Agent writes    →   Plan → Review →    →   fusion/FN-123 branch
   toggle to           PROMPT.md           Execute → Review        concurrent, zero
   settings panel"     (steps, scope,      (per step, until        file conflicts
                       acceptance)         done)

See every step, before the merge

Fusion task detail: workflow steps visible on an in-progress task with diffs and file changes

Every task shows its plan, its reviews, its diffs, and its file changes in real time. Jump into an active task and nudge direction, tighten constraints, pause, or re-prompt.


What makes it different

🧠 AI planning Describe a task in plain language. Planning agents turn it into a PROMPT.md plan with steps, file scope, and acceptance criteria.
🔁 Workflow gates Plan → Review → Execute → Review on every step. Pre-merge gates block bad code; post-merge gates run informational checks.
🌳 Worktree isolation Each task runs in its own branch and worktree (fusion/{task-id}). Parallel tasks. Zero conflicts.
Smart merge Passing every gate? Fusion squash-merges and moves on. Opt into manual approval anywhere.
🛰️ Multi-node mesh Laptop, Mac mini, Linux server, cloud VM, phone — all synced. Desktop, mobile, web.
🧩 Any model Anthropic, OpenAI, Ollama — or anything pi-compatible. Local and cloud coexist.
🏢 Agent companies Import pre-built teams — 440+ agents across 16 companies — and run them autonomously for weeks.
📬 Inter-agent messaging Built-in mailbox between agents. Delegate, clarify, coordinate.
🗺️ Missions Hierarchical planning (Mission → Milestone → Slice → Feature → Task) with autopilot and validation contracts.
🧪 Self-improvement Agents reflect on their own output and update their prompts as they learn your codebase.
🔓 Open source. MIT. No vendor lock-in. Run it on your own hardware. Shipping weekly.

How it works

graph TD
    H((You)) -->|rough idea| T["Planning<br/><i>auto-planning</i>"]
    T --> TD["Todo<br/><i>scheduled for execution</i>"]
    TD --> IP["In Progress<br/><i>for each step:<br/>plan, review, execute, review</i>"]

    subgraph IP["In Progress"]
        direction TD
        NS([Begin step]) --> P[Plan]
        P --> R1{Review}
        R1 -->|revise| P
        R1 -->|approve| E[Execute]
        E --> R2{Review}
        R2 -->|revise| E
        R2 -->|next step| NS
        R2 -->|rethink| P
    end

    R2 -->|done| IR["In Review<br/><i>ready to merge,<br/>or auto-complete</i>"]
    IR -->|direct squash merge<br/>or merged PR| D["Done"]

    style H fill:#161b22,stroke:#8b949e,color:#e6edf3
    style T fill:#2d2006,stroke:#d29922,color:#d29922
    style TD fill:#0d2044,stroke:#58a6ff,color:#58a6ff
    style IP fill:#1a0d2e,stroke:#bc8cff,color:#bc8cff
    style P fill:#1a0d2e,stroke:#bc8cff,color:#e6edf3
    style R1 fill:#1a0d2e,stroke:#bc8cff,color:#e6edf3
    style E fill:#1a0d2e,stroke:#bc8cff,color:#e6edf3
    style R2 fill:#1a0d2e,stroke:#bc8cff,color:#e6edf3
    style NS fill:#1a0d2e,stroke:#bc8cff,color:#bc8cff
    style IR fill:#0d2d16,stroke:#3fb950,color:#3fb950
    style D fill:#1a1a1a,stroke:#8b949e,color:#8b949e

Tasks with dependencies are processed sequentially. Independent tasks run in parallel. Optionally require manual approval before tasks move from Planning to Todo (requirePlanApproval setting).


Multi-node. One board. Every platform.

Fusion mesh: laptop, Mac mini, Linux server, cloud VM, phone — all synced

macOS Windows Linux Web iOS Android

Laptop, Mac mini, Linux server, cloud VM, phone — every node is a peer. Your task state, agents, logs, and diffs stay synchronized across the mesh. The same Fusion ships as:

  • 🖥️ Desktop app — Electron for macOS (Intel + Apple Silicon), Windows 10/11, and Linux
  • 📱 Mobile app — Capacitor for iOS/iPadOS and Android (MOBILE.md)
  • 🌐 Web dashboard — any modern browser, served from the fn dashboard daemon
  • 🔌 CLIfn binary + pi extension for terminal-first workflows

Start the daemon on any node, connect your other devices, and the board follows you everywhere.


Run an agent company

Fusion agent company: import a team, run it autonomously for weeks

Import a team. Run it autonomously for weeks. 440+ agents across 16 companies, wired for missions, mailboxes, and inter-agent delegation.

npx companies.sh add paperclipai/companies/gstack

Built on Pi. Compatible with the tools you already use.

Fusion stands on open tools we love. Every Pi extension works out of the box. Hermes, Paperclip, and OpenClaw all ship as first-class plugins — route any workspace to whichever runtime fits the task. And any Paperclip agent-company imports with a single command.

Pi

Pi — the runtime

pi.dev

Fusion is built on top of Pi — the minimal, extensible coding-agent CLI. Every Pi extension works inside of Fusion. Install Fusion as a Pi extension to get native tools (fn_task_create, fn_task_list, fn_task_show, …) and a /fn command to manage Fusion from any Pi session.

pi install npm:@runfusion/fusion

This installs the Pi extension — it provides Fusion tools and /fn inside pi sessions only. To get the fn CLI in your terminal, install globally: npm install -g @runfusion/fusion.


Hermes

Hermes experimental

Nous Research

The open-source autonomous agent from Nous Research. Install the Hermes plugin and run agents through Hermes for long-running, context-growing work — route any Fusion workspace to it.

OpenClaw experimental

OpenClaw runtime support is available as an experimental plugin (fusion-plugin-openclaw-runtime) for runtime discovery/configuration parity. Configure agents with runtimeConfig.runtimeHint: "openclaw" after installing the plugin.


Paperclip

Paperclip experimental

paperclip.ing

The human control plane for AI labor. Install the Paperclip plugin to run agents through Paperclip inside Fusion.

Fusion also natively supports the companies.sh agent-company standard: import a prebuilt team — 440+ agents across 16 companies — and let them coordinate over Fusion's mailbox, missions, and workflow gates for weeks of autonomous work. Same company format, same agents, same skills as Paperclip.

npx companies.sh add paperclipai/companies/gstack

Hermes, Paperclip, and OpenClaw are experimental runtime plugins — APIs and wire formats may shift between minor releases. Pi is Fusion's stable runtime dependency.


Quick start

Zero install, straight from npm:

npx runfusion.ai

That launches the dashboard. Subcommands forward through: npx runfusion.ai task create "fix X", npx runfusion.ai --help, etc. (Or verbosely: npx @runfusion/fusion dashboard.)

One-line installer (macOS & Linux — auto-picks Homebrew, falls back to npm):

curl -fsSL https://runfusion.ai/install.sh | sh
fusion dashboard

Homebrew (macOS & Linux):

brew tap runfusion/fusion
brew install fusion
fusion dashboard            # or: fn dashboard

Or as a one-liner (auto-taps): brew install runfusion/fusion/fusion.

npm global:

npm install -g @runfusion/fusion
fn dashboard                # or: fusion dashboard

Pi extension (optional): To use Fusion tools inside Pi chat sessions, also run pi install npm:@runfusion/fusion. This adds a /fn command and Fusion tools within pi — but does not install the fn CLI globally.

From a clone (for development):

pnpm dev dashboard

Then click the Open: URL printed in the terminal. It embeds a bearer token (http://localhost:4040/?token=fn_...) that the browser captures to localStorage on first visit and reuses automatically thereafter. On the server side, Fusion now persists the dashboard/daemon token in ~/.fusion/settings.json on first authenticated run and reuses it on later starts unless you override it (--token, FUSION_DASHBOARD_TOKEN, FUSION_DAEMON_TOKEN) or disable auth with --no-auth. See CLI reference → fn dashboard → Authentication for full precedence and reset/revocation options.

First-run setup

On first launch, Fusion opens the onboarding wizard with three guided steps:

  1. AI Setup — Use a simplified quick-start provider list (recommended providers plus any already-connected providers), then expand Advanced provider settings only if you need additional providers or setup details. You only need one provider to get started.
  2. GitHub (Optional) — Connect GitHub for issue import and PR management
  3. First Task — Create your first task or import from GitHub (if no project is active, onboarding first prompts you to register/select a project directory)

The wizard is dismissible and non-blocking — click Skip for now to use the dashboard immediately. Re-trigger it later from Settings → Authentication → Reopen onboarding guide.

Mobile

For Capacitor + PWA workflow, see MOBILE.md.


Documentation

Guide What it covers
Getting Started Installation and onboarding
Dashboard Guide Board/list views, terminal, git manager
Task Management Task lifecycle and CLI commands
Settings Reference Configuration options
Architecture System internals
Agents Agent management, spawning, heartbeat
Workflow Steps Quality gates, templates, phases
Missions Mission hierarchy, planning, autopilot
Multi-Project Central registry, isolation modes
Docker Container deployment

Core features

  • AI Planning — Planning agent generates detailed PROMPT.md with steps, file scope, and acceptance criteria
  • Step-by-step Execution — Plan → Review → Execute → Review cycle for each task step
  • Git Worktree Isolation — Each task runs in its own worktree (fusion/{task-id} branch)
  • Workflow Steps — Configurable quality gates (pre-merge: blocks merge; post-merge: informational)
  • GitHub Integration — Import issues, create PRs, real-time PR/issue badges
  • Dashboard — Real-time kanban board, agent management, terminal, git manager, mission planner
  • Missions — Hierarchical planning (Mission → Milestone → Slice → Feature → Task) with autopilot, validation contracts, fix-feature retries, and blocked-handoff semantics
  • Multi-Project — Manage multiple projects from a single installation with project isolation
  • Inter-Agent Messaging — Built-in messaging for coordination between agents and users

Provider authentication

Fusion supports OAuth-based authentication for AI providers configured via Settings → Authentication. When the dashboard is accessed via a non-localhost host (remote node, LAN host/IP, or reverse proxy), provider login URLs are automatically rewritten to route OAuth callbacks through a bridge endpoint (/api/auth/openai-codex/callback), ensuring the redirect reaches the active browser session.

  • OpenAI Codex — Authenticates via Settings OAuth flow with secure state validation
  • Other providers — Authenticate via API key entry in Settings
  • pi authentication — Handled separately via the pi CLI (/login) or ANTHROPIC_API_KEY environment variable

Model system

Fusion uses a dual-scope model hierarchy with five independent lanes. Global settings define baseline defaults; project settings provide per-project overrides.

Lane Purpose Global Baseline Keys Project Override Keys
Executor Task execution agent executionGlobalProvider + executionGlobalModelId executionProvider + executionModelId
Planning Task planning agent planningGlobalProvider + planningGlobalModelId planningProvider + planningModelId
Validator Plan/code reviewer validatorGlobalProvider + validatorGlobalModelId validatorProvider + validatorModelId
Title Summarization Auto-title generation titleSummarizerGlobalProvider + titleSummarizerGlobalModelId titleSummarizerProvider + titleSummarizerModelId
Workflow Step Refinement AI prompt refinement (uses defaultProvider/defaultModelId) (uses modelProvider/modelId on WorkflowStep)

Per-Task Overrides: Tasks can override the executor, validator, and planning lanes with per-task model fields (modelProvider/modelId, validatorModelProvider/validatorModelId, planningModelProvider/planningModelId).

Precedence: Per-task → Project override → Global lane → defaultProvider/defaultModelId → Automatic resolution.

For full settings documentation, see Settings Reference.

Scheduled tasks / automations

Fusion supports scheduled task automation via the /api/automations endpoints. Automations can run shell commands or multi-step workflows on a configurable schedule.

Scheduling scope

Automations and routines can run in two scopes:

  • Global — Runs across all projects. Use this for cross-project maintenance, backups, or unified reporting.
  • Project — Runs only within a specific project. Use this for project-specific CI, testing, or deployment tasks.

When you create a schedule without choosing a scope, Fusion defaults to project scope with the default project ID for backward compatibility.

To explicitly target a scope:

  • In the dashboard Scheduled Tasks modal, use the Global / Project toggle.
  • Via the API, pass ?scope=global or ?scope=project&projectId=<id> on automation/routine endpoints.

Scope resolution rules:

  • scope=global always resolves to the global automation/routine lane, independent of the active project.
  • scope=project requires a projectId. If omitted, it falls back to "default".
  • CRUD, run, toggle, and webhook operations are strictly scope-isolated: a global schedule cannot be mutated from a project-scoped request, and vice versa.

Operational guidance for multi-project setups:

  • Prefer global schedules for shared infrastructure (e.g., nightly backups, memory insight extraction).
  • Prefer project schedules for per-repository automation (e.g., per-project test runners, deployment hooks).
  • Global and project lanes are polled independently by the engine, so due runs in one lane do not block the other.

Automations

Endpoint Method Description
/api/automations GET List all automations (filtered by scope if specified)
/api/automations POST Create automation (scope defaults to project)
/api/automations/:id GET Get automation by ID
/api/automations/:id PATCH Update automation
/api/automations/:id DELETE Delete automation
/api/automations/:id/run POST Trigger manual run
/api/automations/:id/toggle POST Toggle enabled/disabled
/api/automations/:id/steps/reorder POST Reorder automation steps

Routines

Routines are AI agent tasks triggered by cron schedules, webhooks, or manual execution. Routines share the same global/project scope model as automations.

Endpoint Method Description
/api/routines GET List all routines (filtered by scope if specified)
/api/routines POST Create routine (scope defaults to project)
/api/routines/:id GET Get routine by ID
/api/routines/:id PATCH Update routine
/api/routines/:id DELETE Delete routine
/api/routines/:id/run POST Manual trigger
/api/routines/:id/trigger POST Canonical manual trigger
/api/routines/:id/runs GET Get execution history
/api/routines/:id/webhook POST Webhook trigger (signature verification supported)

CLI quick examples

fn task create "Fix the login bug"                    # Quick entry → planning
fn task plan "Build auth system"                      # AI-guided planning
fn task import owner/repo --labels bug                # Import GitHub issues
fn task show FN-001                                   # View task details
fn task logs FN-001 --follow                          # Stream execution logs
fn task steer FN-001 "Use TypeScript"                 # Guide the agent mid-execution

fn project add my-app /path/to/app                    # Register a project
fn project list                                       # List all projects

fn settings set maxConcurrent 4                       # Configure settings
fn settings export                                    # Export configuration

fn mission create "Auth System" "Build auth"          # Create mission
fn mission activate-slice <slice-id>                  # Activate a slice

fn skills search react                                # Search skills.sh
fn skills install firebase/agent-skills               # Install agent skills

Packages

Package Description
@fusion/core Domain model — tasks, board columns, SQLite store
@fusion/dashboard Web UI — Express server + kanban board with SSE
@fusion/engine AI engine — planning, execution, scheduling, workflow steps
@runfusion/fusion CLI + pi extension — published to npm

Development

pnpm install                  # Install dependencies
pnpm build                    # Build all packages
pnpm dev dashboard            # Run dashboard + AI engine
pnpm dev:ui                   # Dashboard only (no AI engine)
pnpm lint                     # Lint all packages
pnpm typecheck                # Type-check all packages
pnpm test                     # Run all tests

Build a standalone executable

Build a single self-contained fn binary using Bun:

pnpm build:exe                # Build for current platform
pnpm build:exe:all            # Cross-compile for all platforms

License

MIT — open source, no vendor lock-in. See LICENSE.

Description
Fork of github.com/Runfusion/Fusion with Coolify-friendly Dockerfile
Readme MIT 124 MiB
Languages
TypeScript 95.4%
CSS 3.3%
JavaScript 1.2%