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

SYB 商品页支持批量创建 PDD 采集任务（复用既有批量接口） #162

New Issue
Open
opened 2026-08-31 09:11:10 +08:00 by ila · 4 comments
ila commented 2026-08-31 09:11:10 +08:00
Owner
Copy Link
Copy Source

所属与来源

  • 关联工单：#161 PDD 商品详情关联与继续采购入口（同为减少跨页跳转的改进）、#84 修复 PDD 单商品定位模式无法勾选创建采集任务。
  • 来源：用户于 2026-08-31 反馈：「SYB 商品要采集 PDD 商品时不能批量采集，需要点击每行的『去采集』来采集。」
  • 类型：Admin 前端 / SYB 商品页批量创建采集任务。
  • 设计证据：调整既有表格的选择语义并新增第二个批量操作入口，复用 PDD 商品页既有的批量创建对话框交互与视觉规范；属现有页面的小范围扩展，提供标注截图或明确复用说明即可，不需要完整原型。设计证据经用户确认后方可编写生产代码。 需覆盖的状态：
    • 同时选中采购候选行与 PDD 待采集行；
    • 两个按钮各自的独立数量；
    • 「选中 M 行 / 去重后 N 个 PDD 商品」摘要；
    • 超过 100、无可采集行、部分失败的结果展示。
  • 工具回退说明：本工单通过 Gitea API 创建；当前会话未提供 Gitea MCP 工具，按 AGENTS.md「Gitea 交互与工单最小读取」记录回退原因。

当前事实（行号按提交 5d85625 复核，2026-08-31 修正）

  1. 服务端批量创建采集任务的能力已存在：server/app/goauto/task/router.go:33 注册 admin.POST("/batch", handler.AdminBatchCreate)，对应 task/admin_handler.go:63 → service.BatchCreate。
  2. PDD 商品页已完整支持批量：web/src/views/goauto/pdd-products/index.vue:14 的表格带 @selection-change，:34-42 为「批量创建采集任务」对话框，可选择采集规则与 Android 设备，并逐条展示结果（:37 明确「部分商品失败不会影响其他商品」）。
  3. （2026-08-31 更正）SYB 商品页已经具备多选与批量入口，缺的只是「批量创建采集任务」这一种动作。 原工单「页面无多选、无批量入口」的表述不成立，现按代码更正：
    • index.vue:17 已有 <el-table-column type="selection" :selectable="rowSelectable">；
    • :6 已有「已选择 N 条」计数，:14 已有「创建采购」批量按钮；
    • :33-49 为批量创建采购确认对话框，:52 为批量结果对话框。
    • 采集侧确为逐行跳转：:28 每行按处理阶段渲染 nextAction 按钮，:210 映射中 open_pdd 为「查看 PDD 商品」，需跳转到 PDD 商品详情后再采集。
  4. 既有多选被限制为「可创建采购」的行：:207 rowSelectable(row) { return this.canPurchase && this.purchaseReady(row).eligible }。pdd_pending 的行 eligible 必为 false，当前根本无法被勾选。
  5. 处理阶段数据来自采购域：processStage 由采购预检接口 previewPurchaseTasks 返回（purchase/batch.go:57-59，判定在 :101 的 processStageFromDataset），且仅在 canPurchase 为真时加载（index.vue:213）。
  6. :16 的表头提示当前写死为「表头全选只选择当前页中可以创建采购任务的商品」。
  7. 批量创建采集任务已有硬性上限 100：task/admin_service.go:144 校验 len(request.PDDProductIDs) > 100 即拒绝，同时 :147-153 已拒绝重复商品 ID。
  8. 预检项已返回 pddProductId（purchase/batch.go:40），前端可直接用它作为去重键，无需额外接口。
  9. SYB 商品页共有 10 种处理阶段（:145），其中 pdd_pending（PDD 待采集）、pdd_collection_failed（PDD 采集失败）、purchase_ready（可创建采购）在业务上天然可批量。
  10. 多个 SYB 订单行可能指向同一个虾皮商品，进而指向同一个 PDD 商品（models/schema.go:413-416：多个虾皮商品可共用同一个 PDD 商品）。
  11. 既有业务规则：同一 PDD 商品不能同时存在多个 pending 或 running 采集任务（AGENTS.md 第 1 节）。

问题

SYB 商品页以「订单行」为中心，每行处理阶段不同，因此做成了「逐行给出下一步动作」的形态——这一形态本身合理。但处于「PDD 待采集」阶段的行无法一起处理：页面已有的多选与批量入口只服务于采购（事实 3、4），采集仍只能逐行跳转。

新订单批量同步进来时，往往几十行同时停留在「PDD 待采集」，只能逐行点击跳转，操作成本与实际业务量不匹配。而批量能力在服务端与 PDD 商品页均已具备，缺的只是 SYB 商品页到该能力的入口。

目标

  1. SYB 商品页可勾选「PDD 待采集」的行并一次性批量创建采集任务——这需要先放开当前只允许勾选采购可用行的限制（事实 4）。
  2. 复用既有服务端批量接口与 PDD 商品页的批量交互，服务端零改动。
  3. 避免因多行指向同一 PDD 商品而产生无意义的失败。

非目标

  • 服务端不做任何改动：批量创建接口与其全部校验保持原样。
  • 本期采集侧只覆盖 pdd_pending 一种处理阶段；pdd_collection_failed（批量重新采集）不在本工单范围，待本期效果验证后再评估。
  • 关于 purchase_ready 的准确边界（原表述「不在范围」不准确）：本工单不新增或改变 purchase_ready 的采购业务能力；仅为支持混选，调整其前端候选过滤、独立计数、按钮启用状态与提交子集，并完成既有采购批量回归。
  • 不改变逐行 nextAction 的既有行为。
  • 不改变采集任务的创建逻辑、规则选择与设备分配语义。
  • 不新增页面与导航。

实施方案

  1. 重新定义表格的选择语义（本工单的核心改动，原第 1 项作废）：表格已有多选列，但 rowSelectable 当前只放行采购可用的行。需改为「一套选择集、两个批量动作、各自判定资格」：
    • rowSelectable 放宽到「采购可用 或 处于 pdd_pending」；
    • 工具栏并列「创建采购」与「批量创建采集任务」两个按钮，各自只按自己的资格计数并启用/禁用；
    • 选中行同时含两类时，两个按钮各自只作用于自己那部分，并在按钮旁明确显示将作用的条数（例如「批量创建采集任务（8）」），不得对不适用的行静默丢弃或报错。
    • 该「同一页面多种批量动作的选择语义」需与 #161 保持一致，实施前先确认规范。
    • 资格判定按动作分开，不再把采购 eligible 当成通用选择资格，实现等价于：
