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

SYB PDD订单号自动回填与采购管理批量补偿 #305

New Issue
Open
opened 2026-09-17 18:07:50 +08:00 by ila · 5 comments
ila commented 2026-09-17 18:07:50 +08:00
Owner
Copy Link
Copy Source

实施状态（2026-09-18）：v1已确认，#305/#306已合并main并完成线上迁移、权限对账及Server/Web发布。运行代码7e257ca，发布记录65d1f34；健康/资源/认证接口验证通过，真实SYB回填端到端待用户验收。

原始需求摘要

  • 来源：用户于 2026-09-17 提出，内部系统不设置支付确认或复杂权限门禁；Agent 已能把采购成功后的 PDD 订单号提交给 Admin，需要将订单号回填到对应 SYB 订单商品明细。
  • 已提供抓包证据：工作区 update_syb_pdd_order_number.har。HAR 含真实业务标识，只作为本地分析证据，不得提交 Git、工单或 Wiki。
  • 交互方向：Agent 上报成功后自动回填；采购管理提供批量补偿/重试入口。

Gitea MCP 在本会话未提供可调用工具，本工单按仓库规则回退到 Gitea API 创建；凭据仅从本机安全环境读取，未写入工单或仓库。

目标

  1. 对实时 SYB 采购任务，在 Agent 成功提交 PDD 订单号后，服务端异步回填到准确的 SYB 商品明细。
  2. 在 Admin「采购管理」提供批量补偿入口，支持历史记录及自动回填失败记录重新发起。
  3. 通过写前、写后回读保证同值幂等，正确处理写入结果未知和远端已有不同订单号。
  4. 逐条记录回填状态和失败原因，一条失败不影响同批其他任务。

非目标

  • 不执行付款，不增加自动支付能力。
  • 不等待或校验支付状态；无 paid 门禁。
  • 不回填物流/快递单号；该范围属于 #37。
  • 不修改 Agent 的下单流程和订单号识别逻辑。
  • 不上传、保存或输出 HAR 中的真实订单、Cookie、个人数据。
  • 不自动覆盖 SYB 中已经存在的不同采购单号。

当前事实与接口证据

代码事实

  • purchase_task 已保存 pdd_order_no、order_submitted_at，并关联 syb_product_id。
  • syb_product 已保存 SYB stock_id 和 detail_id，可精确定位货运单内的商品明细。
  • sybclient.Client 已持久化并恢复 SYB Cookie 会话，所有请求统一解析 {status,msg,data,code}。
  • 现有 writeback_status、tracking_no 用于 #37 物流回填，不得复用为本工单的 PDD 订单号回填状态。

HAR 实测事实

POST /am/stock/detail/updateDetailPurchaseCode
  ?code=<PDD订单号>
  &type=pdd
  &created=
  &cost=0
  &id=<stock.id>
  &detailId=<details[].id>
  • 请求无 JSON body；HAR 样本返回 HTTP 200、status=true、msg=更新成功。
  • 随后的 POST /am/stock/detail/listByStock?hist=0 回读中：目标 stock.id、details[].id 精确命中，purchaseCode 与提交值一致，purchasePlatform=pdd，purchaseStatus=1，purchaseTime 由 SYB 生成。
  • 该操作不是纯展示字段更新，会把该明细标记为已采购。
  • HAR 未证明重复写入和已有不同订单号时的远端行为，客户端必须用前后回读规避。

前置依赖与并行性

  • 依赖现有 Agent order_created 结果落库、SYB 会话恢复、DetailListByStock 查询能力。
  • 与 #37 可在需求层并行，但实现时不得复用或改写 #37 的物流回填字段/状态。
  • 涉及数据库迁移和外部写操作：实施迁移、真实 SYB 写入及发布前必须再次取得用户明确授权。

影响范围

  • Server：采购结果编排、SYB 客户端写接口、异步回填执行器、Admin API、数据库迁移。
  • Web：采购管理列表的状态展示、批量回填和单条重试。
  • Android：无代码变化，仅复用已上报的 PDD 订单号。
  • 文档：SYB ERP 接口、采购业务规则/API、部署与任务运行说明（如新增常驻 worker/调度行为）。

方案

1. 独立状态与持久任务

不得复用物流 writeback_status。采用独立、可持久化的 PDD 采购单号回填记录或等价的独立字段，至少保存：

  • purchase_task_id（唯一关联）；
  • 状态：pending / running / succeeded / failed / conflict / unknown；
  • 请求 ID（唯一，用于 Admin 命令幂等）；
  • 尝试次数、最后错误码/脱敏错误说明；
  • 已回填 PDD 单号快照、完成时间；
  • 创建/更新时间。

具体使用独立表还是 purchase_task 独立字段，在实施前按现有迁移兼容性确定；不得改变 #37 字段语义。

2. 自动触发

  • Agent order_created 结果完成本地事务后，仅把符合条件的任务置为 pending，不得在 Agent 回调事务中同步调用 SYB。
  • 条件仅为：实时 SYB 采购任务、存在 syb_product_id、有效 pdd_order_no、任务已进入 order_created。
  • 不检查 payment_review_status。
  • 后台执行必须有租约或原子抢占，防止多实例重复并发写同一任务。

3. SYB 写入契约

新增 sybclient 方法（命名按代码风格确定），参数使用：

  • id = SYBProduct.StockID
  • detailId = SYBProduct.DetailID
  • code = strings.TrimSpace(PurchaseTask.PDDOrderNo)
  • type = pdd
  • created = ""
  • cost = 0

校验正整数 ID、订单号非空且不超过现有任务字段长度；不根据单个 HAR 样本硬编码订单号正则。

4. 写前与写后回读

每条任务独立执行：

  1. 用 listByStock 回读并按 stockId + detailId 精确定位。
  2. 远端 purchaseCode 与目标相同且 purchasePlatform=pdd：不写，直接成功。
  3. 远端采购单号非空且不同：状态记 conflict，不得静默覆盖。
  4. 远端为空：发送一次更新请求。
  5. 响应成功后再次回读；仅在 purchaseCode 和 purchasePlatform 一致时记成功。
  6. 网络超时、连接中断、5xx、响应损坏等结果未知：不得自动重发写请求；先回读，相同则成功，否则记 unknown/失败并等待人工批量补偿。
  7. 明确业务失败直接记失败，保留脱敏原因。

