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

采购规则落库并支持 Admin 编辑（不含模块合并与改名） #127

New Issue
Open
opened 2026-08-28 14:13:38 +08:00 by ila · 5 comments
ila commented 2026-08-28 14:13:38 +08:00
Owner
Copy Link
Copy Source

所属与来源

  • 关联工单：#115 识别文案迁入规则下发、#116 门禁与校验分级、采购 MVP 相关工单。
  • 来源：用户于 2026-08-28 询问「现在采购的规则是写在哪里」，在确认采购规则为源码常量后提出「要不要把采购规则提取出来分 admin 和 agent，把『采集规则』模块改名为『Agent 规则』，把采购规则也加到这里」。经讨论确认：本工单只做采购规则落库与 Admin 可编辑，模块合并与改名另行建单。
  • 类型：Server + Admin / 采购规则存储与可编辑化（不含 Agent 行为变更）。
  • 工具回退说明：本工单通过 Gitea API 创建。当前会话未提供 Gitea MCP 工具，按 AGENTS.md「Gitea 交互与工单最小读取」记录回退原因。

当前事实（提交 9bb19b4 复核）

  • 采购规则内容是源码常量：server/app/goauto/purchasecontract/default.go 的 DefaultLiveRule() 返回一整条 JSON，其自身注释即写明「Purchase rules do not yet have their own editable archive」。
  • 引用点：purchase/batch.go:237（批量创建）与 purchase/retry.go:126（批量重试）直接调用该常量。
  • POST /api/admin/v1/purchase-tasks（purchase/service.go:47-50）虽接受调用方传入 ruleSnapshot，但 Admin 无编辑入口，实际不可配。
  • 校验位于 purchasecontract/contract.go：动作白名单、能力位、forbiddenClickFragments、swipe 参数上下限，均为源码常量。
  • 快照机制已具备：models.PurchaseTask.RuleSnapshot（models/purchase.go:117）冻结创建时的规则，purchase/lifecycle.go:180 另存 RuleSnapshotHash 于尝试记录。
  • 对照：采集规则有独立表 collection_rule（models/schema.go:100-112）与完整 Admin 接口（access/purchaser.go:69-73：模板查看、列表、新增、修改、删除，且写操作对采购员角色关闭）。

结论：PDD 侧任何采购流程文案或步骤变化，当前必须修改 Go 源码并重新部署服务端；采集侧经 #115 已可通过 Admin 配置，两者能力不对等。

目标

  1. 采购规则从源码常量迁移为数据库记录，可由管理员在 Admin 编辑。
  2. 校验强度、安全边界与既有快照机制完全不变。
  3. 存量任务不受影响：已有 rule_snapshot 保持不可变。
  4. 为后续「规则中心」聚合与改名打基础，但本工单不做导航与命名变更。

非目标

  • 不做模块合并与改名：不新增「规则中心」/「Agent 规则」导航，不改动采集规则模块的名称与入口。该部分另行建单，且需先出设计证据。
  • 不合并两种规则的 schema：采集规则（schemaVersion 2，描述性配置）与采购规则（schemaVersion 1，类型化动作序列）结构不同，校验器保持独立，不共用编辑器。
  • 不修改 Agent 代码与采购执行逻辑。
  • 不实现支付；pay / payment 动作仍按 #116 口径拒绝。
  • 不放宽 forbiddenClickFragments 与地址类永久禁令。
  • 不修改采集规则表结构与既有采集接口。
  • 不改变采购任务状态机、租约与并发约束。

实施方案

一、数据模型

  1. 新增独立表 purchase_rule，结构对齐 collection_rule：id、name、content_json、三个幂等请求 ID 列、时间戳与软删除列。不复用 collection_rule 表。
  2. 数据库迁移新增该表；迁移必须可重复执行且不影响既有表。按 AGENTS.md，迁移属高风险改动，实施前需再次人工确认。
  3. 内置默认规则以迁移方式写入一条初始记录，内容与当前 DefaultLiveRule() 完全一致（逐字节比对），保证行为不变。

二、服务端

  1. purchasecontract.DefaultLiveRule() 保留但降级为「初始化种子」，仅供迁移与测试使用；batch.go:237 与 retry.go:126 改为从数据库读取当前启用的采购规则。
  2. 读取不到启用规则时明确失败并给出可读错误码，不得回退到源码常量，避免出现「Admin 显示一套、实际执行另一套」的双事实源。
  3. 创建任务时继续冻结快照到 purchase_task.rule_snapshot，RuleSnapshotHash 逻辑不变；后续修改规则不影响已排队任务。
  4. 保存规则时必须通过 purchasecontract.Validate（live 与 rehearsal 两种模式均校验），校验不通过即拒绝保存，不允许保存无效规则后再在执行期失败。

三、Admin 接口与权限

  1. 新增 /api/admin/v1/purchase-rules 的查看、新增、修改、删除接口，路径风格对齐采集规则。
  2. 权限必须独立：在 access/purchaser.go 中为采购规则单独登记权限点，不与采集规则共用。写操作（新增/修改/删除）对采购员角色关闭，与采集规则写操作的现有口径一致。
  3. 采购规则包含 createOrder 与 updateShippingAddress 等不可逆动作，保存时必须二次确认；确认交互属界面变化，按双门禁需先提供设计证据（可复用现有规则编辑界面规范并提供标注截图），确认后再写生产代码。

