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

功能：管理员批量软删除采购任务（高风险，需二次确认） #178

New Issue
Open
opened 2026-08-31 17:54:04 +08:00 by ila · 0 comments
ila commented 2026-08-31 17:54:04 +08:00
Owner
Copy Link
Copy Source

Gitea MCP 未向当前会话暴露，按仓库规则回退项目根目录安全配置与 Gitea API 维护本工单；凭据未写入工单、代码或日志。

2026-09-02 补充核实与确认：核实了软删除后 syb_product_id 维度的最新任务查询行为——若按项目既有惯例（gorm.DeletedAt，models/schema.go 多处已用同一模式）实现软删除，GORM 默认对所有查询自动加 deleted_at IS NULL 过滤，purchase/service.go:248 的"查最新任务"逻辑无需改动即会自动跳过已软删除的任务，效果等同于该 SYB 商品此前从未创建过采购任务，可直接重新创建正式采购任务。用户已确认接受此行为（软删除即视为"当作没发生过"，不保留"曾失败过"的阻拦痕迹）。此项此前列为"待核实"，现已转为已确认事实，见下方「判断边界」。

另有用户提出「物理删除、不限状态」的更激进版本（含 order_created 等已产生真实订单的任务）；已提示该版本会突破 AGENTS.md 永久规则第 41 条与 #178 当前方案的既有红线，用户尚未明确决定是否采用，本次更新不改变方案范围，仍按软删除 + 限定状态执行，如后续确认采用物理删除版本将另行大改本工单。

高风险标记——已获用户明确确认（2026-09-02：「接受软删除这个决策本身」）：本单涉及删除采购任务数据，属于 AGENTS.md 永久规则中「创建订单、权限、安全、并发、数据库迁移、删除数据…」列出的高风险类别。当前采购任务模块从未提供任何删除接口是既有设计决策而非疏漏（见下方「已核实事实」），本单是对该决策的一次反转。用户已明确接受"允许软删除采购任务"这一决策本身。注意：本确认只覆盖"软删除"这个决策，不代表已确认「物理删除、不限状态」的更激进版本（该版本仍标记为"讨论中、未采纳"，见下方 2026-09-02 补充核实说明）；数据库迁移脚本、以及真机/正式环境实施前，仍需按仓库规则分别再次等待人工确认。

原始需求摘要

来源：用户于 2026-08-31 先确认「管理员也不能删除任何采购任务」的现状核验结果，随后明确要求「改成管理员可以批量勾选删除采购订单」，并要求建单。

目的：让管理员能够批量清理不需要的采购任务记录。

基线与已核实事实

代码基线：5338dd0（2026-08-31）。核验日期 2026-08-31。

  • server/app/goauto/purchase/router.go:28-44：admin 路由组内没有任何 DELETE 方法，也没有 batch-delete 类接口；唯一的终止性操作是 POST /:taskId/cancel（状态机转 cancelled，记录保留）。
  • models/purchase.go:177,284：PurchaseTaskAttempt.Task 与另一处 Task *PurchaseTask 外键均为 OnDelete:RESTRICT，未设置 CASCADE。这意味着当前 schema 在数据库层面就会阻止物理删除任何仍有 attempt 或规格决策记录关联的采购任务——不是应用层漏做校验，是约束层面主动挡住。
  • purchase/manual.go:88-108：Cancel 要求填写取消原因，运行中/订单提交中状态不允许取消，取消后记录（含 CancelReason、CancelledBy、CancelledAt）永久保留，是当前唯一的"结束一个任务"路径。
  • 对比：collection-tasks、shopee-products 都有软删除（DeletedAt + deleted_at 查询自动排除），采购任务模块从建立起就没有对应能力。
  • models/schema.go:395-410（ShopeeProduct.DeletedFlag 注释）记录了本项目此前踩过的坑：MySQL 的复合唯一索引把多个 NULL 视为互不相同，单纯加 DeletedAt 不足以保证"软删除后可以用同一业务键重新创建"语义正确，需要配合辅助列。采购任务是否存在类似的唯一索引风险需要在实施前逐一核实（如 create_request_id、cancel_request_id 等幂等键）。

