Merge branch 'test'

# Conflicts:
#	.claude/homunculus/observations.jsonl

ruoyi-admin/src/main/java/com/ruoyi/app/order/PosOrderShOprateController.java

@@ -637,6 +637,10 @@ public class PosOrderShOprateController extends BaseController {
         if (type != null && !type.isEmpty()) {
             wrapper.eq(PosOrder::getType, Long.valueOf(type));
         }
+        // 外送订单须骑手已接单才对商家可见；自取、堂食不受配送状态限制。
+        wrapper.and(w -> w.ne(PosOrder::getType, 0L)
+                .or(delivery -> delivery.in(PosOrder::getDeliveryStatus, 1L, 2L, 3L)
+                        .isNotNull(PosOrder::getQsId)));
         switch (tab == null ? "" : tab) {
             case "pending":
                 wrapper.eq(PosOrder::getState, 0L)

ruoyi-admin/src/test/java/com/ruoyi/app/order/OrderListPaymentFilterTest.java

@@ -18,6 +18,9 @@ import org.apache.ibatis.builder.MapperBuilderAssistant;
 import org.junit.jupiter.api.BeforeAll;
 import org.junit.jupiter.api.BeforeEach;
 import org.junit.jupiter.api.Test;
+import org.junit.jupiter.params.ParameterizedTest;
+import org.junit.jupiter.params.provider.NullAndEmptySource;
+import org.junit.jupiter.params.provider.ValueSource;
 import org.mockito.MockedStatic;
 import org.mockito.ArgumentCaptor;
 import org.springframework.test.util.ReflectionTestUtils;
@@ -111,6 +114,34 @@ class OrderListPaymentFilterTest {
         assertEquals(1, Collections.frequency(parameters, "1"));
     }
 
+    @ParameterizedTest
+    @NullAndEmptySource
+    @ValueSource(strings = {"pending", "preparing", "ready", "completed", "cancelled", "refund"})
+    void merchantListRequiresAssignedRiderForDeliveryAcrossAllTabs(String tab) {
+        IPosOrderService orders = mock(IPosOrderService.class);
+        IInfoUserService users = mock(IInfoUserService.class);
+        PosOrderShOprateController controller = new PosOrderShOprateController();
+        ReflectionTestUtils.setField(controller, "posOrderService", orders);
+        ReflectionTestUtils.setField(controller, "infoUserService", users);
+        InfoUser merchant = new InfoUser();
+        merchant.setUserId(801L);
+        merchant.setUserType("3");
+        auth.when(AuthContext::requireUserId).thenReturn(801L);
+        when(users.getOne(any())).thenReturn(merchant);
+        when(orders.page(any(Page.class), any(Wrapper.class))).thenReturn(new Page<>());
+
+        controller.orderList(tokenFor(801L), 1, 10, tab, null, null);
+
+        LambdaQueryWrapper<PosOrder> query = capturedQuery(orders);
+        String sql = query.getSqlSegment();
+        for (var entry : query.getParamNameValuePairs().entrySet()) {
+            sql = sql.replace("#{ew.paramNameValuePairs." + entry.getKey() + "}",
+                    String.valueOf(entry.getValue()));
+        }
+        // 非外送订单保留；外送须已接单并有骑手，取餐和送达后的订单仍可查询。
+        assertTrue(sql.contains("sh_id = 801 AND (type <> 0 OR (delivery_status IN (1,2,3) AND qs_id IS NOT NULL))"), sql);
+    }
+
     @BeforeEach
     void setUpMessages() {
         messages = mockStatic(MessageUtils.class);

specs/006-orderstate/plan.md

@@ -108,3 +108,9 @@ E:\QtwCode\foodie\foodie-admin-vue\
 新增订单配送推送服务统一处理两类跨入口副作用：到付创建或在线支付成功后通知附近可接单骑手，以及已分配骑手订单取消后的相关方通知。用户聚合下单、旧 `/addorder` 到付入口、LINE Pay 和 OMG 支付成功入口共用同一开放条件，避免不同支付方式形成不同履约顺序。
 
 商家接单和出餐在原支付、归属校验基础上增加骑手分配校验；骑手新任务查询增加 `state=0` 和 `payStatus=1` 条件。骑手占用查询只统计 `state IN (0,1,2)` 且 `deliveryStatus IN (1,2)` 的有效履约订单，取消订单不继续占用骑手。
+
+## 2026-09-15 增量实施设计
+
+在 `PosOrderShOprateController.orderList` 公共查询条件中追加 `type <> 0 OR (delivery_status IN (1,2,3) AND qs_id IS NOT NULL)`，与门店权限及各页签条件以 AND 组合后交由现有分页查询执行。接口参数和响应保持现状，不修改商家受理、支付、配送状态流转，也不新增字段。
+
+定向验证各页签、空页签及未传页签均携带接单过滤，非外送分支可保留自取/堂食，并回归支付条件和子账号门店权限。

specs/006-orderstate/spec.md

@@ -725,3 +725,9 @@ wrapper.last("ORDER BY ST_Distance_Sphere(point(longitude, latitude), " +
 - [美团外卖开放平台 — 订单退款与取消](https://developer.waimai.meituan.com/home/questionDetail/6295)
 - [美团外卖开放平台 — 订单确认退款请求](https://developer.waimai.meituan.com/home/docDetail/122)
 - [美团外卖订单中心演进](https://tech.meituan.com/2016/09/09/mt-waimai-order-evolution.html)
+
+## 2026-09-15 增量：商家列表隐藏未接单外送订单
+
+- `/system/orderShOprate/orderList` 的全部页签及不传 `tab` 的查询，外送订单（`type=0`）仅在 `deliveryStatus IN (1,2,3)` 且 `qsId` 非空时可见；未被骑手接单的外送订单不返回，包括取消、售后页签。
+- 自取、堂食不要求骑手接单，沿用原支付、订单状态及商家门店权限条件。
+- 过滤在数据库分页前执行，列表记录和分页总数使用同一条件；已取餐、已送达的订单不因配送状态推进而被隐藏。

specs/006-orderstate/tasks.md

@@ -241,3 +241,9 @@ Task T022: "骑手端 PosOrderQsOprateController.orderList()"
 - Phase 1 完成后需手动执行 SQL（updatesql/sql.md）
 - 前端文件编辑需用 Python 脚本处理 CRLF 换行符问题
 - 旧方法（PosOrderController 中旧列表查询）保留不删
+
+## 2026-09-15 增量：商家列表接单过滤
+
+- [x] T042 为商家全部页签、空页签及未传页签补充接单过滤回归，修改前 8 个新增用例均因缺少条件失败。
+- [x] T043 在 `orderList` 分页前统一限制外送订单须 `deliveryStatus IN (1,2,3)` 且 `qsId` 非空，保留自取/堂食、支付和门店权限条件。
+- [x] T044 使用 JDK 21 运行 `OrderListPaymentFilterTest`、`PosOrderShOprateControllerTest`、`PosOrderQsOprateControllerTest` 定向测试，23/23 通过；未执行真实数据库分页联调和完整回归。

specs/024-flash-delivery/plan.md

@@ -701,3 +701,23 @@ The staged list must not contain `.claude/homunculus/observations.jsonl`、`.tmp
 ### 2026-09-09：编辑操作订单 ID 改为请求体
 
 按用户要求，仅调整确认修改地址和追加小费：在 FlashDeliveryAddressConfirmRequest、FlashDeliveryTipAddRequest 添加 orderId；Controller 两个方法只接 token 与 RequestBody DTO，通过 DTO 将订单 ID 传给既有 Service。requireEditableOrder 在查询前拒绝空/非正订单 ID。同步端点契约、JSON 绑定/身份传递测试、App 文档及定向验证，原有费用和并发业务规则保持不变。
+## 2026-09-14：多取货点实施计划（2026-09-15 修订）
+
+**目标**：每站独立联系人及物品，默认按用户顺序引导、取得下单人同意并记录骑手声明后允许调整，单点可省略 stopId/多点必传，重复取件幂等，任意站取货后禁止用户取消。本节替换原多点增量方案，生产代码仍待实施。
+**实现**：新订单统一写站点表，订单表维护首点地址/物品摘要与 pickup_stop_count；不做历史迁移、无站点回退或测试数据清理。用户顺序用于整线报价、展示和默认引导；骑手沟通同意后调整实际取件顺序，记录原因及声明，保留原顺序且不变价，前往与取件分离；追加小费不重算路线。
+**约束**：JDK 21；ruoyi-admin -> ruoyi-system；明确 DTO、token 请求头、Service 国际化校验；SQL 只记录 updatesql/sql.md；保留原编码换行。本轮仅更新现有 spec.md、plan.md、tasks.md，不执行生产实现、SQL、测试或提交。
+
+1. **数据层（T089、T090）**：在 ruoyi-system 的 domain/flash 新增 FlashDeliveryOrderStop，mapper/flash 新增 Mapper 与 XML；存每站联系人、地址、packageType/quantity/weightRange/specification、状态和确认时间，关联站点凭证。订单实体与 FlashDeliveryOrderMapper.xml 的 resultMap、select/insert/update 同步 pickup_stop_count、首点地址及物品摘要；站点按 order_id 查询并建立同单 stop_order 唯一约束。updatesql/sql.md 记录建表、订单加列、凭证关联所需 SQL 及三个字典项，上限初始化为 1；不执行 SQL。
+2. **配置及路线（T090、T091）**：RouteDistanceProvider 新增多经点方法，GoogleRoutesDistanceProvider 以首取点为 origin、其余 intermediates、收货点 destination，不开启 optimizeWaypointOrder；FlashDeliveryRouteService 降级逐段直线求和。数量有效范围 1..26，字典缺失/非法回退 1，超限在地图调用前拒绝；路线与降级均校验整线 40 公里。FlashDeliveryHomeView 下发 pickupStopLimit、showMultiPickup、showUrgentOption。
+3. **请求、报价及创建（T091）**：在 ruoyi-admin 的 flashdelivery/dto 新增含完整地址和物品字段的取货点 DTO，QuoteRequest/CreateRequest 扩展 pickups 数组；保留旧 pickup + 订单级物品单点适配。两种地址输入同时出现、数组与旧订单级物品同时提交均拒绝；逐站校验物品、数量、重量范围、规格、地址/坐标及取收同址，并统一校验开关和上限。FlashDeliveryApplicationService 沿用创建幂等、路线及费用复算，创建站点、摘要与图片处于同一事务。
+4. **待接单编辑（T091）**：AddressChangeRequest/AddressConfirmRequest 同步完整 pickups + delivery；多点不得以 pickup 覆盖站点集合，旧单点编辑保留物品；待接单调整顺序也使用完整站点序列重报价并确认，接单后骑手调整访问先后不走地址编辑和重报价。沿用原运价快照及 orderVersion，确认时复算整线；先执行校验创建人/待接单/无骑手/版本的订单条件 UPDATE，成功后同事务保存站点、首点摘要、数量和收件人绑定，失败整体回滚。addTip 保留只增加小费及 amount，不查路线、不重算其他费用，不重验开关或数量上限。
+5. **取件及取消（T092、T093）**：FlashDeliveryProofRequest 增加可选 stopId；原 pickup 接口单点可省略、多点必传，另提供路径 stopId 接口；两处 ID 同传必须一致，共用取件业务实现，不自动选择下一未取站。FlashDeliveryOrderMapper 新增按订单 ID SELECT ... FOR UPDATE；取件、用户/平台取消均在事务内先锁订单行，再读最新站点状态，不能使用锁前读到的状态校验。校验订单、骑手、PICKUP 类型；新取件目标须符合 FR-096，非默认站须先保存调整原因及已取得同意声明，不能直接以 stopId 绕过；已确认站点重试无新写入，不能因目标已变化拒绝幂等重试。新取件必须处于 ACCEPTED，站点和凭证保存后检查是否全部取完，递增订单版本并记录站点日志；仅全部取完更新 PICKED_UP/pickedUpAt。用户取消锁内检查任意已取站点并拒绝；平台沿用介入权限，按 FR-098 记录异常站、处理结果、已取物品去向及交接凭证后再关闭异常订单，不能漏取、虚假取件或直接完成。图片、日志或其他更新失败必须全部回滚。
+6. **视图及契约（T093、T094）**：列表增加 pickupStopCount 并保留首点摘要，各角色详情增加带 ID、独立物品及凭证的 stops，pickupImageUrls 仅作聚合展示；接单前逐站隐藏联系人、电话、坐标、PIN 及图片。用户、骑手及平台展示已取数量/总数量，部分取件仍为 ACCEPTED，但用户取消入口按任意站是否已取控制并在刷新时更新；平台详情同步展示各站和调整记录供介入核对。实现阶段同步 contracts/api.md、data-model.md、quickstart.md、docs/flash-delivery-app-api.md 和现有全部后端语言资源；平台改动同步四语言。错误 key 覆盖缺少 stopId、越权、输入冲突、点数超限、开关关闭；允许按规则调整，补充缺少原因/同意声明、目标或调整记录不匹配等国际化错误。导航使用 travelmode=two-wheeler，默认指向用户顺序中最早的未取站，保存调整后为选定单站，全部取完后为收货点；客户端生成 URL，导航不等同取件。
+7. **测试（T088、T095）**：扩展 ApplicationService、ControllerContract、RouteService、OrderView、RiderOrderListView、MapperXml、I18nContract 测试。覆盖独立物品、旧单点适配/冲突、完整站点编辑/物品保持/版本竞争；单点省略 ID、多点缺 ID 拒绝、记录同意声明及原因后 B 先于 A 成功、缺少调整记录/原因/声明拒绝、跨单/收货站/他人骑手拒绝；响应丢失后重试及并发重复请求不追加凭证或推进别站，最后两站并发完成只推进一次，凭证失败整体回滚。取消与取件并发验证两种先后结果，不能仅用顺序调用宣称并发通过。数量覆盖 0、1、26、27 及字典缺失/非法，26 点对应 25 intermediates；覆盖整线 40 公里、降级、脱敏和追加小费不调用路线。
+8. **验证交付（T095）**：实现后临时设置本机 JDK 21，运行受影响闪送定向测试及 mvn -pl ruoyi-admin -am -DskipTests package，再执行 git diff --check、变更范围和编码换行检查。需要 MySQL 的事务/并发检查独立执行记录，单元和 Mapper 文本检查不能替代数据库验证。真实地图、数据库、App 联调及未执行回归明确列出；核对暂存仅含本功能文件后中文提交。
+
+9. **顺序调整记录（T098）**：按 FR-095、FR-096 设计独立的履约目标选择/调整操作，使用明确 RequestBody DTO 和 token 请求头；服务端保存当前目标及订单、调整前后目标、原因、声明、骑手和时间，不修改 stop_order、站点物品或报价。采用订单行锁与取件/取消串行校验，防止重复请求追加同一次记录或过期请求覆盖目标；已取站及已取消订单拒绝新调整。目标完成后回到用户顺序中最早未取站。同步实体、Mapper/XML、视图及契约；必要 SQL 在实现时写入 updatesql/sql.md，不执行迁移。此操作保存履约选择，不生成导航 URL，也不推进取件状态。
+10. **客户端与异常核对（T099）**：用户下单前可排序，待接单调整需重报价确认，显示 FR-094 提示。骑手默认突出下一站，可查看其他站；选择非默认站时先提示联系下单人，要求原因及已取得同意声明，保存成功后再导航。区分“前往”与“已取货”，声明不显示为用户审批；订单聊天可作为依据，首期不新增用户 App 审批流程。各端保留原顺序，展示实际进度及取消条件，平台展示调整记录、异常处理结果和物品交接信息；可见文本按各端既有国际化要求实现。关联文档在 T094 同步，当前三件套为待实施增量依据。
+11. **补充验收（T100）**：覆盖默认 A、沟通并保存调整后前往 B、仅导航状态不变、缺原因/声明或直接绕过调整操作拒绝、B 取件后默认回 A、原顺序/物品/金额不变、部分取件进度及取消入口、平台明确标注骑手声明、无法取货的介入与交接记录；覆盖调整请求重复、与取件/取消竞争、目标变化后的取件幂等重试。联调验证前不得将 App 行为标记为已验证，骑手声明不能作为已验证用户同意真实性的依据。
+
+外部约束：Google Routes 单次最多 25 个中途点，Maps URL 使用 two-wheeler 且途经点数量受平台限制；本期采用字典有效上限最多 26 个取货点与单站导航，不做无限站点分段请求。

specs/024-flash-delivery/spec.md

@@ -4,7 +4,7 @@
 
 **创建日期**：2026-08-31
 
-**状态**：既有功能已验证；2026-09-07 设计稿费用与物品信息对齐增量已确认，待实施
+**状态**：既有功能已验证；2026-09-07 设计稿费用与物品信息对齐增量已确认，待实施；2026-09-14 多取货点增量已确认，2026-09-15 按方式 2 修订取件顺序规则，待实施
 
 **输入**：基于蓝湖“闪送”分组 7 个设计页面、2026-08-24 用户端/骑手端补充原型及 2026-09-03 更新的 19 张用户端设计稿，实现帮送/帮取业务场景、普通/1 对 1 加急配送、共享地址簿、路线报价、完整物品信息、立即/预约配送、费用明细与报价校验、可选 PIN 交付、创建订单、寄件人/收件人订单查询、骑手主动抢单、急送独占、取件、送达、用户签收、平台配置与介入的非支付业务闭环。
 
@@ -295,3 +295,63 @@
 - 本次只新增以上能力；沿用现有取消规则、非支付边界。复用现有字段与 version，无数据库迁移。
 
 - FR-078（2026-09-09 入参调整）：确认修改地址与追加小费使用 POST /orders/address 和 POST /orders/tip；订单 ID 通过 JSON 请求体 orderId 传入，必须是有效正整数，token 仍放请求头。
+## 2026-09-14：闪送多取货点（多取一送，2026-09-15 修订）
+
+本节按 2026-09-15 用户确认的方式 2 更新：默认按用户顺序引导，取得下单人同意后允许调整实际取件顺序；替换此前无条件自由取件的规则，生产功能仍待实施。单笔订单包含 1 至 N 个取货点和 1 个收货点，每个取货点独立关联联系人和物品信息。用户填写顺序用于初始路线报价、展示和默认取件引导；调整实际取件顺序须遵守 FR-094 至 FR-098。按整条路线距离计价，不新增每取货点附加费；点间不设单独距离限制，整条报价路线仍不得超过 40 公里。
+
+### 用户故事 8：用户发布多取货点订单并由骑手逐点取件（优先级：P1）
+
+用户逐站填写联系人、地址和物品，填写唯一收货点后获取整条路线报价；骑手接单后默认按用户顺序前往未取货站点，需要调整时先与下单人沟通、取得同意并保存调整记录，再逐站确认取件并上传凭证，全部取货点完成后订单进入已取件，送达流程不变。
+
+**优先级原因**：每站独立物品和凭证用于履约核对与纠纷定位。
+
+**独立测试**：验证每站物品独立、按用户顺序报价和默认引导、沟通同意后调整并记录骑手声明、前往与取件分离、单点可省略 stopId、多点必传 stopId、重试不推进其他站点、取件与用户取消互斥，以及全部取货点完成时仅推进一次主状态。
+
+**验收场景**：
+
+1. **假如** 多地点开关开启，**当** 用户报价或创建多点订单，**那么** 各站分别校验联系人和物品，按用户填写顺序计算整条路线距离、时长和费用。
+2. **假如** 数量超过字典有效上限，**当** 报价、创建或修改取货点，**那么** 返回国际化错误；字典缺失或非法时有效上限为 1。
+3. **假如** 多地点开关关闭，**当** 报价、创建或编辑提交多于一个取货点，**那么** 拒绝；既有订单履约及仅追加小费不受开关和上限调整影响。
+4. **假如** 订单只有一个取货点，**当** 骑手不传 stopId，**那么** 定位唯一取货点；多点订单未传 stopId 必须拒绝，不自动选择未取货站点。
+5. **假如** 用户顺序为 A → B → C 且均未取件，**当** 骑手查看订单，**那么** 默认突出显示前往 A；骑手取得下单人同意、填写原因并声明已取得同意，保存先前往 B 的调整记录后，可以实际到 B 取货并上传凭证确认；主状态保持 ACCEPTED，全部取货点完成后才进入 PICKED_UP。
+6. **假如** 请求指定非本单站点、收货站点或他人订单站点，**当** 取件确认，**那么** 拒绝；同一骑手重试已确认站点只返回已确认结果，不重复写凭证、时间、日志或推进其他站点。
+7. **假如** 任意站点已经取货，**当** 用户自助取消，**那么** 拒绝并要求平台介入；与取件并发时，取件先成功则用户取消失败，取消先成功则取件失败。
+8. **假如** 用户选择加急和多个取货点，**当** 报价或创建，**那么** 允许并沿用整条路线计价及骑手独占规则。
+9. **假如** 待接单订单修改地址或调整站点顺序，**当** 报价或确认保存，**那么** 使用完整站点序列和原运价快照重算整线，经用户确认新报价后保存；接单后骑手仅调整实际取件先后不重算金额；仅追加小费时只增加小费和总金额，不请求路线或重算其他费用。
+10. **假如** 整线超过 40 公里或地图服务失败，**当** 报价、创建或地址编辑重报价，**那么** 按整线执行距离上限和逐段直线降级；点数超限在地图调用前拒绝。
+11. **假如** 旧单点请求提交 pickup 与订单级物品字段，**当** 报价或创建，**那么** 适配为一个含独立物品的取货点；pickup 与 pickups 同时提交时拒绝。
+12. **假如** 多点地址保存与抢单或其他编辑并发，**当** 保存，**那么** 站点、摘要、收件人绑定、路线和金额必须同一事务提交或回滚，不出现两套地址或报价。
+
+13. **假如** 用户下单前调整站点顺序，**当** 确认报价，**那么** 按最终顺序计算并展示路线和费用，提示默认按此顺序取件、骑手如需调整将先沟通。
+14. **假如** 骑手选择非默认未取站，**当** 缺少调整原因或未声明已取得下单人同意，**那么** 不保存调整，也不能通过直接调用取件确认绕过所需记录；首期不要求用户在 App 内点击批准。
+15. **假如** 已保存先前往 B 的调整，**当** 打开或退出导航，**那么** B 仍为待取件，不生成取件凭证、不增加已取数量、不推进主状态；实际交接并提交有效图片后才可确认已取。
+16. **假如** 用户顺序为 A → B → C，**当** B 已取且 A/C 待取，**那么** 保留原始顺序和报价，展示已取 1/3 站及各站状态，默认下一站回到 A，用户自助取消不可用。
+17. **假如** 平台核对调整，**当** 查看记录，**那么** 展示调整前后目标站、原因、骑手、操作时间和骑手声明，不显示为用户已在 App 审批；订单聊天可作为沟通依据。
+18. **假如** 某站暂未备好，**当** 沟通同意后先去其他站，**那么** 原站继续待取；最终无法取货时联系平台处理，不能删除站点、虚假取件或直接完成整单。平台记录已取物品去向和交接凭证后再关闭异常订单。
+19. **假如** 调整请求重试或与取件、取消并发，**当** 保存，**那么** 不重复追加同一次记录，不以过期状态覆盖目标；取消后禁止新调整，已取站不能作为新目标。
+
+- FR-079：通用站点表 flash_delivery_order_stop 保存订单 ID、类型（PICKUP/DELIVERY）、用户填写顺序、快照和履约信息，作为新订单站点数据唯一真相；所有新订单（含单点）统一写入取货和收货站点。订单表 pickup_* 维护首取货点摘要，新增 pickup_stop_count。当前为测试阶段，不做历史订单迁移、无站点履约回退或历史详情适配，不自动清理测试数据。
+- FR-080：每个取货点独立保存联系人、电话、地址、详细地址、市/区、交接方式、经纬度和物品字段 packageType、quantity、weightRange、specification；逐站按既有物品规则校验并供骑手核对。唯一收货点保存收件信息，收件账号绑定和交付 PIN 维持订单级一套。既有订单级物品字段仅保留首取货点兼容摘要，不代表多点订单全部物品，不作为站点物品来源。
+- FR-081：数据字典 flash_pickup_stop_limit 配置取货点上限，不含收货点；仅接受 1 至 26 的整数，缺失、空值或非法配置时有效上限为 1。报价、创建、修改取货点均校验非空且不超过有效上限，超限返回国际化错误；首页下发有效 pickupStopLimit。26 个取货点对应 25 个中途点，超点数在地图调用前拒绝，不作为地图故障降级。
+- FR-082：flash_show_multi_pickup 控制多点能力；关闭时多于一个取货点的报价、创建和地址编辑均拒绝。开关或上限调整不影响已创建订单取件、送达及仅追加小费。
+- FR-083：flash_show_urgent_option 经首页配置下发，仅控制 App 加急选项展示；后端仍按 deliveryType 执行既有校验，不受该展示开关影响。
+- FR-084：初始及地址编辑报价按用户填写顺序计算：首取货点为起点，其余取货点为中途点，收货点为终点，不自动优化顺序；地图失败逐段直线距离求和，40 公里上限按整线执行。stop_order 用于报价、展示及默认取件引导；骑手按 FR-095 改变实际取件顺序不重排用户站点、不重算订单金额。
+- FR-085：沿用 FR-004 至 FR-006、FR-070 至 FR-072 的运价、报价回传校验和整数 TWD 取整，以整线距离替代原单段距离，不新增站点附加费或按物品计价项；保留 FR-076 小费只增加小费及总金额，不重算路线、基础配送费或加急费。
+- FR-086：deliveryType=URGENT 允许多个取货点，FR-065、FR-066 骑手独占规则不变。
+- FR-087：骑手默认按用户顺序取件，按 FR-095 保存沟通同意后的调整记录后可以先取其他未取站；每站实际取到货后至少上传一张取件图片。保留 POST /system/flashDelivery/rider/orders/{id}/pickup，请求 DTO 增加可选 stopId；单点可省略，多点必传。另提供 POST /system/flashDelivery/rider/orders/{id}/stops/{stopId}/pickup，路径 ID 为操作目标，同时传请求体 stopId 时必须一致。缺失必需 ID、站点不属本单或不是 PICKUP、骑手不是接单人时拒绝；同一骑手重试已确认站点幂等返回，不重复写凭证、日志或确认时间。新取件按 FR-096 校验当前目标及必要的调整记录；保存每站状态、时间和凭证；全部取货点完成才进入 PICKED_UP，pickedUpAt 记录最后一个实际完成取件的站点时间，不按 stop_order 判断末站。
+- FR-088：任意取货点已确认即禁止用户自助取消，不限定用户排序第一站；全部未取时维持现有取消规则，平台保留介入能力。取件与用户/平台取消共用订单行级并发保护：同一事务先锁订单行，再读取最新订单及站点状态并校验、更新。站点状态、凭证、主状态、版本和日志一并提交或回滚，不能只在取消前单独查询一次。取消成功后禁止新增取件；任一站取件成功后用户取消必须失败。
+- FR-089：列表保留现有字段和首取货点地址/物品摘要，新增 pickupStopCount；用户、骑手及平台详情新增 stops，包含站点 ID、类型、用户顺序、联系人、电话、地址、交接方式、坐标、独立物品、状态、确认时间及凭证。凭证按站关联，既有 pickupImageUrls 可聚合展示，不能用聚合列表覆盖各站凭证。骑手接单前逐站隐藏联系人、电话、精确坐标、PIN 及凭证图片，保留文字地址及履约判断所需物品信息。
+- FR-090：客户端按 FR-094 至 FR-096 确定的当前目标站拼装 Google Maps URL，默认指向用户顺序中最早的未取站，保存沟通同意后的调整后指向选定站，全部取完后导航到唯一收货点。选择前往、打开导航与确认已取货是独立操作。使用 api=1、travelmode=two-wheeler、dir_action=navigate，正确编码参数，起点默认设备当前位置；不依赖携带全部途经点的 URL 履约。后端按 FR-029 权限返回坐标，不生成导航 URL，不新增用于生成导航 URL 的接口；调整记录保存属于履约操作，不能仅保存在客户端。
+- FR-091：站点表、订单表加列、站点凭证关联所需变更及三个字典项 SQL 只记录在 updatesql/sql.md，不直接执行数据库操作。
+- FR-092：报价和创建新增 pickups 数组，每项含完整取货地址及 FR-080 物品字段；保留旧 pickup 与订单级物品作为单点输入，统一适配后校验。pickup 与 pickups 不得同时提交；使用 pickups 时不允许同时提交旧订单级物品字段，冲突返回国际化错误。AddressChange/Confirm DTO 同步支持完整 pickups 与唯一 delivery；旧 pickup 编辑仅适用于单点并保留该站物品，多点编辑缺少完整 pickups 必须拒绝，不能丢弃其余站点。
+- FR-093：地址编辑沿用 FR-073 至 FR-075、FR-077 的权限、状态、版本及原运价快照，重算整线；订单原子条件更新成功后，在同一事务保存完整站点、首点摘要、数量、收件人绑定及费用，失败全部回滚。完整站点输入保留并校验逐站物品，不因编辑联系人或地址清空物品。
+
+- FR-094：下单前用户可调整取货点顺序，按最终顺序报价并确认；待接单订单调整顺序沿用 FR-093 重报价及确认流程。下单页提示“默认按此顺序取件，骑手如需调整将先与您沟通”，用户可见文案按现有国际化要求实现。骑手接单后可以查看全部站点，默认突出显示用户顺序中最早的未取站为下一站。
+- FR-095：骑手需要先去其他未取站时，须先联系下单人并取得同意，再选择“先前往该站”，填写调整原因并声明“已取得下单人同意”。服务端保存订单、调整前目标站、调整后目标站、原因、骑手身份、操作时间及同意声明。首期不要求用户在 App 内点击批准；骑手勾选只证明其作出了声明，不证明下单人实际同意，平台不得标记为用户审批通过。订单聊天可作为沟通依据；未取得同意不能自行调整，无法联系下单人时联系平台处理。
+- FR-096：选择前往与确认已取货分开：前者只确定目标并记录必要的调整，不能修改站点取件状态、取件时间、凭证或主状态；后者必须实际交接并提交有效取件图片。新取件确认以当前目标为准；选择非默认站须先保存 FR-095 记录，不能通过直接提交 stopId 绕过。已确认站点的重试仍按 FR-087 幂等处理，不受目标已变化影响。选定目标在取件前保持；再次改变目标时记录调整。目标站取件后回到用户顺序中最早的未取站，全部取完后转为收货点。调整操作校验接单骑手、订单状态和本单未取站，保存须防重复并与取件、取消使用一致的订单并发保护。
+- FR-097：保留用户原始站点顺序及报价，按每站实际确认时间和状态展示履约进度；用户、骑手及平台显示已取数量/总数量（如“已取 1/3 站”）。部分取件主状态仍为 ACCEPTED，取消入口按是否任意站已取判断，不能仅依据主状态显示可取消。平台详情可查看 FR-095 调整记录；调整声明和取件凭证分别展示，不相互替代。
+- FR-098：骑手仅能调整本单未取货地点的访问先后，不能新增或删除地点、修改地址或物品，也不能漏取。某站暂时无法取货可以沟通后先去其他站，该站继续保留待取件；最终无法取货、缺件或拒收须联系平台处理，不能虚假确认取件、擅自部分履约或直接完成整单。平台介入时记录问题站、处理结果及已取物品去向和交接凭证，再关闭异常订单；沿用既有介入权限，本次不新增支付退款功能。
+
+**方案来源**：上述为本项目 2026-09-15 已确认的方式 2。Lalamove 的业务规范仅作为讨论背景；骑手声明、调整记录及具体 App 操作是本项目设计，不标注为已核实的 Lalamove 操作流程。
+
+地图约束依据：[Google Routes 中途点限制](https://developers.google.com/maps/documentation/routes/intermed_waypoints)、[Google Maps URL 参数及平台途经点限制](https://developers.google.com/maps/documentation/urls/get-started)。

specs/024-flash-delivery/tasks.md

@@ -160,3 +160,22 @@
 - JDK 21 执行 `mvn -B -pl ruoyi-admin -am -Dtest=FlashDeliveryControllerContractTest,FlashDeliveryApplicationServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`：72 项通过，所有参与模块编译成功。
 - `docs/flash-delivery-app-api.md` 已同步，JSON 示例解析及差异检查通过，保留 CRLF。
 - 本轮 URL/入参调整后未重跑完整回归，前一阶段完整回归为 474 项通过；真实地图、数据库及 App 联调仍未执行。
+## Phase 18：多取货点（多取一送）
+
+本阶段按 2026-09-15 用户确认的方式 2 更新，以 FR-094 至 FR-098 替换原无条件自由取件规则。T088 至 T095、T098 至 T100 仍待实施；T097 仅记录本次文档修订，不表示生产功能完成，未运行代码测试或构建。
+
+- [x] T087 记录多取货点规格、计划与任务：多取一送、通用站点表、整线距离计价、每站独立联系人及物品、原取件顺序设计（已由 T097 修订）、用户顺序用于报价展示、加急允许多点、点间无独立距离限制、双开关与数量上限走数据字典
+- [ ] T088 编写并运行多点定向测试确认旧实现缺失：独立物品、输入兼容/冲突、单点可省略及多点必传 stopId、默认按序及记录同意声明后调整、前往与取件分离、重试/并发幂等、取消与取件竞争、末站并发及事务回滚、字典 1..26/非法回退；数据库并发验证与模拟测试分开记录
+- [ ] T089 在 updatesql/sql.md 记录站点表（独立联系人、地址、物品、履约信息及索引）、订单 pickup_stop_count、站点凭证关联及三个字典项 SQL；上限初始值 1，只记录不执行，不做历史迁移/回退或测试数据清理
+- [ ] T090 新增 FlashDeliveryOrderStop 实体/Mapper/XML，扩展订单映射、首点地址/物品摘要及订单行锁查询；实现多经点请求和逐段直线降级，最多 26 取点/25 中途点及整线 40 公里校验
+- [ ] T091 实现逐站物品 pickups[] 报价/创建、旧 pickup 单点适配及冲突拒绝；统一开关/上限/地址/物品校验、站点写入和复算；地址编辑同步完整站点、物品、摘要及收件人绑定，同事务版本保护；小费仅增金额、不查路线
+- [ ] T092 实现原 pickup 与路径 stopId 接口：单点可省略、多点必传、两处 ID 一致性、按 FR-096 校验当前目标及必要的调整记录、每站凭证、重试无副作用、全部取完才推进 PICKED_UP；多点缺少 stopId 不得动态选择下一未取站，已确认站点重试不受当前目标变化影响
+- [ ] T093 实现取件与用户/平台取消共用订单行锁及事务，任意站已取禁止用户自助取消，取消后禁止新取件；补 stops 独立物品/凭证、列表首点摘要及 pickupStopCount、已取数量/总数量与取消条件、逐站脱敏、平台详情及首页有效 pickupStopLimit/双开关
+- [ ] T094 更新 contracts/api.md、data-model.md、quickstart.md、docs/flash-delivery-app-api.md 和现有全部后端语言资源，平台改动同步四语言；明确新旧输入、站点物品、地址编辑及顺序重报价、幂等及取消、默认下一站、调整记录/骑手声明和异常交接；导航到默认或沟通后调整的单站并使用 travelmode=two-wheeler，前往与取件分离，不将本项目方案写成 Lalamove 已核实流程
+- [ ] T095 JDK 21 运行闪送定向测试、模块构建、git diff --check，检查变更范围及编码换行；实际验证取消/取件与末站并发事务，明确未执行的数据库/地图/App 联调及回归，核对暂存范围后中文提交
+- [x] T096 按用户逐项确认修订本三件套：每站独立物品、单点可省略/多点必传 stopId、原自由取件规则（已由 T097 替换）、任意站取货后禁止用户取消及并发保护、不考虑历史订单、字典限制 1..26/非法回退 1；其余采用审核建议，保留旧单点输入、小费不重算和修正导航参数
+
+- [x] T097 按 2026-09-15 会话确认的方式 2 修订 spec.md、plan.md、tasks.md：用户可排序并确认报价、默认下一站、沟通同意后调整及记录原因/骑手/时间/声明、原顺序与金额保留、实际进度、前往与取件分离、不能漏取及异常交接边界；首期无用户 App 审批，骑手声明不等同用户同意证明
+- [ ] T098 实现 FR-095、FR-096 当前目标及调整记录保存、DTO/实体/Mapper/视图/必要 SQL、原因与声明校验、订单权限和状态保护、重复请求与并发保护；取件校验有效目标及必要记录，目标完成后回到原顺序最早未取站，不修改原顺序/物品/金额
+- [ ] T099 落实用户端排序与提示、骑手端默认下一站/沟通后选择目标/前往与取件分离、各端实际取件进度及取消入口；平台可核对调整声明、异常处理结果和已取物品去向/交接凭证，用户可见文案国际化，聊天可作为沟通依据
+- [ ] T100 补充并执行顺序调整验收：有无原因/声明、直接取件绕过、导航不推进状态、B 取件后回 A、原顺序与金额不变、进度/取消按钮、声明展示、异常交接、调整重复及与取件/取消并发、已取站重试；配合 T095 记录实际测试与 App/数据库联调结果