fleet: cli task.ts 8 → 0 + dashboard.ts 8 → 0 — and converting the retry classifier alone would have turned a silent no-op into a crash

[gsxdsm]

Census

	before	after
packages/cli/src/commands/task.ts	8	0
packages/cli/src/commands/dashboard.ts	8	0
repo backlog	610	594

Baseline re-recorded; --strict exits 0.

The finding: half this conversion would have been worse than none

Converting the retry classifier — so fn task retry recognises a renamed review lane at all — turned a silent no-op into a hard error:

TransitionRejectionError: Invalid transition: 'checking' → 'todo'. Unknown column for this workflow.

The command now correctly decided to retry, and then moved the card to the literal "todo", which does not exist on that board. Three moveTask(id, "todo") targets, none of which the census counts — it counts comparisons, and a move target contains no comparison at all.

So the classifier and the target are both converted here. Shipping only the first would have replaced "retry quietly does nothing" with "retry throws", which is a worse operator experience than the bug it fixed. This was caught only because the test drives the whole command rather than the predicate — a unit test of the classifier would have gone green on the half-fix.

What was broken

dashboard.ts — one rule, four copies. column === "in-progress" || column === "in-review" was pasted into the TUI refresh-stats callback, the periodic TUI refresh, the shutdown log summary, and the initial stats population. On a renamed board all four reported active=0 while the per-column counts printed immediately beside them showed the work plainly — a dashboard insisting nothing is running while its own board disagrees.

Extracted to one resolved helper. I am calling this de-duplication of an existing four-fold copy rather than a new abstraction: one rule, one implementation, so the four cannot drift apart again.

A real bug found while wiring it: one of the four lists from a board-scoped project store (taskStore), not the outer store. My first pass resolved workflows against the outer store for all four — which would have resolved foreign workflows for a scoped board. Threaded to the same store each site listed from.

task.ts — the archived-lineage label (a renamed archive silently lost its (archived) suffix), both node-override in-progress guards (the CLI would rewrite the node override of a task an agent was actively executing), the in-review retry classifier, and the near-duplicate candidate filter — where a renamed board never excluded completed work, so every finished task stayed a duplicate candidate and the guard flagged new work as a duplicate of something already shipped.

The duplicate filter reorders recency before the completion filter. Both still precede slice(200), so the resulting set and its order are identical; the reorder bounds the per-task workflow resolution by the 7-day window instead of the whole board.

The fixture is derived, not hand-built

The renamed workflow is BUILTIN_CODING_WORKFLOW_IR with only its column ids renamed. I first hand-built a four-node graph and the failures were instructive: the IR validator rejects an undeclared back-edge, and once declared as kind: "rework" the transition table still did not match the default board's. A hand-rolled fixture ends up testing the fixture's shape as much as the code. Deriving from the builtin guarantees the only difference between the two runs is the vocabulary — which is the entire differential claim.

It also asserts the rename landed (checking present, in-review absent), so a surviving literal cannot pass by accident.

Revert proof

reverted	result
retry classifier → column === "in-review"	1 failed / 1 passed
retry target → literal "todo"	1 failed / 1 passed
neither (shipped)	2 passed

Verification

• new PG suite — 2 passed (real store, real persisted workflow, driven through the real runTaskRetry)
• 5 adjacent CLI suites — 38 passed, no regressions
• pnpm test:gate — 158 / 10 / 487 / 71 · pnpm lint clean · CLI tsc --noEmit 0 errors

Not converted, deliberately

One DELIBERATE-LITERAL mark in task.ts: the board-print glyph at ~L615. Its comment already reasoned the case out fully — the loop iterates the legacy COLUMNS constant, so col can never be a custom id — it was simply missing the machine-readable marker. The deeper bug it names (a card in a renamed column is not rendered at all, because the loop derives its column set from the legacy enum) is the R8/U10 surface change and is far larger than this glyph.

[coderabbitai]

Warning

Review limit reached

@gsxdsm, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 2 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 2d289838-2ea1-4962-ac0b-3659973dbe14

📥 Commits

Reviewing files that changed from the base of the PR and between 2fe82cb and 93781f5.

📒 Files selected for processing (6)

• .changeset/cli-renamed-column-lanes.md
• packages/cli/src/__tests__/task-retry-renamed-review.pg.test.ts
• packages/cli/src/commands/dashboard.ts
• packages/cli/src/commands/task.ts
• packages/engine/src/restart-recovery-coordinator.ts
• scripts/lib/lifecycle-column-census-baseline.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