isPurchaseCandidate(row) {
  const ready = this.purchaseReady(row)
  return ready.processStage === 'purchase_ready' && ready.eligible
}

isCollectionCandidate(row) {
  const ready = this.purchaseReady(row)
  return ready.processStage === 'pdd_pending' &&
    Number.isInteger(ready.pddProductId) && ready.pddProductId > 0
}

rowSelectable(row) {
  return this.isPurchaseCandidate(row) || this.isCollectionCandidate(row)
}
  • 采购候选必须严格满足 ready.eligible === true && ready.processStage === 'purchase_ready'，比现有 rowSelectable 多了一层阶段判断。
  • 既有 E2E fixture 需要先补齐真实字段：web/tests/e2e/syb-network-retry.spec.ts:53（{ sybProductId: 73, eligible: true, minUnitPriceCent: 100, maxUnitPriceCent: 300 }）与 :98（{ sybProductId: 75, eligible: true }）都没有 processStage，严格判定下这些行将不可勾选、用例会失败。所有批量选择相关 fixture 至少补齐 processStage、processStageLabel、processStageReason 与本场景需要的 pddProductId，参照 syb-product-layout.spec.ts:13 的既有写法。
  • 不得为兼容不完整的测试数据而放宽生产判断。

  1. 两个批量动作只能提交各自的候选子集（阻塞级）：当前 openPurchaseBatch()（index.vue:260）直接把全部 selectedProducts 的 id 送去预检，submitPurchaseBatch()（:279）再原样提交 purchaseDialog.ids。放宽选择后必须改为只提交 isPurchaseCandidate 的行；采集动作只提取 isCollectionCandidate 行的 pddProductId。不得把不适用的行发到服务端后依赖逐项跳过。

  2. 同步修正 :16 的表头提示（事实 6）：现文案只描述采购，加入采集动作后即为错误说明，须一并改写为同时覆盖两种批量动作。

  3. 统一混选语义：允许混选、按动作分流、数量透明（取代早期「混选禁用」的表述，二者互相冲突，以本项为准）：

    • 按钮文案为 创建采购（N） 与 创建 PDD 采集（N），各自只按自己的候选数计数与启用；
    • 确认框明确显示「选中 M 条 SYB 明细，其中 N 条适用于当前动作」；
    • 不适用项不进入请求，也不静默丢弃——数量差异在界面上可见。
      本期采集侧只对 pdd_pending 开放。

  4. 按 PDD 商品去重：选中的多行可能指向同一个 PDD 商品（事实 10）。提交前必须按 PDD 商品去重，否则会撞上「同一商品不能同时存在多个 pending/running 采集任务」的既有约束（事实 11），产生大量看似失败实为重复提交的报错。去重结果需在确认对话框中体现（例如「已选择 12 行，去重后 8 个商品」）。去重键直接取预检项已返回的 pddProductId（事实 8）。服务端 :147-153 亦会拒绝重复 ID，前端去重只是避免无意义报错。

  5. 上限按去重后的 PDD 商品数判断，顺序不可颠倒：筛选 pdd_pending → 提取有效 pddProductId → 去重 → 判断是否超过 100 → 打开确认框/发送请求。不能按原始 SYB 行数判断。确认框展示「选中 M 行，去重后 N 个 PDD 商品」。

  6. 处理异步 readiness 与选择状态的时序；readiness 只禁用动作，不阻塞列表浏览：rowSelectable 依赖 loadPurchaseReadiness（index.vue:213）的异步结果，而该请求本就是列表加载后独立发起的，须保持「列表先展示、准备状态独立加载」的既有体验。

    • readiness 加载期间：SYB 列表继续可见、可滚动、可查看详情；复选框与两个批量按钮禁用并显示「正在检查」；
    • 不对整张表增加阻塞式 loading，不清空已加载列表；
    • readiness 返回后刷新 selectable 状态并校正已失效的选择，避免布局跳动；
    • readiness 失败时保持列表可用，仅禁用选择与批量动作，并沿用现有的刷新恢复路径（nextAction: 'refresh'）；
    • 查询、分页、阶段刷新与批量完成后均清空选择，避免提交旧选择。

  7. 调用既有的 POST /api/admin/v1/collection-tasks/batch 接口，不新写任何创建逻辑。

  8. 复用 PDD 商品页的批量对话框交互：优先复用而非复制第二套实现，可提取的最小共享部分为规则与设备加载、确认/结果对话框、batchCreateCollectionTasks 提交与逐条结果展示；页面各自保留候选集合计算与完成后的刷新方式，不抽象整个表格选择模型。若抽取成本超出本工单范围，允许各自实现并在工单记录原因。原有要求不变：选择采集规则、可选指定 Android 设备、逐条展示创建结果、部分失败不影响其他。视觉与文案与 PDD 商品页保持一致，不另设一套。

  9. 批量完成后刷新列表与处理阶段，使已创建任务的行更新为对应阶段。

  10. 服务端返回的失败原因原样展示，不在前端二次解释或改写。

  11. 确认并记录权限耦合（事实 5）：processStage 来自采购预检接口且仅在 canPurchase 时加载，因此按当前实现，批量采集入口实际被采购权限门控。本期接受该耦合并在工单与界面说明中写明「本入口对采购员开放」；不通过新增服务端接口解耦——若后续确需对非采购角色开放，另建工单，届时「服务端零改动」不再成立。

安全边界

  • 服务端既有校验全部保留：采集规则有效性、设备可用性、同商品并发任务限制、幂等请求 ID。
  • 前端去重仅为减少无意义请求，不得替代服务端校验。
  • 不新增权限点。创建动作沿用既有采集任务创建权限；但入口可见性受采购预检的 canPurchase 门控（事实 5、方案第 9 项），这是本期已知并接受的耦合，须在工单回写。
  • 不涉及采购、下单、地址与支付。

