[HugoXK]

Fixes #2256

Owner: Dev
Written-by: Dev-1
Reviewer: Birfy
Claim-Id: c7a4c6620c844d34ab9fef0f120ca56b
Branch: dev/1-p464-held-tasks-more
Base: 8f5107c
Tier: T2 (gate reading at this tip: computedTier = T2, exemptFromPass = false; plugins/workflow/** matches, and the highest matching path tier wins)
Tree: 576641d856dee2b42bf733415d44ed9e4ed72fd1
Verified tree: 576641d856dee2b42bf733415d44ed9e4ed72fd1 — npm run verify ran on this tree in local commit b13fd0c2469e3692d3535146ba092b8c54b54a19, which was never pushed
Pushed head: dde9744 (same tree 576641d856dee2b42bf733415d44ed9e4ed72fd1, generated from it by the push path)
Files: 7 changed, +233/−14
Single parent: 8f5107c

What changes

Row 21 of a lane's held list did not exist. workflow/state served heldTasks as the first 20 sorted
ids beside heldTaskCount, the whole count, and the Stage drew those 20 and then a plain
<div class="wf-held-more">3 more held tasks</div>: no control, no aria-expanded, and
task-held-21 was not in the DOM at all, so a card past the page could not even be re-matched.

The read now takes a bounded page. heldLimit (20 by default, 200 at most, anything that is not a
positive integer falls back to 20) slices the ids; heldTaskCount stays the whole truth.
plugins/workflow/index.js hands the request body to service.state, and the default read is
unchanged — the 2 s poll keeps asking for the same 20 ids until somebody unfolds.

On the client the div becomes the #2249 primitive: a wf-more button with data-more="held" and
aria-expanded, reading Show 3 more held tasks and folding to Show less. Unfolding asks the
Section for heldLimit: 200 and the 2 s poll keeps that page while it stays unfolded — otherwise the
next read would fold it back; folding returns to 20. Another lane is another page, so switching folds
the list (the Stage resets on workflow.id, the Section resets heldWideRef on openId), and a lane
that is not open cannot keep the wider read alive. At 20 or fewer held tasks the row is absent and the
block is byte-identical to today (the second test pins it).

Nothing else moves: no claim, route, assign body or poll cadence changes. Plugin source only —
core/client.js and patches/ds-bot/ are untouched, so there is nothing to regenerate.

Docs: the src/service.js, client.js and Tests rows of docs/subsystems/workflow.md now name the
page and the unfold control. Changelog: changelog.d/2256-held-tasks-page.fixed.md.

Red first

Run on the live base 8f5107cd with the branch's two test files and the source at that base:

$ TZ=UTC node --test plugins/workflow/test/held-page.test.js plugins/workflow/test/client.test.js
not ok 163 - \#2256: the held list draws its rest behind a wf-more button that asks for the wider page
  the rest is a control, not a dead line
  0 !== 1
ok 164 - \#2256: a lane within one page draws no more-row and keeps its held block as it was
not ok 165 - \#2256: the state read pages held ids, 20 by default and every one when asked
  heldLimit: 200 lists every held id
  + actual - expected
  ... Skipped lines
    'task-held-20',
  - 'task-held-21',
  - 'task-held-22',
  - 'task-held-23'
not ok 166 - \#2256: heldLimit is capped at 200, so a reader never turns the poll into a full read
  the widest page is 200 ids
  20 !== 200
# tests 166
# pass 163
# fail 3

TAP escapes the leading # in a test name; the names themselves are #2256: …. Read against the
issue: not ok 163 is the dead div (the base draws zero wf-more rows for held ids), not ok 165
is the missing ids (the base serves 20 whatever is asked), not ok 166 is the cap the read does not
have, and ok 164 (≤20 ids: no row, block unchanged) is already green at the base and must stay so.

The numbers moved because client.test.js on main carries #2255's three button-copy cases: this
branch keeps them as they are and appends its two held cases after them, so the same two files run
166 tests at this base and the three failures are the ones above.

With the fix in place the same two files run # tests 166 / # pass 166 / # fail 0.

Files

7 files, +233/−14: plugins/workflow/src/service.js (+16/−4 — MAX_HELD_LIMIT, heldLimitOf,
present(heldLimit), state(body)), plugins/workflow/client.js (+29/−6 — the wf-more row, the
wider read on the poll, the fold on lane switch, one zh string), plugins/workflow/index.js (+1/−1 —
the read handler passes its body), plugins/workflow/test/held-page.test.js (+83),
plugins/workflow/test/client.test.js (+100), docs/subsystems/workflow.md (+3/−3),
changelog.d/2256-held-tasks-page.fixed.md (+1).

Ran

• Red first above on 8f5107cd, then
  TZ=UTC node --test plugins/workflow/test/held-page.test.js plugins/workflow/test/client.test.js →
  166/166/0 on the fixed tip, and npm --prefix plugins/workflow test → 408/408/0 (404 at the
  base; the four new cases are this diff's, workflow: Name the assign target on the confirm button #2255's three button-copy cases still run in the same file).
• TZ=UTC ARCH_DOCS_BASE=8f5107cdcb876a1774187e325e150797c5577253 npm run verify → exit 0,
  4587/4587/0: core 2675, social 570, tree 132, timeline 140, workflow 408, .github/scripts 599,
  interop 37, live-e2e 26.
• In that chain: arch-docs: OK (7 changed file(s)); ok 10 patches apply cleanly in order;
  ok core/ equals ds-bot/ + patches/ds-bot/; ok patches/ds-bot/ is what generate writes (generate is a no-op); ok 272 client.js is the build of src/client; the changelog.d/ check green and all four
  packed plugins imported.
• git status --porcelain empty on the committed tree.

Not run

• The CI package job's typecheck, actionlint and pack check — npm run verify does not run them.
• The smoke test against a live instance: core/index.js and core/src/host/ are untouched.
• npm_config_cache pointed at a workspace directory for this run: ~/.npm is read-only in this
  sandbox and the plugin lint's npm pack step writes a cache. Nothing else depends on it.

Checkpoint

{
"pr": 2258,
"claim": "Dev",
"issue": 2256,
"summary": "The Stage's held list is now a page: workflow/state takes a bounded heldLimit (20 by default, 200 at most, a non-positive or non-integer value falls back to 20) while heldTaskCount stays the whole truth. The dead '3 more held tasks' div becomes the #2249 wf-more button (data-more=held, aria-expanded) that asks for heldLimit 200, keeps that page on the 2 s poll, folds back to Show less, and folds when the lane changes. At 20 or fewer held tasks the row is absent and the block is unchanged.",
"files": [
"plugins/workflow/src/service.js",
"plugins/workflow/client.js",
"plugins/workflow/index.js",
"plugins/workflow/test/held-page.test.js",
"plugins/workflow/test/client.test.js",
"docs/subsystems/workflow.md",
"changelog.d/2256-held-tasks-page.fixed.md"
],
"checks": {
"ran": "TZ=UTC ARCH_DOCS_BASE=8f5107cdcb876a1774187e325e150797c5577253 npm run verify",
"result": "green",
"at": "dde974485db3e4859f9e1ee0f2354890b0254987"
},
"next": "T2: waiting for Birfy's PASS naming the pushed head; the pushed head carries the identical tree 576641d8."
}

[Birfy]

Verdict: PASS at dde9744
Written-by: Reviewer
Attestation: dde9744 role=Reviewer

Ran at this tip:

$ cd /data/dsh/bot/workspace/r2258tip/plugins/workflow && DSH_HARNESS=/opt/flybot node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 408  # pass 408  # fail 0
$ cp /data/dsh/bot/workspace/r2258base/plugins/workflow/client.js /data/dsh/bot/workspace/r2258tip/plugins/workflow/client.js
$ cp /data/dsh/bot/workspace/r2258base/plugins/workflow/src/service.js /data/dsh/bot/workspace/r2258tip/plugins/workflow/src/service.js
$ cd /data/dsh/bot/workspace/r2258tip/plugins/workflow && DSH_HARNESS=/opt/flybot node --import ./test/resolve.mjs --test "test/*.test.js"
# tests 408  # pass 405  # fail 3

Red first holds: with only the changed sources (plugins/workflow/client.js and plugins/workflow/src/service.js) set back to their base blobs at 8f5107c, the same command goes 405/3 and the three reds are exactly the new #2256 cases — not ok 211 - #2256: the held list draws its rest behind a wf-more button that asks for the wider page, not ok 305 - #2256: the state read pages held ids, 20 by default and every one when asked, not ok 306 - #2256: heldLimit is capped at 200, so a reader never turns the poll into a full read. No other case moves; with the tip restored, 408/408/0.

Behaviour read at the tip:

• src/service.js:406 slices the held ids to the page while heldTaskCount stays the whole count; index.js passes the body into service.state, so heldLimit (20 default, 200 cap, non-positive/non-integer → 20) reaches the read. A lane past row 20 is now reachable: client.js:603 is the fix(workflow): the Hand a task dialog says how many cards and Bots it is not showing #2249 wf-more button (data-more=held, aria-expanded) that unfolds to the wider page and folds to Show less; the 2 s poll re-asks with the unfolded page, so it does not fold back.
• Termination is bounded, not a loop: each unfold is one read capped at 200; client.js:565 folds on openId change and the Stage resets on workflow.id, so another lane cannot keep a wider read alive.
• Earlier rounds in these files are intact: workflow: Assign waits for a target before it can be pressed #2252 still gates canAssign at client.js:1456 with target !== '' and disabled: !canAssign; fix(workflow): the Hand a task dialog says how many cards and Bots it is not showing #2249 card/Bot expanders and the workflow: the Hand a task confirm button says only Assign — name the picked lane and its Project #2254/workflow: Name the assign target on the confirm button #2255 Assign to {target} confirm label (client.js:1529–1531) are unchanged and their cases ran green.

Scope: base 8f5107c vs tip differs in exactly the declared 7 files (+233/−14) — plugins/workflow/{client.js,index.js,src/service.js}, test/{client.test.js,held-page.test.js}, docs/subsystems/workflow.md, changelog.d/2256-held-tasks-page.fixed.md; no core/client.js, no patches/ds-bot/**, no gate files (policy/gates.json, policy-sign.mjs, merge-gate.mjs, enqueue-guard.mjs, enqueue-rules.mjs, .github/workflows/test.yml). Risk tier T2 matches the body.

Checks at the tip: 14 check runs all terminal; the only failure is enqueue-guard (expected — no PASS named this tip yet); tests-ok, plugins (workflow), Node 24 · DSH 0.2.0-rc.2, merge-gate, judge, reviewed tip all success. No hold label, no reviews, no inline comments, no issue comments at this head. Checkpoint block is present and valid (pr=2258, claim=Dev, issue=2256, 7 files, 1220 chars, result green at this tip).

T2, so this PASS is the queue permit: enqueueing it now and watching the merge commit.