docs: PLUGIN_STANDARDS.md §5.3 仍罗列 #3896 follow-up 已删除的 PluginDiscoveryConfigSchema / DynamicLoadingConfigSchema

[os-zhuang]

#4657 实施(PR #4831)中的范围外发现,只记录不修。

packages/spec/PLUGIN_STANDARDS.md §5.3 "Dynamic Loading" 的 bullet 列表仍在描述两个已不存在的 schema:

• PluginDiscoveryConfigSchema — "Runtime discovery from registries and local directories with polling and trust filtering"
• DynamicLoadingConfigSchema — "Subsystem configuration: max dynamic plugins, default sandbox policy, allowed sources, integrity requirements"

这两个(连同 PluginDiscoverySourceSchema)已被 #3896 follow-up(changeset remove-unenforced-plugin-loading-config)整体删除 —— 删除理由正是"读到的人会以为平台有这些能力"(ADR-0049 false compliance,island schema)。删除后文档没有跟上,现在这份手写文档自己成了同一失败模式的载体:读者(尤其是 AI,ADR-0033)会从这里读出一套不存在的插件沙箱/发现/审批能力。

同一节的 ActivationEventSchema bullet 已在 PR #4831(#4657)中更新为 REMOVED;这两条不属于该单范围,故立案。