验收标准

  • pdd_pending 的行可以被勾选（放宽 rowSelectable 后），工具栏出现「批量创建采集任务」入口。
  • 「创建采购」的既有可选行范围与行为未被本次放宽破坏（回归验证）。
  • 允许混选：选中行同时含采购候选与 pdd_pending 行时，两个按钮各自显示正确数量，各自只作用于自己那部分，界面上可见数量差异，无静默丢弃。
  • 创建采购请求的 body 只含采购候选的 SYB ID；创建采集请求只含 pdd_pending 对应的去重后 PDD ID（以浏览器网络面板佐证）。
  • readiness 加载期间列表内容与详情入口仍可用，仅复选框与两个批量按钮不可用并显示「正在检查」；无整表阻塞 loading、列表不被清空。
  • readiness 失败时列表不被清空、不弹无恢复路径的阻塞错误，且不会提交任何批量请求。
  • 查询、分页、刷新、批量完成后选择被清空。
  • 所有批量选择相关 E2E fixture 已补齐完整阶段契约；在严格阶段判定下既有采购候选仍可勾选（回归通过）。
  • :16 表头提示已改写为同时覆盖两种批量动作，与实际行为一致。
  • 多行指向同一 PDD 商品时按 pddProductId 去重，确认对话框展示去重后的数量。
  • 上限按去重后的 PDD 商品数判断（非原始行数）；超过 100 时给出明确提示且不调用接口。
  • 批量创建走既有 POST /collection-tasks/batch（代码检查佐证未新增创建实现）。
  • 批量对话框的规则选择、设备选择与结果展示与 PDD 商品页一致。
  • 部分商品创建失败不影响其他商品，失败原因原样展示。
  • 批量完成后列表与处理阶段正确刷新。
  • 逐行 nextAction 的既有行为未发生变化。
  • 服务端未做任何改动（以 diff 佐证）。
  • 入口的采购权限耦合已在工单记录，界面说明与实际可见性一致。

验证方式

  • 前端构建与既有 Web 测试通过。
  • 必须进行浏览器行为验证（构建通过不足以证明多动作选择正确），至少覆盖：
    • purchase_ready 与 pdd_pending 的行均可勾选（fixture 已补齐 processStage 等字段）；
    • readiness 延迟期间列表可浏览、可看详情，但复选框与两个按钮不可用；
    • readiness 失败时列表保留、可经刷新恢复，且不发出任何批量请求；
    • 两个按钮分别显示正确的作用数量；
    • 创建采购请求只含采购候选 SYB ID；
    • 创建采集请求只含 pdd_pending 对应的去重后 PDD ID；
    • 多条 SYB 行指向同一 PDD 时只提交一次；
    • 去重后超过 100 时给出提示且不调用接口；
    • 部分失败原样展示服务端 message；
    • 完成后刷新阶段并清空选择；
    • 逐行 nextAction 行为保持不变。
  • 与从 PDD 商品页发起的批量创建对比，确认结果一致。
  • 不涉及服务端与 Agent，不需要真机验证；如实记录该结论。
  • 未覆盖的浏览器与异常路径如实回写。

依赖、并行与风险

  • 无前置依赖，服务端零改动。
  • 与 #161 修改文件不同（#161 改 PDD 商品详情，本工单改 SYB 商品列表），但两者都在扩大「多选 + 批量发起」的交互面。「同一页面多种批量动作的选择语义」应先统一再分别实施，否则两页会做出不一致的多选语义。
  • 风险：批量选中行数过多导致一次提交过大。缓解：服务端已硬限 100（task/admin_service.go:144），前端按该数字给出明确提示。
  • 风险（新增）：放宽 rowSelectable 会改变既有采购批量的可选行范围，可能让采购按钮收到不适用的行。缓解：方案第 1 项的按动作分别判定资格，并在验收中回归采购批量。
  • 风险：严格阶段判定会使缺少 processStage 的既有 E2E fixture 失败。缓解：实施第一步先补齐 fixture，再改生产判断；禁止反向放宽判定。
  • 风险：本期只覆盖一种阶段，用户可能期望其他阶段也可批量。缓解：非目标中已明确，待效果验证后再评估扩展。
  • 回退：还原提交即可，无数据影响。

文档影响

  • 预计无长期文档影响：不改变接口契约、数据结构、业务规则与权限边界，仅新增前端入口。实施完成后在工单记录该结论并跳过 Wiki 更新；若 Common-Changes 中记录了采集任务的创建路径，则一并补充该入口。

状态

待实施（界面需先取得设计证据）。

修订记录

  • 2026-08-31（三）：合并二次评审——采购候选使用完整预检契约并先补齐缺少 processStage 的既有 E2E fixture（syb-network-retry.spec.ts:53、:98）、readiness 加载只禁用动作而不阻塞列表浏览（修正上一版「加载期间禁止选择」的过头表述）、修正非目标中 purchase_ready 的边界表述；相应补充验收、浏览器验证项与风险。
  • 2026-08-31（二）：合并 2026-08-31 实施前评审意见——按动作分离资格判定、两个动作只提交各自子集、混选语义统一为「允许混选按动作分流」（推翻早期「混选禁用」表述）、上限按去重后 PDD 数判断、补充 readiness 与选择状态的时序处理、共享逻辑复用的边界，并新增浏览器行为验证清单与设计证据覆盖项。评审结论已并入正文，正文为唯一实施依据。
  • 2026-08-31：复核发现原「当前事实 3」不成立（页面已有多选与批量采购入口），据此更正事实 3-8、重写实施方案第 1-2 项、补充 rowSelectable 放宽与采购权限耦合的处理，并相应调整验收、风险与并行说明。