四、Admin 界面

  1. 在现有采集规则模块之外提供采购规则的编辑入口，本工单不改导航结构与模块名称；界面可复用现有规则编辑组件，但必须与采集规则在视觉与入口上明确区隔，避免误编辑。
  2. 界面部分依赖第 10 项设计证据；在设计证据确认前，可先完成第一至三节（数据模型、服务端、接口与权限），规则通过接口直接维护。

安全边界

  • 校验强度不降低：动作白名单、能力位要求、forbiddenClickFragments、地址类永久禁令、pay 动作拒绝全部保持。
  • 采购规则写权限与采集规则分离，不因进入同一产品区域而共用权限点。
  • 已冻结的任务快照不可变，规则修改不得回溯影响运行中或已完成任务。
  • 数据库迁移前需人工确认；迁移只新增表，不改动既有表结构与数据。
  • 不实现支付、不新增点击支付目标。

验收标准

  • purchase_rule 表创建成功，迁移可重复执行，既有表与数据不受影响。
  • 初始记录内容与当前 DefaultLiveRule() 逐字节一致。
  • 批量创建与批量重试均从数据库读取规则；读取不到启用规则时明确失败，不回退源码常量。
  • 通过 Admin 接口修改采购规则后，新建任务的 rule_snapshot 反映新内容，已有任务快照不变。
  • 保存包含 pay 动作、支付 点击目标或地址类文字的规则时被拒绝，错误信息与 #116 口径一致。
  • 采购规则写接口对采购员角色关闭，权限点与采集规则相互独立。
  • 采购任务的创建、认领、执行、重试与状态机行为与本工单实施前一致。
  • 界面部分在设计证据确认前未进入生产代码。

验证方式

  • go test ./app/goauto/purchase/... ./app/goauto/purchasecontract/... ./app/goauto/access/...
  • 迁移在空库与既有库两种前提下各执行一次，确认幂等且不破坏既有数据。
  • 回归：批量预检、批量创建、批量重试、单任务创建四条路径各跑一次，确认规则来源切换后行为不变。
  • 不涉及 Agent，不需要真机验证；如实记录该结论。
  • 未覆盖的部署环境与并发场景如实回写。

依赖、并行与风险

  • 建议排在 #124 收口之后实施；采购 live 流程若仍在真机调整期，schema 可能变动，届时需重新确认默认规则内容。
  • 与 #124 无代码冲突，可并行开发但不建议同时验收。
  • 后续工单（不在本工单范围）：规则中心聚合视图与模块改名。命名建议避免使用「Agent 规则」——「Agent」在本项目已指代 Android 客户端本身及 AgentManualCollectionSetting 的「Agent 手动采集规则」，再复用会产生歧义；建议「规则中心」下分「采集规则 / 采购规则」。
  • 风险：规则来源从常量切换为数据库后，若初始记录写入失败会导致采购无法创建。缓解：迁移与初始记录在同一事务；第 5 项要求明确失败而非静默回退，便于第一时间发现。
  • 回退：还原本工单提交并保留 purchase_rule 表（不删表），代码恢复读取源码常量即可。

文档影响

  • 需更新 Wiki Architecture-and-Code-Map（docs/02-architecture-and-code-map.md）：采购规则来源由源码常量改为数据库表。
  • 需更新 Wiki Android-Agent-API-Contract（docs/08-agent-api-contract.md）：采购规则的存储位置与快照口径描述。
  • 需更新 Wiki Business-Rules-and-Glossary（docs/03-business-rules-and-glossary.md）：采购规则可编辑范围与权限边界。
  • 按 Wiki-first 门禁：先改线上页面并回读 revision，再执行一轮 sync 与一轮 sync --check，把页面与 revision 写回本工单。

状态

待实施（数据库迁移需在实施前再次人工确认）。

