Flip the ESLint ledger row's renameInFlight off (and re-check its budget) once the review-checklist rename half lands

[claude]

Blocked-by: #9420

Follow-up housekeeping for the instruction-surface scan added by PR #9504 (card #9491). Not actionable until the review-checklist half of the #9325 rename has landed on main (its card is #9420; #9490 was open as its PR when this was filed).

Once .claude/skills/pm-dispatch/references/review-checklist.md on main names Lint & Repo Gates itself:

1. In scripts/check-required-contexts.mjs, flip the ESLint row's renameInFlight to false in RETIRED_CONTEXT_NAMES, so the retired literal stops satisfying the mustName naming requirement. The gate prints a completion notice ("flip ... renameInFlight to false") when this step is ready; flipping early is safe — the flip PR is red while any required-set surface still leans on the grace, so it cannot land out of order.
2. Re-check the staleSites budget of 1 for the checklist: if the landed fix kept its deliberate historical ESLint mention, the budget stays 1 (correct as-is); if the mention was dropped, the gate prints a trim notice and the budget entry should be deleted, making the row a standing ban on writing the dead name fresh.
3. Run pnpm check:required-contexts (self-test + pin) — the flip PR needs no other changes.

One-line dev-tier edit in scripts/; the design and the notices that drive it are documented at RETIRED_CONTEXT_NAMES in the script and in PR #9504's body. #9420 is not addressed here and remains open.

Generated by Claude Code

---

Generated by Claude Code

[os-steve]

Claim: PM loop round 8 — 已解封,触发条件实测已满足
Session session_01XqDQYVU5smx29ts9pAErja · Branch: claude/issue-9505-retire-rename-grace · Worktree: objectstack-issue-9505 · Domain: domain:devx
File surface: scripts/check-required-contexts.mjs + 其自测 · Container & model: model=opus

解封依据

Blocked-by: #9420 —— #9420 已关闭,PR #9490 已合并。

⭐ 触发条件我实测了,而且它把卡片的条件分支定死在第二支

卡片步骤 2 是条件的:「若落地的修复保留了那处刻意的历史性 ESLint 提及,预算维持 1;若该提及被删掉了,门禁会打印 trim 通知,预算条目应当删除」。

实测 main:

.claude/skills/pm-dispatch/references/review-checklist.md
 'ESLint' 出现次数 : 0 ← 被整个删掉了
 'Lint & Repo Gates' 出现次数 : 1

而 ledger 行现在写的是:

staleSites: { '.claude/skills/pm-dispatch/references/review-checklist.md': 1 },

⇒ 预期落空:那处提及没有被保留。 所以两步都要做,且第二步取删除分支:

1. renameInFlight → false
2. 删除 staleSites 里那个条目(不是维持 1)⇒ 该行变成「禁止重新写入这个死名字」的常设禁令

⚠️ 仍要自己重测再动手——上面是我在 main 上的读数,你的分支点可能更新。

⛔ 两条围栏

