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

#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,至少要回答:

PluginHotReloadSchema / PluginSandboxingSchema(及 PluginLoadingConfigSchema 整块、manifest.loading 这个 authorable 键)—— enforce 还是 remove?
若 enforce:hot reload 的 canonical 词表是 PluginHotReloadSchema 还是 plugin-lifecycle-advanced.zod.ts 的 HotReloadConfigSchema?两套并存本身就是双源(参照 dual-source 收敛的既有做法),需要先收敛再谈实现。
若 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

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

方向: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 作者会真的以为自己加了隔离。
hot-reload 双源收敛:保留有实现体(HotReloadManager)的 HotReloadConfigSchema 一侧作为将来 enforce 的起点;退役 PluginHotReloadSchema。
硬前置:动手前必须补 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

feat(lint): gate a sharing-rule condition the runtime can only skip (o…

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

Claim: PM loop round 1+ (maintainer's explicit acceleration: dispatch now, do not wait for the next batch — 2026-08-09 ~08:3xZ)
Session: session_01PiRUoQkTSBBmpyXBY3cVn2
Branch: claude/issue-4914-plugin-loading-retirement
Worktree: objectstack-issue-4914
Domain: domain:spec
File surface: packages/spec/src/kernel/plugin-loading.zod.ts (retire PluginHotReloadSchema / PluginSandboxingSchema / the PluginLoadingConfigSchema block per the 2026-08-04 REMOVE ruling), packages/spec/src/kernel/manifest.zod.ts (loading: authorable key, ~:509), plugin-loading.test.ts pins, packages/spec/src/migrations/registry.ts (retirement registries), packages/spec/PLUGIN_STANDARDS.md §5.1/§5.2/§5.4 rewrite, liveness ledger, spec generated trees (authorable-surface loses 23+ keys). Read-only sweep of objectui origin/main (bare-name counter-check, in-lap — the hard prerequisite's remaining half; cloud half measured clean 2026-08-09 06:5xZ, this thread). (Stop on breach; explain in the report.)
Serial constraints cleared: in-flight siblings #4697 (PR #6998, patch lap), #6815, #6704 — all source-disjoint from this card's files; ALL FOUR collide on spec generated artifacts + retirement registries at landing ⇒ landing serialized by this seat, this card queues last in the relay. Same-file check: #6815 also touches migrations/registry.ts — union-keep discipline, recount from the file (#6526).
Container assessment: M-L (full retirement playbook + repo-wide sweeps), mode:subagent shared container — heavy verification serializes on the container flock.

Generated by Claude Code

test(spec): pin count 824->823 and regenerate strictness ledger for the

merge origin/main into #4914 — union-keep both step17 semantic entries

chore(changeset): declare the ADR-0087 disposition for #4914

PM status note (patrol 14:40Z): the dispatched os-dev subagent for this card was stopped externally (session-level cancellation; discovered by probe delivery failure). Unlike a clean cancellation, this one left real work product: draft PR #7067 — implementation complete per its body (three-repo reverse lookups with controls, tombstone route, D3-only registration with measured D2-inapplicability, both ratchets answered, registries recounted union-keep), but the final dev report was never returned and the PR sits at mergeable_state: dirty (main has moved ~7 merges since its last push at 73733182).

Remaining work for whoever adopts it: one merge lap over current origin/main (os-regen artifacts regenerated from the merged tree; RETIRED_KEYS_BY_MAJOR[17] / RETIRED_DEFS_BY_MAJOR[17] / step17.semantic recounted from the file per #6526 — several sibling retirement PRs landed today), re-run of the ratchet-owned gates, and CI convergence. The card stays pm:dispatched with this note as the state of record; re-dispatch/adoption awaits the maintainer's word (⛔ not self-initiated, per the cancellation discipline).

Generated by Claude Code

FINISHER CLAIM — PM seat (session session_01PiRUoQkTSBBmpyXBY3cVn2), adoption dev dispatched under the maintainer's re-acceleration (2026-08-09 chat). A fresh os-dev ADOPTS branch claude/issue-4914-plugin-loading-retirement and PR #7067 as-is — scope is the finishing lap only (merge lap over current main with os-regen artifacts regenerated from the merged tree, registries recounted from the file per #6526, ratchet gates re-answered, CI convergence), NOT a reimplementation. The PR body's implementation stands as the record of what was built.

Generated by Claude Code

merge origin/main into #4914 — union-keep both retirement registratio…

refactor(spec)!: remove `manifest.loading` — an inert loading block w…

fix(spec): os migrate meta guidance for the ui-* and plugin-* migrati…

fix(spec): os migrate meta guidance for the driver-*, kernel-* and sy…

docs(plugin-hono-server): re-anchor the dead tracker citations in pac…

docs: re-anchor the last dead tracker citations in eleven lane packag…

docs(driver-memory): re-anchor the dead tracker citations to the comm…

test(spec): kernel test titles state each cited decision in words ins…

Navigation Menu

Repository navigation

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

事实

为什么这比 #4832 更糟

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

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

事实

为什么这比 #4832 更糟

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

Activity

xuyushun441-sys commented on Aug 4, 2026

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

os-zhuang commented on Aug 9, 2026

os-zhuang commented on Aug 9, 2026

os-zhuang commented on Aug 9, 2026

os-zhuang commented on Aug 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions