OPC/goauto
2
0
Fork 0
Code Issues 192 Pull Requests Actions Packages Projects Releases Wiki Activity

采购任务就地重试：不新建任务，重跑时刷新采购规则 #157

New Issue
Closed
opened 2026-08-29 16:33:28 +08:00 by ila · 2 comments
ila commented 2026-08-29 16:33:28 +08:00
Owner
Copy Link
Copy Source

所属与来源

  • 关联工单：#132 PDD 商品替换（四）续做入口（其「继续采购」保持新建任务，与本工单语义不同）、#127 采购规则落库、#155 采集失败任务按 attempt 复用（同类做法，可参考）。
  • 来源：用户于 2026-08-29 明确：采购任务失败时点击「重试采购」应当重跑当前任务而不是创建新任务；并进一步确认最小化改动方案为「Agent 从 Admin 获取最新的采购规则，尝试重新运行选择的采购任务」。
  • 类型：Server + Android Agent / 采购任务就地重试。
  • 设计证据：复用采购任务详情中既有的「重试采购」按钮，仅改变其行为与确认文案，不新增页面、组件与导航；提供标注截图或复用现有规范即可，不需要完整原型。
  • 工具回退说明：本工单通过 Gitea API 创建；当前会话未提供 Gitea MCP 工具，按 AGENTS.md「Gitea 交互与工单最小读取」记录回退原因。

当前事实（提交 cc326eb 复核）

  1. Agent 的「重试采购」当前是创建新任务：purchase/retry.go:143 的 AgentRetry 注释为「creates one safe replacement task」，内部委托 BatchRetry；retry.go:67-69 明确「creates new pending purchase tasks from failed task identities. The failed rows remain immutable history」。
  2. Android 确认文案（TaskHistoryFragment.kt:82）仍为「系统会保留原任务，并创建一个新的采购任务」。
  3. 按钮仅对失败任务显示：PurchaseRetryPolicy.showsAction 要求 status == "failed"（TaskHistoryFragment.kt:81）——本工单不改变该显示条件。
  4. 每次 attempt 都记录规则哈希：lifecycle.go:182 创建 PurchaseTaskAttempt 时写入 RuleSnapshotHash。因此即使任务上的 RuleSnapshot 被更新，「历次尝试各自使用了哪一版规则」仍可从 attempt 追溯。
  5. 建任务时会校验设备能力：batch.go:284 与 service.go:284 均调用 ensureCapabilities(...)；lifecycle.go:49/99/174/545 在调度与执行环节读取 RequiredCapabilitiesJSON。
  6. 采集侧已有可参考的就地重置实现：task/lifecycle_service.go:27-37 的 Reset（Admin）与 ResetForDevice（Agent）共用同一内部 reset，Agent 入口额外校验设备在线与任务归属；AGENTS.md 第 1 节已将「重置采集任务保留快照、清空旧结果后重新进入 pending」定为业务规则。最新提交 cc326eb 进一步实现了采集失败任务按 attempt 复用。

目标

  1. 「重试采购」改为就地重跑当前任务：任务号不变，商品、规格映射、价格快照一律不动。
  2. 重试时从服务端读取当前生效的采购规则并更新任务的规则快照——采购失败的常见原因之一即规则不适配（PDD 改版、按钮文案变化），采购员在 Admin 修正规则后需要能用新规则重跑同一笔。
  3. 不限制重试次数：由采购员人工判断。
  4. 与 #132 的「继续采购」在语义与文案上明确区分。

非目标

  • 不改变 #132 的「继续采购」：商品被替换后数据已变，必须重新解析商品、映射与价格，仍为新建任务。
  • 不改变 AgentRetry / BatchRetry 的既有实现与语义——它们继续服务于「继续采购」与 Admin 的批量重试。
  • 不改变按钮的显示条件（仍仅对失败任务显示）。
  • 不限制重试次数，不引入自动重试。
  • 不做「快照失效则拒绝」校验：商品停用、映射失效等情况下重试自然会失败，采购员据此判断是否回 Admin 重建。按最小化改动原则本期不实现。
  • 不修改采集侧行为。
  • 不实现支付；不放宽 #116 的门禁。

实施方案

服务端：新增就地重试

  1. 新增就地重试能力，结构参照采集侧的 Reset / ResetForDevice：Admin 与 Agent 共用同一内部实现，Agent 入口额外校验设备在线与任务归属（任务不属于该设备时按「任务不存在」处理）。
  2. 前置校验：
    • 任务状态为 failed；
    • 未跨过不可逆边界——order_submit_started 及其之后的任何状态一律拒绝。PDD 侧可能已生成订单，重跑会重复下单，且该事实采购员在 Agent 上无法看到。此为硬性拦截，提示走既有的「授权重新采购」流程；
    • 幂等：沿用 requestId，重复提交返回既有结果。
  3. 通过校验后，在同一事务内：
    • 读取当前生效的采购规则，更新任务的 RuleSnapshot、RuleType、RuleSchemaVersion、RequiredCapabilitiesJSON；
    • 重新校验设备能力：复用既有 ensureCapabilities，新规则的 requiredCapabilities 可能与旧版不同，不校验会把设备不支持的规则下发下去，跑到中途才失败。校验不通过即拒绝重试并给出可读原因；
    • 状态置回 pending，清空租约与运行守卫，清空 ErrorCode / ErrorMessage；
    • 商品、规格映射、价格、Target 快照一律不动。
  4. 记录一次 attempt（或沿用既有 attempt 机制），使「试过几次、每次用哪版规则、各自失败原因」可追溯。

Agent

  1. 「重试采购」按钮改为调用就地重试接口；显示条件不变。
  2. 确认文案更新，删除「创建一个新的采购任务」，改为表达「使用最新采购规则重跑当前任务」。文案保持简短，不新增说明块。
  3. 任务详情展示已尝试次数与上次失败原因，供采购员判断是否继续重试或回 Admin 重建。
  4. 与 #132 的「继续采购」文案明确区分，避免误点：前者是同一笔再试，后者是换商品后重开一笔。

安全边界

  • 已跨不可逆边界的任务一律拒绝就地重试，防止重复下单。
  • 规则更新后必须重新校验设备能力，不得下发设备不支持的规则。
  • 商品、规格、价格快照不可变；本工单只更新规则相关字段。
  • 历次尝试的规则版本通过 attempt 的 RuleSnapshotHash 保留，不因更新任务快照而丢失审计。
  • 不实现支付；不新增下单或地址目标。

验收标准

  • 点击「重试采购」后任务号不变，原任务状态由 failed 回到 pending 并可被重新执行。
  • 不产生新的采购任务。
  • 任务的 RuleSnapshot 更新为当前生效规则；RuleType、RuleSchemaVersion、RequiredCapabilitiesJSON 同步更新。
  • 商品、Mapped*、Target*、价格上下限等快照逐字段比对无变化。
  • 新规则要求的能力与设备不匹配时，重试被拒绝并给出可读原因。
  • order_submit_started 及其之后状态的任务重试被拒绝，提示走「授权重新采购」。
  • 不限制重试次数：连续多次重试均被受理（在前置校验通过的前提下）。
  • 幂等：相同 requestId 重复提交不产生重复效果。
  • 每次重试留下可追溯的尝试记录，含所用规则哈希与失败原因。
  • Agent 确认文案不再出现「创建一个新的采购任务」。
  • 「重试采购」与 #132 的「继续采购」文案可区分。
  • AgentRetry / BatchRetry 的既有行为未被改动，Admin 批量重试与 #132 的继续采购不受影响。
  • 采集侧的重置行为未受影响。