## 所属与来源 - 关联工单：#161 PDD 商品详情关联与继续采购入口（同为减少跨页跳转的改进）、#84 修复 PDD 单商品定位模式无法勾选创建采集任务。 - 来源：用户于 2026-08-31 反馈：「SYB 商品要采集 PDD 商品时不能批量采集，需要点击每行的『去采集』来采集。」 - 类型：Admin 前端 / SYB 商品页批量创建采集任务。 - 设计证据：调整既有表格的选择语义并新增第二个批量操作入口，复用 PDD 商品页既有的批量创建对话框交互与视觉规范；属现有页面的小范围扩展，提供标注截图或明确复用说明即可，不需要完整原型。**设计证据经用户确认后方可编写生产代码。** 需覆盖的状态： - 同时选中采购候选行与 PDD 待采集行； - 两个按钮各自的独立数量； - 「选中 M 行 / 去重后 N 个 PDD 商品」摘要； - 超过 100、无可采集行、部分失败的结果展示。 - 工具回退说明：本工单通过 Gitea API 创建；当前会话未提供 Gitea MCP 工具，按 `AGENTS.md`「Gitea 交互与工单最小读取」记录回退原因。 ## 当前事实（行号按提交 5d85625 复核，2026-08-31 修正） 1. **服务端批量创建采集任务的能力已存在**：`server/app/goauto/task/router.go:33` 注册 `admin.POST("/batch", handler.AdminBatchCreate)`，对应 `task/admin_handler.go:63` → `service.BatchCreate`。 2. **PDD 商品页已完整支持批量**：`web/src/views/goauto/pdd-products/index.vue:14` 的表格带 `@selection-change`，`:34-42` 为「批量创建采集任务」对话框，可选择采集规则与 Android 设备，并逐条展示结果（`:37` 明确「部分商品失败不会影响其他商品」）。 3. **（2026-08-31 更正）SYB 商品页已经具备多选与批量入口，缺的只是「批量创建采集任务」这一种动作。** 原工单「页面无多选、无批量入口」的表述不成立，现按代码更正： - `index.vue:17` 已有 `<el-table-column type="selection" :selectable="rowSelectable">`； - `:6` 已有「已选择 N 条」计数，`:14` 已有「创建采购」批量按钮； - `:33-49` 为批量创建采购确认对话框，`:52` 为批量结果对话框。 - 采集侧确为逐行跳转：`:28` 每行按处理阶段渲染 `nextAction` 按钮，`:210` 映射中 `open_pdd` 为「查看 PDD 商品」，需跳转到 PDD 商品详情后再采集。 4. **既有多选被限制为「可创建采购」的行**：`:207` `rowSelectable(row) { return this.canPurchase && this.purchaseReady(row).eligible }`。`pdd_pending` 的行 `eligible` 必为 false，**当前根本无法被勾选**。 5. **处理阶段数据来自采购域**：`processStage` 由采购预检接口 `previewPurchaseTasks` 返回（`purchase/batch.go:57-59`，判定在 `:101` 的 `processStageFromDataset`），且仅在 `canPurchase` 为真时加载（`index.vue:213`）。 6. `:16` 的表头提示当前写死为「表头全选只选择当前页中可以创建采购任务的商品」。 7. **批量创建采集任务已有硬性上限 100**：`task/admin_service.go:144` 校验 `len(request.PDDProductIDs) > 100` 即拒绝，同时 `:147-153` 已拒绝重复商品 ID。 8. **预检项已返回 `pddProductId`**（`purchase/batch.go:40`），前端可直接用它作为去重键，无需额外接口。 9. SYB 商品页共有 10 种处理阶段（`:145`），其中 `pdd_pending`（PDD 待采集）、`pdd_collection_failed`（PDD 采集失败）、`purchase_ready`（可创建采购）在业务上天然可批量。 10. 多个 SYB 订单行可能指向同一个虾皮商品，进而指向**同一个 PDD 商品**（`models/schema.go:413-416`：多个虾皮商品可共用同一个 PDD 商品）。 11. 既有业务规则：同一 PDD 商品不能同时存在多个 `pending` 或 `running` 采集任务（`AGENTS.md` 第 1 节）。 ## 问题 SYB 商品页以「订单行」为中心，每行处理阶段不同，因此做成了「逐行给出下一步动作」的形态——这一形态本身合理。但**处于「PDD 待采集」阶段的行无法一起处理**：页面已有的多选与批量入口只服务于采购（事实 3、4），采集仍只能逐行跳转。 新订单批量同步进来时，往往几十行同时停留在「PDD 待采集」，只能逐行点击跳转，操作成本与实际业务量不匹配。而批量能力在服务端与 PDD 商品页均已具备，缺的只是 SYB 商品页到该能力的入口。 ## 目标 1. SYB 商品页可勾选「PDD 待采集」的行并一次性批量创建采集任务——**这需要先放开当前只允许勾选采购可用行的限制**（事实 4）。 2. 复用既有服务端批量接口与 PDD 商品页的批量交互，服务端零改动。 3. 避免因多行指向同一 PDD 商品而产生无意义的失败。 ## 非目标 - **服务端不做任何改动**：批量创建接口与其全部校验保持原样。 - **本期采集侧只覆盖 `pdd_pending` 一种处理阶段**；`pdd_collection_failed`（批量重新采集）不在本工单范围，待本期效果验证后再评估。 - 关于 `purchase_ready` 的准确边界（原表述「不在范围」不准确）：**本工单不新增或改变 `purchase_ready` 的采购业务能力**；仅为支持混选，调整其前端候选过滤、独立计数、按钮启用状态与提交子集，并完成既有采购批量回归。 - 不改变逐行 `nextAction` 的既有行为。 - 不改变采集任务的创建逻辑、规则选择与设备分配语义。 - 不新增页面与导航。 ## 实施方案 1. **重新定义表格的选择语义（本工单的核心改动，原第 1 项作废）**：表格已有多选列，但 `rowSelectable` 当前只放行采购可用的行。需改为「一套选择集、两个批量动作、各自判定资格」： - `rowSelectable` 放宽到「采购可用 **或** 处于 `pdd_pending`」； - 工具栏并列「创建采购」与「批量创建采集任务」两个按钮，各自只按自己的资格计数并启用/禁用； - 选中行同时含两类时，两个按钮各自只作用于自己那部分，并在按钮旁明确显示将作用的条数（例如「批量创建采集任务（8）」），不得对不适用的行静默丢弃或报错。 - 该「同一页面多种批量动作的选择语义」需与 #161 保持一致，实施前先确认规范。 - 资格判定**按动作分开**，不再把采购 `eligible` 当成通用选择资格，实现等价于： ```js isPurchaseCandidate(row) { const ready = this.purchaseReady(row) return ready.processStage === 'purchase_ready' && ready.eligible } isCollectionCandidate(row) { const ready = this.purchaseReady(row) return ready.processStage === 'pdd_pending' && Number.isInteger(ready.pddProductId) && ready.pddProductId > 0 } rowSelectable(row) { return this.isPurchaseCandidate(row) || this.isCollectionCandidate(row) } ``` - 采购候选必须**严格**满足 `ready.eligible === true && ready.processStage === 'purchase_ready'`，比现有 `rowSelectable` 多了一层阶段判断。 - **既有 E2E fixture 需要先补齐真实字段**：`web/tests/e2e/syb-network-retry.spec.ts:53`（`{ sybProductId: 73, eligible: true, minUnitPriceCent: 100, maxUnitPriceCent: 300 }`）与 `:98`（`{ sybProductId: 75, eligible: true }`）都**没有 `processStage`**，严格判定下这些行将不可勾选、用例会失败。所有批量选择相关 fixture 至少补齐 `processStage`、`processStageLabel`、`processStageReason` 与本场景需要的 `pddProductId`，参照 `syb-product-layout.spec.ts:13` 的既有写法。 - **不得为兼容不完整的测试数据而放宽生产判断。** 2. **两个批量动作只能提交各自的候选子集（阻塞级）**：当前 `openPurchaseBatch()`（`index.vue:260`）直接把全部 `selectedProducts` 的 id 送去预检，`submitPurchaseBatch()`（`:279`）再原样提交 `purchaseDialog.ids`。放宽选择后必须改为**只提交 `isPurchaseCandidate` 的行**；采集动作只提取 `isCollectionCandidate` 行的 `pddProductId`。**不得把不适用的行发到服务端后依赖逐项跳过。** 3. **同步修正 `:16` 的表头提示**（事实 6）：现文案只描述采购，加入采集动作后即为错误说明，须一并改写为同时覆盖两种批量动作。 4. **统一混选语义：允许混选、按动作分流、数量透明**（取代早期「混选禁用」的表述，二者互相冲突，以本项为准）： - 按钮文案为 `创建采购（N）` 与 `创建 PDD 采集（N）`，各自只按自己的候选数计数与启用； - 确认框明确显示「选中 M 条 SYB 明细，其中 N 条适用于当前动作」； - 不适用项不进入请求，也不静默丢弃——数量差异在界面上可见。 本期采集侧只对 `pdd_pending` 开放。 5. **按 PDD 商品去重**：选中的多行可能指向同一个 PDD 商品（事实 10）。提交前必须按 PDD 商品去重，否则会撞上「同一商品不能同时存在多个 pending/running 采集任务」的既有约束（事实 11），产生大量看似失败实为重复提交的报错。去重结果需在确认对话框中体现（例如「已选择 12 行，去重后 8 个商品」）。去重键直接取预检项已返回的 `pddProductId`（事实 8）。服务端 `:147-153` 亦会拒绝重复 ID，前端去重只是避免无意义报错。 6. **上限按去重后的 PDD 商品数判断，顺序不可颠倒**：筛选 `pdd_pending` → 提取有效 `pddProductId` → 去重 → 判断是否超过 100 → 打开确认框/发送请求。**不能按原始 SYB 行数判断**。确认框展示「选中 M 行，去重后 N 个 PDD 商品」。 7. **处理异步 readiness 与选择状态的时序；readiness 只禁用动作，不阻塞列表浏览**：`rowSelectable` 依赖 `loadPurchaseReadiness`（`index.vue:213`）的异步结果，而该请求本就是列表加载后独立发起的，须保持「列表先展示、准备状态独立加载」的既有体验。 - readiness 加载期间：SYB 列表**继续可见、可滚动、可查看详情**；复选框与两个批量按钮禁用并显示「正在检查」； - **不对整张表增加阻塞式 loading，不清空已加载列表**； - readiness 返回后刷新 selectable 状态并校正已失效的选择，避免布局跳动； - readiness **失败**时保持列表可用，仅禁用选择与批量动作，并沿用现有的刷新恢复路径（`nextAction: 'refresh'`）； - 查询、分页、阶段刷新与批量完成后均清空选择，避免提交旧选择。 8. 调用**既有的** `POST /api/admin/v1/collection-tasks/batch` 接口，不新写任何创建逻辑。 9. **复用 PDD 商品页的批量对话框交互**：优先复用而非复制第二套实现，可提取的最小共享部分为规则与设备加载、确认/结果对话框、`batchCreateCollectionTasks` 提交与逐条结果展示；页面各自保留候选集合计算与完成后的刷新方式，**不抽象整个表格选择模型**。若抽取成本超出本工单范围，允许各自实现并在工单记录原因。原有要求不变：选择采集规则、可选指定 Android 设备、逐条展示创建结果、部分失败不影响其他。视觉与文案与 PDD 商品页保持一致，不另设一套。 10. 批量完成后刷新列表与处理阶段，使已创建任务的行更新为对应阶段。 11. 服务端返回的失败原因原样展示，不在前端二次解释或改写。 12. **确认并记录权限耦合**（事实 5）：`processStage` 来自采购预检接口且仅在 `canPurchase` 时加载，因此按当前实现，批量采集入口实际被采购权限门控。本期**接受该耦合**并在工单与界面说明中写明「本入口对采购员开放」；不通过新增服务端接口解耦——若后续确需对非采购角色开放，另建工单，届时「服务端零改动」不再成立。 ## 安全边界 - 服务端既有校验全部保留：采集规则有效性、设备可用性、同商品并发任务限制、幂等请求 ID。 - 前端去重仅为减少无意义请求，**不得替代服务端校验**。 - 不新增权限点。创建动作沿用既有采集任务创建权限；但入口可见性受采购预检的 `canPurchase` 门控（事实 5、方案第 9 项），这是本期已知并接受的耦合，须在工单回写。 - 不涉及采购、下单、地址与支付。 ## 验收标准 - [ ] `pdd_pending` 的行可以被勾选（放宽 `rowSelectable` 后），工具栏出现「批量创建采集任务」入口。 - [ ] 「创建采购」的既有可选行范围与行为未被本次放宽破坏（回归验证）。 - [ ] 允许混选：选中行同时含采购候选与 `pdd_pending` 行时，两个按钮各自显示正确数量，各自只作用于自己那部分，界面上可见数量差异，无静默丢弃。 - [ ] 创建采购请求的 body 只含采购候选的 SYB ID；创建采集请求只含 `pdd_pending` 对应的去重后 PDD ID（以浏览器网络面板佐证）。 - [ ] readiness 加载期间列表内容与详情入口仍可用，仅复选框与两个批量按钮不可用并显示「正在检查」；无整表阻塞 loading、列表不被清空。 - [ ] readiness 失败时列表不被清空、不弹无恢复路径的阻塞错误，且不会提交任何批量请求。 - [ ] 查询、分页、刷新、批量完成后选择被清空。 - [ ] 所有批量选择相关 E2E fixture 已补齐完整阶段契约；在严格阶段判定下既有采购候选仍可勾选（回归通过）。 - [ ] `:16` 表头提示已改写为同时覆盖两种批量动作，与实际行为一致。 - [ ] 多行指向同一 PDD 商品时按 `pddProductId` 去重，确认对话框展示去重后的数量。 - [ ] 上限按**去重后的 PDD 商品数**判断（非原始行数）；超过 100 时给出明确提示且不调用接口。 - [ ] 批量创建走既有 `POST /collection-tasks/batch`（代码检查佐证未新增创建实现）。 - [ ] 批量对话框的规则选择、设备选择与结果展示与 PDD 商品页一致。 - [ ] 部分商品创建失败不影响其他商品，失败原因原样展示。 - [ ] 批量完成后列表与处理阶段正确刷新。 - [ ] 逐行 `nextAction` 的既有行为未发生变化。 - [ ] 服务端未做任何改动（以 diff 佐证）。 - [ ] 入口的采购权限耦合已在工单记录，界面说明与实际可见性一致。 ## 验证方式 - 前端构建与既有 Web 测试通过。 - **必须进行浏览器行为验证（构建通过不足以证明多动作选择正确）**，至少覆盖： - `purchase_ready` 与 `pdd_pending` 的行均可勾选（fixture 已补齐 `processStage` 等字段）； - readiness 延迟期间列表可浏览、可看详情，但复选框与两个按钮不可用； - readiness 失败时列表保留、可经刷新恢复，且不发出任何批量请求； - 两个按钮分别显示正确的作用数量； - 创建采购请求只含采购候选 SYB ID； - 创建采集请求只含 `pdd_pending` 对应的去重后 PDD ID； - 多条 SYB 行指向同一 PDD 时只提交一次； - 去重后超过 100 时给出提示且不调用接口； - 部分失败原样展示服务端 message； - 完成后刷新阶段并清空选择； - 逐行 `nextAction` 行为保持不变。 - 与从 PDD 商品页发起的批量创建对比，确认结果一致。 - 不涉及服务端与 Agent，不需要真机验证；如实记录该结论。 - 未覆盖的浏览器与异常路径如实回写。 ## 依赖、并行与风险 - 无前置依赖，服务端零改动。 - 与 #161 修改文件不同（#161 改 PDD 商品详情，本工单改 SYB 商品列表），但两者都在扩大「多选 + 批量发起」的交互面。**「同一页面多种批量动作的选择语义」应先统一再分别实施**，否则两页会做出不一致的多选语义。 - 风险：批量选中行数过多导致一次提交过大。缓解：服务端已硬限 100（`task/admin_service.go:144`），前端按该数字给出明确提示。 - **风险（新增）：放宽 `rowSelectable` 会改变既有采购批量的可选行范围**，可能让采购按钮收到不适用的行。缓解：方案第 1 项的按动作分别判定资格，并在验收中回归采购批量。 - **风险：严格阶段判定会使缺少 `processStage` 的既有 E2E fixture 失败**。缓解：实施第一步先补齐 fixture，再改生产判断；禁止反向放宽判定。 - 风险：本期只覆盖一种阶段，用户可能期望其他阶段也可批量。缓解：非目标中已明确，待效果验证后再评估扩展。 - 回退：还原提交即可，无数据影响。 ## 文档影响 - 预计无长期文档影响：不改变接口契约、数据结构、业务规则与权限边界，仅新增前端入口。实施完成后在工单记录该结论并跳过 Wiki 更新；若 `Common-Changes` 中记录了采集任务的创建路径，则一并补充该入口。 ## 状态 待实施（界面需先取得设计证据）。 ## 修订记录 - 2026-08-31（三）：合并二次评审——采购候选使用完整预检契约并先补齐缺少 `processStage` 的既有 E2E fixture（`syb-network-retry.spec.ts:53`、`:98`）、readiness 加载只禁用动作而不阻塞列表浏览（修正上一版「加载期间禁止选择」的过头表述）、修正非目标中 `purchase_ready` 的边界表述；相应补充验收、浏览器验证项与风险。 - 2026-08-31（二）：合并 2026-08-31 实施前评审意见——按动作分离资格判定、两个动作只提交各自子集、混选语义统一为「允许混选按动作分流」（推翻早期「混选禁用」表述）、上限按去重后 PDD 数判断、补充 readiness 与选择状态的时序处理、共享逻辑复用的边界，并新增浏览器行为验证清单与设计证据覆盖项。评审结论已并入正文，正文为唯一实施依据。 - 2026-08-31：复核发现原「当前事实 3」不成立（页面已有多选与批量采购入口），据此更正事实 3-8、重写实施方案第 1-2 项、补充 `rowSelectable` 放宽与采购权限耦合的处理，并相应调整验收、风险与并行说明。
ila commented 2026-08-31 09:29:11 +08:00
Author
Owner
Copy Link
Copy Source

2026-08-31 实施前评审补充

结论：修订后的根因和“服务端零改动”范围合理；实施前需统一混选语义并补齐浏览器行为验证。

必须纳入实施方案

  1. 资格判定按动作分开，不再把采购 eligible 当成通用选择资格。 建议实现等价于：
isPurchaseCandidate(row) {
  const ready = this.purchaseReady(row)
  return ready.processStage === 'purchase_ready' && ready.eligible
}

isCollectionCandidate(row) {
  const ready = this.purchaseReady(row)
  return ready.processStage === 'pdd_pending' &&
    Number.isInteger(ready.pddProductId) && ready.pddProductId > 0
}

rowSelectable(row) {
  return this.isPurchaseCandidate(row) || this.isCollectionCandidate(row)
}

  1. 两个批量动作只能提交各自候选子集。 当前 openPurchaseBatch() 直接提交全部 selectedProducts；放宽选择后必须改为只提交 isPurchaseCandidate 行。采集动作只提取 isCollectionCandidate 行的 pddProductId。不得把不适用行发到服务端后依赖逐项跳过。

  2. 统一混选语义：允许混选，按动作分流，数量透明。 删除/修正现有“混选被禁用”表述，因为它与“两个按钮各自只作用于自己的子集”冲突。建议按钮：

    • 创建采购（N）
    • 创建 PDD 采集（N）
      确认框明确显示“选中 M 条 SYB 明细，其中 N 条适用于当前动作”。不适用项不进入请求。

  3. 采集上限按去重后的 PDD 商品数判断。 顺序必须为：筛选 pdd_pending → 提取有效 pddProductId → 去重 → 判断是否超过 100 → 打开确认/发送请求。不能按原始 SYB 行数判断。确认框展示“选中 M 行，去重后 N 个 PDD 商品”。

  4. 处理异步 readiness 的选择状态。 loadPurchaseReadiness 完成后需要清除或校正已失效选择，并确保表格 selectable 状态刷新；readiness 加载期间禁止选择。查询、分页、阶段刷新和批量完成后均清空选择，避免旧选择提交。

  5. 复用批量采集对话框逻辑，避免复制第二套实现。 可提取最小共享组件/逻辑：规则与设备加载、确认/结果对话框、batchCreateCollectionTasks 提交、逐条结果展示。页面各自保留候选集合计算和完成后的刷新方式；不抽象整个表格选择模型。

