diff --git a/app/trading/worker/query_runner.py b/app/trading/worker/query_runner.py
index 6e7d377..8a989be 100644
--- a/app/trading/worker/query_runner.py
+++ b/app/trading/worker/query_runner.py
@@ -240,8 +240,11 @@ class QueryRunner:
"found": status.found,
"stage_label": status.stage_label,
"order_state": status.order_state.value if status.order_state else None,
- # 详情页的 __INITIAL_STATE__ 结构从未拿到真实样本，本服务不做字段抽取，
- # 原样透传由上游自担结构变动风险（见 site_interact.OrderDetailSnapshot）。
+ # 站点侧结构化配送状态码（如 "CHECKING_ORDER"）；列表页/stepper 路径
+ # 拿不到时为 None。这是 raw 里 orderData 的规范化摘要，供上游快速对账。
+ "delivery_status": status.delivery_status,
+ # 详情页额外带出的站点原始 JSON 原样透传，由上游自担结构变动风险
+ # （见 site_interact.OrderDetailSnapshot）。
"raw": detail.raw,
"raw_available": detail.raw is not None,
}
diff --git a/app/trading/worker/site_interact.py b/app/trading/worker/site_interact.py
index 04cf853..f684cde 100644
--- a/app/trading/worker/site_interact.py
+++ b/app/trading/worker/site_interact.py
@@ -67,8 +67,12 @@ data/evidence/checkout-research-20260811/NOTES.md）：
- fetch_order_detail / list_recent_orders 同时供「账号只读查询通道」使用
（docs/order-gateway.md §11，上游经网关问「账号里真实的订单长什么样」）。
查询返回的规范化字段全部来自上面这两条已实测路径；额外带出的站点原始 JSON 里，
- **只有订单列表页的 orderListData 是实测过的结构**，详情页的 __INITIAL_STATE__
- 从未拿到过真实样本，只做「解析得动就原样透传」，本模块不猜它的字段。
+ 订单列表页的 orderListData（order-list 页）与订单详情页的 __INITIAL_STATE__
+ （detail 页，2026-08-16 首次拿到真实样本，见 scripts/probe_order_detail.py 与
+ .probe/order_detail/）**两个都是实测过的结构**，其中详情页配送阶段走
+ orderData.shippingList[].deliveryInfo.deliveryStatus 结构化枚举（只实测过
+ CHECKING_ORDER，见 _parse_order_detail_status）。其余字段（金额/地址/支付方式等）
+ 仍在 raw 里原样透传，本模块不重复造抽取与解释层。
**httpx 不能用于带账号的写操作**：Rakuten 对账号操作有 TLS/HTTP2 指纹校验，
同一份 cookie Playwright 能用、httpx 不能。所以本模块全程使用 Playwright
@@ -317,9 +321,19 @@ _ORDER_DETAIL_URL_TEMPLATE = (
# 订单列表页与详情页共用同一套「配送阶段进度条」组件：4 个固定阶段的 ，
# 当前阶段比其余几个多一段形如 `item-shipping-active--{hash}` 的 class
# （hash 是 CSS modules 编译产物，逐次构建会变；`-active--` 这个中缀是本模块
-# 唯一依赖的稳定信号）。用 re.findall 顺序返回 4 个 (class, 阶段文案) 二元组。
+# 唯一依赖的稳定信号）。用 re.findall 顺序返回 (class, 阶段文案) 二元组。
+# 2026-08-16 用真账号实测详情页（scripts/probe_order_detail.py，样本落盘
+# .probe/order_detail/）发现：**li class 必须锚定进度条 item 前缀 `item--3gWCU`**，
+# 否则页面上还有一套面包屑 （class 也是 `...--hash` 且紧邻 `title--2uGVi`，
+# label 同样是「ショップ」）会先于进度条第 0 项被 `findall` 抓走，导致：
+# 1. 面包屑 li 被当成第 0 阶段（active 恒为 False）；
+# 2. 真正带 `-active--` 的进度条第 0 项被错位跳过。
+# 真实样本上不锚定会 4 项全判 active=False、永远拿不到当前配送阶段。锚定后 4 项
+# 正确命中、active 落在第 0 项。两个 class 前缀（`item--3gWCU` / `title--2uGVi`）
+# 均为 CSS modules 产物，逐次构建可能变——本模块把 `` 视为唯一
+# 依赖的稳定信号之一，结构化配送状态另见 _parse_order_detail_status。
_ORDER_STEPPER_ITEM_PATTERN = re.compile(
- r'.*?([^<]*)
', re.DOTALL,
+ r'.*?([^<]*)
', re.DOTALL,
)
_ORDER_STEPPER_ACTIVE_MARKER = "-active--"
# 「ショップ」（店铺已接单，未发货）阶段没有对应的 OrderState 取值——报告过
@@ -333,6 +347,24 @@ _ORDER_STAGE_TO_STATE: dict[str, OrderState] = {
"配達完了": OrderState.DELIVERED,
}
+# ---- 订单详情页结构化配送状态（2026-08-16 首次拿到真实样本才补的路径）----
+# 详情页 __INITIAL_STATE__（pageType="ph-detail"）里的 orderData.shippingList[]
+# 每项的 deliveryInfo.deliveryStatus 是站点侧的结构化配送状态码，比解析进度条
+# CSS class 稳得多。但本模块**只映射实测见过的值**，没见过的枚举码（出荷/配達完了
+# 对应的 deliveryStatus 字符串具体长什么样，还没等到那一步的真实样本）不接管、
+# 交回 stepper _ORDER_STAGE_TO_STATE 兜底（避免掐掉 monitor 的 SHIPPED/DELIVERED
+# 上报）——绝不瞎猜映射成 OrderState，测一单真实进入「出荷/配達完了」的订单就能补上。
+# 2026-08-16 真实样本（订单仍停在「ご注文確認中」）只覆盖了 CHECKING_ORDER 这一个值。
+_DELIVERY_STATUS_TO_STATE: dict[str, OrderState] = {}
+
+# 配送状态码 → 站点给的状态文案；这张表独立于 stepper 文案映射，键是稳定的
+# deliveryStatus 枚举值。CHECKING_ORDER 是 2026-08-16 实测值（页面同时给出
+# deliveryStatusTitle="ご注文確認中"），其余条目留待真实样本补充，不做猜测。
+# stage_label 直接取 deliveryStatusTitle 的站点原文（比这张表更不易失真）。
+_DELIVERY_STATUS_TITLE: dict[str, str] = {
+ "CHECKING_ORDER": "ご注文確認中",
+}
+
# ---- 订单列表反查：verify_on_site 恢复核对用（规格 §5，2026-08-13 实测确认）----
# order.my.rakuten.co.jp/purchase-history/order-list 是真实的「我的订单列表」页
# （不是 _ORDER_DETAIL_URL_TEMPLATE 那个 detail_page_view 分支，两者 act 不同）。
@@ -507,15 +539,22 @@ class OrderStatusSnapshot:
found=False 表示页面上没找到这个订单号——**不当错误处理**：站点自己说
「ご注文の反映に10分ほどかかります」，下单后短时间内查不到是正常的，调用方
（runner._monitor_order）应该继续下一轮轮询，不是放弃。
- stage_label 是真实站点用的阶段原文（如「出荷」），供日志/证据留原始信号；
- order_state 是映射到 OrderState 的结果，映射不到（比如仍在「ショップ」这个
- 起始阶段，或者进度条没解析出来）时为 None——同样不当错误，只是「这次没有
- 新状态可报」。html 是抓取到的整页内容，供调用方按需落证据。
+ stage_label 是真实站点用的阶段原文（如「出荷」或「ご注文確認中」），供日志/
+ 证据留原始信号；order_state 是映射到 OrderState 的结果，映射不到（比如仍在
+ 「ショップ」这个起始阶段、或 deliveryStatus 枚举还没实测到的值）时为 None——
+ 同样不当错误，只是「这次没有新状态可报」。html 是抓取到的整页内容，供调用方
+ 按需落证据。
+
+ delivery_status 是详情页 orderData 侧的结构化配送状态码（如
+ "CHECKING_ORDER"），列表页（check_order_status / 进度条路径）拿不到时为 None。
+ 它不是 OrderState 的中间表示，只是把站点原始码原样带出来给调用方/上游用——
+ 规范化映射见 _parse_order_detail_status 的 deliveryStatus 分支。
"""
found: bool
stage_label: str | None = None
order_state: OrderState | None = None
+ delivery_status: str | None = None
html: str = ""
@@ -523,13 +562,12 @@ class OrderStatusSnapshot:
class OrderDetailSnapshot:
"""订单详情页的一次完整读取结果（fetch_order_detail 的返回值）
- `status` 是已实测的那部分（配送阶段进度条，见 _parse_order_status）；
- `raw` 是整页 `window.__INITIAL_STATE__` 的原文——**详情页的这份结构从未被
- 真实数据验证过**（2026-08-13 那次实测只验了进度条组件），因此这里刻意
- 只做「能解析成 JSON 就原样带出去」，不写任何字段抽取逻辑。要金额、收货
- 地址、付款方式这些字段的调用方，自己从 raw 里取并自担结构变动风险；等拿到
- 真实详情页样本后再在本模块补规范化解析，不要在没有样本的情况下先猜着写。
- 解析不出（页面没有内联状态、或不是 JSON）时为 None。
+ `status` 是已实测的那部分：配送阶段（`_parse_order_status` / stepper，2026-08-13
+ 验证）、以及 2026-08-16 首次从真实详情页样本补上的结构化配送状态
+ （`orderData.shippingList[].deliveryInfo.deliveryStatus`，见
+ `_parse_order_detail_status`）。`raw` 是整页 `window.__INITIAL_STATE__` 的
+ 原文，原样带出去给需要金额/地址/支付方式等更全字段的上游自取——本模块只做
+ 「解析得动就带走」并补了配送阶段这一层的规范化，其余字段不猜。
"""
status: OrderStatusSnapshot
@@ -1842,7 +1880,11 @@ class SiteInteractor:
两个调用方：付款后监控（`check_order_status`，只要配送阶段）与账号只读
查询通道的 order_detail（规格 §11，还要 raw 原文）。站点交互与轮询节奏
解耦，也方便离线单测轮询逻辑（用桩替换本方法）与解析逻辑
- （`_parse_order_status`，纯函数）。
+ （`_parse_order_status` / `_parse_order_detail_status`，纯函数）。
+
+ 配送阶段解析优先走详情页结构化 `orderData`（`_parse_order_detail_status`，
+ 2026-08-16 拿到真实样本后新增），抽样不到或枚举未识别时降级回进度条
+ （`_parse_order_status`）——两条路径都拿不到才返回 found=False。
与 enter_checkout 不同，本方法开自己的临时 Page 并在返回前关闭——
submit_order/pay 已经处理完并关闭了 `_checkout_pages` 里留存的会话，
@@ -1878,12 +1920,19 @@ class SiteInteractor:
# 只在「没解析到订单」时才查掉登录：解析到了就说明页面是真的订单页，
# 没必要再判一次；反过来，found=False 有两种可能（订单还没反映出来 /
# 被踢去登录），这里把后者摘出来，不让它伪装成前者。
- snapshot = _parse_order_status(html, site_order_id)
+ #
+ # 2026-08-16 拿到真实详情页样本后，解析优先走结构化 orderData
+ # （_parse_order_detail_status），解析不到时降级回 stepper
+ # （_parse_order_status）。两者都拿到 state/order_id 才算 found。
+ state = _parse_initial_state(html)
+ snapshot = _parse_order_detail_status(state, site_order_id) or _parse_order_status(
+ html, site_order_id
+ )
if not snapshot.found and auth_site.looks_logged_out(
"rakuten", final_url=final_url, body=html
):
raise _LoggedOutMidRead(f"订单详情页落地 {final_url}")
- return OrderDetailSnapshot(status=snapshot, raw=_parse_initial_state(html))
+ return OrderDetailSnapshot(status=snapshot, raw=state)
return await self._read_with_relogin_retry(
f"check_order_status site_order_id={site_order_id}", read
@@ -2129,6 +2178,69 @@ def _parse_order_status(html: str, site_order_id: str) -> OrderStatusSnapshot:
return OrderStatusSnapshot(found=True, html=html)
+def _parse_order_detail_status(state: dict | None, site_order_id: str) -> OrderStatusSnapshot | None:
+ """订单详情页结构化配送状态解析（纯函数，供 fetch_order_detail 调用）
+
+ 只负责「从详情页 __INITIAL_STATE__.orderData 抽配送阶段」这一条路径。
+ 抽不到（state 为 None / 缺 orderData / 缺 deliveryStatus）返回 None，告诉调用方
+ 该降级回 stepper 路径（_parse_order_status）——因为那是从 html 解析的，而本函数
+ 只拿到 state，不持有 html，降级必须由拿到 html 的调用方来做。
+ 这样两条解析路径各自保持纯函数、可独立单测，互不污染。
+
+ 2026-08-16 首次拿到真实详情页样本（scripts/probe_order_detail.py 与
+ .probe/order_detail/01-detail-initial-state.json，订单仍停在「ご注文確認中」）
+ 后新增本路径。deliveryStatus 的规范化映射遵循「只映射实测值」原则
+ （_DELIVERY_STATUS_TO_STATE / _DELIVERY_STATUS_TITLE 目前都只有 CHECKING_ORDER）：
+ **未被识别的枚举码直接返回 None、交回 stepper 兜底**，绝不瞎猜映射成
+ OrderState——避免真实订单走到「出荷/配達完了」时把 monitor 的 SHIPPED/DELIVERED
+ 上报掐掉，测一单真实进入那一步的订单后再补映射。
+
+ Args:
+ state: `_parse_initial_state(html)` 的结果。
+ site_order_id: 站点注文番号，用于 found 判定。
+
+ Returns:
+ 识别出的 deliveryStatus 时返回 OrderStatusSnapshot；否则返回 None（调用方降级）。
+ """
+ if state is None:
+ return None
+ # 先确认这份 state 确实是所查的这笔订单，再信任它的配送状态——否则要是 SPA
+ # 复用了别的订单草稿/导航到别的页，光看到 deliveryStatus 就当 found 会误报。
+ # 用站点自己给的 orderNumber 对账（requestParams 与 orderData.orderSummary 都带，
+ # 任一命中即可；两处都拿不到就按「不是这笔订单」降级回 stepper 的 html 判定）。
+ order_number = (
+ (state.get("requestParams") or {}).get("orderNumber")
+ or (state.get("orderData") or {}).get("orderSummary", {}).get("orderNumber")
+ )
+ if order_number != site_order_id:
+ return None
+ order_data = state.get("orderData") or {}
+ shipping = order_data.get("shippingList") or []
+ delivery_info = (shipping[0].get("deliveryInfo") or {}) if shipping else {}
+ delivery_status = delivery_info.get("deliveryStatus")
+ if not delivery_status:
+ return None
+ # 只在该枚举值「已被实测认识」时才接管这份状态：多了就返回 None 交回 stepper
+ # 路径兜底——否则这张新表还没见过「出荷/配達完了」对应的 deliveryStatus 字符串，
+ # 一旦真实订单走到那一步，结构化路径会给 order_state=None 把 monitor 的
+ # SHIPPED/DELIVERED 上报掐掉，而 stepper 的 _ORDER_STAGE_TO_STATE 早就能映射。
+ if delivery_status not in _DELIVERY_STATUS_TO_STATE and delivery_status not in _DELIVERY_STATUS_TITLE:
+ return None
+
+ # deliveryStatus 是结构化枚举，用它作为权威阶段信号
+ stage_label = delivery_info.get("deliveryStatusTitle") or _DELIVERY_STATUS_TITLE.get(
+ delivery_status
+ )
+ order_state = _DELIVERY_STATUS_TO_STATE.get(delivery_status)
+ return OrderStatusSnapshot(
+ found=True,
+ stage_label=stage_label,
+ order_state=order_state,
+ delivery_status=delivery_status,
+ html="",
+ )
+
+
def _parse_order_list(html: str) -> OrderListPage:
"""订单列表页解析核心逻辑（纯函数，供 list_recent_orders 调用，便于离线单测）
diff --git a/docs/order-gateway.md b/docs/order-gateway.md
index 0e77375..4f5348f 100644
--- a/docs/order-gateway.md
+++ b/docs/order-gateway.md
@@ -435,18 +435,31 @@ queued ──lease──> leased ──result──> succeeded
"kind": "order_detail",
"order_number": "306087-20260813-0863947697",
"found": true, // false 不是错误：站点自己说下单后要 ~10 分钟才反映
- "stage_label": "出荷", // 站点原文（已实测的配送阶段进度条）
+ "stage_label": "出荷", // 站点原文（配送阶段）
"order_state": "shipped", // 映射到 OrderState；映射不到为 null
+ "delivery_status": "CHECKING_ORDER", // 站点结构化配送状态码；列表页/stepper 路径为 null
"raw": { /* 页面 __INITIAL_STATE__ 原文 */ },
"raw_available": true
}
```
-> **实测边界（重要）**：`stage_label` / `order_state` 走的是 2026-08-13 用真实订单号
-> 验证过的进度条解析；但**详情页的 `__INITIAL_STATE__` 结构从未拿到真实样本**。
-> 因此本服务对它只做「解析得动就原样透传」，不抽任何字段——想要金额、收货地址、
-> 付款方式的调用方自己从 `raw` 里取并自担结构变动风险。等拿到真实样本后再在
-> `site_interact.py` 里补规范化解析，**不要在没有样本的情况下先猜着写**。
+> **实测边界（2026-08-16 更新）**：上次评估时「详情页 `__INITIAL_STATE__` 结构从未
+> 拿到真实样本」——**已用真账号真实爬过一次**（`scripts/probe_order_detail.py`，
+> 样本落盘 `.probe/order_detail/`，订单号 306087-20260813-0863947697）。确认：
+> - 详情页 `pageType="ph-detail"`，配送阶段有两处可解析信号：CSS 进度条
+> （`_parse_order_status`）**以及** `orderData.shippingList[].deliveryInfo.
+> deliveryStatus` 结构化枚举（`_parse_order_detail_status`，2026-08-16 新增）。
+> `stage_label` 优先取 `deliveryStatusTitle` 站点原文（如「ご注文確認中」）。
+> - 进度条解析修了一个此前未暴露的回归：不锚定 `` 时，
+> 详情页的面包屑 `` 会先于进度条第 0 项被 `findall` 抓走，导致带 `-active--`
+> 的当前阶段被错位跳过、永远判不出阶段（见 `_ORDER_STEPPER_ITEM_PATTERN` 注释）。
+> - `deliveryStatus` 的枚举→`OrderState` 映射**仍只实测过 `CHECKING_ORDER` 一个值**，
+> 未识别的枚举值一律不接管、交回 stepper 兜底（避免掐掉 monitor 的
+> SHIPPED/DELIVERED 上报）。`delivery_status` 字段把这个原始码原样带给上游对账。
+> - `raw` 仍原样透传，想要金额/收货地址/付款方式的调用方从 `raw.orderData` 自取
+> （2026-08-16 样本确认其结构：`orderSummary` / `itemObject.itemList[]` /
+> `shippingList[].deliveryInfo.deliveryAddress` / `paymentInfoModel` 等），
+> 本服务仍不自担字段抽取的去重/解释责任。
结果体积上限 `RAKUTEN_QUERY_RESULT_MAX_BYTES`：超限先丢 `raw_pages`/`raw` 并置
`raw_omitted`；丢完仍超限则整单判失败，让上游缩小窗口重来——不把几 MB 页面状态
diff --git a/scripts/probe_order_detail.py b/scripts/probe_order_detail.py
new file mode 100644
index 0000000..a5f5022
--- /dev/null
+++ b/scripts/probe_order_detail.py
@@ -0,0 +1,212 @@
+"""订单详情页探针：为账号只读查询通道（docs/order-gateway.md §11）取详情页真实 DOM 结构
+
+目标：`fetch_order_detail` 目前只把详情页 `window.__INITIAL_STATE__` 原样透传
+（从未有过真实样本，只做「解析得动就带走」，见 site_interact.py::_parse_initial_state
+上方与 OrderDetailSnapshot 文档）。本探针用真账号登录态打开一条真实订单的详情页
+（`_ORDER_DETAIL_URL_TEMPLATE` 那条 `act=detail_page_view` 路径），把整页 HTML、
+以及解析出的 `__INITIAL_STATE__` JSON 都落盘，作为后续补规范化字段抽取的第一份
+真实样本。
+
+只读导航，不做任何加购/下单操作。
+
+用法：
+ .venv/Scripts/python.exe scripts/probe_order_detail.py
+ .venv/Scripts/python.exe scripts/probe_order_detail.py --headful
+ .venv/Scripts/python.exe scripts/probe_order_detail.py --order 306087-20260813-0863947697
+"""
+from __future__ import annotations
+
+import argparse
+import asyncio
+import json
+import re
+import sys
+from pathlib import Path
+
+sys.path.insert(0, str(Path(__file__).resolve().parent.parent))
+
+# Windows 控制台默认 GBK，打印含日文/波浪符（如 U+301C 〜）的中文会抛
+# UnicodeEncodeError——统一改 stdout 为 UTF-8，跟 save() 落盘的编码保持一致
+# （记忆 project://jp-rakuten/index 里「Git Bash 打中文 body 乱码」是同一问题的另一面）
+if hasattr(sys.stdout, "reconfigure"):
+ try:
+ sys.stdout.reconfigure(encoding="utf-8")
+ except Exception:
+ pass
+
+from app.shared.config import get_settings # noqa: E402
+from app.trading.core import auth_site # noqa: E402
+
+PROBE_DIR = Path(__file__).resolve().parent.parent / ".probe" / "order_detail"
+PROBE_DIR.mkdir(parents=True, exist_ok=True)
+
+# 与 site_interact.py::_ORDER_DETAIL_URL_TEMPLATE 保持一致
+ORDER_DETAIL_URL_TEMPLATE = (
+ "https://order.my.rakuten.co.jp/purchase-history/"
+ "?order_number={order_number}&shop_id={shop_id}&act=detail_page_view"
+)
+DEFAULT_ORDER_ID = "306087-20260813-0863947697"
+
+
+def save(name: str, content: str | bytes) -> Path:
+ path = PROBE_DIR / name
+ if isinstance(content, bytes):
+ path.write_bytes(content)
+ else:
+ path.write_text(content, encoding="utf-8")
+ print(f" saved -> {path} ({len(content)} bytes)")
+ return path
+
+
+def parse_initial_state(html: str) -> dict | None:
+ m = re.search(
+ r"window\.__INITIAL_STATE__\s*=\s*(.+?);\s*window\.",
+ html,
+ re.DOTALL,
+ )
+ if not m:
+ return None
+ try:
+ return json.loads(m.group(1))
+ except json.JSONDecodeError:
+ return None
+
+
+async def run(*, headful: bool, order_id: str) -> int:
+ from playwright.async_api import async_playwright
+
+ settings = get_settings()
+ state_path = settings.auth_state_path / "rakuten_state.json"
+ if not state_path.exists():
+ print(f"找不到登录态文件：{state_path}")
+ return 1
+
+ shop_id = order_id.split("-", 1)[0]
+ url = ORDER_DETAIL_URL_TEMPLATE.format(order_number=order_id, shop_id=shop_id)
+
+ async with async_playwright() as pw:
+ browser = await pw.chromium.launch(
+ headless=not headful,
+ channel=settings.browser_channel or None,
+ proxy=settings.playwright_proxy,
+ args=["--no-first-run", "--disable-blink-features=AutomationControlled"],
+ )
+ context = await browser.new_context(
+ storage_state=state_path,
+ user_agent=auth_site.RAKUTEN_USER_AGENT,
+ locale="ja-JP",
+ timezone_id="Asia/Tokyo",
+ viewport={"width": 390, "height": 844},
+ is_mobile=True,
+ has_touch=True,
+ )
+ page = await context.new_page()
+
+ api_calls: list[tuple[int, str]] = []
+
+ def on_response(r):
+ api_calls.append((r.status, str(r.url)))
+
+ page.on("response", on_response)
+
+ print(f"=== 访问订单详情页（order_id={order_id}）===")
+ try:
+ await page.goto(url, wait_until="domcontentloaded", timeout=30_000)
+ await page.wait_for_timeout(3000)
+ except Exception as exc:
+ print(f"导航失败：{type(exc).__name__}: {exc}")
+
+ html = await page.content()
+ final_url = page.url
+ print(f" final_url={final_url} body_len={len(html)}")
+ print(f" 含订单号 {order_id}: {order_id in html}")
+ logged_out = auth_site.looks_logged_out(
+ "rakuten", final_url=final_url, body=html
+ )
+ print(f" looks_logged_out={logged_out}")
+
+ save("00-detail-default.html", html)
+
+ state = parse_initial_state(html)
+ if state is None:
+ print(" !! 解析不到 __INITIAL_STATE__（可能 PC 模板 / 掉登录 / 反爬）")
+ else:
+ print(f" __INITIAL_STATE__ 顶层键：{sorted(state.keys())}")
+ print(f" pageType={state.get('pageType')!r}")
+
+ # 打印与订单/阶段相关的子结构概览，方便人眼核对
+ print("\n=== 与订单字段相关的线索 ===")
+ flat_search = {}
+ def walk(node, prefix=""):
+ if isinstance(node, dict):
+ for k, v in node.items():
+ p = f"{prefix}.{k}" if prefix else k
+ if isinstance(v, (dict, list)):
+ walk(v, p)
+ elif isinstance(v, (str, int, float)) and 0 < len(str(v)) <= 80:
+ flat_search[p] = v
+ elif isinstance(node, list):
+ for i, v in enumerate(node[:5]):
+ walk(v, f"{prefix}[{i}]")
+ walk(state)
+ for pat in ["order", "stage", "配送", "出荷", "配達", "金額", "amount",
+ "address", "payment", "shop", "item", "status"]:
+ hits = {k: v for k, v in flat_search.items() if pat in k.lower()}
+ if hits:
+ print(f" 键含 {pat!r}（前 15 条）：")
+ for k, v in list(hits.items())[:15]:
+ print(f" {k} = {v!r}")
+
+ save("01-detail-initial-state.json", json.dumps(
+ state, ensure_ascii=False, indent=2,
+ ))
+ # 顶层平铺一份，方便快速看
+ save("02-detail-initial-state-top.json", json.dumps(
+ {k: (v if not isinstance(v, (dict, list)) else "…") for k, v in state.items()},
+ ensure_ascii=False, indent=2,
+ ))
+
+ # 配送阶段进度条（_ORDER_STEPPER_ITEM_PATTERN 那套），确认详情页同样适用
+ steps = re.findall(
+ r'.*?([^<]*)
',
+ html,
+ re.DOTALL,
+ )
+ print(f"\n=== 配送阶段进度条（_ORDER_STEPPER_ITEM_PATTERN）===")
+ if steps:
+ for cls, label in steps:
+ print(f" stage={label!r} active={'-active--' in cls}")
+ else:
+ print(" （未匹配到进度条 li 结构）")
+
+ print("\n=== 捕获的 XHR（末 20 条）===")
+ for status, u in api_calls[-20:]:
+ print(f" {status} {u[:160]}")
+
+ # 截图留底（无头模式下可能是白屏/异常渲染，正好暴露反爬）
+ try:
+ await page.screenshot(path=str(PROBE_DIR / "03-detail-screenshot.png"), full_page=True)
+ print(" 截图 ->", PROBE_DIR / "03-detail-screenshot.png")
+ except Exception as exc:
+ print(f" 截图失败：{type(exc).__name__}: {exc}")
+
+ await browser.close()
+
+ print(f"\n探针输出目录：{PROBE_DIR}")
+ return 0
+
+
+async def main() -> int:
+ parser = argparse.ArgumentParser()
+ parser.add_argument("--headful", action="store_true")
+ parser.add_argument(
+ "--order",
+ default=DEFAULT_ORDER_ID,
+ help="要探测的订单号（默认已知订单 2026-08-13 实测那单）",
+ )
+ args = parser.parse_args()
+ return await run(headful=args.headful, order_id=args.order)
+
+
+if __name__ == "__main__":
+ raise SystemExit(asyncio.run(main()))
diff --git a/tests/test_site_interact.py b/tests/test_site_interact.py
index 64ef005..2494b24 100644
--- a/tests/test_site_interact.py
+++ b/tests/test_site_interact.py
@@ -39,6 +39,7 @@ from app.trading.worker.site_interact import (
_parse_checkout_summary,
_parse_initial_state,
_parse_order_list,
+ _parse_order_detail_status,
_parse_order_status,
parse_order_datetime,
)
@@ -334,6 +335,118 @@ def test_order_status_snapshot_defaults():
assert s.html == ""
+# ---- _parse_order_status：2026-08-16 真实详情页样本暴露出面包屑干扰的回归 ----
+# 真实详情页除了配送进度条，还有一套面包屑 （class 同样含 CSS modules hash、
+# label 也是「ショップ」且紧邻 title--2uGVi）。不锚定 li class 前缀时，findall
+# 会先抓走面包屑、再把带 -active-- 的进度条第 0 项错位跳过，导致永远判不出当前
+# 阶段。修复后锚定 item--3gWCU 前缀，下面用脚本 probe_order_detail.py 落盘的真实
+# 片段回归防倒退回退化。
+
+# 摘自 .probe/order_detail/00-detail-default.html 的可复现片段：
+# 面包屑 li（应被排除）在前，真正的进度条第 0 项（active）夹在中间。
+_REAL_STEPPER_HTML = (
+ ''
+ ''
+ ''
+ '- '
+ '
..
ショップ
'
+ '- '
+ '
出荷
'
+ '- '
+ '
配達店
'
+ '- '
+ '
配達完了
'
+ '
'
+ f'注文番号：{_REAL_ORDER_ID}
'
+ ''
+)
+
+
+def test_parse_order_status_breadcrumb_sibling_does_not_shadow_active_item0():
+ """真实详情页有面包屑 li，不得让它替代进度条 item-0 挡在 -active-- 判定前"""
+ snapshot = _parse_order_status(_REAL_STEPPER_HTML, _REAL_ORDER_ID)
+ assert snapshot.found is True
+ assert snapshot.stage_label == "ショップ"
+ assert snapshot.order_state is None
+
+
+# ---- _parse_order_detail_status：2026-08-16 首次拿到详情页真实样本才有的路径 ----
+# orderData.shippingList[].deliveryInfo.deliveryStatus 是站点结构化配送状态，比
+# CSS 进度条稳。但映射遵循「只映射实测值」，当前只有 CHECKING_ORDER 一个样本。
+
+
+def _detail_state(*, delivery_status: str | None, title: str | None, order_ok: bool = True) -> dict:
+ """构造详情页 __INITIAL_STATE__ 最小 fixture（真实样本 .probe/order_detail）"""
+ return {
+ "pageType": "ph-detail",
+ "requestParams": {"orderNumber": _REAL_ORDER_ID if order_ok else "other-order"},
+ "orderData": {
+ "orderSummary": {"orderNumber": _REAL_ORDER_ID if order_ok else "other-order"},
+ "shippingList": [
+ {
+ "deliveryInfo": (
+ {"deliveryStatus": delivery_status, "deliveryStatusTitle": title}
+ if delivery_status
+ else {}
+ )
+ }
+ ],
+ },
+ }
+
+
+def test_parse_order_detail_status_uses_delivery_status_when_present():
+ """结构化的 deliveryStatus 优先于 stepper，stage_label 取站点原文"""
+ snapshot = _parse_order_detail_status(
+ _detail_state(delivery_status="CHECKING_ORDER", title="ご注文確認中"), _REAL_ORDER_ID
+ )
+ assert snapshot is not None
+ assert snapshot.found is True
+ assert snapshot.delivery_status == "CHECKING_ORDER"
+ assert snapshot.stage_label == "ご注文確認中"
+ # 尚无实测映射的枚举值不猜 order_state（CHECKING_ORDER 对应「ショップ」阶段，
+ # 已报告过 ORDERED/PAID，不需要 monitor 再报，与 stepper 行为一致）
+ assert snapshot.order_state is None
+
+
+def test_parse_order_detail_status_unknown_code_falls_back_to_none():
+ """没实测过的 deliveryStatus 不接管——交回 stepper 兜底（避免掐掉 SHIPPED/DELIVERED 上报）
+
+ 实测只认识 CHECKING_ORDER；一旦真实订单走到「出荷/配達完了」，其 deliveryStatus
+ 字符串还是未知，此时若结构化路径返回 order_state=None 会把 monitor 的状态上报
+ 掐掉。所以未识别的枚举值直接返回 None，由调用方降级到 stepper 的
+ _ORDER_STAGE_TO_STATE（后者早就能映射出荷/配達完了）。
+ """
+ assert (
+ _parse_order_detail_status(
+ _detail_state(delivery_status="SOME_FUTURE_STATUS", title="出荷待ち"),
+ _REAL_ORDER_ID,
+ )
+ is None
+ )
+
+
+def test_parse_order_detail_status_returns_none_wrong_order():
+ """state 的 orderNumber 对不上所查订单时不得当 found（防 SPA 复用到别的订单）"""
+ assert (
+ _parse_order_detail_status(
+ _detail_state(delivery_status="CHECKING_ORDER", title="ご注文確認中", order_ok=False),
+ _REAL_ORDER_ID,
+ )
+ is None
+ )
+
+
+def test_parse_order_detail_status_returns_none_when_no_order_data():
+ assert _parse_order_detail_status(None, _REAL_ORDER_ID) is None
+ assert (
+ _parse_order_detail_status(_detail_state(delivery_status=None, title=None), _REAL_ORDER_ID)
+ is None
+ )
+
+
# ---- check_order_status 在没启动 Playwright 时应失败 ----