5. Admin 交互

  • 采购管理列表展示独立的“SYB 单号回填状态”。
  • 复用现有列表勾选和工具栏模式，增加“批量回填 SYB”按钮。
  • 允许勾选具有 SYB 关联和 PDD 订单号的记录；后端仍逐条校验，不依赖前端可信判断。
  • 失败、冲突、结果未知记录提供查看原因；失败/未知可单条重新发起。冲突不得自动覆盖。
  • 批量结果逐条返回成功、跳过、冲突或失败；部分失败不回滚成功项。
  • 不新增支付审核、角色授权或二次人工审批门禁；沿用采购管理现有访问权限。

设计证据

这是现有采购管理页的小范围列表/工具栏变更，不要求完整新页面原型。实施前需补充并由用户确认一份标注截图或低保真图，至少覆盖：

  • 正常、处理中、成功、失败、冲突/结果未知状态；
  • 无 PDD 单号时的禁用状态；
  • 批量执行后的逐条结果；
  • 单条重试入口和失败说明。

API 契约建议

最终路径遵循现有 Admin API 风格，至少提供等价能力：

  • 批量发起：请求包含 requestId、purchaseTaskIds[]；
  • 单条重试：请求包含新的 requestId；
  • 采购任务查询返回独立的 PDD 单号回填状态、完成时间和脱敏错误信息。

同一 requestId 必须幂等；重复请求返回原结果，不重复调 SYB 写接口。

验收标准

  • Agent 上报 order_created 后，符合条件的任务自动进入独立回填队列，无支付审核门禁。
  • 正确使用 stock_id + detail_id 更新对应 SYB 商品明细，不误写同一货运单的其他商品。
  • 远端已是同一 PDD 单号时不发写请求并返回成功。
  • 远端已有不同单号时标记冲突，不覆盖。
  • 写入成功后回读确认 purchaseCode 和 purchasePlatform=pdd。
  • 写入结果未知时不自动盲重试，回读后正确收敛。
  • 采购管理可以批量补偿；批次内部分失败不影响其他成功项。
  • 不修改 #37 物流回填状态和行为。
  • HAR、Cookie、真实订单号及个人数据没有进入 Git、日志、工单或 Wiki。
  • UI 标注截图/低保真图已经用户确认。

验证要求

  • sybclient 单元测试：参数、成功信封、业务失败、会话失效、网络结果未知；断言写请求最多一次。
  • 服务测试：自动入队、并发抢占、同值幂等、不同值冲突、写后回读、部分成功、Admin 请求幂等。
  • 多商品货运单测试：只更新目标 detailId。
  • Web 测试：选择条件、批量动作、状态与逐条结果展示。
  • 执行受影响范围验证，并记录真实命令和结果。
  • 未经额外授权只使用 mock/fake SYB 验证；真实 SYB 回填属于外部写操作，必须单独授权后才能验收。

风险

  • 更新接口会同时改变 purchaseStatus、purchasePlatform 和 purchaseTime，不是单字段写入。
  • SYB 接口无官方文档，契约来自单次 HAR；远端升级可能改变行为。
  • 对结果未知请求盲目重发可能覆盖数据，因此必须回读收敛。
  • 一张货运单可包含多条商品明细，禁止仅按订单号或 stockId 更新。

文档影响

长期契约发生变化，实施完成后需要更新线上 Wiki 并回读 revision，再同步镜像：

  • SYB-ERP-Interface（对应 docs/12-syb-erp-interface.md）：补充 updateDetailPurchaseCode 请求、响应、写入副作用和结果未知规则。
  • 采购业务/API 契约页面：补充自动触发、独立状态、批量补偿和幂等规则。
  • 如引入新 worker 或启动方式变化，更新 Deployment-and-Operations。
