ADR-0130(objectstack#14122):Studio 包选择器列出 project 域的 module 包

[os-sam]

Blocked-by: objectstack-ai/objectstack#14163

objectstack ADR-0130(docs/adr/0130-release-artifact-as-co-ownership-boundary.md,已合并)Consequences 表第 6 行的 objectui 侧实现;epic 为 objectstack-ai/objectstack#14122。运行时链(schema #14161 → 装载 #14162 → 闸 #14163)落地后本卡才有可显示的多包物。

要求

Studio 包选择器今天只显示 type: app 的项目包(实测 app.objectstack.hotcrm 单项,22 个系统插件被过滤)。改为:project 域的 module 包一并列出,系统插件照旧过滤——这是 ADR-0130 给 Studio 的分组收益兑现处(对象/flow/权限按包边界分组,零新增 authorable key)。

边界

• ⛔ 消费者市场面不动:isConsumerInstallable 与 marketplace 列表不受影响(ADR-0019 D2/D3,发布物停在控制面)。
• 具体过滤判据以 objectstack 侧落地后的包记录为准(type + 域标记),实现时读运行时实态,不硬编码包名。

验收

多包物安装后,Studio 选择器可切换到各 module 包,其对象/flow/权限视图按包 scope 正确过滤;单包存量应用显示与今日一致。

[hotlong]

派发前对卡面前提的实测更正 —— 过滤器已经放行 module 包；真正要修的是 writable 的推导

epic objectstack#14122 的 PM 席在派发前对着 objectui main 与 objectstack main（含 #14240）核了一遍，卡面第一条要求的前提不成立，且藏着一个更实质的缺陷。

1. 选择器今天就不按 type 过滤

Studio 的 PackageSwitcher（packages/app-shell/src/views/studio-design/StudioDesignSurface.tsx:258）从 fetchPackages() 取列表，列表经 parsePackages()（packages/app-shell/src/views/studio-design/packages-io.ts:29）过滤，判据只有一条：

const scope = typeof m.scope === 'string' ? m.scope : '';
if (scope === 'system' || scope === 'cloud') continue; // kernel — not app packages

没有任何对 type 的判断。 卡面说"今天只显示 type: app 的项目包"——那是对当前数据的描述（装机里唯一的非 system 包恰好是 app.objectstack.hotcrm），不是对过滤器的描述。一个 type: module、scope: project 的子包一旦被 #14240 的装载路径注册，零改动就会出现在选择器里。

所以"列出 module 包"这一条由构造满足，不需要写代码。派发时不要让 dev 去"实现"一个已经存在的行为。

2. 真正的缺陷：省略 scope 的子包会显示为可写

同一个函数的下一行：

out.push({ id, name: String(m.name ?? id), writable: scope !== 'project', namespace });

链条如下，每一环都已对树核实：

环	事实	位置
①	ManifestSchema.scope 的默认值 'project' 只在 parse 时施加	spec/src/kernel/manifest.zod.ts:263
②	#14240 的装载路径刻意把原始 body 交给 registerApp，⛔ 不用 parse 后的克隆（D7 逐位相同的前提）	objectql/src/artifact-packages.ts 模块头
③	installPackage 把 manifest 原样存入 InstalledPackage.manifest	objectql/src/registry.ts const pkg: InstalledPackage = { manifest, … }
④	GET /api/v1/packages 直接返回 registry.getAllPackages()，不规范化	runtime/src/domains/packages.ts:269
⑤	parsePackages 读到 m.scope === undefined → scope = '' → 通过 system/cloud 过滤 → writable: '' !== 'project' === true	packages-io.ts:38-41

结论：多包物里任何一个没写 scope 键的 module 子包（这是常态——作者依赖默认值），在 Studio 里会被当成可写的 database 包，而它实际是只读的 project 包。今天的 app.objectstack.hotcrm 之所以正确显示 🔒只读，是因为它的 manifest 显式写了 scope: 'project'。

修法在 objectui 侧：缺省 scope 视为 'project'（与 schema 默认一致），而不是视为 ''。这正好落在卡面自己划的边界里——"具体过滤判据以 objectstack 侧落地后的包记录为准，实现时读运行时实态"。

3. 卡面验收第二条才是实质工作

"其对象/flow/权限视图按包 scope 正确过滤"——即 /studio/<packageId>/{data,automations,access} 切到一个 module 子包时，只显示该包拥有的对象/flow/权限集。这一条未经验证：今天所有对象都归一个包，按包过滤从未被真实数据考验过。这是本卡要证明的东西，需要一个真实的多包物启动来测。

派发指令将据此改写

• ⛔ 不实现 type 过滤——它不存在也不需要存在
• ✅ 修 writable 推导（缺省 scope → 'project'），并 pin：一个省略 scope 的 project 包在选择器里 writable === false
• ✅ 用真实多包物（objectstack main 已含 #14161/#14240/#14354 后）验证三个分区按包 scope 过滤，截图为证
• ✅ 单包存量应用显示与今日逐位一致（负向 pin）

---

由 epic objectstack#14122 的 PM 席登记。本卡仍 pm:queue，blocked-by objectstack#14163（PR #14354 复审中）。

---

Generated by Claude Code

[hotlong]

认领

• 会话：session_01UHvF5hyiZjnCyExFnfQB8m（epic objectstack#14122 的 PM 席）
• 分支：claude/issue-7177-studio-picker-module-packages
• 阻塞解除中：objectstack#14354（D1+D3 闸）已 PASS、ready、auto-merge 已 arm，正在合并队列。派发给 dev 时附带一条硬门：多包物启动验证前必须确认 objectstack origin/main 已含 #14354 的合并（packages/objectql/src/registry.ts 存在 refuseCoOwnedObjectNameCollision），否则等待，⛔ 不得用"各包不同命名空间"代替共享命名空间来绕过。

范围按上一条评论的更正执行：不实现 type 过滤；修 parsePackages 对缺省 scope 的 writable 推导并 pin；用真实多包物验证 data / automations / access 三个分区按包 scope 过滤；单包存量显示逐位不变的负向 pin。

---

Generated by Claude Code

[hotlong]

修法改向：writable 由服务端给，客户端不再猜 —— 新增 blocked-by objectstack#14375

上一条评论里我提的修法（"缺省 scope 视为 'project' → 只读"）撤回。继续核服务端权威后发现它会造成回归：

服务端的可写规则不看 scope 的这一维

isWritablePackage(engine, id)（objectstack packages/metadata-protocol/src/package-writability.ts:73，ADR-0070 D2，也是 objectstack#8146 维护者裁定"一个可写答案、徽标说真话"的落点）：

步	规则	依据
①	在 engine.manifests 里（启动时经 registerApp 注册的代码包）→ 只读	engine.ts:4784 this.manifests.set(id, manifest)
②	scope ∈ {system, cloud} → 只读	READ_ONLY_PACKAGE_SCOPES
③	其余（project 或缺省 scope 的 DB base）→ 可写	—

客户端 parsePackages 的 writable: scope !== 'project' 与它是两条不同的规则：

• 多包物的 module 子包（缺省 scope）：服务端 ① → 只读；客户端 → 可写。分叉（本卡的缺陷）。
• Studio 自建 / 复制出的 DB base（同样缺省 scope）：服务端 ③ → 可写；客户端 → 可写。碰巧一致。

所以"缺省 scope → 只读"会把第二行的 DB base 一并翻成只读——那是 Studio 的主流程。区分两者的唯一信号 engine.manifests 只在服务端，客户端无法从 GET /packages 今天的原始载荷中推出正确答案。

落点

• objectstack#14375（已立卡、已认领、派发中）：GET /packages 与 GET /packages/:id 每行附加 writable，由服务端用同一个 isWritablePackage 算出；四态 pin（含"缺省 scope 的 DB base 仍为 true"）。
• 本卡（objectui）改为：parsePackages 优先读 p.writable（typeof === 'boolean'），字段缺失时回落今日启发式（兼容旧服务端），并把 packages-io.ts:7-11 那段与规则相反的文档注释改写成"服务端是权威，启发式只是旧服务端的回落"；pin：① 载荷带 writable:false 且缺省 scope → false；② 载荷带 writable:true 且缺省 scope → true；③ 载荷无 writable → 与今日输出逐位相同（负向）。
• 卡面验收第二条（三个分区按包 scope 过滤）不变，仍需真实多包物启动，等 #14354 与 #14375 都进 main。

Blocked-by：objectstack#14163（PR #14354，已 ready + auto-merge）、objectstack#14375（新）。认领保持。

---

Generated by Claude Code

[hotlong]

os-dev-report

{
 "issue": 7177,
 "status": "rework",
 "branch": "claude/issue-7177-studio-picker-module-packages",
 "pr": "https://github.com/objectstack-ai/objectui/pull/7331",
 "premise_still_valid": true,
 "summary": "Part 1 is complete and landed on the branch: parsePackages now reads the server's top-level `writable` verdict when the row carries one (typeof === 'boolean') and keeps `scope !== 'project'` untouched as the fallback for servers that predate objectstack#14375; the module doc comment is rewritten to say the server is the authority, the heuristic is only the legacy fallback, and it is wrong for the scope-less booted module row; the system/cloud hide filter is unchanged. Five pins plus a byte-identical negative pin, and a patch changeset for @object-ui/app-shell. Part 2 is split: the SINGLE-package negative is DONE and the MULTI-package verification is BLOCKED. Boot ref: objectstack bd0ee2fbb634e7cdcd3c2afffb6258fd8f3a0942 (head of PR objectstack#14430; confirmed NOT yet in objectstack main -- `withWritableVerdict` has 0 occurrences in origin/main's packages/runtime/src/domains/packages.ts). SINGLE-PACKAGE NEGATIVE: examples/app-todo booted on its own port with a fresh file: DB; GET /api/v1/packages returned 23 rows, all 23 carrying `writable`; the one row the switcher keeps is com.example.todo with scope 'project' and writable false -- identical to today's heuristic. A POST /packages/com.example.todo/duplicate then produced com.example.todo_copy with NO scope key and writable true, so both verdict directions were exercised against a live server; in the objectui HMR console (VITE_SERVER_URL + DEV_PROXY_TARGET pointed at that server, so this branch's code rendered) the switcher lists Todo Manager as Read-only and Todo Copy as Writable. That second row is exactly what a client-side 'missing scope means read-only' rule would have broken. MULTI-PACKAGE: blocked by objectstack#14439 per the PM's mid-course correction. One honest attempt -- a two-package packages[] config with one type:app and one type:module package sharing one namespace, neither declaring scope, booted through `os dev` -- was refused at the producer door, verbatim: '✗ defineStack validation failed (2 issues):' / '✗ packages.0.manifest.objects.0: Expected string but received object.' / '✗ packages.1.manifest.objects.0: Expected string but received object.' / '✗ Compile failed — fix errors above before starting dev server'. ArtifactPackageEntrySchema.manifest is the authoring ManifestSchema whose `objects` is z.array(z.string()) (glob patterns). A SECOND, independent door refuses the same shape after compile and is recorded on the PR for objectstack#14439 to meet as well: MetadataPlugin._parseAndRegisterArtifact hard-parses the whole artifact with ObjectStackDefinitionSchema before ADR-0130 D4's load path (which deliberately does not judge bodies) is reached, so an assembled packages[i].manifest.objects fails 'expected string, received object' and packages[i].manifest.permissions fails its union; measured by parsing artifact variants directly (objects + permissions: 4 issues; permissions removed: 2; both removed: passes). flows/apps and the other collections are undeclared on ManifestSchema, so they are stripped from the parsed copy and survive in the raw body -- which makes `objects` (Data pillar) and `permissions` (Access pillar) precisely the two the D4 seam cannot carry today. SECTION-FILTERING: not verified for the multi-package case; the one thing the API could be asked about a mixed install is that GET /api/v1/meta/flow?package=IDENT filters correctly per package (the client's `packageId` option is sent on the wire as `package`) -- objects and permissions could not be exercised because the fixture cannot carry them. Status is 'rework' only because the card's acceptance line 2 stays open behind objectstack#14439; the code change itself is complete and verified. Screenshots under /tmp/claude-0/-home-user/9474bf6f-d90c-5a21-b347-0245cc7e5487/scratchpad/issue-7177/shots/: todo-switcher.png (both verdict directions, the negative check), core-switcher.png, module-data.png, module-automations.png, module-access.png.",
 "tests": "All at dcef834 (git rev-parse --short HEAD after the final commit), exit codes captured by redirect before any pipe. (1) pnpm exec vitest run packages/app-shell/src/views/studio-design/packages-io.writableVerdict.test.ts packages/app-shell/src/views/studio-design/packages-io.test.ts packages/app-shell/src/views/studio-design/packages-io.duplicateEnvelope.test.ts -> 'Test Files 3 passed (3)' / 'Tests 23 passed (23)', lock VERDICT command-exit 0. (2) whole directory pnpm exec vitest run packages/app-shell/src/views/studio-design/ -> 'Test Files 44 passed (44)' / 'Tests 236 passed (236)', VERDICT command-exit 0. (3) pnpm --filter @object-ui/app-shell run type-check -> VERDICT command-exit 0, after building the dependency closure (pnpm --workspace-concurrency=2 --filter '@object-ui/app-shell^...' run build, 0); the chained tsconfig.test.json includes src/**/*.test.ts so the new pins are compiled. (4) eslint --no-inline-config --format json on the two changed files -> 0 errors 0 warnings, files linted 2. NARROWING DECLARED: population is the repo-wide `eslint .`, file count read from --format json, and eslint.config.js configures no type-aware linting (0 occurrences of projectService / parserOptions / project: / TypeChecked), so this diff cannot move any untouched file's verdict; CI runs the full farm regardless. (5) node scripts/check-changeset-presence.mjs -> exit 0, '1 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'. (6) pnpm check:control-bytes / check:vi-mock-specifiers / check:vi-mock-inherit / check:i18n-keys -> VERDICT command-exit 0, each printing its own OK line. (7) node scripts/check-governed-queue-guard.mjs --test on the three changed paths -> 'NOT GOVERNED'. (8) grep -naP for control bytes on the three changed files -> no match. ABLATION (prediction stated before the run): subject packages-io.ts restored to its pre-change bytes from the pinned base commit ad3d4029, with the fix COMMITTED first so the restore leg had a real restore point. Mutation confirmed ON DISK before measuring: removed-text count 0, injected-text count 1, git hash-object ccf29082... differing from the HEAD blob c94002e1.... No rebuild leg applies and none is claimed: the pins import the subject by a relative specifier inside the same package, so nothing resolves through dist. Predicted: only the two DISCRIMINATING pins go red (pin 1 scope-less writable:false, pin 3 scope:project both directions) while pins 2/4/5 and the negative stay green because they agree with the heuristic by construction. Observed exactly that: 'Tests 2 failed | 13 passed (15)', the two named tests. RESTORE leg: git checkout HEAD -- ABSOLUTE_PATH via a trap, on-disk blob back to c94002e170b25bc7a2d40500e7adfef3a7328393 (equal to the HEAD blob), git diff HEAD on the path empty, re-run 'Tests 15 passed (15)'. LIVE: GET /api/v1/packages on the app-todo boot returned 23/23 rows carrying writable; com.example.todo scope 'project' writable false; com.example.todo_copy scope ABSENT writable true.",
 "mcp_calls": "6",
 "open_questions": [
 {
 "question": "Multi-package Studio verification (switcher shows both, module marked read-only, the three sections filter by package) is unrun -- no producer emits a packages[] artifact. When should it be re-run?",
 "options": [
 "A: re-run against objectstack#14439's examples/app-multi-package fixture once it lands, on this same branch, before this PR leaves draft",
 "B: land this PR now on the Part 1 evidence and re-run as a follow-up card once objectstack#14439 lands",
 "C: hold this PR in draft until objectstack#14439 lands, whatever that costs in latency"
 ],
 "recommendation": "B, because the Part 1 change is independently complete and already verified against a live server in BOTH verdict directions (com.example.todo read-only, the scope-less duplicate writable), and the objectstack#14375 server half is itself still in draft; holding this behind a producer card that has not started serves no reviewer. The re-run is a small, well-specified follow-up and the PR body already names it as blocked-by."
 },
 {
 "question": "The D4 refusal has TWO doors, not one. objectstack#14439 as described covers the producer (defineStack / os compile). Does its scope also cover the ingestion door -- MetadataPlugin._parseAndRegisterArtifact hard-parsing the artifact with ObjectStackDefinitionSchema, which refuses assembled packages[i].manifest.objects and .permissions after compile?",
 "options": [
 "A: widen objectstack#14439 to cover both doors, since a producer that emits a packages[] artifact the runtime then refuses at boot ships a broken feature",
 "B: leave objectstack#14439 on the producer and file the ingestion door as its own card blocked-by it",
 "C: change ManifestSchema so the assembled body is expressible (a spec decision, explicitly out of a loader's hands per artifact-packages.ts's own module header)"
 ],
 "recommendation": "A, because the two doors refuse the SAME shape for the same reason and a producer card that stops at compile would land a fixture that still cannot boot. C is the real question underneath and is a spec decision for the maintainer, not something either card should settle on its own."
 }
 ],
 "out_of_scope_findings": [
 "NOT FILED, handed to the PM who said they are filing it: booting examples/app-showcase and calling GET /api/v1/packages answers HTTP 500 INTERNAL_ERROR 'Converting circular structure to JSON -- starting at object with constructor _ObjectQL ... property engine closes the circle'. Reproduced on objectstack bd0ee2fb. Pre-existing, unrelated to this change, and the reason the single-package negative check used examples/app-todo instead.",
 "NOT FILED, needs PM triage before a card is worth writing: POST /api/v1/packages/com.example.todo/duplicate on the app-todo boot answered HTTP 200 with data {success:false, copiedCount:0, failedCount:0, copied:[], failed:[]} -- the EMPTY arm objectui's own describeDuplicateFailure documents -- even though the source package carries 1 object, 4 flows, views, dashboards and reports. The package record WAS created (com.example.todo_copy appears in GET /packages, scope-less and writable), so the duplicate produced an empty base. I could not establish from the tree whether copying a booted CODE package's items is expected to be a no-op (the doc says the rows may be outside the caller's scope), so I am reporting the evidence rather than filing a possibly-wrong card. objectui's client side is correct here: it names the empty arm rather than reporting a bare HTTP error."
 ]
}

---

Generated by Claude Code

[hotlong]

PM 裁定：Part 1 现在落地；多包 Studio 验证挂到 objectstack#14439 落地后复跑

dev 报告已收（PR #7331）。两个 open question：

1. 何时复跑多包验证 → 取 B：本 PR 按 Part 1 证据落地。代码改动独立完整，已在真实服务器上双向验证（com.example.todo 只读、复制出的无 scope 键 base 可写），继续压在 draft 里对任何复审者都无益。复跑作为 objectstack#14439 落地后的验收项记在该卡（PM 负责，不另开卡）。
2. D4 有两道门 → 取 A：objectstack#14439 已扩到三道 parse 缝（作者态 defineStack、编译 compile.ts:271、装载 metadata/plugin.ts:912），见该卡评论；dev 已收到同步。

顺带两条平台发现都已入卡：showcase 包读门循环引用 500 → objectstack#14442；对代码包 duplicate 得到空 base → objectstack#14444（待 triage，不在 objectui 绕）。

落地步骤：按 objectui 规矩 git merge origin/main 同步（PR 当时 behind）→ CI 绿 → ready → squash auto-merge。

---

Generated by Claude Code

[hotlong]

更正：上一条里「对代码包 duplicate 得到空 base」的卡号写错了，正确的是 objectstack-ai/objectstack#14451（#14444 不是它）。其余不变。

---

Generated by Claude Code