[objectstack-fleet]

Fixes #20048
Clause-②: no

What this changes

The maintainer answered the card's open choice in the skills seat's session, verbatim: 「B:走中继落地(推荐)」. The seat's landing (ready flip + auto-merge arm, and their reverse) now goes through the fleet-write relay as objectstack-fleet[bot]. The two allow-listed ccr commands are no longer a landing route. A classifier denial during landing still means: stop, report to the maintainer, record the command and the reason on the card. The text now says the fallback does not exist: never respell, never go back to ccr.

Text only, in four ratcheted files, line-neutral in each (in-place rewrites, no re-wrap, no ceiling touched):

file	before	after	ceiling
.claude/skills/pm-dispatch/SKILL.md	319	319	319
.claude/skills/pm-dispatch/references/landing-operations.md	101	101	101
.claude/skills/pm-dispatch/references/rest-channel.md	82	82	82
.claude/skills/pm-dispatch/references/platform-readings.md	469	469	469

Every ccr hit under .claude (git grep -n ccr -- .claude), decided one by one

hit	decision
landing-operations.md:51 ccr pair is the only landing route	changed: relay ops pr_ready + automerge_enable, spelling pointed to rest-channel.md
landing-operations.md:54 "never switch to the relay"	changed: stop, report and record still hold; "never respell, never fall back to ccr"
SKILL.md:201 ready/draft goes the ccr way	changed: ready/draft goes through the relay ops; the endpoint pointer now names rest-channel (where the spelling lives)
rest-channel.md:17 "dispatch.mjs has no allow row"	changed: batch writes still go through the per-op tools; calling dispatch.mjs directly is for landing only
rest-channel.md:51 ccr ready flip	changed: the relay spelling, with a note that with-fleet.sh --via dispatch carries the same ops
rest-channel.md:55 ccr auto-merge	changed: the actions-file shape, and the reverse ops pr_draft / automerge_disable marked as never called for real
rest-channel.md:56 ccr 422 on draft	changed: the fact is kept as a ccr reading and turned into an order rule. pr_ready goes first in the file. The executor stops at the first failure and does not try later actions (fleet-write/execute.mjs)
rest-channel.md:34 ccr review_threads read · :54 ccr resolve/unresolve	not changed: not a landing operation
platform-readings.md:48 "undraft single channel = ccr"	changed: undraft and arm go through the relay ops, with zero denials under auto mode. The ccr route with allow rows is still denied and is retired
platform-readings.md:49 "this route eats the session GraphQL pool"	changed "this route" to "the ccr route": the historical reading now names its subject
platform-readings.md:138 · :146 ccr as the draft-flip / arm route in the quota section	changed to the relay op
platform-readings.md:162 "ccr route 429 at full budget"	not changed: a dated reading of the ccr route, still true as history
platform-readings.md:435 content-based denial reading	changed: the [Self-Approval] fact is kept, and the ccr flip denial is added beside it ("ccr 翻转亦拒")
.claude/settings.json:61-66 ccr allow rows	not changed: the maintainer's surface. See the question below

landing-operations.md:53 (undraft hits 429, wait for resets at) does not name ccr and is left as it is. How a 429 surfaces under the relay has not been measured.

The relay spelling, measured (dry run only; nothing was sent, no real PR was landed)

node scripts/pm/fleet-write/dispatch.mjs --repo objectstack-ai/objectstack --actions-file land.json --dry-run with land.json = [{"op":"pr_ready","pull":20022},{"op":"automerge_enable","pull":20022}], exit 0:

fleet-write/dispatch: DRY RUN — nothing sent. This is the request POST /repos/objectstack-ai/objectstack/dispatches would carry:
{
  "event_type": "fleet-write",
  "client_payload": {
    "request_id": "fw-20260925T011802Z-630c75",
    "repo": "objectstack-ai/objectstack",
    "session": "session_01LNRg6FUMXYWgkAbDsfZpC8",
    "actions": [
      { "op": "pr_ready", "pull": 20022 },
      { "op": "automerge_enable", "pull": 20022 }
    ]
  }
}