## 所属与来源 - 关联工单：#115 识别文案迁入规则下发、#116 门禁与校验分级、采购 MVP 相关工单。 - 来源：用户于 2026-08-28 询问「现在采购的规则是写在哪里」，在确认采购规则为源码常量后提出「要不要把采购规则提取出来分 admin 和 agent，把『采集规则』模块改名为『Agent 规则』，把采购规则也加到这里」。经讨论确认：**本工单只做采购规则落库与 Admin 可编辑，模块合并与改名另行建单**。 - 类型：Server + Admin / 采购规则存储与可编辑化（不含 Agent 行为变更）。 - 工具回退说明：本工单通过 Gitea API 创建。当前会话未提供 Gitea MCP 工具，按 `AGENTS.md`「Gitea 交互与工单最小读取」记录回退原因。 ## 当前事实（提交 9bb19b4 复核） - 采购规则内容是**源码常量**：`server/app/goauto/purchasecontract/default.go` 的 `DefaultLiveRule()` 返回一整条 JSON，其自身注释即写明「Purchase rules do not yet have their own editable archive」。 - 引用点：`purchase/batch.go:237`（批量创建）与 `purchase/retry.go:126`（批量重试）直接调用该常量。 - `POST /api/admin/v1/purchase-tasks`（`purchase/service.go:47-50`）虽接受调用方传入 `ruleSnapshot`，但 Admin 无编辑入口，实际不可配。 - 校验位于 `purchasecontract/contract.go`：动作白名单、能力位、`forbiddenClickFragments`、swipe 参数上下限，均为源码常量。 - 快照机制已具备：`models.PurchaseTask.RuleSnapshot`（`models/purchase.go:117`）冻结创建时的规则，`purchase/lifecycle.go:180` 另存 `RuleSnapshotHash` 于尝试记录。 - 对照：采集规则有独立表 `collection_rule`（`models/schema.go:100-112`）与完整 Admin 接口（`access/purchaser.go:69-73`：模板查看、列表、新增、修改、删除，且写操作对采购员角色关闭）。 结论：PDD 侧任何采购流程文案或步骤变化，当前必须修改 Go 源码并重新部署服务端；采集侧经 #115 已可通过 Admin 配置，两者能力不对等。 ## 目标 1. 采购规则从源码常量迁移为数据库记录，可由管理员在 Admin 编辑。 2. 校验强度、安全边界与既有快照机制完全不变。 3. 存量任务不受影响：已有 `rule_snapshot` 保持不可变。 4. 为后续「规则中心」聚合与改名打基础，但本工单不做导航与命名变更。 ## 非目标 - **不做模块合并与改名**：不新增「规则中心」/「Agent 规则」导航，不改动采集规则模块的名称与入口。该部分另行建单，且需先出设计证据。 - **不合并两种规则的 schema**：采集规则（schemaVersion 2，描述性配置）与采购规则（schemaVersion 1，类型化动作序列）结构不同，校验器保持独立，不共用编辑器。 - 不修改 Agent 代码与采购执行逻辑。 - 不实现支付；`pay` / `payment` 动作仍按 #116 口径拒绝。 - 不放宽 `forbiddenClickFragments` 与地址类永久禁令。 - 不修改采集规则表结构与既有采集接口。 - 不改变采购任务状态机、租约与并发约束。 ## 实施方案 ### 一、数据模型 1. 新增独立表 `purchase_rule`，结构对齐 `collection_rule`：`id`、`name`、`content_json`、三个幂等请求 ID 列、时间戳与软删除列。**不复用 `collection_rule` 表**。 2. 数据库迁移新增该表；迁移必须可重复执行且不影响既有表。按 `AGENTS.md`，迁移属高风险改动，实施前需再次人工确认。 3. 内置默认规则以迁移方式写入一条初始记录，内容与当前 `DefaultLiveRule()` 完全一致（逐字节比对），保证行为不变。 ### 二、服务端 4. `purchasecontract.DefaultLiveRule()` 保留但降级为「初始化种子」，仅供迁移与测试使用；`batch.go:237` 与 `retry.go:126` 改为从数据库读取当前启用的采购规则。 5. 读取不到启用规则时明确失败并给出可读错误码，**不得回退到源码常量**，避免出现「Admin 显示一套、实际执行另一套」的双事实源。 6. 创建任务时继续冻结快照到 `purchase_task.rule_snapshot`，`RuleSnapshotHash` 逻辑不变；后续修改规则不影响已排队任务。 7. 保存规则时必须通过 `purchasecontract.Validate`（live 与 rehearsal 两种模式均校验），校验不通过即拒绝保存，不允许保存无效规则后再在执行期失败。 ### 三、Admin 接口与权限 8. 新增 `/api/admin/v1/purchase-rules` 的查看、新增、修改、删除接口，路径风格对齐采集规则。 9. **权限必须独立**：在 `access/purchaser.go` 中为采购规则单独登记权限点，不与采集规则共用。写操作（新增/修改/删除）对采购员角色关闭，与采集规则写操作的现有口径一致。 10. 采购规则包含 `createOrder` 与 `updateShippingAddress` 等不可逆动作，保存时必须二次确认；确认交互属界面变化，按双门禁需先提供设计证据（可复用现有规则编辑界面规范并提供标注截图），确认后再写生产代码。 ### 四、Admin 界面 11. 在现有采集规则模块之外提供采购规则的编辑入口，**本工单不改导航结构与模块名称**；界面可复用现有规则编辑组件，但必须与采集规则在视觉与入口上明确区隔，避免误编辑。 12. 界面部分依赖第 10 项设计证据；在设计证据确认前，可先完成第一至三节（数据模型、服务端、接口与权限），规则通过接口直接维护。 ## 安全边界 - 校验强度不降低：动作白名单、能力位要求、`forbiddenClickFragments`、地址类永久禁令、`pay` 动作拒绝全部保持。 - 采购规则写权限与采集规则分离，不因进入同一产品区域而共用权限点。 - 已冻结的任务快照不可变，规则修改不得回溯影响运行中或已完成任务。 - 数据库迁移前需人工确认；迁移只新增表，不改动既有表结构与数据。 - 不实现支付、不新增点击支付目标。 ## 验收标准 - [ ] `purchase_rule` 表创建成功，迁移可重复执行，既有表与数据不受影响。 - [ ] 初始记录内容与当前 `DefaultLiveRule()` 逐字节一致。 - [ ] 批量创建与批量重试均从数据库读取规则；读取不到启用规则时明确失败，不回退源码常量。 - [ ] 通过 Admin 接口修改采购规则后，新建任务的 `rule_snapshot` 反映新内容，已有任务快照不变。 - [ ] 保存包含 `pay` 动作、`支付` 点击目标或地址类文字的规则时被拒绝，错误信息与 #116 口径一致。 - [ ] 采购规则写接口对采购员角色关闭，权限点与采集规则相互独立。 - [ ] 采购任务的创建、认领、执行、重试与状态机行为与本工单实施前一致。 - [ ] 界面部分在设计证据确认前未进入生产代码。 ## 验证方式 - `go test ./app/goauto/purchase/... ./app/goauto/purchasecontract/... ./app/goauto/access/...` - 迁移在空库与既有库两种前提下各执行一次，确认幂等且不破坏既有数据。 - 回归：批量预检、批量创建、批量重试、单任务创建四条路径各跑一次，确认规则来源切换后行为不变。 - 不涉及 Agent，不需要真机验证；如实记录该结论。 - 未覆盖的部署环境与并发场景如实回写。 ## 依赖、并行与风险 - 建议排在 #124 收口之后实施；采购 live 流程若仍在真机调整期，schema 可能变动，届时需重新确认默认规则内容。 - 与 #124 无代码冲突，可并行开发但不建议同时验收。 - 后续工单（不在本工单范围）：规则中心聚合视图与模块改名。命名建议避免使用「Agent 规则」——「Agent」在本项目已指代 Android 客户端本身及 `AgentManualCollectionSetting` 的「Agent 手动采集规则」，再复用会产生歧义；建议「规则中心」下分「采集规则 / 采购规则」。 - 风险：规则来源从常量切换为数据库后，若初始记录写入失败会导致采购无法创建。缓解：迁移与初始记录在同一事务；第 5 项要求明确失败而非静默回退，便于第一时间发现。 - 回退：还原本工单提交并保留 `purchase_rule` 表（不删表），代码恢复读取源码常量即可。 ## 文档影响 - 需更新 Wiki `Architecture-and-Code-Map`（`docs/02-architecture-and-code-map.md`）：采购规则来源由源码常量改为数据库表。 - 需更新 Wiki `Android-Agent-API-Contract`（`docs/08-agent-api-contract.md`）：采购规则的存储位置与快照口径描述。 - 需更新 Wiki `Business-Rules-and-Glossary`（`docs/03-business-rules-and-glossary.md`）：采购规则可编辑范围与权限边界。 - 按 Wiki-first 门禁：先改线上页面并回读 revision，再执行一轮 `sync` 与一轮 `sync --check`，把页面与 revision 写回本工单。 ## 状态 待实施（数据库迁移需在实施前再次人工确认）。
127-146-v1.svg
5.3 KiB
127-146-v1.svg
ila commented 2026-08-28 14:17:27 +08:00
Author
Owner
Copy Link
Copy Source

