⏱️ 本卡所有读数取自同一动作:2026-09-17T23:45Z,树为 origin/main = c993b7c820,被复核的 PR head = a443fc3574。承接 #18745 / PR #18834 。
一句话
PR #18834 给 check-adr-0087-registration.mjs 加了 RETIREMENT 臂(「X → delete the property」这类没有新名字 的处方)。收紧后恰好有一张 存量 changeset 从「无处方」变成「有处方」——.changeset/18318-evalcontext-no-query-api.md ——而它持的豁免 not-required (runtime-interface-only …) 继承处方拒绝 。⇒ 今天不红,但将来任何 PR 碰到 packages/formula/src/types.ts 并让门禁重判它时,它会被拒。
读数(本席独立重跑,⛔ 非转述)
把 origin/main 版与 PR head 版的 findMigrationPrescription 同时 import,对全量 changeset 逐个跑:
stock: 418 个 .changeset/*.md
BEFORE {framed-line:1, from-to-label:26, header-framed-table:2} null 389
AFTER {framed-line:1, from-to-label:26, header-framed-table:2, framed-removal:1} null 388
移动的行:恰好 1 —— null -> framed-removal :: .changeset/18318-evalcontext-no-query-api.md
既有命中中 branch 或证据行发生变化的:0(超集性质成立)
触发它的那一行,逐字:
**Migration — `api: { … }` → delete the property.**
它脚上的处置,逐字节选:
<!-- adr-0087: not-required (runtime-interface-only packages/formula/src/types.ts#EvalContext) … -->
为什么这不是「探测器修错了」
⭐ 那个拒绝在它自己的道理上是对的。 正文确实 开了处方:它告诉消费者删掉 api 属性 —— 那和「改写成 x」一样是消费者要做的活,且同样与「你正文里没有处方」这个豁免条件矛盾。⇒ 诚实的修法在处置面 ,⛔ 不在探测器上开洞。
⚠️ 同样要公道地记下:#18318 / PR #18736 的作者没有做错事。 那张 changeset 的四个 runtime-interface-only 谓词都是正面逐条验过 的,作者还把探测器的漏判主动交了上去 而不是让它替自己扛。缺陷在探测器,已由 #18745 收掉;剩下的只是这一张的处置 被新读数反过来抵触了。
处置选项(⛔ 非裁定)
A —— 维持不动。⚠️ 代价落在无辜的人头上:下一个碰 packages/formula/src/types.ts 的人撞上一个不是他造成 的拒绝,还得自己把来龙去脉考古一遍。
B —— 重新处置那张 changeset:要么登记 该迁移,要么把移除句改写成不带箭头的形 (语义不变,只是不再落进处方形)。⭐ 本席倾向 B。
C —— 按文件机械豁免。⛔ 本席明确否掉 ,只为让它可见地被否掉:按文件的 allow-list 正是这整套门禁存在要对付的形状。
⭐ 先看发布窗口再动手
那张 changeset 是 @objectstack/formula 的 minor ,正在等发布 。⇒ 一旦发布消费掉它,本卡自行消失。 接手的人先读发布窗口 :若发布就在眼前,A 是理性的;若还要挂一段时间,B 便宜且一劳永逸。⇒ 这是时机 问题,⛔ 不是该不该记的问题 —— 所以本卡先把它记住。
边界
⛔ 本卡不授权任何人去编辑别人的 changeset 正文之外的东西 ,也 ⛔ 不是对 #18318 或 PR #18736 的追责。⭐ #18745 的 dev 把这份读数交回而没有顺手改 ,那是对的:一次探测器修复不该在路过时编辑别人的 changeset。
查重(MCP search_issues,含 closed)
以 18318 / evalcontext / changeset 处置 / runtime-interface-only 被拒 / retirement 臂 等词检索,零命中 。⇒ 无孪生。
出处
domain:spec seat 2(座位贴 #18549 )复核 PR #18834 / 卡 #18745 时,dev 在 open_questions 第 1 问里交回并推荐 B。本席独立重跑了全量 stock (见上)确认「恰好一行移动」后立卡。
os-decision-facets
⚠️ 由派发席(domain:spec seat 2)在半状态巡检 H62 指出后补上 —— ⏱️ 2026-09-18T10:08Z。⛔ 正文原有内容一字未改、未删。⭐ 本卡进决策箱是因为交付已完成、余下的是一次落地裁定 (见 PR #18905 ),⛔ 不是实施未完成。
① 项目长远合理性 —— check-empty-changeset 对「改动一份 merge-base 上已存在的 changeset」必拒 ,而它 DELIBERATE CORRECTION 一类的补救原文是 'do NOT restore it -- say so on the PR and get it confirmed'。⇒ 这条红按设计无法靠改写消除 ,它存在的意义就是把决定摆到人面前。本卡问的是:这次的确认由谁给、以什么形式留痕。
② 实际业务拉动 —— 被改的是一份 pending 的发布注记 ,它会原样进下一次发布的 CHANGELOG。⛔ 按 FOREIGN_REMEDY(从 base 恢复)去做,会把一句已经变假 的话放回去。
③ 防 AI 犯错 —— ⚠️ Check Changeset 不是必过上下文 (本席逐条枚举过 REQUIRED_CONTEXTS,共 7 条,它不在其中)⇒ 一个只看必过项的 agent 会直接把它合掉,而这正是那道门禁要拦的动作。⭐ 挂 skip-changeset 更坏 :那个标签豁免整个 job ,会连带清掉 deliberate-correction 这条拒绝 —— 用一个从来不是为这问题写的豁免去换一块绿。
④ 创业阶段不扩散 —— 三条路的面都很小:A 确认后手动合(红留作审计痕迹)· B 授权席位对「仅非必过项红、且逐条点名」的情形挂 auto-merge · C 不落,等发布消费掉那张 changeset 让卡自行消失(⚠️ 发布 PR chore: version packages #17076 已挂多日)。⛔ 都不改任何已发布面。
Prior rulings read: retirement,changeset,18318-evalcontext-no-query-api,runtime-interface-only,packages,formula,types → 72 hits; ADR-0068 D3, ADR-0076 D9, ADR-0087 D7, ADR-0129 D3, ADR-0131 D13, ADR-0029 D8, ADR-0029 D9.1, ADR-0029 D9.2
⚠️ 上列决策本席逐条看过题名,没有一条预先回答「一次 deliberate correction 的确认由谁给」 。⭐ 门禁自己的文本给了形式(「say so on the PR and get it confirmed」),⛔ 没说确认人是席位还是维护者 —— 这正是本卡要裁的那一格。
The question, in one line: PR #18905 的 deliberate-correction 确认 —— A 你/维护者确认后手动合、红留痕,B 授权本席对「仅非必过项红且逐条点名」的情形挂 auto-merge,还是 C 不落等发布?
Generated by Claude Code
⏱️ 本卡所有读数取自同一动作:2026-09-17T23:45Z,树为
origin/main=c993b7c820,被复核的 PR head =a443fc3574。承接 #18745 / PR #18834。一句话
PR #18834 给
check-adr-0087-registration.mjs加了 RETIREMENT 臂(「X→ delete the property」这类没有新名字的处方)。收紧后恰好有一张存量 changeset 从「无处方」变成「有处方」——.changeset/18318-evalcontext-no-query-api.md——而它持的豁免not-required (runtime-interface-only …)继承处方拒绝。⇒ 今天不红,但将来任何 PR 碰到packages/formula/src/types.ts并让门禁重判它时,它会被拒。读数(本席独立重跑,⛔ 非转述)
把
origin/main版与 PR head 版的findMigrationPrescription同时 import,对全量 changeset 逐个跑:触发它的那一行,逐字:
它脚上的处置,逐字节选:
为什么这不是「探测器修错了」
⭐ 那个拒绝在它自己的道理上是对的。 正文确实开了处方:它告诉消费者删掉
api属性 —— 那和「改写成x」一样是消费者要做的活,且同样与「你正文里没有处方」这个豁免条件矛盾。⇒ 诚实的修法在处置面,⛔ 不在探测器上开洞。runtime-interface-only谓词都是正面逐条验过的,作者还把探测器的漏判主动交了上去而不是让它替自己扛。缺陷在探测器,已由 #18745 收掉;剩下的只是这一张的处置被新读数反过来抵触了。处置选项(⛔ 非裁定)
packages/formula/src/types.ts的人撞上一个不是他造成的拒绝,还得自己把来龙去脉考古一遍。⭐ 先看发布窗口再动手
那张 changeset 是
@objectstack/formula的 minor,正在等发布。⇒ 一旦发布消费掉它,本卡自行消失。 接手的人先读发布窗口:若发布就在眼前,A 是理性的;若还要挂一段时间,B 便宜且一劳永逸。⇒ 这是时机问题,⛔ 不是该不该记的问题 —— 所以本卡先把它记住。边界
⛔ 本卡不授权任何人去编辑别人的 changeset 正文之外的东西,也 ⛔ 不是对 #18318 或 PR #18736 的追责。⭐ #18745 的 dev 把这份读数交回而没有顺手改,那是对的:一次探测器修复不该在路过时编辑别人的 changeset。
查重(MCP
search_issues,含 closed)以
18318/ evalcontext / changeset 处置 /runtime-interface-only被拒 / retirement 臂 等词检索,零命中。⇒ 无孪生。出处
domain:specseat 2(座位贴 #18549)复核 PR #18834 / 卡 #18745 时,dev 在open_questions第 1 问里交回并推荐 B。本席独立重跑了全量 stock(见上)确认「恰好一行移动」后立卡。os-decision-facets
domain:specseat 2)在半状态巡检 H62 指出后补上 —— ⏱️ 2026-09-18T10:08Z。⛔ 正文原有内容一字未改、未删。⭐ 本卡进决策箱是因为交付已完成、余下的是一次落地裁定(见 PR #18905),⛔ 不是实施未完成。check-empty-changeset对「改动一份 merge-base 上已存在的 changeset」必拒,而它 DELIBERATE CORRECTION 一类的补救原文是'do NOT restore it -- say so on the PR and get it confirmed'。⇒ 这条红按设计无法靠改写消除,它存在的意义就是把决定摆到人面前。本卡问的是:这次的确认由谁给、以什么形式留痕。FOREIGN_REMEDY(从 base 恢复)去做,会把一句已经变假的话放回去。Check Changeset不是必过上下文(本席逐条枚举过REQUIRED_CONTEXTS,共 7 条,它不在其中)⇒ 一个只看必过项的 agent 会直接把它合掉,而这正是那道门禁要拦的动作。⭐ 挂skip-changeset更坏:那个标签豁免整个 job,会连带清掉 deliberate-correction 这条拒绝 —— 用一个从来不是为这问题写的豁免去换一块绿。Prior rulings read: retirement,changeset,18318-evalcontext-no-query-api,runtime-interface-only,packages,formula,types → 72 hits; ADR-0068 D3, ADR-0076 D9, ADR-0087 D7, ADR-0129 D3, ADR-0131 D13, ADR-0029 D8, ADR-0029 D9.1, ADR-0029 D9.2
The question, in one line: PR #18905 的 deliberate-correction 确认 —— A 你/维护者确认后手动合、红留痕,B 授权本席对「仅非必过项红且逐条点名」的情形挂 auto-merge,还是 C 不落等发布?
Generated by Claude Code