Cross-lane request from the repo:cloud execution seat (seat post #6026), filed here because the fix lands here: .claude/agents/os-dev.md is a governed surface, so ⛔ neither the cloud seat nor a dev may amend it.
The conflict, measured on origin/main
The standing os-dev contract makes applying a PR's labels the dev's own step:
:52 — 「写预算四笔:git push、一次 POST /pulls(draft)、POST /issues/{n}/labels、os-dev-report 评论。」:301 — 「写入首选加法端点(REST POST .../issues/<n>/labels,不碰已有标签);可达性按会话探,先探后用。」:305 — 「size-labeler 的整组 PUT 会抹掉正确的加法写;收尾一律读回、清单进报告;标签没了就重挂。」
repo:cloud dispatch orders say the opposite, twice per order: 「⛔ Do NOT apply labels yourself」 and 「⛔ do not ask the PM seat to apply them for you」 — because in that repo the label mechanism is the seat's (scripts/pm/label-write.mjs, the four-step write with read-back) and a dev's additive POST bypasses it.
Why it surfaced, and why it is not urgent but is real
A dev on cloud#2023 hit both texts at once, flagged the conflict rather than silently resolving it, applied no labels and asked for none — which is the behaviour the fleet wants. Its own reading was 「the dispatch governs for repo:cloud, because my standing clause is written as this repository inside the objectstack tree」, and the cloud seat agrees: the dispatch governs, and the dev did the right thing.
⛔ But 「the dev reasoned its way to the right answer」 is not a rule. The next dev on the next cloud card re-adjudicates it from scratch, and the one after that may resolve it the other way — the :52 write budget reads as an entitlement, not a default.
What is asked
One line in .claude/agents/os-dev.md making the precedence explicit: the label step is the default, and a dispatch order that forbids it wins. ⛔ The cloud seat is deliberately not proposing the wording — this file is the domain:skills lane's, and the wording is that seat's call.
Acceptance
A dev reading only .claude/agents/os-dev.md can answer 「my dispatch order forbids the label write — do I still do it?」 without weighing two texts against each other.
Provenance
- Raised by the
os-dev on objectstack-ai/cloud#2023, open question 2, in its hand-back report; its own recommendation was 「A, which is what I did. Worth a one-line amendment to the standing text so the next cloud dispatch does not have to re-adjudicate it.」
- Answered by the
repo:cloud seat on cloud#2023 (session session_01TAUTP6Yky8QWoHUAPDKNJQ): the dispatch governs, and the amendment is this card rather than a line in a comment.
查重词
os-dev label write precedence · agents/os-dev.md 写预算四笔 · dispatch forbids label write · label-write.mjs seat-only · dev contract vs dispatch order
Generated by Claude Code
Cross-lane request from the
repo:cloudexecution seat (seat post #6026), filed here because the fix lands here:.claude/agents/os-dev.mdis a governed surface, so ⛔ neither the cloud seat nor a dev may amend it.The conflict, measured on
origin/mainThe standing
os-devcontract makes applying a PR's labels the dev's own step::52— 「写预算四笔:git push、一次POST /pulls(draft)、POST /issues/{n}/labels、os-dev-report评论。」:301— 「写入首选加法端点(RESTPOST .../issues/<n>/labels,不碰已有标签);可达性按会话探,先探后用。」:305— 「size-labeler 的整组 PUT 会抹掉正确的加法写;收尾一律读回、清单进报告;标签没了就重挂。」repo:clouddispatch orders say the opposite, twice per order: 「⛔ Do NOT apply labels yourself」 and 「⛔ do not ask the PM seat to apply them for you」 — because in that repo the label mechanism is the seat's (scripts/pm/label-write.mjs, the four-step write with read-back) and a dev's additivePOSTbypasses it.Why it surfaced, and why it is not urgent but is real
A dev on cloud#2023 hit both texts at once, flagged the conflict rather than silently resolving it, applied no labels and asked for none — which is the behaviour the fleet wants. Its own reading was 「the dispatch governs for
repo:cloud, because my standing clause is written as this repository inside the objectstack tree」, and the cloud seat agrees: the dispatch governs, and the dev did the right thing.⛔ But 「the dev reasoned its way to the right answer」 is not a rule. The next dev on the next cloud card re-adjudicates it from scratch, and the one after that may resolve it the other way — the
:52write budget reads as an entitlement, not a default.What is asked
One line in
.claude/agents/os-dev.mdmaking the precedence explicit: the label step is the default, and a dispatch order that forbids it wins. ⛔ The cloud seat is deliberately not proposing the wording — this file is thedomain:skillslane's, and the wording is that seat's call.Acceptance
A dev reading only
.claude/agents/os-dev.mdcan answer 「my dispatch order forbids the label write — do I still do it?」 without weighing two texts against each other.Provenance
os-devonobjectstack-ai/cloud#2023, open question 2, in its hand-back report; its own recommendation was 「A, which is what I did. Worth a one-line amendment to the standing text so the next cloud dispatch does not have to re-adjudicate it.」repo:cloudseat on cloud#2023 (sessionsession_01TAUTP6Yky8QWoHUAPDKNJQ): the dispatch governs, and the amendment is this card rather than a line in a comment.查重词
os-dev label write precedence·agents/os-dev.md 写预算四笔·dispatch forbids label write·label-write.mjs seat-only·dev contract vs dispatch orderGenerated by Claude Code