9cafa045df
## 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>
Changeset Format Guide
Each changeset file in this directory describes one user-facing change for release notes.
Required body format
---
"@runfusion/fusion": minor
---
summary: Add a Command Center productivity control for LOC backfills.
category: feature
dev: Uses the new `fn_backfill_loc` tool; settings key `commandCenter.locBackfill`.
Fields
| Field | Required | Description |
|---|---|---|
summary |
Yes | One line, user-facing, max 120 chars. Describe what changed for the operator. |
category |
Yes | One of: feature, fix, breaking, security, performance, internal. |
dev |
No | Developer or migration detail. Preserved in per-package CHANGELOGs but excluded from distilled release notes. |
Audience
The summary is the only content that appears in end-user release notes by default. Write for Fusion operators — describe behavior, fixes, and what changed. Avoid internal class names, file paths, and implementation detail.
Bump types
patch— bug fixes, internal changesminor— new features, CLI additions, toolsmajor— breaking changes
Validation
Run pnpm check:changesets to validate. The linter runs in the PR-check gate and test:gate. Legacy freeform changesets pass with a warning during the transition period.