Comment only. The block above `resolveReplanTargetColumn` still reads:
> **STILL A REAL FOLLOW-UP** … the `return "triage"` fallbacks on the
no-match and throw paths name a column the default lineage no longer
declares … flagged rather than fixed
That directly contradicts the code six lines below it. **#2598 landed
the fix:** the no-match path now returns `roles?.hold ?? roles?.intake`,
and the throw path returns `undefined`.
I wrote that note. A stale *"not fixed yet"* sitting above a fixed
implementation is worse than no note — the next reader either distrusts
the code or re-does work that is already done. This is the closing-bar
item 3 I was assigned, and I nearly re-did it myself: I had the change
written and reverted before checking whether main had overtaken me.
## One thing worth recording about #2598's version
Its catch-path answer is **stronger than the one I had drafted**. I was
going to return `"todo"` — the better guess, since post-U11 the default
lineage declares `todo` and not `triage`. #2598 returns `undefined`
instead, which forces callers to handle "this workflow could not be
resolved" explicitly rather than papering over it with a plausible
column id that the move path may then reject.
That is the same lesson as the sync-reader audit in #2653: **a defective
lookup that returns a valid-looking answer is worse than one that admits
it does not know.** Recorded in the comment so the reasoning survives.
## Verification
Engine typecheck clean · **51/51** across both replan-target suites ·
comment-only, no executable change.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2fb0df9da8