Files

Victor Canô 9cafa045df fix(pr-merge): resolve repo from the project checkout, not process.cwd(), in PR-mode auto-merge (#2281 )

## Summary

In a centrally-installed, multi-project Fusion server (one process
serving several repos, `process.cwd()` = the install dir, not any repo),
every task under `mergeStrategy: "pull-request"` fails at the auto-merge
stage with:

```
Could not determine repository. Specify owner/repo in params or run from a git repository with a GitHub remote.
```

PR creation from the dashboard and status polling work; only the
engine's automatic PR path fails. This is the **non-workspace sibling of
#1924** (FN-7610 routed workspace-mode tasks to direct merge but does
not cover regular multi-project tasks) and the completion of
#1797/FN-7133 (which fixed only the `getPrMergeStatus` arguments).

## Root cause

`GitHubClient.resolveRepo()` (`packages/dashboard/src/github.ts`) falls
back to a cwd-less `getCurrentRepo()` — i.e. `git remote get-url origin`
in `process.cwd()` — whenever a PR method is called without explicit
`owner`/`repo`. The engine merge path already resolves the correct repo
from the per-project cwd (`prRepo = getCurrentRepo(cwd)`, FN-7133) but
only threaded it into `getPrMergeStatus`. Every other GitHub call
omitted it:

- `processPullRequestMergeTask`: `findPrForBranch` / `createPr` /
`mergePr` on both the per-task and shared-branch-group paths
- `createGroupPrCallback` (group-PR promotion): `findPrForBranch` /
`createPr`
- `createPrNodeGithubOps` (`pr-create`/`pr-merge` workflow nodes):
cwd-less `getCurrentRepo()` persisted `entity.repo` as `""` (poisoning
the downstream `splitRepoSlug` consumers), and the git
push/`createPr`/`mergePr` ran against `process.cwd()`
- the engine's review-response run (`buildRespondCallback`):
`respondOps.getCwd` collapses to `process.cwd()` because no CLI
composition site wires `getTaskWorktree`, so its git ops and response
agent ran outside the project repo

In a central install the fallback throws; worse, if `process.cwd()`
happens to be inside some *other* git repo, it silently targets the
**wrong repository**.

## What changed

- `fix(pr-merge): thread repo identity into PR auto-merge GitHub calls`
— widens the CLI-local `GitHubOperations` interface (optional
`owner`/`repo`, already accepted by `GitHubClient`'s
`FindPrParams`/`CreatePrParams`/`MergePrParams`) and passes `prRepo` at
all six call sites in `processPullRequestMergeTask`.
- `fix(pr-merge): resolve group-PR repo from project cwd in
createGroupPrCallback` — resolves via `getCurrentRepo(cwd)` from the
callback input (same T4 pattern as `syncGroupPrCallback`) with a loud
failure instead of a silent wrong-repo fallback.
- `fix(pr-merge): resolve PR-node repo from task worktree instead of
process cwd` — `resolvePrSource` resolves from `task.worktree`, git ops
run in `getTaskWorktree(...) ?? task.worktree ?? process.cwd()`, and
`createPr`/`mergePr` pass `owner`/`repo` parsed from `entity.repo`.
- `fix(pr-merge): resolve review-response run cwd from the task
worktree` — the engine owns the store, so `buildRespondCallback` prefers
the task's recorded `worktree` for the response run's git ops + agent,
keeping `ops.getCwd` as the single-project fallback (defensive against
structural `PrNodeStore`s without `getTask`).
- Changeset (`@runfusion/fusion` patch, structured body) included.

Deliberately **not** done: a constructor-scoped default repo on
`GitHubClient` — one client instance is shared across all projects in a
central install (`serve.ts`/`daemon.ts`/`dashboard.ts`), so per-call
`owner`/`repo` is the only correct scope.

## Testing

- New regression tests simulate the central-install topology
(`getCurrentRepo` mocked as `(cwd?) => cwd ? repo : null`, exactly the
failing environment) and drive the merge flow end-to-end on the per-task
path, the shared-branch-group path, `createGroupPrCallback`, and all
three `createPrNodeGithubOps` ops, asserting every GitHub call carries
explicit `owner`/`repo` (45 tests in
`packages/cli/src/commands/__tests__/task-lifecycle.test.ts`, all
green).
- `packages/engine/src/__tests__/pr-respond-cwd-resolution.test.ts`
covers the respond-run cwd: worktree preferred, `ops.getCwd` fallback
when the task has no worktree, when the lookup fails, and when a
structural store has no `getTask`.
- Existing exact-argument assertions were extended to the new call
contract (no assertions weakened or removed).
- `pnpm lint`, `pnpm typecheck`, and `pnpm build` green locally; `pnpm
test:gate`'s engine-core suite green (294/294) — its PostgreSQL-backend
lane needs local PG credentials this environment lacks, so that lane
defers to CI. `pnpm verify:fast` (scoped typecheck/build + CLI build +
boot smoke) also passes.

## Repro

1. Install the CLI centrally; run the server from a dir that is not a
git repo, serving ≥1 project with a GitHub `origin` and `mergeStrategy:
"pull-request"`.
2. Run a task to completion and let it reach the merge stage.
3. Before this fix: the auto-merger throws `Could not determine
repository …` (tasks with a persisted PR poll fine but never merge).
Merging the same task from the Pull Requests tab succeeds, because the
dashboard route resolves the repo explicitly (`parseBadgeUrl(...) ??
getCurrentRepo(rootDir)`).

Full analysis: https://github.com/Tchori-Labs/Fusion/issues/4

---

Developed with Claude (co-authored on all commits).

https://claude.ai/code/session_01ChEa8SHFYNAzjCdFbwFMfh


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **Bug Fixes**
- Resolved pull request auto-merge failures in centrally installed,
multi-project deployments.
- Ensured explicit repository context (`owner/repo`) is used for pull
request lookup, creation, and merging throughout the merge workflow.
- Improved pull request response handling to prefer the task worktree
for working-directory resolution, with safe error behavior when task
details are unavailable.
- **Tests**
- Expanded coverage for multi-repository merge workflows and
worktree-based repository/cwd resolution in PR response handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude <noreply@anthropic.com>

2026-07-17 17:28:09 -07:00

scripts

fix smoke test

2026-06-10 18:06:51 -07:00

skill/fusion

