[finding] the six required check-run names are restated in the PM readings ledger, which check-required-contexts does not scan

The six required check-run names are spelled in .claude/skills/pm-dispatch/references/platform-readings.md as the operative per-repo required set a seat reads before it flips a PR ready. Nothing pins that copy.

scripts/check-required-contexts.mjs holds INSTRUCTION_SURFACES, and its scan set is AGENTS.md, .claude/skills/pm-dispatch/references/review-checklist.md, .claude/skills/spec-property-retirement/SKILL.md, docs/launch-readiness.md and docs/releases-maintenance.md. The readings ledger is not on it, and neither is .claude/skills/pm-dispatch/references/true-green.md.

Why it matters: renaming any of the six job names reddens the gate on AGENTS.md and on the review checklist, so the rename PR is forced to fix those two. The ledger's copy is invisible to the same run and would keep the dead name — and the ledger's copy is the one a seat consults at the moment it decides whether a PR may be enqueued. The same RETIRED_CONTEXT_NAMES standing ban (writing ESLint fresh) also does not reach this file.

Reproduce:

read INSTRUCTION_SURFACES in scripts/check-required-contexts.mjs and note the five entries
git grep -n 'Temporal Conformance' -- .claude AGENTS.md and note the ledger hit that is not in that list

Two shapes a fix could take, both out of scope for the card that found this:

add the ledger as an INSTRUCTION_SURFACES entry with mustName all six, which is the same treatment review-checklist.md already gets
or decide the ledger should point at the pinned surface instead of restating the six names, and delete the copy

Observation only: nothing is broken today, and no rename is in flight. Filed unassigned for first-touch grading.

Generated by Claude Code

分诊 · `pm:queue` / `domain:skills` / `priority:p3` / `enhancement` / `finding`

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。

复核（`origin/main` = `95d5cbb`）—— 卡片给的复现步骤照做，两步都成立

① INSTRUCTION_SURFACES 的五个条目（scripts/check-required-contexts.mjs:504）：

'AGENTS.md'
'.claude/skills/pm-dispatch/references/review-checklist.md'
'.claude/skills/spec-property-retirement/SKILL.md'
'docs/launch-readiness.md'
'docs/releases-maintenance.md'

与卡片列的五个一字不差。

② 台账那处命中确实不在名单上：

git grep -ln "Temporal Conformance" -- .claude AGENTS.md
→ .claude/skills/pm-dispatch/references/platform-readings.md    ← 不在 INSTRUCTION_SURFACES
→ AGENTS.md                                                      ← 在名单上（阳性对照）

⭐ 这次复现自带对照：同一次读里，一个命中在扫描集内、一个在集外 ⇒ 「台账没被扫」不是仪器没开火，是真的没被扫。

为什么锚定 `domain:skills`

两个可能落点都在治理面：要么给 check-required-contexts.mjs 的 INSTRUCTION_SURFACES 加一个条目，要么改写 .claude/skills/pm-dispatch/references/platform-readings.md 让它指向被钉的表面而不再复述六个名字。

按车道表，domain:devx 与 domain:skills 的分界按门禁的 SUBJECT：治理 agent 指令面 / governed 面的归 skills，治理代码或文档质量的归 devx。check-required-contexts 的扫描集从头到尾就是 agent 指令面（AGENTS.md、两个 skills 目录下的参考文件、两份 docs 流程文件）⇒ 其 SUBJECT 是指令面本身 ⇒ domain:skills。

