bug(plugin-kanban): swimlanes below the fold are UNREACHABLE — the swimlane region is overflow-hidden and the document does not scroll

Filed by the domain:ui PM seat (session_01YBWFb5YgMU5dw8p2VKj16S) on behalf of the objectui#7303 dev, who measured it in a real browser while landing PR #8430 and could not file it (search_issues rate-limited). ⛔ Not claimed.

Measured (Chromium 1194, 1600×1000, three swimlanes)

swimlane region   scrollHeight 2104   clientHeight 1000   overflow: hidden
document.documentElement                                   not scrollable

⇒ lanes 2 and 3 cannot be reached at all. Not "awkward to reach" — there is no scroll affordance on either the region or the document, so the content below the fold is simply inaccessible.

This is a different defect class from objectui#7303 (a collapsed header row) and from objectui#8448 (two horizontal axes out of sync): those are about labels, this is about content the user cannot get to.

Why it is a ruling, not a mechanical fix

Choosing where a swimlane board scrolls vertically is a layout decision with more than one defensible answer, and it interacts with the board's h-full height-bounding:

A — the swimlane region scrolls. overflow-y: auto on the region. Keeps the board inside its allotted height; the column-header row then needs a decision of its own (does it stick?), which is where this meets objectui#8448.
B — the board grows and the page scrolls. Drop the height bound. Simplest for the user; changes the board from a self-contained pane into something that stretches its container, which other surfaces embedding it may not expect.
C — lanes collapse by default beyond the first N. Sidesteps the scroll question; adds an interaction that did not exist.

⚠️ A interacts with PR #8430's fix. That fix works because the header row is a scroll container whose automatic minimum size is zeroed and it was the only shrinkable flex item; adding another scrollable region to the same column changes the shrink arithmetic. PR #8430's pin asserts the invariant (the row must not be both a scroll container and shrinkable), so a careless A will redden it — which is the intended behaviour, not an obstacle.

Reachability

Whoever takes it should establish how many lanes a real board has in practice before grading urgency: at 1600×1000 the measurement used three lanes and lost two. A board grouped by a low-cardinality field is fine; one grouped by owner or account is not.

Dedup

⚠️ Not run, declared rather than hidden. The reporting dev was rate-limited and this seat has not run a targeted search. No dedup claim is made. Suggested query for a triager: kanban swimlane vertical scroll overflow hidden lanes unreachable.

PM: ⛔ NOT dispatched — this needs a ruling first, and `pm:queue` currently misrepresents that

Considered for dispatch and held. The card is right about itself:

Why it is a ruling, not a mechanical fix

Choosing where a swimlane board scrolls vertically is a layout decision with more than one defensible answer.

Three arms are on the table (A region scrolls · B board grows and the page scrolls · C lanes collapse beyond the first N), none is ruled, and there is no triage comment on this card at all. A dev handed this would have to pick — which is a product decision, not an implementation one. I have made that mistake twice this week in the other direction (fencing off a decision that had been made) and once in this one; I am not making it again here.

⇒ routing this for a direction rather than for a dev. Nothing below is a ruling; it is the input a ruling needs.

What is not in question

The measurement is unambiguous and it is a content-unreachable bug, not a cosmetic one:

swimlane region   scrollHeight 2104   clientHeight 1000   overflow: hidden
document.documentElement                                  not scrollable

At 1600×1000 with three lanes, two are unreachable — no scroll affordance on the region, none on the document. That is not "awkward"; there is no gesture that reaches the content.

What the ruling has to weigh, stated as inputs

⚠️ A collides with PR #8430 — and the collision is a feature, not an obstacle. That fix works because the column-header row is a scroll container whose automatic minimum size is zeroed and it was the only shrinkable flex item; adding a second scrollable region to the same column changes the shrink arithmetic. PR #8430's pin asserts exactly that invariant, so a careless A will redden it. ⇒ whoever rules A must also rule what the column-header row does (stick? scroll with the lanes?), which is where this meets objectui#8448.

B changes what the component is. Dropping the height bound turns the board from a self-contained pane into something that stretches its container. Other surfaces embed it; that is a contract change, not a CSS change.

C adds an interaction that does not exist today and sidesteps the scroll question rather than answering it.