必须增加浏览器行为验证

现有构建不足以证明多动作选择正确。至少覆盖：

  • purchase_ready 与 pdd_pending 均可选择；
  • 两个按钮分别显示正确作用数量；
  • 创建采购请求只含采购候选 SYB ID；
  • 创建采集请求只含 pdd_pending 对应的去重 PDD ID；
  • 多条 SYB 行指向同一 PDD 时只提交一次；
  • 去重后超过 100 时给出明确提示且不调用接口；
  • 部分失败原样展示服务端 message；
  • 完成后刷新阶段并清空选择；
  • 逐行 nextAction 行为保持不变。

设计证据需覆盖

  • 同时选中采购行与 PDD 待采集行；
  • 两个按钮的独立数量；
  • “选中行数 / 去重后 PDD 数量”摘要；
  • 超过 100、无可采集行、部分失败结果。

建议先实施本工单验证统一选择语义，再实施 #161。

## 2026-08-31 实施前评审补充 结论：修订后的根因和“服务端零改动”范围合理；实施前需统一混选语义并补齐浏览器行为验证。 ### 必须纳入实施方案 1. **资格判定按动作分开，不再把采购 `eligible` 当成通用选择资格。** 建议实现等价于： ```js isPurchaseCandidate(row) { const ready = this.purchaseReady(row) return ready.processStage === 'purchase_ready' && ready.eligible } isCollectionCandidate(row) { const ready = this.purchaseReady(row) return ready.processStage === 'pdd_pending' && Number.isInteger(ready.pddProductId) && ready.pddProductId > 0 } rowSelectable(row) { return this.isPurchaseCandidate(row) || this.isCollectionCandidate(row) } ``` 2. **两个批量动作只能提交各自候选子集。** 当前 `openPurchaseBatch()` 直接提交全部 `selectedProducts`；放宽选择后必须改为只提交 `isPurchaseCandidate` 行。采集动作只提取 `isCollectionCandidate` 行的 `pddProductId`。不得把不适用行发到服务端后依赖逐项跳过。 3. **统一混选语义：允许混选，按动作分流，数量透明。** 删除/修正现有“混选被禁用”表述，因为它与“两个按钮各自只作用于自己的子集”冲突。建议按钮： - `创建采购（N）` - `创建 PDD 采集（N）` 确认框明确显示“选中 M 条 SYB 明细，其中 N 条适用于当前动作”。不适用项不进入请求。 4. **采集上限按去重后的 PDD 商品数判断。** 顺序必须为：筛选 `pdd_pending` → 提取有效 `pddProductId` → 去重 → 判断是否超过 100 → 打开确认/发送请求。不能按原始 SYB 行数判断。确认框展示“选中 M 行，去重后 N 个 PDD 商品”。 5. **处理异步 readiness 的选择状态。** `loadPurchaseReadiness` 完成后需要清除或校正已失效选择，并确保表格 selectable 状态刷新；readiness 加载期间禁止选择。查询、分页、阶段刷新和批量完成后均清空选择，避免旧选择提交。 6. **复用批量采集对话框逻辑，避免复制第二套实现。** 可提取最小共享组件/逻辑：规则与设备加载、确认/结果对话框、`batchCreateCollectionTasks` 提交、逐条结果展示。页面各自保留候选集合计算和完成后的刷新方式；不抽象整个表格选择模型。 ### 必须增加浏览器行为验证 现有构建不足以证明多动作选择正确。至少覆盖： - `purchase_ready` 与 `pdd_pending` 均可选择； - 两个按钮分别显示正确作用数量； - 创建采购请求只含采购候选 SYB ID； - 创建采集请求只含 `pdd_pending` 对应的去重 PDD ID； - 多条 SYB 行指向同一 PDD 时只提交一次； - 去重后超过 100 时给出明确提示且不调用接口； - 部分失败原样展示服务端 message； - 完成后刷新阶段并清空选择； - 逐行 `nextAction` 行为保持不变。 ### 设计证据需覆盖 - 同时选中采购行与 PDD 待采集行； - 两个按钮的独立数量； - “选中行数 / 去重后 PDD 数量”摘要； - 超过 100、无可采集行、部分失败结果。 建议先实施本工单验证统一选择语义，再实施 #161。
ila commented 2026-08-31 09:41:03 +08:00
Author
Owner
Copy Link
Copy Source

