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

Activity

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

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions