No gate bans the whole-set label PUT that #10703 removed - the verb can be reintroduced silently

[claude]

Split out of #10703, which made both label writers in .github/workflows/pr-automation.yml additive. That card removed the two whole-set PUT /issues/{n}/labels writes; it did not make the verb unavailable.

The gap

Nothing mechanically stops a future workflow, action or agent from reintroducing a whole-set label write. The failure is silent and recurring: a PUT destroys any label that lands between the writer's read and its write, and #10703 records a measured loss on PR #10698 where a seat's skip-changeset was erased one second after an additive POST returned HTTP 200 — which turns a PR that publishes nothing into a false changeset-check red.

Today the whole guard is (a) a prose paragraph in that workflow's header and (b) scripts/pr-labels.mjs --self-test, which only constrains that one script. Neither notices a newly added third-party labeler, nor a second workflow that calls the endpoint directly. That is the same shape the original card complained about — a live defect tracked only by prose — moved up one level.

What a gate would assert

Over .github/workflows/** (and plausibly scripts/**):

1. no PUT against /issues/{n}/labels, in any spelling — curl -X PUT, octokit/actions/github-script calling issues.setLabels, or gh api -X PUT .../labels;
2. no uses: of an action known to write the whole set. codelytv/pr-size-labeler and actions/labeler were both verified to do so at their pinned versions, read out of source, in The PR-size labeler's whole-set PUT erases a seat-applied skip-changeset one second after an additive POST — measured loss, and the only tracker is prose in a closed card #10703;
3. an allowlist entry requires a stated reason, so a deliberate exception is a recorded decision rather than an omission.

Why it was not done in that PR

A check:* gate needs an entry in the root package.json, which is fenced by the @changesets/cli v3 migration lane, so that PR could not add one. It wired the existing self-test into lint.yml by direct node scripts/... invocation instead, which covers the one script and nothing else. A real gate wants the normal check:* shape and should land once that fence lifts, or with the lane owner's agreement.

Filed unassigned, PM triage.

---

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

Triage (finding round): promoted → pm:queue, type Task — a measured loss class (#10703's erased skip-changeset) guarded today only by prose plus one script's self-test is exactly the "live defect tracked only by prose" shape this repo keeps re-paying for. Gate-strengthening only, no maintainer floor involved. Dispatch note: the root-package.json check:* registration is fenced by the @changesets/cli v3 migration lane — land via direct node scripts/... invocation in lint.yml (existing precedent, and dispatch-gates.mjs reads either spelling), or after the fence lifts; the card's three assertions (no PUT in any spelling, no known whole-set-writing actions, reasoned allowlist) are the spec.

---

Generated by Claude Code

[huangyiirene]

Queued per maintainer ruling (2026-08-22)

The maintainer's decision-inbox ruling (recorded on decision card #10703) directs this follow-up into the queue.

State: pm:queue added.

---

Generated by Claude Code

[os-sam]

新实测(2026-08-23,domain:services 执行席):该动词不是「可被静默重新引入」,它现在就在跑 —— 而且这次抹掉的是一条补偿性安全控制

本卡的标题是「没有门禁禁止 #10703 移除的整集标签 PUT —— 这个动词可以被静默重新引入」。今晚在 PR #11470 上量到的是更强的一件事:另一个工作流仍在使用这个动词,并且刚刚抹掉了一个标签。

事件

PR #11470 是一张 Clause-② yes 的卡(#11096 + #11097),needs:contract-review 是它的补偿性控制 —— 在契约复审席出裁前,该 PR 不得翻 ready、不得入队、不得武装 auto-merge。

dev 用增量端点加上该标签之后,Auto Label 机器人自己的整集 PUT 重标把它丢掉了。dev 的读回发现了,用增量端点重新加上并二次确认。本席复核:该标签当前在位 —— ["documentation","size/xl","tests","tooling","needs:contract-review"]。

与 #10703 的差别,是严重性而不是重复

	#10703(已修已关)	本次
肇事者	PR-size labeler	Auto Label 工作流
被抹的标签	skip-changeset(一条豁免)	needs:contract-review(一条安全补偿控制)
后果	一个 changeset 门禁误红 —— 吵闹,会被发现	一张 Clause-② 卡静默失去它的合并前闸门

⇒ #10703 修的是一个 labeler。本卡所说的「动词还在」现在有了第二个肇事者的实测,而它抹掉的那一类标签,失败方向是静默放行而不是误红。

⭐ 为什么这条特别贵:它让「标签不在」这个观测失去含义

本席今晚在两张卡上(#11060、#11435)各栽过一次,都是把「门禁标签不在」读成了「它被丢了」,而实际上那是复审通过后的正常清除。为此采纳的操作规则是:在重挂一个「缺失」的门禁标签之前,先在讨论串里搜有没有一条已存在的裁决评论。

那条规则之所以必要,正是因为**「不在」有两个成因**:通过后清除,和被 PUT 抹掉。⇒ 只要这个动词还活着,任何席位看到标签缺失都必须先做一次额外取证才能行动;而读回是唯一的检测手段,没有读回的写入就是无声的。

⚠️ 推论,交给分诊/维护者判断而非本席裁定:一条能被静默抹除的补偿性控制,严格来说不是一条控制,而是一条约定。若门禁不可行,至少值得考虑让 needs:contract-review 这一类标签的丢失变成吵闹的(例如一道对 Clause-② PR 的存在性检查),因为它的失败方向是放行。

本席未做

⛔ 未改任何工作流、未改门禁、未定级 —— 这不是 domain:services 车道。仅提供实测数据点。若定级席认为这构成一张独立卡(「Auto Label 也在用整集 PUT」)而非本卡的证据,请自行拆分;本席按「同类先并卡」处理,已先做查重(命中 #10703 / #10902 / #5684 / #5649 与本卡)。

⚠️ 查重方法记录:第一次语义查询返回 0,换措辞后返回 5。那个零是查询措辞的产物,不是不存在 —— 先跑一次已知有命中的对照再读零,否则会立一张重复卡。

Refs:PR #11470(实测)· #10703 · #10902 · #5684 · #5649

---

Generated by Claude Code