fusion

Author	SHA1	Message	Date
gsxdsm	3aa942ee5f	capacity: spawned agents count against the project agent count (#2579 ) Two configurable numbers per project. `maxSpawnedAgentsPerParent` (5) and `maxSpawnedAgentsGlobal` (20) were a third and fourth limiter with private budgets invisible to both. ## This closes a hole, not just knobs A spawned child is an agent and gets its own git worktree (branched from the parent’s — the tool’s own description says so), but children were counted by neither capacity gate. A fan-out could put up to 20 extra worktrees on disk while the scheduler believed the project was at its configured limit. The operator’s two numbers were simply wrong about what was running. ## The old caps also measured the wrong thing `totalSpawnedCount` decrements on child cleanup, but the per-parent set is cleared only when the parent task ends. So `maxSpawnedAgentsPerParent` throttled cumulative spawns across a task’s life rather than concurrent ones — a long-running task could exhaust its budget with five children that had all long since finished, and the operator had no way to see why. ## Fix `fn_spawn_agent` gates on the same project agent count every other lane uses (`computeTopLevelConcurrencyClaimedFromStore`) plus live children. One number, one answer, no private budget that can disagree with the board. The refusal names Max Concurrent Tasks — a control the operator actually has. The old messages pointed at settings that no longer exist, which is worse than no message: it sends someone hunting for a knob that is not there. ## Verification Revert-proof, measured: restoring the private budgets turns 3 of the 4 new cases red — a project at 1/1 could still spawn, which is precisely the hole. `executor.ts` restored byte-identical. `pnpm lint` clean · core + engine `tsc` clean · `pnpm test:gate` green (414 + 10 + 71) · new suite 4/4 · `settings-default-descriptions` 4/4. There was no spawn-capacity test before this; the file is new. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * New Features * Spawned agents now count toward the project’s Max Concurrent Tasks capacity. * Agent spawning is blocked when capacity is reached, including concurrent spawn attempts. * Bug Fixes * Prevented over-allocation during simultaneous agent spawns. * Restored available capacity when agent creation fails. * Changes * Removed separate per-parent and global spawned-agent limits. * Updated settings to reflect the revised capacity controls. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 23:34:41 -07:00
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	8d3b8262c0	U2b: the second move-path divergence — legal targets differ, not just message shape (blocks the useWorkflow flip) (#2638 ) Tests only. Advances U2b's equivalence proof without touching `moves.ts`, whose edit order is still being agreed between U12 and MAIN. ## Why this one decides the sequencing The equivalence suite already records one divergence: rejection type and message differ. That is a shape difference and easy to absorb. This second one is a difference in which moves are legal, and it is workflow-dependent. U11 removed `triage` from the default coding lineage, so rows left there sit in a column their own workflow no longer declares. #2515 added an escape hatch to `resolveAllowedColumns` so such a card has a legal move — its workflow's rebound target — instead of `Valid targets: none`. That hatch lives inside the `useWorkflow` block, so it only runs on the hooks path. Mutation-verified in #2597: stubbing it back to `[]` left an operator-move test green, because the inline path answers from the legacy `VALID_TRANSITIONS` map instead, whose `triage` row happens to permit the move for unrelated reasons. So flipping `useWorkflow` changes move validation for every stranded card, not just side-effect routing. ## What that means for "flip the flag, then delete the flag-OFF branch" That plan is not the mechanical cleanup it looks like, and KTD-6's Phase A escalation correction already ruled on this exact shape once: > Deleting the inline branch would have swapped every project onto an untravelled code path and called it a cleanup. > > The convergence is its own unit with an equivalence proof (U2b), and it blocks Phase B. Nothing downstream may assume the trait-hook path runs until it lands. Flipping the flag and deleting the other branch is that deletion, reached from the other side. The tests won't catch a divergence because both paths have tests and only one of them runs — which is precisely why U2b was scoped as a proof rather than a refactor. Recommended order: U2b's equivalence proof completes → U12 flips `useWorkflow` → the flag-OFF branch and its 5 guards go away wholesale. That still gets the "strictly less work" outcome, just after the proof instead of instead of it. ## A note on how this is asserted Deliberately a positive assertion about the inline path, not a comparison of two target lists. The two paths do not reach the same rejection — inline enumerates the legacy table and reports it in the message; hooks throws the typed unknown-column rejection first. That asymmetry is the divergence. Comparing two lists would hide it behind two empty arrays and read as equivalence, which is the failure mode this suite exists to prevent. 11 tests green; 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 23:13:31 -07:00
gsxdsm	1d0f21b428	U12 R12: lifecycle-column literal ratchet — and the raw count's floor is not zero (#2630 ) The anti-regression ratchet U12 R12 calls for. Counts lifecycle-column literal comparisons in production source and fails when the count rises. ## Two jobs 1. Ratchet. A converted guard cannot silently come back as a literal. Ceilings only go down. Mutation-verified both ways: adding one `t.column === "triage"` fails with "rose to 49 (ceiling 48)"; lowering the ceiling to 47 fails with "rose to 48 (ceiling 47)". The number is exact, not approximately right. 2. Honest denominator — the finding. `triage` is overloaded in this codebase: a column id, an agent role, a session purpose, a prompt-template family, and a CLI glyph key. A raw grep counts them together, which makes "reach zero" unreachable by construction — converting `role === "triage"` in `agent-prompts.ts` would break the planning agent's prompt-template resolution, and the failure would look nothing like a column bug. \| \| count \| \|---\|---:\| \| raw `triage` matches \| 72 \| \| not a column at all \| 10 \| \| genuine column comparisons \| 48 \| The 10: `agent-prompts.ts` ×3 (`role`), `usage-limit-detector.ts` ×2 (`agentType`), `skill-resolver.ts` (`sessionPurpose`), `tool-availability.ts` (`surface`), `cli/commands/task.ts` (a glyph key), plus two in comments. Ceilings recorded for all four ids — `in-progress` (133) and `in-review` (200) were untracked entirely. ## A measurement error of mine that writing this caught A grep over `packages/<pkg>/src` misses `packages/dashboard/app`, where the board components live. That undercounted `triage` as 43 in an earlier audit of mine when it was 62. The source roots are now listed explicitly in code so the number cannot drift with someone's glob. ## The classifier is under test, not trusted A ratchet that matched nothing would pass forever while measuring nothing — the failure mode this program keeps finding. Three self-tests prevent it: - it asserts positively that `agent-prompts` / `skill-resolver` / `tool-availability` are excluded, so a classifier change that swallowed them would fail rather than quietly shrink the number; - it asserts the classifier still matches real column comparisons; - it pins `live-agent-count.ts`'s two sites as permanent no-flags fallbacks, with the reason, so a future edit that deletes them has to argue with it rather than silently drop stranded cards from the footer's queued total. The classifier keys on the left-hand side naming a column — deliberately syntactic, so a reader can audit it against the source without running anything, and conservative: an unrecognised shape counts as a column comparison, erring toward demanding conversion rather than excusing it. 7 tests green; 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 23:03:14 -07:00
gsxdsm	bcb9782d3f	fix(test): re-green task-delete-notice after the SQLite-arm deletion (21 → 0) (#2637 ) Unowned work, picked up. `task-delete-notice.test.ts` was 21 failed / 13 passed on main → now 34 passed. Test-only. `pnpm test:gate` green, `pnpm lint` clean. ## Cause `deleteTaskImpl` and `deleteTaskIfImpl` are now thin delegators. The SQLite arms were deleted in the PG cutover (`FNXC:SqliteDualPathCleanup 2026-07-26`) and both forward unconditionally to `store.deleteTaskBackend` / `store.deleteTaskIf` — `deleteTaskImpl` is literally "throw if self-delete; return `store.deleteTaskBackend()`", with no `backendMode` branch left. The suite drove them against a `makeSqliteStore` fake providing neither method, so every case threw `store.deleteTaskBackend is not a function` before reaching any notice logic. All 21 failures were measuring a crash, not a decision. ## Fixes - the PG fake gains `deleteTaskBackend` / `deleteTaskIf`, wired to the real backend impls rather than stubbed — so the delegating paths still prove the delegation preserves the notice decision instead of asserting against a mock; - plus `withTaskLock` (`deleteTaskIf` wraps the conditional delete in the per-task lock), running the body inline so the predicate and short-circuit paths execute for real; - every remaining `makeSqliteStore` call site retargeted, and the now-dead factory deleted so it cannot rot back in. ## Corrected a claim the file was making The header's Surface Enumeration said the three paths prove "the behavior cannot depend on backend mode". There is one backend now. The enumeration is still worth driving — a caller reaching the public entry point must get the same notice as one reaching the backend directly, and these paths prove exactly that — but it is a different claim, and the file now states it, with the two paths renamed from `(SQLite)` to what they actually are. ## A bug in my own patch, caught by re-running My first edit inserted the method assignments after the `return`, so they were unreachable and the symptom didn't change. I only found it because the failure count stayed identical and I checked the file instead of assuming the edit had landed. Worth noting because "the patch applied" and "the patch took effect" are different facts, and this session has now produced three variants of that same mistake. ## Deliberately not fixed here `task-delete-caller-attribution` (13 failed) and `task-delete-nonblocking-cleanup` (2 failed) share the root cause, but their `makeDeleteStore` fake carries `backendMode: false` and lacks the PG surface the real backend impl needs (`asyncLayer` / `transactionImmediate` / `rowToTask` …). Wiring them means either building that surface out or re-pointing the suites at `deleteTaskBackendImpl` directly — a judgement about what those suites are for, and worth making deliberately rather than folding into this fix. Whoever owns the PG cutover cleanup will know which; the diagnosis above is the whole of it. Verified no collateral: `task-merge` and `legacy-adoption` unaffected (166 passed across the three files). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 23:03:03 -07:00
gsxdsm	7397cea2dc	U12: pin the move-path flag blast radius (6 seams, not 1) before flipping it (#2639 ) Per the sequencing agreed in-thread — U12 resolves the flag first, then the flag-OFF branch is deleted wholesale — this is the step before the flip, not the flip. ## The flag is six switches, not one `moves.ts:363` reads the raw compatibility flag nothing in production source writes, and gates the hottest lifecycle path in the system. Every summary so far has under-scoped it, mine included: I described it as the `789`/`837` pair. Measured, it is six decision points: \| seam \| what flipping turns on \| \|---\|---\| \| 392 \| resolves the task's workflow IR — `undefined` when off, so every IR-dependent guard below is inert \| \| 489 \| typed rejections: unknown-column and adjacency validation \| \| 789 \| column side effects route through the trait hooks instead of the inline legacy block (timing, reset-on-entry, abort-on-exit, `merge.onEnter`) \| \| 1092 \| writes the transition-pending marker that capacity counting reads \| \| 1330 \| runs plugin hooks on column change \| \| 1395 \| records `workflowId` on the emitted move payload \| ## The risk is seam 2, and it is not an equivalence question With the flag off there is no target-column validation on the move path at all. Flipping introduces new refusals for moves that succeed today, on the path every engine lane uses. That is not "do the two implementations agree" — it is new behaviour, and a green suite is not evidence about it. `recoveryRehome` already carves out legacy targets (#1411); nothing proves the other callers are covered. ## What this PR asserts - The seam count. Mutation-checked, not assumed: replacing one gate with `if (true)` fails with `expected 5 to be 6`. (My first mutation attempt silently didn't apply — `str.replace` with no assert — so the anchor is verified now.) - All six read ONE flag. If a seam were rewritten to consult settings directly, a flip would move five behaviours and leave one behind, and nothing else in the suite would notice because both states are individually valid. - The flag-OFF branch is still inline, so the delete-with-the-branch step has a test naming the plan if someone converts its guards instead. - The atomically-coupled second reader is named. `workflow-task-create-ops.ts` computes the `movePolicyPreflight` that `moves.ts` consumes, so un-gating either alone either evaluates workflow move policies whose result is ignored, or validates against a preflight never computed. Comments cannot inflate the count — it is an AST walk. Parse failure fails loudly via `parseDiagnostics` rather than a try/catch, since `createSourceFile` is error-tolerant and a partial tree would undercount and read as "seams were removed". ## Preconditions for the flip, recorded in the file header 1. An equivalence proof for seam 3 across timing, reset-on-entry, abort-on-exit and `merge.onEnter`. Neither implementation is the observed baseline — they have never both run in production. 2. A census of the moves seam 2 would newly reject. 3. Both raw-flag readers flipped atomically. ## Why not just flip it here Because I cannot honestly claim the equivalence proof from a source read, and the flip is on every task move. Landing the blast radius as a test first means the flip PR has something to be proven against, and it means the next person cannot under-scope it the way this has been under-scoped four times. ## Verification `pnpm lint` clean, `pnpm test:gate` green (10 / 482 / 71), `tsc -p packages/core/tsconfig.json` clean, suite 5/5. No changeset: test-only, no behaviour change. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:55:57 -07:00
gsxdsm	50ebf3c543	TAKING cli/project.ts (fn project reported 0 running agents) + two test fixes — dashboard conversions WITHDRAWN in favour of #2626 and #2636 (#2631 ) Three app-cluster conversions plus the evidence that they behave on a renamed AND a merged board. ## Per-file guard counts \| file \| before \| after \| note \| \|---\|---\|---\|---\| \| `packages/cli/src/commands/project.ts` \| 0 \| 0 \| not a comparison site — see below \| \| `packages/dashboard/app/components/TaskContextMenu.tsx` \| 2 \| 2 \| count does not move — deliberate, see below \| \| `packages/dashboard/app/components/Column.tsx` \| 2 \| 2 \| count does not move — deliberate, see below \| Read this before scoring the PR against the bar. You said a claim that does not move your number is not done, so I am telling you up front that this PR does not move it, and why. Both dashboard conversions are fallback-preserving: ```ts const isIntakeColumn = columnFlags ? columnFlags.intake === true : column === "triage"; ``` The literal survives as the no-flags branch, so the grep still counts it. That is the shape the sibling code already uses (`isPreExecutionHoldColumn`, same file, converted earlier in the program), and dropping the fallback would make an unresolved-column render lose the affordance a second way. What changes is the behaviour when flags exist — which is what the mutation results below measure. If you want these to zero out the count, the fallback has to go, and that is a separate decision about whether an unresolved column should fail open or closed. Say the word and I will do it as a follow-up; I did not make that call unilaterally because it is not reversible from a rendering standpoint. `cli/project.ts` was never a comparison site at all — it fed raw rows to `isRunningAgentTaskShape`, so the helper's own internal legacy fallback kicked in and `fn project` reported 0 running agents on any renamed board. Fixed by resolving the IR per task before counting. Nothing to subtract. ## Two of the three had a test that looked like coverage and was not - `Column.tsx` — the quick-create gate is `workflowMode \|\| isIntakeColumn`. Every pre-existing intake case in `Column.test.tsx` also passes `workflowMode`, so the `\|\|` short-circuited and none of them ever reached the trait lookup. Added cases that omit `workflowMode`, the only path where the conversion changes the answer. - `TaskContextMenu.tsx` — the intake suppression was asserted only for the legacy `triage` id, the one board shape where a broken conversion still returns the right answer. Mutation-verified rather than asserted: \| mutation \| result \| \|---\|---\| \| `isIntakeColumn` → `column === "triage"` \| 2 of 88 fail (exactly the renamed and merged cases) \| \| menu suppression → `task.column !== "triage"` \| 1 of 12 fail \| ## A pre-existing red I fixed on the way past `uses VALID_TRANSITIONS and in-review back-to-progress labels` was already failing on origin/main. #2521 correctly moved the "Back to X" label onto the host's `columnLabel` function; this file's stub is `(column) => column`, so the hardcoded `"Back to In Progress"` expectation was left over from the pre-#2521 hardcode and nothing had updated it. Matching the raw id would have made it pass while proving nothing, so instead that one case gets a display-like label function — the assertion now fails both if the "Back to" prefix regresses and if the label stops routing through `columnLabel`. Strengthened, not relaxed. Counts against completion criterion #2. ## Verification - `Column.test.tsx` + `TaskContextMenu.test.tsx`: 100 passed - `tsc -p tsconfig.app.json` (the root config does not cover `app/`) and the CLI typecheck: clean - `pnpm test:gate`: green 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:52:30 -07:00
Phil Larson	a54d60ee70	fix(core): restore standalone central backend initialization (#2596 ) ## Summary - restore the owned PostgreSQL backend bootstrap for layer-less `CentralCore.init()` callers - fix node, mesh, and project CLI commands returning empty state and logging `backendHandle is only available in backend mode` during cleanup - add a hermetic regression test for standalone backend ownership and shutdown PR #2454 accidentally added an unconditional early return immediately before the existing standalone bootstrap. Runtime pool sharing remains unchanged: `attachBackendLayer()` releases the central-only connections before adopting the project store layer. ## Verification - RED: regression failed because `createCentralBackendLayer` had zero calls - GREEN: focused regression passes - `pnpm --filter @fusion/core typecheck` - `pnpm --filter @fusion/core build` - `pnpm test` with `FUSION_PG_TEST_SKIP=1`: 482 engine + 132 Core gate + 71 CLI shape + changed regression passed; isolation clean - changeset format check passed The local PostgreSQL merge-gate harness is unavailable without credentials (`empty password returned by client`), so its 10 tests were explicitly skipped rather than misreported. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Restored PostgreSQL central registry access for standalone Node/mesh/project CLI commands without marking the host offline on shutdown. * Improved CentralCore lifecycle handling: concurrent `init()` coalesces, and operations are blocked once `close()` is requested/in progress. * Refined embedded PostgreSQL runtime shutdown: owner stop is coordinated with lease release, registrations are rejected while stopping, and shutdown/teardown uses lease lifecycle consistently. Embedded start failures now treat stopping as retryable. * Tests * Expanded coverage for CentralCore close/init/attach races and embedded PostgreSQL lease/shutdown coordination scenarios. * Documentation * Updated Changeset notes to clarify CLI and shutdown semantics. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-29 22:41:17 -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	51e108b4f0	core/workflow-ir-resolver: let callers tell a RESOLVED workflow from a GUESSED one (unblocks the triage census) (#2618 ) Shared-backlog infrastructure, not a single-file conversion. This is the blocker I hit on three separate census files and flagged twice; landing it once beats working around it five more times. ## The problem `resolveWorkflowIrForTask` returns the default coding IR in two cases that are not the same as knowing which workflow governs a task: - the selection read threw; - the store reported no selection at all — the synchronous PostgreSQL path does exactly this, deliberately. Callers cannot distinguish either from a genuine selection. For lifecycle-column work that difference decides correctness. Post-merge the default coding lineage declares `todo` as its single Planning column and no `triage`. So a call site converting a `column === "triage"` guard to trait resolution silently stops firing for `builtin:legacy-coding` cards whenever the store cannot name the workflow — it is handed the default's vocabulary with no signal that it was a guess. ## Why this is the census blocker, with receipts Every conversion I have landed has hit it and worked around it the same way: \| Site \| Workaround forced \| \|---\|---\| \| `usage-limit-detector.ts` (#2572) \| narrowed to intake, three separate corrections \| \| `mission-feature-sync.ts` (#2609) \| legacy ids unioned, then position-ordered to stop over-claiming \| \| `live-agent-count.ts` (#2604) \| not converted at all — left as a documented finding \| That is why the count stalls around a dozen rather than converging on zero: the honest conversion is unavailable, so each site keeps the literal "just in case". With provenance a caller can finally say what it means — trust the resolved columns when the workflow was selected; fall back to legacy compat only when it was guessed. ## What lands `resolveWorkflowIrForTaskWithProvenance` returning `{ ir, source: "selection" \| "default", workflowId? }`. Additive by construction: `resolveWorkflowIrForTask` delegates to it and drops the provenance, so the two answers cannot drift and no existing caller changes behaviour. ## Red-green Mislabelling the no-selection guess as a selection fails its test (`1 failed \| 5 passed`). One test deliberately pins the underlying fact rather than assuming it — the default guess really does lack `triage` and does have `todo`. If that lineage ever regains the column the hazard changes, and the callers relying on provenance should be revisited; this is what will tell them. Another asserts `resolveWorkflowIrForTask` returns exactly the provenance form's IR across all three paths, so the delegation cannot silently diverge. ## Not done here I have not converted any call site onto it. Each one is a behaviour decision for its owner — `comments-ops.ts`, `task-creation.ts`, `archive-planning.ts`, plus revisiting the three above — and bundling them would make this unrevertable. The enabler is the shared part. ## Verification - 6 new tests green; `pnpm test:gate` green (132 / 10 / 482 / 71); `pnpm lint` clean; `tsc --noEmit` clean - Additive API on a private package (`@fusion/core`), no behaviour change, so no changeset 🤖 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:50 -07:00
gsxdsm	f14059e8d3	Retry still refuses cards parked mid-planning on 5 builtins (survives #2614 ; count 0 → 0, defect-only) (#2621 ) Rebased onto main after #2614 landed this file. That PR's conversion already took the tracked count for `register-task-workflow-routes.ts` to 0, so this PR does not move your number and I am not claiming it does. \| file \| before \| after \| \|---\|---:\|---:\| \| `packages/dashboard/src/routes/register-task-workflow-routes.ts` \| 0 (post-#2614) \| 0 \| What it fixes is a live 400 that #2614 left in place. Measured on current main: 9 of this file's 14 retry tests fail without the change below. ## The defect `POST /api/tasks/:id/retry` must answer "does this card sit where its workflow plans?", because the yes-branch is destructive — it stamps `needs-replan` and deletes PROMPT.md. Two predicates stood in for that question and neither answered it: - #2614 resolved the intake column. Correct for the merged lineage; wrong wherever intake and the planning column differ. - The older arm asked `!workflowHasColumn(ir, "triage")`. Measured across all 12 builtins: not one plans in `triage`, while seven still declare that column. So for the five that declare `triage` and run every plan node in `todo` — `quick-fix`, `review-heavy`, `compound-engineering`, `design`, `legacy-coding` — the predicate is `false` and a `planning`/`needs-replan` card sitting in its own planning column is refused outright: ``` 400 — "Task is not in a retryable state (current status: needs-replan)" ``` The operator has no button at all on a card parked mid-planning. The mirror-image fault is destructive rather than obstructive: a workflow that plans anywhere other than `todo` had a `todo` card's PROMPT.md deleted for a re-plan nobody asked for. ## Fix `workflowPlansInColumn` asks the graph. Planning nodes are recognised by the semantic markers the builtins carry — `config.seam === "planning"` and an exact `workflowAction` set (measured vocabulary: `plan-replan`, `code-review`, `pre-merge-remediation`) — with node ids as a backstop. Deliberately not a `startsWith("plan")` prefix. That was my first attempt and greptile was right to kill it: it matched in the destructive direction, classifying a custom `plan-execute` column as a planning column, which deletes a specification. An unlisted planning action costs a replan (recoverable, card stays retryable); a wrongly-listed one costs a spec (not). Hence opt-in. ### Second concern, split out Narrowing the destructive branch must not narrow retryability — those were one boolean and are two questions. A card parked outside its planning column would otherwise fail the gate and answer 400: that trades a card which loses its spec for a card nothing can rescue. It stays retryable via the non-destructive branch, scoped to pre-WIP columns so no `in-progress`/`in-review` status gains a path it lacked. A v1 IR declares neither columns nor nodes, so placement is unanswerable rather than answered "no". `workflowDeclaresColumnModel` distinguishes the two — reading that silence as "past planning" is exactly what 400'd a v1 planning card. ## Verification All three greptile P1s on the earlier revision were real and are fixed with revert-proof tests (bespoke planning-node ids; the v1 regression I introduced; my own loose action prefix). `pnpm lint` clean · dashboard `tsc` clean · `pnpm test:gate` green (132 + 10 + 482 + 71) · core 11/11 · dashboard 119/119 (`retry-planning-column` + `stale-merge-status` + `routes-tasks`). 🤖 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:33 -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	6ca7cc94ec	triage census — core/types/archive-planning.ts 1→0, plus the self-healing.ts audit (10 guards, 2 traps a mechanical conversion would miss) (#2622 ) Batched: one conversion plus the audit for the largest remaining file, so the CAPACITY worker inherits the analysis instead of redoing it. ## Per-file counts \| File \| Before \| After \| \|---\|---:\|---:\| \| `packages/core/src/types/archive-planning.ts` \| 1 \| 0 \| Verified with the raw pattern (`column [!=]== "triage"`), which is what the coordinator greps — including checking that my own explanatory comment did not reintroduce the literal. It did, on the first attempt; caught and removed before pushing. ## The conversion: a doc that manufactures dead guards There is no executable guard in this file — raw 1, code 0. I fixed it anyway, because the documentation was wrong in the way that propagates: it told consumers to derive running agents via a hardcoded intake-column comparison. Post-merge the default lineage declares one Planning column and no `triage`, so anyone implementing from that sentence writes a comparison that matches nothing — a dead guard authored on purpose, from an instruction we left lying around. A doc handing out a dead predicate is worse than a dead guard, because it manufactures more of them. Now describes roles. Also disambiguates the neighbouring line where "triage agent" is a lane/role id, not a column — the same conflation that accounts for 23 of the original broad 48. ## Audit: `self-healing.ts` (10 guards, unclaimed at time of writing) 45% of the remaining bar, and every one sits in a recovery sweep. 6 of the 10 are sole-`triage` and already dead for default-workflow cards. \| Line \| Guard \| Fires for default cards? \| What silently stops \| \|---\|---\|---\|---\| \| 2964 / 2984 / 3019 \| advanced-triage recovery: filter, live re-check, `moveTaskIf` CAS \| No \| stranded specification work never recovered \| \| 12173 / 12494 \| orphaned-approved + orphaned-planning sweeps \| No \| orphaned planning sessions never reaped \| \| 12321 \| `task_refine` candidates \| No \| refinement tasks never recovered \| \| 9218, 10703, 11282, 12218 \| paired with `todo` \| Yes, via the `todo` arm \| — (legacy-compat arms) \| Two traps a mechanical conversion walks straight into: 1. `listTasks({ column: "triage" })` at 12172 and 12493 is a dead QUERY, not just a dead filter. Convert only the `t.column === "triage"` predicate and both sweeps scan an empty result set — the file counts as converted while the sweeps stay exactly as dead. This is the coordinator's rule #2 in its most literal form: a guard surviving in another branch of the same function. 2. Lines 2964 / 2984 / 3019 are one transaction — filter, live re-verify, and a `moveTaskIf` compare-and-set. Convert them independently and you get a filter matching the resolved intake column against a CAS still demanding the literal, so every move refuses. Silently: `moveTaskIf` returning false is indistinguishable from a lost race. Both need the resolved-vs-guessed distinction from #2618 — a `builtin:legacy-coding` card in `triage` must still be recovered when the store cannot name its workflow. ## Related live finding, not fixed here `resolvePlannerLanesForTask` (merged in #2610; used by `executor.ts:11978`, `scheduler.ts:1843`/`:2414`, `mission-autopilot.ts:973`) cannot tell a resolved workflow from a guessed one. Probe on main against a `{ getTask }`-only store: ``` PROBE lanes: ["todo"] dedicated: [] ``` So a `builtin:legacy-coding` card in `triage` is not recognised as a planner lane — mission-feature rollback stops firing and the spec-staleness planner skip never fires. Neither errors. #2618 is the fix; ~3 lines per resolver in `planner-lane-resolution.ts`. ## Verification `tsc --noEmit` on `@fusion/core` clean; `pnpm lint` clean. Comment-only change, no behaviour change, no changeset. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Documentation * Clarified terminology for archived task planning overrides. * Updated project health documentation to better explain how active agent counts are calculated across workflow stages. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:23:45 -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	9a11e0b136	U2b reproduction: the live move path accepts the column U11 deleted (characterized, not patched) (#2601 ) Found while proving U11's caveat 2. Characterization plus guard-rails — no production change, deliberately. ## The defect A default-workflow card in Planning can be moved into `triage` — a column its workflow no longer declares — re-creating exactly the stranded state `reconcileUndeclaredTaskColumns` exists to repair. Measured on a fresh store: ``` experimentalFeatures.workflowColumns null ← no production writer createTask(...) column = "todo" moveTask("todo" → "triage") ACCEPTED moveTask("todo" → "bogus-column") REJECTED: "Valid targets: in-progress, triage, archived" ``` The second rejection is the tell. Validation is real — but it is the legacy `VALID_TRANSITIONS` table talking, and that table does not know the card's workflow. Its `todo` row still lists `triage`. ## Why the workflow-aware check does not run `moves.ts` gates its adjacency block — including `workflowHasColumn(workflowIr, toColumn)` — on `isWorkflowColumnsCompatibilityFlagEnabled`, which reads the raw `experimentalFeatures.workflowColumns` key. Nothing writes it, so the block is dead on the path every real project takes. Corollary, already reported: U11's undeclared-source escape hatch in `resolveAllowedColumns` also does not run in production. It was added with #2515 so a stranded card would have a legal move instead of `Valid targets: none`; on the live path that rescue comes from the legacy table instead. Mutation-verified — stubbing the hatch back to `[]` leaves the operator-move test green. ## Why I did not fix it PR #2499 un-gated the capacity check and explicitly scoped validation out: > SCOPE, deliberately narrow: only the CAPACITY check is un-gated. `workflowIr` stays flag-gated so transition VALIDATION keeps its current behavior — the inline path's bare-Error/"Valid targets:" contract is unchanged, and none of the Phase A2 divergences are flipped here. That is a considered decision by the owner of this function, and several suites pin the contract it protects. Overriding it from outside would flip an error shape I do not own. What has changed since that decision is U11: the legacy table now offers a target the default workflow does not declare, which it never did before. That is new input to the scoping call, not licence to ignore it — so this lands as a reproduction for U2b rather than a patch. U2b's branch (`feature/workflow-move-path-convergence`) is stale — HEAD predates several merged PRs, clean tree — so nothing is being raced. ## What ships The defect is characterized, not asserted-as-correct: the test pins today's behaviour so it is visible and measurable, and an `it.todo` states the intended behaviour. Writing it as a passing "refuses" test would have required the fix; writing it as a failing test would redden CI; asserting the current behaviour as correct would be a lie. Characterization plus `it.todo` is the honest third option. Four guard-rails pin what a fix must not break: - every declared lifecycle move (`todo → in-progress → in-review → done`) - archiving - a `recoveryRehome` deliberately reaching an undeclared column — the path that rescues already-stranded cards, and the one a careless fix would break - a premise test asserting the compatibility flag really is unset, so the suite fails loudly if that ever changes rather than silently testing a different code path ## Exposure Narrow but real. U10 already fixed the dashboard move menu to offer only workflow-declared targets, so the board does not present this. The write path does — REST API, CLI, plugins, any stale client — which is why the guard belongs in `moves.ts` rather than only in the UI. 5 passed + 1 todo; 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 * Added coverage for task moves involving workflow-declared and undeclared columns. * Documented a known issue where tasks can currently be moved into the deleted `triage` column. * Preserved valid moves, archiving, and recovery re-homing behavior. * Documentation * Added reproduction steps, affected move paths, and guardrails for addressing the issue. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:12: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	71f64025d8	triage census — core/live-agent-count.ts: the literal fallback is NOT fixture-only (finding, 2 sites still open) (#2604 ) Taking `packages/core/src/live-agent-count.ts` from the shared triage-guard backlog. This PR does not convert it — it corrects a comment that would have stopped the conversion, and records why the conversion is not a one-liner. ## Per-file guard count \| File \| Before \| After \| Note \| \|---\|---:\|---:\|---\| \| `packages/core/src/live-agent-count.ts` \| 2 \| 2 \| not converted — see below \| Census across `packages//src` excluding tests, for the pattern `column === "triage"` / `column !== "triage"`: \| File \| Sites \| \|---\|---:\| \| `engine/self-healing.ts` \| 10 \| \| `dashboard/src/routes/register-task-workflow-routes.ts` \| 7 \| \| `core/task-store/comments-ops.ts` \| 3 \| \| `dashboard/src/routes/board-workflows.ts` \| 2 \| \| `core/task-store/task-creation.ts` \| 2 \| \| `core/live-agent-count.ts` \| 2 \| \| `engine/spec-staleness.ts`, `engine/replan-target.ts`, `engine/mission-feature-sync.ts`, `core/types/archive-planning.ts` \| 1 each \| ## The finding The comment in this file asserted the literal fallback was unreachable: > "The literal fallback is fixture-only; board/store callers always supply flags/IR."* It is false. `useExecutorStats` resolves `columnFlagsByTaskId?.get(task.id) ?? columnFlagsById?.get(task.column)` — `undefined` for any card whose column is absent from the board's flag map, which is exactly the renamed-or-undeclared column case. So the literals run in production, on the cards least likely to match them. Consequence is under-reporting, not a stall. A card in a renamed planner column matches neither `triage` nor `todo`, so `isWaitingAgentTask` returns false and the footer's queued count silently omits it. Default-workflow cards still match through the `todo` arm after the Planning merge, which is why nothing looks broken — the same "still fires via the todo arm" shape as the executor sites I audited in #2572, but here with a real observable effect. ## Why I did not convert it Removing the id guesses means deciding what an absent flag set should mean, and `"not intake"` is as much a guess as `"todo is intake"` — either choice moves the numbers the operator sees in the footer. Doing that safely needs the dashboard's flag-map population understood and a test that pins the queued count, neither of which is a small change. A comment asserting an untrue invariant is worse than no comment: it is precisely what would stop the next person converting these two sites, because they would read it and move on. Correcting it is the useful part I can land with confidence right now; the census entry stays open. ## Verification `tsc --noEmit` on `@fusion/core` clean; `pnpm lint` clean. Comment-only change to production source, so no behaviour change and no changeset. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:47:52 -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
gsxdsm	d1cbb8ce90	U11: rank assigned work by lifecycle role (1 -> 0), plus two documented non-conversions (#2563 ) Based on `main`. Continuing with unassigned work in my area (scheduling/ranking core). ## Measured (drift-review tracking) \| file \| comparisons before \| after \| \|---\|---:\|---:\| \| `packages/core/src/assigned-task-ranking.ts` \| 1 \| 0 \| ## What was wrong `tierForTask` identified the two actionable tiers by literal id — `in-progress` → `in_progress`, `todo` → `ready_todo` / `partial_blocked`. The file's own comment already recorded half of this: > Only treating default `todo`/`in-progress` as titled hid assigned work as a bare count But the fix that followed was a floor, not a fix: unrecognised columns fall to `other` so work stays visible, while a renamed hold column loses `ready_todo` and `partial_blocked` entirely. Work that is genuinely ready to start then ranks below everything already in progress, so an agent reading its Wake Delta sees ready work buried. Nothing errors and nothing disappears — the ordering is just wrong, which is how it survived a comment that noticed the adjacent problem. `partial_blocked` is the sharper loss: it's the only tier distinguishing "ready" from "waiting on a dependency" for hold-column cards, and it was unreachable for any renamed workflow. ## Two sibling files deliberately NOT converted Checked before assuming work existed: `live-agent-count.ts` — already trait-driven. Its literals are the else-branch of `flags ? traits : literals`, and the source says why: "The literal fallback is fixture-only; board/store callers always supply flags/IR." Converting a fixture-only fallback would be churn. `task-priority.ts` → `sortTasksForDisplayColumn` — dead. No production caller. The dashboard has its own independent implementation in `app/components/taskSorting.ts` with a richer signature (`doneSortMode`, `isArchivedColumn`), and that's the one `Lane.tsx` imports. Core's copy is reached only by its own tests and the barrel export. That's the third dead export this unit has found by checking reachability before converting (after the legacy dispatcher and `isRunnableQueuedOverlapCandidate`). Deletion is a separate concern from conversion and is not in this PR. ## Verification - Mutation-verified: not threading `roles` through to `tierForTask` fails 4 of 6 new tests - 13 tests green (6 new + the pre-existing ranking suite) - merge gate green (414 + 10 + 71), tsc clean, lint clean No changeset: `@fusion/core` is private. 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-07-29 10:26:46 -07:00
gsxdsm	969c2cdf1d	capacity part 4: drop the central global_concurrency table (migration 0037) (#2555 ) Final piece of the cross-project cap removal. Enforcement (#2509), settings/API/UI (#2529) are merged; this removes the storage. Nothing read the table. `global_max_concurrent` held the deleted machine-wide cap; `currently_active`/`queued_count` were written only by `acquireGlobalSlot`/`releaseGlobalSlot`, measured earlier in this program to have no production caller, so those counters were fiction. Live “N running (all projects)” telemetry comes from `CentralCore.getLiveRunningAgentCounts` and is unaffected. Dropped rather than left unread: a lingering table with plausible-looking counters invites a future reader to trust it — the same trap as a readable-but-ignored settings key. ## The trap this hit, because the first attempt looked correct `schema-applier.ts` warns that “migrations are registered here explicitly (not auto-discovered from the migrations dir), so a new .sql file that is not wired through a version constant + bookkeeping check silently never runs.” My first pass added the `.sql`, updated the drizzle model and bumped the baseline — and the table was still present in a fresh database. It was caught only because the test asserts the table is gone (`to_regclass(...) IS NULL`) rather than merely unreferenced; an absence-of-reference assertion would have passed while the table survived. Now registered properly: `DROP_GLOBAL_CONCURRENCY_VERSION = "0037"`, explicit path constant, applied-check, bookkeeping insert. The historical `0000` baseline is deliberately not rewritten — a fresh database CREATEs the table then drops it, converging with upgraded databases without editing history, which is how every prior migration here behaves. Also removed: the drizzle model, the `centralTableNames` entry, and the `replacesCentralSeed` special case in the SQLite migrator (a legacy SQLite `globalConcurrency` table now has no destination and is simply not migrated — correct, since its cap is deleted and its counters were never written). ## Verification `pnpm lint` clean · core `tsc` clean · `pnpm test:gate` green (414 + 10 + 71) · `schema-applier` 75/75 · `sqlite-migrator` 43/43 · full core PG suite 1044 passed / 3 failed — the same 3 pre-existing (`central-archive-secrets` log-prefix, `workflow-settings-project-identity` legacy fallback ×2). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 10:15:42 -07:00
gsxdsm	8578a1d27d	U8 PR5: thread the implementation exit to the step seam, and declare the stepwise pending-review park (inert) (#2546 ) Follows #2519 (U8 PR4). Both halves are inert — no behavior change — and this removes the blocker PR4 documented. ## What was blocking PR4 could only land its IR half because the pending-review ending could not reach a graph edge on the default workflow. Three links in the chain: \| Link \| Problem \| \|---\|---\| \| `runGraphTaskStep` \| awaited the memoized implementation pass and discarded its result \| \| `RunTaskStepResult` / `RunSingleStep` \| had nowhere to carry an exit \| \| `stepExecute` seam \| flattened every ending to `step-done` / `step-failed` \| All three are fixed. The outcome stays `failure` (the step genuinely did not complete) while the value now names the ending — which is what `runForeach` propagates upward, since it returns a failing instance's value as the foreach node's own. Every other ending keeps `step-failed` byte-identically. One design note: the exit is a property of the pass, not of a step. A single memoized pass serves every foreach instance, so all instances report the same ending — correct, because the ending is what stopped the whole session. With the value surviving, the stepwise IR declares the same `review-handoff` park node and `steps --outcome:review-pending--> review-pending-handoff --success--> end` edge the plain-`execute` shape got in PR4, inherited by the final-review and Ideas variants that clone it. ## A bug my own threading introduced, and what caught it The first threading commit covered one of the two paths out of `runProjectedGraphTaskStep`. The early-return branch carried the exit; the main path goes through `runTaskStep` in `step-runner.ts`, which builds its own result and dropped it — i.e. it worked on the path I happened to read, and not on the path the default workflow actually takes. FN-5436's regression test caught it, not code review. That is the second time this test has stood between this unit and a silent regression, which is worth recording somewhere durable: `executor-step-session.test.ts > FN-5436: pending-review skip on no-fn_task_done exit` is the load-bearing test for this area. ## Why the seam flip is still not here With the threading complete I applied the behavior half again — flip the execute seam to return `review-pending`, delete the inline `handoffTaskToReview`, add a named compat classifier for user-authored graphs. FN-5436 still failed: the card did not reach `in-review`, so something between the seam value and the park node is not routing under that harness. I have not isolated whether that is the mock store's IR resolution (it exposes no `getWorkflowDefinition`, so the run resolves the built-in through a different path), a foreach aggregation detail, or the park node's own seam. I stopped rather than keep guessing, and reverted the behavior edits so this lands green and inert. Shipping a half-routed move is exactly the failure this unit exists to remove — a lifecycle transition that silently does not happen. The alternative on offer was to relax FN-5436's assertion, which would have been appeasing a test that is telling the truth. ### What the instrumentation showed (done after opening this PR) I ran the bounded next step rather than leaving it as a note. Two facts, both measured: 1. The IR is correct. Resolving `BUILTIN_STEPWISE_FINAL_REVIEW_CODING_WORKFLOW_IR` at runtime shows the node and the edge survive the final-review variant's edge rewiring: ``` EDGES [{"from":"steps","to":"browser-verification","condition":"success"}, {"from":"steps","to":"review-pending-handoff","condition":"outcome:review-pending"}, {"from":"steps","to":"end","condition":"failure"}] HAS NODE true ``` That matters because the variant does `template.edges = [ ... ]` (a wholesale replacement) and filters outer edges touching `review` — `review-pending-handoff` is not `review`, so it survives. Worth knowing before anyone adds another node near it. 2. The `stepExecute` seam is never invoked in that harness, even though the run terminates at `steps#0:step-execute` and the implementation session demonstrably runs (`"Agent finished without calling fn_task_done but Step 0 is blocked on pending review"` is in the task log). A `console.log` at the seam's value computation produced no output. So the exit is threaded correctly and the IR can route it, but under this harness the value never originates. 3. Nor is `createPromptLikeHandler`'s returned handler. Instrumenting its dispatch (`node.id` + resolved seam) produced nothing either — so the node is not reaching the prompt-like path at all. Control experiment, because a negative result from instrumentation is worthless until you prove the instrumentation is observable. A `process.stderr.write` at module load of the same file appears exactly once in the same run, so writes from that module are captured under this harness and the two negatives above are real, not artifacts of swallowed output. That narrows the remaining work to one question — what actually drives `steps#0:step-execute` in this run, if neither the prompt-like handler nor the `stepExecute` seam does — and rules out the IR, the foreach propagation, the threading, and the instrumentation as suspects. Next step, now much narrower: find the handler registration this run resolves for a foreach instance node (the graph executor's handler map, not the seam table), then flip the seam, delete the inline handoff, and update the three ratchets that will correctly fire — PR3's routing pin, the out-of-band adjacency check, and PR1's ownership ledger (`runImplementation` 3 → 2; `handleGraphFailure` 0 → 1 for custom graphs only). ## Verification - `executor-step-session` + exit-events + ownership ledger + graph-boundary — 56 tests green - `builtin-workflows` + `builtin-coding-workflow-ir` — green. The layout-completeness contract required a layout entry for the new node in all four stepwise-derived workflows; placed off the main line, because a park is an exit and not a stage. - `pnpm test:gate` green (10 / 309 / 71); `pnpm lint` clean; `tsc --noEmit` clean - Changeset included (`patch`, `internal`) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 09:54:39 -07:00
gsxdsm	67904f8a2c	U11: merge Todo into Planning on the default lineage (+ the migration mechanism, and a measured safety audit that cuts the work list 32%) (#2515 ) Merges Todo into Planning on the operator's real default workflow. Held from merge pending the `triage` literal audit below — see Gating. ## The board change `builtin:coding` → `BUILTIN_STEPWISE_FINAL_REVIEW_CODING_WORKFLOW_IR` → clones `BUILTIN_STEPWISE_CODING_WORKFLOW_IR`. That IR now declares five columns, and `plan`, `plan-review`, `plan-replan` and `start` all live in the merged Planning column: ``` columns: todo="Planning", in-progress, in-review, done, archived start -> todo plan -> todo plan-review -> todo plan-replan -> todo parse -> in-progress (first implementation node) ``` The id stays `todo`, the display name becomes "Planning". That is the cheaper half: `todo` was already the hold column, so every trait lookup, task row, stored selection and the 121 `column === "todo"` guards keep their meaning, and no stored row needs re-homing. Promoting `triage` instead would have produced the same board while making those guards workflow-dependent — live for Coding (Ideas), silently dead for Coding. `builtin:legacy-coding` keeps its six-column shape, per the operator's decision. It exists to be the old thing. ## Entry contract, before and after each IR edit \| \| result \| \|---\|---\| \| before the default-lineage edit \| 15 passed \| \| after the edit \| 13 passed, 2 failed \| \| after reading both \| 15 passed \| Neither failure was routed around. One was a genuine expectation change (two planning entry points became one); the other was my own `mergeTodoIntoPlanning` helper throwing "source IR is not the split-column shape this merge transforms" — because production is the merged shape now. I deleted the helper rather than making it tolerant: a transform that has silently become a no-op asserts nothing. ## The safety argument, proven not asserted Entering at `start` is exactly what dragged cards backward in the three earlier reverted attempts. `merged-planning-start-node-no-move.test.ts` proves against the real boundary controller and real default IR that entering `start` performs no move (`moveTask` is never called), reaches no hold→wip capacity seam, and still moves on a genuine crossing so the no-op is same-column rather than a disabled boundary. Removing the controller's same-column short-circuit turns exactly the two no-move tests red. ## The migration mechanism A card can outlive its column. `resolveAllowedColumns` derives targets from graph adjacency, and an undeclared source has none — so it returned `[]` and every move was rejected with "Valid targets: none", including the one that would rescue the card. An undeclared source now resolves to the workflow's rebound target. Escape hatch, not relaxation: declared columns are untouched, and it offers the rebound target only, so a stranded card gets back into the lifecycle rather than a free jump past review. ## A real regression this surfaced `isDefaultWorkflowColumns` matched the legacy six ids as a set. The merged default declares five, so the match stopped firing and the default board fell through to neighbor-only adjacency, which drops legal moves and invents an illegal one: \| edge \| effect \| \|---\|---\| \| `in-progress → done` \| dropped — the mission-validation cross edge \| \| `in-review → todo` \| dropped — review work back to planning \| \| `todo/done → archived` \| dropped — the FN-4892 direct-archival edges \| \| `done → in-review` \| invented — a backward edge no rule allows \| Adjacency now derives from lifecycle roles. The load-bearing assertion: the legacy six still reproduce `VALID_TRANSITIONS` verbatim. Applied only when a workflow declares the full role set, so custom boards keep neighbor adjacency. ## Failure accounting (core package, vs a 49-failure baseline) \| stage \| failed \| new \| \|---\|---:\|---:\| \| after the merge \| 65 \| 18 \| \| after the escape hatch \| 52 \| 5 \| \| after role-derived adjacency \| 53 \| 4 \| The 4 remaining are 3 `builtin-workflows` expectations encoding the pre-merge shape and 1 create-intake expectation naming `triage` on `builtin:coding`. Two `schema-applier` and two `workflow-reconciliation-production-shape` failures appeared in intermediate runs and are not mine — both files pass in isolation (75/75 and 7/7). I re-ran each before attributing them, which is why the earlier "priority" flag on the reconciliation pair was withdrawn. Gate: 309/309. Lint clean. ## Gating: the `triage` audit (`docs/solutions/architecture-patterns/u11-triage-literal-safety-audit.md`) Program tracking cited 58 `triage` comparisons. Measured with the same pattern: \| \| count \| \|---\|---:\| \| raw comparisons \| 87 \| \| inside comments \| 1 \| \| not a lifecycle column at all \| 15 \| \| column comparisons \| 71 \| \| OR-paired with `"todo"` in the same expression \| 32 \| \| exclusive `triage` — the real work list \| 39 \| 15 do not compare a column. `role === "triage"`, `surface === "triage"`, `sessionPurpose === "triage"`, `entry.agent === "triage"` name the planning agent. Converting them would be actively wrong, and the failure — a planning agent that can't resolve its prompt template — would look nothing like a column bug. One site changes an operator-visible affordance, which is why per-site review beat a sweep: `TaskCard.tsx:1927` — `taskColumnFlags?.intake === true && task.column !== "triage"`. The literal is a narrowing, not a match. After the merge a Planning card has `intake === true` and `column === "todo"`, so the narrowing stops applying and Start begins rendering on default Planning cards where it previously did not. A sweep would have "converted" the literal and shipped the new affordance silently. These guards do not go dead, they go workflow-dependent — `triage` stays live for legacy-coding, Ideas, every linear built-in and any user workflow (R11) — which is harder to detect than dead. Work list and ownership are in the audit doc. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 09:39:20 -07:00
gsxdsm	82baaa0b67	test(U9): give the FN-7720 "no fabricated verdict" invariant a real assertion (#2541 ) U9, PR6. Test-only, one file, no production change. Found while characterizing the reviewer lane (U9 is "review and merge"; PRs 1–5 covered merge). ## A test named for an invariant it does not assert `store-bypass-review.test.ts` has a case called "rewrites the failed step to skipped with bypass audit metadata and no fabricated verdict", containing `expect(result?.verdict).toBeUndefined()`. Its fixture sets `verdict: undefined`. The assertion is vacuous. Deleting `delete bypassed.verdict;` from `store.ts` leaves the whole suite green. Measured: `NEW-failures=0` across `store-bypass-review`, `task-merge-bypass`, `task-merge`, `legacy-adoption`. I explicitly confirmed the suite runs rather than skips — 9 tests via `pgDescribe` against the shared PG harness. A skipped suite produces exactly the same misleading zero, and that is the failure mode I hit earlier in this unit with a regex that matched nothing. ## Why it matters FN-7720 is explicit that a bypass writes status `skipped` and never fabricates a reviewer verdict. The invariant only has teeth when the failed step carries a verdict — which is the actual risk case: a reviewer says `REVISE`, an operator bypasses, and the verdict rides forward onto a `skipped` step. Every downstream reader then sees a reviewer verdict attached to a step no reviewer passed. The production code is correct. It was simply unasserted. ## The added case is two-sided With `verdict: "REVISE"` seeded, it asserts: - the bypassed step has no verdict (not carried forward), and - `bypassedFromVerdict` preserves `"REVISE"` (not silently lost from the audit trail) so it fails if the clear is removed and if the audit field is dropped. A one-sided version would pass against a bypass that simply discards all verdict history. \| Mutation \| NEW failures \| \|---\|---\| \| remove `delete bypassed.verdict` \| 1 — this test, and only it \| \| drop `bypassedFromVerdict` \| 1 — this test, and only it \| ## Reviewer-lane characterization so far By-name coverage search done first this time, per the lesson from #2520: \| Invariant \| Verdict \| \|---\|---\| \| FN-8492 orphaned pending results REWRITTEN to failed, never deleted \| covered — `legacy-adoption.test.ts`, NEW=2; one case is literally named "NEVER deletes an orphaned entry" \| \| FN-7720 bypass writes status `skipped` \| covered — NEW=1 \| \| FN-7720 bypass never fabricates a verdict \| was vacuous — fixed here \| Still to characterize, and stated rather than implied: review verdicts routing as graph outcomes, and provider-outage hold-in-place (no fabricated verdict on outage). Those are the next PR. ## Note on this shared checkout Earlier in this unit I used `git stash` to isolate a measurement and, because my tree was already committed-clean, the `pop` targeted the operator's stash entry. It failed safely on an untracked-file conflict and both entries are intact — but that was luck. I no longer use stash here; isolation is done by editing and restoring files directly, with `git status` asserted clean afterwards. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 09:35:54 -07:00
gsxdsm	f1be80420f	U12 part 9: make the raw-flag census a ratchet that fails when the last read goes — answer: 2 reads left, key cannot be deleted (#2537 ) ## U12 part 9 — the flag census now answers itself Independent of the #2530 rebase; adds one test file, no production changes. ## The answer, first: NO, the settings key cannot be deleted yet Three files reference the raw flag on current main (`3ff98aae5`): ``` packages/core/src/store.ts ← declares it packages/core/src/task-store/moves.ts:363 ← U2b: `useWorkflow` packages/core/src/task-store/workflow-task-create-ops.ts:351 ← U2b: move-policy preflight ``` Everything else that greps is a comment, a test writing the flag deliberately to reach the dead path, or the unrelated `workflowColumns.` i18n namespace for the Columns editor panel. Why I can't remove them.* Both are on the move path and belong to U2b, which carries an equivalence-proof obligation because the two move implementations it arbitrates have never both run in production. They are also not separable from each other: `workflow-task-create-ops.ts:351` computes the `movePolicyPreflight` that `moves.ts` consumes and validates, so un-gating it alone would start evaluating workflow move policies — with their plugin-gate side effects — while the branch consuming the result stays off. That is a behaviour change with no consumer, which is worse than either end state. U2b has not landed. Program history on main runs `#2466 → #2467 → #2468 → #2469 → #2479 → #2500 → #2512 → #2513 → #2525 → #2528 → #2535`. #2468 was Phase A2 steps 1–2 only — the differential characterisation. No convergence PR exists. ## Why this is a PR and not another status message You have asked this question three times. I have answered it three times by grepping, and each answer was a number nobody could re-derive later — including me, which is why I re-ran the audit from scratch each time. That is exactly the shape this program keeps finding: a fact everyone believes, maintained by nobody. So the census is now a test. It fails in both directions, deliberately: - A new read appears → someone re-gated behaviour on a flag that is `false` for every real project, so the feature behind it will not run. That is the defect class U12 spent its length finding (the capacity gate, the U5 guards, the move policies — all looked enforced, none were). - The last read disappears → U2b has landed, and the settings key can finally go. The removal steps are written at the assertion. The second case is the one that matters. It converts "remember to delete the settings key someday" into a failing test at the exact moment that becomes possible, instead of a note in a PR body that ages out. ## Verified in both directions, not assumed - Adding a reference in `lifecycle-ops.ts` → fails with `+ "packages/core/src/task-store/lifecycle-ops.ts"`. - Dropping `moves.ts` from the allowlist → fails with `+ "packages/core/src/task-store/moves.ts"`. Equality rather than subset is what makes the second case possible; a subset check would let the last reader vanish silently and leave the key orphaned forever. Two supporting assertions, both there because of failure modes this program has already hit: - No production code WRITES the key. That is the premise the entire unit rests on — if a writer appears, every "this branch is unreachable" conclusion in U12 needs revisiting. - The scan sees >200 files. A broken path glob would otherwise make every assertion vacuously green: a guard reporting success without checking anything. ## Verification `pnpm test:gate` (414 + 10 + 71), `pnpm lint`, `pnpm verify:fast`, core typecheck green. ## Standing offer If you want U12 actually closed rather than ratcheted, the remaining work is U2b's convergence. I have the inventory and the divergence list its characterisation suite does not yet cover (plugin column gates, the `transitionPending` marker, `workflowId` in `task:move` run-audit, move-policy preflight). I would want the current U2b worker stood down from `moves.ts` first — two writers on the file this whole program pivots on is the one hazard I would not take on my own authority. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Tests * Added a new automated Vitest “census ratchet” to ensure only an approved, fixed set of production reads is made for the workflow columns compatibility flag. * Added checks that disallow hardcoded `workflowColumns: true/false` assignments in production sources. * Added allowlist validation, including per-file occurrence counts, required rationale text length, and confirmation that referenced files exist. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 09:05:04 -07:00
Phil Larson	b85a5d4531	fix(core): bound compound engineering review remediation (#2532 ) ## Summary - cap Compound Engineering Code Review remediation at two Execute→Review repair passes - enable no-progress detection for the built-in CE workflow - preserve explicit project/workflow overrides while making the authored CE default visible in settings and docs - update stale IR/changeset language that still described Code Review as unbounded when unset ## Why The previous CE default was effectively unbounded. A reviewer that repeatedly returned `REVISE` could consume thousands of remediation cycles without terminally parking the task. The built-in workflow should fail closed after a small, explicit budget while still allowing operators to author a different numeric cap. ## Verification - `FUSION_PG_TEST_SKIP=1 corepack pnpm@10.33.0 --filter @fusion/core exec vitest run src/__tests__/builtin-workflows.test.ts` — 46 passed, 17 skipped - `corepack pnpm@10.33.0 --filter @fusion/core typecheck` - `corepack pnpm@10.33.0 --filter @fusion/dashboard exec vitest run app/components/__tests__/WorkflowSettingsPanel.test.tsx app/components/__tests__/workflow-setting-display.test.ts` — 33 passed - `corepack pnpm@10.33.0 --filter @fusion/dashboard typecheck` - `corepack pnpm@10.33.0 changeset status --since=origin/main` - `git diff --check origin/main...HEAD` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - Improvements - Compound Engineering Code Review now caps remediation attempts at 2; after two unsuccessful attempts, the process parks instead of retrying indefinitely. - Post-restart review recovery now completes in a single maintenance cycle to reduce delays. - Default post-review fix budget increased from 3 to 10. - Review revision limits now consistently honor workflow-authored defaults when settings are left empty, and `0` disables automatic remediation. - Documentation - Updated the workflow editor, settings reference, workflow steps, and operator panel text to clarify cap/default/disable semantics (including CE: 2). - Tests - Added/updated unit tests to validate the new bounded remediation behavior and messaging. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-29 00:05:29 -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	3ff98aae56	U12 part 8: delete the lossy normalizeColumn + behaviour ratchet — and the definitive answer on the raw flag (2 reads left, both U2b's) (#2535 ) ## U12 part 8 — deletes the lossy `normalizeColumn`, and ratchets it shut Independent of the #2525 → #2528 → #2530 stack; touches only `@fusion/core` exports. This closes one of the two `@deprecated (workflowColumns, U12)` markers the unit was named for. ### The hazard `normalizeColumn` coerced an arbitrary value to a legacy column, rewriting every workflow-defined custom id to `triage`. Silent data loss for any project whose workflow declares a column outside the six built-ins — and it sat one line away from `normalizeColumnId`, which sanitises structurally and passes real ids through. The dashboard picked the wrong one for its entire task-ingest path until that was diagnosed; `useTasks.ts` and `routes-trait-rekey.test.ts` still carry the notes from that fix. So this is not a hypothetical footgun — it already fired once, on the surface where it mattered most. Deleted rather than left deprecated because it has zero callers anywhere in the workspace. It was pure exported hazard: a lossy coercion next to its safe twin, waiting to be picked again. ### The ratchet is the point `no-lossy-column-coercion-export.test.ts` bans the behaviour, not the identifier: it walks every exported single-argument function whose name mentions "column" and fails if one maps a valid custom id onto a different legacy id. Re-adding `normalizeColumn` under any name trips it. Verified by actually reintroducing the function — two of the three cases fail, including the name-agnostic one. That last detail is what stops it being a guard that checks nothing. Coverage stated plainly: deleting an unused export has no behaviour to revert-check. The compile is the proof it had no callers; the ratchet is the proof it cannot return. --- ## Answering the standing question: does anything still read the raw `workflowColumns` flag? Yes. Exactly two sites, and both are U2b's. I am not able to close this out, and here is the complete list rather than a summary: ``` packages/core/src/store.ts:38,43 ← the definition packages/core/src/task-store/moves.ts:9,363 ← `useWorkflow` packages/core/src/task-store/workflow-task-create-ops.ts:11,351 ← move-policy preflight ``` That is the whole list in production code. Everything else that greps is a comment, a test that writes the flag deliberately to exercise the dead path, or the unrelated `workflowColumns.` i18n namespace for the Columns editor panel. Why I have not deleted the settings key.* It cannot go while those two read it — the key is what they read. And the two are not separable from each other: `workflow-task-create-ops.ts:351` computes the `movePolicyPreflight` that `moves.ts` consumes and validates, and un-gating the preflight alone would start evaluating workflow move policies (with their plugin-gate side effects) while the branch that consumes the result stays off. That is a behaviour change with no consumer, which is worse than either state. Status of the blocker. U2b has not landed. `main` at `919f68f9b` still has both reads; the program's merged history goes `#2466 → #2467 → #2468 (characterisation only) → #2469 → #2479 → #2500 → #2512 → #2513`, with no convergence PR. PR #2468 was Phase A2 steps 1–2 only — the differential characterisation — and the convergence that deletes one of the two move paths was never merged. So the honest state of the unit: everything U12 owns is done except the two reads that U2b owns, and the settings key that cannot be deleted until they are gone. If you want me to take U2b itself, say so — I have the inventory and the divergence list, and I would want the current U2b worker stood down from `moves.ts` first. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:23:25 -07:00
gsxdsm	18d654a5ff	capacity, part 3: delete the globalMaxConcurrent setting, API and UI (#2529 ) Part 3 of the capacity simplification, and the half that removes the knob. Enforcement (shared semaphore, runtime wiring) went in #2509; this removes everything an operator or API client can still see, so nothing is left readable-but-ignored. ## Deleted Settings key + schema default · CentralCore’s `getGlobalConcurrencyState` / `updateGlobalConcurrency` / `acquireGlobalSlot` / `releaseGlobalSlot` and the `concurrency:changed` event · the whole Global Concurrency block in `async-central-core` · `PUT /api/global-concurrency` · the Scheduling · Global settings section · the footer and Command Center global sliders · the dead `getGlobalConcurrencyLimit` reader whose only caller went in #2509. ## Kept, deliberately `GET /api/global-concurrency` survives as telemetry only — live `currentlyActive` / `projectsActive` from CentralCore’s side-effect-safe source. “How busy is this machine?” is still a real question once the cap that used to answer it is gone. It no longer reports `globalMaxConcurrent`/`queuedCount`: those came from the deleted cap and from slot bookkeeping production code never incremented, so publishing them was publishing zeros dressed as state. `useGlobalConcurrency` becomes read-only. Everything that existed to persist went with the cap — the 500 ms debounce, the save-state machine, the commit-on-close/unmount flush, the slider clamp, the `interactive` gate. The module-level shared store is kept: its original justification (two mounted consumers drift apart with private copies) holds for a polled read exactly as it did for a cap, and one fetch now serves both. The live “N running (all projects)” readout survives in both surfaces, moved onto the per-project row. ## Two sections become one Scheduling · Global existed to host exactly one control. With it deleted the section renders an empty pane, so the Global/Project pair merges back into “Scheduling”. An empty nav entry is a promise of settings that are not there. ## One real fix found on the way `SchedulingSection`’s `concurrencyLoading` gated the project concurrency inputs on the global-concurrency fetch — never the right source, since `maxConcurrent` and `maxWorktrees` come from the settings form. It is repointed at the form’s own load, preserving the invariant it existed for: a concurrency input stays disabled until its live value arrives, so an operator cannot overwrite a resolved limit with a blank fallback. ## Migration A stored `globalMaxConcurrent` is ignored — it is a project-blob key nothing reads, so dropping it needs no schema change. The `central.global_concurrency` table is dropped in a follow-up; this slice stops seeding and reading it first, so that drop has no live writer to race. ## Verification, and how the wider suite was controlled `pnpm lint` clean · core/engine/dashboard `tsc` clean · `pnpm test:gate` green (309 + 10 + 71) · dashboard settings/footer/command-center/hooks 2237/2237 · core `central-core-backend` 9/9. The broader dashboard suite shows failures, and I checked rather than assumed: running the suspect files on clean main reproduces `api-git` (49), `TaskDetailModal.rendering` (28) and `settings-mobile` (17) identically. Two were genuinely mine — `SettingsModal.scheduling-merge` (0 on main, 17 on this branch: my nav rename) and one `settings-mobile` picker case asserting `scheduling` is a scoped pair — and both are fixed. Tests for deleted behaviour are removed with it (footer confirm/cancel/flush/dedupe, global marker geometry, the hook’s PUT case, the CentralCore slot cases), each carrying a note on what it guarded and where the surviving project-side equivalent lives. Fixture-only references were updated, not deleted. Nothing booted. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:23:13 -07:00
gsxdsm	da0351857e	U12 part 5: put real workflow adjacency on the wire — custom-workflow move menus were guessing (measured), and the VALID_TRANSITIONS shortcut is gone (#2525 ) ## U12 part 5 — the move menu was guessing; now it asks the graph Stacks on #2521 (same file). Merge that first. The context menu had no adjacency data at all, so it did two wrong things at once: it approximated move targets from a column's neighbours in declared order, and — because that approximation is strictly weaker than the real graph — it kept a `VALID_TRANSITIONS` shortcut for any workflow whose column-id set matched the six built-ins. Measured, the approximation loses real operator moves: \| current \| workflow graph \| neighbour approximation \| \|---\|---\|---\| \| `in-progress` \| in-review, todo, triage, done \| todo, in-review \| \| `todo` \| in-progress, triage, archived \| triage, in-progress \| \| `done` \| todo, triage, archived \| in-review, archived \| So every custom workflow has been offering a guess: menu entries the store would reject, and legal moves it never offered. The built-ins were fine only because the shortcut bypassed the guess entirely. ### The fix `BoardWorkflowColumn` gains `moveTargets`, resolved by `resolveAllowedColumns` — the same resolver `moveTaskInternal` validates against. The menu now offers exactly what the store will accept, for any workflow. Threaded through all four metadata builders (Board, Lane, ListView, TaskDetailModal). Optional on the wire, deliberately: a client older than this field keeps the neighbour fallback rather than losing its move menu mid-upgrade. ### Why deleting the legacy shortcut is safe Not an assertion — a measurement, then a pin. `resolveAllowedColumns(BUILTIN_CODING_WORKFLOW_IR, c)` is identical to `VALID_TRANSITIONS[c]` for all six columns, order included: ``` triage ["todo","archived"] == VALID SAME todo ["in-progress","triage","archived"] == VALID SAME in-progress ["in-review","todo","triage","done"] == VALID SAME in-review ["done","in-progress","todo","triage"] == VALID SAME done ["todo","triage","archived"] == VALID SAME archived ["done"] == VALID SAME ``` `builtin-adjacency-matches-legacy-transitions.test.ts` pins it so the equivalence cannot drift silently — if the built-in workflow's edges change without `VALID_TRANSITIONS` following, default menus change shape and that test fails first. It compares order too, since the menu renders targets in the order it receives them, so a reorder is operator-visible. Default-workflow menus are therefore byte-identical. Custom ones stop guessing. ### What's left of the legacy vocabulary here `COLUMNS` is gone from `TaskContextMenu` — deleting the shortcut removed its last use. `VALID_TRANSITIONS` survives for exactly one thing: the no-metadata load window, documented at the site. I measured removing that in #2521 and it left Task Detail with no move options during load, which is a regression rather than a cleanup. It retires when the load window does. ### Revert-proof, two ways - Drop the `declaredTargets` branch → the custom-workflow case fails: the neighbour fallback returns `["backlog","building"]`, missing the legal `shipped` jump and offering `backlog`, which that graph forbids. That is exactly the defect class shipped to every custom workflow today. - A second case pins that an adjacency edge into a column the board cannot show is dropped, not rendered as a dead menu entry. ### Verification `pnpm test:gate` (309 + 10 + 71), `pnpm lint`, `pnpm verify:fast`, core + dashboard typechecks green. No new test failures: five suites report 31 failures with and without the change — an identical, pre-existing set, verified by diffing failing test names against a stashed clean tree, not by comparing counts. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Move menus for custom workflows now show only the destinations permitted by that workflow. * Task-specific workflow rules are applied consistently across boards, lists, lanes, and task details. * Invalid or unavailable destinations are excluded from move options. * Existing clients remain supported when workflow destination data is unavailable. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 23:23:00 -07:00
gsxdsm	5de083ef08	U8 PR4: declare the pending-review park as a graph node (inert) — and why the behavior move is blocked on the step-session chain (#2519 ) Fourth PR of U8 — the graph owns execution. This is the IR half of the pending-review routing move. Inert: no behavior change. The behavior half is deliberately NOT in this PR, for a measured reason below. ## What lands A `review-handoff` seam node (`review-pending-handoff`, column `in-review`) in `BUILTIN_CODING_WORKFLOW_IR`, with: ``` execute --outcome:review-pending--> review-pending-handoff --success--> end ``` An implementation session can end because a step is blocked on a pending review: the agent cannot continue, and the card belongs in review rather than in an error bucket (`status: failed` on an `in-review` row deadlocks the merge queue). Today the executor performs that transition inline, mid-session, and the graph finds out afterwards — which is why `handleGraphFailure` carries `alreadyFinalizedToReview`, a classifier whose only job is recognising a move the graph did not make. Two design points worth recording, both verified against the interpreter rather than assumed: - The edge goes to `end`, not to `review`. Routing to the ordinary `review` node would have continued the run into `merge-gate` and `merge-attempt` on work whose steps are incomplete. "Hand off and stop" is what the inline handoff does; the edge to `end` is what preserves it. - `outcome:` edges match on the node's VALUE and take priority over generic `success`/`failure` edges (`shouldTraverseEdge` / `traverseChildren`). So this claims only the pending-review ending, and a workflow that does not declare the edge falls through to its generic `failure` edge — exactly today's behavior. That is what makes the eventual move safe for user-authored graphs. ## Why the behavior half is not here — a measured finding I implemented it, and backed it out. The record matters more than the diff: 1. `BUILTIN_CODING_WORKFLOW_IR` is not the default workflow. It backs `builtin:legacy-coding`; `builtin:coding` uses the stepwise-final-review IR, which has no `execute` node — its implementation runs as a `foreach` of `step-execute`. 2. The foreach mechanism would work. `runForeach` propagates a failing instance's `value` up as the foreach node's own value, so a `steps` node could carry an `outcome:review-pending` edge. 3. But `stepExecute` flattens it first. The seam returns `value: result.outcome === "success" ? "step-done" : "step-failed"`, discarding the exit before it can reach any edge. So on the default workflow the exit cannot reach an edge, and a compat classifier in `handleGraphFailure` keyed on the failure value cannot see it either. Removing the inline handoff therefore regressed the default path: the card stopped reaching `in-review` at all. `executor-step-session.test.ts`'s FN-5436 case caught it — ``` FAIL FN-5436: pending-review skip on no-fn_task_done exit > parks in-review when review request has no subsequent verdict expected "moveTask" to be called with [ 'FN-5436-B', 'in-review' ] Number of calls: 0 ``` I could have made that green by relaxing the assertion. That would have been appeasement of a test that was telling the truth, so the behavior commit came out instead. Also caught, and worth noting as the ratchets earning their keep: the PR1 ownership ledger flagged the change as `runImplementation` 3 → 2 review handoffs and `handleGraphFailure` 0 → 1 — i.e. a relocation, not an elimination, for every non-plain-`execute` shape. That number is what turned "this move is good" into "this move is only good for one workflow shape". And PR3's routing-unchanged pin plus its out-of-band adjacency ratchet both fired, forcing the routing change to be declared rather than slipping in. ## PR5 Thread the implementation exit through the step-session chain (`runImplementationPhase` → `graphStepRunOnce` → `runGraphTaskStep` → `runProjectedGraphTaskStep` → `stepExecute`) so the seam can return `review-pending` instead of flattening to `step-failed`; add the node + edge to the stepwise IRs; then flip the execute seam and delete the inline handoff in one correct step for every built-in shape at once. The compat path for user-authored graphs is then a single named classifier rather than a call buried two thousand lines into a session loop. ## Verification - `builtin-coding-workflow-ir` + `builtin-workflows` — 76 tests green (the layout-completeness contract required a layout entry for the new node; it is placed off the main line because the park is an exit, not a stage) - `executor-step-session` + ownership ledger + exit events — 50 tests green, unchanged - `pnpm test:gate` green (309/10/71); `pnpm lint` clean - Changeset included (`patch`, `internal`) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 22:19: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	743df98aa4	capacity, part 1: merge pinned at 1, worktrees-off mode, and one dead knob deleted (#2502 ) First slice of the capacity simplification. Operator: "just have two capacity — overall per project agent count and max worktrees. Remove all other capacities and counts." Plus two later additions: merge is always 1, fixed, and worktrees off ⇒ limit by total agents only. Three independently revertable commits. No limiter is added anywhere; one is deleted, one is made structurally absent, and one is pinned. --- ## 1. Merge concurrency ratcheted at 1 (test-only) I was asked to add a limiter if merge concurrency could be raised. It cannot — there is no setting, workflow property, pool or trait config anywhere that raises it, so this adds no code and pins what already holds. Serialization lives in the pump: `drainMergeQueue`’s `mergeRunning` re-entrancy latch, `activeMergeTaskId` as a single-slot identity, the `mergeBodyInFlight` next-generation latch, and one `ProjectEngine` per projectId. Not in the merge-queue lease, which is a per-task ROW (`primaryKey [projectId, taskId]`) — two tasks can hold leases simultaneously by construction, and it has exactly one caller (the worktree-reuse handoff). Ordinary merges never take it. A lease-level test would have been describing an invariant that layer has never held. The second half guards the other direction: a merge-concurrency setting would not fail the pump ratchet — it would sit unread until someone wired it up. Revert-proof: deleting the latch → `expected 1 times, but got 2 times`; deleting the `finally` → latch-stuck; injecting `maxConcurrentMerges: 2` → fails naming the key; injecting a `maxParallelLanes` merge-trait field → fails naming the field. Sources restored byte-identical after each injection. ## 2. `worktreesEnabled` — off means the worktree limit cannot bind No worktrees-off mode existed (no `worktreesEnabled`/`useWorktrees`/`worktreeMode` anywhere — only worktree configuration). Why not `maxWorktrees: 0`, which needs no new key: it deadlocks. `?? 4` keeps `0` (not nullish), the gate is `used >= limit`, so `0 >= 0` holds on an empty board and nothing ever dispatches — while the operator-visible reason reads `gate=maxWorktrees; used=0/0`, a limiter that looks like it is working while the board is dead. It also needs the Command Center `{min:1}` clamp relaxed. So `0` costs the gate rewrite and the clamp change and encodes a mode as a magic value. Off is absence, not a big number. `resolveWorktreeCapacityLimit` returns `number \| null`; `ConcurrencyGateDiagnostic.maxWorktreesGate` is now optional, so consulting a worktree limit in OFF mode does not type-check. A gate holding `Infinity` can start binding again the moment someone "fixes" a comparison; an absent gate cannot. That paid for itself immediately: making it nullable surfaced a second, independent worktree gate (`activeWorktrees >= maxWorktrees` early-return) that a skip-by-convention approach would have missed silently. Scope, deliberately: this is a statement about counting, not isolation. It does not make concurrent agents safe to share one checkout and builds nothing toward that — the non-worktree paths that exist today are fallbacks to the operator’s own tree, one of which caused FN-8600. Revert-proof: a resolver ignoring the flag turns both OFF scheduler tests red while every ON test stays green — they reuse the same fixture (5 in-progress, limit 4) that pre-existing tests prove blocks, so the pair moves in opposite directions. Removing `disabled:` reddens the UI test. ## 3. `maxTriageConcurrent` deleted — it controlled nothing Measured: zero enforcement reads. The only `.maxTriageConcurrent` reference in the repo was a route echoing it back in `/config`. FN-8453 removed the pool it gated and left the knob shipping in `DEFAULT_SETTINGS`, the settings type, the section registry, the API response and six i18n catalogs, doing nothing, for releases. Historical FNXC comments are updated, not deleted — they explain a real past incident; they now say "planning admission slot" so they stop implying a live setting. Tombstoned so it cannot return. `/config` loses a field; safe in-repo since `fetchConfig`’s own return type never declared it. --- ## Two corrections worth recording - I earlier reported `maxWorktrees` had no Settings UI. Wrong — `WorktreesSection.tsx:47`; my grep was truncated by `head`. It changed the placement (toggle beside it, rather than a duplicate key in Scheduling). - I planned to assert the queued-reason string is rewritten in OFF mode. Measured that it is unreachable: when `maxConcurrent` binds, the sweep bails before the per-task reason and logs nothing. The test asserts absence instead. Two near-misses caught before commit: a pre-existing FN-7505 guard caught my new key missing a description mapping; and editing i18n via `json.load/dump` silently dropped unrelated duplicate keys (`autoUpdateAndRestart` in `fr`) — Python keeps only the last of a duplicated key. Redone textually, every catalog re-validated. ## Verification `pnpm lint` clean · core/engine/dashboard/i18n typecheck clean · `pnpm test:gate` green (309 + 10 + 71) · capacity/worktree suites 11/11 · engine merge-invariant + scheduler 45/45 · dashboard settings 114/114. Rebased onto current main and re-verified. Nothing was booted at any point. 🤖 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 * Added a project setting to enable or disable running tasks in worktrees. * Disabling worktrees removes worktree capacity limits from task scheduling. * The “Max Worktrees” setting is disabled when worktree execution is turned off. * Changes * Removed the unused triage concurrency setting from configuration and dashboard responses. * Updated scheduling diagnostics and queue messages to reflect disabled worktree capacity limits. * Added localized labels and help text for the new setting. <!-- 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:31 -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	9d3e53d0c5	U8 PR3: the implementation phase announces HOW it ended — including when the executor moved the card itself (#2507 ) Third PR of U8 — the graph owns execution. Independent of everything merged so far; small, green, revertable on its own. ## The problem this makes visible `result.taskDone` is the entire language the execute seam has for talking to the graph: ```ts if (result.taskDone) return { outcome: "success", value: "implemented" }; return { outcome: "failure", value: paused ? "implementation-paused" : "implementation-incomplete" }; ``` The endings that one bit cannot express are exactly the ones the implementation phase transitions itself: - a session that paused after the work was already complete → finalizes to review inline; - a session that stopped because a step is blocked on a pending review → hands off to review inline (a pending-review block is a wait, not a failure; marking it failed deadlocks a row that is both `in-review` and `failed`). The graph then sees `taskDone === false`, reports `implementation-incomplete`, and `handleGraphFailure` compensates with `alreadyFinalizedToReview` / `completionFinalized` — classifiers whose entire job is recognising a move the graph did not make. That was invisible. An out-of-band transition and a genuine implementation failure were indistinguishable in logs, in events, and in tests. You cannot remove a transition you cannot see, and you cannot prove you removed it either. ## What lands A closed `ImplementationExit` enum (`engine/executor/implementation-exit.ts`) reported from six completion-adjacent exits in `runImplementation`, announced by the execute seam as `NodeCompleted.exit` on the U3 lifecycle bus. Two ids are flagged as out-of-band — the ones where the executor, not the graph, performs the transition. Routing is unchanged, and that is the point. The seam returns byte-identically what it returned before for every exit, so this PR cannot move a card. The routing move needs new IR edges and lands separately; splitting them is what keeps both independently revertable. Per R5 an exit id is a reaction — nothing branches on one, and dropping every subscriber must change no outcome (a named U8 test scenario, asserted here). `NodeCompleted.exit` is added to the event key allow-list deliberately — which is exactly what that allow-list is for — and carries closed enum ids only, never prose. ## Revert-proofs, each observed failing \| Injected change \| Result \| \|---\|---\| \| Remove the emit entirely \| 6 failures \| \| Let an exit change the returned outcome \| 2 failures (the routing-unchanged pins) \| \| Delete one `reportImplementationExit(...)` call site \| 1 failure (the wiring ratchet) \| The third proof exists because of a hole I found in my own tests. These tests stub `runImplementationPhase` — the only way to reach all six exits deterministically — which means deleting a real call site left the entire file green. A stubbed seam can only prove the seam. I'd also written "every exit is reported — the signal is real, not a placeholder" in the header, which the tests did not support. Both are fixed: there is now a ratchet asserting every enum id is wired at a real call site and that each out-of-band id sits adjacent to the handoff it describes, and the header says what the tests actually prove. ## Scope 6 of `runImplementation`'s ~28 dispositions (per the ownership ledger merged in #2490), chosen as the ones the routing move needs. The remaining ~22 report nothing yet — the ledger, not this enum, stays the record of that gap, and the module says so. ## Verification - 15 new tests + ledger + graph-boundary + task-done-blocked + graph-requeue-gate + step-session + review-verdicts + tool-failure-retry — 9 files, 115 tests green - `@fusion/core` `workflow-events` — 20 tests green (allow-list change covered) - `pnpm test:gate` green (17/307, 2/10, 1/71); `pnpm lint` clean; `tsc --noEmit` clean on both packages - Changeset included (`patch`, `internal`), passes `check:changesets` ## Next PR4 is the routing move itself: `review-handoff-pending-review` becomes a graph outcome with its own IR edge, and `alreadyFinalizedToReview` becomes provably unreachable for that path. The IR edge change will be its own commit, separate from the seam change. 🤖 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:07 -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	0021bd363e	U4: retire the surfacing family onto one policy-driven runner (measured: trim is ~34% of the estimate) (#2487 ) Stacked on #2486. Base is `feature/u4-safeguard-scoped-to-mutation` — do not merge before it. Retires the surfacing family — `surfaceStalePausedTodos`, `surfaceStalePausedReviews`, `surfaceInReviewStalled` — onto one policy-driven runner. Migrated together, because they were three copies of one skeleton and a fix applied to one had to be remembered for the other two. #2484's characterization suite is the regression floor and passes unchanged. ## Two unconverted sites found in core Without these the migration would have been cosmetic for two of the three: `getStalePausedReviewSignal` and `getInReviewStalledSignal` both hardcoded `task.column !== "in-review"`. `getStalePausedTodoSignal` gained the equivalent `holdColumn` parameter back in B1 — its two siblings were missed, so they silently stopped matching for any workflow that renames its review column. Both now take `reviewColumn`, defaulting to the legacy id. ## Three bugs this work introduced, and the tests caught Each was silent in the diff: 1. I dropped the engine activation floor from all three signal calls. Wall-clock the engine wasn't running for is not quiet time, so every sweep would have reported cards as stale purely because the engine restarted. Caught by the pre-existing suite — not by my own characterization floor, which is exactly why that floor wasn't sufficient alone. 2. I passed `task.column` as the role column, making the signal's own column check compare a value against itself — tautologically true, so the check was silently deleted. The resolved role column is now passed. 3. The role gate was conditional on the role resolving, so it was silently absent for exactly the workflows whose role failed to resolve. Now unconditional, with the legacy id as fallback. ## The shared test is a table One row per sweep; every invariant asserted for all three — threshold inheritance, declared-policy override, renamed role column, the negative case outside the role column, at-most-once, activation floor, both pause gates, non-positive-threshold disable, soft-delete. Adding a fourth surfacing sweep means adding a row. Its log mock appends to the card's log, because the at-most-once dedup reads that log — a call-recording mock cannot observe suppression at all. ## Measured line delta — this corrects the survey estimate downward \| \| lines \| \|---\|---:\| \| `self-healing.ts` \| −192 / +95 = −97 \| \| new runner file \| +209 \| \| core signal conversions \| +23 \| \| NET \| +135 \| Three sweeps migrated increased total lines by 135 while shrinking `self-healing.ts` by 97. Per sweep: −32 in `self-healing.ts`. Break-even is 6.5 sweeps. Extrapolated to all 34 POLICY sweeps: −1,099 in `self-healing.ts`, −890 net once the runner is amortized. My survey estimated −2,612 for that bucket. The measured figure is 34% of it. The reconciler's size was never the issue — the estimate assumed per-sweep bodies collapse to almost nothing, and they do not: each keeps a real eligibility predicate, signal call, and operator message. ## Verification - 33 shared-family tests green - 471 passed across five engine suites, with the single known pre-existing `archiveStaleDoneTasks` failure - 44 core signal tests green - tsc clean in core and engine; lint clean; merge gate green (299 + 10 + 71) No changeset: `@fusion/core` and `@fusion/engine` are private. 🤖 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 - Added support for overriding which workflow column is treated as the relevant “in review” column for stale-paused and stalled-review surfacing. - Bug Fixes - Tightened safety safeguards so only lifecycle-mutating recovery actions are blocked when a card is user-paused; observational surfacing remains allowed. - Improved surfacing consistency across stale paused todos, stale paused reviews, and in-review stalled cases, including stronger deduping and cycle-aware behavior. - Tests - Expanded and reworked safety and surfacing “family” coverage to verify the new invariants. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-27 19:49:05 -07:00
gsxdsm	89284df85e	E2E: table-driven converted-sweep coverage, two new sites, and an honest unproven-sites ledger (#2485 ) Follow-up to #2475 (merged). Test-only, plus one test-utility seam. ## Why a table #2475 proved one converted sweep. The count has since gone to three, twice while this work was open — `surfaceStalePausedTodos` appeared during #2475's review, and #2478 landed `recovery-reconciler.ts` while this branch was open. A suite with a bespoke `describe` per sweep is a coverage claim that quietly becomes false. Replaced with a table of `(seed, run, acted, roles, observability)`. The driver derives four assertions per entry: \| \| positive \| negative \| \|---\|---\|---\| \| renamed vocabulary \| acts on the card \| inert in a non-target column \| \| default vocabulary \| acts (regression floor) \| inert \| Adding a converted sweep is one entry — the #2478 site proved that in practice, not in principle. `actsOnRole`/`inertRole` are keys of `Vocabulary`, not column strings, so an entry cannot hardcode `todo` and pass for the wrong reason. ## Two findings, both from mutation rather than reading 1. The census was wrong about `recovery-reconciler.ts:198.` It was flagged as a `resolveLifecycleColumns` site, so the row was first labelled as covering it. Destroying that role resolution leaves all 18 tests green — `decideRecovery` looks policy up by column id and never consults a role. The row is relabelled to what it actually proves, and mutation-verified against that instead: keying the reconciler's policy lookup on the `todo` literal fails exactly its renamed test. 2. `resolveRoleRecovery` is an unreachable export. It is the only use of `resolveLifecycleColumns` in that file and has no production caller anywhere in engine, core, or dashboard. So that census line is not a live converted site — it is a helper written ahead of its consumer. Not fixed here: it is production code owned by the U4 slice, and whether the consumer is still to land or it should be deleted is its author's call. ## Observability is now explicit in the type `persisted-row` is the strong form. `returned-decision` is recorded as weaker evidence and the reconciler row uses it, because `reconcileRecovery` decides and does not apply — there is no row to read. Naming it in the type is what stops a return-value assertion from quietly passing as observed state, and it is what keeps the ledger truthful per site. ## Harness seam `PgTestHarness` now exposes its raw admin SQL client. The store stamps `updatedAt`/`columnMovedAt` on every write, so `updateTask` cannot express an aged row at all — the patch is accepted and the value silently replaced with `now`. Found by the new case failing on BOTH vocabularies, which is what distinguishes a broken fixture from a broken guard. Seeding only; assertions still read back through the real `getTask` path. ## Mutation verification \| Mutation \| Result \| \|---\|---\| \| revert only `recoverStrandedCompletedTodoTasks`'s resolution \| exactly that row's renamed test fails \| \| revert only `surfaceStalePausedTodos`'s resolution \| exactly its own renamed test fails \| \| reconciler policy lookup keyed on `todo` \| exactly the reconciler row's renamed test fails \| \| `resolveRoleRecovery` role resolution destroyed \| nothing fails → finding #2 \| \| `hold-release` `isHeldTask` keyed on `todo` \| 5 of 18 fail; default spine survives \| \| `markMoveInFlight` dropped \| both spine tests fail \| Per-site verification matters here: three rows could all be riding one guard. They are not. ## The honest number Proven end to end: 5 (two self-healing sweeps, the reconciler's policy lookup at the weaker observability, hold-release's capacity release, and the graph boundary + `moveTask` + post-commit bus). Not proven: 11 call sites — `merger.ts:324-326`, `merger-ai.ts:1022,1039`, `auto-merge-finalization.ts:20-22`, `executor.ts:1763,6339,6341`, `self-healing.ts:713,6732`, `mesh-lease-manager.ts:61`, `task-agent-sync.ts:59`, `core/task-store/reads.ts:130`, `core/live-agent-count.ts:63-75`, and four dashboard route sites. The ledger lives in the file, not just here, so it stays with the code. ## Where the table does not fit — reported, not papered over The merge/rebound family cannot be a table row: those sweeps have no observable persisted effect without a real git repository, so `acted` cannot be written against the row at all. They need an engine-slow real-git lane. The dashboard sites need an HTTP route test with a live store. Both are different lanes, not missing entries. ## Verification - 18/18 green; engine + core `tsc --noEmit` clean; `pnpm test:gate` green (299 + 10 + 71) - full core PG suite run (the harness is shared): 1036 passed, 3 failed in `central-archive-secrets` and `workflow-settings-project-identity` — reproduce identically with this change stashed, pre-existing 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 15:25:17 -07:00
gsxdsm	b133d521c4	U4 vertical slice: recovery-policy reconciler + ratified safety invariant (measured: engine ~780, real cost is a settings migration) (#2478 ) Stacked on #2477. Base is `feature/workflow-vocabulary-u4-delete-dep-blocked` — do not merge before it. The smallest end-to-end slice of the U4 reshape, built to measure the real cost before committing to the full policy table. The survey's ~900-line reconciler figure was reasoned, not prototyped; this replaces it with numbers. Everything here is additive and unwired. No behavior changes. ## What lands \| \| lines \| what \| \|---\|---:\|---\| \| `WorkflowColumnRecovery` (IR) \| 42 \| one key — `stalenessMs` + `onStale`. Optional and omitted when unset, so existing workflows serialize byte-identically. \| \| `recovery-reconciler.ts` \| 176 \| one engine: walks live cards, resolves each card's policy from its own workflow (per task, shared `irCache` — a 400-card board across three workflows reads three IRs), returns decisions. Decision and application are separate so the safety boundary is assertable without running an engine. \| \| `recovery-policy-safety.test.ts` \| 156 \| one-time. The ratified invariant. \| ## Measured cost vs the ~900 estimate Engine + IR types = 222 lines for one action (`surface`) and one safeguard. Extrapolating the rest — `rebound` (target resolution, attempt budgets, backward-move proof, five more safeguards) ≈ +350, `archive` ≈ +50, the `budgets`/`dependencies` keys ≈ +150 — lands near 780. So ~900 was a good estimate for the engine, and the vertical slice does not move it much. That is the answer to the question asked. ## But the estimate's real miss is not lines 16 of the 34 POLICY sweeps read an operator setting today — ~17 distinct policy-threshold keys, including `stalePausedTodoThresholdMs`, `inReviewStalledThresholdMs`, `taskStuckTimeoutMs`, `doneAutoArchiveDays`, `maxPostReviewFixes`. Moving those sweeps into workflow policy is not a code refactor — it is a settings migration with operator-visible blast radius, and it needs three decisions the line estimate never surfaced: 1. Does workflow policy override the global setting, or defer to it? 2. What happens to existing projects that already configured those settings? 3. Does an unset policy inherit the setting, or the built-in default? That is the gating question for the full table — not the reconciler's size. ## Why the sweep is not retired here Retiring `surfaceStalePausedTodos` requires builtin:coding to declare the policy and `stalePausedTodoThresholdMs` to migrate — or the behavior silently disappears for every existing project. That is the settings migration above, and it belongs behind its own decision rather than smuggled into a measurement slice. The reconciler is therefore unwired — deliberately dead code, for exactly as long as it takes to get that decision. ## The ratified safety invariant The six safeguards (user pause, `autoMerge:false`, dependency, capacity, merge-proof, at-most-once) live outside the policy table. A workflow must never be able to author a safety invariant away. Encoded two ways, because either alone is defeatable: - structural — the policy exposes only an allow-listed key set; adding a key requires editing the test and re-stating the safety argument (the friction is the point); - behavioral — a policy attempting every spelling of "ignore the user pause" has no effect. Both halves mutation-verified, because a safety test that cannot fail is worse than none: - making the reconciler honor a policy field that disables the user-pause safeguard → fails - adding an unreviewed key to the policy schema → fails A third test asserts the reconciler still acts on an unpaused card, so a reconciler that suppressed everything cannot pass by doing nothing. ## Scope limits stated rather than implied Only the `surface` action is implemented, so only its relevant safeguard is wired. `surface` mutates no lifecycle state; the other five gate lifecycle-mutating actions that do not exist yet, and wiring them now would be untestable dead code. A test records this so the absence reads as deliberate and must be updated when `rebound` lands. ## Verification - `tsc --noEmit` clean in core and engine; `pnpm lint` clean - merge gate green (299 + 10 + 71) - 23 safety tests green; `workflow-lifecycle-traits` green No changeset: `@fusion/core` and `@fusion/engine` are private. 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-07-27 15:06:19 -07:00
gsxdsm	710d56b2db	U4 trim: delete the dependency-blocked-todo feature (unreachable in production) and revert 5a2de7d (#2477 ) Stacked on #2474. Base is `feature/workflow-vocabulary-u4-dead-code` — do not merge before it. Deletes an entire feature that has never executed in production, and reverts `5a2de7d`, which only threaded resolved lifecycle columns through it. ## Reachability evidence — the whole basis for this ``` surfaceDependencyBlockedTodos ← in NEITHER sweep registry; no caller in └─ getDependencyBlockedTodoReporter() engine/dashboard/cli — only tests └─ engine/dependency-blocked-todo-reporter.ts ← sole caller of ↓ └─ core/computeDependencyBlockedTodoReport ``` self-healing owns two name-based sweep registries (`runStartupRecovery`, 58 entries; `runMaintenance`, 76). `surfaceDependencyBlockedTodos` is in neither, so nothing ever invoked the chain below it. Its four tests passed while proving nothing about production. ## Why delete rather than wire it up Wiring was the tempting option and is the riskier one. Switching on a 450-line path that has never run — whose tests therefore establish nothing about its behavior against real data — is a behavior change with unquantified blast radius. This program already refused exactly that move for the pool-id sentinel, a one-line change that would switch on dormant enforcement across every project. This is the same class of move at ~450× the size. Deleting is also the recoverable direction: git keeps the feature, and it can be resurrected deliberately — with tests that prove it runs — if dependency-blocked reporting is actually wanted. ## The settings keys go with it `dependencyBlockedTodoReportEnabled` defaulted `true` while driving nothing. A schema/API-visible switch that lies about what the system does is worse than no switch. (It had no dashboard UI field — the dashboard test allowlist already recorded it as "no UI field".) Four sibling tuning keys are removed with it. ## Against my own earlier work `5a2de7d` threaded resolved lifecycle roles into `computeDependencyBlockedTodoReport` and its reporter, answering a review finding I confirmed as real. The code was correct; the impact claim was not, because the path never executes. Neither the reviewer nor I checked reachability before agreeing the defect mattered — only correctness. A correction is posted on that thread in #2470. Scope limit on that admission: the same finding also described incorrect scheduler ordering. That half runs through `buildUnblockWeightMap` in `task-priority.ts`, which is live and was already threading `terminalColumns` (B1, `434b385`). Scheduler ordering was never affected, before or after. ## What survives `blocker-fanout.ts` stays — it is live via `task-priority.ts`. Only the plural `holdColumns` option added by `5a2de7d` is reverted, since the deleted report was its sole consumer. `holdColumn` (singular, from B1) remains. ## Net 1,244 deletions / 5 insertions across 15 files — ~450 production lines, ~684 test lines, 5 settings keys. ## Verification - `tsc --noEmit` clean in core, engine, and dashboard-app; `pnpm lint` clean - merge gate green (299 + 10 + 71) - self-healing suite: 411 passed, 1 pre-existing failure (`archiveStaleDoneTasks`) - dashboard settings-descriptions suite green - `settings-parity.test.ts` has one pre-existing failure (`agentToolOutputMaxChars` overlap) that fails identically with these changes stashed — unrelated to this deletion No changeset: `@fusion/core` and `@fusion/engine` are private. 🤖 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 * Added quiet-window backlog health diagnostics for stalled items in review, with repeat-alert suppression. * Added default thresholds for backlog-pressure alerts. * Changes * Removed dependency-blocked todo reporting and related alerts. * Removed the dependency-blocked todo enable/disable setting; remaining tuning options are no longer active. * Updated the workflow hold classification to use a single todo column. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-27 14:54:32 -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	553cc3b517	Phase A3: the in-txn capacity invariant does NOT hold — root-caused, ratcheted, not fixed (#2469 ) Stacked on #2468, which is stacked on #2467. Base is `feature/workflow-move-path-convergence`. Answer: the A2 observation was real. The documented invariant is broken. Not a false alarm, not a harness artifact. `workflow-capacity.ts` states enforcement "runs INSIDE `moveTaskInternal`'s transaction and is NEVER bypassable (not a guard — runs regardless of bypassGuards/recoveryRehome/moveSource)". It does not hold for default-workflow tasks, for two independent reasons. ## R1 — Pool-id sentinel mismatch (the defect) \| Site \| Sentinel for "no workflow selection" \| \|---\|---\| \| `moves.ts:319` (in-txn check, asks) \| `?? "builtin:coding"` \| \| `countActiveInCapacitySlotAsyncImpl` (answers) \| `?? DEFAULT_WORKFLOW_POOL_ID` → `"__default-workflow__"` \| \| `hold-release.ts:116` (sweep, second enforcement point) \| `?? DEFAULT_WORKFLOW_POOL_ID` ✅ \| The check asks for occupants of a pool that no occupant is ever bucketed into, so the count comes back `0` and the limit can never bind. The sweep is correct, so the two enforcement points disagree about pool identity — precisely what the module docstring says is impossible ("the two enforcement points can never disagree on what a limit is, only on the live count"). Note the shape of the bug: it is not a missing check. The check runs, queries correctly, and returns a confidently wrong answer. ## R2 — The `useWorkflow` gate The whole block sits inside `if (useWorkflow && workflowIr && fromColumn !== toColumn)` (`moves.ts:921`), and `useWorkflow` reads the raw `experimentalFeatures.workflowColumns` key nothing in production sets. On the live path the check cannot run at all, so R1 is latent today and becomes reachable the moment A2 converges onto the flag-ON side. ## How this was established, not guessed Three of my assumptions failed earlier in this program, so this one is pinned by a discriminating experiment rather than a code reading: \| Case \| Path \| Selection \| Result \| \|---\|---\|---\|---\| \| DEFECT (R2) \| inline (live) \| none \| accepted — check cannot run \| \| DEFECT (R1) \| hooks \| none \| accepted — sentinels disagree \| \| DISCRIMINATOR \| hooks \| explicit `builtin:coding` \| refused, `capacity-exhausted` \| The third case changes nothing but sentinel agreement. That rules out "capacity is simply not wired" and isolates the cause to the mismatch. Both-path forcing reuses A2's `assertPathActive` probe. Without it this suite would silently run one path twice and report a tautology — the failure mode that produced sixteen false passes across A2's two harness bugs. ## The deliverable: an invariant ratchet The three cases above assert today's wrong behavior, so on their own they would let the defect live forever. A fourth case states the invariant as written and is marked `it.fails`: - today — the body fails, so `it.fails` passes; CI stays green while honestly recording the breach; - when fixed — the body passes, `it.fails` fails, forcing whoever lands the fix to flip it and the two `DEFECT:` expectations. That is "a test that fails if the invariant is broken" in the only shape that does not park a permanently-red test in CI. ## Blast radius (step 4) — why I did not fix it The fix is one line: make `moves.ts:319` use `DEFAULT_WORKFLOW_POOL_ID`, matching the sweep. The consequences are not one line. Today: zero. `useWorkflow` is false everywhere, so the corrected check still cannot run on the live path. The sentinel fix is safe to land in isolation. At A2 convergence: every default-workflow task move into `in-progress` becomes capacity-checked against `maxConcurrent` (default 2), for the first time. Affected movers: - The graph column boundary catches `capacity-exhausted` and parks the run. Runs that previously proceeded would begin suspending — this is a scheduling behavior change across every project, not an error path. - `executor.ts`, `project-engine.ts`, `pr-comment-handler.ts` each move tasks into `in-progress` and would begin seeing a rejection they have never seen. - Operator drags and the promote route would start refusing beyond `maxConcurrent`. Scheduler-side admission (`maxConcurrent`) is a separate, still-live control, so this is not "capacity is unenforced today" — it is "the store-level check the graph and promote paths are written against returns 0 and never binds". Recommendation: land the sentinel fix on its own (provably inert today), with the ratchet flipped in the same commit, before A2 convergence — so convergence does not simultaneously switch paths and switch on a previously-dead enforcement. ## Verification 4 cases green against real PostgreSQL (3 passed + 1 expected-fail), path flip proven live on every case. `pnpm lint` and `tsc --noEmit` green. ## Follow-up: both "not verified" items are now answered Recorded here rather than left as open questions, since this is where anyone investigating capacity will look. 1. Does the sync/SQLite counter carry the same mismatch? — YES, identically, but it is unreachable. `countActiveInCapacitySlotSyncImpl` (`project-store-ops.ts:767`) buckets rows the same way as the async one: ```ts const effectiveWorkflowId = row.wid ?? TaskStore.DEFAULT_WORKFLOW_POOL_ID; ``` So it disagrees with `moves.ts:319` in exactly the same way. However its only caller is the public `TaskStore.countActiveInCapacitySlotSync` wrapper, which has no in-repo caller at all — it is dead API surface. The mismatch is real but currently unreachable, which makes it a landmine for whoever wires it up rather than an active defect. Fixing the sentinel should fix both call sites together. 2. Are custom workflows with an explicit numeric `limit` affected? — NO, and this is already proven by the discriminator above. The mismatch fires only when the selection row is absent — that is what the `??` fallback is for. A custom workflow necessarily has a selection row; that is what makes it custom. The DISCRIMINATOR case adds an explicit selection and the rejection appears, which is exactly the custom-workflow shape. So the defect is scoped to no-selection (default-workflow) tasks only. The explicit-numeric-`limit` question turns out to be orthogonal: `resolveColumnBudgetKey` returning `col:${columnId}` decides which columns share a budget, not which pool id is passed to the counter. It does not interact with the sentinel at all. Net effect on blast radius: narrower than first stated. Only default-workflow (no-selection) tasks slip the limit today. Custom-workflow tasks are already enforced — meaning the fix does not switch enforcement on for them, it only closes the gap for the default workflow. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Tests * Added coverage for workflow column capacity enforcement during transactions. * Documented scenarios where capacity limits are bypassed, including tasks without workflow selection. * Verified that explicit workflow selection correctly rejects moves when capacity is exhausted. * Added a tracked failing test for the expected invariant once enforcement is corrected. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-27 13:59:56 -07:00
gsxdsm	b941d3cba5	Phase A2 (steps 1-2): differential characterization of the two move paths (#2468 ) Stacked on #2467 (base is `feature/workflow-owned-lifecycle`, not `main`). Phase A2 steps 1 and 2. Step 3 — make one path authoritative and delete the other — is NOT done. It is blocked on a measured divergence, escalated to the operator. This PR is the evidence that decision needs. ## The setup `moves.ts` branches on `useWorkflow = isWorkflowColumnsCompatibilityFlagEnabled(settings)`, which reads the raw `experimentalFeatures.workflowColumns` key. Nothing in production writes it, so the inline branch is LIVE and `default-workflow-hooks.ts` is DEAD. Because only one implementation runs, equivalence cannot be observed by running the suite normally — the dead path is never entered. Every case here forces both paths explicitly through one shared fixture and compares a 19-field observation, not "it moved". ## Step 1-2 result: side-effect equivalence is PROVEN Eight behaviors, field-by-field identical across both paths: \| Behavior \| Verdict \| \|---\|---\| \| `in-progress → todo` user reopen field clears \| equivalent \| \| Engine-source reopen does not set `userPaused` \| equivalent \| \| `preserveStatus` keeps status/error \| equivalent \| \| `preservePause` keeps an operator park (FN-7851) \| equivalent \| \| Timing / `cumulativeActiveMs` across exit and re-entry \| equivalent \| \| `preserveResumeState` step progress \| equivalent \| \| `preserveWorktree` \| equivalent \| \| Default worktree clear on reopen \| equivalent \| ### Why this is a proof and not a green suite Two independent guards, both of which caught a real silent failure in this PR's own development: - The forcing mechanism is self-checked. `assertPathActive` probes an undeclared target column — whose rejection message differs per path — before every case. The first version of this suite wrote the flag with `updateSettings` instead of `updateGlobalSettings` (`experimentalFeatures` is global-scoped, which is exactly why `moves.ts` reads it through `getSettingsFast()`), and reported nine passing "equivalence" cases while running the inline path twice. The check then caught a second failure: `updateGlobalSettings` merges, so resetting with `{}` left a previous `true` in place and leaked the hooks path into seven cases that believed they were on inline. - The suite is mutation-tested. Deleting `task.blockedBy = undefined` from `applyResetOnEntryEffects` fails the reopen case, naming the field. Restored before commit. Timestamps are compared by presence rather than value — the two runs happen at different wall-clock instants by construction — but a path that forgets to stamp `executionCompletedAt`, or wrongly clears `firstExecutionAt`, still fails. ## ⚠️ Read this before writing any both-paths test A differential harness that cannot prove which path it is on will report a tautology, confidently, and in green. This suite hit that twice in one afternoon: 1. Global-scoped key written to project scope. The first version set the flag with `updateSettings`. `experimentalFeatures` is global-scoped — which is exactly why `moves.ts` reads it through `getSettingsFast()` (merged global + project). The write was silently accepted and never reached `useWorkflow`. Result: nine passing "equivalence" cases while running the inline path twice. 2. Merge-on-write leaking a stale `true`. `updateGlobalSettings` merges, so resetting with `{ experimentalFeatures: {} }` left the previous `workflowColumns: true` in place. Result: the hooks path leaked into seven cases that believed they were on inline. Neither failure produced a red test. Both were caught only by `assertPathActive` — a per-case probe that moves a task to an undeclared column and asserts on the rejection message, which differs per path (`Valid targets: …` inline vs `Unknown column for this workflow` on hooks). This is the same failure class as a spy passing on a refused payload (see #2467): the observation confirms the assumption instead of the behavior. The rule that generalizes: > When a test forces a code path, assert that the path is active using a signal only that path can produce — before every case, not once in setup. A forcing mechanism that can fail silently makes every assertion downstream worthless. Any future work touching both move paths needs this probe or it will get a confident wrong answer. ## Why step 3 is blocked ### Divergence: rejection type and message \| \| Inline (live) \| Hooks (dead) \| \|---\|---\|---\| \| Validates against \| legacy `VALID_TRANSITIONS` \| the task's own workflow \| \| Throws \| bare `Error` \| `TransitionRejectionError` with a machine-readable `rejection` \| \| Message \| `Valid targets: …` \| `Unknown column for this workflow` \| Both reject, so neither is "broken" — but they are not interchangeable. Making either authoritative changes what every catch site observes, including the flag-OFF characterization suite that pins the bare-Error contract and the callers that branch on `rejection.code`. ### Unproven, recorded as an honest negative: in-transaction capacity The capacity block sits inside `if (useWorkflow && workflowIr && fromColumn !== toColumn)`, so it cannot run on the live path. The natural inference is "convergence turns store-level capacity rejection on for every project at once" — a serious blast radius, since `capacity-exhausted` is what the graph column boundary parks on and what the promote route surfaces to operators. That inference did not survive measurement. With `maxConcurrent: 1` and an already-occupied wip column, the second move was accepted on both paths. Something further in — `resolveColumnCapacity`'s limit resolution, or what `countActiveInCapacitySlotAsync` counts as an occupant — keeps the check from firing even flag-on. This suite does not establish which. So the capacity blast radius is unquantified, not absent. The test pins today's observed behavior so the investigation starts from a fact rather than from the code reading; if a future change makes it reject, that failure is the signal to reopen the question. ## Verification - 10/10 green against real PostgreSQL, with the path flip proven live by `assertPathActive` on every case. - Mutation-tested (see above). - `pnpm lint` and `tsc --noEmit` (core) green. Not verified: whether the capacity gate would activate under some other configuration; the plugin column-gate and post-commit plugin-hook divergences (also inside the `useWorkflow` gate) are identified structurally but not characterized here. 🤖 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 updates now provide more consistent task state notifications and workflow activity handling. * Task lists display resolved workflow column names and lifecycle details more reliably. * Bug Fixes * Workflow-based task promotion and board views no longer depend on an obsolete feature setting. * Improved recovery for tasks left in transitional states. * Preserved task status, pause, progress, timing, and worktree behavior across workflow transitions. * Reliability * Added stronger validation and durable handling for workflow events and follow-up processing. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-27 13:49:55 -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	99c9f14ee0	feat: run Plan Review in the planning lane with a Plan Review badge (#2462 ) ## What Plan Review, planning, and the replan loop move from the implementation column into the planning lane (`todo`), so a task under specification never holds a WIP slot. The card crosses into `in-progress` exactly once, at `parse`, released by the scheduler. Operators also finally see a Plan Review badge while the gate runs — it was previously invisible on the default workflow. ## The part that made it possible Moving the node is ten lines. It was attempted three times and reverted each time, because a graph run with no durable continuation replayed from `start` and dragged an in-progress card backward out of the WIP column, firing `abort-on-exit` and stranding it in a pre-WIP column with no releaser. So this PR adds the graph entry contract — `resolveColumnResumeNode`: \| Card is in \| Resumes at \| \|---\|---\| \| `triage` \| `start` \| \| `todo` \| `plan` \| \| `in-progress` \| `parse` — never re-plans, never moves backward \| \| `in-review` \| first review node — gates are not skipped \| `ir.columns` is ordered and that order is the lifecycle order; rework and failure edges are excluded so the entry point is always the main path. The proof it's the right fix: `executor-task-done-invariant` passes unmodified after failing every previous attempt. ## Also in here - Release gate narrowed twice. `isUnplannedForExecution` applies its pre-release plan-review gate only when the node's column equals the card's column and the group is enabled for the task. The enablement check fixes a real deadlock — a task with Plan Review toggled off was held forever waiting for evidence nothing would ever write. - Badge cleanup. Gate badge reads "Plan Review" instead of the ambiguous "Reviewing" and no longer hides behind a lane restriction; the status badge stops duplicating it; `planning` renders as "Planning" instead of the raw engine token. - Coding (Ideas) renames its planner column to "Planning" (id `todo` unchanged) and loses its private planning-node re-home — the graph it clones is already plan-in-place. - New sweep `reconcileUndeclaredTaskColumns` re-homes a row whose column its workflow no longer declares. Written for a follow-up, kept because it makes any column edit survivable. ## Test changes Scheduler and release fixtures now model a card whose Plan Review passed — the state every real card is in when the capacity sweep sees it. A held unreviewed card is the gate working, and that path stays owned by `pre-release-plan-review.test.ts`. New `workflow-graph-entry-contract.test.ts` covers the invariant at every lifecycle position, plus the gap-column and remediation-node cases. ## Verification Gate 299 + 70 + 10, dashboard badge suites 672, engine workflow/entry/executor suites 147, core 122. Lint and typecheck clean. Full engine suite sits at the pre-existing baseline (notifier / plugin-runner / notification-service, untouched by this). ## Follow-up Removing the Todo column entirely is a separate ~207-site lifecycle-vocabulary refactor — planned in `docs/plans/2026-07-26-001-refactor-workflow-owned-lifecycle-plan.md` (companion docs PR). 🤖 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 * Plan Review now runs in the Planning lane before implementation begins. * Cards resume from their current workflow column without replaying earlier steps. * Added automatic recovery for cards stranded in outdated workflow columns. * Improvements * Renamed the Coding (Ideas) planner column to “Planning.” * Refined Plan Review gating to respect enabled settings and the card’s current column. * Updated planning and Plan Review badges for clearer, consistent labels across cards and lists. * Bug Fixes * Improved workflow transitions and release behavior around planning, review, and execution. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 23:42:46 -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	0e3d2a2265	refactor: delete meta-task auto-archive and automated recovery follow-ups (#2461 ) Deletes two pieces of automated "meta" machinery that filed and garbage-collected cards restating state already on the task that failed. Net -1015 lines. ## Why Automated recovery follow-ups. `createAutomatedFollowup` and its dedup engine (289 lines of signature matching, 1h recurrence rate-limiting, 24h supersedes windows) existed to file recovery cards for verification-cap and merge-conflict give-ups. In both cases the parent is already parked `failed` with a descriptive `error` and a log entry carrying the failing command, branch, and output — the card was a second copy of that. Meta-task auto-archive. The sweeps that garbage-collected those cards were worse than redundant: the regex classifier matched ordinary feature work, and its positional fallback bound cards to unrelated tasks, so live work could be archived. They are removed together, because the auto-archive sweeps only existed to clean up after the follow-up engine. ## What changed ### Deleted - `packages/engine/src/verification-followup-dedup.ts` in full — `createAutomatedFollowup`, `decideAutomatedFollowup`, `AutomatedFollowupKind`, `computeVerificationFailureSignature`, `extractFailingTestFiles`. - `findActiveRecoveryFollowUp` — dead code, defined and never called (`tsc` independently flagged it `6133 declared but its value is never read`). - The meta-task auto-archive sweeps `autoArchiveResolvedMetaTasks` / `autoArchiveStalledMetaTasks` and helpers `classifyMetaTask` / `resolveMetaTargetTaskId` / `computeMetaChainDepth` / `archiveMetaTask` / `evaluateMetaAutoArchiveGuards`, plus settings `metaTaskStallAutoCloseMs` and `metaTaskActiveExecutionGraceMs`. - Run-audit types `task:auto-archived-meta-resolved`, `task:auto-archived-meta-stalled`, `task:auto-archive-meta-resolved-skipped`, `task:auto-archive-meta-stalled-skipped`, `verification:followup-created`, `verification:followup-deduped`. The two signature helpers were deleted rather than relocated — once the three call sites went they were provably unreachable: `buildVerificationFailureSignature` had exactly one caller, and it was the only caller of `extractFailingTestFiles`. ### Call sites 1 and 2 — park kept, card dropped Verification-cap and merge-conflict give-ups keep their park, audit event, operator comment, and log entry. Site 1's `error` string was reworded off `"See follow-up task for investigation."` (no follow-up will exist) to carry the guidance itself. `autoResolveDisabled` was kept — it still drives the outer park guard and the `reason` string; only the inner branch that guarded card creation is gone. ### Call site 3 — autostash orphan, replaced not deleted This one is a genuine data-loss guard, so it keeps a durable trail. A `live`-classified orphan is a merger stash holding real uncommitted work, and unlike sites 1–2 there is no parked parent — the parent may already be `done` and merged, so nothing else on the board would ever mention the stash. The card is replaced by a `logEntry` and an `addTaskComment` on the parent, preserving every fact the old description carried: the sha, `record.label` (the handle `git stash` recovery needs), `record.detectedByTaskId`, and `sourcePhase`. New truthful run-audit event `task:autostash-orphan-live-detected` replaces the borrowed `verification:followup-` name, with ids/outcomes-only metadata per AGENTS.md. ### Kept unchanged: the two real product features Eval follow-ups (`eval-followups.ts`) and PR-comment follow-ups (`pr-comment-handler.ts`) only borrowed the shared engine for its dedup pass. Both keep their exact behavior, column, priority, `sourceType`, and log lines, with dedup inlined as a `listTasks` scan on `suggestionId` / `prNumber` respectively. Both fail open (create) if the listing throws, matching the old engine. ## Test changes — read this one Two tests asserted the deleted* engine's rate-limited `"[verification recurrence]"` logEntry. Those assertions were removed, not loosened: both tests still assert no duplicate card is created, and the eval test still asserts the existing id is reported back. No coverage of surviving behavior was weakened. The three `meta-` test files were deleted along with the sweeps they covered. ## Verification ``` $ pnpm test:gate Test Files 2 passed (2) Tests 10 passed (10) # core Test Files 16 passed (16) Tests 299 passed (299) # engine-core Test Files 1 passed (1) Tests 70 passed (70) # ci-shape GATE_EXIT=0 $ pnpm --filter @fusion/engine --filter @fusion/core exec tsc --noEmit -p tsconfig.json TSC_EXIT=0 (no output) ``` Plus a file-scoped run over the touched surfaces (`eval-followups`, `pr-comment-handler`, `merger-autostash-orphan-surface`, `merger-autostash-cleanup`, `run-audit`, `run-audit-secret-taxonomy`, `project-engine`, `project-engine-manager`): 213/213 passed. A repo-wide grep confirms no surviving references to any deleted symbol, module, or audit event. 🤖 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 * Failed tasks now retain recovery and verification details directly on the original task instead of generating separate follow-up cards. * Live autostash issues now preserve stash information in task comments and activity logs. * Existing evaluation and pull-request follow-ups continue to be reused when appropriate. * Changes * Removed automatic archival of meta-tasks. * Removed obsolete meta-task timing settings. * Documentation * Updated architecture and settings documentation to reflect these workflow changes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 22:38:58 -07:00

1 2 3 4 5 ...

2503 Commits