This PR makes CLI lifecycle handling workflow-aware for renamed columns.

• Resolves task retry classification and retry destinations from workflow roles.
• Aligns missing-worktree retry classification with the resolved review lane.
• Uses workflow traits for dashboard active counts, duplicate filtering, archive labels, and node-override guards.
• Adds PostgreSQL regression coverage for default and renamed review lanes.
• Adds the required patch changeset and updates the lifecycle-column census baseline.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
packages/cli/src/commands/task.ts	Replaces lifecycle-column literals with per-task workflow-role resolution across retry and related CLI behavior.
packages/cli/src/commands/dashboard.ts	Centralizes workflow-aware active-task counting and resolves scoped tasks against their originating project store.
packages/engine/src/restart-recovery-coordinator.ts	Allows the missing-worktree classifier to consume a resolved review-lane answer while preserving existing caller behavior.
packages/cli/src/tests/task-retry-renamed-review.pg.test.ts	Adds real-store coverage for retry behavior under default and renamed workflow vocabularies.
.changeset/cli-renamed-column-lanes.md	Records the published CLI fixes as a patch release using the required labeled format.
scripts/lib/lifecycle-column-census-baseline.json	Updates the literal-column census after converting the affected CLI comparisons.

_{Reviews (3): Last reviewed commit: "fix(cli): keep both retry classifiers on..." | Re-trigger Greptile}

[gsxdsm]

The split is real and is now closed. The stated consequence is not — and I checked rather than assuming, because the fix and the claim come apart here.

What is real: converting only the generic classifier left isInReviewMissingWorktreeSessionStartFailure on the literal, so on a renamed lane the generic branch fires and the specialized one does not. Two definitions of "in review" inside one function.

What did not reproduce: the claim that the generic branch leaves worktree/branch intact so the next execution repeats the failure. It doesn't. Both branches end with them cleared, because the backward move to the hold column clears them anyway. I instrumented the after-state under both vocabularies with the fix reverted:

AFTER> {"col":"todo"}        # default vocabulary
AFTER> {"col":"drafting"}    # renamed vocabulary

No worktree, no branch, either way. I also checked the two remaining candidate divergences and they converge too: with mergeRetries === 0 and no steps the execution-failure branch is taken and there is nothing to reset; with mergeRetries > 0 the merge-retry branch is taken and it does pass resetMergeRetries: true.

So the two new test cases do not fail with the fix reverted, and I am not claiming they do — the test's own comment says so, and so does the commit message. Reporting a proof I don't have would be worse than the bug.

I fixed it anyway, because a latent split is worth closing on its own terms and the fix is one optional parameter. isReviewColumn is optional: extension.ts asks both questions with the literal and is internally consistent that way, so the default preserves its meaning exactly while the converted caller passes the resolved answer.

The two new cases still earn their place — they pin that a missing-worktree failure in either vocabulary comes back retryable with no stale session metadata, which nothing covered before.

Verification: new suite 4 passed; restart-recovery suite 6 passed; pnpm test:gate 158 / 10 / 487 / 71; pnpm lint clean; CLI tsc --noEmit 0 errors.

[gsxdsm]

Fixed — added .changeset/cli-renamed-column-lanes.md as a patch on @runfusion/fusion, in the labelled summary/category/dev format. pnpm check:changesets passes.

The summary is written for operators ("CLI commands that stopped working on boards with renamed columns") with the mechanism kept in dev, per the AGENTS.md note that summary is the only field reaching end-user release notes.

[gsxdsm]

Both findings are already addressed on this branch — I verified rather than taking the commit messages' word — and there is a third issue neither review caught: this PR and #2728 collide.

Changeset (finding 2): present. .changeset/cli-renamed-column-lanes.md is in this PR's diff and is not on main, so it ships with the change. Correctly shaped too — summary/category/dev, patch bump on @runfusion/fusion.

Classifier (finding 1): fixed, via isInReviewMissingWorktreeSessionStartFailure(task, isReviewColumn?) — the caller passes the already-computed boolean, so the lane decision lives in one place and the classifier cannot be handed a set that disagrees with the gate beside it.

---

The collision, which is the thing worth acting on

#2728 widened the same function with a different signature, and both PRs are open:

PR	signature	who decides the lane
#2736 (here)		the caller, which already computed it
#2728		the classifier, by membership

Both typecheck and both are green on their own branch. Whichever merges second will not conflict textually in a way git flags — it will simply overwrite the other's signature and break the other's call site.