2026-08-31 二次评审补充（实施前需并入正文）

现有方案已可实施；补充以下防歧义约束：

1. 生产资格判断使用完整预检契约

采购候选必须严格满足：

ready.eligible === true && ready.processStage === 'purchase_ready'

浏览器测试和 mock fixture 必须补齐真实 API 字段，至少包括 processStage、processStageLabel、processStageReason 与本场景需要的 pddProductId。现有仅返回 eligible: true 的 fixture 需要更新。不得为兼容不完整测试数据而放宽生产判断。

2. readiness 加载只禁用动作，不阻塞列表浏览

保持现有“列表先展示、准备状态独立加载”的体验：

  • SYB 列表继续可见、可滚动、可查看详情；
  • readiness 加载期间复选框和两个批量按钮禁用，并显示“正在检查”；
  • 不对整张表增加阻塞式 loading，不清空已加载列表；
  • readiness 返回后刷新 selectable 状态并校正选择，避免布局跳动；
  • readiness 失败时保持列表可用，选择和批量动作禁用，并提供现有刷新恢复路径。

3. 修正非目标中 purchase_ready 的表述

purchase_ready 并非完全不在范围。准确边界为：

本工单不新增或改变 purchase_ready 的采购业务能力；仅为支持混选，调整其前端候选过滤、独立计数、按钮启用状态和提交子集，并完成既有采购批量回归。

补充验收

  • 所有批量选择 E2E fixture 使用完整阶段契约；严格阶段判断下既有采购候选仍可选；
  • readiness 延迟期间列表内容与详情入口可用，但复选框及两个批量按钮不可用；
  • readiness 失败不清空列表、不弹无恢复路径的阻塞错误，并且不会提交任何批量请求。
## 2026-08-31 二次评审补充（实施前需并入正文） 现有方案已可实施；补充以下防歧义约束： ### 1. 生产资格判断使用完整预检契约 采购候选必须严格满足： ```js ready.eligible === true && ready.processStage === 'purchase_ready' ``` 浏览器测试和 mock fixture 必须补齐真实 API 字段，至少包括 `processStage`、`processStageLabel`、`processStageReason` 与本场景需要的 `pddProductId`。现有仅返回 `eligible: true` 的 fixture 需要更新。不得为兼容不完整测试数据而放宽生产判断。 ### 2. readiness 加载只禁用动作，不阻塞列表浏览 保持现有“列表先展示、准备状态独立加载”的体验： - SYB 列表继续可见、可滚动、可查看详情； - readiness 加载期间复选框和两个批量按钮禁用，并显示“正在检查”； - 不对整张表增加阻塞式 loading，不清空已加载列表； - readiness 返回后刷新 selectable 状态并校正选择，避免布局跳动； - readiness 失败时保持列表可用，选择和批量动作禁用，并提供现有刷新恢复路径。 ### 3. 修正非目标中 purchase_ready 的表述 `purchase_ready` 并非完全不在范围。准确边界为： > 本工单不新增或改变 `purchase_ready` 的采购业务能力；仅为支持混选，调整其前端候选过滤、独立计数、按钮启用状态和提交子集，并完成既有采购批量回归。 ### 补充验收 - 所有批量选择 E2E fixture 使用完整阶段契约；严格阶段判断下既有采购候选仍可选； - readiness 延迟期间列表内容与详情入口可用，但复选框及两个批量按钮不可用； - readiness 失败不清空列表、不弹无恢复路径的阻塞错误，并且不会提交任何批量请求。
ila commented 2026-08-31 10:30:23 +08:00
Author
Owner
Copy Link
Copy Source

