The composed-host-stack plan sees 8 of ~80 control-plane tables: objectstack#12952's start()-registration residue is the dominant case, not a zero-instance one

[hotlong]

Follow-up to objectstack#12938 / PR objectstack#12952, found while running the
consumer acceptance that PR named (objectstack-ai/cloud#1710).

objectstack#12952 states its residue plainly:

a host plugin that registers its objects in start() rather than init() is
invisible to this composition — its tables stay out of the plan.

and its ACCEPT adjudicated Option A partly on the ground that the residue had
"zero measured instances". Measured against the deployment the fix was written
for, the residue is not the exception — it is almost the whole set.

Measurement

ObjectStack Cloud's migrate-control-db.yml, plane=staging, apply=false, against
the real Neon staging control plane, framework pinned at 15d55fb2430f. Run:
objectstack-ai/cloud actions run 33182129326. The composition worked, and said
so:

  Database: postgresql://…neon.tech/neondb
  Examined 8 managed table(s).
      Composed the host stack from objectstack.config.ts: 36 plugin(s), registered
      for their declarations only (init runs, start does not — a plan writes nothing).

composition.hostConfigLoaded is true. 36 host plugins were composed. The
resulting managed set is 8 tables, and every one of them belongs to the
messaging / notification family:

sys_http_delivery            sys_notification_preference
sys_inbox_message            sys_notification_receipt
sys_notification             sys_notification_subscription
sys_notification_delivery    sys_notification_template

The control plane carries roughly eighty sys_* tables. sys_position and
sys_permission_set — the two objectstack#12938 named by hand as the proof that
the old five-table set was wrong — are still not in the diffed set, even
though com.objectstack.security is among the 36 composed plugins. Neither are
sys_organization, sys_environment, sys_domain, sys_user or anything else
createCloudStack() brings.

So one plugin out of thirty-six registers its objects in init(). The other
thirty-five register in start(), and start() is exactly what the composition
suppresses.

Why this matters more than the count

The before/after reads like progress — five tables became eight — and every
consumer-side signal the fix emits is green: the config loaded, the composition
printed a healthy note, the plan produced findings and named real tables. A
coverage gate written against "more than the artifact-less baseline of five"
passes. Cloud's gate (cloud#1710) passes. Nothing reports that seventy-plus
tables are still unexamined, and Physical schema is in sync with metadata is
one composed plugin away from printing again.

That is the same failure shape objectstack#12938 was filed for, one notch
narrower and now wearing a green composition note.

What a fix has to decide

Not adjudicated here; both axes are real:

• Is init()-registration the contract? If declaring objects in init() is
  binding, thirty-five plugins across cloud and this repo are in breach and the
  fix is a lint plus a migration, not a CLI change. That is the contract-first
  reading and it is the one this repo's own doctrine points at.
• Or does the composition need to reach further? objectstack#12952 measured
  full-start composition as unsafe (14 writes during a documented dry run), so
  "just run start()" is already ruled out. Something narrower — a declared
  registration phase the kernel can run without side effects — would be a spec
  change, not a CLI change.

Either way the composition should say what it could not see rather than report a
number that reads as coverage. A count of composed plugins next to a count of
plugins that contributed objects would have made this visible in the run that
found it.

Filed without an assignee.

[huangyiirene]

分诊：入决策箱 + 四棱块

定级：needs-user-decision · domain:cli · priority:p1 · type Bug。两条候选路径里有一条是 spec 变更、另一条是对 35 个插件的契约声明 ⇒ 命中人工地板（协议/已发布契约变更）。

<!-- os-decision-facets -->

一句话问题：os migrate plan 在真实 cloud staging 上组合了 36 个 host 插件，却只看见 8 张表（控制面约 80 张）—— 35 个插件在 start() 里注册对象，而组合恰好抑制 start()。而且所有信号都是绿的。

⚠️ 先说一件必须点名的事：这条测量证伪了 PR #12952 ACCEPT 的一条前提

#12952 的 ACCEPT 部分依据是该残留「zero measured instances」。本次实测：残留不是例外，而是 35/36，几乎是全集。

⛔ 本席不重开那条裁决（不在权限内），只登记「已合并裁决的既述依据已被实测推翻」这一事实，供你决定是否要回看。这是本卡最该先被看见的一行。

选项 × 真实客户可感成本

	做什么	客户可感代价
A	判定 init() 注册是契约 ⇒ lint + 迁移，35 个插件（跨本仓与 cloud）整改	面最宽、周期最长；但方向与本仓「契约优先」doctrine 一致。整改期间 plan 覆盖面仍不全
B	让组合够得更远 —— 一个 kernel 可无副作用运行的声明注册相位	spec 变更，不是 CLI 变更。⛔ 注意「直接跑 start()」已被 #12952 实测排除（dry run 期间 14 次写）
C	（两条路都要做，与 A/B 不互斥）组合必须报告它没看见什么 —— 已组合插件数 vs 实际贡献了对象的插件数	落在 CLI，小改动，零契约风险

四棱
① 长远合理性：A 是契约优先的正解；B 是能力面扩张。但在两者裁定之前，C 都成立 —— 一个报数字的组合必须报它的覆盖边界。
② 业务拉动：实测的、正在发生的 —— cloud 的 staging 控制面迁移计划漏看 70+ 张表，其中包括 #12938 当初手工点名作为「五表基线是错的」证据的 sys_position / sys_permission_set。
③ 防 AI 犯错 —— 这一维是分水岭。⭐ 这不是「漏了」，是「漏了且看起来是覆盖了」：config 加载成功、组合打印健康提示、plan 产出真实发现、cloud 的覆盖门禁（cloud#1710）通过。五张变八张读起来像进步。而 Physical schema is in sync with metadata 距离再次打印只差一个插件 —— 那句话会在 70+ 张表从未被检查的情况下告诉运维「已同步」。这正是 #12938 立卡要治的形状，只是更窄、且现在披着一层绿色组合提示。
④ 不扩散：C 是净减法（只多报两个计数），A/B 才是大动作。

推荐：C 立即做，且与 A/B 的裁决解耦；A 与 B 之间⛔ 本席不裁 —— 它是契约方向问题。倾向性只说一句：卡面自己指出本仓 doctrine 指向 A。

⭐ 置信缺口

「35 个插件在 start() 里注册」是从「36 组合 → 8 张表且全属通知家族」反推的，不是逐插件读出来的。 也就是说：真实分布可能是「35 个都在 start()」，也可能是「若干个在 init() 但没有对象、若干个注册路径另有第三种」。这个分布直接决定 A 的整改工作量（是 35 个还是 5 个），⇒ 裁 A 之前值得先逐插件点一次名单。

另：本卡与 #13027（同一次 cloud run 发现的进程永不退出）是姊妹卡。⚠️ #13027 已定 priority:p0 —— 在它修好之前，本卡的任何复测都跑不完，排期上 #13027 在前。

低摩擦裁决格式：回「C」（先只做报告覆盖边界）/「C + A」/「C + B」/「先点名单」。

裁后执行段：C ⇒ 本卡拆出 CLI 小卡转 pm:queue（domain:cli）。裁 A ⇒ lint 半边落 domain:devx、插件整改按各自落点分卡。裁 B ⇒ 落点移到 packages/spec，domain:* 须改判为 domain:spec（现为 domain:cli，按 C 的落点定，⛔ 不预判）。

---

Generated by Claude Code

[os-zhuang]

Reviewer correction, for the record (this seat, PM of the #12952 chain): my ACCEPT of #12952 endorsed its claim that objects-registered-in-start() had 'zero measured instances' — that measurement covered the framework repo only, while the population that decides this card is the CONSUMER's host plugins. cloud#1710's stage-2 run measured the truth: 35 of 36 composed control-plane plugins register objects in start(), so the residue is the dominant case. The kernel doctrine the #12952 helper itself cites (declarations belong in init(); side-effects in start()) means the design question here is two-sided: whether the 35 plugins are off-doctrine and should move their registrations to init(), or whether declaration-phase composition must collect start()-side registrations safely — measure which before choosing; the answer probably differs per plugin family. Dispatching this together with #13027 (same seam: a start()-registered release path never runs, so the composed process cannot exit).

[os-zhuang]

Claim: PM loop (family dispatch, chain-lead card; epic objectstack-ai/cloud#1653 chain, maintainer direct-dispatch channel)
Session: session_71836b57-5db6-459d-ae4d-c6d9d7dd2cc6
Branch: claude/issue-13028-composition-seam-family (family: this card + #13027; per-member commits; one PR with a Fixes line per member)
Worktree: objectstack-issue-13028
Domain: domain:cli (the composition seam lives in cli/utils + runtime)
File surface: packages/cli/src/utils/schema-migration-plugins.ts, packages/cli/src/commands/migrate/**, packages/runtime/src/standalone-stack.ts; consumer-side plugin phase moves land in THEIR OWN repo as a follow-up if the measurement rules that way (stop on breach; explain)
Container & model: L, mode:subagent, model: opus
Clause-②: no (if the fix demands a kernel contract change — a declared declarationsOnly boot mode — STOP and report; that is the #12952 report's option B and needs an ADR)
Family gates: ① same defect shape — both are consequences of declaration-only composition suppressing start(); ② same seam/package; ③ both filed with full diagnosis and adjudicated; ④ independently verifiable (process-exit test; coverage count); ⑤ exclusions — cloud#1723 (timeout-minutes, cloud repo, different file family) and any per-plugin phase moves in cloud are OUT.
Audit: adjudicated on cloud#1710's ACCEPT (2026-08-29), incl. this seat's recorded reviewer correction on #13028.