feat: 实现采购运行时规格解析 (#255)

docs/admin/02-architecture.md

@@ -248,6 +248,8 @@ handler 返回批次 JSON；管理员在统一导入记录页查看摘要
 - Admin 是任务的创建者和分配者，Client 是执行者。
 - Admin **不知道** Client 执行到哪一步（没有心跳，是有意的）。
 - Client 提交结果时，Admin **无条件接受**，哪怕任务已取消或已重派。
+- Client 的运行时规格解析是 `POST /api/v1/client/tasks/{task_id}/spec-resolution` 一次性命令，
+  不是任务状态查询或轮询；权威字段、哈希和错误码仍以 Client 侧契约 §7.1 为准。
 - Admin 用户登录与 Client 身份是两套边界。Web Session 不传给 Client，
   Web 登录中间件也不覆盖 `/api/v1/client/*`。
 - 详见 [04 Client 接口实现](04-client-api.md)。
@@ -269,6 +271,21 @@ URL 内凭据、环回、链路本地、云元数据和未显式允许的私网
 唯一确定的规则结果不调用模型；有效人工映射始终优先。保存前重新计算上下文版本并检查
 当前可购买候选，防止 PDD 重采集或人工并发修改后写入过期结果。
 
+采购运行时规格解析复用同一个 `AISecretStore`、端点策略、HTTP 客户端、超时、响应结构
+校验和置信度阈值，但不复用 SYB 映射写入路径。Handler 只限制 64 KiB 请求体并翻译稳定
+错误码；`service/purchase_spec_resolution.go` 负责请求/哈希/任务身份校验、规则优先和 AI
+候选白名单；`repository/purchase_spec_resolution.go` 只保存观察和最终决策。
+
+一次解析分成以下三个边界：
+
+1. 短事务核对任务和领取历史，写入 `purchase_spec_resolutions.outcome=pending` 候选观察；
+2. 事务外执行确定性规则或调用模型，同一进程内相同幂等身份串行，避免并发重复调用；
+3. 短事务把 `pending` 完成一次，并与 `idempotency_keys` 的完整响应一起提交。
+
+服务中断后留下的 `pending` 可以由原幂等请求接管；最终 SQL 仍只允许第一次从 `pending`
+完成。响应中的 `match` 必须从保存的请求候选逐字重建。此链路不更新任务、PDD 商品和
+下单执行状态；`shopee_backfill` 只保留为来源诊断信号，不参与启用或拒绝判断。
+
 批量入口先在事务中创建 `ai_match_batches` 和逐条 `ai_match_batch_items`，再由 Admin 进程内
 的有界工作池执行。工作池按业务上下文哈希归并相同明细，运行中持续写入逐条状态和汇总计数；
 浏览器只轮询批次状态接口，不持有 API Key，也不承担匹配判断。Admin 启动时把遗留的