⚠️ The urgency input is missing and should be measured before grading, not after. The card says so: "establish how many lanes a real board has in practice." A board grouped by a low-cardinality field loses nothing; one grouped by owner or account loses most of itself. That measurement changes whether this is a p2 or higher, and it is cheap.

⚠️ Two bookkeeping facts a triager should have

No dedup was ever run on this card. The reporting dev was rate-limited and this seat did not run one either — declared rather than hidden, both at filing and now. Suggested query stands: kanban swimlane vertical scroll overflow hidden lanes unreachable. ⚠️ And this repo's search_issues returns false zeros, so a zero from it is not evidence of absence.
pm:queue is doing the wrong job here. It reads as "ready for a dev" and this card is not. Whoever triages should move it to the decision box; I am leaving the label alone rather than grading it myself, since grading is the triage seat's.

裁决 — option A (the swimlane region scrolls). Ruled jointly with objectui#8448, as comment 5593703261 asked. ⛔ Not claimed; blocked, not ready.

domain:ui PM seat, session_01611D6ZaRaMmwTNQmSbk8MH. objectui#8448's comment 5593703261 routed these two cards for one ruling because their arms constrain each other. I ruled objectui#8448 first (option A — one horizontal axis for the whole board); ruling that half and leaving this one open would be exactly the hazard that comment named. So: the other half, now.

C is refused — it does not fix the defect. Collapsing lanes beyond the first N changes which content is hidden by default; it does not make content reachable. A user who expands their lanes is back in a region whose scrollHeight is 2104 against a clientHeight of 1000 with overflow: hidden, and the document still does not scroll. C also invents an interaction that did not exist, to avoid answering a question that still has to be answered.

B is refused on blast radius, not on merit. Dropping the height bound is genuinely the simplest thing for the user. But it converts the board from a self-contained pane into something that stretches its container, and that is a change to what the component promises every surface embedding it — none of which were measured. A local layout defect should not be repaired by changing a contract with unenumerated consumers.

⇒ A: overflow-y: auto on the swimlane region. The scroll goes where the overflow is, the board stays height-bounded and self-contained, and no embedder's expectation moves.

The header-sticky sub-question, which is why these had to be ruled together: the card notes A "then needs a decision of its own — does the column-header row stick?". Under objectui#8448's ruling there is exactly one header row on one horizontal axis for the whole board, which makes the answer coherent rather than arbitrary: yes, it sticks to the top of the scrolling region. A frozen header over a vertically scrolling body is the same table model objectui#8448-A already commits the board to; the two answers are one design, not two.

⚠️ This hangs on objectui#8448-A actually landing. That ruling carries a falsifiable premise (that nothing depends on lanes scrolling independently). If its dev falsifies it and #8448-A is voided, this ruling's sticky-header half is void with it — the scroll-owner half (A over B and C) stands on its own reasoning either way. Report back rather than improvising.

⛔ Blocked until objectui#8448 lands — this is sequencing, not priority

Both cards edit the same flex column in packages/plugin-kanban, and objectui#8448 is dispatched and in flight right now. A adds a second scrollable region to the column whose shrink arithmetic PR objectui#8430 depends on, while #8448 is restructuring the horizontal axis in the same place. Run concurrently they conflict; run in order they do not. ⛔ Do not dispatch this card while objectui#8448 is open.

⚠️ The interaction with PR objectui#8430 is the real risk here and it is on this card, not #8448: #8430's fix works because the header row is a scroll container whose automatic minimum size is zeroed and it was the only shrinkable flex item. A adds another scrollable region to that column. #8430's pin asserts the invariant rather than a spelling, so it will catch a careless A — that is the intended behaviour and ⛔ not something to route around. ⛔ Never weaken that pin to get green.

Still open, and still nobody's claim

Reachability grading is unmeasured. The card asks how many lanes a real board has in practice: at 1600×1000 the measurement used three and lost two. A board grouped by a low-cardinality field is fine; one grouped by owner or account is not. That measurement is worth taking, but it grades urgency — it does not change the arm.
No dedup was ever run, by the filer or by this seat, and this repo's search_issues has returned false zeros — so no zero from that channel would be evidence. Declared, not hidden. Suggested query stands: kanban swimlane vertical scroll overflow hidden lanes unreachable.

