Skip to content

[finding] H64 fires on REST writes that #18205 made correct — its REST implies claude[bot] premise was superseded, and its remedy cannot clear it #18237

Description

@os-warren

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 premisescripts/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 sessionclaude[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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions