Skip to content

#6497 之后:迁移说明探测器仍读不到「只由表头/标签起框」的改写表 —— 存量 11 条声明为 breaking 的 changeset 仍在拿豁免 #6559

Description

@os-project-manager

在实现 #6497(PR #6558)时测出来的范围外发现。未认领。

#6497findMigrationPrescription() 读懂了迁移框架标题所辖区域内的无箭头改写表(新分支 framed-table,+4 / −0,误报 0)。但「作者把改写框起来了、探测器读不到那个框」这一类,在 #6497 之后还剩两种拼写,都是在同一次全量测量里量出来的,数字口径与 #6558 一致(存量 1384 条 changeset、241 条声明 breaking、分支 3 落地之后)。

一、只由表格自己的表头单元格起框(14 条 / 其中 11 条声明 breaking)

正文里没有 ## Migration 这类标题,框是表头行自己给的,而这些词都不在现有的 MIGRATION_FRAMING_RE 里:

表头拼法 出现的 changeset
| Wrote | Write instead | data-driver-find-stream-retired.mdstorage-service-list-retired.md
| Removed | Live replacement | prune-dead-audit-config-cluster.mdprune-dead-capabilities-descriptor.mdprune-orphan-featureflag-schema.md
| you wrote | write instead | … unknown-key-strictness-automation-batch11.mdunknown-key-strictness-ui-batch13.mdunknown-key-strictness-ui-batch16.mdview-subblock-strictness-batch18.md(| You wrote | Where | Write instead |)
| Was | Now | adr-0114-field-error-catalog.md
| you wrote | on a … | now | rare-jars-shave.md

这是一条真实的房规(4 种拼法、11 条声明为 breaking 的 changeset),不是某一条 changeset 的怪癖 —— 和 #6419 当年认定 ## FROM → TO 是房规的判据同形。

二、由标签行而非标题起框(4 条 / 其中 2 条声明 breaking)

**Migration.** 独占一行,紧跟一张改写表。今天只有标题能打开框架区域,标签行不能:

  • data-driver-find-stream-retired.md —— **Migration.** + | Wrote | Write instead |,正文写着 for await (const row of driver.findStream(obj, q)) 改成分页调 driver.find(...);
  • storage-service-list-retired.md —— 同形。

(两条与第一类重叠;两类并集是 11 条声明为 breaking 的 changeset。)

影响

#6497 完全同类:门禁是前向的,这条盲区也是前向的 —— 今后任何 PR 只要把迁移说明写成 | Wrote | Write instead | 这样的表、而标题里不带迁移词,就可以合法地写下 not-required (no-migration-prescription),门禁会批准这条自相矛盾的豁免。存量侧,这 11 条今天仍落在 --audit-stockexempt-no-prescription 桶里,够不着残差面。

为什么 #6558 没有顺手做掉

刻意不做,理由是可测量的,不是省事:

  1. 需要一套新的封闭词表(老列/新列的词),而不是复用现有的框架词表。新词表有它自己的误报面,得单独量 —— 这正是 [finding][spec-tooling] ADR-0087 门的 no-migration-prescription 矛盾检查匹配的是占位符 FROM/TO,不是真实处方 —— 写得越好的处方越照不到 #6419#6148 门禁的迁移说明探测器读不到「无箭头的两列改写表」—— not-required (no-migration-prescription) 可被合法豁免绕过,存量已见 4 条同形 #6497 两次都遵守的次序。
  2. 直接复用现有框架词表去读表头是行不通的,已实测:那样只买到 1 条无判决影响的真阳性(filter-icontains-and-regex-retirement.md,不声明 breaking),却带来 1 条真实误报 —— rate-limit-config-dual-source-c9.md 的表是两个类型的对照矩阵,只因表头里有 (renamed) 一词被命中,而那个词在给列命名,不在框改写。fix(ci): ADR-0087 迁移说明探测器读得懂「无箭头的改写表」(#6497) #6558 因此拒绝了这条捷径。
  3. 误报没有诚实的出口:作者被错误拒掉一条他有权使用的豁免时,封闭词表里没有别的选项给他。所以「一条诚实收窄的探测器胜过一条吵闹的」这条结论对本单同样成立,谁来做都得先量误报。

要打败的数字(#6558 落地后重测)

  • 探测器现状:133 命中 / 101 breaking(1384 条存量、241 条 breaking);
  • 本单目标面:表头起框 14 条 / 11 breaking,标签起框 4 条 / 2 breaking,并集 11 条 breaking;
  • 另有完全无框架oldnew 清单/表 132 条 / 21 breaking —— 那是锚定框架的诚实残差,不是本单的目标,放宽到那里需要的是另一场论证。

这三组数字已写进 scripts/check-adr-0087-registration.mjs 的「残余盲区」自述(#6558),此处只是把它们立成可分诊的卡片。

复现:node scripts/check-adr-0087-registration.mjs --audit-stock,上面 11 条均不出现在残差列表里。


Generated by Claude Code

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions