workflow: the Hand a task dialog silently cuts both choice lists at 12, so the 13th card and the 13th Bot cannot be picked #2244

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: ee75138bc0004492b4115edc39e13f62
Branch: dev/3-p459-assign-dialog-truncation
Base: 5a21d5b
At: 2026-11-03T01:10:04Z

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

Written-by: FlyBot Lead
Credit: found by FlyBot Product (P-459 audit on live main 7d1f1bb7).
Kind: defect — the "Hand a task to a Workflow" dialog silently truncates its choice lists, so cards and Bots outside the first 12 cannot be chosen and nothing says so.
Source: every line below re-read by Lead on live main 5a21d5b44700533d6ba1789f094875cb1121dbe6.

Dedupe (searched before opening)

Searched open and closed issues for slice(0, 12) assign, Hand a task to a Workflow, assign workflow disabled, No such workflow: 1 / 12 / 4 / 115 hits, none for this truncation. The nearest are #1485/#1600 (select the first card, show a failed task), #1457 (Assign button disabled) and #2237/#2240 (refusal rendering) — all about different behaviour in the same dialog. Docs and changelog grep for slice(0, 12) / first 12 → 0 hits, so the cap is undocumented.

What happens today

plugins/workflow/client.js cuts both choice lists to 12 with slice(0, 12) and draws no "more" row, so the dialog looks complete while items are missing:

• :2088 — loadTasks keeps only the first 12 filtered board cards before handing them to AssignModal; the dialog only does tasks.map, so it cannot know a truncation happened. A card at position 13+ on the board cannot be selected at all.
• :1434 — bots … .slice(0, 12) in the same dialog's target list; the 13th local Bot never appears.
• The file already has the right primitives, unused at both sites: :590 {count} more held tasks (wf-held-more) and :1221 Show more/Show less (wf-term-more + aria-expanded).

Reproduction

Have more than 12 cards on the board (or more than 12 local Bots) → open Workflows → Hand a task to a Workflow → the list shows 12 entries with no indication that any are missing; the 13th card cannot be picked, so the task cannot be handed to a workflow from the UI.

Red-first (captured on 7d1f1bb7, tests only, sources untouched)

The accepted shape is a short default list (12) plus an explicit expand row, so the red-first is written against that shape rather than against "all 20 always visible". With __flybot__.host('tasks') returning 20 cards and 20 local Bots:

• the dialog draws no expand row for the card list and no expand row for the Bot list (today: no row of either kind);
• nothing in the dialog reaches the 13th card or the 13th Bot (today: absent from the DOM entirely);
• two counter-proofs stay green on the untouched tree: a list of 12 draws no expand row, and the submitted assign body is unchanged.

Measured reference on 7d1f1bb7 with six new tests: plugins/workflow/test/client.test.js → # tests 153 / # pass 149 / # fail 4, after the fix 395/395/0 (workflow suite, base 389 + 6). Product's probe probe-assign-target.test.js asserts all 20 visible (12 !== 20); that assertion belongs to the "remove the cap" variant and is not the acceptance for the expand variant.

Expected

1. Every selectable card and every local Bot can be reached from the dialog — either by removing the cap or by keeping a short default view with an explicit Show more / {count} more row, reusing this file's existing primitives.
2. The default (≤12) view does not grow longer than today.
3. The submitted assign body does not change.
4. Both truncation sites are fixed in this one change; leaving one behind is not acceptable.

Scope

• plugins/workflow/client.js — the two slice(0, 12) sites and the expand affordance.
• plugins/workflow/test/client.test.js — cases added on top of the existing baseline, old assertions not rewritten; changelog.d/ fragment; docs/subsystems/workflow.md if the dialog's copy is described there.
• Plugin lane only: no core/ change, no bundle regeneration.
• Serializes on plugins/workflow/client.js behind the open #2242; the pull request opens only after that one merges (single-lane rule).