root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
12,496 Commits 1 Branch 0 Tags
dca20496f4c5cc03d86906d63f5536ee545e2bbf
Commit Graph

2366 Commits

Author SHA1 Message Date
gsxdsm
dca20496f4 consolidate/u7: plugins to zero + 8 executor rebound guards + resume lanes (supersedes #2607, #2635, #2640) (#2644) 
Consolidation branch for U7, per the new one-branch working mode.
**Supersedes #2607, #2635, #2640** — the three of my PRs that were stuck
on review threads. My other seven (#2602, #2605, #2606, #2611, #2621,
#2628, #2633) are green with **zero unresolved threads** and are
deliberately left alone for the merge sweep.

## What is in here, file by file

| file | change | guards before → after |
|---|---|---|
| `plugins/…/glasses/src/agent-actions.ts` | gates, destinations and
degraded-resolution refusal all resolve from the task's own workflow | 2
→ 0 |
| `plugins/…/glasses/src/quick-capture.ts` | accepted capture columns
come from the board; default no longer names the deleted column | 1 → 0
|
| `plugins/…/glasses/src/settings.ts` | quick-capture default was
`triage`, the column #2515 removed | (assignment, uncounted) |
| `plugins/…/dependency-graph/src/GraphTaskNode.tsx` | redundant column
condition deleted | 1 → 0 |
| `packages/engine/src/executor.ts` | 8 rebound guards compare the
resolved column; 4 resume-eligibility literals share one resolver | 151
→ 143 (+4 off-bar) |
| `packages/engine/src/__tests__/` | 4 new suites, 26 cases | — |

`plugins/` reaches **zero** column guards with this branch.

## The three threads it closes

**#2607 — five findings, all mine, all the same rule.** I kept
*qualifying* a legacy-id fallback instead of removing it:

| attempt | rule | hole review found |
|---|---|---|
| 1 | fall back to `todo` when the role is missing | moved cards to
phantom columns |
| 2 | …only if the workflow **declares** `todo` | aliased **review**
lane named `todo` |
| 3 | …and only if no other role is assigned to it | **traitless**
parking column named `todo` |

The qualifications were the mistake. Once `resolveLanes` returns a lane
set the workflow *has* a column vocabulary, so "no column carries the
hold trait" is a complete answer — refuse. `destination()` is two lines
now, with no aliasing surface left to qualify.

Plus a sixth, which is a genuinely different state: **degraded
resolution is indistinguishable from the default board.**
`resolveWorkflowIrForTask` is total by design — a missing definition
silently returns the *default* coding IR — so a card on a custom board
whose definition could not be read resolved to `todo`/`in-progress`.
`undefined` lanes cannot express that (it means "no workflow at all",
where the legacy ids *are* the answer). The actions now refuse with 409.
#2618 would replace this check with resolver provenance; it is not
merged, so this does not depend on it.

**#2635 — "seven rebound sites remain untested."** Fair; my "same shape"
note was an assertion, not coverage. Seven of the eight need a live
graph run to reach, so the *shape* is pinned instead: a static check
that no guard in front of a rebound move compares against a column
literal, with a vacuity case (the same detection run against the
original shape) and a match-count floor (≥8), because a guard reporting
success on zero matches is worse than no guard.

**#2640 — duplicate workflow resolution.** Framed as I/O; it is also a
correctness bug. Eligibility and re-entry are two halves of one decision
and resolved the workflow separately, so a workflow edit landing between
them has the halves reading *different boards*. Now one caller-owned
memo per decision — caller-owned because a process-lifetime cache would
have to guess when a mid-flight workflow edit invalidates it.

## Behavioural findings, not tidying

- **The last-resort recovery for completed-but-stranded work did not
exist off the default lineage.** `promotedFromPlannerColumn` was false
on a renamed board, so finished work resting in planning was never
promoted; the code fell through to a review handoff that role adjacency
rejects, and the card stayed stuck with its work complete.
- **Rebound guards could not see the column their own move targeted.**
U5b converted the move target; the eight `column !== "todo"` checks in
front of it were left literal, so on a renamed board the engine moved a
card into the column it was already in — and `moveTaskInternal` runs
reset-on-entry on every real move, so at the `preserveProgress: false`
site it reset step progress a second time.
- **The FN-1404 `task:move` audit row was lying**, recording `to:
"todo"` while the move target was resolved. A run-audit trail that
disagrees with the move it describes is worse than none. Not a
comparison, so no census counts it.
- **A task interrupted by an engine pause never resumed on a renamed
board** (off-bar, `in-review`/`in-progress` literals): four comparisons
decided one question and had to agree; two of them disagreed on a
renamed board, so re-entry silently never fired.

## Revert proofs, isolated per site

| reverted | result |
|---|---|
| `destination()` back to attempt 3 | 3 of 38 fail |
| degraded-resolution refusals removed | 2 of 42 fail |
| capture set back to the legacy five | 2 of 3 fail (renamed-board
suite) |
| forward exclusions → literals | 1 of 14 fails |
| missing-wip refusal removed | 2 of 14 fail |
| `promotedFromPlannerColumn` → literals | 3 of 7 fail |
| promotion target → `"in-progress"` | 3 of 7 fail |
| one rebound guard → `!== "todo"` | 1 of 3 fails (static shape) |
| resume lanes → legacy trio | 1 of 5 fails |

Every conversion is paired with a negative — a forward move, a
not-a-planner-lane card, a default-lineage card, an unresolvable
workflow — so neither "always fire" nor "never fire" can pass for
"resolve the role".

## Commit discipline

Twelve commits, each one thing: the code move (`resolvePlannerLanes` out
of `triage.ts`) is separate from every behavior change, and each review
fix is its own commit with its own revert proof.

## Verification

- `pnpm test:gate` **71/71**
- 162/162 across the glasses plugin's 19 files; 26/26 across the four
new engine suites
- engine + glasses typecheck clean; `pnpm lint` clean

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


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Engine recovery and retries now work correctly with renamed or
customized workflow columns.
  * Tasks in manual-intake columns are no longer automatically planned.
* Agent actions and quick capture now respect each board’s declared
columns and lifecycle stages.
* Awaiting-approval tasks are recognized regardless of their current
column.
* Command Center SDLC funnel stages now accurately reflect customized
workflows.

* **Documentation**
* Added guidance for safely changing workflow-column logic and
interpreting lifecycle-column checks.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:52:55 -07:00
gsxdsm
f6010ef558 fix(test): planning-lane E2E is RED on main (2/7, incl. its own control) — same unplanned-spec fixture defect #2634 fixed next door (#2658) 
Found while establishing the pre-closing E2E baseline for the final
verification pass (closing bar, item 4). **Two of this family's seven
cases are failing on `origin/main` right now**, and one of them is its
own control.

```
releases an ordinary held card on a default board (the control)       expected [] to include 'FN-OK'
holds a card parked for approval MID-SWEEP, after the snapshot read   expected false to be true
```

## Cause — the same defect #2634 repaired in the file next door

`seedHeldTask` creates the task and never writes a `PROMPT.md`, so the
card carries only the bootstrap seed. FN-7648's
`isUnplannedForExecution` reads that file for any card resting in an
intake- or hold-trait column and refuses to move an unplanned card into
a processing column, so the sweep released nothing.

**Being held was the gate working.** The fixture was exercising the gate
rather than the sweep — which is exactly why the *control* failed, and a
failing control means the rest of the family's assertions cannot be
trusted either.

`workflow-lifecycle-live-e2e` had the identical problem and #2634 fixed
it the same way. This file landed alongside it (#2611) and did not get
the same treatment. Worth stating twice because it is a general rule for
this directory: **a release/scheduler fixture that does not model a card
which cleared specification is testing the gate, not the sweep.**

## The check that matters more than the fix

#2611's stated value is "3/7 red without the guard". Making red tests
green is the easiest thing in the world to do wrongly, so I verified the
family still discriminates *after* the seed — disabling
`isTaskBlockedOnApproval` in `hold-release.ts` still kills exactly
three, and the same three:

| killed by mutation |
|---|
| does NOT release a card blocked on manual plan approval on a
**default** board |
| does NOT release a card blocked on manual plan approval on a
**renamed** board |
| holds a card parked for approval **MID-SWEEP**, after the snapshot was
read |

Two cases turned green, zero discriminating power lost. Without that
mutation this change would be indistinguishable from weakening the tests
until they passed, which the standing rule forbids.

Note the third killed case is also one of the two that were failing: it
was red for the fixture reason **and** genuinely proves the guard.

## Why it is worth a PR of its own

The closing bar's final verification pass (gate, `verify:fast`, all E2E,
census) has to run on a green tree. Two red E2E cases on main would
otherwise show up in that report as a new failure and cost a diagnosis
at exactly the wrong moment.

Pre-closing baseline for the record — **13 E2E families, 109 tests,
these 2 the only failures**:

```
green  agent-count 13 · agent-link 5 · lease-rebound 6 · lifecycle 24 · merge-family 7
       merge-rebound 4 · merge-safeguards 10 · merged-board 5 · planner-lane 5
       planner-lane-resolution 3 · rebound-family 15 · stranded-column 5
RED    planning-lane 7  (2 failing)
```

## Verification

7/7 green, mutation 3/7 as designed, engine typecheck clean (0 lines),
`pnpm lint` exit 0, `pnpm test:gate` exit 0.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:47:43 -07:00
gsxdsm
b6b2fdcdc6 test(U7): rescue the orphan-triage regression test — main has the fix but not its test (#2663) 
Main already carries **every other artifact** from #2593 — the
provenance fix, the `DELIBERATE-LITERAL` markers in
`TaskCard`/`TaskDetailModal`/`register-routes`, the audit doc. The one
thing missing is the test.

That is the same artifact class that vanished when #2645's branch was
force-pushed, so I rebased #2593 onto current main, found every commit
conflicting because the work had landed by other routes, and rescued the
one piece that had not.

**#2593 can now be closed** — it carries nothing else main lacks.
**#2654 needs rebasing onto main** rather than stacking on it.

## What makes this test worth rescuing

It took three attempts to write honestly, and the reason is pinned in
the test body: on a bare mock, `resolvePlannerLanes` reads
`resolveTaskWorkflowIrSync`, which the mock does not define, so it
returns `LEGACY_PLANNER_LANES` (`intake: "triage"`) and a `triage` card
matches the **first** arm — the orphan arm is never reached. Every
earlier fixture I wrote passed through that short-circuit and proved
nothing.

All three cases stub that reader with the merged default (`intake:
"todo"`), which is what production resolves, leaving the orphan arm as
the only thing deciding. They differ **only** in the workflow readers.

| case | role |
|---|---|
| **C** — workflow declares `triage` as a review lane | **the
discriminator.** Pre-fix, the sync reader ignores the selection, returns
the default IR declaring no `triage`, so the arm fires and a card is
finalized out of a custom workflow's code-review column |
| **B** — workflow resolves, declares no `triage` | positive control;
without it "returns false" is unfalsifiable |
| **A** — workflow unresolvable | **behavior pin, NOT a regression
test** — passes in both worlds |

I had A labelled "REGRESSION" until the mutation said otherwise. It is
relabelled with the null result documented, because a future edit making
it flip would mean the arm's scope changed.

## Verification, stated precisely

**231/231** against main's implementation.

The mutation that proved C discriminates was run on the branch where the
pre-fix code still compiled. **It cannot be re-run against main**: the
`WorkflowIr` type import was removed along with the fix, so a naive
revert no longer transforms. I am stating that rather than implying I
re-verified it here — the discrimination was demonstrated, just not on
this base.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:37:20 -07:00
gsxdsm
3bf9bf5f74 collapse the plan-admission-throttle payload to one gate (+ AGENTS.md) (#2562) 
The cross-project semaphore is deleted, so
`task:plan-admission-throttled` was describing a gate that no longer
exists. Nothing wires `options.semaphore` any more, which left three
things dead-but-visible:

- `semaphoreAvailable` was permanently `Infinity`, so
`Math.min(projectRoom, …)` was a no-op keeping a deleted limiter in the
arithmetic
- `blockedBy` was a **discriminator** between `"running-agent cap"` and
`"global semaphore"`; only the first can occur
- four `semaphore*` metadata fields were always `undefined`, and two
more terms in the dedupe signature were constant

## `blockedBy` is kept, not dropped

Even though it is now a constant. The event exists (FN-8600) to answer
*“why did this card sit queued to plan?”* after the fact — a named
reason answers that even when there is one gate, whereas a payload with
**no** reason field reads as “unknown”. It costs nothing and preserves
the shape if a second gate is ever added.

The dedupe signature drops the two semaphore terms and keeps the
eligible task IDs — that term is what stops a **new** card’s stall being
swallowed when the counts land on an unchanged tuple, which is the
property the event depends on.

## AGENTS.md

It documented the removed field names verbatim, so it is updated in the
same commit. Leaving docs describing a payload the code cannot emit is
exactly the readable-but-wrong artifact this program keeps deleting.

## Verification

`pnpm lint` clean · engine `tsc` clean · `pnpm test:gate` green · triage
suites **234/234**.

---

**Correction I owe on `concurrency.ts`, measured rather than
estimated.** I earlier told the coordinator ~75% of its 886 lines could
go with the cross-project cap. That was line-range arithmetic and it was
wrong. With the cap now fully removed, `concurrency.ts` is **still 886
lines**, because `AgentSemaphore` has four consumers unrelated to it —
`verification-concurrency` (maxConcurrentVerifications),
`research-orchestrator` (research runs), `experiment-executor`
(maxConcurrentExperiments), `step-session-executor` (parallel steps) —
plus `ProjectAdmissionCoordinator`, which is FN-8453 oldest-first
**ordering**, not a limiter. The real remaining win there is the
pre-held-slot bookkeeping and the idle-semaphore leak recovery, which
existed to service the global instance; I will measure that as its own
slice rather than quote a fraction.

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

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Updated plan admission throttling to consistently use the project’s
running-agent capacity.
* Improved throttle audit events by reporting stable capacity details
and removing obsolete semaphore information.
* Preserved accurate deduplication for repeated throttling events,
including changes in stalled tasks.

* **Documentation**
* Updated run-audit guidance to match the revised throttling event
format.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:31:27 -07:00
gsxdsm
8393bba7dc U7: the replan rebound targets a column the workflow declares (R7) — re-landed on main (#2598) 
> Based on `main`, no dependencies. Re-landed after closing the stacked
chain (#2517, and #2551 below) that never reached main.

## What main already has, and what it lacks

Main independently converted the planner-lane **parameters** in this
file — and **better than I had**: it splits `plannerColumn` from
`roles.mergedPlanningColumn`, because a merged lane joins the FN-8596
arrival-order rescue but *not* the "planner column is never advanced"
shortcut. That work is main's and untouched here.

What main still lacks is the **R7 fix**: `resolveReplanTargetColumn`
returns `"triage"` **by fiat** for any workflow declaring neither legacy
id — `builtin:marketing` (ideation/backlog/drafting/…) and every fully
renamed set. A Plan Review REVISE therefore moves the card into a column
its workflow **does not declare**, for `reconcileUndeclaredTaskColumns`
to clean up after. A move the engine makes on purpose, not drift.

| Workflow | Target | Changed? |
|---|---|---|
| `builtin:coding` / stepwise | `todo` | no |
| Coding (Ideas) | `todo` | no |
| `builtin:marketing` | `backlog` (its own hold) | **yes** — was
`triage`, undeclared |
| declares no planning lane | `undefined` → park | **yes** — was
`triage` by fiat |

## The ordering the existing suite taught me

Legacy ids stay preferred **first**, and the trait resolution prefers
**hold over intake**. That is not arbitrary:

Coding (Ideas) declares `ideas` as its intake, and `ideas` is **manual
capture with no AI** (plan R10) — a rejected plan sent there stops being
replanned at all. The old code got Ideas right **by accident**: it never
recognised `ideas` as intake and fell through to `todo`. An "intake
first" trait rule would have shipped that regression dressed as a
cleanup, and three existing Ideas tests were the only thing between me
and doing it.

## An inverted comment, corrected

The function's own U11 note read: *"the second lookup asks for `todo`,
which U11 deletes… the first lookup still matches `triage` (which U11
keeps)"*.

**That is backwards.** #2515 keeps `todo` and deletes `triage`, so the
consequence is the opposite of what was written — the `todo` branch is
what saves builtin coding. Fixed rather than left, because a comment
that inverts a merge's direction sends the next reader to the wrong
branch.

## Fail-closed callers

`undefined` means "nowhere to replan" (plan U5: *skipped with a log
rather than moved arbitrarily*). All four call sites park **visibly**
rather than log a move they did not make. The scheduler's rebound still
writes `needs-replan` — deliberately, since that is what blocks dispatch
and the branch has already decided the card must not be released — with
only the *log* made conditional.

## The superseded test is deleted, not skipped

A skipped test is a guard that cannot fire. Its replacement asserts the
new contract **and** the R7 invariant directly — *"a column this
workflow declares"*, not just an id — plus a new case for a workflow
with no planning lane at all.

## Verification

| Check | Result |
|---|---|
| replan-target | 41/41 |
| with scheduler-trait-dispatch + pre-release-plan-review | 55/55 |
| `tsc --noEmit` (engine) | clean |
| `pnpm lint` | clean |
| `pnpm test:gate` | green (482 + 10 + 71) |
| `pnpm check:changesets` | clean |

`triage.test.ts` still shows main's **8 pre-existing #2515 failures** —
unchanged by this, fixed by **#2576**.

## Closing #2551

Its parameter work is superseded by main's better version; this PR
carries the only part main lacked. Same story as #2517: a stacked PR
outlived the surface it was converting.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:31:03 -07:00
gsxdsm
cf6133da8b consolidate/e2e — E2E evidence: already-finalized terminal roles (real merge entry, no git) + ledger corrections (#2648) 
Consolidation branch for the E2E-evidence worker. Two commits, both
engine test/comment only — **no production code, census unchanged**.

## Census (the authoritative instrument)

`node scripts/lifecycle-column-census.mjs` on this branch: **triage 10,
total 784** — identical to its base.
`lifecycle-column-census-ast.test.ts` and
`lifecycle-column-census.test.ts` pass (15). This PR neither shrinks nor
grows the backlog; it is evidence.

## What it contains, file by file

| file | change |
|---|---|
|
`packages/engine/src/__tests__/workflow-already-finalized-live-e2e.pg.test.ts`
| **new** — 3 cases, live PG store + real `runAiMerge` |
| `packages/engine/src/__tests__/workflow-lifecycle-live-e2e.pg.test.ts`
| comment only — retires two unproven-ledger entries |

## The evidence: `isAlreadyFinalizedColumn` never needed the real-git
lane

My unproven-sites ledger listed it as requiring a git harness because it
is module-private inside `runAiMerge`. Reading the function instead of
costing the lane: `runAiMerge` reaches it after only `store.getTask`, a
pure workspace assert, and a pure branch resolve — **before** the merge
blocker, settings, and any branch sync. `projectRootDir` is never
touched on that path, and the short-circuit returns a `noOp` rather than
throwing. Reachable through the real public entry point with no
repository at all.

### Why two cases and not one

The guard resolves terminal columns **per role**:

```ts
terminal = [lifecycle.complete ?? "done", lifecycle.archived ?? "archived"]
```

#2471's P1 caught the first cut replacing the whole legacy **pair** as
soon as *any* terminal role resolved — a workflow declaring `complete`
but no `archived` collapsed to one element, silently lost the archived
short-circuit, and an archived card then threw *"must be in
'in-review'"* for a card whose real state was "already done, nothing to
do".

A per-set rule passes for whichever role **is** declared and fails the
other, so a single case cannot tell the two rules apart. The shared
fixture declares `complete` (renamed `shipped`) and **no** `archived`,
so it is exactly that partially-declared shape — resolved half and
fallback half live on one board.

Mutation-verified, each killing only its own case:

| mutation | kills |
|---|---|
| per-**set** replacement (the #2471 defect) | the legacy-`archived`
fallback case |
| legacy pair only (conversion reverted) | the renamed-`shipped` case |

Plus a differential: a renamed **review** card must not report
already-finalized. Without it both cases above would pass for a guard
that finalizes everything — turning every merge into a silent no-op, the
worst failure this function has.

Evidence strength is stated in the file header rather than overclaimed:
this reads a returned **decision**, not a persisted row, so it proves
the renamed board resolves and short-circuits — not that a card moves.

## Ledger corrections (comment only)

Two entries retired, both wrong the same way — each stated a **lane
cost** as if it were an impossibility:

- `columnIsIntakeOrHold` — "consumers are dashboard-side" is true and
irrelevant; its one consumer is an exported pure function. Proven on
merged and renamed boards by work already merged in #2631.
- `register-task-workflow-routes.ts` — "standing up the route shell is
mock-the-world" was false; `createApiRoutes` + `test-request.js` is this
repo's established convention with ten existing suites for that file.
Covered by its owner in #2614.

Counting this PR's own subject, that is **seven** wrong lane-cost
inferences in that ledger. The rule it keeps violating is unchanged and
now recorded in the file: read what the FUNCTION touches before costing
a lane for it.

## Verification

`pnpm test:gate` exit 0 (695), `pnpm lint` exit 0, engine typecheck
clean, 28 tests green across the AST ratchet and the three
merged-board/planner-lane/already-finalized families.

## Not in scope here

The `performWorkflowRerunBounce` E2E. The harness exists (`new
TaskExecutor(store, "/tmp/test", {})`), but `executor.ts:4305` gates the
rebound on the legacy `in-progress`/`in-review` pair while resolving its
target by role — so on a renamed board the bounce never fires and the
resolved target is unreachable. An E2E asserting today's behaviour would
cement that. It is executor.ts's owner's fix; evidence should follow it.
Detail in #2632's thread.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:27:30 -07:00
gsxdsm
20878e9d5f census: count column: "<legacy>" query filters as a separate, separately-pinned instrument (backlog unchanged at 784) (#2650) 
Pre-launch input for the 779-guard fleet. **The backlog number does not
move: 784 before, 784 after.** This adds a second number beside it.

## The problem it measures

A guard is not the only way a legacy column id decides behaviour:

```ts
const todo = await this.store.listTasks({ column: "todo", slim: true });
```

That is a **source query** — it selects the rows a sweep considers *at
all*. On a renamed or merged board it returns nothing, so a sweep whose
per-task predicate was correctly converted still does nothing, while
looking converted. `self-healing.ts:2849` names the pairing in prose,
and #2560 had to repair exactly that combination after a converted
predicate was left with a literal query.

The census walks comparison `BinaryExpression`s. A `PropertyAssignment`
is not one, so this class was invisible to the instrument **and to its
ratchet** — it could grow silently.

Measured: **83 query filters, 43 IR node definitions.**

I proved one live consequence earlier on #2648:
`recoverStuckMergeDeadlocks` cannot see a renamed board at all — the
renamed rows exist and none appear in its three-literal union
(`renamedInsideUnion=0`, on a live PG store).

## Why this matters *before* the fleet is briefed

The fleet rule is *"the baseline ratchet must shrink by exactly the
converted count."* In `self-healing.ts` — the largest batch at 111 —
both classes sit in the same functions, so today a worker either:

- converts only the comparisons → arithmetic is clean, and sweeps whose
source query still filters a dead literal stay blind; or
- converts the query too → the count does **not** move by the converted
amount, and a more-correct PR looks like a miscount.

The second punishes the better worker. With a second pinned number,
converting a query becomes visible work instead of an apparent error.

## Counted separately, deliberately

`totals.column` is a published shape — the baseline, the reporter, and
other workers' in-flight PRs read it, and the completion bar is defined
against it. Growing it would move a number the program is actively
driving to zero.

So the new counts live in `summary.properties` / `queryByFile`, under
their own baseline keys, with their own both-directions ratchet (same
rule as #2633's, including the stale-allowance half). `totals` keeps its
**exact** shape — two existing tests assert it with `toEqual`, and
breaking a contract others depend on mid-flight to add a number is not
worth it.

## Definitions are not queries

Workflow IR graph nodes carry `column:` to declare where a node lives —
`{ id: "review", kind: "...", column: "in-review" }`. That is the
lineage describing itself: not a lookup, not convertible, and ~43 of the
raw matches. They are told apart **structurally** (an `id`/`kind`
sibling in the same object literal), not by filename, so a definition
written anywhere classifies the same way.

## Baseline seeding, stated plainly

`--update-baseline` could not pin a **new** category: the regression
check runs before the write, and with no prior key every file reads as a
rise. I seeded the three new keys once, directly, leaving every guard
field byte-identical. The diff is purely additive — no removals.

## Finding, not caused by this change

**`--strict` is already red on clean main**:
`register-task-workflow-routes.ts` is **23** against a baseline of
**22**. Verified by stashing this branch and re-running on an unmodified
tree. Until that is reconciled the guard ratchet is passing nothing —
worth fixing before the fleet starts relying on it as the work order.

## Verification

- census suites **44 green**, 6 new cases: counted; kept out of the
backlog; definition-not-query; both instruments independent (a bug
routing comparisons into the query bucket would otherwise look clean on
both); `DELIBERATE-LITERAL` honoured; non-legacy id ignored
- `node scripts/lifecycle-column-census.mjs` → backlog still 784
- `pnpm lint` exit 0, `pnpm test:gate` exit 0 (695)

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:27:18 -07:00
gsxdsm
2771408bba ci: enforce the lifecycle-column ratchet — it has never actually run (#2654) 
**The ratchet was advisory.** `scripts/lifecycle-column-census.mjs`
existed only as `pnpm census:lifecycle-columns` — without `--strict` —
and **no workflow invoked it**. Nothing has ever compared the tree to
the baseline. Every "the baseline ratchet holds them" assumption in this
program rested on a check that does not run.

That explains both classes of hole:

**1. Three PRs lowered counts without re-recording,** leaving allowances
the deleted guards could return through while every check stayed green.
I've tightened them across #2593 and earlier PRs, but nothing stops the
next one.

**2. #2621 GREW the count while its own title claimed "count 0 → 0".**
It added `column === "triage"` and `column === "todo"` at
`register-task-workflow-routes.ts:2681`, taking that file to **23
against an allowance of 22**. It landed unchallenged. This is the
failure mode the ratchet exists to prevent, and it happened *inside this
program*, in a PR that asserted the opposite.

## The change

Adds `check:lifecycle-columns` (the census with `--strict`) to the
`pr-checks.yml` lint job, next to `check:changesets` and
`check:routes-modular` — the established pattern. **~1.8s over ~1950
files**, so this is not a slow-test addition.

## Proven to fail, in both directions

A guard that reports success without checking anything is worse than no
guard, so:

| injected defect | result |
|---|---|
| `const __probe = (c: string) => c === "triage"` added to `moves.ts` |
`count ROSE — moves.ts: 39 -> 40`, exit 1 |
| run against main's current baseline | exit 1 on
`mission-feature-sync.ts: allows 5, tree has 0` |

Both reverted; exit 0 restored. Note the second row: **this check is RED
on main right now**, which is the point.

## Merge order

**Stacked on #2593**, which carries the `DELIBERATE-LITERAL` marker for
the #2621 site (a v1 IR declares no roles, so no trait can answer that
question) plus the baseline re-record. Standalone on main this PR is red
— correctly. **Merge #2593 first**, then this.

I stacked rather than duplicating those two edits because I already
caused one conflict today by appending related content from two
branches, and #2651 merged a correction ahead of the section it
corrected. Same-content edits in two PRs is the same mistake.

## Census

Unchanged by this PR: **776 total, triage 5, reviewed 16** — it adds no
guards and converts none. It only makes the numbers enforceable.

## For the fleet

This should land before the 776-guard fleet launches. The brief says
"the baseline ratchet must shrink by exactly the converted count" —
until now nothing verified that claim, so a batch worker could report a
shrink that did not happen, or grow the count while converting, and CI
would agree.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:20:31 -07:00
gsxdsm
642a4fa264 consolidate/u12 — U12 consolidation: 4 live defects, the AST ratchet fail-closed, and the moves.ts flag scoped (#2647) 
One branch, one PR, per the consolidation directive. Contents
file-by-file below.

**Supersedes #2625** (its overlapping conversions landed via U11's
#2624/#2626/#2636; only the parts nobody else did are folded here).
**#2630 and #2639 stay open** — both green with zero threads, per rule
3.

## Four live defects, each measured

**1. Every planning card renders an actions menu.**
`TaskContextMenu.tsx` still had `shouldShowActionsMenu: task.column !==
"triage"` on main *after* the rest of that file was converted. Since
#2515 removed the id, the condition is TRUE for every card, so the
suppression stopped applying anywhere — including on cards whose menu is
empty, the orphaned click target the Surface Enumeration rule exists to
catch.

Found **twice independently**: by reading the guard, and again by the
invariance test below, which failed on main with `shouldShowActionsMenu`
true on one lineage and false on another. That is the argument for an
invariance property over per-site conversion — the file had already been
converted "2 → 1" and the survivor was the live one.

**2. Worktree upcoming-work list empty on renamed boards.**
`groupByWorktree` filtered `t.column === "todo"`. On the default board
the id and the role coincide so every existing test passed; renamed, it
matched nothing and a whole panel read as idle.

**3. Hold-lane FIFO ordering lost on renamed boards.**
`sortTasksForDisplayColumn` gated priority-then-FIFO on `column ===
"todo"`, degrading to the generic id-ordered sort elsewhere. Cards
simply appear in the wrong order, silently.

**4. The AST ratchet still failed open** — fourth time in that file,
third found by review. `receiverName` understood only one-level property
access and bare identifiers, so `task["column"]`, `metadataColumn(entry,
"to")`, ternaries, `(task!.column)` and backtick literals were dropped.
**Measured on main: `in-progress` 196 → 197, `in-review` 211 → 213** —
three real guards nobody counted, including `metadataColumn(entry, "to")
=== "in-review"` in `reliability-metrics.ts`. Now walks wrappers,
resolves calls to the callee name, and emits a `<SyntaxKind>`
**sentinel** for anything unnameable: counted *and* trips the
classification guard, so a human judges it instead of it vanishing.

## Per-file guard counts

| file | before | after |
|---|---:|---:|
| `app/components/TaskContextMenu.tsx` | 1 | **0** |
| `app/utils/worktreeGrouping.ts` | 1 | **0** |
| `app/components/taskSorting.ts` | 1 | **0** |

The other dashboard files I had converted reached 0 via U11's PRs; where
our work overlapped I took theirs during the rebase, including two
places where theirs was **stronger** than mine — they deleted Column's
unreachable quick-create arm outright (with fixtures migrated) where I
had converted it, and they verified the same `isPreExecutionHoldColumn`
degraded-set asymmetry I did, independently.

## Flip precondition: the moves.ts flag is scoped, not flipped

`move-target-declared-census.test.ts` answers precondition 2 with
measurement. 41 engine `moveTask` calls have literal targets — `todo`
27, `in-progress` 7, `done` 6, `archived` 1 — and **all four are
declared by the default lineage**, so the default board is not the
exposure. `triage` appears only in a comment noting `replan-target.ts`
used to hardcode it. My own grep had said `todo=29`; the AST says 27,
because grep counts comments.

The exposure is **custom** lineages: 20 of the 41 carry no
`recoveryRehome` and would reject with unknown-column post-flip; 21 are
exempt via the #1411 carve-out, which makes that carve-out load-bearing.

I did not flip the flag. It is six seams, not the `789`/`837` pair every
summary including mine described, and seam 2 turns on *new refusals*
rather than swapping equivalent implementations — a green suite says
nothing about that. #2639 pins the blast radius.

## Tests

- `column-role-id-invariance.test.tsx` — hold traits fixed, vary only
the column id across MERGED / LEGACY / RENAMED; every decision must
agree. Drives the real consumers, so a component keeping an inline
comparison fails it. Includes a unanimous-and-**false** case so it can't
be satisfied by a predicate hardwired to true. **This is the test that
caught defect 1 on main.**
- `worktreeGrouping.test.ts` — includes two cards both in a column named
`staging`, one hold and one not, asserting opposite answers. That
assertion is impossible under a board-wide column-id set, which is why
hold resolution is keyed per task via `getEffectiveTaskWorkflowId`
(#2625 review).
- `taskSorting.test.ts` — discriminates on the **tiebreak**, not
priority: both branches sort by priority, so my first version passed for
the wrong reason. Equal-priority cards whose `createdAt` order disagrees
with their id order.
- `no-hardcoded-lifecycle-columns.test.ts` — 16 detector cases: 11
shapes counted, 4 legitimate ignored, one asserting the sentinel path.

Revert checks, all run: menu suppression → diff names the field;
worktree → `expected [] to include 'FN-50'`; sort → `FN-2, FN-9` instead
of `FN-9, FN-2`; ratchet → the 3 recovered guards disappear.

## One site that should never be converted

`MissionControlPanel.tsx:46` — `{ id: "triage", match: (c) => c ===
"triage" || c === "signal" || c === "backlog" }` is a deliberate
name-similarity heuristic for the SDLC funnel; it matches synonyms and
folds unknown columns into an "other" bucket so custom columns still
contribute. Converting it changes what the funnel displays. Like the
`live-agent-count` fallbacks, it belongs in a documented floor — **the
ratchet's target is that floor, not zero.**

`DocumentsView.tsx:73` is convertible but the file has no column flags
at all, so a real fix means plumbing board-workflow metadata into a view
that doesn't fetch it — its own unit of work.

## Verification

`pnpm lint` clean. `pnpm test:gate` green (10 / 482 / 71). `tsc -p
packages/dashboard/tsconfig.app.json` and `packages/core/tsconfig.json`
clean. Core ratchet + seam suites 24/24. Dashboard target suites 37/38 —
the one failure is the pre-existing `"Back to In Progress"` label
casing, confirmed identical on the base.

---

## Added after the initial push

**5. `TaskCard` lost inline editing on renamed boards; `TaskDetailModal`
kept it.** Still live on main: the modal resolved field editability from
traits in U10/R8, the card used a hardcoded `{triage, todo}` set with
**no trait path at all** — even though `taskColumnFlags` was already in
scope. On a renamed board the title was editable in the modal and the
pencil was missing from the card. Body moved unchanged into
`isFieldEditableColumnRole` so the two surfaces cannot drift again.

The veto traits are the substance: a column can legally carry `hold`
**and** a WIP or review trait, and a plain `intake || hold` check would
let an operator rewrite a description while a session executes against
it.

Coverage gap **measured, not assumed**: mutating `canEdit` back to the
hardcoded set left `TaskCard*` at the same failure count as the
unmutated run — nothing caught it. The four render cases assert the real
`aria-label`; that mutation now fails with `Unable to find an accessible
element ... name 'Edit task'`.

**6. The ratchet's target is a documented FLOOR, not zero** — and this
changes the completion bar.

Zero is not reachable, and chasing it means breaking working code. Two
categories are permanent, now protected as positive assertions so a
future sweep cannot "finish the job" by deleting them:

- `MissionControlPanel.tsx`'s `FUNNEL_STAGES` is a deliberate
**name-similarity** heuristic — it matches `signal`, `backlog`, `to-do`,
`ready`, `shipped` and folds unrecognised columns into an "other" bucket
so a custom board still contributes counts. It is not asking whether a
column has the intake trait; it buckets arbitrary column *names* for
display. Asserted on the **synonym list**, because the synonyms are what
prove it is name matching — if they disappear the site has changed
character and the exemption stops applying.
- `live-agent-count.ts`'s no-flags arm is reachable (a remote store is
deliberately given an empty flag map; a card in an undeclared column has
no flags at all) and deleting the literal makes such a card match **no**
arm, so the queued total silently under-reports a stranded card.

A count with an undocumented floor invites someone to drive it to zero.

**Not done, and why:** `DocumentsView.tsx:73` is convertible but that
file has no column flags anywhere, so a real fix means plumbing
board-workflow metadata into a view that does not fetch it — its own
unit of work, not something to smuggle into a conversion.

**Re-verified after these commits:** `pnpm lint` clean, `pnpm test:gate`
green (10 / 482 / 71), `tsc` clean on core and `tsconfig.app.json`, core
ratchet suite 26/26, `columnRoles` 10/10, `TaskCard.test.tsx` 384/386
(the 2 are pre-existing CSS assertions). `TaskDetail*` is 130 failed /
551 passed **both with and without** this change — verified by stashing,
so pre-existing and unrelated.

---

## Flag resolution: preconditions 1 and 2 are now DISCHARGED.
Precondition 3 is blocked, and by evidence.

**Precondition 1 — the side-effect equivalence proof — done.**
`moves-flag-equivalence.test.ts` runs the same journey under both flag
states against live PG and diffs the persisted row. **Result:
identical** — whole-row equality across 128 fields plus an equal timing
shape, over `todo → in-progress → in-review → todo → in-progress`.

That test was **wrong twice** before it meant anything, and both times
it was passing:

1. **It proved nothing.** `experimentalFeatures` is **global-only**, and
`moves.ts` reads `getSettingsFast()`, which filters global-only keys out
of the project layer. My `updateSettings` write was silently discarded,
`useWorkflow` was false in *both* runs, and the "proof" compared the
legacy path against itself. Found by stamping the flag-ON branch and
observing the test still passed. Now written via `updateGlobalSettings`,
and the helper **asserts the flag took effect** before the journey runs.
2. **The journey was forward-only**, so it never reached the reopen
hook's field resets (`status`, `error`, `blockedBy`, pause clearing) — a
mutation there passed. Extended with a backward move and a re-entry.

Mutation-verified after both fixes: stamping seam 3, and diverging the
reopen hook, each fail the comparison.

**Precondition 2 — done, and its answer is a blocker.** The census says
the default board is safe: all 41 literal engine move targets are
declared by the default lineage. But **20 of those 41 carry no
`recoveryRehome`**, so on a custom lineage that does not declare `todo`
/ `in-progress` / `done`, seam 2 would start rejecting them with
unknown-column. That is a user-facing break on custom boards, not a
theoretical one, and it is not fixed by the equivalence proof — seam 2
adds *new refusals* rather than swapping implementations.

**So the flip is one step away, and the step is not mine to take
alone:** those 20 call sites need to resolve their target from the
task's workflow (or justify `recoveryRehome`), and they live across
engine lanes in `moves.ts` caller territory — U2b/MAIN. Flipping before
that trades a dormant flag for broken custom boards.

What remains for precondition 3 once those land: flip both readers
**atomically** (`moves.ts` + `workflow-task-create-ops.ts`, since the
latter computes the preflight the former consumes), delete the flag-OFF
branch with its guards, and drop the settings key.

---

## CORRECTION: seam 2 is not a blocker. My earlier claim was wrong.

I stated in #2639 and above that "with the flag off there is **no**
target-column validation on the move path", so flipping would introduce
new refusals. **That is not what happens.** Reproduced against live PG:
the identical custom-lineage move rejects with the flag **OFF** as well
—

```
Error: Invalid transition: 'backlog' -> 'todo'. Valid targets: building
```

Transition validation is already in force on the flag-OFF path. So for
the shape in question — an engine move to a column the task's own
workflow does not declare — **the move already fails today**, and seam 2
introduces no new break for it. The 20 census sites lacking
`recoveryRehome` are broken on a custom lineage *now*, not broken by the
flip.

I found this because the discriminator I added to prove "the flag is the
cause" failed. Had I written the test to my assumption it would have
passed and the false claim would have shipped — the same way the
equivalence test passed while proving nothing until I tried to make it
fail.

**Revised precondition status:**

| precondition | status |
|---|---|
| 1 — side-effect equivalence | **discharged** — identical rows,
mutation-verified both directions |
| 2 — seam-2 exposure census | **discharged, and it is not a blocker** —
the rejection predates the flag |
| 3 — flip both readers atomically, delete the flag-OFF branch, drop the
settings key | **the remaining work** |

So the flip is no longer gated on fixing 20 engine call sites. What it
is still gated on is precondition 3 being done atomically across
`moves.ts` and `workflow-task-create-ops.ts` (the latter computes the
preflight the former consumes), which is `moves.ts` caller territory.

Three cases now cover seam 2: the flag-ON rejection, the flag-OFF
rejection (asserting the error *message*, so a change in which guard
rejects stays visible rather than reading as agreement), and the #1411
`recoveryRehome` carve-out succeeding — pinning why that carve-out is
load-bearing and must not be tidied away.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-30 00:13:58 -07:00
gsxdsm
f5cc416ae4 U7 item 3: the replan no-match fallback named a column no lineage declares (#2659) 
**Item 3 from the closing bar.** Behaviour change, own commit.

## The defect

`resolveReplanTargetColumn` fell back to the literal `"triage"` when a
workflow declared neither legacy planner id. That names a column the
workflow doesn't declare — and since #2515 the **default lineage doesn't
declare it either**, so the fallback pointed at a column that exists
nowhere. The replan move then either failed outright or put the card
somewhere no sweep owns.

Resolved through `resolveReboundTarget` (KTD-10: hold → intake → first
declared) — the same helper every other rebound path uses, so replan
lanes and rebound lanes stay consistent instead of drifting.

## The catch path keeps its literal, deliberately

It's reached only when resolution **throws** — not when it silently
falls back to the default IR, which returns a real workflow and takes
the `todo` branch above. With no IR there's nothing to resolve, and
swapping one arbitrary literal for another changes behaviour without
evidence about the workflow. Documented at the site so the asymmetry
reads as a decision, not an oversight.

## Test

Written first and observed **red**. It asserts the target is a column
the workflow actually declares:

```ts
expect(workflowHasColumn(ir, target)).toBe(true);
```

rather than pinning a specific id — so it can't pass by naming a
*different* wrong column, which is how the previous version of this test
stayed green while the fallback was broken.

**Mutation-verified:** restoring the literal fails it.

## Verification

40 replan-target tests green, engine tsc clean, lint clean, merge gate
green (487 + 132 + 10).

No changeset: `@fusion/engine` is private.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-07-30 00:13:39 -07:00
gsxdsm
be63e72f10 U11 [E2E evidence]: live-PG proof for the stranded-column rescue and the planner-lane asymmetry (8 tests, test-only) (#2629) 
**Completion bar #3 for my phases.** Test-only, no production changes,
no guard-count movement — the two live-PG E2E suites I held during the
freeze.

## Why these exist

Every U11 slice I shipped closed with the same caveat: *all evidence is
unit-level*. Three claims in particular were argued from reading code,
and each is the kind a mock would happily confirm:

1. #2515 left `triage` a legal id but removed it from the default
lineage.
2. #2603 — `createTask` resolves the workflow's intake column, and an
explicit `column` **overrides** it. Nine write sites were removed on
that reasoning.
3. #2591 — a card stranded on a legacy planner id is admitted by
planning discovery, which is what lets it heal with no data migration.

Both suites drive a **real PostgreSQL TaskStore** (per-file throwaway
database) and the **real shipped workflows**, not fixture IRs. Claim 3
goes through the real `discoverReadyPlanningTasks` — the method the poll
calls. Every assertion is on **observed persisted state** (fresh
`getTask` after clearing the task cache), the rule inherited from
`workflow-lifecycle-live-e2e.pg.test.ts`, because "a function was
called" is exactly what has passed falsely on this program before.

## Two things the E2E found that unit tests did not

**The shared fixture's "merged" shape was not #2515's.** Omitting
`separateIntake` leaves the hold column with *no* intake trait, so the
resolver reports `undefined` — "I have no intake to name" — whereas the
shipped merged lineage carries intake **and** hold on one column and
reports `[]` — "intake exists and *is* the hold column". Callers treat
those differently: `undefined` keeps their legacy default, `[]`
positively asserts no dedicated planner lane. Assuming the plain shape
was the merged shape is how a test appears to cover #2515 while covering
something else. Added an opt-in `mergedIntake` to model the real thing;
the third shape is now asserted explicitly.

**`insertWorkflowDefinitionSync` throws in backend mode** — it's the
SQLite path. The suites use `createWorkflowDefinition` +
`writeTaskWorkflowSelection` like the other live E2Es, including binding
to the id the *store* allocated rather than the one passed in, which the
lifecycle suite documents as a way a renamed-workflow fixture silently
resolves to the default IR.

## Fixture changes are opt-in

Both new options follow the existing `mergeOrchestration` precedent:
seven suites build on this builder and a shared fixture must not
silently change an existing suite's subject.

## Naming

`workflow-planner-lane-**resolution**-live-e2e` deliberately, to stay
distinguishable from #2611's `workflow-planning-lane-live-e2e`.
Different subjects — that one drives the real hold-release sweep, this
one drives the resolvers the lane guards consume. Near-identical names
would invite someone to delete one as a duplicate.

## Verification

- 8 new tests green against a real PG store
- **Mutation-verified:** disabling the #2591 rescue in
`discoverReadyPlanningTasks` fails claim 3, and only claim 3
- Merge gate green (482 + 132 + 10), engine tsc clean, lint clean

**Pre-existing failures, not from this PR:** the full live-E2E sweep is
82 tests / 2 failed, both in `workflow-lifecycle-live-e2e.pg.test.ts`.
Verified by swapping main's `_workflow-vocabulary-fixture.ts` in and
re-running: 2 failed either way, identical. They are main's, and they
appeared since my earlier clean run of that suite — worth a look against
bar #2.

## What this does not cover

Neither suite runs a planning **session** — that lane is the AI,
substituted here as `testMode` does in production. So this proves a card
is *admitted* and re-homable, not that a full plan-and-release round
trip happens. The release half is covered by the existing lifecycle E2E.

No changeset: `@fusion/engine` is private and this is test-only.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-07-30 00:07:20 -07:00
gsxdsm
177c2309d9 consolidate/u11: a hold column is a planner lane only if it precedes wip (real defect in merged code) + funnel aliases (triage 11 -> 10) (#2645) 
**Consolidation branch for u11/u7.** Supersedes #2624. Contents changed
substantially while it sat unmerged — this body reflects what is
actually in it now.

## Measured with the authoritative census, not grep

`node scripts/lifecycle-column-census.mjs` — **triage guards 11 → 10.**

## 1. A real defect in merged code: a hold column is only a planner lane
if it precedes implementation

Found by greptile on #2616, verified by me, fixed here at the source
because that PR cannot land.

`resolveLifecycleColumns` returns `hold` as the **first** hold-trait
column in declared order, with no positional constraint relative to wip
(`workflow-lifecycle-traits.ts`: `hold:
first(LIFECYCLE_ROLE_FLAGS.hold)`). A workflow using a hold trait for a
**mid-pipeline wait** — a pause after implementation starts — therefore
had that column returned as its planner lane, and
`reconcileMissionFeatureState` demoted the feature to `triaged`. The
mission board reported started work as not-yet-started: silent, and
wrong in the direction that makes a roadmap lie.

This is my defect, introduced in #2610.

**Why it survived:** every lineage anyone has tested puts the hold *in
front* of wip, so the default and Ideas boards are unaffected and no
existing test could see it.

**The fix is positional, with a deliberate asymmetry.** A hold column
counts only when it appears before wip in declared order. When wip
cannot be located the hold is left **out** rather than guessed —
including it wrongly demotes live work on the roadmap, while excluding
it wrongly costs only a `triaged` transition the next reconcile
re-applies.

Mutation-verified: dropping the positional test fails the mid-pipeline
case and nothing else.

## 2. MissionControlPanel funnel aliases

Assessed and **deliberately not trait-converted**. These are heuristic
*name aliases* for a canonical SDLC stage — the matcher already accepts
`signal`/`backlog`/`ready`/`shipped` because it buckets arbitrary
boards, with an `other` fallback. Post-#2515 a default board's planning
cards sit in `todo` and count at the Todo stage, leaving Planning at
zero: the funnel reporting where cards *are*, not a guard that stopped
firing. Hoisted to a named set so it stops reading as unconverted.

This is the **DISPLAY-ALIAS** class the census still lacks — receiver
*is* a column id, purpose is presentation rather than a lifecycle
decision. `DocumentsView`'s status dot is the other one. Without that
bucket a ratchet will keep demanding conversions that make the product
worse.

## What I dropped, because main's version was better

The original #2624 carried a `TaskContextMenu` conversion. #2626 landed
`isPureIntakeColumn` — intake **without** hold — while mine treated any
intake-flagged column as intake. That's wrong for a **merged Planning
column**: it carries both traits, cards there wait for capacity and have
real actions, so I would have suppressed the menu where it belongs — a
new regression in place of the one I was fixing. Theirs is correct. Mine
is gone, along with its now-invalid test and a helper nothing else used.

## Verification

- merge gate green (482 + 132 + 10), engine tsc clean, dashboard tsc
clean, lint clean
- 7 planner-lane tests green, mutation-verified

No changeset: `@fusion/engine` and `@fusion/dashboard` are private.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-07-30 00:00:46 -07:00
gsxdsm
3e8f604848 test(engine): census the UNCONVERTED lifecycle surface — 417 legacy column literals, ratcheted (#2557) 
Test-only, no production change. Independent of my other open PRs.

## The number nobody was counting

This program has two censuses, and **both count converted things**: the
unproven-sites ledger (callers of the lifecycle-role resolvers) and
`raw-workflow-columns-flag-census` (reads of the `workflowColumns`
flag).

Neither counts what is still keyed to a legacy column id — **which is
where every defect this program has found actually lived**:

| defect | the literal |
|---|---|
| pool-id sentinel (capacity gate never bound) | `?? "builtin:coding"`
vs the counter's sentinel |
| agent-link leak (slot consumed forever) | terminal column matched
against a fixed id set |
| stale-paused badge silent on renamed boards | `task.column !== "todo"`
|
| merge chokepoint threw on a finished card | the `done`/`archived` pair
|
| recovered card stranded harder | `?? "todo"` |

Every one was found **by hand, one at a time, by whoever happened to
look.**

## Measured

**438 lifecycle decisions keyed to a legacy column name** (417
comparisons + 31 `??` column fallbacks, minus 8 agent-id false positives
and 2 lines carrying both shapes), across 85+ production files — 94 in
`self-healing.ts`, 70 in `executor.ts`, 26 in the dashboard
task-workflow routes.

That is the real size of the remaining surface. It dwarfs the 15-site
resolver census I've spent this unit closing, which is worth knowing
before anyone calls the vocabulary work finished.

## A hit is not a bug

Many are correct — documented legacy fallbacks, the legacy-adoption
path, code genuinely about the built-in workflow. The census claims only
that each site decides by **name** rather than by **role**, and
therefore needs a human judgment. Reporting 417 as a bug count would be
exactly the overclaiming this program keeps correcting.

## A ceiling, not an equality — deliberate

The sibling flag census fails in both directions. That number moves only
when two units touch it. **This** one moves whenever any of a dozen
concurrent conversion slices lands, and an exact-equality assertion
would go red on work heading the *right* way.

A test that's red for good reasons gets suppressed, and a suppressed
ratchet is worse than none — the failure mode AGENTS.md's quarantine
rule exists to prevent. So the count may fall freely and may never rise;
when it falls, the failure message says to lower the pin.

## Verified in both directions

- green at 417
- adding **one** literal to `replan-target.ts` → `census ROSE to 418
(ceiling 417)`
- the regex is unit-tested to count a **decision**, not a mention: a
column id in a fixture, a log line, or a `moveTask` argument is not
counted — inflating the number into noise is how a census stops being
acted on
- unreadable sources **fail closed** rather than silently shrinking the
count


## Follow-up (a8c150b12): the census was blind to three of the five
defects it cites

I ran the census against its own header. It lists five motivating
defects; the comparison-only regex counted **two**. The pool-id
sentinel, the rebound strand and the terminal fallback are all `??`
**defaults** — invisible to a `.column === "x"` pattern.

A census that cannot see three of the five bugs it names as its reason
to exist is worse than none: it reports a number that *feels* like
coverage. That is precisely the overclaim this unit keeps catching in
other people's work — caught here in mine, and only because the header
wrote the examples down somewhere they could be tested against.

It now counts two shapes — deciding **by** a name (`===`/`!==`) and
**defaulting** to one (`??`) — and pins the five motivating examples as
a test case, so the pattern cannot narrow back without failing.

**Measured: 417 comparisons + 31 fallbacks, of which 2 lines carry both
shapes → 446 lines.** Ceiling raised 417 → 446 to cover the missing
shape, not to excuse new debt.

`?? "builtin:coding"` stays deliberately uncounted: it defaults a
*workflow* id rather than a column and is legitimately correct at most
sites. It already has a stronger guard —
`scripts/check-capacity-pool-id.mjs` bans it only where the value
reaches a capacity counter, which is the only place it's wrong.

Verified both directions: green at 446; adding one fallback of the
newly-counted shape → `census ROSE to 447 (ceiling 446)`.


## Follow-up 2 (98f4264fd): 8 false positives removed — 446 → 438

Then I checked the census against real source instead of trusting the
pattern. Its top-scoring fallback file was `triage.ts` with 8 hits — and
**every one is `agentId: task.assignedAgentId ?? "triage"`**, an *agent*
id, not a column. `"triage"` is both a column id and the synthetic agent
id triage stamps on its audit rows.

Eight of ~34 fallbacks is a quarter of that shape: enough to make the
number **wrong** rather than merely imprecise. A census with known false
positives is one people learn to discount — the same end state as not
having one, which is exactly what its own header warns about.

Excluded, and the exclusion is **pinned as a test case** so it can't
creep back: the three agent-id spellings must match the raw shape *and*
be filtered, while a genuine column fallback that also mentions triage
(`first("intake") ?? "triage"`) must still count.

**Residual imprecision is stated rather than tuned away.** A couple of
counted lines are display defaults (a column rendered in CLI output).
They stay: the census claims each site *needs a human judgment*, and a
display default passes that judgment in seconds. Chasing them costs more
than the precision buys and makes the pattern too clever to trust.
Agent-ids were excluded because they're a quarter of the shape — not
because any false positive is intolerable.

Ceiling 446 → **438**. Verified both directions: green at 438; one new
fallback → `census ROSE to 439`.

## Verification

- census 3/3; engine `tsc --noEmit` clean; `pnpm test:gate` green (414 +
10 + 71)

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 23:54:49 -07:00
gsxdsm
2a4013b723 consolidate/u9 — review+merge lane: E2E evidence, re-greens, and the conversion blocker (#2646) 
**U9's consolidation branch.** Supersedes nothing — #2637 and #2643 are
green with zero threads and left for your sweep per rule 3.

## Contents

| File | Change | Before → After |
|---|---|---|
| `__tests__/executor-step-numbering-zero-based.test.ts` | isolate the
review-handoff `moveTask` call so the assertion is attributable | **1
failed / 3 passed → 4 passed** |
| `__tests__/ce-workflow-step-executor.test.ts` | re-green against the
block-first merge boundary | **3 failed / 48 passed → 51 passed** |
| `__tests__/goal-anchoring-audit.test.ts` | swallow path reports at
debug, not `console.warn` | **1 failed / 6 passed → 7 passed** |

Triage-guard counts: **no change**. My lane has no remaining column
receivers — the rest belong to the capacity/U7/U8/U11/U12 workers, or
are deliberate compat retentions I verified individually
(`spec-staleness.ts` carries its own "U11 proof" block;
`live-agent-count.ts`'s literal fallback is reachable by flag-less
callers).

Commits kept small and separated: signature fix, then attribution fix,
then the boundary re-green, then the debug-channel fix.

**Census reconciliation:** `node scripts/lifecycle-column-census.mjs`
reports **11** triage guards on main, and **none are in the review/merge
lane** — they are the `moves.ts` flag-OFF branch plus the dashboard
cluster. Nothing in this branch moves that number, and I am not chasing
the 779 non-triage guards per your instruction.

## 1. The review-handoff assertion (and a lesson)

The handoff gained a third argument (workflow move provenance), so a
two-arg `toHaveBeenCalledWith` failed on the extra options object while
the card moved correctly.

My first fix used `expect.anything()` — and I *documented in the
comment* that six mutations couldn't make it fail, then shipped it
anyway. Greptile (P2) correctly called that out: this flow records two
`moveTask` calls, so the assertion is satisfied by the boundary move
even if the handoff regresses. **Documenting a weakness is not removing
it.**

Now the test selects the handoff call by its own marker
(`workflowMoveMetadata.reason === "workflow-review-handoff"`), asserts
exactly one such call, and asserts its target column:

| Mutation | Before | After |
|---|---|---|
| change the seam's `reason` | green | **NEW=1**, this test only |
| retarget the seam to `"done"` | green | **NEW=1**, this test only |

## 2. The merge boundary changed shape

`ensureWorkflowMergeBoundaryTask` (`executor.ts:7808`) now **refuses** a
foreach step-execute region with incomplete pre-merge node proof —
logging `"Workflow merge boundary blocked: <reason>"` and returning
**without moving**. The move-then-check sequence this file pinned is
gone: `"Workflow merge boundary moved task to in-review before
requesting merge"` no longer exists anywhere in production.

Three fixes, one per failure:

1. **negative case** pinned the retired move-first log. Now pins the
*stronger* property the new order gives: an unproven card is **not moved
into review at all**. The old assertion could only say "it was moved,
then blocked". Log text asserted by stable prefix — the reason clause
enumerates missing instance ids, which is legitimately volatile.
2. **"moves direct-to-merge tasks into in-review"** got zero calls: its
fixture recorded no node results, so the gate blocked it. Added one
`steps#0:step-execute` pre-merge result.
3. **"completes graph-native checklist projection"** also got zero
calls. Its existing `plan` result proves *some* pre-merge node ran but
not the per-instance work; the gate additionally requires an instance
per foreach step-execute. Added the two matching its two steps.

(2) and (3) are the same class as the lifecycle E2E `seedTask` fix in
#2634: a fixture that never modelled completed work, asking the engine
to advance it, and reading the correct refusal as a failure. Proof shape
matched to the evaluator (`source: "node"`, `phase: "pre-merge"`,
terminal = `passed`/`skipped`) rather than guessed.

Verified the gate is what these fixtures exercise: disabling the
boundary proof check fails the negative case (`NEW=1`, that test only).

`pnpm test:gate` green, `pnpm lint` clean.

## Where U9 actually stands

The conversion (S06/S07/S08) is **not** done, and is now precisely
characterised rather than "blocked on U8":

`workflow-graph-executor.ts:310` short-circuits every
`MERGE_REGION_KINDS` entry to the legacy merge seam, so `merge-gate`,
`merge-attempt`, `manual-merge-hold`, `retry-backoff`, `recovery-router`
and both `branch-group-*` handlers **never execute**.
`createMergeGateHandler` does read `task.autoMerge` and emit
auto-on/auto-off — and is never called. The builtin IR's
`outcome:auto-*` edges are unreachable.

**U9's conversion, concretely: stop short-circuiting
`MERGE_REGION_KINDS` and let those nodes run.** S06/S07/S08 all hang off
that one change. Safeguard 2 has no node-level representation today, so
enabling the region without carrying the `autoMerge` contract into it
would let an `autoMerge:false` card merge on PR-readiness alone. Full
write-up in
`docs/plans/workflow-owned-merge-stack/u9-safeguard-baseline.md`
(#2634).

## 3. A recurring class worth a shared helper

`goal-anchoring-audit`'s swallow path now reports via `log.debug` (a
deliberate demotion of log noise), and `debug` is FUSION_DEBUG-gated so
vitest emits nothing — the test asserted a channel that was both wrong
*and* disabled. I kept both halves of the contract (swallowed **and**
reported) by enabling the flag for that case, rather than deleting the
awkward assertion.

**This is the third instance this session** — `worktree-pool`,
`self-healing`'s auto-archive line, and now this. If a fourth appears it
deserves a shared test helper rather than three bespoke fixes.

## Two failing files I could NOT responsibly take — flagged, not touched

**`executor-prompt.test.ts` (3 failures) — I ESCALATED THIS AND I WAS
WRONG. Retracting.**

I flagged these as a possible real pause-contract violation: an agent
session spawning while an operator has globally paused the engine. I
then finished the diagnosis, and the evidence goes the other way.
Recording the retraction with the same detail as the alarm, because a
false alarm aimed at another unit costs them a chase.

**The discriminator I asked for, resolved.** Six tests in that file
assert `expect(mockedCreateFnAgent).not.toHaveBeenCalled()` during
global pause; 3 fail. Splitting them by what they drive:

| Assertions | Drives | Result |
|---|---|---|
| `does not resume unpaused in-progress task while global pause is
active` (+2 siblings) | no executor method — `task:updated` / resume
paths | **pass** |
| `parks todo tasks in in-progress when fn_task_done…` (+2 siblings) |
`executor.execute(...)` **directly** | **fail** |

So the guard holds on every event-driven path and is absent only from
the direct `execute()` entry.

**And `execute()` is not the guard site — the scheduler is.**
`scheduler.ts:1491` is an explicit hard stop (*"Global pause (hard
stop): halt all scheduling activity"*), with a second gate at `:1055`,
and the scheduler never calls `.execute(` at all — dispatch routes
through the runtime. In production a global pause halts scheduling
before anything reaches the executor.

**Conclusion: the pause contract is intact in production.** The 3
failing tests call `execute()` directly, bypassing the upstream gate,
and assert a defence-in-depth check *inside* `execute()` that is not
there. They are testing a path production does not take during a pause.

What that leaves is a real but much smaller question, and a design one
rather than a defect: should `execute()` carry its own pause check as
defence-in-depth, given non-scheduler callers exist (self-healing,
manual retry)? If yes, add the guard and all six assertions pass. If no,
the 3 direct-`execute` assertions are asserting a guarantee the
architecture places elsewhere and should be retired. **I have not
changed either the code or the tests** — but nobody needs to hunt a
pause-contract regression, because there isn't one.

**`executor-fast-mode-workflows.test.ts` (1 failure) — mechanism not
isolated.** `visitedNodeIds` is `['review']` where the test expects
`['start','review']`. Three probes failed to explain it: giving the
review node an explicit `column: "in-progress"` changed nothing (so it
is not column-based entry resolution), and swapping `seam: "review"` for
a plain prompt config did not isolate it either. Two structurally
identical sibling tests in the same file still pass with `['start',
...]`, so something in graph traversal distinguishes them that I did not
find. That is U8/graph-executor territory; I am not asserting a
`visitedNodeIds` shape I cannot explain.

## Still open and green

- **#2637** — `task-delete-notice` 21 failed → 34 passed.
- **#2643** — shellout allowlist re-pin. **Merge early:** it re-drifts
whenever `executor.ts`/`self-healing.ts` line counts shift, with no git
conflict to warn you. It already drifted once while open
(`executor.ts:17106 → 17198`) and I re-pinned it.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 23:50:59 -07:00
gsxdsm
6ed284f36a drop the dead semaphore parameter from dropPreHeldExecutorSlot (#2574) 
Small follow-on to the cross-project cap removal.

`dropPreHeldExecutorSlot(taskId, semaphore?)` released a cross-project
semaphore slot. That semaphore is deleted, and **all 16 production call
sites passed `this.options.semaphore`**, which nothing wires any more —
so the release was a no-op on an always-undefined value: an optional
parameter that reads as if it does something.

## What is *not* deleted

Pre-held slots are **dual-purpose**: a cross-project semaphore slot
**and** the FN-8453 per-project coordinator reservation. Only the first
is gone. The reservation is the half that matters — every rejection path
funnels through this helper so an early scheduler/triage return cannot
permanently consume a project slot — and it stays. That is why this is a
parameter change, not a helper deletion.

Sites that still hold a semaphore reference release it **explicitly**
next to their drop, so behaviour is unchanged for any caller that
supplies one. Nothing wires one in production today, but silently
leaking a slot for a caller that does is not a trade a cleanup is
allowed to make.

## One real leak fixed — found by a failing test, not by reading

`ProjectAdmissionCoordinator.admitOldest`’s release lambda took the
pre-held branch and **returned**, relying on the deleted parameter to
hand the host slot back. With the parameter gone, that branch unwound
the registration and the reservation while **leaking the host slot** the
attempt had acquired. The release is now unconditional across both
branches.

Worth noting how it surfaced: the test that caught it (`drops a declined
candidate’s pre-held executor slot`) asserted `semaphore.activeCount`,
which I had initially assumed was just coupling to the deleted half. It
was not — it was pinning a real invariant.

## Tests

Five cases in `concurrency.test.ts` pinned `sem.activeCount` through a
drop. Each is re-pointed at the surviving contract — registration and
reservation unwound, nothing left for a later pass to “take” — with the
semaphore assertions moved to the sites that now own the release.

## Verification

`pnpm lint` clean · engine `tsc` clean · `pnpm test:gate` green ·
`concurrency.test.ts` **56/56**. The 8 `triage.test.ts` failures are
**pre-existing** — reproduced identically with this branch’s `triage.ts`
replaced by main’s.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 23:34:52 -07:00
gsxdsm
3aa942ee5f capacity: spawned agents count against the project agent count (#2579) 
Two configurable numbers per project. `maxSpawnedAgentsPerParent` (5)
and `maxSpawnedAgentsGlobal` (20) were a **third and fourth** limiter
with private budgets invisible to both.

## This closes a hole, not just knobs

A spawned child **is** an agent and gets **its own git worktree**
(branched from the parent’s — the tool’s own description says so), but
children were counted by **neither** capacity gate. A fan-out could put
up to 20 extra worktrees on disk while the scheduler believed the
project was at its configured limit. The operator’s two numbers were
simply wrong about what was running.

## The old caps also measured the wrong thing

`totalSpawnedCount` decrements on child cleanup, but the per-parent
**set** is cleared only when the **parent task** ends. So
`maxSpawnedAgentsPerParent` throttled *cumulative* spawns across a
task’s life rather than *concurrent* ones — a long-running task could
exhaust its budget with five children that had all long since finished,
and the operator had no way to see why.

## Fix

`fn_spawn_agent` gates on the same project agent count every other lane
uses (`computeTopLevelConcurrencyClaimedFromStore`) plus live children.
One number, one answer, no private budget that can disagree with the
board.

The refusal names **Max Concurrent Tasks** — a control the operator
actually has. The old messages pointed at settings that no longer exist,
which is worse than no message: it sends someone hunting for a knob that
is not there.

## Verification

**Revert-proof, measured:** restoring the private budgets turns **3 of
the 4** new cases red — a project at 1/1 could still spawn, which is
precisely the hole. `executor.ts` restored byte-identical.

`pnpm lint` clean · core + engine `tsc` clean · `pnpm test:gate` green
(414 + 10 + 71) · new suite 4/4 · `settings-default-descriptions` 4/4.

There was no spawn-capacity test before this; the file is new.

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

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Spawned agents now count toward the project’s **Max Concurrent Tasks**
capacity.
* Agent spawning is blocked when capacity is reached, including
concurrent spawn attempts.
* **Bug Fixes**
  * Prevented over-allocation during simultaneous agent spawns.
  * Restored available capacity when agent creation fails.
* **Changes**
  * Removed separate per-parent and global spawned-agent limits.
  * Updated settings to reflect the revised capacity controls.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 23:34:41 -07:00
gsxdsm
22a66c3a51 fix(test): re-pin the blocking-shellout allowlist after source lines moved (5 lines, 0 new sanctions) (#2643) 
**A failing ratchet, fixed without widening it.** 5-line diff, no
production change. `pnpm test:gate` green.

`engine-no-blocking-shellout.test.ts` was red on main, reporting **5
unaudited synchronous shellouts** (1 in `executor.ts`, 4 in
`self-healing.ts`).

## No new violation — the allowlist went stale

The allowlist is keyed by `(file, LINE, primitive, signature)`.
`self-healing.ts` shrank during the U4 extractions, so the recorded
lines drifted. Every flagged signature was **already sanctioned**:
self-healing's three sat at 4445/4451/4488 and are now at
4127/4133/4170. The file carries an FNXC note for precisely this case —
*"Re-pin all audited shellouts after current main moved source lines
without changing the sanctioned short-git-plumbing calls."*

**Re-pinned by signature, not by hand:** for each of the 33 entries,
find the line whose trimmed text equals the recorded signature and take
the occurrence closest to the old line — which stays stable when a
signature repeats, e.g. `merger.ts`'s six identical `git reset --merge`
calls. Result: **5 lines moved, 0 signatures unfound**, so nothing
became sanctioned that was not sanctioned before.

## A wrong turn worth recording

I first read the guard's *"only after proving timeout and maxBuffer
bounds"* as applying to every sanctioned site. I checked all 5, found
none had `timeout` or `maxBuffer`, and was about to add bounds to
`executor.ts` and `self-healing.ts` — an unnecessary production change
in two files other workers are actively editing.

Re-reading the guard's own comment corrected it: the bounds criterion
belongs to `BOUNDED_GIT_DIFF` (data-dependent diff output, where the
buffer can grow with the repo), not to `SHORT_GIT_PLUMBING`. All 5 are
`rev-parse` / `merge-base --is-ancestor` / `rev-list --count` / `branch
--list` — fixed-size output, already the sanctioned category.

## Verified the ratchet still bites

A re-pin could silently widen a guard, so I checked rather than assumed:
injecting an unaudited `execSync("git log --all")` into
`integration-branch.ts` **fails** the ratchet and it names the offending
signature; reverting returns it to green.

## Why this one was worth taking

A red ratchet is the worst failure mode for a guard — it stops being a
signal and starts being noise someone silences. This one had already
caught a real class of defect (unbounded sync shellouts on the shared
event loop), and it was red for a purely mechanical reason.

`workflow-lifecycle-live-e2e` (#2634, merged) and
`executor-review-verdicts` (#2641) clear two more of main's 13 failing
engine-default files; this is a third.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 23:23:25 -07:00
gsxdsm
14c73ab727 U11 [tool-availability + skill-resolver + cli/task]: name the 3 literals that are NOT columns (48 -> 45) (#2619) 
**Taking: `engine/tool-availability.ts`, `engine/skill-resolver.ts`,
`cli/commands/task.ts`** — the three census hits that are not board
columns.

## Census

| file | before | after |
|---|---:|---:|
| `packages/engine/src/tool-availability.ts` | 1 | **0** |
| `packages/engine/src/skill-resolver.ts` | 1 | **0** |
| `packages/cli/src/commands/task.ts` | 1 | **0** |
| **repo total (comment-stripped)** | **48** | **45** |

## These are not lifecycle guards — converting them would have been
wrong

- **`tool-availability`** — `surface: "triage" | "executor"` is an
**agent lane**. The lane that writes specs keeps its name whatever the
board calls its planning column. Resolving it from a workflow IR would
make an agent's prompt depend on board configuration.
- **`skill-resolver`** — `sessionPurpose === "triage"` is an **agent
role**. Same argument: a role doesn't move when a board renames a
column.
- **`cli task list`** — the glyph chain distinguished **active** columns
from the rest and nothing else; all four active ids mapped to the same
`●`.

Each is now named (`AgentResearchSurface`,
`ROLE_FALLBACK_SESSION_PURPOSES`, `ACTIVE_COLUMN_GLYPH_IDS`) so the next
person working the census sees at a glance that they're out of scope,
rather than re-deriving it as I had to.

## A real divergence my own equivalence test caught

I first wrote the glyph as the tempting inverse:

```ts
const dot = col === "done" || col === "archived" ? "○" : "●";
```

That is equivalent across all six lifecycle ids and **not** equivalent
for anything else — the original chain fell through to `"○"` for an
unrecognised id, while the inverse renders it as **active**. The loop
only walks the six `COLUMNS` today, so nothing would have caught it in
practice; a renamed workflow reaching this code later would have
silently changed how its columns render.

Shipped as an explicit ACTIVE set that mirrors the fallthrough exactly.
The test asserts equivalence over the six ids **and** over unknown ids,
which is where the difference lives.

That's the point of testing a "pure rename" at its edges rather than
only where it's currently exercised.

## Verification

- 71 tests green across skill-resolver / heartbeat-skills /
tool-availability / the new equivalence suite
- merge gate green (482 + 132 + 10), engine + CLI tsc clean, lint clean

## Note on the remaining count

Of the 45 left, `replan-target.ts` (2), `board-workflows.ts` (2) and
`archive-planning.ts` (1) show up in a **raw** grep but are **0** real —
every hit is inside a comment. A raw grep reports 53; comment-stripped
is 45. Real remaining work concentrates in `self-healing.ts` (11),
`register-task-workflow-routes.ts` (6), and the parked `moves.ts` /
`default-workflow-hooks.ts` (9).

No changeset: `@fusion/engine` is private; the CLI change is
display-identical.

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


---

## ⚠️ Read before merging — these are ROLE renames, not column
conversions

The coordinator's hand classification says several literals in this PR
"must be left exactly as they are" because they compare an **agent
role**, not a task column, and resolving them to a column trait would be
a bug. **I agree, and this PR does not do that.**

What it does: replaces a bare `=== "triage"` with a **named role
predicate** — `isPlanningAgentLane`, `AgentResearchSurface`,
`ROLE_FALLBACK_SESSION_PURPOSES`. Behaviour is **byte-identical** for
every input. No IR is consulted, no trait is resolved, no column is
involved.

The reason to keep it rather than revert: the danger isn't the literal,
it's that nothing at the call site tells the next person `"triage"` here
means a *lane*. A list of exceptions maintained elsewhere only helps
someone who finds the list; a call named `isPlanningAgentLane` helps
whoever is reading the line. It also shrinks what the #2630 ratchet's
ignore list has to carry.

Reversible: if the preference is to leave the literals untouched, say so
and I'll strip these hunks — but then the ratchet's ignore list must
carry **all twelve** role sites or it can never reach zero, because
those six are correct code.

## Classification finding

Bucketing by the **receiver** of the comparison (not the literal)
mechanically separates guards from roles, and it found **six role sites
currently listed as "real column guards"**:

| site | receiver | what it actually is |
|---|---|---|
| `usage-limit-detector.ts:144, 207` | `agentType` | agent type — the
column test one line above is *already* trait-driven |
| `skill-resolver.ts:432` | `sessionPurpose` | session purpose |
| `tool-availability.ts:32` | `surface` | agent surface (`"triage" \|
"executor"`) |
| `effective-model-resolution.ts:148` | `entry.agent` | agent-log lane |
| `useTasks.ts:162` | `entry.agent` | agent-log lane |

So the real bar is roughly **39**, not 45. The rule that found all
twelve without judgement calls: `column`/`toColumn`/`taskColumn`/`c` are
guards; `role`/`agent`/`agentType`/`surface`/`sessionPurpose` are not.
Worth teaching #2630's ratchet directly.
 2026-07-29 23:10:11 -07:00
gsxdsm
f91b8a4178 TAKING mission-feature-sync.ts: roadmap reconciliation resolves lifecycle roles (unowned drift site) (#2602) 
> **Taking `packages/engine/src/mission-feature-sync.ts`** from the
shared backlog — announced in the title per the collision protocol.
Based on `main`, no dependencies.

It is in **no unit's file list**: absent from the plan's per-file census
*and* from the drift review's ownership split (self-healing, dashboard,
triage/replan-target, core, executor). It is a planning-lane reader.

## What was broken

`reconcileMissionFeatureState` maps a task's lifecycle **position** onto
its mission feature's roadmap status, and read five column literals:
`done`, `archived`, `in-progress`, `in-review`, `triage`/`todo`.

On a renamed workflow **every branch answers "no"**, so the function
collapses to a permanent `noop`.

**What an operator sees:** a mission roadmap frozen at whatever status
it last held, while the tasks underneath it run to completion. Nothing
errors, nothing retries. Worse than a wrong status, because a stale
roadmap reads as a stable one.

## Guard counts (per the reporting requirement)

| Metric | Before | After |
|---|---:|---:|
| `column === / !== "triage"` in this file | **1** | **1** |
| role comparisons converted | — | **5** |

**The metric does not move here, and I am not claiming it does.** The
five role comparisons are converted; the one literal that remains is the
deliberate scoped migration acceptance this change *adds*. That is the
third time on this program the real fix has been invisible to the
convergence count — the count finds the site, it does not define done.
Worth knowing while the shared backlog is being tracked by that number:
repo-wide it currently reads **29** triage comparisons (including 4 in
`plugins/`, which are also unowned).

## Fallback direction matters

**Unresolvable workflow falls back to the legacy ids, not to `noop`.** A
mission whose workflow cannot be read should keep tracking on the
default vocabulary rather than go silent — going silent *is* the failure
being fixed, so the fallback must not reproduce it.

**The planner-lane branch also accepts an orphaned legacy id.** A
pre-existing test asserted a card in `triage` returns its feature to
`triaged`; that stopped holding for the default lineage after #2515 —
the migration-window population again. Accepting `triage`/`todo`
additively keeps those rows tracked, **scoped to ids the workflow does
not declare**, for the reason greptile gave on #2593: a custom workflow
may legitimately name its **review** lane `triage`, and mapping a card
there to `triaged` would walk the roadmap backwards while the task is
awaiting merge.

## A test of mine that proved nothing until fixed

The scoping case first used a `triaged` feature. The planner-lane branch
only fires for an **in-progress** feature, so the fixture fell through
to the review branch and **passed under both implementations**. It
discriminates only once the feature status lets the wrong branch win —
verified by reverting the scoping and watching exactly that case fail.

## Revert proofs

| Reverted | Result |
|---|---|
| all five literals restored | **5 of 15 fail** — every renamed case;
every default case passes |
| legacy acceptance unscoped | **1 of 15 fails** — the
custom-`triage`-as-review case |

## Verification

| Check | Result |
|---|---|
| new suite | 15/15 |
| pre-existing mission-feature-sync + mission-autopilot +
scheduler-trait-dispatch | 94/94, **no expectation edits** |
| `tsc --noEmit` (engine) | clean |
| `pnpm lint` | clean |
| `pnpm test:gate` | green (482 + 10 + 71) |
| `pnpm check:changesets` | clean |

## Next from the shared backlog

Taking
`plugins/fusion-plugin-even-realities-glasses/src/agent-actions.ts` (3)
and `plugins/fusion-plugin-dependency-graph/src/GraphTaskNode.tsx` (1)
next — 4 sites in `plugins/`, which no unit owns and which the #2587
ratchet now scans. Shout if anyone is already there.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 23:06:55 -07:00
gsxdsm
9edc746f96 E2E evidence: the MERGED board (third completion criterion) — plus a RETRACTION of my #2613 escalation (#2632) 
This is the merged-board half of the evidence assignment. **It is red,
deliberately, and the red is the finding.** Do not merge it to make the
red go away — the assertions are correct and `main` is broken.

## Escalation first: #2613 broke the default board, and the gate did not
notice

`6a33d8f8c` — *"Phase B — TAKING task-creation.ts: intake classification
by trait (4 sites → 0)"* (#2613) — regressed four E2E cases, including
**the default-vocabulary full lifecycle**, which is scenario 1 of the
whole E2E assignment.

Attribution is a clean single-file revert, not a guess:

```
HEAD (main):                                        4 failed | 39 passed
HEAD with ONLY 6a33d8f8c's task-creation.ts reverted:    28 passed  (both files fully green)
```

Failing:

1. `scenario 1 — DEFAULT vocabulary … persists the card in the expected
column at every stage`
2. `scenario 2 — RENAMED vocabulary … writes the same column-transition
audit trail as the default`
3. `releases a card out of the merged lane on capacity — the release is
not a self-move`
4. `does not re-release a card that already left the merged lane`

**`pnpm test:gate` is green on this branch — exit 0, 695 tests.** #2613
merged through a green gate, and its own tests pass. This is the eighth
time this program a test has passed without exercising its subject, and
the first one an E2E family caught rather than review.

### Mechanism

`isIntakeColumn` in `task-creation.ts` decides whether a new card gets a
**bootstrap** prompt (freeform, "triage will plan this later") or a
**specified** prompt (planned, executable). #2613 rewrote it as:

```ts
const isIntakeColumn = (intakeFacts.intake !== undefined && task.column === intakeFacts.intake) || …
```

where `intakeFacts.intake` falls back to the **default workflow's**
intake when the create supplies no `workflowId`. Post-U11 the default
workflow's intake **is `todo`**. So any card created directly in `todo`
is now classified as intake and gets a bootstrap prompt — unplanned.
Unplanned cards do not advance through the graph (no `NodeEntered` audit
rows → failures 1 and 2) and hold-release will not release them
(FN-7648: no unplanned card enters a processing column → failures 3 and
4).

Before U11 this was safe: `triage` was intake and `todo` was a distinct
lane, so creating in `todo` meant "planned work". The merge deleted that
distinction.

### Why this is the exact trap you warned about

You said you did not want *"a conversion that swaps the literal for a
trait lookup WITHOUT checking what the guard was for."* The old
`task.column === "triage"` guard meant **"is this card unplanned?"** On
a merged board, intake-vs-hold **cannot answer that question at all** —
one column is both. The distinguishing fact is not the column; it is
whether the caller supplied a spec. Resolving the role faithfully still
gets the wrong answer, because the question was never really about the
column.

Not fixing it from here: `task-creation.ts` is #2613's owner's file, and
the fix is a design call about which fact replaces the column test.

## What the evidence itself adds

Three families extended to the U11 shape — one column carrying **both**
intake and hold. That breaks a class of guard renamed boards
structurally cannot reveal:

| shape | consequence |
|---|---|
| `intake && !hold` | **unsatisfiable** — silent |
| hold → intake release | **self-move**, re-fires every poll — loops |
| `intake && column !== "triage"` | inverts to **always-true** — silent
|

Two are silent and one loops, so every case sweeps **twice** and asserts
no re-release; a single pass cannot tell a no-op from a self-move.

### A fixture that could not fail

My first merged row used `MERGED_VOCAB`, which is *faithful* to U11 — it
reuses the legacy ids, because that is what the default lineage has.
That fidelity **destroyed its discriminating power**: its hold column
*is* `todo`, so a guard falling back to the `todo` literal returns the
same answer as one resolving the role. The "hold but not intake"
mutation left all 23 green.

Added `MERGED_RENAMED_VOCAB` — merged *structure*, renamed *vocabulary*
— the only combination where the collapse is observable **and** the
literal is wrong. Same mutation now fails exactly 1 of 23. Both
vocabularies stay: one asks *"does the collapse break the release
path"*, the other *"is the role actually resolved"*.

One rebound mutation was **genuinely unobservable** rather than
undetected — `hold` is also the first column in that fixture, so the
fallback chain lands there regardless. Pointing rebound at `complete`
instead fails 9 of 15. Recorded rather than papered over.

## For the CAPACITY worker before `self-healing.ts` is marked done

`self-healing.ts:2952` and `:9134` query `listTasks({ column: "triage"
})`. Converting the 10 guards leaves those sweeps **blind** — they never
see a renamed card, so the guard is correct and unreachable. Query and
guard convert together or not at all.

There are **137** such `column: "<legacy id>"` sites repo-wide, 52 in
that one file, and the 45→0 grep counts none of them because they are
object properties, not comparisons. **The bar can reach zero with sweeps
still unable to fire.**

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

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 22:59:37 -07:00
gsxdsm
8e211d1870 TAKING scripts/: parse instead of grep — an AST classifier for the lifecycle-column bar, cross-checked by a second implementation (#2633) 
The program's completion bar is "`column === "triage"` reaches zero".
This measures what that bar actually covers, and checks the measurement
in so it cannot drift.

## The number, measured by the checked-in tool

```
lifecycle-column-census: scanned 1956 source files

  COLUMN guards (the backlog):   1031
  ROLE comparisons (not guards):   10
  DELIBERATE-LITERAL (reviewed):    4

  by column id:
     313  done
     217  in-review
     201  in-progress
     177  archived
      83  todo
      40  triage

  top files:
     151  packages/engine/src/executor.ts
     136  packages/engine/src/self-healing.ts
      50  packages/dashboard/app/components/TaskCard.tsx
      44  packages/core/src/task-store/moves.ts
      34  packages/dashboard/app/components/TaskDetailModal.tsx
```

**`triage` is under 4% of the class.** Every one of those 1031 sites is
the same defect: a lifecycle decision made by column NAME, which stops
matching the moment a board renames a column. The bar can be met in full
while 991 identical guards remain — and two files hold a quarter of
them.

## The tracked count is wrong in three directions at once

Each of these cost real work this week, which is why this is a PR and
not a comment.

1. **Vocabulary.** It measures one of six legacy ids.
2. **Receiver.** It is anchored on locals named
`column`/`toColumn`/`fromColumn`, so it never saw the three real guards
in `executor.ts` written against `from` and `originColumn`. One of those
meant completed-but-stranded work was never recovered on a renamed
board, with nothing else owning that state (converted in #2628).
3. **Collision.** `role === "triage"`, `agentType === "triage"`,
`entry.agent === "triage"` compare an **AGENT ROLE**. The planner *lane*
is named `triage` and keeps that name — U11 removed the *column*. Ten
such sites were counted as backlog, and the "obvious" fix (renaming the
role) silently empties the planner's prompt template and mis-binds its
model markers.

A count that is too high and too low simultaneously sends work to the
wrong files while hiding the files that need it. So the census reports
**three separate numbers** and never nets them.

## Proven to fail on the original defect

Not asserted — exercised:

```
$ # reintroduce `task.column === "triage" || task.column === "todo"` into live-agent-count.ts
$ node scripts/lifecycle-column-census.mjs --strict; echo "exit=$?"
  packages/core/src/live-agent-count.ts: 10 -> 12
exit=1
$ # restore the file
$ node scripts/lifecycle-column-census.mjs --strict >/dev/null; echo "exit=$?"
exit=0
```

The CLI also exits 1 when its own file list comes back empty — a guard
that reports success without checking anything is worse than no guard.

## 12 regression cases, split by what they defend

Must catch: all six ids; a guard on a local named `from`/`originColumn`
(verbatim the executor.ts shape); single quotes; negation; several
comparisons on one line.

Must **not** catch: role comparisons; comment prose (two tracked
"guards" in `replan-target.ts` were prose about a filter that lives in
another file); a trailing `// … === "triage"` on a code line; sites
carrying a `DELIBERATE-LITERAL` marker.

Plus: **one marker cannot launder a distant guard in the same file** —
that is how allowlists rot.

## Report-only, deliberately

`--strict` compares per-file counts against
`scripts/lib/lifecycle-column-census-baseline.json` and fails when any
file's count **rises**. It is **not** wired into the merge gate: a
thousand-site backlog cannot be a blocking check the day it is first
measured, and a guard nobody can pass is a guard everyone disables.
Owners tightening their own area re-record the baseline in the PR that
lowers it. This is the ratchet shape the `DELIBERATE-LITERAL` markers
scattered through the program already anticipate.

## Stated limitation

Classification is by receiver **name**, so a future field named `agent`
that holds a column would be misclassified as a role comparison.
Recorded at the site, and it is precisely why the two classes are
reported separately instead of netted into one figure.

## Verification

- 12/12 new cases
(`packages/engine/src/__tests__/lifecycle-column-census.test.ts`)
- `pnpm test:gate` **71/71**; `pnpm lint` clean
- `pnpm census:lifecycle-columns`, `--json`, and `--strict` all
exercised end to end
- documented in `docs/testing.md`; no production code touched

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 22:52:18 -07:00
gsxdsm
26c82ebc18 ratchet the planner-liveness gate so a fourth door fails CI (FN-6756) (#2540) 
Test-only follow-up to the merged P0 (#2531). No production change, no
changeset (internal).

## Why

This bug reached users **three times**, each as the same mistake in a
new place:

| | What happened |
|---|---|
| FN-8600 | the reclaim sweep removed a worktree a live **planner** was
using — fixed by registering planning paths and teaching *that* sweep
`isPathActive` |
| FN-6756 | the leaked-slot reaper never got the same signal; its last
line of defense computed liveness from four TaskExecutor-owned maps, so
a triage planner matched none of them |
| (same PR) | fixing that was not enough — `recoverPausedAbortFailures`
**discarded** the refusal and still logged `"Auto-recovered…"`, audited
and counted it. The whole bug again, while reporting success |

The shared cause is not any one sweep: **“liveness” was re-derived per
call site**, so closing one door left the next open and nothing failed.
Every one of those fixes was found by review, not by CI. This makes the
next one a CI failure.

## Four properties, each written to fail on the exact defect that got
through

1. **Every `clearPhantomExecutorBinding?.(` call site consumes its
return** — a bare expression statement (including
`void`/`await`-prefixed) is the signature of the pause-abort defect.
2. **The destructive path delegates to `hasLiveSessionSurface`** rather
than inlining the session-map disjunction — a second copy can drift from
the one callers gate on, which is precisely how each sweep got “fixed”
without fixing the next.
3. **The probe is wired** in `in-process-runtime`. `self-healing.ts`
already records `releaseExecutorWorktreeOwnership` as a
declared-but-never-wired option that silently no-opped; an unwired
*probe* is worse, since `?.() === true` is `false` when unwired and
every gate would quietly stop deferring with nothing failing.
4. **The probe counts registered session paths**, not just executor maps
— a triage planner appears in no executor-owned map, so that term is the
only thing that sees it.

Grep-level, comment-stripped, production source only; no engine boot and
no fixtures (FN-5048). Fails closed on an empty/moved source file so a
rename cannot make it silently check nothing.

## Proven, one injection at a time

**The first draft of property 1 was worthless** — its filter chain was
convoluted enough to discard every candidate, so the injected bare call
passed. Caught by actually running the injection instead of trusting the
green, and rewritten as a single “is this a bare expression statement”
rule.

| Injection | Result |
|---|---|
| discard the return value | fails, naming the call site |
| re-derive liveness inline | fails on the delegation assertion |
| unwire the probe | fails, naming `in-process-runtime` |
| drop the registry term | fails, naming `activeSessionRegistry` |

Clean tree passes 4/4; all three sources restored byte-identical (`git
status` shows only the new file).

**Verified:** `pnpm lint` clean · engine `tsc` clean · `pnpm test:gate`
green (414 + 10 + 71).

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

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Tests**
* Added safeguards to ensure liveness checks remain consistently
enforced.
* Verified phantom executor cleanup uses shared session-liveness
detection.
* Added coverage for registered session paths to prevent false inactive
states.
* Added fail-closed checks when required runtime source is unavailable.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 22:42:26 -07:00
gsxdsm
55ce01335c self-healing.ts: resolve pre-WIP columns by role — 11 → 0 receiver-agnostic (largest single item) (#2560) 
Taken ahead of my capacity slice, per the drift review.

U11 merges the two pre-implementation columns into one that **keeps the
id `todo`** and **deletes `triage`**. Every `column === "triage"` here
is live breakage the moment that IR lands — and it does not throw, it
simply **stops matching**, so the sweep never fires again and the suite
stays green. That is the Problem Frame’s measured failure mode, landing
on self-healing, where a silently-dead recovery is least likely to be
noticed.

## Count for tracking convergence

`self-healing.ts`, code only, `column === / !== "todo" | "triage"`:

| | before | after |
|---|---:|---:|
| `"triage"` comparisons | **10** | **0** |
| `todo` + `triage` combined | 24 | 15 |

The 15 remaining are all `"todo"`, whose id **survives** U11 — not
breakage, and deliberately left for the hold-column conversion rather
than mixed in here.

## Ten sites, converted by role (intake / hold)

advanced-triage recovery (3, one sweep) · dependency-deadlock blocked
dependents · parked-agent task link · orphaned-approved planning ·
orphaned planning · duplicate-decision candidates · refine-source sweep
· leaked-slot reaper

## Two literals the grep did not count — and they would have silently
killed their sweeps

`listTasks({ column: "triage" })` in both orphaned-planning sweeps.
Converting only the predicate would have left the **query** returning
nothing once the id is gone; the sweep would have looked converted and
done nothing. Both now query the board and filter by role.

All ten route through one seam (`resolvePreWipColumns` /
`filterByPreWipRole`) with a caller-owned per-sweep cache, so 400 cards
over three workflows read three IRs, not 400.

## Two judgement calls, stated

**Unresolvable workflows fall back to the legacy literals, not to
nothing.** These are *recovery* sweeps: a card whose IR cannot be read
must keep its current behaviour rather than silently drop out of every
sweep. That is the conservative direction *here*, and deliberately
differs from conversions whose failure mode is a destructive move.
Pinned by test.

**The leaked-slot reaper’s predicate is left as-is and flagged in
place.** It is arguably too *wide* under plan-in-place — a card being
specified sits in the hold column while a planner works in its worktree,
so “waiting to run must not pin a worktree” no longer holds. What stops
that being live is the FN-6756 liveness gate (already merged). Narrowing
it is a behaviour change and gets its own commit; this PR is vocabulary
only.

The dependency-deadlock site needed restructuring rather than
substitution: its filter is synchronous and role resolution reads the
IR, so membership is precomputed once per sweep.

## Verification

**Revert-proof, measured:** making the resolver return the literals
regardless of workflow turns **4 of the 6** new cases red — the
renamed-workflow ones, precisely the case a literal cannot serve.
`self-healing.ts` restored byte-identical.

`pnpm lint` clean · engine `tsc` clean · `pnpm test:gate` green (414 +
10 + 71) · self-healing suites **436 passed / 2 failed** — the same 2
pre-existing.

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

## Re-verified against current `origin/main` (2026-07-29)

Per the definitive-list instruction, re-measured rather than re-asserted
— comment-stripped, so FNXC prose quoting a removed literal does not
inflate the count.

- `origin/main` `self-healing.ts`: **10** code sites (lines 2964, 2984,
3019, 9218, 10703, 11282, 12173, 12218, 12321, 12494 — the same ten,
line numbers shifted only).
- This branch: **0**.
- Main touched this file after my branch point (#2600, the R7 dead-guard
fix). Checked: its diff adds **no** `"triage"` literal, and git reports
this PR `MERGEABLE`, so the merge result stays at 0 — the branch being
behind does not hide a new site.

So merging this moves the tracked number **45 → 35**.

Both stated constraints hold: every site resolves to the **intake/hold
ROLE** (not a renamed literal), and the count is zero across the whole
file rather than per-branch — there is no surviving guard in another
branch of the same function. The two `listTasks({ column: "triage" })`
**queries** are converted too; predicate-only conversion would have left
these sweeps looking converted while returning nothing.

## Re-measured RECEIVER-AGNOSTICALLY (2026-07-30, after the revised bar)

The revised count matches any receiver, not just `.column`. Re-measured
with that pattern, comment-stripped, this file is **11 → 0**, not 10 →
0.

| pattern | origin/main | this branch |
|---|---:|---:|
| `<anything> === / !== "triage"` (any receiver, both quote styles,
line-splits) | **11** | **0** |

The eleventh is the one your list attributes separately to
`engine/self-healing.ts`:

```
origin/main:3017   if (!resumeColumn || resumeColumn === "triage") continue;
```

`resumeColumn` is a bare local holding `live.workflowIrPinColumnId`, so
a `.column`-anchored pattern cannot see it. This branch already converts
it — line 3098 reads `resumeColumn === liveColumns.intake`, resolved
from the same per-sweep role cache as the other ten. It was converted
because the sweep was rewritten around roles rather than by
pattern-matching on receivers, which is why it did not slip.

**Merging this therefore moves the revised 56 by 11, to 45.**

### The 5 literal mentions that remain, and why each is not a guard

Nothing above is a comparison. For completeness, since "a file is not
done because the pattern is gone from it":

- **3 legacy fallbacks** (`?? "triage"`) at 2978, 2980, 10821 — the
unresolvable-workflow path in `resolvePreWipColumns`. These are
*recovery* sweeps: a card whose IR cannot be read must keep its current
behaviour rather than silently drop out of every sweep. Pinned by test.
- **2 union reads** at 6044 (`["triage", "todo"]`) and 9291
(`listTasks({ column: "triage" })` alongside a `todo` read) — unions
covering both vocabularies, with the role filter deciding membership.
Neither replaces nor disables anything.

Known residual gap, stated rather than hidden: those unions do not cover
a **renamed** intake (Coding (Ideas)'s `ideas`). That gap **pre-dates
U11** — the same unions missed `ideas` before the merge — so it is not a
regression here, and closing it needs a cross-workflow lane union rather
than a vocabulary edit.

## AST-VERIFIED, replacing the grep-derived figure (2026-07-30)

Since no grep-derived number is authoritative, I re-measured this file
by PARSING it — `ts.createSourceFile`, walking binary expressions,
classifying on the left-hand side. Not a pattern match.

| | origin/main | this branch |
|---|---:|---:|
| lifecycle-column comparisons (AST-classified) | **11** | **0** |

All eleven classify as `COLUMN`; none is an agent role, session purpose
or surface name, so all eleven are real guards and every one is
converted:

```
2964  task.column          9218  dep.column          12218  task.column
2984  live.column         10703  task.column         12321  task.column
3017  resumeColumn        11282  linkedTask.column   12494  t.column
3019  current.column      12173  t.column
```

`3017` is `resumeColumn` — a bare local holding `workflowIrPinColumnId`,
which is exactly the receiver class the `.column`-anchored greps missed.
It is converted here to `resumeColumn === liveColumns.intake`, resolved
from the same per-sweep role cache as the other ten. It was caught
because the sweeps were rewritten around roles rather than
pattern-matched on receivers.

The classifier is on #2623 as `scripts/lib/lifecycle-column-ast.mjs` and
is offered to #2630 to import. My earlier "11 → 0" was correct — but it
was a regex reading, and this is the same number arrived at by parsing.

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 22:42:14 -07:00
gsxdsm
833f379fbd U7: ratchet the planning claim to a single writer (extracted from #2517 so it can land) (#2587) 
> Test-only, based on `main`, no dependencies. **Extracted from #2517**,
which has been overtaken by events — see the bottom.

U7's stated verification is *"a grep-level assertion that planning
status literals have one writer module"*. This is that assertion, and
the plan names **FN-8504** as the acceptance case: a store-open sweep
cleared a live planner's status because two owners wrote it.

## What it asserts

1. **`status: "planning"` — the claim on a card — is written by exactly
one production module** (`triage.ts`).
2. That single write goes through `updatePlanningStateIfStillCurrent`,
never a bare `store.updateTask`. FN-7977 and FN-8361 are both the latter
bug.

## What it deliberately does not assert

Stated in the file so the guard is not oversold:

- **Who clears the status.** Eleven modules write `status: null` for
unrelated reasons — "one clearer" would be *false*, and the only way to
make it pass is to weaken it into meaninglessness.
- **`needs-replan`.** Post-U3 it is the graph's own durable replan
signal with multiple writers **by design**.
- **Mission `status: "planning"`.** A different entity, excluded by
*path* rather than by pattern — a pattern loose enough to tell them
apart is loose enough to miss a real task write.

## Writes and bindings are separate contracts

Adding constant-indirection detection (`const CLAIM = "planning"`
defeats every shape pattern) flagged `replan-target.ts` — which binds
the literal only to **exclude** it from a status set and writes no task
status anywhere.

Calling that a second writer would have been a false accusation;
dropping the binding rule would have reopened the hole. So the **write**
list stays at one module and **binding** is its own allowlist.

## Proven to fail — twice

A guard that cannot be shown to fail is not a guard.

**1. The real scan function is re-run over a fixture tree** by four of
its own tests — a re-implementation would prove only that the copy
works. Covers every evasion form (single quotes, template literal,
whitespace, plain assignment, computed key), the indirection route, a
comparison-only counter-case, and a brand-new package.

**2. End-to-end against real source**, in a form the *original* detector
missed on **both** axes — a single-quoted writer in `packages/desktop`,
a package the first version never scanned. Re-verified on post-U11
`main` just now:

```
FAIL ... + "packages/desktop/src/bundled-plugin-dirs.ts"
      Tests  1 failed | 13 passed (14)
```

Both holes — double-quote-only matching, and a hardcoded four-package
scope — were found by greptile on #2527, and are why the detector now
**discovers** its roots by enumerating `packages/<name>/src` rather than
listing them.

## Why this is a separate PR

**#2517 has been overtaken.** Main absorbed a better discovery
conversion from another worker (it handles U11's merged column, which
mine did not); #2515 then changed the column vocabulary underneath it;
and what remains there is entangled with 14 U11 fixture updates.

This file is a source scan with no dependency on any of that, so it
lands on its own. My recommendation on #2517: **close it** and re-land
its remaining unique content — the sweeps, the handler snapshot,
stuck-abort, `recoverApprovedTask`'s intake gate — as focused PRs
against post-U11 main. Holding a 1262-line PR open through three
vocabulary changes has cost more than it has delivered. That is a
reversible call and it is yours if you disagree; say so and I will
rebase it instead.

## Verification

| Check | Result |
|---|---|
| suite | 14/14 |
| `pnpm lint` | clean |
| `pnpm test:gate` | green (482 + 10 + 71) |

Cheap by construction (FN-5048): grep-level over production source, no
engine boot.

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


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Tests**
* Added automated safeguards to ensure planning task cards have exactly
one valid writer.
* Added checks covering direct and indirect status updates, supported
syntax variations, package discovery, and comment or test-file
exclusions.
* Added validation that planning updates occur only through the approved
guarded workflow.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 22:41:30 -07:00
gsxdsm
8beba5f543 U7 E2E evidence: the planning lane, real PostgreSQL + real hold-release sweep (3/7 red without the guard) (#2611) 
> Completion-bar **item 3** for my phase. Test-only, based on `main`, no
dependencies, no changeset.

## The gap this closes

The planning lane was the **one lifecycle lane with no E2E coverage**.
The existing live-E2E files cover the lifecycle spine, agent count,
agent link, lease rebound, the merge family and the rebound family —
**not one exercises a planning decision.** Every U7 fix shipped with the
caveat the other units already removed for their lanes: *"all evidence
is unit-level."*

That caveat matters more here than anywhere, because the planning fixes
are **guards that refuse things**, and a refusal is what unit tests are
worst at proving. Nine times on this program a planning test passed
without exercising its subject: a fake that ignored its predicate, a
store stub returning a non-promise into `.catch`, a fixture that
silently resolved to the default IR, a control that passed when it
should have failed.

## What is real

- a per-file **throwaway PostgreSQL** TaskStore (never the operator's)
- the **real `runHoldReleaseSweep`** — every guard, trait resolution,
reservation ordering, and the in-transaction `moveTaskIf` predicate
- **persisted rows** read back with the store's task cache defeated, so
an assertion can only have come from the row

Nothing about the AI is substituted, because none of these decisions
involve it — there is no seam here to script.

## The proof, which is the point

With **#2491's two approval guards removed** from `hold-release.ts`,
this file goes **3 of 7 red against real PostgreSQL**:

```
FAIL  does NOT release a card blocked on manual plan approval on a default board
FAIL  does NOT release a card blocked on manual plan approval on a renamed board
FAIL  holds a card parked for approval MID-SWEEP, after the snapshot was read
      Tests  3 failed | 4 passed (7)
```

Restored: **7/7**. So the file demonstrably exercises the guard rather
than merely observing that a sweep works — which the two control cases
(an ordinary held card **is** released, on both vocabularies) exist to
keep falsifiable.

## The case no unit test could honestly make

The **mid-sweep** case needs the in-transaction predicate enforced by a
real store. The hand-built fake that shipped with #2491 originally **did
not honour the predicate at all** — exactly what greptile caught. Here
PostgreSQL enforces it, and the sweep's own log confirms the refusal:

```
[scheduler] Hold release for FN-RACE skipped — task became paused or left todo
```

It parks the card inside `reserveSlot`, which runs *after* the snapshot
and *before* the move — the precise window the in-txn half exists for.

## Coverage

Both approval hold shapes (`status: "awaiting-approval"` and `paused` +
`pausedReason`), on **both** vocabularies, so no assertion can pass by
matching a legacy id. The renamed run's log shows the real sweep
releasing the control card to `building`, not `in-progress`.

## Lane

`.pg.test.ts`, skipped via `pgDescribe` when no PostgreSQL is reachable,
so **the merge gate is unaffected**. Throwaway per-file database, never
port 4040, no temp-root walk.

## Verification

| Check | Result |
|---|---|
| E2E suite (real PostgreSQL) | 7/7 |
| same suite with #2491's guards reverted | **3/7 fail** |
| `tsc --noEmit` (engine) | clean |
| `pnpm lint` | clean |
| `pnpm test:gate` | green (482 + 10 + 71) |

## Still owed on the completion bar for my lane

E2E for the other three U7 fixes — approved-plan recovery (#2593), the
spec-staleness exemption (#2583), and the discovery advancement guard
(#2576) — is **not** in this PR. Those need a driver for triage's own
poll/recovery path rather than the sweep, which is a different harness
shape; adding it here would have made this PR a harness project rather
than evidence. 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 22:40:05 -07:00
gsxdsm
31e49b684a TAKING default-workflow-hooks.ts + executor.ts + live-agent-count.ts + 6 dashboard files: reopen semantics by role, and the census's blind spot in both directions (13 sites) (#2628) 
Batched conversion of every lifecycle-column guard I hold, plus the
three the census could not see. **Six files to zero, repo-wide 60 → 49
by a comment-stripped unanchored sweep.** Each conversion has an
isolated revert proof and a paired negative case, and the one code move
is a separate commit from the behavior changes.

## Per-file before → after

Counts from a comment-stripped, unanchored `(===|!==) ["']triage["']`
sweep over `packages/*/src` + `plugins/*/src`, excluding tests.

| file | before | after | note |
|---|---:|---:|---|
| `core/default-workflow-hooks.ts` | 4 | **0** | |
| `core/task-store/moves.ts` | 5 | **4** | only the flag-ON mirror
converted; the flag-OFF inline block is the parity reference and stays |
| `engine/executor.ts` | 3 | **0** | **absent from the 45-guard list** —
see below |
| `core/live-agent-count.ts` | 2 | **0** | duplication removed; answer
deliberately unchanged |
| `engine/replan-target.ts` | 2 | **0** | both were comment prose, not
guards |
| `core/agent-prompts.ts` | 3 | **0** | ROLE comparisons, never column
guards |
| `engine/usage-limit-detector.ts` | 2 | **0** | ROLE comparisons |
| `dashboard/app/components/DocumentsView.tsx` | 1 | **0** | real column
guard |
| `dashboard/app/components/TaskChatTab.tsx` | 2 | **0** | ROLE |
| `dashboard/app/components/AgentLogViewer.tsx` | 1 | **0** | ROLE |
| `dashboard/app/components/effective-model-resolution.ts` | 1 | **0** |
ROLE |
| `dashboard/app/hooks/useTasks.ts` | 1 | **0** | ROLE |
| `dashboard/…/command-center/MissionControlPanel.tsx` | 1 | 1 | alias
table, marked `DELIBERATE-LITERAL` with its reason |

## The census errs in BOTH directions

This is the finding I would most like carried into the remaining work.

- It **flagged 10 sites that were never column guards.** `role ===
"triage"` / `agentType === "triage"` compare an **AGENT ROLE**. The
planner *lane* is named `triage` and keeps that name — U11 removed the
*column*. Worse than noise: the obvious "finish the migration" edit is
to rename the role, and that silently empties the planner's prompt
template and mis-binds its model markers. `PLANNER_AGENT_ROLE` now names
it, so the two vocabularies are distinguishable by grep and a rename
fails loudly (revert proof: 4 tests, two of them pre-existing).
- It **missed 3 real guards in `executor.ts`**, because the pattern
matches `column`/`toColumn`/`fromColumn` and those locals are named
`from` and `originColumn`. A census keyed on variable names will keep
missing guards wherever a local was named for its role in the function.

## Two real defects, not tidying

**1. A renamed board could merge with its re-review never run.**
`default-workflow-hooks.ts` is named for the default workflow, but the
store runs it on the flag-ON path for *every* workflow — the trait
registry resolves hooks by trait id, not by workflow. Its reopen
predicates listed the default lineage's column names, so on a renamed
board **no reopen effect fired at all**. One of them clears
`workflowStepResults`, which `getTaskMergeBlocker` reads: a card bounced
out of review carried its old `passed` result back in, and that
satisfies the merge gate. Same regression the graph-owned-crossing
carve-out exists to prevent, arriving through the other door. (Two
smaller ones rode along: failure state never cleared on a renamed
reopen, and an operator dragging a card back to the queue never parked
it, so the scheduler re-dispatched what they had just pulled back.)

**I forgot the carve-out on my first pass, and that was worse than not
converting.** A role-resolved clear plus a *name*-matched exemption
means a renamed board takes the clear and never the exemption,
destroying the remediation input the graph had just written. My own
paired negative test caught it.

**2. The last-resort recovery for completed-but-stranded work did not
exist off the default lineage.** In `recoverCompletedTask`,
`promotedFromPlannerColumn` was false on a renamed board, so finished
work resting in the planning lane was never promoted — the code fell
through to `handoffTaskToReview` straight from the planning column, and
role adjacency has no planning → review edge, so the handoff was
rejected and the card stayed stuck with its work complete. I converted
the promotion **target** too: resolving the lane and then moving to a
literal `in-progress` is the half-conversion I have already been burned
by twice this program, where the guard starts admitting cards and the
move then sends them to a column the board does not declare.

## E2E evidence

`renamed-board-reopen.pg.test.ts` drives a **real PostgreSQL store** and
a real `moveTask` on a workflow whose columns carry the standard traits
under non-default names. The unit tests cannot show this: if `moves.ts`
passed `undefined`, every unit case still passes via the no-basis
fallback while the real board keeps the old behavior. **Proof it is
load-bearing: forcing `moveLifecycleColumns` to `undefined` fails 2 of
3.** The executor suite covers both the split-role and the MERGED
post-U11 shape.

## Revert proofs, isolated per site

| change reverted | result |
|---|---|
| reopen predicate → literal names | 4 of 10 fail |
| reopen field clears → literal names | 2 of 10 fail |
| `userPaused` hold lane → literal `todo` | 1 of 10 fail |
| graph carve-out → literal names | 1 of 10 fail |
| store passes `undefined` lifecycle columns | 2 of 3 fail (real PG) |
| `promotedFromPlannerColumn` → literals | 3 of 7 fail |
| two-hop condition → `=== "triage"` | 1 of 7 fails |
| promotion target → `"in-progress"` | 3 of 7 fail |
| `isPlannerColumnFor` → literals | 1 of 7 fails |
| live-agent-count: one arm dropped | 2 of 11 fail |
| DocumentsView: trait branch removed | 3 of 7 fail |
| planner role renamed to `"planner"` | 4 fail (2 pre-existing) |

Every conversion is paired with a negative case (a forward move, a
not-a-planner-lane card, a default-lineage card, a renamed column with
no traits), so neither "always fire" nor "never fire" can pass for
"resolve the role".

## Deliberately NOT converted, with reasons

- **`moves.ts` flag-OFF inline block (4).** That branch *is* the legacy
path, kept verbatim so the two can be parity-checked. Converting it
erases the reference implementation.
- **`live-agent-count.ts`'s no-flags fallback.** Reachable, and there is
nothing to resolve from — `enrich…FromFlags` exists for callers with
board flags rather than an IR, so a column missing from that map is the
renamed case. "Not intake" is as much a guess as "todo is intake", and
Running/Waiting are complements, so a card matching neither arm is
reported as neither and the footer's queued total under-reports it. The
real fix is at the caller; four new cases pin that flags override the
legacy answer **in both directions**. What did change is the
duplication: two hand-written copies of one rule now call one named
function.
- **`MissionControlPanel`'s `FUNNEL_STAGES`.** An alias table of column
*names* where `triage` sits beside `signal` and `backlog`. Command
Center aggregates across projects, so there is no single workflow to
resolve traits from — the honest conversion is a data change, not a
predicate change.
- **`DocumentsView` with no traits.** Same no-basis rule; the documents
list is full of historical columns absent from the current board. A case
asserts a renamed column with no traits still reads as "working",
documenting the gap rather than hiding it.

## Fixture findings

Each cost a red run that looked like the code under test:

- a `merge-blocker` column needs a reachable merge-class node, or
`parseWorkflowIr` rejects the workflow;
- a back-edge must be `kind: "rework"`, and a rework edge is legal only
**into** a node with `config.reworkRegion: true`;
- a workflow gets role-level transitions only when it declares wip +
review + complete + **archived** plus a planning lane — without the
archived column, adjacency falls back to order-derived neighbours and
`checking -> queued` is not a legal move at all;
- `recoverCompletedTask` only *reaches* the promotion seam when nothing
is left to gate; without passed `plan-review`/`code-review` rows it
re-enters the workflow graph and returns first, so a naive fixture
silently tests the wrong branch and every assertion reads "no moves
happened" for an unrelated reason.

## Verification

- `pnpm test:gate` **71/71**
- new suites: 10/10 reopen-semantics, 3/3 renamed-board-reopen (real
PG), 7/7 executor-planner-lanes, 7/7 documents-status-dot, 4/4
planner-role-is-not-a-column
- neighbours: 132 + 10 + 482 (gate shards), 350/351 engine
planning/replan suites, 64/64 agent-prompts, 51/51 usage-limit-detector,
11/11 live-agent-count, 11/11 dashboard hook/log suites
- the single engine failure (`executor-fast-mode-workflows.test.ts` ›
"raw fast mode still invokes non-executable review seam nodes")
**reproduces with my changes stashed** — pre-existing on `origin/main`
- typechecks clean for core, engine, and dashboard-app
(`tsconfig.app.json`; `tsconfig.json` checks nothing under `app/`);
`pnpm lint` clean

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 22:39:14 -07:00
gsxdsm
c9f117bcd9 fix(test): dep-abort rebound asserts the resolved column, not the retired triage literal (#2641) 
**Review-lane test, 1 failed → 21 passed.** Test-only. `pnpm test:gate`
green, `pnpm lint` clean.

## Production was right; the test was stale

```
expected moveTask("FN-DEP", "triage")
received moveTask("FN-DEP", "todo")
```

`handleDepAbortCleanup` no longer hardcodes a column. It moves the card
to `resolveReboundColumnFor(store, taskId)` (`executor.ts:16576`), which
resolves the task's **own** workflow rebound target by trait — hold,
else intake, else first column — with a `todo` fallback. For this
fixture's default workflow that resolves to `todo`, which post-U11
**is** the merged Planning column. `triage` is not declared on the
default lineage at all, so the old expectation was asserting a column
the workflow does not have.

## Why the concrete value, not the resolver

I asserted `"todo"` rather than re-calling `resolveReboundColumnFor` in
the test. Deriving the expectation from the code under test makes the
assertion agree with whatever the resolver happens to return — the exact
anti-pattern `task-delete-notice.test.ts` documents for its notify table
("deriving the expectation from the value under test makes the suite
agree with whatever the production constant happens to say").

That's only legitimate because **per-workflow resolution already has its
own coverage** — `replan-target-merged-planning-column.test.ts` and
`replan-target-renamed-planner.test.ts`. I checked they exist rather
than assuming; without them, pinning a concrete id here would be hiding
the interesting behaviour.

Also added the negative: the move must **not** be `triage`, so a
regression that reinstates the literal fails instead of quietly passing
on a column the default lineage no longer declares.

**Red-green:** reinstating `moveTask(taskId, "triage")` in production
fails exactly this test (`NEW-failures=1`).

## Context — main's engine-default census

Measured on `origin/main` just now: **66 failed / 9382 passed across 13
files**. This clears one. `workflow-lifecycle-live-e2e.pg.test.ts` is
another and is already fixed in #2634 (pending merge), which takes it
from 2 failures to 0 and adds two new scenarios.

Of the remaining 11, none are in the review/merge lane:
`agent-tools-intake-column`, `builtin-workflows-lifecycle`,
`workflow-graph-optional-step-fix` and
`workflow-settings-fallback-alignment` are column-vocabulary drift
belonging to the U11/U12 owners (the optional-step-fix one expects
`triage` where the replan rebound now resolves `todo` — same class as
this fix, different owner's file); the rest are
executor/CE/goal-anchoring.

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

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 22:38:47 -07:00
gsxdsm
73338502e5 fix(test) + E2E: re-green main's lifecycle release leg, and prove the MERGED board + REVISE rework (#2634) 
**Second batch.** Three commits, no production code. `pnpm test:gate`
green, `pnpm lint` clean, all three E2E suites together **3 files / 41
tests, exit 0**.

## 1. main's lifecycle E2E is RED right now — this fixes it

Independently of my work, on a detached `origin/main`: **2 failed / 18
passed**. Scenarios 1 and 2 fail with `sweep.released` **empty**.

**Cause:** `seedTask` relied on task creation's PROMPT.md, which is a
bootstrap seed (`"# <id>\n\n<description>"`). FN-7648's
`isUnplannedForExecution` reads that file for any card resting in an
intake- **or** hold-trait column and refuses to move an unplanned card
into a processing column. The sweep reported `held: [{ reason:
"move-rejected-or-no-slot" }]`.

**That is the gate working.** The fixture was asking the scheduler to
release a card that had never been specified. The fix is the one the
graph-entry contract doc already prescribes: *"Scheduler/release test
fixtures must model a card that cleared the gate ... A held unreviewed
card is the gate working."* `seedTask` now writes a planned PROMPT.md.

**Verified it repairs main, not just this branch:** applying only that
file to a detached `origin/main` leaves scenarios 1 and 2 **passing**,
with the 4 residual failures being scenarios 3 and 6 — which need the
fixture-options commit main does not have.

### I was wrong in #2627 and this corrects it

In #2627 I named the in-transaction capacity gate (#2488/#2499) as the
likely cause. **It was not.** Two hypotheses died, both recorded in the
code comment so nobody re-runs them:

| Hypothesis | Result |
|---|---|
| E2E settings lack `maxConcurrent` → capacity gate rejects the move |
added `maxConcurrent`/`maxWorktrees` → **still 2 failed**. Not the
cause. |
| the move itself is refused | a direct `moveTask(id, wip)` →
**succeeded**. Never the blocker. |

Only then did probing the two release gates give
`isTaskBlockedOnApproval=false`, `isUnplannedForExecution=true`, and
dumping the file show the stub. I've flagged the wrong lead on #2627 too
— a plausible-sounding cause pointed at another worker's PR is worse
than no lead.

## 2. E2E evidence: the MERGED intake+hold board

U11's shape — one column carrying intake **and** hold — had no
end-to-end coverage; every prior E2E drove intake and hold as separate
columns.

- shared fixture gains opt-in `mergedIntakeAndHold`, plus `MERGED_VOCAB`
(legacy ids, so a failure is attributable to the **role** merge alone)
and `MERGED_RENAMED_VOCAB` (ids move too).
- lifecycle scenario 3 drives the full spine: planning runs **in place**
on the dual-role column, the real `runHoldReleaseSweep` releases
**from** it, the graph runs to complete.
- 4 merge-safeguard cases on the merged board (finalize, proofless
refusal with the same reason, merged+renamed landing no legacy id,
at-most-once).

## 3. E2E evidence: a REVISE routes back through rework

The plan's `InReview → InProgress: review requests changes` had **no**
live-engine evidence on any board — the fixture's review seam always
succeeded.

Two things the engine taught me, both corrected here:
- the **IR validator refused** my rework edge: it is only legal into a
node with `config.reworkRegion: true`. A real contract, and the
validator catching it is the system working. `exec` now declares it (the
shape the builtin uses on `merge-attempt`).
- my first assertion was wrong. A REVISE does **not** leave the card in
wip — rework re-enters `exec` within the same run, review approves on
its second call, and the card finishes at complete. The evidence is the
**seam sequence**
`["planning","execute","review","execute","review","merge"]`, not an
intermediate column the run has already passed. Asserting the final
column alone would have been satisfied by a graph that ignored the
REVISE entirely.

## Both families are mutation-attributed

| Scenario | Mutation | Result |
|---|---|---|
| 3 — merged intake+hold | `isHeldTask` treats intake/hold as exclusive
| **exactly its 2 tests** fail |
| 6 — REVISE → rework | disable rework re-entry in
`workflow-graph-executor` | **exactly its 2 tests** fail |

Both fixture options are opt-in; the two pre-existing suites are
behaviourally unchanged (27 → 29 → 41 passed across the additions, no
existing assertion touched).

## Still not shipped: safeguard 2's graph E2E

Attempted twice, deleted both times. Attempt 1 passed and then survived
mutating `merge-gate` to ignore `task.autoMerge` — the card parked on
the review column's `merge-blocker` trait, not the gate. Attempt 2
removed that trait to isolate the gate, and the **control** case parked
too. Isolating it needs a merge path mirroring the builtin (`merge-gate
→ merge node → end`) rather than a direct edge to `end` — a real
redesign, not a speculative edit. The enforcement that holds today is
`allowInReviewMergeProcessing` in `project-engine` (unit-mutation
verified, NEW=9; gated via #2526).

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 22:23:32 -07:00
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
gsxdsm
89d6d76d60 Unowned: the R7 sweep guessed with another workflow's columns — its "do not guess" guard was unreachable dead code (#2600) 
## Unowned: the R7 sweep's "do not guess a column" guard could not fire

Picked up from my own #2543 finding. Independent of my other PRs.

### The guard existed in comment form only

`reconcileUndeclaredTaskColumns` wraps IR resolution in a try/catch
whose comment reads:

> An unresolvable workflow is its own fault path; do not guess a column.

But `resolveWorkflowIrById` catches **every** failure and returns
`defaultCodingWorkflowIr()`, and `resolveWorkflowIrForTask` does the
same for a failed selection read. The resolver never rejects, so that
catch is **dead code**.

What actually happened to a card whose workflow could not be loaded: it
was judged against the **default** workflow, and if its column was not
one the default declares, the sweep re-homed it to the **default's**
rebound target. It guessed, using a workflow that is not the card's own
— the precise outcome the guard was written to prevent, in a **startup
recovery path that runs against every task**.

### How it was found, which is the part worth keeping

By being **unable to make a test of the guard fail**. Three separate
mutations all passed — deleting the `continue`, deleting the try/catch,
and simulating a whole-sweep abort at that very catch. I had written
that off once as "this case pins the outcome, not the mechanism". The
inability was the signal, not a limitation of the assertion: the branch
is unreachable.

This is the seventh instance of the program's core shape, and the first
I found in a guard I had just finished writing coverage for.

### The fix

The sweep now **proves the resolved IR belongs to the task** before
moving its card: it reads the task's workflow selection and confirms
that id resolves to a real definition (built-in or stored).

- A task with **no** selection legitimately resolves to the default
workflow — not treated as unresolvable.
- An unreadable selection **read** is itself grounds not to guess.

Placed at the **move site**, not at resolution, deliberately: it costs
one definition read only for a card already about to be moved — a
healthy board reaches that line for nobody — and it keeps the fix inside
the sweep instead of changing a resolver whose soft-failure many other
callers depend on. Changing `resolveWorkflowIrById` to reject would have
been the tidier-looking fix and a much wider blast radius.

### Revert-proof, both directions

- Remove the proof → the case fails `expected 2 to be 1`: the unloadable
card is re-homed on a guess.
- The same case asserts the neighbour **is** still repaired, so the fix
cannot be mistaken for letting one bad card disable the sweep for
everyone else. That is the per-task isolation property, and a
single-task fixture cannot distinguish it from a whole-sweep abort —
verified by injecting a throw at the loop head (`expected 0 to be 2`).

### Verification

`pnpm test:gate` (482 + 10 + 71), `pnpm lint`, engine typecheck green.
Sweep suite + `legacy-tombstones`: 13 passed.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Prevented startup recovery from moving cards into incorrect columns
when their workflow cannot be loaded or resolved.
* Cards with unreadable workflow information now remain in place, while
other recoverable cards continue to be repaired correctly.
* Added safeguards to avoid guessing a fallback workflow during column
reconciliation.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 21:21:04 -07:00
gsxdsm
534798dea0 test(U9): E2E evidence for the merge safeguards on a real PG store (completion-bar item 3) (#2615) 
**U9 E2E evidence.** One new `.pg.test.ts`, 6 tests, green. No
production changes. `pnpm test:gate` green — `pgDescribe`-skipped
without PostgreSQL, so the gate is unaffected.

## What this closes

The U9 safeguard baseline verified all six merge safeguards by
**mutation at unit level**. The sibling `workflow-merge-family-live-e2e`
covers exactly **one** end-to-end. This drives
`finalizeProvenAutoMergeTask` — the last move a card makes — against a
real PostgreSQL `TaskStore`, asserting on the **persisted column** read
back after clearing the task cache. Never on "a function was called".

Only the merge **proof** is seeded (`mergeDetails.mergeConfirmed`),
which is what a real merger writes; there's no git and none is needed.
Column resolution, blocker evaluation, the move and its guards, and
persistence are all real. Includes the rename differential, where a
guard keyed on a literal goes silent.

## Three things I expected and measured wrong

Corrected in the file rather than worked around — each is a claim I
would otherwise have shipped:

**1. Dependency gating does not reach this seam.** My first draft
asserted a refusal. A proven-merged card with a live `blockedBy`
finalizes to the complete column anyway. That's coherent: dependency
gating lives in `getTaskCompletionBlocker` and gates whether work may be
*called* complete, while this seam runs after `mergeConfirmed` —
refusing would strand a merged card in review and misreport the
repository without un-merging anything. Now pinned as designed behavior
*with* that reasoning, not filed as a hole.

**2. The at-most-once outcome is `already-done`**, not the
`already-complete` I guessed.

**3. `expect(outcome).toBe("blocked")` cannot attribute a refusal.** The
finalizer has **three layered refusal gates**, and the two proof gates
emit the *same* reason (`missing-merge-confirmation`, also returned by
`validateWorkflowDoneMergeProof`). So removing either one left my
original assertion **green**:

| Mutation | Result |
|---|---|
| remove the durable-proof gate | 6 passed — invisible |
| remove the main-path proof gate | 6 passed — invisible |
| remove **both** | **2 failed** / 4 passed |

Fixed by pinning the **reason**, not just the refusal. The lesson
generalises: single-gate mutation cannot detect redundant
defense-in-depth from outside, so the unit-level attribution in the
baseline doc and this E2E are **complementary**, not duplicative. I
nearly labelled these tests as proving a specific gate they don't.

## Flagged, not changed — safeguard 1 at this seam

Written as open questions and answered by running them. **Both a
`paused` and a `userPaused` proven-merged card are moved to the complete
column.**

For `paused` that's documented design — `auto-merge-finalization.ts:243`
evaluates hard blockers with `paused: false` because the branch already
landed.

For `userPaused` it sits against the invariant re-ratified in #2486:
*never MUTATE lifecycle state of a user-paused card.* The mitigating
argument is the same one — the merge is durable, so the move is
bookkeeping that reflects reality, and refusing would leave an
operator's card permanently misfiled in review.

**Either reading may be right. What was not acceptable is that it was
untested.** Both are now explicit named assertions with the tension in
the comment, so tightening the pause contract becomes a decision rather
than a discovery. Resolution belongs to whoever owns the pause contract
— I'm not quietly changing merge behavior on a paused card.

## Safeguard coverage after this PR

| # | Safeguard | Unit (mutation) | E2E |
|---|---|---|---|
| 1 | user pause | ✅ | ✅ pinned as an exception at this seam — flagged
above |
| 2 | autoMerge:false | ✅ | ✗ gate lives upstream in `project-engine`,
not this seam |
| 3 | dependency gating | ✅ | ✅ pinned as *not* applying here, with
rationale |
| 4 | capacity single-flight | ✅ | ✗ in-memory pump, no store seam to
observe |
| 5 | merge-proof | ✅ | ✅ both vocabularies, reason-attributed |
| 6 | at-most-once | ✅ | ✅ second finalize classifies `already-done`, no
second move |

The two gaps are stated rather than implied: safeguard 2's gate is
`allowInReviewMergeProcessing` in `project-engine`, which needs an
engine harness rather than a store one, and safeguard 4 is an in-memory
single-flight latch with nothing persisted to assert on. Both are
covered by mutation at unit level and both are in the gate as of
#2526/#2569.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 21:20:17 -07:00
gsxdsm
592fd5c0c6 U11 [mission-feature-sync + spec-staleness]: convert the last two planner-lane guards (48 -> 46) (#2610) 
**Taking: `engine/mission-feature-sync.ts`, `engine/spec-staleness.ts`**
— the last two planner-lane guards in my area.

## Census (comment-stripped, `=== "triage"` / `!== "triage"` in
`packages/*/src`, tests excluded)

| file | before | after |
|---|---:|---:|
| `packages/engine/src/mission-feature-sync.ts` | 1 | **0** |
| `packages/engine/src/spec-staleness.ts` | 1 | **0** |
| **repo total** | **48** | **46** |

## Both are real conversions, not seams

Each guard takes its vocabulary from the **caller**, which holds the
store — so unlike a defaulted parameter nothing passes, these can
actually be driven.

**`reconcileMissionFeatureState`** — a card back in a planner lane
returns the mission feature to `triaged`. Keyed on literals, a renamed
workflow left the feature reading `in-progress` forever: the roadmap
claims work is underway while the card waits to be re-planned. Nothing
errors; the rollup is just wrong. The vocabulary arrives via
`MissionFeatureSyncContext` rather than by widening this module's
deliberately narrowed `Pick<TaskStore, "getTask">`.

**`shouldSkipSpecStalenessForPreservedProgress`** — returning `false`
for a planner-lane card is what *keeps* staleness evaluation on. Miss
the lane and it falls through to the preserved-progress branch, so a
card with progress skips staleness and keeps a spec that should have
been re-validated.

## The two take different defaults — and I got it wrong first

I defaulted **both** to the `triage`/`todo` pair and broke the
pre-existing U11 proof in `spec-staleness.test.ts`, which states the
reason exactly:

> same column, different status, opposite correct answer

- **mission-feature-sync → the PAIR.** It asks "is this card waiting to
be planned?", true in either lane.
- **spec-staleness → the DEDICATED planner column only.** On a merged
lineage `todo` is *also* the hold lane, so the planner distinction there
is carried by **status** (`planning` / `needs-replan`), not by the
column. Treating the merged column as a planner lane stops a parked card
with preserved progress from skipping staleness. Its default is now the
single legacy id — byte-identical to the literal it replaced.

That asymmetry is now pinned by its own test rather than left for the
next reader to rediscover.

## Findings on the remaining census, from measuring it

Two of the 46 are **not lifecycle-column guards** and converting them
would be wrong:

- `tool-availability.ts:32` — `surface === "triage"` where `surface:
"triage" | "executor"` is an **agent lane**, not a column.
- `skill-resolver.ts:432` — `sessionPurpose === "triage"`, a **session
purpose**.

Also worth noting for the count: `replan-target.ts` reads as 2 in a raw
grep but is **0** — both hits are inside comments. `board-workflows.ts`
(2) and `archive-planning.ts` (1) are likewise comment-only. A raw grep
says 52; comment-stripped says 46.

## Not wired at the call sites yet

`scheduler.ts` / `mission-autopilot.ts` (mission sync) and `executor.ts`
/ `scheduler.ts` (staleness) still omit the new option, so behaviour is
byte-identical today. Deliberate: `executor.ts` belongs to u8's active
slice and I would rather not create a textual collision for a
pass-through. The seam is proven by tests and the count is real; wiring
is a follow-up.

## Verification

- **Mutation-verified:** restoring either literal fails a test
- 35 tests green across the three suites, merge gate green (482 + 132 +
10), tsc clean, lint clean

No changeset: `@fusion/engine` is private.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-07-29 21:20:09 -07:00
gsxdsm
45e8b5f7ac U8: pin the completion-finalize ordering invariant before moving the last out-of-band exit (#2599) 
Groundwork for moving `paused-after-completion`, the **last**
out-of-band exit. Stacked on #2590.

## What lands

1. **An indentation defect I introduced.** My bulk edit when the exit
vocabulary landed left the second `paused-after-completion` site
mis-indented inside a `finally` block. Cosmetic, but misleading
indentation in a `finally` is how a future reader misjudges scope.

2. **The adjacency ratchet now requires `markCompletionFinalized` before
the handoff, at every reporting site.** It previously checked only the
first occurrence, and only for the handoff itself.

That ordering is the invariant `handleGraphFailure` depends on and
**cannot check for itself**: `alreadyFinalizedToReview` /
`completionFinalized` exist to recognise this out-of-band move when a
later teardown re-marks the abort as `hard-cancel`. Without the durable
marker set first, a completed no-commit task is re-parked `failed` —
FN-6644/FN-6641.

It is asserted **structurally, and labelled as such in the test**. Both
call sites sit in pause and `finally` paths that cannot be driven
without mocking an entire agent session; presenting a source assertion
as behavioural coverage would repeat the overclaim I have been correctly
pulled up on twice in this unit.

Red-green: removing `markCompletionFinalized` from either site fails the
ratchet.

## Why the move itself is not in this PR

`paused-after-completion` is structurally harder than the pending-review
ending that #2590 moved, and the difference is worth recording before
someone assumes it is a copy-paste:

- it does **four** things, not one — `markCompletionFinalized`,
`handoffTaskToReview`,
`clearCompletedTaskWatchdog`/`signalTaskComplete`. Only the handoff is
lifecycle; the rest is substrate that must stay put.
- one of the two sites is inside a **`finally`**. Moving a transition
out of a `finally` is not the same operation as moving one out of a
branch: the graph may already be unwinding, so "report and let the graph
route" needs a defined answer for a run that is already ending.
- there is **no behavioural coverage of either site today** — the
closest tests only exercise the exit vocabulary. The pending-review move
succeeded on the fourth attempt precisely because FN-5436 existed to
catch each wrong version; this exit has no equivalent, so the move needs
that floor built first, and building it means real session mocking
rather than a shortcut.

## Verification

- exit-events + primitive-exit-events + step-session + ownership ledger
— green
- `pnpm lint` clean; `tsc --noEmit` clean
- No user-facing behaviour change, so no changeset

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

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **Bug Fixes**
  - Improved handling of workflow steps that pause for review.
- Tasks now remain in review when a review request has no subsequent
decision.
  - Added clearer completion events for primitive prompt steps.
  - Preserved correct failure handling when later workflow steps fail.

- **Workflow Improvements**
- Built-in workflows now route pending reviews through a dedicated
review handoff.
- User-authored workflows retain compatible review parking behavior when
routing is unavailable.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 21:04:39 -07:00
gsxdsm
3f763cba87 U8: the graph owns the pending-review park — ownership ledger 28 → 27 (#2590) 
The routing move this unit has been building toward, landing on the path
the engine actually runs. **Includes #2578's commit** (the live-path fix
it depends on) — merge that first, or this supersedes it.

## What changes

Three things together, because a half-routed move is a card that
silently does not advance:

1. The **live** implementation primitive (`runCodingSession`) returns
`{outcome: "failure", value: "review-pending"}` for that ending.
2. The primitive step handler stops flattening every ending to
`step-done`/`step-failed`, so the value survives the foreach —
`runForeach` propagates a failing instance's value as the node's own —
and reaches an edge.
3. The inline `handoffTaskToReview` in `runImplementation` is
**deleted**. The phase reports and stops, which is all an implementation
phase should do.

Built-in workflows route to the `review-pending-handoff` node added in
#2519/#2546, which performs the handoff and ends the run: the same two
effects in the same order, with the graph as the owner.

## Proof, end to end

FN-5436 — the test that blocked this move twice and was right both times
— now passes, with a **stronger** assertion than it had:

```ts
expect(store.moveTask).toHaveBeenCalledWith("FN-5436-B", "in-review",
  expect.objectContaining({
    workflowMoveSource: "workflow-graph",
    workflowMoveMetadata: expect.objectContaining({ nodeId: "review-pending-handoff" }),
  }));
```

The old two-argument `moveTask(id, "in-review")` could not distinguish a
graph-owned park from an out-of-band one — which is the entire
distinction this unit exists to make. The invariant (park in review,
never `failed`) is unchanged; the owner is now proven.

## Every ratchet fired, and each records a real change

| Ratchet | Before | After | Why |
|---|---|---|---|
| Ownership ledger — `runImplementation` review handoffs | 3 | **2** |
the handoff left the phase |
| Ownership ledger — `handleGraphFailure` | 0 | **1** | the named compat
classifier |
| Ledger headline — executor-owned dispositions | 28 | **27** | first
decrement of the unit |
| Out-of-band exit list | 2 | **1** | pending-review is graph-owned now
|
| Primitive routing pin | "must not reroute" | routes *only* the moved
ending | declared, not discovered |

None was relaxed. The `handleGraphFailure` 0 → 1 is the honest one: for
a user-authored graph without the edge this is a **relocation, not an
elimination** — the transition is still executor-performed, but from one
named classifier in the failure ladder rather than a call buried two
thousand lines into a session loop. The ledger says so rather than
letting the headline number imply more progress than there is.

## Why it took four attempts

Recorded because the reason is reusable: the value was being produced on
`createAuthoritativeWorkflowSeams`, a handler that never runs (#2578).
Every earlier attempt was correct code on a dead path, and the only
thing that showed it was instrumenting until a negative result was
proven observable rather than assumed.

## Verification

- step-session + exit-events + primitive-exit-events + ownership ledger
+ graph-requeue-gate + task-done-blocked — **83 tests green**
- `pnpm test:gate` green (10 / 482 / 71); `pnpm lint` clean; `tsc
--noEmit` clean
- Changeset included (`patch`, `internal`)

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

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Bug Fixes**
* Improved handling of tasks awaiting review so they are correctly
routed to the review workflow.
* Tasks now remain in review instead of being marked as failed when no
follow-up review route is configured.
* Review handoffs now include workflow ownership and provenance details.
* Preserved standard failure handling for tasks that are not awaiting
review.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 20:59:06 -07:00
gsxdsm
d5f1ce7abd U11 [writes]: stop CREATING cards into a column the workflow no longer declares (9 -> 0, engine+cli) (#2603) 
**Taking: `engine/triage.ts`, `engine/pr-comment-handler.ts`,
`engine/eval-followups.ts`, `cli/commands/task.ts`, `cli/extension.ts`**
(write class — no collision with the comparison backlog).

## A class the census does not count

The 48-guard work list tracks `=== "triage"` **comparisons**. These are
`column: "triage"` **writes** — and post-#2515 every one creates a card
directly into the state STALL 3 was about, except **manufactured
continuously** rather than left behind by the upgrade.

## Why they bite

`createTaskImpl` resolves the column as:

```ts
column: input.column || options?.resolvedEntryColumn || fallbackIntakeColumn || "triage"
```

`input.column` **wins**, so an explicit `column: "triage"` overrides the
workflow's resolved intake column entirely.
`store-create-intake-column.test.ts` already pins that a create with
**no** column lands in the default workflow's intake (now `todo`) —
these callers opted out of it.

The sharpest is `triage.ts`'s `fn_task_create` agent tool: it passed
`workflowId: params.workflow_id` **and** `column: "triage"` in the same
call. The caller chose a workflow and the column ignored it — a Coding
(Ideas) create landed in `triage` instead of `ideas`.

## Counts

**Comparison guards: unchanged by this PR.** This is the write class;
conflating the two would misreport convergence toward the zero bar.

| file | `column: "triage"` writes before | after |
|---|---:|---:|
| `packages/engine/src/triage.ts` | 1 | **0** |
| `packages/engine/src/pr-comment-handler.ts` | 1 | **0** |
| `packages/engine/src/eval-followups.ts` | 1 | **0** |
| `packages/cli/src/commands/task.ts` | 3 | **0** |
| `packages/cli/src/extension.ts` | 3 | **0** |
| **total** | **9** | **0** |

## A test that pinned the defect

`pr-comment-handler.test.ts` asserted `column: "triage"` in the
createTask call — so it would have **failed the fix and passed the
bug**. Rewritten to assert the invariant (the caller passes no column,
so the workflow's intake wins) plus an explicit `Object.hasOwn(arg,
"column") === false`, which is what actually catches a reintroduction.

## Interaction with #2591

My merged #2591 rescues these cards once created — they sit on a legacy
planner id their workflow doesn't declare and are still in planning
stage. So this isn't a *visible* stall today; the rescue absorbs it.
**That's the reason to fix it rather than leave it:** a self-healing
path silently absorbing a steady stream of malformed creates is exactly
how the underlying defect stays invisible.

## Deliberately not touched

- `{ id: "start", kind: "start", column: "triage" }` in the builtin
coding / PR / lead-generation IRs — workflow-internal **node
declarations** for workflows that still legitimately declare a `triage`
column, not lifecycle writes.
- Left for their owners: `core/task-store/project-store-ops.ts:210`,
`core/task-store/update-task-deps.ts:111` (main worker),
`dashboard/src/routes/register-gitlab.ts:108` (u12). Same defect, same
one-line shape.

## Verification

- 304 engine/CLI tests green across the affected suites
- merge gate green (482 + 132 + 10), engine + CLI tsc clean, lint clean

No changeset: `@fusion/engine` and `@fusion/core` are private; the CLI
change is a bug fix with no user-facing API change — happy to add one if
you'd rather it appear in release notes.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-07-29 20:58:52 -07:00
gsxdsm
9c1c6f7479 docs(engine): close the unproven-sites ledger — one entry was wrong, the rest need two named lanes (#2544) 
Comment-only change to the ledger. No test or production code moves.

## Why this is a PR and not a note

The ledger is the artifact that keeps *"the E2E covers the conversion"*
honest. It gets the same treatment as the code: claims verified by
mutation, not by reading.

## Correction: one entry was wrong

`core/task-store/reads.ts` was listed as **unproven**. It isn't. Core's
`store-stale-paused-renamed-hold.pg.test.ts` is a real-store test that
drives `listTasks` against a renamed hold column — and forcing the
hydration back to the `todo` literal **fails exactly that file's renamed
case**.

I had listed it as unproven because I assumed a separate E2E was needed.
Verified *before* removing it, since "already covered somewhere else" is
precisely the assumption that lets a gap hide.

## What remains, and why it is not another table row

**Lane 1 — real git.** `merger.ts`'s `resolveMergerLifecycleColumn` and
`executor.ts`'s `resolveReboundColumnFor` are module-private helpers
whose only callers sit inside merge/session machinery needing a real
worktree, branch and squash; `merger-ai.ts` is the same. Re-checked with
the lens that freed `auto-merge-finalization` and both self-healing
rebounds — **these genuinely need the lane.** The earlier over-broad
claim doesn't retroactively excuse them.

**Lane 2 — dashboard HTTP.** The four `register-task-workflow-routes`
sites sit behind `registerTaskWorkflowRoutes(ctx, deps)`, needing a full
`ApiRoutesContext` plus twelve injected deps. Standing that up is the
mock-the-world shell FN-5048 says not to add. The narrower alternative —
exporting the two private resolvers — yields **unit** evidence while
looking like E2E.

Deliberately not done rather than done badly and overclaimed.
`live-agent-count`'s `columnIsIntakeOrHold` is the same lane: only the
*waiting* predicate reads it, and its consumers are dashboard-side.

## Running total

**10 of 15 census sites proven end to end** across six suites; 5 remain,
each named with the lane it needs.

## Verification

- lifecycle suite 20/20; engine `tsc --noEmit` clean; `pnpm test:gate`
green (414 + 10 + 71)

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

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Tests**
* Updated end-to-end test coverage documentation to accurately reflect
verified workflow and task-store behavior.
* Clarified coverage gaps for live agent-count logic and dashboard
workflow routes.
  * Added a two-lane breakdown describing remaining coverage work.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 20:56:04 -07:00
gsxdsm
c9df4b9dee U11 migration proof: the path an operator actually hits, with all three caveats answered (#2597) 
Tests only. Proves the upgrade path the existing E2E does not cover, and
answers the three caveats.

## Why the existing coverage was not enough

The existing cases strand a card in a synthetic
`a-column-no-workflow-declares` on a **fixture** vocabulary. The real
upgrade leaves cards in **`triage`**, on the **real `builtin:coding`**
workflow.

That difference is the whole point: `triage` is still a legal `ColumnId`
and is still declared by legacy-coding, Ideas and every linear built-in
(R11), so nothing rejects it and **nothing throws**. The card simply
sits in a column its *own* workflow no longer declares — where it
carries no trait flags and is invisible to every trait-driven sweep.

## What is proven, on a temp PostgreSQL project

- A card left in the deleted `triage` column on a default-workflow board
is re-homed to `todo`, the merged Planning column.
- **Revert check in-suite:** without the sweep running, the card stays
in `triage`. Without this, the case above could pass because some
*other* sweep or a store-open reconcile moved the card — and would keep
passing if the sweep were deleted outright.
- **Progress and the plan artifact survive.** `preserveProgress: true`
is asserted end-to-end rather than trusted from the option name.
- A `userPaused` card is skipped and stays in the deleted column.

**Mutation-verified:** stubbing `reconcileUndeclaredTaskColumns` to
`return 0` turns **5 of 11** tests red, including all three positive
migration cases. The sweep is demonstrably the mover.

## The three caveats — answered

**1. `userPaused` cards are skipped → caveat, not a stall.**
An operator park is authoritative and the sweep must not override it, so
the card does stay in a column its workflow no longer declares. But it
is reachable two ways: unpausing makes the next sweep re-home it, and
**U11's undeclared-source escape hatch in `resolveAllowedColumns`
(merged with #2515) lets an operator move it by hand meanwhile** — that
path returns the workflow's rebound target instead of `Valid targets:
none`. Recorded as a test so the behaviour is a decision rather than an
accident.

My recommendation: **leave it skipped.** Re-homing a paused card
silently moves work an operator deliberately froze, and the escape hatch
already gives them a way out. Overriding a park to fix a column is the
wrong trade.

**2. Sweep only runs when self-healing is enabled → caveat, not a stall,
for the same reason.**
The escape hatch lives in the **move-validation** path, not in
self-healing, so it works with self-healing off entirely. A card
stranded that way is draggable out of the deleted column by hand. Worth
knowing: before #2515's escape hatch this *would* have been a hard stall
— `resolveAllowedColumns` returned `[]` for an undeclared source, so the
card could not be moved anywhere at all, by anyone.

**3. Re-home targets the HOLD column → correct, and progress survives.**
Under U11 the hold column **is** the Planning column, so "everything
lands in Planning" is the intended destination rather than a compromise.
Asserted with real step progress on the row.

**None of the three is worse than a caveat.** The reason all three are
survivable is the same single mechanism — the undeclared-source escape
hatch — which is worth knowing because removing it would silently
promote all three to hard stalls.

## Incidental

Fixed two fixture-level PostgreSQL column-name errors found while
writing this: `currentStep` → `current_step`, and `user_paused` is an
**integer** flag rather than a boolean. Both would have made a future
test here fail confusingly.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 20:31:15 -07:00
gsxdsm
131feb243c U8: the exit announcement was on a dead code path — move it to the handler the engine actually runs (#2578) 
A merged behavior of mine has never executed. This fixes it and adds the
ratchet that would have caught it.

## The finding

`createDefaultNodeHandlers` chooses the prompt-node handler like this:

```ts
const promptLike = deps?.primitives
  ? createPrimitivePromptLikeHandler(deps.primitives, runCustomNode)
  : createPromptLikeHandler(seams, runCustomNode);
```

`executeWorkflowGraph` always passes `primitives:
this.createAuthoritativeWorkflowPrimitives(settings)`
(`executor.ts:6051`). **So `createPromptLikeHandler` — and with it every
`execute` / `step-execute` function in
`createAuthoritativeWorkflowSeams` — is unreachable for prompt nodes.**
Both objects are passed to the graph executor and only one is consulted.

The `NodeCompleted.exit` announcement added in #2507 was wired into that
seam. It type-checks, its tests pass (they call the seam object
directly), and it has never run in production. `runCodingSession` in the
primitives is the live twin, and that is where it emits now.

## How it was found — and why the negative is trustworthy

Instrumenting `createAuthoritativeWorkflowSeams.stepExecute` produced no
output for a run that demonstrably visits `steps#0:step-execute`. So did
instrumenting `createPromptLikeHandler`'s dispatch. A negative result
from instrumentation is worthless until the instrumentation is shown to
be observable, so: a `process.stderr.write` at module load of the same
file **did** appear, exactly once, in the same run. The two negatives
were real, not swallowed output.

This is also the answer to the open question I left in #2546 — the
pending-review routing move kept failing because the seam value it
depends on is never produced. **That move is still not landed here.**
This commit only relocates the announcement, so it stays small and
separately revertable; the routing move follows once its value
originates on the live path.

## The ratchet

A source assertion pins the dispatch rule: `deps?.primitives ?
createPrimitivePromptLikeHandler` and the executor's wiring of
`primitives`. Inverting or conditionalising that preference would
silently disable every behavior attached to the primitives path — the
same failure in the other direction — and **a seam-level unit test
cannot tell the two apart**, which is precisely how this survived review
twice.

## Red-green

Removing the emit fails 2 of the 4 new tests (`Tests 2 failed | 2 passed
(4)`). The other two are the regression floor: an ordinary completion
emits `success` with no `exit`, and the returned routing outcome is
unchanged — announcing must not reroute.

## Scope note

I did **not** delete the now-known-dead seam wiring in this PR.
`createAuthoritativeWorkflowSeams` is still passed to the graph executor
and its non-prompt entries (`stepReview`, `merge`) are reached through
other handlers, so deciding what is genuinely dead there is a deletion
audit of its own — and this program's rule is that deletions never ride
along with behavior changes. Filed as the next slice.

## Verification

- 4 new tests + exit-events + step-session + triage audit + ownership
ledger — **54 tests green**
- `pnpm test:gate` green (10 / 414 / 71); `pnpm lint` clean; `tsc
--noEmit` clean
- Changeset included (`patch`, `fix`)

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 20:30:54 -07:00
gsxdsm
2aa68867e5 U11 follow-up: usage-limit parking silently stopped covering the planning lane (#2567) 
Second of the 39 audited `triage` sites from #2515's safety audit.
Unlike the first, this one is **real breakage**, not a proof of safety.

## The defect

The usage-limit pauser decides which tasks are on a rate-limited
provider by asking, per lane, whether the card sits in that lane's
column. The **planning** lane asked for the literal `triage`.

Now that Todo is merged into Planning, a card being planned on the
default workflow rests in `todo`. The branch resolves to an empty
provider list, so the card is not recognised as using the planning
provider — and is **neither parked when that provider hits its limit nor
resumed when it recovers**. It runs into the limit and fails.

Silent by construction: the detector reports nothing, it simply matches
no tasks.

## The test caught my own first attempt at testing it

The initial version asserted on the task that **triggered** the
usage-limit hit — and **passed against unfixed code**, because the
trigger is always parked directly without consulting `taskUsesProvider`.
Only a **bystander** card reaches the lane/column branch.

All three assertions now use a separate trigger, and the comment says
why, because the obvious test shape is the one that proves nothing.

## Why a paired literal rather than trait resolution

`taskUsesProvider` is a synchronous predicate over a task and settings,
with no IR in scope and no call site that could supply one without a
signature change reaching several callers.

Both ids name a pre-implementation column in every built-in — `triage`
for the split shape, `todo` for the merged one and for Coding (Ideas) —
so the pair covers the planning lane in all of them. Flagged for U12's
ratchet allowlist with that reason attached.

**Over-inclusion is the safe direction and is deliberate.** On a split
workflow a `todo` card is capacity-parked rather than actively planning,
so it may now be parked during an outage it was not using. Parking one
extra idle card is recoverable; failing to park a card whose provider is
rate-limited is not.

Regression direction asserted: widening the **column** match must not
widen the **provider** match — a planning card on a different provider
is still not parked.

## Audit progress

39 exclusive `triage` sites (from
`docs/solutions/architecture-patterns/u11-triage-literal-safety-audit.md`,
merged in #2515):

| status | sites |
|---|---|
| proven safe as-is | `spec-staleness.ts` — the guard is carried by
**status**, not column; the mechanical conversion was tried and is
*wrong* |
| confirmed safe by inspection | `mission-feature-sync.ts` (already
OR-pairs), `TaskContextMenu.tsx` (already trait-paired) |
| **fixed here** | `usage-limit-detector.ts` |
| remaining | 35, with the owners named in the audit |

Gate 309/309, lint clean.

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

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 20:30:47 -07:00
gsxdsm
b0b9614fd5 U12 part 10: pin the R7 undeclared-column sweep — the repair three earlier PRs cited had no test of its own (#2543) 
## U12 part 10 — the R7 sweep everything else leans on was itself
unpinned

`reconcileUndeclaredTaskColumns` re-homes a card resting in a column its
workflow no longer declares. It is the shipped answer to **R7**, and it
is the reason several earlier U12 deletions were safe — I cited it when
deleting the superseded `runWorkflowColumnsIntegrityPass` (#2500), and
again when arguing that a torn workflow switch leaves *recoverable*
state (#2512).

Its only coverage was **incidental**: two live PostgreSQL e2e suites
that exercise it in passing. A repair the rest of the unit leans on had
no test of its own — a guarantee everyone cites and nobody checks, which
is the exact shape this unit keeps finding.

### Six cases

The plan names three scenarios for U12; those are the three ways this
sweep can be wrong, plus I added the over-fire direction:

- repairs the stranded card to its workflow's **own** rebound target
(not a hardcoded legacy id)
- leaves a **user-paused** card alone
- leaves an **unresolvable-workflow** card alone
- is **idempotent** — a second run does not move the card again
- ignores a card already resting in a declared column
- repairs one stranded card **without disturbing** healthy or paused
neighbours

The leave-alone cases matter more than the repair. A sweep that
over-fires rewrites an operator's board, and this one runs at startup
against every task.

It also asserts `recoveryRehome: true` explicitly, because that flag is
load-bearing rather than incidental: the stranded card's *source* column
is undeclared too, so adjacency resolves to `[]` and every target is
rejected without it. Its absence once made this sweep a repair that
never repaired anything (#2462).

### Mechanism coverage — measured, and one case that isn't

Verified by mutation rather than asserted:

| mutation | result |
|---|---|
| delete the user-pause guard | **2 cases fail** |
| delete the already-declared short-circuit | **2 cases fail** |
| delete the unresolvable-workflow `continue` | still green |

That last row is stated at the assertion rather than hidden. The
unresolvable-workflow case pins the **outcome**, not the mechanism:
every mutation I could construct — dropping the `continue`, dropping the
try/catch so the throw reaches the outer handler — also ends in "no
move". So it is a regression guard on observable behaviour, not proof
the specific guard is reached, and I am not claiming otherwise.

### A decision I made

Store double rather than PostgreSQL. The sweep's decisions are pure
functions of the task list and the resolved IR, and a double makes the
"did **not** move" assertions exact rather than inferred from an absence
of change. It also keeps the suite off the slow lane, per the standing
rule against adding slow tests.

### Verification

`pnpm test:gate` (414 + 10 + 71), `pnpm lint`, engine typecheck green.
New suite: 6 passed.


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Tests**
* Added coverage for automatically restoring tasks stranded in
undeclared workflow columns.
* Verified paused tasks, unresolved workflows, and tasks already in
valid columns remain unchanged.
  * Confirmed repairs are idempotent and affect only the intended task.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 20:30:27 -07:00
gsxdsm
88c7502eae test(engine): prove the recovered-lease rebound AND its audit on a renamed board (#2539) 
Test-only. Sixth E2E family. Closes the `mesh-lease-manager` ledger
entry.

## Two things to prove, and only one is where the card lands

The conversion note records the defect precisely:

> They were previously two independent `=== "todo"` comparisons that
could disagree, which is how **the audit came to claim a card landed in
`todo` when the workflow has no such column**.

1. the card rebounds to the renamed workflow's own rebound column
2. the unreachable-owner **audit** reports the column the card actually
reached

**(2) is the half that rotted silently, and it is the worse one.** The
audit is what an operator reads to find out where a recovered card went.
Confidently wrong is worse than absent — and on a renamed board it named
a column the workflow does not even declare.

## One thing deliberately NOT renamed

`decisionPath` keeps its legacy `lease-recovered-to-todo` wording. The
code explains why: it is a stable discriminator that existing queries
and dashboards match on, and renaming it would break them in order to
describe the same decision. The column actually used travels in
`newColumn`.

I've pinned that split with an explicit assertion so a future vocabulary
"cleanup" cannot quietly rename a field that **is not a column at all**.
Stating it here so it reads as a decision rather than an oversight.

## Mutation-verified

Forcing the legacy literal fails **exactly the three renamed cases**,
leaving the default-vocabulary floor and the fresh-lease negative green.

## Negative half

A lease renewed just now is not recoverable — "rebound anything with a
checkout" would tear live work off its owner.

## Fixture guard

The stale-lease seed writes lease bookkeeping through the admin client
and then **asserts the seed took effect**. A silently-dropped write
would make the recovery look correctly declined — the same trap that
produced a vacuous paused-park test earlier in this program, so it is
now guarded by default.

## Verification

- six live-E2E suites green together: **58/58**
- engine `tsc --noEmit` clean
- `pnpm test:gate` green (414 + 10 + 71)

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 20:30:19 -07:00
gsxdsm
a68785a41d P0: two silent triage guards in the executor's ownership — one strands a card with nothing to rescue it (#2572) 
P0 audit of the executor's assigned `triage` sites after the
Planning-column merge. **One of them can strand a card**, so leading
with that.

## The stall — `handleDepAbortCleanup`

`executor.ts` moved a dependency-aborted task to the **literal**
`triage`. The default coding lineage no longer declares that column.

A card that gains a dependency mid-execution has its work discarded and
is then parked in a column its own workflow does not define. Nothing in
the graph routes a card out of an undeclared column. The only rescue is
`reconcileUndeclaredTaskColumns`, which runs on the **next engine
start** — so between the abort and a restart the card is stalled with no
automatic recovery. It does not throw, so it would have surfaced as a
user report, not a red test.

Fixed to `resolveReboundColumnFor`, the helper the other ~16 executor
rebounds already use.

## The silent skip — `UsageLimitPauser.taskUsesProvider`

The planning lane was identified by the same literal. For a default card
the lane resolved to **no providers**, so when a provider hit a usage
limit during a *planning* session, the fan-out that pauses peers on that
provider skipped every default-workflow card and they kept hammering the
rate-limited provider.

Not a stall: the triggering task is still paused by the explicit
fallback below the filter. What was lost is blast-radius containment. A
planning session runs while the card is pre-implementation, and the
caller has already excluded `done`/`archived`, so that is exactly "not
the implementation column and not the review column" — which matches
`todo`, `triage`, `ideas`, and a renamed planner alike.

## Full audit table for my assigned sites

| Site | (a) Still fires for a default card? | (b) What silently stops |
(c) Action |
|---|---|---|---|
| `executor.ts:16395` `moveTask(id, "triage")` | **No** — writes an
undeclared column | Card parked where nothing routes it; rescue only at
next engine start | **Fixed** — `resolveReboundColumnFor` |
| `usage-limit-detector.ts:126` `column === "triage"` | **No** |
Usage-limit fan-out skips every default card; peers keep hitting the
limited provider | **Fixed** — pre-implementation predicate |
| `executor.ts:3409` `from === "todo" \|\| from === "triage"` | **Yes**,
via the `todo` arm | — | Unchanged; `triage` arm still live for
legacy-coding |
| `executor.ts:4951` `originColumn === "todo" \|\| === "triage"` |
**Yes**, via the `todo` arm | — | Unchanged |
| `executor.ts:4963` `originColumn === "triage"` double-hop | No, and
correctly so | Nothing — the extra hop exists only for shapes that
declare `triage` | Unchanged; still required by legacy-coding |
| `executor.ts:1110` `Type.Literal("triage")` | n/a | — | **Not a
column** — an agent ROLE in `spawnAgentParams` |

Counts for my ownership: **6 sites audited, 2 defects, 2 fixed, 3
correct as-is, 1 false positive.**

## Red-green

Reverting each fix fails its own test:

```
Tests  2 failed | 2 passed (4)
  × dependency-abort cleanup requeues to a DECLARED column
  × usage-limit fan-out … pauses a peer card sitting in the merged Planning column (id `todo`)
```

The other two are the regression floor and pass both ways by design: a
legacy workflow that **does** declare `triage` still fans out, and an
in-progress card is still **not** swept into the planning lane (the
guard must stay narrow — "any non-wip column" would have been the easy
wrong fix).

## Verification

- New audit suite + graph-boundary + step-session + ownership ledger —
**45 tests green**
- `pnpm test:gate` green (10 / 414 / 71); `pnpm lint` clean; `tsc
--noEmit` clean
- Changeset included (`patch`, `fix`)

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 19:03:10 -07:00
gsxdsm
beb33b5dd1 P0 STALL 3: rescue cards stranded in a column their workflow no longer declares (fixes 8 red tests on main) (#2591) 
Based on `main`. **Fixes STALL 3 — and it needs no data migration.**

## The stall

#2515 removed `triage` from the default lineage while leaving the id
legal for stored rows, and shipped **no migration**. Planning discovery
resolves a card's lanes from its own workflow, and for a default card
`intake` and `hold` **both** resolve to `todo` — so a card *sitting* in
`triage` matched neither branch and was admitted by nothing.

`triage` was the default intake column before #2515, so **every existing
project has cards there.**

Nothing else rescued them. #2515's escape hatch makes an undeclared
source column resolve to the workflow's rebound target, but every path
that *uses* it (executor, agent-heartbeat, merger) is triggered by
**active work**, and a parked card has none. The card sat until an
operator dragged it by hand.

## Proof this is a real regression, not a stale test

**8 tests in `triage.test.ts` were RED on clean `origin/main`** —
verified by swapping main's `triage.ts` into this tree and re-running.
**All 8 pass with this change.** The sharpest:

```
expected "specifyTask" to be called 4 times, but got 0 times
```

Discovery was admitting zero triage cards.

## The fix

A card resting on a legacy pre-implementation id that its own workflow
no longer declares is **unowned by construction** — no lane's rules
apply to it. Admitting it to **planning** heals it through the normal
path: it gets planned, and finalize releases it to the workflow's hold
column, **re-homing the row as a side effect of ordinary work**. No
migration, no backfill, no operator action.

## The narrowing is the load-bearing part

My first version rescued **any** undeclared column, and it was wrong. A
card can also sit in a column its workflow genuinely owns while the
**selection** fails to resolve — the resolved default IR then doesn't
declare that column either. That version re-specified a parked Coding
(Ideas) `ideas` card, breaking **FN-7596's manual-intake rule** (an
ideas card is promoted by an *operator*, never auto-planned).

`triage.test.ts` caught it. The rescue is now scoped to the legacy
planner ids, so a workflow-specific column name is never second-guessed.
That distinction — healing #2515's orphans vs. overruling a workflow
about its own board — is the whole design.

## A user-pause hole this would have opened

`couldBeCandidate` screens `paused` but not `userPaused`, so a row
carrying `userPaused` alone slipped through. Harmless before (an
undeclared-column card was admitted by nothing) and **reachable the
moment admission widens**. Planning a card mutates its lifecycle state,
which the ratified safeguard forbids for a user-paused card — so the
guard is now explicit rather than inherited. Covered by a test and
mutation-verified.

## Cost

Resolution now derives roles **and** declared column ids from one
`resolveWorkflowIrForTask` call, replacing
`resolveTaskLifecycleColumns`. Same call, same `irCache`, same bounded
concurrency window — **cost unchanged**, no added read.

## Verification

- **Mutation-verified three ways**, each failing a different test:
remove the rescue; widen it back to any undeclared column; drop the
user-pause guard
- 8 previously-red-on-main tests now green
- 263 triage/scheduler tests green, merge gate green (482 + 10 + 71),
tsc clean, lint clean

## What this does NOT do

It does not re-home rows that are past the planning stage. Admission
still requires `isTaskStillInPlanningStage`, so a card that advanced
past planning in an undeclared column stays with self-healing's
advanced-recovery sweep rather than being re-specified here. If such
rows exist and are also stranded, that is a separate sweep and a
separate PR.

No changeset: `@fusion/engine` is private.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-07-29 19:02:55 -07:00
gsxdsm
cf7b1a3d46 Drift review (unowned): gridlock detection + autopilot retries resolve the hold column — main 103→101 (#2561) 
> **Based on `main`, not on my U7 stack** — merges in any order, no
dependency on #2517.

My assigned files (`triage.ts`, `replan-target.ts`) are at zero, so this
picks up two lifecycle-column literals **no unit's file list claims**.
Both ask *"is this card in the hold column?"* by the id `todo`, and both
are broken **today** for any workflow that renamed it.

## gridlock-detector — the worse of the two

`column !== "todo"` decides which cards count as **schedulable**, and an
empty schedulable set is an **early return**. On a renamed board the
detector concluded *"no gridlock"* at exactly the moment a real one
would be visible.

> A detector that goes quiet on the boards it cannot parse is worse than
one that is absent, because its silence reads as health.

**Converting only the `todo` half would have shipped a still-broken
detector**, and the test caught it. The `active` filter is equally
literal (`in-progress` / `in-review`) — and an empty active set is
*also* an early return. Two literals, one silence.

The `in-progress` half sits **outside the drift review's `todo|triage`
pattern**, which is precisely why a count-driven sweep would have left
it behind and declared the file done. Converted here rather than
deferred as out of scope. Worth flagging to the other workers: the
convergence metric is a good *tracker* but a bad *definition of done* —
an adjacent literal in the same predicate can preserve the whole bug at
a lower score.

## mission-autopilot

The retry compared against `todo` **and moved to the literal `todo`** —
so on a renamed workflow it relocated the card into a column the
workflow may not declare (R7) on **every retry**. Now resolves the hold
role; when the workflow declares none it leaves the card in place and
says so, because the error/status clear still runs, so the retry is not
lost — the card just stays in its own lane.

## Two fixture defects of my own, both caught by the tests failing
wrongly

**My first autopilot tests re-implemented the decision** and asserted on
the copy — proving only that the copy works. That is the anti-pattern
named in
`docs/solutions/store-fake-defects-that-masquerade-as-production-bugs.md`
(#2534) and in the #2527 ratchet review, and I had no excuse: the
constructor takes two stores and `handleTaskFailure` is public.
Rewritten to drive the real method.

**My first gridlock fixture failed on both vocabularies** — the detector
needs three preconditions and I supplied one. A test that fails on its
*no-regression* half is a broken fixture, not a discovered bug. The
"both halves failed" heuristic from that same doc is what flagged it.

That is eight fixture defects across this unit, every one caught by
reading *why* a test failed rather than making it pass.

## Revert proofs, each isolated to one literal

| Restored | Result |
|---|---|
| gridlock hold filter | **1 of 5 fails** (renamed case) |
| autopilot move target | **1 of 5 fails** (renamed case) |

Default-vocabulary halves pass either way — the correct signature for
conversions that change no existing behavior.

## Convergence

Measured against `origin/main` with a comment-stripped scan of `column
=== / !== "todo" | "triage"` in `packages/*/src`, excluding tests:

**103 → 101.**

(The gridlock `active` filter is a third site fixed here that this
pattern does not count.)

## Verification

| Check | Result |
|---|---|
| new suite | 5/5 |
| pre-existing gridlock + autopilot suites | 85/85, **no expectation
edits** |
| `tsc --noEmit` (engine) | clean |
| `pnpm lint` | clean |
| `pnpm test:gate` | green (414 + 10 + 71) |
| `pnpm check:changesets` | clean |

## Still unowned after this

`mission-feature-sync.ts` (1: a planning-lane check) and
`auto-claim-snapshot.ts` (1: `isRunnableAutoClaimCandidate`, a **pure
sync** predicate that needs the injected-lane pattern from #2551, not a
resolve). `notification-service.ts` has one more with a different
semantic — *"has progressed past"* — which needs its own thinking rather
than a mechanical swap. I will take these next unless someone claims
them.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 10:54:35 -07:00
gsxdsm
bbaa254dc3 test: add the missing debug to 27 logger mocks (206 → 4 failures) (#2573) 
**Test-infrastructure fix.** 29 test files. No production code, no
altered assertions, no widened timeouts.

Now **3 commits** (#2584 merged into this branch): the logger-mock
sweep, a cron-runner follow-up from review, and the 4 residual failures
the sweep deliberately deferred.

**Whole branch: 764 tests, 0 failures** across the touched set.

---

## Commit 1 — the missing `debug` on 27 logger mocks

`createLogger`'s real shape is `{ log, debug, warn, error }`. 27 engine
test files mock `../logger.js` with logger-shaped literals that **omit
`debug`**, so any production path reaching `log.debug` threw:

```
TypeError: schedulerLog.debug is not a function
TypeError: runtimeLog.debug is not a function
TypeError: log.debug is not a function      (SelfHealingManager.start)
```

Measured, same commit, same 27 files:

| | Failed | Passed |
|---|---|---|
| before | **206** | 558 |
| after | **4** | 760 |

**202 failures fixed by one missing mock export.** Per-file: `notifier`
36→0, `plugin-runner` 56→0, `grok-runtime-routing` 14→0,
`self-healing-completion-fanout` 1→0. That last one also leaked an
unhandled rejection out of `startMaintenance`, which vitest warns "might
cause false positive tests" elsewhere in the file.

*A note on the number:* a full `engine-default` run went 283 → 106
across my two sessions, but `main` moved in between (U11 landed), so
that spread is **not** attributable here. 206 → 4 is the honest figure:
same commit, same file set, only this diff varying.

## Commit 2 — cron-runner's factory (greptile P1)

My regex required `log: vi.fn()`; `cron-runner.test.ts` uses `log:
cronLoggerSpies.log`, so the `createLogger` factory's returned literal
never matched and the logger production received still lacked `debug`.

**Measured before claiming a live fix, and the numbers don't support
that part:** `cronLoggerSpies.debug.mock.calls.length` is **0** across
all 155 tests, and the suite is 155 passed both before and after. The
described failure mode — `tick()` hitting `log.debug`, throwing, and
being swallowed by its own error handler — is **not reachable today**,
because no test exercises those three branches (`cron-runner.ts:377`,
`:385`, `:410`). The fix is defensive, not curative. The real gap it
surfaced is **missing coverage** for schedule dedupe / scope mismatch /
lost atomic claim, which I did not write blind to close a thread.

## Commit 3 — the 4 residuals

**`notification-service` (3):** messages moved to DEBUG in production
(`:580`, `:846`) while tests asserted `schedulerLog.log`.

The token case needed more than a relocation. It asserted
`expect(schedulerLog.log).not.toHaveBeenCalledWith(containing("new-token"))`.
Moving only the *positive* assertion to `debug` would leave the secrecy
check watching a channel the message no longer uses — a token could leak
through `debug` and the test would still pass. The negative now runs
across all four channels. **Verified it bites:** interpolating the token
into the debug line fails the test.

**`openclaw-runtime-integration` (1):** `../pi.js` mock missing
`wrapToolsWithOutputBudget` (same class as #2547); this suite exercises
a non-pi runtime, exactly where that wrapper applies.

**Not swept repo-wide, and the measurement is why.** 37 `pi.js` mocks
omit that export. Patching 30 moved the set from **11 failed to 10** —
thirty files of churn for one test. Reverted. Commit 1 earned its
27-file diff with 202 fixes; this one earned nothing, and a no-op sweep
is just future merge conflicts for other workers on this program.

---

## Why none of this is appeasement

AGENTS.md forbids making a red test pass by loosening it. This does the
opposite: the mocks were **wrong** — they claimed to stand in for
`createLogger` while missing part of its interface. Nothing was relaxed;
stubs were completed, and the one assertion I did move got **stronger**
(four channels instead of one).

## Also deliberately not done

Extending `scripts/check-mock-completeness.mjs` to catch this class.
Measured first: a naive rule over relative intra-package mocks flags
**147** factories of which **146 are green** — almost pure false
positives. The barrel heuristic works because `cliSrc` gives a tight
import surface; that doesn't transfer. A gate that noisy gets ignored,
which is worse than no gate.

## How this was found

While characterizing U9's review lane. These files were pre-existing
baseline noise under mutation runs — and that noise is exactly what made
my own safeguard baseline (#2511, corrected in #2520) report two false
verdicts. **A red suite does not merely lack coverage; it makes every
nearby measurement untrustworthy.**

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 10:50:46 -07:00
gsxdsm
d2ce1ba8b5 U11: resolve the scheduler's event-handler columns by trait (10 live sites, sync resolution) (#2518) 
Based on `main`. Ten live `"todo"` sites in `scheduler.ts` now resolve
the column by trait.

## Four groups, converted together

They fail **independently**, and a half-conversion is indistinguishable
from a working system:

| group | sites | failure mode |
|---|---:|---|
| **Wake triggers** | 4 | **Latency** — snapshot invalidation,
mission-failure tracking, engine requeue tracking, move-to-backlog wake.
The wake doesn't fire and the card waits up to a poll interval. Exactly
why it would go unnoticed indefinitely. |
| **Parked wakes** | 2 | Latency — unpause and planning-finished, keyed
on hold OR intake. |
| **Dependency** | 3 | **Not latency.** After a blocker completes or is
soft-deleted, the query returns nothing, so the dependent is *never*
unblocked and waits on a blocker that already finished. |
| **Agent link** | 1 | `rollbackRunningAgentsForQueuedTodoTask` passes a
synthetic `{ column: "todo" }`. Wrong here **drops a running agent's
task link** — the worse direction of that safeguard. Resolved
`parkedColumns` is now passed through too, rather than letting the
helper fall back to its legacy default. |

## Resolution is synchronous, deliberately — the part worth reading

My first cut used the async resolver and made the `task:updated`
listener `async` to suit it. **That broke 5 pre-existing tests, and the
tests were right:** introducing a new `await` *before* a listener's
existing synchronous work defers everything after it to a microtask and
reorders handlers relative to a synchronous emitter.

A conversion must not change event ordering. It now uses the store's
sync IR path (`resolveTaskWorkflowIrSync`), so **no new suspension point
is introduced anywhere**.

That's the fifth time in this program a change that looked like a move
quietly altered behavior — and the first time the existing suite caught
it before review.

## Verification

- **Mutation-verified:** forcing the resolver back to the literals fails
**4 of the 6** new tests
- 110 tests green across all 8 scheduler suites (6 new)
- Fail-soft to the legacy pair: an unresolvable workflow behaves exactly
as before rather than losing the wake
- merge gate green (309 + 10 + 71), tsc clean, lint clean

## Measured

10 of my unit's 68 remaining code sites converted.

`scheduler.ts` now has **one** `"todo"` literal left in live code:
`isRunnableQueuedOverlapCandidate`, which is **exported but has no
production caller** — its only consumer was the legacy dispatcher
deleted in #2505. That's a **deletion, not a conversion**, so it is
deliberately not in this PR.

No changeset: `@fusion/engine` is private.

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


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
* Scheduling now correctly recognizes workflow-specific hold and intake
columns, including renamed columns.
* Tasks entering a hold column reliably trigger scheduling and wake-up
behavior.
  * Dependency recovery now finds blocked tasks in renamed hold columns.
* Planning, unpausing, task completion, deletion, and requeue flows now
respect each workflow’s configured parked columns.
* Prevented unnecessary scheduling for moves between unrelated workflow
columns.

* **Tests**
* Added coverage for renamed hold-column scheduling, wake-up, and
dependency-unblocking scenarios.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->
 2026-07-29 10:44:12 -07:00
gsxdsm
fb7ab6df26 test: re-green self-healing, worktree-pool and DB-corruption assertions (#2592) 
**Test-only.** Three files, two commits. No production changes.

| File | Before | After |
|---|---|---|
| `self-healing-db-corruption` | 5 failed / 1 passed | **6 passed** |
| `self-healing` | 1 failed / 411 passed | **412 passed** |
| `worktree-pool` | 2 failed / 57 passed | **59 passed** |

All three are the same underlying story in different costumes: **the
assertion is watching a channel production stopped using**, or a step
that aborts before it can log at all.

## Commit 1 — the fake store was missing the health refreshers

`surfaceDbCorruption` *refreshes* health before reading the snapshot
(`FNXC:IncompletePgPorts 2026-07-26-20:45`, so PG connectivity is
re-checked instead of trusting an always-healthy sentinel). The fake
carried **neither** refresher, so the async branch fell through to
`this.store.refreshDatabaseHealth()` — undefined — and the step threw
before reaching dispatch. **Every assertion in the file was measuring
zero calls against a step that had already aborted.**

Both stubs are **no-ops on purpose.** Production ignores the refresh
return and reads `getDatabaseHealth()` immediately after, so the
snapshot mock stays the single source of truth. My first attempt
delegated them to `getDatabaseHealth`, which consumed a *second* value
per pass from the test that queues three `mockReturnValueOnce` snapshots
(one per `runMaintenance`) and broke its corruption → clear → corruption
ordering. Faithful beats convenient.

## Commit 2 — two more debug-level assertions

- **`self-healing`**: `"auto-archive: archived …"` is emitted at DEBUG
(`self-healing.ts:2747`); the test asserted `.log`. The mock already had
`debug` (from #2573), so only the target was stale.
- **`worktree-pool`**: both checkout-failure cases assert on
`console.error`, which is *correct* — `createLogger`'s `debug` writes
there. But debug is **gated on `FUSION_DEBUG`** (`logger.ts:43`), unset
under vitest, so the line was never emitted. One test is literally named
*"logs checkout -- failure at debug level"* while asserting a channel
debug could not reach.

Fixed by enabling `FUSION_DEBUG="worktree-pool"` for the suite and
deleting it in `afterEach` so the flag can't leak into sibling files.
**Deliberately not** fixed by re-pointing the assertions at another
channel — that describes whatever the code happens to do rather than the
behavior the test names.

## Verified each actually guards

A test that merely stops failing can still assert nothing, so every fix
was mutation-checked:

| Mutation | NEW failures |
|---|---|
| `surfaceDbCorruption` returns early | **5** |
| remove the auto-archive debug line | **1** — that test, only it |
| remove the checkout-failure debug line | **2** — both cases, only them
|

## Known residual, stated rather than hidden

`self-healing-db-corruption` **still exits non-zero** with 9 unhandled
`this.store.listTasks is not a function` rejections from
`openSurfacingCycle` (`self-healing.ts:7737`). These **predate this
change** — identical count before and after. The maintenance pass opens
one shared surfacing cycle up front, independent of which steps
`stubMaintenance` stubs.

I tried to clear them and backed it out, twice:
- adding `listTasks: async () => []` lets the cycle open, but then
*other* unstubbed sweeps run for real — an orphaned-planning-segment
audit fires and breaks 3 assertions expecting `recordRunAuditEvent`
never to be called;
- stubbing the four `surface-*` siblings didn't help either, because the
cycle is opened by the **pass**, not by the steps.

Making that file honestly green needs a fake complete enough for the
whole maintenance registry — a bigger change than the bug in front of
me, and one that would bury the fix above. Flagging it rather than
shipping a half-sweep.

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

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 10:43:14 -07:00
gsxdsm
21497b23db P0: approved plans never released after #2515 + triage.ts 11 -> 0 (#2549) 
Rebased onto post-#2515 `main`. **This PR is the fix for a P0 stall**,
not just a conversion.

## Stall 1 — approved plans were never released

`recoverApprovedTask` opened with a bare `task.column !== "triage"`.
#2515 merged Todo into Planning on the default lineage, so every default
card now sits in `todo` and **this guard rejected all of them**. An
approved plan whose finalize was interrupted was never released, and
nothing else owns that card. Callers: `triage.ts:1296` (stuck-kill
recovery) and `in-process-runtime.ts:1460`.

`triage` stayed a legal id, so nothing threw — the guard just stopped
matching.

I verified the fix **mechanism** rather than assuming it.
`resolveLifecycleColumns` on the IR #2515 actually shipped returns:

```
{ intake: "todo", hold: "todo", wip: "in-progress", review: "in-review", complete: "done", archived: "archived" }
```

so the converted guard admits default cards. The new regression test
asserts the **return value**, because on a merged lineage the card is
already where the release would send it — "no move issued" is what
*both* the broken and the fixed code do, so only the outcome
discriminates.

**Mutation-verified:** restoring the literal `!== "triage"` fails 2 of 5
tests.

## A defect of my own, found while auditing — same shape as the P0

`clearStaleSpecifyingStatuses` is a board-wide startup sweep with no
single task to resolve lanes against, and I had resolved **both** its
queries from the default workflow. Post-#2515 that workflow's `intake`
and `hold` are the **same** column, so both queries collapsed onto
`todo` and **nothing ever swept `triage`**. A legacy or Coding (Ideas)
card holding a stale `planning` status would then occupy a planning
admission slot permanently — exactly the failure the 2026-07-04 note
above that function warns about.

Now queries the **union** of the legacy planner ids and the resolved
lanes, deduped by task id. Querying extra columns is free here: the
sweep only reads, and every row is filtered on `status === "planning"`
before anything is written.

Caught by `triage.test.ts`, **not by my own tests** — worth recording,
since it is the same collapse the P0 is about.

## Rebase note

The discovery conflict was resolved **in favour of `main`**. Main's
version is strictly better than mine: it resolves lanes with the
**async** `resolveTaskLifecycleColumns` (so it is not subject to the
sync-resolver limitation below), keeps the two admission branches
disjoint for a merged column, and bounds concurrency. My sync version
was dropped.

## Measured

| file | comparisons before | after |
|---|---:|---:|
| `packages/engine/src/triage.ts` | **11** | **0** |

## Known red, NOT from this PR

8 tests in `triage.test.ts` fail on **clean `origin/main`** — confirmed
by swapping main's `triage.ts` into this tree and re-running (same 8).
They are reporting the upgrade stall, not stale expectations: a card
*sitting* in `triage` is admitted by nothing after #2515 (`expected
"specifyTask" to be called 4 times, but got 0 times`), and #2515 shipped
no data migration re-homing those rows. Left untouched here — the fix is
a data migration, not a conversion. Reported to the coordinator
separately.

## Verification

- merge gate green (414 + 10 + 71), tsc clean, lint clean
- mutation-verified as above

## Separate finding — affects every worker

`resolveTaskWorkflowIrSync` **cannot resolve a task's selection in
production.** `getTaskWorkflowSelectionImpl` is `return undefined`
unconditionally and `getTaskWorkflowSelectionAsyncImpl` is *"always
PostgreSQL path"*, so the sync resolver **always** returns the DEFAULT
workflow IR. `moves.ts` already hit this and fixed it by going async.
Consequence for `resolvePlannerLanes` here: correct for default-lineage
cards (the default IR is exactly what comes back — which is why Stall 1
is genuinely fixed) and **inert for custom workflows**. Not papered
over; the async path is main's discovery code, and converting the
remaining event-listener sites needs the handler-reordering problem
solved first.

No changeset: `@fusion/engine` is private.

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

---

## P0 audit table — every `triage` site in my assigned files

(a) does it still fire for a default-workflow card after #2515? (b) if
not, what silently stops happening? (c) fix.

| site | (a) still fires? | (b) what silently stops | (c) disposition |
|---|---|---|---|
| `triage.ts:613` wake handler | **yes** | — OR-shaped (`todo \|\|
triage`), still matches | converted anyway |
| `triage.ts:651` evacuation guard | **yes** | — OR-shaped, still
matches | converted anyway |
| `triage.ts:741` stale-planning sweep | **yes** | — OR-shaped, still
matches | converted anyway |
| `triage.ts:1088` `recoverApprovedTask` | **NO** | **STALL 1** —
approved plan never released; nothing else owns the card | **fixed +
regression test + mutation-verified** |
| `triage.ts:1396` advanced-recovery discovery | **NO** | that recovery
never matches a default card | fixed by the same conversion |
| `clearStaleSpecifyingStatuses` (mine) | **NO** | **my own defect** —
both queries collapsed onto `todo`, `triage` never swept; stale
`planning` holds an admission slot forever | **fixed** (union of legacy
+ resolved lanes) |
| `replan-target.ts:177` / `:185` | **NO** | **STALL 2** — see #2552 |
fixed in #2552 |
| `spec-staleness.ts:95` | **NO** | narrow: a Planning card with null
status and `currentStep > 0` now skips staleness where it previously did
not | **recorded, not fixed** — see below |
| discovery (`isAtIntakeColumn`) | **NO** | **STALL 3** — a card
*sitting* in `triage` is admitted by nothing | **reported, not fixed** —
needs a data migration |

**Why `spec-staleness.ts:95` is not fixed here.** The guard already
returns `false` for `status === "planning"` and `needs-replan`, so an
*actively* planning card is still covered by status. The `column ===
"triage"` arm only added coverage for a planner-lane card with **no**
status — and post-merge that case is genuinely ambiguous, because `todo`
is now both the planning lane and the hold lane, so a card with progress
there may legitimately be a released card that *should* skip. Guessing
either way is a behaviour change without evidence, so I recorded it
rather than picking one.
 2026-07-29 10:30:18 -07:00
gsxdsm
c92bce2f8c test: delete 2 project-engine-manager tests for the deleted cross-project cap (#2575) 
**Test-only.** One file, 2 obsolete tests + 1 dead import removed. No
production change.

`project-engine-manager.test.ts` has been **red on main: 2 failed / 44
passed** → now **44 passed**.

## The failures

Both threw `TypeError: Cannot read properties of undefined (reading
'acquire')`, because both reach `(manager as any).globalSemaphore` — a
private field that no longer exists.

`project-engine-manager.ts:88` records why (`FNXC:CapacityModel
2026-07-28-20:10`, *"drop the cross-project cap"*):

> The shared cross-project semaphore, its mutable limit and the
`concurrency:changed` subscription are **DELETED**. Capacity is two
numbers per project; a machine-wide cap was a third limiter with its own
separate authority (a central-DB singleton row), and reconciling it
against the per-project gates is exactly the multi-limiter arbitration
this simplification removes.

So both tests assert residual-slot accounting on a shared pool that was
**deliberately** removed — not a regression.

## Why deleted rather than repaired

There is no shared semaphore left for them to describe. Reconstructing
one inside the test would assert a capacity model the engine no longer
has — a test that passes while describing fiction, which is worse than
the red it replaces.

Also drops the now-dead `ScopedAgentSemaphore` import (these were its
only uses). Lint does not flag unused imports here, so it would
otherwise have sat as quiet dead code.

## What I did NOT take, and why

`workflow-graph-optional-step-fix.test.ts` — the other red file adjacent
to this lane, 5 failures. Its failures are **U11 column-vocabulary
drift**: the replan rebound now resolves to `todo` where the test
expects `triage`, and one case gets a hard-cancel pause-abort log
instead of the Plan Review replan message.

That is the U11/U12 owner's semantics to settle. Picking whichever
column makes the assertion pass could silently encode the wrong
lifecycle target — and per the graph-entry contract doc, a rebound
landing in a column the workflow does not declare is precisely the
failure mode that "does not fail a test; it disables a recovery path in
production." Flagging it rather than guessing.

## Running tally of this cleanup thread

| File | Before | After |
|---|---|---|
| 27 logger mocks (#2573) | 206 failed | 4 failed |
| `merge-error-recovery` (#2559) | 10 failed | 0 |
| `reviewer` (#2547) | 2 failed | 0 |
| `project-engine-manager` (this) | 2 failed | 0 |

Every one was a test describing behavior that had moved or been deleted,
or a mock that had drifted from its real shape — none was a product
defect. That pattern is worth naming: on this repo a red non-blocking
suite has mostly meant *stale tests*, which is exactly what makes it
easy to ignore, and exactly why it silently corrupted my own safeguard
measurements in #2511.

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

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-29 10:22:46 -07:00
gsxdsm
1c9f6c546b P0: default Planning cards read as ADVANCED after #2515 (FN-8596 stranding re-opened) + 6 red tests repaired (#2552) 
Rebased onto `main` (post-#2515) and **upgraded from a conversion to a
P0 stall fix**.

## What changed since review

Greptile's P1 on this PR said the `plannerColumn` seam was unused —
*"every current production caller omits `plannerColumn`, so this default
still compares against `triage`."* That was correct, and **#2515 turned
it from an unused seam into a live stall.**

## The stall

#2515 merged Todo into Planning on the default lineage (one
pre-implementation column, id `todo`, display "Planning"). `triage`
stayed a legal id, so nothing throws — the bare `column === "triage"`
guards in `hasAdvancedPastPlanning` just **stopped matching for
default-workflow cards**.

A default card in `todo`, status cleared to null by the stale-status
sweep, carrying execution stamps from a previous pass, now returns
**ADVANCED**. So `isTaskStillInPlanningStage` is false and nine guarded
call sites refuse planning updates, finalize, delete and handoff:

`triage.ts` 3108 / 3117 / 3160 / 3438 / 3937 — `self-healing.ts` 12126 /
12448 / 12454

The file's own FNXC note at `:150` already records what that costs:

> Nobody owned the card and it sat indefinitely.

This is that same FN-8596 stranding, re-opened by the column merge.
Confirmed empirically — the rescue test fails on pre-fix code.

## The fix is an asymmetry, and that's the point

The two guards are **not the same rule**:

1. the FN-8596 **arrival-order rescue** — a stamp predating arrival in
the planner lane means replanning, not advancement
2. **"the planner column itself is never advanced"**

Rule 1 must recognise the merged Planning column. **Rule 2 must not** —
on the merged lineage `todo` is *also* the released/hold lane, so making
it blanket "not advanced" would strand the release path instead: a
released card with steps would read as still-planning and
`hasAdvancedPastPlanning(t) || releasedToTodo` would stop distinguishing
anything.

Rule 1 is already gated on the stamp predating arrival, so a released
card later claimed by execution keeps its newer stamp and still reads as
advanced.

**Closed via the default** (`mergedPlanningColumn = "todo"`) rather than
by wiring call sites — the stall closes everywhere at once, with no
call-site change and nothing to collide with another worker's slice.
Dedicated-planner workflows (Coding (Ideas), and every workflow still
declaring `triage`) are byte-identical.

## Second commit: 6 tests left RED on main by #2515

Verified pre-existing by stashing every local change and re-running —
same 6 failures on a clean branch. `resolveReplanTargetColumn` reads the
IR rather than a literal, so it **self-healed** to the correct
post-merge answer (`todo`); the expectations were the stale half.
Updated to the post-merge truth, not loosened — each still pins one
exact column.

## Audit table for this file (P0 sweep)

| site | still fires for a default card? | what silently stopped |
disposition |
|---|---|---|---|
| `replan-target.ts:177` `inPlannerLane` | **NO** | FN-8596 rescue —
planning writes no-op, card strands | **fixed** (rule 1) |
| `replan-target.ts:185` never-advanced | NO | nothing — must stay
dedicated-planner-only | **deliberately unchanged** (rule 2) |
| `resolveReplanTargetColumn` | yes (IR-driven) | — self-healed to
`todo` | tests repaired |
| its two `return "triage"` fallbacks | n/a | reachable only for
workflows declaring neither column | **recorded, not fixed** —
column-policy decision, has its own covering test |

## Verification

- **Mutation-verified both directions:** dropping the merged lane from
rule 1 fails **2** tests; wrongly extending rule 2 to the merged lane
fails **1**
- 50 replan-target tests green (7 new)
- merge gate green (414 + 10 + 71), tsc clean, lint clean

## Separate finding — affects every worker

`resolveTaskWorkflowIrSync` **cannot resolve a task's selection in
production.** `getTaskWorkflowSelectionImpl` is `return undefined`
unconditionally and `getTaskWorkflowSelectionAsyncImpl` is *"always
PostgreSQL path"*, so the sync resolver **always** returns the DEFAULT
workflow IR. `moves.ts` already hit this and fixed it by going async.
Any conversion built on the sync resolver is inert for **custom**
workflows — harmless for default cards, since the default IR is exactly
what comes back. Reported to the coordinator for the other workers; not
actionable in this PR, which uses no sync resolution.

No changeset: `@fusion/engine` is private.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
 2026-07-29 10:15:54 -07:00