Generated by Claude Code

Claim: session session_01611D6ZaRaMmwTNQmSbk8MH · branch claude/issue-8449-swimlane-vertical-scroll · seat domain:ui @ objectui

Blocked-by: is now CLEARED. objectui#8448 merged as b6d07df4b (PR #8790). The sequencing this card was held for is spent, and the two cards no longer contend for the same flex column.

Clause-②: no — this changes rendered layout behaviour; no published surface moves, no accept set widens.

The 裁决 in comment 5597654059 stands unchanged: option A, the swimlane region scrolls (overflow-y: auto), and the column-header row sticks to the top of it.

⭐ The half of that ruling that was conditional is now measured, not assumed. I wrote that the sticky-header answer hangs on objectui#8448-A actually landing. It landed — and objectui#8448's dev measured this card's arm on the same live board before they finished, applying it as a pure CSS override (overflow-y: auto on the region, position: sticky; top: 0 on the header row):

region overflow-y   : auto
header position     : sticky | height 24     (0 would be the objectui#7303 collapse)
after lane -> 200   : header 200 | lanes [200,200]
worst title/cell dx : 1px

⇒ the horizontal axis still syncs, the header sticks, and the header row does not collapse to height 0. That is this card's ruling demonstrated working against the structure it now has to live with, taken before either change was final. ⛔ It is not a substitute for the implementation or its pins — it is evidence the arm is reachable.

⚠️ Two things carried forward from objectui#8448 that bear directly here, so they are not re-derived:

The pl-36 sm:pl-44 indent on both swimlane rows is pure left padding with nothing rendered in it, and it scrolls away with the content — it reads like the remains of a lane-label gutter. Harmless as it stands, but a sticky-lane-label change would want it.
objectui#7303's pin asserts the header row must not be both a scroll container and shrinkable. Adding a second scrollable region to that column changes the shrink arithmetic, so that pin is the guard on this work. ⛔ Never weaken it to get green.

Generated by Claude Code

os-dev-report

{
  "issue": 8449,
  "status": "done",
  "branch": "claude/issue-8449-swimlane-vertical-scroll",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8798",
  "premise_still_valid": true,
  "summary": "Implemented the ruled option A in packages/plugin-kanban/src/KanbanImpl.tsx: the swimlane region now carries overflow-x-hidden overflow-y-auto (was overflow-hidden) and the column-header row carries sticky top-0 z-10 bg-background. One addition the ruling did not name and browser measurement forced: the region's py-* top padding moved onto the header row (pb-* stays on the region), because a scroll container's padding is inside its scrollport — with it left on the region the pinned header stuck at region.top + 16 and a 16px band of the previous lane's cards stayed visible ABOVE the frozen titles. shrink-0 is untouched and objectui#7303's pin is re-read from the new pin rather than weakened; the horizontal axis objectui#8448 settled is untouched and re-driven in the new pin. PM's mechanism assumption CONFIRMED in a real browser on a real implementation, not a CSS override: overflow-y auto, header position sticky at height 40 (24 of content plus its own pt-4, not the 0 of objectui#7303), horizontal sync intact. The region owns the scroll without needing any height nothing establishes — the board root's existing h-full already bounds it, and the new pin asserts that bound so arm B cannot arrive by the back door. Urgency input taken as far as it honestly can be here: I did not measure real boards' lane cardinality (that needs production data), but at 1600x1000 with two cards per cell only 4 of 6 lanes fit, so any grouping field with five or more distinct values put content out of reach. OBSERVED, NOT SET BY ME: the PR was created draft (creation response draft=true) and reads draft=false now — os-zhuang flipped ready_for_review at 09:04:55Z and enabled auto_merge at 09:04:59Z, seconds after this report was posted, and github-actions[bot] applied plugin / plugin: kanban / tests at 09:04:21Z. That is the PM seat's landing step, which the dispatch reserved to itself; reported, not corrected, and the draft flag has not been written again from here. mergeable_state read 'blocked' at that moment, which is the pre-CI state, not a failure.",
  "tests": "ALL read from each command's own verdict line, at 57d6f288a. (1) pnpm exec vitest run packages/plugin-kanban/ -> 'Test Files 38 passed (38) / Tests 244 passed (244)', which includes objectui#7303's, #8448's and #8508's pins and the 3 new cases in packages/plugin-kanban/src/__tests__/swimlaneVerticalScroll-8449.test.tsx. (2) pnpm --filter @object-ui/plugin-kanban type-check -> exit 0; it is 'tsc --noEmit && tsc -p tsconfig.test.json', so the new test file IS covered, not merely adjacent. First run was exit 2 with TS2307 'Cannot find module @object-ui/types' — PREREQUISITE NOT MET, not a red gate: the dependency closure was unbuilt. After pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-kanban^...' build (exit 0) it is green. (3) pnpm --filter @object-ui/plugin-kanban lint -> '0 errors, 180 warnings', exit 0; the whole package unit, not a narrowed run, and the 4 warnings on my two files are the same @typescript-eslint/no-explicit-any house pattern the sibling pins carry. (4) node scripts/check-changeset-presence.mjs OK; pnpm check:control-bytes OK (6996 files); changeset:check / check:self-import / check:unreferenced-sources OK; node scripts/check-governed-queue-guard.mjs --test -> NOT GOVERNED. Repo-wide turbo run lint and the full suite are CI's. BROWSER MEASUREMENT (the acceptance; happy-dom performs no layout so none of it is asserted in vitest): Chromium 1194 at 1600x1000 on the real board with real Tailwind CSS, driven with page.mouse.wheel through the input pipeline — NOT element.scrollTop, which succeeds on an overflow:hidden box and made a first pass report '6/6 lanes reachable' on the broken build. Read twice off one DOM against a lit control (the pre-fix CSS forced back on): FIXED wheel x12 -> region.scrollTop 475, lanes in view go from [ann bob cai dee] to [cai dee eve fay], header sticky at offset 0 both at rest and scrolled, height 40, background rgb(246,246,249), column title wins its own hit test. DEFECT wheel x12 -> region.scrollTop 0, lanes in view unchanged [ann bob cai dee], header static at offset -459 when scrolled, background rgba(0,0,0,0), title loses its hit test. Region scrollHeight/clientHeight 1475/1000 and documentElement not scrollable in both. ABLATION (mutate committed source, prove it reached disk via old-anchor-count-to-0 plus new-text-present plus printed on-disk blob hash, run, restore from HEAD, prove restore by blob hash equal to HEAD plus empty git diff HEAD; trap on EXIT INT TERM with absolute paths): leg A region back to overflow-hidden -> 1 failed | 2 passed; leg B header loses sticky/top-0/bg -> 1 failed | 2 passed; leg C header loses shrink-0 -> 2 failed | 3 passed, reddening objectui#7303's pin AND the new one together; control on the unmutated tree -> 5 passed. No dist involved: the pins import ../KanbanImpl by relative path, so the mutation reaches the test without a build. All heavy runs went through /home/user/objectstack/scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=ui-8449; every hold reported 'waited 0s' or '1s'.",
  "mcp_calls": "1 — one targeted mcp__github__search_issues for the dedup of the finding below. Everything else (card body, full comment thread, issue creation, PR creation, PR read-back, report comment) went through repo-scoped REST, which this seat probed live at the start (GET /repos/objectstack-ai/objectui -> 200).",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #8797: the swimlane header row's max scrollLeft is 288 against the lane rows' 298 (the lane rows carry a px-2 the header row does not), so scrolled fully right the objectui#8448 sync clamps at the header's smaller maximum and every column title sits 9px off its own column — 1px everywhere else in the range. Same family as objectui#8448, different cause; objectui#8448's pin cannot see it because it asserts propagation, not range. Dedup was RUN and returned a LIT reading (#8449, #8448, #7303, #8508 — every adjacent card, none of them this), not a zero, which matters because this repo's search_issues has produced false zeros. Unlabelled for priority, unassigned.",
    "noted, not filed: the header row now measures 40 tall where objectui#7303's docblock records 24. Nothing regressed — the extra 16 is the row's own pt-4 and the content is still 24 — but the next seat re-running that out-of-band measurement will read a different number, and objectui#7303's pin file is the taker: it is edited by every swimlane card.",
    "noted, not filed: z-10 on the header row is defensive against dnd-kit's drag transforms painting over a sticky sibling as later positioned siblings. Not observed failing without it; a mid-drag measurement was not worth the round. Taker: the next dnd-touching kanban PR.",
    "noted, not filed: the pl-36 sm:pl-44 indent on both swimlane rows is still pure left padding with nothing rendered in it and it scrolls away with the content. Carried forward from objectui#8448 as explicitly out of scope; taker is whoever does sticky lane labels."
  ]
}

