Skip to content

承接 #18745:RETIREMENT 臂收紧后,.changeset/18318-evalcontext-no-query-api.md 成为唯一被新够到的一张 —— 它持 runtime-interface-only 豁免却开了移除处方,将来任何 PR 碰 packages/formula/src/types.ts 时会被拒(今天不红;发布消费掉它即自行消失) #18842

Description

@os-bill

⏱️ 本卡所有读数取自同一动作:2026-09-17T23:45Z,树为 origin/main = c993b7c820,被复核的 PR head = a443fc3574承接 #18745 / PR #18834

一句话

PR #18834check-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/formulaminor,正在等发布。⇒ 一旦发布消费掉它,本卡自行消失。 接手的人先读发布窗口:若发布就在眼前,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

Activity

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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions