fusion

Author	SHA1	Message	Date
gsxdsm	c143327d4b	fix(core): the archived-document guards failed in OPPOSITE directions on a renamed lane (#2886 ) Two of the four convertible sites my own learnings doc miscounted as sentinels — the #2877 review corrected "8 of 9 must not be converted" to "5 of 9", and these are two of the three that correction freed. They read `task.column` straight off a row `select`, so they are board lanes by exactly the test that document gives, and a renamed archived column is simply not seen. What makes the pair worth fixing together is that they fail in opposite directions: \| guard \| on a renamed archived lane \| consequence \| \|---\|---\|---\| \| `upsertTaskDocument` \| fails to reject \| an archived card's documents stay writable — the read-only contract silently does not hold \| \| `publishArchivedTaskDocumentAddition` \| fails to accept \| a legitimate archived-document publication is refused as `parent-not-archived` \| The second is the sharper one: valid operator work refused, and refused with a message that reads as a data-integrity error rather than a lifecycle mismatch. ## Shape Both take an `AsyncDataLayer` and can resolve nothing themselves; their store-level impls hold the store, so the lane set arrives as a parameter resolved once per call — the shape #2875 used for the SQL predicate. One shared `resolveArchivedLanes` for both paths, deliberately: if the write guard and the publication guard could disagree about whether a card is archived, a card ends up both read-only and un-publishable. ## The revert proof caught my own fixture first My first version set `deletedAt` alongside the renamed column, and the revert proof passed with the fix removed. Both guards are `column-is-archived \|\| deletedAt != null`, so a soft-deleted fixture short-circuits the exact comparison under test — the assertion was holding for an unrelated reason. Dropping `deletedAt` isolates it, and is also the real shape: a live row in a workflow-declared archived lane is what a renamed board produces, and what `getLiveTaskColumn` was written to catch. Revert proof, measured honestly the second time: restore `task.column === "archived"` and the renamed-lane case fails — the upsert resolves instead of rejecting. ## Real PostgreSQL, deliberately These are row predicates inside a transaction. A mocked store would assert the arguments and prove nothing about the comparison that runs — the same reasoning as #2875. Three cases: the renamed lane rejects, the legacy `archived` id still rejects (most boards never rename anything), and a live card is still allowed through (a guard that rejects everything is its own bug). ## Verification - `pnpm test:gate` — 161 / 487 / 13 / 71 passed - `pnpm lint` — clean - `tsc --noEmit` (`@fusion/core`) — clean - new `archived-document-lanes.pg.test.ts` + existing `artifacts-documents-evals.pg.test.ts` — 12 passed against real PostgreSQL Note: the SQL-literal baseline is untouched here — #2881 owns re-recording it after #2864's conversion left main's gate red. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 17:40:30 -07:00
gsxdsm	ab15e5f9f7	docs(lanes): audit the three files the census points at with no reason attached (#2873 ) No source change. Every literal stays counted and none gets an exemption marker. What changes is that the census now points at these three with the analysis attached, instead of making each worker who reaches them re-derive it. Peers have already done this well for `notification-service.ts` — converted it, measured a real delivery regression, reverted, and left it counted with the reason. These three had nothing at all, and one of them is the highest-impact unowned site I found. ## `planner-overseer.ts` (3 guards) — REAL, and larger than three literals suggest On a renamed board `resolveWatchedStage` returns `null` for every card. `observeTask` returns early on a null stage, so no observation is recorded, no `overseer:intervention` entry is emitted, and `PlannerRecoveryController` — which consumes those observations — has nothing to steer, retry, or targeted-fix. The entire oversight loop is inert and silent about it, exactly like the self-healing sweeps whose queries returned empty arrays. Not mechanical, which is why it is flagged rather than converted. `resolveWatchedStage` is a pure sync function over a `Partial<OverseerTaskRef>` with no store and no task id, so the lane answer has to arrive as a parameter. Its only production caller, `observeTask`, is async and the monitor does hold a store — but it runs once per task per poll, so resolving inside it buys a workflow read per card on a timer. The shape that works is the one the board-load enrichment landed on in #2845: resolve at the poll, once, with an IR cache keyed by workflow, and pass the flags down. That makes it a change to `project-engine.ts`'s poll as much as to this file — a cost judgement about a periodic engine loop, not a rename. `columnFlags` is in the unwired-lane-parameter vocabulary, so whoever adds the parameter cannot leave it unwired. ## `async-mission-store-queries.ts` (1 of 3) — REAL `getTerminalTaskEvidence` tests only `column === "done"` for its `done` verdict, so a completed card on a renamed board falls through every branch to `{ kind: "nonterminal" }`. The caller is mission terminal evidence repair, so a finished feature reads as unfinished — a wrong verdict, not an error. The `archived` test beside it has the same defect, masked for soft-deleted rows by its `deletedAt` companion, which is why only the `done` half bites in practice. Takes a bare `QueryHandle`: no store, no task object, no workflow. The fix is a resolved terminal-lane set threaded in by the caller — the same shape `getLiveTaskColumn` needs, and it should land with it so the two cannot disagree about what "finished" means. ## `audit-ops.ts` (2) — one sentinel, one real, and they look identical ```ts if (state === "archived") // ← getLiveTaskColumn's MANUFACTURED value: do NOT convert if (pgRow.column === "archived") // ← a real board lane: convertible ``` The first compares against a string `getLiveTaskColumn` fabricates for an archived-or-soft-deleted parent, so converting it to `isArchivedColumnRole` would keep passing on the built-in board and start failing on a renamed one — a soft-deleted task's log would become writable. The second reads the task row, so a renamed archived column keeps accepting log writes; its `deletedAt` companion masks that in practice. Two lines that look the same and need opposite treatment is precisely the reason these notes are worth more than the count. ## Verification - `pnpm test:gate` — 161 / 487 / 13 / 71 passed - `pnpm lint` — clean - `tsc --noEmit` (`@fusion/core`, `@fusion/engine`) — clean - `planner-overseer.test.ts` — 50 passed - census `--strict` — exit 0, counts unchanged (that is the point) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 16:43:43 -07:00
gsxdsm	89aaf341d0	the unwired-seam audit: 9 defects the census cannot see, incl. a reviewed card that cannot merge (#2820 ) Nine operator-visible defects in a class the census cannot see, plus the audit method that found them. The census scans for lifecycle-column comparisons. This PR is about guards that have no literal to find: a helper takes an optional resolved lane set, its own test passes it, the census entry is gone — and the callers pass nothing. A resolved seam nobody wired is indistinguishable from no seam at all. ## What was broken \| defect \| operator sees \| \| --- \| --- \| \| `getTaskMergeBlocker` unwired in `mergeTaskImpl` \| `Cannot merge FN-1: task is in 'checking', must be in 'in-review'` — a reviewed card cannot merge \| \| …and in the completion move \| `Cannot move FN-1 to done: …` — and cannot complete \| \| `isParkedTaskColumn` unwired ×2 (`agent-heartbeat`) \| a durable agent keeps claiming a parked card; Health Check renders it RUNNING \| \| `resolveLinkSyncColumnRoles` first-per-role \| link hygiene skips a second hold lane entirely \| \| `executor` active-task predicate first-per-role \| a card in a second wip lane reads as INACTIVE; its prompt file becomes reclaimable \| \| `isPlanningContinuationTaskDispatchable` partially threaded \| a board declaring `done` as non-terminal stalls its cards — stalled by a lane name \| \| `default-workflow-hooks:72`, `executor:2404` \| resolved gate admits the move, unresolved blocker refuses it \| ## The recurring shape, which is sharper than "a caller forgot an argument" Four sites resolve the lane and then re-ask with the literal, a few lines apart in the same function: - `task-artifacts-ops` resolves `completeColumn`, then asks the blocker with the literal. - `default-workflow-hooks:72` gates on `lifecycleColumns?.review`, then the literal. - `executor:2404` compares `resolveResumeLanes(…).review`, then the literal. - `resolvePlanningContinuationCandidate` applies the caller's terminal set, then delegates without it. Grep for the helper, not the literal. The literal is one function away, correctly annotated as a fallback — which is exactly why the census is blind to all of it. ## The arity trap, named and measured (six occurrences, one caught by review here) `resolveLifecycleColumns` answers "which column is the* hold lane?". A `.includes()`/`.has()` test asks "is this any hold lane?". Nothing distinguishes them — same types, no literal. A default-vs-renamed differential cannot catch it, because the default board declares one column per role and therefore cannot express the failing shape. It needs a structurally* different fixture. That is a sharper rule than "test both vocabularies", and it would have caught all six. Scanned: 12 candidate sites. 4 fixed · 3 blocked (2 on the inert sync IR reader; `triage:833` also query-shaped) · 1 needs a hook-contract change · 3 not defects (a returned tuple; an ordering-sensitive precedence list) · 1 false positive of my own scan. A sweep over all twelve would have broken the ordering-sensitive pair, delivered nothing at the sync-blocked ones, and "fixed" a site that was already correct. ## Two traps in fixing this class — I hit both here 1. The legacy id is a FALLBACK, not a member. Pre-seeding `"in-review"` admits a board that declares `in-review` as its WIP column — a card mid-implementation merges prematurely. A real resolved answer must replace the default. (Caught by review; it is the same unscoped-legacy-acceptance the glasses plugin's review caught earlier, which I had read and reintroduced.) 2. Two guards, one assertion. `toContain("must be in")` passed with `mergeTaskImpl` reverted, because the completion guard caught the card instead. The assertion now names the site (`Cannot merge` vs `Cannot move … to done`) so the two fail independently. ## Corrections I made to my own work, recorded rather than quietly fixed - My first PG test was vacuous three ways: `saveWorkflowDefinition?.()`/`setTaskWorkflowSelection?.()` do not exist (the `?.` swallowed both, so the task kept the builtin workflow), `updateTask({column})` does not move a card, and a two-node IR made every setup move illegal. Premise is now asserted, not assumed. - My doc claimed the audit was complete. It enumerated helpers, not every caller — `getTaskMergeBlocker` alone has 13 call sites. Corrected in place, with the still-unwired ones listed by file and line and a note to distrust any "audit complete" claim including mine. - A severity correction to another worker's E2E: `selectActionablePlanningContinuations` has no production caller, so its stated consequence is latent, not live. ## Verification - `pnpm test:gate` — 161 + 487 + 13 + 71 - `tsc` on core and engine; `pnpm lint`; `check:changesets`; census `--strict` — all clean, each run explicitly - Every fix revert-measured; each has a non-vacuous companion. The two-hold-lane and repurposed-`in-review` cases exist because the default board cannot express those shapes. ## Deliberately not done, with reasons in `resolved-seams-nobody-wired.md` `isTaskReadyForMerge` (dead in production — wiring it would be the anti-pattern itself); `getTaskHardMergeBlocker` (3 of 4 callers are query-gated sweeps); `getInReviewStallReason` (needs a batch prefetch, not a per-task resolve — its callers decorate every task on every list read; the in-review stall badge is wrong on renamed boards until then); `default-workflow-hooks` planning/live-work sets (needs `DefaultWorkflowMoveContext` to carry the IR — a shared contract change).	2026-07-30 15:08:01 -07:00
gsxdsm	f53c9dbd39	fix(core): merge re-enqueue threw on every board with a renamed review column (#2819 ) The single most consequential finding from the u12 seam-gate work, picked up because batch-core (#2783) merged without it and it is now unowned. ## The defect `enqueueMergeQueueInTransaction` gates on the task's column being a review column, and takes the board's review columns as an optional trailing argument. - `moves.ts:487` and `moves.ts:1153` — the automatic handoff-to-review path — resolve and pass them. - The public `enqueueMergeQueue` wrapper (`async-merge-coordination.ts:246`), reached through `store.enqueueMergeQueue`, did not, so it fell back to `new Set(["in-review"])`. This is not the quiet legacy-id degradation most of these seams produce. The reject branch records `mergeQueue:enqueue-rejected` and throws `MergeQueueInvalidColumnError`. Its production callers are `merger.ts:7251` and `self-healing.ts:10329` — so on any board whose review lane is renamed, the merge and recovery re-enqueue paths failed outright while the handoff path kept working. ## Measured, not asserted With the fix reverted, the renamed case fails with the exact predicted error and the controls stay green: ``` × renamed vocabulary: a task in the RENAMED review lane enqueues for merge MergeQueueInvalidColumnError: Task KB-001 is in column 'checking', not 'in-review'; cannot enqueue ✓ default vocabulary: a task in the review lane enqueues for merge ✓ renamed vocabulary: a task in the WIP lane is still REJECTED ✓ default vocabulary: a task in the WIP lane is still REJECTED Tests 1 failed \| 3 passed (4) ``` With it: `Tests 4 passed (4)`. ## About the suite Differential. The fixture is the builtin coding workflow with only its column ids renamed, so the sole difference between the two runs is vocabulary — a hand-built graph would test the fixture's own transition table as much as the code. It asserts the rename actually landed (`checking` present, `in-review` absent), so a surviving literal cannot pass by luck, and it walks the graph rather than jumping, because moves are transition-validated. Both negatives included. A WIP-lane task must still be REJECTED under each vocabulary. Supplying the real columns must not degrade into "every column is a review column", which would let work merge straight out of the WIP lane — the failure mode a careless version of this fix would introduce. ## Why nothing caught it Partial supply. Two of three call sites passed the argument, so a check asking "does SOME caller supply this?" reported the seam as satisfied, and the lifecycle-column census counted the conversion as done. Closing that one-supplier floor in `scripts/check-inert-flag-seams.mjs` (on #2772) is what surfaced it. ## Verification - `pnpm test:gate` green - new suite 4/4; neighbouring merge-queue suites (`taskstore-lifecycle`, `store-in-review-stall`, `runtime-lifecycle-async`) 29/29 - `tsc -p packages/core` 0, lint 0 - changeset included (`@runfusion/fusion` patch) Note: #2772 still carries a TEMPORARY per-call-site exemption for this seam. Once this lands, that exemption's staleness check will fail and I will remove it there — it cannot outlive the fix. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 14:26:11 -07:00
gsxdsm	3603da731f	fix(core): duplicate markers were never cleared on a board with renamed terminal columns (#2823 ) Third unowned finding picked up after batch-core (#2783) merged without addressing its reports. Same class as #2819, opposite failure direction. ## The defect `clearNearDuplicateReferencesTo` runs on every complete/archive/delete of a canonical task and clears the `nearDuplicateOf` markers pointing at it. It first asks `isNearDuplicateCanonicalInactive` whether the canonical really is finished — a safety check, so a live canonical's markers are not cleared out from under an operator. That call omitted the canonical's resolved column flags, so it fell back to the legacy `done`/`archived` ids. On a renamed board a just-completed canonical (`shipped`, `filed`) read as still active, the guard early-returned, and the markers were never cleared. The flagged duplicates stayed parked behind a user decision that could never arrive — the exact stranding the predicate's own FNXC note says it was written to prevent. ## I had the direction backwards, and it matters My first report of this seam described it as markers cleared against a live canonical. That is wrong. The legacy fallback errs toward "still active", so the failure is the opposite: markers that never clear at all. Same seam, same missing argument, entirely different symptom to look for — which is why the direction is worth pinning in a test rather than reasoning about. ## Measured With the fix reverted, exactly one case flips: ``` ✓ default vocabulary: completing the canonical clears the duplicate's marker × renamed vocabulary: completing the canonical clears the duplicate's marker ✓ renamed vocabulary: a canonical still in the WIP lane does NOT clear the marker ✓ default vocabulary: a canonical still in the WIP lane does NOT clear the marker ✓ a soft-deleted canonical clears the marker under a renamed board Tests 1 failed \| 4 passed (5) ``` With it: `Tests 5 passed (5)`. ## Both negatives included A canonical still in the WIP lane must not clear its duplicates' markers, under each vocabulary. Resolving the real flags must not degrade into "every column is terminal", which would clear markers out from under an operator who has not made the duplicate decision yet. The soft-deleted path is covered too, since that branch never consults column flags at all. ## A fixture trap worth keeping `sourceMetadata` is `jsonb` and must be seeded as an object. Seeding a stringified value reads back fine through `getTask` — it parses either shape — while the production query's `source_metadata->>'nearDuplicateOf'` matches nothing. The fixture looks correctly seeded and the code under test can never find the row. My first version had this, and the self-check in the seed helper is what caught it. ## Scope Five of this predicate's six production call sites already resolved flags. This was the sixth, and the one that runs on every archive/complete transition. Not touched here: the same function's SQL predicate excludes duplicates by literal `ne(column, "archived")` / `ne(column, "done")`. That is a per-row question across many rows in one statement, not a one-line supply, so it is flagged rather than guessed at. The five engine call sites of this predicate are separately reported on #2785 and surfaced only via #2822. ## Verification `pnpm test:gate` green, new suite 5/5, `tsc -p packages/core` 0, lint 0, changeset included. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 14:03:29 -07:00
gsxdsm	a6af3188df	fix(core): startup recovery deadlocked on its own per-task lock (#2809 ) ## The bug `recoverStaleTransitionPendingImpl` runs its whole per-task body inside `store.withTaskLock(id, …)`. On the PostgreSQL arm it then read the task with `store.getTask(id)` — and `getTaskImpl` opens with `store.withTaskLock(id, …)` too. The per-task lock is non-reentrant. This codebase states that invariant in prose in two other files: > "nesting inside `withTaskLock` would deadlock since the lock is non-reentrant" — `branch-and-pr-entities.ts:561` > "because the per-task lock is non-reentrant" — `workflow-ops.ts:464` So the sweep waited forever on a lock its own frame was holding. PostgreSQL-only — which is every production install. The SQLite arm on the very next line reads through `readTaskFromDb`, a lock-free row read. The backend-mode port swapped only the PostgreSQL arm to `getTask`. The fix restores a lock-free read (`readTaskRow`) on that arm; nothing else changes. ## Why it survived until now The branch is entered only when a stale marker names a plugin hook the trait registry still knows (`hasSurvivingPluginHook`). Three nearby cases all miss it: \| marker \| path \| \|---\|---\| \| none \| the row is never scanned \| \| only `default-workflow:postCommit` \| `hasSurvivingPluginHook` false — marker just cleared \| \| names an uninstalled plugin hook \| reconciled away as degraded; nothing survives to re-run \| \| names a registered plugin hook \| reaches the in-lock read → deadlock \| Those first three are what the existing tests cover. The fourth is precisely the state a crash mid-hook leaves behind. All four are asserted in the new suite so the path cannot be re-narrowed and called covered. ## Impact This sweep runs at startup. A task left with such a marker deadlocks startup recovery — and because it deadlocks while holding the task's lock, that task is also left permanently unlockable. ## How it was found, including a correction By bisection, not by reading. An earlier attempt of mine to drive this recovery reported that "the sweep never returns". That was wrong in a way worth recording: the sweep returns fine in three of the four cases, and generalising the one hang to the whole function is what hid the actual trigger across several sessions. Narrowing case by case — empty store, plain task, default-only marker, unknown-hook marker, registered-hook marker — put the fault on one line. ## Verification - Mutation-verified against the real defect. With the fix reverted, the regression case fails by name — `recoverStaleTransitionPendingImpl did not settle within 8000ms — deadlock` — while the other three stay green. That is the actual pre-fix behaviour, not a simulation of it. - Every case is timeboxed on purpose: a deadlock otherwise surfaces as a suite-level timeout naming no case, which is useless for locating the fault. The deadline is not a flake knob — the fixed code settles in ~150 ms and the broken code never settles, so there is no value in between to tune. - A vacuity guard (no markers → scans nothing) so a change that stopped listing marked rows can't leave the other cases green. - `pnpm test:gate` — exit 0 - full live-PG E2E surface — 152/152 - `pnpm lint` — clean Changeset included (`patch`, category `fix`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 13:58:02 -07:00
gsxdsm	109204c590	fix: the query class — three sweeps that never ran on a renamed board (#2818 ) Three sweeps that never ran at all on a renamed board, plus the shared answer the rest of the class needs. Consolidated from three handoff branches so the helper appears once. #2811 merged, so this is my only open PR. `#2800` measured this class and shipped evidence deliberately without conversions: `listTasks({ column: "<literal>" })` filters in the store, so on a renamed board the read returns an empty array and the sweep it feeds does nothing. The census scores the comparison inside the loop, never the query above it. ## What was broken \| file \| census count \| what actually happened on a renamed board \| \|---\|---\|---\| \| `backlog-pressure-reporter.ts` \| 0 \| both reads empty, ratio computed as 0/0 — the alert never fired, on a board that may be under exactly the pressure it reports \| \| `stale-task-reporter.ts` \| 0 \| both reads empty — no stale-task signal ever raised, where work is most likely sitting unnoticed \| \| `restart-recovery-coordinator.ts` \| flagged \| sweep never ran — an engine restart left interrupted tasks stuck with no requeue \| Two of the three have a census count of zero. They contain no lifecycle comparison at all, so they have never appeared in the backlog, in a per-file list, or in any "N → 0" claim — and were completely inert. A file at zero is not evidence of anything. ## The shared answer, and what it is not Every existing resolver answers a per-task question. A query has no task in hand, so it needs the project-level one: every column any workflow declares for a role, unioned with the legacy ids so a board mid-rename still finds rows under the old ones. The set is never empty, so a caller cannot accidentally query nothing. The header states what it is not: answering a per-card question from the union would mark a card as review because some other workflow calls its column review — the flat-set mistake this program has made four times. ## The finding that generalises: the query is rarely the whole defect `stale-task-reporter` still reported zero after the query was fixed — `getTaskAgeStalenessSignal` defaults to the legacy pair, so a card the query now returned was refused inside the signal. Converting only the query would have looked like a fix and changed nothing. That is a caveat on #2800's approach, offered as refinement rather than correction: asserting the query ARGUMENT is right when pinning a known defect (the outcome is 0 either way) and insufficient when proving a fix, because the outcome is the only thing that distinguishes a real conversion from a deeper one. All three conversions here assert outcomes. `restart-recovery` had three layers — query, a redundant re-assertion (deleted; a test pins the `paused` guard it did contribute), and a move destination that was already resolved but whose warning comment was stale. A stale warning is its own hazard: it told the next reader a defect existed where none did. ## Verification - helper 8 passed · three reporter/coordinator suites 29 passed - `pnpm test:gate` 161 / 13 / 487 / 71 · lint clean · `--strict` exits 0 · four `tsc` targets clean - each conversion revert-proven independently; the failing case is named in each test header ## Two mistakes worth recording The helper's own test caught a bug in it. My first draft wrapped the definition loop in one `try`, and `parseWorkflowIr` validates rather than parses — one malformed row would have returned legacy-only lanes for every workflow, indistinguishable from the bug it exists to fix. Now isolated per definition. I clobbered the core barrel by taking `index.ts` wholesale from a handoff branch, dropping two exports `main` had added since; three packages stopped compiling. Taking a file from another branch takes its whole contents, including what is now stale — for a barrel that is nearly always wrong. Re-applied as a single edit on top of `main`. ## Not included `self-healing.ts`'s 49 — actively owned and mid-conversion; an outside refactor there produces conflicting halves of one sweep. `project-engine.ts` (7) and `executor.ts` (2) need their own read of what each sweep does with the rows, which these three are the argument for. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 13:55:10 -07:00
gsxdsm	1824c04584	fix(core): restore an archived card to the lane it came from (#2832 ) ## What Fixes the defect #2824 measured. That PR's characterization cases — merged and asserting the wrong-but-real behaviour — are flipped here to the correct lanes, which is what they were written to do. ## The bug ```ts // archive-lifecycle-2.ts const preArchiveColumn = task.preArchiveColumn ?? "todo"; ``` `preArchiveColumn` has no database column. It exists on the `Task` type and in the archive snapshot, and nowhere else — so the in-place restore cannot carry it, `store.getTask(id)` reads a live row that never had it, and the literal decided the destination for every unarchive that has ever run. \| board \| what happened \| \|---\|---\| \| default \| `todo` is declared, so the resolver returned it. Restores landed in the queue and looked right. \| \| custom \| `todo` is declared nowhere, so the resolver took its "no usable history" branch and returned the complete lane. A card archived mid-implementation came back marked finished. \| That coincidence is why this survived three separate fixes to `resolveUnarchiveTargetColumnImpl` — a `?? "done"` that invented a column, an `isColumn` legacy-enum gate, and the same gate one function over. Every one was correcting how the resolver interprets a value that never arrived. ## The fix is two halves, and either alone does nothing 1. Capture — `taskToArchiveEntryImpl` records `task.column` into the snapshot. That is the last place the original is still in hand, since the entry's own `column` is set to `"archived"` on the line above. 2. Read — `unarchiveTaskImpl` reads the snapshot it already loaded, not the restored row. I shipped half of this first and watched the destination stay wrong, which is how I found that the field has no row to live on. Mutation matrix: \| state \| result \| \|---\|---\| \| both halves \| 5/5 pass \| \| capture only (read reverted) \| 3 fail \| \| read only (capture reverted) \| 3 fail \| I also tried carrying it through `restoreTaskFromArchive`'s row update — that fails to typecheck, which is the proof that no such column exists and the snapshot is the only source. ## Behaviour changes, deliberately - Custom boards — a card returns to the lane it was archived from instead of appearing finished. - Default board — a card archived from `done` restored to `todo` under the literal and now restores to `done`. Returning finished work to the queue was the fallback showing through, not a rule anyone chose; the resolver's own branches say a card archived from a declared column goes back to it. ## One expectation of mine was wrong, and the resolver was right I expected a card archived from the review lane to return to hold. It returns to the review lane, and that is correct: `.review` is derived from the `mergeOrchestration` flag, not from `human-review`. The fixture's review column declares `human-review` + `merge-blocker` only, so it is not a `.review` lane to the resolver — just a declared column with usable history. The case now asserts that with the reasoning attached, so the next reader does not "fix" it back to hold. ## Verification - unarchive suite — 5/5, mutation matrix above - `pnpm test:gate` — exit 0 - full live-PG E2E surface — 164/164 - `pnpm lint` — clean Changeset included (`patch`, category `fix`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 13:54:53 -07:00
gsxdsm	e5c9ea3870	fix(core): resolve the task's own terminal node in the node-override guard (#2812 ) ## What Fixes the defect #2793 measured but deliberately did not fix. That PR's two characterization tests are flipped here to assert the correct behaviour — which is what they were written to do. ## The bug `updateTask({ nodeId })` passes through `validateNodeOverrideChange` twice, and both calls were wrong in different ways: \| call \| how it answered "is this terminal?" \| \|---\|---\| \| `branch-and-pr-entities.ts:568` \| `resolveTaskWorkflowIrSync` — the default workflow for every task under PostgreSQL \| \| `task-update.ts:53` \| no options at all → `defaultIsTerminalNodeId`, the bare literal `nodeId === "end"` \| On a board whose terminal node is not named `end`, the FN-7641 guard inverted in both directions: - an override to a non-terminal node that happens to be named `end` was rejected with a merge-proof error about finalizing a card the operator was not finalizing; - an override to the board's real terminal node was written verbatim, no error, card unadvanced — the silent no-op FN-7641 exists to prevent. ## The fix A new `isTaskTerminalNodeIdAsync` resolves the task's own workflow, with the identical literal fail-soft for an unresolvable one. Both call sites use it — pre-resolved, because `validateNodeOverrideChange`'s callback is synchronous and it asks the question at most once. Nothing forced the sync call at either site: both frames are already `async` and already awaiting. That is the same finding as #2809's review, one file over. The sync helper is deleted, not kept as a fallback. Keeping both would re-create the half-conversion this program keeps finding — one caller resolved, one not, and no way to tell from a call site which it got. `branch-and-pr-entities.ts` also leaves the sync-resolver call-site allow-list (ratchet green, 3/3), the second of the six allow-listed sites to close. ## Why both halves were needed — and how that is proven #2793's mutation matrix showed the rejected-`end` case is over-determined: both guards independently called it terminal, so correcting either one alone changed nothing an operator could see. That is why fixing only the allow-listed sync site would have looked like progress and delivered none. Re-measured here, on the fixed tree: \| state \| result \| \|---\|---\| \| both guards fixed \| 3/3 pass \| \| inner guard reverted to no-options \| 1 fails \| \| outer guard reverted to the literal \| 1 fails \| ## Tests #2793's two cases now assert the fixed behaviour and keep their reasoning: - the non-terminal `end` override is written, and the card stays in review — a routing change, not a finalize; - the real terminal `finish` override is refused without merge proof, and the field is not written on the way to refusing. The fixture-integrity case (`finish` is the end node, `end` is not) is unchanged — it is what stops both assertions passing for the wrong reason. ## Verification - terminal-node suite — 3/3, both-halves matrix above - sync-resolver call-site allow-list ratchet — 3/3 - `pnpm test:gate` — exit 0 - full live-PG E2E surface — 151/151 - `pnpm lint` — clean Changeset included (`patch`, category `fix`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 13:15:04 -07:00
gsxdsm	ed83fd6ec3	batch-core: node-override guards let a running task be re-routed on a renamed board (45 → 43) (#2821 ) ## The defect Two guards in `node-override-guard.ts` answered a role question with a column name: - `task.column === "in-progress"` refuses changing a task's node override mid-flight. On a renamed board it never matched, so an operator could re-route a running task — precisely what the guard exists to prevent, and the failure is silent because the guard simply returns `allowed: true`. - `task.column !== "done"` gates overriding to the terminal node. On a renamed board it never matched either, so the override was refused for exactly the tasks that had legitimately reached the end node. Both fail in the direction that looks like normal behaviour rather than an error. ## Why the lanes are injected rather than resolved in place `validateNodeOverrideChange` is synchronous by design, and its existing `isTerminalNodeId` option already establishes the pattern: callers with cheap IR access inject, callers without keep a documented literal fallback. Both production callers now supply the lanes — `branch-and-pr-entities.ts:594` (which already injected `isTerminalNodeId`) and `task-update.ts:53`. That was the deciding factor: an optional parameter that only tests fill is the inert-injection shape this program keeps finding, where a guard reads as converted, its test passes because the test injects the value, and production keeps the literal. I checked both call sites had a store in scope before adding the option. `resolveNodeOverrideLanes` lives beside the guard rather than in the callers, so the two cannot drift about what "executing" and "completed" mean. ## Fallbacks A workflow expressing no trait on any column is a v1 upgrade — `synthesizeDefaultColumns` emits `traits: []` everywhere — not a board without these roles, so it keeps the legacy ids. Same for an unresolvable workflow. Both preserve exactly the behaviour the literals already had. ## Verification - Mutation-verified per guard: restoring `task.column === "in-progress"` fails a case; restoring `task.column !== "done"` fails a different one. - The suite also pins the paired negative — resolving lanes must not turn the guard into a blanket refusal for a task outside every WIP lane. - `node-override-guard.test.ts` → 27 passed - `pnpm test:gate` → 161 + 487 + 13 + 71 - `--strict` → exit 0; `tsc --noEmit` and `pnpm lint` → 0 errors Census: batch-core scope 45 → 43; repo total 255. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - Bug Fixes - Node overrides now correctly recognize workflow-defined in-progress and completed lanes, including renamed columns. - Override validation falls back safely for legacy or unresolved workflows. - Prevented validation from using stale task-column information during updates. - Tests - Added coverage for workflow lane resolution, legacy fallbacks, renamed lanes, and override eligibility. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 13:08:25 -07:00
gsxdsm	240a6be0aa	fix(core): dependency update deadlocked on a self-blocked task (#2810 ) ## The bug `updateTaskDependenciesImpl` wraps its whole body in `store.withTaskLock(id, …)`, then reads the current blocker with `readDepTask(task.blockedBy)` → `store.getTask()`. `getTaskImpl` opens with `withTaskLock(id, …)` too, and the per-task lock is non-reentrant. So when `blockedBy` is the task's own id, the call waits forever on a lock its own frame holds — and holds that lock while doing so, leaving the row permanently unlockable. ## Found by generalising #2809, not by luck #2809 removed one `getTask`-inside-`withTaskLock`. An AST scan for the same shape across `packages/core` and `packages/engine` returned exactly three sites: \| site \| verdict \| \|---\|---\| \| `lifecycle-ops.ts:1049` \| the deadlock fixed in #2809 \| \| `update-task-deps.ts:233` (`assertTaskExists`) \| safe — a self-dependency is rejected 15 lines earlier \| \| `update-task-deps.ts:344` (`readDepTask`) \| this bug \| Both surviving sites carry the same `FNXC:SqliteDualPathCleanup` note — "In backend mode, readTaskFromDb uses store.db (SQLite) which is unavailable. Replace with async store.getTask() calls." That port is the common cause across the whole class: it swapped a lock-free read for a lock-acquiring one. ## Why `blockedBy === id` is reachable The dependencies list rejects self-reference explicitly ("Task X cannot depend on itself") — and that guard is precisely why the sibling `assertTaskExists` read on this same lock is safe, so it is left unchanged. `blockedBy` has no such guard: `updateTask({ blockedBy })` accepts the task's own id. The first test asserts that rather than assuming it. The whole regression rests on that state being reachable, so it is proven, not stipulated — and it also pins the asymmetry, so a future guard on `blockedBy` will show up here as a deliberate change. ## The fix Return the in-lock copy already in scope instead of re-reading. One line, no new read path, and strictly more correct than a re-read: it is the state this mutation is reasoning about, rather than whatever a concurrent writer left behind. ## Verification - Mutation-verified against the real defect. With the fix reverted the regression case fails by name — `updateTaskDependencies did not settle within 8000ms — deadlock` — while the precondition and the ordinary-path cases stay green. That is the actual pre-fix behaviour. - A differential covering the ordinary case (blocked by another task). Without it, a fix that short-circuited every blocker read would pass everything else. - Timeboxed for the same reason as #2809: a deadlock otherwise surfaces as a suite-level timeout naming no case. Not a flake knob — the fixed path settles in ~0.5 s and the broken one never settles. - `pnpm test:gate` — exit 0 - `pnpm lint` — clean Changeset included (`patch`, category `fix`). Independent of #2809 — different file, no overlap — but the same class, and the scan above is the argument that the class is now closed. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:12:33 -07:00
gsxdsm	74cba4b46d	batch-core: one shared landed-lane helper for the source-issue surfaces (75 → 72) (#2783 ) ## batch-core continued — the source-issue cluster Follow-on to #2780 (merged). Scope is still `packages/core` + `packages/dashboard/src`. ### The defect Five places asked the same question — has this task landed? — and all five compared against the literal `done`: \| surface \| consequence on a renamed board \| \|---\|---\| \| GitHub source-issue commenter \| never comments on or closes the source issue \| \| GitLab source-issue commenter \| same \| \| GitLab `closedAt` backfill reconciler \| finds nothing, reports a clean scan \| \| session-diff boundary \| finished tasks diff against an already-merged branch \| \| tracking-comment transition \| (already converted; left alone) \| The commenters are the sharpest case: they returned before reading a single setting, so on a renamed board the feature looked disabled rather than broken — an operator checking `githubCommentOnDone` would see it enabled and still get nothing. The backfill is the quietest: `scanned: N, filled: 0` reads as "nothing to do", so the failure was indistinguishable from success. ### The fix One home: `packages/dashboard/src/task-lifecycle-lanes.ts`. Callers now only ask. Five copies of one question is exactly how the halves drift apart — the motivating incident is FN-6115 → FN-6118 → FN-6123, where the same affordance was fixed three times because it lived in two components. This also folds in the duplicate landed-lane helper I had left in `register-session-diff-routes.ts` in the previous PR, which was the sixth copy waiting to happen. Two helpers, and the difference is deliberate: - `landedColumnsForTask` — `complete ∪ archived`. Membership, since a board may declare more than one column carrying either role, and `columnsWithFlag(...)[0]` would silently ignore the second. - `completeColumnsForTask` — complete only. The GitLab backfill's own FNXC note records that archived tasks live in `archiveDb` and are intentionally excluded, so it must not widen to the archived role just because the shared helper offers it. Today it lists with `includeArchived: false` and would see no archived rows either way — but that is an incidental property of the query, not the contract. The test pins the difference so the two are not later "simplified" into one, which would change that caller's behaviour without touching it. Both treat an empty resolved set as unexpressed, not absent — the v1 hazard: `synthesizeDefaultColumns` upgrades a v1 graph with `traits: []` on every column, so reading empty as "no complete lane" would stop these surfaces firing on every pre-v2 project. The reconciler is two-stage on purpose: the cheap provider and `closedAt` tests run first and reject almost everything, so a workflow read only happens for real candidates, and it shares one IR cache across the scan — one read per distinct workflow rather than per task. ### Census `batch-core` scope 75 → 72; repo total 338. ### Verification - `pnpm --filter @fusion/dashboard exec tsc --noEmit -p tsconfig.json` → 0 errors - `pnpm lint` → 0 errors - commenter + reconciler suites → 63 passed; helper suite → 5 passed - Mutation-verified: making the helper ignore its resolved set fails 1 of 5. --- ## Round 2 — server.ts, chat.ts, and a correction Census: 75 → 67 across this PR. ### The correction (see the review thread above) My first pass gated the source-issue commenters on `landedColumnsForTask` (`complete ∪ archived`), which widened the trigger — `to === "done"` never fired on archival, and the landed set does. Both commenters now use `completeColumnsForTask`, and the unused `hasTaskLanded` wrapper is gone. The ratchet for it is pinned on the default board, deliberately: a widening is visible exactly where the legacy names still apply, so no renamed-board fixture would catch it. ### `chat.ts` — three sites, and a pair that had to move together - Chat verification required `column === "in-progress"`, so on a renamed board every chat-driven verification was refused with a message naming a column the board does not have. - The planner refinement pair. Two separate guards decide this feature: `createSession` registers the tool only for a finished task, and the tool's own `execute()` refuses a non-finished source. Both compared `done`. Converting only one half would have offered the tool and then had it refuse itself — the half-converted-pair shape. The new test asserts both halves in one case (tool present and refinement created), and each half reverted independently fails it. Existing `chat-manager` coverage caught neither revert, which is why the case exists rather than relying on the suite that was already there. Complete-only again, not the landed set: an archived task is off the board and is not a refinement source. ### `server.ts` - Planner-chat retention — the archival cutoff was a literal, so on a renamed board task-planner chat sessions were retained forever; the rule this listener exists to enforce never fired. Resolved, and awaited inside the existing fire-and-forget chain rather than by making the listener `async` — `task:moved` has synchronous subscribers whose ordering is load-bearing elsewhere, and a chat-row delete is not the right place to introduce a microtask boundary into that emit. - `isBadgeEligibleTask` — deliberately NOT converted, and marked as backlog. On a renamed board it is genuinely wrong: an archived card stays badge-eligible, its snapshot is never evicted, and the cache grows for the daemon's lifetime — the exact memory leak the predicate was added to fix, back under a different column name. What blocks it is measured, not assumed: both callers are synchronous `task:updated` / `task:created` listeners whose next statement is documented as "Update local cache immediately", so awaiting lets a second event for the same task interleave between the eligibility check and the cache write. I did not add an optional `archivedColumns` parameter, because nothing could fill it — the callers are the sync listeners. That is the inert-injection shape this PR's own review caught twice on #2780: the predicate would read as converted, its test would pass by injecting the value, and production would keep the literal. The unblocking change (a resolved-archived-lane cache on the badge-snapshot scope, keeping the predicate synchronous) is recorded at the site. ### Verification - `tsc --noEmit` → 0 errors; `pnpm lint` → 0 errors - `chat-manager` → 101 passed; commenter/reconciler/helper/badge suites → 55 passed - Mutation-verified per fix, including each half of the refinement pair separately <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Improved task lifecycle handling for renamed workflow lanes, including completed, archived, landed, and in-progress states. * Task lists now exclude completed tasks regardless of the completion lane’s name. * Chat verification and refinement actions now recognize configured workflow lanes. * GitHub and GitLab completion comments trigger only for genuinely completed tasks, not archived tasks. * Knowledge index refreshes and GitLab metadata updates now support custom completion lanes. * Tests * Added regression coverage for renamed completion lanes and archived-task behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:03:07 -07:00
gsxdsm	e84e9d7f60	fix: the caller audit — five unwired parameters, five defects in their callers (#2803 ) Seven fixes that were sitting on separate handoff branches with no owner while `main` moved. Consolidated, rebased onto current `main`, and verified together rather than only per-branch. The individual branches remain if a subset is preferred. This is the same consolidation that got `batch-core` and #2787 adopted. Close it if it breaks queue policy — the branch keeps the work safe either way. ## Where these came from #2787's review found an optional parameter whose production caller never passed it. That is a class, so I ran it against everything I had landed and found five more. All five turned out to have their real defect in the CALLER, not the parameter — in four of them the parameter was unreachable: \| unwired parameter \| what was actually wrong \| \|---\|---\| \| `blocker-fanout.escalationColumns` \| the hold default made the count zero — no bottleneck warning was emitted at all \| \| analytics `columnFlagsByName` \| routes never built a map — 0 in-progress / 0 in-review beside correct cost totals \| \| `isLegacyAutoMergeStampCandidate` \| the read queried a column a renamed board does not have, so the backfill iterated nothing \| \| `rankAssignedTasksForWakeDelta` \| `getTasksByAssignedAgent`'s `excludeArchived` used the literal — archived cards returned as open work \| \| `duplicate-intake.columnFlagsByColumnId` \| intake could archive or soft-delete a newly created task as a duplicate of finished work \| The heuristic worth keeping: an optional parameter no production caller fills is a marker pointing at an unexamined caller. The census cannot see any of these five — every gate is a `Set`/array literal or a query filter, i.e. a definition rather than a comparison. ## Also included - `executor.ts` — the stale-spec guard did the exact thing its own comment forbids: on a renamed board it ran on a LIVE task and pulled it out of execution into replan. `activeMergeStatuses` protected merging cards by accident, which is why the symptom looked arbitrary. - `register-project-routes.ts` — project health reported 0 active tasks; its list also still contained `triage`, dead since U11. - `dashboard/app/utils/taskTiming.ts` — a second copy of `getTotalAgentActiveMs`. Core's was converted; the card chip imports this one, so the census counted the site as done while the rendered number stayed keyed on `"in-progress"`. ## Verification Verified as a set: `pnpm test:gate` 161 / 13 / 487 / 71 · core suites 15 passed · engine 7 · dashboard 12 · four `tsc` targets clean · lint clean · census `--strict` exits 0. Each fix is revert-proven individually; the specific case that fails is named in each test header. ## Two honesty notes Three guards here are structural, not behavioural, and say so in their headers. `sanitizeAgentTaskLinks` is a closure inside `createApiRoutes`; the analytics aggregators need a live `AsyncDataLayer`; the stale-spec guard sits deep inside `execute()`. Each ratchet fails on revert — verified — but none is an end-to-end proof, and the headers state which half they cover. One of my behavioural test sets would have lied. The intake-dedup cases drive `findSameAgentDuplicates` directly; I removed the wiring to measure the revert and they stayed green, because they pin the predicate and not the caller. That is the exact illusion this audit was chasing, reproduced in my own file. The forward now has its own structural check. ## Deliberately not included `worktree-pool.ts:1205` — it fails safe (a missed match protects a branch from cleanup rather than deleting it) and sits in the merger's branch-reaping path where the opposite error destroys work. That deserves its owner's judgement, not a drive-by conversion. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:02:53 -07:00
gsxdsm	8c9b84ae38	batch-core: packages/core + dashboard/src lifecycle conversion (129 → 92) (#2780 ) ## batch-core — `packages/core` + `packages/dashboard/src` Shared branch: two workers are converting into it. Opening the PR because the branch was green with none, and a branch without a PR merges nothing. ### Census Measured with `node scripts/lifecycle-column-census.mjs --json`. \| \| guards \| \|---\|---\| \| batch-core scope at branch point \| 129 \| \| batch-core scope now \| 92 (51 files) \| \| repo total now \| 358 \| Files closed so far: `store.ts` 11→0, `task-merge.ts` 6→0, `live-agent-count.ts` 6→0 (marked, not converted — see #2762), `task-update.ts` 3→0, display-ordering + Wake Delta ranking 5→0, `register-git-github.ts` 4→0. ### The `register-git-github.ts` slice Three PR routes — `pr/create`, `pr/push-branch`, `pr/resolve-conflicts` — plus the `CHANGES_REQUESTED` handler each compared `task.column !== "in-review"`. On a renamed board none of them matched, so every PR affordance the dashboard offers was refused for a card sitting in the lane that board calls review, and the refusal named a column that does not exist there. All four now share one helper, `reviewColumnsForTask`, which gets two things right that this program has repeatedly gotten wrong: - Membership, not a single id. It takes the broad review set (`mergeOrchestration ∪ mergeBlocker ∪ humanReview`). `resolveLifecycleColumns` returns the first column per trait, so a single-id answer silently ignores a board that declares a merge lane and a separate human sign-off lane. These guards only refuse or permit — they never move the card — so over-admitting costs nothing while under-admitting refuses a request that should have worked. - An empty resolved set means UNEXPRESSED, not absent. `synthesizeDefaultColumns` upgrades a v1 graph by emitting every default column with `traits: []`, so a v1-upgraded workflow resolves to an empty review set while its `in-review` column plainly exists and holds the card. Reading empty as "this board has no review lane" would refuse these routes on every pre-v2 project — a worse regression than the one being fixed, and invisible to any v2 test. This is the dashboard twin of the `fn pr create` guard in `packages/cli/src/commands/pr.ts` (#2775). The two surfaces answer the same question and now agree — FN-5893 surface enumeration. ### Testing note: why the seam and not the routes I wrote route-level HTTP tests first and deleted them. An express fixture over `registerGitGitHubRoutes` hangs — every case, including the pure refusals, times out at 4s, because registering the router starts background work the fixture never satisfies. Making it run would mean mocking git, the GitHub client, and the pollers: a mock-the-world shell, which is what the project's do-not-add-slow-tests rule (FN-5048) says to avoid in favour of a narrow seam. `reviewColumnsForTask` is the narrow seam — it holds the entire decision, and the four call sites now do nothing but ask it and render its answer. Six cases pin it: the renamed lane is returned and `in-review` is not, a two-lane board returns both, a v1-upgraded board falls back, an unresolvable workflow falls back, and the refusal renders lanes an operator can act on. Mutation-verified, both directions: reverting the helper to the legacy literal fails 2 of 6; treating an empty set as an answer fails 1 of 6. One fixture bug worth recording, since it would have made the two-lane case vacuous: the trait id is kebab-case `human-review`, not `humanReview`, and the built-in traits must be registered via `import "@fusion/core"` before flags resolve. ### Verification - `pnpm --filter @fusion/dashboard exec tsc --noEmit -p tsconfig.json` → 0 errors - `pnpm lint` → 0 errors - `register-git-github.review-lanes.test.ts` → 6 passed --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 09:28:27 -07:00
gsxdsm	18641ba5d2	fleet: the age-staleness hydration site #2746 missed (3rd time in this file), and a blocker that blocked forever (#2749 ) ## Census \| \| before \| after \| \|---\|---\|---\| \| `packages/core/src/task-age-staleness.ts` \| 4 \| 0 \| \| `packages/core/src/blocker-fanout.ts` \| 4 \| 1 (the marked no-metadata fallback) \| \| repo backlog \| 581 \| 573 \| Baseline re-recorded; `--strict` exits 0. ## Both were the unconverted sibling in an already-converted file That is the shape this program keeps re-finding, and both files here even carry notes about previous P1s on the same question. ### 1. Age staleness never fired `getTaskAgeStalenessSignal` returns `undefined` unless the card is in wip or review, then picks its warning/critical thresholds by which of the two it is. Keyed on the literals, a renamed board produced no age-staleness badge at all. That is the worst shape a monitoring failure can take: a missing warning is indistinguishable from health. Nothing looks broken — "this card has been sitting in progress for a day" simply stopped being said. `reads.ts` already resolves `holdColumn` and `reviewColumn` per row for the sibling signals. Its own comments record a P1 where exactly this role was threaded into a helper but omitted at both hydration sites — "same defect, same file, one role over". So this adds the third resolver (`resolveWipColumnForTask`, mirroring the review twin) and threads both lanes at both sites, off the same per-pass IR cache. The signal's reported `column` deliberately stays on the legacy id: that field is its public shape, which consumers switch on, so renaming it is a separate breaking change rather than part of resolving a guard. ### 2. A blocker that blocked forever `isStaleBlockedByBlocker` decides whether a `blockedBy` marker is stale. Keyed on the literals, a finished blocker on a renamed board never read as stale — so the dependent kept its marker permanently and its "waiting on" badge pointed at work that shipped days ago. Every path that clears a stale marker consults this predicate first, so nothing else rescues it. `computeBlockerFanoutMap` — the only production caller — already takes `terminalColumns`/`holdColumn`/`classify`, and the file documents two separate P1s about getting this right. The predicate sat on the literals and the call passed nothing. Both are fixed, and that matters more than it sounds: converting the predicate alone would have changed nothing at runtime while the census scored it as a 4-site win. That is the half-conversion trap, and it is why the wiring gets its own revert proof below. ## Revert proof — each reverted alone \| reverted \| result \| \|---\|---\| \| age-staleness lanes → literals \| 3 failed / 8 passed \| \| blocker predicate → literals \| 2 failed / 9 passed \| \| fanout wiring (`classify` not consulted) \| 1 failed / 10 passed \| \| none (shipped) \| 11 passed \| Each group also carries a paired negative — a non-active lane still raises no staleness signal, and a live blocker is still not stale — so neither fix can degrade into "always fires". ## Verification - 4 core suites (blocker/staleness/age/reads) — 33 passed, no regressions - new suite — 11 passed - `pnpm test:gate` — 10 / 158 / 487 / 71 · `pnpm lint` clean · core `tsc --noEmit` 0 errors ## The 1 remaining `blocker-fanout.ts` keeps one `DELIBERATE-LITERAL`: the no-metadata fallback for an unconverted caller. Deleting it makes an unresolved caller read every blocker as non-terminal, so stale markers would never clear at all — strictly worse than the legacy behaviour it would replace. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:35:24 -07:00
gsxdsm	86a2b48968	fleet: branch-group-ops 6 → 0 — an agent asking for its next task was told there was none (#2739 ) Second application of the sync-filter pattern decided in #2737. `branch-group-ops.ts` 6 → 0. ## The failure `selectNextTaskForAgentImpl` picks an agent's next task by filtering the board for its WIP lane, then its hold lane — both `task.column === "<literal>"`. On a renamed board both filters match nothing, so an agent asking for work is told there is none, with its own assigned tasks sitting in the list it just fetched. No error, no log line. The agent idles. `pauseTaskImpl` had the same shape: pausing a running card on a renamed board left its `status` untouched, so the UI kept showing it as working. ## Consumer, not a gate — checked rather than assumed Applying the #2724 test to this file, since it sits closer to the persistence layer than the reconciler did: its only SQL predicate is `eq(table.projectId, ...)`. Nothing here compares a column to a literal in SQL, so there is no second encoding of these questions to diverge from. The list arrives from `store.listTasks` and the filters select among rows already in hand. Async predicates were the alternative and would have turned these filter chains into sequential awaits inside the dispatch path. One prefetch, one IR read per distinct workflow, filters stay synchronous. `pauseTaskImpl` resolves for the single task it holds rather than joining a map — different entry point, one id in scope, and a map would have exactly one entry. ## Revert proof \| reverted \| result \| \|---\|---\| \| the wip literal \| renamed WIP case fails: `expected null to be truthy` \| \| the hold literal \| renamed hold case fails identically \| The new test calls the impl directly with a store fake resolving a renamed IR. The existing `selectNextTaskForAgent` coverage drives a real store harness, so exercising a renamed vocabulary there means registering a real custom workflow and moving cards through it — heavier than the question, which is only which lane the filters name. The bind evaluator runs for real; only the store is faked. A third case pins that the hold filter keeps its `userPaused` exclusion, so a filter matching every column would not satisfy the other two. Related coverage checked before writing a new file: `agent-heartbeat-worktree-renamed-hold.test.ts` covers the requeue target on a renamed board, not the dispatcher's selection filters — different branch of the same subsystem, so a case added there would have read as duplicate coverage of the wrong thing. ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 20 passed across the routing-policy and new dispatch suites · core `tsc` clean · `pnpm lint` clean · census `--strict` exits 0. 🤖 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 agent task selection when workflow lane names or IDs have been renamed. - Agents now correctly resume assigned in-progress or queued tasks across customized workflows. - Prevented agents from selecting tasks paused by users, including on boards with renamed lanes. - Updated task pausing behavior to correctly reflect lifecycle stages beyond default lane names. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:09:36 -07:00
gsxdsm	86639f2ce4	fleet: planning drain + archive writers 12 → 4 — one stale row starves planning, and a finaliser that wrote an undeclared column (#2742 ) Claimed on #2733 before starting. `in-process-runtime.ts` + `task-artifacts-ops.ts` — 12 → 4. ## 1. The planning drain: one stale row stops planning for the whole project FN-8470's own note on this code says it: one orphan earlier in created_at FIFO prevented every later planning continuation from dispatching. So on a renamed board the literal terminal pair did not mis-handle one card — an archived or completed card's stale work item read as live, stayed in the due set, and starved the drain behind it. The two classifiers take an optional terminal set, which is this file's own injection idiom (the specification-complete reaction already takes a `resolveIr` dependency so the pure passes are testable without constructing a runtime that would attach to the real project registry). Optional is load-bearing: a required parameter would have compiled at every existing caller and then answered "not terminal" for everything. That is the silent direction, and both halves are asserted in the test. ## 2. `moveToDoneImpl` writes `task.column` directly This is the store's own finaliser, not a `moveTask` caller — so its literal is not caught by `moveTask`'s unknown-column validation the way every converted call site in this program is. It silently persisted `done` on a board that does not declare it, and then emitted `to: "done"` to every listener. This is one of the few sites where a literal writes bad state rather than merely failing to act. A workflow declaring no complete lane now throws instead of inventing one — #2733's rule: a missing field on a resolved struct is an answer, and `?? legacy` discards it. ## 3. The unarchive destination — three decisions in four lines, all literal \| pre-archive column \| lands in \| \|---\|---\| \| unusable / archived \| the complete lane \| \| the wip or review lane \| the hold lane (its worktree and session are long gone) \| \| anything else \| back where it was \| The second is the expensive one: a card archived from the wip lane was restored straight back into it with no worktree, and the scheduler then counts it as a live holder occupying a slot. Made async — its one production caller already is, and the sync alternative is the PostgreSQL no-op documented in #2703. ## Also - The mission-error requeue (guard and destination in one change): an errored mission task stayed in the wip lane holding a slot, because the guard never matched. - The planner-chat retention cutoff on archive — the quiet direction of this defect class: nothing breaks, data that should be deleted simply accumulates, and the only symptom is storage growth nobody attributes to a column name. ## The live defect is not where the census points `reliability-metrics.ts`'s 6 guards are pure historical readers over activity-log entries, and the dashboard does not call them. The live path is `server.ts`'s `getTaskMovedCountsByDay({ toColumn: "in-review" })` — a SQL query filter, the class the census counts separately. So the operator's reliability panel reads zero on a renamed board because of a query literal, and converting the six guards the census reports would change nothing an operator sees. Converting historical readers also risks reinterpreting past events under today's traits, which is a different decision from converting a live guard — I am not making it inside a vocabulary sweep. Worth generalising for the fleet: a file's census count and its live exposure are different numbers. This is the second file where the reported guards are the inert copy and the real one is a query (`executor.ts:5805` was the first). ## Verification `pnpm test:gate` 10 / 158 / 487 / 71 · 31/31 continuation suites · 8/8 archive PG suites · in-process-runtime PG suite green · 5 new cases, 2 red on revert · `tsc` clean in core and engine · `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-30 07:53:28 -07:00
gsxdsm	7c408ef650	fleet: merge path 10 → 2 — a merged PR never advanced its task on a renamed board (#2733 ) Claimed on #2728 before starting. The merge path: `merge-queue-ops-2.ts` + `merger.ts` — 10 → 2, both survivors flagged with reasons. ## A merged PR never advanced its task on a renamed board `applyPrMergedTransition` is what moves a card when GitHub reports a PR merged. Every guard in it was a default-lineage literal, and they all failed in the same direction: \| guard \| renamed board \| \|---\|---\| \| `column === "done"` → skip as already-done \| never matched, so a complete card was re-processed \| \| `column !== "in-review"` → bail `wrong-column` \| always matched, so a card sitting in review bailed \| Net effect: a PR merged on GitHub never advances its Fusion task. The operator sees a merged PR whose card sits in review forever — which reads as a broken webhook, so it gets debugged in the wrong place entirely. That is the most expensive property of this defect class: it does not just fail, it misdirects. One snapshot now covers the pre-check, the deliberate re-read (a merge can land between checks), and the move target. The target is asserted in the test alongside the guards, because converting guards alone would admit the card and then move it to a column the board does not declare. ## merger.ts - The orphan-stash liveness guard classified every finished task as unfinished on a renamed board, so orphaned stashes were never cleaned up. Unioned with the legacy ids: too strict here leaves clutter, too loose discards a stash whose task is still running, so over-inclusion is the safe direction. - The worktree-conflict scan filters by worktree path before resolving lanes. The naive order — resolve, then filter — is exactly what made the github-tracking reconciler scan proportional to task history (#2714 review). Lesson transferred rather than re-learned. - The deprecated `aiMergeTask` already-finalized guard. ## Two flagged, not converted `merge-queue-ops-2`'s sync enqueue guard runs inside `store.db.transactionImmediate`. A synchronous lane resolution reads `getTaskWorkflowSelectionImpl`, which returns `undefined` unconditionally in PostgreSQL mode — so a "conversion" there would drop the census by one and behave exactly as the literal (the finding from #2703). Converting it properly means making the path async or pushing the trait read into SQL: store architecture, not a call site. Left literal with that note, so the next worker does not turn it into a false green. `merger.ts`'s last comparison is the same class. ## Pre-existing red, reported not folded 22 failures in `packages/dashboard/src/__tests__/routes-github.test.ts` — spec revise/rebuild and approve/reject-plan, all asserting moves to `triage`, the column U11 deleted. Verified by reverting my diff and re-running: identical 22. Same stale-literal-in-a-test class as the two assertions #2720 fixed, and it is 22 tests pinning a column that does not exist — worth someone owning deliberately rather than as a rider here. ## Verification census 10 → 2 · `pnpm test:gate` 487 / 71 · 23/23 across three merger suites · 4 new cases, 2 red on revert · `tsc` clean in core and engine · `pnpm lint` clean. ## Also examined and deliberately left alone - `live-agent-count.ts` (6 guards) — every literal there is the documented degradation path for a task shape that was not enriched, and both production callers already enrich (`useExecutorStats`, `fn project`). Converting them converts nothing; deleting them removes the fallback that fixtures rely on. The invariant that matters is caller enrichment, which is not a literal at all. - `task-merge.ts` (6 guards) — `getTaskMergeBlocker` is a pure function with no store; its callers inject `resolveTask`. Resolving lanes needs a matching injected resolver, which is an interface change across every caller. Also worth a decision first: its dependency check accepts `in-review` as satisfied while the store's `blockedBy` computation (#2720) does not — two definitions of "dependency satisfied" in one codebase, and I am not settling that one silently inside a vocabulary sweep. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 07:08:16 -07:00
gsxdsm	ab715cbd39	fleet: default-workflow-hooks.ts 7 → 0 — every duration display read ZERO on a renamed board (#2734 ) Claiming `default-workflow-hooks.ts` (7 → 0), verified free against every open PR's diff first. ## Not a vocabulary tidy — three silent zeroes This file's header names it for the default workflow, but the store runs it on the flag-ON path for every workflow: the trait registry resolves each hook by trait id, not by workflow. `reopen-semantics-by-role.test.ts` already documents that exact hazard for the reopen predicates. The timing, completion and in-review hooks had the same defect and were not part of that conversion. On a renamed board, with nothing thrown and nothing logged: - `applyTimingEffects` accrues `cumulativeActiveMs` while a card sits in the WIP lane. With the lane named, the exit test never fires — so no active time is ever accrued, and `productivity-analytics.ts`, `task-timing.ts` and every duration display read zero. - `applyCompletionTimingEffects` never stamps `executionCompletedAt`, so a finished card looks unfinished to anything reading that field. - `applyInReviewEnterEffects` returns early, leaving the recovery counters set. The file already had the idiom — `ctx.lifecycleColumns`, `planningColumnsOf`, `liveWorkColumnsOf` with `LEGACY_` fallbacks — so this adds no abstraction. One deliberate detail: `applyTimingEffects` resolves the WIP lane once into a local rather than reading it twice. The exit test and the re-entry test have to agree about which column is WIP, or a rename makes the accounting count an interval twice, or not at all. ## A test that would have lied to me I wrote the new cases through `applyDefaultWorkflowMoveEffects` first, and all three failed on the DEFAULT lineage too. The dispatcher resolves hooks by trait, and neither test IR declares the `timing` trait, so those hooks never ran at all. That failure looks exactly like a conversion bug. Going through the dispatcher would have been testing the trait registry's wiring rather than this change — so the cases call the converted functions directly, and the reason is recorded in the test. ## Revert proof — all three, each naming the renamed lineage \| reverted \| failure \| \|---\|---\| \| the `in-progress` literals \| `renamed lineage accrued no active time: expected undefined to be 300000` \| \| the `done` literal \| `renamed lineage did not stamp completion: expected undefined to be '2026-07-30T00:00:00.000Z'` \| \| the `in-review` literal \| `renamed lineage kept its recovery counter: expected 3 to be undefined` \| Every case runs on both lineages and the default one passes either way — which is the point of running it. ## A finding I did not act on `evaluateMergeBlockerGuard` appears exactly once in the repo — its own definition. And the file header says it is "implemented as the `evaluateDefaultWorkflowGuards` reader", which does not exist either. The merge-blocker guard hook is defined and never consulted. I converted it (trailing optional lifecycle param, matching `DefaultWorkflowMoveContext`) but did not delete it: the header states this file is a deliberate parallel of `store.ts`'s flag-off path so the two can be parity-checked, which makes removing it a scope call for whoever owns that convergence — not something to decide inside a conversion. ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 22 passed across `default-workflow-hooks` + `reopen-semantics-by-role` · core `tsc` clean · `pnpm lint` clean · census `--strict` exits 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 07:05:05 -07:00
gsxdsm	61b82a2737	fleet: pure lifecycle predicates 17 → 5 — a monitoring signal that went quiet, and a blocker that waited forever (#2745 ) Claimed on #2742 before starting. Four pure modules — 17 → 5, every survivor flagged with a reason. All four are pure functions with no store, so the fix shape is the injected-set contract established in #2728, not an in-function resolve. ## Three failures that never error \| predicate \| what a renamed board got \| \|---\|---\| \| `getTaskAgeStalenessSignal` \| `undefined` for every card — age-staleness reported nothing \| \| `isStaleBlockedByBlocker` \| "not stale" for a blocker that was finished, paused in review, or retry-exhausted \| \| `areAllDependenciesDone` \| "not satisfied" for a dependency that had landed \| The first is the one to sit with: a monitoring signal that goes quiet is indistinguishable from health. The board looks fine while cards sit for days, and nobody investigates a metric that isn't alarming. The signal also chose its threshold pair by wip-vs-review, so both halves were literal. The second means the blocked card waited forever, silently — "not stale" is the answer that produces no event. The third is the third place "satisfied" is asked. It now gives the same answer as the store's `blockedBy` computation (#2720) and the merge blocker: complete or archived, unioned with the legacy ids. Three surfaces, one rule — which is exactly why I refused to settle it inside a vocabulary sweep the first two times it came up. ## Optional is load-bearing Both halves are asserted for every predicate: supplying lanes makes a renamed board work, omitting them preserves every existing caller. A required parameter would have compiled at every call site and then answered "not active" / "not stale" / "not satisfied" for everything. That is the silent direction, and no type checker catches it — which is the argument for optional-plus-legacy-default over a clean signature. The restart-recovery classifiers (with-progress / no-progress / merge-active) take the same set, and the combiner threads it to all three, so a caller cannot convert the outer question and leave an inner one literal. `isInReviewMissingWorktreeSessionStartFailure` is deliberately untouched — #2728 converts it and duplicating that would conflict. ## The five that remain - 3 are the ternary trait-fallback branches (`lanes ? … : legacy`) — the documented degradation path the census counts by design, not unconverted guards. I am not marking them `DELIBERATE-LITERAL` to move the number; that marker means "a lifecycle literal reviewed and kept", and mislabelling to flatter a count is how the instrument stops meaning anything. - `recoverInterruptedRuns`' filter sits behind a `listTasks({ column: "in-progress" })` query. The query is the live filter, so converting the redundant predicate moves the census and changes nothing an operator sees. Third file where the reported guard is the inert copy and the real one is a query. - `resolveWorkflowBypassGuards` is sync and receives only column strings — no task, no store. Converting it means adding lanes to `MoveTaskOptions` and threading them from the moves path, which another worker owns. Marked `DELIBERATE-LITERAL` as an explicit hand-off, with the consequence named: on a renamed board the operator's drag out of the wip lane was rejected by the transition validator, so a card could not be cancelled from the board at all (AGENTS.md's Move-Task hard-cancel contract). ## Verification `pnpm test:gate` 10 / 158 / 487 / 71 · 9 new cases, 5 red on revert · 13/13 with the archive PG suite · `tsc` clean in core and engine · `pnpm lint` clean · census 17 → 5. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 06:48:00 -07:00
gsxdsm	b6b28c3b0b	fleet: task-age-staleness 4 → 0 + the claim guard — an agent could claim a finished card, and no card was ever 'stale' (#2746 ) Two core clusters. 6 converted, 2 flagged. ## Two silent failures No card was ever stale. `task-age-staleness.ts` applies its signal only to the mid-flight and review lanes — a card in a hold or terminal lane is waiting or finished, not stale. Both lanes were named by id, so on a renamed board the signal returned `undefined` for every card and the stale-card warning never appeared anywhere on the board. An agent could claim a finished card. `claimTaskForAgent`'s terminal guard was `column === "done" \|\| column === "archived"`. On a renamed board neither matched, so the claim succeeded and the agent began work on completed output. ## The threshold selectors are a separate literal, and half-converting is worse than neither `task-age-staleness` has two independent uses of `in-progress`: the lane gate that decides whether the signal applies, and the threshold selectors that pick which warning/critical numbers to measure against. Converting only the gate admits a renamed-WIP card and then measures it against the review threshold — a wrong number, silently. Both are converted, and each is revert-proofed on its own: \| reverted \| result \| \|---\|---\| \| the lane gate \| 3 of the new cases fail (`expected undefined to be defined`) \| \| the threshold selectors \| the threshold case fails — a renamed WIP card gets the review threshold \| No new seam for either: the staleness signal already took a `context` object, and its one production caller (`task-store/reads.ts`) already holds a per-pass IR cache for precisely this kind of resolution. ## Cost stated rather than hidden The `reads.ts` resolution is unconditional, where the hold-column read directly beside it is gated on `task.paused`. That asymmetry is deliberate: the lanes this needs are exactly what decides whether the signal applies at all, so there is no cheaper gate available ahead of it. With the shared per-pass cache that is a struct build per card, not an IR read. ## Flagged and left counted `formatCurrentTaskLine` is a pure formatter over `Pick<Task, "column">` whose output prints the column name for a human reader — same class as `github-tracking-comments.ts:165`. It also degrades gracefully: the "(not active — X)" wording is lost on a renamed board, but "(X)" is still accurate, just less specific. Threading a resolution into a string builder to pick a word is the wrong trade. ## The recurring blind spot, fourth time None of the 12 existing staleness cases could have caught this — `lifecycle` is optional and they all omit it, so they assert the legacy fallback. Same for the reconciler's 33 (#2737) and `TaskReviewTab`'s 45 (#2744). This is now a consistent property of the optional-flags seam: the existing suite stays green through the conversion and through a broken one. Every file in this program needs at least one case that supplies flags, or the conversion is untested in both directions. Worth making an explicit review criterion rather than something each worker rediscovers. ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 31 passed across staleness / routing-policy / dispatch suites · core `tsc` clean · `pnpm lint` clean · census `--strict` exits 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 05:52:01 -07:00
gsxdsm	ddba730a59	fix(core): 8 reds across 4 files — incl. a real FN-8603 contract violation and a ratchet row pinning deleted code (#2725 ) ## Measured Full `@fusion/core` suite: 8 failed / 6 files → 1 failed / 1 file (4611 passed). `pnpm typecheck` exit 0 across every package, `pnpm lint` clean, gate 726. The one remaining failure is not mine to fix — see the last section. ## Four causes; two are product-side, not test drift 1. A real FN-8603 contract violation. `tool-output-budget.ts:116` had a bare `console.warn`, breaking the rule that production diagnostics route through the shared logger so severity markers and `FUSION_DEBUG` gating survive. `log-severity-spam-contract` caught it exactly as designed. Now `createLogger("tool-output-budget")`, kept at `warn` — an invalid operator-supplied budget is a real misconfiguration, not routine chatter. 2. A ratchet row pinning deleted code. The manifest pinned a `local reattached project ${project.id}` demotion in `central-core.ts` whose call site was deleted by `5ae6332563` ("collapse dead SQLite dual-path code"). Verified absent from all of `packages/core/src`, not merely moved. A manifest row for deleted code can only ever fail — it ratchets nothing — so it is removed with that provenance recorded in place. 3. An intentional settings overlap. `agentToolOutputMaxChars` now appears in both scopes. Admitted to the parity list because `settings-schema.ts:462` states the intent outright: "Project settings participate in the existing effective-settings merge, allowing a project-specific tool-output cap … to override global policy." Placed in `GLOBAL_SETTINGS_KEYS` order, as that test requires. 4. `maxPostReviewFixes` 3 → 10 — the third file pinning the stale 3. Driven off the exported `DEFAULT_MAX_POST_REVIEW_FIXES` rather than a fourth literal copy. That constant exists because the declaration default and two inline `3`s had already drifted apart once; adding another copy would guarantee a fourth drift. ## duplicate-guard: a narrow seam instead of a rebuilt mock Its 3 failures were `Cannot read properties of undefined (reading 'projectId')` — the fake modelled the deleted SQLite path (`db.prepare().all()`) and recovered the window by parsing a captured cutoff string. It broke when the query moved to `asyncLayer` + Drizzle. Rebuilding a Drizzle chain to recover a number the policy already returns would be mock-the-world for no gain, so the window policy is now one exported pure function — `resolveFingerprintWindowMs`, the byte-identical expression — that both the store query and the tests call. Two side benefits: the ±5s timing tolerance is gone (exact assertions), and the `Math.max(1, …)` floor now has coverage the old cutoff-parsing shape could not see. Load-bearing, verified by mutation: restoring the old 5-minute ceiling fails 3 of them; deleting the floor fails the new case. ## The remaining failure is a deliberately-deferred product decision `agent-logs-and-monitor.pg.test.ts > aggregateActivityAnalytics …` expects funnel stage `todo` count 2 and gets 0. This is already diagnosed and deferred by another worker, in `activity-analytics.ts:604`: > "The merged column landing in `triage` while the `todo` stage stays empty is a SEPARATE and larger question — it makes the funnel show a phantom 100% drop between Triage and Todo on every default board since U11 — and it is deliberately not settled here. Changing which stage the Planning column reports would retroactively alter how historical analytics read… Flagged for a product decision on PR #2669." The merged Planning column carries `["intake","hold","reset-on-entry"]` and `stageForTraits` prefers the earliest stage, so `intake` wins. Either fix — remapping the stage, or changing the expectation — silently settles how historical analytics read. I left it alone rather than pick a side inside a test-repair PR. ## Two "flaky" files that are NOT flaky — and I nearly mislabelled them `pg-test-harness-template-concurrency.pg.test.ts` and `moves-intake-only-hard-cancel.pg.test.ts` each failed in one full-suite run and not another, which reads as flake and would have earned a quarantine entry plus a 14-day deletion clock under the standing rule. Measured in isolation instead: \| File \| alongside other PG suites \| alone \| \|---\|---\|---\| \| `pg-test-harness-template-concurrency` \| fails intermittently \| 4 passed, 3/3 runs \| \| `moves-intake-only-hard-cancel` \| failed once \| 2 passed \| So this is shared-PG-template contention between concurrently running suites, not an inherent flake in either test. Quarantining them would have started a deletion clock on healthy coverage and hidden a real harness-parallelism interaction. Flagged for whoever owns the PG harness; no quarantine entry added. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Improved duplicate-detection window handling with consistent defaults, limits, and minimum values. * Invalid tool output limits now produce standardized warning messages while preserving fallback behavior. * Updated settings and workflow validation to accurately reflect supported configuration defaults and scopes. * Tests * Strengthened coverage for duplicate-detection windows and configuration parity. * Removed an outdated logging severity expectation tied to a no-longer-applicable message. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-30 05:33:27 -07:00
gsxdsm	8f2cddc5fd	fleet: update-task-deps.ts 7 → 0 — settles "dependency satisfied", and the store was writing a column U11 deleted (#2720 ) Claim announced on #2714 before starting. `packages/core/src/task-store/update-task-deps.ts` — 7 → 0. This one settles an open question and turned up a live bug on the shipped default board, not just on renamed ones. ## 1. What "dependency satisfied" means — settled, not guessed I flagged this in three files rather than swapping it three times independently (`executor.ts:12325`, `register-task-workflow-routes.ts:3995`, here). The answer has to be the same everywhere or the scheduler and the store disagree about which cards are blocked. Settled in the store, where `blockedBy` is actually written: - SATISFIED = the dependency's own board's complete or archived column. Archived counts: it is finished work the operator filed away, and reading it as unsatisfied blocks every dependent forever with no recourse short of editing the graph. - NOT review — a card in review is not done; its branch has not landed. - Unioned with the legacy ids, because a row can outlive the column it is stored in. On a renamed board the old literals matched nothing, so every dependency read as unresolved and `blockedBy` was pinned to the first one permanently — dependents never unblocked after the work landed. ## 2. The re-specification move was writing a DELETED column — on the default board `hasNewDependencies && column === "todo"` set `column = "triage"`. U11 (#2515) deleted `triage`, keeping `todo` as the merged Planning column. Measured, not assumed: ``` resolveDefaultWorkflowIr() columns: todo[intake,hold,reset-on-entry] in-progress[wip,…] in-review[merge,…] done[complete] archived[archived] ``` So the store has been writing a column the shipped board does not declare. And the emitted event hardcoded `from: "todo", to: "triage"` — `task:moved` is what the GitHub tracking poster, the auto-merge handoff and the executor's listeners react to, so every subscriber was being told about a column that does not exist. Now the guard reads the hold lane, the target is the intake lane, the log line names the real column, and when intake === hold (the default lineage post-U11) there is no move and no event — announcing a move into the column the card already occupies re-runs reset-on-entry effects in every listener. ## 3. Two existing suites taught me more than the conversion did `refine-duplicate-task.pg.test.ts` proved the union is required, in one run. My first version compared only the resolved lanes and refused a row sitting in `done` on a board declaring `published`: "Cannot refine KB-001: task is in 'done', must be in 'published' or 'editorial-review'". That row is real, and refusing an operator action on it is worse than accepting one extra column name. Over-inclusion is the safe direction for "may I refine this?" — the same reasoning as the executor's `resolveTerminalColumnsFor`. Two assertions expected `"triage"`. They were not protecting behaviour; they were protecting a stale literal that outlived its column. Updated with the measurement in the file, because a silently-changed expectation is indistinguishable from a broken one. ## Revert proof 1 of 3 new PostgreSQL cases reddens when the union is removed. Driven through the real store on PostgreSQL because `blockedBy` is persisted and resolution reads the workflow selection from the database — a mocked store would prove neither. ## Verification `pnpm test:gate` 487 / 71 · 13/13 in the two pre-existing dependency/refine suites · 3/3 new · `tsc -p packages/core` clean · `pnpm lint` clean · census `--strict` exit 0 (7 → 0 for this file). Changeset: none. `@fusion/core` is private, and while item 2 is an operator-visible fix on the default board, it lands as internal behaviour with no API change — say the word if you want one anyway for the release notes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 05:29:36 -07:00
gsxdsm	f6e460acdf	fleet: moves.ts 15 → 2 (hot path; one hoisted resolution, net one FEWER than before) (#2705 ) Claiming `packages/core/src/task-store/moves.ts` — 15 guards, largest unclaimed. This is the core move path, every task move in the system, so the conversion is built to add no work to it. ## Census before/after \| \| before \| after \| \|---\|---:\|---:\| \| `moves.ts` column guards \| 15 \| 2 \| \| repo backlog (this branch vs `origin/main`) \| 693 \| 679 \| Baseline re-recorded; `--strict` exits 0. (Backlog figures don't compose across my open fleet PRs — each branch carries only its own reductions. 693 → 679 is this branch against main as measured, not a running total.) ## Zero added cost, and actually one fewer resolution than before `moveTaskInternal` already resolves the workflow IR unconditionally at line 400 — the `useWorkflow` gate is gone — and already derived a lifecycle from it ~400 lines later for the trait hooks. So one hoisted `moveLifecycle` immediately after the IR resolution serves all 14 guards, and the later local now aliases it instead of resolving a second time. Net effect on the hot path: one fewer `resolveLifecycleColumns` call than before this PR. ## Converted: 14 6× `toColumn === "done"` → complete · 4× `fromColumn === "in-review"` → review · 1× `toColumn === "in-review"` → review · 2× `toColumn === "todo"` → hold · 1× `toColumn === "in-progress"` → wip Every site keeps its legacy id as the fallback. `undefined` here means no IR on this path or a v1 column-less IR, and a move must behave exactly as before when there is no basis to resolve from — this is the transaction that arbitrates capacity, so "unchanged when unresolvable" is the requirement, not a nicety. ## Flagged, not converted: 1 Line 309 — `task.column === "archived"` in the handoff-invariant check. It sits in a different function that runs before any IR resolution, so converting it would mean adding a resolution to a path that currently has none. That is a cost on the handoff path rather than the free reuse everything else here gets, so it wants a deliberate decision rather than my inclusion. ## Verification — the paths that matter, not just typecheck Because this is the move transaction, `tsc` + lint is not sufficient evidence: - `pnpm test:gate` GREEN — 158 + 10 + 487 + 71 - `workflow-capacity-invariant` + `move-path-equivalence` 7/7 (the in-transaction capacity gate lives in this file) - `handoff-to-review-atomicity` 4/4 - `store-movement` + `move-task-preserve-status` + `task-move-hard-cancel-ordering` + `transition-pending-and-status-clear` 16/16 - `pnpm lint` clean · core `tsc` clean · `--strict` exits 0 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 04:06:02 -07:00
gsxdsm	dc50425e98	docs: correct 104 future-dated FNXC timestamps across 61 files (#2680 ) ## What The FNXC convention exists so a reader can place a note against the change that motivated it. A stamp dated after the edit landed defeats exactly that. This is program-wide drift, not one author's slip — I contributed to it in my own commits this week, which is how I noticed it. ## Measured, on this tree 104 stamps across 61 files dated later than the day they were written, from one day ahead to 2026-10-19 (81 days): \| count \| date \| count \| date \| count \| date \| \|---\|---\|---\|---\|---\|---\| \| 50 \| 2026-07-31 \| 6 \| 2026-08-05 \| 3 \| 2026-08-13 \| \| 17 \| 2026-08-01 \| 1 \| 2026-08-07 \| 1 \| 2026-08-19 \| \| 7 \| 2026-08-02 \| 1 \| 2026-08-12 \| 2 \| 2026-08-26 \| \| 11 \| 2026-08-03 \| \| \| 3 \| 2026-10-19 \| An earlier number I circulated was ~70. That came from a narrower pathspec and was wrong; 104 is the measurement. ## How Each stamp is rewritten to the date of the commit that introduced that line, via per-line `git blame` — deliberately not stamped uniformly with today's date. A uniform stamp swaps a wrong date for a different wrong date and flattens the ordering that makes these comments navigable; blame preserves it. Times of day are untouched, and a blame date in the future is clamped rather than trusted. ## Why the verification is listed A docs sweep across 61 files is precisely where a stray edit hides, so the safety claims are mechanical rather than asserted: - every changed line begins with a comment marker — no code touched; - no test asserts an FNXC date later than today, so no `toContain` assertion on embedded source text can be silently invalidated (several such assertions do exist); - CSS files, which carry several of those assertions, are outside the pathspec. ## Verified lint clean · merge gate green (487 + 158 + 10 + 71) · `census --strict` exit 0 · tsc clean for core, engine, and dashboard (`tsconfig.app.json`). No behavior change. Comment text only. ## Not done here A guard preventing recurrence. A check that rejects an FNXC stamp dated after the commit would stop this returning, but it needs a decision about where it runs (lint rule vs. gate) and it is a behavior change to CI — it does not belong riding inside the sweep it would police.	2026-07-30 02:38:58 -07:00
gsxdsm	bc782d8d92	U12: resolve the move-path compatibility flag — trait hooks unconditional, legacy branch deleted (#2655 ) U12's headline goal. The raw `experimentalFeatures.workflowColumns` flag gated every task move; its six seams are now unconditional and the flag, its last two readers, and the 124-line inline legacy branch are deleted. ## Deleted, not converted The flag-OFF branch goes with the gate. Converting a branch we intended to delete would have left a second definition of every column side effect alive to drift — the defect this program has spent its length removing. Both readers flip in one commit because they are not separable: the preflight in `workflow-task-create-ops.ts` computes the `movePolicyPreflight` that `moves.ts` consumes and validates. Un-gating either alone either evaluates workflow move policies — with their plugin-gate side effects — whose result is ignored, or validates against a preflight that was never computed. ## Evidence, not assertion Equivalence (precondition 1). `moves-flag-equivalence.test.ts` (commit 1) ran the same journey under both flag states against live PostgreSQL and diffed the persisted row: identical across 128 fields plus an equal timing shape, over `todo → in-progress → in-review → todo → in-progress`. Mutation-verified both ways — stamping the flag-ON branch, and diverging the reopen hook, each fail it. And there was stronger evidence already on main that isn't mine. U2b's `move-path-equivalence.pg.test.ts` ran every scenario once per path and has been green across ~10 of them: `preserveStatus`, `preservePause`, timing accounting, `preserveProgress`, `preserveWorktree`, engine-source rehome, `in-progress → todo`. Two independently built harnesses agreeing is the best evidence this question has had. The flag was read by nothing in production. `experimentalFeatures` is global-only and no module writes it, so this path had never run for any project without a stale persisted value. That is also why a green suite was never evidence on its own — both paths were individually valid and only one was live. ## Two claims of mine this PR corrects 1. Seam 2 does not introduce new rejections. I said in #2639 and in the census that with the flag off there is no target validation, so flipping would add refusals. Reproduced the opposite: a move to an undeclared column already rejects on the legacy path with `Invalid transition: … Valid targets: …`. I found it because the discriminator I wrote to prove "the flag is the cause" failed. 2. My first equivalence test proved nothing. It used `updateSettings`; `experimentalFeatures` is global-only, so `getSettingsFast()` filtered the write out and `useWorkflow` was false in both runs. Caught by stamping the flag-ON branch and watching the test stay green. It now writes via `updateGlobalSettings` and asserts the flag took effect before the journey. U2b's harness carries the same warning independently — `MUST be updateGlobalSettings, NOT updateSettings`. ## The user-visible change Move rejections now report workflow-resolved targets instead of the hardcoded legacy adjacency table. Concretely: `Valid targets: in-progress, triage, archived` becomes `Valid targets: archived, in-progress`. That is the fix, not a regression — the legacy table still advertised `triage`, a column the default lineage stopped declaring at #2515, so an operator following the old message was told to move somewhere impossible. Likewise a move into `triage` is now refused rather than stranding the card in a column with no trait flags, invisible to every trait-driven sweep until reconciliation re-homes it. `live-move-path-undeclared-target.test.ts` characterised exactly that defect and carried `it.todo("should REFUSE a move into a column the task's workflow does not declare (U2b)")` — this fulfils it. ## Test migration \| file \| change \| \|---\|---\| \| `move-path-equivalence.pg.test.ts` \| deleted — every scenario ran once per path; purpose fully discharged \| \| `workflow-capacity-invariant.pg.test.ts` \| `setPath("inline"\\|"hooks")` → `assertMovePathLive()`; the probe is kept so capacity cannot pass because moves were broken for an unrelated reason \| \| `store-movement.pg.test.ts` \| asserts the refusal and that the legitimate backward move still works, so it reads as a narrowing \| \| `raw-workflow-columns-flag-census.test.ts` \| deleted per its own instructions — it was built to fail in both directions and fired exactly as designed: `expected [] to deeply equal [3 readers]` \| \| `moves-workflow-flag-seams.test.ts` \| deleted — it pinned the six seams this removes \| ## Verification Full core suite: 33 failed / 10 files — byte-identical to main's baseline, with zero files failing exclusively on this branch. I measured the baseline by checking out `origin/main` and running the same command, because the first comparison I made was by count alone and would have blamed the flip for 8 files that were already red. `pnpm lint` clean. `pnpm test:gate` green (10 / 132 / 482 / 71). `tsc -p packages/core/tsconfig.json` clean. Core builds. ## Left in place deliberately The `workflowColumns` settings key stays schema-tolerated and is already in `HIDDEN_EXPERIMENTAL_FEATURE_KEYS`, so an upgraded project carrying a stale value renders nothing and loads cleanly. Removing it from the schema would risk rejecting those projects for no benefit now that nothing reads it. --- ## Rebased onto current main — and `triage` reaches ZERO \| metric \| before \| after \| \|---\|---:\|---:\| \| `moves.ts` column guards \| 39 \| 15 \| \| repo column total \| 745 \| 741 \| \| `triage` column guards \| 1 \| ABSENT (0) \| `triage` is now absent from `byColumnId` entirely: no unconverted `triage` guard remains anywhere in production source. Combined with #2664 (the last one, in `TaskContextMenu`) this closes bar item 1. The census behaved exactly as designed on the rebase: the flip deletes guards, so `--strict` reported `moves.ts: allows 39, tree has 15` rather than leaving a stale allowance, and the re-record lands in this PR's diff. ## Verification on the rebased tree - Full core suite: 33 failed / 10 files — identical to main's baseline, zero files failing exclusively on this branch (measured by checking out `origin/main` and diffing the failing-file sets, not by comparing counts). - `pnpm test:gate` green (10 / 158 / 487 / 71). - `pnpm check:lifecycle-columns` exits 0. - `pnpm lint` clean, `@fusion/core` builds. ## Two review fixes carried in this PR P1 — optionless engine moves lost their bypass. `resolveWorkflowBypassGuardsImpl` did `void moveSource;` — it discarded the resolved parameter and re-read `options?.moveSource`, so `moveTask(id, target)` resolved to `"engine"` at the call site and computed `bypassGuards === false`. Latent while the flag gated validation; with the gate gone, an internal executor/merger/recovery move made without an options object would be judged as a user move. P2 — the absence signal. Emitting `workflowId` unconditionally would have stamped `builtin:coding` onto every task with no explicit selection, reporting a fallback as authoritative. Now emits the selection directly, so absent still means "not resolved here". <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - Bug Fixes - Task moves are now validated against the task’s declared workflow. - Invalid destinations are rejected with a clear error, and tasks remain in their original column. - Valid backward moves continue to work as expected. - Move behavior and lifecycle updates are now handled consistently across workflows. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 02:19:32 -07:00
gsxdsm	fe7e68bc13	fix(core): wedge notifications could never be resolved on PostgreSQL (42P18) (#2669 ) Not a U12 change — found while attributing the pre-existing live-PG failures during U12's closing verification, and it turned out to be a product bug rather than a stale test. ## The defect `resolveWedgeNotification` builds its UPDATE with: ```ts jsonb_build_object('status', 'resolved', 'transitionedAt', ${transitionedAt}) ``` `jsonb_build_object` is variadic `"any"`, so there is no signature for PostgreSQL to resolve the bind parameter against. It rejects the statement at parse time: ``` 42P18: could not determine data type of parameter $1 ``` Parse-time is the important part: this failed on every call, not on unusual data. Wedge notifications could not be resolved at all in PostgreSQL mode. Casting the parameter to `::text` fixes it. ## Evidence - `store-wedge-resolution.pg.test.ts` goes 0/7 → 7/7. That suite has been red on `main`. - Causally verified, not assumed: removing the cast reproduces `42P18` exactly. The fix is the cast, not something incidental to the edit. - Checked the rest of `packages/core` for the same shape — this is the only `jsonb_build_object` call site, so there is no second instance hiding. ## Why it survived The failure is in a live-PG suite that was already red, so it read as part of the ambient noise. I only found it because the closing verification required me to attribute each failing suite to a cause rather than count them — and "these 4 fail on main too" is an attribution of whose, not of what. Worth flagging for whoever owns the remaining three (`agent-logs-and-monitor`, `central-archive-secrets`, `workflow-settings-project-identity`): the same reasoning applies. A suite failing on main is not evidence that the code is fine. ## Verification `pnpm test:gate` green (10 / 158 / 487 / 71). `pnpm check:lifecycle-columns` exits 0. `tsc -p packages/core/tsconfig.json` clean. `pnpm lint` clean. Independent of #2655; either order merges. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 02:05:27 -07:00
gsxdsm	8d84cee11e	fix(core): the workflow-settings identity resolver contradicted its own docs (2 long-red tests) (#2671 ) Second of the four long-red live-PG suites, after #2669. This one is stale documentation making a stale test look like a code bug — behaviour is unchanged. ## What was wrong `getWorkflowSettingsProjectIdImpl` documented a three-step resolution order: ``` (a) store.asyncLayer?.projectId — central-registry id (PG) (b) store.db.getProjectIdentity()?.id — legacy SQLite identity (c) store.rootDir — last-resort key ``` The code does (a), then returns `rootDir`. Step (b) was removed by `FNXC:SqliteDualPathCleanup 2026-07-26-14:15` — but the doc block kept describing it, and a comment three lines above the return still said "Only the true legacy (non-backend) path consults the SQLite identity", which has been false for every caller since. ## Which side was wrong — settled by construction, not judgement In my triage on #2669 I said I would not guess between "the test is stale" and "the code lost a needed branch", because the two have opposite consequences and the stale comments made the intent unreadable from outside. That was the right call then; it is now answerable: `dbImpl` throws unconditionally and ignores its store argument (`task-id-integrity.ts:58`): ```ts export function dbImpl(_store: TaskStore): Database { throw new Error("TaskStore.db: SQLite Database is not available in backend mode …"); } ``` There is no mode in which `store.db` yields a usable SQLite handle. Step (b) is unreachable by construction, not merely unused — so the code is right and the documentation was wrong. ## Why the tests passed review originally They build a store double whose `getProjectIdentity()` returns a value: ```ts db: { getProjectIdentity() { return { id: "legacy_identity_id" }; } } ``` Production cannot produce that shape. The double made an unreachable branch look testable, which is how the assertion survived the cleanup that deleted the branch. Rewritten to the shipped contract. A neighbouring case that already asserted `rootDir` when the stub throws was passing all along — the two forms of the same store disagreed inside one file. ## Verification Suite 7/9 → 9/9. `pnpm test:gate` green (10 / 158 / 487 / 71). `pnpm check:lifecycle-columns` exits 0. `tsc -p packages/core/tsconfig.json` clean. `pnpm lint` clean. No changeset: no behaviour change, and no user-visible effect. ## Remaining from the four - ✅ `store-wedge-resolution` — real product bug, fixed in #2669 - ✅ `workflow-settings-project-identity` — this PR - ⬜ `agent-logs-and-monitor` — `expected +0 to be 2` on an aggregation - ⬜ `central-archive-secrets` — an assertion on `warn` arguments Two of four were real problems hiding behind "pre-existing". The other two are still unruled-out. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 01:32:43 -07:00
gsxdsm	76e92f33c4	fix(core): review badges were silent on renamed boards — the same P1 as #2470 , one role over (#2586 ) Independent of my other open PRs. ## The defect PR #2470's review caught `getStalePausedTodoSignal` gaining a `holdColumn` parameter in B1 while both hydration sites in `reads.ts` omitted it — a correct guard comparing against the literal, so the badge was silent for a paused card in a renamed hold column. That P1 was fixed for `holdColumn` and not for its sibling. `getStalePausedReviewSignal` and `getInReviewStalledSignal` both take `reviewColumn`, and all six call sites in the same file left it defaulted to `"in-review"`. So on a renamed board (`checking`) both review badges were silent — the identical defect, in the identical file, one role over, after the pattern had already been found, written down, and fixed next door. ## The transferable part: this class is invisible to the census My column-literal census (#2557) cannot see this. The literal lives in a parameter default, and the offending call site contains no literal at all — it's defined by what it omits. The audit that finds it is different in kind: "for every role-parameterised signal, does each caller pass the role?" — run across the callers, not the definitions. Result on `reads.ts`: ``` PASSES holdColumn x2 <- fixed by #2470 OMITS reviewColumn x6 <- never fixed ``` ## Why threading differs per path Not one helper call, because the three list paths differ: - `listTasksImpl` / `searchTasksImpl` map asynchronously → resolve inline through a per-pass IR cache - `listTasksModifiedSinceImpl` maps synchronously → pre-resolve into a Map beside the existing `holdColumnByTaskId`, which exists for exactly the same reason One IR per workflow per pass in all three. ## Evidence Proven against a real store through the real hydration paths (`listTasks` and `listTasksModifiedSince`), mirroring the sibling renamed-hold suite because the defect lives in hydration rather than in the pure signal. Mutation-verified: reverting the threading fails the two renamed cases and leaves the negative and the builtin regression floor green. The fixture asserts itself — an unpaused or unaged card produces no signal for reasons unrelated to the column, which would let the suite pass while testing nothing. ## Verification - new suite 4/4 - full core PG: 1048 passed / 3 failed — the same three that reproduce with this change stashed - core `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-30 00:48:08 -07:00
gsxdsm	174eb22534	cleanup: delete the dead sync capacity-pool helper rather than document it (#2656 ) Follow-up to the #2653 audit, and the one item there that is better deleted than described. ## Why delete rather than annotate `resolveEffectiveWorkflowIdSync` has no callers. Verified across every `.ts`/`.tsx` in `packages` (excluding `dist`): only its own impl, the `store.ts` import and public method, and one comment naming it. Not exported from the core index, not referenced by any test. It is also wrong. It reads `getTaskWorkflowSelection` — the sync selection reader that has returned `undefined` unconditionally since the PG cutover — so it always resolved `resolveCapacityPoolId(undefined)`: the default pool for every task, regardless of workflow. The binding capacity path reads the selection asynchronously inside its transaction and does not use this. That combination is the argument. A dead function is clutter; a dead function that returns a plausible wrong answer is a trap. The next person to need "which capacity pool is this task in?" would find a public method with exactly the right name, call it, and get default-pool behavior with no signal that anything degraded. #2653 documents it, but documentation loses to autocomplete. ## Provenance of the claim greptile's P2 on #2653 corrected my first draft, which called this a live capacity collapse — it isn't, precisely because nothing calls it. I verified the no-callers claim myself before accepting, and this PR is the logical end of that correction: if it is unreachable, it should not exist. ## Removed - the impl in `task-store-helpers.ts` - the `resolveEffectiveWorkflowIdSync` public method on `TaskStore` - the import specifier in `store.ts` - the now-unused `resolveCapacityPoolId` import (its only use was the deleted function) - updated the `workflow-definitions.ts` comment that named it ## Verification core / engine / dashboard typechecks clean · eslint clean on both touched files · `pnpm --filter @fusion/core build` exit 0 · `pnpm test:gate` green (487 + 71). The engine and dashboard typechecks are the ones that matter here: removing a public method from `TaskStore` would surface immediately in any consumer that called it, and neither reports anything. ## Census Unchanged (776 / triage 5) — no guards added or converted. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 00:37:46 -07:00
gsxdsm	f8c053c3fa	fix(core): TAKING comments-ops.ts — re-triage on renamed planner lanes (3 triage guards → 0) (#2612 ) Claiming `packages/core/src/task-store/comments-ops.ts` from the shared backlog so nobody collides. ## Guard count \| scope \| before \| after \| \|---\|---\|---\| \| `comments-ops.ts` \| 3 \| 0 \| \| repo-wide `column === / !== "triage"` in `packages//src` (excl. tests) \| 26* \| 23 \| ## Why this file, and why it matters more than its size `addComment`'s post-comment re-triage decides, from the card's column, whether a user comment should invalidate an approved spec or send already-planned work back for re-specification. It asked with three legacy literals: ```ts task.column === "todo" \|\| task.column === "triage" task.column === "triage" && status === "awaiting-approval" hasRealPrompt && (todo \|\| (triage && status !== "awaiting-approval")) ``` On a renamed board none match, so a user comment on planned work does nothing: no approval invalidation, no re-specification, no error. The operator types a correction and the agent never sees it. This is the surface a human actually touches, which makes it the worst place in the program for a silent guard. Now resolved per task via `resolveLifecycleColumns`, fail-soft to the legacy pair — this phase is documented best-effort ("failures are logged but never fail the comment add"), so an unresolvable workflow must behave exactly as before rather than skip re-triage. ## Red-green, not green-only The suite was written first and failed 3 of 6 against the literals — precisely the three renamed cases — while the two negatives and the default-vocabulary floor passed throughout. Both negatives earn their place: re-triaging a WIP card would discard an in-flight session, and the author gate (agent comments must not re-triage) has to survive the conversion. ## Fixture guards its own preconditions `PROMPT.md` is written where the guard reads it rather than relying on task creation's side effects. `hasRealPrompt` gates two of the three branches, so a bootstrap stub would make those cases pass for the wrong reason — the trap that has produced two vacuous tests in this program already. ## Verification - new suite 6/6; `store-comments` 14/14 - full core PG: 1050 passed / 3 failed — the same three that reproduce with this change stashed (`central-archive-secrets`, `workflow-settings-project-identity`) - core `tsc --noEmit` clean; `pnpm test:gate` green (482 + 132 + 10) 🤖 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 comment-driven re-triage for workflows with renamed planning columns. - Comments on planned or awaiting-approval tasks now correctly move eligible tasks to “Needs re-plan.” - Prevented re-triage for tasks actively in progress. - Preserved existing re-triage behavior for standard workflow columns. - Non-user comments no longer incorrectly trigger re-triage. <!-- 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:27:43 -07:00
Phil Larson	15b21dead1	fix(dashboard): reconcile task state through live API (#2595 ) ## Summary - add a project-scoped live API route for updating individual task checklist steps - add an atomic live API route for resolving stale durable wedge episodes - prevent operator repair tooling from opening a second embedded store that can diverge from the running dashboard backend ## Why Legacy graph-native workflow runs can retain successful `workflowStepResults` while their narrative checklist remains at 0/N. The existing `fn task update` fallback may open a separate embedded store, producing split-brain writes that do not accumulate in the live dashboard backend. There was also no API surface for the existing atomic wedge-episode resolver. ## Verification - `pnpm exec vitest run src/routes/__tests__/register-task-workflow-routes.step-update.test.ts` — 5/5 passing - `pnpm build` in `packages/dashboard` — passing - full managed runtime workspace build — passing - deployed to the managed local runtime and used to reconcile six legacy review-deadlock tasks - live board audit: zero `in-review-stall-deadlock` paused reasons - exact local and Tailscale dashboard roots: HTTP 200 with 16,926-byte bodies <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * New Features * Added live API endpoints to update individual task checklist steps with validation (step index and allowed status values). * Added an endpoint to reconcile/resolve stale task “wedge” episodes, resolving only the matching active episode and returning conflicts on mismatches. * Tests * Expanded route tests for step updates and wedge resolution, including consistent 404 behavior for soft-deleted and missing tasks, plus conflict and invalid-input cases. * Expanded PostgreSQL coverage for wedge resolution persistence and concurrent episode replacement scenarios. * Bug Fixes * Improved task-lookup error handling so soft-deleted tasks are consistently treated as “not found” (HTTP 404). <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-29 23:27:32 -07:00
gsxdsm	76b513e028	comments-ops.ts: user comments stopped invalidating spec approval (guards 3 → 0) (#2606 ) Taking `packages/core/src/task-store/comments-ops.ts` from the shared 48-guard backlog. \| file \| before \| after \| \|---\|---:\|---:\| \| `packages/core/src/task-store/comments-ops.ts` \| 3 \| 0 \| ## One of the three was a live defect The awaiting-approval branch read: ```ts task.column === "triage" && task.status === "awaiting-approval" ``` #2515 merged the two pre-implementation columns into one with id `todo`, so a card awaiting spec approval now sits in `todo` and that condition can never match. A user comment on such a card silently stopped invalidating the approval — the operator types a correction, the spec stays approved, and the task proceeds on the very spec they were correcting. No error, no log line, nothing to notice. This is exactly the failure mode the census exists to eliminate, and it is user-visible: the operator’s correction is accepted into the comment thread and then ignored by the pipeline. The other two guards survived by luck — their `column === "todo"` arm still matched the merged column, so only the dead `triage` arm was inert. ## Fix All three resolve the intake/hold roles from the task’s own workflow. Unresolvable workflows fall back to the legacy pair: this is a best-effort re-triage path whose failure mode is a missed re-spec, so degrading to the old vocabulary beats dropping the card out of the branch entirely. ## Verification Regression test drives the real store on the merged column and asserts the approval is invalidated. Revert-proof, measured: restoring the `triage` literal fails with `expected awaiting-approval not to be awaiting-approval`. `comments-ops.ts` restored byte-identical. `pnpm lint` clean · core `tsc` clean · `pnpm test:gate` green (482 + 132) · `store-comments` 15/15. 🤖 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:15 -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	6a33d8f8cc	Phase B — TAKING task-creation.ts: intake classification by trait (4 sites → 0) (#2613 ) Taking: `packages/core/src/task-store/task-creation.ts` \| file \| guards before \| after \| \|---\|---:\|---:\| \| `packages/core/src/task-store/task-creation.ts` \| 4 \| 0 \| (4 remaining pattern matches in that file are inside the new explanatory comments, not code.) ## What the literals meant, and why they had stopped meaning it ``` resolvedEntryColumn !== "triage" ×2 "this workflow has a MANUAL intake" task.column === "triage" ×2 "created into the intake column" ``` The first named the default workflow's intake id to express "not the default workflow". Post-U11 the default's intake is `todo`, so the comparison became vacuously true for the default workflow and the guard stopped separating the two shapes it exists to separate. The real fact is the intake trait's `autoTriage: false`, which `resolveWorkflowIntakeFacts` now reads from the IR alongside the intake column id. The second was the last-resort clause for a card whose workflow could not be resolved. `intakeFacts.intake` covers that properly — it falls back to `DEFAULT_WORKFLOW_ID` rather than to a bare id — so an explicit `column: "triage"` create on a workflow that still declares `triage` (R11) is matched through the resolved intake instead of a coincidence of naming. `isUnplannedStartCreate` is also restated in terms of what it actually detects — "the card landed past its workflow's manual intake", which is what quick-add Start does by submitting the workflow id and the post-intake column together. That replaces `&& task.column === "todo"`, another id standing in for a relationship. ## Two expectations the conversion legitimately inverted Both read before changing, neither retargeted blindly. *1. "keeps generateSpecifiedPrompt for a direct create into todo (not bootstrap)"* `todo` is the default's intake now, so a card created there with no spec must get the bootstrap seed — triage admits a card for planning only when its `PROMPT.md` reads as a seed. Keeping the old expectation would have pinned the FN-8587 stall: a boilerplate spec that reads as "already planned" and is never planned. The old behaviour survived only by accident of resolution failing in the harness, which left the `=== "triage"` literal as the sole deciding clause. Removing that literal is what surfaced it — which is the point of the conversion. Split into two tests so the contract it was really protecting (an explicit non-intake column stays a specified create) keeps its own case. 2. `store-reservation-atomicity`'s file-scope rollback test It stubs `generateSpecifiedPrompt` to inject a bad `## File Scope`, so it needs a create that actually calls that generator. A `todo` create now gets the bootstrap seed instead, and bootstrap intake prompts deliberately skip the file-scope hard-fail because their body is freeform operator prose where a stray `## File Scope` token is not a real declaration. Moved to a non-intake column so validation still runs. Left as-is the test would have been vacuous — no throw, no rollback exercised — while still reporting green. ## Verification Core package vs the 47-failure post-merge main baseline: 47 failed — zero new. Two files reported failures in the wide run and pass in isolation (`create-task-reserved-id` 4/4, `schema-applier` 75/75) — the known contention pattern in this suite; re-run before attributing. Gate 482 + 10 + 71** green. Lint and core typecheck clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:39:57 -07:00
gsxdsm	f47fc167ee	convert(core/task-store/comments-ops.ts): triage guards 3 → 1, and the dead approval-invalidation it hid (#2608 ) Taking `packages/core/src/task-store/comments-ops.ts` (announced for collision avoidance). Two commits: a behaviour-identical extraction, then the conversion. \| File \| triage column comparisons before \| after \| \|---\|---\|---\| \| `packages/core/src/task-store/comments-ops.ts` \| 3 \| 1 \| `pnpm test:gate` green. ## The bug the literal was hiding `builtin:coding` → `BUILTIN_STEPWISE_FINAL_REVIEW_CODING_WORKFLOW_IR`, whose merged Planning column keeps the id `todo` and declares no `triage` column. So `task.column === "triage" && task.status === "awaiting-approval"` never matched a default card. The damage was graded: - with a real spec — the card fell through to the re-triage arm. Same `needs-replan` write, but audited as "requested re-specification of planned task" instead of "invalidated spec approval". - with a bootstrap-stub spec — `hasRealPrompt` was false and neither arm fired, so a user comment on a card awaiting spec approval invalidated nothing. The approval silently stood. That second case is the real regression; the wording is cosmetic. I checked both rather than assuming the first one was the whole story. ## The conversion The column was never the discriminator. Callers reach this only after establishing the card sits in a pre-implementation column, so re-testing it inside was redundant before U11 and wrong after. Status carries the distinction — the same conclusion `spec-staleness.test.ts` already reached for its sibling guard. Red-green: the 3 new cases fail with the literal reinstated (3 failed / 4 passed) and pass without it. Two assert the merged-Planning card is now invalidated; the third uses a `planning`-named column to show no column id remains in the decision at all. The 1 remaining literal is deliberate: the caller's gate `column === "todo" \|\| column === "triage"` names both vocabularies, so it still fires for default cards, and narrowing it to traits needs an IR the caller doesn't have. Commit 1 is move-only — the extracted body is the inlined expression verbatim, `triage` literals included, so the moved logic diffs empty apart from field renames. Behaviour change is entirely in commit 2. --- ## Census correction — the 48 is 41, and "reach ZERO" is wrong as stated I re-measured before picking a file, and the shared number needs three corrections. Same-scope method: `packages//src`, `.ts`, tests excluded, comments stripped. \| Measurement \| Count \| \|---\|---\| \| raw `=== "triage"` / `!== "triage"` \| 54 \| \| …comments stripped \| 48* ← matches your figure \| \| …of those, genuine column comparisons \| 41 \| \| …non-column identifiers that must NOT be converted \| 7 \| The 7 are `role === "triage"` ×3 (`agent-prompts.ts`), `agentType === "triage"` ×2 (`usage-limit-detector.ts`), `sessionPurpose === "triage"` (`skill-resolver.ts`), `surface === "triage"` (`tool-availability.ts`). The triage service keeps its name; only the column id was merged away. Converting these would break the triage lane, so the bar cannot be literal zero — it's zero column comparisons, with those 7 documented as permanent. Two I nearly misclassified and hand-checked: `col === "triage"` (`cli/commands/task.ts`, indexes `COLUMN_LABELS`) and `from === "triage"` (`executor.ts`, a `moveTask` from-column) are columns despite their names. ## Of the 41, which are actually dead Splitting by whether a `todo` companion arm sits in the same condition: - 27 have one → still fire for default cards. Real but lower priority. - 14 have none → candidates for silently-dead. But on inspection that set shrinks further: - `register-task-workflow-routes.ts` ×5 compare against a resolved `approveIntakeColumn`/`refineIntakeColumn` variable plus a legacy `"triage"` fallback, so they still fire via the variable; - `spec-staleness.ts:40` is a deliberate R11 compat retention — `spec-staleness.test.ts` already carries a "U11 proof" block concluding the guard is carried by status, not column, and that other workflows still declare `triage`. Converting it would be wrong; - `self-healing.ts` ×7 is U4's file; - `comments-ops.ts` ×1 was genuinely dead — this PR. So the actionable dead set is far smaller than 14, and `self-healing.ts` holds most of it. I'd suggest whoever takes `self-healing.ts` starts from that 7 rather than its 11 total. ## Files I evaluated and did NOT convert - `replan-target.ts` — my first pick, then both its "sites" turned out to be comment text. Zero real sites; already trait-resolved via `workflowHasColumn`. - `mission-feature-sync.ts:88` — `(column === "triage" \|\| column === "todo")` still fires via the `todo` arm. The genuine gap is a custom-named planning column, but `reconcileMissionFeatureState`'s store is narrowed to `Pick<TaskStore,"getTask">`, so trait resolution means plumbing through `scheduler.ts` — U5's file. Left to avoid the collision, per KTD-2's warning that most sites have no IR in scope. - `tool-availability.ts` / `skill-resolver.ts` / `usage-limit-detector.ts` — non-column identifiers, see above. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:07:28 -07:00
gsxdsm	ad3dc202f8	P0: a fresh project created every task into a column its workflow no longer declares (#2589 ) Highest-severity finding of the post-merge audit, and it is the out-of-the-box shape rather than an edge case. ## The defect `createTask` resolves the intake column only as a by-product of materializing the project's default workflow. A project that has never explicitly set a default workflow has no persisted default row — so that materialization returns nothing, `resolvedEntryColumn` stays `undefined`, and the row falls through to the hard-coded `\|\| "triage"`. Post-merge, that column does not exist in the default workflow. Measured, three creates on one store: \| create \| column \| \|---\|---\| \| no default row persisted \| `triage` ← broken \| \| default explicitly `builtin:coding` \| `todo` \| \| explicit `workflowId` \| `todo` \| `builtin:coding` is the implicit default via `DEFAULT_WORKFLOW_ID`, and nothing writes a default-workflow row until an operator picks one. So this was every new task on a fresh project. ## What it costs Triage discovery resolves intake by trait, so `isAtIntakeColumn` is false for a card sitting in `triage` while its workflow says `todo` — the card is never admitted for planning. It isn't in the hold column either, so hold-release ignores it. Only `reconcileUndeclaredTaskColumns` eventually re-homes it. A newly created task is invisible to planning until that sweep runs. Not a permanent stall, but the first thing an operator does on a new project is create a task. ## The fix — three parts, and missing any one leaves it half-fixed 1. `resolveDefaultWorkflowIntakeColumn` falls back to `DEFAULT_WORKFLOW_ID` when no default row is persisted — the implicit default every other resolver already assumes. 2. Both create paths consult it as a last resort before the literal, so any path that already has an explicit column or a resolved entry column is untouched. 3. `isIntakeColumn` honours the same fallback. Without this the card lands in the right column but is classified not-intake and receives `generateSpecifiedPrompt` instead of the bootstrap seed — and triage admits a card only when its `PROMPT.md` reads as a seed, so it would sit in Planning already looking "planned". FN-8587's failure mode by another route. `workflowId: null` ("No workflow") is excluded and asserted — there is no workflow whose intake could be resolved, so that path keeps the literal. ## Fixture drift, fixed with intent preserved Seven tests asserted a created card lands in `triage`. None had their assertion merely retargeted: - `move-task-if-planning`, `delete-task-if-planning` — the mechanism under test is the live predicate, not the column. Predicates and the "advanced" column now name where the card actually rests. - `task-lifecycle-e2e`, `activity-log-parity`, `mission-store` — first-column and first-transition expectations. - `workflow-reconciliation-production-shape` — the subtle one. Its filler must occupy the target workflow's capped `triage` entry column, but was created before the switch and so landed in the project default's intake. It now names its column explicitly, which makes the fixture independent of the project default — exactly the coupling that let it drift. - `store-create-intake-column` — the "lands in triage" guard now names the invariant (the default workflow's own intake column) and keeps a `not.toBe("triage")` so a regression back to the literal still fails. ## Measured Core package, against the 47-failure post-merge main baseline: 47 failed / 4413 passed — zero new failures. Three engine triage tests are red and are not from this change: verified by stashing these edits and re-running against clean main, where they fail identically. They arrived with #2515 and belong to the triage-fixture owner. Gate 414 + 10 + 71 green. 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 * New tasks now consistently start in the default workflow’s `todo` intake column, including fresh projects without persisted workflow settings. * Bootstrap `PROMPT.md` content is now created consistently for all supported task-creation paths. * Task movement and deletion behavior now correctly respects current columns and avoids acting on stale task data. * Workflow reconciliation and activity tracking now reflect the updated default task lifecycle. * Tests * Expanded coverage for intake-column resolution, task lifecycle transitions, stale candidates, and workflow edge cases. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 19:03:03 -07:00
Phil Larson	9a8fc409ff	fix: persist manual task pauses (#2536 ) ## Summary - persist an explicit `userPaused` latch when operators pause tasks through CLI, MCP, dashboard task routes, or mission stop - keep automatic/internal pauses distinct (`userPaused` remains false unless explicitly requested) - clear the latch on unpause - route the flag through in-memory and PostgreSQL task stores - add contract coverage across core, CLI, MCP, dashboard task routes, and mission stop ## Why A manually paused task could lose the reason for its pause across dashboard/runtime restart. Startup recovery then treated it like an internally interrupted task and reclaimed it, restarting automation against the operator’s intent. Manual pauses must survive restart and remain non-runnable until explicitly unpaused. ## Verification - core pause durability tests: 2 passed - CLI task/extension tests: 150 passed; PostgreSQL integration lane remains active in CI - dashboard route tests: 261 passed - `@fusion/core`, `@runfusion/fusion`, and `@fusion/dashboard` typechecks passed - full workspace build passed with pnpm 10.33.0 - changeset validation and `git diff --check` passed - live aggregate runtime verification also confirmed `paused=true,userPaused=true` survived a normal dashboard restart with zero active tasks <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - Bug Fixes - Manual task pauses now persist across application restarts and recovery. - Pauses initiated via the CLI, dashboard, MCP tools, and mission stop controls are recorded as explicit user actions. - Automatically paused tasks remain eligible for recovery. - Unpausing clears the durable manual-pause state. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-29 00:04:28 -07:00
gsxdsm	063978c289	U12 part 3: make the v1-IR persistence unconditional — after this, every raw-flag read is on the move path (U2b) (#2513 ) ## U12 part 3 — every remaining raw-flag read is now on the move path Stacks on #2512 (shares a line in `workflow-ops.ts`). Merge that first. Behaviour-preserving. Not a single persisted byte changes. ### What changed The three v1-IR rollback-compat persist sites (#1405) all read `flagOn ? ir : downgradeIrToV1IfPure(ir)`, where `flagOn` came from the retired raw `experimentalFeatures.workflowColumns` key. No production writer sets it, so every real project has always taken the downgrade arm. Removing the branch is a runtime no-op; it deletes three flag reads. Sites: `createWorkflowDefinitionImpl`, `updateWorkflowDefinitionImpl`, and `insertWorkflowDefinitionSyncImpl` — whose `flagOn` parameter is gone too, along with the plumbing that resolved it in `migrateLegacyWorkflowStepsImpl`. With those gone, `TaskStore.workflowColumnsFlagOn()` has no callers and is deleted. Its six readers were the three U5 guards (part 2) and these three persist sites. ### The decision I made, and why I went the other way I had this slice scoped as "retire the v1 downgrade." I rejected that. It is a compatibility affordance, not cutover machinery: it fires only for a graph exactly equivalent to pure v1 (default columns, default placements, no v2-only features), and `upgradeV1ToV2` re-reads it into an identical v2 graph, so the runtime never sees a difference. Retiring it would break a binary downgrade for zero benefit — and stale binaries opening these databases is an observed event in this project, not a hypothetical. So the slice became the strictly better version of itself: same three flag reads removed, no compat surface touched. ### Why this matters for sequencing `isWorkflowColumnsCompatibilityFlagEnabled` survives. It is still read by `moves.ts:363` and by `workflow-task-create-ops.ts:351`'s move-policy preflight that feeds it. Removing those reads is the U2b move-path convergence with its equivalence-proof obligation. The point of deleting the wrapper is that it makes the remainder enumerable: ``` $ grep -rn isWorkflowColumnsCompatibilityFlagEnabled --include=.ts packages/ \| grep -v __tests__ packages/core/src/store.ts:38 <- the definition packages/core/src/task-store/moves.ts:9,363 <- U2b packages/core/src/task-store/workflow-task-create-ops.ts:11,351 <- U2b (feeds moves.ts) ``` Every surviving read is on the move path.* U2b deletes the definition and the unit closes. ### On coverage — stated honestly This change is behaviour-preserving, so it has no revert-proof test, and I am not going to claim one. `flagOn ? ir : downgrade(ir)` with an always-false flag is `downgrade(ir)`. What needed a guard is the next edit someone is tempted to make — deleting `downgradeIrToV1IfPure` as dead cutover machinery. New `workflow-ir-v1-rollback-persistence.test.ts` fails if it is removed, and pins the exact boundary: the built-in coding workflow (named columns + traits) stays v2; a pure-v1-equivalent graph stores as v1 without the synthesized `columns`; a downgraded graph re-parses to an identical runtime graph (the property that makes unconditional application safe); a graph with a custom column stays v2. ### Verification `pnpm test:gate` (307 + 10 + 71), `pnpm lint`, `pnpm verify:fast` (17 steps), typecheck green. Core workflow-named suites: 383 passed, 1 failed — `workflow-ir-settings.test.ts > moved-key catalog ...` (`expected 10 to strictly equal 3`), which I confirmed fails identically on a stashed clean tree. Pre-existing, unrelated. No Fusion instance booted. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Improved workflow persistence compatibility by consistently storing pure v1-equivalent workflows in the compatible format. * Preserved v2 workflows and custom column information when they are not v1-equivalent. * Retired obsolete feature-flag checks without changing stored workflow or board behavior. * Tests * Added coverage for workflow version preservation, rollback-compatible serialization, and custom columns. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 19:09:06 -07:00
gsxdsm	3badc244a7	U12 part 2: bind the three U5 reconciliation guards — USER-VISIBLE (and one path that couldn't run under PostgreSQL at all) (#2512 ) ## U12 part 2 — the three U5 reconciliation guards now actually fire USER-VISIBLE. Taken on standing authority; here is exactly what changed for operators. All three read the RAW `experimentalFeatures.workflowColumns` key via `store.workflowColumnsFlagOn()`. Nothing in production writes it, so all three have been inert since the workflow-columns cutover. \| Guard \| Before (every real project) \| After \| \|---\|---\|---\| \| Workflow edit removing an occupied column \| Save succeeded; cards left in a column the workflow no longer declares \| Save fails with `OccupiedColumnsError` unless `rehomeTo` is supplied \| \| Workflow delete \| Occupant capture returned `[]`; cards sat in the deleted workflow's columns until the next engine start \| Cards move to the default workflow's entry column as part of the delete \| \| Workflow switch \| Never reconciled; the `reconciliation` field in the declared return type was never populated \| Card in an undeclared column moves to the resolved target; a declared column is preserved \| Both consumers already handle the new outcomes and needed no change: `register-workflow-routes.ts` maps `OccupiedColumnsError` to a structured 409 carrying per-column occupant counts, and `fn_workflow_update` returns a retryable structured result. The dashboard editor's `rehomeTo` retry flow becomes reachable for the first time. I only updated two stale "flag-ON" comments there — that code was correct all along and simply never fired. ### What an operator actually sees (USER-VISIBLE — read this bit) Four changes to what the board and the API do. Nothing here is silent. 1. Editing a workflow to remove a column that has cards in it now FAILS. Previously the save succeeded and the cards were left in a column their workflow no longer declared. The dashboard shows the existing 409 with per-column occupant counts and prompts for a re-home target; retrying with `rehomeTo` moves the cards and saves. Removing an EMPTY column is unaffected. 2. Deleting a workflow moves its cards immediately to the default workflow's entry column, instead of leaving them until the next engine start. 3. Switching a task's workflow moves the card when the new workflow does not declare its current column. A card whose column IS declared stays exactly where it is. The API response now carries the `reconciliation` summary it always promised. 4. A switch whose re-home would be REJECTED is now refused before anything is written. If the destination column is at its WIP limit, the switch fails with a structured 409 (`workflow-switch-rehome-failed`) naming the task, both columns and the reason — and nothing changes: the task keeps its current workflow AND its current column. Retry after making room. Previously this combination committed the selection and then silently reported a move that never happened, leaving selection and column disagreeing. Can a torn card still happen? Yes, in one narrow case, and here is how you recover. If the destination fills in the window between the pre-flight and the move, the selection is already committed and the card ends up in a column its new workflow does not declare. That case is not silent: it writes a `task:workflow-switch-torn` run-audit row, and the error carries `selectionCommitted: true` with both columns. Recovery: make room in the destination and move the card there, or switch the task back — and if neither happens, the R7 startup sweep `reconcileUndeclaredTaskColumns` re-homes it on the next engine start. The card is never lost; it is visible in a lane the board may not draw until one of those runs. The one thing to watch after merge: (1) converts a previously-silent success into a visible failure, so an operator mid-edit on a busy workflow will start seeing a 409 they never saw before. That is the point — the alternative was stranding their cards — but it is the change most likely to generate a "this used to work" report. ### The thing that made this more than a gate removal Un-gating the switch guard surfaced that `selectTaskWorkflowAndReconcileImpl` read the task through `store.readTaskFromDb` — the synchronous SQLite reader, which throws under PostgreSQL: ``` TaskStore.db: SQLite Database is not available in backend mode ``` The flag returned before that line, so the gate was hiding a path that could not execute at all in the production backend, not merely a disabled feature. Ported to the async `readTaskRow`. Found by the new tests, not by reading the code. ### Review round 2 (both findings real, both fixed) Torn write with no alarm — fixed by ORDERING, not by a louder message. My first attempt only made the error loud, which left the torn state intact. The real fix is that the deterministic rejection cause (destination at its WIP limit) is now checked BEFORE `selectTaskWorkflow` commits, by resolving the target IR straight from `workflowId` instead of through the task's selection. Nothing commits on that path. For the residual race the failure is loud AND recorded: `rehomeOccupant` now returns `{ moved, error? }` (additive; sweep callers ignore it), the switch writes a `task:workflow-switch-torn` run-audit row, and throws `WorkflowSwitchRehomeFailedError` with `committed: true`. Consumers translate it: the dashboard route returns a structured 409 with `selectionCommitted`, and `fn_task_set_workflow` returns the same fields — no more generic "something went wrong". Fabricated column for a deleted task. My first fix fell back to `fromColumn` when the final read found no row, so a task soft-deleted mid-switch was reported as having its old column preserved. Absent now reads as absent (the optional `reconciliation` is omitted). Extracted as the pure `buildSwitchReconciliation` seam because the window is not reachable through the public call — `selectTaskWorkflow` rejects an already-deleted task up front — so it is a genuine race, and I test the decision directly rather than asserting it from reading the code. ### Revert-proof, measured New `workflow-reconciliation-production-shape.pg.test.ts` — 6 cases, with the flag never written, which is the configuration every real project has. Each flip reverted individually: - re-gate the edit guard → 2 failures (OccupiedColumnsError case; rehomeTo re-home case) - re-gate the delete capture → 1 failure (card stays in `custom-hold`) - restore the switch early return → 2 failures (`reconciliation` undefined; card does not move) - all three in place → 6/6 green Round-2 fixes, also measured: - restore the `fromColumn` fallback → the "row is gone" case fails (reports `preserved: true` for a deleted task) - drop the `!outcome.moved` throw → the capacity-blocked case fails (resolves instead of raising) - move the capacity pre-flight back AFTER the commit → the case fails on the SELECTION assertion (expected `WF-002`, received `WF-001`), i.e. it proves the ordering, not the wording The pre-existing coverage in `workflow-authoritative-reads.pg.test.ts` reached the occupied-column guard by writing the flag ON itself — same pattern as the ListView/Board suites in part 1. Its flag write is removed; it now runs in the production shape. ### Where I nearly got this wrong My first revert harness was buggy and I briefly concluded the delete re-home was redundant — I had probed the stored column and seen `triage` with what I thought was the flip reverted. It wasn't. `workflow-ops.ts` contains two identical `const occupantTaskIds = await store.listWorkflowOccupantTaskIds(id, false)` lines (field-reconcile block, delete path), so my first-match edit reverted the wrong one. Re-run anchored on surrounding context, the delete case fails as predicted. Recorded in the test header as a caution. I also chased and refuted a scarier hypothesis along the way — that an unrelated `updateTask` coerces a custom column back to `triage`. It does not; the column survives. ### Deliberately NOT in this PR The v1-IR rollback-compat persistence (`downgradeIrToV1IfPure`) on the workflow UPDATE path. It shared the same `flagOn` variable, which is how it surfaced: one flag read was feeding two unrelated decisions, so the flag has more decision sites than call sites — my earlier 9-site inventory undercounted. It chooses the stored shape of the graph rather than gating a guard, so it is a persistence-format change with a different blast radius. It now reads the flag explicitly, behaviour unchanged, for a follow-up. The `moves.ts` group remains U2b's. ### Verification `pnpm test:gate` (307 + 10 + 71), `pnpm lint`, `pnpm verify:fast` (17 steps), both typechecks green. Full `packages/core` PostgreSQL suite: 1042 passed, 3 failed — `central-archive-secrets.test.ts` (log-prefix assertion) and `workflow-settings-project-identity.pg.test.ts` (×2, project-id resolution). I confirmed the identical 3 failures on a stashed clean tree: pre-existing, unrelated. No Fusion instance booted. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Workflow edits now prevent removal of occupied columns unless cards are moved to a specified destination. * Cards are automatically re-homed when workflows are deleted or switched. * Workflow switches now check destination capacity before committing and provide clear conflict details when re-homing fails. * Reconciliation results now indicate whether cards were moved or preserved. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 18:52:46 -07:00
gsxdsm	35b0df1838	U11 PR2: entry contract under the merged column + a real intake-column bug the audit surfaced (#2503 ) Second small PR for U11. Two commits: a tests-only entry-contract pin, then a real present-day bug fix the audit surfaced. ## The audit you asked for, finished — no design fork You named four surfaces as the remaining risk. All four can take a combined `intake` + `hold` column. One needed a code change; here it is. \| Surface \| Verdict \| Evidence \| \|---\|---\|---\| \| `isUnplannedForExecution` \| Safe \| PR1 (#2495) — passed unmodified; a mutation now fails exactly the merged-column test \| \| Capacity hold / release \| Safe \| PR1 — `hold-release.ts:260` already accepts intake or hold \| \| `start`'s column / entry contract \| Safe \| commit 1 — all 6 assertions passed unmodified \| \| `createTask` intake wiring \| Broken today \| commit 2 — fixed, revert-proven \| \| (also found) triage auto-discovery \| Needs conversion \| `triage.ts:1382` — deferred to PR3, see below \| ## Commit 1 — entry contract under the merged column (tests only) All 6 new assertions passed on the first run. Regression floor, not evidence of a fix — I could not make them fail and am not claiming otherwise. They pin one real behavioral difference rather than asserting sameness everywhere: the merged shape answers `start` where the split shape answers `plan`, because `start` becomes the first node in that column once the columns collapse. That is equivalent only because `start` reaches the specification node by a single unconditional success edge — asserted, so if a node is ever inserted between them this fails instead of silently admitting an unspecified card into implementation. Also pinned: past planning both shapes agree exactly; a card past the merged column still never resumes at a planning node (the backward drag that fires `abort-on-exit`); and a row persisted in the deleted `triage` column resolves to `undefined`, safe only while the executor's start-node fallback exists. ## Commit 2 — a real bug, found by the audit The intake column was resolved only as a by-product of materializing workflow steps. A create supplying `enabledWorkflowSteps` without an explicit `workflowId` takes neither materialization branch, so `resolvedEntryColumn` stays `undefined` and `column:` falls through to the hard-coded `\|\| "triage"`. Today, on Coding (Ideas), that lands the card in `triage` — a column that workflow does not declare. Created straight into a phantom lane. Measured: the new test fails `expected 'triage' to be 'ideas'` against unmodified sources. Why it blocks U11. Once `triage` leaves the coding IRs this stops being an Ideas edge case and becomes the default workflow's behavior for every create down this path: the card lands in an undeclared column and — because `isIntakeColumn` keys on the same `"triage"` literal — gets `generateSpecifiedPrompt` instead of the bootstrap seed. Triage admits a card for planning only when its `PROMPT.md` reads as a seed, so a placeholder spec is classified "already planned" and never planned. The card sits in Planning forever with no log line in any lane — FN-8587's exact failure mode, promoted from one edge case to every new card. The fix resolves the intake column side-effect-free (read the IR, ask which column carries `intake`). It deliberately does not call `materializeDefaultWorkflowSteps`, which would persist step rows the caller explicitly opted out of by supplying its own toggles. Unresolvable workflow returns `undefined` and each call site keeps its legacy fallback, so no path loses behavior when the IR cannot be read. Applied to both create paths. Branch ordering preserved in both — the explicit empty-toggle case (`length === 0` hydrating back as `[]`) still runs, now nested rather than sequential. Revert check: with `task-creation.ts` reverted, "lands a Coding (Ideas) task in ideas even when enabledWorkflowSteps is supplied" fails `expected 'triage' to be 'ideas'`. The companion bootstrap-`PROMPT.md` assertion passes either way today — it is correct by accident of the `"triage"` literal — and is kept precisely because that accident disappears with U11. ## Verification 37 tests green across the three intake/create suites; 119 across the entry-contract, merged-column and lifecycle suites; `pnpm test:gate` green (307 + 10 + 71); lint and core typecheck clean. Changeset added. ## Deferred to PR3, with the line numbers `discoverReadyPlanningTasks` has two hardcoded branches: ```ts (t) => t.column === "triage" && isTaskStillInPlanningStage(t) // triage.ts:1382 (t) => t.column === "todo" && !this.processing.has(t.id) … // triage.ts:1389 ``` Delete `triage` and branch 1 matches nothing for coding cards; branch 2 then does all the work and is narrower (it admits only `needs-replan` or bootstrap-stub cards). Commit 2 is what makes branch 2 sufficient — every new card now gets a real bootstrap seed. They cannot double-fire: a card is in `todo` xor `triage`. Two adjacent sites are already merged-shape-ready: `triage.ts:3899` skips the redundant same-column move for a plan-in-place card, and `triage.ts:753`'s stale-status sweep already scans both columns. Then the ~10-line IR change, then the migration proof. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 17:35:14 -07:00
gsxdsm	46f35323cf	fix(core): make the capacity gate actually bind for real projects (R2) — USER-VISIBLE (#2499 ) Follow-up to #2488 (merged). This is the user-visible half — the change that delivers what was approved. #2488 alone is latent. ## One line `workflow-capacity.ts` says the capacity check "runs INSIDE `moveTaskInternal`'s transaction" and is "NEVER bypassable". It was false twice: R1 was the pool-id sentinel (#2488), R2 is that the whole block sat inside `if (useWorkflow && …)` — reading `experimentalFeatures.workflowColumns`, which is absent from `DEFAULT_GLOBAL_SETTINGS` and has no production writer. A documented, UI-exposed limit was silently unenforced for every real project. Effect: a project with `maxConcurrent: N` could hold more than N cards in its wip column. Now the move is refused with `capacity-exhausted`. ## Scope is deliberately narrow Only the capacity check is un-gated. `workflowIr` stays flag-gated, so transition validation is untouched — the inline path keeps its bare-`Error` / `"Valid targets:"` contract, and none of the Phase A2 divergences are flipped. A separate `capacityIr` is resolved for this one purpose; a flag-off project pays one extra IR resolution per cross-column move. ## The release path already expected this `hold-release`'s own docstring: > the in-txn capacity check is NOT a guard — it still runs (KTD-10), so two holds racing into one slot serialize: exactly one commits, the other rejects with `capacity-exhausted` and retries next sweep and it reserves worktree + semaphore slots before issuing a move specifically so it can release them on that rejection. That handler was dead code. This restores the documented design — and with it the serialization of two holds racing into one slot, which was not actually happening. ## Measured blast radius — not estimated \| suite \| with R2 \| baseline \| new failures \| \|---\|---\|---\|---\| \| core PG (real store) \| 1037 passed / 3 failed \| 1037 passed / 3 failed \| 0 \| \| engine-default \| 279 failed / 9167 \| 279 failed \| 0 (failing-file-set diff) \| The three core-PG failures are the same pre-existing ones that reproduce with everything stashed. Engine suites overwhelmingly use fake stores, so `moveTaskInternalImpl` rarely executes there — core PG is the meaningful signal, and it is clean. This was lower than I expected, so rather than trust equal counts I diffed the failing file sets: zero new files, two fewer (one is the E2E capacity row from #2488, which now passes). ## Acceptance Flipped exactly as Phase A3 specified: `DEFECT (R2, STILL LIVE)` → `FIXED (R2)`, and move-path-equivalence's capacity `DIVERGENCE` → `CONVERGED`. Both fail with this change reverted (verified: 2 failed / 12 passed). ## Why I proceeded without a decision I had escalated R2 and had no answer. Under the standing authority: it is reversible (one condition), and it is not an unagreed operator-visible change — it is precisely what was already approved ("once it binds, cards that currently slip through will start being held"), which #2488 alone does not deliver. My recommendation was option B and I acted on it. Revert is one PR. Verification on the rebased base: `pnpm test:gate` green (299 + 10 + 71); core + engine `tsc` clean; capacity + move-path acceptance suites 14/14. 🤖 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 - Column WIP limits are now enforced when moving tasks into full columns. - Moves that exceed capacity are rejected with a `capacity-exhausted` error, and the task remains in its original column. - Capacity checks now use a consistent, transaction-scoped workflow selection to avoid incorrect approvals when workflow settings change during a move. - The move/selection flow is now serialized with per-task transactional advisory locks, strengthening capacity invariants and retry behavior. - Existing transition validation behavior remains unchanged. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 16:28:00 -07:00
gsxdsm	fd6d005333	U12 part 1: delete the legacy board path (262 ListView + 39 Board tests were measuring it; 9-site flag inventory, moves.ts group blocked on U2b) (#2500 ) ## U12, part 1 of 2 — and one blocker you need to route The unit's headline deletion (`isWorkflowColumnsCompatibilityFlagEnabled`) is blocked by U2b and is not in this PR. What is here is everything that could be deleted without making a convergence decision that belongs to another unit. ### The blocker PR #2468 landed as `b941d3cba` — but that was Phase A2 steps 1–2 only: the differential characterization. The convergence (pick a path, delete the other, delete the flag) has not landed; `feature/workflow-move-path-convergence` is still live. Deleting the raw flag is that convergence. `move-path-equivalence.pg.test.ts` says so in its own header, and its second `describe` is literally "the flag gates MORE than side effects". The plan makes this a blocking unit with an equivalence proof obligation and an explicit "stop and escalate rather than reconcile silently" note. So I stopped. ### Inventory: every read of the raw flag, with a verdict Nine sites. All false in production because nothing writes `experimentalFeatures.workflowColumns`. Blocked on U2b — one branch, not separable: \| Site \| Silently disabled today \| Visible if flipped \| \|---\|---\|---\| \| `moves.ts:312` `useWorkflow` \| typed `TransitionRejectionError`, workflow adjacency, the shared transition invariants (merge-blocker trait generalization), plugin column gates, the `transitionPending` marker, `workflowId` in `task:move` run-audit, and the trait-hook side-effect path \| Yes — rejections change type and message \| \| `moves.ts:931` \| the in-transaction capacity gate. `resolveColumnCapacity` never runs \| Yes — WIP limits begin binding \| \| `workflow-task-create-ops.ts:351` \| `prepareWorkflowMovePolicyPreflight` returns `undefined` unconditionally → workflow/plugin move policies have never been evaluated \| Yes — new rejections \| On #2488: the pool-id sentinel fix is correct and still inert. Two dead layers stacked — the gate it fixed is inside `if (useWorkflow && …)`. Not blocked, but each moves operators' cards — deferred to PR 2 per your call: \| Site \| Silently disabled today \| \|---\|---\| \| `workflow-ops.ts:183` \| `OccupiedColumnsError` + `rehomeTo` when a workflow edit removes an occupied column. Today the save succeeds and strands the cards \| \| `workflow-ops.ts:344` \| occupant re-home on workflow delete \| \| `workflow-definitions.ts:700` \| workflow-switch reconciliation, and the `reconciliation` field in the API response \| I verified these three are not coupled to `moves.ts`: `rehomeOccupant` reaches a custom target via the `isWorkflowDeclaredRecoveryRehome` carve-out (`moves.ts:641`), which exists because the repair "silently no-oped on every store open" before it. Not blocked, no behaviour change for current binaries (also PR 2): `project-store-ops.ts:687` + `lifecycle-ops.ts:1119` — `downgradeIrToV1IfPure` on persist, for binary-downgrade rollback. Needs a round-trip test, not an assumption. ### What this PR deletes Dashboard. `workflowColumnsEnabled` was a literal `true` at all three `MainContent` call sites; the server hardcodes `flagEnabled: true`. Gone: Board's legacy single-lane board (55 lines mapping the hardcoded `COLUMNS` enum — the last board surface deriving columns from the legacy vocabulary, an R8 violation that survived U10); `tasksByColumn` and its cache ref, orphaned with it; ListView's `LEGACY_LIST_COLUMNS` (the ListView copy of the synthesized-trait-flags defect U10 fixed in Board); both props; the `shouldHydrateCache` gate; TaskDetailModal's `flagEnabled` early return. Neither Board nor ListView imports the legacy column enum any more. Core. `evacuateCustomColumnsToLegacy` (#1409) — both triggers require the previous settings to have the flag ON, which no writer produces. `runWorkflowColumnsIntegrityPass` — no caller anywhere, superseded by `reconcileUndeclaredTaskColumns` (registered in startup recovery), and it read through the sync SQLite handle, so invoking it under PostgreSQL would have thrown rather than reconciled. Migration answer: a project with `workflowColumns: false` persisted needs no migration and no read-time drop. Nothing in this PR reads the key, and it stays in `HIDDEN_EXPERIMENTAL_FEATURE_KEYS` so Settings still suppresses it rather than resurrecting it as an unknown setting. Proven by tests, no instance booted. `flagEnabled` stays on the wire as a constant. Removing it changes the response shape, and a browser tab outliving a server upgrade would read the missing field as "off" and degrade. One boolean, no client branches on it, droppable a release later. ### Measured - Production sources: -332 / +131 (net -201). Additions are almost entirely FNXC comments recording why each branch was unreachable. - Dashboard production only: -168 / +93. - Core: -164 / +38. ### The finding I'd actually flag `Board.test.tsx` and `ListView.test.tsx` both left `workflowColumnsEnabled` unset and stubbed `fetchBoardWorkflows` with a never-resolving promise. Under the old gate that rendered the legacy board — so 262 ListView tests and 39 Board tests were asserting against a configuration production never reached, and a real regression in the workflow board or list would not have failed either file. Same shape as the other four: looked enforced, wasn't. Both now seed the first-paint lane cache with the default workflow's real columns (ids and names copied from `BUILTIN_CODING_WORKFLOW_IR`) — the same seam production uses. Repointing them surfaced assertions that encoded legacy-only values: `"In Progress"`/`"In Review"` (real IR names are `"In progress"`/`"In review"`), and Planning Mode asserted to receive `null` as the workflow id, which is only what `getTaskPlanningWorkflowId` returns when `workflowMode` is false. `"Back to In Progress"` is not one of those — it is a hardcoded i18n string in `TaskContextMenu:210`, not derived from the column name. Left alone, and flagged: it will not follow a renamed column. That's U11 vocabulary territory. One test is SKIPPED, not weakened — "keeps unaffected columns stable when archived collapse toggles". Pointed at the real board the invariant is false: toggling the archived column re-renders unaffected columns (measured: todo renders 3×, not 2×). Pre-existing production behaviour this deletion exposed, never covered because the test measured the dead path. I ruled out the obvious causes (every callback prop is `useCallback`; the per-column task memo's deps exclude `archivedCollapsed`; memoizing the inline `canDropTask` binding did not close it — I wrote that fix, could not prove it with a failing test, and reverted it). The reason is recorded at the test: un-skip with a fix, never with a new expected number. ### Verification `pnpm test:gate` (299 + 10 + 71), `pnpm lint`, `pnpm verify:fast` (17 steps), and both package typechecks green. `settings-defaults.test.ts > warns once per process for legacy cwd-main mode` fails — pre-existing, confirmed by stashing my changes and re-running. No Fusion instance was booted. ### Routing request Per your call: the `moves.ts` group and the final removal of `isWorkflowColumnsCompatibilityFlagEnabled` go to U2b, inside the convergence PR where the equivalence proof already lives. The divergences their characterization suite does not yet cover: plugin column gates, the `transitionPending` marker, `workflowId` in `task:move` run-audit, and move-policy preflight. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 15:45:40 -07:00
gsxdsm	fbe7eb5c5a	U7 PR1: the manual plan-approval gate was bypassable (3 planning-lane surfaces, 8/13 revert-proof) (#2491 ) ## What this is The first slice of U7 — the graph owns planning. Characterizing the planning lane's dual ownership turned up a live defect in the exact seam the unit exists to remove, so this PR fixes that first and reports the measured map of what U7 still has to move. ## The defect The manual plan-approval gate parks a card by writing `status: "awaiting-approval"` and returning early from `finalizeApprovedTask` — before the release move. `specifyTask` then calls `onSpecifyComplete` unconditionally afterwards. Three automated surfaces went on to advance the parked card, each having re-derived its own weaker "may I advance this?" check from `paused`/`userPaused` alone. `isTaskBlockedOnApproval` (`packages/core/src/task-merge.ts`) already declares itself "the single shared predicate core and engine code must consult before rebounding, requeuing, resuming, re-planning, or otherwise advancing a task". Measured: it had exactly one production consumer (`overseer-human-control-policy.ts`). Now four. Reachable end to end for a plan-in-place card — one whose column already equals the plan-review node's column (Coding (Ideas), or any `needs-replan` revision resting in the default workflow's `todo`): ``` park at awaiting-approval → onSpecifyComplete fires anyway → a runnable plan-review continuation is seeded → the drain dispatches it → Plan Review runs on a plan the operator never approved → its evidence satisfies isUnplannedForExecution → the capacity sweep releases the card into In progress ``` Blast radius: projects that have manual plan approval switched on. `planApprovalMode` defaults to auto-approve (FN-7557), so unset projects have no gate to skip — but the operator who turns it on is precisely the one who cares. ## Surface enumeration Per AGENTS.md — fix the invariant, not the repro. \| # \| Surface \| Fix \| \|---\|---\|---\| \| 1 \| `issueRelease` — the choke point for the sweep, `promoteHeldTask`, `releaseHeldTaskByEvent`, and the scheduler's `reserveSlot` guard \| Guarded there rather than inside `isUnplannedForExecution`, because an approval-held card is not "unplanned". Guarded again inside the `moveTaskIf` predicate so a park landing mid-sweep cannot lose the race (R6 — only the in-txn check is authoritative). Operator force-promote (`allowUnplanned`) still waives it: that is a human decision about this card. \| \| 2 \| Both continuation seeders — `seedPreReleasePlanReviewContinuation` (normal completion) and `evaluateStrandedHoldContinuation` (FN-8592 self-healing re-seed) \| Guard at the seam, not in the callers: the seeder itself checked nothing, and its two callers each pre-checked a different subset. \| \| 3 \| `resolvePlanningContinuationCandidate` (drain classifier) \| Skip, never orphan. Cancelling terminalizes the item, so an approval landing a minute later would have nothing left to resume and would need a second repair to come back. \| ## Measured, not assumed The two hold shapes `isTaskBlockedOnApproval` accepts were not equally broken. The `paused` + `pausedReason` shape was already refused by the sweep and the drain — they happen to test `paused` — so it was refused for the wrong stated reason, not advanced. Every genuine advance gap is on the status-only shape, which is exactly what the gate writes. Both are covered anyway, plus an `ORDINARY_PAUSE` counter-case so the new check cannot quietly become a catch-all for every operator park. ## Revert proof With the three production files reverted: 8 of 13 tests fail. The 5 that still pass are the 3 controls and the 2 pause-shape rows the pre-existing `paused` checks already covered. ``` ·x··xxxxx·xx· → Tests 8 failed \| 5 passed (13) ``` ## Verification \| Check \| Result \| \|---\|---\| \| new suite \| 13/13 \| \| hold-release (×2) + plan-review (×3) + pre-release-plan-review + promote-force-unplanned \| 43/43 \| \| stranded-hold-continuation (×2) + continuation-selection + planning-finished-wake + planning-service \| 27/27 \| \| scheduler-trait-dispatch \| 9/9 \| \| `pnpm --filter @fusion/engine exec tsc --noEmit` \| clean \| \| `pnpm lint` \| clean \| \| `pnpm test:gate` \| green \| \| `pnpm check:changesets` \| clean \| ## Two findings for the coordinator 1. `triage.ts` is absent from the Phase B census. The plan's per-file table (535 sites) covers `self-healing.ts` (U4), the executor/scheduler cluster (U5), and the core policy modules (U6). `triage.ts` appears in none of them, so its lifecycle-column literals are unowned scope — U7 absorbs them. Measured with the plan's own methodology (block and line comments stripped, code lines only): a naive quoted-literal grep of `triage.ts` reports 50 sites, but *35 of those are the agent role* string `"triage"`, not the column. The genuine lifecycle-column surface is 15 sites, of which 12 are planning-lane and 3 are `column !== "done"` in duplicate search. The 50 figure would over-count by 3.3×. 2. The graph's planning seam is a rubber stamp, in triplicate. `createAuthoritativeWorkflowSeams().planning` returns `{ outcome: "success", value: "pre-specified" }`; `WorkflowPlanningService.runPlanningSession` returns the same; `createNoopLegacySeams().planning` is a bare success. The real specification is ~1,000 lines of `triage.specifyTask`, entirely outside the graph. That is the flip U7's remaining slices have to make, and it is the reason the planning lane has two owners at all. ## Deliberately not in this PR Triage's unconditional `onSpecifyComplete` call. That is the ownership** half — `finalizeApprovedTask` must report whether it released, and the reaction must key on that outcome — and it belongs with the seam flip, where finalize's outcome becomes the graph's edge condition anyway, rather than as a half-measure now. With the three guards above in place, the downstream damage is already contained; what remains is a reaction firing for a non-event and an operator-visible log line (`Specified X → todo`) that is untrue for a parked card. 🤖 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 * Tasks awaiting manual plan approval are no longer automatically planned, reviewed, started, or released into active work. * Approval-held items are consistently skipped across planning continuations and related workflows. * Approval-held due work is deferred to prevent starvation while waiting, and operator force-promotion still bypasses the gate. * Tests * Added regression coverage to ensure the manual approval hold behavior remains invariant across multiple continuation scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 21:39:21 -07:00
gsxdsm	7871b28766	fix(core): bind the in-transaction capacity gate — one shared pool-id convention (NOT user-visible yet — see R2) (#2488 ) ## The bug `moves.ts` asked `countActiveInCapacitySlotAsync` for occupants of pool `"builtin:coding"`, while the counter buckets selection-less rows under `DEFAULT_WORKFLOW_POOL_ID` (`"__default-workflow__"`). Nothing ever landed in the pool being asked about, so the count came back 0 and a finite limit could never bind. ## Root fix, not a literal swap A shared constant would not have prevented this: `DEFAULT_WORKFLOW_ID` was already imported in `moves.ts` and the code still wrote a literal. So both sides now call a shared function, `resolveCapacityPoolId` — "which pool does a selection-less task belong to" has exactly one answer and no call site is in a position to disagree with it. The one variable serving two masters is split: a capacity pool key (a bucketing sentinel that must not collide with a workflow id) and a workflow id (telemetry, must stay a real id). The emitted `TaskTransitioned` payload is byte-identical. ## Checked, not assumed: no second copy `scheduler.ts:2514` and `:2536` do carry `?? "builtin:coding"` — but as an IR resolution key (`resolveWorkflowIrById`), where a real workflow id is required and the pool sentinel would not resolve at all. Same literal, different concept, correctly used. A blanket replace would have broken it. ## Something did depend on the gate being dead — exactly one thing `move-path-equivalence.pg.test.ts` → "UNPROVEN: in-transaction column capacity did NOT reject on EITHER path in this fixture". It left the cause open — > something further in (`resolveColumnCapacity`'s limit resolution, or what `countActiveInCapacitySlotAsync` counts as an occupant — a task with no session/agent may not count) keeps the check from firing … This suite does not establish which. — and predicted its own obsolescence ("if a future change makes this reject, that is the capacity gate coming alive"). Neither guess was right; it was the pool id. Updated to assert the divergence with the answer recorded — not weakened. Its fixture also had to start each phase from an empty wip column: once the gate binds, the inline phase's leftovers trip the cap on the holder move before the contended move under test runs. `schema-applier.test.ts` failed only in the full-suite run and passes in isolation both with and without the fix — cross-file contamination, not mine. ## Before / after — measured, both directions `maxConcurrent: 1`, real PG store, real `moveTask`: \| \| flagOFF / no selection \| flagOFF / selection \| flagON / no selection \| flagON / selection \| \|---\|---\|---\|---\|---\| \| before \| ADMITTED \| ADMITTED \| ADMITTED ← the bug \| REJECTED \| \| after \| ADMITTED \| ADMITTED \| REJECTED \| REJECTED \| The E2E acceptance row asserts held at cap 1 and admitted at cap 2 on the same fixture, so it cannot pass by simply never admitting anything. With the fix reverted that row fails; the `admitted` case still passes, as it should. The Phase A3 ratchet's two flipped assertions also fail with the fix reverted. Ratchet flipped exactly as its author specified: `DEFECT (R1)` becomes a rejection, and `it.fails` on the invariant becomes a plain `it`. ## ⚠️ This is NOT user-visible yet — please read before merging The premise this was approved on ("once it binds, cards that currently slip through will start being held") does not hold for this change alone. The whole capacity block sits inside `if (useWorkflow && workflowIr && fromColumn !== toColumn)`, and `useWorkflow` is `experimentalFeatures.workflowColumns === true` — absent from `DEFAULT_GLOBAL_SETTINGS`, with no writer anywhere outside tests. That is Phase A3's R2, still live and now retitled `DEFECT (R2, STILL LIVE)` with the measured matrix recorded in it. So on merge: nothing changes for any real project. Making it actually bind means also removing the `useWorkflow` condition — a materially larger, genuinely user-visible change that I have not made unilaterally. Escalated for a decision; if that lands, the changeset here should be re-categorised. ## Review follow-up (48e79ffd9): the convention was still duplicated — swept and ratcheted The first pass added the resolver and routed the transactional gate + counters, but hold-release still derived the pool independently. Swept the repo: six sites name the sentinel, five derive the convention and now call `resolveCapacityPoolId` (`hold-release.ts:116/118/442/576`, `task-store-helpers.ts:290`). The sixth, `scheduler.ts:1558`, names the default pool as a literal in a capacity diagnostic — no selection input, nothing to disagree with — so it keeps the constant. Does this change hold-release behavior? No, and it was never releasing against the wrong pool. hold-release computed `x ?? DEFAULT_WORKFLOW_POOL_ID`, which is exactly what the counter buckets under; `moves.ts` (`?? "builtin:coding"`) was the sole disagreeing site, and the first commit moved it into agreement with hold-release, not the reverse. `resolveCapacityPoolId(x)` is `x ?? DEFAULT_WORKFLOW_POOL_ID`, so every routed site computes an identical value for every input. No second user-visible change rides along with this PR — the only behavior delta remains the gate binding on the flag-ON path, which per R2 is still not the path production takes. Evidence: hold-release + capacity suites 43/43 identical before and after. The resolver is now the only way to compute a pool id, not merely the newest way. `scripts/check-capacity-pool-id.mjs` fails on any inline `?? DEFAULT_WORKFLOW_POOL_ID` outside `workflow-capacity.ts`, wired into both `pretest` and the blocking `test:gate`. A review note would not have sufficed: the original defect landed in a file that already imported the canonical constant. Verified both ways — clean run scans 1124 files and passes; reintroducing the old hold-release expression exits 1 and names the line. ## Review follow-up (a5b675503): the ratchet was rebuilt because it would not have caught the bug The first ratchet matched one spelling (`?? DEFAULT_WORKFLOW_POOL_ID`) and the real defect used another (`?? "builtin:coding"`). Verified: reintroducing the original defect and running the old checker exits 0. A guard that reports success without checking is worse than no guard — it stops anyone looking. Rebuilt on the TypeScript AST with two rules. Rule 1 (sink): a value reaching a capacity counter's `workflowId` must come from `resolveCapacityPoolId`, or a local initialized from it — so it fires on the original defect regardless of which literal was used, on one line or twenty. Rule 2 (sentinel): no `??` onto the sentinel at any qualification depth or as its raw value; multiline is one AST node and caught by construction. `?? "builtin:coding"` is deliberately not banned outright — it is the legitimate default for a workflow id in ~8 places, and is only a bug when it reaches a capacity pool. Fails closed three ways that previously reported success without inspecting: unreadable file, unparseable file, and an empty file listing (the old script would have printed a green tick off a broken glob). Acceptance was not "passes on main". Each form was reintroduced into the real source and confirmed to fail: the original defect in `moves.ts`, a multiline fallback, and a deeply qualified sentinel. All are pinned in `capacity-pool-id-check.test.ts` (12 cases: 7 must-catch starting with the reduced actual pre-fix `moves.ts`, 4 must-not-flag, 1 fail-closed) so the guard cannot silently narrow again. Also added to `pretest:full`, which had omitted it. ### Follow-up (0be8df6ea): a dead rule found by fixing a test title Splitting the mislabelled fail-closed test surfaced more than a mislabel: `ts.createSourceFile` is error-tolerant and does not throw on malformed syntax, so the `try/catch` behind the `unparseable` rule was unreachable and that rule could never fire. The earlier "fails closed three ways" claim was overstated — the guard advertised a capability it did not have. Detection now reads `sf.parseDiagnostics`; a partial AST can silently lack the `??` nodes and sink calls the rules look for, so "did not parse" must not read as "inspected and clean". Mutation-verified: reverting the detection fails that case and only that case. Test-file exclusion also moved to the repo's `{test,spec}.{ts,tsx}` guideline shape — a `.spec.ts` under `packages/<pkg>/src/` was being scanned as production source. Verified both ways: the `.spec.ts` is skipped, and the identical content in a non-test file is still caught, so the exclusion is scoped rather than a hole. ## Verification - engine + core `tsc --noEmit` clean - `pnpm test:gate` green (299 + 10 + 71) - E2E 20/20; capacity + move-path suites 14/14 - full core PG: 1037 passed / 3 failed — all three reproduce with the fix stashed (pre-existing) - engine-default: 279 failed vs 280 at baseline with the fix stashed — pre-existing red lane, no regression - hold-release + capacity suites: 43/43 identical before and after the resolver routing - `check-capacity-pool-id` ratchet: 14/14 regression cases; clean over 1124 files; exits 1 on the original defect, a multiline fallback, and a deeply qualified sentinel reintroduced into real source 🤖 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 * Fixed capacity-limit accounting when workflow selection is missing by consistently deriving the correct capacity pool id. * Made capacity enforcement align across move and hold/release paths, rejecting over-limit moves with `capacity-exhausted`. * Tests * Updated PostgreSQL and added an E2E scenario to verify the corrected in-transaction gating behavior at `maxConcurrent` limits of 1 and 2. * Chores * Added an automated guard to detect inconsistent capacity pool id fallback patterns in code. * Public API * Exposed `resolveCapacityPoolId` for consistent capacity pool id derivation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 21:09:51 -07:00
gsxdsm	5d0f1ef631	Phase B slice B1: lifecycle column roles in the U6 policy modules (4 guards, red-green) (#2479 ) Stacked on #2469 → #2468 → #2467. Base is `feature/workflow-capacity-ground-truth`. This is slice B1 of Phase B, not all of Phase B. Sizing escalation sent separately; the census is below. ## Why this is a slice Measured census of code lines referencing a lifecycle column literal (comments excluded): \| Unit \| Files \| Sites \| \|---\|---\|---:\| \| U4 \| `self-healing.ts` \| 203 \| \| U5 \| `executor.ts` 171, `scheduler.ts` 55, `replan-target.ts` 20, `merger-ai.ts` 5, `hold-release.ts` 4, `mesh-lease-manager.ts` 4, `task-agent-sync.ts` 3 \| 262 \| \| U6 \| `moves.ts` 34, `default-workflow-hooks.ts` 13, `board-config.ts` 9, `blocker-fanout.ts` 6, `task-priority.ts` 5, `dependency-blocked-todo-report.ts` 2, `stale-paused-todo.ts` 1 \| 70 \| \| \| Total \| 535 \| The plan's "~207" counts the guard category only. Under the phase's non-negotiable rule — a test that fails before conversion, per guard — that is ~200 red-green cycles. Doing it as one sweep would reproduce exactly the failure this phase exists to prevent: converted guards nobody proved still fire. `moves.ts` and `default-workflow-hooks.ts` stay parked per the dispatch constraint (move-path convergence and the pool-id sentinel are on an operator decision). ## Guards converted (4), each red-green Every case below was written first and observed failing against the literal implementation. \| Module \| Guard \| Before → After \| \|---\|---\|---\| \| `stale-paused-todo.ts` \| stall detection \| `column !== "todo"` → resolved hold column \| \| `blocker-fanout.ts` \| active \| `ACTIVE_COLUMNS.has(col)` → `!terminalColumns.has(col)` \| \| `blocker-fanout.ts` \| hold-wait metric \| `col === "todo"` → resolved hold column \| \| `task-priority.ts` \| unblock active \| `UNBLOCK_ACTIVE_COLUMNS` deleted, folded into the terminal set \| Three of the seven new cases are regression floors that pass before and after. One of them earned its keep immediately: it failed on my own fixture (`activeCount` vs the public `totalCount`), catching a bad test rather than bad code — which is the point of asserting the default path alongside the renamed one. ### The `task-priority` finding `UNBLOCK_ACTIVE_COLUMNS` and `DONE_COLUMNS` encoded one concept twice, two lines apart, and disagreed for any custom column: dependency counting treated a `drafting` card as unmet (correct) while the active check treated it as inactive (wrong), zeroing the blocker's unblock weight. The enumeration wasn't just legacy-shaped — it contradicted its own neighbour. ## ⚠️ Behavior change, not a pure refactor Inverting active from enumeration to exclusion means a card in a column that is neither terminal nor in the legacy enum now counts as active where it previously did not. That is the plan's stated intent, but it is a real change for any project already using a custom column — Coding (Ideas)' `ideas` column is the in-tree case. Fan-out counts and unblock weights for such cards will rise. ## Verification - Four affected suites green (45 tests), each conversion observed red→green. - `pnpm lint`, `tsc --noEmit` (core) green. Not verified / not done, stated plainly: - Call sites are not wired. These modules now accept resolved roles; every parameter still defaults to the legacy set, so at the call sites the vocabulary is unchanged. A caller that cannot resolve a workflow keeps literal behavior. Threading `resolveLifecycleColumns` through `reads.ts` and `self-healing.ts` is follow-on work — until then the guards are convertible, not converted end-to-end. - `dependency-blocked-todo-report.ts` and `board-config.ts` are untouched in this slice. - 19 core-suite failures exist on this branch; all confirmed pre-existing by stashing and re-running on a clean tree (`duplicate-guard`, `log-severity-spam-contract`, `settings-parity`, `task-delete-caller-attribution`, `settings-defaults`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- Supersedes #2470, which GitHub force-closed when its base branch was deleted by the merge of #2469 and refuses to reopen. Same head branch, same commits (rebased onto `main`), now based on `main` directly. The two P1 review threads on #2470 were resolved there — one of them with a correction noting the threading half landed in code that was subsequently deleted as a dead feature in #2477. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Dependency and blocker reports now correctly recognize custom hold, active, and terminal workflow columns. * Blockers in renamed terminal columns are no longer incorrectly reported as active. * Stale paused-task badges and self-healing now work with workflow-specific hold columns. * Mixed boards with different workflow column names are handled consistently. * Existing default workflow behavior remains compatible, including fallback handling when workflow details cannot be resolved. * Enhancements * Reporting and task-priority calculations now support configurable single or multiple hold and terminal columns. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-27 14:19:32 -07:00
gsxdsm	4158cf1ab7	Phase A: workflow-owned lifecycle foundation (U1, U2, U3) (#2467 ) Phase A (Foundation) of `docs/plans/2026-07-26-001-refactor-workflow-owned-lifecycle-plan.md`. Three units, one commit each. No operator-visible behavior change. ## U1 — Lifecycle-column resolution seam `resolveLifecycleColumns(ir)` returns `{ intake, hold, wip, review, complete, archived }` — the first column carrying each trait, `undefined` for a role no column carries. `resolveTaskLifecycleColumns(store, taskId, cache?)` is the store-aware form; the cache is caller-owned so a sweep reads one IR per workflow rather than one per card. A v1/column-less IR resolves to `undefined` for the whole struct rather than a struct of undefined roles. A caller must be able to distinguish "this workflow declares no hold column" (a real shape to honor) from "no column vocabulary at all" (skip and log) — only the second licenses conservative fallback. Nothing consumes the seam yet; Phases B–D convert the ~207 hardcoded column literals onto it. ## U2 — Delete the pre-cutover parity machinery (delete-only) `workflow-columns-settings.ts` — `isWorkflowColumnsEnabled` had the body `return true`. Six live call sites branched on it, so every flag-OFF arm was dead code that read as a supported configuration. Deleted; surviving side inlined at self-healing's transitionPending sweep, the scheduler's per-column capacity diagnostic, merge-trait's policy resolver, the board-workflows payload, two task-workflow routes, and the CLI TUI's column enrichment. `workflow-parity.ts` — asserted the default workflow's adjacency equals the legacy `VALID_TRANSITIONS`. U11 deliberately breaks that equality by merging Todo into Planning, so this is not a stale assertion to update; it is a contract against the target state. Its emitter (`workflow-parity-observer.ts`) is already a tombstone, so `getWorkflowParitySummary` and `computeWorkflowColumnsGraduationReport` aggregated run-audit rows nothing writes and had no caller outside `TaskStore`. Both store methods go with it. `flagEnabled` stays on the board-workflows wire as a constant `true` — shipped dashboard clients still branch on it, and changing the response shape is not a deletion. U10 retires the field once no client reads it. The `legacy-tombstones` ratchet is extended to both files plus seven symbols, each with the reason it is gone. ### ⚠️ Finding: the third listed deletion was NOT dead The plan also lists "the flag-off inline move path" in `task-store/moves.ts`. It is not deleted, per U2's execution note ("any behavior change found while removing a branch means the branch was not dead"). That path is gated on `isWorkflowColumnsCompatibilityFlagEnabled` (`store.ts:38`) — a different function from the always-true public helper. It reads the raw `experimentalFeatures.workflowColumns` setting, which nothing in production sets (`settings-schema.ts:396` — "no default flags are emitted"; zero non-test writers; the operator's own `~/.fusion/settings.json` has no such key). So `useWorkflow` is false for effectively every real project: the flag-OFF inline side effects are the live default move path and the flag-ON `default-workflow-hooks` path is the dead one. The code says so itself at `moves.ts:638`. Deleting that branch would swap every project onto an untravelled code path — a behavior change, not a deletion. Carry this into Phases B and C, stated plainly so the plan's error is not repeated: > The inline move path in `moves.ts` is LIVE. `default-workflow-hooks.ts` (the trait-hook path) is DEAD. KTD-6 asserted the inverse. Until the convergence unit lands, nothing may assume trait hooks run — a guard, sweep, or subscriber written against `applyDefaultWorkflowMoveEffects` would never fire in production and would still pass its tests. Convergence is not attempted here. It is its own unit (Phase A2) with a proper equivalence proof, per operator decision. ### U3's emit point is on the LIVE path — the seam is not born dead Worth stating explicitly because it is the failure mode that would make every later subscriber silently never fire: the `TaskTransitioned` emit is not inside the `if (useWorkflow)` branch. That block closes at `moves.ts:1212`; the emit sits at `:1214`, beside the existing `store.emit("task:moved", …)`, on the unconditional post-commit path. It therefore fires on both the live inline path and the dead hooks path, and the convergence unit inherits the obligation to keep it firing on whichever path survives — same events, same order, same payloads. The graph-side emitters (`NodeEntered`, `RunSuspended`) carry the same risk from a different direction: the bus refuses an invalid payload silently by design, so an emitter regression would stop the event with no test failure. They are asserted end-to-end through the real bus — "did a subscriber actually receive it", not "was emit called" — because a spy passes on a refused payload. The `moveTaskInternalImpl` emit does not yet have that end-to-end assertion against a real store move; that proof belongs to the convergence unit, which has to build the both-paths fixture anyway. ## U3 — Post-commit event seam with a transactional outbox The bus is not a queue, not a transaction participant, and not a delivery guarantee. Durable follow-on work uses the transactional outbox — a `workflow_work_items` row written inside the transition transaction (the shape `createCompletionHandoffWorkflowWork` already uses). "Emit after commit, let a subscriber enqueue the work" has a crash window where a process dies between commit and subscriber, leaving no event and no work-item row, so required work is skipped permanently with nothing to recover from. Post-commit subscribers therefore carry only losable reactions. Emission is consequently lossy and isolated by design: a throwing or rejecting subscriber is caught and logged, cannot roll back the transition, and cannot stop the others. Deliveries append to one serial chain, so two transitions on a task deliver in commit order. The ids/outcomes-only rule is mechanised, not documented — run-audit's equivalent lives only in prose and has been violated repeatedly. A payload carrying an object body or a prose string is refused at the emit boundary and never reaches a subscriber or log sink. It degrades rather than throws: the emitter is post-commit, so a shape bug must not become a lifecycle failure. Emit points: `TaskTransitioned` from the single post-commit point in `moveTaskInternalImpl`; `NodeEntered` and `RunSuspended` from the graph column boundary, the latter after the durable continuation is persisted so an observed suspension implies a resumable run. `registerWorkflowEventSubscribers` (engine) is empty on purpose — U7/U8/U10 move real reactions onto it, each with the characterization test proving the reaction was non-authoritative first. ## Verification - `pnpm test:gate` — green (2/10, 16/299, 1/71). - `pnpm lint`, `pnpm build`, `tsc --noEmit` on core and engine — green. - U1: 20 tests in `workflow-lifecycle-traits.test.ts`, including the fully-renamed-workflow case (fails if the resolver falls back to a literal) and a shared-cache read-count assertion. - U2: `legacy-tombstones.test.ts` green with the extended ratchet; `board-workflows`, `merge-trait`, `workflow-graph-executor-parity`, and move-hook suites green with no expectation edits. - U3: 20 bus-invariant unit tests (isolation, ordering, the allowed-key and required-key halves of the ids-only rule, lossiness) plus 3 end-to-end emitter-delivery tests; 5 outbox tests against a real PostgreSQL work-item table (crash survival, rollback, at-least-once redelivery on lease expiry, idempotent handler → one effect, dropped-subscriber vs. durable work). A hand-written fake of the lease predicate would only prove the fake redelivers. Not verified: the `moveTaskInternalImpl` emit is confirmed on the unconditional post-commit path by structure and by the surrounding tests, but is not yet asserted end-to-end against a real store move on both flag settings — that is Phase A2's fixture. The engine subscriber registry ships empty by design, so no production subscriber exercises the bus end-to-end yet. `settings-defaults.test.ts` has one pre-existing failure on `main` (a logger-prefix mismatch in the `mergeIntegrationWorktree=cwd-main` warning) — confirmed present on a clean tree, unrelated to this branch. 🤖 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 * Workflow lifecycle columns are now derived from workflow definitions, supporting renamed and custom workflows. * Added post-commit lifecycle events for task transitions, node entry, and run suspend/resume with validated payloads. * Follow-on processing for lifecycle emissions is now more robust (rollback-safe, at-least-once delivery, idempotent handling). * Bug Fixes * Workflow board responses, task enrichment, and promotion no longer depend on workflow-columns feature-flag gating. * Subscriber failures no longer impact committed workflow transitions. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-27 13:30:13 -07:00
gsxdsm	5ae6332563	refactor: collapse dead SQLite dual-path code; keep migration-only readers (#2454 ) # Remove dead SQLite dual-path code; keep migration-only readers ## Summary PostgreSQL cutover left hundreds of production dual-path branches (`backendMode ? PG : SQLite/store.db`) whose SQLite arms only hit throwing `Database`/`ArchiveDatabase`/`CentralDatabase` stubs. This change mechanically collapses those unreachable arms so production authority is AsyncDataLayer/PostgreSQL only, while preserving the six authorized read-only migration/recovery `DatabaseSync` seams. ## Dual-path mass removed \| Metric \| Before \| After \| \|---\|---\|---\| \| `if (…backendMode)` (non-test) \| ~328 \| ~70 \| \| `store.db` / `this.db` refs in core (non-test) \| ~570+ \| ~375 (mostly pure legacy MissionStore/eval/insight SQLite classes + thin getters) \| \| Net diff \| — \| ~6.7k lines removed across 41 files \| Remaining `backendMode` checks are intentional (incomplete-PG sync safe-defaults, settings-sync disabled-on-PG, symbol-lock PG-only gates, “requires PostgreSQL” config versioning throws), not live SQLite authority. ## Subsystems cleaned - Core TaskStore / task-store/: collapsed if/else and early-return dual-path across reads, moves, lifecycle, mutations, workflow, archive, branch/PR, artifacts, comments, audit, project ops, etc. `initImpl` is PostgreSQL-only (SQLite startup tail deleted). - Satellite stores: automation, agent, routine, plugin, secrets, approval-request, central-core dual-path arms collapsed. - Plugins: reports async methods, compound-engineering pipeline + session stores, CLI Printing Press store — SQLite fallbacks removed; PG required. - Engine: no functional dual-path change beyond whitespace (settings-sync / peer-exchange PG-disabled behavior kept). ## Six migration-only readers retained (allowlist unchanged) 1. `packages/core/src/postgres/sqlite-migrator.ts` 2. `packages/core/src/project-identity.ts` 3. `packages/core/src/sqlite-validation.ts` 4. `packages/core/src/postgres/startup-factory.ts` 5. `packages/cli/src/commands/db.ts` 6. `scripts/lib/start-local-project.mjs` Plus low-level `sqlite-adapter` and migrator/startup-import tests. Inventory ratchet still requires exactly these six `new DatabaseSync(` production sites, all `readOnly: true`. ## Not treated as SQLite - `.fusion/project.json`, `task.json`, `agent-log.jsonl` file storage - AsyncDataLayer / Drizzle PG paths - Incomplete-PG sync safe-default stubs (still return empty/false/null under backend without consulting SQLite) ## Verification - `sqlite-production-reader-inventory.test.ts` — 15/15 pass - `incomplete-pg-ports.pg.test.ts` — 6/6 pass - Targeted PG tests (create-task, move, handoff, runtime-persistence, agent, mission, insight, central-core) — green - `tsc --noEmit` for `@fusion/core`, `@fusion/engine`, `@fusion/dashboard` — green - `scripts/check-no-getdatabase.mjs` — clean <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit Improvements * Improved end-to-end consistency by making PostgreSQL/async persistence the standard across core task/workflow, automation, agents, plugins, routines, secrets, approvals, central operations, and session storage. * Unified scheduling, settings, configuration revision writes, run/workflow selection, queues/leases/transitions, and audit/lifecycle updates around consistent async transaction behavior. * Bug Fixes * Fixed edge cases for archived/deleted reads, unarchive/recovery flows, not-found handling, and task/artifact/document/log/comment operations, including more reliable emissions and hydration across search/list and lifecycle operations. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-26 23:28:42 -07:00
gsxdsm	3f33cb000f	feat: per-origin workflow selection + feedback-derived refinement titles Two task origins had no workflow picker in front of the operator and always inherited the project default: `fn task create` (CLI + the `fn_task_create` agent tool) and refinement tasks. Add a Project General setting for each, where blank/unset means "Selected workflow" (the operator's current Board lane, falling back to the project default) and a concrete id pins that origin. Because the Board lane lives in browser localStorage, non-browser callers could not resolve "Selected workflow" at all. `boardSelectedWorkflowId` mirrors the lane into project settings so they can. Note this makes the mirrored lane project-scoped: two operators on one project share it, last switch wins. The Board never reads it back, so the only effect is which workflow a newly created task inherits. Resolution is `TaskStore.resolveOriginWorkflowOverrideId(origin)`: pinned setting -> mirrored lane -> `undefined` to inherit each caller's existing default-workflow path unchanged. A deleted or fragment id degrades to inherit rather than throwing, so a stale settings value can never break task creation. An explicit `workflow_id` argument to `fn_task_create` still wins. Separately, a refinement is now titled by the operator's own feedback via the shared `deriveFallbackTaskTitle`, not `Refinement: <parent title>`. Ten refinements of one task previously rendered ten identical titles, so the board could not tell them apart while the text saying what each one asked for sat in the description. Provenance moves to a `Refines <id>` card chip alongside the existing detail-view parent link and dependency edge. Verified: merge gate (299 tests), lint, full build, and typecheck for core, CLI, and dashboard all pass. New coverage: origin resolution across both origins and the full precedence ladder, the two settings pickers, the board-lane mirror, refinement titling (including sibling distinctness), and the card chip. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 20:33:25 -07:00
gsxdsm	15a2fb18cc	Merge branch 'fix/incomplete-pg-ports' Wire incomplete PostgreSQL ports for archive, reconcile, health, settings cache, agent cache, and async prompt overrides.	2026-07-26 13:16:13 -07:00

1 2 3

138 Commits