[finding] MCP `list_issues` by a SINGLE label omitted a card carrying that label (objectui#7780 with `pm:retriage`, 2026-09-07) — the second facet of the labels-array reading, moved from objectui#7582

[os-musk]

Moved from objectui#7582 by the domain:skills execution seat (session session_018dxq7YqsLDMeZDZ5AzsgJX, os-musk, 2026-09-07T15:0xZ), because the fix lands in this repo: objectui carries no PM references tree (measured by the devx@objectui seat, objectui#7582 comment 5558315009 — no .claude/skills/pm-dispatch/ there), and the ledger for PM-side platform facts is .claude/skills/pm-dispatch/references/platform-readings.md here. Triage confirmed the lane as domain:skills and handed the grade to this seat (objectui#7582 comment 5572085122). Self-triaged at filing: priority:p3 · Task · pm:queue. The source card is closed as moved.

Facet 1 — already on the ledger (nothing to do)

objectui#7582's original reading — mcp__github__list_issues treats its labels array as OR, a two-label population query returning 147 where the intersection is 32, with no warning — is carried on main at platform-readings.md line 233: 「MCP list_issues 的 labels 数组是并集:多标签 totalCount 是析取的规模,恒 ≥ 各单标签。」 (landed from objectstack#15647, the objectstack twin). The workaround the card recorded (enumerate on the more selective single label, verify completeness by hasNextPage: false and rows == totalCount, intersect client-side) is the seat's practice this shift.

Facet 2 — NOT on the ledger, one specimen, needs a re-measure before it is written

Triage's observation on objectui#7582 (5572085122), verbatim: 「本席在本轮实测到该工具按单标签列举也会漏——objectui#7780 当时带着 pm:retriage,却没有出现在按该标签的列举里。⇒ 平台读数文件里这一条应当同时记下两个失效面(OR 语义、以及单标签列举的漏项),否则下一个读者会以为单标签是安全的。」

That is n=1, taken by another seat, and it contradicts the completeness check the facet-1 workaround relies on (rows == totalCount on a single label). ⇒ Before any line is written: re-measure a single-label list_issues against a control read (search_issues with label: qualifiers, or REST GET /issues?labels=X where a session has REST) on a label with a known member — one omission reproduced with hasNextPage: false and rows == totalCount is the reading; a non-reproduction is reported as such and the card closes with the reading, ⛔ not with a line.

Acceptance

• Re-measurement recorded on this card (population, control, result, UTC).
• If reproduced: ONE line in references/platform-readings.md (≤120 bytes, no issue numbers, fact only) stating that a single-label listing can omit a member and naming the cross-check; the ledger sits at 395/395 after PR docs(pm-skill): the sixth readings increment — seven measured platform facts, ceiling 388 → 395 (ruled) #16615, so it lands as the seventh readings increment under the standing one-file exception (ruledRaises record, counts in the ACCEPT) — fold with any other pending readings candidate the seat names at claim time.
• If not reproduced: the card closes with the negative reading and its control quoted.
• Governed (.claude/**) ⇒ draft PR, in-seat review, os-zhuang + hotlong, needs-user-decision + 速读 at ACCEPT.

Dedup

Ledger grep on main for the OR fact: line 233 (facet 1). Ledger grep for a single-label omission: none. Cards: objectstack#15647 (closed, facet 1's carrier), objectui#7582 (closed as moved), #16566 (closed, the truncation facet — a different defect: a full first page, not an omission inside a page). ⛔ Not upgraded to exhaustive.

Refs: objectui#7582 · objectstack#15647 · objectui#7780 (the specimen).

[os-musk]

Rider for the seventh readings increment, recorded here because this card is its queued carrier (skills seat, session session_018dxq7YqsLDMeZDZ5AzsgJX, 2026-09-07T15:1xZ) — one line in references/platform-readings.md (≤120 bytes, fact only) if it deduplicates against the ledger, counted in the ACCEPT's candidate/landed/already-present/refused tally:

• Container fact, measured three times today by two devs and the seat: pnpm check:pm-dispatch-gates (the dispatch-gates --self-test, ~1534 cases) needs about 13 minutes and cannot complete inside this container's 600 s per-command foreground cap; a plain foreground run times out (exit 124) with no verdict and reads like a hang. The case that catches a no-path-population contradiction sits near the end, so a 540 s partial run is NOT a reading of it (PR pm gates: refuse a widening diff whose claim declares Clause-②: no (the mechanical half of the directional ruling) #16604 patch round 2 was exactly that). Working technique: start it detached with output redirected to a file and block on the PID across foreground calls (tail --pid), or read the file at report time and mark NOT MEASURED if the verdict line is absent.

---

Generated by Claude Code

[os-musk]

Seat rider — readings for the seventh increment, taken this shift (skills seat, session session_018dxq7YqsLDMeZDZ5AzsgJX), 2026-09-07T15:38Z. Each n is as stated; none is written into platform-readings.md yet; this card's flight re-measures where a re-measure is possible.

1. Re-measure of this card's own n=1. At 15:38Z objectui#7780 no longer carries pm:retriage (its labels now: enhancement, pm:queue, finding, priority:p3, domain:spec), so the 2026-09-07 omission cannot be re-run against the same card. list_issues objectui OPEN labels: [pm:retriage] returns 4 with totalCount 4 (finding: GET /api/v1/meta/diagnostics reports 94/94 registry entries INVALID — the platform's own __search column carries a key FieldSchema rejects, plus a missing config #7561, chore(qa): drop the obsolete stale-prose NOTE from records-forms.action-location-matrix once PR #7540 lands #7547, pm-dispatch SKILL: the file-at-destination ruling (#7165) puts target:v17 cards into cloud, which the 发版板 section says can never happen — a live v17 card was invisible to both prescribed queries for ~10h #7493, [approvals] Point the account app's Approvals nav at the inbox component; contribute a Setup inbox entry; document mounting the inbox in business apps #7234). The flight re-measures cross-channel: the same population via search_issues (repo:objectstack-ai/objectui is:open label:pm:retriage) against list_issues; a card present in one and absent from the other is the reading; equal sets are a null result for that instant, not a refutation.
2. n=1 (PR skills(pm-dispatch): the Thread-read: claim field with its H50 patrol row, and the carried-assertion rule #16597). An approved, green, mergeable_state: clean PR whose auto-merge was armed at 12:05Z was re-folded by a push at ~14:4xZ, read green from 14:59Z, and showed no queue ref through 15:20Z; one re-send of enable_pr_auto_merge (SQUASH) at 15:21Z produced refs/heads/gh-readonly-queue/main/pr-16597-… by 15:23Z. Candidate line: a push to an armed PR's head can drop the arm with no field saying so — re-send after a re-fold, then probe the queue ref.
3. n=1 (PR pm gates: refuse a widening diff whose claim declares Clause-②: no (the mechanical half of the directional ruling) #16604). update_pull_request draft:false at 15:17Z, then enable_pr_auto_merge SQUASH at 15:19Z on an already-green, clean PR; the queue ref was present at 15:23Z (≤ 4 min).
4. n=2 (PR pm gates: refuse a widening diff whose claim declares Clause-②: no (the mechanical half of the directional ruling) #16604, PR skills(pm-dispatch): the Thread-read: claim field with its H50 patrol row, and the carried-assertion rule #16597). enable_pr_auto_merge on a PR already reading mergeable_state: clean succeeded (the "Auto-merge enabled" reply with the empty method / enabled at fields already on the ledger), contrary to the tool description's "fails gracefully if the PR is already mergeable (clean status)".
5. Carried, unverified by the seat (flight K's report 5572694127 on [finding] Three merged ADRs still say "Proposed — awaiting the maintainer's hand-merge, which is itself the acceptance act" — a sentence their own presence on main disproves, and which seats read as a gate #15453): issue_read get_labels answered "Could not resolve to an Issue with the number of 16647" for a PR number, and search_pull_requests returned the PR's labels on the same channel — the ledger already carries the first half; the second half is the candidate.

Counts and timestamps in 1–4 are the seat's own readings; 5 is the dev's, marked as such.

---

Generated by Claude Code

[os-musk]

Seat rider, one more reading for the seventh increment (skills seat, session session_018dxq7YqsLDMeZDZ5AzsgJX, 2026-09-07T23:46Z), n=1, not yet on the ledger:

6. enable_pr_auto_merge on PR fix(pm): check-clause2-carriers names the board's SOURCE, answers --help, and refuses an argument it does not honour #16699 (ready, all 37 check runs complete) with mergeMethod: SQUASH answered Auto-merge enabled … (method: MERGE, enabled at 2026-09-07T23:46:12Z) — the reply's method field read MERGE for a SQUASH request, and this time the two fields were populated where the four earlier calls today (PRs pm gates: refuse a widening diff whose claim declares Clause-②: no (the mechanical half of the directional ruling) #16604, skills(pm-dispatch): the Thread-read: claim field with its H50 patrol row, and the carried-assertion rule #16597 ×2, finding: serve.ts's cloud-connected marketplace arm can silently replace a host config's own marketplace plugins #8357) returned them empty. Read as: the reply's method is not the request's, and the merge queue's configured method decides what lands (every queue landing this shift squashed to one commit). The queue-ref probe is the effect reading either way. To be re-measured by the flight before it is written.

---

Generated by Claude Code