diff --git a/doc/sql/transport/blade_waybill_pending_return_confirm_20261024.sql b/doc/sql/transport/blade_waybill_pending_return_confirm_20261024.sql
new file mode 100644
index 00000000..8b80aa07
--- /dev/null
+++ b/doc/sql/transport/blade_waybill_pending_return_confirm_20261024.sql
@@ -0,0 +1,79 @@
+-- ----------------------------
+-- 回单待确认状态改名：business_status 还停在 pending_return 的运单订正为 pending_return_confirm
+-- 写业务数据。执行前必须先存档（第 0 节），执行后必须跑第 2 节校验。可重复执行。
+-- ----------------------------
+--
+-- 为什么要订正：
+--   2026-10-22 起 dev 把「司机打完末位卡、等业务员确认回单」的状态值从 pending_return
+--   改成 pending_return_confirm（WaybillProcessSupport.STATUS_PENDING_RETURN_CONFIRM，911393fb），
+--   并把旧值从代码里彻底删掉——dev 全仓 grep '"pending_return"' 已 0 命中。
+--   而列表口径只认新值：
+--     · 运次列表（司机端小程序 /waybill/task/page）的状态集合直接下到 SQL：
+--       TripQueryServiceImpl.visibleRows 的 .in(business_status, TripAggregation.CHILD_STATUSES)，
+--       CHILD_STATUSES 里没有 pending_return ⇒ 这行连分组的机会都没有，整趟车在库层被滤掉；
+--     · 运单列表的 TAB_ALL_STATUSES / ACTIVE_STATUSES 同样没有旧值。
+--   于是库里还停在 pending_return 的运单，部署 dev 之后从运单列表和运次列表一起消失，
+--   司机端小程序四个 tab 全都看不到它——这正是 2026-10-24 测试反馈「待回单确认的运单在小程序
+--   列表里看不到」的机制（若该环境部署的仍是 master，则 master 的 TripAggregation.CHILD_STATUSES
+--   本来就不含 pending_return，症状相同）。
+--
+-- 旧值是谁写的：
+--   master 的 DriverWaybillServiceImpl（末位打卡节点为到货/卸货/签收、且过程配置要求回单内部确认时）
+--   调 markPendingReturn()，写入 business_status = 'pending_return'。语义与新值一一对应，
+--   都是「司机已打完末位卡、等确认回单」。
+--
+-- 处置口径：
+--   只改可见运单（is_deleted = 0）里 business_status = 'pending_return' 的行，改成 pending_return_confirm。
+--   update_time 不在 SET 里，保留原值——它是事后追溯改动时间的唯一线索。
+--   blade_loading_manage / blade_master_order / blade_transport_plan 也有 business_status 列，
+--   但那是各自单据的过程状态，不参与运次可见口径，本脚本不动它们（第 2 节给出现值为旧值的行数，
+--   预计为 0；若不为 0 先人工确认再决定是否订正）。
+--   可重复执行：第二次执行时 WHERE 命中 0 行。
+-- ----------------------------
+-- 0. 存档（必须在订正之前执行，仅首次需要）
+-- ----------------------------
+--   CREATE TABLE blade_waybill_pending_return_bak AS
+--     SELECT id, waybill_no, loading_no, business_status, driver_phone, update_time
+--       FROM blade_waybill
+--      WHERE is_deleted = 0 AND business_status = 'pending_return';
+
+-- ----------------------------
+-- 1. 订正状态
+-- ----------------------------
+START TRANSACTION;
+
+UPDATE `blade_waybill`
+SET `business_status` = 'pending_return_confirm'
+WHERE `is_deleted` = 0
+  AND `business_status` = 'pending_return';
+
+COMMIT;
+
+-- ----------------------------
+-- 2. 校验（执行后必看，前两条都必须返回 0）
+-- ----------------------------
+--   -- 仍停在旧值的可见运单
+--   SELECT COUNT(*) FROM blade_waybill
+--    WHERE is_deleted = 0 AND business_status = 'pending_return';
+--
+--   -- 订正过的行必须都在备份表里且已是新值（应为 0）
+--   SELECT COUNT(*) FROM blade_waybill_pending_return_bak b
+--     LEFT JOIN blade_waybill w ON w.id = b.id
+--    WHERE w.id IS NULL OR w.business_status <> 'pending_return_confirm';
+--
+--   -- 其它单据的 business_status 里是否也有旧值（只报不改，预计 0）
+--   SELECT 'blade_loading_manage' AS tbl, COUNT(*) FROM blade_loading_manage
+--    WHERE is_deleted = 0 AND business_status = 'pending_return'
+--   UNION ALL
+--   SELECT 'blade_master_order', COUNT(*) FROM blade_master_order
+--    WHERE is_deleted = 0 AND business_status = 'pending_return'
+--   UNION ALL
+--   SELECT 'blade_transport_plan', COUNT(*) FROM blade_transport_plan
+--    WHERE is_deleted = 0 AND business_status = 'pending_return';
+
+-- ----------------------------
+-- 3. 回退（订正后发现问题时执行）
+-- ----------------------------
+--   UPDATE blade_waybill w
+--     JOIN blade_waybill_pending_return_bak b ON b.id = w.id
+--      SET w.business_status = b.business_status;