观察项:json-schema.manifest.json 没有 #4662 那样的「整文件规范形态」比对 —— 不改变键集的手编至今无人可见 #5972

Activity

1. baozhoutao

   added

   finding

   on Aug 6, 2026
2. claude

   added

   domain:spec-tooling

   on Aug 6, 2026
3. claude commented on Aug 6, 2026

   

   claudeBot

   on Aug 6, 2026 – with Claude

   Contributor

   More actions

   发现分诊轮:持有(留 finding)+ 补域 domain:spec-tooling。

   • 域锚定:落点 packages/spec/scripts/build-schemas.ts(manifest 写触发条件那一段)—— 属 spec-tooling 座位的文件面(packages/spec/scripts/**),⛔ 不落 domain:spec(不动 *.zod.ts,不改任何可授权表面)。
   • 为什么还留着:正文的影响评估诚实且经得起复核 —— 三种手编(重排 schemas 数组、缩进/尾换行、重复条目)都不改变任何门禁判定,也不改变消费者行为(manifest 只被 build-schemas.ts 自己读),今天为零。这不是缺陷,是同一文件家族里两种严格度并存(authorable-surface.json 自 feat(spec)!: 双源 C5 收敛 — ActivationEventSchema 归 ./kernel 结构化形状,./studio re-export (#4653) #4662 起整文件比对,manifest 只比键集 + json-schema.manifest.json 的「deliberate removal」删行仍是纪律而非门禁 —— #4650 的同类洞,上移一层(整 schema 级) #4725 的 description 一项)。
   • 为什么不现在做:改法本身很小(合并成「整文件 vs 规范序列化」比对,沿用 check:authorable-surface 在 --check 模式下仍会写 json-schema.manifest.json —— 一个「检查」在改工作区 #4711 分叉),但代价是任何格式漂移都要求跑一次 gen:schema,而 spec 生成物按 category 分片：拆掉三个单体 ratchet 文件的合并队列串行税（维护者 2026-08-06 已拍板） #5837(按 category 分片三个单体 ratchet)与 投影类生成物是否该退出仓库 —— 分清「记忆」与「投影」,前者必须留在 PR 粒度,后者可以 CI 重算 #4676(投影类生成物是否退出仓库)都会重新动这个文件的形状。先动会做两遍。
   • 重启条件:spec 生成物按 category 分片：拆掉三个单体 ratchet 文件的合并队列串行税（维护者 2026-08-06 已拍板） #5837 或 投影类生成物是否该退出仓库 —— 分清「记忆」与「投影」,前者必须留在 PR 粒度,后者可以 CI 重算 #4676 任一落地时并入 —— 谁先落地谁最省事地把两边严格度对齐;或在此之前出现第一例真实的手编漂移(重复条目最可能)。
   • 前提检查:来源单 json-schema.manifest.json 的「deliberate removal」删行仍是纪律而非门禁 —— #4650 的同类洞,上移一层(整 schema 级) #4725 的 descriptionStale 已在 manifest 写触发条件里(正文引用即当前形态),feat(spec)!: 双源 C5 收敛 — ActivationEventSchema 归 ./kernel 结构化形状,./studio re-export (#4653) #4662 的整文件比对仍在 authorable-surface 侧 —— 两种严格度并存的事实成立。
   • 查重:feat(spec)!: 双源 C5 收敛 — ActivationEventSchema 归 ./kernel 结构化形状,./studio re-export (#4653) #4662 / json-schema.manifest.json 的「deliberate removal」删行仍是纪律而非门禁 —— #4650 的同类洞,上移一层(整 schema 级) #4725 / spec 生成物按 category 分片：拆掉三个单体 ratchet 文件的合并队列串行税（维护者 2026-08-06 已拍板） #5837 / 投影类生成物是否该退出仓库 —— 分清「记忆」与「投影」,前者必须留在 PR 粒度,后者可以 CI 重算 #4676 已在正文互链,三仓无独立重复单。

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

   ---

   Generated by Claude Code
4. claude commented on Aug 7, 2026

   

   claudeBot

   on Aug 7, 2026 – with Claude

   Contributor

   More actions

   Findings triage (#4949 discipline): close (completed) — the gap this finding records has been closed, incidentally, by #5837.

   Restart condition fired, and overshot it. The 2026-08-06 13:57Z hold said: 「#5837 或 #4676 任一落地时并入 —— 谁先落地谁最省事地把两边严格度对齐」. #5837 is closed/completed (2026-08-07T00:28:11Z). It did not merely create the opportunity to align the two strictness levels — it aligned them, because the alignment fell out of the reshard for free.

   Stale-premise check (origin/main @ 42af12f, read from the tree). The premise is not merely stale — the file it is about no longer exists:

   • packages/spec/json-schema.manifest.json (the monolith) is absent from main. The manifest is now 14 category shards under packages/spec/json-schema.manifest/ (ai, api, automation, cloud, data, identity, integration, kernel, qa, security, shared, studio, system, ui). The authorable surface was resharded the same way (15 shards).

   • The write trigger quoted in the body — manifestChanged = !manifest || added.length > 0 || renamedAway.length > 0 || descriptionStale — is gone. packages/spec/scripts/build-schemas.ts:560 now reads:

     const canonicalManifestTexts = schemaManifestShardTexts([...generatedKeys].sort());
     const staleManifestShards = [...canonicalManifestTexts]
       .filter(([name, text]) => manifestTexts?.get(name) !== text)
       .map(([name]) => name);
     const manifestChanged =
       manifestTexts === null || added.length > 0 || renamedAway.length > 0 ||
       staleManifestShards.length > 0 || orphanManifestShards.length > 0;

     That is a byte-for-byte comparison against the canonical serialization, per shard — structurally the same check authorable-surface has had since feat(spec)!: 双源 C5 收敛 — ActivationEventSchema 归 ./kernel 结构化形状,./studio re-export (#4653) #4662. The script says so itself, in the comment directly above (:551–:556): "Comparing BYTES rather than key sets is what keeps the shards' own description part of the artifact … Sharding made the comparison stricter for free: hand-formatting inside a shard is now caught the same way feat(spec)!: 双源 C5 收敛 — ActivationEventSchema 归 ./kernel 结构化形状,./studio re-export (#4653) #4662 catches it in the authorable surface."

   All three named blind spots are now covered. Checked one by one against the new trigger rather than assumed from the comment:

   body's blind spot	status under the sharded writer
   reordering the schemas array	canonical text is built from [...generatedKeys].sort() ⇒ any reorder is a byte diff ⇒ staleManifestShards ⇒ reported
   indentation / trailing-newline edits	byte diff ⇒ reported
   duplicate entries (the one no set-comparison could ever see)	byte diff ⇒ reported. This was the sharpest of the three and it is the one the reshard closes most cleanly

   --check mode even distinguishes the case explicitly (:576): "does not match its generated form (the key set is current)" — the exact failure the finding said nothing would say anything about.

   Why closed rather than promoted. There is no work left. The two-strictness-levels asymmetry the finding recorded is gone, and the resolution came through the route the hold predicted (「谁先落地谁最省事地把两边严格度对齐」) — it just cost nothing to whoever landed #5837, which is why it happened silently and needs saying here. Nothing to dispatch.

   ⚠️ Attribution caveat, stated rather than glossed. git log -- packages/spec/json-schema.manifest/kernel.json points at db8c285, whose subject is "fix(plugin-auth): SMS daily-quota refusal answers 429, not 500" — merge-queue batching makes single-commit attribution unreliable here, so the evidence above is the state of the tree, not a commit message. The verdict rests on the code at build-schemas.ts:551–:565 and the absent monolith, both read directly from origin/main; it does not rest on which squash carried them.

   Maintainer veto window applies as usual (#4949): reopen if you read the alignment differently.

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

   ---

   Generated by Claude Code
5. claude

   closed this as completedon Aug 7, 2026
6. claude

   removed

   finding

   on Aug 7, 2026