判断边界

  • 已确认：删除采购任务记录会切断规格决策、执行历史、可能存在的订单号与人工核账记录之间的审计链条，且现有 schema 用 RESTRICT 外键主动防止了这种情况。
  • 已确认：用户明确要求的是"删除"，不是现有的"取消"；两者语义不同，本单不能用扩大"取消"的方式变相满足需求。
  • 待用户决定（讨论中，未采纳）：是否改为"物理删除、不限状态"。已提示会突破 AGENTS.md 第 41 条及本单现有红线（尤其是允许删除 order_created 等已产生真实订单的任务，记录将永久无法恢复）。在用户明确采用前，本单继续按软删除 + 限定状态执行。
  • 尚未确认：允许删除的任务状态范围——默认收窄到 failed/cancelled/rehearsal_completed 三种（见下方方案第 1 步），用户尚未明确表态是接受该默认范围还是要调整；每扩大一类状态都需要重新评估风险并写回本工单。
  • 已确认（2026-09-02）：软删除后，同一 SYB 商品可以直接重新创建正式采购任务，不受被删除任务的历史状态影响——按 GORM DeletedAt 默认行为，purchase/service.go:248 的最新任务查询会自动跳过已软删除的记录，无需额外开发即可达到此效果。用户已确认接受该行为。

目标

  1. 管理员在采购任务列表可批量勾选，对符合条件的任务执行软删除。
  2. 删除后的任务记录仍完整保留在数据库中（DeletedAt 语义），不再出现在默认列表，但保留通过筛选查看和审计的能力，不物理清除任何字段。
  3. 删除操作限定在明确安全的任务状态范围内，排除任何可能已产生资金或库存后果、或仍在执行中的任务。
  4. 删除必须记录操作人、操作时间和原因，与「取消」现有的审计要求对齐。

非目标

  • 不做物理删除（DELETE FROM），不清除或改写任何历史字段。
  • 不允许删除处于 pending、spec_probe_pending、running、order_submit_started、order_result_unknown 状态的任务；不允许删除已创建订单（order_created）的任务，无论是否已支付——已创建订单意味着现实世界可能已经产生了采购行为，删除记录会制造审计缺口。
  • 不提供"删除后允许同一 SYB 商品的历史记录被完全遗忘"的效果——已推翻（2026-09-02）：用户明确接受"软删除即视为该 SYB 商品从未创建过采购任务，可直接重新创建"这一效果，不再是非目标，见「判断边界」。syb_product_id 维度的查询逻辑经核实无需修改即自动满足此行为（GORM 默认过滤已软删除记录）。
  • 不修改「取消」现有行为、不合并"删除"和"取消"为同一操作。
  • 不新增批量物理清理、定时清理等自动化删除机制。
  • 不涉及 Android Agent、采集、规则或规格匹配。

前置依赖与并行性

  • 需要先核实采购任务表及关联表（purchase_task_attempt、规格决策相关表）是否存在依赖"未删除"语义的唯一索引，若存在需比照 ShopeeProduct.DeletedFlag 的方案设计辅助列，避免重现历史踩过的坑（create_request_id/cancel_request_id 等幂等键属于此类，需在实施时逐一检查是否会因软删除记录仍占用唯一值而阻碍新任务创建，即便主流程的 syb_product_id 查询本身已确认无需改动）。
  • 与 #172、#175、#177 无代码重叠，可并行。

固定实施方案（草案，待用户确认）

1. 允许删除的状态范围

只允许删除以下状态的任务：failed、cancelled、rehearsal_completed。

  • 排除一切"尚未结束"的状态（进行中或可能仍在被 Agent 领取执行）。
  • 排除 order_created、order_result_unknown：这两种状态都意味着现实世界可能已经创建了订单，删除记录会制造审计缺口，即便未支付也不例外。
  • 用户在确认阶段可以调整此范围，但每新增一类允许删除的状态都需要重新说明理由并写回本工单。

2. 软删除字段与迁移

  • 为 PurchaseTask 增加软删除支持（DeletedAt 及必要的辅助去重列，视第 1 步核实结果决定是否需要）。
  • 默认查询范围（AdminList、AdminDetail、syb_product_id 最新任务查询等）自动排除已删除记录；新增筛选参数可选查看已删除记录，与 shopee-products 现有"已删除"筛选模式保持一致。
  • 数据库结构变更需数据库迁移，属于高风险变更，实施前需人工确认迁移脚本。

3. 批量删除接口

  • POST /api/admin/v1/purchase-tasks/batch-delete，请求体包含任务 id 列表、requestId（幂等）、删除原因（必填，比照 Cancel 的 Reason 校验）。
  • 服务端对每个 id 加锁校验：状态不在允许范围内的，单条拒绝并在批量结果中标注原因，不影响其余可删除项（比照现有 AdminBatchRetry/shopeeproduct.BatchSoftDelete 的逐项结果返回模式）。
  • 记录操作人、操作时间、删除原因到新增字段，与 Cancel 的审计字段对齐。