验证方式

  • go test ./app/goauto/purchase/... ./app/goauto/...
  • cd android && .\gradlew.bat :app:testDebugUnitTest :app:assembleDebug
  • 覆盖用例：正常就地重试、规则更新后能力不匹配、跨不可逆边界被拒、幂等重放、连续多次重试。
  • 真机 PKG110：构造一条因规则不适配而失败的采购任务 → 在 Admin 修正采购规则 → 在 Agent 点重试 → 确认使用新规则重跑且任务号不变。真实下单前须取得人工授权；永久禁止支付。
  • 真机、多设备与异常路径未覆盖部分如实回写。

依赖、并行与风险

  • 无强前置依赖。若 #127（采购规则落库）已完成，「当前生效规则」从数据库读取；未完成则沿用现有来源，实施时确认并说明。
  • 与 #132 无代码冲突，但两者都会修改 TaskHistoryFragment.kt 的采购任务详情，不建议同时进行。
  • 风险：更新规则快照会使任务上的规则版本与失败当时不同。缓解：attempt 的 RuleSnapshotHash 保留历次版本（事实 4）。
  • 风险：不做失效校验时，商品已停用的任务重试仍会失败一次。此为已确认的取舍——以一次失败换取实现简化，采购员据错误信息判断是否回 Admin 重建。
  • 回退：还原提交即可恢复「重试即新建任务」的既有行为，已创建任务不受影响。

文档影响

  • Wiki Business-Rules-and-Glossary：采购任务重试的语义（就地重跑、刷新规则、不限次数），以及与「继续采购」「批量重试」的区别。
  • Wiki Android-Agent-API-Contract：新增就地重试接口。
  • 按 Wiki-first 门禁：先改线上页面并回读 revision，再执行一轮 sync 与一轮 sync --check，把页面与 revision 写回本工单。

状态

待实施。

