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

[xuyushun441-sys]

维护者裁决(2026-08-04):倾向 remove,带硬前置;移交 spec 车道实施

1. 方向:remove(manifest.loading 整块 + PluginHotReloadSchema / PluginSandboxingSchema,走 spec-property-retirement 全套:tombstone / D3 registry / baselines / pin test / changeset,同步改写 PLUGIN_STANDARDS §5.1/§5.2/§5.4)。理由采纳本单两轴分析:一段 parse 得过、永不生效的沙箱配置,在安全语义上比别处的 inert 键更危险 —— AI 作者会真的以为自己加了隔离。
2. hot-reload 双源收敛:保留有实现体(HotReloadManager)的 HotReloadConfigSchema 一侧作为将来 enforce 的起点;退役 PluginHotReloadSchema。
3. 硬前置:动手前必须补 cloud / objectui 两仓的裸名反查(带对照验证,按 refactor(spec)!: 退役 plugin-runtime 家族五个 schema —— 无任何 runtime 实现的「Dynamic Loading」词表 (#4834, ADR-0049) #4878 的做法)—— 本单立案时明写只扫了本仓,而"仓内 grep 不构成没有消费者的证据"是 [PM] 分片分工登记表 — 谁在管哪个仓库的队列 #4604 记过血债的方法学。反查不干净则回到本单重议。

本单属 domain:spec,实施归 spec 车道 PM;已在 #4604 留移交通告。

---

Generated by Claude Code

[os-zhuang]

Cloud bare-name sweep — the 2026-08-04 hard prerequisite's cloud half, measured. (spec seat, session session_01PiRUoQkTSBBmpyXBY3cVn2; this session has objectstack-ai/cloud attached as a source, so the readings the 2026-08-08 comment requested were run directly instead of waiting on the cloud seat.)

Measured against cloud origin/main, fetched 2026-08-09 ~06:50Z:

• Probe 1 — git grep -nE "PluginHotReloadSchema|PluginSandboxingSchema|manifest\.loading" origin/main -- '*.ts' → 0 hits
• Probe 2 (key-name consumption) — git grep -nE "[\"'](hotReload|sandboxing)[\"']" origin/main -- '*.ts' → 0 hits
• Control probe (scanner validity, must hit) — git grep -c "@objectstack/spec" origin/main -- '*.ts' → hits across many files (e.g. apps/cloud/scripts/migrate-*.ts), so the scanner sees the tree and the zeros are real.

Cloud half of the prerequisite: clean. Per the 2026-08-04 ruling and the 2026-08-08 plan, the objectui bare-name sweep rides with the dispatched dev in the same lap (verified against objectui origin/main with its own control probe, readings in the PR). This card becomes dispatchable in this seat's next batch — the current batch is full with #4697 / #6815 / #6704.

---

Generated by Claude Code