docs: 2026-04-27 保险订单列表 VO 字段补齐 + 全程方案哨兵

- 27_fix_insurance-order-list_ext-fields.md (PR #1455)
  保险订单列表新增 extOrderNo + extPolicyNo, 保留 policyNo 兼容字段
- 27_refactor_insurance-scheme_full-trip-totaldays.md (PR #1454)
  保险方案全程语义对齐, totalDays=-1 哨兵, listActive 过滤同步

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

changelogs/2026-04/27_fix_insurance-order-list_ext-fields.md

@@ -0,0 +1,44 @@
+# 保险订单列表补保游网订单号 + 保单号字段
+
+**日期**: 2026-04-27
+**PR**: #1455 (Closes #1453)
+**影响端**: 管理端 admin
+
+## 背景
+
+管理后台 `/insurance/orders` 列表页「保游网订单号」+「保单号」两列展示为空，DB 实际有值（`ext_order_no` + `ext_policy_no`）。
+
+根因：列表 VO `InsuranceOrderVO` 缺 `extOrderNo` 字段，且把 `ext_policy_no` 装配到了 `policyNo`（与详情 `InsuranceOrderDetailVO.extPolicyNo` 命名不一致）。
+
+## 接口变化
+
+`GET /admin/insurance/orders` 列表项 response **新增 2 个字段**，**保留旧字段**：
+
+| 字段 | 类型 | 说明 | 状态 |
+|------|------|------|------|
+| `extOrderNo` | String | 保游网订单号 (如 `BX2026042416212230000164`) | **新增** |
+| `extPolicyNo` | String | 保单号 / 保游网保单号 (如 `11209006600506922149`) | **新增** |
+| `policyNo` | String | 与 `extPolicyNo` 同值 | **保留兼容**, 后续版本删除 |
+
+## 前端改动
+
+列表列定义已使用 `extOrderNo` + `extPolicyNo`，本 PR 后端补齐字段后**前端无需改动**，自动生效。
+
+后续等本期上线稳定后，后端会移除 `policyNo` 字段，前端不需要做任何动作（前端已不读 `policyNo`）。
+
+## 验证
+
+DB 实证：
+```sql
+SELECT insurance_order_id, ext_order_no, ext_policy_no, status, create_time
+FROM insurance_order ORDER BY create_time DESC LIMIT 3;
+
+2047591721386098690 BX2026042416212230000164 11209006600506922149  INSURED  2026-04-24 16:21:32
+2047583238506844161 BX2026042415474050000153 11209006600506922106  CANCELLED 2026-04-24 15:48:00
+2046992253949591554 BX2026042300392020000007 11209006600506912961  INSURED  2026-04-23 00:39:35
+```
+
+API response 经此 PR 后 `extOrderNo` + `extPolicyNo` 同步下发。
+
+## 详情接口
+`GET /admin/insurance/orders/{id}` 详情接口字段不变（一直就是 `extOrderNo` + `extPolicyNo`），本 PR 仅对齐列表接口。

changelogs/2026-04/27_refactor_insurance-scheme_full-trip-totaldays.md

@@ -0,0 +1,48 @@
+# 保险方案"全程方案"语义对齐 (totalDays 哨兵)
+
+**日期**: 2026-04-27
+**PR**: #1454 (Closes #1425)
+**影响端**: 管理端 admin
+
+## 背景
+
+保险方案的「段配置」(InsuranceSchemeSegment) 中 `dayOffsetEnd = -1` 是「行程最后一天/全程」的合法哨兵值。
+
+之前 `computeTotalDays` 算法见到 -1 时会跳过该段、错误返回 maxDay=1，导致「全程方案」入库时 `totalDays=1`。`AdminInsuranceSchemeController.listActiveSchemes` 按 `totalDays.equals(s.getTotalDays())` 精确过滤，结果「全程方案」**只在 1 天行程下拉里能查到**，多天行程查不到，与字段语义不符。
+
+## 改动
+
+### 后端
+- 新增哨兵常量 `InsuranceConstants.TOTAL_DAYS_FULL_TRIP = -1`
+- `computeTotalDays` 见到任一段 `dayOffsetEnd == -1` → 返回哨兵 -1
+- `listActiveSchemes` 过滤逻辑同步: `totalDays==-1 || totalDays==请求tripDays` 视为命中
+
+### 接口字段语义变化
+
+**`GET /admin/insurance/schemes/active?tripDays=N`**
+- 之前: 只返回 `totalDays == N` 的方案
+- 现在: 返回 `totalDays == N` 或 `totalDays == -1`（全程方案）的方案
+
+**`POST /admin/insurance/schemes` / `PUT /admin/insurance/schemes/{id}`**
+- request body 行为不变（前端继续配 `dayOffsetEnd: -1` 表示全程段）
+- response body 中的 `totalDays` 字段语义变化:
+  - 之前: 全程方案返回 `1`（错误语义）
+  - 现在: 全程方案返回 `-1`（哨兵, 表示"任意天数都适用"）
+  - 普通方案不受影响
+
+## 前端注意
+
+**列表页/详情页展示**: 如果前端 UI 需要展示 `totalDays`, 见到 `-1` 应当展示为「全程」/「任意天数」, 而不是直接显示 "-1天"。
+
+**新增/编辑表单**: `totalDays` 字段是后端计算字段, 前端不需要表单填写, 直接读 response 即可。
+
+## 数据迁移
+
+- 现存所有方案均为非 -1 段配置, `totalDays` 都是正值, 无需迁移
+- 本次上线后用户配置全程段时, 入库 `totalDays=-1` 自动生效
+
+## 单测
+
+- `InsuranceManageServiceTest`: +3 case (单段全程哨兵 / 多段含全程 / 全部正常段保持原算法)
+- `AdminInsuranceSchemeControllerTest`: +2 case (5 天行程仅命中全程 / 同时命中全程+精确)
+- 全部 56 单测绿