A writable package created via `POST /api/v1/packages` is registered in memory only — it does not survive a restart, and leaves its published metadata orphaned

[yinlianghui]

What happens

POST /api/v1/packages returns 201 and the package is fully usable — you can publish object drafts into it, the runtime serves them, the REST endpoints work. But the server logs:

[protocol.installPackage] no 'package' service — '<ns>' registered in-memory only (will not survive a restart)

After restarting objectstack dev, the state is split three ways:

Probe	Result
Studio → MY PACKAGES (WRITABLE)	No writable packages yet
GET /api/v1/data/<ns>_<obj>	404 Object '<ns>_<obj>' is not registered
GET /api/v1/meta/object/<ns>_<obj>/published	200 — the published object metadata is still there

So the published metadata outlives both the package and the runtime registration. Re-creating the package and re-publishing does recover (the orphaned metadata does not block it), but the intermediate state is inconsistent and Studio gives no signal that anything is wrong — it simply shows no writable packages.

Repro (17.4.0, objectstack dev)

1. POST /api/v1/packages with a writable-base package → 201.
2. PUT /api/v1/meta/object/<obj>?mode=draft&package=<ns> → 200.
3. POST /api/v1/packages/<ns>/publish-drafts → 200. Confirm the object serves data.
4. Restart objectstack dev, then run the three probes above.

Expected — one of

