PayActivity 一次既有 Back 后最多25次200ms采样（原3次），约5秒，不含捕获耗时。过渡最多60次；首次待付款页开始独立30次读取预算，总上限90次且不重复重置。缺少完整订单号/时间立即UP滑动，最多4次、400ms手势、500ms稳定等待；完整证据立即停止。新增待付款分支无任何控件点击；创建订单/支付边界不改。
Server go test -p 1 ./app/goauto/purchase ./app/goauto/clientapi 通过；go build通过。新增8组金额/缺失/零/历史保留/负值/结果类型与幂等测试。既有订单号/SYB入队回归通过。
Android全量测试尝试在既有 ImageSearchBackRecoveryTest.a back that does move the page does not count as stalled / PinduoduoImageSearchAutomation.awaitPage 运行3分多钟未结束（jstack定位），已停止本次测试进程，未改图搜范围；不宣称全量通过。
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
原始需求
用户 2026-09-19：「can we get the purchase order number after create order in pdd app?」并现场创建采购任务（SYB 订单 260919DS5BSHR3）配合实测。
现场实测（任务 391，设备 8 = 192.168.0.173:38881，PDD 8.25.0）
用
dumpsys window全程追踪 Activity 变化（不触碰无障碍层，避免干扰 Agent 自身执行）：订单创建成功：
260919-137457877324044，收货地址后缀_cg391，与本任务一致。Agent 是在待付款页出现前约 1 秒退出的，它根本没有看到那一页。
失败后抓取该页控件树（90 节点），订单号确实在页面上，但位于折叠线以下：
屏幕高 2376。零高度节点
isVisibleToUser为 false。用户实测需要向下滑动两次才能让订单号进入视野。页面判定现状（决定走哪条分支）
PDD_PAYMENT_ACTIVITIES = {com.xunmeng.pinduoduo.app_pay.core.PayActivity}NewPageActivity，与订单列表、订单详情、下单确认页完全相同，无法靠 Activity 区分，只能靠文字：UNPAID_MARKERS = [待付款, 待支付, 去支付]、ORDER_CONTEXT_MARKERS = [订单编号, 订单号, 下单时间, 创建时间]paymentVisible = isKnownPddPaymentActivity && !orderContextVisible && !unpaidContextVisible根因：两层叠加
第一层（主因）：支付页等待窗口短于 PDD 的页面过渡时间
落到 PayActivity 后按一次返回键，再连续 3 帧（600ms）仍是 PayActivity 就报
PURCHASE_ORDER_PAYMENT_REPEATED。实测 PayActivity 停留 2 秒，600ms 必然用尽。第二层：待付款页的滑动是固定节奏，不是按需
index是全局帧计数，与微信页、支付页的绕路共用；ORDER_RESULT_MAX_SAMPLES = 60（12 秒）中，本次绕路已消耗约 20 帧生产影响：224 个
order_result_unknown中 223 个的 error_code 是PURCHASE_ORDER_PAYMENT_REPEATED；12 个order_created全部带订单号（读到就一定准）。方案
UNPAID_MARKERS但parseOrderEvidence仍无结果时，立即滑动并重读，有界重复（覆盖实测所需的 2 次并留余量），不再等固定节奏。[必须]该分支只做滑动与读取，不得点击任何控件。支付、下单相关文字仅作只读识别信号，不得作为点击目标。验收
order_created结束，全程无点击。order_created结束并带回订单号。风险与回退
AGENTS.md为高风险，实施前需人工确认。ORDER_RESULT_MAX_SAMPLES与任务整体时限。相关但不在本工单范围
本次任务地址后缀为
_cg391（正确），但同设备上另外 5 个历史订单的后缀全部是_cg348（5 个不同商品、5 个不同订单号共用一个后缀）。说明地址改写会间歇性失败，会让依赖后缀匹配的回填把订单号挂到错误任务上。需另建工单核查。追加范围：在待付款页一并读取应付金额并上报（用户 2026-09-19 确认）
既然订单号改为在待付款页当场获取、不再依赖遍历「我的订单」，同一次取帧里应当把应付金额一并带回。
实测页面证据（任务 391 失败后抓取的同一页）：
已优惠3元使用3元平台无门槛券,应付:,13元,(免运费)应付订单编号： 260919-137457877324044应付金额位置高于订单号，只要能走到待付款页就已在视野内，不需要额外机制；本工单的等待窗口与按需滑动修复即可覆盖。
语义（用户确认）：
pdd_order_amount_cent存应付金额。该页同时存在
拼单价¥16、平台优惠-¥3、应付:13元三个数。应付是「还需支付多少」；本项目从不支付，因此这些订单不会产生实付金额，该列按应付语义写入，不再区分实付。改动链路：
PurchaseLiveAutomation：新增应付金额解析（仅匹配应付，不得匹配拼单价/平台优惠/实付），与订单号、下单时间在同一批labels中解析；金额缺失或不唯一时只留空该字段，不影响订单号回报。PurchaseOrderEvidence与PurchaseExecutionOutcome：新增订单应付金额字段（现仅有actualUnitPriceCent单价，无订单总额）。ResultRequest新增pddOrderAmountCent。lifecycle.go：在写入ActualUnitPriceCent的同一处写入PDDOrderAmountCent；该列已存在，不需要迁移。与回填的写入冲突：
pdd_order_amount_cent此前只由回填写入（回填读的是实付:）。按本次确认统一为应付语义后，两条写入路径需保持一致；回填侧是否同步调整，在本工单实施时一并确认。追加验收：
拼单价/平台优惠/应付三个数时，只取应付金额；金额不唯一或缺失时该字段为空且不影响订单号与下单时间的回报。pddOrderAmountCent正确落库到pdd_order_amount_cent。docs/08-agent-api-contract.md。文档影响更正：本工单新增 Agent 上报字段
pddOrderAmountCent，属共享 API 契约变化，需更新docs/08-agent-api-contract.md；正文「无长期文档影响」的结论相应作废。下单后在待付款页向下滑动取订单号，替代按返回键to 下单后核单失败：支付页等待窗口过短 + 待付款页未按需滑动根因更正（2026-09-19）
初版把主因写成「缺少向下滑动」。拿到完整 Activity 时间线后，这个判断不成立，已更正正文。
错在哪里：滑动逻辑是存在的——
readOrderResult()在识别到订单页/待付款页后，每 15 帧（3 秒）会swipePurchase(UP, 400)一次。初版只看了失败时的页面快照，没有追踪 Activity 序列，就推断成「代码没有滑动」。实际主因：支付页的等待窗口短于 PDD 的页面过渡时间。
PayActivity 实测停留 2 秒，600ms 的窗口必然用尽——Agent 在待付款页出现前约 1 秒就退出了，根本没走到有滑动逻辑的那个分支。
第二层问题仍然成立但不是主因：待付款页上订单号确实在折叠线以下（零高度、
isVisibleToUser=false），现有滑动是固定节奏而非按需，且index与微信页、支付页的绕路共用预算，到达待付款页后不重新起算，剩余滑动次数可能不足用户实测所需的 2 次。方案相应从「补充滑动」改为三点：放宽支付页等待窗口、待付款页按需滑动、滑动预算与绕路解耦。
状态：待人工确认后实施（采购流程，高风险）。
开始实施。用户明确要求按 #325 工单范围执行，不扩大范围。本次仅 Android PurchaseLiveAutomation 的支付页有界等待、待付款页独立预算/按需滑动，以及应付金额随采购结果上报、Server 接收与入库、相关测试/API契约。Agent我的订单回填、Chrome回填、Web展示和历史金额不改；既有路径仍为实付语义，因此统一旧路径/历史数据不是本单已完成能力，不将本次混合来源列宣称全局已统一。基线 origin/main 10be374；独立工作树 issue-325。用户实施指令授权代码实施，不执行真机创建订单、付款、迁移或线上发布。本会话未提供 Gitea MCP，回退 API。
实现完成，待验收（2026-09-19）
按用户“按照工单执行，不扩大范围”实施。无 Gitea MCP，按规则回退 API。
验证
APK与边界
用户授权步骤1/2/3已执行（2026-09-19）
用户明确授权先合并main、更新线上Admin/API、再安装到192.168.0.173:38881。当前无Gitea MCP，回退API。
未发起真机采购、改地址、订单回填或付款，业务验收待用户发起采购。已有Wiki记录了本次契约；本轮复用既有部署拓扑/配置/命令与回滚方式，无新增长期运维方式变化，因此发布证据集中回写工单，不重复Wiki同步。工单保持待验收。
补充安装验证（2026-09-19）：按用户授权将同一 #325 APK 覆盖安装至 192.168.0.9:33259。安装前线上设备7活动/待执行采购及采集计数均0，本地采购220条均completed。adb install -r 返回 Success；手机base.apk SHA256=f343e731b1bf4390cdb3e24948aeaaeafe612dbee9a928e1f70370cd8754fb4e，与上一台安装包一致。lastUpdateTime=2026-09-19 14:13:10，版本文字仍0.9.59/code72。未卸载或清数据，未发起采购、回填或付款；保持待验收。当前无Gitea MCP，沿用API回写。
2026-09-19按用户再次明确要求，两台设备重新adb install -r覆盖安装最新main对应#325 APK。安装前设备7/8线上pending/running等任务均0，本地采购记录全部completed。192.168.0.173:38881安装时间15:54:17；192.168.0.9:33259安装时间15:54:18；两台均Success，base.apk SHA256均f343e731b1bf4390cdb3e24948aeaaeafe612dbee9a928e1f70370cd8754fb4e。版本仍0.9.59/code72。当前main相对b76fb73无Android差异。未卸载/清数据，未触发采购或付款。无Gitea MCP，使用API回写。