Files
fusion/packages/engine/src/__tests__
gsxdsm 88df46bedb test: re-green executor-workspace onto FN-6756's contract (+ flag a dead branch) (#2617)
**Test-only.** One file. No production changes.
`executor-workspace.test.ts`: **2 failed / 10 passed → 13 passed**.

(This commit was pushed earlier and I failed to open its PR — the work
was finished and sitting on a dangling branch, which is why
`executor-workspace` still shows in main's failure census.)

## Why it was red

Both cases asserted that `clearPhantomExecutorBinding` **succeeds**
while session-registry paths are held.

PR #2531 (FN-6756, P0: *"stop reaping worktrees out from under live
planners"*) inverted that. `hasLiveSessionSurface` now includes
`activeSessionRegistry.pathsForTask(taskId).length > 0`, and that guard
runs **before** both branches — so any registered path refuses the
clear. The FNXC note at `executor.ts:2729` says the kind-blind guard is
deliberate: *"A leaked entry now blocks THIS sweep rather than a live
planner losing its worktree — the strictly safer failure."*

So the old expectations describe the pre-#2531 contract. Rewritten to
the current one, which had **no direct coverage**: a refusal leaves
`activeWorktrees` and the registry entries untouched. The FN-6736 KTD2
invariant ("every held path, not one") is kept, exercised with no
registry paths so the guard permits it.

**Verified the new tests guard:** removing the registry term from
`hasLiveSessionSurface` fails 2 of them (`NEW-failures=2`), and only
them.

## Flagged, not fixed — a possible dead branch

The guard appears to make **both branches it precedes** unreachable for
their stated purpose:

- the default branch exists to unregister every held registry path
(FN-6736);
- `preserveWorktrees: true` exists to **keep** those paths so a
`moveTask(preserveWorktree: true)` re-dispatch reattaches to the same
worktree (FN-7249) — and its **only** production caller is the
self-healing reclaim at `self-healing.ts:3565`.

Both need registered paths to do anything, and the guard rejects exactly
that case. With none registered, one sweeps nothing and the other
preserves nothing.

The third new test pins this so the conflict is **executable rather than
prose**: `preserveWorktrees: true` returns `false` while the path it
exists to preserve is registered.

I did not "fix" it by rewriting the assertion to match production — that
would bury a possible regression in FN-7249's reattach path. Resolving
it (exempting the non-destructive `preserveWorktrees` path, or narrowing
the guard by kind) is a product decision for the FN-6756 owner.

## Main's engine-default census, measured just now

| Point | Failed | Files |
|---|---|---|
| when I started this sweep | 283 | 28 |
| after the logger-mock fix (#2573) | 106 | 23 |
| **now** | **65** | **12** |

This PR clears one of the remaining 12.
`executor-review-verdicts.test.ts` is newly red and in my lane — taking
that next.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-07-29 21:37:14 -07:00
..