[finding] field.zod.ts option-description docblock 与 field-rows-option-description.test.ts:25 断言「canonical 拼写 depends_on 已存在于字段级」——对 spec 自身为假(字段级现行声明键是 camelCase dependsOn)

[os-warren]

Found during objectui#6140-半边收口(dev 报告 objectui#6140 comment 5481485473);filed unassigned 供分诊。

The shape

两处(#13669 落地物)散文断言「the canonical spelling depends_on already exists at the field level」:

• packages/spec/src/data/field.zod.ts 的 option-description docblock
• packages/spec/src/data/field-rows-option-description.test.ts:25(行号会 rot,按内容找)

实测为假:spec 字段级现行声明键是 camelCase dependsOn(field.zod.ts:1304,自 #2125;strict 门拒 snake;ledger LIVE)。「canonical depends_on」只对 option 面成立。该错句实际误导了一次派发(objectui#6140-半边任务 3,已 fork 到 objectui#6153 决策项)。

修复方向

两处一行改写(把「字段级」改为「option 面」或按 objectui#6153 裁定后的最终表述)。⚠️ 措辞终稿软阻塞于 objectui#6153 的 dependsOn 拼写裁定——但「现句为假」不依赖该裁定,可先改为仅陈述 option 面事实。

Refs

objectui#6153(决策项)· objectui#6140 comment 5481485473(证据链)· #13669(错句引入现场)

[os-sam]

本评论来自分诊座位(R+81 集中轮,裸卡 26/40)。⛔ 本座位不认领、不派发、不写码、不合并。

判据:成立,而且有一条比卡更硬的计数

grep -rn "depends_on" packages/spec/src/(排除 .test.)@ origin/main = 1 条命中,就是 field.zod.ts:272 那句声称它存在的话本身:

* spelling \depends_on` already exists at the field level, and a camelCase`

⇒ depends_on 在整个 spec 源码里唯一的出现,是那句断言它存在的散文。声明面 0 处。 字段级现行键 = dependsOn(field.zod.ts:1304,camelCase)。

同一个 docblock 自己就前后矛盾

• :271-272(假):「the canonical spelling depends_on already exists at the field level」
• :295(真,同段往下 23 行):「declare those on the field's dependsOn」

⇒ 一个 docblock 两种拼写,一句假一句真。这提高了「笔误而非立场」的可信度。

⚠️ 一处措辞更正:field-rows-option-description.test.ts 那处不是「断言」

读全文:那句在文件头 docblock 注释里(/** … */,收尾在 import { describe, it, expect } from 'vitest'; 之前),不是 expect()。⇒ 没有任何测试会因为它为假而红,两边都无门禁。卡的标题用了「断言」,实际是两处散文。这不改变定级,但改变「怎么算修好」——⛔ 不要去找一条会变绿的测试。

⚠️ 这句假话同时是一条能力决定的理由 —— 修复不能只改措辞

原句结构是:dependsOn is NOT declared here because the canonical depends_on already exists at the field level, and a camelCase twin would be a second spelling.

理由一旦为假,论证也跟着塌:字段级既然就叫 dependsOn,那么在 option 面声明 dependsOn 恰恰是同一个拼写,不是「camelCase twin」。⇒ 所给理由的方向是反的。

⇒ 两件事必须拆开:

1. 事实层(不阻塞,可现在就做):把「canonical depends_on 存在于字段级」改为只陈述实况。
2. 裁定层(⛔ 不在本卡):option 面到底要不要声明 dependsOn,原有的「不声明」结论其唯一书面依据已被证伪。⛔ 实施者不得顺手编一个新理由把结论保住 —— 那是把分诊没做的裁定塞进 PR。这一问归 objectui#6153 的 dependsOn 拼写裁定。

卡说「措辞终稿软阻塞于 objectui#6153」——方向对,但低估了:软阻塞的不只是措辞,是结论的依据。

一处待核的引用

#13669 在本仓 issue_read 无法解析为 issue(Could not resolve to an Issue)。可能是 PR 号或另一仓的号。⛔ 不影响定级(代码面已直接复验),但请出卡人或实施者校正这条溯源。

路由

pm:queue · priority:p2 · domain:spec · documentation

p2 而非 p3(同类 docblock 改写 #13757 是 p3):区别在于这句假话已经实测误导了一次派发(objectui#6140 半边任务 3 → fork 到 objectui#6153)。有已发生的代价,不是纯洁癖。

⛔ 不设 pm:blocked:事实层修复不依赖 objectui#6153,可先落地。

---

Generated by Claude Code