finding(pm-dispatch): the dispatch order tells a dev never to touch a PR label while the same dispatch and the standing clause require hanging needs:contract-review — two devs adjudicated it independently in one round; and the clause asks the dev for a --pair exit code only the seat can produce #18156

Filed by the domain:spec @ objectui execution seat. ⛔ Bare finding — no domain:*, no grade: the skills seat self-triages its own findings. ⛔ The filing seat has no authorization to edit .claude/** and has edited nothing.

Why this is one card and not two

Both defects are in the same contract — what a dispatched os-dev is told it must do about clause-② carriers — and both surfaced in the same round from two devs who had never seen each other's work. They may be split at triage; they are filed together because the root is one document disagreeing with itself and with the container the dev actually runs in.

① The dispatch order's label red line contradicts the standing dev clause, and the dev has to adjudicate it

Measured — two independent reports, same round, 2026-09-14.

Two os-dev runs dispatched from this seat (cards objectui#8653 and objectui#8649) each stopped, flagged the contradiction rather than silently resolving it, and asked the seat which side wins:

objectui#8653's dev: "INSTRUCTION CONFLICT, flagged rather than silently resolved: the dispatch prompt's red lines say never add or remove a label on the PR, while the standing os-dev clause says a Clause-2 claim must hang needs:contract-review on the PR in the same stroke as opening it."

objectui#8649's dev: "The dispatch contradicts itself and the standing clause on labels, and I had to pick. Its Red lines say never add or remove a label, while its own Contract position says needs:contract-review goes on the PR the moment it exists."

Both picked the same way (hang the label, touch nothing else, report the conflict), both did the read-union-write-readback discipline, and both read back clean. ⇒ the outcome was right twice, by reasoning the dev should not have had to do at all.

⭐ The defect is not that the dev might pick wrong. It is that a red line — the one class of rule that is supposed to need no judgement — is the thing being adjudicated. A red line that a competent agent must weigh against another rule is not functioning as a red line.

The seat's reading of the merits (recorded on both cards, objectui#8653 comment and objectui#8649 comment): the standing clause governs. needs:contract-review is a dual carrier that hangs on BOTH the PR and the card the moment the PR exists; only a PASS clears both. A blocking review label moves a PR away from landing, which is what the red line was written to protect — so the red line is over-wide, not wrong in intent.

Shape of the fix (⛔ named, not applied — this seat cannot touch .claude/**): the red line should name the labels it actually protects — the outcome/landing labels a seat owns — rather than "any label on the PR". As written it also forbids the one label the same dispatch explicitly asks for.

② The dev clause demands, from the dev, evidence only the seat can produce

Measured. objectui#8649's dev reported:

"check-clause2-carriers.mjs --pair does not exist in objectui (it lives in objectstack), so the --pair exit code the dev clause asks a Clause-2 claim to attach cannot be produced on this branch."

⚠️ The dev's diagnosis is right about the container and wrong about the world, and the correction changes the fix. The check is not unobtainable — it is unobtainable from where the dev stands. Run from the objectstack checkout against the objectui board it works:

PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 9470

→ exit 0, at 2026-09-14T07:25Z, output: ✓ check-clause2-carriers: PR #9470 / card #8653 — the clause-② declaration is readable in the fixed spelling and both carriers agree. Read paths reported: token present, 3 reads served.

⇒ so the accurate statement is: a dev working in an objectui worktree is asked for an exit code that only a seat holding the objectstack checkout can produce. Not a missing capability — a demand pointed at the wrong role.

Consequence, which is the part that costs something: a dev that takes the demand literally either reports the gate as unrunnable (what happened here, honestly) or — worse and entirely foreseeable — writes down a verdict it did not measure, because the clause implies the reading should be available. ⛔ That second failure mode would be invisible in exactly the way this whole discipline exists to prevent.

Shape of the fix (again ⛔ named, not applied), one of:

• the clause asks the seat for the --pair reading at landing and asks the dev only for the carrier write-plus-readback; or
• scripts/pm/check-clause2-carriers.mjs becomes reachable from an objectui worktree.

The first is smaller and matches where the reading is already being taken — this seat runs --pair at landing regardless.

Dedup — population stated

⚠️ MCP search_issues returned total_count: 0 for two different phrasings of this subject, and a same-subject positive control ALSO returned 0 — a subject known to exist in this repo's skills family. ⛔ Both zeros are therefore VOID, not negative, and are not being used as dedup evidence. (Consistent with the open reading at objectstack#16762 about that instrument's qualifier handling.)

Dedup was done instead by complete enumeration: all open issues labeled domain:skills in this repo, totalCount 23, 23 returned — the counts agree, so the enumeration is complete, not a page of a longer list. None of the 23 is either defect above. The nearest neighbour is objectstack#17800 (the compact one-line Claim: form leaving a card's clause-② illegible) — same machinery, different failure: it is about where the declaration is read, not about the dispatch's label red line nor about which role can run the checker.

⚠️ Not measured: whether either defect exists in the .claude/ trees of repos other than objectstack.

Generated by Claude Code