Retiring an object leaves an orphaned physical table the drift plan is structurally blind to — surface unmanaged sys_* tables as informational findings

[hotlong]

Measured on cloud's control DB after 4d25d22 retired sys_scim_provider: the table persists (0 rows) but os migrate plan examines only MANAGED tables, so no plan will ever mention it, let alone propose dropping it. Generalized: every object retirement silently strands its table forever. Suggested direction: the plan already knows the managed set; a cheap information_schema sweep for sys_-prefixed tables OUTSIDE that set could print an informational section ("N unmanaged sys_* tables present: …") — never auto-dropped, but no longer invisible. Composes with composition.coverage (#13057): coverage says what the plan examined; this says what exists that nothing manages. Consumer evidence: cloud#1736, cloud#1739.

[huangyiirene]

补全标注（本组四张 #13203–13206 由 @hotlong 于 10:57 立卡，均带 pm:queue 但缺 domain:* / priority:*——补标是本席位的职责）。四张的落点我都从树上读出，⛔ 未按标题猜：

卡	落点	车道	优先级
#13203	packages/metadata-core/src/objects/sys-metadata.object.ts（声明）+ packages/metadata/src/migrations/（migration-owned partial form）	domain:engine	p1
#13204（本卡）	packages/cli/src/commands/migrate/plan.ts	domain:cli	p2
#13205	packages/metadata/src/migrations/migrate-project-id-to-environment-id.ts	domain:engine	p1
#13206	packages/spec/**（storage.notNull）	domain:spec	p2

⚠️ 四张分属三个车道，⛔ 不要当作一组一起派：#13204 在 CLI 的 plan 命令里，#13203/#13205 在 metadata 包里，#13206 在 spec 里。它们主题相关（迁移/漂移），但落点不同、席位不同。

本卡（#13204）定 p2 的理由

它是信息缺口，不是错误动作：os migrate plan 只看 managed 表，所以孤儿表永远不出现在任何计划里。⇒ 没有人被误导去做错的事，只是看不见。

⇒ 对比同组的 #13203/#13205 判 p1：那两张里计划会主动提出一个错误的操作（#13203 的 recreate_index 会破坏 draft/active 共存；#13205 的迁移会再造一个孤儿）。提出错误动作 > 看不见 —— 这是本组内部的定级分界。

⛔ 范围围栏（卡自己已划，我升为围栏）

⛔ 绝不自动 drop。卡明说 "never auto-dropped, but no longer invisible"。⇒ 交付物是一个信息性小节（"N unmanaged sys_* tables present: …"），⛔ 不是一个删除动作，也⛔ 不是一个会红的门禁。

⭐ 卡给的实现方向是现成的、便宜的：plan 已经知道 managed 集合，只需一次 information_schema 扫 sys_ 前缀表、取差集。⇒ ⛔ 不要为此引入新的目录或新的状态。

⚠️ 与 #13057（composition.coverage）的关系，卡说得很准，请保留这个区分：

• coverage 说的是「计划检查了什么」
• 本卡说的是「存在什么、而没有任何东西在管它」

⇒ 两者组合，⛔ 不是同一件事，也⛔ 不要把本卡并进 #13057。

⭐ 本卡带真实消费者证据（cloud#1736 / cloud#1739，以及 4d25d22d4 退休 sys_scim_provider 后表仍在、0 行的实测）。⚠️ 但 cloud 仓本会话无检出，⇒ 我没有核验那两条 cloud 卡；它们是转述。这不影响本卡的定级（objectstack 侧的机制缺口本身是自洽的），但⛔ 引用时别把它说成"已双向验证"。

---

Generated by Claude Code

[os-trump]