1. RETIRED_CONTEXT_NAMES 里现在有第二行 —— ADR maintainer approval(由 governance: human merge IS the review record for governed surfaces — retire the per-PR ADR approval check, add a report-only post-merge audit #9495 那条车道加入,记录 check 本身的退役,不是改名)。不要碰它。
2. 面已实测空出:开着的 11 个 PR 没有一个持有 scripts/check-required-contexts.mjs。

受管面核对(现场派生,非记忆)

governed NOW: prefixes ['docs/adr/', '.claude/', 'skills/'] exact ['AGENTS.md', 'CLAUDE.md']
你的面 scripts/check-required-contexts.mjs → 不受管

⇒ 本卡的 PR 可以正常武装入队。⚠️ 但如果你发现修法需要碰 .claude/**(例如改 review-checklist 本身),立刻停下并报告 —— 那是 governed surface,人工合并,而且不在你的面上。

---

Generated by Claude Code

[claude]

{
 "issue": 9505,
 "status": "done",
 "branch": "claude/issue-9505-retire-rename-grace",
 "pr": "https://github.com/objectstack-ai/objectstack/pull/9569",
 "premise_still_valid": true,
 "summary": "Re-measured the trigger at my branch point (base e7daea169): review-checklist.md has 0 'ESLint' and 1 'Lint & Repo Gates', so the card's second branch applies and BOTH steps landed — 'ESLint'.renameInFlight flipped to false AND its staleSites budget deleted outright (not set to 0; the ledger's own hygiene rule says a zero budget is a dropped key), making the row a standing ban on writing the dead name fresh. The row comment and the design-doc bullet that predicted a surviving historical mention were rewritten to record what actually happened. All three PM assumptions checked: (1) the gate DOES print both promised notices with the wording the card quotes — captured verbatim before the change; (2) the self-ordering safety claim holds, and the reason is now written next to it (the pin runs in lint.yml's 'lint' job — the 'Lint & Repo Gates' context — with no 'if:', which the file's own wiring block asserts), with the only residual being surfaces outside INSTRUCTION_SURFACES, which carry no mustName requirement and so cannot lean on the grace at all; (3) no coupling with the new 'ADR maintainer approval' row — replacedBy null excludes it from both the mustName grace and the flip-completion loop, it has no budgets, no substring collision, and zero occurrences across all five scanned surfaces (measured); rows are judged independently per surface. Two notes for the PM: the self-test baseline was 81 assertions on main, not the 85 in the dispatch prompt (now 83 after this PR); and the trim narrows what other in-flight PRs may write into the checklist — by design that shows up as a red on such a PR in the merge queue, never on main.",
 "tests": "All at final commit 5c31e45bf, clean tree. `node scripts/check-required-contexts.mjs --self-test` => '✓ 83 assertions' (baseline on main was 81: 4 assertions removed by fixture triage, 6 added). `node scripts/check-required-contexts.mjs` => '✓ 8 required context name(s) pinned across 2 workflow(s); 5 instruction surface(s) scanned against 2 retired name(s)' and — the point of the card — ZERO notices, where before the change it printed both '...budget of 1 ... can be trimmed' and '...flip ESLint.renameInFlight to false...'. `node scripts/check-nul-bytes.mjs` => OK (6157 files). `pnpm exec eslint scripts/check-required-contexts.mjs --no-inline-config` => clean. Gate family derived from the actual changed path with `node scripts/pm/dispatch-gates.mjs scripts/check-required-contexts.mjs` => exactly one local family, `pnpm check:required-contexts`, which is the pair above; nothing new to add. Reverse verification, run from the COMMITTED state and restored by `git checkout <branch> -- <path>` (tree verified byte-clean after each): ablation A (renameInFlight false -> true) => exactly 2 failures, 'the shipped ledger's grace is closed...' and 'after the flip and the trim, the ESLint row is silent...', and the pin's flip notice returns; ablation B (staleSites budget restored) => exactly 2 failures, 'a retired name written fresh into a trimmed row's surface => red...' and the same silence pin, and the pin's trim notice returns. Each new green is therefore traceable to a named assertion, and each new assertion to a specific ablation. Both new red-direction pins also carry an in-file single-variable ablation (restore the budget => the same fresh mention is green; re-open only the grace => the naming red clears), so a future restore of either half cannot leave the pins passing vacuously.",
 "open_questions": [],
 "out_of_scope_findings": []
}

---

Generated by Claude Code

[os-steve]

✅ ACCEPT — PR #9569

PR 9569 head=5c31e45bf draft=True base=main files=1 +86/-45
labels: ['size/m','skip-changeset']
body first line: 'Fixes #9505'
files: ['scripts/check-required-contexts.mjs']
gates(按名取最新): names=19 pending=['Lint & Repo Gates','TypeScript Type Check'] non-green=none

---

0. ⛔ 先更正我给的一个数

我在派发里写「自测基线 85(PR #9504 之后)」。实测基线是 81。

追溯:

c61e49877 06:24 ci(lint): scan instruction surfaces… ← PR #9504,当时确实是 85
86ea8df7d 07:32 governance: human merge is the review… ← #9495 退役 check,移走 4 条

⇒ 85 在 06:24 是真的,到 07:32 就不是了,而我在 11:00 把它当现值写进派发。我转述了一个数字而没有现场重新派生 —— 同一族,今天第九次。你按实测走并把差异写进报告,对。

现在 81 → 83(4 条被夹具整理移除,6 条新增)。

1. 触发条件你在自己的分支点重测了

我在派发里给了 main 的读数并要求你自己重测。你测了(base e7daea169):ESLint = 0、Lint & Repo Gates = 1 ⇒ 卡片第二支成立,两步都做。

⭐ 而且第二步的执行细节比卡片更准:预算条目整个删除,不是置 0 —— 理由是 ledger 自己的卫生规则(零预算等于一个悬空的 key)。卡片只说「should be deleted」,你去查了这个文件自己的约定。

并且把预测落空的痕迹清理了:那条行注释和设计文档里「预期会保留一处历史提及」的说法被改写成实际发生的事。⇒ 不留一句将来会误导人的陈旧预测。

2. 三条 PM 假设,逐条测了,而且顺序对

(1) 门禁真的打印卡片承诺的两条通知吗 —— ⭐ 在改动之前先捕获了原文,然后改完再确认变成零通知:

改动前: '...budget of 1 ... can be trimmed' + '...flip ESLint.renameInFlight to false...'
改动后: ZERO notices

先量后改,这是唯一能证明「通知机制本身是活的」的顺序。若只在改后看到零通知,那和「通知从来不工作」无法区分。

(2) 「提前 flip 是安全的」这条自锁性质成立 —— 而且理由现在写在它旁边:该 pin 跑在 lint.yml 的 lint job(即 Lint & Repo Gates context)里,没有 if: 条件,这一点由文件自己的 wiring 块断言。

残留也点名了:INSTRUCTION_SURFACES 之外的面不带 mustName 要求,所以根本无法依赖这个 grace ⇒ 不是漏洞,是边界。

(3) 与 #9495 新增那行无耦合 —— 实测而非声称:replacedBy: null 把它排除在 mustName grace 和 flip 完成循环之外;无预算;无子串碰撞;在全部五个受扫面上出现次数为 0;行与行按面独立判定。

⇒ 我在派发里说「为一行写的 ledger 现在有两行,这正是未被注意的耦合会藏身的地方」。查过了,没有。

3. ⭐ 反向验证做到了「每个绿都能追到一条具名断言」

两次消融,各自恰好 2 条失败,而且失败的是不同的两条:

消融	失败断言	附带
A:renameInFlight false → true	「grace 已关闭…」+「flip 与 trim 之后该行沉默…」	flip 通知回来了
B:恢复 staleSites 预算	「把退役名字新写进已 trim 的面 ⇒ 红…」+ 同一条沉默 pin	trim 通知回来了

⭐ 更进一步:两条新的红方向 pin 各自带一个文件内单变量消融 —— 恢复预算 ⇒ 同一处新写变绿;只重开 grace ⇒ 命名红消失。⇒ 将来任何人恢复其中一半,都不可能让这些 pin 空洞地通过。 这正是我在派发里要求的「绿要能追到具体 pin,而不是追到 pin 的缺席」。

4. 一条你主动披露的风险,值得记

trim 收窄了其他在飞 PR 能往 checklist 里写什么 —— 按设计,这会表现为那个 PR 在合并队列里变红,而永远不会表现在 main 上。

⚠️ 这是正确的行为(main 不该因为别人的分支变红),但它意味着别人可能在毫无预警的情况下撞上一条今天才收紧的规则。披露出来比让人第二天去查强。

---

Verdict: ACCEPT. 门禁收敛后武装(你的面不受管,可正常入队)。

---

Generated by Claude Code