4. 前端

  • 采购任务列表增加多选与批量删除入口，复用虾皮商品列表的批量删除交互（勾选、确认对话框说明软删除语义、结果反馈每条成功/失败原因）。
  • 列表默认不显示已删除任务；新增筛选项可查看已删除任务（只读，不能对已删除任务再次执行任何操作）。
  • 删除确认对话框必须清楚说明：仅软删除、记录仍可审计查看、不影响历史订单数据。

设计证据

新增批量操作与列表筛选状态，按规则需要用户确认覆盖范围（正常、空、加载、失败、权限边界）；可复用虾皮商品批量删除的既有交互模式作为参考，但因涉及采购域和数据删除，仍需提供标注截图或原型供用户确认，不适用纯 UI 文案豁免。

验收标准

  • 只有 failed、cancelled、rehearsal_completed 状态的采购任务可被删除；其余状态返回明确拒绝，批量场景下不影响其他可删除项。
  • 删除为软删除，数据库记录字段不被清除或篡改，可通过筛选查看已删除任务。
  • 已删除任务不出现在默认列表、不能被再次执行任何操作（取消、重试、写回、支付核对等）。
  • 删除记录操作人、操作时间、删除原因。
  • syb_product_id 维度的最新任务查询和重新创建判断逻辑在有已删除任务的情况下行为正确，已在核实与实施中明确处理（不是默认放任不管）。
  • 批量删除接口幂等（同一 requestId 重复提交不重复处理）。
  • Server 单元测试、契约测试与构建通过；Web 单元测试与既有 e2e 测试通过。
  • 数据库迁移脚本经人工确认后执行，迁移前后现有数据不受影响。

必测场景

  • 批量勾选混合状态（部分可删除、部分不可删除）时，逐项结果正确区分成功与拒绝原因。
  • 尝试删除 order_created、running、pending 等禁止状态，明确拒绝。
  • 删除后再次访问该任务详情、发起取消/重试/写回等操作均被拒绝或明确提示已删除。
  • 同一 SYB 商品的历史任务被软删除后，再次创建正式采购任务应当成功，等同于该商品从未创建过采购任务（已确认的预期行为，非"待验证是否符合预期"）。
  • 幂等：同一批量删除请求重复提交，结果一致，不产生副作用。
  • 筛选查看已删除任务，列表正确显示且不可操作。

风险与安全门禁

  • 这是对既有安全设计的反转：当前无删除接口是刻意的架构决策（外键 RESTRICT、无删除路由），本单实施前必须由用户对"允许软删除"这一决策本身做一次独立、明确的确认，不能仅凭"建工单"指令视为已获得实施授权。
  • 严禁扩展为物理删除；严禁允许删除 order_created/order_result_unknown 状态的任务。
  • 数据库迁移、外键与索引变更需人工确认迁移脚本后再执行。
  • 真机或正式环境实施前，需按仓库规则再次等待人工确认。
  • 不涉及创建订单、支付、修改地址；不新增任何采购动作能力。

文档影响

有长期文档影响。 新增采购任务删除能力与状态限制，需更新 Wiki 中记录采购任务状态机与业务规则的页面（如 03-业务规则与术语 一类页面），说明软删除语义、允许状态范围与审计字段。在线回读 revision 后完成一次 sync 和一次 sync --check，revision 回写本工单。

状态

部分确认，仍待确认（2026-08-31 创建，2026-09-02 更新）。已确认：接受"软删除"这一决策本身；软删除后同一 SYB 商品可直接重新创建采购任务。仍待确认后才能开始实施：

  1. 允许删除的任务状态范围——是否接受默认的 failed/cancelled/rehearsal_completed，还是要调整；
  2. 设计证据——本单改动涉及采购域数据删除，按规则默认仍需标注截图或原型，除非用户像 #188 一样明确表示以文字方案确认放行、不要求截图；
  3. 「物理删除、不限状态」的更激进版本是否采用（若采用，本工单需要大改，当前方案与验收标准均基于软删除）。

数据库迁移脚本执行前、以及真机或正式环境实施前，按仓库规则仍需分别再次等待人工确认，不因本次确认而跳过。

