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) <noreply@anthropic.com>
5e1f1df4e3