My recommendation is to keep this PR's boolean, and I say that against my own change: the caller here has already resolved the lane set to answer its neighbouring guard, so passing the boolean avoids recomputing membership and removes the possibility of the classifier and the gate disagreeing — which is the precise defect both PRs were opened to fix. The set form re-opens that door for the sake of a default nobody needs once the caller resolves.

If #2736 merges first, #2728's engine hunk should be dropped and its call site changed to pass the boolean; its CLI-side lane set stays as is. I will do that on #2728 rather than leave it for whoever hits the breakage.

Rebased onto current main and verified: CLI + engine tsc clean (0 errors), gate green (487 + 158 + 10 + 71), census --strict exit 0. Force-push checked with --not HEAD first — both remote commits were reproduced.

[gsxdsm]

Correction to my comment above — the shell ate the two signatures out of that table, which is exactly the comparison the comment exists to make. Restating it properly:

PR	signature	who decides the lane
#2736 (here)	isInReviewMissingWorktreeSessionStartFailure(task, isReviewColumn?: boolean)	the caller, which has already computed it
#2728	isInReviewMissingWorktreeSessionStartFailure(task, reviewColumns: Iterable<string> = ["in-review"])	the classifier, by membership

Both typecheck and both are green on their own branch. Whichever merges second will not produce a conflict git flags — it will overwrite the other's signature and break the other's call site.

Recommendation unchanged, and still against my own PR: keep this one's boolean. The caller has already resolved the lane set to answer its neighbouring guard, so passing the boolean avoids recomputing membership and removes any chance of the classifier and the gate disagreeing — the precise defect both PRs were opened to fix. The set form re-opens that door for a default that stops mattering once the caller resolves.

If this merges first, #2728's engine hunk should be dropped and its call site switched to the boolean; its CLI-side lane set is unaffected. I will do that on #2728 rather than leave it for whoever hits the breakage.

[gsxdsm]

Collision note for the coordinator — #2728 and #2736 overlap, and they are complementary rather than duplicate. #2728 was opened first; I did not see it before starting.

Both touch packages/cli/src/commands/task.ts and dashboard.ts, so they will conflict on merge. What each uniquely carries:

	#2728	#2736
extension.ts, dashboard retry route	✅	❌ (I explicitly declined — see below)
isInReviewMissingWorktreeSessionStartFailure across 3 surfaces	✅ (Set<string> param)	partial (boolean param)
active-task count in fn dashboard	✅	✅ (overlaps)
retry classifier (isInReviewRetry)	❌	✅
retry target (moveTask(id, "todo"))	❌	✅
near-duplicate candidate filter, archived-lineage label, node-override guards	❌	✅
changeset for the published CLI	❌	✅

Suggested order: land #2728 first, then I rebase #2736 onto it and drop everything already covered, keeping the retry classifier + target, the near-duplicate filter, the lineage label, the node-override guards, and the changeset. I am happy to do that rebase — just say the word.

One finding from #2736 that matters to #2728 regardless of order. Converting the retry classifier without also converting the retry target does not just leave a bug — it creates a worse one:

TransitionRejectionError: Invalid transition: 'checking' → 'todo'. Unknown column for this workflow.

runTaskRetry correctly decides to retry, then moves the card to the literal "todo", which does not exist on that board. There are three such moveTask(id, "todo") targets and the census does not count any of them — it counts comparisons, and a move target contains no comparison. So a future pass that converts the classifier alone will turn today's silent no-op into a crash, and the census will report progress.

Also worth flagging on the shared engine predicate: our two PRs give it different signatures (Set<string> vs boolean), so whichever lands second needs to adopt the other's. #2728's Set is the better shape for the multi-surface case.

Finally, on the P1 raised here about the two classifiers disagreeing: I measured it, and the stated consequence (stale worktree/branch retained) does not reproduce — both branches end with them cleared because the backward move clears them. Details in the thread above; recording it here so #2728 does not re-derive it.

[gsxdsm]

Superseded by #2752, which is the part of this that still matters.

#2728 landed first and covered the active-task count, the near-duplicate filter, the archived-lineage label, the node-override guards, and the missing-worktree classifier — so re-litigating those here would be conflict for no gain.

What it did not carry is now #2752: it converted the retry classifier and left the three re-queue targets on the literal "todo", which is the half-conversion I flagged on that PR before it merged. That combination is live on main today and it does not fail silently — it throws Invalid transition: 'checking' → 'todo'. The census cannot see it, because it counts comparisons and a move target contains none.

#2752 carries the target fix, the PG suite that reproduces main's crash, and the changeset for the published CLI that #2728 omitted.