Completes FN-4315 by adding a patch changeset for `@runfusion/fusion` and updating project documentation (AGENTS.md and settings reference) to cover the audit recovery pipeline feature.
Fusion-Task-Id: FN-4315
Fusion-Task-Lineage: 2646fd86-e525-4b62-a041-616fa7789e84
Follow-up to a2b494ddc. The previous fix correctly stopped using
task.baseCommitSha for the contamination check, but the new
resolveContaminationBaseRef tried origin/main first and fell back to
local main only if the origin/main lookup failed. On dev machines that
have not pushed recently, origin/main is a tracking ref that can lag
local main by hundreds of commits. `git merge-base HEAD origin/main`
then resolves successfully and returns the last common ancestor between
the (force-reset-to-local-main) branch and the stale origin/main ref,
which is exactly the same stale SHA the prior bug surfaced. Every
commit on local main since that point is then flagged as foreign
contamination.
Observed: after restarting the engine with a2b494ddc, FN-4315/FN-4403
still failed with `since base e787036b80cc...`. Local main was 166
commits ahead of origin/main; e787036 was the last shared commit.
Fix: reorder the shell fallback to prefer `main` over `origin/main`.
Local main is the canonical integration target for Fusion's merger,
and origin/main is only useful as a fallback when local main does not
exist (rare in a worktree).
Test updated: `resolveContaminationBaseRef returns the current
merge-base...` now asserts local `main` appears before `origin/main` in
the issued command so the shell `||` resolves to local main first.
Fusion-Task-Id: FN-4417
The contamination check at executor.ts was reusing task.baseCommitSha as
its reference SHA. That field is intentionally preserved across resumed
sessions for stable diff math, which means it can lag behind main by
many commits. Passing it to assertCleanBranchAtBase caused every
legitimately-merged commit on main since the stale SHA to be reported
as a foreign task-attributed contamination commit, pausing the task
with pausedReason=branch-cross-contamination.
FN-4403 was the trigger case: a pooled worktree was force-reset to
current main by WorktreePool.prepareForTask (correctly), then the
executor immediately ran assertCleanBranchAtBase(rootDir, branch,
staleBaseCommitSha, taskId) and flagged 157 commits across ~39
unrelated FN-* tasks as contamination. FN-4417 itself then hit the
same bug when it tried to start, blocking the board.
Two fixes, both in packages/engine/src/executor.ts:
1. New resolveContaminationBaseRef(worktreePath) computes a fresh
merge-base against origin/main or main and is used in place of
resolveDiffBaseRef for the contamination check. It never reads
task.baseCommitSha and never falls back to HEAD~1 (which on a
force-reset pooled branch would be a main commit and re-introduce
the same false positive at smaller scale). Returns undefined on
git failure so the caller treats it as check skipped.
2. captureBaseCommitSha gains an explicit { isResume: boolean }
parameter and only preserves an existing baseCommitSha when
isResume is true. On fresh/pool acquisitions the branch was just
force-reset to current main, so the stored value is stale by
definition. Always recapture in that case. Diff-base stability
across resumed sessions (FN-4309/FN-4383) is preserved by passing
isResume: true on resume; the existing executor call site is
already gated on non-resume and passes false.
Tests:
- executor-base-commit-capture.test.ts: updated to thread isResume
through assertions and added a FN-4417 regression case that verifies
a stale-but-ancestor baseCommitSha is recaptured (not preserved) on
non-resume.
- executor-base-commit-capture.real-git.test.ts: FN-4309/FN-4383
multi-session test now explicitly passes isResume: true on the
second capture, matching the real resume code path.
- executor-contamination-base.test.ts (new): three focused tests for
resolveContaminationBaseRef covering fresh-merge-base resolution,
graceful failure when neither origin/main nor main resolves, and a
structural guard that the function arity is 1 (no baseCommitSha
parameter, so the bug cannot regress through that surface).
Verified: 4265 engine tests pass; tsc clean.
Fusion-Task-Id: FN-4417
- Unstage gitignored paths before squash merge commit creation using git check-ignore
- Re-run the guard on the verification-fix squash restore path to keep ignored artifacts out of final merges
- Add merger tests covering forced .fusion artifacts, spaced ignored paths, and ignored-only squash results
- Document the gitignored-path merge guard and add a published package changeset
Fusion-Task-Id: FN-4309
Squash-imported the working tree of fusion/fn-4326 as a single commit so this branch carries the dep's content without inheriting its individual commits. If the dep is later squash-merged to main, this commit's patch-id should match the merge and rebase cleanly.
Fusion-Task-Id: FN-4350
Fusion-Task-Lineage: 11fff2c2-1cd1-4562-9b01-032a15217479
Adopts the documentation and integration test additions from the
Fusion executor's parallel work on FN-4333 (sleek-oak worktree). The
core hot-fix already landed in ccd718acd.
- AGENTS.md: update the post-squash audit paragraph to describe the
three modes and the verified-tree short-circuit.
- docs/settings-reference.md: add postMergeAuditMode row.
- packages/engine/src/__tests__/merger-merge-lifecycle.test.ts: add
integration tests covering postMergeAuditMode=off (skips audit) and
postMergeAuditMode=warn (continues despite dirty findings).
Fusion-Task-Id: FN-4333