> Gitea MCP 未向当前会话暴露，按仓库规则回退项目根目录安全配置与 Gitea API 维护本工单；凭据未写入工单、代码或日志。 > > **2026-09-02 补充核实与确认**：核实了软删除后 `syb_product_id` 维度的最新任务查询行为——若按项目既有惯例（`gorm.DeletedAt`，`models/schema.go` 多处已用同一模式）实现软删除，GORM 默认对所有查询自动加 `deleted_at IS NULL` 过滤，`purchase/service.go:248` 的"查最新任务"逻辑无需改动即会自动跳过已软删除的任务，效果等同于该 SYB 商品此前从未创建过采购任务，可直接重新创建正式采购任务。**用户已确认接受此行为**（软删除即视为"当作没发生过"，不保留"曾失败过"的阻拦痕迹）。此项此前列为"待核实"，现已转为已确认事实，见下方「判断边界」。 > > 另有用户提出「物理删除、不限状态」的更激进版本（含 `order_created` 等已产生真实订单的任务）；已提示该版本会突破 `AGENTS.md` 永久规则第 41 条与 #178 当前方案的既有红线，**用户尚未明确决定是否采用**，本次更新不改变方案范围，仍按软删除 + 限定状态执行，如后续确认采用物理删除版本将另行大改本工单。 > > **高风险标记——已获用户明确确认（2026-09-02：「接受软删除这个决策本身」）**：本单涉及删除采购任务数据，属于 `AGENTS.md` 永久规则中「创建订单、权限、安全、并发、数据库迁移、删除数据…」列出的高风险类别。当前采购任务模块从未提供任何删除接口是既有设计决策而非疏漏（见下方「已核实事实」），本单是对该决策的一次反转。用户已明确接受"允许软删除采购任务"这一决策本身。**注意**：本确认只覆盖"软删除"这个决策，不代表已确认「物理删除、不限状态」的更激进版本（该版本仍标记为"讨论中、未采纳"，见下方 2026-09-02 补充核实说明）；数据库迁移脚本、以及真机/正式环境实施前，仍需按仓库规则分别再次等待人工确认。 ## 原始需求摘要 来源：用户于 2026-08-31 先确认「管理员也不能删除任何采购任务」的现状核验结果，随后明确要求「改成管理员可以批量勾选删除采购订单」，并要求建单。 目的：让管理员能够批量清理不需要的采购任务记录。 ## 基线与已核实事实 代码基线：`5338dd0`（2026-08-31）。核验日期 2026-08-31。 - `server/app/goauto/purchase/router.go:28-44`：admin 路由组内没有任何 `DELETE` 方法，也没有 batch-delete 类接口；唯一的终止性操作是 `POST /:taskId/cancel`（状态机转 `cancelled`，记录保留）。 - `models/purchase.go:177,284`：`PurchaseTaskAttempt.Task` 与另一处 `Task *PurchaseTask` 外键均为 `OnDelete:RESTRICT`，未设置 CASCADE。这意味着当前 schema 在数据库层面就会阻止物理删除任何仍有 attempt 或规格决策记录关联的采购任务——不是应用层漏做校验，是约束层面主动挡住。 - `purchase/manual.go:88-108`：`Cancel` 要求填写取消原因，运行中/订单提交中状态不允许取消，取消后记录（含 `CancelReason`、`CancelledBy`、`CancelledAt`）永久保留，是当前唯一的"结束一个任务"路径。 - 对比：`collection-tasks`、`shopee-products` 都有软删除（`DeletedAt` + `deleted_at` 查询自动排除），采购任务模块从建立起就没有对应能力。 - `models/schema.go:395-410`（`ShopeeProduct.DeletedFlag` 注释）记录了本项目此前踩过的坑：MySQL 的复合唯一索引把多个 `NULL` 视为互不相同，单纯加 `DeletedAt` 不足以保证"软删除后可以用同一业务键重新创建"语义正确，需要配合辅助列。采购任务是否存在类似的唯一索引风险需要在实施前逐一核实（如 `create_request_id`、`cancel_request_id` 等幂等键）。 ## 判断边界 - 已确认：删除采购任务记录会切断规格决策、执行历史、可能存在的订单号与人工核账记录之间的审计链条，且现有 schema 用 `RESTRICT` 外键主动防止了这种情况。 - 已确认：用户明确要求的是"删除"，不是现有的"取消"；两者语义不同，本单不能用扩大"取消"的方式变相满足需求。 - **待用户决定（讨论中，未采纳）**：是否改为"物理删除、不限状态"。已提示会突破 `AGENTS.md` 第 41 条及本单现有红线（尤其是允许删除 `order_created` 等已产生真实订单的任务，记录将永久无法恢复）。在用户明确采用前，本单继续按**软删除 + 限定状态**执行。 - 尚未确认：允许删除的任务状态范围——默认收窄到 `failed`/`cancelled`/`rehearsal_completed` 三种（见下方方案第 1 步），用户尚未明确表态是接受该默认范围还是要调整；每扩大一类状态都需要重新评估风险并写回本工单。 - **已确认（2026-09-02）**：软删除后，同一 SYB 商品可以直接重新创建正式采购任务，不受被删除任务的历史状态影响——按 GORM `DeletedAt` 默认行为，`purchase/service.go:248` 的最新任务查询会自动跳过已软删除的记录，无需额外开发即可达到此效果。用户已确认接受该行为。 ## 目标 1. 管理员在采购任务列表可批量勾选，对符合条件的任务执行软删除。 2. 删除后的任务记录仍完整保留在数据库中（`DeletedAt` 语义），不再出现在默认列表，但保留通过筛选查看和审计的能力，不物理清除任何字段。 3. 删除操作限定在明确安全的任务状态范围内，排除任何可能已产生资金或库存后果、或仍在执行中的任务。 4. 删除必须记录操作人、操作时间和原因，与「取消」现有的审计要求对齐。 ## 非目标 - 不做物理删除（`DELETE FROM`），不清除或改写任何历史字段。 - 不允许删除处于 `pending`、`spec_probe_pending`、`running`、`order_submit_started`、`order_result_unknown` 状态的任务；不允许删除已创建订单（`order_created`）的任务，无论是否已支付——已创建订单意味着现实世界可能已经产生了采购行为，删除记录会制造审计缺口。 - ~~不提供"删除后允许同一 SYB 商品的历史记录被完全遗忘"的效果~~——**已推翻（2026-09-02）**：用户明确接受"软删除即视为该 SYB 商品从未创建过采购任务，可直接重新创建"这一效果，不再是非目标，见「判断边界」。`syb_product_id` 维度的查询逻辑经核实无需修改即自动满足此行为（GORM 默认过滤已软删除记录）。 - 不修改「取消」现有行为、不合并"删除"和"取消"为同一操作。 - 不新增批量物理清理、定时清理等自动化删除机制。 - 不涉及 Android Agent、采集、规则或规格匹配。 ## 前置依赖与并行性 - 需要先核实采购任务表及关联表（`purchase_task_attempt`、规格决策相关表）是否存在依赖"未删除"语义的唯一索引，若存在需比照 `ShopeeProduct.DeletedFlag` 的方案设计辅助列，避免重现历史踩过的坑（`create_request_id`/`cancel_request_id` 等幂等键属于此类，需在实施时逐一检查是否会因软删除记录仍占用唯一值而阻碍新任务创建，即便主流程的 `syb_product_id` 查询本身已确认无需改动）。 - 与 #172、#175、#177 无代码重叠，可并行。 ## 固定实施方案（草案，待用户确认） ### 1. 允许删除的状态范围 只允许删除以下状态的任务：`failed`、`cancelled`、`rehearsal_completed`。 - 排除一切"尚未结束"的状态（进行中或可能仍在被 Agent 领取执行）。 - 排除 `order_created`、`order_result_unknown`：这两种状态都意味着现实世界可能已经创建了订单，删除记录会制造审计缺口，即便未支付也不例外。 - 用户在确认阶段可以调整此范围，但每新增一类允许删除的状态都需要重新说明理由并写回本工单。 ### 2. 软删除字段与迁移 - 为 `PurchaseTask` 增加软删除支持（`DeletedAt` 及必要的辅助去重列，视第 1 步核实结果决定是否需要）。 - 默认查询范围（`AdminList`、`AdminDetail`、`syb_product_id` 最新任务查询等）自动排除已删除记录；新增筛选参数可选查看已删除记录，与 `shopee-products` 现有"已删除"筛选模式保持一致。 - 数据库结构变更需数据库迁移，属于高风险变更，实施前需人工确认迁移脚本。 ### 3. 批量删除接口 - `POST /api/admin/v1/purchase-tasks/batch-delete`，请求体包含任务 id 列表、`requestId`（幂等）、删除原因（必填，比照 `Cancel` 的 `Reason` 校验）。 - 服务端对每个 id 加锁校验：状态不在允许范围内的，单条拒绝并在批量结果中标注原因，不影响其余可删除项（比照现有 `AdminBatchRetry`/`shopeeproduct.BatchSoftDelete` 的逐项结果返回模式）。 - 记录操作人、操作时间、删除原因到新增字段，与 `Cancel` 的审计字段对齐。 ### 4. 前端 - 采购任务列表增加多选与批量删除入口，复用虾皮商品列表的批量删除交互（勾选、确认对话框说明软删除语义、结果反馈每条成功/失败原因）。 - 列表默认不显示已删除任务；新增筛选项可查看已删除任务（只读，不能对已删除任务再次执行任何操作）。 - 删除确认对话框必须清楚说明：仅软删除、记录仍可审计查看、不影响历史订单数据。 ## 设计证据 新增批量操作与列表筛选状态，按规则需要用户确认覆盖范围（正常、空、加载、失败、权限边界）；可复用虾皮商品批量删除的既有交互模式作为参考，但因涉及采购域和数据删除，仍需提供标注截图或原型供用户确认，不适用纯 UI 文案豁免。 ## 验收标准 - [ ] 只有 `failed`、`cancelled`、`rehearsal_completed` 状态的采购任务可被删除；其余状态返回明确拒绝，批量场景下不影响其他可删除项。 - [ ] 删除为软删除，数据库记录字段不被清除或篡改，可通过筛选查看已删除任务。 - [ ] 已删除任务不出现在默认列表、不能被再次执行任何操作（取消、重试、写回、支付核对等）。 - [ ] 删除记录操作人、操作时间、删除原因。 - [ ] `syb_product_id` 维度的最新任务查询和重新创建判断逻辑在有已删除任务的情况下行为正确，已在核实与实施中明确处理（不是默认放任不管）。 - [ ] 批量删除接口幂等（同一 `requestId` 重复提交不重复处理）。 - [ ] Server 单元测试、契约测试与构建通过；Web 单元测试与既有 e2e 测试通过。 - [ ] 数据库迁移脚本经人工确认后执行，迁移前后现有数据不受影响。 ## 必测场景 - 批量勾选混合状态（部分可删除、部分不可删除）时，逐项结果正确区分成功与拒绝原因。 - 尝试删除 `order_created`、`running`、`pending` 等禁止状态，明确拒绝。 - 删除后再次访问该任务详情、发起取消/重试/写回等操作均被拒绝或明确提示已删除。 - 同一 SYB 商品的历史任务被软删除后，再次创建正式采购任务应当成功，等同于该商品从未创建过采购任务（已确认的预期行为，非"待验证是否符合预期"）。 - 幂等：同一批量删除请求重复提交，结果一致，不产生副作用。 - 筛选查看已删除任务，列表正确显示且不可操作。 ## 风险与安全门禁 - **这是对既有安全设计的反转**：当前无删除接口是刻意的架构决策（外键 `RESTRICT`、无删除路由），本单实施前必须由用户对"允许软删除"这一决策本身做一次独立、明确的确认，不能仅凭"建工单"指令视为已获得实施授权。 - 严禁扩展为物理删除；严禁允许删除 `order_created`/`order_result_unknown` 状态的任务。 - 数据库迁移、外键与索引变更需人工确认迁移脚本后再执行。 - 真机或正式环境实施前，需按仓库规则再次等待人工确认。 - 不涉及创建订单、支付、修改地址；不新增任何采购动作能力。 ## 文档影响 **有长期文档影响。** 新增采购任务删除能力与状态限制，需更新 Wiki 中记录采购任务状态机与业务规则的页面（如 `03-业务规则与术语` 一类页面），说明软删除语义、允许状态范围与审计字段。在线回读 revision 后完成一次 `sync` 和一次 `sync --check`，revision 回写本工单。 ## 状态 **部分确认，仍待确认（2026-08-31 创建，2026-09-02 更新）**。已确认：接受"软删除"这一决策本身；软删除后同一 SYB 商品可直接重新创建采购任务。**仍待确认后才能开始实施**： 1. 允许删除的任务状态范围——是否接受默认的 `failed`/`cancelled`/`rehearsal_completed`，还是要调整； 2. 设计证据——本单改动涉及采购域数据删除，按规则默认仍需标注截图或原型，除非用户像 #188 一样明确表示以文字方案确认放行、不要求截图； 3. 「物理删除、不限状态」的更激进版本是否采用（若采用，本工单需要大改，当前方案与验收标准均基于软删除）。 数据库迁移脚本执行前、以及真机或正式环境实施前，按仓库规则仍需分别再次等待人工确认，不因本次确认而跳过。
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#178