docs(pm-dispatch): re-key platform-readings' GraphQL-only list now the ccr routes are counted (#18396)

Fixes #18361

`references/platform-readings.md` only, in place at **466 / 466 lines**
(ratchet ceiling, headroom 0). **Four** rows re-keyed by judgment; no
row added, none removed, no re-wrap, every rewritten line under the
gate's 120-byte cap.

Three rows landed in the first commit (`b0c55121`). The fourth arrived
with the seat's review (comment 5694684277 on #18361), which widened
this claim's file surface by one row: a fact table does not carry a row
whose job is to say the row above it is false, so the row above is
re-keyed in place instead — second commit `a7026a35`, no force-push, no
rebase.

Rows are located by CONTENT, not by the card's line numbers: the card
was filed against `1411cf2c` and the file has landed twice since
(`b57671ed` #18359 at 04:18Z, `05f1cdd6` #18363 at 06:40Z), so :134 /
:143 / :57 have drifted.

## Row 1 — the GraphQL-only membership row (line 134 on this branch)

Landing point: the row directly under 「GraphQL 池 5000/时,只留给没有 REST
对应物的几件。」

before (verbatim, 113 B):

```
- 那几件 = draft 翻转、auto-merge 挂载、语义 `/search/*`、Projects field_values、`issue transfer`。
```

after (verbatim, 118 B):

```
- 那几件 = `rest-channel.md`〈不可迁移〉那三件;draft 翻转与 auto-merge 挂载有 ccr 路、不在内。
```

## Row 2 — the queue-repo landing row (line 142), widened into scope by
the seat's review

Landing point: the row directly under 「红窗调度:守候只给上面那几件 GraphQL-only 的,⛔
其余一切不为配额空等。」

before (verbatim, 107 B):

```
- 走队列的仓落地必经 auto-merge ⇒ 红窗里无退路;直合仓有,合并本身有 REST 端点。
```

after (verbatim, 118 B):

```
- 走队列的仓落地仍必经 auto-merge,红窗里照样走 ccr REST 挂载;直合仓合并本身有 REST 端点。
```

The row's premise — that arming is GraphQL-only — is the same one the
card retires, so the row is retired with it. What survives is what is
still true: a queue repo's landing still goes through auto-merge (the
queue is not bypassed), the mount in a red window rides the ccr REST
route, and the direct-merge half keeps its REST endpoint.

## Row 3 — the red-window stand-down row (line 143)

Landing point: the row directly under row 2.

before (verbatim, 70 B):

```
- MCP 侧限流下,draft 翻转与 auto-merge 挂载整窗不可得。
```

after (verbatim, 89 B):

```
- 红窗里 draft 翻转与 auto-merge 挂载照常走 ccr REST,⛔ 不为它们守候。
```

The first commit ended this row with 「⇒ 上条无退路不成立」, a clause whose only
job was to void the row above. The review rejected that shape —
correctly: a reader of a fact table should not have to hold two rows in
mind to get one fact. With row 2 re-keyed, the clause has nothing to do
and is gone.

## Row 4 — the echo row (line 57), carrying comment 5693336603's
mechanism

Landing point: the row directly under 「squash 的 committer date
是入队时刻,快进不改 ⇒ 落地时刻读 merged_at/merged,不读 git log。」

before (verbatim, 114 B):

```
- 回显两向不可靠,空回显不等于未挂上 ⇒ ⛔ 不拿它当任何方向的证据、不为它空转。
```

after (verbatim, 115 B):

```
- 回显两向不可靠:全绿加 `clean` 即吞进队列不存记录 ⇒ 空回显是成功常态,⛔ 不空转。
```

The byte WAS there, so the note is carried here rather than left on the
card: the mechanism (all checks green plus `mergeable_state: clean` is
consumed straight into the queue and stores no record, so an empty echo
is the normal echo of SUCCESS) replaces two clauses the row no longer
has to spend bytes on. `空回显不等于未挂上` is subsumed by the stronger
`空回显是成功常态`, and `⛔ 不拿它当任何方向的证据` follows from `回显两向不可靠` in the same
sentence. The note's third half — never re-arm on a NULL alone — is NOT
restated: the file already carries it at 「⛔ 永不据它判没挂上而重挂 —— 重挂踢队重排。」, and
a second copy is what this card exists to remove.

## The card's question: mirror rest-channel's 「不可迁移 —— 只有这三件」, or point
at it

**Point at it.** Three reasons, in descending authority:

1. A maintainer ruling already assigns ownership. The 2026-09-01 batch
(总监批 #22, quoted in `scripts/pm/check-skill-line-ratchet.mjs`'s ceiling
comment for `rest-channel.md`) reads, verbatim and untranslated: 「**C
同批**:退役 L58 对红窗常设规则的复述 —— 内容归属裁定:**红窗规则由 `platform-readings.md`
配额段独家持有**,`rest-channel.md` 只留指路」. The split it draws is symmetric:
red-window POLICY is this file's, per-operation CHANNEL MAPPING is
rest-channel's. Which operations have no REST twin is channel mapping.
2. This file already says so in its own voice, one row below the one
being re-keyed: 「逐操作通道归属、写侧配方与队列路由三读法见 rest-channel.md,⛔ 不在本表复述。」 The
row this PR re-keys was the one row in breach of its own neighbour.
3. The drift is the evidence. rest-channel's list stayed correct across
lock 1; the mirror here went stale and stood a seat down for two
operations that had a route the whole time. A mirror re-opens exactly
that channel. rest-channel's heading already carries the return pointer
(「红窗守候规则住 platform-readings.md 配额段」), so after this PR each fact has
exactly one home and each home points at the other.

What is NOT delegated is the JUDGMENT the card asked for: the two
operations that left the list are named here, in the negative, because a
seat that remembers the old list needs the deletion stated, not merely
absent. The three that stay are not re-listed.

⛔ `rest-channel.md` is not touched by this PR. Its rows 46 and 50 are
already correct.

## Acceptance notes

- Adjacent rows read and left standing because they stay TRUE under the
re-key: 「红窗调度:守候只给上面那几件 GraphQL-only 的…」 (line 141) becomes
automatically correct once line 134 points at the three; and
「被挡住的翻转是在等窗口,不是关于该 PR 的信号…」 (line 144) survives, because a flip can
still be blocked by the session gate (`GitHub access is not enabled for
this session`) or by REST core, so its prohibition still has a referent.
- noted, not filed: 「走队列的仓落地仍必经 auto-merge」 still reads as if arming
were the only landing path. It is, on this repo, under Prime Directive
14's governed-surface carve-out and the queue rules — but the row does
not say which of those makes it so. 承接者: none; recorded here so the next
author of this block knows it was read and judged, not missed.
- Out-of-scope finding reported to the seat (class b, contract
violation): the spec seat's 2026-09-16T06:19Z measurement (seat post
#6017, comment 5692971090) — no `enqueued` event on this repo's
`/issues/N/timeline`, the queue ref answering BUILD rather than
membership, and `auto_merge` cleared on enqueue — conflicts with rows
10–12 of this same file, which make the timeline event the decisive
membership reading. Out of this card's scope, untouched here. Row 4's
rewrite was written to be consistent with it (a consumed request stores
no record), not against it.

## Gates

Targeted set for a `.claude/skills/**` docs-only diff, re-derived from
the actual change at the new head with `node
scripts/pm/dispatch-gates.mjs --commands` (no paths) and reconciled with
`--ran`: 16 derived / 16 run / 0 NOT-MEASURED / 0 UNRUN, the same 16 as
the first round. Exit codes captured to a file before reading, never
across a pipe. Ratchet at the new head: 466 lines, ceiling 466, headroom
0. Per-command results are in the report comments on #18361.

`skip-changeset`: nothing published moves — `.claude/**` is not in any
package's `files[]`, it is the fast track, not a measurement.

## 维护者速读(草稿)

**改了什么** —— 只动 `references/platform-readings.md` 四行,行数 466 → 466。一是
GraphQL-only 清单那行:不再自己列五件,改成指向 `rest-channel.md`〈不可迁移〉的三件,并写明 draft 翻转与
auto-merge 挂载有 ccr 路、不在其内。二是「走队列的仓落地必经 auto-merge ⇒ 红窗里无退路」那行:改成落地仍必经
auto-merge、红窗里照样走 ccr REST 挂载,直合仓那半保留。三是红窗那行:两件在限流窗里照常走 ccr
REST,别为它们守候。四是回显那行:补进「全绿加 clean 即被吞进队列、不存记录,所以空回显是成功的常态」这条机制。

**为什么改** —— 锁 1 之后 ccr 路是这两件操作的唯一通道,而清单还把它们记作没有 REST
对应物。后果不是措辞问题:读到红窗那几行的席位会白等一个根本不用等的窗口。清单归属有 2026-09-01
的裁定在先(红窗规则归本表独家,通道归属归
`rest-channel.md`),所以这次是把重复的那份退役成指路,不是再抄一遍。第二行是席位复核时扩进来的:原先我只在下一行写「上条无退路不成立」,事实表不该有一行专门宣布上一行为假,现在把上一行本身改对了。

**风险与代价(含回滚)** —— 风险有两处。① 席位要判某个操作是不是 GraphQL-only
时,多读一个文件(`rest-channel.md`,82 行、零配额);换来的是清单只有一份、不会再各自漂移。②
这四行都在同一段里,措辞收紧后相邻行的语气略有重叠(红窗里走 ccr REST
这件事在两行都出现一次),是刻意的:一行讲落地路径,一行讲要不要守候。回滚代价极低:四行就地改写,两个提交都可 `git
revert`,棘轮读数不变。

**席位意见** ——

**你要做的** —— 若同意「指路而不镜像」这一判断,按 references
档在席复核后落地即可;若更希望本表继续自列三件(以红窗里少读一个文件换一份可能再漂的副本),请在此说明,我改回列举形。


---
_Generated by [Claude Code](https://claude.ai/code)_

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-elon-musk

.claude/skills/pm-dispatch/references/platform-readings.md

@@ -54,7 +54,7 @@
 - `auto_merge_enabled` webhook 载荷同报 `merge` ⇒ 三个载体一致也不作数,判据是落地提交的父数。
 - squash 落地重写署名 trailer:作者行按提交作者身份改拼,`Claude-Session:` 原样存活。
 - squash 的 committer date 是入队时刻,快进不改 ⇒ 落地时刻读 `merged_at`/`merged`,不读 `git log`。
-- 回显两向不可靠,空回显不等于未挂上 ⇒ ⛔ 不拿它当任何方向的证据、不为它空转。
+- 回显两向不可靠:全绿加 `clean` 即吞进队列不存记录 ⇒ 空回显是成功常态,⛔ 不空转。
 - 回读 `auto_merge` 非空本接口给不了:`pull_request_read` 与 `fields` 枚举都无该成员。
 - 效果读数 = 下列阳性探针、timeline 入队事件、最终落地;队列分支仅在场时算。
 - 队列 ref 答 BUILD 不答成员资格:`gh-readonly-queue/*` 只在存在时有意义,即有 build 在跑。
@@ -131,16 +131,16 @@
 - 用户类写绑作者:封号则其评论与卡按作者 404,标签/状态/标题/正文存活。
 - ⇒ 耐久算按令牌类重算,⛔ 不假定署名恒 `claude[bot]`;用户类下请 PR 作者复审回 422。
 - GraphQL 池 5000/时,只留给没有 REST 对应物的几件。
-- 那几件 = draft 翻转、auto-merge 挂载、语义 `/search/*`、Projects field_values、`issue transfer`。
+- 那几件 = `rest-channel.md`〈不可迁移〉那三件;draft 翻转与 auto-merge 挂载有 ccr 路、不在内。
 - 逐操作通道归属、写侧配方与队列路由三读法见 `rest-channel.md`,⛔ 不在本表复述。
 - MCP list/search 家族整个走 GraphQL 稀缺池,`issue_write` 连查找半边都吃。
 - 配额红时认领类动作排队,评论走 REST 桶先行把结论发出去。
 - `gh` CLI 的动词按传输分两桶,池枯竭时只死一半。
 - porcelain 家族(`gh issue view` / `gh pr list`)与 `gh pr create` 走 GraphQL,当场回限流。
 - 同批事实改走 `gh api` 的 REST 路径照常返回,含开 draft PR;容器无 `gh`,本条只对本机席适用。
 - 红窗调度:守候只给上面那几件 GraphQL-only 的,⛔ 其余一切不为配额空等。
-- 走队列的仓落地必经 auto-merge ⇒ 红窗里无退路;直合仓有,合并本身有 REST 端点。
-- MCP 侧限流下,draft 翻转与 auto-merge 挂载整窗不可得。
+- 走队列的仓落地仍必经 auto-merge,红窗里照样走 ccr REST 挂载;直合仓合并本身有 REST 端点。
+- 红窗里 draft 翻转与 auto-merge 挂载照常走 ccr REST,⛔ 不为它们守候。
 - 被挡住的翻转是在等窗口,不是关于该 PR 的信号 ⇒ ⛔ 不据它重挂、不据它改判状态。
 - 其余动作(评论、标签、请审、读、timeline)照常走 REST。
 - 报文里的 user ID 只是报文:据它推 MCP 池跨席共享与本节首条冲突,⛔ 未裁不写成事实。