实施完成，待验收

设计证据：2026-08-31 用户确认本工单低保真交互。采用一套选择集、采购与采集按动作分流、按钮独立计数；采集确认框展示 SYB 行数与去重后的 PDD 商品数。

实现：

  • SYB 商品页支持同时选择 purchase_ready 与 pdd_pending；资格严格按完整 processStage 契约判断。
  • 创建采购（N） 只提交采购候选 SYB ID；创建 PDD 采集（N） 只提交 pdd_pending 对应的去重 PDD ID。
  • 采集批量复用现有 /api/admin/v1/collection-tasks/batch、采集规则、设备选择和逐项结果结构；失败原因原样展示。
  • readiness 加载期间列表和详情保持可用，选择与批量按钮禁用；失败保留列表并提供刷新动作；查询和批量完成清空选择。
  • 服务端和 Android Agent 均未改动。入口继续受采购预检/采购员权限门控，符合工单接受的权限耦合。

验证：

  • pnpm build:prod：通过。构建仍输出仓库既有 CSS 伪类和 chunk-size 警告，无构建错误。
  • pnpm exec eslint src/views/goauto/syb-products/index.vue：通过。
  • PLAYWRIGHT_TEST_BASE_URL=http://localhost:9530 PLAYWRIGHT_DISABLE_VIDEO=1 pnpm exec playwright test tests/e2e/syb-product-layout.spec.ts tests/e2e/syb-network-retry.spec.ts：11/11 通过。覆盖混选、动作子集、PDD 去重、部分失败原文、readiness 延迟/失败、旧预检不覆盖新查询及逐行下一步回归。
  • 未执行真机验证：本工单不改变 Agent 接口、任务契约或设备执行行为。

文档影响：无长期文档影响。未改变 API、数据结构、业务规则或权限边界，仅新增现有管理端能力入口，因此跳过 Wiki 更新与同步。

提交：4e05048，已推送 origin/main。

状态：待用户验收。

## 实施完成，待验收 设计证据：2026-08-31 用户确认本工单低保真交互。采用一套选择集、采购与采集按动作分流、按钮独立计数；采集确认框展示 SYB 行数与去重后的 PDD 商品数。 实现： - SYB 商品页支持同时选择 `purchase_ready` 与 `pdd_pending`；资格严格按完整 `processStage` 契约判断。 - `创建采购（N）` 只提交采购候选 SYB ID；`创建 PDD 采集（N）` 只提交 `pdd_pending` 对应的去重 PDD ID。 - 采集批量复用现有 `/api/admin/v1/collection-tasks/batch`、采集规则、设备选择和逐项结果结构；失败原因原样展示。 - readiness 加载期间列表和详情保持可用，选择与批量按钮禁用；失败保留列表并提供刷新动作；查询和批量完成清空选择。 - 服务端和 Android Agent 均未改动。入口继续受采购预检/采购员权限门控，符合工单接受的权限耦合。 验证： - `pnpm build:prod`：通过。构建仍输出仓库既有 CSS 伪类和 chunk-size 警告，无构建错误。 - `pnpm exec eslint src/views/goauto/syb-products/index.vue`：通过。 - `PLAYWRIGHT_TEST_BASE_URL=http://localhost:9530 PLAYWRIGHT_DISABLE_VIDEO=1 pnpm exec playwright test tests/e2e/syb-product-layout.spec.ts tests/e2e/syb-network-retry.spec.ts`：11/11 通过。覆盖混选、动作子集、PDD 去重、部分失败原文、readiness 延迟/失败、旧预检不覆盖新查询及逐行下一步回归。 - 未执行真机验证：本工单不改变 Agent 接口、任务契约或设备执行行为。 文档影响：无长期文档影响。未改变 API、数据结构、业务规则或权限边界，仅新增现有管理端能力入口，因此跳过 Wiki 更新与同步。 提交：`4e05048`，已推送 `origin/main`。 状态：待用户验收。
ila commented 2026-08-31 10:50:06 +08:00
Author
Owner
Copy Link
Copy Source

Claude Code 评审闭环

评审结论合理，已接受并补齐测试证据；生产代码无需修改。

补充内容：

  • readiness 失败场景显式断言 SYB 商品列表仍保留。
  • 补齐虾皮商品动态路由 fixture，恢复「去关联」后 PDD 商品选择器成功加载的行为断言。
  • 新增去重后 101 个 PDD 商品的边界场景：提示最多 100 个、不打开确认框、不调用批量接口。

验证：

  • PLAYWRIGHT_TEST_BASE_URL=http://localhost:9530 PLAYWRIGHT_DISABLE_VIDEO=1 pnpm exec playwright test tests/e2e/syb-product-layout.spec.ts tests/e2e/syb-network-retry.spec.ts
  • 结果：12/12 通过。

提交：5270390，已推送 origin/main。

#162 继续保持待用户验收；未关闭工单。

## Claude Code 评审闭环 评审结论合理，已接受并补齐测试证据；生产代码无需修改。 补充内容： - readiness 失败场景显式断言 SYB 商品列表仍保留。 - 补齐虾皮商品动态路由 fixture，恢复「去关联」后 PDD 商品选择器成功加载的行为断言。 - 新增去重后 101 个 PDD 商品的边界场景：提示最多 100 个、不打开确认框、不调用批量接口。 验证： - `PLAYWRIGHT_TEST_BASE_URL=http://localhost:9530 PLAYWRIGHT_DISABLE_VIDEO=1 pnpm exec playwright test tests/e2e/syb-product-layout.spec.ts tests/e2e/syb-network-retry.spec.ts` - 结果：12/12 通过。 提交：`5270390`，已推送 `origin/main`。 #162 继续保持待用户验收；未关闭工单。
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#162