## 所属与来源 - 关联工单：#132 PDD 商品替换（四）续做入口（其「继续采购」保持新建任务，与本工单语义不同）、#127 采购规则落库、#155 采集失败任务按 attempt 复用（同类做法，可参考）。 - 来源：用户于 2026-08-29 明确：采购任务失败时点击「重试采购」应当**重跑当前任务**而不是创建新任务；并进一步确认最小化改动方案为「Agent 从 Admin 获取最新的采购规则，尝试重新运行选择的采购任务」。 - 类型：Server + Android Agent / 采购任务就地重试。 - 设计证据：复用采购任务详情中**既有**的「重试采购」按钮，仅改变其行为与确认文案，不新增页面、组件与导航；提供标注截图或复用现有规范即可，不需要完整原型。 - 工具回退说明：本工单通过 Gitea API 创建；当前会话未提供 Gitea MCP 工具，按 `AGENTS.md`「Gitea 交互与工单最小读取」记录回退原因。 ## 当前事实（提交 cc326eb 复核） 1. **Agent 的「重试采购」当前是创建新任务**：`purchase/retry.go:143` 的 `AgentRetry` 注释为「creates one safe replacement task」，内部委托 `BatchRetry`；`retry.go:67-69` 明确「creates new pending purchase tasks from failed task identities. The failed rows remain immutable history」。 2. Android 确认文案（`TaskHistoryFragment.kt:82`）仍为「系统会保留原任务，并**创建一个新的采购任务**」。 3. 按钮仅对失败任务显示：`PurchaseRetryPolicy.showsAction` 要求 `status == "failed"`（`TaskHistoryFragment.kt:81`）——本工单**不改变**该显示条件。 4. **每次 attempt 都记录规则哈希**：`lifecycle.go:182` 创建 `PurchaseTaskAttempt` 时写入 `RuleSnapshotHash`。因此即使任务上的 `RuleSnapshot` 被更新，「历次尝试各自使用了哪一版规则」仍可从 attempt 追溯。 5. **建任务时会校验设备能力**：`batch.go:284` 与 `service.go:284` 均调用 `ensureCapabilities(...)`；`lifecycle.go:49/99/174/545` 在调度与执行环节读取 `RequiredCapabilitiesJSON`。 6. **采集侧已有可参考的就地重置实现**：`task/lifecycle_service.go:27-37` 的 `Reset`（Admin）与 `ResetForDevice`（Agent）共用同一内部 `reset`，Agent 入口额外校验设备在线与任务归属；`AGENTS.md` 第 1 节已将「重置采集任务保留快照、清空旧结果后重新进入 pending」定为业务规则。最新提交 `cc326eb` 进一步实现了采集失败任务按 attempt 复用。 ## 目标 1. 「重试采购」改为**就地重跑当前任务**：任务号不变，商品、规格映射、价格快照一律不动。 2. 重试时**从服务端读取当前生效的采购规则并更新任务的规则快照**——采购失败的常见原因之一即规则不适配（PDD 改版、按钮文案变化），采购员在 Admin 修正规则后需要能用新规则重跑同一笔。 3. 不限制重试次数：由采购员人工判断。 4. 与 #132 的「继续采购」在语义与文案上明确区分。 ## 非目标 - **不改变 #132 的「继续采购」**：商品被替换后数据已变，必须重新解析商品、映射与价格，仍为新建任务。 - 不改变 `AgentRetry` / `BatchRetry` 的既有实现与语义——它们继续服务于「继续采购」与 Admin 的批量重试。 - 不改变按钮的显示条件（仍仅对失败任务显示）。 - **不限制重试次数**，不引入自动重试。 - **不做「快照失效则拒绝」校验**：商品停用、映射失效等情况下重试自然会失败，采购员据此判断是否回 Admin 重建。按最小化改动原则本期不实现。 - 不修改采集侧行为。 - 不实现支付；不放宽 #116 的门禁。 ## 实施方案 ### 服务端：新增就地重试 1. 新增就地重试能力，**结构参照采集侧的 `Reset` / `ResetForDevice`**：Admin 与 Agent 共用同一内部实现，Agent 入口额外校验设备在线与任务归属（任务不属于该设备时按「任务不存在」处理）。 2. 前置校验： - 任务状态为 `failed`； - **未跨过不可逆边界**——`order_submit_started` 及其之后的任何状态一律拒绝。PDD 侧可能已生成订单，重跑会重复下单，且该事实采购员在 Agent 上无法看到。此为硬性拦截，提示走既有的「授权重新采购」流程； - 幂等：沿用 requestId，重复提交返回既有结果。 3. 通过校验后，在同一事务内： - 读取**当前生效的采购规则**，更新任务的 `RuleSnapshot`、`RuleType`、`RuleSchemaVersion`、`RequiredCapabilitiesJSON`； - **重新校验设备能力**：复用既有 `ensureCapabilities`，新规则的 `requiredCapabilities` 可能与旧版不同，不校验会把设备不支持的规则下发下去，跑到中途才失败。校验不通过即拒绝重试并给出可读原因； - 状态置回 `pending`，清空租约与运行守卫，清空 `ErrorCode` / `ErrorMessage`； - **商品、规格映射、价格、Target 快照一律不动**。 4. 记录一次 attempt（或沿用既有 attempt 机制），使「试过几次、每次用哪版规则、各自失败原因」可追溯。 ### Agent 5. 「重试采购」按钮改为调用就地重试接口；显示条件不变。 6. 确认文案更新，**删除「创建一个新的采购任务」**，改为表达「使用最新采购规则重跑当前任务」。文案保持简短，不新增说明块。 7. 任务详情展示已尝试次数与上次失败原因，供采购员判断是否继续重试或回 Admin 重建。 8. 与 #132 的「继续采购」文案明确区分，避免误点：前者是同一笔再试，后者是换商品后重开一笔。 ## 安全边界 - 已跨不可逆边界的任务一律拒绝就地重试，防止重复下单。 - 规则更新后必须重新校验设备能力，不得下发设备不支持的规则。 - 商品、规格、价格快照不可变；本工单只更新规则相关字段。 - 历次尝试的规则版本通过 attempt 的 `RuleSnapshotHash` 保留，不因更新任务快照而丢失审计。 - 不实现支付；不新增下单或地址目标。 ## 验收标准 - [ ] 点击「重试采购」后**任务号不变**，原任务状态由 `failed` 回到 `pending` 并可被重新执行。 - [ ] 不产生新的采购任务。 - [ ] 任务的 `RuleSnapshot` 更新为当前生效规则；`RuleType`、`RuleSchemaVersion`、`RequiredCapabilitiesJSON` 同步更新。 - [ ] 商品、`Mapped*`、`Target*`、价格上下限等快照逐字段比对无变化。 - [ ] 新规则要求的能力与设备不匹配时，重试被拒绝并给出可读原因。 - [ ] `order_submit_started` 及其之后状态的任务重试被拒绝，提示走「授权重新采购」。 - [ ] 不限制重试次数：连续多次重试均被受理（在前置校验通过的前提下）。 - [ ] 幂等：相同 requestId 重复提交不产生重复效果。 - [ ] 每次重试留下可追溯的尝试记录，含所用规则哈希与失败原因。 - [ ] Agent 确认文案不再出现「创建一个新的采购任务」。 - [ ] 「重试采购」与 #132 的「继续采购」文案可区分。 - [ ] `AgentRetry` / `BatchRetry` 的既有行为未被改动，Admin 批量重试与 #132 的继续采购不受影响。 - [ ] 采集侧的重置行为未受影响。 ## 验证方式 - `go test ./app/goauto/purchase/... ./app/goauto/...` - `cd android && .\gradlew.bat :app:testDebugUnitTest :app:assembleDebug` - 覆盖用例：正常就地重试、规则更新后能力不匹配、跨不可逆边界被拒、幂等重放、连续多次重试。 - 真机 PKG110：构造一条因规则不适配而失败的采购任务 → 在 Admin 修正采购规则 → 在 Agent 点重试 → 确认使用新规则重跑且任务号不变。**真实下单前须取得人工授权；永久禁止支付。** - 真机、多设备与异常路径未覆盖部分如实回写。 ## 依赖、并行与风险 - 无强前置依赖。若 #127（采购规则落库）已完成，「当前生效规则」从数据库读取；未完成则沿用现有来源，实施时确认并说明。 - 与 #132 无代码冲突，但两者都会修改 `TaskHistoryFragment.kt` 的采购任务详情，不建议同时进行。 - 风险：更新规则快照会使任务上的规则版本与失败当时不同。缓解：attempt 的 `RuleSnapshotHash` 保留历次版本（事实 4）。 - 风险：不做失效校验时，商品已停用的任务重试仍会失败一次。此为已确认的取舍——以一次失败换取实现简化，采购员据错误信息判断是否回 Admin 重建。 - 回退：还原提交即可恢复「重试即新建任务」的既有行为，已创建任务不受影响。 ## 文档影响 - Wiki `Business-Rules-and-Glossary`：采购任务重试的语义（就地重跑、刷新规则、不限次数），以及与「继续采购」「批量重试」的区别。 - Wiki `Android-Agent-API-Contract`：新增就地重试接口。 - 按 Wiki-first 门禁：先改线上页面并回读 revision，再执行一轮 `sync` 与一轮 `sync --check`，把页面与 revision 写回本工单。 ## 状态 待实施。
ila commented 2026-08-29 16:52:57 +08:00
Author
Owner
Copy Link
Copy Source