> 实施状态（2026-09-18）：v1已确认，#305/#306已合并main并完成线上迁移、权限对账及Server/Web发布。运行代码7e257ca，发布记录65d1f34；健康/资源/认证接口验证通过，真实SYB回填端到端待用户验收。 ## 原始需求摘要 - 来源：用户于 2026-09-17 提出，内部系统不设置支付确认或复杂权限门禁；Agent 已能把采购成功后的 PDD 订单号提交给 Admin，需要将订单号回填到对应 SYB 订单商品明细。 - 已提供抓包证据：工作区 `update_syb_pdd_order_number.har`。HAR 含真实业务标识，只作为本地分析证据，不得提交 Git、工单或 Wiki。 - 交互方向：Agent 上报成功后自动回填；采购管理提供批量补偿/重试入口。 > Gitea MCP 在本会话未提供可调用工具，本工单按仓库规则回退到 Gitea API 创建；凭据仅从本机安全环境读取，未写入工单或仓库。 ## 目标 1. 对实时 SYB 采购任务，在 Agent 成功提交 PDD 订单号后，服务端异步回填到准确的 SYB 商品明细。 2. 在 Admin「采购管理」提供批量补偿入口，支持历史记录及自动回填失败记录重新发起。 3. 通过写前、写后回读保证同值幂等，正确处理写入结果未知和远端已有不同订单号。 4. 逐条记录回填状态和失败原因，一条失败不影响同批其他任务。 ## 非目标 - 不执行付款，不增加自动支付能力。 - 不等待或校验支付状态；无 `paid` 门禁。 - 不回填物流/快递单号；该范围属于 #37。 - 不修改 Agent 的下单流程和订单号识别逻辑。 - 不上传、保存或输出 HAR 中的真实订单、Cookie、个人数据。 - 不自动覆盖 SYB 中已经存在的不同采购单号。 ## 当前事实与接口证据 ### 代码事实 - `purchase_task` 已保存 `pdd_order_no`、`order_submitted_at`，并关联 `syb_product_id`。 - `syb_product` 已保存 SYB `stock_id` 和 `detail_id`，可精确定位货运单内的商品明细。 - `sybclient.Client` 已持久化并恢复 SYB Cookie 会话，所有请求统一解析 `{status,msg,data,code}`。 - 现有 `writeback_status`、`tracking_no` 用于 #37 物流回填，不得复用为本工单的 PDD 订单号回填状态。 ### HAR 实测事实 ```text POST /am/stock/detail/updateDetailPurchaseCode ?code=<PDD订单号> &type=pdd &created= &cost=0 &id=<stock.id> &detailId=<details[].id> ``` - 请求无 JSON body；HAR 样本返回 HTTP 200、`status=true`、`msg=更新成功`。 - 随后的 `POST /am/stock/detail/listByStock?hist=0` 回读中：目标 `stock.id`、`details[].id` 精确命中，`purchaseCode` 与提交值一致，`purchasePlatform=pdd`，`purchaseStatus=1`，`purchaseTime` 由 SYB 生成。 - 该操作不是纯展示字段更新，会把该明细标记为已采购。 - HAR 未证明重复写入和已有不同订单号时的远端行为，客户端必须用前后回读规避。 ## 前置依赖与并行性 - 依赖现有 Agent `order_created` 结果落库、SYB 会话恢复、`DetailListByStock` 查询能力。 - 与 #37 可在需求层并行，但实现时不得复用或改写 #37 的物流回填字段/状态。 - 涉及数据库迁移和外部写操作：实施迁移、真实 SYB 写入及发布前必须再次取得用户明确授权。 ## 影响范围 - Server：采购结果编排、SYB 客户端写接口、异步回填执行器、Admin API、数据库迁移。 - Web：采购管理列表的状态展示、批量回填和单条重试。 - Android：无代码变化，仅复用已上报的 PDD 订单号。 - 文档：SYB ERP 接口、采购业务规则/API、部署与任务运行说明（如新增常驻 worker/调度行为）。 ## 方案 ### 1. 独立状态与持久任务 不得复用物流 `writeback_status`。采用独立、可持久化的 PDD 采购单号回填记录或等价的独立字段，至少保存： - `purchase_task_id`（唯一关联）； - 状态：`pending / running / succeeded / failed / conflict / unknown`； - 请求 ID（唯一，用于 Admin 命令幂等）； - 尝试次数、最后错误码/脱敏错误说明； - 已回填 PDD 单号快照、完成时间； - 创建/更新时间。 具体使用独立表还是 `purchase_task` 独立字段，在实施前按现有迁移兼容性确定；不得改变 #37 字段语义。 ### 2. 自动触发 - Agent `order_created` 结果完成本地事务后，仅把符合条件的任务置为 `pending`，不得在 Agent 回调事务中同步调用 SYB。 - 条件仅为：实时 SYB 采购任务、存在 `syb_product_id`、有效 `pdd_order_no`、任务已进入 `order_created`。 - 不检查 `payment_review_status`。 - 后台执行必须有租约或原子抢占，防止多实例重复并发写同一任务。 ### 3. SYB 写入契约 新增 `sybclient` 方法（命名按代码风格确定），参数使用： - `id = SYBProduct.StockID` - `detailId = SYBProduct.DetailID` - `code = strings.TrimSpace(PurchaseTask.PDDOrderNo)` - `type = pdd` - `created = ""` - `cost = 0` 校验正整数 ID、订单号非空且不超过现有任务字段长度；不根据单个 HAR 样本硬编码订单号正则。 ### 4. 写前与写后回读 每条任务独立执行： 1. 用 `listByStock` 回读并按 `stockId + detailId` 精确定位。 2. 远端 `purchaseCode` 与目标相同且 `purchasePlatform=pdd`：不写，直接成功。 3. 远端采购单号非空且不同：状态记 `conflict`，不得静默覆盖。 4. 远端为空：发送一次更新请求。 5. 响应成功后再次回读；仅在 `purchaseCode` 和 `purchasePlatform` 一致时记成功。 6. 网络超时、连接中断、5xx、响应损坏等结果未知：不得自动重发写请求；先回读，相同则成功，否则记 `unknown`/失败并等待人工批量补偿。 7. 明确业务失败直接记失败，保留脱敏原因。 ### 5. Admin 交互 - 采购管理列表展示独立的“SYB 单号回填状态”。 - 复用现有列表勾选和工具栏模式，增加“批量回填 SYB”按钮。 - 允许勾选具有 SYB 关联和 PDD 订单号的记录；后端仍逐条校验，不依赖前端可信判断。 - 失败、冲突、结果未知记录提供查看原因；失败/未知可单条重新发起。冲突不得自动覆盖。 - 批量结果逐条返回成功、跳过、冲突或失败；部分失败不回滚成功项。 - 不新增支付审核、角色授权或二次人工审批门禁；沿用采购管理现有访问权限。 ## 设计证据 这是现有采购管理页的小范围列表/工具栏变更，不要求完整新页面原型。实施前需补充并由用户确认一份标注截图或低保真图，至少覆盖： - 正常、处理中、成功、失败、冲突/结果未知状态； - 无 PDD 单号时的禁用状态； - 批量执行后的逐条结果； - 单条重试入口和失败说明。 ## API 契约建议 最终路径遵循现有 Admin API 风格，至少提供等价能力： - 批量发起：请求包含 `requestId`、`purchaseTaskIds[]`； - 单条重试：请求包含新的 `requestId`； - 采购任务查询返回独立的 PDD 单号回填状态、完成时间和脱敏错误信息。 同一 `requestId` 必须幂等；重复请求返回原结果，不重复调 SYB 写接口。 ## 验收标准 - [ ] Agent 上报 `order_created` 后，符合条件的任务自动进入独立回填队列，无支付审核门禁。 - [ ] 正确使用 `stock_id + detail_id` 更新对应 SYB 商品明细，不误写同一货运单的其他商品。 - [ ] 远端已是同一 PDD 单号时不发写请求并返回成功。 - [ ] 远端已有不同单号时标记冲突，不覆盖。 - [ ] 写入成功后回读确认 `purchaseCode` 和 `purchasePlatform=pdd`。 - [ ] 写入结果未知时不自动盲重试，回读后正确收敛。 - [ ] 采购管理可以批量补偿；批次内部分失败不影响其他成功项。 - [ ] 不修改 #37 物流回填状态和行为。 - [ ] HAR、Cookie、真实订单号及个人数据没有进入 Git、日志、工单或 Wiki。 - [ ] UI 标注截图/低保真图已经用户确认。 ## 验证要求 - `sybclient` 单元测试：参数、成功信封、业务失败、会话失效、网络结果未知；断言写请求最多一次。 - 服务测试：自动入队、并发抢占、同值幂等、不同值冲突、写后回读、部分成功、Admin 请求幂等。 - 多商品货运单测试：只更新目标 `detailId`。 - Web 测试：选择条件、批量动作、状态与逐条结果展示。 - 执行受影响范围验证，并记录真实命令和结果。 - 未经额外授权只使用 mock/fake SYB 验证；真实 SYB 回填属于外部写操作，必须单独授权后才能验收。 ## 风险 - 更新接口会同时改变 `purchaseStatus`、`purchasePlatform` 和 `purchaseTime`，不是单字段写入。 - SYB 接口无官方文档，契约来自单次 HAR；远端升级可能改变行为。 - 对结果未知请求盲目重发可能覆盖数据，因此必须回读收敛。 - 一张货运单可包含多条商品明细，禁止仅按订单号或 `stockId` 更新。 ## 文档影响 长期契约发生变化，实施完成后需要更新线上 Wiki 并回读 revision，再同步镜像： - `SYB-ERP-Interface`（对应 `docs/12-syb-erp-interface.md`）：补充 `updateDetailPurchaseCode` 请求、响应、写入副作用和结果未知规则。 - 采购业务/API 契约页面：补充自动触发、独立状态、批量补偿和幂等规则。 - 如引入新 worker 或启动方式变化，更新 `Deployment-and-Operations`。
ila commented 2026-09-18 09:49:13 +08:00
Author
Owner
Copy Link
Copy Source

