保存成功的回执一律自称 "customization overlay",包括注册表声明 supportsOverlay:false 的类型(object / flow / action / seed / hook)

[os-zhuang]

观察类发现,由 #5086 的正文点出、在修 #5086(PR #5263)时确认。纯文案,不影响持久化行为,所以单独记录而不搭车。

事实

packages/metadata-protocol/src/protocol.ts 的 saveMetaItem 成功回执只有两种句式,都写死了 "customization overlay":

Saved customization overlay (org=<id>, state=active) — type=…, name=… [seq=N]
Saved customization overlay (env-wide, state=active) — type=…, name=… [seq=N]

而 DEFAULT_METADATA_TYPE_REGISTRY 里有一批类型明确声明 supportsOverlay: false,却按设计可以运行时写入:object、field、hook、seed、mapping、flow、action。对这些类型,一次全新创建(不是任何东西的 overlay)也会被回执成 "saved a customization overlay"。

真实 boot 实测(showcase,pnpm dev -- --fresh):

PUT /api/v1/meta/view/rc3_probe_view
→ 200 {"success":true,…,"message":"Saved customization overlay (env-wide, state=active) — type=view, name=rc3_probe_view [seq=1]"}

view 恰好是 supportsOverlay: true,回执没问题;把同一句话发给 object / flow 的新建就不成立了。

为什么不是"顺手改一下"

supportsOverlay 与 allowOrgOverride 在 spec 的 TSDoc 里是两件事:前者描述 loader 的合并能力,后者是运行时写入的许可,而且只有后者被明确指定为 403 not_overridable 的判据。所以这句回执要说清楚的是三件事之一 —— 覆盖了一个 artifact / 新建了一条 DB-only 记录 / 写了一条 per-org 行 —— 而这三者在写路径里是能分辨的(isArtifactBacked + organizationId 已经算过)。也就是说这是"回执可以说真话但没说"的问题,不是术语挑刺。

#5086 关心的那一半(job / agent 根本不该写成功)已由 PR #5263 修掉;剩下的就是这句措辞。

建议(留给 triage)

按已算出的事实分句:artifact-backed ⇒ Saved customization overlay;无 artifact 的新建 ⇒ Created <type> '<name>';org 维度照旧附在括号里。改动面是 2 处 message 模板 + 对应断言。

参考:#5086 / PR #5263。