实施完成，待验收

已按 #157 实施采购失败任务“就地重试”，提交并推送 main。

实现结果

  • 新增 Agent 接口：POST /api/agent/v1/purchase-tasks/{taskId}/reset。
  • 普通“重试采购”现在复用原 purchase_task.id，恢复为 pending，不创建新采购任务。
  • 重试事务只刷新：
    • RuleSnapshot
    • RuleType
    • RuleSchemaVersion
    • RequiredCapabilitiesJSON
  • 商品、SYB/蝦皮身份、Target、Mapped、数量、价格保护、地址后缀等业务快照不变。
  • 清除任务错误、租约、Claim 与运行守卫；重新校验原设备在线、空闲及新规则能力。
  • #127 仍为待实施，因此本次“当前规则”按工单约定读取服务端现有 DefaultLiveRule()，没有提前引入数据库表、迁移或第二事实源。
  • 每次受理预建同任务的新 pending attempt，记录规则哈希；正常 Start 复用该 attempt，不重复创建执行记录。
  • requestId 通过确定性 attempt ID 幂等；相同请求重放不重复修改任务或增加 attempt。
  • order_submit_started、order_created、order_result_unknown，以及存在不可逆时间、订单提交请求、PDD 订单号或下单时间的任务全部返回 PURCHASE_RETRY_UNSAFE，提示走“授权重新采购”。
  • 采购详情新增已执行尝试次数及上次失败错误；待执行 attempt 不计入“已尝试”。
  • Android 普通“重试采购”改调 /reset，成功页显示任务号不变和下一 attempt 序号。
  • #132 “继续采购”仍调用原 /retry，继续创建新任务；AgentRetry、BatchRetry 与 Admin 批量重试实现和语义均未改动。