#305 v1 轻量低保真与实施前核验（2026-09-18，待用户确认）

用户本轮要求“先实施#305”。已核对 #306 分支 07a3817（基线main 9194fd6）的采购结果、订单回填、旧物流候选和采购管理页面。当前尚无本单代码、数据库迁移或真实SYB写入。本会话无Gitea MCP，按规则使用API回退。

必须接全的入口

  1. 普通采购 lifecycle.go：Agent 的 order_created 成功落库。
  2. 人工遍历订单 order_backfill.go：首次补回订单号，以及 already_backfilled 同号重放。后者也应幂等确保回填记录存在，不能被提前return漏掉。
  3. 已有历史记录通过本单的批量补偿入口处理；不在迁移时自动扫描并写入全部历史订单。

两个自动入口共用“确保回填记录存在”，在本地事务内持久化pending，由独立worker在事务提交后处理SYB。不得先提交订单后仅发易丢失的内存通知；SYB失败不撤销已取得的PDD订单事实。实付金额缺失/冲突不影响单号回填，金额不上传SYB。#306未部署不阻塞设计与mock开发，发布时单独核验其迁移依赖。

v1 列表低保真（仅合成占位，不含真实订单）

复用现有采购管理列表，不新建页面：

采购管理
[现有查询条件……]   [查询] [重置]
已选 3 条   [重试采购（1）]   [批量回填 SYB（2）]

选择 | 任务    | …… | 订单 / 支付 | SYB 单号回填       | 操作
[√]  | 示例-A  | …… | 示例订单-A  | 待回填             | 详情
[ ]  | 示例-B  | …… | 示例订单-B  | 回填中             | 详情
[ ]  | 示例-C  | …… | 示例订单-C  | 已回填             | 详情
[√]  | 示例-D  | …… | 示例订单-D  | 失败 · 会话失效    | 详情
[ ]  | 示例-E  | …… | 示例订单-E  | 单号冲突 · 查看原因 | 详情
[ ]  | 示例-F  | …… | 示例订单-F  | 结果待核对         | 详情
[√]  | 示例-G  | …… | 尚未取得    | 待取得订单号       | 详情

标注：

  • 已有勾选器现在仅允许失败采购重试，不能直接沿用该条件。改为允许“可重试采购 OR 可发起单号回填”的行，两个按钮分别筛选自己的子集、展示各自数量。绝不因扩展勾选而让已创建订单进入重试采购。
  • 新增一列“SYB 单号回填”，与采购状态和人工支付复核分开。按钮仅发起已选记录，不偷偷处理全表。
  • 未选中或没有符合条件的回填记录：批量按钮禁用；无单号、备货/演练、无SYB关联、处理中、不属于order_created的记录不参与回填。无单号不影响原来合法的失败采购重试。
  • 点击后显示“提交中…”并禁用重复点击；接受入队只叫“已加入回填”，不叫“回填成功”。
  • 批量即时结果复用结果弹窗：逐条显示“已加入回填 / 已回填 / 跳过 / 冲突 / 失败及原因”；后续由列表状态与详情查看完成结果。一条失败不撤销其他项。
  • 空列表保持“暂无采购任务”；页面加载失败沿用现有“重新加载”；请求超时提示“提交结果未确认，请刷新状态”，不假装整批失败。
  • 不增加支付确认、角色审批或二次确认弹窗；沿用采购管理现有访问范围，但后端逐条验证条件。
  • 不适用的备货任务显示“不适用”；已有不同远端单号显示“冲突”，不提供强制覆盖。

v1 详情低保真

订单与人工处理
[订单：示例订单-A，下单时间，实付价格（原样保留）]
[支付复核（原样保留）]  [物流（原样保留）]
[现有物流回填区域（保持原业务，避免与本单混淆）]

SYB 单号回填
状态：失败 / 结果待核对 / 已回填 /……
原因：会话失效，请恢复SYB登录后重试
完成时间：—
[重新回填 SYB]  （仅失败/结果待核对；未发起时为“回填 SYB”）

失败/unknown重试都先回读远端。同值直接成功；不同值保持冲突，不盲目覆盖。成功状态只表示已经回读确认目标明细purchaseCode和purchasePlatform=pdd，不表示付款。

后端具体方案（随v1一起确认）

  • 采用独立持久表 purchase_order_writeback，purchase_task_id唯一；保存stock/detail定位快照、单号快照、状态、尝试次数、租约/占用、脱敏错误和完成时间。不复用旧writeback_status及paid门槛。
  • 幂等批量命令保存requestId与规范化任务集/逐项接受结果；同requestId不同内容拒绝，相同内容返回原接受结果，不重发SYB写入。批次上限复用现有100条习惯。
  • 拟定 POST /api/admin/v1/purchase-tasks/syb-order-writeback，body={requestId,purchaseTaskIds[]}；单条按钮复用同接口传一个ID，不增加冗余接口。
  • Admin查询新增orderWriteback对象（状态/原因/完成时间/可重试），与物流writebackStatus分开。
  • worker以原子抢占/租约保证同一任务串行；不同采购任务指向相同stockId+detailId也必须序列化。遗留running/写入结果未知先回读，不能因重启或租约到期盲重发。
  • 若外部写请求超时且回读仍无法确认，落unknown等待人工补偿；只有再次回读确认远端为空且没有仍在运行的写入时才允许写，不用覆盖来解决不确定性。
  • 与SYB其他人工客户端不存在分布式事务，不能宣称远端原子CAS；该残余竞态在验收中说明。
  • SYB更新将明细标记已采购；参数保持HAR证明的type=pdd、created为空、cost=0，不带#306实付金额。
  • 旧“选为回填候选”是物流后续能力，不用其接口处理本单，不移除其原规则。

设计审核与停止点

  • 本评论即线上可访问的v1低保真审核稿；版本标识“#305 v1 / 2026-09-18”，App ID不适用（Gitea Markdown低保真，非QuantUX工程）。
  • 状态：草稿待确认；确认人/时间：待用户回复后登记。
  • 按工单原有设计门禁，等待用户确认v1后才写生产代码。当前不创建本地原型快照、不修改长期Wiki（仅目标设计，尚无长期实现变化）。
  • UI/UX检查采用 ui-ux-pro-max：复用列表多选、loading防重提交、逐条结果、失败下一步和文字状态，不增加独立管理页面或审批流程。
  • 真实数据库迁移、SYB写入与环境发布仍需对象明确的另行授权；本次后续代码测试默认只用fake/mock与隔离数据库。
## #305 v1 轻量低保真与实施前核验（2026-09-18，待用户确认） 用户本轮要求“先实施#305”。已核对 #306 分支 07a3817（基线main 9194fd6）的采购结果、订单回填、旧物流候选和采购管理页面。当前尚无本单代码、数据库迁移或真实SYB写入。本会话无Gitea MCP，按规则使用API回退。 ### 必须接全的入口 1. 普通采购 lifecycle.go：Agent 的 order_created 成功落库。 2. 人工遍历订单 order_backfill.go：首次补回订单号，以及 already_backfilled 同号重放。后者也应幂等确保回填记录存在，不能被提前return漏掉。 3. 已有历史记录通过本单的批量补偿入口处理；不在迁移时自动扫描并写入全部历史订单。 两个自动入口共用“确保回填记录存在”，在本地事务内持久化pending，由独立worker在事务提交后处理SYB。不得先提交订单后仅发易丢失的内存通知；SYB失败不撤销已取得的PDD订单事实。实付金额缺失/冲突不影响单号回填，金额不上传SYB。#306未部署不阻塞设计与mock开发，发布时单独核验其迁移依赖。 ### v1 列表低保真（仅合成占位，不含真实订单） 复用现有采购管理列表，不新建页面： 采购管理 [现有查询条件……] [查询] [重置] 已选 3 条 [重试采购（1）] [批量回填 SYB（2）] 选择 | 任务 | …… | 订单 / 支付 | SYB 单号回填 | 操作 [√] | 示例-A | …… | 示例订单-A | 待回填 | 详情 [ ] | 示例-B | …… | 示例订单-B | 回填中 | 详情 [ ] | 示例-C | …… | 示例订单-C | 已回填 | 详情 [√] | 示例-D | …… | 示例订单-D | 失败 · 会话失效 | 详情 [ ] | 示例-E | …… | 示例订单-E | 单号冲突 · 查看原因 | 详情 [ ] | 示例-F | …… | 示例订单-F | 结果待核对 | 详情 [√] | 示例-G | …… | 尚未取得 | 待取得订单号 | 详情 标注： - 已有勾选器现在仅允许失败采购重试，不能直接沿用该条件。改为允许“可重试采购 OR 可发起单号回填”的行，两个按钮分别筛选自己的子集、展示各自数量。绝不因扩展勾选而让已创建订单进入重试采购。 - 新增一列“SYB 单号回填”，与采购状态和人工支付复核分开。按钮仅发起已选记录，不偷偷处理全表。 - 未选中或没有符合条件的回填记录：批量按钮禁用；无单号、备货/演练、无SYB关联、处理中、不属于order_created的记录不参与回填。无单号不影响原来合法的失败采购重试。 - 点击后显示“提交中…”并禁用重复点击；接受入队只叫“已加入回填”，不叫“回填成功”。 - 批量即时结果复用结果弹窗：逐条显示“已加入回填 / 已回填 / 跳过 / 冲突 / 失败及原因”；后续由列表状态与详情查看完成结果。一条失败不撤销其他项。 - 空列表保持“暂无采购任务”；页面加载失败沿用现有“重新加载”；请求超时提示“提交结果未确认，请刷新状态”，不假装整批失败。 - 不增加支付确认、角色审批或二次确认弹窗；沿用采购管理现有访问范围，但后端逐条验证条件。 - 不适用的备货任务显示“不适用”；已有不同远端单号显示“冲突”，不提供强制覆盖。 ### v1 详情低保真 订单与人工处理 [订单：示例订单-A，下单时间，实付价格（原样保留）] [支付复核（原样保留）] [物流（原样保留）] [现有物流回填区域（保持原业务，避免与本单混淆）] SYB 单号回填 状态：失败 / 结果待核对 / 已回填 /…… 原因：会话失效，请恢复SYB登录后重试 完成时间：— [重新回填 SYB] （仅失败/结果待核对；未发起时为“回填 SYB”） 失败/unknown重试都先回读远端。同值直接成功；不同值保持冲突，不盲目覆盖。成功状态只表示已经回读确认目标明细purchaseCode和purchasePlatform=pdd，不表示付款。 ### 后端具体方案（随v1一起确认） - 采用独立持久表 purchase_order_writeback，purchase_task_id唯一；保存stock/detail定位快照、单号快照、状态、尝试次数、租约/占用、脱敏错误和完成时间。不复用旧writeback_status及paid门槛。 - 幂等批量命令保存requestId与规范化任务集/逐项接受结果；同requestId不同内容拒绝，相同内容返回原接受结果，不重发SYB写入。批次上限复用现有100条习惯。 - 拟定 POST /api/admin/v1/purchase-tasks/syb-order-writeback，body={requestId,purchaseTaskIds[]}；单条按钮复用同接口传一个ID，不增加冗余接口。 - Admin查询新增orderWriteback对象（状态/原因/完成时间/可重试），与物流writebackStatus分开。 - worker以原子抢占/租约保证同一任务串行；不同采购任务指向相同stockId+detailId也必须序列化。遗留running/写入结果未知先回读，不能因重启或租约到期盲重发。 - 若外部写请求超时且回读仍无法确认，落unknown等待人工补偿；只有再次回读确认远端为空且没有仍在运行的写入时才允许写，不用覆盖来解决不确定性。 - 与SYB其他人工客户端不存在分布式事务，不能宣称远端原子CAS；该残余竞态在验收中说明。 - SYB更新将明细标记已采购；参数保持HAR证明的type=pdd、created为空、cost=0，不带#306实付金额。 - 旧“选为回填候选”是物流后续能力，不用其接口处理本单，不移除其原规则。 ### 设计审核与停止点 - 本评论即线上可访问的v1低保真审核稿；版本标识“#305 v1 / 2026-09-18”，App ID不适用（Gitea Markdown低保真，非QuantUX工程）。 - 状态：草稿待确认；确认人/时间：待用户回复后登记。 - 按工单原有设计门禁，等待用户确认v1后才写生产代码。当前不创建本地原型快照、不修改长期Wiki（仅目标设计，尚无长期实现变化）。 - UI/UX检查采用 ui-ux-pro-max：复用列表多选、loading防重提交、逐条结果、失败下一步和文字状态，不增加独立管理页面或审批流程。 - 真实数据库迁移、SYB写入与环境发布仍需对象明确的另行授权；本次后续代码测试默认只用fake/mock与隔离数据库。
ila commented 2026-09-18 09:52:39 +08:00
Author
Owner
Copy Link
Copy Source