修正：正文中的「启用规则」为悬空前提，改为单例生效设置

正文「实施方案 → 二、服务端」第 4、5 项写有「从数据库读取当前启用的采购规则」「读取不到启用规则时明确失败」。经复核，enabled 这一概念在当前代码中并不存在：

  • models.CollectionRule（server/app/goauto/models/schema.go:100-112）只有软删除 DeletedAt，没有 enabled 或 is_default 字段；
  • 采购规则此前是源码常量，同样没有任何启用状态。

若不修正，实施时会被迫自行发明一套启用语义。现按下述口径修订，覆盖正文第 4、5 项。

一、改用单例生效设置，不给规则加启用标记

新增单例表 purchase_rule_setting，结构对齐现有的 agent_manual_collection_setting（schema.go:177-186）：

  • 单行记录（id 固定为 1，autoIncrement:false）；
  • rule_id 外键指向 purchase_rule，OnDelete:RESTRICT；
  • 幂等请求 ID 列与时间戳，与既有单例设置一致。

选择单例表而非在规则上加 is_default 标记的理由：单例表天然保证「有且只有一条生效」，不需要额外维护「不得同时存在多条默认」的唯一性约束与并发校验。采购批量创建必须能唯一确定规则来源，单例语义与该需求完全吻合。

二、正文第 4、5 项的修订表述

  1. purchasecontract.DefaultLiveRule() 保留但降级为初始化种子，仅供迁移与测试使用；purchase/batch.go:237 与 purchase/retry.go:126 改为读取 purchase_rule_setting 指向的采购规则。
  2. 单例设置缺失、指向的规则不存在或已被软删除时，明确失败并给出可读错误码，不得回退到源码常量，避免出现「Admin 显示一套、实际执行另一套」的双事实源。

