## Summary
- thread resolved review lanes through `isTaskReadyForMerge`
- preserve required pre-merge step filtering
- add coverage for a renamed review lane
## Test plan
- `pnpm --filter @fusion/core exec vitest run --silent=passed-only
--reporter=dot src/__tests__/task-merge.test.ts`
- `pnpm --filter @fusion/core typecheck`
- `pnpm check:lane-wiring`
- `pnpm check:changesets`
- `pnpm exec eslint packages/core/src/merge/task-merge.ts
packages/core/src/__tests__/task-merge.test.ts`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Custom review lanes are now honored during merge-readiness checks and
auto-merge processing.
* Renamed workflow lanes correctly determine whether tasks can merge.
* Tasks resumed from a paused state are routed and evaluated using the
appropriate review lane.
* The default `in-review` lane remains supported when no custom review
lanes are configured.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: gsxdsm <gsxdsm@users.noreply.github.com>
ab9789f0a8 was committed with `git add -A` while an agent was mid-investigation
in this same checkout, so it captured that agent's temporary instrumentation:
eight `process.stderr.write('[F] …')` probe lines inside product code
(executor/mark-stuck-aborted.ts) and a 359-line scratch copy of a test file.
Both were pushed. Reverting both; no product behavior was ever intended to
change in those files.
Also lands the executor-stuck-requeue fix that investigation produced: the
grace-timeout assertion ran before the product finished, because the callback
continues past its timer into resetStepsIfWorkLost -> loadWorkspaceConfig, real
async fs I/O that `vi.advanceTimersByTimeAsync` does not await. The test now
awaits a completion barrier resolved by the requeue's own final moveTask rather
than a timeout or retry. The product was correct.
Lesson for this checkout: stage by explicit path while agents are running.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two product defects surfaced by workspace-e2e's remaining failures.
1. A merge-boundary fence silently did not apply. captureWorkspaceReviewEvidence
computes a repository's file list over baseCommitSha..<resolved task branch>,
but computeReviewDiffFingerprint hardcoded baseRef..HEAD. For a workspace
entry whose checkout sits on the integration branch those are different
ranges, so the fingerprint did not describe the files captured beside it: a
diverged checkout hard-failed an approved repository as content-changed,
and a checkout at the base produced an empty diff -> undefined fingerprint ->
the repo dropped out of mergeBoundaryFingerprints, so BOTH the
approval-missing and content-changed fences stopped applying to it at all.
computeReviewDiffFingerprint now takes an optional headRef; workspace
evidence passes the resolved task branch. The singular-review caller, whose
worktree IS the branch, keeps the ambient HEAD default.
2. Land intents were recorded and resolved under different conditions.
landOneRepo records an intent only when ctx.workspaceLand is set, which
landWorkspaceTask passes only for remote targets, but the resolve side was
gated on durableLandLease alone. A local-only land therefore resolved an
intent that was never recorded, got "missing", and failed a fully-landed
repo as a partial land AFTER its integration ref had advanced. Resolve now
uses the same condition as record.
The approveWorkspaceReview helper's "reviewStep called exactly once" constant
only held because defect 1 suppressed a repository; it now derives the expected
count from the same production capture the review loop uses.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An investigation reported that under PostgreSQL `updateTask(id, { steps: [] })`
silently no-ops while a non-empty array writes fine, and worked around it in
fixtures. Reproduced and traced: the write is literal and correct — the row and
task.json both hold `[]`. What actually happens is that an empty array means
"plan not parsed yet", not "this task has no steps", so all four read paths
re-derive steps from PROMPT.md when the stored array is empty: getTaskImpl, the
two list hydrations (reads.ts), and updateStep's auto-init, whose range error
already says outright that "its steps are defined in PROMPT.md".
No product change: removing the re-derivation would strand every task whose plan
lives only in PROMPT.md. Instead both halves of the contract are now pinned by a
PG test and documented at the write site, so the next reader sees the mechanism
instead of re-diagnosing it as a lost write. To make a task genuinely stepless,
remove the step headings from PROMPT.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Six parallel agents worked the 150 remaining failures. Engine suite: 297 failing
tests at baseline 3f448f7292 -> 8. 12,391 passing.
The failures were mostly pointing at live regressions, not stale tests. Eleven
product defects found and fixed:
- Operator approval mail dropped from BOTH executor gate closures: a gate paused
a task for approval and no mailbox row was ever written.
- FN-8840 title-duplicate handling reverted in triage.ts, self-healing.ts, and
scheduler.ts: a title-only "DUPLICATE: <id>" card consumed a full planner
session, an operator-authored PROMPT.md could be erased, and a title-only
redirect became dispatchable again.
- A failed plan-admission audit write set its dedupe marker anyway, silencing
the stall permanently (FN-8600 regression); engine now has an outcome-reporting
bounded-audit seam mirroring core's FN-9182.
- A best-effort plan mirror could abort a whole planning attempt after the
authoritative PROMPT.md had already been written.
- AI-merge cleanup lost its alreadyAbsent/idempotent signal on the real-git path.
- Workspace merge-boundary file comparison ran without its review-evidence fence,
hard-failing every file for callers with no review episode.
- After a file-scope violation the retry re-selected the rejected squash and
never re-merged.
- Parallel step branches leaked: a name-based classifier read executor-created
fusion/step-* branches as operator-owned and skipped cleanup.
- workspace_coordination_leases / workspace_land_intents were missing from
projectTableNames, so the PG harness never truncated them and leases leaked
across tests.
Four of those are silent reversions from ONE commit, 1cf86baa1c, labeled a
behavior-preserving "executor pure peels" refactor. It passed its own targeted
verification; only a full-suite audit found them.
Test-side repairs are root-cause fixes at shared factories: required pre-merge
gate declarations, branch-write provenance, fake stores missing production write
seams, dead vi.mock specifiers that silently mocked nothing (allowlist ratcheted
11 -> 8), and stale expectations after deliberate IR/tool/error-class changes.
Tests for deleted features were deleted with their removing commit cited.
Left red deliberately (4): executor-worktree-liveness's unrouted-graph-run
assertion and three workspace-e2e landing-stack layers, each needing a design
ruling rather than a test edit. Two durable-write call sites remain flagged
unresolved rather than given invented fencing verdicts.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three more fixtures wrote a task branch without an origin, so the
`updateTaskUnlockedImpl` provenance boundary threw before any scenario ran —
the same guard, and the same missed-fixture class, as the shared reliability
helper fixed earlier. Each fixture binds a task to its worktree branch on the
engine's behalf, so each now says so.
worktree-lifecycle-certification 0/4 -> 4/4, audit-and-recovery 1/3 -> 3/3,
self-healing-interactions 6/7 -> 7/7.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fusion agents keep shipping behavior changes that leave stale tests behind, and
targeted verification structurally cannot catch it: it runs the tests for the
files the agent TOUCHED, while the assertions encoding the old behavior live in
files it did not. Measured on one full engine suite run (2026-08-24): 297 failing
tests, ~135 of them from exactly five such changes — the FN-158 pre-merge-gate
guard (~70 fixtures across 13 files), the branch-write provenance guard (18 from
ONE shared fixture), a workflow-IR reorder (10 stale topology assertions), an
updateTaskAtomic seam missing from fake stores (~9), and FN-074's splitting
removal leaving 4 reviewer-prompt tests asserting a deleted contract. Every one
passed its own targeted verification.
- AGENTS.md: new standing rule with the four search triggers (guard added,
feature removed, order/default/constant/prompt changed, public method added),
a fix-at-the-shared-factory preference, and an explicit ban on weakening a
stale test or restoring removed behavior to satisfy one.
- Executor prompt: the same searches, stated as a finish condition.
- Full triage prompt: specs for behavior-changing tasks must include a step that
NAMES the search, so it is planned rather than left to chance.
The fast triage prompt is deliberately excluded: it carries a hard size budget
(agent-prompts.test.ts caps it at 7500 chars) and adding this pushed it over —
an instance of the very rule being documented, now cited in it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Mark isAtOrPastReviewLane as DELIBERATE-LITERAL so the lifecycle-column
census ratchet stops treating FN-158's physical pre-cutover lane IDs as
new unexamined guards. Refresh the pinned baseline to match.
Four tests asserted DEFAULT_REVIEWER_PROMPT still carried the task-SPLITTING
contract: "Subtask breakdown", "12+ implementation steps", "The bar for
splitting is high", and a REVISE directing the planner to fn_task_create 2-5
child tasks. FN-074 removed task splitting across core, dashboard, and engine,
and FN-125 removed the reviewer's ability to create tasks at all. FN-074's
message says it updated affected tests; these were missed and sat red asserting
a contract the product deliberately dropped.
Removed rather than repaired: restoring that prompt text to make them pass would
re-add removed behaviour. The two tests in this block covering the prompt
contract that still exists are untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The engine suite's failures are not independent bugs; they are a handful of
systemic drifts where a guard shipped and its fixtures were never updated.
- Required pre-merge gates (FN-158): the door refuses a card whose enabled
optional groups produced no result, and the built-in workflow enables Plan and
Code Review by default. Merge-mechanics fixtures now declare an explicit empty
list, stating the intent they always had. group-merge-coordinator's
"post-Code-Review member" instead gets real PASSING workflowStepResults,
because recording the pass is what that fixture actually means.
- Branch-write provenance: the shared reliability fixture creates a task with a
branch, which now requires an explicit origin. It stands in for an
engine-created branch, so it says so.
- updateTaskAtomic: a production write seam missing from several fake stores,
copied from the faithful fake in merger-ai.test.ts.
- Durable-write inventory: eight unclassified TaskStore surfaces classified,
including the two batched reads this branch added.
- workflow-graph-merge-region-collapse asserted completion-summary AFTER
code-review; the IR wires it before, and production logs agree.
merger-ai.test.ts alone goes 37 -> 0. Engine failures 288 -> ~200.
Also records a first-sighting suite-only flake in the observed register per the
standing rule, rather than quarantining a file with substantial coverage.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Full-suite set-diff against 3f448f7292 caught three regressions the raw counts
hid (that suite is chronically red: 297 failures at baseline, 294 with the
change).
The step exemption was too broad. It also applied to
recoverAlreadyMergedReviewTasks, the content-scan recovery where mergeDetails is
ABSENT and landing is inferred by finding matching content on the base branch.
That heuristic can match a cherry-pick, so exempting incomplete steps there
would launder a genuinely unfinished task to done on a guess — which is exactly
what landed-content-soft-blocker.real-git.test.ts exists to prevent. The
exemption now requires mergeConfirmed AND a commitSha: FN-9193's actual state,
and nothing weaker. Content-scan recovery and no-op merges keep the blocker.
Also seeds mergeSweepHoldReasons in the shared merge-lane fixture, which the
fixture-drift guard requires of every auto-merge state field.
Verified by set-diff: zero test files now fail that did not fail at baseline.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
FN-9193's branch landed on main as eaa1d47c, but a Code Review revision request
had reset its steps while the approved merge was in flight. The card was left
mergeConfirmed WITH incomplete steps, and every finalization site refused with
"task has incomplete steps" — so it sat failed, re-reading its own contradiction.
Restarting it made things worse: replanning issued seven fresh pending steps, so
the retry re-created the exact condition blocking it. A loop with no exit.
Holding a landed card out of done un-merges nothing; the code is on the target
branch either way. All four finalization sites now use
getMergeConfirmedFinalizationBlocker, which exempts incomplete steps once
landing is proven and records the unfinished ones on the task instead of
dropping them. A no-op merge that landed no content still blocks — that is the
protective half of the guard being replaced, and the executor's no-op branch
depends on it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Use a consistent icon-and-label back affordance across direct and room chat threads.
- Render the lucide ArrowLeft icon with localized Back text and preserved accessible naming.
- Cover mobile direct and room thread back buttons with icon, text, and accessibility assertions.
- Add a patch changeset for the published Fusion package.
Files changed:
.changeset/fix-chat-back-arrow.md | 6 ++++++
packages/dashboard/app/components/ChatView.css | 2 +-
packages/dashboard/app/components/ChatView.tsx | 14 ++++++++++++--
.../app/components/__tests__/ChatView.mobile.test.tsx | 4 +++-
.../app/components/__tests__/ChatView.rooms.test.tsx | 7 ++++++-
5 files changed, 28 insertions(+), 5 deletions(-)
Fusion-Task-Id: FN-9199
Fusion-Task-Lineage: aab2a300-cc2a-4768-b60b-81d7477b8fab
Co-authored-by: Fusion (runfusion.ai) <noreply@runfusion.ai>
ProjectEngine's in-review auto-merge sweep was a second merge authority. It
judged eligibility from column, status, steps and retry budget alone, with no
idea where the card sat in its workflow graph, so it merged work the graph had
never authorized: FN-9191 merged ~2s after fn_task_done, before Code Review had
ever started, and FN-9193 merged while Code Review was re-running — the gate
then requested revision and reset the steps, but the in-flight merge landed the
pre-remediation branch anyway and left the card mergeConfirmed WITH incomplete
steps, unfinalizable for five hours.
- classifyMergeSweepAdmission (core) admits only merge-confirmed finalization,
a card parked at a merge-region node, an interrupted attempt, or a fenced
quiescent stall. Every initiation is fenced on satisfied pre-merge gates.
- All four doors prove authority: the sweep, the 300ms column-entry handoff
(which matches FN-9191's timing better than any sweep tick), the unpause
re-enqueue, and a position-only pre-dispatch re-check for cards the graph
moved out of the merge lane while they were queued.
- workflow-merge-region.ts holds the canonical merge-region predicate;
INTERPRETER_ENTRY_NODE_KINDS now aliases it so the two cannot drift.
- Multi-repo: branch-group integration/promotion are merge-region nodes, an
in-flight sub-repo land reads as foreign liveness, and a cross-node
merge-dispatch lease defers.
- Sweep reads are batched, so admission costs O(1) queries per poll.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
An enabled pre-merge gate that has not reported yet is a not-yet condition,
not a failure. FN-9191 proved the difference is load-bearing: the in-review
auto-merge sweep enqueued the card ~2s after fn_task_done and ~18s before the
graph started its own Code Review node, the merge door correctly refused, and
the auto-merge error path parked it status="failed". Code Review APPROVED two
minutes later, but every subsequent merge — including the graph's own merge
node — then died on "task is marked 'failed'".
- Merge doors throw the typed PreMergeStepsNotRunError for that blocker.
- The auto-merge error path treats it as a deferral: no status write, no
mergeRetries burn, no operator handoff.
- enqueueEligibleInReviewTasks holds a card out of the merge queue until every
enabled pre-merge group has a result, so the race stops at admission.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Tailscale remote access failed in the container with a bare "process exited 1":
the image ships the `tailscale` CLI but nothing ever ran `tailscaled`, so the
`tailscale funnel <port>` spawn died instantly on "failed to connect to local
tailscaled".
- Add scripts/docker-entrypoint.sh, which best-effort starts tailscaled in
userspace-networking mode (needs neither NET_ADMIN nor /dev/net/tun, so the
documented `docker run` is unchanged) and then execs the CLI with CMD verbatim.
Opt out with FUSION_DISABLE_TAILSCALED=1.
- Symlink /var/lib/tailscale into /home/node/.tailscale so the documented
`-v <vol>:/home/node` mount persists the node login across container recreates,
and pre-create the daemon's socket/log paths node-owned before the USER switch.
- Preflight daemon reachability and backend state with `tailscale status --json`
in evaluateRemoteLifecycle instead of only `which tailscale`, so unreachable,
logged-out, and stopped backends all report an actionable
runtime_prerequisite_missing reason rather than an unexplained exit 1.
Regression coverage asserts the invariant across all three unusable-backend
surfaces, not just the reported container repro.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Migrations 0061 (activity-log task-id index), 0062 (remove task/subtask
splitting), 0063 (AI merge review reconciliation), and 0064 (task repository
scope) advanced SCHEMA_BASELINE_VERSION to 0064 without updating this
non-gate PG integration test, leaving it red on the non-blocking suite:
- Bump the immutable-identity assertion to 0064 and pin 0062-0064 identities.
- Append the four new versions to all five getAppliedMigrations() lists.
- Add central.central_activity_log to the hand-built 0000 upgrade fixture so
the 0061 index migration finds the relation real 0000 DBs have from
0000_initial.sql (fixture gap, not a product regression).
FN-149 shipped migration 0065_fn_149_review_convergence_stage.sql and registered
REVIEW_CONVERGENCE_STAGE_VERSION but left SCHEMA_BASELINE_VERSION at "0064". The first
store open applied and recorded 0065; the next open (project store, same boot) hit
assertBinaryNotOlderThanDatabase, saw 0065 > 0064 and threw StaleBinarySchemaError, so
every startup died with "this binary only knows up to 0064" on fresh and upgraded
databases alike.
- Bump SCHEMA_BASELINE_VERSION to "0065" (marker only: applies no SQL, touches no data).
- Move the DB-free migration-wiring assertions out of the PostgreSQL integration file
into src/__tests__/migration-wiring-integrity.test.ts and wire it into test:unit-gate,
so the ceiling/migration drift now fails the merge gate instead of main's boot.
- Refresh the stale migration-identity expectations (0062-0065).
Symptom verification: `node scripts/dev-with-memory.mjs --isolated=<tmp> --prebuild none`
exited 1 with the guard error before; it now boots and serves the dashboard.
Allow users to pan the desktop and tablet board from noninteractive task-card surfaces without disrupting controls or mobile scrolling.
- Start horizontal panning from eligible task-card bodies and text while preserving native controls and editing behavior.
- Wire board pan state and cursor styling across live board roots while keeping mobile snap and touch scrolling unchanged.
- Add regression coverage, documentation updates, and a patch changeset.
Files changed:
.changeset/fn-109-board-card-pan.md | 7 ++
docs/dashboard-guide.md | 5 +-
docs/task-management.md | 4 +-
packages/dashboard/app/components/Board.css | 7 +-
packages/dashboard/app/components/Board.tsx | 8 +-
.../app/components/__tests__/Board.test.tsx | 98 ++++++++++++++++------
.../app/hooks/__tests__/useBoardMousePan.test.tsx | 47 ++++++++++-
packages/dashboard/app/hooks/useBoardMousePan.ts | 12 +--
8 files changed, 146 insertions(+), 42 deletions(-)
Fusion-Task-Id: FN-109
Fusion-Task-Lineage: 456bd9d3-9767-4b82-9f99-f191abc44b18
Co-authored-by: Fusion <noreply@runfusion.ai>
## Summary
- update workspace worktree test stores for callback-based entry
mutations
- preserve validation, existing-entry, and singular-routing behavior in
the fakes
- canonicalize the macOS worktree path fixture before comparing
persisted state
- remove the stale inert-seam exception left after the review-column
callback became fully supplied
## Test plan
- `pnpm --filter @fusion/engine exec vitest run
src/__tests__/node-worktree-isolation.test.ts
src/__tests__/workspace-root-worktree-routing.test.ts
src/__tests__/worktree-acquisition.test.ts --silent=passed-only
--reporter=dot`
- `pnpm --filter @fusion/engine exec vitest run
src/__tests__/worktree-acquisition-workspace.test.ts
--silent=passed-only --reporter=dot`
- Directly changed engine workspace suite with PostgreSQL-dependent
blocks skipped: 338 passed, 4 skipped
- `pnpm --filter @fusion/engine typecheck`
- `node scripts/check-inert-flag-seams.mjs`
- `node --test scripts/__tests__/check-inert-flag-seams.test.mjs`
- `pnpm lint`
- `pnpm check:changesets`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved recovery of orphaned worktrees by consistently using
canonical paths.
* Strengthened worktree assignment and updates to preserve existing
entries and prevent stale task state.
* Improved synchronization and validation during concurrent workspace
updates.
* Refined self-healing recovery so branch metadata changes only when
necessary.
* Improved handling of stalled tasks, retry exhaustion, and clearing
obsolete worktree or branch information.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