2026-09-18 用户确认 #305 v1 设计通过，开始实施。设计依据 comment-8314；基于 #306 的 07a3817 建立 feat/305-syb-order-writeback 隔离工作区，保留原目录改动。覆盖正常采购与手动订单回填两个入队入口、独立持久状态、SYB单次写入/前后回读、Admin批量补偿。只用fake/mock及隔离数据库验证；未授权真实SYB写入、业务库迁移、权限写入或发布，不执行。当前无Gitea MCP，沿用API回退。

2026-09-18 用户确认 #305 v1 设计通过，开始实施。设计依据 comment-8314；基于 #306 的 07a3817 建立 feat/305-syb-order-writeback 隔离工作区，保留原目录改动。覆盖正常采购与手动订单回填两个入队入口、独立持久状态、SYB单次写入/前后回读、Admin批量补偿。只用fake/mock及隔离数据库验证；未授权真实SYB写入、业务库迁移、权限写入或发布，不执行。当前无Gitea MCP，沿用API回退。
ila commented 2026-09-18 10:21:16 +08:00
Author
Owner
Copy Link
Copy Source

#305 实施完成，待验收（2026-09-18）

用户已于本轮确认 v1，设计依据 comment-8314，确认记录 comment-8316。采用线上 Markdown 低保真，无 QuantUX App ID，不导出原型或任务快照。本会话无可用 Gitea MCP，继续使用 API 回退。

实现与提交

分支 feat/305-syb-order-writeback，基于 #306 的07a3817：

  • e89de1a：Server/Web、独立迁移及测试。
  • 7e257ca：Wiki 回读后的5个长期镜像。
  • 均已推送；隔离工作区干净，未改原工作区、未合并 main。
  1. 普通采购 order_created 与人工 order-backfill 首次成功/同号 already_backfilled 均在本地事务内确保唯一回填记录。金额缺失或冲突不阻止单号队列；外部SYB失败不撤销订单事实。
  2. 独立 purchase_order_writeback / command / lease 三表，不复用物流字段。持久批量 requestId + 排序任务集幂等，最多100条；返回逐项受理结果，接受不代表最终写入成功。
  3. worker每3秒轮询，以2分钟数据库单例租约串行处理；写前保存起始标记和校验所有者。跨任务相同SYB明细的未确认写入阻止新写，崩溃恢复只读，不自动重发。
  4. 精确 stockId + detailId；写前同单号+pdd直接成功，异单号/不兼容平台conflict。写请求最多一次，不跟随重定向；写后及未知响应都回读确认。未确认unknown等待人工补偿。
  5. 只写订单号，created为空、cost固定0；实付金额不进入SYB。没有支付门槛、自动付款或新增审批。
  6. 采购管理增加状态列、工具栏批量回填、详情补偿与受理结果弹窗；混选时“采购重试”和“单号回填”各自过滤。旧物流逻辑保留，文字区分“SYB物流回填”。
  7. 新接口 POST /api/admin/v1/purchase-tasks/syb-order-writeback 沿用管理员/采购员权限，已纳入启动对账代码；没有执行业务库权限写入。界面按 ui-ux-pro-max 复用原组件，覆盖loading、禁用、文字状态与失败下一步，没有扩展新页面。

验收项对应验证

  • 自动入队：普通结果服务测试 + 人工首次回填/同号回放 + 事务回滚测试。
  • 唯一目标、多明细不串写：fake中同时包含无关detail，写方法断言stock/detail；重复目标拒绝。
  • 同值幂等、异值/异平台冲突、写后核对、未知不重复发送：11组远端结果测试。
  • 并发和恢复：第二worker抢占失败、崩溃running只回读、租约内手动补偿跳过、另一任务unknown阻止写入、订单事实变化拒绝。
  • Admin幂等/部分接受/权限：重复命令重放原接受结果、改变任务集拒绝、合法+不存在任务混合、admin/purchaser成功信封、未授权拒绝。
  • Web：混选任务分流、不把已下单任务交给采购重试、未支付详情补偿、冲突无覆盖按钮；保留金额/空值/未知采购结果回归。
  • 请求测试确认六个query参数、无body、cost=0、业务/登录/坏JSON/5xx处理及307不重发。
  • 局部迁移测试确认表结构、版本记录、不排入历史、不改变采购事实、重复schema操作不重置租约。

执行结果

通过：

  • go test ./app/goauto/purchase ./app/goauto/sybclient ./app/goauto/access ./app/goauto/migrations ./cmd/migrate/migration/version-local
  • go test ./app/goauto/clientkey ./app/goauto/purchasecontract
  • go build ./...
  • Web pnpm build:prod（已有CSS/包体积警告）
  • Playwright新增3例全部通过；连同金额/空值/未知结果3例，最终选定回归6/6通过。使用本地19528静态dist与全部mock API，临时服务已停止。
  • git diff --check
  • Wiki先更新并在线回读，再执行一次sync和一次sync --check：17个镜像全部一致。

已有基线失败，未掩盖/删除/放宽：

  • 全量 go test ./... 仅sybimport的12个旧解析用例失败，与此前基线核验一致；本单没有改该目录。其余包通过。
  • purchase-task-module首例旧1280布局“查询条件同一行”断言仍失败（#306时已复现）；其他3例通过。最终6例选择性回归明确排除该已知失败，不宣称全套E2E通过。
  • 修改页eslint为24错误/11警告，全部为已有tab/space缩进；通过git show HEAD基线内容核对为相同数量/规则，本单未新增lint项。
  • harness check --strict仍因基线 docs/evidence/pdd-home-35727-summary.md 未登记而失败（1项）；镜像一致性检查本身已通过。

长期文档与回读 revision

  • Android-Agent-API-Contract：5a61e4f2cf2bb33b824ca722e9cee03071e1dffd
  • Business-Rules-and-Glossary：f353b476add5081d4d7a1493e5454b6400518923
  • Architecture-and-Code-Map：c8dd6b1f25bf367d065e0969a4de858d857a3181
  • SYB-ERP-Interface-Contract：432e392ebe428ea19c0aa260f8e5938f36e4c3f0
  • Deployment-and-Operations：a630bab8f1c775ce9ed29cac990777b6760eeda4

每次Wiki写入显式带原title并对revision/正文回读校验，未重命名页面。未创建任务归档或额外文档。

