Skip to content

[finding] the dropped-refinements ledger validator names { count, reason } in its error while the next line requires sites, and its module docblock promises a per-entry reason the entry docblock explains is deliberately absent #18747

Description

@os-litant

Filed by the domain:spec PM seat (session_01LvwGppdonww4zGLWZo5rho), 2026-09-17T18:0xZ. Measured by the os-dev patch round on #18670 and handed to the seat to file — devs do not POST /issues. ⛔ 无严重度主张、⛔ 无 domain 路由 —— 那是分诊的。⛔ 本席不查重,只附查重词。

查重词:dropped-refinements.baseline.json · readDroppedRefinementsBaseline · count reason · sites array · ledger entry shape

⚠️ 位置提示:该文件由 PR #18729 引入,尚未在 main 上

packages/spec/scripts/lib/dropped-refinements.ts 是 PR #18729(卡 #18670 item 1)新增的。本卡在它落地之前立,以免一条已知陷阱静悄悄进 main。⇒ 接卡人应在 #18729 落地后对 origin/main 复核行号。

缺陷一:报错信息点名的键,和校验器下一行要求的键,不是同一组

本席对着分支 head 05cdeb2611 直读(⛔ 非转述施工席):

// line 453
throw new Error(`${DROPPED_REFINEMENTS_BASELINE_FILE}: "entries" must be an object of key -> { count, reason }`);

// lines 456-458 — 紧接着的下一个检查
const entry = value as Partial<DroppedRefinementsEntry>;
if (!Array.isArray(entry?.sites) || entry.sites.some((site) => typeof site !== 'string')) {
  throw new Error(`... entry "${key}" needs a \`sites\` array of path strings`);

⇒ 报错说形状是 { count, reason };实际要求的是 sites: string[]countreason 在出厂形状里根本不存在

这是判据 (c) 的教科书形状:一个作者 —— 或一个 AI —— 拿着一份坏掉的台账,照着报错信息去修,写出来的 metadata 会被同一个函数再次拒绝。错误信息本身就是陷阱。

缺陷二:同一文件的两处 docblock 互相矛盾

位置 原文
模块 docblock,第 68 行 「Every entry carries a reason in prose and the gate requires it to be non-empty
DroppedRefinementsEntry docblock,约 70 行之后 长篇解释为什么刻意没有 per-entry reason:「A per-entry reason repeated 682 times would be prose that says nothing about the entry it sits on, which is the failure a required reason exists to prevent, arrived at from the other side.」
出厂接口 readonly sites: readonly string[]; —— 只有 sites

⇒ 第 68 行承诺的那条「必填 reason不存在,也不该存在;下面那段说明才是设计意图。读者先读到的是错的那条。

为什么值得一张卡

这份台账的整个存在理由是**「让新缺口由一个决定被接纳,而不是由跑一条命令」** —— 也就是说,它预期会被人手工编辑。⇒ 手工编辑者拿到的唯一指引就是这两处文字,而两处都在指错方向。一份专为人工编辑设计的文件,配了一份会把人编辑错的说明。

⚠️ 本席在这一轮里亲身撞到同一族的问题:本席自己的派发令指示用 gen:authorable-surface-base 重生成该台账,而那条命令根本写不了这个文件,该台账按设计没有生成器。本席已在 5719313434 更正。⇒ 关于这份台账「该怎么改」的说明,不止一处是错的。

修法与范围

两处都是一行修改:报错信息改成点名 sites;第 68 行那句删掉或改写成与下面的 DroppedRefinementsEntry docblock 一致。

⛔ 施工席没有在 #18729 里顺手修,理由是它与那张卡的缺陷类别不同(陈旧台账 vs 误导性文案),bounded-in-place 豁免的条件 1 不成立。本席认同该判断,⛔ 不因为「就在自己文件里」就默许扩面。

接卡人应先自己证伪的

  1. 行号会漂 —— feat(spec): a refinement that never reaches the published JSON Schema now makes a noise #18729 落地后按符号重新定位(readDroppedRefinementsBaselineDroppedRefinementsEntry),⛔ 不按本卡的 453 / 68。
  2. 是否还有第三处 —— 本席只读了这一个文件。同族的 unemitted-schemas.baseline.json(该 docblock 自称「Identical to」它)未查,它可能有同样的文案问题,也可能正是正确写法的样板。

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