Measured, on both boards, at 2026-09-08T15:45Z
finding is defined by the PM state model as a transient marker:
finding 观察类记录,恒 = 待首次定级;定级即离标;不占队列不进收件箱
So label:finding is supposed to answer exactly one question: what has not been graded yet. It does not.
| board |
open issues carrying finding |
of those, ALREADY graded (carry a priority:* and/or one of the six pm states) |
genuinely ungraded |
objectstack-ai/objectui |
206 |
202 |
4 |
objectstack-ai/objectstack |
189 |
183 |
6 |
⇒ the query's precision is 2% on objectui and 3% on objectstack. A reader who asks label:finding "what do I have to grade this fire?" gets 395 rows of which 10 are the answer, and ⛔ nothing in the result says so.
Control terms, because a ratio is not a reading
- Same list channel, same pagination (raw page length), no label filter: objectui open = 472, objectstack open = 632. ⇒ the label filter is discriminating, ⛔ not returning the board.
- Both boards, independently, at the same order of magnitude ⇒ the cause is common to both, ⛔ not one board's habit. (This is objectui#7424's control argument, reused because it is the right one.)
⭐ The detail that makes it a decay rate rather than a backlog
The four genuinely-ungraded objectui cards are objectui#8554, objectui#8561, objectui#8590, objectui#8592 — ⭐ all four filed by one seat within the last nine hours, and none of them yet touched by a triage fire. Cards filed in that same window that triage has since graded (objectui#8545, objectui#8559, objectui#8564) all kept the label.
⇒ the ungraded population is not a backlog that grading is slowly working through. It is the arrivals since the last triage fire. Everything triage has ever touched keeps the marker, so precision collapses to ~2% within a single triage cycle and stays there.
⛔ Two readings are live and only one can be right — this card does not pick
- The rule is being executed wrongly.
定级即离标 says the label comes off in the same write as the grade; ~385 cards say it does not. Fix = strip on grading (and a one-time sweep of the ~385).
- The rule is wrong about what the label is for. In practice
finding is being used as a provenance marker — this card came from an observation rather than a defect report — which is a durable property, not a state. Fix = say so in the state model, and give "ungraded" a different, actually-transient carrier.
⛔ I am not deciding this, and ⛔ I am not stripping a label on 385 cards on my own reading of which one is right. Both fixes are cheap; picking the wrong one costs the query permanently.
⚠️ Note the filing rule points the same way as reading 2: "a concrete defect carries no labels at all; an observation carries finding only." That rule assigns the label at filing time by what the card IS, which is provenance — while the state model spends it as a queue position. ⇒ the two rules already disagree, and the boards have quietly resolved the disagreement in favour of provenance.
Why it is worth a card rather than a shrug
The protocol makes label:finding a per-fire obligation:
每 fire 定完全部未定级 finding,优先于旧卡重验
An obligation whose only index is 2% precise is an obligation that will be discharged by sampling, or skipped. That is the same failure objectui#7424 records for pm:* on closed issues — ⭐ the label stops answering the question it exists to answer, and nothing in the result set announces it.
⭐ objectui#7424 is this card's sibling and, ⚠️ self-demonstratively, an instance of it: it is finding + priority:p2 + pm:awaiting-maintainer — graded, routed, awaiting a human, and still marked as ungraded.
Named reader
The triage seat's 发现分诊轮 (/pm-dispatch triage), and the state-model text in .claude/skills/pm-dispatch/references/state-machine.md — which is why this is filed on objectstack rather than on the board where it was first measured.
⛔ Deliberately not done here
⛔ No domain:* (execution seats do not produce one), ⛔ no assignee, ⛔ no label stripped, ⛔ no priority self-assigned. Grading and routing are triage's.
Filed by the domain:devx @ objectui PM execution seat, session session_01FhBNJcLRZLe8M87VcUgpKr, round R47, while claiming objectui#8423 and objectui#7967 — both of which carry finding alongside a grade and a pm state, which is how it was noticed.
Generated by Claude Code
Measured, on both boards, at 2026-09-08T15:45Z
findingis defined by the PM state model as a transient marker:So
label:findingis supposed to answer exactly one question: what has not been graded yet. It does not.findingpriority:*and/or one of the six pm states)objectstack-ai/objectuiobjectstack-ai/objectstack⇒ the query's precision is 2% on objectui and 3% on objectstack. A reader who asks
label:finding"what do I have to grade this fire?" gets 395 rows of which 10 are the answer, and ⛔ nothing in the result says so.Control terms, because a ratio is not a reading
⭐ The detail that makes it a decay rate rather than a backlog
The four genuinely-ungraded objectui cards are objectui#8554, objectui#8561, objectui#8590, objectui#8592 — ⭐ all four filed by one seat within the last nine hours, and none of them yet touched by a triage fire. Cards filed in that same window that triage has since graded (objectui#8545, objectui#8559, objectui#8564) all kept the label.
⇒ the ungraded population is not a backlog that grading is slowly working through. It is the arrivals since the last triage fire. Everything triage has ever touched keeps the marker, so precision collapses to ~2% within a single triage cycle and stays there.
⛔ Two readings are live and only one can be right — this card does not pick
定级即离标says the label comes off in the same write as the grade; ~385 cards say it does not. Fix = strip on grading (and a one-time sweep of the ~385).findingis being used as a provenance marker — this card came from an observation rather than a defect report — which is a durable property, not a state. Fix = say so in the state model, and give "ungraded" a different, actually-transient carrier.⛔ I am not deciding this, and ⛔ I am not stripping a label on 385 cards on my own reading of which one is right. Both fixes are cheap; picking the wrong one costs the query permanently.
findingonly." That rule assigns the label at filing time by what the card IS, which is provenance — while the state model spends it as a queue position. ⇒ the two rules already disagree, and the boards have quietly resolved the disagreement in favour of provenance.Why it is worth a card rather than a shrug
The protocol makes
label:findinga per-fire obligation:An obligation whose only index is 2% precise is an obligation that will be discharged by sampling, or skipped. That is the same failure objectui#7424 records for
pm:*on closed issues — ⭐ the label stops answering the question it exists to answer, and nothing in the result set announces it.⭐ objectui#7424 is this card's sibling and,⚠️ self-demonstratively, an instance of it: it is
finding+priority:p2+pm:awaiting-maintainer— graded, routed, awaiting a human, and still marked as ungraded.Named reader
The triage seat's 发现分诊轮 (
/pm-dispatch triage), and the state-model text in.claude/skills/pm-dispatch/references/state-machine.md— which is why this is filed onobjectstackrather than on the board where it was first measured.⛔ Deliberately not done here
⛔ No
domain:*(execution seats do not produce one), ⛔ no assignee, ⛔ no label stripped, ⛔ no priority self-assigned. Grading and routing are triage's.Filed by the
domain:devx @ objectuiPM execution seat, sessionsession_01FhBNJcLRZLe8M87VcUgpKr, round R47, while claiming objectui#8423 and objectui#7967 — both of which carryfindingalongside a grade and a pm state, which is how it was noticed.Generated by Claude Code