⏱️ 本卡所有读数取自同一动作:2026-09-17T14:42Z。逐条本席第一手实测,亮控与暗控都写在读数旁边。
一句话
.meta() 标记会原样进已发布的 packages/spec/json-schema/,而该目录一个 tracked 文件都没有 —— 于是「第一个真去标键的卡」会改变已发布的包内容,却不产生任何 git diff,因此读 diff 的门禁一个都看不见。
⚠️ 立卡席的更正(⏱️ 2026-09-18T11:53Z,⛔ 原文一字未删):上面这句里的「不产生任何 git diff」与下表的「git diff 没有任何一行」太强,实测为假。PR #19016 的 dev 顶了回来,本席复核后采纳 —— 见文末的「更正」节。幸存下来的、且仍然为真的那一半是:⛔ 动的是 json-schema/ 这个产物,而它没有任何 tracked 表示 ⇒ 没有任何 diff 能显示它动过;而另外两处看得见的变化恰恰是陷阱 —— 它们让发布故事读起来像已经讲完了。
实测(第一手,四行一组,亮控暗控齐)
packages/spec 解析到的 zod 版本:4.4.3
z.number().meta({ dimensionless: 'failed attempts' })
-> {"type":"number","dimensionless":"failed attempts"} ← 进去了
⭐ LIT .meta({ externalVocabulary: 'CORS max-age' })
-> {"type":"number","externalVocabulary":"CORS max-age"} ← 已知在场的姊妹,同样进
⭐ DARK .meta({ totallyFabricatedMarkerXyz: 'control' })
-> {"type":"number","totallyFabricatedMarkerXyz":"control"} ← ⚠️ 伪造的名字也照样进
⭐ DARK 没有 .meta()
-> {"type":"number"} ← 干净
⇒ 这条通道是通用的,⛔ 不是一张 marker 白名单。(这一点本身是设计如此并有文档:xRef / xExpression / xEnumDeprecated 走的就是同一条通道 —— 所以「通道是通用的」⛔ 不是缺陷。)
缺陷在它与发布面的组合上
packages/spec/package.json 的 files[] 含 'json-schema' ✅ 实测
packages/spec/json-schema/ 的 tracked 文件数 0 实测
⭐ 亮控 同一把 ls-tree 在 packages/spec/api-surface/ 17
两条合起来:json-schema/ 是发布内容(在 files[] 里),但不在 git 里(生成物)。⇒ 某天有人给一个键挂上 .meta({ dimensionless: '…' }):
| 谁会看见 |
看见吗 |
已发布的 json-schema/ 内容 |
变了 |
git diff |
没有任何一行 ⚠️ 更正:标记那一行的编辑是看得见的,见文末 |
| 读 diff 的 changeset 门禁 |
⚠️ 更正:看得见那次编辑;看不见的是 json-schema/ 这个产物动没动 |
「scripts/** 不在 files[] 里,所以 skip-changeset」这条推理 |
看上去仍然成立 |
⇒ 一次已发布内容的变更会带着一条读起来完全正确的 skip-changeset 理由发出去。
⛔ 今天树上没有错的东西 —— 这一点要说清楚
PR #18684(卡 #18500)一个键都没标,本席实测:diff 恰 2 个文件,零个落在 files[] 上;check:docs 绿 ⇒ 零张参考页移动。⇒ 它的 skip-changeset 是实测正确的,⛔ 本卡不指向它。
本卡指向的是「第一个真去标键的卡」 —— 那张卡欠的申报是对两个发布者的,不是一个:渲染出来的参考页,以及已发布的 JSON Schema。
与 #18665 是同一个形状,这也是本席不同意「不立卡」的理由
⚠️ 交付本读数的 dev 自判为「noted, not filed」,理由是:没有复现、没有被违反的成文契约、危害形状是「元数据被发布」而不是被拒绝或被静默丢弃。三条都属实。
本席仍然立卡,理由只有一条:这是一个「义务在以后才触发、而那时没有任何东西会检查它」的缺口 —— 和本席今天立的 #18665(预申报派生物臂能把 skills/** 长进实际文件面,档位与净增行数预算两件义务一起漏)是同一个形状。这类缺口的代价不在今天,在没人记得的那一天;而「没有复现」恰恰是因为还没人走到那一步。
建议的修法(⛔ 非裁定,列出取舍)
- A(最小):在
check-duration-unit-keys.ts 的 marker 读者旁写一行 docblock,点名「标一个键会改变已发布的 json-schema/,申报要对两个发布者做」。代价几乎为零,但它是散文,⛔ 没有执行力。
- B:给 changeset 门禁加一条:diff 里出现新的
.meta({ <marker> }) 键位 ⇒ 要求非 skip-changeset。⚠️ 这条要先量误报率(xRef / xExpression 等同通道 marker 会不会大面积命中)。
- C:把
packages/spec/json-schema/ 纳入版本管理,让发布内容的变化在 diff 上可见。⚠️ 代价最大,且与「它是生成物」的既有决定相冲突 —— ⛔ 本席不推荐,列出只为把取舍写全。
⛔ 本席不替维护者选;三条可叠加。
查重(MCP search_issues,含 closed,28 条命中逐条读过)
出处
domain:spec seat 2(座位贴 #18549)复核 PR #18684 / 卡 #18500 时,dev 回答本席派发令里的第 2 问带回的读数;本席用自己的探针复测并补了两个暗控。⛔ 本卡不归 spec 车道执行也可以 —— 归属由分诊定。
⚠️ 更正(立卡席,⏱️ 2026-09-18T11:53Z) —— 本卡原文的一个论断太强,实测为假
出处:PR #19016(本卡的 A)那一轮 dev 在报告里点出,本席逐条复核后采纳。⛔ 原文一字未删,更正以本节为准。
⏱️ 2026-09-18T11:53Z 本席现读 origin/main = 43f4766889:
packages/spec/package.json 的 files[] 含 "src/**/*.zod.ts" true
⇒ 给一个 spec 键挂 marker,改的那个 .zod.ts **本身就是已发布文件** ⇒ 那一行编辑在 diff 上**看得见**
content/docs/references/ 的 tracked 文件数 224
packages/spec/scripts/lib/schema-section.ts:256 externalVocabularyNote(prop)
:257 const standard = prop?.externalVocabulary; "dimensionless" 在该文件 6 次
⭐ LIT 同文件 "describe" 10 次 · ⭐ DARK 伪造 marker 0 次
⇒ 渲染器**确实读**这两个 marker ⇒ 标键之后那张 tracked 参考页**会动**
⚠️ 今天 content/docs/references/ 里 "externalVocabulary" 读 0 —— 因为**还没有任何键被标**(本卡的前提),
⛔ 不是因为渲染器不读它。这两个 0 的区别就是本卡这次栽跟头的地方。
⇒ ⭐ 幸存的发现(更窄,但仍然是真的):packages/spec/json-schema/ 在 files[] 上、却没有任何 tracked 表示 ⇒ 没有任何 diff 判据能够触及它动没动。⛔ 盲区是那个产物,⛔ 不是那次编辑。
⇒ ⚠️ 这条更正同时改变了选项 B 的成色:一个读 diff 的门禁并不瞎 —— 标一个 spec 键必然要编辑一个已在 files[] 上的 .zod.ts。dev 在 13175 个非合并提交上量了 B 的误报面(宽判据 41 次命中 / 10 次误报 = 24.4%;窄判据 6 次 / 3 次误报 = 50%,且宽判据 10 次误报里有 7 次是改 scripts/ 的提交,含这把门禁自己的自测夹具)。⇒ B 在这条更正之后是冗余的,而只有 C(给 json-schema/ 一个 tracked 的摘要/投影,像 json-schema.manifest/ 那样)才够得着那个盲区。
⛔ 本席仍然不替维护者选;上面只是把三条路的成色按实测重新摆了一次。
Generated by Claude Code
⏱️ 本卡所有读数取自同一动作:2026-09-17T14:42Z。逐条本席第一手实测,亮控与暗控都写在读数旁边。
一句话
.meta()标记会原样进已发布的packages/spec/json-schema/,而该目录一个 tracked 文件都没有 —— 于是「第一个真去标键的卡」会改变已发布的包内容,却不产生任何 git diff,因此读 diff 的门禁一个都看不见。实测(第一手,四行一组,亮控暗控齐)
⇒ 这条通道是通用的,⛔ 不是一张 marker 白名单。(这一点本身是设计如此并有文档:
xRef/xExpression/xEnumDeprecated走的就是同一条通道 —— 所以「通道是通用的」⛔ 不是缺陷。)缺陷在它与发布面的组合上
两条合起来:
json-schema/是发布内容(在files[]里),但不在 git 里(生成物)。⇒ 某天有人给一个键挂上.meta({ dimensionless: '…' }):json-schema/内容git diff没有任何一行json-schema/这个产物动没动scripts/**不在files[]里,所以skip-changeset」这条推理⇒ 一次已发布内容的变更会带着一条读起来完全正确的
skip-changeset理由发出去。⛔ 今天树上没有错的东西 —— 这一点要说清楚
PR #18684(卡 #18500)一个键都没标,本席实测:diff 恰 2 个文件,零个落在
files[]上;check:docs绿 ⇒ 零张参考页移动。⇒ 它的skip-changeset是实测正确的,⛔ 本卡不指向它。本卡指向的是「第一个真去标键的卡」 —— 那张卡欠的申报是对两个发布者的,不是一个:渲染出来的参考页,以及已发布的 JSON Schema。
与 #18665 是同一个形状,这也是本席不同意「不立卡」的理由
本席仍然立卡,理由只有一条:这是一个「义务在以后才触发、而那时没有任何东西会检查它」的缺口 —— 和本席今天立的 #18665(预申报派生物臂能把
skills/**长进实际文件面,档位与净增行数预算两件义务一起漏)是同一个形状。这类缺口的代价不在今天,在没人记得的那一天;而「没有复现」恰恰是因为还没人走到那一步。建议的修法(⛔ 非裁定,列出取舍)
check-duration-unit-keys.ts的 marker 读者旁写一行 docblock,点名「标一个键会改变已发布的json-schema/,申报要对两个发布者做」。代价几乎为零,但它是散文,⛔ 没有执行力。.meta({ <marker> })键位 ⇒ 要求非skip-changeset。xRef/xExpression等同通道 marker 会不会大面积命中)。packages/spec/json-schema/纳入版本管理,让发布内容的变化在 diff 上可见。⛔ 本席不替维护者选;三条可叠加。
查重(MCP
search_issues,含 closed,28 条命中逐条读过).refine()carries the rule — an author validating againstpackages/spec/json-schema/**gets a green for metadata the runtime refuses #18670(open)「the published JSON Schema is WIDER than the zod schema it is generated from wherever a.refine()carries the rule」—— 同一个发布面,不同的缺陷:它讲的是.refine()的规则到不了 JSON Schema,本卡讲的是.meta()的标记到得了、而且没人看得见它到了。json-schema/是一个没人对账的发布产物」,⇒ 若维护者想把它们并成一张「发布产物对账」的卡,那是合理的,⛔ 但本席不代并。hookmetadata type's authorable keys reach no key-level ratchet —HookSchemaemits no JSON Schema, soauthorable-surface/holds zerodata/Hook:keys #16906 · [finding]src/migrations/spec-changes.tsexports five Zod schemas for the ADR-0087 D4spec-changes.jsonrelease manifest, and none of them is published —migrationsis absent from build-schemas.ts's Protocol namespace map #16514 —— 讲的是某些 schema 压根不发 JSON Schema,方向相反。出处
domain:specseat 2(座位贴 #18549)复核 PR #18684 / 卡 #18500 时,dev 回答本席派发令里的第 2 问带回的读数;本席用自己的探针复测并补了两个暗控。⛔ 本卡不归 spec 车道执行也可以 —— 归属由分诊定。出处:PR #19016(本卡的 A)那一轮 dev 在报告里点出,本席逐条复核后采纳。⛔ 原文一字未删,更正以本节为准。
⏱️ 2026-09-18T11:53Z 本席现读
origin/main=43f4766889:⇒ ⭐ 幸存的发现(更窄,但仍然是真的):
packages/spec/json-schema/在files[]上、却没有任何 tracked 表示 ⇒ 没有任何 diff 判据能够触及它动没动。⛔ 盲区是那个产物,⛔ 不是那次编辑。⇒⚠️ 这条更正同时改变了选项 B 的成色:一个读 diff 的门禁并不瞎 —— 标一个 spec 键必然要编辑一个已在
files[]上的.zod.ts。dev 在 13175 个非合并提交上量了 B 的误报面(宽判据 41 次命中 / 10 次误报 = 24.4%;窄判据 6 次 / 3 次误报 = 50%,且宽判据 10 次误报里有 7 次是改scripts/的提交,含这把门禁自己的自测夹具)。⇒ B 在这条更正之后是冗余的,而只有 C(给json-schema/一个 tracked 的摘要/投影,像json-schema.manifest/那样)才够得着那个盲区。⛔ 本席仍然不替维护者选;上面只是把三条路的成色按实测重新摆了一次。
Generated by Claude Code