未验证与下一步授权边界

  • 尚未执行业务MySQL迁移1789800200000、权限启动对账、重启/发布、真实SYB写入；没有Android改动，不需要为本单更换APK。
  • SQLite/模拟多worker测试不冒充生产MySQL多实例验证；真实SYB接口仅有原HAR协议证据，当前测试均fake/httptest。远端无CAS，系统外人工并发及任意延迟请求仍有残余竞态。
  • 下一步须明确本地或线上环境，授权#305迁移、权限对账、配套Server/Web发布及真实订单回填验证。发布前核验#306金额列前置（1789800100000）与该分支合并范围；重启将启用已排队记录的真实写入。不会自动批量回填历史记录，也不会改定时任务开关。
  • 工单保持open/待验收，不代用户关闭。
## #305 实施完成，待验收（2026-09-18） 用户已于本轮确认 v1，设计依据 [comment-8314](https://git.ilapage.cn/OPC/goauto/issues/305#issuecomment-8314)，确认记录 comment-8316。采用线上 Markdown 低保真，无 QuantUX App ID，不导出原型或任务快照。本会话无可用 Gitea MCP，继续使用 API 回退。 ### 实现与提交 分支 feat/305-syb-order-writeback，基于 #306 的07a3817： - e89de1a：Server/Web、独立迁移及测试。 - 7e257ca：Wiki 回读后的5个长期镜像。 - 均已推送；隔离工作区干净，未改原工作区、未合并 main。 1. 普通采购 order_created 与人工 order-backfill 首次成功/同号 already_backfilled 均在本地事务内确保唯一回填记录。金额缺失或冲突不阻止单号队列；外部SYB失败不撤销订单事实。 2. 独立 purchase_order_writeback / command / lease 三表，不复用物流字段。持久批量 requestId + 排序任务集幂等，最多100条；返回逐项受理结果，接受不代表最终写入成功。 3. worker每3秒轮询，以2分钟数据库单例租约串行处理；写前保存起始标记和校验所有者。跨任务相同SYB明细的未确认写入阻止新写，崩溃恢复只读，不自动重发。 4. 精确 stockId + detailId；写前同单号+pdd直接成功，异单号/不兼容平台conflict。写请求最多一次，不跟随重定向；写后及未知响应都回读确认。未确认unknown等待人工补偿。 5. 只写订单号，created为空、cost固定0；实付金额不进入SYB。没有支付门槛、自动付款或新增审批。 6. 采购管理增加状态列、工具栏批量回填、详情补偿与受理结果弹窗；混选时“采购重试”和“单号回填”各自过滤。旧物流逻辑保留，文字区分“SYB物流回填”。 7. 新接口 POST /api/admin/v1/purchase-tasks/syb-order-writeback 沿用管理员/采购员权限，已纳入启动对账代码；没有执行业务库权限写入。界面按 ui-ux-pro-max 复用原组件，覆盖loading、禁用、文字状态与失败下一步，没有扩展新页面。 ### 验收项对应验证 - 自动入队：普通结果服务测试 + 人工首次回填/同号回放 + 事务回滚测试。 - 唯一目标、多明细不串写：fake中同时包含无关detail，写方法断言stock/detail；重复目标拒绝。 - 同值幂等、异值/异平台冲突、写后核对、未知不重复发送：11组远端结果测试。 - 并发和恢复：第二worker抢占失败、崩溃running只回读、租约内手动补偿跳过、另一任务unknown阻止写入、订单事实变化拒绝。 - Admin幂等/部分接受/权限：重复命令重放原接受结果、改变任务集拒绝、合法+不存在任务混合、admin/purchaser成功信封、未授权拒绝。 - Web：混选任务分流、不把已下单任务交给采购重试、未支付详情补偿、冲突无覆盖按钮；保留金额/空值/未知采购结果回归。 - 请求测试确认六个query参数、无body、cost=0、业务/登录/坏JSON/5xx处理及307不重发。 - 局部迁移测试确认表结构、版本记录、不排入历史、不改变采购事实、重复schema操作不重置租约。 ### 执行结果 通过： - go test ./app/goauto/purchase ./app/goauto/sybclient ./app/goauto/access ./app/goauto/migrations ./cmd/migrate/migration/version-local - go test ./app/goauto/clientkey ./app/goauto/purchasecontract - go build ./... - Web pnpm build:prod（已有CSS/包体积警告） - Playwright新增3例全部通过；连同金额/空值/未知结果3例，最终选定回归6/6通过。使用本地19528静态dist与全部mock API，临时服务已停止。 - git diff --check - Wiki先更新并在线回读，再执行一次sync和一次sync --check：17个镜像全部一致。 已有基线失败，未掩盖/删除/放宽： - 全量 go test ./... 仅sybimport的12个旧解析用例失败，与此前基线核验一致；本单没有改该目录。其余包通过。 - purchase-task-module首例旧1280布局“查询条件同一行”断言仍失败（#306时已复现）；其他3例通过。最终6例选择性回归明确排除该已知失败，不宣称全套E2E通过。 - 修改页eslint为24错误/11警告，全部为已有tab/space缩进；通过git show HEAD基线内容核对为相同数量/规则，本单未新增lint项。 - harness check --strict仍因基线 docs/evidence/pdd-home-35727-summary.md 未登记而失败（1项）；镜像一致性检查本身已通过。 ### 长期文档与回读 revision - Android-Agent-API-Contract：5a61e4f2cf2bb33b824ca722e9cee03071e1dffd - Business-Rules-and-Glossary：f353b476add5081d4d7a1493e5454b6400518923 - Architecture-and-Code-Map：c8dd6b1f25bf367d065e0969a4de858d857a3181 - SYB-ERP-Interface-Contract：432e392ebe428ea19c0aa260f8e5938f36e4c3f0 - Deployment-and-Operations：a630bab8f1c775ce9ed29cac990777b6760eeda4 每次Wiki写入显式带原title并对revision/正文回读校验，未重命名页面。未创建任务归档或额外文档。 ### 未验证与下一步授权边界 - 尚未执行业务MySQL迁移1789800200000、权限启动对账、重启/发布、真实SYB写入；没有Android改动，不需要为本单更换APK。 - SQLite/模拟多worker测试不冒充生产MySQL多实例验证；真实SYB接口仅有原HAR协议证据，当前测试均fake/httptest。远端无CAS，系统外人工并发及任意延迟请求仍有残余竞态。 - 下一步须明确本地或线上环境，授权#305迁移、权限对账、配套Server/Web发布及真实订单回填验证。发布前核验#306金额列前置（1789800100000）与该分支合并范围；重启将启用已排队记录的真实写入。不会自动批量回填历史记录，也不会改定时任务开关。 - 工单保持open/待验收，不代用户关闭。
ila commented 2026-09-18 10:29:06 +08:00
Author
Owner
Copy Link
Copy Source

