12462 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
gsxdsm	9edc746f96	E2E evidence: the MERGED board (third completion criterion) — plus a RETRACTION of my #2613 escalation (#2632) ... This is the merged-board half of the evidence assignment. **It is red, deliberately, and the red is the finding.** Do not merge it to make the red go away — the assertions are correct and `main` is broken. ## Escalation first: #2613 broke the default board, and the gate did not notice `6a33d8f8c` — *"Phase B — TAKING task-creation.ts: intake classification by trait (4 sites → 0)"* (#2613) — regressed four E2E cases, including **the default-vocabulary full lifecycle**, which is scenario 1 of the whole E2E assignment. Attribution is a clean single-file revert, not a guess: ``` HEAD (main): 4 failed | 39 passed HEAD with ONLY 6a33d8f8c's task-creation.ts reverted: 28 passed (both files fully green) ``` Failing: 1. `scenario 1 — DEFAULT vocabulary … persists the card in the expected column at every stage` 2. `scenario 2 — RENAMED vocabulary … writes the same column-transition audit trail as the default` 3. `releases a card out of the merged lane on capacity — the release is not a self-move` 4. `does not re-release a card that already left the merged lane` **`pnpm test:gate` is green on this branch — exit 0, 695 tests.** #2613 merged through a green gate, and its own tests pass. This is the eighth time this program a test has passed without exercising its subject, and the first one an E2E family caught rather than review. ### Mechanism `isIntakeColumn` in `task-creation.ts` decides whether a new card gets a **bootstrap** prompt (freeform, "triage will plan this later") or a **specified** prompt (planned, executable). #2613 rewrote it as: ```ts const isIntakeColumn = (intakeFacts.intake !== undefined && task.column === intakeFacts.intake) || … ``` where `intakeFacts.intake` falls back to the **default workflow's** intake when the create supplies no `workflowId`. Post-U11 the default workflow's intake **is `todo`**. So any card created directly in `todo` is now classified as intake and gets a bootstrap prompt — unplanned. Unplanned cards do not advance through the graph (no `NodeEntered` audit rows → failures 1 and 2) and hold-release will not release them (FN-7648: no unplanned card enters a processing column → failures 3 and 4). Before U11 this was safe: `triage` was intake and `todo` was a distinct lane, so creating in `todo` meant "planned work". The merge deleted that distinction. ### Why this is the exact trap you warned about You said you did not want *"a conversion that swaps the literal for a trait lookup WITHOUT checking what the guard was for."* The old `task.column === "triage"` guard meant **"is this card unplanned?"** On a merged board, intake-vs-hold **cannot answer that question at all** — one column is both. The distinguishing fact is not the column; it is whether the caller supplied a spec. Resolving the role faithfully still gets the wrong answer, because the question was never really about the column. Not fixing it from here: `task-creation.ts` is #2613's owner's file, and the fix is a design call about which fact replaces the column test. ## What the evidence itself adds Three families extended to the U11 shape — one column carrying **both** intake and hold. That breaks a class of guard renamed boards structurally cannot reveal: | shape | consequence | |---|---| | `intake && !hold` | **unsatisfiable** — silent | | hold → intake release | **self-move**, re-fires every poll — loops | | `intake && column !== "triage"` | inverts to **always-true** — silent | Two are silent and one loops, so every case sweeps **twice** and asserts no re-release; a single pass cannot tell a no-op from a self-move. ### A fixture that could not fail My first merged row used `MERGED_VOCAB`, which is *faithful* to U11 — it reuses the legacy ids, because that is what the default lineage has. That fidelity **destroyed its discriminating power**: its hold column *is* `todo`, so a guard falling back to the `todo` literal returns the same answer as one resolving the role. The "hold but not intake" mutation left all 23 green. Added `MERGED_RENAMED_VOCAB` — merged *structure*, renamed *vocabulary* — the only combination where the collapse is observable **and** the literal is wrong. Same mutation now fails exactly 1 of 23. Both vocabularies stay: one asks *"does the collapse break the release path"*, the other *"is the role actually resolved"*. One rebound mutation was **genuinely unobservable** rather than undetected — `hold` is also the first column in that fixture, so the fallback chain lands there regardless. Pointing rebound at `complete` instead fails 9 of 15. Recorded rather than papered over. ## For the CAPACITY worker before `self-healing.ts` is marked done `self-healing.ts:2952` and `:9134` query `listTasks({ column: "triage" })`. Converting the 10 guards leaves those sweeps **blind** — they never see a renamed card, so the guard is correct and unreachable. Query and guard convert together or not at all. There are **137** such `column: "<legacy id>"` sites repo-wide, 52 in that one file, and the 45→0 grep counts none of them because they are object properties, not comparisons. **The bar can reach zero with sweeps still unable to fire.** 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:59:37 -07:00
gsxdsm	7ab6506c0f	docs(solutions): proving a code path actually runs — the five ways U8 shipped code that never executed (#2642) ... Durable write-up of U8's verification findings. **Docs only — no code change, no CI risk beyond lint.** These currently exist only in PR bodies, which nobody greps. `docs/solutions/` is where this project keeps exactly this kind of thing, and every one of the five will recur: the handler-pair shape and the resolved-vs-guessed fork both have more call sites than U8 touched. ## The five 1. **Two prompt-node handlers exist; only one runs.** `createDefaultNodeHandlers` prefers the primitives handler whenever `deps.primitives` is set, and `executeWorkflowGraph` always sets it — so every seam entry in `createAuthoritativeWorkflowSeams` is unreachable for prompt nodes. A lifecycle announcement sat there through two PRs. It type-checked and its unit tests passed, because a seam-level test calls the seam object directly and therefore always can. 2. **A negative instrumentation result is worthless without a control.** No output from an instrumented seam is only evidence once you have shown writes from that module are visible under the harness. One `process.stderr.write` at module load separates "never ran" from "output swallowed" — opposite conclusions. 3. **Source-string ratchets prove syntax, not behavior.** Three were torn down in review. The sharpest guarded a never-executed-code bug with a source search, reproducing the bug one level up; measured, the behavioural version fails an inverted dispatch and the textual one passes it. Includes the sub-rules paid for the hard way: use the AST not regex (a brace in a string truncated an extraction to 13 lines and every count read a *passing* zero), guard the guard, anchor by index rather than a character window. 4. **A green test on first try, on a path with no prior coverage, is a warning.** Two conversions were reverted in one day because their tests passed with the change reverted. Negative assertions succeed trivially when the method returns early — `recoverCompletedTask` has seven guards before the converted line, and the fixture has to satisfy all of them. 5. **A named workflow selection is not a resolved one.** Provenance cannot be inferred from the returned value, because a fallback IR and a valid id-less IR are structurally identical — the resolver that knows has to report it. This is the fork every remaining lifecycle-column conversion hits. ## Why this rather than another conversion Everything left in my area is now owned and further along than I could take it: `executor.ts` → #2628 (which solved the `recoverCompletedTask` fixture I could not), `self-healing.ts` → #2560 (independently hit all three traps I catalogued), the dashboard cluster → #2625/#2626/#2636. Duplicating that would be motion, not progress. Turning findings that cost real cycles into something greppable is the useful thing I can still add. `pnpm lint` clean. No changeset — internal documentation. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a best-practices guide for verifying that workflow code paths actually execute. * Covers reliable behavioral assertions, instrumentation controls, regression-proof tests, source validation, and detection of fallback behavior. <!-- 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:59:24 -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
gsxdsm	8e211d1870	TAKING scripts/: parse instead of grep — an AST classifier for the lifecycle-column bar, cross-checked by a second implementation (#2633) ... The program's completion bar is "`column === "triage"` reaches zero". This measures what that bar actually covers, and checks the measurement in so it cannot drift. ## The number, measured by the checked-in tool ``` lifecycle-column-census: scanned 1956 source files COLUMN guards (the backlog): 1031 ROLE comparisons (not guards): 10 DELIBERATE-LITERAL (reviewed): 4 by column id: 313 done 217 in-review 201 in-progress 177 archived 83 todo 40 triage top files: 151 packages/engine/src/executor.ts 136 packages/engine/src/self-healing.ts 50 packages/dashboard/app/components/TaskCard.tsx 44 packages/core/src/task-store/moves.ts 34 packages/dashboard/app/components/TaskDetailModal.tsx ``` **`triage` is under 4% of the class.** Every one of those 1031 sites is the same defect: a lifecycle decision made by column NAME, which stops matching the moment a board renames a column. The bar can be met in full while 991 identical guards remain — and two files hold a quarter of them. ## The tracked count is wrong in three directions at once Each of these cost real work this week, which is why this is a PR and not a comment. 1. **Vocabulary.** It measures one of six legacy ids. 2. **Receiver.** It is anchored on locals named `column`/`toColumn`/`fromColumn`, so it never saw the three real guards in `executor.ts` written against `from` and `originColumn`. One of those meant completed-but-stranded work was never recovered on a renamed board, with nothing else owning that state (converted in #2628). 3. **Collision.** `role === "triage"`, `agentType === "triage"`, `entry.agent === "triage"` compare an **AGENT ROLE**. The planner *lane* is named `triage` and keeps that name — U11 removed the *column*. Ten such sites were counted as backlog, and the "obvious" fix (renaming the role) silently empties the planner's prompt template and mis-binds its model markers. A count that is too high and too low simultaneously sends work to the wrong files while hiding the files that need it. So the census reports **three separate numbers** and never nets them. ## Proven to fail on the original defect Not asserted — exercised: ``` $ # reintroduce `task.column === "triage" || task.column === "todo"` into live-agent-count.ts $ node scripts/lifecycle-column-census.mjs --strict; echo "exit=$?" packages/core/src/live-agent-count.ts: 10 -> 12 exit=1 $ # restore the file $ node scripts/lifecycle-column-census.mjs --strict >/dev/null; echo "exit=$?" exit=0 ``` The CLI also exits 1 when its own file list comes back empty — a guard that reports success without checking anything is worse than no guard. ## 12 regression cases, split by what they defend Must catch: all six ids; a guard on a local named `from`/`originColumn` (verbatim the executor.ts shape); single quotes; negation; several comparisons on one line. Must **not** catch: role comparisons; comment prose (two tracked "guards" in `replan-target.ts` were prose about a filter that lives in another file); a trailing `// … === "triage"` on a code line; sites carrying a `DELIBERATE-LITERAL` marker. Plus: **one marker cannot launder a distant guard in the same file** — that is how allowlists rot. ## Report-only, deliberately `--strict` compares per-file counts against `scripts/lib/lifecycle-column-census-baseline.json` and fails when any file's count **rises**. It is **not** wired into the merge gate: a thousand-site backlog cannot be a blocking check the day it is first measured, and a guard nobody can pass is a guard everyone disables. Owners tightening their own area re-record the baseline in the PR that lowers it. This is the ratchet shape the `DELIBERATE-LITERAL` markers scattered through the program already anticipate. ## Stated limitation Classification is by receiver **name**, so a future field named `agent` that holds a column would be misclassified as a role comparison. Recorded at the site, and it is precisely why the two classes are reported separately instead of netted into one figure. ## Verification - 12/12 new cases (`packages/engine/src/__tests__/lifecycle-column-census.test.ts`) - `pnpm test:gate` **71/71**; `pnpm lint` clean - `pnpm census:lifecycle-columns`, `--json`, and `--strict` all exercised end to end - documented in `docs/testing.md`; no production code touched 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:52:18 -07:00
gsxdsm	6d10683dbd	docs(solutions): store fakes that lie — six fixture defects that each looked like a production bug (#2534) ... Six consecutive slices of U7 produced **six test-fixture defects, and every one first presented as a bug in the code under test.** Not one was real. Each cost 15–60 minutes debugging the wrong file. **Two would have shipped a false green** — a test passing while asserting nothing — if the failure had happened to look plausible rather than implausible. This is not a story about carelessness. Every one of these fakes was modelled on an existing fixture in this repo, and the repo's fixtures are inconsistent about exactly the things that matter. ## The catalogue | # | Defect | How it presented | Real cause | |---|---|---|---| | 1 | `moveTaskIf` ignores its predicate | Test passed; in-txn guard untested and indistinguishable from absent | Fake never invoked the callback | | 2 | `updateTaskAtomic: vi.fn()` never invokes its callback | *Every* finalize bailed before the branch under test | Success is derived from whether the callback ran | | 3 | Harness default parameter swallows the input | "Task vanished" case became a duplicate of the control | `harness(undefined)` triggers the default | | 4 | `logEntry: vi.fn()` returns `undefined` | Sweep appeared to match only one column | `.catch` on a non-promise throws, aborting the loop after item one | | 5 | Harness lets `poll()` reach the real `specifyTask` | **exit 1 with every test green** | Real agent path threw *asynchronously*, after assertions passed | | 6 | `updateTask: vi.fn()` returns `undefined` | Branch "did not run" | Same as #4 | **4 and 6 are the same shape, found a week apart, because nothing prevented the second.** That is the argument for writing this down. ## The three rules 1. **Every store method a fake exposes returns what the real one returns** — overwhelmingly a promise. Production writes `await store.m(...).catch(h)` as a fail-soft idiom; `.catch` on `undefined` throws a `TypeError` that unwinds into a broad *"never let housekeeping break the poll"* handler and vanishes. Symptom is never "your fake is wrong" — it is *"the loop only processed the first item"*. 2. **A fake handed a predicate or callback must invoke it.** Ignoring it makes the guarded and unguarded implementations *indistinguishable*, so a test named for the guard cannot detect the guard's removal. Includes the `onLockedRead` hook, without which an in-transaction recheck stays untestable even once the predicate is invoked. 3. **Stub the agent-dispatch boundary.** `poll()` ends in "start an agent", which in a unit test throws *after* the test resolved — `17 passed`, exit code 1, which on CI reads as infrastructure noise. > Never accept a non-zero exit on a green run. It is the only signal that something escaped your assertions entirely. ## Also covered - **How to spot a fixture defect fast** — the tell is *failing for the wrong reason*. Three concrete checks before you open the production file. - **Why differential tests earn their keep** even when they feel redundant: the default-vocabulary half doubles as a fixture self-check, because it asserts behavior that is by definition already shipping. On this program, "both halves failed" was the signal that found three of the six. - **The connection to guards that cannot fire** — six of those on this program too, including a ratchet I wrote that matched only a double-quoted literal (#2527). Same discipline either way: *prove the check fails on the thing it claims to catch before trusting that it passes.* Including the warning that one ratchet injection silently failed to apply, leaving a green run that would have "proven" the ratchet worked. ## The concrete next step, stated plainly A shared `createTaskStoreFake({ tasks, workflowIr })` with promise-resolving, callback-invoking defaults would remove this whole class in one small PR. **It is not built here** because it is cross-unit and needs adopters — building it inside U7 and hoping others find it is how conventions die. The doc says: if you are about to hand-roll a seventh store fake, build the helper instead and link it. Docs-only; no changeset (AGENTS.md excludes internal docs). 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added guidance on six store-fake defect patterns that can resemble production bugs during testing. * Documented best practices for creating reliable store fakes, including promise handling, callback invocation, and async dispatch isolation. * Added diagnostic techniques for distinguishing fixture issues from genuine application defects. * Included guidance for validating production guards and links to related documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:42:36 -07:00
gsxdsm	26c82ebc18	ratchet the planner-liveness gate so a fourth door fails CI (FN-6756) (#2540) ... Test-only follow-up to the merged P0 (#2531). No production change, no changeset (internal). ## Why This bug reached users **three times**, each as the same mistake in a new place: | | What happened | |---|---| | FN-8600 | the reclaim sweep removed a worktree a live **planner** was using — fixed by registering planning paths and teaching *that* sweep `isPathActive` | | FN-6756 | the leaked-slot reaper never got the same signal; its last line of defense computed liveness from four TaskExecutor-owned maps, so a triage planner matched none of them | | (same PR) | fixing that was not enough — `recoverPausedAbortFailures` **discarded** the refusal and still logged `"Auto-recovered…"`, audited and counted it. The whole bug again, while reporting success | The shared cause is not any one sweep: **“liveness” was re-derived per call site**, so closing one door left the next open and nothing failed. Every one of those fixes was found by review, not by CI. This makes the next one a CI failure. ## Four properties, each written to fail on the exact defect that got through 1. **Every `clearPhantomExecutorBinding?.(` call site consumes its return** — a bare expression statement (including `void`/`await`-prefixed) is the signature of the pause-abort defect. 2. **The destructive path delegates to `hasLiveSessionSurface`** rather than inlining the session-map disjunction — a second copy can drift from the one callers gate on, which is precisely how each sweep got “fixed” without fixing the next. 3. **The probe is wired** in `in-process-runtime`. `self-healing.ts` already records `releaseExecutorWorktreeOwnership` as a declared-but-never-wired option that silently no-opped; an unwired *probe* is worse, since `?.() === true` is `false` when unwired and every gate would quietly stop deferring with nothing failing. 4. **The probe counts registered session paths**, not just executor maps — a triage planner appears in no executor-owned map, so that term is the only thing that sees it. Grep-level, comment-stripped, production source only; no engine boot and no fixtures (FN-5048). Fails closed on an empty/moved source file so a rename cannot make it silently check nothing. ## Proven, one injection at a time **The first draft of property 1 was worthless** — its filter chain was convoluted enough to discard every candidate, so the injected bare call passed. Caught by actually running the injection instead of trusting the green, and rewritten as a single “is this a bare expression statement” rule. | Injection | Result | |---|---| | discard the return value | fails, naming the call site | | re-derive liveness inline | fails on the delegation assertion | | unwire the probe | fails, naming `in-process-runtime` | | drop the registry term | fails, naming `activeSessionRegistry` | Clean tree passes 4/4; all three sources restored byte-identical (`git status` shows only the new file). **Verified:** `pnpm lint` clean · engine `tsc` clean · `pnpm test:gate` green (414 + 10 + 71). 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Tests** * Added safeguards to ensure liveness checks remain consistently enforced. * Verified phantom executor cleanup uses shared session-liveness detection. * Added coverage for registered session paths to prevent false inactive states. * Added fail-closed checks when required runtime source is unavailable. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:42:26 -07:00
gsxdsm	55ce01335c	self-healing.ts: resolve pre-WIP columns by role — 11 → 0 receiver-agnostic (largest single item) (#2560) ... Taken ahead of my capacity slice, per the drift review. U11 merges the two pre-implementation columns into one that **keeps the id `todo`** and **deletes `triage`**. Every `column === "triage"` here is live breakage the moment that IR lands — and it does not throw, it simply **stops matching**, so the sweep never fires again and the suite stays green. That is the Problem Frame’s measured failure mode, landing on self-healing, where a silently-dead recovery is least likely to be noticed. ## Count for tracking convergence `self-healing.ts`, code only, `column === / !== "todo" | "triage"`: | | before | after | |---|---:|---:| | `"triage"` comparisons | **10** | **0** | | `todo` + `triage` combined | 24 | 15 | The 15 remaining are all `"todo"`, whose id **survives** U11 — not breakage, and deliberately left for the hold-column conversion rather than mixed in here. ## Ten sites, converted by role (intake / hold) advanced-triage recovery (3, one sweep) · dependency-deadlock blocked dependents · parked-agent task link · orphaned-approved planning · orphaned planning · duplicate-decision candidates · refine-source sweep · leaked-slot reaper ## Two literals the grep did not count — and they would have silently killed their sweeps `listTasks({ column: "triage" })` in both orphaned-planning sweeps. Converting only the predicate would have left the **query** returning nothing once the id is gone; the sweep would have looked converted and done nothing. Both now query the board and filter by role. All ten route through one seam (`resolvePreWipColumns` / `filterByPreWipRole`) with a caller-owned per-sweep cache, so 400 cards over three workflows read three IRs, not 400. ## Two judgement calls, stated **Unresolvable workflows fall back to the legacy literals, not to nothing.** These are *recovery* sweeps: a card whose IR cannot be read must keep its current behaviour rather than silently drop out of every sweep. That is the conservative direction *here*, and deliberately differs from conversions whose failure mode is a destructive move. Pinned by test. **The leaked-slot reaper’s predicate is left as-is and flagged in place.** It is arguably too *wide* under plan-in-place — a card being specified sits in the hold column while a planner works in its worktree, so “waiting to run must not pin a worktree” no longer holds. What stops that being live is the FN-6756 liveness gate (already merged). Narrowing it is a behaviour change and gets its own commit; this PR is vocabulary only. The dependency-deadlock site needed restructuring rather than substitution: its filter is synchronous and role resolution reads the IR, so membership is precomputed once per sweep. ## Verification **Revert-proof, measured:** making the resolver return the literals regardless of workflow turns **4 of the 6** new cases red — the renamed-workflow ones, precisely the case a literal cannot serve. `self-healing.ts` restored byte-identical. `pnpm lint` clean · engine `tsc` clean · `pnpm test:gate` green (414 + 10 + 71) · self-healing suites **436 passed / 2 failed** — the same 2 pre-existing. 🤖 Generated with [Claude Code](https://claude.com/claude-code) ## Re-verified against current `origin/main` (2026-07-29) Per the definitive-list instruction, re-measured rather than re-asserted — comment-stripped, so FNXC prose quoting a removed literal does not inflate the count. - `origin/main` `self-healing.ts`: **10** code sites (lines 2964, 2984, 3019, 9218, 10703, 11282, 12173, 12218, 12321, 12494 — the same ten, line numbers shifted only). - This branch: **0**. - Main touched this file after my branch point (#2600, the R7 dead-guard fix). Checked: its diff adds **no** `"triage"` literal, and git reports this PR `MERGEABLE`, so the merge result stays at 0 — the branch being behind does not hide a new site. So merging this moves the tracked number **45 → 35**. Both stated constraints hold: every site resolves to the **intake/hold ROLE** (not a renamed literal), and the count is zero across the whole file rather than per-branch — there is no surviving guard in another branch of the same function. The two `listTasks({ column: "triage" })` **queries** are converted too; predicate-only conversion would have left these sweeps looking converted while returning nothing. ## Re-measured RECEIVER-AGNOSTICALLY (2026-07-30, after the revised bar) The revised count matches any receiver, not just `.column`. Re-measured with that pattern, comment-stripped, this file is **11 → 0**, not 10 → 0. | pattern | origin/main | this branch | |---|---:|---:| | `<anything> === / !== "triage"` (any receiver, both quote styles, line-splits) | **11** | **0** | The eleventh is the one your list attributes separately to `engine/self-healing.ts`: ``` origin/main:3017 if (!resumeColumn || resumeColumn === "triage") continue; ``` `resumeColumn` is a bare local holding `live.workflowIrPinColumnId`, so a `.column`-anchored pattern cannot see it. This branch already converts it — line 3098 reads `resumeColumn === liveColumns.intake`, resolved from the same per-sweep role cache as the other ten. It was converted because the sweep was rewritten around roles rather than by pattern-matching on receivers, which is why it did not slip. **Merging this therefore moves the revised 56 by 11, to 45.** ### The 5 literal mentions that remain, and why each is not a guard Nothing above is a comparison. For completeness, since "a file is not done because the pattern is gone from it": - **3 legacy fallbacks** (`?? "triage"`) at 2978, 2980, 10821 — the unresolvable-workflow path in `resolvePreWipColumns`. These are *recovery* sweeps: a card whose IR cannot be read must keep its current behaviour rather than silently drop out of every sweep. Pinned by test. - **2 union reads** at 6044 (`["triage", "todo"]`) and 9291 (`listTasks({ column: "triage" })` alongside a `todo` read) — unions covering both vocabularies, with the role filter deciding membership. Neither replaces nor disables anything. Known residual gap, stated rather than hidden: those unions do not cover a **renamed** intake (Coding (Ideas)'s `ideas`). That gap **pre-dates U11** — the same unions missed `ideas` before the merge — so it is not a regression here, and closing it needs a cross-workflow lane union rather than a vocabulary edit. ## AST-VERIFIED, replacing the grep-derived figure (2026-07-30) Since no grep-derived number is authoritative, I re-measured this file by PARSING it — `ts.createSourceFile`, walking binary expressions, classifying on the left-hand side. Not a pattern match. | | origin/main | this branch | |---|---:|---:| | lifecycle-column comparisons (AST-classified) | **11** | **0** | All eleven classify as `COLUMN`; none is an agent role, session purpose or surface name, so all eleven are real guards and every one is converted: ``` 2964 task.column 9218 dep.column 12218 task.column 2984 live.column 10703 task.column 12321 task.column 3017 resumeColumn 11282 linkedTask.column 12494 t.column 3019 current.column 12173 t.column ``` `3017` is `resumeColumn` — a bare local holding `workflowIrPinColumnId`, which is exactly the receiver class the `.column`-anchored greps missed. It is converted here to `resumeColumn === liveColumns.intake`, resolved from the same per-sweep role cache as the other ten. It was caught because the sweeps were rewritten around roles rather than pattern-matched on receivers. The classifier is on #2623 as `scripts/lib/lifecycle-column-ast.mjs` and is offered to #2630 to import. My earlier "11 → 0" was correct — but it was a regex reading, and this is the same number arrived at by parsing. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:42:14 -07:00
gsxdsm	833f379fbd	U7: ratchet the planning claim to a single writer (extracted from #2517 so it can land) (#2587) ... > Test-only, based on `main`, no dependencies. **Extracted from #2517**, which has been overtaken by events — see the bottom. U7's stated verification is *"a grep-level assertion that planning status literals have one writer module"*. This is that assertion, and the plan names **FN-8504** as the acceptance case: a store-open sweep cleared a live planner's status because two owners wrote it. ## What it asserts 1. **`status: "planning"` — the claim on a card — is written by exactly one production module** (`triage.ts`). 2. That single write goes through `updatePlanningStateIfStillCurrent`, never a bare `store.updateTask`. FN-7977 and FN-8361 are both the latter bug. ## What it deliberately does not assert Stated in the file so the guard is not oversold: - **Who clears the status.** Eleven modules write `status: null` for unrelated reasons — "one clearer" would be *false*, and the only way to make it pass is to weaken it into meaninglessness. - **`needs-replan`.** Post-U3 it is the graph's own durable replan signal with multiple writers **by design**. - **Mission `status: "planning"`.** A different entity, excluded by *path* rather than by pattern — a pattern loose enough to tell them apart is loose enough to miss a real task write. ## Writes and bindings are separate contracts Adding constant-indirection detection (`const CLAIM = "planning"` defeats every shape pattern) flagged `replan-target.ts` — which binds the literal only to **exclude** it from a status set and writes no task status anywhere. Calling that a second writer would have been a false accusation; dropping the binding rule would have reopened the hole. So the **write** list stays at one module and **binding** is its own allowlist. ## Proven to fail — twice A guard that cannot be shown to fail is not a guard. **1. The real scan function is re-run over a fixture tree** by four of its own tests — a re-implementation would prove only that the copy works. Covers every evasion form (single quotes, template literal, whitespace, plain assignment, computed key), the indirection route, a comparison-only counter-case, and a brand-new package. **2. End-to-end against real source**, in a form the *original* detector missed on **both** axes — a single-quoted writer in `packages/desktop`, a package the first version never scanned. Re-verified on post-U11 `main` just now: ``` FAIL ... + "packages/desktop/src/bundled-plugin-dirs.ts" Tests 1 failed | 13 passed (14) ``` Both holes — double-quote-only matching, and a hardcoded four-package scope — were found by greptile on #2527, and are why the detector now **discovers** its roots by enumerating `packages/<name>/src` rather than listing them. ## Why this is a separate PR **#2517 has been overtaken.** Main absorbed a better discovery conversion from another worker (it handles U11's merged column, which mine did not); #2515 then changed the column vocabulary underneath it; and what remains there is entangled with 14 U11 fixture updates. This file is a source scan with no dependency on any of that, so it lands on its own. My recommendation on #2517: **close it** and re-land its remaining unique content — the sweeps, the handler snapshot, stuck-abort, `recoverApprovedTask`'s intake gate — as focused PRs against post-U11 main. Holding a 1262-line PR open through three vocabulary changes has cost more than it has delivered. That is a reversible call and it is yours if you disagree; say so and I will rebase it instead. ## Verification | Check | Result | |---|---| | suite | 14/14 | | `pnpm lint` | clean | | `pnpm test:gate` | green (482 + 10 + 71) | Cheap by construction (FN-5048): grep-level over production source, no engine boot. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Tests** * Added automated safeguards to ensure planning task cards have exactly one valid writer. * Added checks covering direct and indirect status updates, supported syntax variations, package discovery, and comment or test-file exclusions. * Added validation that planning updates occur only through the approved guarded workflow. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:41:30 -07:00
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	8beba5f543	U7 E2E evidence: the planning lane, real PostgreSQL + real hold-release sweep (3/7 red without the guard) (#2611) ... > Completion-bar **item 3** for my phase. Test-only, based on `main`, no dependencies, no changeset. ## The gap this closes The planning lane was the **one lifecycle lane with no E2E coverage**. The existing live-E2E files cover the lifecycle spine, agent count, agent link, lease rebound, the merge family and the rebound family — **not one exercises a planning decision.** Every U7 fix shipped with the caveat the other units already removed for their lanes: *"all evidence is unit-level."* That caveat matters more here than anywhere, because the planning fixes are **guards that refuse things**, and a refusal is what unit tests are worst at proving. Nine times on this program a planning test passed without exercising its subject: a fake that ignored its predicate, a store stub returning a non-promise into `.catch`, a fixture that silently resolved to the default IR, a control that passed when it should have failed. ## What is real - a per-file **throwaway PostgreSQL** TaskStore (never the operator's) - the **real `runHoldReleaseSweep`** — every guard, trait resolution, reservation ordering, and the in-transaction `moveTaskIf` predicate - **persisted rows** read back with the store's task cache defeated, so an assertion can only have come from the row Nothing about the AI is substituted, because none of these decisions involve it — there is no seam here to script. ## The proof, which is the point With **#2491's two approval guards removed** from `hold-release.ts`, this file goes **3 of 7 red against real PostgreSQL**: ``` FAIL does NOT release a card blocked on manual plan approval on a default board FAIL does NOT release a card blocked on manual plan approval on a renamed board FAIL holds a card parked for approval MID-SWEEP, after the snapshot was read Tests 3 failed | 4 passed (7) ``` Restored: **7/7**. So the file demonstrably exercises the guard rather than merely observing that a sweep works — which the two control cases (an ordinary held card **is** released, on both vocabularies) exist to keep falsifiable. ## The case no unit test could honestly make The **mid-sweep** case needs the in-transaction predicate enforced by a real store. The hand-built fake that shipped with #2491 originally **did not honour the predicate at all** — exactly what greptile caught. Here PostgreSQL enforces it, and the sweep's own log confirms the refusal: ``` [scheduler] Hold release for FN-RACE skipped — task became paused or left todo ``` It parks the card inside `reserveSlot`, which runs *after* the snapshot and *before* the move — the precise window the in-txn half exists for. ## Coverage Both approval hold shapes (`status: "awaiting-approval"` and `paused` + `pausedReason`), on **both** vocabularies, so no assertion can pass by matching a legacy id. The renamed run's log shows the real sweep releasing the control card to `building`, not `in-progress`. ## Lane `.pg.test.ts`, skipped via `pgDescribe` when no PostgreSQL is reachable, so **the merge gate is unaffected**. Throwaway per-file database, never port 4040, no temp-root walk. ## Verification | Check | Result | |---|---| | E2E suite (real PostgreSQL) | 7/7 | | same suite with #2491's guards reverted | **3/7 fail** | | `tsc --noEmit` (engine) | clean | | `pnpm lint` | clean | | `pnpm test:gate` | green (482 + 10 + 71) | ## Still owed on the completion bar for my lane E2E for the other three U7 fixes — approved-plan recovery (#2593), the spec-staleness exemption (#2583), and the discovery advancement guard (#2576) — is **not** in this PR. Those need a driver for triage's own poll/recovery path rather than the sweep, which is a different harness shape; adding it here would have made this PR a harness project rather than evidence. Taking that next. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:40:05 -07:00
gsxdsm	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	c9f117bcd9	fix(test): dep-abort rebound asserts the resolved column, not the retired triage literal (#2641) ... **Review-lane test, 1 failed → 21 passed.** Test-only. `pnpm test:gate` green, `pnpm lint` clean. ## Production was right; the test was stale ``` expected moveTask("FN-DEP", "triage") received moveTask("FN-DEP", "todo") ``` `handleDepAbortCleanup` no longer hardcodes a column. It moves the card to `resolveReboundColumnFor(store, taskId)` (`executor.ts:16576`), which resolves the task's **own** workflow rebound target by trait — hold, else intake, else first column — with a `todo` fallback. For this fixture's default workflow that resolves to `todo`, which post-U11 **is** the merged Planning column. `triage` is not declared on the default lineage at all, so the old expectation was asserting a column the workflow does not have. ## Why the concrete value, not the resolver I asserted `"todo"` rather than re-calling `resolveReboundColumnFor` in the test. Deriving the expectation from the code under test makes the assertion agree with whatever the resolver happens to return — the exact anti-pattern `task-delete-notice.test.ts` documents for its notify table ("deriving the expectation from the value under test makes the suite agree with whatever the production constant happens to say"). That's only legitimate because **per-workflow resolution already has its own coverage** — `replan-target-merged-planning-column.test.ts` and `replan-target-renamed-planner.test.ts`. I checked they exist rather than assuming; without them, pinning a concrete id here would be hiding the interesting behaviour. Also added the negative: the move must **not** be `triage`, so a regression that reinstates the literal fails instead of quietly passing on a column the default lineage no longer declares. **Red-green:** reinstating `moveTask(taskId, "triage")` in production fails exactly this test (`NEW-failures=1`). ## Context — main's engine-default census Measured on `origin/main` just now: **66 failed / 9382 passed across 13 files**. This clears one. `workflow-lifecycle-live-e2e.pg.test.ts` is another and is already fixed in #2634 (pending merge), which takes it from 2 failures to 0 and adds two new scenarios. Of the remaining 11, none are in the review/merge lane: `agent-tools-intake-column`, `builtin-workflows-lifecycle`, `workflow-graph-optional-step-fix` and `workflow-settings-fallback-alignment` are column-vocabulary drift belonging to the U11/U12 owners (the optional-step-fix one expects `triage` where the replan rebound now resolves `todo` — same class as this fix, different owner's file); the rest are executor/CE/goal-anchoring. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:38:47 -07:00
gsxdsm	890d588891	Phase B — Column.tsx 2→0 and taskActivity.ts 2→0 (U11's cluster to zero) (#2636) ... **Claimed:** `Column.tsx`, `taskActivity.ts` — both to zero. | file | before | after | |---|---:|---:| | `packages/dashboard/app/components/Column.tsx` | **2** | **0** | | `packages/dashboard/app/utils/taskActivity.ts` | **2** | **0** | ## `Column.tsx` — two different fixes, because the two sites are different problems **The preserve-progress prompt** routed through `isPreImplementationColumnRole`. This is the *same* question that helper was written for — ListView asks it about a move target, Column asks it about itself — and the degraded id sets are identical (`{todo, triage}`), so the consolidation is exact. I verified the sets matched **before** consolidating, because the sibling case is not interchangeable: `isPreExecutionHoldColumn` in `TaskContextMenu` drives the Plan affordance and its degraded set is `{triage}` alone. Routing *that* through this helper added `plan` to flagless `todo` cards, caught by an existing test. **Same shape, identical trait path, non-interchangeable fallbacks.** **The legacy-board arm** (`workflowMode || column === "triage"`) — deleted, on the third attempt. I deleted it twice before and reverted both times because four Column tests render without `workflowMode`. That was the delete-only rule working, but **my conclusion from it was wrong**: a behaviour change means the branch was not dead *for those callers*, and the callers are **fixtures, not production**. Board is Column's only consumer and passes `workflowMode` at all three render sites. Defending an unreachable arm so four tests keep passing preserves the tests, not the behaviour. Two notes for anyone converting the remaining dashboard files: - I did **not** default `workflowMode` to `true`, which was the tempting one-liner. `isArchived`, `isHoldColumn` and `isWipProcessingColumn` all switch on that same flag, so a global default would silently reinterpret every other fixture in an 85-test file. - **"Four tests break" was itself an underestimate.** Two more FN-770 fixtures surfaced only after the first two were fixed, because they render their own explicit `column="triage"` block instead of using `defaultProps`. The blast radius only became accurate by fixing it in waves. ## `taskActivity.ts` — composed, not copied The degraded arm now composes `utils/columnRoles`' predicates instead of naming ids. **No local copy** — which is the failure mode #2625 hit from the other direction. Equivalent *by construction*: | lane | composition | resolves to | |---|---|---| | intake | `isIntakeColumnRole(undefined, col)` | `triage` | | hold | `isPreImplementationColumnRole(...)` **and not** intake | `todo` | reproducing `col === "triage" || (col === "todo" && isReplanning)` exactly, since the shared pre-implementation set is `{todo, triage}` and the shared intake id is `triage`. Deliberately phrased as *"pre-implementation and not intake"* rather than a second id list: if either shared set changes, this composition follows it instead of silently disagreeing with the file next door. That disagreement is precisely what bit the `TaskContextMenu` consolidation above. **I previously reported this site as blocked on `TaskCard.tsx` (U12's)** — on the theory that the arm could only die once every caller supplied resolved flags. Wrong framing: the arm doesn't need to become *unreachable*, it needs to stop *naming ids*. Composing the shared predicates does that without touching any caller. ## Verification **1139 of 1141** green across `app/utils`, `Column` and `TaskCard` suites. The two `TaskCard` failures are **pre-existing** — verified by stashing this change and re-running, where they fail identically. Dashboard app typecheck and lint clean. Takes U11's cluster to zero except `TaskContextMenu.tsx`, whose remaining site is covered in **#2626** and whose second site is a documented non-consolidation. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:37:43 -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	73338502e5	fix(test) + E2E: re-green main's lifecycle release leg, and prove the MERGED board + REVISE rework (#2634) ... **Second batch.** Three commits, no production code. `pnpm test:gate` green, `pnpm lint` clean, all three E2E suites together **3 files / 41 tests, exit 0**. ## 1. main's lifecycle E2E is RED right now — this fixes it Independently of my work, on a detached `origin/main`: **2 failed / 18 passed**. Scenarios 1 and 2 fail with `sweep.released` **empty**. **Cause:** `seedTask` relied on task creation's PROMPT.md, which is a bootstrap seed (`"# <id>\n\n<description>"`). FN-7648's `isUnplannedForExecution` reads that file for any card resting in an intake- **or** hold-trait column and refuses to move an unplanned card into a processing column. The sweep reported `held: [{ reason: "move-rejected-or-no-slot" }]`. **That is the gate working.** The fixture was asking the scheduler to release a card that had never been specified. The fix is the one the graph-entry contract doc already prescribes: *"Scheduler/release test fixtures must model a card that cleared the gate ... A held unreviewed card is the gate working."* `seedTask` now writes a planned PROMPT.md. **Verified it repairs main, not just this branch:** applying only that file to a detached `origin/main` leaves scenarios 1 and 2 **passing**, with the 4 residual failures being scenarios 3 and 6 — which need the fixture-options commit main does not have. ### I was wrong in #2627 and this corrects it In #2627 I named the in-transaction capacity gate (#2488/#2499) as the likely cause. **It was not.** Two hypotheses died, both recorded in the code comment so nobody re-runs them: | Hypothesis | Result | |---|---| | E2E settings lack `maxConcurrent` → capacity gate rejects the move | added `maxConcurrent`/`maxWorktrees` → **still 2 failed**. Not the cause. | | the move itself is refused | a direct `moveTask(id, wip)` → **succeeded**. Never the blocker. | Only then did probing the two release gates give `isTaskBlockedOnApproval=false`, `isUnplannedForExecution=true`, and dumping the file show the stub. I've flagged the wrong lead on #2627 too — a plausible-sounding cause pointed at another worker's PR is worse than no lead. ## 2. E2E evidence: the MERGED intake+hold board U11's shape — one column carrying intake **and** hold — had no end-to-end coverage; every prior E2E drove intake and hold as separate columns. - shared fixture gains opt-in `mergedIntakeAndHold`, plus `MERGED_VOCAB` (legacy ids, so a failure is attributable to the **role** merge alone) and `MERGED_RENAMED_VOCAB` (ids move too). - lifecycle scenario 3 drives the full spine: planning runs **in place** on the dual-role column, the real `runHoldReleaseSweep` releases **from** it, the graph runs to complete. - 4 merge-safeguard cases on the merged board (finalize, proofless refusal with the same reason, merged+renamed landing no legacy id, at-most-once). ## 3. E2E evidence: a REVISE routes back through rework The plan's `InReview → InProgress: review requests changes` had **no** live-engine evidence on any board — the fixture's review seam always succeeded. Two things the engine taught me, both corrected here: - the **IR validator refused** my rework edge: it is only legal into a node with `config.reworkRegion: true`. A real contract, and the validator catching it is the system working. `exec` now declares it (the shape the builtin uses on `merge-attempt`). - my first assertion was wrong. A REVISE does **not** leave the card in wip — rework re-enters `exec` within the same run, review approves on its second call, and the card finishes at complete. The evidence is the **seam sequence** `["planning","execute","review","execute","review","merge"]`, not an intermediate column the run has already passed. Asserting the final column alone would have been satisfied by a graph that ignored the REVISE entirely. ## Both families are mutation-attributed | Scenario | Mutation | Result | |---|---|---| | 3 — merged intake+hold | `isHeldTask` treats intake/hold as exclusive | **exactly its 2 tests** fail | | 6 — REVISE → rework | disable rework re-entry in `workflow-graph-executor` | **exactly its 2 tests** fail | Both fixture options are opt-in; the two pre-existing suites are behaviourally unchanged (27 → 29 → 41 passed across the additions, no existing assertion touched). ## Still not shipped: safeguard 2's graph E2E Attempted twice, deleted both times. Attempt 1 passed and then survived mutating `merge-gate` to ignore `task.autoMerge` — the card parked on the review column's `merge-blocker` trait, not the gate. Attempt 2 removed that trait to isolate the gate, and the **control** case parked too. Isolating it needs a merge path mirroring the builtin (`merge-gate → merge node → end`) rather than a direct edge to `end` — a real redesign, not a speculative edit. The enforcement that holds today is `allowInReviewMergeProcessing` in `project-engine` (unit-mutation verified, NEW=9; gated via #2526). 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:23:32 -07:00
gsxdsm	eb874f3da3	convert(cli/commands/task.ts): triage guard 1 → 0 (+ a live main regression in the lifecycle E2E release path) (#2627) ... **Batched push, gate open.** One conversion; the two E2E commits are held back and the reason is below — it is the more important half of this PR body. ## Conversion | File | triage column comparisons before | after | |---|---|---| | `packages/cli/src/commands/task.ts` | **1** | **0** | `pnpm test:gate` green, `pnpm lint` clean. All four non-terminal columns rendered the **same** glyph, so the four id comparisons were only ever asking "is this column terminal?". Naming `triage` made it a lifecycle-vocabulary site for no behavioural reason — the merged Planning column dropped that id, so the comparison silently stopped matching while the output stayed correct **by accident** (the fallthrough gave it the same glyph). Behaviour-identical **only** because the loop iterates the legacy `COLUMNS` constant (`types/board.ts:27` — exactly the six ids), so `col` can never be a custom id. Stated because the forms **diverge** outside that set: the old chain fell through to the terminal glyph for an unrecognised id, the new form returns the non-terminal one. If this ever iterates workflow-resolved columns that difference becomes live, and the right answer is a trait lookup, not this. **Deeper bug deliberately untouched, for U12:** because the loop iterates the legacy enum, a card in a workflow-renamed column **is not rendered at all**. That is R8's surface change, far bigger than this glyph. *(Note: this file is not on the 45-guard list, so it will not move your count. Flagging so the numbers reconcile.)* --- ## ⚠️ Live regression on origin/main — the lifecycle E2E release path While rebasing to push, the flagship lifecycle E2E went red. **I verified it on `origin/main` alone, with none of my commits: 2 failed / 18 passed.** ``` scenario 1 — DEFAULT vocabulary → AssertionError: expected [] to include 'FN-E2E-1' (r.sweep.released is EMPTY) scenario 2 — RENAMED vocabulary → audit trail differential broken: renamed produced [{end},{review}], default produced [] ``` Both are pre-existing tests I have never touched. **The capacity release sweep is releasing nothing.** **Likely cause, from reading rather than bisecting** — so treat it as a lead, not a verdict: `moves.ts:1059` now resolves a capacity pool id and enforces `enforcePooledColumnCapacity` **inside the move transaction** (#2488 "bind the in-transaction capacity gate", made user-visible by #2499 "make the capacity gate actually bind for real projects"). The E2E drives with `settings = { experimentalFeatures: { workflowGraphExecutor: true } }` — **no `maxConcurrent`** — while the fixture's wip column declares `{ trait: "wip", config: { limitSetting: "maxConcurrent", countPending: true } }`. If the resolved limit is finite and the pooled count meets it, the hold→wip move is rejected on capacity and the sweep correctly reports nothing released. If that is right, it is a **test-harness/production interaction, not a product break** — but it means the program's primary end-to-end evidence for the capacity boundary is currently inert on main, which matters for completion criterion 3. It needs the capacity worker's eyes, since #2488/#2499 are theirs and I would be guessing at the intended pool/limit contract. ## Why my two E2E commits are held They add scenario 3 (merged intake+hold board) and scenario 6 (REVISE → rework), both of which **depend on the same release leg**. On current main they fail for main's reason, taking the file from 2 failures to 4. Pushing them would add red to the count you are tracking and obscure whose regression it is. Both are complete, mutation-attributed, and green against the commit I wrote them on: | Scenario | Proves | Mutation that fails it | |---|---|---| | 3 — merged intake+hold | capacity release works from a dual-role column | `isHeldTask` treating intake/hold as exclusive → exactly its 2 tests | | 6 — REVISE → rework | `InReview → InProgress` on renamed *and* merged boards | disabling rework re-entry → exactly its 2 tests | They go out in the next batch the moment the release path is green. ## Also not shipped, twice attempted, deleted both times Safeguard 2 (`autoMerge:false` terminal-until-human) still has **no** graph-level E2E. Attempt 1 passed and then survived mutating `merge-gate` to ignore `task.autoMerge` — the card was parking on the review column's `merge-blocker` trait, not the gate. Attempt 2 removed that trait to isolate the gate, and then the *control* case parked too, so the flag still was not the discriminator. A fixture that can isolate it needs a merge path mirroring the builtin (`merge-gate → merge node → end`) rather than a direct edge to `end` — a real redesign, not a speculative edit. The enforcement that actually holds today is `allowInReviewMergeProcessing` in `project-engine` (unit-mutation verified, NEW=9; gated via #2526). 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 22:04:59 -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	88df46bedb	test: re-green executor-workspace onto FN-6756's contract (+ flag a dead branch) (#2617) ... **Test-only.** One file. No production changes. `executor-workspace.test.ts`: **2 failed / 10 passed → 13 passed**. (This commit was pushed earlier and I failed to open its PR — the work was finished and sitting on a dangling branch, which is why `executor-workspace` still shows in main's failure census.) ## Why it was red Both cases asserted that `clearPhantomExecutorBinding` **succeeds** while session-registry paths are held. PR #2531 (FN-6756, P0: *"stop reaping worktrees out from under live planners"*) inverted that. `hasLiveSessionSurface` now includes `activeSessionRegistry.pathsForTask(taskId).length > 0`, and that guard runs **before** both branches — so any registered path refuses the clear. The FNXC note at `executor.ts:2729` says the kind-blind guard is deliberate: *"A leaked entry now blocks THIS sweep rather than a live planner losing its worktree — the strictly safer failure."* So the old expectations describe the pre-#2531 contract. Rewritten to the current one, which had **no direct coverage**: a refusal leaves `activeWorktrees` and the registry entries untouched. The FN-6736 KTD2 invariant ("every held path, not one") is kept, exercised with no registry paths so the guard permits it. **Verified the new tests guard:** removing the registry term from `hasLiveSessionSurface` fails 2 of them (`NEW-failures=2`), and only them. ## Flagged, not fixed — a possible dead branch The guard appears to make **both branches it precedes** unreachable for their stated purpose: - the default branch exists to unregister every held registry path (FN-6736); - `preserveWorktrees: true` exists to **keep** those paths so a `moveTask(preserveWorktree: true)` re-dispatch reattaches to the same worktree (FN-7249) — and its **only** production caller is the self-healing reclaim at `self-healing.ts:3565`. Both need registered paths to do anything, and the guard rejects exactly that case. With none registered, one sweeps nothing and the other preserves nothing. The third new test pins this so the conflict is **executable rather than prose**: `preserveWorktrees: true` returns `false` while the path it exists to preserve is registered. I did not "fix" it by rewriting the assertion to match production — that would bury a possible regression in FN-7249's reattach path. Resolving it (exempting the non-destructive `preserveWorktrees` path, or narrowing the guard by kind) is a product decision for the FN-6756 owner. ## Main's engine-default census, measured just now | Point | Failed | Files | |---|---|---| | when I started this sweep | 283 | 28 | | after the logger-mock fix (#2573) | 106 | 23 | | **now** | **65** | **12** | This PR clears one of the remaining 12. `executor-review-verdicts.test.ts` is newly red and in my lane — taking that next. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:37:14 -07:00
gsxdsm	d438cd1d13	U12 drift: register-task-workflow-routes.ts — resolve the intake column (7 -> 1) (#2614) ... **File claimed: `packages/dashboard/src/routes/register-task-workflow-routes.ts`.** Per-file lifecycle-column guard count: **7 → 1**, and the 1 is comment prose (line 3758), so this file is done for completion-bar item 1. ## The bug this fixes `retrySpecification` decided "this Retry is a re-plan, not a generic retry" with `task.column === "triage"`. `status: "planning"` is retryable **only** through that flag — it is not in the generic `failed`/`stuck-killed` set. So on any lineage whose intake column is not literally named `triage`, a card visibly sitting in planning got `400 Task is not in a retryable state`. The operator's Retry button did nothing, with no error to explain why. Post-#2515 that includes the **default** workflow: `columnsWithFlag(resolveDefaultWorkflowIr(), "intake")` is `["todo"]` and the default's columns are `[todo, in-progress, in-review, done, archived]` — `triage` is not declared at all. The pre-existing `todo` fallback below it papered over the default case (it fires when the workflow has no `triage`), which is why this did not show up as a total outage; custom and renamed lineages had no such cover. Now: `const retryIntakeColumn = await resolveIntakeColumnForTask(scopedStore, task.id)`. ## Red-green, measured `packages/dashboard/src/__tests__/plan-approval-intake-column.test.ts` — new case, custom lineage with intake `backlog`, card in `backlog` with `status: "planning"`: - with the change: `200` - with `task.column === "triage"` restored: **`AssertionError: expected 400 to be 200`** The fixture uses `planning` deliberately. A `failed` fixture would pass either way through the generic retryable set and prove nothing. ## What is NOT tested, and why not This PR also removes four `&& task.column !== "triage"` disjuncts I added earlier while widening the P0 approve/reject guard. **Those are untestable by construction** and I am not claiming coverage for them: removing an extra acceptance only shrinks what the guard accepts, and no case can feed these routes a `triage` card now that no shipped lineage declares one. I re-widened one guard and confirmed the suite stays green — i.e. nothing depends on the disjunct in either direction. That is the honest result, not a passing test. ## Three fixtures updated, not guards re-widened `stranded-refinements-routes.test.ts` failed with three `expected 400 to be 200` — the same failures that made me widen in the first place. This time I probed instead: `BASE_TASK` had `column: "triage"`, a column the default workflow no longer declares, so a 400 is **correct** and the fixtures were pre-merge artifacts describing a board shape the product stopped shipping. Changed to `column: "todo"` with the resolver output recorded in the file. ## Observation, deliberately not fixed here The `todo` fallback at ~2642 (`retrySpecification = !workflowHasColumn(workflowIr, "triage")`) is now near-dead: for the merged default the first branch already fires. It survives only for a lineage that has a `todo` column, no `triage`, and some *other* intake column — where treating a `todo` card as planning is arguably wrong. Deleting it is a behaviour change with its own blast radius, so it does not ride along in a conversion commit. ## Verification `pnpm lint` clean. `pnpm test:gate` green (10 / 482 / 71). Target suites: `plan-approval-intake-column.test.ts` 8/8, `stranded-refinements-routes.test.ts` 12/12. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:34:31 -07:00
gsxdsm	1469d57477	U12 drift: ListView.tsx — one tested column-role helper (5 -> 0) (#2620) ... **File claimed: `packages/dashboard/app/components/ListView.tsx`.** Per-file lifecycle-column guard count: **5 → 0** (3 live, 2 in comment prose that described the deleted code). ## What was actually wrong All three live sites were *already* flags-first. The defect was that each carried its own inline copy of the same fallback: ```ts targetFlags ? Boolean(targetFlags.intake || targetFlags.hold) : column === "todo" || column === "triage" ``` Three copies, none reachable from a test, each reading like a lifecycle rule rather than the degraded mode it is. A fourth copy was the natural next step. ## Why the fallback survives instead of being deleted `columnFlagsById` is legitimately empty in two states: the pre-load window before the workflows fetch resolves, and a card stranded in a column its workflow no longer declares. A bare `flags.intake === true` returns false in both, and **both failures are silent** — the Planning badge stops appearing, and a backwards move stops asking whether to preserve step progress, so the operator loses completed steps with no prompt and no error. Deleting the fallback is not the cleanup it looks like. So it is kept, named (`isPreImplementationColumnRole`, `isIntakeColumnRole` in `app/utils/columnRoles.ts`), defined once, and documented with that reason at the definition. The legacy ids now live in a named `LEGACY_PRE_IMPLEMENTATION_COLUMN_IDS` set — a last-resort guess, not a comparison masquerading as a rule. ## Tests, and the case that never had one `app/__tests__/columnRoles.test.ts` (6). The degraded branch is now covered for the first time — it was unreachable while inline inside two `handleMove` closures and a `useCallback`. It also pins the **inversion** a fourth copy would eventually get wrong: a resolved column whose traits say it is *not* pre-implementation must not be overridden by an id that happens to be `todo` or `triage`. That is the direction that trains operators to dismiss the prompt. Mutation-checked, measured: | mutation | result | |---|---| | ignore the flags argument (`return LEGACY_….has(columnId)`) | **4 failed / 2 passed** | | ignore the id fallback (`return Boolean(flags?.intake \|\| flags?.hold)`) | **4 failed / 2 passed** | ## Behaviour preservation `ListView.test.tsx` + `workflow-resolved-columns.test.tsx`: **260 passed**, unchanged. The extraction is a pure move — the two helper bodies are the inline expressions verbatim, with the id set hoisted. `pnpm lint` clean. `tsc -p tsconfig.app.json` clean (the app config, not the root one that silently skips `app/`). No changeset: behaviour-preserving refactor. ## Backlog measured on `origin/main` at time of writing 48 total. `self-healing.ts` (10) is the capacity worker's; `register-task-workflow-routes.ts` (7) is my #2614. Remaining unowned in this area after this PR: `TaskCard.tsx` 4, `TaskDetailModal.tsx` 3, `TaskContextMenu.tsx` 2, `Column.tsx` 2, `taskActivity.ts` 2. Several of those hold the *same* fallback pattern and can now call this helper rather than grow another copy. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:23:46 -07:00
gsxdsm	89d6d76d60	Unowned: the R7 sweep guessed with another workflow's columns — its "do not guess" guard was unreachable dead code (#2600) ... ## Unowned: the R7 sweep's "do not guess a column" guard could not fire Picked up from my own #2543 finding. Independent of my other PRs. ### The guard existed in comment form only `reconcileUndeclaredTaskColumns` wraps IR resolution in a try/catch whose comment reads: > An unresolvable workflow is its own fault path; do not guess a column. But `resolveWorkflowIrById` catches **every** failure and returns `defaultCodingWorkflowIr()`, and `resolveWorkflowIrForTask` does the same for a failed selection read. The resolver never rejects, so that catch is **dead code**. What actually happened to a card whose workflow could not be loaded: it was judged against the **default** workflow, and if its column was not one the default declares, the sweep re-homed it to the **default's** rebound target. It guessed, using a workflow that is not the card's own — the precise outcome the guard was written to prevent, in a **startup recovery path that runs against every task**. ### How it was found, which is the part worth keeping By being **unable to make a test of the guard fail**. Three separate mutations all passed — deleting the `continue`, deleting the try/catch, and simulating a whole-sweep abort at that very catch. I had written that off once as "this case pins the outcome, not the mechanism". The inability was the signal, not a limitation of the assertion: the branch is unreachable. This is the seventh instance of the program's core shape, and the first I found in a guard I had just finished writing coverage for. ### The fix The sweep now **proves the resolved IR belongs to the task** before moving its card: it reads the task's workflow selection and confirms that id resolves to a real definition (built-in or stored). - A task with **no** selection legitimately resolves to the default workflow — not treated as unresolvable. - An unreadable selection **read** is itself grounds not to guess. Placed at the **move site**, not at resolution, deliberately: it costs one definition read only for a card already about to be moved — a healthy board reaches that line for nobody — and it keeps the fix inside the sweep instead of changing a resolver whose soft-failure many other callers depend on. Changing `resolveWorkflowIrById` to reject would have been the tidier-looking fix and a much wider blast radius. ### Revert-proof, both directions - Remove the proof → the case fails `expected 2 to be 1`: the unloadable card is re-homed on a guess. - The same case asserts the neighbour **is** still repaired, so the fix cannot be mistaken for letting one bad card disable the sweep for everyone else. That is the per-task isolation property, and a single-task fixture cannot distinguish it from a whole-sweep abort — verified by injecting a throw at the loop head (`expected 0 to be 2`). ### Verification `pnpm test:gate` (482 + 10 + 71), `pnpm lint`, engine typecheck green. Sweep suite + `legacy-tombstones`: 13 passed. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Prevented startup recovery from moving cards into incorrect columns when their workflow cannot be loaded or resolved. * Cards with unreadable workflow information now remain in place, while other recoverable cards continue to be repaired correctly. * Added safeguards to avoid guessing a fallback workflow during column reconciliation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:21:04 -07:00
gsxdsm	534798dea0	test(U9): E2E evidence for the merge safeguards on a real PG store (completion-bar item 3) (#2615) ... **U9 E2E evidence.** One new `.pg.test.ts`, 6 tests, green. No production changes. `pnpm test:gate` green — `pgDescribe`-skipped without PostgreSQL, so the gate is unaffected. ## What this closes The U9 safeguard baseline verified all six merge safeguards by **mutation at unit level**. The sibling `workflow-merge-family-live-e2e` covers exactly **one** end-to-end. This drives `finalizeProvenAutoMergeTask` — the last move a card makes — against a real PostgreSQL `TaskStore`, asserting on the **persisted column** read back after clearing the task cache. Never on "a function was called". Only the merge **proof** is seeded (`mergeDetails.mergeConfirmed`), which is what a real merger writes; there's no git and none is needed. Column resolution, blocker evaluation, the move and its guards, and persistence are all real. Includes the rename differential, where a guard keyed on a literal goes silent. ## Three things I expected and measured wrong Corrected in the file rather than worked around — each is a claim I would otherwise have shipped: **1. Dependency gating does not reach this seam.** My first draft asserted a refusal. A proven-merged card with a live `blockedBy` finalizes to the complete column anyway. That's coherent: dependency gating lives in `getTaskCompletionBlocker` and gates whether work may be *called* complete, while this seam runs after `mergeConfirmed` — refusing would strand a merged card in review and misreport the repository without un-merging anything. Now pinned as designed behavior *with* that reasoning, not filed as a hole. **2. The at-most-once outcome is `already-done`**, not the `already-complete` I guessed. **3. `expect(outcome).toBe("blocked")` cannot attribute a refusal.** The finalizer has **three layered refusal gates**, and the two proof gates emit the *same* reason (`missing-merge-confirmation`, also returned by `validateWorkflowDoneMergeProof`). So removing either one left my original assertion **green**: | Mutation | Result | |---|---| | remove the durable-proof gate | 6 passed — invisible | | remove the main-path proof gate | 6 passed — invisible | | remove **both** | **2 failed** / 4 passed | Fixed by pinning the **reason**, not just the refusal. The lesson generalises: single-gate mutation cannot detect redundant defense-in-depth from outside, so the unit-level attribution in the baseline doc and this E2E are **complementary**, not duplicative. I nearly labelled these tests as proving a specific gate they don't. ## Flagged, not changed — safeguard 1 at this seam Written as open questions and answered by running them. **Both a `paused` and a `userPaused` proven-merged card are moved to the complete column.** For `paused` that's documented design — `auto-merge-finalization.ts:243` evaluates hard blockers with `paused: false` because the branch already landed. For `userPaused` it sits against the invariant re-ratified in #2486: *never MUTATE lifecycle state of a user-paused card.* The mitigating argument is the same one — the merge is durable, so the move is bookkeeping that reflects reality, and refusing would leave an operator's card permanently misfiled in review. **Either reading may be right. What was not acceptable is that it was untested.** Both are now explicit named assertions with the tension in the comment, so tightening the pause contract becomes a decision rather than a discovery. Resolution belongs to whoever owns the pause contract — I'm not quietly changing merge behavior on a paused card. ## Safeguard coverage after this PR | # | Safeguard | Unit (mutation) | E2E | |---|---|---|---| | 1 | user pause | ✅ | ✅ pinned as an exception at this seam — flagged above | | 2 | autoMerge:false | ✅ | ✗ gate lives upstream in `project-engine`, not this seam | | 3 | dependency gating | ✅ | ✅ pinned as *not* applying here, with rationale | | 4 | capacity single-flight | ✅ | ✗ in-memory pump, no store seam to observe | | 5 | merge-proof | ✅ | ✅ both vocabularies, reason-attributed | | 6 | at-most-once | ✅ | ✅ second finalize classifies `already-done`, no second move | The two gaps are stated rather than implied: safeguard 2's gate is `allowInReviewMergeProcessing` in `project-engine`, which needs an engine harness rather than a store one, and safeguard 4 is an in-memory single-flight latch with nothing persisted to assert on. Both are covered by mutation at unit level and both are in the gate as of #2526/#2569. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:20:17 -07:00
gsxdsm	592fd5c0c6	U11 [mission-feature-sync + spec-staleness]: convert the last two planner-lane guards (48 -> 46) (#2610) ... **Taking: `engine/mission-feature-sync.ts`, `engine/spec-staleness.ts`** — the last two planner-lane guards in my area. ## Census (comment-stripped, `=== "triage"` / `!== "triage"` in `packages/*/src`, tests excluded) | file | before | after | |---|---:|---:| | `packages/engine/src/mission-feature-sync.ts` | 1 | **0** | | `packages/engine/src/spec-staleness.ts` | 1 | **0** | | **repo total** | **48** | **46** | ## Both are real conversions, not seams Each guard takes its vocabulary from the **caller**, which holds the store — so unlike a defaulted parameter nothing passes, these can actually be driven. **`reconcileMissionFeatureState`** — a card back in a planner lane returns the mission feature to `triaged`. Keyed on literals, a renamed workflow left the feature reading `in-progress` forever: the roadmap claims work is underway while the card waits to be re-planned. Nothing errors; the rollup is just wrong. The vocabulary arrives via `MissionFeatureSyncContext` rather than by widening this module's deliberately narrowed `Pick<TaskStore, "getTask">`. **`shouldSkipSpecStalenessForPreservedProgress`** — returning `false` for a planner-lane card is what *keeps* staleness evaluation on. Miss the lane and it falls through to the preserved-progress branch, so a card with progress skips staleness and keeps a spec that should have been re-validated. ## The two take different defaults — and I got it wrong first I defaulted **both** to the `triage`/`todo` pair and broke the pre-existing U11 proof in `spec-staleness.test.ts`, which states the reason exactly: > same column, different status, opposite correct answer - **mission-feature-sync → the PAIR.** It asks "is this card waiting to be planned?", true in either lane. - **spec-staleness → the DEDICATED planner column only.** On a merged lineage `todo` is *also* the hold lane, so the planner distinction there is carried by **status** (`planning` / `needs-replan`), not by the column. Treating the merged column as a planner lane stops a parked card with preserved progress from skipping staleness. Its default is now the single legacy id — byte-identical to the literal it replaced. That asymmetry is now pinned by its own test rather than left for the next reader to rediscover. ## Findings on the remaining census, from measuring it Two of the 46 are **not lifecycle-column guards** and converting them would be wrong: - `tool-availability.ts:32` — `surface === "triage"` where `surface: "triage" | "executor"` is an **agent lane**, not a column. - `skill-resolver.ts:432` — `sessionPurpose === "triage"`, a **session purpose**. Also worth noting for the count: `replan-target.ts` reads as 2 in a raw grep but is **0** — both hits are inside comments. `board-workflows.ts` (2) and `archive-planning.ts` (1) are likewise comment-only. A raw grep says 52; comment-stripped says 46. ## Not wired at the call sites yet `scheduler.ts` / `mission-autopilot.ts` (mission sync) and `executor.ts` / `scheduler.ts` (staleness) still omit the new option, so behaviour is byte-identical today. Deliberate: `executor.ts` belongs to u8's active slice and I would rather not create a textual collision for a pass-through. The seam is proven by tests and the count is real; wiring is a follow-up. ## Verification - **Mutation-verified:** restoring either literal fails a test - 35 tests green across the three suites, merge gate green (482 + 132 + 10), tsc clean, lint clean No changeset: `@fusion/engine` is private. 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-07-29 21:20:09 -07:00
gsxdsm	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	45e8b5f7ac	U8: pin the completion-finalize ordering invariant before moving the last out-of-band exit (#2599) ... Groundwork for moving `paused-after-completion`, the **last** out-of-band exit. Stacked on #2590. ## What lands 1. **An indentation defect I introduced.** My bulk edit when the exit vocabulary landed left the second `paused-after-completion` site mis-indented inside a `finally` block. Cosmetic, but misleading indentation in a `finally` is how a future reader misjudges scope. 2. **The adjacency ratchet now requires `markCompletionFinalized` before the handoff, at every reporting site.** It previously checked only the first occurrence, and only for the handoff itself. That ordering is the invariant `handleGraphFailure` depends on and **cannot check for itself**: `alreadyFinalizedToReview` / `completionFinalized` exist to recognise this out-of-band move when a later teardown re-marks the abort as `hard-cancel`. Without the durable marker set first, a completed no-commit task is re-parked `failed` — FN-6644/FN-6641. It is asserted **structurally, and labelled as such in the test**. Both call sites sit in pause and `finally` paths that cannot be driven without mocking an entire agent session; presenting a source assertion as behavioural coverage would repeat the overclaim I have been correctly pulled up on twice in this unit. Red-green: removing `markCompletionFinalized` from either site fails the ratchet. ## Why the move itself is not in this PR `paused-after-completion` is structurally harder than the pending-review ending that #2590 moved, and the difference is worth recording before someone assumes it is a copy-paste: - it does **four** things, not one — `markCompletionFinalized`, `handoffTaskToReview`, `clearCompletedTaskWatchdog`/`signalTaskComplete`. Only the handoff is lifecycle; the rest is substrate that must stay put. - one of the two sites is inside a **`finally`**. Moving a transition out of a `finally` is not the same operation as moving one out of a branch: the graph may already be unwinding, so "report and let the graph route" needs a defined answer for a run that is already ending. - there is **no behavioural coverage of either site today** — the closest tests only exercise the exit vocabulary. The pending-review move succeeded on the fourth attempt precisely because FN-5436 existed to catch each wrong version; this exit has no equivalent, so the move needs that floor built first, and building it means real session mocking rather than a shortcut. ## Verification - exit-events + primitive-exit-events + step-session + ownership ledger — green - `pnpm lint` clean; `tsc --noEmit` clean - No user-facing behaviour change, so no changeset 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Bug Fixes** - Improved handling of workflow steps that pause for review. - Tasks now remain in review when a review request has no subsequent decision. - Added clearer completion events for primitive prompt steps. - Preserved correct failure handling when later workflow steps fail. - **Workflow Improvements** - Built-in workflows now route pending reviews through a dedicated review handoff. - User-authored workflows retain compatible review parking behavior when routing is unavailable. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 21:04:39 -07:00
gsxdsm	3f763cba87	U8: the graph owns the pending-review park — ownership ledger 28 → 27 (#2590) ... The routing move this unit has been building toward, landing on the path the engine actually runs. **Includes #2578's commit** (the live-path fix it depends on) — merge that first, or this supersedes it. ## What changes Three things together, because a half-routed move is a card that silently does not advance: 1. The **live** implementation primitive (`runCodingSession`) returns `{outcome: "failure", value: "review-pending"}` for that ending. 2. The primitive step handler stops flattening every ending to `step-done`/`step-failed`, so the value survives the foreach — `runForeach` propagates a failing instance's value as the node's own — and reaches an edge. 3. The inline `handoffTaskToReview` in `runImplementation` is **deleted**. The phase reports and stops, which is all an implementation phase should do. Built-in workflows route to the `review-pending-handoff` node added in #2519/#2546, which performs the handoff and ends the run: the same two effects in the same order, with the graph as the owner. ## Proof, end to end FN-5436 — the test that blocked this move twice and was right both times — now passes, with a **stronger** assertion than it had: ```ts expect(store.moveTask).toHaveBeenCalledWith("FN-5436-B", "in-review", expect.objectContaining({ workflowMoveSource: "workflow-graph", workflowMoveMetadata: expect.objectContaining({ nodeId: "review-pending-handoff" }), })); ``` The old two-argument `moveTask(id, "in-review")` could not distinguish a graph-owned park from an out-of-band one — which is the entire distinction this unit exists to make. The invariant (park in review, never `failed`) is unchanged; the owner is now proven. ## Every ratchet fired, and each records a real change | Ratchet | Before | After | Why | |---|---|---|---| | Ownership ledger — `runImplementation` review handoffs | 3 | **2** | the handoff left the phase | | Ownership ledger — `handleGraphFailure` | 0 | **1** | the named compat classifier | | Ledger headline — executor-owned dispositions | 28 | **27** | first decrement of the unit | | Out-of-band exit list | 2 | **1** | pending-review is graph-owned now | | Primitive routing pin | "must not reroute" | routes *only* the moved ending | declared, not discovered | None was relaxed. The `handleGraphFailure` 0 → 1 is the honest one: for a user-authored graph without the edge this is a **relocation, not an elimination** — the transition is still executor-performed, but from one named classifier in the failure ladder rather than a call buried two thousand lines into a session loop. The ledger says so rather than letting the headline number imply more progress than there is. ## Why it took four attempts Recorded because the reason is reusable: the value was being produced on `createAuthoritativeWorkflowSeams`, a handler that never runs (#2578). Every earlier attempt was correct code on a dead path, and the only thing that showed it was instrumenting until a negative result was proven observable rather than assumed. ## Verification - step-session + exit-events + primitive-exit-events + ownership ledger + graph-requeue-gate + task-done-blocked — **83 tests green** - `pnpm test:gate` green (10 / 482 / 71); `pnpm lint` clean; `tsc --noEmit` clean - Changeset included (`patch`, `internal`) 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved handling of tasks awaiting review so they are correctly routed to the review workflow. * Tasks now remain in review instead of being marked as failed when no follow-up review route is configured. * Review handoffs now include workflow ownership and provenance details. * Preserved standard failure handling for tasks that are not awaiting review. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:59:06 -07:00
gsxdsm	d5f1ce7abd	U11 [writes]: stop CREATING cards into a column the workflow no longer declares (9 -> 0, engine+cli) (#2603) ... **Taking: `engine/triage.ts`, `engine/pr-comment-handler.ts`, `engine/eval-followups.ts`, `cli/commands/task.ts`, `cli/extension.ts`** (write class — no collision with the comparison backlog). ## A class the census does not count The 48-guard work list tracks `=== "triage"` **comparisons**. These are `column: "triage"` **writes** — and post-#2515 every one creates a card directly into the state STALL 3 was about, except **manufactured continuously** rather than left behind by the upgrade. ## Why they bite `createTaskImpl` resolves the column as: ```ts column: input.column || options?.resolvedEntryColumn || fallbackIntakeColumn || "triage" ``` `input.column` **wins**, so an explicit `column: "triage"` overrides the workflow's resolved intake column entirely. `store-create-intake-column.test.ts` already pins that a create with **no** column lands in the default workflow's intake (now `todo`) — these callers opted out of it. The sharpest is `triage.ts`'s `fn_task_create` agent tool: it passed `workflowId: params.workflow_id` **and** `column: "triage"` in the same call. The caller chose a workflow and the column ignored it — a Coding (Ideas) create landed in `triage` instead of `ideas`. ## Counts **Comparison guards: unchanged by this PR.** This is the write class; conflating the two would misreport convergence toward the zero bar. | file | `column: "triage"` writes before | after | |---|---:|---:| | `packages/engine/src/triage.ts` | 1 | **0** | | `packages/engine/src/pr-comment-handler.ts` | 1 | **0** | | `packages/engine/src/eval-followups.ts` | 1 | **0** | | `packages/cli/src/commands/task.ts` | 3 | **0** | | `packages/cli/src/extension.ts` | 3 | **0** | | **total** | **9** | **0** | ## A test that pinned the defect `pr-comment-handler.test.ts` asserted `column: "triage"` in the createTask call — so it would have **failed the fix and passed the bug**. Rewritten to assert the invariant (the caller passes no column, so the workflow's intake wins) plus an explicit `Object.hasOwn(arg, "column") === false`, which is what actually catches a reintroduction. ## Interaction with #2591 My merged #2591 rescues these cards once created — they sit on a legacy planner id their workflow doesn't declare and are still in planning stage. So this isn't a *visible* stall today; the rescue absorbs it. **That's the reason to fix it rather than leave it:** a self-healing path silently absorbing a steady stream of malformed creates is exactly how the underlying defect stays invisible. ## Deliberately not touched - `{ id: "start", kind: "start", column: "triage" }` in the builtin coding / PR / lead-generation IRs — workflow-internal **node declarations** for workflows that still legitimately declare a `triage` column, not lifecycle writes. - Left for their owners: `core/task-store/project-store-ops.ts:210`, `core/task-store/update-task-deps.ts:111` (main worker), `dashboard/src/routes/register-gitlab.ts:108` (u12). Same defect, same one-line shape. ## Verification - 304 engine/CLI tests green across the affected suites - merge gate green (482 + 132 + 10), engine + CLI tsc clean, lint clean No changeset: `@fusion/engine` and `@fusion/core` are private; the CLI change is a bug fix with no user-facing API change — happy to add one if you'd rather it appear in release notes. 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-07-29 20:58:52 -07:00
gsxdsm	9c1c6f7479	docs(engine): close the unproven-sites ledger — one entry was wrong, the rest need two named lanes (#2544) ... Comment-only change to the ledger. No test or production code moves. ## Why this is a PR and not a note The ledger is the artifact that keeps *"the E2E covers the conversion"* honest. It gets the same treatment as the code: claims verified by mutation, not by reading. ## Correction: one entry was wrong `core/task-store/reads.ts` was listed as **unproven**. It isn't. Core's `store-stale-paused-renamed-hold.pg.test.ts` is a real-store test that drives `listTasks` against a renamed hold column — and forcing the hydration back to the `todo` literal **fails exactly that file's renamed case**. I had listed it as unproven because I assumed a separate E2E was needed. Verified *before* removing it, since "already covered somewhere else" is precisely the assumption that lets a gap hide. ## What remains, and why it is not another table row **Lane 1 — real git.** `merger.ts`'s `resolveMergerLifecycleColumn` and `executor.ts`'s `resolveReboundColumnFor` are module-private helpers whose only callers sit inside merge/session machinery needing a real worktree, branch and squash; `merger-ai.ts` is the same. Re-checked with the lens that freed `auto-merge-finalization` and both self-healing rebounds — **these genuinely need the lane.** The earlier over-broad claim doesn't retroactively excuse them. **Lane 2 — dashboard HTTP.** The four `register-task-workflow-routes` sites sit behind `registerTaskWorkflowRoutes(ctx, deps)`, needing a full `ApiRoutesContext` plus twelve injected deps. Standing that up is the mock-the-world shell FN-5048 says not to add. The narrower alternative — exporting the two private resolvers — yields **unit** evidence while looking like E2E. Deliberately not done rather than done badly and overclaimed. `live-agent-count`'s `columnIsIntakeOrHold` is the same lane: only the *waiting* predicate reads it, and its consumers are dashboard-side. ## Running total **10 of 15 census sites proven end to end** across six suites; 5 remain, each named with the lane it needs. ## Verification - lifecycle suite 20/20; engine `tsc --noEmit` clean; `pnpm test:gate` green (414 + 10 + 71) 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Tests** * Updated end-to-end test coverage documentation to accurately reflect verified workflow and task-store behavior. * Clarified coverage gaps for live agent-count logic and dashboard workflow routes. * Added a two-lane breakdown describing remaining coverage work. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:56:04 -07:00
gsxdsm	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	c9df4b9dee	U11 migration proof: the path an operator actually hits, with all three caveats answered (#2597) ... Tests only. Proves the upgrade path the existing E2E does not cover, and answers the three caveats. ## Why the existing coverage was not enough The existing cases strand a card in a synthetic `a-column-no-workflow-declares` on a **fixture** vocabulary. The real upgrade leaves cards in **`triage`**, on the **real `builtin:coding`** workflow. That difference is the whole point: `triage` is still a legal `ColumnId` and is still declared by legacy-coding, Ideas and every linear built-in (R11), so nothing rejects it and **nothing throws**. The card simply sits in a column its *own* workflow no longer declares — where it carries no trait flags and is invisible to every trait-driven sweep. ## What is proven, on a temp PostgreSQL project - A card left in the deleted `triage` column on a default-workflow board is re-homed to `todo`, the merged Planning column. - **Revert check in-suite:** without the sweep running, the card stays in `triage`. Without this, the case above could pass because some *other* sweep or a store-open reconcile moved the card — and would keep passing if the sweep were deleted outright. - **Progress and the plan artifact survive.** `preserveProgress: true` is asserted end-to-end rather than trusted from the option name. - A `userPaused` card is skipped and stays in the deleted column. **Mutation-verified:** stubbing `reconcileUndeclaredTaskColumns` to `return 0` turns **5 of 11** tests red, including all three positive migration cases. The sweep is demonstrably the mover. ## The three caveats — answered **1. `userPaused` cards are skipped → caveat, not a stall.** An operator park is authoritative and the sweep must not override it, so the card does stay in a column its workflow no longer declares. But it is reachable two ways: unpausing makes the next sweep re-home it, and **U11's undeclared-source escape hatch in `resolveAllowedColumns` (merged with #2515) lets an operator move it by hand meanwhile** — that path returns the workflow's rebound target instead of `Valid targets: none`. Recorded as a test so the behaviour is a decision rather than an accident. My recommendation: **leave it skipped.** Re-homing a paused card silently moves work an operator deliberately froze, and the escape hatch already gives them a way out. Overriding a park to fix a column is the wrong trade. **2. Sweep only runs when self-healing is enabled → caveat, not a stall, for the same reason.** The escape hatch lives in the **move-validation** path, not in self-healing, so it works with self-healing off entirely. A card stranded that way is draggable out of the deleted column by hand. Worth knowing: before #2515's escape hatch this *would* have been a hard stall — `resolveAllowedColumns` returned `[]` for an undeclared source, so the card could not be moved anywhere at all, by anyone. **3. Re-home targets the HOLD column → correct, and progress survives.** Under U11 the hold column **is** the Planning column, so "everything lands in Planning" is the intended destination rather than a compromise. Asserted with real step progress on the row. **None of the three is worse than a caveat.** The reason all three are survivable is the same single mechanism — the undeclared-source escape hatch — which is worth knowing because removing it would silently promote all three to hard stalls. ## Incidental Fixed two fixture-level PostgreSQL column-name errors found while writing this: `currentStep` → `current_step`, and `user_paused` is an **integer** flag rather than a boolean. Both would have made a future test here fail confusingly. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:31:15 -07:00
gsxdsm	a3a7f16977	Drift 4/4: reset reported a successful reset as a 409 "limbo" conflict — plus the audit verdict for every other site in the file (#2582) ... ## Drift 4/4 — a second live bug in the routes file, plus the audit for the rest of it **Stacks on #2571** (the P0). Merge that first. ### The bug `POST /tasks/:id/reset` resolves its destination through `resolveReboundColumnForTask` — the task's own workflow rebound column — and then verified the outcome against the literal `todo`. **Twice.** So on any workflow whose rebound column is not `todo` — Coding (Ideas), any custom or renamed lineage — a reset that **succeeded** was reported as a `409` "limbo state" conflict. The mover and its own verification disagreed about where the card was supposed to land. Both checks now compare against `resetColumn`, which is already in scope two lines above the first one. ### Revert-proof, after I caught my own vacuous test My first version of this test **passed with the fix reverted**. The reset route demands `{ confirm: true }` and was 400ing before it ever reached the column check, so `expect(status).not.toBe(409)` was trivially true. That is the third time in this program a route/DOM assertion has looked like coverage while checking nothing, and the second time I have caught it in my own test. With the confirmation sent, the reverted form fails: `expected 409 not to be 409` — a correctly-reset card reported as limbo. ### Audit of the remaining sites in this file | site | fires after #2515? | verdict | |---|---|---| | 2597/2607 manual retry | yes | **SAFE, by design.** Falls back to a `todo` branch gated on the workflow declaring no `triage` column — exactly the merged shape. Written for Coding (Ideas); the merge made the default match it. | | 4584 respecify | yes | **SAFE.** Already `column === "triage" \|\| column === respecifyTarget`, and `respecifyTarget` resolves the intake column. | | 2887/2917 reset verification | **no** | **FIXED here** — false 409 on a successful reset. | | 1121 awaiting-planning enrichment | partially | **BROKEN, deliberately not converted** — see below. | ### The one I chose not to convert, and why `1121` filters on `column === "todo"`, so a workflow whose waiting lane is named otherwise gets no enrichment and silently falls back to the heuristic. I converted it and **reverted**. Resolving each task's hold column needs a per-task workflow read, and this is the board-load path whose own comment exists because unbounded reads here *"turn a board load into thousands of reads"*. My version did those reads for **every task before the enrich limit applied** — trading a silent degradation for a load-time regression on every board. Converting it properly needs the hold column resolved per **workflow** from data the board payload already carries, not per task from the store. That is a real change with a measurable cost, not a rename. Left with the cost written at the site rather than quietly skipped, and flagged here so it is tracked rather than forgotten. ### Verification `pnpm test:gate` (414 + 10 + 71), `pnpm lint`, dashboard typecheck green. Route suites: 9 passed, including `stranded-refinements-routes.test.ts` unchanged at 5. ### My drift set, final | file | before | after | PR | |---|---|---|---| | `TaskCard.tsx` | 8 | 3 | #2558 | | `ListView.tsx` | 5 | 3 | #2566 | | `taskActivity.ts` (found underneath) | 1 | 1 | #2566 | | `TaskDetailModal.tsx` | 4 | 3 | #2577 | | `register-task-workflow-routes.ts` | 10 | 11 → 9 | #2571 + this | Routes went 10 → 11 in #2571 (guards widened to accept resolved-intake **or** `triage`, so a P0 fix could not reject anything previously allowed) and back to 9 here. Every other survivor is the documented no-metadata fallback: flags are absent during the pre-load window and for a card stranded in a vanished lane, and a bare trait read would drop the affordance in exactly those states. They retire with the load window, not with a rename. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:31:02 -07:00
gsxdsm	131feb243c	U8: the exit announcement was on a dead code path — move it to the handler the engine actually runs (#2578) ... A merged behavior of mine has never executed. This fixes it and adds the ratchet that would have caught it. ## The finding `createDefaultNodeHandlers` chooses the prompt-node handler like this: ```ts const promptLike = deps?.primitives ? createPrimitivePromptLikeHandler(deps.primitives, runCustomNode) : createPromptLikeHandler(seams, runCustomNode); ``` `executeWorkflowGraph` always passes `primitives: this.createAuthoritativeWorkflowPrimitives(settings)` (`executor.ts:6051`). **So `createPromptLikeHandler` — and with it every `execute` / `step-execute` function in `createAuthoritativeWorkflowSeams` — is unreachable for prompt nodes.** Both objects are passed to the graph executor and only one is consulted. The `NodeCompleted.exit` announcement added in #2507 was wired into that seam. It type-checks, its tests pass (they call the seam object directly), and it has never run in production. `runCodingSession` in the primitives is the live twin, and that is where it emits now. ## How it was found — and why the negative is trustworthy Instrumenting `createAuthoritativeWorkflowSeams.stepExecute` produced no output for a run that demonstrably visits `steps#0:step-execute`. So did instrumenting `createPromptLikeHandler`'s dispatch. A negative result from instrumentation is worthless until the instrumentation is shown to be observable, so: a `process.stderr.write` at module load of the same file **did** appear, exactly once, in the same run. The two negatives were real, not swallowed output. This is also the answer to the open question I left in #2546 — the pending-review routing move kept failing because the seam value it depends on is never produced. **That move is still not landed here.** This commit only relocates the announcement, so it stays small and separately revertable; the routing move follows once its value originates on the live path. ## The ratchet A source assertion pins the dispatch rule: `deps?.primitives ? createPrimitivePromptLikeHandler` and the executor's wiring of `primitives`. Inverting or conditionalising that preference would silently disable every behavior attached to the primitives path — the same failure in the other direction — and **a seam-level unit test cannot tell the two apart**, which is precisely how this survived review twice. ## Red-green Removing the emit fails 2 of the 4 new tests (`Tests 2 failed | 2 passed (4)`). The other two are the regression floor: an ordinary completion emits `success` with no `exit`, and the returned routing outcome is unchanged — announcing must not reroute. ## Scope note I did **not** delete the now-known-dead seam wiring in this PR. `createAuthoritativeWorkflowSeams` is still passed to the graph executor and its non-prompt entries (`stepReview`, `merge`) are reached through other handlers, so deciding what is genuinely dead there is a deletion audit of its own — and this program's rule is that deletions never ride along with behavior changes. Filed as the next slice. ## Verification - 4 new tests + exit-events + step-session + triage audit + ownership ledger — **54 tests green** - `pnpm test:gate` green (10 / 414 / 71); `pnpm lint` clean; `tsc --noEmit` clean - Changeset included (`patch`, `fix`) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:30:54 -07:00
gsxdsm	2aa68867e5	U11 follow-up: usage-limit parking silently stopped covering the planning lane (#2567) ... Second of the 39 audited `triage` sites from #2515's safety audit. Unlike the first, this one is **real breakage**, not a proof of safety. ## The defect The usage-limit pauser decides which tasks are on a rate-limited provider by asking, per lane, whether the card sits in that lane's column. The **planning** lane asked for the literal `triage`. Now that Todo is merged into Planning, a card being planned on the default workflow rests in `todo`. The branch resolves to an empty provider list, so the card is not recognised as using the planning provider — and is **neither parked when that provider hits its limit nor resumed when it recovers**. It runs into the limit and fails. Silent by construction: the detector reports nothing, it simply matches no tasks. ## The test caught my own first attempt at testing it The initial version asserted on the task that **triggered** the usage-limit hit — and **passed against unfixed code**, because the trigger is always parked directly without consulting `taskUsesProvider`. Only a **bystander** card reaches the lane/column branch. All three assertions now use a separate trigger, and the comment says why, because the obvious test shape is the one that proves nothing. ## Why a paired literal rather than trait resolution `taskUsesProvider` is a synchronous predicate over a task and settings, with no IR in scope and no call site that could supply one without a signature change reaching several callers. Both ids name a pre-implementation column in every built-in — `triage` for the split shape, `todo` for the merged one and for Coding (Ideas) — so the pair covers the planning lane in all of them. Flagged for U12's ratchet allowlist with that reason attached. **Over-inclusion is the safe direction and is deliberate.** On a split workflow a `todo` card is capacity-parked rather than actively planning, so it may now be parked during an outage it was not using. Parking one extra idle card is recoverable; failing to park a card whose provider is rate-limited is not. Regression direction asserted: widening the **column** match must not widen the **provider** match — a planning card on a different provider is still not parked. ## Audit progress 39 exclusive `triage` sites (from `docs/solutions/architecture-patterns/u11-triage-literal-safety-audit.md`, merged in #2515): | status | sites | |---|---| | proven safe as-is | `spec-staleness.ts` — the guard is carried by **status**, not column; the mechanical conversion was tried and is *wrong* | | confirmed safe by inspection | `mission-feature-sync.ts` (already OR-pairs), `TaskContextMenu.tsx` (already trait-paired) | | **fixed here** | `usage-limit-detector.ts` | | remaining | 35, with the owners named in the audit | Gate 309/309, lint clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:30:47 -07:00
gsxdsm	94e4b7453d	U12 part 11: CONCEPTS.md taught the legacy enum as the model — and told operators column agents need a flag that no longer exists (#2545) ... ## U12 part 11 — CONCEPTS.md taught the legacy enum as the model, and one entry was simply false Docs only. No changeset: AGENTS.md excludes internal docs from changesets. ### The one that is an error, not staleness `CONCEPTS.md` → **Column agent**: > Requires both the workflow-columns and graph-executor flags; with either off, bindings are inert at execution time. **That kill switch was removed.** `executor.ts` says so at the binding site: > the former workflowColumns kill switch was removed, so stale persisted false values cannot silently disable custom-node, seam, or watcher bindings So the shared vocabulary document was telling operators that a shipped feature depends on a flag that no longer gates it — and, worse, that a stale persisted `false` would disable it. Anyone debugging "why isn't my column agent running?" would have been sent to a flag that has nothing to do with it. Corrected, with the history kept in one clause so it stays legible to anyone who remembers the old behaviour. ### The one the plan named `CONCEPTS.md` → **Task** defined the entity as moving "through columns (triage, todo, in-progress, in-review, done, archived)" — teaching the legacy enum as the model, in the document whose whole job is shared vocabulary. The plan lists this entry explicitly as U12 scope. It now says a Task moves through the columns **its workflow declares**; that two Tasks on the same board may have entirely different column sets; and that the six familiar ids are the **Default workflow's choice** — which is why they saturate stored data — rather than a property of the model. ### The same class, one doc over `docs/dashboard-guide.md` restated a trait rule as an id list: "Eligible existing tasks (triage, todo, in-progress, in-review)". The implementation gates on traits — `isMutableLiveColumn` is `complete !== true && archived !== true`. Now stated as the trait rule, with the Default workflow's ids as an illustration rather than the definition, so a renamed or custom workflow reads correctly against this doc. ### Left alone deliberately The **Column (workflow-defined)** and **Default workflow** entries already describe the workflow-scoped model accurately. Their references to the legacy enum are about the Default workflow *specifically*, which is exactly where naming those ids is correct — removing them would make the docs less true, not more. This is the same judgement as declining to delete `downgradeIrToV1IfPure` earlier in the unit: legacy vocabulary describing a legacy-shaped thing is not drift. ### Verification Docs only, no code paths touched. The factual claims were checked against source rather than assumed: the kill-switch removal against `executor.ts`, and the trait rule against `TaskContextMenu.isMutableLiveColumn`. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:30:40 -07:00
gsxdsm	b0b9614fd5	U12 part 10: pin the R7 undeclared-column sweep — the repair three earlier PRs cited had no test of its own (#2543) ... ## U12 part 10 — the R7 sweep everything else leans on was itself unpinned `reconcileUndeclaredTaskColumns` re-homes a card resting in a column its workflow no longer declares. It is the shipped answer to **R7**, and it is the reason several earlier U12 deletions were safe — I cited it when deleting the superseded `runWorkflowColumnsIntegrityPass` (#2500), and again when arguing that a torn workflow switch leaves *recoverable* state (#2512). Its only coverage was **incidental**: two live PostgreSQL e2e suites that exercise it in passing. A repair the rest of the unit leans on had no test of its own — a guarantee everyone cites and nobody checks, which is the exact shape this unit keeps finding. ### Six cases The plan names three scenarios for U12; those are the three ways this sweep can be wrong, plus I added the over-fire direction: - repairs the stranded card to its workflow's **own** rebound target (not a hardcoded legacy id) - leaves a **user-paused** card alone - leaves an **unresolvable-workflow** card alone - is **idempotent** — a second run does not move the card again - ignores a card already resting in a declared column - repairs one stranded card **without disturbing** healthy or paused neighbours The leave-alone cases matter more than the repair. A sweep that over-fires rewrites an operator's board, and this one runs at startup against every task. It also asserts `recoveryRehome: true` explicitly, because that flag is load-bearing rather than incidental: the stranded card's *source* column is undeclared too, so adjacency resolves to `[]` and every target is rejected without it. Its absence once made this sweep a repair that never repaired anything (#2462). ### Mechanism coverage — measured, and one case that isn't Verified by mutation rather than asserted: | mutation | result | |---|---| | delete the user-pause guard | **2 cases fail** | | delete the already-declared short-circuit | **2 cases fail** | | delete the unresolvable-workflow `continue` | still green | That last row is stated at the assertion rather than hidden. The unresolvable-workflow case pins the **outcome**, not the mechanism: every mutation I could construct — dropping the `continue`, dropping the try/catch so the throw reaches the outer handler — also ends in "no move". So it is a regression guard on observable behaviour, not proof the specific guard is reached, and I am not claiming otherwise. ### A decision I made Store double rather than PostgreSQL. The sweep's decisions are pure functions of the task list and the resolved IR, and a double makes the "did **not** move" assertions exact rather than inferred from an absence of change. It also keeps the suite off the slow lane, per the standing rule against adding slow tests. ### Verification `pnpm test:gate` (414 + 10 + 71), `pnpm lint`, engine typecheck green. New suite: 6 passed. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Tests** * Added coverage for automatically restoring tasks stranded in undeclared workflow columns. * Verified paused tasks, unresolved workflows, and tasks already in valid columns remain unchanged. * Confirmed repairs are idempotent and affect only the intended task. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:30:27 -07:00
gsxdsm	88c7502eae	test(engine): prove the recovered-lease rebound AND its audit on a renamed board (#2539) ... Test-only. Sixth E2E family. Closes the `mesh-lease-manager` ledger entry. ## Two things to prove, and only one is where the card lands The conversion note records the defect precisely: > They were previously two independent `=== "todo"` comparisons that could disagree, which is how **the audit came to claim a card landed in `todo` when the workflow has no such column**. 1. the card rebounds to the renamed workflow's own rebound column 2. the unreachable-owner **audit** reports the column the card actually reached **(2) is the half that rotted silently, and it is the worse one.** The audit is what an operator reads to find out where a recovered card went. Confidently wrong is worse than absent — and on a renamed board it named a column the workflow does not even declare. ## One thing deliberately NOT renamed `decisionPath` keeps its legacy `lease-recovered-to-todo` wording. The code explains why: it is a stable discriminator that existing queries and dashboards match on, and renaming it would break them in order to describe the same decision. The column actually used travels in `newColumn`. I've pinned that split with an explicit assertion so a future vocabulary "cleanup" cannot quietly rename a field that **is not a column at all**. Stating it here so it reads as a decision rather than an oversight. ## Mutation-verified Forcing the legacy literal fails **exactly the three renamed cases**, leaving the default-vocabulary floor and the fresh-lease negative green. ## Negative half A lease renewed just now is not recoverable — "rebound anything with a checkout" would tear live work off its owner. ## Fixture guard The stale-lease seed writes lease bookkeeping through the admin client and then **asserts the seed took effect**. A silently-dropped write would make the recovery look correctly declined — the same trap that produced a vacuous paused-park test earlier in this program, so it is now guarded by default. ## Verification - six live-E2E suites green together: **58/58** - engine `tsc --noEmit` clean - `pnpm test:gate` green (414 + 10 + 71) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 20:30:19 -07:00
gsxdsm	30e0a8f291	U11 P0 audit: no hard stall in the recovery block — and one obvious fix is wrong (#2570) ... Docs only. Answers the P0 question per site: **does it still fire, what silently stops happening, is there a backup?** ## Headline: no hard stall The alarming reading — *"the orphaned-planning-status sweeps stop finding default cards, so a card whose planner died sits with `status:"planning"` forever, invisible to discovery"* — **does not hold.** `triage.ts`'s `sweepStalePlanningStatuses` is the **periodic primary** for that repair and already tests `column !== "triage" && column !== "todo"`. It covers the merged column. The two self-healing sweeps perform the same repair and are **redundant nets**, not the sole rescue. That is the difference between a P0 and a cleanup, and it is only visible by reading the **backup** path rather than the broken guard. Recorded so nobody re-derives the panic. ## Self-healing block, by blast radius | site | fires? | what stops | backup | verdict | |---|---|---|---|---| | `:12106`, `:12427` | no | clearing a stale `planning` status | `triage.sweepStalePlanningStatuses` | redundant net lost — **cleanup** | | `:2961/2981/3016` `recoverAdvancedTriageTasks` | no | re-homing a card with a worktree + durable IR pin to its **pinned** resume column | hold-release still releases it on capacity (real spec ⇒ `isUnplannedForExecution` false) | **degraded, not stuck** — fix first | | `:12254` | no | a bounded priority nudge | none needed; the doc says nudge, not rescue | **low** | | `:12151`, `:9151` | **yes** | — | already OR-paired | **safe** | **Second-order trap at `:3016`.** It skips when `resumeColumn === "triage"`, guarding against resuming a card into the column it already occupies. Post-merge the pinned column is `todo`, which is **not** skipped — so pairing the literal at `:2961` *without* also pairing `:3016` produces a `todo → todo` move. **Repair the three together.** ## Two sites in the ownership split are already handled - **`usage-limit-detector.ts:126`** (assigned to u8) — already fixed in **PR #2567**. Real breakage: the planning lane stopped being recognised, so a card being planned was neither parked when its provider hit a usage limit nor resumed when it recovered. - **`spec-staleness.ts:95`** (assigned to u7) — already proven safe as-is, merged with #2515. **Its obvious fix is wrong.** I tried `|| task.column === "todo"` and it turned an existing test red: it breaks the parked-preserved-progress path. ## The generalisation, which is the most useful thing here **On the merged column, `todo` answers two different questions.** After the merge `todo` is both the planner column *and* the capacity-hold column. So any site that used `triage` to mean *"is being planned"* **cannot simply be paired with `todo`**, because `todo` also means *"is parked waiting for capacity"*. Those sites need **status or a trait**, not a wider literal. That is precisely the mistake a bulk conversion makes, and `spec-staleness.ts` is the worked example: the guard was already asking status, and widening the column would have destroyed the distinction. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 19:03:23 -07:00
gsxdsm	a68785a41d	P0: two silent triage guards in the executor's ownership — one strands a card with nothing to rescue it (#2572) ... P0 audit of the executor's assigned `triage` sites after the Planning-column merge. **One of them can strand a card**, so leading with that. ## The stall — `handleDepAbortCleanup` `executor.ts` moved a dependency-aborted task to the **literal** `triage`. The default coding lineage no longer declares that column. A card that gains a dependency mid-execution has its work discarded and is then parked in a column its own workflow does not define. Nothing in the graph routes a card out of an undeclared column. The only rescue is `reconcileUndeclaredTaskColumns`, which runs on the **next engine start** — so between the abort and a restart the card is stalled with no automatic recovery. It does not throw, so it would have surfaced as a user report, not a red test. Fixed to `resolveReboundColumnFor`, the helper the other ~16 executor rebounds already use. ## The silent skip — `UsageLimitPauser.taskUsesProvider` The planning lane was identified by the same literal. For a default card the lane resolved to **no providers**, so when a provider hit a usage limit during a *planning* session, the fan-out that pauses peers on that provider skipped every default-workflow card and they kept hammering the rate-limited provider. Not a stall: the triggering task is still paused by the explicit fallback below the filter. What was lost is blast-radius containment. A planning session runs while the card is pre-implementation, and the caller has already excluded `done`/`archived`, so that is exactly "not the implementation column and not the review column" — which matches `todo`, `triage`, `ideas`, and a renamed planner alike. ## Full audit table for my assigned sites | Site | (a) Still fires for a default card? | (b) What silently stops | (c) Action | |---|---|---|---| | `executor.ts:16395` `moveTask(id, "triage")` | **No** — writes an undeclared column | Card parked where nothing routes it; rescue only at next engine start | **Fixed** — `resolveReboundColumnFor` | | `usage-limit-detector.ts:126` `column === "triage"` | **No** | Usage-limit fan-out skips every default card; peers keep hitting the limited provider | **Fixed** — pre-implementation predicate | | `executor.ts:3409` `from === "todo" \|\| from === "triage"` | **Yes**, via the `todo` arm | — | Unchanged; `triage` arm still live for legacy-coding | | `executor.ts:4951` `originColumn === "todo" \|\| === "triage"` | **Yes**, via the `todo` arm | — | Unchanged | | `executor.ts:4963` `originColumn === "triage"` double-hop | No, and correctly so | Nothing — the extra hop exists only for shapes that declare `triage` | Unchanged; still required by legacy-coding | | `executor.ts:1110` `Type.Literal("triage")` | n/a | — | **Not a column** — an agent ROLE in `spawnAgentParams` | Counts for my ownership: **6 sites audited, 2 defects, 2 fixed, 3 correct as-is, 1 false positive.** ## Red-green Reverting each fix fails its own test: ``` Tests 2 failed | 2 passed (4) × dependency-abort cleanup requeues to a DECLARED column × usage-limit fan-out … pauses a peer card sitting in the merged Planning column (id `todo`) ``` The other two are the regression floor and pass both ways by design: a legacy workflow that **does** declare `triage` still fans out, and an in-progress card is still **not** swept into the planning lane (the guard must stay narrow — "any non-wip column" would have been the easy wrong fix). ## Verification - New audit suite + graph-boundary + step-session + ownership ledger — **45 tests green** - `pnpm test:gate` green (10 / 414 / 71); `pnpm lint` clean; `tsc --noEmit` clean - Changeset included (`patch`, `fix`) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 19:03:10 -07:00
gsxdsm	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	beb33b5dd1	P0 STALL 3: rescue cards stranded in a column their workflow no longer declares (fixes 8 red tests on main) (#2591) ... Based on `main`. **Fixes STALL 3 — and it needs no data migration.** ## The stall #2515 removed `triage` from the default lineage while leaving the id legal for stored rows, and shipped **no migration**. Planning discovery resolves a card's lanes from its own workflow, and for a default card `intake` and `hold` **both** resolve to `todo` — so a card *sitting* in `triage` matched neither branch and was admitted by nothing. `triage` was the default intake column before #2515, so **every existing project has cards there.** Nothing else rescued them. #2515's escape hatch makes an undeclared source column resolve to the workflow's rebound target, but every path that *uses* it (executor, agent-heartbeat, merger) is triggered by **active work**, and a parked card has none. The card sat until an operator dragged it by hand. ## Proof this is a real regression, not a stale test **8 tests in `triage.test.ts` were RED on clean `origin/main`** — verified by swapping main's `triage.ts` into this tree and re-running. **All 8 pass with this change.** The sharpest: ``` expected "specifyTask" to be called 4 times, but got 0 times ``` Discovery was admitting zero triage cards. ## The fix A card resting on a legacy pre-implementation id that its own workflow no longer declares is **unowned by construction** — no lane's rules apply to it. Admitting it to **planning** heals it through the normal path: it gets planned, and finalize releases it to the workflow's hold column, **re-homing the row as a side effect of ordinary work**. No migration, no backfill, no operator action. ## The narrowing is the load-bearing part My first version rescued **any** undeclared column, and it was wrong. A card can also sit in a column its workflow genuinely owns while the **selection** fails to resolve — the resolved default IR then doesn't declare that column either. That version re-specified a parked Coding (Ideas) `ideas` card, breaking **FN-7596's manual-intake rule** (an ideas card is promoted by an *operator*, never auto-planned). `triage.test.ts` caught it. The rescue is now scoped to the legacy planner ids, so a workflow-specific column name is never second-guessed. That distinction — healing #2515's orphans vs. overruling a workflow about its own board — is the whole design. ## A user-pause hole this would have opened `couldBeCandidate` screens `paused` but not `userPaused`, so a row carrying `userPaused` alone slipped through. Harmless before (an undeclared-column card was admitted by nothing) and **reachable the moment admission widens**. Planning a card mutates its lifecycle state, which the ratified safeguard forbids for a user-paused card — so the guard is now explicit rather than inherited. Covered by a test and mutation-verified. ## Cost Resolution now derives roles **and** declared column ids from one `resolveWorkflowIrForTask` call, replacing `resolveTaskLifecycleColumns`. Same call, same `irCache`, same bounded concurrency window — **cost unchanged**, no added read. ## Verification - **Mutation-verified three ways**, each failing a different test: remove the rescue; widen it back to any undeclared column; drop the user-pause guard - 8 previously-red-on-main tests now green - 263 triage/scheduler tests green, merge gate green (482 + 10 + 71), tsc clean, lint clean ## What this does NOT do It does not re-home rows that are past the planning stage. Admission still requires `isTaskStillInPlanningStage`, so a card that advanced past planning in an undeclared column stays with self-healing's advanced-recovery sweep rather than being re-specified here. If such rows exist and are also stranded, that is a separate sweep and a separate PR. No changeset: `@fusion/engine` is private. 🤖 Generated with [Claude Code](https://claude.com/claude-code)	2026-07-29 19:02:55 -07:00
gsxdsm	a56253f426	P0: plan approve/reject rejects EVERY card on a merged planning column — operator-visible stall, cannot approve or reject (#2571) ... ## P0 — plan approve/reject is dead for cards on a merged planning column **This is the "card stuck with nothing to rescue it" case you asked to hear about immediately.** Found auditing my files after #2515. ### What happens #2515 removed `triage` from the merged default lineage — one pre-implementation column, id `todo`, displayed "Planning". Four routes guard with: ```ts if (task.column !== "triage") throw badRequest("Task must be in 'triage' column ...") ``` On a workflow with no `triage` column that condition is **true for every card**, so the routes reject all of them: | route | effect on a merged-lineage card | |---|---| | `POST /tasks/:id/approve-plan` | 400 — **cannot approve** | | `POST /tasks/:id/reject-plan` | 400 — **cannot reject** | | `task_refine` route (×2) | 400 — refine blocked | A card parked `awaiting-approval` can be **neither approved nor rejected**. It is stuck, the operator is being asked for a decision they have no way to give, and nothing throws to reveal it. ### Why it is the worst variant of this drift Everything we have chased so far is a guard that silently **stops** firing. This is a guard that silently starts firing on **everything** — same root cause, opposite symptom, and worse, because the failure is visible to the operator as a task that demands an answer and refuses every one. ### The fix, and a deliberate choice The guards resolve the workflow's own intake column through the existing `resolveIntakeColumnForTask`, and they **widen rather than replace**: a card is accepted if it is in the resolved intake column **or** in `triage`. That is on purpose for a P0. The fix cannot reject anything the route previously allowed, so it carries no regression risk of its own. Narrowing to the resolved column alone is a follow-up once the legacy id is gone everywhere — not something to do under time pressure on a route that gates operator decisions. I found the value of that when a strict replacement broke 3 pre-existing tests in `stranded-refinements-routes.test.ts`. The widened form passes all of them **and** the new P0 cases. ### The convergence number goes UP, and I am not hiding it Live-code `column === / !== "todo" | "triage"` in `register-task-workflow-routes.ts`: **10 → 11**. Each converted guard keeps the legacy id as an explicit second condition, so a widened guard has two literals where it had one. The metric counts id literals; it does not know the guard is now strictly more correct. Reporting the direction that is true rather than the one that looks better — and flagging that this file's number will only fall once the widening can be removed. ### Revert-proof Restore either bare literal and the matching case fails with **400 where 200 is expected**, on a `todo` card with `awaiting-approval`. A third case pins that the guard still **narrows** — an `in-progress` card is still rejected — so this cannot be mistaken for deleting the check. ### Verification `pnpm test:gate` (414 + 10 + 71), `pnpm lint`, dashboard typecheck green. New suite 3 passed; `stranded-refinements-routes.test.ts` back to 5 passed (it was 3 failed under the strict form). ### Still auditing `TaskDetailModal.tsx` conversion is in flight on a separate branch. `TaskCard.tsx` (#2558) and `ListView.tsx` + `taskActivity.ts` (#2566) are already open — and note #2566 covers `isTaskAgentActive`, whose planner-lane clause has the *silent* version of this same bug: planning cards read as idle everywhere at once. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 11:11:50 -07:00
gsxdsm	3c46ecca14	Drift (unowned): the planner-activity signal was never written after #2515 — the three badge conversions were reading an empty field (#2594) ... ## Drift, unowned: the planner-activity signal was never being written **Stacks on #2577.** Merge order: #2566 → #2577 → this. ### This is what made the other three PRs cosmetic `addRecentPlannerActivityForFreshAgentLog` in `useTasks.ts` stamped `recentAgentActivityAt` **only for cards literally in `triage`**. #2515 removed that column from the default lineage, so after that merge the stamp never happened for a default-workflow card. Every consumer downstream then had **no data to act on**, however correctly it resolved its own column traits: - the pulsing Planning badge (TaskCard, ListView) - the agent-active row border - the column header's executing count So #2558 / #2566 / #2577 convert the *readers* of a field that nothing was *writing*. They ask the right question of an empty value. This is the fix that gives them something to read — and it was on nobody's drift list. I found it chasing why a badge test would not go green. ### The decision, and why I did not thread metadata here The hook processes SSE and has no resolved column metadata. The lane is matched by id against **both** shapes — pre-merge `triage`, post-merge `todo`. Over-stamping a legacy hold-lane card is harmless: every consumer additionally requires the column to be an **intake** lane before rendering anything, so the extra timestamps are filtered downstream. Threading board context into this hook to avoid a harmless over-stamp would be a much larger change for no behavioural gain, so I widened instead and wrote the reasoning at the site. ### Also converted `Column.tsx`'s move-progress prompt. Unlike the same prompt in TaskCard/ListView/TaskDetailModal, this component's `column` **is** the drop target, so its own `columnFlags` are the target's traits — no lookup needed. Worth noting because the same-looking regex meant three different things across four files, which is exactly why these were converted one at a time. ### Revert-proof Restore `task.column !== "triage"` and the merged-column case fails: `expected undefined to be '2026-07-28T12:00:01.000Z'` — nothing stamped, badge has nothing to render. A companion case pins that the stamp still **narrows**: an `in-progress` card is not planner activity. ### Verification `pnpm test:gate` (482 + 10 + 71), `pnpm lint`, dashboard typecheck green. `useTasks.test.ts` + `Board.test.tsx`: 210 passed. ### Audited and deliberately left | site | verdict | |---|---| | `Column.tsx:550` `workflowMode \|\| column === "triage"` | Dead in practice — `workflowMode` is true whenever lanes resolve, so the disjunct only matters with no metadata at all. Not worth a change. | | `taskSorting.ts:73` `column === "todo"` | Still correct for the default (the merged column keeps that id); wrong only for a renamed workflow's hold lane. Needs the sort to take flags — a wider signature change than this PR's scope, and cosmetic (ordering) rather than a lost affordance. | | `worktreeGrouping.ts:77` | Same shape as above; grouping only, no lost control. | Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 11:11:12 -07:00
gsxdsm	cf7b1a3d46	Drift review (unowned): gridlock detection + autopilot retries resolve the hold column — main 103→101 (#2561) ... > **Based on `main`, not on my U7 stack** — merges in any order, no dependency on #2517. My assigned files (`triage.ts`, `replan-target.ts`) are at zero, so this picks up two lifecycle-column literals **no unit's file list claims**. Both ask *"is this card in the hold column?"* by the id `todo`, and both are broken **today** for any workflow that renamed it. ## gridlock-detector — the worse of the two `column !== "todo"` decides which cards count as **schedulable**, and an empty schedulable set is an **early return**. On a renamed board the detector concluded *"no gridlock"* at exactly the moment a real one would be visible. > A detector that goes quiet on the boards it cannot parse is worse than one that is absent, because its silence reads as health. **Converting only the `todo` half would have shipped a still-broken detector**, and the test caught it. The `active` filter is equally literal (`in-progress` / `in-review`) — and an empty active set is *also* an early return. Two literals, one silence. The `in-progress` half sits **outside the drift review's `todo|triage` pattern**, which is precisely why a count-driven sweep would have left it behind and declared the file done. Converted here rather than deferred as out of scope. Worth flagging to the other workers: the convergence metric is a good *tracker* but a bad *definition of done* — an adjacent literal in the same predicate can preserve the whole bug at a lower score. ## mission-autopilot The retry compared against `todo` **and moved to the literal `todo`** — so on a renamed workflow it relocated the card into a column the workflow may not declare (R7) on **every retry**. Now resolves the hold role; when the workflow declares none it leaves the card in place and says so, because the error/status clear still runs, so the retry is not lost — the card just stays in its own lane. ## Two fixture defects of my own, both caught by the tests failing wrongly **My first autopilot tests re-implemented the decision** and asserted on the copy — proving only that the copy works. That is the anti-pattern named in `docs/solutions/store-fake-defects-that-masquerade-as-production-bugs.md` (#2534) and in the #2527 ratchet review, and I had no excuse: the constructor takes two stores and `handleTaskFailure` is public. Rewritten to drive the real method. **My first gridlock fixture failed on both vocabularies** — the detector needs three preconditions and I supplied one. A test that fails on its *no-regression* half is a broken fixture, not a discovered bug. The "both halves failed" heuristic from that same doc is what flagged it. That is eight fixture defects across this unit, every one caught by reading *why* a test failed rather than making it pass. ## Revert proofs, each isolated to one literal | Restored | Result | |---|---| | gridlock hold filter | **1 of 5 fails** (renamed case) | | autopilot move target | **1 of 5 fails** (renamed case) | Default-vocabulary halves pass either way — the correct signature for conversions that change no existing behavior. ## Convergence Measured against `origin/main` with a comment-stripped scan of `column === / !== "todo" | "triage"` in `packages/*/src`, excluding tests: **103 → 101.** (The gridlock `active` filter is a third site fixed here that this pattern does not count.) ## Verification | Check | Result | |---|---| | new suite | 5/5 | | pre-existing gridlock + autopilot suites | 85/85, **no expectation edits** | | `tsc --noEmit` (engine) | clean | | `pnpm lint` | clean | | `pnpm test:gate` | green (414 + 10 + 71) | | `pnpm check:changesets` | clean | ## Still unowned after this `mission-feature-sync.ts` (1: a planning-lane check) and `auto-claim-snapshot.ts` (1: `isRunnableAutoClaimCandidate`, a **pure sync** predicate that needs the injected-lane pattern from #2551, not a resolve). `notification-service.ts` has one more with a different semantic — *"has progressed past"* — which needs its own thinking rather than a mechanical swap. I will take these next unless someone claims them. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 10:54:35 -07:00
gsxdsm	bbaa254dc3	test: add the missing debug to 27 logger mocks (206 → 4 failures) (#2573) ... **Test-infrastructure fix.** 29 test files. No production code, no altered assertions, no widened timeouts. Now **3 commits** (#2584 merged into this branch): the logger-mock sweep, a cron-runner follow-up from review, and the 4 residual failures the sweep deliberately deferred. **Whole branch: 764 tests, 0 failures** across the touched set. --- ## Commit 1 — the missing `debug` on 27 logger mocks `createLogger`'s real shape is `{ log, debug, warn, error }`. 27 engine test files mock `../logger.js` with logger-shaped literals that **omit `debug`**, so any production path reaching `log.debug` threw: ``` TypeError: schedulerLog.debug is not a function TypeError: runtimeLog.debug is not a function TypeError: log.debug is not a function (SelfHealingManager.start) ``` Measured, same commit, same 27 files: | | Failed | Passed | |---|---|---| | before | **206** | 558 | | after | **4** | 760 | **202 failures fixed by one missing mock export.** Per-file: `notifier` 36→0, `plugin-runner` 56→0, `grok-runtime-routing` 14→0, `self-healing-completion-fanout` 1→0. That last one also leaked an unhandled rejection out of `startMaintenance`, which vitest warns "might cause false positive tests" elsewhere in the file. *A note on the number:* a full `engine-default` run went 283 → 106 across my two sessions, but `main` moved in between (U11 landed), so that spread is **not** attributable here. 206 → 4 is the honest figure: same commit, same file set, only this diff varying. ## Commit 2 — cron-runner's factory (greptile P1) My regex required `log: vi.fn()`; `cron-runner.test.ts` uses `log: cronLoggerSpies.log`, so the `createLogger` factory's returned literal never matched and the logger production received still lacked `debug`. **Measured before claiming a live fix, and the numbers don't support that part:** `cronLoggerSpies.debug.mock.calls.length` is **0** across all 155 tests, and the suite is 155 passed both before and after. The described failure mode — `tick()` hitting `log.debug`, throwing, and being swallowed by its own error handler — is **not reachable today**, because no test exercises those three branches (`cron-runner.ts:377`, `:385`, `:410`). The fix is defensive, not curative. The real gap it surfaced is **missing coverage** for schedule dedupe / scope mismatch / lost atomic claim, which I did not write blind to close a thread. ## Commit 3 — the 4 residuals **`notification-service` (3):** messages moved to DEBUG in production (`:580`, `:846`) while tests asserted `schedulerLog.log`. The token case needed more than a relocation. It asserted `expect(schedulerLog.log).not.toHaveBeenCalledWith(containing("new-token"))`. Moving only the *positive* assertion to `debug` would leave the secrecy check watching a channel the message no longer uses — a token could leak through `debug` and the test would still pass. The negative now runs across all four channels. **Verified it bites:** interpolating the token into the debug line fails the test. **`openclaw-runtime-integration` (1):** `../pi.js` mock missing `wrapToolsWithOutputBudget` (same class as #2547); this suite exercises a non-pi runtime, exactly where that wrapper applies. **Not swept repo-wide, and the measurement is why.** 37 `pi.js` mocks omit that export. Patching 30 moved the set from **11 failed to 10** — thirty files of churn for one test. Reverted. Commit 1 earned its 27-file diff with 202 fixes; this one earned nothing, and a no-op sweep is just future merge conflicts for other workers on this program. --- ## Why none of this is appeasement AGENTS.md forbids making a red test pass by loosening it. This does the opposite: the mocks were **wrong** — they claimed to stand in for `createLogger` while missing part of its interface. Nothing was relaxed; stubs were completed, and the one assertion I did move got **stronger** (four channels instead of one). ## Also deliberately not done Extending `scripts/check-mock-completeness.mjs` to catch this class. Measured first: a naive rule over relative intra-package mocks flags **147** factories of which **146 are green** — almost pure false positives. The barrel heuristic works because `cliSrc` gives a tight import surface; that doesn't transfer. A gate that noisy gets ignored, which is worse than no gate. ## How this was found While characterizing U9's review lane. These files were pre-existing baseline noise under mutation runs — and that noise is exactly what made my own safeguard baseline (#2511, corrected in #2520) report two false verdicts. **A red suite does not merely lack coverage; it makes every nearby measurement untrustworthy.** 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 10:50:46 -07:00
gsxdsm	d2ce1ba8b5	U11: resolve the scheduler's event-handler columns by trait (10 live sites, sync resolution) (#2518) ... Based on `main`. Ten live `"todo"` sites in `scheduler.ts` now resolve the column by trait. ## Four groups, converted together They fail **independently**, and a half-conversion is indistinguishable from a working system: | group | sites | failure mode | |---|---:|---| | **Wake triggers** | 4 | **Latency** — snapshot invalidation, mission-failure tracking, engine requeue tracking, move-to-backlog wake. The wake doesn't fire and the card waits up to a poll interval. Exactly why it would go unnoticed indefinitely. | | **Parked wakes** | 2 | Latency — unpause and planning-finished, keyed on hold OR intake. | | **Dependency** | 3 | **Not latency.** After a blocker completes or is soft-deleted, the query returns nothing, so the dependent is *never* unblocked and waits on a blocker that already finished. | | **Agent link** | 1 | `rollbackRunningAgentsForQueuedTodoTask` passes a synthetic `{ column: "todo" }`. Wrong here **drops a running agent's task link** — the worse direction of that safeguard. Resolved `parkedColumns` is now passed through too, rather than letting the helper fall back to its legacy default. | ## Resolution is synchronous, deliberately — the part worth reading My first cut used the async resolver and made the `task:updated` listener `async` to suit it. **That broke 5 pre-existing tests, and the tests were right:** introducing a new `await` *before* a listener's existing synchronous work defers everything after it to a microtask and reorders handlers relative to a synchronous emitter. A conversion must not change event ordering. It now uses the store's sync IR path (`resolveTaskWorkflowIrSync`), so **no new suspension point is introduced anywhere**. That's the fifth time in this program a change that looked like a move quietly altered behavior — and the first time the existing suite caught it before review. ## Verification - **Mutation-verified:** forcing the resolver back to the literals fails **4 of the 6** new tests - 110 tests green across all 8 scheduler suites (6 new) - Fail-soft to the legacy pair: an unresolvable workflow behaves exactly as before rather than losing the wake - merge gate green (309 + 10 + 71), tsc clean, lint clean ## Measured 10 of my unit's 68 remaining code sites converted. `scheduler.ts` now has **one** `"todo"` literal left in live code: `isRunnableQueuedOverlapCandidate`, which is **exported but has no production caller** — its only consumer was the legacy dispatcher deleted in #2505. That's a **deletion, not a conversion**, so it is deliberately not in this PR. No changeset: `@fusion/engine` is private. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Scheduling now correctly recognizes workflow-specific hold and intake columns, including renamed columns. * Tasks entering a hold column reliably trigger scheduling and wake-up behavior. * Dependency recovery now finds blocked tasks in renamed hold columns. * Planning, unpausing, task completion, deletion, and requeue flows now respect each workflow’s configured parked columns. * Prevented unnecessary scheduling for moves between unrelated workflow columns. * **Tests** * Added coverage for renamed hold-column scheduling, wake-up, and dependency-unblocking scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai -->	2026-07-29 10:44:12 -07:00