[CRM] 9 个孤儿 __search 列待清理（17.0 收紧搜索伴生列供给条件后遗留）

[yinlianghui]

现象

os migrate plan 报 9 个对象存在数据库里有、元数据中无的 __search 伴生列（crm_competitor、crm_opportunity_line_item、crm_quote_line_item、crm_task、sys_metadata 等）。

不影响功能。择机执行 os migrate apply --allow-destructive 清理即可（注意先停服务，参见平台 issue #526）。

详见分支 upgrade/objectstack-17 的 docs/upgrade-17/test-report.md §4 L2。

[yinlianghui]

📎 分支 upgrade/objectstack-17 已推送至上游（仅分支，无 PR，勿合并——阻塞于 17.0 正式版与 objectstack#3912/#3913/#3914）。正文引用的文档现在可直接访问：测试报告 ｜ 测试计划

[yinlianghui]

⚠️ 改判：不要执行本 issue 原建议的 --allow-destructive 清理。

列级验证（同一 worktree、同一 artifact、两个全新库）：

• objectstack dev 建的库：crm_task 34 列，含 __search
• os migrate plan --database-url <新文件> 建的库：33 列，无 __search；且 migrate 对自己建的库报 0 destructive

即这 9 个 __search 不是孤儿，而是 dev 运行时（pinyin 搜索伴生列）供给并在用的活列；是 migrate CLI 与 dev 运行时的 schema 视图不一致把它们误判成孤儿。按原建议清理会删掉搜索功能的列，下次 dev 启动还可能重建。

已上报平台：objectstack-ai/objectstack#3955（含复现表格；顺带报告了全新库立即出现 3 条 relax_unique_index 的建表/漂移不对称）。

本 issue 状态改为：阻塞于上游 #3955，在平台修复前不做任何本地清理动作。

[yinlianghui]

已重开：本 issue 是被提交信息误关的，结论未变

#542 合并后本 issue 于 2026-07-30 10:04 被自动关闭。这是误关，已重开。

原因

关闭它的不是 PR 描述，而是 commit message：fba1f4fa（#542 的首个提交）正文第 14 行带着 Closes #528。该提交随合并进入 main，GitHub 按提交信息执行了自动关闭。

改写 #542 描述时我确认过 GitHub 的 closingIssuesReferences 字段为 0，据此判断合并不会关闭本 issue——那个字段只反映 PR 描述，不包含提交信息里的关键字，所以判断有误。提交信息在 PR 创建时就已写好，改描述改不到它。

结论不变：不要做任何清理

评论区早前的改判仍然成立：

• 那 9 个 __search 列不是孤儿，是 dev 运行时（拼音搜索伴生列）供给并在用的活列；
• 根因是 migrate CLI 与 dev 运行时的 schema 视图不一致，已上报 objectstack#3955；
• 按原建议执行 os migrate apply --allow-destructive 会删掉搜索功能的列。

本 issue 保持打开，阻塞于上游 #3955，在平台修复前不做任何本地清理动作。

已合并的 #542 并不与此矛盾

#542 最终合入的手册（docs/MAINTENANCE.md §3.1）已经按改判重写：它把 17.0 的 __search 报告记为已知误报（do not touch until #3955 lands），并给计划复核步骤加了第二道判据（是否运行时伴生列）和取证方法（与同 artifact 新建库对比列清单）。也就是说 main 上的文档立场是正确的，只有这个 issue 的开关状态错了，现已修正。

给后续的提醒

若某个 PR 的提交信息里带 Closes/Fixes #N，仅改 PR 描述不足以阻止关闭——需要改写提交信息（force-push），或在合并后手动重开，就像这次一样。