三、迁移与接口补充

  • 数据库迁移在创建 purchase_rule 表并写入初始记录的同一事务内，创建 purchase_rule_setting 单行并指向该初始记录，保证迁移完成后采购立即可用。
  • Admin 接口新增「设置当前生效采购规则」的写操作，权限与采购规则的其他写操作一致（对采购员角色关闭），并沿用既有幂等请求 ID 机制。
  • 删除采购规则时，若该规则正被单例设置引用则拒绝删除（OnDelete:RESTRICT 之外，服务层也要给出可读错误），避免出现无生效规则的状态。

四、明确不在本工单范围：停用开关

用户于 2026-08-28 明确：停用开关先不做。

因此本工单不新增 enabled 字段，不引入「生效 / 停用 / 删除」三态。规则可用性仍沿用 AGENTS.md 第 1 节既有业务规则：「规则创建即生效；删除后不能创建新任务，但已有任务继续使用自身规则快照」。该长期业务规则本工单不改动，相应地也不涉及 Business-Rules-and-Glossary 中该条的改写。

若后续需要可逆的停用能力，须单独建单，并先取得用户对修改该条永久业务规则的确认。

五、受影响的验收标准

正文验收标准中涉及「启用规则」的两条相应调整为：

  • 批量创建与批量重试均读取 purchase_rule_setting 指向的规则；单例设置缺失或指向失效规则时明确失败，不回退源码常量。
  • 迁移完成后单例设置指向初始记录，采购创建流程可直接工作。
  • 删除被单例设置引用的采购规则时被拒绝，并返回可读错误。

正文其余目标、非目标、安全边界、验证方式与文档影响不变。

## 修正：正文中的「启用规则」为悬空前提，改为单例生效设置 正文「实施方案 → 二、服务端」第 4、5 项写有「从数据库读取**当前启用的**采购规则」「读取不到**启用规则**时明确失败」。经复核，**`enabled` 这一概念在当前代码中并不存在**： - `models.CollectionRule`（`server/app/goauto/models/schema.go:100-112`）只有软删除 `DeletedAt`，没有 `enabled` 或 `is_default` 字段； - 采购规则此前是源码常量，同样没有任何启用状态。 若不修正，实施时会被迫自行发明一套启用语义。现按下述口径修订，覆盖正文第 4、5 项。 ### 一、改用单例生效设置，不给规则加启用标记 新增单例表 `purchase_rule_setting`，结构对齐现有的 `agent_manual_collection_setting`（`schema.go:177-186`）： - 单行记录（`id` 固定为 1，`autoIncrement:false`）； - `rule_id` 外键指向 `purchase_rule`，`OnDelete:RESTRICT`； - 幂等请求 ID 列与时间戳，与既有单例设置一致。 **选择单例表而非在规则上加 `is_default` 标记的理由**：单例表天然保证「有且只有一条生效」，不需要额外维护「不得同时存在多条默认」的唯一性约束与并发校验。采购批量创建必须能唯一确定规则来源，单例语义与该需求完全吻合。 ### 二、正文第 4、5 项的修订表述 4. `purchasecontract.DefaultLiveRule()` 保留但降级为初始化种子，仅供迁移与测试使用；`purchase/batch.go:237` 与 `purchase/retry.go:126` 改为**读取 `purchase_rule_setting` 指向的采购规则**。 5. 单例设置缺失、指向的规则不存在或已被软删除时，**明确失败并给出可读错误码，不得回退到源码常量**，避免出现「Admin 显示一套、实际执行另一套」的双事实源。 ### 三、迁移与接口补充 - 数据库迁移在创建 `purchase_rule` 表并写入初始记录的**同一事务**内，创建 `purchase_rule_setting` 单行并指向该初始记录，保证迁移完成后采购立即可用。 - Admin 接口新增「设置当前生效采购规则」的写操作，权限与采购规则的其他写操作一致（对采购员角色关闭），并沿用既有幂等请求 ID 机制。 - 删除采购规则时，若该规则正被单例设置引用则拒绝删除（`OnDelete:RESTRICT` 之外，服务层也要给出可读错误），避免出现无生效规则的状态。 ### 四、明确不在本工单范围：停用开关 用户于 2026-08-28 明确：**停用开关先不做**。 因此本工单**不新增** `enabled` 字段，不引入「生效 / 停用 / 删除」三态。规则可用性仍沿用 `AGENTS.md` 第 1 节既有业务规则：「规则创建即生效；删除后不能创建新任务，但已有任务继续使用自身规则快照」。该长期业务规则本工单不改动，相应地也不涉及 `Business-Rules-and-Glossary` 中该条的改写。 若后续需要可逆的停用能力，须单独建单，并先取得用户对修改该条永久业务规则的确认。 ### 五、受影响的验收标准 正文验收标准中涉及「启用规则」的两条相应调整为： - [ ] 批量创建与批量重试均读取 `purchase_rule_setting` 指向的规则；单例设置缺失或指向失效规则时明确失败，不回退源码常量。 - [ ] 迁移完成后单例设置指向初始记录，采购创建流程可直接工作。 - [ ] 删除被单例设置引用的采购规则时被拒绝，并返回可读错误。 正文其余目标、非目标、安全边界、验证方式与文档影响不变。
ila commented 2026-08-28 14:27:03 +08:00
Author
Owner
Copy Link
Copy Source