⚠️ governed surface（.claude/** 与 scripts/ 上治理指令面的门）⇒ draft PR + 人工合并（GOVERNED_APPROVERS：os-zhuang / hotlong）。

`priority:p3` 的理由

卡片自陈「Observation only：今天没有任何东西是坏的，也没有任何改名在飞」，复核后同意——六个名字今天在两处都是对的。

风险是条件性的：一旦有人改任一个 job 名，门会在 AGENTS.md 与 review-checklist 上变红、逼那条 PR 顺手修好它们，而台账里的那份拷贝对同一次运行不可见、会留着死名字。⚠️ 而台账那份恰恰是席位在决定一条 PR 能否入队的那一刻去查的那份。⇒ 值得修，不急。

顺带记下卡片提到的第二个盲点：RETIRED_CONTEXT_NAMES（例如禁止重新写出 ESLint）那条常设禁令同样够不到这个文件；以及 .claude/skills/pm-dispatch/references/true-green.md 也不在扫描集内。⇒ 若选「加扫描集」那条路，⚠️ 请把 true-green.md 一并考虑，⛔ 但要先确认它是否真的复述了那六个名字——本席位未测，⛔ 不要凭本条提示直接加。

⛔ 两条路线，⛔ 本席位不代选

把台账加进 INSTRUCTION_SURFACES，mustName 六个名字——与 review-checklist.md 今天受到的待遇相同。
让台账指向被钉的表面、删掉那份复述。 —— 更彻底：一份不复述就不会腐烂。

判据（供决策者参考，非裁决）：台账的读者是正要决定入队的席位，他需要的是当场可读的六个名字还是一个指针？若指针够用，路线 2 从根上消灭这一类；若席位确实需要就地可读，路线 1 才是对的。⛔ 请在动手前把这个判断写进卡里。

交给接手者的两条

⛔ 无论哪条路线，都必须让门在改名时真的变红。 路线 1 选完要验证：临时改一个 job 名，确认门在台账上也报红（⛔ 不是「我加了条目所以应该会红」）。
⛔ 不要顺手把 true-green.md 或别的文件一起塞进去。 每加一个扫描面都是一次新的耦合；未测的文件不进名单。

_{分诊席位 · claude-opus-5 · 本轮 R+156}

Generated by Claude Code

Claim: PM loop round 5 — graded p3 at first touch (triage's grade and route stand); route 1 taken: the readings ledger joins INSTRUCTION_SURFACES with mustName for the six required contexts, proved red by a temporary rename
Session: session_019RfFHiRCSs3JXLK4cwcfox
Branch: claude/issue-15652-required-contexts-scan-the-ledger
Worktree: objectstack-issue-15652
Domain: domain:skills
File surface: scripts/check-required-contexts.mjs only — one INSTRUCTION_SURFACES entry for .claude/skills/pm-dispatch/references/platform-readings.md with mustName = the six required context names (the same treatment review-checklist.md gets), the RETIRED_CONTEXT_NAMES ban reaching it by the same entry, self-test cases in both directions, and the gate's own header/registry note updated by its convention. ⛔ No edit to the ledger itself (it is on PR #15641, approved, awaiting re-enqueue; its six names are spelled the same on main and on that head), ⛔ true-green.md not added (untested, per triage), ⛔ no other file (stop on breach; explain in the report)
Container & model: S (one registry entry + its proof), mode:subagent, model: opus (dispatch-gates.mjs --tier scripts/check-required-contexts.mjs at 1c1421401, 2026-09-05T04:12Z: no path-derived mandate)
Clause-②: no
Serial constraints cleared: no open PR touches scripts/check-required-contexts.mjs (search 04:1xZ: seven hits by body mention, none by file — PR #15641's 14 files and PR #15290's two are known). Not governed (check-governed-merges --test exit 0) ⇒ the seat's contract-tier review, then ready + auto-merge once every check is green. The PR carries Fixes #15652.

Decision re-read (04:1xZ): route 1 over route 2 on the frame's third axis — the ledger's reader is a seat at the moment of enqueue and needs the six names readable in place; a pin that reds on rename keeps that copy honest, whereas a pointer removes information from the one place it is consulted. Triage's two hand-over conditions are the acceptance conditions: the red must be proved (rename one job name on a throwaway copy and show the gate red on the ledger), and nothing else joins the scan set. The separate unfiled reading from another dev — Governed Surface Queue Guard is required in the live ruleset but has no REQUIRED_CONTEXTS row — is ⛔ not this card's; report it if the gate prints it, do not fix it.

Generated by Claude Code

os-dev-report

{
  "issue": 15652,
  "status": "done",
  "branch": "claude/issue-15652-required-contexts-scan-the-ledger",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/15727",
  "premise_still_valid": true,
  "summary": "Route 1 taken, exactly as claimed: one INSTRUCTION_SURFACES entry in scripts/check-required-contexts.mjs for .claude/skills/pm-dispatch/references/platform-readings.md with mustName for all six required contexts, in the same shape the review-checklist.md entry uses, so the RETIRED_CONTEXT_NAMES standing ban reaches the ledger through that same entry. Carried along by the file's own convention: the provenance block's count line (four of five surfaces carry a path separator becomes five of six), a dated note recording the scan set's re-derivation, three self-test cases in the stale-name battery, and that battery's declared floor (28 becomes 31). No edit to the ledger itself, no other file, no other entry; references/true-green.md is NOT added and the reason is measured rather than assumed - it names none of the six. The re-derivation of the scan set with the header's own query found the ledger to be the only *.md in that population (AGENTS.md, CLAUDE.md, .claude/, docs/, minus the header's standing docs/adr exclusion) that names a registered context and was not enrolled. Draft PR #15727 with skip-changeset, verified applied by read-back; never marked ready, never enqueued, no auto-merge, no approval.",
  "tests": "All at 618f44fb8, the head the PR opens on; tree clean, one committed file. THE RED, PROVED (triage's hand-over condition), on a throwaway root - scripts/, .github/ and the six surfaces copied into a temp dir with a node_modules symlink; the worktree itself never mutated (git status clean throughout). (a) control, untouched copy, exit 0: '✓ check-required-contexts: 6 required context name(s) pinned across 2 workflow(s); 6 instruction surface(s) scanned against 2 retired name(s) (#9491).' (b) mutation CONFIRMED ON DISK before measuring - 'Temporal Conformance (live PG + MySQL)' renamed to 'Temporal Conformance (live Postgres + MySQL)' in the ledger copy: old literal 1 occurrence becomes 0, new literal 1; blob hash 8fce82f9fb5dea5070b88d558d34a2364e864748 becomes eff473272cb18d97150c2c470e6ecc07b9f7af26. Gate exit 1, exactly one problem: '✗ check-required-contexts - 1 problem(s)' / '.claude/skills/pm-dispatch/references/platform-readings.md no longer names the required context 'Temporal Conformance (live PG + MySQL)'.' (c) ABLATION, single variable - the pre-change gate (git show origin/main:scripts/check-required-contexts.mjs, verified to carry 0 occurrences of the new path) run against the IDENTICAL mutated copy, exit 0: '✓ ... 5 instruction surface(s) scanned against 2 retired name(s) (#9491).' Five surfaces, silent on the rename - the red in (b) is this entry's doing and nothing else. Gate restored to my version (2 occurrences back), ledger copy restored and proved byte-identical by git hash-object on both sides (8fce82f... == 8fce82f...; an empty hash would have been read as a failed restore), re-run exit 0 with 6 surfaces. GATES: node scripts/check-required-contexts.mjs --self-test exit 0 ('✓ ... 153 assertions'); pnpm check:required-contexts exit 0 ('✓ check-required-contexts: 6 required context name(s) pinned across 2 workflow(s); 6 instruction surface(s) scanned against 2 retired name(s) (#9491).'). dispatch-gates --commands --repo objectstack-ai/objectstack derived 30 families (no path list passed - the script took its own change set); all 30 run, all exit 0, reconciled by '✓ dispatch-gates --ran: 30 derived famil(ies) accounted for - 30 run, 0 NOT-MEASURED.' Two needed a second pass and neither was a red: --verify-required-set exited 2 (NOT VERIFIED) until re-run with NODE_OPTIONS=--use-env-proxy, then exit 0; check:pm-dispatch-gates exited 124 on my 420s cap, then exit 0 with a larger budget ('✓ dispatch-gates self-test: 1445 cases pass.'). The family list was re-derived after git fetch origin main (main had moved to a5cef3769) and is byte-identical. NO NARROWING NEEDED on lint: full-repo pnpm lint (eslint . --no-inline-config) through scripts/pm/os-verify-lock.sh, 'VERDICT command-exit 0 · held the lock 103s' (shared box, so that absolute is a contended reading). Script's own suite: git grep found no vitest pin naming check-required-contexts, so its --self-test is the whole of it; control-byte self-scan of the edited file is empty. CI on the PR head: all 35 check runs concluded - 24 success, 11 skipped, 0 failures. The six required contexts: Lint & Repo Gates success, TypeScript Type Check success, Test Core success, Dogfood Regression Gate success; Build Core and Temporal Conformance (live PG + MySQL) reported 'skipped' by their path filters.",
  "mcp_calls": "2 - both MCP GitHub reads of the card (issue body, then its comments). Every write and every other read went through repo-scoped REST from this container, which answered 201/200 on PR create, label add and read-back.",
  "open_questions": [],
  "out_of_scope_findings": [
    "NOT filed, held by the seat for dedup per the claim's ruling - direction B from 'node scripts/check-required-contexts.mjs --verify-required-set' through the proxy (exit 0, 2026-09-05): the exact line is '⛔ direction B - required in the live set, pinned by NO registry row (1).' / '• Governed Surface Queue Guard - from main (active)'. The live ruleset (main, id 12119582, active) carries SEVEN required contexts; REQUIRED_CONTEXTS pins six. Registry left exactly as it is. Secondary reading from the same run, same owner: the readings ledger states 'objectstack six' for that set, which is a count the live sweep now contradicts - mustName does not require exclusivity, so this PR is green either way, and the ledger was not touched."
  ]
}

Generated by Claude Code

Navigation Menu

Repository navigation

[finding] the six required check-run names are restated in the PM readings ledger, which check-required-contexts does not scan #15652

分诊 · `pm:queue` / `domain:skills` / `priority:p3` / `enhancement` / `finding`

复核（`origin/main` = `95d5cbb`）—— 卡片给的复现步骤照做，两步都成立

为什么锚定 `domain:skills`

`priority:p3` 的理由

⛔ 两条路线，⛔ 本席位不代选

交给接手者的两条

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[finding] the six required check-run names are restated in the PM readings ledger, which check-required-contexts does not scan #15652

Description

Activity

os-zhuang commented on Sep 5, 2026

分诊 · pm:queue / domain:skills / priority:p3 / enhancement / finding

复核（origin/main = 95d5cbb）—— 卡片给的复现步骤照做，两步都成立

为什么锚定 domain:skills

priority:p3 的理由

⛔ 两条路线，⛔ 本席位不代选

交给接手者的两条

claude commented on Sep 5, 2026

claude commented on Sep 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

分诊 · `pm:queue` / `domain:skills` / `priority:p3` / `enhancement` / `finding`

复核（`origin/main` = `95d5cbb`）—— 卡片给的复现步骤照做，两步都成立

为什么锚定 `domain:skills`

`priority:p3` 的理由