2026-09-18 用户明确授权“合并main，迁移，把最新代码部署到线上服务器”。已将#305及#306依赖快进合并main并推送7e257ca；线上185.216.248.75当前二进制标记60c7526，迁移51项已执行，仅缺1789800100000和1789800200000。上线前采集/采购执行中计数均0。沿用既有Nginx/systemd拓扑，先服务器内受限备份，再执行两项迁移、启动权限对账及Server/Web发布；保留任务开关，不批量排入历史回填，不付款。发现旧release static/var相互循环链接，新release将直接链接已确认存在的真实旧资源目录，不删除或改写历史资源。当前无Gitea MCP，按规则API回退。

2026-09-18 用户明确授权“合并main，迁移，把最新代码部署到线上服务器”。已将#305及#306依赖快进合并main并推送7e257ca；线上185.216.248.75当前二进制标记60c7526，迁移51项已执行，仅缺1789800100000和1789800200000。上线前采集/采购执行中计数均0。沿用既有Nginx/systemd拓扑，先服务器内受限备份，再执行两项迁移、启动权限对账及Server/Web发布；保留任务开关，不批量排入历史回填，不付款。发现旧release static/var相互循环链接，新release将直接链接已确认存在的真实旧资源目录，不删除或改写历史资源。当前无Gitea MCP，按规则API回退。
ila commented 2026-09-18 10:34:53 +08:00
Author
Owner
Copy Link
Copy Source

已授权合并、迁移与线上发布完成（2026-09-18）

  • 用户明确授权合并main、迁移、部署线上。#305及#306已快进合并main并推送；运行代码7e257ca，发布记录提交65d1f34（仅文档，未改变运行产物）。
  • 线上185.216.248.75新目录/home/goauto/releases/20260918-7e257ca-305；旧目录/home/goauto/releases/20260916-03647dd保留。服务器内数据库备份/home/goauto/backups/20260918-305/database.sql，39,879,933字节，文件0600；没有下载或输出生产数据。
  • 迁移核验：原51项，仅缺1789800100000、1789800200000；现两项均执行成功，金额nullable BIGINT、回填三表及单例租约已回读。没有批量排入历史订单，验证时队列0条。
  • 既有启动权限对账已登记新POST接口与purchaser权限。任务1/2的status=1、3/4/5的status=2保持不变；没有修改Cron、主动触发同步、创建采购订单或执行付款。
  • 新release只修正自身的资源链接：static直接引用20260907-29ba16e-236/static，var直接引用20260903-2d6d244-r1/var，均为确认存在的真实目录。旧release之间已有static/var循环，不再继承；不删除或覆盖历史资源。旧代码回滚路径保留，但其原循环问题仍须注意。
  • GoAuto服务重启、Nginx配置检查与reload完成；两服务active。公网Admin首页与10项JS/CSS资源HTTP200，/api/v1/health HTTP200。未认证采购接口业务码401；已登录采购列表200并含orderWriteback；新接口空批次422（无业务写入）。最近结构日志检查无panic/fatal/1146/1054。
  • main合并后重新运行受影响Server测试通过，Linux amd64二进制及Web生产构建通过。二进制本地与线上SHA256一致：4833d779843f0613455ea2b56cadff6efd88d2b96c13e00cb4423cac02e72cb7。
  • Deployment-and-Operations已更新并在线回读revision 26ff59a7203d84dfe1a8e929fda24204960f1d7c；随后一次sync与一次sync --check，17个镜像一致，镜像提交65d1f34已推送main。本次未改变其他长期契约。
  • #306已有APK可使用新服务端；本次无Android构建/安装或升级发布操作。没有以真实采购任务手动验证SYB写入，不把健康检查冒充回填端到端成功；后续正常上报可自动入队，历史订单仍需手动勾选补偿。
  • 当前代码、迁移及部署完成，工单保留open待用户验收。Gitea使用API回退，原因同前述记录。
## 已授权合并、迁移与线上发布完成（2026-09-18） - 用户明确授权合并main、迁移、部署线上。#305及#306已快进合并main并推送；运行代码7e257ca，发布记录提交65d1f34（仅文档，未改变运行产物）。 - 线上185.216.248.75新目录/home/goauto/releases/20260918-7e257ca-305；旧目录/home/goauto/releases/20260916-03647dd保留。服务器内数据库备份/home/goauto/backups/20260918-305/database.sql，39,879,933字节，文件0600；没有下载或输出生产数据。 - 迁移核验：原51项，仅缺1789800100000、1789800200000；现两项均执行成功，金额nullable BIGINT、回填三表及单例租约已回读。没有批量排入历史订单，验证时队列0条。 - 既有启动权限对账已登记新POST接口与purchaser权限。任务1/2的status=1、3/4/5的status=2保持不变；没有修改Cron、主动触发同步、创建采购订单或执行付款。 - 新release只修正自身的资源链接：static直接引用20260907-29ba16e-236/static，var直接引用20260903-2d6d244-r1/var，均为确认存在的真实目录。旧release之间已有static/var循环，不再继承；不删除或覆盖历史资源。旧代码回滚路径保留，但其原循环问题仍须注意。 - GoAuto服务重启、Nginx配置检查与reload完成；两服务active。公网Admin首页与10项JS/CSS资源HTTP200，/api/v1/health HTTP200。未认证采购接口业务码401；已登录采购列表200并含orderWriteback；新接口空批次422（无业务写入）。最近结构日志检查无panic/fatal/1146/1054。 - main合并后重新运行受影响Server测试通过，Linux amd64二进制及Web生产构建通过。二进制本地与线上SHA256一致：4833d779843f0613455ea2b56cadff6efd88d2b96c13e00cb4423cac02e72cb7。 - Deployment-and-Operations已更新并在线回读revision 26ff59a7203d84dfe1a8e929fda24204960f1d7c；随后一次sync与一次sync --check，17个镜像一致，镜像提交65d1f34已推送main。本次未改变其他长期契约。 - #306已有APK可使用新服务端；本次无Android构建/安装或升级发布操作。没有以真实采购任务手动验证SYB写入，不把健康检查冒充回填端到端成功；后续正常上报可自动入队，历史订单仍需手动勾选补偿。 - 当前代码、迁移及部署完成，工单保留open待用户验收。Gitea使用API回退，原因同前述记录。
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#305