## Summary
- Local `fusion/*` branches for **done** tasks kept unique tip SHAs
after squash/AI merge, so self-healing logged
`stale-active-branch-rescue-needed` on every maintenance sweep without
ever deleting them.
- **Completion fan-out** now force-deletes the task branch even when
unique commits remain (squash-safe).
- **`reclaim-stale-active-branches`** force-deletes complete-lane
leftovers (`reason=complete-column-unique-commits-force`) and no longer
emits rescue-needed for those lanes; non-complete columns still warn and
preserve unmerged work. Archived lanes still skip reclaim entirely.
Also cleaned up 116 leftover local fusion branches on this machine
(done/orphan only; 9 active kept).
## Test plan
- [x] `pnpm --filter @fusion/engine exec vitest run
src/__tests__/self-healing-completion-fanout.test.ts
src/__tests__/self-healing.test.ts -t "SelfHealingManager
reclaimStaleActiveBranches|self-healing completion
fan-out|force-deletes"`
- [ ] After merge/restart engine: confirm logs no longer spam
rescue-needed for done tasks
- [ ] Confirm active todo/in-progress fusion branches still get
rescue-needed when unique and no worktree
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved cleanup of stale task branches after completion, including
branches with unique commits remaining after squash or AI-assisted
merges.
* Completed tasks now reliably remove residual branches and worktree
metadata.
* Non-completed tasks continue to preserve recoverable branches and
display rescue warnings.
* Added clearer recovery logging and audit records for forced branch
cleanup.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
FN-8656 moved the recentEngineTodoRequeues / dispatch-oscillation reset behind
await resolveTaskParkedColumns, racing sync delete/update handlers. A hold
requeue then delete in the same tick could re-set the settle guard after the
clear and leave the card undispatchable. Consume the sync parked lanes in the
emitter prologue again.
Remove the FN-8700 PR/file-claim blocking mechanism end to end (operator
decision after FN-8728 parked on unrelated PR #2398):
- Drop the AGENTS.md claim-check rule and scripts/check-file-claimed.mjs
- Executor prompt + fn_task_done no longer accept pr:N refs or treat open
PRs as blocked-exit reasons
- execution-block-classifier classifies on Fusion task dependencies only;
legacy pr refs are discarded, reason prose never makes a block durable
- Remove the session-log BLOCKED promotion and the gh-backed
reconcile-external-pr-blockers self-healing sweep
- Legacy file-claim parks are no longer honored, so previously PR-blocked
rows recover via normal paths
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
## Summary
- add reverted-task resolution keys to every secondary app catalog
- restore structural locale parity after the reverted-task dashboard UI
landed
- include labeled patch release metadata
## Test plan
- `pnpm --filter @fusion/i18n test`
- `pnpm i18n:status`
- `pnpm check:changesets -- --strict`
- `pnpm build`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Localization**
* Added localized labels for reverted tasks, resolution actions,
revision actions, and related task titles in French, Korean, Simplified
Chinese, and Traditional Chinese.
* Added Spanish locale entries for consistent support of these task
actions.
* Improved terminology coverage across supported secondary locales.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Classify blocked exits so check-file-claimed / open-PR collisions never
auto-replan. Park failed with externalBlockers metadata (pr:N supported),
promote BLOCKED session logs instead of incomplete-step requeue, thrash-
exhaust after 3 identical durable blocks, and clear parks when gh reports
blocking PRs merged or closed.
Scope stuck-requeue merge-base failure to the task-branch proof so setup
still reaches the session; loosen MCP coverage to allow let session
rebinding; mock getRootDir for stranded-hold capacity; and expect the
scheduler parked-role site to use awaited resolveTaskParkedColumns after
FN-8656.
After one free needs-replan clear of an inactive DUPLICATE marker, a
re-emit of the same dismissed canonical parks status failed
(DUPLICATE_REPLAN_EXHAUSTED) so triage no longer re-admits the card.
Tracks clear count in sourceMetadata; self-healing mirrors triage.
FN-8704 failed at the graph parse node because PROMPT.md was only
"DUPLICATE: FN-8676". Filesystem validation treated non-empty as planned
and admitted the card into WIP, which then looped on parse failure.
Treat a sole DUPLICATE redirect as unplanned: block dispatch and hold
release, badge as awaiting planning, and if parse still sees that shape
rebound to needs-replan with feedback instead of parking failed.
Failed parks left in the WIP column still counted as running agents and
file-scope lease holders, so they consumed maxWorktrees/maxConcurrent and
could serialize unrelated todos. Match review-lane semantics: status
failed is never a live top-level holder.
Clearing a DUPLICATE marker for an inactive or kept canonical left
status:null without PROMPT.md. The scheduler treats planning→null as
"finished planning" and re-dispatched the card; FS validation rebounded
to needs-replan with no ceiling, and triage re-planned with empty
feedback so the planner could re-emit the same inactive marker forever
(FN-8704 / FN-8676).
Leave needs-replan + dismissal metadata + replan feedback instead, share
the clear contract across triage and self-healing, and bound scheduler
filesystem-validation rebounds with the shared recovery budget.
Session setup, track bookkeeping, intentional skill exclusions, token-cache
metrics, zero-count recovery summaries, and expected-missing PROMPT seed reads
were flooding the default log pane. Gate them behind FUSION_DEBUG so only
state transitions and operator-actionable warnings remain visible.
Refresh canonical live-task claims at serialized scheduler, planning, and merge admission boundaries, including workflow-step leases and reservation handoffs. Back off capacity-denied merges safely across abort and restart lifecycles. Render queued planning cards in the header badge family with compact reason-specific icons.
Route durable planning and review continuations through shared project admission, retain reservations through execution, and prevent duplicate continuations from releasing another run's slot.
Retained directories on queued, paused, blocked, or terminal tasks no longer
consume scheduler slots. Agent concurrency and worktree capacity now count the
same canonical live-task population through one project admission ceiling
(resolveActiveTaskCapacityLimit) with an atomic reserveIfAvailable claim, so
planning, execute, and merge lanes cannot each observe and claim the final
worktree slot independently.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Allow queued tasks to reuse worktrees they already hold when the durable worktree ledger is at or above capacity. Preserve independent agent and semaphore limits, and avoid releasing a worktree slot that a rejected transfer never acquired.
## Census
**Before: `COLUMN guards (the backlog): 2`, `--strict` RED. After:
`BACKLOG ZERO`, all five gates green.**
Two commits from last night's `maxWorktrees` rollout copied the same
holder ledger, both with literals:
| commit | file | gate |
|---|---|---|
| `374956ef23` | `triage.ts` | planning admission |
| `6c7467a78d` | `executor.ts` | `fn_spawn_agent` |
```ts
t.column !== "done" && t.column !== "archived"
```
## What it costs
Both exclude terminal lanes because a finished card's worktree is
**cleanup-owned, not capacity**. On a renamed board neither literal
matches, so every finished card keeps counting as a live holder. The
count only grows, the gate reaches zero room on a board with free slots,
and planning admission is withheld forever / every spawn is refused.
That is the **mirror** of the breach these commits fixed, and strictly
worse: 8 planners on a 4-slot board is visible; a permanent stall is
silent. The recorded reason even names the worktree budget, which the
operator then checks and finds has room.
## The conversion
`resolveProjectColumnsForRoles(store, ["complete", "archived"])` —
project-level, because the ledger spans the whole board with no single
task to resolve against. Matches triage's existing use in
`sweepStalePlanningStatuses` and executor's at the wip gates.
Legacy-seeded, so a default board still excludes exactly `done` and
`archived` — byte-identical there.
## Both conversions were UNCOVERED when written
Measured with #3214's blinding procedure **before** writing tests:
reverting either to the literals left **all 19 tests in the capacity
suites green**. Nothing in the tree could tell the conversion from what
it replaced — which is how the literals got there in the first place.
Each now has a renamed-board case that fails when blinded:
```
triage converted 2 passed | BLINDED 1 failed | 1 passed | restored 2 passed
executor converted 8 passed | BLINDED 1 failed | 7 passed | restored 8 passed
```
## The pairing earned itself immediately
Both new cases assert an **absence** (no throttle / no refusal), so each
is paired with a positive proving the gate still fires on the same
renamed board when a card genuinely holds the last worktree.
That caught a real defect in my own fixture: the candidate scan resolves
each task's **own workflow selection**, not `listWorkflowDefinitions`,
so my first version fell back to the default board where `drafting`
isn't a hold lane. No card was eligible, nothing throttled, and the
absence assertion **passed for the wrong reason**. The positive failed
and exposed it. Recorded at the fixture so the next reader doesn't
reintroduce it.
## Verification
```
42 tests across 6 capacity suites pass
check-fnxc-future-dates green
check-inert-sync-lane-conversions green
check-lane-wiring green
check-sql-column-literals green
census --strict green (BACKLOG ZERO restored)
```
No changeset: internal engine fix, no published-package surface change.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Last loose thread from the 2026-07-31 stamp-repointing wave. Two comment
lines.
```
line 1027 ConcurrencyAdmission 2026-07-31-09:00 -> 2026-07-21-22:30 (eef5eb751e)
line 1471 WorkflowLifecycleColumns 2026-07-31-05:00 -> 2026-07-30-20:55 (109204c590)
```
## Not a revert — neither value was ever right
| stamp | originally | after #3280 | authoring commit (UTC) |
|---|---|---|---|
| `ConcurrencyAdmission` | `2026-08-06-09:00` (16 days ahead) |
`2026-07-31-09:00` (10 days late) | **2026-07-21 22:30** |
| `WorkflowLifecycleColumns` | `2026-08-01-05:00` (~1.5 days ahead) |
`2026-07-31-05:00` (~1 day late) | **2026-07-30 20:55** |
Both were written **ahead of their own commits** to begin with. Three
lanes then repointed stamps to turn `main` green (#3261, #3269, #3280),
moving the **date** back a day while keeping the clock time — which
converts an hours-off stamp into a days-off one in the opposite
direction. #3282 reverted the batch it owned; these two were outside its
scope.
So restoring the originals would be wrong too. The defensible values are
the authoring commits' UTC timestamps, per the `date -u` rule #3281
settled.
## Why now
`scheduler.ts` is a hot file. This survived two successive claimants — I
flagged it on #3262 and again on #3288 rather than opening a conflicting
PR, and said I'd take it once the file was unclaimed.
`check-file-claimed` now reports UNCLAIMED, so here it is.
## Scope
The gate is **green either way** — #3277 fixed the comparison, so
nothing is blocked by this. It is purely about the FNXC trail recording
when the work actually happened, which is the only reason the trail
exists. A stamp that satisfies a check while misstating the date by ten
days is worse than no stamp.
## Verification
```
check-fnxc-future-dates green
check-inert-sync-lane-conversions green
check-lane-wiring green
check-sql-column-literals green
census --strict green
```
Diff is two comment lines — no executable change. No changeset.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## What
Pins the **worktree-capacity arithmetic** — the gap #3262 measured,
named, and explicitly left for someone to claim. Two commits: a
behaviour-preserving seam extraction, then the test.
#3262's own scope note:
> blinding this predicate to `false` leaves all 22 scheduler suites
green (365 tests). The capacity logic it feeds has no behavioural
coverage at all.
## Two live defects, opposite directions
Both came out of these few lines:
- **UNDER-COUNT admits work over the cap.** `maxWorktrees=4`, four
planning sessions each holding a worktree, and a replan dispatch
admitted as the **fifth** — the ledger counted WIP cards only and never
learned to count planners.
- **OVER-COUNT self-deadlocks.** A planned Ready card *retains* its
planning worktree for execution reuse, so counting it as a holder blocks
its own release: `2 wip + 3 idle-held = 5/4`, and the first unpause
released 2 of 4 slots' worth of work.
**Both are pinned, and the asymmetry is why.** Under-counting breaks the
cap and lets real work over it; over-counting only starves dispatch. A
test covering the "safe" direction alone would leave the expensive one
open.
## Mutation-tested — all four caught
| mutation | result |
|---|---|
| drop the terminal exclusion | 1 failed / 7 passed |
| count WIP cards twice | 2 failed / 6 passed |
| count cards holding no worktree | 1 failed / 7 passed |
| drop the self-slot subtraction | 1 failed / 7 passed |
```
clean: 8 passed (8)
scheduler suite: 16 files / 151 tests passed (behaviour preserved by the extraction)
typecheck, lint: clean
```
## Scope, stated rather than implied
The terminal predicate is **injected**, not resolved here. Which lanes
are terminal is #3262's test; resolving it in this file would make it
fail for that reason instead of this one. This pins the **set
arithmetic** — who is excluded, and how the total is formed.
Still not covered, and I am not claiming otherwise: the *stateful* half
of the ledger — the `+= 1` on dispatch and the `Math.max(0, … - 1)` on
failure inside `schedule()`'s loop. Extracting that would mean
restructuring dispatch itself, which is a different change from this
one.
## Process note
I claimed this on #3262 **before** starting rather than after, because
`scheduler.ts` is the hottest file in the tree and I produced three
duplicate PRs earlier tonight by picking up small shared-surface work
someone else already had in flight. Announcing first cost one comment;
the duplicates cost three PRs and two closes.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved scheduler capacity calculations for tasks that retain
existing worktrees.
* Prevented WIP tasks from being counted twice.
* Excluded completed and worktree-less tasks from reserved capacity.
* Corrected candidate capacity calculations when no worktree capacity is
reserved.
* **Tests**
* Added coverage for worktree reservation totals and candidate reuse
scenarios.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
