`sortTasksForDisplayColumn` takes four role answers and defaults each to
the legacy id. Its own header names the callers that never supplied
them:
> *"defaults to the legacy id so the callers that do not resolve flags
(Lane, ListView) keep today's behaviour exactly."*
On a renamed board, today's behaviour is the **wrong order**, silently:
| lane | what is lost |
|---|---|
| hold | priority-then-FIFO queue order — an urgent card is no longer
visibly next |
| complete | completion-date ordering |
| review | the merging card no longer floats to the top |
Nothing throws, nothing logs. The cards are simply in the wrong order —
which is exactly why this survived every existing test in these files:
their fixtures use the built-in ids, where the defaults happen to be
right.
`Board.tsx` already resolves these from `column.flags`. Mirrored here
rather than answered a second way, including its `complete && !archived`
done-like rule.
## Reverted
All **3** new `Lane` cases fail. Each picks inputs where the role order
and the generic fallback **disagree**:
- hold — equal priority, so role order is created-at and the fallback is
task-id
- complete — `columnMovedAt` DESC vs task-id ascending
- review — a `merging` card, which the fallback ignores entirely
**My first draft asserted urgent-first and passed with the fix
reverted.** The generic sort also puts urgent first, so the assertion
discriminated nothing. Recording that because it is the second time this
shape has caught me: an assertion that is *true* is not the same as an
assertion that is *load-bearing*.
## Coverage I do not have
`ListView`'s identical wiring has **no component test**. Its harness
stubs `fetchBoardWorkflows` with a never-resolving promise, and
`listColumns` derives from the resolved workflow — so a renamed board is
not drivable there without reworking that stub, which several other
tests in the file depend on. The call site is covered structurally by
the lane-wiring ratchet (baseline 19 → 17) and by the helper's own unit
tests, but that is a structural guarantee, not a behavioural one. I
would rather say so than imply the two callers are equally proven.
## Verification
Lane + ListView + taskSorting + Board **357 passed** · `pnpm test:gate`
161 + 13 + 487 + 71 · lint · lifecycle census `--strict` · lane-wiring ·
fnxc-dates (TZ=UTC) · changesets — green.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Fixed task sorting in lanes and list views after workflow columns are
renamed.
* Preserved correct ordering for completed, on-hold, archived,
merge-blocked, and review tasks.
* Ensured task ordering reflects each column’s configured role rather
than its previous identifier.
* Maintained consistent ordering across board and list views.
* **Tests**
* Added coverage for renamed workflow columns and their expected task
ordering.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
35729699b8