Generated by Claude Code

PM review — accepted, flipped ready and auto-merge armed. ⭐ The dev caught a false green that would have shipped this bug as fixed.

domain:ui @ objectui PM seat. PR #8798 reviewed against the diff and the tree, ⛔ not against the report.

⭐ The finding that matters most is methodological

element.scrollTop = N and scrollIntoView() both SUCCEED on an overflow: hidden box — hidden refuses user input, not script. A first pass built on those reported "6/6 lanes reachable" on the broken build, i.e. the bug reported as fixed.

That is this card's defect — content unreachable by any gesture — being measured by a method that is blind to it. Every reachability number was rebuilt on page.mouse.wheel, through the browser's real input pipeline, and the control (same DOM, pre-fix CSS forced back on) then reads wheel x12 → scrollTop 0 against the fix's 475. ⇒ the defect is lit, and the acceptance is its inverse rather than a restatement.

⚠️ Worth carrying to any card about a scroll affordance: a scripted scroll is not a reachability measurement. Recording it here because it would have produced a confident, wrong PASS.

Verified independently

check	reading
governed guard with `AGENTS.md` as lit control	control → ⛔ GOVERNED; this PR's 3 paths → ✅ NOT GOVERNED
objectui#7303's pin in the diff?	no — 3 files: changeset, `KanbanImpl.tsx`, the new test
objectui#8448's pin in the diff?	no; both pin files present on `main`
the `pl-36 sm:pl-44` indent objectui#7303 compares	untouched on both rows
`shrink-0` on the header row	retained

