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

docs/admin/01-requirements.md

@@ -415,6 +415,32 @@ Admin 本地时区，付款状态只是 Client 核单上报时的快照，Admin
 - “AI规格匹配”是当前有效映射的来源筛选，不替代“可创建采购任务”等业务阶段。人工修改后
   当前来源立即变为人工，但历史 AI 决策和批次记录继续保留。
 
+### 4.7 采购运行时真机规格解析（#255）
+
+采购任务已经在 Client 上选定颜色，但任务目标尺码和当前 PDD 页面文字无法精确对应时，
+Client 可以把这一刻页面显示的可购买尺码提交给 Admin 做一次解析。该能力只用于解决
+“任务规格与真机候选文字不一致”，不会改变正常精确匹配流程。
+
+- Admin 必须先核对采购任务、任务版本、PDD 商品、任务原始规格和该 Client 的领取历史；
+  任一身份不一致都拒绝，并且不产生解析决策。
+- 候选编号、原文、颜色和尺码由 Client 按页面顺序固定。Admin 重新计算候选快照哈希，
+  AI 只能选择本次请求内的候选短编号，不能生成或改写 PDD 规格。
+- 先执行确定性规则：忽略大小写、空白和分隔符，处理已明确的繁简差异，并支持唯一的
+  `kg / 公斤 / 千克 / 斤` 单值或正向区间等价。只有唯一候选等价时才自动返回；多个等价、
+  倒序或多个候选同时重叠时直接返回 `uncertain`，不交给 AI 猜一个。
+- 规则没有唯一结论时才使用当前已启用且通过连接测试的 AI 配置；模型结论仍须通过候选
+  白名单、冲突/缺失维度和管理员置信度阈值门禁。模型超时、格式错误或越权候选都形成
+  可审计结论，不把模型输出直接写进任务。
+- `pdd_products.skus_json.spec_source=shopee_backfill` 只用于诊断规格来源，既不自动触发 AI，
+  也不拒绝本次解析；是否需要解析只由真机候选和任务目标能否唯一对应决定。
+- 相同任务、执行尝试和候选快照幂等重放时返回第一次的完整响应；并发相同请求只完成一条
+  最终决策。候选观察与最终决策分两个短事务，调用模型期间不持有数据库事务。
+- 解析记录是只追加的运行审计。它不得修改 `tasks` 状态、版本、目标规格、价格、
+  `task_runs.irreversible_action_at` 或 `pdd_products.skus_json`，也不得保存控件树、截图、订单、
+  收货信息、Cookie、Token 或 API Key。
+- Admin 返回候选后，Client 仍须重新读取页面并继续执行商品、规格、数量、总价、地址、
+  不可逆标记和单次提交门禁；运行时解析不能绕过任何真实下单安全检查。
+
 ## 5. 创建采购任务的校验
 
 `[必须]` 下面任何一条不满足就不允许创建，并明确告诉操作员缺什么：

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 启动时把遗留的