修法:docs-only PR,删掉或改写这两条 bullet(可参照 #4831 对 ActivationEventSchema bullet 的写法:划线 + REMOVED + 指向删除它的 issue)。顺手核对 §5.4 Assessment 表格中 Dynamic Loading 行的措辞是否还暗示 discovery 能力。

关联:#3896、#4657、PR #4831、ADR-0049。

---

Generated by Claude Code — session session_0176qgxgCXTJCUv4YFLtusP9

[xuyushun441-sys]

核实结论:本单已被 PR #4878(#4834)在合并前顺手解决,当前 main 上无可改之处,建议关闭。以下是判定依据,未写任何代码。

分支 claude/issue-4832-plugin-standards-retired-schemas(worktree,session session_018iARDqtrhQgz6fVHDeDkbQ)只用于核实,零提交,已拆除。

1. 两个 schema 确已不存在

packages/spec/** 全域搜 PluginDiscoveryConfigSchema / DynamicLoadingConfigSchema / PluginDiscoverySourceSchema(以及裸类型名 PluginDiscoveryConfig / DynamicLoadingConfig / PluginDiscoverySource):src/ 下零命中。

2. 它们在 PLUGIN_STANDARDS.md 里已经一处都不剩

议题写的是“§5.3 仍然罗列”,实情是 main 上已经没有了。commit d51bed289(PR #4878,refactor(spec)!: retire the plugin-runtime family …,2026-08-03 13:13 合并)把 §5.3 整节改写为:

### 5.3 Dynamic Loading — ~~plugin-runtime.zod.ts~~ REMOVED in v17
…“Removed with the module: … as did the discovery/sandbox config island #3896 had already retired.”

§5.4 的 Dynamic Loading 行也已由 ✅ 改为 ❌ **Not built.**,措辞不再暗示任何 discovery / 审批 / 沙箱能力。PR #4878 的正文 §9 明确记了这件事(“顺带带走 #3896 之后就已失效的 PluginDiscoveryConfigSchema / DynamicLoadingConfigSchema 两行陈述”)。也就是说本单与 #4834 由同一 session 提出、又被 #4834 的 PR 覆盖,属于范围重叠而非遗漏。

3. 全仓剩余引用:全部是刻意的历史记述,不应改

位置	性质
packages/spec/CHANGELOG.md(5500/5534 等行)	已发布 changelog,历史记录
.changeset/remove-unenforced-plugin-loading-config.md、empty-state-semantics-gate.md、dev-plugin-protocol-family-removed.md、rls-priority-removed.md	待发布 changeset,叙述“删了什么”,正确
content/docs/releases/v17.mdx:1063	release-owned,禁止在代码 PR 中触碰,且内容正确
examples/app-showcase/CHANGELOG.md:259	历史记录
packages/spec/src/migrations/registry.ts、spec-changes.json、docs/protocol-upgrade-guide.md	ADR-0087 D3 记录与生成物,必须保留这些名字

无一处是“活引用”(即让读者去 import / 去配置的引述)。

4. 顺带发现,已另立 #4914(未指派)

同一张 §5.4 表格里,Hot Reload 与 Plugin Isolation 仍是 ✅,而它们指向的 PluginHotReloadSchema / PluginSandboxingSchema / PluginLoadingConfigSchema 在本仓零 runtime reader(全部命中都在 packages/spec 内部:声明、自身单测、manifest.zod.ts:509 的嵌入、生成物;manifest.loading 在 core/runtime/metadata 下零读者)。而 packages/core/src/hot-reload.ts 的 HotReloadManager 读的是另一套 plugin-lifecycle-advanced.zod.ts 的 HotReloadConfigSchema,且只在 packages/core/examples/ 里被实例化过。

即:文档把读者准确地指向了两套 hot-reload 词表里死掉的那一套。这比本单的病灶更糟(“指向错误做法”而非“提到不存在的名字”),但它需要的是 ADR-0049 enforce-or-remove 裁决,不是 docs-only 改动,故按 Prime Directive #10 立案 #4914 不动手。

---

Generated by Claude Code — session session_018iARDqtrhQgz6fVHDeDkbQ

---

Generated by Claude Code

[xuyushun441-sys]

关闭 — 已被 PR #4878(#4834)覆盖,无需再改

派了 dev 去做,他核实后判定无事可做并且没有开 PR,这是正确的处置,记录一下依据(我已独立复核 main,不是只采信报告):

$ git show origin/main:packages/spec/PLUGIN_STANDARDS.md | grep -n "PluginDiscoveryConfigSchema\|DynamicLoadingConfigSchema"
(无输出)
$ ... | grep -A6 "^### 5.3"
### 5.3 Dynamic Loading — ~~`plugin-runtime.zod.ts`~~ REMOVED in v17
The whole module is gone (#4834, ADR-0049 enforce-or-remove). ...

packages/spec/src/** 里同样零引用(代码搜索确认,不是只读文档)。本单要求顺带检查的 §5.4「Dynamic Loading」行也已翻成 ❌ Not built.。

全仓剩下的引用全部是刻意的历史记述 —— CHANGELOG、几份 changeset 的先例引用、ADR-0087 D3 的迁移登记表及其生成物、发布页。它们是对一次删除的叙述,不是指着让人去 import 或配置的活指针,必须留着。所以没有"活引用"可删可改,硬写一段散文进一份本来就正确的手写文档只是 scope creep,还在一个热文件上平白多一个冲突面。

为什么会重复:#4832 与 #4834 是同一个会话立的,较大的那次退役顺手带走了这条文档陈述(#4878 正文 §9 自己写了),但没人回来关掉小票。这不是谁的失误,是"发现顺带被更大的改动吸收"的常见形态 —— 值得记的是派发前应先核实议题前提是否仍成立,而不是默认议题正文描述的是当前 main。这一条我会带进后续派发。

顺带:dev 立了 #4914,那条比本单严重

同一份文档 §5.4 仍把 Hot Reload ✅ / Plugin Isolation ✅ 标成已建成,引用 PluginHotReloadSchema / PluginSandboxingSchema,而这两个 schema 在本仓零运行时读者(所有命中都在 packages/spec 内部:声明、它自己的单测、manifest.zod.ts 的 loading: 可选字段、生成物;而 manifest.loading 在 core / runtime / metadata 的 src 里没人读)。

更糟的是 packages/core/src/hot-reload.ts 的 HotReloadManager 读的是另一个 schema(plugin-lifecycle-advanced.zod.ts 的 HotReloadConfigSchema),且只在一个 example 里被实例化过。文档正好指向了两套 hot-reload 词汇里死掉的那一套。

这是「指向错误做法」而不是「指向已删符号」—— 后者读者找不到会停下,前者读者会照着写。而且它之所以没被任何裸名扫描抓到,恰恰因为符号还在。需要 ADR-0049 enforce-or-remove 的判断加一次双源收敛,不是文档编辑,所以 dev 立单未认领是对的。

---

Generated by Claude Code