#321 · prod 测试数据清理方案（精确删除清单 + 回滚方案）

依据义父 2026-09-30 口令：prod 的商品/订单按测试数据处理，只要已上线 C 端不受损即可清理；

但执行须先经本清单审批。本文件只列方案与精确 SQL，未在任何环境执行 prod 删除或下线。

>

纪律：未经义父确认清单，不执行 prod 删除或零售 C 端域下线。prod 冻结中。

一、备份与回滚锚点（已生成）

回滚策略（两层）：

1. 手术级（推荐）：执行删除前，先对受影响表做单表 dump：

docker exec kailash-pg pg_dump -U yos -d kailash -Fc -t orders -t order_items -t commission_entries -t redemption_events -t distribution_records -t guest_bindings -t settlement_records -t refund_records -f /tmp/prod_affected_pre.dump

若删除后需回滚，用 --clean --if-exists 仅恢复这 8 张表，不动其余数据。

1. 全量级：上述全量 dump 作终极兜底（恢复会覆盖删除后所有新数据，仅在手术级不足时使用）。

二、已查清的测试行与关联关系（prod 实测）

2.1 四表行数与 is_test 分布

2.2 orders.order_type 分布（291 笔测试单）

room 65 / package 195 / ticket 24 / retail 7（均为 is_test=t）；另有 4 笔 is_test=f 全为 retail。

2.3 4 笔「未打 is_test 标记的测试单」（需义父拍板，见 §3 Tier-2）

• 全部 pending_payment（未支付，无退款/资金风险）。
• 商品均为 印刷唐卡（goods.id=20，¥288），明细 source='self'、fulfillment_item_id=NULL，未绑表主键。
• 属 09-30 测试窗通过真实小程序下的单，但漏打 is_test 标记 —— 按新口令「全部按测试数据」建议删，但因 is_test=f 需显式确认。

2.4 外键约束（决定删除顺序，关键安全点）

指向 orders 的外键共 12 张表，分两类：

• CASCADE（自动带走）：order_items、fulfillment_items、order_events、reviews、room_bookings（及 user_temple_stamps/user_footprints 为 SET NULL）。
• RESTRICT（须先手动清）：commission_entries(50)、redemption_events(148)、distribution_records(50)、guest_bindings(0)、settlement_records(0)、refund_records(0)——括号内为 prod 上引用 is_test 订单的行数。

⚠️ staging 验证实测教训：staging 的 guest_bindings 有 1 行引用 is_test 订单，若不先清会撞 FK。prod 当前为 0 但方案仍纳入，防未来漂移。

三、精确删除清单（待审批）

Tier-1 · 明确测试数据（建议直接删，无业务价值）

-- 在 prod 单事务内执行（BEGIN ... COMMIT），ON_ERROR_STOP=1
DELETE FROM commission_entries  WHERE order_id IN (SELECT id FROM orders WHERE is_test=true);  -- 50
DELETE FROM redemption_events  WHERE order_id IN (SELECT id FROM orders WHERE is_test=true);  -- 148
DELETE FROM distribution_records WHERE order_id IN (SELECT id FROM orders WHERE is_test=true); -- 50
DELETE FROM guest_bindings     WHERE anchor_order_id IN (SELECT id FROM orders WHERE is_test=true); -- 0(安全)
DELETE FROM settlement_records WHERE order_id IN (SELECT id FROM orders WHERE is_test=true);  -- 0(安全)
DELETE FROM refund_records     WHERE order_id IN (SELECT id FROM orders WHERE is_test=true);  -- 0(安全)
DELETE FROM orders WHERE is_test=true;  -- 291，级联带走 order_items(202)/reviews/order_events/room_bookings 等

预期结果：orders 295→4，order_items 206→4，goods/retail_products 不变。

Tier-2 · 4 笔未标记测试单（需义父确认）

-- 仅当义父批准时追加（同样在事务内）
DELETE FROM order_events WHERE order_id IN (6280,6281,6282,6283);  -- 4(CASCADE 已含，冗余保险)
DELETE FROM orders WHERE id IN (6280,6281,6282,6283);             -- 4

预期结果：orders 4→0，order_items 4→0。这 4 笔无 RESTRICT 子行，删除干净。

Tier-3 · 商品目录（判断项，默认保留）

Tier-3 删除 retail_products 不影响 C 端（C 端从不调用），仅清空 A 端零售商品目录。是否删由义父决定；本方案默认保留。

四、/api/miniapp/retail/* C 端域核查结果

保留项：A 端 retail.console_router（/api/miniapp/merchant-console/retail，main.py:194）独立、继续保留。

候选下线动作（需单独审批，未执行）：

• 代码层：从 main.py 移除 app.include_router(miniapp_retail.router)（:184）与 retail.miniapp_router（:195 挂载处），保留 retail.console_router（:194）。
• 影响：C 端少两个死路由；A 端零售后台不受影响。

五、staging 验证记录（已做，未污染 staging）

在 staging PG16 库用完整删除顺序跑事务（含 guest_bindings 清理），结果：

• 6 张子表清理执行（54/109/54/1/0/1），orders 删 190 行 → orders_t=0，goods/retail_products 不变。
• ROLLBACK 后 orders_t 恢复 190，goods/rp 不变 → staging 完好，SQL 端到端正确。

六、prod 执行 SOP（仅义父批准后）

1. 先取手术级单表 dump（§一）兜底。
2. 单事务执行 Tier-1（及义父批准的 Tier-2）；ON_ERROR_STOP=1，删前核对计数、删后核对 orders_t 与 goods/rp 不变。
3. 回归 C 端：/health + GET /api/miniapp/products + GET /api/miniapp/orders（该用户应空） + 风物下单 _create_goods_order 路径。
4. 若义父批准 Tier-3 删 retail_products，单独批次执行并回归 A 端 /api/admin/retail-products。
5. 零售 C 端代码下线（§四）另走独立审批与 staging 复验。

七、待义父确认的事项（决策点）

1. Tier-2：4 笔 is_test=f 测试单（6280–6283）是否一并删除？
2. Tier-3：retail_products 15 行是否删除（默认保留）？
3. 代码下线：/api/miniapp/retail/* C 端域是否进入下线实施（默认仅标记候选）？
4. 确认后由波波按 §六 SOP 在 prod 执行，执行前再冻结复核。

本方案所有删除/下线动作均未执行，仅 staging 事务内验证（已回滚）。prod 全程冻结。