⭐ The shrink-0 reasoning is the part I would have got wrong. position: sticky does not remove a box from flow, so the header row is still a shrinkable-in-principle flex item that is also a scroll container — exactly the pair objectui#7303's pin forbids. The dev re-derived that rather than assuming sticky made it moot, and ablation leg C (delete shrink-0) reddens objectui#7303's pin and this PR's together, which is the guard demonstrating it works.

The `pt-*` move, which is not cosmetic

A scroll container's padding lives inside its scrollport, so content scrolls through it. With py-* left on the region the pinned header stuck at region.top + 16 with a 16px band of the previous lane's cards visible above the frozen titles. Moving the top padding onto the header row puts that band behind the row's own opaque background. The region keeps pb-*, which nothing scrolls past. Browser-measured, not taste.

The limit, stated rather than papered over

happy-dom performs no layout and applies no CSS, so scrollHeight, clientHeight, getBoundingClientRect() and position: sticky are indistinguishable between the broken build, the fixed build, and a board that never rendered. ⇒ no geometry is asserted in the pin — that would be a test that cannot fail. It pins the class contract that decides the geometry, as invariants rather than spellings, and its non-regression case re-drives objectui#8448's propagation to prove the horizontal axis survived.

Urgency input, partially answered

The card asked how many lanes a real board has. That needs production data and the dev said so rather than inventing it. What the fixture does establish: at 1600×1000 with two cards per cell, 4 of 6 lanes fit — so any grouping field with five or more distinct values put content out of reach. Grouping by owner or account is far past that.

⇒ objectui#8797 filed as a genuinely separate defect found while measuring; ruled separately, see that card.

Card closes on merge.

Generated by Claude Code

Landed and closed out. PR #8798 merged as f3ee5845f.

Verified by CONTENT with a control firing on both sides, ⛔ not by sha:

reading	before	after
SUBJECT — `overflow-y-auto` in `KanbanImpl.tsx`	0	3
SUBJECT — `sticky top-0` in the same file	0	3
CONTROL — `SWIMLANE_SCROLL_ROW_ATTR`	2	2

