From 5e1f1df4e314616f9000b2bc5fcc8910593d49e8 Mon Sep 17 00:00:00 2001 From: gsxdsm Date: Thu, 30 Jul 2026 05:11:21 -0700 Subject: [PATCH] docs(dashboard): correct a false "deleted column" claim that shipped in #2726 (#2727) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Comment-only correction. **#2726 (mine) landed a factually wrong FNXC note in main** and this retracts it at the site. ## The false claim #2726's note — and its PR title — asserted a **live stale-target bug**: that `triage` is a column U11/#2515 deleted, so TaskCard's in-review move menu pushes `"Move to triage"` for a column that no longer exists. It is not deleted: ``` packages/core/src/builtin-coding-workflow-ir.ts:49 { id: "triage", name: "Planning", traits: [{ trait: "intake" }] }, ``` `triage` (intake) and `todo` (hold) are still **separate columns** on the default board, and `triage` also exists in `builtin-pr` and `builtin-lead-generation`. I was carrying a merged-planning-column shape from other work in this program and asserted it against the tree without reading the IR. **There is no stale-target bug.** I found this while preparing to report the "bug" as a review comment on #2688 — checking the builtins before filing is the only reason it did not propagate into a second PR. It had already shipped by then, which is why this is a follow-up rather than an edit. ## What the note says now What is actually true of the site: `column` is the **loop variable over the function's own hardcoded `["done", "triage"]` array**, so the comparison picks a label from a list this code just wrote itself. Resolving a trait for that string would be meaningless. This is the same reading #2688 arrived at independently, and it is the correct one. The **array** is a real open question — it names move targets by id rather than by role, so a workflow that renames those lanes gets targets it cannot show. That needs a Surface Enumeration per AGENTS (removing or changing a visible menu entry), so it stays flagged rather than fixed. A real question, unlike the one the old comment invented. ## Why a whole PR for a comment The FNXC convention exists so the *reasons* in this codebase stay trustworthy. A note that names a specific PR as having deleted a column, and a specific menu as broken, is exactly the kind of thing a future reader acts on — the cost of leaving it is someone "fixing" a working affordance, or discovering the note is wrong and trusting the surrounding notes less. Also worth recording: **#2726 duplicated #2688**, which claimed TaskCard.tsx first (09:41Z) and took it to 42 → 0. I did not check the remote branch list before starting and mine merged first, so #2688 now conflicts against work it predates. Wasted effort on my side, and a note for the fleet: `git branch -r | grep fleet` before claiming. ## Verification Comment-only — no behaviour change. Census `--strict` exits 0 (unmoved), dashboard `tsc -p tsconfig.app.json` clean, `pnpm lint` clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) --- .../dashboard/app/components/TaskCard.tsx | 32 ++++++++++++------- 1 file changed, 21 insertions(+), 11 deletions(-) diff --git a/packages/dashboard/app/components/TaskCard.tsx b/packages/dashboard/app/components/TaskCard.tsx index cc5be94070..8fe5930af8 100644 --- a/packages/dashboard/app/components/TaskCard.tsx +++ b/packages/dashboard/app/components/TaskCard.tsx @@ -2714,18 +2714,28 @@ function TaskCardComponent({ The retired in-review Move dropdown offered Done (no merge) and Triage in addition to the shared menu model's Todo/In Progress defaults. Fold those targets into this TaskCard-only menu so card consolidation retains every move capability without changing ListView or TaskDetail menus. */ /* - FNXC:WorkflowResolvedColumns 2026-07-31-01:20 (fleet phase — A LIVE STALE-TARGET BUG, flagged not fixed): - These are move TARGETS, not a column guard, and one of them is `triage` — the column #2515/U11 - DELETED when it merged intake and hold into a single `todo` lane. On a post-U11 board this pushes a - "Move to triage" entry for a column that no longer exists; `taskActionColumnLabel("triage")` then - labels a target the board cannot show. + FNXC:WorkflowResolvedColumns 2026-07-31-02:10 (CORRECTION of the note this replaced): + The previous version of this comment claimed `triage` was a column U11/#2515 had DELETED, making + this a live stale-target bug. THAT WAS WRONG, and it shipped. `triage` is a real, present column: - Not fixed here for two reasons: deciding what this affordance should offer instead (nothing? the - merged planning lane?) is a product call about a TaskCard-only menu, and removing a visible menu - entry is exactly the UI-affordance change AGENTS requires a Surface Enumeration for — the - workflow-row chevron took three tasks (FN-6115 -> FN-6118 -> FN-6123) for skipping it. Recorded - with the cause rather than silently converted to a role, which would have hidden the staleness by - making the dead target resolve to a live column. + builtin-coding-workflow-ir.ts:49 { id: "triage", name: "Planning", traits: [{ trait: "intake" }] } + + `triage` (intake) and `todo` (hold) are still SEPARATE columns on the default board, and `triage` + also exists in builtin-pr and builtin-lead-generation. I was carrying a merged-planning-column + shape from other work in this program and asserted it against the tree without checking the IR. + The move target is valid; there is no stale-target bug here. + + WHAT IS ACTUALLY TRUE OF THIS SITE, and why it stays a literal. `column` below is the loop variable + over this function's OWN hardcoded `["done", "triage"]` array. The comparison asks "which entry of + my own list am I on" in order to pick a label — not "what role does this card's column play". + Resolving a trait for a string this code just wrote itself would be meaningless. + + The ARRAY is the part worth revisiting, because it names move targets by id rather than by role, + so a workflow that renames those lanes gets targets it cannot show. That is a behaviour question + about which targets a review card should offer — and removing or changing a visible menu entry is + the UI-affordance change AGENTS requires a Surface Enumeration for (the workflow-row chevron took + FN-6115 -> FN-6118 -> FN-6123 for skipping it). Out of scope for a vocabulary conversion, but a + real question, unlike the one the old comment invented. */ if (isReviewColumn) { for (const column of ["done", "triage"] as const) {