docs/spec: PLUGIN_STANDARDS.md §5.1/§5.2/§5.4 把 Hot Reload 与 Plugin Isolation 标为 ✅,但 PluginHotReloadSchema / PluginSandboxingSchema 全仓零 runtime reader(ADR-0049)

[xuyushun441-sys]

#4832 核实过程中的范围外发现,只记录不修。

#4832 本身已被 PR #4878(#4834)顺手解决:§5.3 已改写为 REMOVED,§5.4 的 Dynamic Loading 行已由 ✅ 改为 ❌。但同一张 §5.4 表格里,紧邻的两行仍是 ✅,而它们指向的 schema 同样没有任何 runtime 读者 —— 这是 #4832 指控的那个失败模式(ADR-0049 false compliance / ADR-0033 AI 误读),只是因为 schema 还“存在”,裸名扫描抓不到,所以活了下来。

事实

packages/spec/PLUGIN_STANDARDS.md 现状:

位置	声称
§5.1	Hot Reload (plugin-loading.zod.ts → PluginHotReloadSchema) —— “supports development, staging, and production”,列出 health validation / auto-rollback / connection draining / maxConcurrentReloads
§5.2	Plugin Isolation (plugin-loading.zod.ts → PluginSandboxingSchema) —— “Sandboxing supports configurable scope and isolation level”,列出 process / vm / iframe / web-worker 与 IPC transports、allowedServices ACL
§5.4	Hot Reload ✅ plugin-loading.zod.ts — Dev + production-safe with rollback and draining
§5.4	Plugin Isolation ✅ plugin-loading.zod.ts — Configurable scope + IPC for process boundaries

本仓扫描(packages/**、examples/**,排除 node_modules / dist)读数:

• PluginHotReloadSchema / PluginSandboxingSchema / PluginLoadingConfigSchema 的全部命中都在 packages/spec 内部:plugin-loading.zod.ts 自身声明、plugin-loading.test.ts 自身单测、manifest.zod.ts:509 的 loading: PluginLoadingConfigSchema.optional() 嵌入,以及生成物。
• manifest.loading 在 packages/core/src、packages/runtime/src、packages/metadata/src 下 零读者。也就是说 manifest.loading.hotReload.* / manifest.loading.sandboxing.* 是可写入 manifest、进 authorable-surface.json(23+ 个键)、但没人读的声明。
• grep hotReload|sandboxing 在 spec 之外只命中两处,都不是这套 schema 的消费者:
  • packages/core/src/plugin-loader.ts:58 是它自己的本地 hotReloadable?: boolean,与 spec 无关;
  • packages/core/src/hot-reload.ts 的 HotReloadManager 读的是另一个 schema —— plugin-lifecycle-advanced.zod.ts 的 HotReloadConfigSchema,不是 §5.1 点名的 PluginHotReloadSchema;而 HotReloadManager 本身只在 packages/core/examples/phase2-integration.ts 里被实例化过,没有任何 runtime 组合它。

为什么这比 #4832 更糟

#4832 的病灶是“文档提到一个不存在的名字” —— 读者去找、找不到、知道自己被误导了。这里是“文档把读者准确地指向一个存在、可 import、parse 得过、但没有接收方的 schema”。作者写下 loading: { sandboxing: { isolationLevel: 'process' } },它 parse 通过、进 manifest、然后什么也不发生。#3950 记过这个形状:an exported schema with no consumer is read as a capability。§5.1 还多一层错:hot reload 在本仓确有一个实现,但读的是另一套词表(HotReloadConfigSchema),所以文档把读者指向了两套里死掉的那一套。

需要的裁决(不是 docs-only)

这不能靠改文档收场 —— 改 ✅ 为 ❌ 只是把假声明搬进 spec 里继续躺着。按 ADR-0049 enforce-or-remove,至少要回答:

1. PluginHotReloadSchema / PluginSandboxingSchema(及 PluginLoadingConfigSchema 整块、manifest.loading 这个 authorable 键)—— enforce 还是 remove?
2. 若 enforce:hot reload 的 canonical 词表是 PluginHotReloadSchema 还是 plugin-lifecycle-advanced.zod.ts 的 HotReloadConfigSchema?两套并存本身就是双源(参照 dual-source 收敛的既有做法),需要先收敛再谈实现。
3. 若 remove:走 spec-property-retirement 全套(tombstone / D3 registry / baselines / pin test / changeset),并同步改写 §5.1、§5.2、§5.4。

我倾向 remove:manifest.loading 是 authorable 键却零读者,留着它就是让 AI 作者写出一段 parse 得过、永不生效的沙箱配置 —— 正是 ADR-0049 要消灭的形状;而 HotReloadConfigSchema 那一侧至少还有 HotReloadManager 这个实现体,是将来 enforce 的更合理起点。但 PluginSandboxing 涉及安全语义,remove 与 enforce 的取舍应由维护者定,故立案不动手。

补充说明扫描范围:以上读数只覆盖本仓。裁决前应按 #4878 的做法补 cloud / objectui 两仓的裸名反查(带对照验证),再确认“零 reader”。

关联:#4832、#4834、PR #4878、#3896、#3950、ADR-0049、ADR-0033。

---

Generated by Claude Code — session session_018iARDqtrhQgz6fVHDeDkbQ