1. Persist API-created packages (symmetric with whatever path Studio's own "new writable package" uses), or
2. Refuse to publish into a package that cannot be persisted (fail at step 3 rather than after a restart), or
3. at minimum surface the in-memory-only status in Studio so the package is visibly ephemeral rather than silently absent after restart.

Why it matters

The failure is invisible until a restart, and then it looks like data loss with a contradiction inside it (metadata says published, runtime says not registered, Studio says nothing exists). Anything that builds state through the packages API across a restart boundary — provisioning scripts, demo setup, CI fixtures — is exposed.

Relationship to existing issues

Closest prior art is #5047 (runtime /packages persistence asymmetry: enable/disable/uninstall write the in-memory registry while install/update go through the protocol service to sys_packages) — same family, different code path: that one is about the enable/disable/uninstall side, this one is about create via POST /api/v1/packages. Also adjacent: #7557 / #7705 (uninstall leaving orphaned sys_metadata rows). All three are closed; the behaviour above was observed first-hand on 17.4.0 today, so it is reported as current, not as a regression claim against those.

Provenance

Found while producing a product film in steedos-labs/video-studio (internal), issue #357, on a read-only clone of objectstack-ai/hotcrm @ c716a2c with @objectstack/* 17.4.0 (same version as platform trunk at the time). Reported by the executing session; filed here by the video lane's PM per our cross-repo finding-transfer flow.

This is a finding, not a claim on anyone's time — filed unassigned.

[os-musk]

Triage: domain:engine; type Bug; priority:p2; pm:queue.

Route — read from the tree, ⛔ not inferred from the endpoint

The endpoint is REST, but the fix is not. The log line this card quotes is emitted from packages/metadata-protocol/src/protocol.ts, and installPackage lives in that same package. Per the lane table packages/metadata* ⇒ domain:engine. Control: a fabricated token returns 0 on the same grep, so those are readings.

⚠️ Note there is already a packages/metadata-protocol/src/durable-package.test.ts — durability is a modelled concern in that package, so the claimant should start by asking what that file already pins and why this path escapes it.

⛔ Not domain:cli: packages/rest only surfaces the 201. A repair there would hide the split state, ⛔ not fix it.

p2

For: measured on a shipped release (17.4.0) with a complete four-step repro; the failure is invisible until a restart; and the post-restart state is self-contradictory three ways — Studio says no writable packages, /data/… 404s "not registered", and /meta/object/…/published still answers 200. ⇒ it reads as data loss to the user, and anything building state across a restart boundary (provisioning scripts, demo setup, CI fixtures) is exposed.

Against p1: it is recoverable — re-creating the package and re-publishing works, and the orphaned metadata does not block it. And it is reached through the API path, ⛔ not Studio's own create path, which the card implies persists correctly. ⇒ real, ⛔ not bleeding.

⭐ The load-bearing asymmetry for whoever fixes it: the published metadata outlives both the package and the runtime registration. A fix that only stops the in-memory registration would leave the orphan; a fix that only cleans the orphan would leave the silent 201.

⛔ Scope

The card offers three shapes. 1 (persist) or 2 (refuse to publish) are this card. ⛔ 3 (surface the ephemeral status in Studio) is not — it lands in objectui and is a different repo and lane; it also only makes the inconsistency legible rather than absent. ⇒ if the round concludes 3 is the right answer, stop and report: that is a routing change, not an implementation choice.

⚠️ ⛔ Do not treat this as a regression against #5047 / #7557 / #7705. All three are closed, and the card is explicit that this was observed first-hand on 17.4.0 and is reported as current, not as a claim against them. #5047 is the nearest prior art (the enable/disable/uninstall half of the same asymmetry) and is worth reading for the shape — ⛔ not for its conclusion.

_{分诊席位 · session_015WpYyzhX8x2kEhouLBidt8 · R+182 · 2026-09-12T03:08Z · 本评论来自分诊座位}

---

Generated by Claude Code

[os-musk]

Clause-②: no

Basis（席位判断）: 这是一个持久化 bug 的修复 —— POST /api/v1/packages 创建的可写包只注册在内存里,重启后三分裂。修法是让它落盘,⛔ 不新增导出符号、⛔ 不在已发布载荷上新增键、⛔ 不移动接受集。⚠️ 附条件,而且这一条是认真的:若你的 diff 触及任何导出符号、已发布载荷的键、或接受集,⛔ 停下报告 —— 声明是席位的,由我重做。⭐ R1 在 #17167 上把 yes 改回 no、在 #17694 上把 level 抬到 minor,两次都是测量推翻了先前的判断;这条线随时可以再动。

---

⚠️⚠️ Amended 2026-09-12 — the Branch: line was UNREADABLE to check-clause2-carriers.mjs, and the checker named it a SEAT TEMPLATE fault, not a typo.
This seat wrote it as a bold **Branch:** \…`line.BRANCH_TOKEN (check-clause2-carriers.mjs:1376) strips leading whitespace, then eats an optional , then an optional backtick, then whitespace — so the bold form leaves a **space between ` and the backtick** and the token fails to match. ⇒ the directive parsed to ZERO branches and the pair read UNJUDGED.
⭐ R1 fixed 「the branch is missing」 and introduced 「the branch is unreadable」 — the same field, one layer down. The bare form below is what the checker's own self-test uses.

Branch: claude/issue-17676-writable-package-durability

Claim: domain:engine execution PM seat · session_01RuoNSXUbBoWHkNS4AknTrM · R2 · 2026-09-12 · dispatching to an os-dev agent.

pm:queue → pm:dispatched,assignee os-musk。origin/main at dispatch = c9eb773bab。

Zone 1 — 裁决,⛔ 非协商

1. ⭐ 落点是 packages/metadata-protocol,⛔ 不是 REST。 分诊实测:卡引用的那条日志从 packages/metadata-protocol/src/protocol.ts 发出,installPackage 也在同一个包里。控制项:伪造 token 在同一 grep 上返回 0。⇒ 端点是 REST,修法不是。
2. ⭐ 先读 packages/metadata-protocol/src/durable-package.test.ts 再动手 —— 分诊点名了它:持久性在这个包里已经是被建模的关注点。⇒ 先问那个文件今天 pin 住了什么、以及本路径为什么逃掉了,⛔ 不要先写修复。
3. ⚠️ 卡的症状是三分裂,⛔ 不是「包没了」 —— Studio 说没有可写包、GET /api/v1/data/<ns>_<obj> 404、而 GET /api/v1/meta/object/<ns>_<obj>/published 仍然 200。⇒ 修复必须让三个探针一致;只修其中一个是把分裂换个位置。

Zone 2 — 席位的读数,⭐ 已标注

#	主张	状态
A	日志行来自 metadata-protocol/src/protocol.ts,installPackage 同包	⚠️ READING —— 引自分诊评论,席位未自行复测。⇒ 你先测,这是路由的全部依据
B	durable-package.test.ts 存在且与持久性相关	⚠️ READING,同上
C	protocol.ts 是本车道最忙的文件(R1 两次落地:#17501 · #17290)	MEASURED ⇒ ⚠️ 若 origin/main 在你脚下移动,merge 进来,⛔ 永不 rebase 已推送的分支

Zone 3 — 建议路线,⭐ 可选

先复现(建包 → 重启 → 三探针),再读 durable-package.test.ts,再决定是补服务接线还是补 pin。⭐ 若测出「package 服务在这条路径上根本没被装上」,那本身就是发现,先报告再修。

⛔ 非协商机制(本轮全部来自 R1 的实测代价)

• ⭐⭐ Clause-② 行在本评论第 0 行 —— 席位的判断,已经做出。 ⭐ 你仍必须把同一行放进 PR 正文顶格。两道闸门读两个载体:Check Changeset 读 PR 正文 + needs:contract-review 标签(⚠️ 标签单独就能把轴强制成 yes,check-changeset-no-major.mjs:if (carrier || …) return 'yes'),--pair 读本评论。
• ⚠️⚠️ 本地 gate sweep 看不见 clause-② 的 level 轴:没有 --event payload 时 check-changeset-no-major.mjs 走 no-pull-request 分支并 exit 0。⇒ ⛔「N 个 gate 全绿」对该轴什么都没说;R1 有两个 PR 在本地全绿后在 CI 翻红。⛔ 不要报成已覆盖。
• ⭐⭐ grep -c 判断「旧文本是否还在」是错的工具 —— 它分不清「主张仍然成立」与「主张被引用并驳回」。R1 栽了四次。⭐ 仓里有对的工具:scripts/js-comment-mask.mjs(stripComments) 比较可执行 token 流。⚠️ 两个方向的控制项都必须发火,并且控制项的锚点要从被测的那一半里取 —— R1 两次用了落在注释里的锚点,控制项静默返回 false,那一肢作废。
• ⚠️ 行导向的 grep 看不见跨行折行的短语 —— R1 栽了两次(driver-sql: a multiple: true boolean/toggle column reads back as a single true — formatOutput's booleanFields pass collapses the parsed array, so a stored [false] presents as true #17586、[finding] Three source comments still say the boot-refusal codes are "deliberately NOT wire vocabulary" — #16649 registered them, so all three are false in packages/core and packages/drivers/driver-sql #16884,后者让席位读到 1 而真值是 3)。⇒ 需要「最后 N 处」这类总体判断时,合并续行,并探测该主张的多种拼法,⛔ 不要只用一个 token。
• ⭐ 每个计数必须点名它的总体,且控制项必须发火。Sweep the stale summary is a table.float comments left behind by #16318's NUMERIC representation change — nine sites in four packages, the sweep already exists on a sibling branch #17144 上四个数字全都对,只是各自没说自己的总体。
• 一任务一 worktree;⛔ 不改共享检出,⛔ 不 git stash。⚠️ 本环境删不掉远程分支(两条通道都 403)⇒ ⛔ 不要推你不打算保留的分支。
• ⚠️ /tmp/claude-0 跨并行 dev 共享,同名文件静默相撞 ⇒ 用按 issue 区分的 scratchpad 路径。
• ⭐ Gate:dispatch-gates.mjs --commands 然后 --ran。exit 3 = PREREQUISITE NOT MET,⛔ 永远不是 pass。 ⭐ $? 取的是管道最后一段的状态。
• ⚠️ REST 编辑 PR 正文会追加平台 footer(create 不会)⇒ 发送时剥光所有 footer,读回确认恰好 1 条。
• ⭐ CI 读数取 latest run per check name(⛔ 不数原始 conclusions);队列成员看 timeline(⛔ 不读 auto_merge,入队后必为 False)。
• 草稿 PR、Fixes #N、changeset。⛔ 不碰 content/docs/releases/。

_{domain:engine 执行 PM 席 · R2 · session_01RuoNSXUbBoWHkNS4AknTrM}

---

Generated by Claude Code

[os-musk]

os-dev-report
{
"issue": 17676,
"status": "needs_decision",
"branch": "claude/issue-17676-writable-package-durability",
"pr": null,
"premise_still_valid": true,
"summary": "The card's defect is real and I reproduced its mechanism on the real implementation — but Zone 1 ruling #1 is half right: the log line IS emitted from packages/metadata-protocol, and the REPAIR is not there either. Measured against the dispatch base c9eb773: installPackage (protocol.ts:22296) does exactly what its own docblock promises — 'when the package service is absent (e.g. the marketplace capability is off) the package is still registered in-memory and visible for the lifetime of the process' — so there is no defect inside that method to fix. YOUR ZONE 2 READINGS, RE-MEASURED BY ME: claim A TRUE (warn at protocol.ts:22353, installPackage at 22296, same package; fabricated-token control returned exit 1 / 0 lines while the real token returned exit 0 / 1 line); claim B TRUE (durable-package.test.ts exists and models #2532 durability). THE DELIVERABLE YOU NAMED — what durable-package.test.ts pins today and why this path escaped it: its single helper makeImpl() hardcodes the services map at line 31 as new Map([['package', { publish, delete: del }]]), and its overrides bag only swaps the IMPLEMENTATIONS of publish/del/find — there is no parameter that removes the service. So all 7 tests in the file run the service-PRESENT branch, and the service-ABSENT else branch at protocol.ts:22351-22355 (the exact branch that emits the card's log line) is structurally unreachable from that file. That is the escape: the pin models durability for a composition that always has the durable store, which is the one composition where the bug cannot occur. ROOT CAUSE (composition, not protocol): service-package/src/index.ts:571 is the SOLE registrar of the 'package' service (fabricated-token control fired); it is mounted only through the marketplace capability token (serve.ts:1693); and marketplace is ABSENT from PLATFORM_ALWAYS_ON_CAPABILITIES, whose full slate at platform-capabilities.ts:290 is exactly queue, job, cache, settings, email, storage, sms, sharing, messaging, analytics. examples/app-showcase:107 declares marketplace; examples/app-crm:54 (ui, automation) and examples/app-todo:58 (automation, triggers) do not — and the card reproduced on hotcrm, a CRM-shaped app. So on every app that does not declare marketplace, the ALWAYS-durable sys_metadata store (rows carry _packageId) is bound to an EPHEMERAL package container. That single asymmetry produces all three probes at once, which is why they split three ways rather than simply losing the package. Ruled OUT as a cause: the protocol's services getter is correctly wired to the live registry (plugin.ts:252, '() => ctx.getServices()'), so this is not a stale-snapshot or wiring bug. I stopped before writing a fix under your Zone 3 instruction ('若测出「package 服务在这条路径上根本没被装上」,那本身就是发现,先报告再修') and under Clause-②: every candidate repair crosses the line you drew. No code was written, no commits exist on the branch.",
"tests": "No diff was produced, so there is nothing to gate: no changeset, no dispatch-gates.mjs --commands/--ran run, and no eslint narrowing claim — all NOT APPLICABLE rather than NOT MEASURED. What I did run, all against the dispatch base c9eb773 in a dedicated worktree. BUILD: pnpm --filter '@objectstack/metadata-protocol^...' build --concurrency=2 under scripts/pm/os-verify-lock.sh (OS_VERIFY_LOCK_SLOT=issue-17676-dev) — VERDICT command-exit 0, held 212s, waited 0s. MEASUREMENT (the real ObjectStackProtocolImplementation, not a re-implementation; temporary file, since deleted, tree confirmed clean by git status --porcelain): constructed the impl with a LIVE services registry containing no 'package' entry, exactly the stock non-marketplace shape, and called installPackage({ manifest: { id: 'com.example.leave', name: 'Leave' } }). Observed: res.package.status = 'installed'; res.message = 'Installed package: com.example.leave'; registry install calls = 1; namespace derived = 'leave'; version defaulted = '0.1.0'; console.warn calls = 2, the second being verbatim the line the card quotes: [protocol.installPackage] no 'package' service — 'com.example.leave' registered in-memory only (will not survive a restart). Nothing was persisted. CONTROL, same call with a package service present: publish called exactly 1 time — so the probe discriminates, it is not blind. Ran alongside the existing suite: pnpm --filter @objectstack/metadata-protocol exec vitest run --maxWorkers=2 src/zz-measure-17676.test.ts src/durable-package.test.ts under the lock — VERDICT command-exit 0, Test Files 2 passed (2), Tests 9 passed (9), so the 7 pre-existing durable-package pins are green and my 2 measurement cases ran beside them. GREP CONTROLS: every symbol claim above was taken with a paired fabricated-token control, exit code captured by redirect-then-capture (never through a pipe) — the real token returned exit 0 with N lines and the control exit 1 with 0 lines in each case. LINE-NUMBER CORRECTION WORTH RECORDING: my first pass read the shared checkout, whose HEAD was f721ef0, not origin/main, and reported the warn at protocol.ts:22146. Every citation in this report was re-taken in the worktree at c9eb773 and the true line is 22353 — the same reading, a different tree. No ablation or reverse verification was run: there is no fix to ablate.",
"mcp_calls": "0 — the repo-scoped REST probe returned 200, so every read (issue body, both comment threads, prior-art card 5047 and its comments) went through REST list/read endpoints plus local grep, and no dedup search was needed because I am filing nothing.",
"open_questions": [
{
"question": "WHICH SHAPE REPAIRS THE ASYMMETRY? This is the whole card, and it is a routing/architecture choice rather than an implementation one, so per Clause-② it is yours to make. The invariant to restore is narrow and I would state it as: durable sys_metadata rows must never be bound to a package container that is not itself durable. Three shapes restore it, they are mutually exclusive, and they land in three different packages and two different lanes. Note also that the dispatch order carried Zones 1/2/3 but NO four-axis decision frame, and my instructions forbid me inventing a set of axes — so I have given options, costs and a recommendation, but deliberately not an axis-by-axis analysis. Please send the frame if you want one.",
"options": [
"A — PERSIST ALWAYS (the card's option 1): add marketplace to PLATFORM_ALWAYS_ON_CAPABILITIES so PackageServicePlugin, and therefore sys_packages plus its boot rehydration, is composed on every non-minimal boot. Makes all three probes agree in the 'it is still there' direction, which is what the reporter actually wanted. COST: edits a frozen, published spec constant in packages/spec and changes the default composition of every stock boot (one extra table plus one hydration query per boot for apps that will never browse a catalog); touches the order contract pinned in platform-capabilities.test.ts and the CLI's serve-capability-vocabulary.test.ts. CLAUSE-② RISK: HIGH — a published spec constant and, on a fair reading, an accept set. SEMANTIC OBJECTION: the token is named marketplace but the thing being made always-on is package PERSISTENCE; turning it on everywhere advertises a marketplace the deployment may not have, which rubs against Prime Directive #10 and Route-ownership rule #4.",
"B — REFUSE (the card's option 2): fail at step 3, publish-drafts, or earlier at the writable-base gate, when the package has no durable backing. Also makes all three probes agree, in the 'nothing is there' direction, and honours 'prefer failing to falling back'. COST: narrows a published endpoint's accepted inputs, and turns runtime metadata authoring from degraded-but-working into impossible on every app that does not declare marketplace — arguably a worse product outcome than the bug. CLAUSE-② RISK: HIGH — accept-set movement, and probably a new error-code constant. CONTRACT OBJECTION, and I think this is close to fatal: ADR-0016 §9.1 declares that 'a package is a flat collection of package_id-tagged metadata' with no draft sys_package_version in the MVP. Under that model the package's DEFINING storage is sys_metadata, which is always durable — so refusing to create or publish into it because a SECONDARY store is absent contradicts the accepted ADR, and Prime Directive #13 says an accepted ADR binds until a superseding one says otherwise.",
"C — RECONSTITUTE AT BOOT (not offered by the card; it follows from ADR-0016 §9.1): rebuild writable packages at boot from the distinct package_id values already present in the durable sys_metadata rows, so no sys_packages row and no capability change is needed. This is the only shape that is arguably Clause-②-clean: no exported symbol, no published-payload key, no accept set, no spec constant. It also matches the ADR's declared model exactly, and the manual counterpart already exists as POST /packages/:id/adopt-orphans. COST: introduces a SECOND source of truth for package existence alongside PackageServicePlugin's sys_packages hydration, and the two would need a precedence rule; it is a new boot-time path in packages/runtime, which is a real architecture addition even though it is contract-quiet."
],
"recommendation": "C, then A as the fallback — but I want your ruling before any code, because C is a new boot path and A edits a published spec constant. C is the only candidate that satisfies the accepted contract (ADR-0016 §9.1 makes sys_metadata the package's defining storage, and those rows already survive — the runtime simply declines to reconstitute from them), restores the invariant in the direction the reporter wants, and does not cross the Clause-② line. B I recommend AGAINST on contract grounds, not on taste: it contradicts ADR-0016 §9.1, and Prime Directive #13 would require a superseding ADR first. If C's second-source-of-truth cost is judged too high, A is the honest alternative and its true cost is the spec-constant edit, not the runtime overhead. ONE MORE PRECEDENT YOU SHOULD WEIGH, because it is the closest thing to a standing ruling on this exact question: the verification comment that closed the prior-art card 5047 recorded, as deliberate debt it declined to fix, that package state already spans two media — the disabled set in a flat OS_HOME file per packages/runtime/src/package-state-store.ts, the package itself in the DB — and ruled that changing that split is 'ADR 级取舍,要改先改 ADR' (an ADR-level tradeoff; change the ADR first). Counting sys_metadata, package state today spans THREE media with three different durability rules, which is the real reason this card's symptom is a three-way split rather than a simple loss. If you read shape A or C as moving that split, 5047's own ruling says an ADR precedes the code."
}
],
"out_of_scope_findings": [
"noted, not filed: protocol.updatePackage carries the byte-identical absent-'package'-service branch one method down (services lookup at protocol.ts:22385, warn at protocol.ts:22399, 'edited in-memory only (will not survive a restart)'), so a manifest edit made without the marketplace capability is lost on restart the same way. Successor is named and immediate: this card's own fix lands in that exact method neighbourhood, and whichever of A/B/C you pick settles this twin in the same diff — filing it separately would duplicate the decision rather than record a second one.",
"noted, not filed: the three-media observation above (in-memory registry vs sys_packages vs the flat OS_HOME package-state file vs sys_metadata) is an ADR-level consistency debt already recorded and deliberately declined on card 5047. Re-filing it would re-open a closed ruling rather than report anything new; it belongs in whichever ADR the decision above produces.",
"noted, not filed: durable-package.test.ts cannot express the service-absent composition at all, because makeImpl hardcodes the services map. This is not a separate card — it is the answer to the question the dispatch asked and it is the coverage the chosen fix must add, so it lands with the fix."
]
}

---

Generated by Claude Code

[os-musk]

→ 决策箱:pm:dispatched → needs-user-decision(同一笔写入,六态互斥已回读)

domain:engine 执行 PM 席 · R2 · session_01RuoNSXUbBoWHkNS4AknTrM · 2026-09-12。派发轮没有写任何代码,按派发令 Zone 3 的指示先报告 —— ⭐ 那是对的,三个候选修法全部越过本席给它画的 Clause-② 线,而且落在三个包、两个车道。

---

一句话问题

在没有开「应用市场」的部署上,用户在 Studio 里建的包、以及往里发布的对象,重启后只消失一半 —— 对象的元数据还在,包却不见了,于是同一份数据从三个入口看是三个答案。

背景

POST /api/v1/packages 返回 201,包完全可用:能往里发布对象草稿、运行时能服务它们、REST 端点正常。重启 objectstack dev 之后:

探针	结果
Studio → MY PACKAGES (WRITABLE)	No writable packages yet
GET /api/v1/data/<ns>_<obj>	404 Object '<ns>_<obj>' is not registered
GET /api/v1/meta/object/<ns>_<obj>/published	200 —— 已发布的对象元数据还在

前提(带 re-check 命令,⭐ 本席逐条独立复测,⛔ 不是转述派发轮)

全部在 c9eb773bab 上取,每条带发火的控制项:

# ① 服务缺席分支就是卡引用的那条日志(protocol.ts:22351-22355)
git show c9eb773bab:packages/metadata-protocol/src/protocol.ts | sed -n '22349,22357p'

# ② 'package' 服务的唯一注册者
git grep -n "registerService('package'" c9eb773bab -- packages/services/service-package/src/index.ts   # :571
# 控制项:伪造 token 返回 0

# ③ marketplace 不在常开能力全集里
git show c9eb773bab:packages/spec/src/kernel/platform-capabilities.ts | sed -n '290,304p'
# 控制项:同范围内 'queue' 读 2(发火);'marketplace' 读 0

# ④ 现有 pin 为什么没接住
git show c9eb773bab:packages/metadata-protocol/src/durable-package.test.ts | sed -n '25,35p'

⭐⭐ ④ 是这张卡真正的发现,也是派发令点名要的东西。 durable-package.test.ts 的 makeImpl() 把 services map 硬编码成 new Map([['package', { publish, delete: del }]]),而它的 overrides 只能换 publish/del/find 的实现,⛔ 没有任何参数能移除该服务。⇒ 文件里 7 个测试全部跑 service-存在分支,而发出上面那条日志的 service-缺席分支从这个文件结构性不可达。这个 pin 为「总是有持久化存储」的组合建模持久性 —— 而那恰恰是 bug 不可能发生的那个组合。

⚠️ 本席一条读数更正,记下来免得下一轮照抄:派发轮第一遍读的是共享检出(HEAD f721ef0ff2),把警告行报成 protocol.ts:22146;在 worktree 的 c9eb773bab 上重取,真值是 22353。同一读数,不同的树。⇒ 本车道「⛔ 永不编辑共享检出」还有另一面:读也会被它误导。

根因:是组合,不是协议

installPackage(protocol.ts:22296)做的正是它自己 docblock 承诺的事 ——「服务缺席时仍在内存注册,进程存活期内可见」。⇒ ⛔ 那个方法里没有缺陷可修。

真正的不对称:sys_metadata(行上带 _packageId)永远持久,而 package 容器只在部署声明了 marketplace 时才存在。app-showcase 声明了它;app-crm、app-todo 没有 —— 卡正是在一个 CRM 形状的应用上复现的。⇒ 一个永久的存储被绑在一个可选的容器上,这一个不对称同时产生三个探针的分裂,这也是为什么症状是「三分裂」而不是「包丢了」。

⛔ 已排除:协议的 services getter 接线正确(plugin.ts:252,() => ctx.getServices()),⛔ 不是快照过期或接线 bug。

Governing text

• ADR-0016 §9.1:「a package is a flat collection of package_id-tagged metadata」,MVP 里没有 draft sys_package_version。⇒ 在该模型下,包的定义性存储就是 sys_metadata,而它一直是持久的。
• 先例 —— 卡 runtime /packages domain 持久化不对称:enable/disable/uninstall 直写 in-memory registry,install/update 却走 protocol service 落 sys_packages #5047 的结案裁决:包状态已经跨介质(禁用集在 OS_HOME 的扁平文件里,包本身在 DB 里),该裁决把改动这个分裂定为「ADR 级取舍,要改先改 ADR」。⚠️ 算上 sys_metadata,今天是三种介质、三套持久性规则。
• Prime Directive [WIP] Add Chinese version of the documentation #13:已接受的 ADR 在被取代前有约束力。

选项 × 真实代价

	做什么	客户可感知的后果	实测代价
A	把 marketplace 加进常开能力,让包存储在每次非最小启动时都被组装	三个探针一致地answer「它还在」—— 报告者想要的方向	⛔ 编辑已发布的 spec 常量,并改变每个 stock 启动的默认组合(永不浏览目录的应用也多一张表 + 每次启动一次水合查询);触及 platform-capabilities.test.ts 的顺序契约与 CLI 的 serve-capability-vocabulary.test.ts。⚠️ 语义反对:token 叫 marketplace,而要常开的东西是包的持久化 —— 等于向没有市场的部署广告一个它没有的市场
B	没有持久后端时,在第 3 步/发布草稿/更早的可写基座闸门上拒绝	三个探针一致地answer「什么都没有」,符合「宁可失败不要降级」	⛔ 收窄一个已发布端点的接受集,并把运行时元数据创作在每个没声明 marketplace 的应用上从「降级但能用」变成「不可能」。⚠️ 契约反对,接近致命:ADR-0016 §9.1 下包的定义性存储是 sys_metadata(永远持久),因为一个次级存储缺席就拒绝创建/发布,与已接受的 ADR 相矛盾
C	启动时从已经持久的 sys_metadata 行里的 distinct package_id 重建可写包	同 A 的方向,但不新增表、不动能力全集	⭐ 唯一条款②干净的形状:⛔ 无导出符号、⛔ 无已发布载荷的键、⛔ 无接受集、⛔ 无 spec 常量;且精确吻合 ADR 声明的模型,手工版本已存在(POST /packages/:id/adopt-orphans)。⛔ 代价:为「包是否存在」引入第二个真相来源(与 sys_packages 水合并列),两者需要优先级规则;是 packages/runtime 的新启动路径

业务含义直译

• A =「所有客户的产品里都装上仓库货架,哪怕这家店从不进货 —— 因为货架的螺丝上挂着库存单。」
• B =「没装货架就不许收货 —— 顾客手里的货还在,但柜台从今天起拒绝开单。」
• C =「每天开门时按库存单把货架重摆一遍 —— 单子一直都在,只是过去没人照它摆。」

四轴(从业务立场)

os-decision-facets

① 项目长远合理性:A 把一个能力 token 的名字和一个与它无关的持久性保证焊死,特例增生;B 让一个已接受的 ADR 与代码互相矛盾,契约债;C 缩小特例(让实际行为回到 ADR 已经声明的模型),但新增一条启动路径与一条优先级规则。⇒ C 最小,A 次之,B 制造新的契约冲突。

② 实际业务拉动:今天撞上的是每一个不开市场的部署的运行时元数据创作者 —— 报告来自 hotcrm,而 app-crm / app-todo 两个出厂示例都不声明 marketplace。⇒ 拉动非零且是默认路径,⛔ 不适用「零拉动 defer」。

③ 防 AI 犯错:今天的失败是静默的——201、能用、重启后一半消失,没有任何东西拒绝。A 和 C 让它不再发生;B 让它变成响亮拒绝。⚠️ 但 B 拒绝的是一个 ADR 说本来就合法的动作 ⇒ 响亮地拒错东西,比静默更难排查。⇒ A/C 优于 B。

④ 创业阶段不扩散:A 永久扩大每个启动的默认组合(一张表 + 一次查询 × 所有客户),且那是已发布 spec 常量上的永久义务;C 不新增任何已声明的键,只新增内部启动逻辑。⇒ C 扩散最小。

推荐:C,回退 A。置信缺口:本分析看不见 —— ⑴ sys_packages 水合与 sys_metadata 重建在同时存在时的优先级该怎么定,本席没测;⑵ 重建路径在大量包下的启动开销没有读数;⑶ #5047 的「要改先改 ADR」是否也覆盖 C(C 不改介质数量,只是开始使用已有介质),本席读不出——这恰恰可能是维护者唯一需要裁的那一点。

推荐 + 回退

荐 C:它是唯一同时满足「已接受的契约」(ADR-0016 §9.1 把 sys_metadata 定为包的定义性存储,而那些行本来就活着 —— 运行时只是拒绝从它们重建)、「报告者想要的方向」、以及「不越过条款②线」的形状。
回退 A:若 C 的第二真相来源代价被判定过高,A 是诚实的替代,它的真实代价是那次 spec 常量编辑,⛔ 不是运行时开销。
⛔ 反对 B,理由是契约不是口味:它与 ADR-0016 §9.1 矛盾,Prime Directive #13 要求先有取代性 ADR。

裁后执行段(⭐ 维护者只裁方向,⛔ 不背执行)

裁定任一字母后,本席按下列原子执行、⛔ 不再请示:

1. 回队并派发,文件面按所裁形状声明(A ⇒ packages/spec + CLI 两个 pin;B ⇒ 端点闸门 + 新错误码;C ⇒ packages/runtime 启动路径)。
2. 条款②由本席重新测量并声明 —— 当前的 no 只对「不写代码」这个状态成立。
3. durable-package.test.ts 的覆盖缺口随所裁修法一起补 —— makeImpl() 必须能表达 service-缺席组合,否则新修法的 pin 会重蹈今天的结构性不可达。⛔ 不单独立卡:它是本卡问的问题的答案。
4. 孪生缺陷同一 diff 一并处置:protocol.updatePackage 在一个方法之下带着逐字节相同的缺席分支(services 查找 :22385,警告 :22399,「edited in-memory only (will not survive a restart)」)⇒ 没有 marketplace 时的清单编辑同样重启即失。⛔ 不另立卡,否则是把同一个决定记两遍。

相关单与 PR

#17676(本卡)· #5047(先例:包状态跨介质 = ADR 级取舍)· ADR-0016 §9.1 · ADR-0078 · POST /packages/:id/adopt-orphans(C 的手工对应物)

_{domain:engine 执行 PM 席 · R2 · session_01RuoNSXUbBoWHkNS4AknTrM · 读数取于 c9eb773bab,逐条带控制项 · 2026-09-12}

---

Generated by Claude Code