修订：界面部分改为「规则中心」一次到位

用户于 2026-08-28 确认：采集规则与采购规则统一收进「规则中心」，下分两类。本评论修订正文「非目标」与「实施方案 → 四、Admin 界面」，覆盖此前「不做模块合并与改名」「不改导航结构与模块名称」的表述。

一、修订原因

正文原写「提供采购规则编辑入口，本工单不改导航结构与模块名称」，该表述自相矛盾：新增一个入口本身就是导航变化，同样需要设计证据。按原计划会产生两次界面变动——先加一个临时的「采购规则」入口，之后再合并改名——用户需要重新适应两次导航，设计证据也要出两轮。

既然界面部分本就卡在设计证据之后，原型直接按目标形态绘制，导航只动一次。

二、非目标修订

删除原非目标中的「不做模块合并与改名」一条，替换为：

  • 不合并两种规则的 schema：采集规则（schemaVersion 2，描述性配置）与采购规则（schemaVersion 1，类型化动作序列）的校验器保持独立，不共用编辑器。
  • 不合并数据层：两张独立表、两套校验器、两套权限点保持不变。「规则中心」只是产品层面的统一入口，不是数据层面的合并。
  • 不改变采集规则的既有功能：编辑界面、校验逻辑、快照机制、接口路径与行为一律保持原样，仅入口位置发生变化。不得借入口迁移顺手重构采集规则相关代码。

其余非目标不变（不实现支付、不放宽禁止清单、不改 Agent 代码与采购执行逻辑、不做停用开关）。

三、Admin 界面修订

原第四节替换为：

  1. 新增「规则中心」作为统一入口，下分「采集规则」与「采购规则」两类（标签页或两级菜单，以原型确认结果为准）。
  2. 采集规则的现有编辑界面整体迁入，功能与行为不变；原有入口收敛到规则中心内，不保留两处并存的入口。
  3. 采购规则复用同一套列表、搜索与版本展示框架，但编辑器与校验独立；入口与视觉上必须与采集规则明确区隔，避免误编辑。
  4. 采购规则保存时二次确认——该规则包含 createOrder 与 updateShippingAddress 等不可逆动作。
  5. 「规则中心」为暂定名称，最终以原型确认为准。不建议采用「Agent 规则」：Agent 在本项目已指代 Android 客户端本身，以及 AgentManualCollectionSetting 中的「Agent 手动采集规则」，复用会产生歧义。

四、实施顺序（明确分阶段）

界面与后端解耦，后端不等原型：

  1. 第一阶段（可立即开工，不依赖任何界面）：数据模型（purchase_rule + purchase_rule_setting）、迁移与初始记录、服务端规则来源切换、Admin 接口与权限登记。此阶段完成后采购规则只能通过接口维护，界面上尚无规则中心。
  2. 第二阶段：产出「规则中心」原型，提交用户确认。按 AGENTS.md 双门禁，导航变化与新模块必须先经原型确认，确认前不得编写前端生产代码。
  3. 第三阶段：按已确认原型实施前端，采集规则入口迁移与采购规则新入口同时落地。

第一阶段可与第二阶段并行；第三阶段严格等待第二阶段确认。

五、后续工单说明

原风险段提到的「后续工单：规则中心聚合视图与模块改名」不再单独建单，该范围已并入本工单的第二、三阶段。

六、验收标准补充

在正文既有验收标准基础上增加：

  • 规则中心内可分别管理采集规则与采购规则，两者入口与编辑界面明确区隔。
  • 采集规则迁入后功能与行为不变：编辑、校验、快照、接口路径与迁移前一致（以现有采集相关测试全部通过为准）。
  • 采集规则不存在两处并存的入口。
  • 采购规则保存时有二次确认。
  • 第一阶段单独交付时，采购创建流程可通过接口正常工作，不依赖前端改动。

七、文档影响补充

在正文既有文档影响基础上增加：Wiki Architecture-and-Code-Map 需记录规则中心的入口结构与「产品层统一、数据层分离」的边界；若采集规则的接口路径未变，则 Android-Agent-API-Contract 中采集部分无需改动，实施时确认并在工单说明。

正文的目标、安全边界、验证方式与依赖风险其余部分不变。