设计证据

按工单既定门禁复用现有采购详情按钮、确认框、结果卡片和 48dp 按钮规范；未新增页面、组件或导航。文案已明确区分：

  • 重试采购：同一任务、刷新规则、任务号不变；
  • 继续采购：替代商品匹配后创建新任务。

自动化验证

  • go test ./app/goauto/purchase/...：通过。
  • go test ./...：通过。
  • .\scripts\verify.ps1 -Component server：Go 全量测试与 build 通过。
  • .\gradlew.bat :app:testDebugUnitTest :app:assembleDebug：通过，Debug APK 构建成功。
  • python dev_scripts/harness.py check --strict：通过。
  • python dev_scripts/harness.py sync：已执行一次。
  • python dev_scripts/harness.py sync --check：已执行一次并通过。
  • git diff --check / staged diff check：通过。

新增服务端测试覆盖：

  • 同任务重置、任务号不变、不新建任务；
  • 规则刷新及业务快照逐字段不变；
  • 能力不匹配拒绝且事务不产生部分修改；
  • 不可逆边界与跨设备拒绝；
  • 相同 requestId 幂等；
  • pending attempt 被 Start 复用；
  • 失败后连续再次就地重试；
  • 尝试次数与上次失败原因查询。

既有 AgentRetry、BatchRetry、替换后继续采购、采集重置相关回归随全量测试通过。

