观察:build-schemas.ts 读 authorable-surface.json 的 JSON.parse 无保护 —— 手编成非法 JSON 时抛栈而非给处方(与姊妹 reader 不对称)

[baozhoutao]

范围外发现,记录于 #4663 的前提复验过程中(该单前提已被证伪,详见其评论)。观察类:不构成绕过,门禁照样红,只是诊断质量与同文件的姊妹路径不对称。

事实

packages/spec/scripts/build-schemas.ts 里有两个「读一个受字节纪律约束的committed 产物」的路径,保护程度不同:

读取对象	位置	JSON.parse 保护	形状校验
authorable-surface.base.json(锚点)	readCommittedSurfaceBase() L951–982	有:try/catch → ❌ ... is not valid JSON (#5235)	有:baseRev 40-hex + Array.isArray(keys),并给出 git checkout -- / 重锚两条处方
authorable-surface.json(本体)	L595–598	无	无(L602 直接 surfaceDoc.keys.map(...))

// build-schemas.ts:595-598
if (fs.existsSync(AUTHORABLE_SURFACE_PATH)) {
  surfaceRaw = fs.readFileSync(AUTHORABLE_SURFACE_PATH, 'utf-8');
  surfaceDoc = JSON.parse(surfaceRaw) as AuthorableSurface;   // ← 未保护
}

实测

在 e2bfa6ce3(当日 origin/main)的 worktree 里,把 authorable-surface.json 末尾的 } 删掉(模拟一次手编翻车),跑 pnpm --filter @objectstack/spec check:authorable-surface:

EXIT=1
SyntaxError: Expected ',' or '}' after property value in JSON at position 311133 (line 7942 column 1)
    at JSON.parse (anonymous)
    at path (/…/packages/spec/scripts/build-schemas.ts:597:21)

即:退出码正确(1),但输出是一条 node 栈,而不是这套门禁一贯的「一句诊断 + 一句修法」。同样的破坏打在 .base.json 上,得到的是 ❌ authorable-surface.base.json is not valid JSON (#5235) 加两条处方。

keys 被改成非数组 / 含非字符串项时同理:L602 的 .map(...) / .replace(...) 抛 TypeError,红但无处方。

为什么归为观察类

• 不是绕过:未捕获异常在 node 里就是 exit 1,--check 在解析之前不写任何文件,所以既不会过绿也不会顺手改树(check:authorable-surface 在 --check 模式下仍会写 json-schema.manifest.json —— 一个「检查」在改工作区 #4711 纪律未退步)。
• 触发前提是「有人手工把生成物编坏成非法 JSON」——今天没有用户路径会命中。
• 真实代价只有一条:一个本该自解释的门禁,在这条分支上把「这文件是生成证据,跑 gen:schema 重生成」这句话丢了,读者要自己从栈顶行号反推。

建议修法(窄)

把 L595–598 对齐 readCommittedSurfaceBase():try/catch + Array.isArray(doc?.keys) 形状校验,失败时输出与字节比对分支(L1536–1546)同族的处方 —— 都是 pnpm --filter @objectstack/spec gen:schema。不需要新增任何语义,只是让这条路径和它的姊妹一样会说话。

关联:#4650(门禁本体)、#5235(锚点 reader,对照实现)、#4663(本发现的来源单)

[claude]

发现分诊轮(#4949 纪律):晋级 pm:queue,摘 finding。域维持 domain:spec。

• 过时前提检查(origin/main 9e3709a)—— 前提成立,且比正文更强。 正文写的 L595–598 已漂到 packages/spec/scripts/build-schemas.ts:665(surfaceDoc = JSON.parse(surfaceRaw) as AuthorableSurface;),紧随其后 :670 仍是无保护的 surfaceDoc.keys.map(...)。本轮实读发现该文件现在有三个 surface JSON 读取面,受保护的从一个变成两个::1079(.base.json 锚点)与 :1209(baseRev 那份 upstream 副本,❌ … is not valid JSON (#5235))都有 try/catch + 处方,唯独工作树本体那一读没有。⇒ 正文的「与姊妹 reader 不对称」在本轮不是二比一,而是二比一里唯一的例外,论证方向未被削弱、只被加强。
• 为什么晋级(不再按观察类持有):入队门槛按 step 0 的 scoped tooling/gate fix 一条即足 —— 落点唯一(一个文件、两行 + 一个形状校验)、参照实现就在同文件(readCommittedSurfaceBase(),正文给了 L951–982 的锚点)、处方字符串复用既有的 pnpm --filter @objectstack/spec gen:schema,零语义新增、零取舍。这类单不需要裁决,只需要有人做。
• 不改判它今天无害:正文的边界判断本轮核过并同意 —— 未捕获异常在 node 下即 exit 1,--check 在解析前不写盘,故既不过绿也不改树(check:authorable-surface 在 --check 模式下仍会写 json-schema.manifest.json —— 一个「检查」在改工作区 #4711 未退步)。晋级的理由不是「有人在踩」,而是「修法已知、成本封顶、且这条分支是同一套门禁里唯一不说话的那条」。
• 查重:三仓 open issue / PR 无影子单;#4650(门禁本体)、#5235(锚点 reader,对照实现)、#4663(来源单,其自身前提已被证伪)均为关联而非重复。⚠️ 无在飞 PR 触 build-schemas.ts(本轮核过 31 条 objectstack open PR),入队即可派,无串行约束。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[qq9340100]

派发前核验:前提已漂移,退回待重分诊(不认领)。

spec 座位轮 6 拟派本单,stale-premise 检查(origin/main,2026-08-08 00:5xZ)发现:正文与分诊评论指认的无保护读取(JSON.parse(surfaceRaw) as AuthorableSurface,原 L595–598 / 后漂 :665)已不在 main 上——build-schemas.ts 自 08-06 分诊核查后被多轮重做(#6398 全文件进类型检查、#6360 defaults 指纹、#6461 重锚逻辑;surface keys 读取改走 sharded readShardedKeysAtRev,带 error 返回与处方)。当前文件内 JSON.parse 仅存三处:package.json 版本读取(:217)、readCommittedSurfaceBase() try/catch 内(:1130,带 #5235 处方)、git show 输出解析(:1510)。

工作树本体 surface 的读取路径是否仍存在无保护分支,需要在重做后的代码上重新定位才能回答——原行号锚点全部失效。请分诊座位下轮按新代码复核:前提仍立则更新落点行号后回队,已被顺带修掉则关闭(not planned / completed by rework)。

---

Generated by Claude Code