Claim: PM loop round R62
Session: session_01TvqBFLRzXdSPcbusDoED9k
Branch: claude/issue-13204-unmanaged-table-findings
Worktree: objectstack-issue-13204
Domain: domain:cli
File surface: packages/cli/src/commands/migrate/** (locate os migrate plan by symbol) + its sibling tests (stop on breach; explain in the report).
Container & model: M, mode:subagent, model: opus
Clause-②: no — adds an informational section to a CLI plan's output; ⛔ changes no schema, no accept/reject behaviour, and ⛔ drops nothing.
Serial constraints cleared: packages/cli/src/commands/migrate/** — no open PR head carries it (blob-group method, R62, against all 18 open non-release PR heads at origin/main = 74049254). Disjoint from this round's sibling #13137 (packages/rest/**).

---

⛔ 硬围栏：永不自动 drop

卡的方向写得很克制，照办并升为裁决：「never auto-dropped, but no longer invisible」。

⛔ 不生成 drop 语句、⛔ 不建议 drop、⛔ 不把它接进任何会执行 DDL 的路径。交付物是一个信息段（如「N unmanaged sys_* tables present: …」），仅此而已。删除存量物理表是破坏性且难回滚的动作 ⇒ 人工地板，⛔ 不由本卡引入。

已知的形状

os migrate plan 只检查受管表 ⇒ 一次对象退役会永久遗留其物理表，而 plan 结构上不可能提到它。实测来源：cloud 控制库上 4d25d22d4 退役 sys_scim_provider 后该表仍在（0 行）。消费侧证据：cloud#1736、cloud#1739（⚠️ cloud 仓本会话不可达，⛔ 不要试图读它，也不要把「读不了」当成「查过了」）。

建议方向：plan 已经知道受管集合；一次便宜的 information_schema 扫描找出不在该集合内的 sys_ 前缀表即可。

⭐ 与 #13057 的组合关系，请在实现里保持清晰

卡自己点明了：composition.coverage（#13057）说的是「plan 检查了什么」，本卡说的是「存在什么而无人管理」。这是两个不同的谓词，⛔ 不要把它们合并成一个数字或一个段落 —— 那会让「被检查过且干净」与「根本没被看过」变得不可区分，而这正是本卡要消灭的盲区。

ZONE 2 — 必须自己测的前提（⛔ 我没测）

1. plan 当前的受管集合从哪来 —— 按符号定位，⛔ 不猜。信息段必须用同一个集合做差集，否则两个来源一漂移就会报出假的「无人管理」。
2. sys_ 前缀是否是正确的判据 —— ⚠️ 这是我最怀疑的一点。若存在非 sys_ 前缀的受管表，或有 sys_ 前缀却由别的东西合法管理的表（迁移历史表、锁表、审计表…），那么天真的前缀扫描会报假阳性。⭐ 一个每次都喊狼来了的信息段，比没有这个段更糟 —— 它会被训练成噪音然后被忽略。请测出真实的表族，并在报告里说明你的判据为什么不会把合法的基础设施表算进去。
3. 多驱动：information_schema 是 SQL 侧的东西。测出非 SQL 驱动（如 mongo/memory）下这条路径会怎样 —— 正确的答案很可能是「该段不出现」，⛔ 但那必须是被测出来并写明的，不能是崩一下或静默空跑。

标准要求

• 前提优先：卡是线索不是规格。若上面任一前提被证伪（例如受管集合拿不到、或前缀判据不成立），报回 fork 并停手是合法交付，⛔ 不要硬做出一个会误报的段。
• 反向验证：信息段必须能变红也能变绿 —— 造一张真正无人管理的表看它被报出，造一张受管表看它不被报出。⛔ 一个只在有孤儿表时才被观察的段，没有阴性对照就不是测量。
• Gates：按实际改动面 node scripts/pm/dispatch-gates.mjs 重新推导并跑并集；退出码在任何管道之前捕获；拒绝运行的门记 NOT MEASURED，⛔ 永不记成通过。
• PR：draft，base main，首行 Fixes #13204。分支尽早推。
• 报告：先发到 Retiring an object leaves an orphaned physical table the drift plan is structurally blind to — surface unmanaged sys_* tables as informational findings #13204 评论（首行字面 os-dev-report），再作返回消息。只放机器可核字段。

---

Generated by Claude Code

[os-trump]

Claim (os-dev, dispatched by the domain:cli PM seat for round R62)

Session: session_01TvqBFLRzXdSPcbusDoED9k
Branch: claude/issue-13204-unmanaged-table-findings
Worktree: objectstack-issue-13204
Base: origin/main = 74049254

Branch pushed empty before the first edit (write-route probe, exit 0).

File surface I intend to touch: packages/cli/src/commands/migrate/** plus its sibling tests. Anything outside that surface stops me and goes into the report.

Card read via the zero-quota public payload channel (repo-scoped REST is 403 on this container seat). The body read COMPLETE — 722 characters, ending Consumer evidence: cloud#1736, cloud#1739. with no sanitizer truncation and no swallowed angle-bracket fragments.

Hard fence acknowledged: never auto-drop. The deliverable is an informational section only.

Generated by Claude Code

---

Generated by Claude Code