Wiki 与提交

  • Business-Rules-and-Glossary revision：1e9bf2da1957b31236921cbf572fa8a61d78e275
  • Android-Agent-API-Contract revision：cbbcc9accc4b1de3bd2b87cb816a204d7acf6e99
  • 提交：16948a9 feat(#157): retry purchase tasks in place
  • 已推送：origin/main

未验证边界

未执行真机 PKG110 的真实采购重跑：点击重试后 Agent 会正常领取任务并可能进入创建 PDD 待付款订单流程，工单与项目规则要求该步骤另行取得人工授权；本次未创建订单、未修改真实地址、未执行支付。

工单保持打开，等待用户验收或授权真机验证。

## 实施完成，待验收 已按 #157 实施采购失败任务“就地重试”，提交并推送 `main`。 ### 实现结果 - 新增 Agent 接口：`POST /api/agent/v1/purchase-tasks/{taskId}/reset`。 - 普通“重试采购”现在复用原 `purchase_task.id`，恢复为 `pending`，不创建新采购任务。 - 重试事务只刷新： - `RuleSnapshot` - `RuleType` - `RuleSchemaVersion` - `RequiredCapabilitiesJSON` - 商品、SYB/蝦皮身份、Target、Mapped、数量、价格保护、地址后缀等业务快照不变。 - 清除任务错误、租约、Claim 与运行守卫；重新校验原设备在线、空闲及新规则能力。 - #127 仍为待实施，因此本次“当前规则”按工单约定读取服务端现有 `DefaultLiveRule()`，没有提前引入数据库表、迁移或第二事实源。 - 每次受理预建同任务的新 `pending` attempt，记录规则哈希；正常 Start 复用该 attempt，不重复创建执行记录。 - `requestId` 通过确定性 attempt ID 幂等；相同请求重放不重复修改任务或增加 attempt。 - `order_submit_started`、`order_created`、`order_result_unknown`，以及存在不可逆时间、订单提交请求、PDD 订单号或下单时间的任务全部返回 `PURCHASE_RETRY_UNSAFE`，提示走“授权重新采购”。 - 采购详情新增已执行尝试次数及上次失败错误；待执行 attempt 不计入“已尝试”。 - Android 普通“重试采购”改调 `/reset`，成功页显示任务号不变和下一 attempt 序号。 - #132 “继续采购”仍调用原 `/retry`，继续创建新任务；`AgentRetry`、`BatchRetry` 与 Admin 批量重试实现和语义均未改动。 ### 设计证据 按工单既定门禁复用现有采购详情按钮、确认框、结果卡片和 48dp 按钮规范；未新增页面、组件或导航。文案已明确区分： - 重试采购：同一任务、刷新规则、任务号不变； - 继续采购：替代商品匹配后创建新任务。 ### 自动化验证 - `go test ./app/goauto/purchase/...`：通过。 - `go test ./...`：通过。 - `.\scripts\verify.ps1 -Component server`：Go 全量测试与 build 通过。 - `.\gradlew.bat :app:testDebugUnitTest :app:assembleDebug`：通过，Debug APK 构建成功。 - `python dev_scripts/harness.py check --strict`：通过。 - `python dev_scripts/harness.py sync`：已执行一次。 - `python dev_scripts/harness.py sync --check`：已执行一次并通过。 - `git diff --check` / staged diff check：通过。 新增服务端测试覆盖： - 同任务重置、任务号不变、不新建任务； - 规则刷新及业务快照逐字段不变； - 能力不匹配拒绝且事务不产生部分修改； - 不可逆边界与跨设备拒绝； - 相同 requestId 幂等； - pending attempt 被 Start 复用； - 失败后连续再次就地重试； - 尝试次数与上次失败原因查询。 既有 AgentRetry、BatchRetry、替换后继续采购、采集重置相关回归随全量测试通过。 ### Wiki 与提交 - `Business-Rules-and-Glossary` revision：`1e9bf2da1957b31236921cbf572fa8a61d78e275` - `Android-Agent-API-Contract` revision：`cbbcc9accc4b1de3bd2b87cb816a204d7acf6e99` - 提交：`16948a9 feat(#157): retry purchase tasks in place` - 已推送：`origin/main` ### 未验证边界 未执行真机 PKG110 的真实采购重跑：点击重试后 Agent 会正常领取任务并可能进入创建 PDD 待付款订单流程，工单与项目规则要求该步骤另行取得人工授权；本次未创建订单、未修改真实地址、未执行支付。 工单保持打开，等待用户验收或授权真机验证。
ila commented 2026-08-29 20:44:38 +08:00
Author
Owner
Copy Link
Copy Source

用户于 2026-08-29 明确确认本工单通过验收。验收结论已记录，现关闭工单。没有新的长期事实变化，本次不重复同步 Wiki。

用户于 2026-08-29 明确确认本工单通过验收。验收结论已记录，现关闭工单。没有新的长期事实变化，本次不重复同步 Wiki。
ila closed this issue 2026-08-29 20:44:39 +08:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin ila
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: OPC/goauto#157