双库方言维护预算（WS-G6）
状态：已定（2026-09-28 产品拍板，2026-09-29 写入治理）。本文自包含结论；历史论证与代码锚点见已归档 09-28 评估 §3 / §4.1。历史评估已归档至
docs/archive/architecture-2026-09/，本文对应的方言边界工作已随已归档收尾计划关闭；当前工作边界见现行执行计划。 适用范围：Backend 在 SQLite 与 PostgreSQL 上的迁移方言、认领/租约方言、事务与锁原语差异，以及为维持「Lite 一等公民」而保留的双库兼容成本。
1. 结论（口径）
- 正常双方言成本 = 固定税。日常为兼容 SQLite / PostgreSQL 付出的实现、测试与评审时间，计入季度预算，但不视为异常超支，也不自动触发方案重开。
- 正常预算 ≤ 8 人周 / 季。单季双方言相关投入以 8 人周为健康上限；这是规划预算，不是硬门禁。
- 超预算才重开 D1（双库方言决策）。仅下列任一条件成立时，才重新评估「是否继续双库 / 是否收缩 Lite 一等公民」；否则继续按固定税推进，不重开讨论。
2. 复审触发器（满足任一即重开 D1）
| # | 触发条件 | 口径说明 |
|---|---|---|
| T-1 | 单季计入 > 12 人周 | 当季双方言实现、排障、对拍、回归直接投入合计超过 12 人周 |
| T-2 | 连续两季 > 8 人周 / 季 | 相邻两个季度各自超过正常预算，即使单季未到 12 |
| T-3 | 方言阻塞发版 ≥ 3 次 / 季 | 因 SQLite / PG 语义差异、迁移或认领方言导致发版被挡或回滚，一个季度内累计 3 次及以上 |
| T-4 | 放弃 Lite 一等公民 | 产品决定 SQLite Lite 不再作为长期一等公民；此时双库永久税前提消失，应重开方言收敛决策 |
触发后重开的是 D1：双库 / Lite 地位的兼容策略，不是默认砍掉 PostgreSQL 或 SQLite；重开结论仍须写回本文并更新产品决策表。
3. 每季粗记账模板
每季末由维护者填一行，不必精确到工时单；用途是看趋势与触发器，不是绩效核算。
| 季度 | 双方言直接投入（人周） | 其中：实现 | 其中：排障/回归 | 方言阻塞发版次数 | 是否触发复审 | 备注 |
|---|---|---|---|---|---|---|
| 2026-Q3 | — | — | — | — | 否 | 基线季，拍板后开始记账 |
| 2026-Q4 | ||||||
填写约定：
- 投入只计「若只维护单库本可不做」的工作；跨库共用的重构、业务功能不计入。
- 阻塞发版指因方言差异导致 Release / 热修被挡或必须回滚的事件；单纯多写一层抽象不算阻塞。
- 连续两季触发 T-2 时，即使每季都 ≤ 12，也要重开 D1。
4. 与其它治理项的关系
- 日常双方言实现边界仍受
backend/app/db/收口约束（见根目录AGENTS.md）；本预算不授权绕过db/适配层。 - Lite 目标规模（5–10 人、预览并发约 3）见 Lite 规模与隔离决策；D2 容量基线未采集前，规模只是目标不是 SLA，与本预算独立。
- 任务运行时的认领方言映射见 统一任务运行时契约；迁移方言份数下降会降低本预算的实际占用。