workflow: the held list promises 230 more but the host caps one read at 200 #2260

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment on this issue.

Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 46a5d0b3651c4bd8bad45ed93c6a4a07
Branch: dev/4-p470-held-cap-remainder
Base: 4a9d3ed
At: 2026-11-03T04:10:29Z

Implementation: FlyBot (ours) — PR follows within 24h. Do not pick up without a pickup-ok comment.

Written-by: FlyBot Lead

Reproduction (live main 4a9d3edd2dcac112797e1d028b3f5f790a4f467e, the #2259 merge)

A lane ends up holding 250 cards — every workflow/assign holds one, maxConcurrent defaults to 2 with an unbounded queue, and a claim stays on the lane after the card leaves the board. Open that lane's Stage:

1. Folded: 20 rows plus a button reading Show 230 more held tasks.
2. Press it: 200 rows, the button becomes Show less, and nothing on screen says 50 ids are still missing; ids 201–250 are neither drawn nor reachable by a second control.

Independent probe, reads any sha (no install, no tree writes):

node probes/workflow-held-cap.mjs 4a9d3edd2dcac112797e1d028b3f5f790a4f467e
PROBE_HELD_FOLDED   {"heldTaskCount":250,"rowsDrawn":20,"moreLabel":"Show 230 more held tasks","ariaExpanded":false}
PROBE_HELD_UNFOLDED {"asked":{"heldLimit":200},"rowsDrawn":200,"moreLabel":"Show less","ariaExpanded":true,"idsStillUnreachable":50,"moreControls":1,"namesTheRemainder":false,"lastIdInDom":false}
PROBE_LIMIT         {"plain":20,"wide200":200,"thousand":200,"count":250}

Why it is a defect

#2256 (shipped by #2258) replaced a dead "N more" line past row 20 with a control that really pages the list. Past 200 that control promises 230 and delivers 200: the same dead promise comes back, only now as a button that cannot deliver it. The reader is told the rest is one click away and there is no second click.

Expected behaviour

• Folded: the button counts what pressing it actually reaches — min(heldTaskCount - heldShown.length, HELD_LIMIT - heldShown.length).
• Unfolded: when heldTaskCount > held.length, one line Showing {shown} of {count} held tasks, the same shape as feedback.js's Showing the newest 50 of 60, so the 200 cap is stated instead of hidden.

Scope

• plugins/workflow/client.js:567 (heldShown), :601-605 (the more control and its label), :1436 (HELD_LIMIT = 200).
• plugins/workflow/test/client.test.js: red first at the base — 250 held ids, workflow/state {heldLimit:200}, assert the folded label equals the reachable count and the unfolded view names the remainder; today assert.equal(rows().length, 250) fails as expected 250, actual 200.
• docs/subsystems/workflow.md one line.
• Counter-case: with 200 held ids or fewer the Stage text stays byte-identical, and the #2256/#2257 cases do not change.

Same statement, same PR, docs only

docs/subsystems/workflow.md says any value other than a positive integer "falls back to 20", but heldLimitOf goes through Number(): heldLimit:'10' really reads 10 ids and heldLimit:true reads 1; only 0, -5, 3.5, 'many', null fall back. State the real rule in the docs rather than tightening the code (tightening would change a contract a client already relies on).

Dedup (run before opening, 2026-11-03)

Live main grep for HELD_LIMIT, heldLimit, wf-held-more; closed issues #2256 (this same list, row 20 → a page, closed by #2258) and #2244 (the 12-row cap in the Hand-a-task dialog, a different surface); no open issue covers the 200-cap remainder. Backlog P-135 (held rows show raw ids), P-181 (queue depth) and P-190 (queueRole chip) are different.