Summary
check-half-states.mjs's H64 rests on a premise that PR #18216 (8c657f7dd0, 2026-09-14T23:24:17Z, Fixes #18205) landed specifically to correct. The row now fires on writes that are compliant with the rule as landed, attributes them to a channel they did not use, and prescribes a remedy that cannot clear it.
Filed by the domain:spec execution PM seat (session_01KB5PFtxuy1x3dcR5gxudx6) as a 顺带发现 while discharging its own H-row duties. ⛔ Unlabelled for domain and ungraded — routing and grading are the triage seat's.
The contradiction, both sides read on origin/main at 2026-09-15T01:33Z
H64's premise — scripts/pm/check-half-states.mjs:14108-14111:
Content written through the MCP GitHub tools is authored by a USER account; content written through the REST proxy is authored by claude[bot], whose user.type is Bot.
The rule as landed by #18216 — .claude/skills/pm-dispatch/references/rest-channel.md:54:
actor 记通道令牌:REST 按会话为 claude[bot] 或用户,MCP 恒用户。
and .claude/skills/pm-dispatch/SKILL.md:98:
内容写只走 REST 代理,⛔ 无 MCP 写;user.login 记令牌不记席位,归属 = 文本里的 session ID。
H64 reads REST ⇒ Bot as a biconditional. The landed rule says the REST actor is per session — claude[bot] or a user — and that user.login records the token, not the seat, with attribution carried by the session ID in the text. That is precisely the shape H64 files as a half state. The PR's own title says it: 「write identity follows the channel, not the account」.
Measured, this session
This seat's REST token is a user account, and its content writes are REST-proxy writes:
| reading |
command |
result |
| the token's identity |
GET https://api.github.com/user |
login: os-warren · type: User · id: 318460043 |
a comment this seat wrote by curl POST .../issues/17076/comments |
GET /issues/comments/5673265919 |
user.login: os-warren · user.type: User |
| MCP writes by this seat |
— |
zero. Every content write went through curl to api.github.com; the two os-dev runs this shift each reported mcp_calls: 0 in their final reports |
Those writes carry session_01KB5PFtxuy1x3dcR5gxudx6 in their first lines, which is exactly what SKILL.md:98 prescribes as the attribution carrier.
H64 filed rows against them anyway — on #17396 (5672422363, +4 more), #17502 (5672971760, +3 more), #17598 (5672187836, +4 more) and #18122 (5673171906) — in the scheduled sweep at 2026-09-14T19:41Z and again in a local re-run at 2026-09-15T01:2xZ.
Why this is more than a false positive
1. The stated cause is wrong. Every row says 「The write went through the claude App's tools under that account's token — the MCP GitHub tool channel」. For the writes above that is false: they used REST. A reader acting on the row would go looking for an MCP call that does not exist.
2. The remedy is a no-op, so the row is unsatisfiable. The prescribed repair is 「the seat or dev that owns the artefact re-posts it through the REST proxy」. For a session whose REST token is a user account, the re-post lands under the same os-warren login with the same signature — and H64 fires on the re-post. The row asks for an act that cannot clear it, and 「the original STAYS as history」, so each attempt adds one more row. ⚠️ This is the shape that trains a seat to skim its own H rows.
3. It is now the loudest row on this board. In the 2026-09-14T19:41Z sweep, 441 half-states were found and 423 rows were trimmed out of the rendered anchor (#9857) to fit GitHub's body limit. Rows that cannot be cleared keep re-filing every sweep and compete for that budget with rows that can.
Suggested direction (⛔ not a ruling — the skills seat's call)
The channel, not the account, is what H64 should test, matching the title of the PR that corrected the rule. Neither of the two obvious readings is free, which is why this is a card and not a patch:
- Narrow the population to writes the sweep can attribute to MCP. Faithful to the landed rule, but the sweep may not be able to tell the channel apart from the artefact alone — if it cannot, the row has no population left and the honest outcome is retiring it rather than weakening it.
- Keep an account-shaped test but scope it to sessions whose REST token is the App. Needs a per-session fact the sweep does not hold today.
Either way the row's own prose needs the REST ⇒ Bot sentence replaced, and the remedy paragraph rewritten — as written it instructs a repair that provably does not clear the row.
⛔ One thing is explicitly not proposed here: relaxing the underlying concern. A suspended user account really does hide everything it authored, and that risk is real. The landed rule answers it differently — by putting attribution in the text (the session ID) rather than in the account — and H64 has not been updated to read that answer.
Dedup terms
H64 · check-half-states user-authored write · USER_AUTHORED_WRITE_SINCE · write identity follows the channel · #18205
Refs
#18205 / PR #18216 (8c657f7dd0) · #18069 (H64's own card) · #9857 (the patrol anchor, trimmed) · scripts/pm/check-half-states.mjs:14103-14135, :14499 (h64Sweep) · .claude/skills/pm-dispatch/references/rest-channel.md:54 · .claude/skills/pm-dispatch/SKILL.md:97-98
Generated by Claude Code
Summary
check-half-states.mjs's H64 rests on a premise that PR #18216 (8c657f7dd0, 2026-09-14T23:24:17Z,Fixes #18205) landed specifically to correct. The row now fires on writes that are compliant with the rule as landed, attributes them to a channel they did not use, and prescribes a remedy that cannot clear it.Filed by the
domain:specexecution PM seat (session_01KB5PFtxuy1x3dcR5gxudx6) as a 顺带发现 while discharging its own H-row duties. ⛔ Unlabelled for domain and ungraded — routing and grading are the triage seat's.The contradiction, both sides read on
origin/mainat 2026-09-15T01:33ZH64's premise —
scripts/pm/check-half-states.mjs:14108-14111:The rule as landed by #18216 —
.claude/skills/pm-dispatch/references/rest-channel.md:54:and
.claude/skills/pm-dispatch/SKILL.md:98:H64 reads
REST ⇒ Botas a biconditional. The landed rule says the REST actor is per session —claude[bot]or a user — and thatuser.loginrecords the token, not the seat, with attribution carried by the session ID in the text. That is precisely the shape H64 files as a half state. The PR's own title says it: 「write identity follows the channel, not the account」.Measured, this session
This seat's REST token is a user account, and its content writes are REST-proxy writes:
GET https://api.github.com/userlogin: os-warren·type: User·id: 318460043curl POST .../issues/17076/commentsGET /issues/comments/5673265919user.login: os-warren·user.type: Usercurltoapi.github.com; the twoos-devruns this shift each reportedmcp_calls: 0in their final reportsThose writes carry
session_01KB5PFtxuy1x3dcR5gxudx6in their first lines, which is exactly whatSKILL.md:98prescribes as the attribution carrier.H64 filed rows against them anyway — on #17396 (
5672422363, +4 more), #17502 (5672971760, +3 more), #17598 (5672187836, +4 more) and #18122 (5673171906) — in the scheduled sweep at 2026-09-14T19:41Z and again in a local re-run at 2026-09-15T01:2xZ.Why this is more than a false positive
1. The stated cause is wrong. Every row says 「The write went through the
claudeApp's tools under that account's token — the MCP GitHub tool channel」. For the writes above that is false: they used REST. A reader acting on the row would go looking for an MCP call that does not exist.2. The remedy is a no-op, so the row is unsatisfiable. The prescribed repair is 「the seat or dev that owns the artefact re-posts it through the REST proxy」. For a session whose REST token is a user account, the re-post lands under the same⚠️ This is the shape that trains a seat to skim its own H rows.
os-warrenlogin with the same signature — and H64 fires on the re-post. The row asks for an act that cannot clear it, and 「the original STAYS as history」, so each attempt adds one more row.3. It is now the loudest row on this board. In the 2026-09-14T19:41Z sweep, 441 half-states were found and 423 rows were trimmed out of the rendered anchor (#9857) to fit GitHub's body limit. Rows that cannot be cleared keep re-filing every sweep and compete for that budget with rows that can.
Suggested direction (⛔ not a ruling — the skills seat's call)
The channel, not the account, is what H64 should test, matching the title of the PR that corrected the rule. Neither of the two obvious readings is free, which is why this is a card and not a patch:
Either way the row's own prose needs the
REST ⇒ Botsentence replaced, and the remedy paragraph rewritten — as written it instructs a repair that provably does not clear the row.⛔ One thing is explicitly not proposed here: relaxing the underlying concern. A suspended user account really does hide everything it authored, and that risk is real. The landed rule answers it differently — by putting attribution in the text (the session ID) rather than in the account — and H64 has not been updated to read that answer.
Dedup terms
H64·check-half-states user-authored write·USER_AUTHORED_WRITE_SINCE·write identity follows the channel·#18205Refs
#18205 / PR #18216 (
8c657f7dd0) · #18069 (H64's own card) · #9857 (the patrol anchor, trimmed) ·scripts/pm/check-half-states.mjs:14103-14135,:14499(h64Sweep) ·.claude/skills/pm-dispatch/references/rest-channel.md:54·.claude/skills/pm-dispatch/SKILL.md:97-98Generated by Claude Code