bash scripts/pm/with-fleet.sh --via dispatch --repo objectstack-ai/objectstack --actions land.json --dry-run also exits 0. It prints with-fleet: transport dispatch — the actions file goes through the fleet-write relay as objectstack-fleet[bot] and hands the same payload to dispatch.mjs. Both spellings work. with-fleet.sh takes --actions, and dispatch.mjs takes --actions-file.

The ops exist in scripts/pm/fleet-write/ops.mjs: pr_ready / pr_draft (pull-requests) and automerge_enable / automerge_disable (contents), each with required: ['pull'], each one GraphQL mutation. The ✓ on the relay line rests on the card's reading: in the cli seat's session, under auto mode, the relay readied and armed three PRs with zero denials.

Deviation: the two allow rows are NOT in this PR

The dispatch asked for two allow rows in .claude/settings.json:

"Bash(node scripts/pm/fleet-write/dispatch.mjs *)",
"Bash(node --use-env-proxy scripts/pm/fleet-write/dispatch.mjs *)",

These would sit beside the post-stamped.mjs pair. The edit was denied by this session's auto-mode classifier, reason [Self-Modification]. It was not retried in any other form. The card's own acceptance note already puts a settings row on the maintainer's hand, so the two rows above are left for the maintainer to add. Without them, each relay landing call is judged by the classifier one by one. The card's reading is three passes in three calls. Note what the rows cover: dispatch.mjs * admits every op in the closed table, not only the four landing ops.

Question for the maintainer

• Should the six ccr allow rows (.claude/settings.json:61-66) be deleted now that the text retires the ccr pair? This PR leaves them in place, because that is your surface.

Gates (run on d32057c6)

node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack derived 22 commands. All 22 exit 0, plus pnpm check:pm-settings-deny-roster (exit 0). That makes 23 runs, and --ran reconciles them: "22 derived famil(ies) accounted for — 22 run, 0 NOT-MEASURED". Among them: check:pm-skill-ratchet, check:pm-skill-id-lint, check:skill-frame-sync, check:doc-authoring, check:pm-governed-merges, check:pm-governed-prose, check:pm-half-states, check:nul-bytes. check:doc-formula-expressions first exited 3 (PREREQUISITE NOT MET, formula not built). It exited 0 after turbo run build --filter=@objectstack/formula --filter=@objectstack/lint. check-governed-merges.mjs --test on the four paths reports GOVERNED — Tier S.

No changeset: .claude/** does not ship.

Acceptance notes

• scripts/pm/check-settings-deny-roster.mjs's header still says the ccr auto-merge route "already serves every real enqueue". That header comment is now stale. Nobody else is working on this file.
• platform-readings.md:48 no longer says "bare GraphQL refused". It referred to GraphQL mutations sent with the session's credentials. The relay sends the same mutations with the App token, so the line would now mislead.

维护者速读(草稿)

改了什么:PM 技能里「转 ready + 挂 auto-merge」的落地路,从 settings 放行清单里的 ccr 两条 curl 命令,改成 fleet-write 中继(以 objectstack-fleet 机器人身份写)。四个技能文件逐行原地改写,行数一行没加。

为什么改:auto 模式下,放行清单里的 ccr 命令照样被权限分类器拒绝,而旧文本又禁止改走中继。结果是席位一旦被拒,就完全没有落地路,已验收的 PR 只能等人手动落地。中继路在同样条件下三次零拒。你已选定方案 B:走中继落地。

风险与代价(含回滚):只改文字,不改代码,不加门禁。中继的反向两个 op(转回 draft、卸载 auto-merge)还没真实调用过,文中已标「未实调」。原计划加的两条 settings 放行行被本会话分类器以 Self-Modification 拒掉,本 PR 不含。回滚就是 revert 本 PR。

席位意见:

你要做的:① 在 .claude/settings.json 加上正文列出的两条 dispatch.mjs 放行行(可选;不加的话,每次中继落地都要逐次过分类器)。② 决定六条 ccr 放行行删不删。

---

Generated by Claude Code