## 修订：界面部分改为「规则中心」一次到位 用户于 2026-08-28 确认：采集规则与采购规则统一收进「规则中心」，下分两类。本评论修订正文「非目标」与「实施方案 → 四、Admin 界面」，覆盖此前「不做模块合并与改名」「不改导航结构与模块名称」的表述。 ### 一、修订原因 正文原写「提供采购规则编辑入口，本工单不改导航结构与模块名称」，该表述自相矛盾：**新增一个入口本身就是导航变化**，同样需要设计证据。按原计划会产生两次界面变动——先加一个临时的「采购规则」入口，之后再合并改名——用户需要重新适应两次导航，设计证据也要出两轮。 既然界面部分本就卡在设计证据之后，原型直接按目标形态绘制，导航只动一次。 ### 二、非目标修订 删除原非目标中的「不做模块合并与改名」一条，替换为： - 不合并两种规则的 schema：采集规则（schemaVersion 2，描述性配置）与采购规则（schemaVersion 1，类型化动作序列）的校验器保持独立，不共用编辑器。 - 不合并数据层：两张独立表、两套校验器、两套权限点保持不变。「规则中心」只是产品层面的统一入口，不是数据层面的合并。 - **不改变采集规则的既有功能**：编辑界面、校验逻辑、快照机制、接口路径与行为一律保持原样，仅入口位置发生变化。不得借入口迁移顺手重构采集规则相关代码。 其余非目标不变（不实现支付、不放宽禁止清单、不改 Agent 代码与采购执行逻辑、不做停用开关）。 ### 三、Admin 界面修订 原第四节替换为： 11. 新增「规则中心」作为统一入口，下分「采集规则」与「采购规则」两类（标签页或两级菜单，以原型确认结果为准）。 12. 采集规则的现有编辑界面整体迁入，**功能与行为不变**；原有入口收敛到规则中心内，不保留两处并存的入口。 13. 采购规则复用同一套列表、搜索与版本展示框架，但编辑器与校验独立；入口与视觉上必须与采集规则明确区隔，避免误编辑。 14. 采购规则保存时二次确认——该规则包含 `createOrder` 与 `updateShippingAddress` 等不可逆动作。 15. 「规则中心」为暂定名称，最终以原型确认为准。**不建议采用「Agent 规则」**：`Agent` 在本项目已指代 Android 客户端本身，以及 `AgentManualCollectionSetting` 中的「Agent 手动采集规则」，复用会产生歧义。 ### 四、实施顺序（明确分阶段） 界面与后端解耦，后端不等原型： 1. **第一阶段（可立即开工，不依赖任何界面）**：数据模型（`purchase_rule` + `purchase_rule_setting`）、迁移与初始记录、服务端规则来源切换、Admin 接口与权限登记。此阶段完成后采购规则只能通过接口维护，界面上尚无规则中心。 2. **第二阶段**：产出「规则中心」原型，提交用户确认。按 `AGENTS.md` 双门禁，导航变化与新模块必须先经原型确认，确认前不得编写前端生产代码。 3. **第三阶段**：按已确认原型实施前端，采集规则入口迁移与采购规则新入口同时落地。 第一阶段可与第二阶段并行；第三阶段严格等待第二阶段确认。 ### 五、后续工单说明 原风险段提到的「后续工单：规则中心聚合视图与模块改名」不再单独建单，该范围已并入本工单的第二、三阶段。 ### 六、验收标准补充 在正文既有验收标准基础上增加： - [ ] 规则中心内可分别管理采集规则与采购规则，两者入口与编辑界面明确区隔。 - [ ] 采集规则迁入后功能与行为不变：编辑、校验、快照、接口路径与迁移前一致（以现有采集相关测试全部通过为准）。 - [ ] 采集规则不存在两处并存的入口。 - [ ] 采购规则保存时有二次确认。 - [ ] 第一阶段单独交付时，采购创建流程可通过接口正常工作，不依赖前端改动。 ### 七、文档影响补充 在正文既有文档影响基础上增加：Wiki `Architecture-and-Code-Map` 需记录规则中心的入口结构与「产品层统一、数据层分离」的边界；若采集规则的接口路径未变，则 `Android-Agent-API-Contract` 中采集部分无需改动，实施时确认并在工单说明。 正文的目标、安全边界、验证方式与依赖风险其余部分不变。
ila commented 2026-08-29 21:07:05 +08:00
Author
Owner
Copy Link
Copy Source

#127 + #146 v1 标注稿待确认（2026-08-29）

  • 设计证据：查看 #127 + #146 v1 标注稿
  • 版本识别：GoAuto #127 + #146 v1
  • 形式：Gitea 在线 SVG 标注稿（HTTP 200，image/svg+xml）
  • 状态：待用户确认；尚未编写生产代码、执行迁移或修改权限

对既有方案的必要修订

#127 最后一次评论提出“规则中心”，但之后 #142 v2 已由用户确认并实施，当前长期导航事实是“采采管理”直接包含业务页面且不增加第三级。为避免回退已验收设计，本版以较新的 #142 为准：

  • 在“采采管理”中新增与“采集规则”同级的“采购规则”；
  • 不新建“规则中心”，不移动或重命名“采集规则”；
  • 采购规则仍使用独立 schema、接口、权限和编辑器。

覆盖范围

  1. 管理员采购规则列表、当前生效标识、创建/编辑/设为当前。
  2. #146 priceGuard.minRatio / maxRatio 两个可见标签、范围、默认值与错误提示位置。
  3. 保存加载/失败/禁用状态及不可逆动作二次确认。
  4. 采购员不显示写入口，服务端权限仍为最终边界。
  5. 空、加载、接口失败沿用现有 Element Plus 表格/表单状态，不新增交互范式。