fix(engine): add honest blocked exit to fn_task_done so impossible tasks park failed instead of laundering to done (#2256 )

2026-07-16 19:35:37 -07:00

src

fix(pr-merge): resolve repo from the project checkout, not process.cwd(), in PR-mode auto-merge (#2281 )

2026-07-17 17:28:09 -07:00

bin.mjs

FN-5916: fix CLI bin targets for pnpm install

2026-06-02 21:54:14 -07:00

build.ts

FN-7568: rename CLI release binary assets to fn-cli-<platform>

2026-07-05 11:31:45 -07:00

CHANGELOG.md

chore(release): v0.70.0

2026-07-17 17:12:42 -07:00

package.json

chore(release): v0.70.0

2026-07-17 17:12:42 -07:00

README.md

docs: clarify Homebrew trusted install

2026-07-12 15:37:02 -07:00

STANDALONE.md

fix(FN-7952): require PostgreSQL in CLI and desktop (#2110 )

2026-07-14 23:18:55 -07:00

tsconfig.json

feat(FN-2625): merge fusion/fn-2625

2026-04-26 21:36:23 -07:00

tsup.config.ts

FN-8224: add Claude ACP runtime support

2026-07-17 12:00:26 -07:00

vitest.build-exe.config.ts

perf(cli): skip native-binary build tests by default

2026-04-23 23:02:38 -07:00

vitest.config.ts

FN-8223: enforce full CLI quarantine ledger lockstep

2026-07-17 11:43:46 -07:00

README.md

@runfusion/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 → · GitHub · Docs

Fusion reel: from rough idea to production code

Install

Zero install, straight from npm:

npx runfusion.ai

Boots the dashboard. Subcommands forward through (npx runfusion.ai task list, etc). Long form: npx @runfusion/fusion dashboard.

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

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

Homebrew (macOS & Linux):

brew install runfusion/fusion/fusion

Fully-qualified install auto-taps and, on Homebrew 6.0+, trusts only this formula. If short-name install fails with “untrusted tap”, run brew trust --formula runfusion/fusion/fusion then brew install fusion.

npm global:

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

Launch the dashboard

From a shell:

fn dashboard                 # or: fusion dashboard / npx @runfusion/fusion dashboard
fn dashboard --paused        # start with automation paused
fn dashboard --dev           # development-mode dashboard + AI engine
fn dashboard --no-engine     # web UI only, no AI engine

The dashboard gives you:

A live kanban board — tasks move through columns automatically as AI works on them
Task detail view — generated spec, step-by-step progress, reviewer verdicts, full execution log
Dependency-aware scheduling — declare task dependencies or let the engine infer them
Auto-merge — on by default; reviewed work squash-merges without you lifting a finger
Parallel execution — independent tasks run simultaneously in isolated git worktrees
Self-sustaining board — agents may spawn follow-up tasks; the board feeds itself

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

Describe a task in plain language. A triage agent reads your project, understands context, and writes a full PROMPT.md spec — 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.

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

Run an agent company

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

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

How it works

You create a task with a rough description. A pipeline of specialized agents takes over.

Specification. A triage agent reads your codebase — file structure, existing patterns, related code — and turns your rough idea into a detailed spec. It breaks the work into discrete steps, identifies which files are in scope, writes acceptance criteria, and assigns a complexity rating that determines how aggressively the work gets reviewed.

Scheduling. Tasks declare dependencies on each other. The scheduler builds a dependency graph and starts work only when upstream tasks are done. Independent tasks run in parallel — each in its own isolated git worktree, so there are no conflicts during execution.

Execution & review. An executor agent works through the spec step by step in the worktree. At each step boundary, a separate reviewer agent, with read-only access, independently evaluates the work. The reviewer can approve (continue), request revisions (fix specific issues), or force a rethink (change the approach entirely). Review depth scales with the task's complexity rating: trivial tasks get light checks, complex tasks get thorough multi-pass review.

Merge. When execution finishes and the reviewer signs off, the task moves to In Review:

Direct merge (default) — automatically squash-merges the completed task branch into your current branch with a clean commit.
Pull request — automatically creates or links a GitHub PR, waits for reviews/checks, then merges once policy conditions are satisfied.

autoMerge controls whether Fusion performs completion automatically. If disabled, tasks stay in In Review until you finish the merge yourself. For PR-first mode, authenticate GitHub with gh auth login.

Tasks flow through: Triage → Todo → In Progress → In Review → Done.

This execution model is heavily based on Taskplane.

What makes it different


🧠 AI specification	Rough idea in, detailed `PROMPT.md` out — steps, file scope, acceptance criteria.
🔁 Workflow gates	Plan → Review → Execute → Review on every step. Block or pass automatically.
🌳 Worktree isolation	Each task runs in its own branch and worktree. Parallel tasks. Zero conflicts.
⚡ Smart merge	Passing every gate? Fusion squash-merges and moves on.
🛰️ Multi-node mesh	Laptop, server, cloud, phone — all synced. Desktop, mobile, web.
🧩 Any model	Anthropic, OpenAI, Ollama, and more.
🏢 Agent companies	Import pre-built teams — 440+ agents across 16 companies.
📬 Inter-agent messaging	Built-in mailbox between agents. Delegate, clarify, coordinate.
🗺️ Missions	Hierarchical planning with autopilot and validation contracts.
🔓 Open source. MIT.	No vendor lock-in. Run it on your own hardware.

Working from chat

Manage tasks without leaving the conversation:

"Every ten minutes, analyze the server code for logic the client hasn't implemented yet and create tasks. Tasks may spawn additional tasks, so just add enough to keep the board saturated."

"Create a Fusion task to fix the login redirect bug"

"Add a task for dark mode support, it depends on FN-003"

"What's the status of FN-042"

"Attach screenshot.png to FN-007"

"Pause FN-012 — I want to add more context first"

The Fusion extension exposes tools to create tasks, check progress, attach files, and pause or resume automation.

Standalone CLI

See STANDALONE.md for additional installation and usage options.

Optional provider: Factory AI via Droid CLI

@runfusion/fusion now ships a vendored @fusion/droid-cli extension in the published CLI bundle.

To use it:

Install the droid binary and ensure it is on your PATH
Authenticate with Droid CLI (droid auth login)
In Fusion dashboard, go to Settings → Authentication and enable Factory AI — via Droid CLI
Restart Fusion when prompted so the extension is loaded into the runtime

Once enabled, droid-cli models appear in Fusion model selection.

Maintainer note: workspace plugins in published CLI bundles

When CLI or dashboard runtime code imports workspace plugin packages (for example @fusion-plugin-examples/roadmap), those imports must stay statically analyzable and covered by packages/cli/tsup.config.ts noExternal rules so plugin runtime code is inlined into dist/bin.js.

Do not introduce dynamic or variable module specifiers for workspace plugin runtime paths in the published execution path. If a workspace plugin is needed for bundled auto-install, stage a bundled plugin entry (dist/plugins/<id>/bundled.js) rather than copying raw TypeScript source into dist/.

Full documentation

Architecture details, development setup, and contributor info live in the project README.

License

MIT — see LICENSE.

runfusion.ai →