fusion

Author	SHA1	Message	Date
gsxdsm	b4ed12e9c8	batch-u7-lane-fixes: three core/engine renamed-board fixes folded (was #2925 , #2930 , #2936 ) (#2925 ) Consolidated per the queue freeze. Three single-fix PRs of mine folded into this one branch; #2930 and #2936 are closed as superseded. Net effect on the queue: 3 → 1. All three are the same root cause — a lifecycle lane compared against a legacy id — and all three carry a measured revert proof. Verified scoped (not full suite) on the folded branch: `tsc --noEmit` clean, `pnpm lint` clean, SQL-literal gate green, census `--strict` green, and 61 tests across five suites plus the guard at 9/9. --- ### 1. `getLiveTaskColumn` produced the archived sentinel from a literal (was #2925) `getLiveTaskColumn` manufactures the string `"archived"` that a dozen comparisons across five files trust — and it tested `row.column === "archived"`. A live row in a renamed archived lane read as live, so the gates hiding an archived card's artifacts and document listings never closed. Fixing those twelve comparisons individually would have been wrong twice over: they are sentinels, and the defect was in the producer. One line, once, and all twelve become correct. `resolveArchivedLanes` moved to `project-lane-vocabulary.ts` — three private copies of one fact is how the "write guard says yes, publication guard says no" disagreement happens at scale. Revert proof (real PostgreSQL): restore the literal → `expected [ { …(14) } ] to deeply equal []`. Caught myself shipping the unwired shape here: I added the parameter to seven functions and wired none of their impl callers — the exact inert-conversion defect this program exists to remove. The failing test is the only reason I noticed. ### 2. Mission delivery repair refused a completed card (was #2930) `getTerminalTaskEvidence` tested only `column === "done"`, so a completed card on a renamed board classified as `nonterminal` and `reconcileFeatureDoneWithTerminalTask` threw `TASK_NOT_TERMINAL: … not shipped`. Valid operator work refused — with the message naming the real column while the check couldn't see it. The type blocked the fix from the far end: `TerminalTaskEvidence` pinned `column: "done"` / `"archived"`, so the resolver couldn't report the real column without a compile error. `kind` already carries the role, so `column` is free to carry the truth. Revert proof (real PostgreSQL): restore the literal → `TerminalTaskReconciliationError: … not shipped`. I had deferred this twice on the premise that `AsyncMissionStore` "holds a layer, not a store". It holds an optional `taskStore`, and the single production construction site supplies it. ### 3. The unwired-lane guard reported two FALSE entries (was #2936) `unwired-lane-parameter-guard.test.ts` has been red on main since #2875, flagging two `InReviewDurationLanes` properties as unwired when the impl demonstrably supplies both. Cause: my own owner-scoping rule requires a mention from a file naming the declaring symbol — correct for a function, structurally impossible for an interface passed as an inferred object literal. Fixed at the caller (name the type) after trying the tool three ways: relaxing type-owned properties hid 12 genuine entries; resolving owners to consuming functions hid 6. Each refinement traded the false positive for false negatives — the sign a co-occurrence heuristic has hit its limit. Recording two wired parameters in `KNOWN_UNWIRED` was rejected: that puts non-debt in the debt list, which is how a ratchet starts lying. Guard back to 9/9, baseline unchanged at 17. This un-reds main. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 19:07:09 -07:00
gsxdsm	c6767cb258	self-healing: foreign-only contamination never cleared on a renamed board (fourteenth sweep) (#2891 ) `recoverForeignOnlyContaminatedInReviewTasks` classifies a branch carrying only foreign commits and clears the contamination park that nothing else clears. Two literal reads meant that on a renamed board it classified nothing, and the task stayed parked indefinitely. ## The two redundant guards were the interesting part Both filters carried a `task.column === …` check that was redundant while the query pinned the column. Under a resolved read they stop being redundant and become the per-card verdict — so they convert here rather than being deleted. Deleting them would have silently widened the sweep, which is the failure this whole class is about. ## Dedupe matters more here than elsewhere The concatenated candidate list is deduped (the P1 reviewed on #2879). It bites harder in this sweep because the two filters have different predicates: a column carrying both a review role and the wip role could satisfy both and classify one branch twice. Explicit `has` guard rather than `new Map(entries)` — that constructor keeps first insertion order but the last value for a repeated key, so it reads as first-bucket precedence while doing the opposite. (Corrected in #2879 and #2883 for the same reason.) ## Revert results Each applied alone and the file re-run: \| conversion \| reverted → \| \| --- \| --- \| \| the resolved reads \| fails — the card is never listed, so the classifier is never called \| \| the review verdict \| fails — the renamed review lane does not match and the card is filtered out \| Observable is candidacy: `classifyForeignOnlyContamination` runs once per accepted card and not at all for a rejected one, which is exactly the read-plus-verdict under test. It is a static named import, so it is intercepted with a scoped `vi.mock` (spyOn cannot rebind an already-resolved ESM binding); only that one export is overridden, so the sweeps in this file that use `inspectBranchConflict` are unaffected. A non-vacuous companion (same card in the board's hold lane → never classified) rules out a read that returns everything. ## Verification `pnpm test:gate` 161 + 487 + 13 + 71, plus `self-healing.test.ts` 412; `tsc` engine clean; `pnpm lint`, `check:changesets`, census `--strict` clean, each run explicitly. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 18:26:06 -07:00
gsxdsm	1dc839743e	census: tell the reader where a DELIBERATE-LITERAL marker has to go (#2909 ) A `DELIBERATE-LITERAL` marker in the wrong position is indistinguishable from no marker, and the miss is silent until CI. Measured on #2883: the marker sat inline in the middle of a conditional expression, so it attached to the wrong AST node and three reviewed literals scored as new debt (`self-healing.ts` 86 → 89). The message the tool printed at the time said "record why at the site with a `DELIBERATE-LITERAL` marker" — which I had done. Nothing in the output suggested placement was the problem. Two lines added to the failure message: - Markers are read from a node's leading comments, so put one on the declaration and hoist the literal into a named helper if needed. - `pnpm lint` does not run this census — CI's Lint job does. That is why the usual "lint passed locally, push" loop cannot catch either mistake, and why the tool itself is the only place a reader sees this in time. ## Verified, not assumed I induced a real failure (a temporary `t.column === "in-review"` guard in `self-healing.ts`) and read the printed output rather than trusting that the string lands in the right branch — the message has two branches and only one is the guard-count-rose path: ``` packages/engine/src/self-healing.ts: 89 -> 90 Resolve a lifecycle column from the task's own workflow (…) correct, record why at the site with a DELIBERATE-LITERAL marker. Put the DELIBERATE-LITERAL marker in the DECLARATION's leading comments, not inline in an expression: markers are read from a node's leading comments, so a mid-expression one attaches to the wrong node and is silently ignored. Hoist the literal into a named helper if you need to. Note that `pnpm lint` does NOT run this census — run it explicitly before pushing. ``` Guidance only — no scanner behaviour changes, so no counts move. ## Verification `pnpm test:gate` 161 + 487 + 13 + 71; `pnpm lint` and census `--strict` clean.	2026-07-30 18:09:31 -07:00
gsxdsm	60bfebdc98	fix(reliability): the duration query hid its lane ids inside a SQL template (#2875 ) The Reliability panel's third and last blind input — and my own loose end. #2861 fixed the two counts beside it, so the panel went from uniformly wrong to partially wrong: entries and bounces populated, duration reporting `no-in-review-entries` forever. Partial blindness is harder to notice than total, which is why finishing it matters more than one site suggests. ```sql metadata->>'to' = 'in-review' OR (metadata->>'from' = 'in-review' AND metadata->>'to' = 'done') ``` ## The class, not just the site This shape is invisible to every check we have. The lifecycle census scans `===`/`!==` comparisons; the unwired-lane-parameter guard scans declarations. Neither sees a lane id inside a `sql` template, so this class is not in the backlog total at all — the number is a floor for this reason as well as the usual one. `scripts/check-sql-column-literals.mjs` (#2841, in flight) is the detector for exactly this: it freezes the surface at 30 sites rather than converting any, so this one was unowned. That PR and this one are complementary — it stops the surface growing, this shrinks it by one. ## The fix Lanes resolve once per call via `resolveProjectColumnsForRoles` and arrive as parameterised equality fragments, one branch per id — no interpolated list, no string building. Resolution lives in `getInReviewDurationEventsImpl` because that is where the store is; `async-audit.ts` takes a bare `db` handle and cannot resolve anything. Best-effort, defaulting to the legacy pair, so a caller that cannot resolve keeps exactly today's query. The union is correct rather than a widening hack, for the same reason as #2861: these are move records, and a past move recorded the column name as it was at the time. A board renamed last month has rows under both ids, so the honest query covers both — which is precisely what `resolveProjectColumnsForRoles` returns. ## Tested against real PostgreSQL, deliberately This is a SQL predicate change. A mocked store would assert the arguments and prove nothing about the query that actually runs — which is the entire risk when the literal lives inside `sql`. The new case inserts real `activity_log` rows on a renamed board and reads them back through the real store method. The legacy-lane case in the same file stays green, which is the compatibility half. Revert proof, measured: restore the hardcoded fragments and the new case fails with ``` expected [] to deeply equal [ 'renamed-entered', 'renamed-done' ] ``` ## Verification - `pnpm test:gate` — 161 / 487 / 13 / 71 passed - `pnpm lint` — clean - `tsc --noEmit` (`@fusion/core`) — clean - `activity-log-parity.pg.test.ts` — 5 passed against real PostgreSQL With this, all three Reliability inputs read the board's own lanes. 🤖 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 * Reliability duration metrics now work correctly with renamed workflow lanes. * Completion tracking recognizes configured completion lanes instead of relying on fixed defaults. * Improved handling of transitions between multiple review lanes and review-to-work-in-progress movements. * Legacy lane behavior remains supported when configured lane information is unavailable. * Tests * Added coverage for renamed lanes, historical lane IDs, and transition 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-30 17:59:34 -07:00
gsxdsm	10f9df1600	fix(overseer): the whole oversight loop was inert on a renamed board (#2898 ) `resolveWatchedStage` keyed on the literals `in-progress`/`in-review`, so on a board that renames either it returned `null` for every card. That is three literals with an outsized blast radius. `observeTask` returns early on a null stage, so: - no `OverseerStageObservation` is recorded, - no `overseer:intervention` entry is emitted, - and `PlannerRecoveryController`, which consumes those observations, has nothing to steer, retry or targeted-fix. The entire oversight loop was inert and silent about it — the same shape as the self-healing sweeps whose queries returned empty arrays. ## I deferred this myself, on a cost argument that was wrong The audit note I wrote for this site said resolving inside `observeTask` "buys a workflow read per card per poll". Then I read the caller: the poll already awaits `resolveEffectiveSettings` per task. It is a per-task async loop regardless, so with an IR cache keyed by workflow the addition is (distinct workflows) resolutions, not (cards). Pricing the fix before checking the caller cost a deferral. Worth recording, because "this needs a cost judgement" is the most comfortable place in this program to leave something. ## The review test is the three-trait union, deliberately `isReviewColumnRole` checks only `mergeBlocker \|\| humanReview`. A board whose review lane carries `merge` (mergeOrchestration) — the built-in default's own shape — would classify as not in review and be skipped. Reaching for the obvious helper would have reintroduced the bug this change removes, through the helper meant to fix it. There is a case asserting exactly that. ## Wiring Both call sites, because either alone leaves a hole: \| site \| why it matters \| \|---\|---\| \| the poll (`project-engine.ts`) \| per-poll IR cache — a workflow edit is picked up next tick rather than served stale \| \| the manual nudge \| otherwise a renamed board answers `no-active-stage` to an operator pressing the button \| `columnFlags` is in the `unwired-lane-parameter` vocabulary, so the wiring cannot silently rot — the guard reports it if a future change drops the argument. Fail-soft throughout: an unresolvable workflow yields `undefined` and the callee falls back to the legacy ids, which is exactly today's behaviour. A v1 IR declares no columns, so it takes the same path. ## Revert proof (measured) Drop the `columnFlags` branch and exactly the three renamed-lane cases fail: ``` expected null to be "executor" expected null to be "merger" (mergeOrchestration lane) expected null to be "merger" (humanReview lane) ``` The legacy-id and neither-role cases stay green — the gate must still gate, and watching every column would be its own defect. ## Verification - `pnpm test:gate` — 161 / 487 / 13 / 71 passed - `pnpm lint` — clean - `tsc --noEmit` (`@fusion/engine`) — clean - `planner-overseer.test.ts` + `planner-recovery-controller-human-control.test.ts` — 64 passed - unwired-lane guard — 9/9, no new entries Carries the one-line SQL-baseline re-record (`team-analytics.ts: 6 → 3`) that #2864 left behind, same as my other open branches — main is red on it, and identical changes to that line merge without conflict. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 17:43:43 -07:00
gsxdsm	defe48d30f	fix(core): per-workflow metrics read zero on a renamed board (#2866 ) Second of the 14 lane-bound SQL sites from #2839, after #2864. Independent of it — different file, different caller argument. ## The defect `aggregateWorkflowAnalytics` filtered in SQL on `t."column" = 'done'` and `IN ('in-progress','in-review')`. On a renamed board those match nothing, so `tasksCompleted`, `tasksInProgress` and `tasksInReview` come back zero for every workflow while the board is busy. Nothing errors. Same shape and same fix as #2864: resolve per project via `resolveProjectColumnsForRoles`, bind an `IN` list, and thread the store from the single Command Center caller so the parameter has a supplier immediately rather than becoming an inert seam. ## What the test caught that I had not The renamed case still failed with the query fixed. The bucketing at lines 296–297 already uses `isWipColumnRole` / `isReviewColumnRole` — correctly converted — but those read `query.columnFlagsByName`, which production supplies and my fixture did not. So: - the SQL decides which rows come back; - the trait map decides which bucket each row lands in. Both halves have to be right. Fixing only the query would have shipped a "conversion" that still reported zero on a renamed board, and the file would have scored as converted twice over. That is exactly the partial-conversion shape this program keeps re-finding — caught here only because the test asserts `tasksInReview` alongside `tasksCompleted`, since those two paths take different resolved sets (complete vs wip+human-review). Asserting the completed count alone would have left the second conversion unproven. ## Measured Reverted, only the renamed case flips: ``` ✓ default vocabulary: completed and in-review work are counted × renamed vocabulary: completed and in-review work are counted ✓ renamed vocabulary: a card in the HOLD lane counts as neither ✓ without a lane store, the legacy ids still answer Tests 1 failed \| 3 passed (4) ``` The hold-lane negative is there so resolving real lanes cannot degrade into "every column counts" — trading an undercount for an overcount is harder to notice than the original bug. ## Scope The sync SQLite arm in the same file keeps its literals: it throws in backend mode and has no production caller, the same dead-arm conclusion reached for `cleanupStaleMergeQueueRowsImpl` on #2839. ## Verification `pnpm test:gate` green · both Command Center analytics suites 8/8 · `tsc` core 0, dashboard 0 · lint 0 · changeset included. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 17:40:48 -07:00
gsxdsm	c143327d4b	fix(core): the archived-document guards failed in OPPOSITE directions on a renamed lane (#2886 ) Two of the four convertible sites my own learnings doc miscounted as sentinels — the #2877 review corrected "8 of 9 must not be converted" to "5 of 9", and these are two of the three that correction freed. They read `task.column` straight off a row `select`, so they are board lanes by exactly the test that document gives, and a renamed archived column is simply not seen. What makes the pair worth fixing together is that they fail in opposite directions: \| guard \| on a renamed archived lane \| consequence \| \|---\|---\|---\| \| `upsertTaskDocument` \| fails to reject \| an archived card's documents stay writable — the read-only contract silently does not hold \| \| `publishArchivedTaskDocumentAddition` \| fails to accept \| a legitimate archived-document publication is refused as `parent-not-archived` \| The second is the sharper one: valid operator work refused, and refused with a message that reads as a data-integrity error rather than a lifecycle mismatch. ## Shape Both take an `AsyncDataLayer` and can resolve nothing themselves; their store-level impls hold the store, so the lane set arrives as a parameter resolved once per call — the shape #2875 used for the SQL predicate. One shared `resolveArchivedLanes` for both paths, deliberately: if the write guard and the publication guard could disagree about whether a card is archived, a card ends up both read-only and un-publishable. ## The revert proof caught my own fixture first My first version set `deletedAt` alongside the renamed column, and the revert proof passed with the fix removed. Both guards are `column-is-archived \|\| deletedAt != null`, so a soft-deleted fixture short-circuits the exact comparison under test — the assertion was holding for an unrelated reason. Dropping `deletedAt` isolates it, and is also the real shape: a live row in a workflow-declared archived lane is what a renamed board produces, and what `getLiveTaskColumn` was written to catch. Revert proof, measured honestly the second time: restore `task.column === "archived"` and the renamed-lane case fails — the upsert resolves instead of rejecting. ## Real PostgreSQL, deliberately These are row predicates inside a transaction. A mocked store would assert the arguments and prove nothing about the comparison that runs — the same reasoning as #2875. Three cases: the renamed lane rejects, the legacy `archived` id still rejects (most boards never rename anything), and a live card is still allowed through (a guard that rejects everything is its own bug). ## Verification - `pnpm test:gate` — 161 / 487 / 13 / 71 passed - `pnpm lint` — clean - `tsc --noEmit` (`@fusion/core`) — clean - new `archived-document-lanes.pg.test.ts` + existing `artifacts-documents-evals.pg.test.ts` — 12 passed against real PostgreSQL Note: the SQL-literal baseline is untouched here — #2881 owns re-recording it after #2864's conversion left main's gate red. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 17:40:30 -07:00
gsxdsm	63e1f81244	fix(gate): a dropped SQL-literal count tightens the baseline instead of failing the gate (#2888 ) ## Why `check-sql-column-literals` runs inside `pnpm test:gate` — the blocking lane. It hard-fails when a count drops, so a single converting PR that doesn't re-record takes down the gate for every worker in the program until someone fixes the baseline by hand. That is not hypothetical. It is happening on `main` right now (`team-analytics.ts` 6 → 3, fixed by #2880), and it is the second instance of the shape — the lifecycle census hit it from a merge wave that dropped eleven files at once. ## The census already resolved this exact trade-off From `docs/testing.md`, on why the census stopped hard-failing on a drop: > "the drop is almost never the failing author's to fix ... A permanently-red gate is a bigger hole than a stale allowance, because it gets ignored and then nothing is guarded at all." That reasoning applies here with more force, because the census is not in the blocking lane and this check is. Same failure mode, higher cost, opposite policy — this aligns them. ## What changes A drop now rewrites the baseline downward, reports what it lowered, and exits 0: ``` [check-sql-column-literals] baseline TIGHTENED — fewer literals than it allowed packages/core/src/team-analytics.ts: allowed 6, now 3 The baseline has been rewritten downward. COMMIT IT so the allowance cannot be regrown into; in CI this write is discarded with the runner, which is why the gate is green and not silent. ``` The rise check is untouched. "No new SQL column literals" is the ratchet's actual purpose and still fails hard. The stale-allowance concern the old comment raised is real and is preserved: the rewritten file must be committed, and in CI the write is discarded with the runner — so the gate goes green rather than silently passing a stale allowance, exactly as the census does. ## Verified in both directions \| scenario \| result \| \|---\|---\| \| drop (`team-analytics.ts` 6 → 3, the live case) \| tightens, exit 0 \| \| rise (a literal added to a zero-allowance file) \| fails, exit 1 — `task-age-staleness.ts: 1 SQL column literal(s), baseline allows 0` \| The rise probe needed a zero-allowance file: adding one literal to `team-analytics.ts` keeps it at 4 against an allowance of 6, which is correctly not a rise. Worth noting because it is an easy way to conclude the guard is dead when it is working. ## Relationship to #2880 #2880 fixes the instance — it re-records the current drift so the gate goes green now. This fixes the class, so the next conversion doesn't take the gate down again. They are independent and either can land first; if #2880 lands first, this becomes a no-op on a matching baseline. ## Verification - `pnpm test:gate` — exit 0 with this change applied - `pnpm lint` — clean No changeset: gate tooling, not published behaviour. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 17:40:17 -07:00
gsxdsm	a453912ddf	self-healing: merged-but-unfinished tasks never finalized on a renamed board (fifteenth sweep) (#2897 ) `recoverMergedReviewTasks` finalizes a task whose merge is confirmed but which never reached the complete lane. Two literal reads meant that on a renamed board it was never found, so a card whose commit is already on the base branch sat in review or hold indefinitely — merged work the board still shows as unfinished. ## The two redundant guards convert, they don't get deleted Both `t.column === …` checks were redundant while the query pinned the column. Under a resolved read they become the per-card verdict. Deleting them would have silently widened the sweep — the same trap called out in #2891. ## Carries the two shapes review established earlier in this series - Narrow when the card can answer, broad when it cannot (#2891). `resolveWorkflowIrForTask` substitutes the built-in IR rather than failing, so a card with an unreadable selection would otherwise be rejected by the very verdict that the project-scoped query had just admitted it under. It falls back to the project sets instead. - Deduped across the buckets (#2879), so a column carrying both a review role and the hold role cannot finalize one card twice. Both were review findings on earlier PRs in this series, applied here up front rather than waiting to be caught again. ## Revert results Each applied alone and the file re-run: \| conversion \| reverted → \| \| --- \| --- \| \| the resolved reads \| fails — the card is never listed \| \| the per-card review verdict \| fails — the renamed review lane does not match \| Observable is `resolveSelfHealingMergeTarget`, a private method called once per candidate, so the assertion sits downstream of both halves without a git fixture. A non-vacuous companion (merge-confirmed card in the wip lane → untouched) rules out a read that returns everything. ## Verification `pnpm test:gate` 161 + 487 + 13 + 71, plus `self-healing.test.ts` 412; `tsc` engine clean; `pnpm lint`, `check:changesets`, census `--strict` clean, each run explicitly.	2026-07-30 17:22:41 -07:00
gsxdsm	890e1f87e7	fix(core): issue panels reported nothing fixed on a renamed board (#2871 ) Fourth and last of the lane-bound analytics sites from #2839, after #2864, #2866 and #2870. ## The defect `aggregateGithubIssueAnalytics` and its GitLab twin filtered their resolved-issue query on `"column" = 'done'`. On a renamed board that matches nothing, so `fixed` is zero, the resolved-issue list is empty, and `net` reports every filed issue as still outstanding — while the team closes issues all week. Nothing errors. Same fix as the previous three: resolve per project via `resolveProjectColumnsForRoles`, bind an `IN` list, thread the store from each Command Center caller so the parameters have suppliers immediately. ## Both providers in one change, deliberately These two files are copies — same query, only the provider literal differs — and a copy is exactly what gets half-fixed. Converting one and not the other type-checks, passes that provider's test, and leaves the second silently broken with no signal anywhere. The suite runs every case against both, so the pair cannot drift. ## Measured Reverted, exactly the two renamed cases fail — one per provider — while both default-vocabulary controls, both WIP-lane negatives, and both omitted-store legacy cases stay green: ``` ✓ github: default vocabulary counts a resolved issue × github: renamed vocabulary counts a resolved issue ✓ github: renamed vocabulary does NOT count an issue still in the WIP lane ✓ github: without a lane store, the legacy id still answers ✓ gitlab: default vocabulary counts a resolved issue × gitlab: renamed vocabulary counts a resolved issue ✓ gitlab: renamed vocabulary does NOT count an issue still in the WIP lane ✓ gitlab: without a lane store, the legacy id still answers Tests 2 failed \| 6 passed (8) ``` That the failures are symmetric is itself the check on the copy-paste risk. ## Scope The sync SQLite arms keep their literals: they throw in backend mode and have no production caller, the same dead-arm conclusion as `cleanupStaleMergeQueueRowsImpl` on #2839. ## Verification `pnpm test:gate` green · Command Center + GitLab issue analytics suites 10/10 · `tsc` core 0, dashboard 0 · lint 0 · changeset included. --- This closes the lane-bound half of #2839. All 14 sites the hand-review identified as genuinely vocabulary-bound are now converted across four PRs. What remains there is the 11 `!= 'archived'` exclusions, which are probably correct as literals — archiving writes `task.column = 'archived'` unconditionally as a state rather than a lane — plus one dead SQLite arm. Those need per-site judgment, not conversion. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 16:53:12 -07:00
gsxdsm	216632bd3a	fix(core): task-duration stats were computed from an empty set on a renamed board (#2870 ) Third of the 14 lane-bound SQL sites from #2839, after #2864 and #2866. Independent of both. ## The defect `aggregateProductivityAnalytics` filtered its duration query on `"column" = 'done'`. On a renamed board that matches nothing, so the entire task-duration distribution — median, p90, average, total — is computed from an empty row set and reports zeros while the project ships work. Nothing errors. Same shape and fix as the previous two: resolve per project via `resolveProjectColumnsForRoles`, bind an `IN` list, thread the store from the single Command Center caller so the parameter has a supplier immediately rather than becoming an inert seam. ## Measured Reverted, only the renamed case flips: ``` ✓ default vocabulary: a finished task contributes to the duration stats × renamed vocabulary: a task in the RENAMED complete lane contributes ✓ renamed vocabulary: a task still in the WIP lane does NOT contribute ✓ without a lane store, the legacy id still answers Tests 1 failed \| 3 passed (4) ``` ## The negative asserts the median, not just the count This fix's failure mode is worse than the bug it fixes. Resolving too many lanes would pull unfinished work into the distribution and produce a plausible-but-wrong median — a number nobody questions — where the bug produces an obvious zero. So the WIP-lane case asserts `medianMs` is null as well as `completedTasks` being 0. ## A fixture error worth naming My first version asserted `taskDuration.count`. `TaskDurationSummary` exposes `completedTasks`. Every case failed with `expected undefined to be 1` — including the controls — which reads exactly like a broken product until you notice the control is failing too. A control that fails is a fixture bug, not a finding; that asymmetry is the fastest way to tell them apart. ## Scope The sync SQLite arm keeps its literal: it throws in backend mode and has no production caller, the same dead-arm conclusion as `cleanupStaleMergeQueueRowsImpl` on #2839. ## Verification `pnpm test:gate` green · both Command Center analytics suites 8/8 · `tsc` core 0, dashboard 0 · lint 0 · changeset included. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 16:50:00 -07:00
gsxdsm	995b52d21d	fix(gate): re-record the SQL baseline — main is red after #2864 (#2878 ) `pnpm test:gate` and both `pretest` hooks fail on `main` right now. Merge this first. ## What happened #2841 (the SQL gate) merged, then #2864 merged. #2864 removed three legacy comparisons from `team-analytics.ts`, but its baseline entry still allows six — and this gate fails on a lowered count by design, so a migrated slot cannot be silently regrown into later. Baseline 30 → 28. ## This is my sequencing error The four analytics conversions were branched and reviewed before the gate existed, so none of them carries a baseline update. The gate then landed first, which means each of them breaks `main` as it merges. I opened all five without thinking about the order they would land in. The three still open — #2866, #2870, #2871 — will each do this again. I am adding baseline updates to them next so they land clean. ## Note on the downward check The "count went down" failure looks like pedantry until it fires. It exists so a migrated site cannot leave an unused allowance behind for the surface to regrow into — the same rot as an allow-list entry for a deleted function. The real cost is that a conversion and its gate have to land in a known order, which is a coupling I created and did not plan for. ## Verification `pnpm test:gate` green with the re-recorded baseline · lint 0 · `node scripts/check-sql-column-literals.mjs` exit 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 16:46:44 -07:00
gsxdsm	ee8ae1eb23	fix(census): the header claimed 0 trait-fallback branches while sites of that shape existed (#2874 ) The census header has been printing `of the column guards, 0 are trait-fallback branches (already converted)` while sites of exactly that shape exist. I flagged this on #2842 as a suspected classifier gap; this confirms and fixes it. ## The miss Only `cond ? trait : literal` was recognised. The other spelling — a negative test with the literal on the true branch — is what a caller writes once it hoists its resolved lanes: ```ts complete: completeLanes === undefined ? columnId === "done" : completeLanes.includes(columnId) ``` That is `github-tracking-state.ts:245-246` — a fully converted resolver whose two degraded arms were reported as unconverted debt. The backlog read higher than the remaining work, and a reader chasing it was sent to lines that are already correct. Second half of the miss: `completeLanes` matches no hint. Adding `Lanes` to the hint list does not work, and the reason is itself a prior fix — hints are word-bounded because the unbounded form once let `hold` match `threshold` and `household`. `\bLanes\b` cannot match inside `completeLanes`, where the boundary does not exist. So resolved-lane identifiers get an explicit suffix rule. ## Both guards on the new rule exist because I broke them while writing it Worth stating, because each failure ran in the dangerous direction — marking a live line "already converted", which removes a real guard from a backlog people trust: \| mistake \| what it excused \| \|---\|---\| \| widened the shared `testsTraitData` \| fed the ancestor-walking rules too, which marked `step.status === "done" \\|\\| step.status === "in-progress"` at `register-task-workflow-routes.ts:941` — a step-status comparison, not a column guard — as converted \| \| let the new rule walk ancestors \| excused any literal inside a block governed by a negative lane test \| Measured: the count went to 6 with two of them wrong before I caught it. The rule is now immediate-parent-only with its widened identifier match local to it, and reports exactly the 2 real sites. ## Verification - Census: 176 guards, 2 trait-fallback (was 176 / 0). The total is unchanged — this sub-count is diagnostic and does not move the ratchet, so `--strict` exits 0 with no baseline re-record. - 5 cases in `scripts/__tests__/lifecycle-census-inverted-fallback.test.mjs`, including both negatives that pin the mistakes above plus one for the suffix rule not over-reaching (`airplanes` is not a lane test). - `pnpm lint` clean; gate green (161/487/13/71). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Improved lifecycle analysis accuracy for trait fallback logic, including inverted conditions, legacy fallback syntax, and null or undefined checks. * Added safeguards to avoid misclassifying complex conditions, unrelated identifiers, and nested expressions. * Improved handling of lifecycle lane and column naming patterns. * Tests * Expanded coverage for valid and invalid fallback scenarios, identifier boundaries, parent-expression restrictions, and property-path checks. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 16:43:31 -07:00
gsxdsm	b85e5f90e1	fix(create): two task-CREATE destinations named a lane the board does not have (#2843 ) Both files sat at census-zero and both wrote real cards into columns no workflow declares. The census scores `===` comparisons, so a lane literal passed as a call argument is invisible to it — one of the four census-blind classes. These are the only two explicit-`column` creates in production: ``` packages/dashboard/src/routes/register-gitlab.ts:108 column: "triage" packages/cli/src/extension.ts:5243 column: "todo" ``` ## The two defects `register-gitlab.ts` — `column: "triage"`, a column U11 DELETED. This one is broken on every board, not only renamed ones: the default lineage is now `todo \| in-progress \| in-review \| done \| archived`. `createTask` already resolves the intake column of the workflow it selects (`resolvedEntryColumn`), and an explicit `column` overrides that resolution — which is why the stale literal survived U11. Nothing rejects the write and nothing logs it: the route answers `201` with a task id and the imported card is simply not on the board. Same shape as the `task-update.ts` triage defect fixed earlier in this program. Fix: omit `column` and let `createTask` resolve intake. `extension.ts` `fn_delegate_task` — `column: "todo"`. On a workflow whose ready lane is named anything else, the delegated card goes to an undeclared column: written, reported to the caller as delegated, never visible to the agent it was delegated to. Fix: resolve the selected workflow's `hold` lane. Deliberately not "omit the column like the GitLab route" — the tool's own contract is "the task goes to the ready-to-work lane and the target agent picks it up on its next heartbeat", so inheriting intake resolution would park a delegated card in a manual-intake lane waiting for a human. That would be a behaviour change; `hold` is the role that names the lane the literal meant. ## New helper: `resolveWorkflowColumnForRole(store, role, workflowId?)` The write-shaped counterpart to `resolveProjectColumnsForRoles`. The read helper unions in the legacy ids because an extra id in a query set is inert; here the same trick is a silent wrong write (post-U12 an undeclared column is a `TransitionRejectionError` on move, a phantom lane on create), so it returns one column from one workflow, or `undefined`. A contract I got wrong twice, now pinned by a test. `undefined` means "this workflow declares no such column" and nothing else. `resolveWorkflowIrById` never throws and never returns nothing — an unregistered builtin id, a missing definition row and a failing read all resolve to the default coding IR (branded via `markFellBack`). So an unreadable workflow yields the built-in hold lane, not `undefined`, and both call sites' `?? "todo"` fallbacks are narrower than they look. Two of my first test cases asserted the opposite and failed; the behaviour is the resolver's, and the write it produces is identical to the caller's own legacy fallback either way. ## Revert proofs (measured, not asserted) \| revert \| failure \| \|---\|---\| \| `column: holdColumn` -> `column: "todo"` \| `extension.test.ts`: `expected 'todo' to be 'queued'` \| \| omitted column -> `column: "triage"` \| `routes-gitlab.test.ts`: `expected 'triage' to be undefined` \| The two neighbouring `fn_delegate_task` cases stay green under the first revert, because the built-in board and the test's `linearWorkflowIr` both call the lane `todo` — which is exactly why this literal survived every previous pass. The GitLab case asserts absence of the key rather than a resolved id: the store there is a fake whose `createTask` echoes its input, so asserting a resolved value would be testing the fake. Absence is the property that hands the decision to the real `createTask`. ## Census \| file \| before \| after \| \|---\|---\|---\| \| `packages/dashboard/src/routes/register-gitlab.ts` \| 1 \| 0 \| \| `packages/cli/src/extension.ts` \| 1 \| 0 \| Baseline tightened. It also picks up `packages/core/src/task-store/moves.ts` 2 -> 0, which was already true on main — not from this diff. ## Noted, deliberately not changed - `validateAssignableAgentId`'s synthetic probe a few lines above still uses `{ id: "<new>", column: "todo" }`. It feeds `isImplementationTask`, whose `IMPLEMENTATION_TASK_COLUMNS` set an earlier worker documented as deliberately-not-converted (converting it makes the routing policy async — an agent-admission behaviour change). On a renamed board the probe is now stricter than the real destination, which is the safe direction and matches the pre-existing behaviour. - The third site from this bucket, `workflow-node-handlers.ts:455` (`transitionTask({ column: "in-review" })` on the `review-handoff` seam), is a hard failure rather than a silent one — `transitionTask` routes through `moveTask`, which post-U12 throws `TransitionRejectionError` for an undeclared destination, so the workflow walk dies at the handoff on any renamed review lane. It is engine (`batch-engine`) and fixing it properly touches `executor.ts`, which #2820 is also editing. Left for that batch rather than opened as a conflicting edit. ## Verification - `pnpm test:gate` — 161 / 487 / 13 / 71 passed - `pnpm lint` — clean - `tsc --noEmit -p tsconfig.json` for `@fusion/core`, `@runfusion/fusion`, `@fusion/dashboard` — clean - `node scripts/lifecycle-column-census.mjs --strict` — exit 0 - targeted: `project-lane-vocabulary.test.ts` 14/14, `routes-gitlab.test.ts` 8/8, `extension.test.ts -t fn_delegate_task` 9/9 🤖 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 * GitLab-imported cards now appear in the workflow’s configured intake lane. * Delegated tasks now move to the workflow’s configured hold lane, including workflows with custom lane names or separate intake and hold lanes. * Delegation reports the task’s final lane and provides an error when it cannot be moved successfully. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 16:20:38 -07:00
gsxdsm	ef50244234	feat(gate): freeze the SQL column-literal surface — 30 sites, none may be added (#2841 ) Instruments a surface no existing check can see. Follows #2839, and corrects the count I reported there (12 → 14). ## Why it was invisible The lifecycle census parses TypeScript comparisons; a legacy id inside a SQL string is string data. The inert-seam gate reasons about parameters and call sites. Neither has ever looked here. What it cost: `cleanupStaleMergeQueueRowsImpl` filtered on `t.column != 'in-review'`, so on a renamed board every queued card looked stale, its `merge_queue` row was deleted, and the card became unleaseable. The operator found it reviewing #2819 — in SQL I had already read past during that same work. The quieter half is analytics: five sites count `"column" = 'done'`, so throughput, cycle time, and team dashboards report zero completed work on a renamed board. Nothing errors, which is why nobody files it. ## What this does, and does not do It does not fix the sites. `resolveProjectColumnsForRoles` is the mechanism and its migration has an owner (#2839). This freezes the population so the surface cannot grow underneath that migration: a new file or a higher count fails, and a lower count fails too — so the baseline ratchets down as sites migrate rather than leaving slots to silently regrow into. That is the same rot as an allow-list entry for a deleted function, which this repo already hit once. AST-based, deliberately: a line grep for the same pattern reports 37 hits, 25 of them prose quoting `column === "done"` in explanatory notes. A guard that is 68% false positives trains its readers to skip it — a lesson this program has already paid for. ## Two corrections found by mutation-testing my own gate 1. Clause fragments were missed. Requiring a SQL keyword in the same literal skipped `team-analytics.ts`, which builds `["assignedAgentId IS NOT NULL", `"column" = 'done'`, ...]` and joins them into a `WHERE` later. That fragment is as vocabulary-bound as any full query but contains no keyword. Fixing it took the population 12 → 14, so the number I put on #2839 was low. 2. My first mutation test proved a direction it had not. I replaced the first textual occurrence in a file — which was inside a comment — and read the unchanged count as the scanner being broken. The scanner was right; my test was wrong. All three directions are now driven against real SQL: \| mutation \| result \| \|---\|---\| \| add a full query with a legacy comparison \| `3 SQL column literal(s), baseline allows 2` \| \| add a bare clause fragment (no keyword) \| caught — same failure \| \| migrate one away (count drops) \| `1 site(s) now, baseline still allows 2 — re-record it` \| \| restore \| exit 0 \| I am flagging that second one because it is the exact failure mode this program keeps finding: a green result read as evidence when the experiment was invalid. ## Verification `pnpm test:gate` green with the new check in it · lint 0 · single AST pass. Wired into `test:gate` and both `pretest` hooks. 🤖 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 automated checks to detect increases in legacy SQL column literals. * Added baseline tracking to ensure known SQL literal counts do not regress. * Tests * Expanded pre-test and gated verification steps with SQL literal and mock completeness checks. * Updated test validation workflows to enforce the new safeguards. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 16:06:24 -07:00
gsxdsm	7784cb1fe8	self-healing: six recovery sweeps that never ran on a renamed board — and the guards widening their queries activates (#2838 ) Six self-healing sweeps did not run at all on a renamed board. Each is a recovery path — the thing that unsticks a card when something has already gone wrong. #2800 measured this class and could not fix it: a read happens before any task is in hand, so there is nothing to resolve a per-task lane from. `resolveProjectColumnsForRoles` (landed separately) is the seam that was missing. ## What was silently dead \| sweep \| what stayed broken on a renamed board \| \| --- \| --- \| \| `reconcileDoneTaskIntegrity` \| a landed card kept no commit sha, forever \| \| `recoverAlreadyMergedReviewTasks` \| a card whose merge succeeded stayed parked with `status: "failed"` \| \| `recoverStuckMergeDeadlocks` \| doubly blind — no candidates and no dependents \| \| `recoverInterruptedMergingTasks` \| a task interrupted mid-merge sat in `merging` indefinitely \| \| `recoverMergeableReviewTasks` \| a card ready to merge was never re-enqueued \| \| `recoverReviewTasksWithFailedPreMergeSteps` \| a card parked on a failed review step was never revived \| The census scored the `task.column === "..."` re-assertion inside each loop, never the query above it. Converting those comparisons would have dropped six counts and changed nothing — the loop bodies were already unreachable. ## The conversion shape — five parts, three of which review taught me Documented in `self-healing-sweeps-are-blind-on-a-renamed-board.md`, because the second sweep drifted from the first: I wrote it from the pre-review version and reproduced a flaw already fixed one commit earlier. 1. Read — project union, query each column, dedupe by id. Legacy ids unioned so a board mid-rename is not skipped. 2. Verdict — per card against its own workflow. Widening the read and widening the verdict are different decisions: a missed row is invisible, a wrong row is a write. Using the project union as a per-card test claims a card because some other board calls its column that role. 3. Provenance — the resolver substitutes the built-in IR rather than failing, so `length > 0` reads as "this card answered" when nobody did. It does not change the verdict (measured: identical) — it makes the unrepaired card reportable. 4. The log strings — widening a query invalidates every message naming the old literal. One logged `"stale merging task(s) in in-review"` after its read covered several lanes. 5. The guards the query ACTIVATES. ## Part 5 is the one that bites A guard downstream of a literal query is unreachable on a renamed board — and unreachable is indistinguishable from correct. That is why these sit unwired indefinitely. `recoverReviewTasksWithFailedPreMergeSteps` filters on `blocker !== "task has failed pre-merge workflow steps"` — an exact string match. Unwired, the blocker returns `"task is in 'checking', must be in 'in-review'"`, so widening the query alone would have made the sweep find every card and reject every card. Measured: 6 sweeps hold both a literal query and an unwired lane guard; 30 hold a literal query with no such guard. All six are named in the doc. One of the six was my own already-converted sweep. I widened `recoverAlreadyMergedReviewTasks` two commits before noticing its `getTaskHardMergeBlocker` was unwired — so for two commits it found renamed-board cards and declined them. The scan must run before widening; I did it after, and only caught it because the next sweep forced the question. `getTaskHardMergeBlocker` was the blind spot for four of the six: a wrapper, no lane parameter at all, every caller behind a literal query. ## Corrections to my own work, kept visible - The project union used as a per-card verdict — the flat-set mistake `project-lane-vocabulary.ts` warns about in its own header, which I quoted while writing it. - A provenance fix that was a no-op: measured identical verdicts in every state, revert passed its own new test, so it was thrown away rather than shipped with a comment claiming otherwise. - The second sweep reproducing the first's pre-fix shape. - Three assertions that were vacuous until the revert exposed them — including one where the write needed a real git repo, so `commitSha` could not distinguish accepted from rejected. ## Verification - `pnpm test:gate` — 161 + 487 + 13 + 71 - `self-healing.test.ts` 412, query-blindness suite 12 - `tsc` on core and engine; `pnpm lint`; `check:changesets`; census `--strict` — all clean, each run explicitly - Every conversion revert-measured, each direction independently where a sweep has two (read and guard) ## Scope 42 queries remain, 5 of the 6 activation-risk sweeps among them. Each is per-sweep work — its own filter semantics, its own downstream guards, its own log strings — so they land one at a time with the pattern proven, never swept. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - Bug Fixes - Self-healing workflows now work correctly on boards with renamed lifecycle columns. - Improved recovery for completed, in-review, interrupted, stalled, and failed-merge tasks. - Prevented tasks from being incorrectly classified using another workflow’s columns. - Added warnings when a task’s workflow lanes cannot be resolved. - Documentation - Expanded guidance on renamed-board recovery behavior and related diagnostic limitations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 15:38:10 -07:00
gsxdsm	92d82b7a17	fix(guard): the unwired-lane check reported 0 because its question was too weak (#2852 ) A guard nobody has proven can fail is a number, not a check. This one was returning a clean `[]` while 18 real unwired lane declarations sat on `main` — including one it was specifically built to catch. ## The escape that found it `diffSnapshots` in the glasses plugin: ```ts opts: { notifyOnColumns: ReadonlySet<ColumnId>; completeColumnsByTaskId?: ReadonlyMap<...> } ... const completeColumns = opts.completeColumnsByTaskId?.get(task.id); const isComplete = completeColumns ? completeColumns.has(task.column) : task.column === "done"; ``` No file anywhere builds that map. The conversion was decorative — the literal decided every real poll, so on a renamed board the wearer is notified of every column transition except the card finishing, the one they care about. The name was already in the guard's vocabulary list, the declaration was exported and optional; it satisfied every condition the guard checks, and the guard said nothing. ## Three independent blind spots \| # \| blind spot \| why it mattered \| \|---\|---\|---\| \| 1 \| `SCANNED_PACKAGES` omitted `plugins/` \| plugins hold lane logic like anything else — this one resolves workflow IRs and decides what "finished" means \| \| 2 \| inline options-object types were not walked \| only bare parameters and named interfaces were. Whether a lane answer arrives as a parameter, an interface property, or an inline field is a style choice — a check evadable by a style choice is decorative \| \| 3 \| the mention rule was `source.includes(parameter)` anywhere \| satisfied by coincidence for any ordinarily-named parameter \| Fixing 1 or 2 alone would still have missed it: measured on `main`, the guard found 0 unwired across 1753 files, and 0 again across 2114 once `plugins` was added, because the shape was invisible too. ### On (3), I proved it on myself Renaming the unwired parameter from `completeColumnsByTaskId` to `completeColumns` — a better name, chosen for good reasons — silenced the guard instantly, because 15 unrelated production files declare a local called `completeColumns`. The check had not been satisfied; it had been switched off by a rename. That is exactly the failure the code comment two lines up condemns, committed one edit later. The fix is the cause, not a name blocklist: a file that never references `diffSnapshots` cannot be the thing that wires `diffSnapshots`'s options. Still deliberately loose — a co-occurrence test, not call-graph analysis — which keeps the low false-positive rate that makes the guard bearable while removing a false negative that scaled with how ordinary a parameter's name was. ## The 17 this uncovered Tightening (3) surfaced 17 further unwired declarations across core, engine and dashboard. Spot-checked, not assumed: `buildUnblockWeightMap` in `task-priority.ts` declares `terminalColumns` and `reviewColumns`, and the only files that pass either are its own tests — the production caller silently uses the built-in `{done, archived}` default. That is the inert-conversion shape this module exists to name. They span three other batches, so they are recorded as a ratcheted baseline in the shape `scripts/lifecycle-column-census.mjs` already uses here — keyed on `file + parameter` so an unrelated edit above them cannot manufacture a failure. A new one fails immediately; these can only leave the list. Listing them beats pretending for another week that they do not exist. ## The glasses fix `completeColumnsByTaskId` -> a flat `completeColumns` set, matching its sibling `notifyOnColumns` in the same options object, resolved once per poll by `notifier.ts` via `resolveProjectColumnsForRoles`. Project-scoped and not per task because this runs on a polling timer over the whole board — a per-card workflow read would scale with the board on every tick. Best-effort: a failed resolve leaves the diff on its documented legacy default rather than dropping a poll. Still gated by `alsoNotifyOnDone`, which the production caller passes as `false`, so it remains unobservable at runtime. Wired anyway: the day someone enables the flag the resolution must already be right — and now the guard will say so if the wiring is removed. ## Revert proofs (measured, one per fix) \| revert \| failure \| \|---\|---\| \| unwire `notifier.ts` \| baseline gains `plugins/…/diff.ts completeColumns` \| \| drop the inline-options walk \| "covers an INLINE options-object type" fails `expected [] to deeply equal [ 'completeColumns' ]`, and the repo scan loses the glasses entry \| \| drop the owner scoping \| the repo scan loses all 17 pre-existing entries \| \| restore `task.column === "done"` \| both new `diff.test.ts` cases fail \| The new diff cases assert both directions — a card in the resolved lane fires, and a card in the legacy `done` does not once the caller resolved other lanes. The second is what proves the resolved set replaces the default rather than being unioned with it. ## Verification - `pnpm test:gate` — 161 / 487 / 13 / 71 passed - `pnpm lint` — clean - `tsc --noEmit` — clean - guard suite — 9/9; full glasses plugin — 188 passed across 19 files 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 15:24:33 -07:00
gsxdsm	eed8ca55fc	batch-dashboard-src: the planner metrics tool froze active runtime on a renamed execution lane (186 → 185) (#2842 ) `packages/cli` and the plugin packages are at zero lifecycle guards, so this picks up the nearest unowned work: the `packages/dashboard/src/` remainder. ## The defect `activeRuntimeMs` adds the wall-clock since `executionStartedAt` only while the card is accruing work — the WIP role — but it was keyed on the literal `in-progress`. On a board whose execution lane is renamed, that live tail was dropped, so `fn_task_planner_get_task_metrics` reported active time frozen at whatever the last completed segment left in `cumulativeActiveMs`. The number stayed plausible, which is why nothing surfaced it. ## The part worth reading: the wiring had no watcher, from either direction I wired the producer (`chat.ts` resolves the task's own lanes via `wipColumnsForTask`) in the same commit, then checked whether that wiring was actually covered. It was not: - Deleting the `wipColumns:` argument left the entire 3830-test dashboard suite green. The formatter's own tests inject the set by hand, so they prove the guard and are structurally blind to whether production fills it. - `check-inert-flag-seams.mjs` does not see it either. It tracks trailing optional parameters; this is a property inside an options bag. That is a real gap in the checker — every seam expressed as an options-bag property is currently unguarded. Reported here rather than fixed, because #2822 and #2830 both already modify that script and a third change would guarantee a three-way conflict. So `createTaskPlannerMetricsTool` is exported and a second test drives it, letting it do its own resolution against a renamed board. Deleting the argument now fails 1 of 2. ## Census \| \| before \| after \| \|---\|---\|---\| \| COLUMN guards \| 186 \| 185 \| \| `packages/dashboard/src/task-planner-chat-metrics.ts` \| 1 \| 0 \| Baseline re-recorded; `--strict` exits 0. ## Two findings I did NOT act on, deliberately 1. `github-tracking-state.ts` keeps 2 counted guards and should. They are the documented degraded-mode arms of a fully-resolved classifier (`completeLanes === undefined ? columnId === "done" : ...`). Marking them `DELIBERATE-LITERAL` would drop the count by reclassification rather than conversion — the exact move the census's own strict-check warns about. Related: the census reports `0 are trait-fallback branches (already converted)`, yet these are precisely that shape, so the trait-fallback classifier appears not to recognise a ternary whose fallback arm is the literal. Worth a look by whoever owns the census. 2. Three pre-existing failures in `packages/dashboard/src/__tests__`, unrelated to this change — measured identically on `origin/main` before and after: - `planning-browser-e2e.test.ts:353` - `register-model-routes-kimi-k3-supplemental.test.ts:60` - `routes-tasks-near-duplicate.test.ts:274` Flagging rather than touching them; per the standing rule they are quarantine candidates, not appeasement candidates. ## Verification Dashboard `tsc` clean, `pnpm lint` clean, census `--strict` 0, `check-inert-flag-seams` 21/21 supplied, changeset lint clean. Targeted suites: `task-planner-chat-metrics.test.ts` 8/8, `task-planner-metrics-tool-wip-lanes.test.ts` 2/2. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 15:16:24 -07:00
gsxdsm	5a3541315c	fix(gate): pnpm test is red on main — stale exemptions, plus two false positives they were masking (#2851 ) `pnpm test` and `pnpm test:full` fail on `main` right now (commit `51934931e1`). Found by running the gates against `main` after my earlier PRs landed, not by CI telling me. > Correction to this PR's first version. I originally wrote that `pnpm test:gate` was failing. It is not: `check-inert-flag-seams` runs in the `pretest` and `pretest:full` hooks, not in `test:gate`. So the blocking merge gate (Lint / Typecheck / Build / Gate) is unaffected and PRs are not blocked — what is broken is every local `pnpm test` run, which fails before a single test executes. Lower urgency than I claimed, still worth fixing promptly, and I would rather correct the scope than leave an overstated one standing. Three causes, each surfaced by fixing the one before it. ## 1. Stale exemptions — the mechanism working #2819 and #2823 merged, so the two `ALLOWED_OMISSIONS` entries covering those call sites became stale and the staleness check failed them. Removed. This is my cleanup: the entries were designed so they could not outlive their fixes, and they didn t. ## 2. Renamed imports were not resolved Removing the first entry surfaced: ``` enqueueMergeQueue() — best call passes 2 of 5 ``` Its only production caller passes all five — through `import { enqueueMergeQueue as enqueueMergeQueueAsync }`. Call sites were recorded under the local name, so an aliased supplier was invisible and the seam read as unsupplied. The local name is now mapped back to the exported one. ## 3. Method calls were conflated with module functions That fix then surfaced two engine sites as omitting — but `store.enqueueMergeQueue(taskId, opts)` is a 2-arg `TaskStore` method that resolves the review columns internally (#2819), not the 5-arg module function sharing its name. Property-access calls are no longer attributed to module-level seams. Tradeoff, stated at the site: a genuine `namespace.fn(...)` call is now skipped. This codebase calls module functions as bare identifiers, and aliases are resolved by fix 2, so that shape does not currently occur. Recorded rather than left for someone to discover. ## Both directions re-verified A fix that quietly disarms the gate would be worse than the red, so I re-ran the defects it exists to catch: \| mutation \| result \| \|---\|---\| \| drop `Column.tsx`'s flags argument (partial supply) \| `supplied by 10/11 call sites; omitted at .../Column.tsx:1 (of 2)` \| \| drop the aliased 5-arg supplier (wholly unsupplied) \| `best call passes 3 of 5` \| \| restored \| exit 0 \| My first attempt at the second row grepped for the wrong message shape and printed nothing. I re-ran it rather than reading silence as success — which is the failure this gate exists to prevent, and one I have made in this same file before. ## Verification `pnpm test:gate` green (it was never affected) · `node scripts/check-inert-flag-seams.mjs` exit 0 · lint 0 · gate reports `21 lane/flag seams, all supplied at every production call site`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 15:10:45 -07:00
gsxdsm	51934931e1	fix(board): the awaitingPlanning badge only ever worked on a lane named "todo" (#2845 ) Converts the one site in `register-task-workflow-routes.ts` that a previous pass deliberately deferred, and does it in the shape that note asked for. ## What the deferral said ``` FNXC:WorkflowResolvedColumns 2026-07-29-00:00 (U12 — R8, DELIBERATELY NOT CONVERTED): … I converted it and then REVERTED: resolving each task's hold column needs a per-task workflow read, and this is the board-load path whose own comment above exists because unbounded reads here "turn a board load into thousands of reads". Converting it properly needs the hold column resolved per WORKFLOW from data the board payload already carries, not per task from the store. ``` That was the right call and the right diagnosis. `resolveProjectColumnsForRoles(store, ["hold"])` is exactly the project-scoped shape it names: one `listWorkflowDefinitions()` read per board load, flat in task count. The expensive part — a PROMPT.md read per row — is untouched and still bounded by `AWAITING_PLANNING_ENRICH_LIMIT`. The test asserts the flatness directly (`listWorkflowDefinitions` called exactly once), so a future per-task regression fails here rather than being discovered as board latency. ## What was broken The filter named `todo`, so on a board whose waiting lane is called anything else no row was enriched at all — no error, no log line, just a silent fall back to the client's `steps.length === 0` heuristic. That heuristic is precisely what this enrichment was added to correct, so the card most likely to be mislabelled — real spec, zero parsed steps, already a scheduler dispatch candidate — sat on "Queued to plan" indefinitely. Over-inclusion is the safe direction and is chosen deliberately: a card in some other workflow's hold lane gets annotated as waiting, which is what a waiting card in a waiting lane should show. ## Revert proof (measured) Restore `task.column === "todo"`: ``` FAIL register-task-workflow-routes.awaiting-planning.test.ts > enriches a card in a RENAMED hold lane, not only one literally named todo expected undefined to be false ``` The other 8 cases in the file stay green — their harness store declares no `listWorkflowDefinitions`, so they run the degraded legacy-`todo` path. That compatibility is half the contract, which is why the new case brings its own store rather than widening the shared harness. ## Census \| file \| before \| after \| \|---\|---\|---\| \| `packages/dashboard/src/routes/register-task-workflow-routes.ts` \| 3 \| 2 \| The 2 remaining in that file are documented trait-fallback branches, not unconverted debt. The baseline also picks up `packages/core/src/task-store/moves.ts` 2 -> 0, already true on main and not from this diff. ## Verification - `pnpm test:gate` — 161 / 487 / 13 / 71 passed - `pnpm lint` — clean - `tsc --noEmit -p tsconfig.json` (`@fusion/dashboard`) — clean - `node scripts/lifecycle-column-census.mjs --strict` — exit 0 - targeted: `register-task-workflow-routes.awaiting-planning.test.ts` 9/9 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 14:48:00 -07:00
gsxdsm	3a5058edd8	chore(census): re-record the baseline after moves.ts reached zero guards (#2844 ) ## Main is red; this fixes it `packages/engine/src/__tests__/census-baseline-corruption-guard.test.ts` fails on `main`: ``` × the census fails readably on a corrupt baseline > still succeeds against the repo's real baseline → expected 'lifecycle-column-census: scanned 1960…' to contain 'every file matches its baseline exact…' ``` A conversion took `packages/core/src/task-store/moves.ts` from 2 column guards to 0 without re-recording the baseline. `--strict` then reports `TIGHTENED` instead of the exact-match line the guard asserts. ## The whole diff ```diff - "packages/core/src/task-store/moves.ts": 2, ``` One removed allowance. Nothing else moved. ## Why committing it is the prescribed workflow, not a workaround The census says so itself when it tightens: > The baseline file has been rewritten downward. COMMIT IT so the allowance cannot be regrown into; > in CI this write is discarded with the runner, which is why the gate is green and not silent. That discard is the reason this recurs: the tightening only ever persists if a human commits the side-effect file, so a conversion PR that does not re-record leaves `main` red for the next person. Leaving the stale `2` in place would also keep an allowance open for guards to regrow into, which is the ratchet's entire purpose. This cannot hide a regression. `--strict` fails hard on a rise; it only rewrites when counts drop. An exit-0 tighten means every change was downward. ## Verification - `census-baseline-corruption-guard.test.ts` — 3/3 - `pnpm check:lifecycle-columns` — exit 0, "every file matches its baseline exactly" Not my change to `moves.ts` — found while running the full `engine-default` project (736 files) looking for fallout from my own merged fixes. That sweep also turned up a second red, fixed separately in #2840. No changeset: the baseline is internal tooling state, not published behaviour. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 14:42:28 -07:00
gsxdsm	cea9637dfc	feat(census): split the query class into read-shaped and write — most of the remainder must not be converted (#2837 ) Splits the census's query class into read-shaped (convertible) and write (must not be converted), reported beside the existing total. On current `main`: ``` QUERY filters (column: "<legacy>"): 63 of those: 48 read-shaped (convertible), 5 writes (do NOT convert), 10 other ``` ## Why the single number misleads `column:` sits in an options-shaped object for both a source query and a write, so the existing definition-vs-query rule cannot separate them. The result reads as "dead reads to convert" — and after #2818 landed, 48 of the 63 are `self-healing.ts` and the rest are largely not convertible at all. Converting a write in this class is harmful, not merely pointless. `async-persistence.ts` soft-deletes with `.set({ column: "archived", deletedAt, … })`, and `getLiveTaskColumn` returns `"archived"` as a sentinel for any soft-deleted row — the write and the sentinel have to agree. A sweep that "finished the query class" by converting all 63 would break live-column resolution for every deleted task. That is the same shape #2808 flagged for `recoveryRehome` moves. Two of the census-invisible classes now have members that must not be fixed, and in both cases the count alone cannot tell you which. ## Reported, not ratcheted `properties.query` and `queryByFile` are byte-identical, so the pinned baseline does not move and no open PR's Lint changes. The split is one extra line of output. Changing what a ratchet enforces is the owner's call; improving what it says is not. Same line I drew when making marker-only failures legible without loosening them. ## Honest limit Read-shaped is a better filter than the raw count and still not a verdict. `auto-merge-finalization.ts:242` is classified read-shaped and must NOT be converted — its own comment records that it is `getTaskHardMergeBlocker`'s review-eligible sentinel, deliberately not re-keyed. Nothing mechanical would catch that; only the comment beside it does. The split narrows a haystack to a readable list; it does not decide the list. ## Verification 4 new cases — a `listTasks` filter counts read, a `.set()` tombstone counts write, IR node definitions stay excluded from the class entirely (the pre-existing rule must keep working), and the pinned total is unchanged by the split. Revert proof: dropping the write branch fails the tombstone case. Census's own suites 87 passed, gate 161 / 13 / 487 / 71, lint clean, `--strict` exits 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 14:29:01 -07:00
gsxdsm	2c24966d0c	fleet: the app-side remainder 18 → 0 — Archive/Revert and diff stats were silently absent on a renamed board (#2731 ) Three genuinely free clusters in one layer and one idiom — `Column.tsx` (7), `ListView.tsx` (6), `useTaskDiffStats.ts` (5). I built the claimed-file set from every open PR's diff before starting, having duplicated a claimed cluster last round. ## Census \| file \| before \| after \| \|---\|---:\|---:\| \| `Column.tsx` \| 7 \| 0 \| \| `ListView.tsx` \| 6 \| 0 \| \| `useTaskDiffStats.ts` \| 5 \| 0 \| 16 converted; 2 reclassified with a reason — the two are accounted for separately below so the numbers stay honest. ## Three silent failures, not three style nits - `ListView` Archive and Revert were gated on `task.column === "done"` / `=== "archived"`, so on a board with renamed terminal lanes they did not render at all. No error, no log — the operator simply cannot archive or revert from the list. - `useTaskDiffStats` compared a bare `column: string` to `done`/`in-progress`/`in-review`, so on a renamed board it fetched nothing and the row showed no changes. - `ListView` progress display had the same shape for the WIP lane. ## The `?? {}` is the whole subtlety Every `Column.tsx` site was `workflowMode ? <trait> : column === "<id>"`. One adapter now feeds the shared helpers: ```ts const columnRoleFlags = workflowMode ? (columnFlags ?? {}) : undefined; ``` `workflowMode` means traits are the only authority, so a workflow-mode column with no resolved flags must answer `false` — which `Boolean(columnFlags?.archived)` did. Passing `undefined` to a role helper instead selects its legacy id fallback, so a flagless workflow-mode column would start matching on its id. An empty object keeps the helper on its trait branch. Legacy mode passes `undefined` deliberately: there the id fallback is the answer, and routing it through the helpers is the point. ## Two things I deliberately did not do `isTodoLikeColumn` keeps its own trait arm. Adopting `isPreImplementationColumnRole` would widen its fallback from `todo` alone to `{todo, triage}`, handing a legacy `triage` column a bulk replan affordance it does not have today — a behaviour change hiding inside a de-duplication. Only its fallback is routed through a helper. The `mode === "done"` pair is reclassified, not converted. It is the hook's own `"done" \| "active"` discriminant, assigned three lines from `shouldFetchDoneTask` — not a column id, with no trait to resolve. The census counts it because the receiver is compared to the string `done`, which is a classifier limit. Marked deliberate and recorded in `deliberateByFile`, so that file's `byFile` drop is 5 while its conversion count is 3. One genuine simplification fell out: `workflowMode ? isReviewColumn : column === "in-review"`, where `isReviewColumn` is itself that same ternary. Both arms already agreed with it — collapsing is behaviour-identical. ## Revert proof Restoring the id comparisons on the ListView row menu fails the new renamed-lane case with `Unable to find an accessible element with the role "menuitem" and name "Archive"`. Driven through the real `fetchBoardWorkflows` seam with a renamed vocabulary — payload → `listColumns` → `columnFlagsById` → row menu — rather than by injecting flags, so the assertion covers the path the component actually uses. The DEFAULT-vocabulary path passes either way, which is exactly why the renamed case has to exist. ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 375 passed across Column / ListView / useTaskDiffStats / role-invariance / columnRoles · dashboard `tsc -p tsconfig.app.json` clean · `pnpm lint` clean · census `--strict` exits 0. `TaskCard.tsx` is touched only to pass the new optional `columnFlags` through; its own census count is unchanged at 3. The 2 `TaskCard` reds in that suite are the known pre-existing CSS-var geometry assertions. 🤖 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 workflow lane handling when columns are renamed or assigned roles through workflow settings. * Archive and Revert actions now remain available for completed and archived tasks in renamed lanes. * Corrected task progress and diff-stat behavior across active, review, completed, and archived lanes. * Updated bulk actions, sorting controls, and auto-merge controls to respond consistently to workflow roles. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 14:12:14 -07:00
gsxdsm	fe8f3af751	fix(gate): barrel imports were silently dropped from the inert-seam check, hiding 5 engine omissions (#2822 ) Self-reported regression from #2772, which has already merged. The seam gate on main currently prints a clean bill of health while five real omissions sit in front of it. ## What broke Closing the imported-shadow hole in #2772 taught the check to record which module each callee was imported from, and to exclude a call site whose module basename does not match the seam's declaring module. That works for relative imports. It does not work for barrel imports. Engine and CLI reach core through `import { ... } from "@fusion/core"`. That specifier's basename is `core`, which never matches a module name like `near-duplicate-canonical` — so every barrel-imported call site was classified as "a different function of the same name" and dropped. The check stopped seeing engine's and cli's calls into core entirely, which is most of the cross-package surface it exists to watch. ## Measured On `main` today: ``` [check-inert-flag-seams] 21 lane/flag seams, all supplied at every production call site. ``` With this fix: ``` packages/core/src/near-duplicate-canonical.ts: isNearDuplicateCanonicalInactive() — supplied by 6/11 call sites; omitted at packages/engine/src/self-healing.ts (x2), packages/engine/src/triage.ts (x3) ``` Those five were always there. Earlier I reported this seam as "supplied by 5/6" — that number was wrong for this reason, and the engine sites were invisible to me when I said it. ## The rule now Only a relative specifier identifies a module well enough to exclude a call site on. Anything else is unresolved, and unresolved must mean counted: an over-counted seam produces a false report somebody investigates, an under-counted one produces silence. I had this backwards, and it is the second time in this lane a change made the gate read cleaner while catching less. ## Both directions verified - Barrel imports counted — the five engine sites appear. - Relative shadows still excluded — lifting the `sortTasksForDisplayColumn` entry still reports it unsupplied, so `Lane`/`Board`/`ListView` calling the dashboard twin through `"./taskSorting"` does not clear core's seam. That was the entire point of the original fix and it still holds. ## The five engine omissions Not fixed here — engine-owned, reported on #2785. Same shape as the merge-queue bug in #2819: a canonical resting in a renamed active column reads as inactive, so duplicate markers get cleared against live work. They carry TEMPORARY per-file exemptions so this PR is green and self-announcing. Noted at the entry: the key is `<file>::<function>`, so a file with two omitting calls is exempted for both — coarser than I want, recorded rather than left to be discovered. ## Verification `pnpm test:gate` green, lint 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 14:09:23 -07:00
gsxdsm	7bf3df9477	chore(core): delete the dead merge-blocker guard, and catch exemptions for deleted seams (#2830 ) Closes the last of the five findings I reported to batch-core (#2783), which merged without them. This one I held back twice on purpose; the reason is now resolved. ## The dead code `evaluateMergeBlockerGuard` had exactly one reference in the repo: its own declaration. Never called, never re-exported from `index.ts`/`index.gate.ts`, never registered as a trait hook. Its `lifecycleColumns` conversion was applied to dead code, and the census counted it as progress. ## Why I would not delete it earlier, and what changed I twice declined this, because no production `"guard"` trait hook is registered anywhere in the codebase — the only `registerTraitHookImpl(..., "guard", ...)` is in a test. If a registration had been dropped, that would be a real product bug and this function would be its evidence, so deleting it would have destroyed the breadcrumb. It is not missing. Merge blocking is enforced inline in `task-store/moves.ts` (~645 and ~821) via `getTaskMergeBlocker`, gated on the resolved trait flags (`toFacts.flags.complete` + `fromFacts.flags.mergeBlocker`) rather than on column ids — a better implementation than the one being deleted. The logic moved; this function, and a file-header line crediting a never-existent `evaluateDefaultWorkflowGuards` reader, were left behind. The header now records where the guard actually lives, so the next person does not repeat the investigation I just did. Also removed: `GuardVerdict` (its return type, used nowhere else) and the orphaned `getTaskMergeBlocker` import — the latter caught by lint, not by me. ## The gap this exposed The allow-list staleness check only fired for a seam the scan still finds — it asks "is this site supplied now?". Delete the declaration and the name is never iterated, so its entry sits in the list forever, exempting nothing and misreporting what is tolerated. I found this by deleting the function and watching the gate stay silent about its leftover entry. Measured: an `ALLOWED` entry naming a non-existent seam now fails with `no such seam declared any more; remove its ALLOWED entry`; removing the probe returns exit 0. The failure header is reworded, since "the sites are supplied now" no longer covers both reasons. This is the fourth blind spot closed in this check, and like the others it was found by exercising the gate rather than reading it. ## Verification `pnpm test:gate` green · `tsc -p packages/core` 0 · lint 0 · gate now reports 20 seams (was 21 — the drop is this deletion). No changeset: deleting unreachable internal code with no exported surface is behaviour-preserving. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 14:09:10 -07:00
gsxdsm	c601a22c0c	chore(gate): the sortTasksForDisplayColumn exemption is permanent, not pending — with evidence (#2831 ) The last of my five batch-core findings, resolved by not changing code. Recording why, because "leave it" is the kind of decision that rots into "nobody looked". ## What was wrong with the entry It read `TEMPORARY: core-owned; reported on #2783`. That PR merged without picking it up, so the entry implied an owner who was going to act, and none exists. A stale exemption misreports what the project tolerates — exactly the rot the staleness checks exist to prevent, and one they cannot catch: the site is genuinely still unsupplied, so nothing fires. ## Evidence, gathered rather than assumed - Zero callers anywhere. The three dashboard call sites (`Lane`, `Board`, `ListView`) bind to a different function of the same name in `app/components/taskSorting.ts`. Only its own tests pass the flags. - Not reachable externally. `@fusion/core` is private; `@runfusion/fusion` declares no `exports` map and re-exports nothing from core wholesale; it is absent from `plugin-sdk`. So there is no production behaviour to be wrong, and no supplier to wire it from. ## Why I did not "fix" it This check's usual remedy is wire a supplier, or delete the parameter and leave the literal counted. Neither is right here: - Deleting the parameter trades a dormant-but-correct implementation for a dormant legacy-only one. The parameter is optional and harmless; the only thing it costs is that the census once counted it as a conversion when it changed nothing — and that is now recorded rather than hidden. - Deleting the function discards a well-documented ordering (the note enumerates three real renamed-board defects) that someone may plausibly wire later. Both are churn with no product effect, in a package I do not own. The actual resolution is consolidating the duplicate with the dashboard twin — that name collision has already cost real time twice in this lane, including one "fix" `tsc` rejected and one bad cross-batch report. But that is a refactor with a design question attached, and it needs an owner rather than a seam-gate cleanup smuggling it in. ## Verification Gate exit 0 · lint 0. No code 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-30 14:06:20 -07:00
gsxdsm	109204c590	fix: the query class — three sweeps that never ran on a renamed board (#2818 ) Three sweeps that never ran at all on a renamed board, plus the shared answer the rest of the class needs. Consolidated from three handoff branches so the helper appears once. #2811 merged, so this is my only open PR. `#2800` measured this class and shipped evidence deliberately without conversions: `listTasks({ column: "<literal>" })` filters in the store, so on a renamed board the read returns an empty array and the sweep it feeds does nothing. The census scores the comparison inside the loop, never the query above it. ## What was broken \| file \| census count \| what actually happened on a renamed board \| \|---\|---\|---\| \| `backlog-pressure-reporter.ts` \| 0 \| both reads empty, ratio computed as 0/0 — the alert never fired, on a board that may be under exactly the pressure it reports \| \| `stale-task-reporter.ts` \| 0 \| both reads empty — no stale-task signal ever raised, where work is most likely sitting unnoticed \| \| `restart-recovery-coordinator.ts` \| flagged \| sweep never ran — an engine restart left interrupted tasks stuck with no requeue \| Two of the three have a census count of zero. They contain no lifecycle comparison at all, so they have never appeared in the backlog, in a per-file list, or in any "N → 0" claim — and were completely inert. A file at zero is not evidence of anything. ## The shared answer, and what it is not Every existing resolver answers a per-task question. A query has no task in hand, so it needs the project-level one: every column any workflow declares for a role, unioned with the legacy ids so a board mid-rename still finds rows under the old ones. The set is never empty, so a caller cannot accidentally query nothing. The header states what it is not: answering a per-card question from the union would mark a card as review because some other workflow calls its column review — the flat-set mistake this program has made four times. ## The finding that generalises: the query is rarely the whole defect `stale-task-reporter` still reported zero after the query was fixed — `getTaskAgeStalenessSignal` defaults to the legacy pair, so a card the query now returned was refused inside the signal. Converting only the query would have looked like a fix and changed nothing. That is a caveat on #2800's approach, offered as refinement rather than correction: asserting the query ARGUMENT is right when pinning a known defect (the outcome is 0 either way) and insufficient when proving a fix, because the outcome is the only thing that distinguishes a real conversion from a deeper one. All three conversions here assert outcomes. `restart-recovery` had three layers — query, a redundant re-assertion (deleted; a test pins the `paused` guard it did contribute), and a move destination that was already resolved but whose warning comment was stale. A stale warning is its own hazard: it told the next reader a defect existed where none did. ## Verification - helper 8 passed · three reporter/coordinator suites 29 passed - `pnpm test:gate` 161 / 13 / 487 / 71 · lint clean · `--strict` exits 0 · four `tsc` targets clean - each conversion revert-proven independently; the failing case is named in each test header ## Two mistakes worth recording The helper's own test caught a bug in it. My first draft wrapped the definition loop in one `try`, and `parseWorkflowIr` validates rather than parses — one malformed row would have returned legacy-only lanes for every workflow, indistinguishable from the bug it exists to fix. Now isolated per definition. I clobbered the core barrel by taking `index.ts` wholesale from a handoff branch, dropping two exports `main` had added since; three packages stopped compiling. Taking a file from another branch takes its whole contents, including what is now stale — for a barrel that is nearly always wrong. Re-applied as a single edit on top of `main`. ## Not included `self-healing.ts`'s 49 — actively owned and mid-conversion; an outside refactor there produces conflicting halves of one sweep. `project-engine.ts` (7) and `executor.ts` (2) need their own read of what each sweep does with the rows, which these three are the argument for. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 13:55:10 -07:00
gsxdsm	ed83fd6ec3	batch-core: node-override guards let a running task be re-routed on a renamed board (45 → 43) (#2821 ) ## The defect Two guards in `node-override-guard.ts` answered a role question with a column name: - `task.column === "in-progress"` refuses changing a task's node override mid-flight. On a renamed board it never matched, so an operator could re-route a running task — precisely what the guard exists to prevent, and the failure is silent because the guard simply returns `allowed: true`. - `task.column !== "done"` gates overriding to the terminal node. On a renamed board it never matched either, so the override was refused for exactly the tasks that had legitimately reached the end node. Both fail in the direction that looks like normal behaviour rather than an error. ## Why the lanes are injected rather than resolved in place `validateNodeOverrideChange` is synchronous by design, and its existing `isTerminalNodeId` option already establishes the pattern: callers with cheap IR access inject, callers without keep a documented literal fallback. Both production callers now supply the lanes — `branch-and-pr-entities.ts:594` (which already injected `isTerminalNodeId`) and `task-update.ts:53`. That was the deciding factor: an optional parameter that only tests fill is the inert-injection shape this program keeps finding, where a guard reads as converted, its test passes because the test injects the value, and production keeps the literal. I checked both call sites had a store in scope before adding the option. `resolveNodeOverrideLanes` lives beside the guard rather than in the callers, so the two cannot drift about what "executing" and "completed" mean. ## Fallbacks A workflow expressing no trait on any column is a v1 upgrade — `synthesizeDefaultColumns` emits `traits: []` everywhere — not a board without these roles, so it keeps the legacy ids. Same for an unresolvable workflow. Both preserve exactly the behaviour the literals already had. ## Verification - Mutation-verified per guard: restoring `task.column === "in-progress"` fails a case; restoring `task.column !== "done"` fails a different one. - The suite also pins the paired negative — resolving lanes must not turn the guard into a blanket refusal for a task outside every WIP lane. - `node-override-guard.test.ts` → 27 passed - `pnpm test:gate` → 161 + 487 + 13 + 71 - `--strict` → exit 0; `tsc --noEmit` and `pnpm lint` → 0 errors Census: batch-core scope 45 → 43; repo total 255. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - Bug Fixes - Node overrides now correctly recognize workflow-defined in-progress and completed lanes, including renamed columns. - Override validation falls back safely for legacy or unresolved workflows. - Prevented validation from using stale task-column information during updates. - Tests - Added coverage for workflow lane resolution, legacy fallbacks, renamed lanes, and override eligibility. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 13:08:25 -07:00
gsxdsm	ba40942a10	batch-dashboard-app: 75 → 2 across packages/dashboard/app — the last two are deliberate, not missed (#2772 ) Batch branch is live: `batch-dashboard-app`. Push conversions here as commits rather than opening per-file PRs — that is the CI-run bottleneck this model removes. One-line ownership note for you to arbitrate: you have addressed me as U11, U12 and U7 at different points, so the `u12 worker -> batch-dashboard-app` mapping is ambiguous from my side. I claimed it because `dashboard/app` is where I have done the most work this session (TaskContextMenu, Column, TaskCard, TaskDetailModal, columnRoles, taskActivity) and I know which of its guards are load-bearing fallbacks. If another worker is the intended owner, say so and I will hand the branch over rather than both of us pushing to it — two workers on one shared branch is exactly what silently discarded a reviewed fix in #2645 today. ## The work order (measured at branch point, tests excluded) 75 guards across 32 files. Largest: `TaskContextMenu.tsx` 9 · `Column.tsx` 7 · `ListView.tsx` 6 · `TaskDetailModal.tsx` 4 · then a long tail of 3s, 2s and 1s. Full per-file list is in the committed work order so feeders can claim without re-measuring. ## Two rules this surface keeps tripping on 1. A literal after `??`, or in the `else` of a `flags ?` ternary, is a DEGRADED-MODE answer — not an unconverted guard. Two real states reach it: the pre-load window (board renders before the workflows fetch resolves) and a card stranded on an id its workflow no longer declares. In both, `columnFlagsById` has no entry at all. Deleting the fallback does not remove a decision — it substitutes "no role" silently, and affordances vanish during first paint. Those sites reach 0 by marking, not deleting. Expect `TaskContextMenu.tsx` and the `utils` files to be mostly marks. A "9 → 0" that deleted 9 fallbacks is a regression wearing a green census. 2. A marker excuses ONLY the construct it is attached to — the statement or function holding the literal, not a sibling declaration. This has cost three passes, two of them mine; my first attempt on `reliability-metrics.ts` scored 1 of 6. Verify by the count moving, not by the comment existing. With the ratchet gate-blocking, a mis-marked batch either wedges the gate or locks the miss into a re-recorded baseline. ## Status Opening commit is the work order only — 0 of 75 converted so far. I am near the end of my context, so I am establishing the branch and the shared list rather than starting conversions I cannot finish cleanly. Feeders can begin immediately; I will keep the branch rebased. My other PR #2762 (`live-agent-count.ts` 6 → 0) is green and unconflicted — per your rule it should land rather than fold into a batch, and it is `packages/core` so it belongs to batch-core anyway. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * New Features * Task UI now resolves workflow “column roles” per task to drive diffs/merge details, routing/steering, progress/runtime visibility, and review badges. * Right-dock/overflow views and dev-server now use per-task column traits for “executing” behavior and dependency-based “Up Next” eligibility. * Bug Fixes * Fixed bulk action selection/delete/archive eligibility and prevented cross-workflow role leakage. * Made in-review/stale-paused-review, stuck, and effective executor/validator model logic role-aware. * Tests * Added regression coverage for degraded-flag behavior and ensured resolved-flag props aren’t ignored. * Added a static check to fail builds on inert optional flag seams. * Documentation * Updated batch work-order and mega-batch branch guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --- ## Late addition: the seam gate was masking a real offender `scripts/check-inert-flag-seams.mjs` matched call sites by NAME, so two same-named functions in different modules were conflated. I had documented that as a known false-positive source and moved on — reports mentioning `sortTasksForDisplayColumn` are noise, read past them. That annotation was the damage. Core's `sortTasksForDisplayColumn` genuinely never receives its `columnFlags` argument outside its own tests. The dashboard's separate function of the same name (`app/components/taskSorting.ts`), called with up to five arguments from `Lane`/`Board`/`ListView`, was raising the arg-count max and clearing core's seam. The offender was behind a row everyone had been told to skip. The gate now records the module each callee is imported from and matches it against the seam's declaring module. Measured, by reverting the change: the scan prints `17 seams, all supplied` and emits no row for the function. With the change, it is reported. Both directions watched. Reported on #2783 rather than fixed from outside — core owns it, and "wire the flags" vs "drop the parameter and let the literal stay counted" is their judgment call. TEMPORARY allow-list entry carries it meanwhile; the existing staleness check fails the moment the site becomes supplied, so the entry cannot outlive the fix. Two known limits remain, both inherent to name matching and both documented in the script: the one-supplier floor, and the `__tests__` exclusion (hence the two permanent `ALLOWED` entries). ## And the one-supplier floor, closed the same way I wrote in the section above that the floor "hasn't cost anything yet." That is verbatim the reasoning that kept the imported-shadow bug alive, so I closed it instead of leaving the note. `best < arity` asked only whether SOME caller supplied the argument. One correct call site cleared the seam while every sibling took the legacy fallback — the `isTaskStuck` defect class, where two of three sites omitted the flags and the gate stayed green because the third was right. Review caught that one. A partially-supplied seam is the harder of the two: wholly-unsupplied is uniformly wrong, this works on the board you tested and degrades on the column you did not. Measured: dropping the flags argument at `Column.tsx`'s supplied call site produces `supplied by 5/6 call sites; omitted at packages/dashboard/app/components/Column.tsx:1 (of 2)`; restoring returns `all supplied at every call site`. Red and green both watched. Two real omissions found, both on `isNearDuplicateCanonicalInactive`: - `TaskDetailModal.tsx` — deliberate, and it corrects a note I left at that site. The old note said hoisting the flags state was "the actual fix." It is not, for this call: the flags in scope describe the modal's task, and the canonical is a different task on a column this component never resolves. Passing them would type-check, read as a conversion, and answer about the wrong task — exactly what `column-role-degraded-flags.test.ts` exists to catch. Supplying it correctly needs a fetch, which is a data change and out of scope. - `core/task-store/branch-group-ops.ts` — genuinely wireable (the impl is async and already holds `store` and `canonicalId`). Reported on #2783, not edited from outside. Exemptions for this class are keyed by call site (`<file>::<function>`), not by function name. A name-level entry would waive every site of a partially-supplied seam, which is backwards — its other sites are correct and are the reason the omission is worth reporting. Both entries carry the same staleness check as the name-level list and cannot outlive their fix. Remaining known limit, now the only one: the `__tests__` exclusion, which makes a test-only export read as having no callers. That is what the two permanent `ALLOWED` entries are. ## The `__tests__` exclusion, and two allow-list entries built on false reasons Named as the "last remaining limit" above, so it got closed too. The scan now reads test files for call sites — but counts them separately, and a test never clears a seam. That direction is the dangerous one: counting test callers as suppliers would have re-hidden core's `sortTasksForDisplayColumn`, whose only suppliers are its own tests. Measured by lifting its exemption: still reported. Both permanent allow-list entries claimed the scanner couldn't see their callers. Both reasons were false, and reading tests is what proved it: - `evaluateMergeBlockerGuard` — zero callers in tests either. Its only reference in the repo is its own declaration; never registered as a trait hook; the `evaluateDefaultWorkflowGuards` reader its file header credits does not exist. The `lifecycleColumns` conversion went onto dead code, and its note describes a crossing the guard cannot make. Reported on #2783, including the two things I am explicitly not concluding (no `"guard"` hook is registered in production; whether that is residue or a dropped registration needs core's intent). - `isRecoverableMissingWorktreeReviewFailure` — 5 test call sites. It wraps `...WithProgress`/`...NoProgress`, the live pair called from `self-healing.ts`, both supplying `reviewColumns`. Entry kept, true reason recorded. ### A wrong turn, recorded because it is the failure mode this PR is about I first classified no-production-caller seams as informational when they weren't re-exported from a package index, reasoning that a public export might be called externally. That silently downgraded `sortTasksForDisplayColumn` — a confirmed real offender — from failing to a footnote. Publication status has nothing to do with whether there is production behaviour to be wrong. Reverted to the simple rule: no production caller means inert, and it fails. It is worth stating plainly because it is the exact shape of everything else in this PR: a change that made the gate read cleaner while making it catch less, and it type-checked, passed every test, and would have reviewed fine. ### Where that leaves the check Every blind spot named in this PR has now been closed, and each one produced a real defect within minutes of closing it — imported shadows, the one-supplier floor, the `__tests__` exclusion. Four verified findings went to core, one to engine. I would not read the remaining ~240 guards' green gates as evidence that they are clean; I would read them as untested. ## Two guards for one question, one of them worse Having hardened the script, I checked its older twin rather than assuming it was fine. `resolved-flags-seams-have-suppliers.test.ts` carried its own copy of the trailing-flags-parameter check — written before the script existed — with all three holes the script has since closed. Measured on one reintroduced defect (dropping the flags argument at `Column.tsx`'s supplied `isNearDuplicateCanonicalInactive` call): \| \| result \| \|---\|---\| \| `scripts/check-inert-flag-seams.mjs` \| `supplied by 5/6 call sites; omitted at .../Column.tsx:1 (of 2)` \| \| this test's arity half \| 3 passed \| Deleted the arity half. Redundancy between a strong and a weak check isn't redundancy — it's a green result available to whoever runs the weak one, and there was no signal at the call site telling you which you were looking at. The props-shape half stays: it has no twin in the script, and I confirmed it still fires by reintroducing the original `PrPanel` defect (outer component stops destructuring `taskColumnFlags`) — it reports `PrPanel declares taskColumnFlags but never takes it`. Dashboard app suite: 113 files / 3921 tests (was 3922 — the deleted case is the difference). ## The gate started catching defects as they landed Syncing with main brought in three fresh conversions from other workers. The hardened check flagged all three immediately — the first time these guards have fired on someone else's landed code rather than on my own. - `TaskCard` — `getRunningOptionalGateBadge(task)` omitted flags while both `ListView` sites supplied. Fixed, and `taskColumnFlags` added to the `useMemo` deps: no `exhaustive-deps` rule here, so a memo that reads flags without listing them keeps the first-paint `undefined` answer and reproduces the bug through staleness instead of omission. - `TaskTokenStatsPanel` — `getTotalAgentActiveMs` omitted while `TaskCard` supplied, so the same runtime number came from the real column on a card and from legacy ids in the detail modal. Now takes `columnFlags`, supplied from `detailColumnFlags` — correct here because the panel renders the modal's own task, unlike the near-duplicate canonical above. - `ListView` ×2 — passed `columnFlagsById.get(task.column)`, the cross-workflow union. A task whose own workflow doesn't declare that column gets a neighbour workflow's traits. The landed comment justified it as "this list already owns `columnFlagsById`" — exactly the reasoning `column-role-degraded-flags.test.ts` exists to reject. It failed on merge and is how I found this. Also: the `getTotalAgentActiveMs` exemption I was carrying self-retired. Main wired the seam, the staleness check failed the entry, and I removed it. That mechanism has now paid for itself once. ### Pre-existing, NOT from this PR: `App.test.tsx` is red on main `app/components/__tests__/App.test.tsx` fails 10 of 141 identically with my changes, with my changes stashed, and with main's own `App.tsx` restored. Not mine, and not in the merge gate. Bisected on clean `main` checkouts, so this is measured rather than inferred: \| commit \| date \| result \| \|---\|---\|---\| \| `main~400` (`41d60f0355`) \| 2026-07-25 \| 140 passed (140 tests) \| \| `main~275` (`74d6513fae`) \| 2026-07-27 \| 3 failed / 141 \| \| `main~210` (`d2ce1ba8b5`) \| 2026-07-29 \| 10 failed / 141 \| \| `main` (`6fc98fd6c7`) \| 2026-07-30 \| 10 failed / 141 \| So it is not one regression — it degraded in two stages across 2026-07-25 → 07-29, and the test file itself changed in that window (140 → 141 tests). Three commits touched it there: `73b2a32e2b`, `f26cbedf4f`, `f157bf7460`. That window overlaps the workflow-owned lifecycle migration, which is suggestive but not something I confirmed. The failures are render-level, not assertion-level — `Unable to find an element with the text: + New Task`, `Unable to find role="dialog"`, `Unable to find ... Back nav task`. The board appears to render nothing. That reads like a real regression or a harness mismatch after the lifecycle migration, not a flake, so I have deliberately not quarantined it — quarantine is for flakes, and using it here would hide the signal. Flagging for whoever owns `App.tsx`. My suites: `app/__tests__` 113 files / 3921 tests green, `tsc` 0, lint 0, census `--strict` 0, seam gate 0. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:46:12 -07:00
gsxdsm	2ccd78abbc	fix: main is red on the lifecycle ratchet — re-record the census baseline (#2811 ) `main` is RED on the lifecycle ratchet right now. `node scripts/lifecycle-column-census.mjs --strict` exits 1 on pristine `origin/main`, which is the `Lint` job's Lifecycle-column ratchet step — so every open PR fails Lint until this lands, regardless of its own contents. Verified on a detached checkout of `origin/main`, not on a branch of mine. ## Cause Eight `DELIBERATE-LITERAL` markers were added across seven files without re-recording the baseline: ``` packages/core/src/task-move-disposer.ts (in-progress, todo) packages/core/src/task-store/archive-lifecycle-2.ts (archived) packages/dashboard/src/github-tracking-comments.ts (done) packages/dashboard/src/gitlab-tracking-comments.ts (in-progress) packages/dashboard/src/server.ts (archived) packages/dashboard/src/task-planner-chat-context.ts (done) packages/dashboard/src/test/mockCoreEngine.ts (in-review) ``` Adding a marker RECLASSIFIES a site (column-guard → deliberate), so the tracked deliberate totals move and `--strict` fails until the baseline records the new shape. It is the same mechanism that turned #2775 red earlier today — a marker landing without its baseline — which is worth noting because it has now happened twice from different PRs. ## The fix Baseline re-recorded, nothing else. Zero source changes; the diff is one derived file. - `--strict` exits 0 - `pnpm test:gate` — 161 / 13 / 487 / 71 - `pnpm lint` clean ## Worth a follow-up by whoever owns the ratchet The failure is structural rather than careless: a PR that adds a marker is doing the right thing, and the baseline requirement is only discovered when CI goes red — after merge, for everyone else. Two options, neither of which I am taking unilaterally on a red-main fix: 1. have `--strict` treat a marker-only reclassification as an accepted rise (it is not new debt — the count of unconverted guards goes down); 2. or fail the PR that adds the marker, by comparing against the base ref rather than the recorded baseline — the machinery for that already exists in this script. I would take (1): a marker is the documented way to close a site, and requiring a second mechanical step to record it is a trap that catches good behaviour. 🤖 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 lifecycle census error messages to distinguish genuine increases in column-guard debt from reclassified deliberate literals. * Added clearer remediation guidance for reclassified results, including when to update the baseline. * Updated lifecycle census baseline mappings to reflect current classifications. * Tests * Added coverage for unchanged baselines, genuine guard-count increases, and marker-only reclassification scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:40:05 -07:00
gsxdsm	6fc98fd6c7	the third census-invisible class: 51 hardcoded moveTask destinations, measured — and duplicates never archived on a renamed board (#2808 ) A third census-invisible class, measured — plus the two worst instances fixed. ## The shape ```ts if (task.column !== "in-review") { … return; } // the census counts THIS await this.store.moveTask(taskId, "in-progress"); // and cannot see THIS ``` The census is an AST scan for comparisons. A `moveTask` destination is a call argument, so no backlog entry ever points at one. Converting the guard alone is worse than converting neither: the handler starts admitting work on a renamed board and then tries to move the card into a lane that board may not declare. This bit twice in one week — #2797 (`branch-worktree` requeued into a lane that may not exist) and #2807 (a GitHub "changes requested" review dropped, then a move to a hardcoded `in-progress`). Both times it was found only because the guard next to it happened to be under conversion. So I went looking. ## Measured Across `core`/`engine`/`dashboard`/`cli`/`plugins`, excluding `__tests__`/`.test.` and comment lines: \| \| count \| \| --- \| ---: \| \| hardcoded `moveTask` destinations in production \| 51 \| \| …passing `recoveryRehome: true` — deliberate, not defects \| 22 \| \| …plain, rejected on a board that does not declare the target \| 29 \| The 22 must not be "fixed". `moves.ts` exempts them on purpose (#1411): a card stranded in an undeclared column has to stay rescuable to a legacy safe-landing column, or it can never be recovered at all. A sweep that converts them deletes the rescue path. That distinction is the reason this is 29 and not 51, and it is why I measured before writing. ## Why this got sharper recently The `workflowHasColumn(workflowIr, toColumn)` rejection used to sit inside a block gated on `isWorkflowColumnsCompatibilityFlagEnabled` — a settings key nothing in production writes — so it never executed and the legacy `VALID_TRANSITIONS` table decided instead. U12 hoisted it out of that dead branch and it is now live, proven on a real store by `live-move-path-undeclared-target.test.ts`: ``` moveTask(card in "todo" -> "triage") now REJECTS: /Unknown column for this workflow/ ``` That changed the failure mode of all 29 from "silently lands the card in an undeclared column" to "throws". 29 is not a crash count. Whether a throw surfaces or disappears depends on whether the caller catches, which is per-site and I did not measure it — the doc says so explicitly rather than letting the number imply severity it hasn't earned. ## Fixed here: 9 of the 29 `duplicate-intake` and `duplicate-guard` both archive a duplicate. On a renamed archive lane the move is rejected, so the duplicate is never archived and keeps sitting on the operator's board as live work — and in `duplicate-guard` the row has already been stamped `deterministicDuplicateOf`, so it is marked a duplicate while occupying an active lane. Half-applied, which is the same trap as #2797's branch clear. Both now resolve the `archived`-trait column from the task's own workflow through one shared helper, unioned with the legacy id. `cli/commands/task-lifecycle` — `finalizePullRequestMerge` and `finalizeNoOpMergeTask` both move the card to a hardcoded `"done"`, and both run `updateTask({ status: null, mergeRetries: 0 })` first. On a rejection the merge has already landed and the bookkeeping is already cleared while the card never reaches its complete lane: the operator sees a merged branch, a card still sitting in review, and a reset retry counter. Same half-applied shape as #2797's branch clear. Both now route through one resolver so they cannot drift. `contamination` / `foreign-only-contamination` (×2) / `restart-recovery-coordinator` — four recovery requeues to a hardcoded `"todo"`, none of them a `recoveryRehome` escape. On a board without that column the move is rejected and the recovery never completes — the card stays contaminated or stranded, which is precisely the state these paths exist to clear. Consolidation. `resolveReboundTargetForTask` and `resolveArchiveTargetForTask` now live beside `resolveTaskLifecycleColumns` in `workflow-lifecycle-traits`, already the store-dependent resolution seam. My first pass put the archive helper inside `duplicate-intake` and had `duplicate-guard` import it from there — wrong home, and it would have grown a copy per caller as more sites converted. Seven call sites now share two definitions. Plain (non-`recoveryRehome`) destinations: 29 → 21. Coverage on the CLI pair is scoped, and I'd rather say so than imply more: the test covers the resolver, not the two call sites. Both enclosing functions are private and reachable only through `processPullRequest`, which needs a live GitHub surface — exporting them purely to test wiring is a worse trade than stating what is covered. Three cases: renamed lane resolves, no-workflow falls back to the legacy id (which also pins that a default board is byte-identical), and a throwing lookup falls back. ## Revert result (measured) \| conversion \| reverted → \| \| --- \| --- \| \| duplicate archive destination \| new case fails — `moveTask` called with `"archived"` on a board whose archive lane is `boxed` \| \| CLI complete-lane resolver \| replacing the body with a bare `return "done"` fails the renamed case \| \| both move-target resolvers \| replacing either body with a bare return of its legacy id fails 5 cases across the resolver suite and `duplicate-guard` \| Each resolver has a non-vacuous companion asserting it does not return the legacy id on a renamed board — without it, a resolver returning any string would pass. The fallback cases are load-bearing rather than padding: `resolveWorkflowIrForTask` degrades to the built-in IR rather than throwing, and the built-in rebound/archive lanes are `todo`/`archived`, so those cases also pin that a default board is byte-identical. The pre-existing case asserting the legacy `"archived"` passes both ways, which is exactly why it could not detect this and why the new one supplies a workflow. ## Ownership note `packages/core` was `batch-core`'s territory and `packages/cli` was `batch-cli-plugins`'. Both batches have landed, and this is newly-discovered work in the class documented here rather than leftover conversion backlog. Four sites, two shared helpers — happy for either half to move if those owners would rather carry it. ## Verification - `pnpm test:gate` — 161 + 487 + 13 + 71, green - `duplicate-guard` + `duplicate-intake` — 40 passed - `tsc` on core and engine — clean - `pnpm lint`, `check:changesets`, census `--strict` — all clean (run explicitly; a clean `pnpm lint` alone is not evidence the CI Lint check passes) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - Bug Fixes - Duplicate tasks are now archived to each workflow’s configured archive lane. - Completed tasks are moved to the workflow-specific completion lane, with a safe fallback for older workflows. - Recovery and requeue actions now use each workflow’s configured rebound lane instead of assuming a fixed destination. - Documentation - Added guidance on avoiding failures caused by hardcoded workflow destinations and incomplete lifecycle conversions. - Tests - Added coverage for renamed workflow lanes, fallback behavior, duplicate archiving, and recovery destinations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:25:00 -07:00
gsxdsm	b7288572a1	engine: a GitHub "changes requested" review was silently dropped on a renamed board (1 → 0) (#2807 ) A human reviewer's feedback was being thrown away. `PrCommentHandler.handleChangesRequested` gated on `task.column !== "in-review"` and returned early. On any board whose review lane is renamed, a GitHub "changes requested" review produced no steering comment and the card never went back to work — the feedback vanished behind a log line nobody reads. No error, no audit row. ## Census \| file \| main \| here \| \| --- \| ---: \| ---: \| \| `packages/engine/src/pr-comment-handler.ts` \| 1 \| 0 \| ## Two literals, only one countable — again ```ts if (task.column !== "in-review") { … return; } // counted … await this.store.moveTask(taskId, "in-progress"); // INVISIBLE to the census ``` The census scores comparisons. The requeue destination is a call argument, so nothing in the backlog pointed at it — the same pairing as the branch-worktree auto-requeue in #2797, and the same trap: converting the gate alone would make the handler admit the review and then attempt a move into a lane the board may not declare, which `moveTask` rejects. A half-conversion here turns a silent drop into a thrown rejection. They convert together or not at all. That is now the second confirmed instance of this shape. The pattern to look for is a counted guard whose body performs a hardcoded `moveTask` — the guard is the visible half and the move is the dangerous one. ## Revert results (measured, each run independently) \| conversion \| reverted → \| \| --- \| --- \| \| review-lane gate \| RENAMED case fails — `updateTask`/`moveTask` never called; the review is dropped \| \| requeue destination \| RENAMED case fails — `moveTask` called with `"in-progress"` instead of the board's wip lane \| The legacy case passes both ways, which is why both vocabularies run. A non-vacuous companion (renamed board, card sitting in the hold lane) keeps a gate that admits everything from passing. ## Verification - `pnpm test:gate` — 161 + 487 + 13 + 71, green - `pr-comment-handler.test.ts` — 34 passed - `npx tsc -p packages/engine/tsconfig.json --noEmit` — clean - `pnpm lint` — clean - `node scripts/lifecycle-column-census.mjs --strict` — exit 0 (Running the census explicitly, not just `pnpm lint`: CI's Lint job runs both, and a clean local `pnpm lint` is not evidence the Lint check passes — that cost a round-trip on #2797.)	2026-07-30 12:06:14 -07:00
gsxdsm	e84e9d7f60	fix: the caller audit — five unwired parameters, five defects in their callers (#2803 ) Seven fixes that were sitting on separate handoff branches with no owner while `main` moved. Consolidated, rebased onto current `main`, and verified together rather than only per-branch. The individual branches remain if a subset is preferred. This is the same consolidation that got `batch-core` and #2787 adopted. Close it if it breaks queue policy — the branch keeps the work safe either way. ## Where these came from #2787's review found an optional parameter whose production caller never passed it. That is a class, so I ran it against everything I had landed and found five more. All five turned out to have their real defect in the CALLER, not the parameter — in four of them the parameter was unreachable: \| unwired parameter \| what was actually wrong \| \|---\|---\| \| `blocker-fanout.escalationColumns` \| the hold default made the count zero — no bottleneck warning was emitted at all \| \| analytics `columnFlagsByName` \| routes never built a map — 0 in-progress / 0 in-review beside correct cost totals \| \| `isLegacyAutoMergeStampCandidate` \| the read queried a column a renamed board does not have, so the backfill iterated nothing \| \| `rankAssignedTasksForWakeDelta` \| `getTasksByAssignedAgent`'s `excludeArchived` used the literal — archived cards returned as open work \| \| `duplicate-intake.columnFlagsByColumnId` \| intake could archive or soft-delete a newly created task as a duplicate of finished work \| The heuristic worth keeping: an optional parameter no production caller fills is a marker pointing at an unexamined caller. The census cannot see any of these five — every gate is a `Set`/array literal or a query filter, i.e. a definition rather than a comparison. ## Also included - `executor.ts` — the stale-spec guard did the exact thing its own comment forbids: on a renamed board it ran on a LIVE task and pulled it out of execution into replan. `activeMergeStatuses` protected merging cards by accident, which is why the symptom looked arbitrary. - `register-project-routes.ts` — project health reported 0 active tasks; its list also still contained `triage`, dead since U11. - `dashboard/app/utils/taskTiming.ts` — a second copy of `getTotalAgentActiveMs`. Core's was converted; the card chip imports this one, so the census counted the site as done while the rendered number stayed keyed on `"in-progress"`. ## Verification Verified as a set: `pnpm test:gate` 161 / 13 / 487 / 71 · core suites 15 passed · engine 7 · dashboard 12 · four `tsc` targets clean · lint clean · census `--strict` exits 0. Each fix is revert-proven individually; the specific case that fails is named in each test header. ## Two honesty notes Three guards here are structural, not behavioural, and say so in their headers. `sanitizeAgentTaskLinks` is a closure inside `createApiRoutes`; the analytics aggregators need a live `AsyncDataLayer`; the stale-spec guard sits deep inside `execute()`. Each ratchet fails on revert — verified — but none is an end-to-end proof, and the headers state which half they cover. One of my behavioural test sets would have lied. The intake-dedup cases drive `findSameAgentDuplicates` directly; I removed the wiring to measure the revert and they stayed green, because they pin the predicate and not the caller. That is the exact illusion this audit was chasing, reproduced in my own file. The forward now has its own structural check. ## Deliberately not included `worktree-pool.ts:1205` — it fails safe (a missed match protects a branch from cleanup rather than deleting it) and sits in the merger's branch-reaping path where the opposite error destroys work. That deserves its owner's judgement, not a drive-by conversion. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:02:53 -07:00
gsxdsm	a8cfce8fbd	executor: stale merge evidence re-entering execution, and a live checkout that read as unowned (12 → 8) (#2805 ) Two executor conversions with real operator consequences, one census false positive, and three sites deliberately left with their reasons recorded. ## Census \| file \| main \| here \| \| --- \| ---: \| ---: \| \| `packages/engine/src/executor.ts` \| 12 \| 8 \| Of the 4: three genuine conversions, one reclassification. ## What was broken `resetMergeStateIfNeeded` — cards re-entered execution carrying stale merge evidence. Merge state is cleared when a card leaves a lane where a merge could have been recorded. Keyed on `in-review`/`done`, a renamed board matched neither, so a card bouncing back into execution kept `mergeDetails` — including a commit sha from its previous pass — into its next run. `review` is not a trait, so this resolves through the same five flags (`complete`, `mergeOrchestration`, `mergeBlocker`, `humanReview`) the dependency gates in this file already use; two gates answering "is this a merge-bearing lane?" differently would be a split brain. The worktree-owner scan — a live checkout read as unowned. `findActiveWorktreeOwner` asks "is anyone else working in this checkout?". Its in-memory `activeWorktrees` leg is vocabulary-independent, but the durable leg — the one that answers after an engine restart, when the in-memory map is empty — filtered with `t.column !== "in-progress"`. On a renamed board that matched nobody, so the worktree read as free and a second task could be handed a checkout another task is live in. Post-restart is exactly when this function matters. Not the query-filter class: that `listTasks` call passes no `column`, so the predicate is the only lane gate on the path. ## A third census false positive in this package Line 16094's `to` is a review-addressing record status — the method signature is `to: "queued" \| "in-progress" \| "addressed" \| "failed"`, and the next two lines test it against `"addressed"` and `"failed"`, which are not columns at all. Marked `DELIBERATE-LITERAL`. That is the third in `packages/engine` after the two `cli-agent` `CliMachineState` ones (#2797). The backlog total includes non-columns; a sweep that "converts" them turns a status machine into a workflow role. ## Revert results (measured, each run independently) \| conversion \| reverted → \| \| --- \| --- \| \| worktree-owner wip predicate \| RENAMED case fails — checkout reads as free while another task is live in it \| \| `resetMergeStateIfNeeded` lanes \| RENAMED case fails — card keeps `commitSha: "abc123"` from its previous pass \| Both DEFAULT cases pass before and after, which is why both vocabularies run. Each has a non-vacuous companion (holder sitting in the complete lane; a return from the hold lane) so a predicate matching every column would not pass. Both reach their seam directly through a cast. The public routes are `handleBranchConflict` (needs a real `BranchConflictError` plus a git repo) and the `task:moved` listener (drags in the whole `execute()` path); going through either would make these tests about a git fixture rather than about the lane predicate. The alternative was the status quo — all 91 `executor-worktree.test.ts` cases seed `column: "in-progress"`, so they assert the legacy fallback and pass either way. I shipped the conversions in one commit stating* they were unproven, then closed that gap in the next; the history shows both. ### Two fake defects found while writing those tests Worth naming, because both are the documented green-for-the-wrong-reason shape: 1. The first fake had no `updateTask`, so the cleanup threw rather than asserting anything. 2. The second returned a new object without persisting — and `cleanupMergeStateForReverification` re-reads through `getTask`. The re-read handed back the stale row, so both vocabularies reported "nothing changed" and it would have read as a passing negative test. ## Deliberately NOT converted, with reasons - The `task:moved` listener cluster (`3521`/`3545`/`3596`/`3606`), including the AGENTS Move-Task hard-cancel contract `userCanceled: source === "user" && to === "todo"`. Its prologue is synchronous (`userCanceledTaskIds.delete`, watchdog clear) and deferring it to a microtask changes hard-cancel ordering. The sync IR reader is not an option — it returns the DEFAULT workflow for every task in production. A safe conversion needs lanes resolved on an earlier async boundary: new machinery plus an ordering change, which is out of fleet scope and not a guess worth making on a hard-cancel path. - `17081` pairs `latestColumn === "in-progress"` with a hardcoded `moveTask(taskId, "in-progress")` two lines above — census-invisible, the same shape as the branch-worktree requeue bug in #2797. They have to convert together, and the move needs the same rejection guard. - `5903` is the query-filter class: `listTasks({ column: "in-progress" })` followed by a re-assertion of the same literal. Converting it drops a count and changes nothing — see `docs/solutions/architecture-patterns/self-healing-sweeps-are-blind-on-a-renamed-board.md` (#2800). ## Verification - `pnpm test:gate` — 161 + 487 + 13 + 71, green - `npx tsc -p packages/engine/tsconfig.json --noEmit` — clean - `pnpm lint` — clean - `--strict` exits 0 --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 12:02:41 -07:00
gsxdsm	f9f06a4fb7	engine tail: nine files to zero — incl. a census-INVISIBLE requeue into a lane that does not exist (−13) (#2797 ) Follow-up to #2785. Nine engine files to zero, all one question — "is this task finished?" — asked in nine places, wrong in every one on a renamed board. ## Census, per file (measured, `--strict` verified) \| file \| main \| here \| \| --- \| ---: \| ---: \| \| `agent-reflection.ts` \| 2 \| 0 \| \| `merger-scope-auto-widen.ts` \| 2 \| 0 \| \| `worktree-pool.ts` \| 2 \| 0 \| \| `cli-agent/state-machine.ts` \| 2 \| 0 (reclassified — see below) \| \| `auto-recovery-handlers/branch-worktree.ts` \| 1 \| 0 \| \| `cli-agent/task-session.ts` \| 1 \| 0 (reclassified) \| \| `merger-integration-worktree.ts` \| 1 \| 0 \| \| `merger-orphan-rehome.ts` \| 1 \| 0 \| \| `plugin-runner.ts` \| 1 \| 0 \| \| net \| \| −13 \| ## The one worth reading: `branch-worktree` had TWO defects, and the census could only see one ```ts if (task.column === "in-progress") { …clear branch… } // counted await this.deps.taskStore.moveTask(task.id, "todo", { … }); // INVISIBLE ``` The census scores comparisons. The requeue destination is a call argument, so nothing in the backlog ever pointed at it — and it is the worse of the two: a board with no `todo` column was requeued into a lane that does not exist. The counted literal is the smaller half (a renamed wip lane meant the stale branch was never cleared, so the card carried a dead branch back into execution). Converting the comparison alone would have dropped a census count and left the board requeuing into nowhere. Destination now resolves through `resolveReboundTarget` (KTD-10 ordering: hold → intake → first column). Reverted independently: destination restored → 2 fail (`moveTask` called with `"todo"`, not `"backlog"`); wip test restored → 1 fail (`updateTask` never called). ## The rest - `plugin-runner` — `onTaskCompleted` never fired on a renamed board. Every plugin that closes an issue, posts a notification, or records a metric on completion silently stopped, with nothing logged. Resolved asynchronously inside the existing fire-and-forget seam, not via `resolveTaskWorkflowIrSync` — per `sync-workflow-ir-callsite-allowlist` that reader returns the DEFAULT workflow for every task in production, so a sync guard here would read as converted and still be wrong. The listener is already `void`-dispatched, so awaiting inside it changes no observable ordering (the shape `NotificationService` already uses). - `merger-orphan-rehome` — a renamed complete lane made every source task read as unfinished, so orphaned commits were never rehomed and stayed stranded off the integration branch. Resolves by the trailer id, not `sourceTask.id`, which the fake store does not populate. - `agent-reflection` — `classifyOutcome` returned `null` for every finished task, so both callers treated completed work as nothing to reflect on: one recorded `reflection:skipped` with reason `"not-completed"`, the other silently `continue`d. Reflection captured nothing at all on a custom board. - `worktree-pool` — shipped tasks' worktrees stayed in the ACTIVE set, so the reclaim pass never returned them and the board walks into worktree exhaustion — a stall whose cause is invisible from the symptom. - `merger-scope-auto-widen` — finished cards counted as active claimants, so a merge was blocked by a task that no longer exists in any meaningful sense. - `merger-integration-worktree` — a shipped task still counted as a live worktree user, so the integration worktree could never be reused and the merge path took the slower rebuild every time. ## The census OVERSTATED the engine backlog by 3 `cli-agent/state-machine.ts` and `cli-agent/task-session.ts` compare against `done` — but that is a `CliMachineState` (`ready`/`busy`/`waitingOnInput`/`done`/`resuming`/`idle`) tracking one CLI agent process. It never reads a board column. The census matches the bare string. Marked `DELIBERATE-LITERAL` rather than left for a later sweep to "convert" a process state into a workflow role. Worth flagging fleet-wide: the backlog total includes at least these three non-columns. ## Revert results (measured, each run) \| conversion \| reverted → \| \| --- \| --- \| \| `plugin-runner` complete gate \| RENAMED case fails — `onTaskCompleted` never invoked \| \| `merger-orphan-rehome` source gate \| RENAMED case fails — `orphan:false, reason:"source-task-not-done"` \| \| `branch-worktree` destination \| 2 fail — `moveTask` called with `"todo"` \| \| `branch-worktree` wip test \| 1 fail — `updateTask` never called \| Each has a non-vacuous companion (renamed board, non-complete lane / mid-flight source / non-wip column) so a guard that fired unconditionally would not pass. Four are NOT revert-proven, and I am not claiming otherwise: `agent-reflection`, `merger-scope-auto-widen`, `merger-integration-worktree`, `worktree-pool`. Their suites omit a workflow and therefore assert the legacy fallback — they pass before and after. `merger-scope-auto-widen` has no test file at all; `scanIdleWorktrees` is mocked in every suite that touches it and driving it for real needs git worktrees on disk. All four strictly widen the finished set (resolved roles ∪ the legacy ids), so default boards are byte-identical. That is the argument for shipping them, not a substitute for coverage. ## Examined and deliberately NOT converted - `backlog-pressure-reporter:173` — fed by `listTasks({ column: "todo" })`, a hardcoded query filter. On a renamed board `todoFull` is empty and the predicate never runs. Converting it drops a census count and changes nothing observable; the fix belongs at the query layer. - `auto-merge-finalization:28` — the catch-arm legacy fallback, which must stay for the same reason `columnRoles.ts` keeps its id fallback. - `auto-merge-finalization:84` — only selects between two diagnostic reason strings that are both `ok: false`, on a pure validator with no store in scope. Converting it would thread a store through a pure function to change a label. ## Merge resolution note Merging main brought conflicts in `agent-assignment.ts` and `ephemeral-worker-manager.ts`. Main's versions won both and mine are dropped: main threads an optional `activeColumns` from `scheduler.ts:2340` (a cleaner seam than widening the store type to resolve internally), and its `isAgentIdle` carries a greptile P1 fix mine lacked — `columnsWithFlag` membership rather than first-per-role, so a workflow declaring two wip lanes has both recognised. That is the fourth time in this program main's version of a contested file was the better one. ## Verification - `pnpm test:gate` — 161 + 487 + 13 + 71, green - `npx tsc -p packages/engine/tsconfig.json --noEmit` — clean - `pnpm lint` — clean - `--strict` exits 0 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Workflow-dependent task completion now recognizes custom lifecycle columns, including renamed boards. * Recovery requeues tasks to the configured destination and clears branch details only from the appropriate work-in-progress column. * Improved handling of completed tasks, orphaned work, shared worktrees, and scope evaluation across custom workflows. * Plugin completion hooks now trigger for any column configured as complete. * Tests * Added coverage for renamed workflow columns and custom completion, recovery, and rehoming behavior. * Documentation * Clarified CLI state terminology in internal developer comments. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 11:28:54 -07:00
gsxdsm	5795d70b27	fix(engine): assignment load must be resolved per task — #2787 P1 follow-up (#2796 ) Fix-forward for the P1 that arrived on #2787 after it merged — so it lands as its own PR rather than a thread reply on merged code. ## The finding `selectPermanentAgentForTask`'s `activeColumns` was resolved from the candidate task's workflow and then applied to every row `listTasks` returned. On a project running several workflows — the normal case — assignments living in another workflow's load-bearing lanes vanished from the tally, and the already-loaded-agent-wins bug returned through a different door. A column id means something only relative to its OWN workflow. `blocker-fanout.ts` documents exactly this and offers a per-task `classify`; the option is now that same shape rather than a third invention: ```ts countsAsAssignmentLoad?: (task: Task) => boolean ``` The scheduler resolves each assigned row against its own IR, sharing one cache for the selection, so a board spanning three workflows reads three IRs — not one per assigned card. ## Why this is the third round on the same parameter, stated plainly 1. I added the parameter and never wired the caller — inert in production. 2. I wired it as a union of wip+review, which dropped hold/intake and made it a regression for backlog work. 3. I resolved it from one workflow and applied it to all — this fix. Each round was a smaller version of the same error: treating a lane answer as global when it is per-task, and per-role when it is per-membership. Worth recording because the first two rounds both looked correct and both passed their tests — the tests asserted the renamed case I was thinking about, not the shape of the data. ## Verification - new cross-workflow case; reverting the predicate to a single workflow's lanes fails it - `agent-assignment` suite 14 passed - `pnpm test:gate` — 161 / 13 / 487 / 71 · lint clean · census `--strict` exits 0 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 11:06:20 -07:00
gsxdsm	90f6319b79	batch-engine tail: re-land the ASYNC half; the sync-resolved half was inert (engine −15) (#2785 ) Tail of `batch-engine` (#2773). That PR merged as a squash while later engine work was still in flight, so `self-healing.ts`, `executor.ts` and `worktree-pool.ts` landed at their pre-conversion counts. This re-lands only the half that is real, and the reason the other half is not here is the substance of this PR. ## Census, per file (measured, `--strict` verified) \| file \| main \| here \| \| --- \| ---: \| ---: \| \| `engine/src/self-healing.ts` \| 107 \| 97 \| \| `engine/src/executor.ts` \| 15 \| 12 \| \| `engine/src/worktree-pool.ts` \| 3 \| 2 \| \| `engine/src/ephemeral-worker-manager.ts` \| 1 \| 0 \| \| `engine/src/agent-tools.ts` \| 5 \| 0 \| \| `engine/src/gridlock-detector.ts` \| 3 \| 0 \| \| `engine/src/triage.ts` \| 4 \| 1 \| \| `engine/src/mission-execution-loop.ts` \| 2 \| 0 \| \| net \| \| −28 \| Baseline re-recorded; `--strict` tightened exactly these 4 entries and no others. ## Finding: a whole class of conversions in this program is INERT, and the census scores it as progress `resolveTaskWorkflowIrSync` returns the default workflow IR for every task in production. The sync selection reader behind it is a PostgreSQL-cutover stub: ```ts // packages/core/src/task-store/workflow-definitions.ts:505 export function getTaskWorkflowSelectionImpl(_store, _taskId) { return undefined; // "Backend mode cannot synchronously read PostgreSQL" } ``` So a guard written as `resolveLifecycleColumns(store.resolveTaskWorkflowIrSync(id))?.hold` resolves an IR, asks for a trait, and answers from the default workflow for every custom board — silently. It reads as converted and the census counts it as converted. `main` gained `sync-workflow-ir-callsite-allowlist.test.ts` for exactly this after my branch point; it is what caught me. I had built three sync resolvers on that reader — `resolveMoveLanesSync` (self-healing, executor) and a widened `resolveTaskParkedColumnsSync` (scheduler) — reasoning that a synchronous `task:moved` listener needs a synchronous reader. That reasoning was sound about the shape and never checked whether the reader reads anything. Dropped from this PR, deliberately, and NOT re-landed anywhere: - `scheduler.ts` 12 → 1 (the widening; the pre-existing narrow helper on main is untouched) - the executor `task:moved` handler, incl. the Move-Task hard-cancel lane comparison - self-healing's `task:moved` fan-out, `classifyPausedAbortWorkflowRecovery`, `reconcileInReviewBranchRebind`, `recoverWedgedActiveMerge`, `recoverPausedAbortFailures`, and 12 single-row lane conversions Those sites are back to their literals. The allow-list's own guidance is the standard I applied: > An unconverted `=== "todo"` is strictly better, because it is at least honest about being a literal. I did not add my call sites to the allow-list. Six entries would have turned the gate green in two minutes and buried the defect; the list's contract requires proving the async resolver is genuinely unreachable, and for a fire-and-forget listener it is not — the listener can `void` an async lane resolution the same way `NotificationService` already does. That is the correct fix and it is a behaviour-shaped change, so it is out of scope here. Fleet-wide consequence: any conversion routed through `resolveTaskWorkflowIrSync` is fake progress, and the census cannot see the difference. `pnpm test:gate` can: the allow-list test is the detector. Its passing here (161/161) is this PR's evidence that nothing inert survived the split. ## What IS in this PR — all async-resolved 1. `self-healing.clearStaleBlockedBy` — lanes resolved per REFERENCED task, not per iterated task. A blocker's own workflow decides whether it is still blocking. 2. `executor` dependency satisfaction — resolved per DEPENDENCY via `columnsWithFlag`. Preserves the load-bearing asymmetry that a dependency in review already satisfies a dependent; a bulk sweep flattens that to complete-only and deadlocks the board. 3. `agent-tools` — the agent task tools listed FINISHED cards as active. `fn_task_list` says it lists "tasks that aren't done or archived"; `fn_task_search` offers `includeDone: false`. Both filtered on `task.column !== "done"`, so a renamed complete lane returned finished cards as outstanding work to an agent, which then reasons and acts on them. `includeArchived` was always enforced by the QUERY and survived a rename; `"done"` was only ever a TS predicate, which is why exactly that half broke. Plus the two dedup guards in the same file. The cross-parent diagnostic filter kept a shipped card as a candidate on a renamed board, so the guard adopted it as canonical and returned `wasDuplicate: true` — absorbing new diagnostic work into a task nobody is working on (the eval-followup defect shape again). The defined-feature bootstrap preflight is not the query-filter class: its query passes `includeArchived: true`, so the TS predicate is the only archived guard there; on a renamed archive lane the archived sibling became the bootstrap canonical and `claimDefinedFeatureTask` then rejects the non-live row, so a valid first task fails to be created at all. Both dedup invariants already had tests — asserted against the legacy ids only, so both passed for the very comparison being replaced. Extended in place into vocabulary differentials rather than added as parallel files. Two helpers rather than one parameterised one: "is this finished?" and "is this archived?" are different questions, and merging them would make the archived-only guard also reject completed rows. The list/search half re-landed with the test it originally shipped without. No suite exercised either tool, so the original commit's "304/304 green" said nothing about the change — the optional-flags failure mode exactly. Both call sites are covered; converting two copies and testing one is the Surface Enumeration failure this program has already hit twice. 4. `gridlock-detector` — FALSE dependency alarms. The gate compared each blocker against `done`/`in-review`/`archived`; on a renamed board all three are true for a finished blocker, so no dependency ever counted as met and the detector reported dependency gridlock for tasks that are not blocked — `notifyGridlock` then pages the operator. Resolved per dependency using the same five flags as the executor's gate (`complete`, `archived`, `mergeOrchestration`, `mergeBlocker`, `humanReview`) — `review` is not a trait, and two gates answering "is this dependency satisfied?" differently is a split brain. Every pre-existing case in that file omits a workflow, so none could detect the change; added the renamed case plus a non-vacuous companion. 5. `triage` — its OWN copies of the same two tools. `createTriageTools` carries a `fn_task_list` and `fn_task_search` byte-identical in intent to the agent-tools pair, plus a third site filtering duplicate candidates. Same defect on all three. Reused the (now exported) agent-tools helper rather than adding a third copy — deliberately stronger than the two-parallel-tests reading of Surface Enumeration, since the copies now share one implementation and cannot drift. Not claiming call-site coverage: `createTriageTools` is private and not drivable without standing up a TriageAgent; the helper is revert-proofed, those two call sites are covered only through it. 6. `mission-execution-loop` — a finished fix task read as LIVE, stalling remediation. The comment above that line states the rule it implements: only an open task makes duplicate triage safe to suppress. On a renamed board the rule inverts — a finished fix task is not `done`/`archived`, so it reads as live, remediation for a fresh validation failure is suppressed indefinitely, and the mission stalls with no error surfaced. Not revert-proven, and I am not claiming it is. No test reaches the `hasLiveFixTask` branch, and the only case that mints a fix feature is git-gated and heavyweight; building that fixture is larger than the conversion. The change strictly widens the finished set (resolved roles ∪ the two legacy ids), so default boards are byte-identical — that is the argument for shipping it unproven, not a substitute for coverage. 7. Four census-invisible membership guards, each inverted on a renamed board — `worktree-pool` (merger-managed branch reclaim could delete a branch out from under an in-flight merge), `agent-assignment` (assignment load counted nothing), `ephemeral-worker-manager` (`isAgentIdle` inverted on both sides), and the dead constants their conversion orphaned. These are `SET.has(task.column)` shapes the census does not count, so the −15 understates them. ## Revert results (measured, each run) \| conversion \| reverted → \| \| --- \| --- \| \| `clearStaleBlockedBy` per-referenced lanes \| renamed-vocabulary case fails; stale `blockedBy` never clears \| \| executor dependency satisfaction \| dependent never unblocks on a renamed review lane \| \| `worktree-pool` merger-managed set \| reclaim proceeds against an in-flight merge \| \| `ephemeral-worker-manager.isAgentIdle` \| idle agent reads busy on a renamed board \| \| `fn_task_list` terminal filter \| RENAMED case fails — shipped card listed as active \| \| `fn_task_search` terminal filter \| RENAMED case fails — same, independently \| \| cross-parent diagnostic dedup \| RENAMED case fails — `wasDuplicate: true`, new work absorbed \| \| bootstrap preflight archived guard \| RENAMED case fails — `validate` called with the archived sibling \| \| gridlock dependency gate \| RENAMED case fails — false gridlock raised for an unblocked task \| `agent-assignment`'s widened `taskStore` type is compile-time; its revert is a tsc failure, not a test failure — stated rather than claimed as coverage. ## Verification - `pnpm test:gate` — 161 + 487 + 13 + 71, all green (161 includes `sync-workflow-ir-callsite-allowlist`) - `npx tsc -p packages/engine/tsconfig.json --noEmit` — clean - `pnpm lint` — clean One commit is a pure import restore: `columnsWithFlag` arrived in a sibling commit that built on the inert resolver and was left behind. The engine tsconfig excludes `src/__tests__/`, so the gate was green while tsc was not — worth knowing that on this package a green gate is not a green build. ## Verified NOT a gap — measured, so the next worker does not re-open them - `restart-recovery-coordinator` (5 counted). Four already take an optional `reviewColumns` set and the counted literals are the documented fallback arm, which must stay for the same reason `columnRoles.ts` keeps its id fallback. The sole production caller (`self-healing.ts:12151-12154`) already passes the resolved set. The fifth is documented at the site as a re-assertion behind a `listTasks({ column: "in-progress" })` query filter. Nothing to convert. - `notification/notification-service` (5 counted). Already documented in-file as deliberately counted with no exemption marker: the wedge-episode site needs per-task serialisation of wedge handling (a delivery-semantics change to operator notifications), and `isManualMergeHold` needs a pre-resolved `LifecycleColumns` threaded through `handleTaskUpdated`, which would pay resolution on every task update. Both are behaviour/placement judgements, not conversions. - `planner-overseer` (3 counted). `resolveWatchedStage`'s two literals are fed by `pollPlannerOverseer`, which calls `listTasks({ column: "in-progress" })` and `{ column: "in-review" }` — hardcoded query filters. On a renamed board those queries return no rows, so the predicate never sees a renamed column. Converting it alone would drop 3 from the census and change nothing an operator can observe. The real fix is at the query layer; that is the tracked query-filter-bounded class, not this PR. - `triage:695` reads `resolvePlannerLanes` → the allow-listed sync IR reader. Left as an honest literal per the rule above. Still open in `packages/engine`, deliberately not in this PR:** `self-healing.ts` (97, of which ~31 are the query-filter-bounded class and the rest need per-site classification in a 13k-line file), `scheduler.ts` (12, blocked on the sync reader above), `executor.ts` (12), and a tail of ~13 more copies of the "is this task finished?" question across eight small files (`agent-reflection`, `auto-merge-finalization`, `merger-scope-auto-widen`, `backlog-pressure-reporter`, `merger-orphan-rehome`, `merger-integration-worktree`, `plugin-runner`, `cli-agent/*`). That tail is a clean follow-up: one question, eight call sites, and the exported `resolveTerminalColumnsForTasks` helper already exists for it. That is the same discipline as the sync-resolver finding: a census number that drops without a behaviour change is not progress, and four of these files would have handed over exactly that. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 10:47:44 -07:00
gsxdsm	4184fde08d	batch-cli-plugins: 7 guards — 3 were a foreign enum, and `fn pr create` refused every card on a renamed board (#2775 ) `batch-cli-plugins` — the u7 worker's mega-batch: `packages/cli` + `plugins` + anything left. ## The batch is 7 guards, and 3 of them are not guards at all The census's per-file list gives this batch seven sites. Reading them, three are a foreign vocabulary the census matches on the string alone: \| file \| site \| verdict \| \|---\|---\|---\| \| `plugins/fusion-plugin-reports/store/report-store.ts` \| `next === "archived"` ×2 \| not a column — `next` is a `ReportStatus` \| \| `plugins/fusion-plugin-reports/store/report-types.ts` \| `to === "failed" \\|\\| to === "archived"` \| not a column — same enum, its own terminal states \| The reports plugin has its own status lineage (`draft → generating → review_* → approved → published`, plus `failed`/`archived`) that shares two spellings with the lifecycle vocabulary. A report is not on a board and has no workflow, so resolving an IR there would answer a question nobody asked. All three are marked `DELIBERATE-LITERAL` with the reason at the site. This cuts the other way from #2763. That PR establishes the census total as a floor (25 membership predicates it structurally cannot see). This is the opposite error in the same number: a foreign enum inflating it. The total is neither a ceiling nor a floor — it is an estimate with error in both directions, and the per-file list is worth reading before trusting a file's count. ## Converted (census before → after, per file) \| file \| before \| after \| \|---\|---\|---\| \| `packages/cli/src/commands/pr.ts` \| 1 \| 0 \| \| `plugins/…/even-realities-glasses/notifications/diff.ts` \| 1 \| 0 \| \| `plugins/…/reports/store/report-store.ts` \| 2 \| 0 (deliberate) \| \| `plugins/…/reports/store/report-types.ts` \| 1 \| 0 (deliberate) \| ### `fn pr create` refused every card on a renamed board The live defect in this batch. The gate was `task.column !== "in-review"`, and its error told the operator to move the task to a column their board does not have: ``` Error: Task must be in 'in-review' column to create a PR (current: signoff) ``` There is no way to satisfy that short of renaming the workflow back. Now resolved through core's `resolveReviewColumns`, and the message names the lanes that actually exist. The SET, not `lifecycle.review`. A board may declare more than one review lane, and a card parked in a `humanReview`-only lane is still a card you can open a PR from. A single-id answer keeps refusing those — the same narrowing #2728's review caught in the CLI retry gate, which is why the test pins both lanes. ## Skipped, with the reason `plugins/fusion-plugin-even-cards` (2 guards) — blocked on packaging, not on analysis. The defect is real: `boardToDeck` filters with `column !== "archived" && column !== "done"`, so on a renamed board every finished card stays in the deck, fills `maxCards`, and pushes the active cards off the display. The wearer sees a board that never finishes anything. I implemented the fix and reverted it: this plugin is not in `pnpm-workspace.yaml` and depends only on `@fusion/plugin-sdk` — it has no `@fusion/core` dependency, so the route cannot reach `resolveTaskLifecycleColumns`. Adding one is a packaging change, which this program's rules put out of scope. Shipping only the injected parameter without a caller was the alternative, and that is precisely the decorative conversion #2759 documents: the census would drop by 2 and the deck would keep the bug. Flagged for whoever owns the plugin's dependency surface. The glasses plugin next door does depend on `@fusion/core`, so this is a one-plugin problem, not a plugin-wide one. ## Honest note on the glasses conversion `diff.ts`'s completion branch is currently unreachable — the only production caller (`notifier.ts`) passes `alsoNotifyOnDone: false`. So that conversion changes nothing at runtime today. It is converted rather than marked deliberate because the literal is not deliberate: it is wrong, and would ship the bug the day someone turns the flag on. Stated here rather than left for a reviewer to discover. ## Verification - new CLI suite 4 passed; `pr-command` + `pr-automerge-cleanup` + `bin-pr-router` 35 passed - glasses plugin 181 passed (19 files) · reports plugin 110 passed (23 files) - `pnpm test:gate` — 158 / 10 / 487 / 71 · `pnpm lint` clean · `--strict` exits 0 Revert proof, measured. Restoring `if (task.column !== "in-review")` fails 3 of the 4 new cases (`process.exit:1` on both renamed lanes, and the refusal message reverts to naming `in-review`). The unresolvable-workflow case keeps passing — it is the legacy path — so the negative cases alone do not pin the fix and all four are required. ## Handoff to `batch-engine` `packages/engine/src/project-engine.ts` 5 → 0 is finished, green, and pushed as `handoff/project-engine-lanes-for-batch-engine` (`34dbb35209`) for the capacity worker to cherry-pick — it is engine-owned, not mine to land. It fixes two live defects: a card that had merged reported as a failed merge to `fn task merge` and the dashboard button (`merged: finalTask?.column === "done"`), and the three post-finalize `column === "done" && mergeConfirmed` fast-path checks, which on a renamed board sent an already-landed card down the bounce path — re-queued, retry-counted, and in the capped branch parked `failed` with its merge sitting on main. Plus `hasAutoHealableVerificationBufferFailure`, which returned false for every card on a renamed board, so a buffer-overflow verification failure was never auto-healed. 8 new tests, revert-proven (restoring the literal fails 4 of 8), gate green. --- ## Completion pass (u7) — the batch is now closed Two workers converged on this branch. I rebased onto the first-landed commit rather than force-pushing over it, took its wording wherever the conclusion was identical, and added what was missing. ### What this pass added 1. `even-cards` (2 sites) — the only in-scope file the first pass left open. Marked DELIBERATE-LITERAL: the package depends on `@fusion/plugin-sdk` only, and the SDK does not re-export the lifecycle role helpers, so there is no IR, no store, and no trait flags to resolve from. Fixing it properly means the SDK exposing role flags on the task shape it hands plugins — a structural change, out of scope, and recorded at the site as the correct home. Live consequence is cosmetic: a finished card on a renamed board shows as active in the glasses deck. 2. A red test in the `fn pr create` conversion. The incoming version rendered `Task must be in 'in-review' to create a PR`, dropping the word `column`. `task.test.ts:3422` pins `must be in 'in-review' column`, so that hunk failed `runTaskPrCreate > exits with error when task not in in-review column`. Restoring the word makes the single-lane message byte-identical to the pre-conversion one, which is what a vocabulary conversion should be — the guard's own test now passes unmodified. Marked at the site so it is not "simplified" back. 3. Duplicate imports — the two independent conversions each added `resolveWorkflowIrForTask`/`resolveReviewColumns`, which does not compile. Deduped in its own commit. ### Census Measured with `--json` on `origin/main` and on this branch. \| file \| before \| after \| action \| \|---\|---\|---\|---\| \| `packages/cli/src/commands/pr.ts` \| 1 \| 0 \| converted \| \| `plugins/fusion-plugin-reports/src/store/report-types.ts` \| 1 \| 0 \| marked \| \| `plugins/fusion-plugin-reports/src/store/report-store.ts` \| 2 \| 0 \| marked \| \| `plugins/fusion-plugin-even-cards/src/cards/board-cards.ts` \| 2 \| 0 \| marked \| \| `plugins/fusion-plugin-even-realities-glasses/.../diff.ts` \| 1 \| 0 \| marked \| Backlog 415 → 408 (−7, exactly the in-scope count). Deliberate 40 → 46 (+6 marked); 6 + 1 converted = 7. `--strict` exits 0. Nothing remains in `cli` + `plugins` + everything-else — there is no follow-up batch behind this one. ### One note on the `even-realities-glasses` site Worth recording beyond "cannot resolve": its only production caller (`notifier.ts:80`) passes `alsoNotifyOnDone: false`, so that arm is unreachable today. Converting it could not have changed observed behaviour either way. ### Verification (measured, on the merged branch) - `pnpm --filter @runfusion/fusion exec tsc --noEmit` → exit 0 - `pnpm lint` → 0 errors - CLI `task.test.ts` → 144 passed, including the `runTaskPrCreate` guard test - `@fusion-plugin-examples/reports` → 110 passed; `even-realities-glasses` → 181 passed Pre-existing failures, not from this change: the 5 `runTaskImportFromGitHub` / `runTaskImportGitHubInteractive` tests fail identically on `origin/main` — verified by stashing this diff and re-running (5 failed / 144 passed both ways). --- ## Census audit (unowned follow-on) After closing the batch scope I audited whether the 392 column-backlog number is inflated by foreign vocabularies — the class this batch found in the reports plugin, where `"archived"` is a `ReportStatus` rather than a board lane. If that class were widespread, every remaining batch would be chasing sites that must not be converted. It is not. The number is real. A receiver-level pass over all 392 column-category sites found exactly 3 false positives, all in `plugins/fusion-plugin-reports` (`next`, a `ReportStatus`), all now marked in this PR. What was checked and cleared: - Property-reached foreign enums (`step.status`, `feature.status`, `mission.status`) — already correctly bucketed into the separate `status` category (185), not the column backlog. Verified against `merge-queue-ops.ts`: 11 lifecycle-spelled literals in the file, census counts 1, and that 1 is the genuine `.column` guard. - Bare step-status variables (`status`, `currentStatus`, `liveStatus` compared to `"done"`/`"skipped"`) — likewise excluded. - Every other receiver in the backlog — `to`, `from`, `column`, `fromColumn`, `toColumn`, `latestColumn`, `state`, `preArchiveColumn`. All resolve to genuine task columns. `executor.ts`'s 15 sites were spot-checked line by line: all 15 are real. The gap the classifier genuinely cannot close is a foreign enum held in a bare variable — the receiver name carries no type information, so `next === "archived"` is indistinguishable from a lifecycle guard by AST alone. That is why the reports sites need a marker rather than a classifier fix, and it is now documented in `lifecycle-column-census-ast.mjs`'s header alongside the measured scope, so the remaining batches do not re-run this hunt. Census tests: 43 passed. The change is comment-only. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 10:38:39 -07:00
gsxdsm	8c9b84ae38	batch-core: packages/core + dashboard/src lifecycle conversion (129 → 92) (#2780 ) ## batch-core — `packages/core` + `packages/dashboard/src` Shared branch: two workers are converting into it. Opening the PR because the branch was green with none, and a branch without a PR merges nothing. ### Census Measured with `node scripts/lifecycle-column-census.mjs --json`. \| \| guards \| \|---\|---\| \| batch-core scope at branch point \| 129 \| \| batch-core scope now \| 92 (51 files) \| \| repo total now \| 358 \| Files closed so far: `store.ts` 11→0, `task-merge.ts` 6→0, `live-agent-count.ts` 6→0 (marked, not converted — see #2762), `task-update.ts` 3→0, display-ordering + Wake Delta ranking 5→0, `register-git-github.ts` 4→0. ### The `register-git-github.ts` slice Three PR routes — `pr/create`, `pr/push-branch`, `pr/resolve-conflicts` — plus the `CHANGES_REQUESTED` handler each compared `task.column !== "in-review"`. On a renamed board none of them matched, so every PR affordance the dashboard offers was refused for a card sitting in the lane that board calls review, and the refusal named a column that does not exist there. All four now share one helper, `reviewColumnsForTask`, which gets two things right that this program has repeatedly gotten wrong: - Membership, not a single id. It takes the broad review set (`mergeOrchestration ∪ mergeBlocker ∪ humanReview`). `resolveLifecycleColumns` returns the first column per trait, so a single-id answer silently ignores a board that declares a merge lane and a separate human sign-off lane. These guards only refuse or permit — they never move the card — so over-admitting costs nothing while under-admitting refuses a request that should have worked. - An empty resolved set means UNEXPRESSED, not absent. `synthesizeDefaultColumns` upgrades a v1 graph by emitting every default column with `traits: []`, so a v1-upgraded workflow resolves to an empty review set while its `in-review` column plainly exists and holds the card. Reading empty as "this board has no review lane" would refuse these routes on every pre-v2 project — a worse regression than the one being fixed, and invisible to any v2 test. This is the dashboard twin of the `fn pr create` guard in `packages/cli/src/commands/pr.ts` (#2775). The two surfaces answer the same question and now agree — FN-5893 surface enumeration. ### Testing note: why the seam and not the routes I wrote route-level HTTP tests first and deleted them. An express fixture over `registerGitGitHubRoutes` hangs — every case, including the pure refusals, times out at 4s, because registering the router starts background work the fixture never satisfies. Making it run would mean mocking git, the GitHub client, and the pollers: a mock-the-world shell, which is what the project's do-not-add-slow-tests rule (FN-5048) says to avoid in favour of a narrow seam. `reviewColumnsForTask` is the narrow seam — it holds the entire decision, and the four call sites now do nothing but ask it and render its answer. Six cases pin it: the renamed lane is returned and `in-review` is not, a two-lane board returns both, a v1-upgraded board falls back, an unresolvable workflow falls back, and the refusal renders lanes an operator can act on. Mutation-verified, both directions: reverting the helper to the legacy literal fails 2 of 6; treating an empty set as an answer fails 1 of 6. One fixture bug worth recording, since it would have made the two-lane case vacuous: the trait id is kebab-case `human-review`, not `humanReview`, and the built-in traits must be registered via `import "@fusion/core"` before flags resolve. ### Verification - `pnpm --filter @fusion/dashboard exec tsc --noEmit -p tsconfig.json` → 0 errors - `pnpm lint` → 0 errors - `register-git-github.review-lanes.test.ts` → 6 passed --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 09:28:27 -07:00
gsxdsm	3092c9c2bb	fleet: live-agent-count.ts 6 → 0 — the no-enrichment fallback, marked not converted (#2762 ) Unclaimed file, no overlap with any open fleet PR. Previous PR (#2756) is merged, so this is my one open PR. ## Census \| \| before \| after \| \|---\|---\|---\| \| backlog \| 447 \| 441 \| \| reviewed \| 38 \| 44 \| \| this file \| 6 \| 0 \| `--strict` exit 0, baseline re-recorded in the same commit. ## Why marked, not converted All six literals sit after a `??` or a `flags ? … :`. Each is reached only when the caller supplied no trait flags and no enriched shape — precisely the case `enrichRunningAgentTaskShape` (takes the IR) and `enrichRunningAgentTaskShapeFromFlags` (takes board flags) exist to remove. There is nothing to resolve from there, so the choice is not convert-vs-literal; it is known legacy answer vs a different guess. And the guess is not neutral. Running and Waiting are complements over the same rows: ```ts isWaitingAgentTask = !running && (columnIsIntakeOrHold ?? isLegacyPreImplementationColumn(column)) ``` A card matching neither arm is reported as neither running nor waiting, so the footer's queued total silently under-reports it. Guessing "not WIP" or "not review" loses cards from the count; the legacy id at least matches every pre-rename board. That is why this file already carries a `DELIBERATE-LITERAL` marker above `isLegacyPreImplementationColumn` with the same argument — this PR extends it to the three functions holding the remaining fallbacks (`enrichRunningAgentTaskShapeFromFlags`, `terminalKind`, `isRunningAgentTask`). The fix for a renamed board is at the CALLER — pass flags, or use the IR-taking enricher. Noted at the site. ## Pattern note for the fleet This is the third file I have taken where `N → 0` is reached by marking rather than converting, and they share a shape worth naming: a literal after `??` or in the `else` of a `flags ?` ternary is a degraded-mode answer, not an unconverted guard. The trait path is already there and already correct; the literal is what runs when the trait path has no input. Deleting it does not remove a decision — it substitutes a different one, silently, in exactly the states where nobody is looking (first paint, un-enriched callers, pre-rename data). ## Verification Core typecheck clean · `live-agent-count.test.ts` 11/11 · `--strict` exit 0 · comments only, no behavior change. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:57:52 -07:00
gsxdsm	9b61d795c9	fix(engine): heartbeat asked 'is this task finished?' with legacy ids — and one of the two sites writes status:failed onto completed work (#2769 ) ## Two heartbeat sites asked "is this task finished?" with the legacy ids `agent-heartbeat.ts` 4 → 0. Neither site is cosmetic. Linked-task clear. The heartbeat clears an agent's assignment once its card is finished. Keyed on the literals, an agent on a renamed board stayed bound to a completed card indefinitely — every later heartbeat ran with stale task context instead of picking up new work, and nothing else clears it. Worktree-acquisition gate. Its failure bookkeeping runs only for a non-terminal task. A card in a renamed complete lane read as non-terminal, so an acquisition failure could stamp `status: "failed"` and an error message onto work that was already done. That second site writes, which drives the fallback direction: an unresolvable workflow degrades toward "terminal", because treating a finished card as unfinished is the expensive mistake here. Both sit in async paths — the first has `await taskStore.getTask(...)` three lines above — so this is an `await`, not a restructure. Extracted to one predicate rather than converted twice: they are the same question, and the two must not drift when one of them acts destructively. ## How this was found, and the part worth recording Generalising #2767. That PR marked a documented false positive the census kept advertising, so I swept for other files whose lifecycle literals were reasoned about in prose but still counted — to find out whether the trap was systemic. It is not. Of twelve candidate files, only this one carried real unconverted guards, and its "false positive" mentions turned out to be unrelated (detection heuristics, not column literals). The sweep mostly came back negative, and that is worth saying so nobody repeats it expecting a haul. ## Revert proof \| reverted \| result \| \|---\|---\| \| neuter the resolution (predicate → literals) \| 3 failed / 2 passed \| \| shipped \| 5 passed \| The two that survive the revert are the degraded-mode pair, which is correct — they assert the legacy answer, so they must pass either way. One case also pins that a legacy `done` id is not terminal on a board that does not declare it, which is what a board-wide union would get wrong. ## Verification - 13 heartbeat suites — 501 passed (496 before, +5 new) - `pnpm test:gate` — 158 / 10 / 487 / 71 · `pnpm lint` clean · engine `tsc --noEmit` 0 errors · `--strict` exits 0 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:42:00 -07:00
gsxdsm	7f3eee9db7	docs(engine): mark the usage-limit terminal filters DELIBERATE-LITERAL — a documented false positive that has now baited two workers (#2767 ) ## No behaviour change. This is the work order retracting a documented false positive. I went to convert the `done`/`archived` filters in `usage-limit-detector.ts`, reasoning that on a renamed board a provider rate limit would pause already-finished work. I wrote the conversion — and only then read the note a previous worker had left directly above it: > "The FIRST thing I suspected there — the `done`/`archived` terminal filter — turned out to be a FALSE POSITIVE: its revert stayed green, because the lane check already excludes finished cards." They are right and I was wrong. A terminal card is already excluded downstream: `taskUsesProvider` resolves the task's active lane, a finished card matches no active lane, so it resolves no providers and cannot be affected. The suite pins exactly this — `pauses a PEER executing in the renamed WIP column` asserts `FN-SHIPPED` is not paused. My conversion is reverted. It changed nothing at runtime and would have lowered the census count while behaviour stayed identical — the precise shape this program keeps warning about, produced by me this time. ## Why a marker and not just the existing prose The note was already there and I walked into it anyway, because the census kept listing this file as 4 unconverted guards. The work order advertised the work; the reasoning against it lived in a comment you only reach after you have started. Prose informs a reader who is already looking; a marker informs the instrument, so the file drops out of the work order. Two distinct reasons are recorded rather than one blanket marker, because they are not the same argument: - the prefilter is a deliberate cheap superset (#2672 review). Converting it reintroduces the whole-board resolution that review removed. Literals are safe here in the direction that matters — a renamed board declares no `done`/`archived` id, so nothing is wrongly excluded. - the final filter is redundant with the lane check, and that redundancy is already proven by an existing test. ## Census \| \| before \| after \| \|---\|---\|---\| \| `usage-limit-detector.ts` \| 4 \| 0 \| \| repo backlog \| 437 \| 433 \| \| DELIBERATE-LITERAL (reviewed) \| 38 \| 42 \| Every one of the 4 is a marker, not a conversion. The backlog moved because reviewed literals left it honestly, not because behaviour changed. ## Verification `usage-limit-detector.test.ts` 58 passed, unchanged before and after · `pnpm test:gate` 10 / 158 / 487 / 71 · `pnpm lint` clean · engine `tsc --noEmit` 0 errors · `--strict` exits 0. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:31:47 -07:00
gsxdsm	d86c1f9d29	batch-engine: packages/engine lifecycle-column conversions (capacity worker's mega-batch) (#2773 ) The engine mega-batch. Folds my four engine PRs and will absorb the remaining `packages/engine` guards as commits on this branch. Superseded and closed: #2722, #2741, #2766, #2770. ## Census — files converted so far \| file \| before \| after \| \|---\|---:\|---:\| \| `notification/notification-service.ts` \| 9 \| 5 \| \| `runtimes/in-process-runtime.ts` \| 6 \| 1 \| \| `eval-followups.ts` \| 2 \| 0 \| \| `pr-comment-handler.ts` \| 1 \| 0 \| \| `task-revert.ts` \| 2 \| 0 \| The last two are census-invisible (`Set.has(task.column)` membership) — the class measured in #2763, which a comparison-based scan cannot count. So the backlog number moves less than the work does, deliberately. ## What each one actually fixed — all silent, none cosmetic - Notifications stopped entirely. `handleTaskMovedAsync` compared `data.to` to `in-review`/`done`, so on a renamed board the two notifications operators rely on most were never sent. - A finished card's plan review could re-enter. The continuation drain's terminal test matched nothing, so a completed card's planning continuation was handed to the executor. - The revert route admitted and the service refused. The route resolved terminal lanes; the service compared to a hardcoded pair. The operator got a dead end from an affordance the UI and route both offered. - Follow-up dedup blocked new cards forever. A finished follow-up in a renamed complete lane read as open, so the dedup matched it permanently — defeating the intent the code documents in the line above it. - The mission requeue wrote a column that may not exist, and its guard never matched. ## Flagged, not fixed — deliberately - `concurrency.ts` idle semaphore leak recovery — the last live caller of the running-agent predicate that does not enrich. On a renamed board it under-counts and can reclaim a legitimately-held slot. The enriching variant is async and this is a synchronous repair path whose failure mode is reclaiming live work. - The archival `task:moved` listener — runs on every move with no cheap gate ahead of it; converting costs an IR resolution per move to decide most moves are not archival. ## Notes carried from the folded PRs Two conflicts resolved in main's favour because main's version was better: `in-process-runtime`'s seam uses `terminalColumns: ReadonlySet` (membership) where mine used `LifecycleColumns` (first-per-role), and the test is rewritten against main's API. That arity trap has now caught me four times, so membership is the default shape in everything new here. Review fixes from the folded PRs are included: the notifier's review set, the second human-review site, the second dedup copy, the workspace revert surface, and the file-content assertions. ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 224 passed across the touched engine suites · engine and dashboard `tsc` clean · `pnpm lint` clean · census `--strict` exits 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:24:50 -07:00
gsxdsm	86a2b48968	fleet: branch-group-ops 6 → 0 — an agent asking for its next task was told there was none (#2739 ) Second application of the sync-filter pattern decided in #2737. `branch-group-ops.ts` 6 → 0. ## The failure `selectNextTaskForAgentImpl` picks an agent's next task by filtering the board for its WIP lane, then its hold lane — both `task.column === "<literal>"`. On a renamed board both filters match nothing, so an agent asking for work is told there is none, with its own assigned tasks sitting in the list it just fetched. No error, no log line. The agent idles. `pauseTaskImpl` had the same shape: pausing a running card on a renamed board left its `status` untouched, so the UI kept showing it as working. ## Consumer, not a gate — checked rather than assumed Applying the #2724 test to this file, since it sits closer to the persistence layer than the reconciler did: its only SQL predicate is `eq(table.projectId, ...)`. Nothing here compares a column to a literal in SQL, so there is no second encoding of these questions to diverge from. The list arrives from `store.listTasks` and the filters select among rows already in hand. Async predicates were the alternative and would have turned these filter chains into sequential awaits inside the dispatch path. One prefetch, one IR read per distinct workflow, filters stay synchronous. `pauseTaskImpl` resolves for the single task it holds rather than joining a map — different entry point, one id in scope, and a map would have exactly one entry. ## Revert proof \| reverted \| result \| \|---\|---\| \| the wip literal \| renamed WIP case fails: `expected null to be truthy` \| \| the hold literal \| renamed hold case fails identically \| The new test calls the impl directly with a store fake resolving a renamed IR. The existing `selectNextTaskForAgent` coverage drives a real store harness, so exercising a renamed vocabulary there means registering a real custom workflow and moving cards through it — heavier than the question, which is only which lane the filters name. The bind evaluator runs for real; only the store is faked. A third case pins that the hold filter keeps its `userPaused` exclusion, so a filter matching every column would not satisfy the other two. Related coverage checked before writing a new file: `agent-heartbeat-worktree-renamed-hold.test.ts` covers the requeue target on a renamed board, not the dispatcher's selection filters — different branch of the same subsystem, so a case added there would have read as duplicate coverage of the wrong thing. ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 20 passed across the routing-policy and new dispatch suites · core `tsc` clean · `pnpm lint` clean · census `--strict` exits 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - Bug Fixes - Improved agent task selection when workflow lane names or IDs have been renamed. - Agents now correctly resume assigned in-progress or queued tasks across customized workflows. - Prevented agents from selecting tasks paused by users, including on boards with renamed lanes. - Updated task pausing behavior to correctly reflect lifecycle stages beyond default lane names. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:09:36 -07:00
gsxdsm	76d77da4d1	fleet: taskSorting + TaskReviewTab 8 → 0 — and Board was faking a column id to force done-sorting (#2744 ) Two app-side clusters, 8 → 0, plus a caller-side hack retired. ## What was broken `TaskReviewTab.tsx` — three of its four questions were `task.column === "in-review"`, driving the Create-PR button, the "frozen on entry to review" auto-merge hint, and PR-feedback addressing. On a renamed review lane all three took their non-review branch: the button was absent, and the hint claimed the effective auto-merge value was not frozen when it was. `taskSorting.ts` — `isReviewColumn` decides whether merging cards float to the top of a lane. Keyed on the id it silently stopped doing that on any renamed review lane, so the operator loses the "what is merging right now" ordering with nothing failing. Both follow the shape this code already established: caller supplies the trait, default to the legacy id. `columnFlags` on the review tab is optional and wired from `TaskDetailModal`, which already resolved it for `canEdit` and the actions menu. ## A synthetic column id, retired `Board.tsx` forced done-sorting by passing the literal `"done"` as the column argument for any complete-flagged lane: ```ts grouped[column.id] = isWorkflowDoneLikeColumn ? sortTasksForDisplayColumn(grouped[column.id] ?? [], "done", doneSortMode) : sortTasksForDisplayColumn(grouped[column.id] ?? [], column.id as ColumnType, ...); ``` A synthetic id standing in for a trait — so a custom complete lane sorted correctly only because its caller lied about its name. Both call sites now pass the real column id and state the trait. (Board's own census count stays at 2: those two literals were the synthetic ids and are gone; the 2 remaining are different sites.) ## Revert proof \| reverted \| failure \| \|---\|---\| \| `task.column === "in-review"` on the Create-PR guard \| `Unable to find an element by: [data-testid="task-review-create-pr"]` \| \| same, on the auto-merge hint \| `expected 'Effective: Auto-merge off' to contain 'frozen on entry to review'` \| A third case pins that the widened test does not treat every column as review. None of the 45 existing `TaskReviewTab` cases could have caught this — `columnFlags` is optional and they all omit it, so they assert the legacy fallback. That is the same blind spot as the reconciler's 33 in #2737, and it keeps recurring: an optional-flags seam means the existing suite stays green through the conversion and through a broken one. ## A process failure worth recording I lost this conversion once and had to redo it. I overwrote four files with their `origin/main` versions to check whether a failing test was pre-existing, then "restored" with `git checkout HEAD -- <dir>`. HEAD was still `origin/main` because I had not committed, so that discarded the work. Same class as the shared-stash incident two PRs back: an implicit or positional restore reference. The fix is ordering, not care — commit before any baseline comparison, so `git checkout HEAD -- <file>` restores my work rather than main's. This PR's commit was created before the comparison for exactly that reason, and the note is in the commit message so the next person hits it there too. ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 232 passed across TaskReviewTab / taskSorting / Board suites · dashboard `tsc -p tsconfig.app.json` clean · `pnpm lint` clean · census `--strict` exits 0. The 1 `board-mobile` failure is pre-existing — verified by swapping in clean `origin/main` copies of all four files and reproducing it. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:06:04 -07:00
gsxdsm	54d1a29621	fix(dashboard): the github-tracking-state classifier seam was never wired — a renamed terminal column still never closed its issue (#2754 ) Not a conversion. A conversion that was never connected to production, found by a parity sweep rather than by the census. ## How it surfaced An AST pass over all 43 github/gitlab-named files, paired by name with counts compared: ``` github-tracking-comments.ts=9 vs gitlab-tracking-comments.ts=4 ASYMMETRIC github-tracking-state.ts=2 vs gitlab-tracking-state.ts=0 ASYMMETRIC github-issue-comment.ts=1 vs gitlab-issue-comment.ts=1 ...8 more pairs, all symmetric at 0 ``` The first is the pair #2715 fixes. The second pointed here — and the asymmetry turned out not to be the interesting part. ## The defect `decideIssueAction` has accepted an injectable `classify` since U12/R2, and that file's own header states the bug the seam fixed: > "A user-authored workflow whose terminal column is called something else never closed its linked GitHub issue, and a custom archive column never mapped to `not_planned`." Its only production caller passed no classifier: ```ts const decision = decideIssueAction(event.from, event.to); ``` So every real move fell through to `legacyColumnLifecycleClass`, and the documented bug was still live. The seam was reachable from unit tests only — which is why all 68 cases in that file were green while the behaviour they document did not work. Same shape as this branch's earlier finding on the tracking-comment guard, where the guard returned before resolving. Adding a seam and wiring it are two changes; only the second one fixes anything. Worth watching for elsewhere in this program: a file can read as fully converted, pass its suite, and still take the legacy path on every call. ## Ordering, inverted on purpose `decideIssueAction` ran first, before the tracking-enabled check, because comparing two strings is free. Resolving a workflow is not — so the cheap property read now short-circuits and only tracked tasks resolve, the ordering `github-tracking-comments.ts` and its GitLab twin already settled on. Untracked tasks returned without acting before and still do. The two remaining literals are `legacyColumnLifecycleClass`, that seam's named default, now marked `DELIBERATE-LITERAL` — and marked only in the same commit as the wiring. While the default was the live path on every move, exempting it would have hidden the real defect behind a marker. ## Revert proof — it detects an unwired seam, not a missing one Dropping the resolved classifier while leaving the seam intact fails both new cases with 0 `setIssueState` calls. That is the whole point: the new cases drive the service, not the pure decision function, so they fail for exactly the reason the 68 existing cases could not. Those pass either way. ## Two self-inflicted errors, recorded because both are recurrences - I hand-edited the baseline with python and wrote a raw NUL byte into the JSON, breaking the census parse. The `deliberateByFile` keys use a real `\0` separator and must be written through `JSON.stringify`, never string interpolation. - I then restored the baseline from a newer `origin/main` than my branch point, which made `--strict` report a `scheduler.ts: 12 → 26` rise that was pure version mixing. Rebase first, then edit. (The real `scheduler.ts` baseline staleness is already owned by #2712 — I checked before assuming it was mine.) ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 71 passed in the tracking-state suite · dashboard `tsc` clean · `pnpm lint` clean · census `--strict` exits 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 08:05:50 -07:00
gsxdsm	86639f2ce4	fleet: planning drain + archive writers 12 → 4 — one stale row starves planning, and a finaliser that wrote an undeclared column (#2742 ) Claimed on #2733 before starting. `in-process-runtime.ts` + `task-artifacts-ops.ts` — 12 → 4. ## 1. The planning drain: one stale row stops planning for the whole project FN-8470's own note on this code says it: one orphan earlier in created_at FIFO prevented every later planning continuation from dispatching. So on a renamed board the literal terminal pair did not mis-handle one card — an archived or completed card's stale work item read as live, stayed in the due set, and starved the drain behind it. The two classifiers take an optional terminal set, which is this file's own injection idiom (the specification-complete reaction already takes a `resolveIr` dependency so the pure passes are testable without constructing a runtime that would attach to the real project registry). Optional is load-bearing: a required parameter would have compiled at every existing caller and then answered "not terminal" for everything. That is the silent direction, and both halves are asserted in the test. ## 2. `moveToDoneImpl` writes `task.column` directly This is the store's own finaliser, not a `moveTask` caller — so its literal is not caught by `moveTask`'s unknown-column validation the way every converted call site in this program is. It silently persisted `done` on a board that does not declare it, and then emitted `to: "done"` to every listener. This is one of the few sites where a literal writes bad state rather than merely failing to act. A workflow declaring no complete lane now throws instead of inventing one — #2733's rule: a missing field on a resolved struct is an answer, and `?? legacy` discards it. ## 3. The unarchive destination — three decisions in four lines, all literal \| pre-archive column \| lands in \| \|---\|---\| \| unusable / archived \| the complete lane \| \| the wip or review lane \| the hold lane (its worktree and session are long gone) \| \| anything else \| back where it was \| The second is the expensive one: a card archived from the wip lane was restored straight back into it with no worktree, and the scheduler then counts it as a live holder occupying a slot. Made async — its one production caller already is, and the sync alternative is the PostgreSQL no-op documented in #2703. ## Also - The mission-error requeue (guard and destination in one change): an errored mission task stayed in the wip lane holding a slot, because the guard never matched. - The planner-chat retention cutoff on archive — the quiet direction of this defect class: nothing breaks, data that should be deleted simply accumulates, and the only symptom is storage growth nobody attributes to a column name. ## The live defect is not where the census points `reliability-metrics.ts`'s 6 guards are pure historical readers over activity-log entries, and the dashboard does not call them. The live path is `server.ts`'s `getTaskMovedCountsByDay({ toColumn: "in-review" })` — a SQL query filter, the class the census counts separately. So the operator's reliability panel reads zero on a renamed board because of a query literal, and converting the six guards the census reports would change nothing an operator sees. Converting historical readers also risks reinterpreting past events under today's traits, which is a different decision from converting a live guard — I am not making it inside a vocabulary sweep. Worth generalising for the fleet: a file's census count and its live exposure are different numbers. This is the second file where the reported guards are the inert copy and the real one is a query (`executor.ts:5805` was the first). ## Verification `pnpm test:gate` 10 / 158 / 487 / 71 · 31/31 continuation suites · 8/8 archive PG suites · in-process-runtime PG suite green · 5 new cases, 2 red on revert · `tsc` clean in core and engine · `pnpm lint` clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 07:53:28 -07:00
gsxdsm	b0b9d1b373	fleet: store.ts 12 → 11 + names the sync-dependency-loop class blocking ~10 sites across 3 clusters (#2709 ) Claiming `packages/core/src/store.ts` (12). One conversion and a triage — because 10 of the 12 share a single blocking shape that is worth naming once rather than rediscovering per file. ## Census before/after \| \| before \| after \| \|---\|---:\|---:\| \| `store.ts` column guards \| 12 \| 11 \| Baseline re-recorded; `--strict` exits 0. ## Converted: 1 1386 — the in-review guard inside `withTaskLock(id, async () => …)`. Already async, and `this` is the store, so `resolveTaskLifecycleColumns(this, task.id)` resolves the review role with `in-review` as the fallback. Import added; nothing else in the method changes. ## The blocking class — 6 sites, and it is not specific to this file 1772, 1791 ×2, 1874 ×2, 1916, 1917, 1933 all read another task's column — a dependency's, a blocker's, an overlap candidate's — inside synchronous callbacks over a prefetched `taskById` map: ```ts const unresolvedDeps = (task.dependencies ?? []).filter((depId) => { const dep = taskById.get(depId); return dep && !dep.deletedAt && dep.column !== "done" && dep.column !== "archived"; }); ``` This is not a substitution. Each dependency may belong to a different workflow, so the role must be resolved per dep — N async resolutions inside a sync `filter`, on a path that deliberately prefetches into a map precisely to avoid per-item I/O. Two honest options: 1. Prefetch lifecycle columns alongside `taskById` and pass a resolved map into these predicates. Keeps them synchronous, one resolution per distinct workflow rather than per dep. This is the one I'd argue for. 2. Accept per-dep resolution and make the callbacks async — changes the shape of dependency evaluation. Both are design changes with real cost, so this is flagged rather than guessed. The same shape appears in at least two other clusters I've worked: `TaskDetailModal`'s `overlapBlockerTask.column` (#2696) and `register-task-workflow-routes`' dependency-summary pair (#2700), both flagged for this exact reason. Worth one decision covering all three rather than three separate judgement calls by three workers. ## Also flagged: 3 1610 and 1739 — enclosing-scope async-ness and store access not established at those points, so not guessed. 1933 belongs to the sync-filter family above. ## Verification `pnpm test:gate` GREEN (158 + 487 + 10 + 71) · `pnpm lint` clean · core `tsc` clean · `--strict` exits 0. 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * Bug Fixes * Updated failed pre-merge review bypass validation to support custom workflow boards. * Tasks can now bypass the step when placed in the board’s configured review lane. * Improved error messages to identify the correct review column when bypassing is not allowed. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 07:36:00 -07:00
gsxdsm	ceca08b1c3	fleet: github-tracking-reconciler 9 → 0 — deciding the sync-filter class (prefetch a resolved map), and the reconciler closed NO issues on a renamed board (#2737 ) `github-tracking-reconciler.ts` 9 → 0, and the reference implementation for the `.filter((task) => task.column === "<id>")` shape I have been flagging across four files. ## I stopped waiting and decided it I flagged this class in #2709, #2696, #2700 and #2715 as "needs one decision" and left ~25 sites unconverted. That decision was mine to make and I should have made it three PRs ago. Prefetch a resolved map, then filter synchronously. The alternative — async predicates — forces every caller into `for await` and turns a list comprehension into a sequential walk. Prefetching keeps the filters synchronous, puts the awaits in one bounded place, and lets the IR cache do the job it was explicitly built for: > "A self-healing pass over 400 cards spanning three workflows must read three IRs, not 400." The cache is instance-scoped and shared across all four passes, so each distinct workflow's IR is read once for the whole run rather than once per pass. `resolveLifecycleColumns` is pure and not memoized by that cache, so this still costs one cheap struct build per task — fine in a background reconcile, and stated rather than hidden. No new abstraction: `resolveTaskLifecycleColumns` already takes a caller-owned cache. The only new code is a local map builder and two named predicates. ## What it cost before On a board with renamed terminal lanes, every filter here matched nothing. The reconciler closed no GitHub issues and reported `scanned: 0` — a clean-looking pass that did nothing. ## Why this is not the split brain #2724 documents — checked, not assumed #2724 proves the archived gate in `packages/core` is enforced in three encodings, so converting one alone diverges them. I checked whether that applies here before converting: - This file contains zero SQL — measured: no drizzle, no `sql` template, no `eq`/`ne`. - It calls `listTasks({ includeArchived: true })`, so the SQL half has already been told to include archived rows. The filter selects among rows it was handed rather than deciding liveness a second time. Gate versus consumer is the distinction, and a consumer can be converted alone. The fourth pass needed its own check because its list comes from `listTasksForGithubTrackingReconcile`, which is SQL — but that impl filters on `deletedAt IS NOT NULL` and `githubTracking IS NOT NULL`, never on the column, so there is no SQL-side encoding of this question to diverge from. ## Why the 33 existing tests stayed green through the conversion Their fake store has no workflow reader, so `resolveTaskLifecycleColumns` catches and returns `undefined` and every case asserts the legacy fallback — exactly what it always asserted. None of them could have caught this being wrong. `workflowIr` is now an opt-in on that fake, which is what makes the new cases real tests rather than restatements. \| reverted \| result \| \|---\|---\| \| terminal filter back to the ids \| "closes issues on a RENAMED complete lane" fails, no `setIssueState` \| \| same \| renamed archived-heuristic case fails, no `setIssueState` \| ## A reachability finding, recorded not acted on In backend mode `reconcileDeletedAndArchived` returns only soft-deleted rows — its own comment says the archived-tasks fallback is a separate `AsyncArchiveLineage` subsystem, skipped there — and `task.deletedAt` is tested first in the `stateReason` chain. So its archived arm is effectively unreachable today. I converted it rather than deleting it: it is the documented FN-5577 done-heuristic, and whether that fallback should be wired here is a separate question from what vocabulary it speaks. ## Verification `pnpm test:gate` GREEN (158 + 10 + 487 + 71) · 35 passed across the three reconciler suites · dashboard `tsc` clean · `pnpm lint` clean · census `--strict` exits 0. Remaining files in this class (`branch-group-ops.ts`, `store.ts`, and the dependency pairs) can now follow this pattern instead of waiting — with the gate-versus-consumer check applied to each, since `branch-group-ops.ts` sits closer to the persistence layer than this one does. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 07:14:54 -07:00
gsxdsm	7c408ef650	fleet: merge path 10 → 2 — a merged PR never advanced its task on a renamed board (#2733 ) Claimed on #2728 before starting. The merge path: `merge-queue-ops-2.ts` + `merger.ts` — 10 → 2, both survivors flagged with reasons. ## A merged PR never advanced its task on a renamed board `applyPrMergedTransition` is what moves a card when GitHub reports a PR merged. Every guard in it was a default-lineage literal, and they all failed in the same direction: \| guard \| renamed board \| \|---\|---\| \| `column === "done"` → skip as already-done \| never matched, so a complete card was re-processed \| \| `column !== "in-review"` → bail `wrong-column` \| always matched, so a card sitting in review bailed \| Net effect: a PR merged on GitHub never advances its Fusion task. The operator sees a merged PR whose card sits in review forever — which reads as a broken webhook, so it gets debugged in the wrong place entirely. That is the most expensive property of this defect class: it does not just fail, it misdirects. One snapshot now covers the pre-check, the deliberate re-read (a merge can land between checks), and the move target. The target is asserted in the test alongside the guards, because converting guards alone would admit the card and then move it to a column the board does not declare. ## merger.ts - The orphan-stash liveness guard classified every finished task as unfinished on a renamed board, so orphaned stashes were never cleaned up. Unioned with the legacy ids: too strict here leaves clutter, too loose discards a stash whose task is still running, so over-inclusion is the safe direction. - The worktree-conflict scan filters by worktree path before resolving lanes. The naive order — resolve, then filter — is exactly what made the github-tracking reconciler scan proportional to task history (#2714 review). Lesson transferred rather than re-learned. - The deprecated `aiMergeTask` already-finalized guard. ## Two flagged, not converted `merge-queue-ops-2`'s sync enqueue guard runs inside `store.db.transactionImmediate`. A synchronous lane resolution reads `getTaskWorkflowSelectionImpl`, which returns `undefined` unconditionally in PostgreSQL mode — so a "conversion" there would drop the census by one and behave exactly as the literal (the finding from #2703). Converting it properly means making the path async or pushing the trait read into SQL: store architecture, not a call site. Left literal with that note, so the next worker does not turn it into a false green. `merger.ts`'s last comparison is the same class. ## Pre-existing red, reported not folded 22 failures in `packages/dashboard/src/__tests__/routes-github.test.ts` — spec revise/rebuild and approve/reject-plan, all asserting moves to `triage`, the column U11 deleted. Verified by reverting my diff and re-running: identical 22. Same stale-literal-in-a-test class as the two assertions #2720 fixed, and it is 22 tests pinning a column that does not exist — worth someone owning deliberately rather than as a rider here. ## Verification census 10 → 2 · `pnpm test:gate` 487 / 71 · 23/23 across three merger suites · 4 new cases, 2 red on revert · `tsc` clean in core and engine · `pnpm lint` clean. ## Also examined and deliberately left alone - `live-agent-count.ts` (6 guards) — every literal there is the documented degradation path for a task shape that was not enriched, and both production callers already enrich (`useExecutorStats`, `fn project`). Converting them converts nothing; deleting them removes the fallback that fixtures rely on. The invariant that matters is caller enrichment, which is not a literal at all. - `task-merge.ts` (6 guards) — `getTaskMergeBlocker` is a pure function with no store; its callers inject `resolveTask`. Resolving lanes needs a matching injected resolver, which is an interface change across every caller. Also worth a decision first: its dependency check accepts `in-review` as satisfied while the store's `blockedBy` computation (#2720) does not — two definitions of "dependency satisfied" in one codebase, and I am not settling that one silently inside a vocabulary sweep. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-30 07:08:16 -07:00

1 2 3 4 5 ...

517 Commits