设计确认后仍须用户单独明确授权 #127 的追加数据库迁移，才能进入生产实施。

## #127 + #146 v1 标注稿待确认（2026-08-29） - 设计证据：[查看 #127 + #146 v1 标注稿](https://git.ilapage.cn/attachments/aa582714-16ec-4b13-8526-3fe05ff402ed) - 版本识别：`GoAuto #127 + #146 v1` - 形式：Gitea 在线 SVG 标注稿（HTTP 200，`image/svg+xml`） - 状态：待用户确认；尚未编写生产代码、执行迁移或修改权限 ### 对既有方案的必要修订 #127 最后一次评论提出“规则中心”，但之后 #142 v2 已由用户确认并实施，当前长期导航事实是“采采管理”直接包含业务页面且不增加第三级。为避免回退已验收设计，本版以较新的 #142 为准： - 在“采采管理”中新增与“采集规则”同级的“采购规则”； - 不新建“规则中心”，不移动或重命名“采集规则”； - 采购规则仍使用独立 schema、接口、权限和编辑器。 ### 覆盖范围 1. 管理员采购规则列表、当前生效标识、创建/编辑/设为当前。 2. #146 `priceGuard.minRatio / maxRatio` 两个可见标签、范围、默认值与错误提示位置。 3. 保存加载/失败/禁用状态及不可逆动作二次确认。 4. 采购员不显示写入口，服务端权限仍为最终边界。 5. 空、加载、接口失败沿用现有 Element Plus 表格/表单状态，不新增交互范式。 设计确认后仍须用户单独明确授权 #127 的追加数据库迁移，才能进入生产实施。
ila commented 2026-08-29 21:10:49 +08:00
Author
Owner
Copy Link
Copy Source

用户于 2026-08-29 明确确认 #127 + #146 v1 标注稿，并授权 #127 按工单方案实施追加数据库迁移。按较新的 #142 导航事实实施：在“采采管理”下新增同级“采购规则”，不引入第三级规则中心。现从 #127 开始实施；不执行支付、真实采购或未授权的数据删除。

用户于 2026-08-29 明确确认 `#127 + #146 v1` 标注稿，并授权 #127 按工单方案实施追加数据库迁移。按较新的 #142 导航事实实施：在“采采管理”下新增同级“采购规则”，不引入第三级规则中心。现从 #127 开始实施；不执行支付、真实采购或未授权的数据删除。
ila commented 2026-08-29 22:02:25 +08:00
Author
Owner
Copy Link
Copy Source

已按已确认的 #127+#146 v1 实施并推送，现转待验收。

实现：

  • 新增采购规则、当前规则设置及追加迁移；迁移会写入与原有 live rule 字节一致的初始规则并设为当前规则。
  • Admin 新增“采购规则”菜单与管理页，支持新增、编辑、切换当前规则、删除非当前规则。
  • 批量预览/创建、批量重试和同任务重置均读取当前数据库规则；既有任务继续使用自身快照。
  • 当前规则缺失或无效时显式返回 CURRENT_PURCHASE_RULE_MISSING，不回退代码常量。

提交：148ba96；测试夹具补充：5d85625；共享文档：1ec895b。
验证：相关 Go 单测、go test ./...、Server build、Web 定向 lint、Web build:prod、DevHarness strict check 均通过。
Wiki：Business Rules 96b59298692b897eb64f06a1d9c7ab03282fa7ad；API Contract 811176b77b923111b5ee972b421716ea224a3a96；Architecture d94641e4574e064395edb9da4b52b1a268925923；Local Dev 88cbef39a8744753021b82f2c97879db29e320d4。

边界：本次仅实现并测试追加迁移，未执行本机/正式数据库迁移，等待单独执行授权。

已按已确认的 #127+#146 v1 实施并推送，现转待验收。 实现： - 新增采购规则、当前规则设置及追加迁移；迁移会写入与原有 live rule 字节一致的初始规则并设为当前规则。 - Admin 新增“采购规则”菜单与管理页，支持新增、编辑、切换当前规则、删除非当前规则。 - 批量预览/创建、批量重试和同任务重置均读取当前数据库规则；既有任务继续使用自身快照。 - 当前规则缺失或无效时显式返回 CURRENT_PURCHASE_RULE_MISSING，不回退代码常量。 提交：148ba96；测试夹具补充：5d85625；共享文档：1ec895b。 验证：相关 Go 单测、go test ./...、Server build、Web 定向 lint、Web build:prod、DevHarness strict check 均通过。 Wiki：Business Rules 96b59298692b897eb64f06a1d9c7ab03282fa7ad；API Contract 811176b77b923111b5ee972b421716ea224a3a96；Architecture d94641e4574e064395edb9da4b52b1a268925923；Local Dev 88cbef39a8744753021b82f2c97879db29e320d4。 边界：本次仅实现并测试追加迁移，未执行本机/正式数据库迁移，等待单独执行授权。
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#127