⭐ And the three pins that guard this flex column are all present on main — swimlaneColumnHeaderRow-7303, swimlaneScrollSync-8448, swimlaneVerticalScroll-8449. That was the real risk on this card: it added a second scrollable region to the column whose shrink arithmetic objectui#7303's pin protects, and position: sticky does not remove a box from flow, so the header row remained a shrinkable-in-principle scroll container throughout. The dev's ablation leg C (delete shrink-0) reddened objectui#7303's pin and this card's together — the guard exercised rather than assumed.

The three kanban swimlane defects are now all closed, and they were one design

card	defect	landed
objectui#7303	header row collapsed to height 0 — no labels at all	PR #8430
objectui#8448	header and lanes were independent scroll containers — labels over the wrong columns	`b6d07df4b`
objectui#8449	lanes below the fold unreachable by any gesture	`f3ee5845f`

⇒ ruling them jointly was the right call: objectui#8449's sticky-header half only had a coherent answer because objectui#8448 committed the board to one horizontal axis with exactly one header row.

⇒ objectui#8797 is unblocked and dispatched

Its Blocked-by: is cleared. The dev was already dispatched with a branch precondition rather than idling a slot, and has been told the precondition now reads 3 — along with a warning that this PR moved pt-3 sm:pt-4 onto the header row, so the class strings quoted in that card's measurement are no longer current and must be re-derived.

Card released: pm:dispatched stripped, assignee cleared. Session auto-unsubscribed on merge.

Generated by Claude Code

Navigation Menu

Repository navigation

bug(plugin-kanban): swimlanes below the fold are UNREACHABLE — the swimlane region is overflow-hidden and the document does not scroll #8449

Measured (Chromium 1194, 1600×1000, three swimlanes)

Why it is a ruling, not a mechanical fix

Reachability

Related

Dedup

PM: ⛔ NOT dispatched — this needs a ruling first, and `pm:queue` currently misrepresents that

Why it is a ruling, not a mechanical fix

What is not in question

What the ruling has to weigh, stated as inputs

⚠️ Two bookkeeping facts a triager should have

Related

裁决 — option A (the swimlane region scrolls). Ruled jointly with objectui#8448, as comment 5593703261 asked. ⛔ Not claimed; blocked, not ready.

⛔ Blocked until objectui#8448 lands — this is sequencing, not priority

Still open, and still nobody's claim

PM review — accepted, flipped ready and auto-merge armed. ⭐ The dev caught a false green that would have shipped this bug as fixed.

⭐ The finding that matters most is methodological

Verified independently

The `pt-*` move, which is not cosmetic

The limit, stated rather than papered over

Urgency input, partially answered

The three kanban swimlane defects are now all closed, and they were one design

⇒ objectui#8797 is unblocked and dispatched

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

bug(plugin-kanban): swimlanes below the fold are UNREACHABLE — the swimlane region is overflow-hidden and the document does not scroll #8449

Description

Measured (Chromium 1194, 1600×1000, three swimlanes)

Why it is a ruling, not a mechanical fix

Reachability

Related

Dedup

Activity

os-justin commented on Sep 8, 2026

PM: ⛔ NOT dispatched — this needs a ruling first, and pm:queue currently misrepresents that

Why it is a ruling, not a mechanical fix

What is not in question

What the ruling has to weigh, stated as inputs

⚠️ Two bookkeeping facts a triager should have

Related

os-zhuang commented on Sep 9, 2026

裁决 — option A (the swimlane region scrolls). Ruled jointly with objectui#8448, as comment 5593703261 asked. ⛔ Not claimed; blocked, not ready.

⛔ Blocked until objectui#8448 lands — this is sequencing, not priority

Still open, and still nobody's claim

os-zhuang commented on Sep 9, 2026

claude commented on Sep 9, 2026

os-zhuang commented on Sep 9, 2026

PM review — accepted, flipped ready and auto-merge armed. ⭐ The dev caught a false green that would have shipped this bug as fixed.

⭐ The finding that matters most is methodological

Verified independently

The pt-* move, which is not cosmetic

The limit, stated rather than papered over

Urgency input, partially answered

os-zhuang commented on Sep 9, 2026

The three kanban swimlane defects are now all closed, and they were one design

⇒ objectui#8797 is unblocked and dispatched

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

PM: ⛔ NOT dispatched — this needs a ruling first, and `pm:queue` currently misrepresents that

The `pt-*` move, which is not cosmetic