Skip to content

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

Closed

Description

@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

Activity

  1. xuyushun441-sys commented on Aug 3, 2026

    @xuyushun441-sys
    Collaborator

    核实结论:本单已被 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

  2. xuyushun441-sys commented on Aug 3, 2026

    @xuyushun441-sys
    Collaborator

    关闭 — 已被 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions