[Decision] 老客户把「选一个人」的字段改成「选多个人」时,平台该自己动客户的库,还是只报警要人来动?(#11535 的自动迁移半边)

[huangyiirene]

由 domain:engine 执行席落卡(session session_01VK8rFDtg8eREaxBGX99Csn)。这是 #11535 被切下来的那一半 —— 那张卡是真实客户报障(作者 baozhoutao,生产库,已手工抢修)。检测半边我已经派发(见 #11535 的认领评论),自动迁移半边不是我能裁的:它动的是存量数据的迁移形状,是破坏性且难回滚的动作,按协议恒交维护者。

一句话问题

一个用了很久的客户,把某个字段从「选一个人」改成「选多个人」,重启之后系统什么都没说,然后开始把「张三、李四」当成一整串文字塞进原来只放一个人的那一格里;自动化流程再把这一整串当成一个人名复制到子记录上,指向一个根本不存在的人。全新装的系统没这个问题,只有真实运营了一段时间的客户会中。现在的问题是:平台发现这件事之后,该不该自己动手改客户数据库的表结构。

前提(带 re-check 命令,复升级时逐条重跑)

• 现在的漂移动作词表只有 5 种,没有「改列基类型」这一项:
  git grep -n "widen_varchar\|narrow_varchar\|drop_column\b" origin/main -- packages/drivers/driver-sql/src/schema-drift.ts
  (2026-08-24 实测:schema-drift.ts:129-133,五种动作,无基类型变更)
• 检测半边是否已落地:看 driver-sql: single→multi-value field change never migrates the existing column type (varchar/text kept), arrays silently stored as stringified literals — data corruption on Postgres #11535 的 Part of PR 是否已合。本卡的选项 B 就是「检测半边即终局」,所以先确认它到底落成了什么。

三条路,和各自客户能感觉到的代价

	做什么	客户感觉到的代价
A	平台在启动时自己改列(顺带删掉旧索引再建)	客户不用做任何事,重启就好了。⚠️ 但平台在没人看着的时候动了生产库的表结构 —— 改错了、或中途断了,恢复要靠备份。一次失败就是一次停机事故,而且是我们造成的。
B	只报警,要人来动	平台绝不碰客户的数据。⚠️ 但客户改个字段就撞上一条「请手工迁移」的错误,得会写 SQL 才能继续;不会写的就卡在那儿,或者干脆忽略警告继续跑,继续坏数据。
C	报警 + 给一条客户自己敲的迁移命令(不在启动时自动跑)	客户要多敲一条命令,但是他自己按下的按钮、自己挑的时间(可以先备份、挑半夜)。⚠️ 我们要多维护一条命令和它的回滚说明。

业务含义直译:A = 「平台替你做主,像自动更新」;B = 「平台只当报警器,像体检报告说『你去做手术』」;C = 「平台给你一把有说明书的手术刀,你自己决定什么时候用」。C 是数据库产品里最常见的做法(和 Salesforce 改字段类型要走一个显式的转换向导、而不是后台偷偷改,是同一个姿态)。

os-decision-facets

• 实际业务拉动:今天就有客户撞上了,而且是已经在生产环境流血的那种 —— 数据已经坏了、已经手工抢修过一轮。三条路都解决「以后不再静默变坏」,区别只在谁来动手。所以这一轴推「必须做点什么」,但不偏向 A:客户要的是「别再悄悄坏」,不是「你替我改库」。
• 项目长远合理性:A 会让平台永久背上「自动改客户表结构」这个承诺 —— 今天是一种字段变更,明天客户会问为什么另外七种不自动改,特例只会增生。C 把能力做成一条显式命令,边界清楚,不承诺「所有变更都自动」。⇒ 偏 C。
• 防 AI 写代码犯错:这一轴看的是出错时谁看到什么。现在最坏:没人看到任何东西,数据默默坏掉,几周后才在一张子记录上发现指向不存在的人 —— 这正是「静默容忍」最贵的形态。A 也有静默的一面:改库成功了没人知道,失败了才知道。B 和 C 都是响亮拒绝:出错当场有人看见,而且看见的是「这张表这一列要迁移」而不是一句含糊的报错。⇒ 强推 B/C,反对把「自动改了」当成默认的安静路径。
• 创业阶段不扩散需求:A 是一个新的平台级能力(迁移引擎 + 索引重建 + 失败回滚),是这三条里最大的一件;而它服务的场景是「改字段类型」,不是每天发生的事。C 的成本接近 B 加一条命令。⇒ 反对 A,偏 B 或 C。

推荐:C(报警 + 显式迁移命令),回退 B(只报警)。 四轴里没有一条支持 A 作为自动、无人值守的行为;A 真正值钱的部分(那段 SQL 怎么写才对)在 C 里同样交付,区别只是谁按下按钮。

⚠️ 本分析看不见什么(强制置信缺口):① 我不知道有多少客户手上是「长期运行库」,也就是说不知道这件事一年会发生 3 次还是 300 次 —— 如果是 300 次,B 的人工成本会难看得多,A/C 的性价比要重算;② 三条路都不修已经坏掉的数据。报障人除了改列,还得「repair the child rows that had already been corrupted」—— 那是第四件事,谁都没覆盖,可能需要单独一张卡;③ 我没有实测 A 在有外键/有索引/有大表时的失败率,那是最能决定 A 是否可接受的数字,而我没量。

裁后我会怎么执行(你不用管)

• 回 C ⇒ 我把命令面立成独立卡进 domain:engine 队列(命令 + 干跑 + 回滚说明 + 文档),driver-sql: single→multi-value field change never migrates the existing column type (varchar/text kept), arrays silently stored as stringified literals — data corruption on Postgres #11535 待检测半边落地后转 pm:blocked 指向它。
• 回 B ⇒ driver-sql: single→multi-value field change never migrates the existing column type (varchar/text kept), arrays silently stored as stringified literals — data corruption on Postgres #11535 在检测半边落地后即可关闭,我在卡上记明「自动迁移不做」及理由。
• 回 A ⇒ 我会先回来问一次边界(启动时跑还是首次写时跑、失败怎么办、大表要不要拒绝),因为那几个是 A 真正的风险面,不该由我替你填。
• 另外无论哪条,我都会问你一句要不要为「修复已经坏掉的存量行」单独立卡(见置信缺口②)。

低摩擦裁决格式:回一个字母即可;「C,但 X」我会按 C 落地并把 X 记进卡里;不回等于留在箱里,不会有人替你裁。

相关

• driver-sql: single→multi-value field change never migrates the existing column type (varchar/text kept), arrays silently stored as stringified literals — data corruption on Postgres #11535 —— 客户报障原卡,检测半边已派发(Part of,⛔ 不 Fixes)
• 漂移动作词表现状:packages/drivers/driver-sql/src/schema-drift.ts:129-133

⚠️ 落卡说明:本卡首版用协议规定的 HTML 注释标记 os-decision-facets 写四棱块首行,回读发现被 sanitizer 吃掉(与本轮两个 dev 的报告标记同一失效模式)。已改为字面文本重写 —— 协议本身规定提取按字面文本 grep、不依赖注释形状,所以字面写法是合规的,并且是唯一能存活的写法。

[os-zhuang]

Maintainer ruling recorded

Ruled 2026-08-24, live PM chat, verbatim: 「11700 11693 不需要考虑历史数据，其他按照你的建议继续」 (on the skills seat's four-facet digest, which recommended C).

Ruled: C — warn + an explicit operator-run migration command (dry-run + rollback notes + docs; never run automatically at boot). Amendment to the recommendation, by the maintainer's own words: historical data is NOT in scope — no separate card for repairing already-corrupted child rows (the confidence-gap-② rider is struck; rows corrupted before the detection landed are the customer's to repair, as the reporting customer already did). Option A (unattended auto-migration) is rejected on all four facets; B survives only as C's degenerate form if the command is never shipped.

Execution per the filing seat's own recorded plan: the command surface becomes its own domain:engine queue card (command + dry-run + rollback notes + docs); #11535 flips pm:blocked pointing at it once the detection half lands; this decision card closes when the command card exists and carries the ruling reference. needs-user-decision → pm:queue in the same stroke so the engine seat picks up the split.

---

Generated by Claude Code

[huangyiirene]

Closing — ruled C, and the command card now exists

Executed by the filing seat (domain:engine, huangyiirene, session session_01VK8rFDtg8eREaxBGX99Csn) per this card's own "裁后我会怎么执行" section, which said: reply C ⇒ the command surface becomes its own domain:engine queue card, and this decision card closes once that card exists carrying the ruling reference.

Command card: #11733 — carries the verbatim ruling, the C shape (migration + dry run + rollback notes + docs, never automatic at boot), and the measured remedy SQL from PR #11720 so it is not re-derived.

⚠️ The amendment is carried, not quietly dropped. The ruling's own words — ⛔ quoted, not translated — 「11700 11693 不需要考虑历史数据，其他按照你的建议继续」 strike confidence-gap ② from my analysis: I had flagged that no route repairs rows corrupted before detection landed and suggested a separate card might be needed. That card is not being filed, and #11733 says so explicitly with an ⛔ instruction not to add backfill or row-repair. Rows already corrupted are the customer's to repair, as the reporting customer did.

A is rejected (unattended auto-migration — the only route where the platform alters a customer's production table with nobody watching). B survives only as C's degenerate form if the command never ships, which #11733 exists to prevent.

State written down, so nothing is left half-done

• An operator-run command to migrate a stale column to json when a field went multi-value (ruled C on #11700) #11733 — pm:queue + domain:engine, unassigned, the execution card.
• driver-sql: single→multi-value field change never migrates the existing column type (varchar/text kept), arrays silently stored as stringified literals — data corruption on Postgres #11535 — the customer's report. Its detection half is PR fix(driver-sql): report a multi-value field left on a stale varchar/text column #11720 (ACCEPTed, landing). Once that lands, driver-sql: single→multi-value field change never migrates the existing column type (varchar/text kept), arrays silently stored as stringified literals — data corruption on Postgres #11535 flips pm:blocked with Blocked-by: #11733 — the remaining half of the customer's problem is the command, and a queue label on it would be a lie about what is dispatchable.
• This card — closed completed, pm:queue stripped in the same stroke so it does not leave the board carrying a state label.

⚠️ One thing #11733 must settle before it is dispatched, flagged rather than assumed: the drift finding lives in packages/drivers/driver-sql, but an operator-facing command plausibly belongs in packages/cli beside the other os migrate surfaces — another seat's lane. If it lands there, #11733 is a cross-lane card and goes to that queue rather than into a driver PR. Its domain:engine label is this seat's transcription of where the decision was made, not a measured landing point; triage should correct it freely.

---

Generated by Claude Code