feat: 定义运行时规格解析契约与审计模型 (#254)

docs/admin/03-data-model.md

@@ -127,6 +127,8 @@ v18（#208）新增 `shops` 业务店铺和 `shop_channel_aliases` 渠道名称
 名称精确回填，无法确认的记录保持未关联。
 v19（#212）将产品概念收敛为唯一店铺名称和唯一启停状态。迁移按“任一旧开关停用
 则保持停用”的安全规则合并 v18 状态，重建由 `shops` 派生的兼容数据和两侧关联。
+v26（#254）新增 `purchase_spec_resolutions`，用一张表保存采购执行中的候选观察、
+幂等身份和最终规格决策；不修改历史 SQLite migration，也不覆盖 PDD 商品主数据。
 
 **v3 为什么丢弃旧 `sku_mappings` 数据（见 #20）：** 新主键需要 `pdd_option_key`，
 这是 Go 的 `service.OptionKey()` 用 `json.Marshal` 算出来的规范化键，SQL 语句
@@ -884,8 +886,8 @@ syb_orders ─(shopee_goods_id, spec_key)─┘
    （skus_json 里是所有规格和价格）
 
 syb_orders ──创建──→ tasks ──分配──→ clients
-                                      ↑
-users（采购员）──1:N 当前归属──────────┘
+                         └──1:N──→ purchase_spec_resolutions
+users（采购员）──1:N 当前归属──────────→ clients
 ```
 
 两条关联都可以变，这是有意的：
@@ -906,6 +908,7 @@ Admin 使用集中 MySQL 8.4，Client 仍使用各自的本地 SQLite；两者
 | 任务编号 | `tasks.task_id` | `pdd_tasks.remote_task_id` |
 | 任务状态 | 7 个（§6） | 8 个，是本机执行状态 |
 | 采集结果 | `pdd_products.skus_json` | `pdd_tasks.pdd_data` |
+| 运行时规格解析 | `purchase_spec_resolutions` 候选观察与最终决策 | #257 在本地保存请求、幂等键和响应；原任务 payload 不覆盖 |
 
 `[必须]` **两边的状态是两套，不要试图同步。**
 Admin 只知道"发出去了 / 收到结果了"，中间过程看不到，这是有意的设计。
@@ -1052,3 +1055,93 @@ CREATE UNIQUE INDEX idx_client_assignment_current
   不新增批次表：提交时所选 `ready` 记录必须在同一事务内全部转为 `queued`；后台每次最多
   读取 20 条并逐条领取为 `applying`。页面按 `apply_batch_id` 聚合当前批次进度。Admin
   重启时，`queued` 恢复为 `ready` 且不会自动写远端，`applying` 转为 `needs_check`。
+
+## 18. `purchase_spec_resolutions` 采购运行时规格解析（MySQL v26）
+
+Client 在同一次采购中选中颜色后，如果任务尺码和 PDD 页面尺码无法精确对应，就通过
+[Client 接口契约](../client/04-admin-api-contract.md) §7.1 提交当前可购买候选。本表用
+**一条记录**同时保存候选观察、幂等身份和最终决策，不拆观察表、决策表或模型响应表。
+
+```sql
+CREATE TABLE purchase_spec_resolutions (
+    resolution_id          VARCHAR(191) COLLATE utf8mb4_bin PRIMARY KEY,
+    task_id                VARCHAR(191) COLLATE utf8mb4_bin NOT NULL,
+    attempt_id             VARCHAR(191) COLLATE utf8mb4_bin NOT NULL,
+    client_id              VARCHAR(191) COLLATE utf8mb4_bin NOT NULL,
+    task_version           BIGINT NOT NULL CHECK (task_version > 0),
+    pdd_goods_id           VARCHAR(191) COLLATE utf8mb4_bin NOT NULL,
+    original_options_json  JSON NOT NULL,
+    selected_color         VARCHAR(191) NOT NULL,
+    target_size            VARCHAR(191) NOT NULL,
+    candidates_json        JSON NOT NULL,
+    candidate_snapshot_hash CHAR(64) COLLATE utf8mb4_bin NOT NULL,
+    request_hash           CHAR(64) COLLATE utf8mb4_bin NOT NULL,
+    observed_at            VARCHAR(35) NOT NULL,
+
+    outcome                VARCHAR(16) NOT NULL DEFAULT 'pending',
+    decision_source        VARCHAR(16),
+    chosen_candidate_id    VARCHAR(16) COLLATE utf8mb4_bin,
+    resolved_options_json  JSON,
+    confidence_bps         INT,
+    reason                 VARCHAR(500),
+    provider_id            VARCHAR(191) COLLATE utf8mb4_bin,
+    source_model           VARCHAR(191),
+    config_fingerprint     CHAR(64) COLLATE utf8mb4_bin,
+    rules_version          VARCHAR(32),
+    prompt_version         VARCHAR(32),
+    created_at             VARCHAR(35) NOT NULL,
+    decided_at             VARCHAR(35),
+
+    UNIQUE KEY uq_purchase_spec_resolution_identity
+        (task_id, attempt_id, candidate_snapshot_hash),
+    KEY idx_purchase_spec_resolution_task
+        (task_id, created_at DESC, resolution_id),
+    KEY idx_purchase_spec_resolution_outcome
+        (outcome, created_at, resolution_id),
+    CONSTRAINT chk_purchase_spec_resolution_options CHECK (
+        JSON_TYPE(original_options_json) = 'OBJECT'
+        AND JSON_LENGTH(original_options_json) BETWEEN 1 AND 16
+        AND JSON_TYPE(candidates_json) = 'ARRAY'
+        AND JSON_LENGTH(candidates_json) BETWEEN 1 AND 100
+        AND (resolved_options_json IS NULL
+             OR JSON_TYPE(resolved_options_json) = 'OBJECT')),
+    CONSTRAINT chk_purchase_spec_resolution_outcome CHECK (
+        outcome IN ('pending', 'matched', 'uncertain', 'rejected', 'failed')),
+    CONSTRAINT chk_purchase_spec_resolution_source CHECK (
+        decision_source IS NULL OR decision_source IN ('rule', 'ai', 'reused')),
+    CONSTRAINT chk_purchase_spec_resolution_confidence CHECK (
+        confidence_bps IS NULL OR confidence_bps BETWEEN 0 AND 10000),
+    CONSTRAINT chk_purchase_spec_resolution_decision CHECK (
+        (outcome = 'pending' AND decided_at IS NULL
+         AND decision_source IS NULL AND chosen_candidate_id IS NULL
+         AND resolved_options_json IS NULL)
+        OR (outcome = 'matched' AND decided_at IS NOT NULL
+            AND decision_source IS NOT NULL AND chosen_candidate_id IS NOT NULL
+            AND resolved_options_json IS NOT NULL AND reason IS NOT NULL)
+        OR (outcome IN ('uncertain', 'rejected', 'failed')
+            AND decided_at IS NOT NULL AND chosen_candidate_id IS NULL
+            AND resolved_options_json IS NULL AND reason IS NOT NULL))
+);
+```
+
+- `(task_id, attempt_id, candidate_snapshot_hash)` 是业务唯一身份；`request_hash` 用于发现
+  同一身份改了目标尺码、候选原文或其他内容。HTTP 的 `idempotency_keys` 仍保存可安全
+  重放的完整响应，两层幂等不能互相替代。
+- `pending` 是内部恢复状态，不返回给 Client。先用短事务写候选观察，规则或 AI 调用在
+  事务外执行；最终 outcome 与 `idempotency_keys.response_body` 在另一个短事务一起提交。
+  崩溃留下 pending 时，相同请求读取原记录继续恢复，不能新建第二条。
+- `matched` 必须有来源、候选短编号、原始 options、原因和决定时间；候选必须逐字来自
+  `candidates_json`。`uncertain/rejected/failed` 不得填写候选和 resolved options，避免
+  Client 把不确定结果当作可点击规格。
+- `confidence_bps` 可空。NULL 表示规则或复用路径没有可比较分数，不得转换成 0；AI
+  分数使用 0～10000 基点。服务商、模型、配置指纹和规则/提示版本都是非敏感快照，
+  表中没有 API Key、完整提示词或完整模型响应。
+- 本表故意不设指向 `tasks` 或 `clients` 的外键。现有页面允许硬删除任务和临时 Client
+  清单记录，规格决策审计不能因此阻塞原流程或被级联删除；Repository 查询始终使用稳定
+  ID，不把缺少主表记录解释成新的业务状态。
+- 本表不参与任务状态机，不更新 `tasks.status/result_data`，也不写
+  `pdd_products.skus_json` 或长期 `spec_mappings`。它只回答这一执行尝试在这一候选快照下
+  可以安全选择哪个原始候选。
+- `original_options_json`、`candidates_json` 和 `resolved_options_json` 只保存接口定义的
+  颜色/尺码字符串。不得保存原始无障碍 XML、截图、订单号、收货信息、Cookie、Token、
+  密码或 API Key；时间统一保存为 UTC ISO 8601。

docs/admin/04-client-api.md

@@ -8,20 +8,25 @@
 
 本文档中 `[必须]` / `[建议]` / `[待定]` 的含义见 [文档索引](../README.md#文档标注说明)。
 
-## 1. 一共四个接口
+## 1. 一共五个接口
 
 ```http
 PUT  /api/v1/client/registration             登记或更新 Client
 POST /api/v1/client/tasks/claim              领一个任务
 POST /api/v1/client/tasks/{task_id}/result   提交成功结果
 POST /api/v1/client/tasks/{task_id}/failure  提交失败/需人工
+POST /api/v1/client/tasks/{task_id}/spec-resolution  一次性解析当前规格候选
 ```
 
+#254 冻结第五个接口的契约和审计模型；Handler、路由和匹配服务由 #255 实现。在 #255
+完成前，旧 Client 仍只使用原四个接口，新 Client 不得把路由尚未提供误判为可重试的 AI 失败。
+
 `task_id` 是不透明的稳定字符串，当前采集任务为 `cjN`、采购任务为
 `cgN`。Client 必须原样保存和回传，不校验旧前缀，不从编号推导类型；
 业务类型始终以响应中的 `type` 为准。
 
-`[必须]` **不得新增"让 Client 查询状态"类接口**，也不得加回租约和心跳。
+第五个接口只接收 Client 当下观察到的规格候选并同步返回一份持久化决策，不读取或返回
+任务调度状态。`[必须]` **不得新增“让 Client 查询状态”类接口**，也不得加回租约和心跳。
 理由见 Client 契约 §1.1：本项目人工付款，重复下单只产生重复的**未付款**订单，
 不值得为它引入一整套中断逻辑。
 
@@ -167,7 +172,7 @@ upsert clients：
 实现上就是 `ON CONFLICT ... DO UPDATE SET` 里**不包含 `name`**，
 不需要额外加"是否人工改过"的标记列。
 
-`[必须]` `result` 和 `failure` 接口**也要刷新 `last_seen_at`**。
+`[必须]` `result`、`failure` 和 `spec-resolution` 接口**也要刷新 `last_seen_at`**。
 否则客户端执行长任务期间不调 claim，会被误判成离线。
 
 新客户端直接调用 claim 时，`204` 是正常的无任务结果，Client 必须正常处理；如果已经预先分配任务，也可能首次调用就返回 `200`。
@@ -247,6 +252,52 @@ Client `SubmissionReceipt` 的统一确认字段，不能只返回 `task_status`
 
 `[必须]` §4.1 的无条件接受**同样适用于本接口**。
 
+### 5.1 采购运行时规格解析
+
+权威 HTTP schema、长度限制、哈希算法和错误代码见 Client 契约 §7.1。Admin 侧路由为：
+
+```http
+POST /api/v1/client/tasks/{task_id}/spec-resolution
+Idempotency-Key: spec-resolution-v1:<identity-sha256>
+```
+
+本命令只在 Client 已进入采购规格面板、选中颜色后仍无法精确匹配任务尺码时使用。请求
+schema v1 只包含：`task_version`、`attempt_id`、`pdd_goods_id`、领取任务时的
+`original_options`、`selected_color`、`target_size`、当前颜色下 1～100 条可购买候选、
+候选快照哈希和观测时间。整个请求体最多 64 KiB。候选编号必须按页面顺序严格使用
+`c1`～`c100`，每条只保存页面原文及原始 `color/size`；禁止原始控件树和截图。
+
+处理顺序：
+
+1. 限制请求体大小并校验 schema、字段长度、候选数量、连续短编号、原文和 options；
+2. 按 Client 契约 §7.1 的长度前缀算法重新计算候选快照哈希和确定性幂等键；
+3. 核对任务存在、类型为采购、版本和 PDD 商品一致，并确认 `X-Client-Id` 在
+   `task_claims` 中领取过该任务；任务当前是否取消、重派或结束不作为状态查询条件；
+4. 计算完整规范请求的 `request_hash`。先按
+   `(task_id, attempt_id, candidate_snapshot_hash)` 复查 `purchase_spec_resolutions`：
+   相同 `request_hash` 复用旧记录，不同 `request_hash` 返回 `409 IDEMPOTENCY_CONFLICT`；
+5. 用短事务保存 pending 候选观察，事务外执行后续工单提供的规则/AI 服务，只允许选择
+   请求中已有候选；再用一个短事务完成解析记录并把可安全重放的响应写入
+   `idempotency_keys`。Admin 崩溃留下的 pending 记录由相同请求恢复，不另建记录；
+6. 返回 `200`，不更新 `tasks.status`、`tasks.result_data` 或
+   `pdd_products.skus_json`，刷新 Client `last_seen_at`。
+
+业务响应固定为 `matched/uncertain/rejected/failed`。只有 `matched` 返回非空 `match`，
+且 `candidate_id`、`raw_text`、`options` 必须是请求候选的逐字副本；`source` 只允许
+`rule/ai/reused/null`，`confidence_bps` 为 `0～10000` 或 NULL。NULL 表示来源没有可比较
+置信度，不能当作 0。`failed` 是已落库、可幂等重放的业务结论，仍返回 HTTP 200；只有
+记录尚未落库时的基础设施故障才返回可有限重试的 `503 SPEC_RESOLUTION_UNAVAILABLE`。
+
+稳定校验错误与 Client 契约保持一致：`INVALID_BODY`、
+`INVALID_SPEC_RESOLUTION_SCHEMA`、`INVALID_SPEC_RESOLUTION_REQUEST`、
+`SPEC_RESOLUTION_HASH_MISMATCH`、`TASK_NOT_FOUND`、`TASK_NOT_PURCHASE`、
+`TASK_VERSION_CONFLICT`、`PDD_GOODS_MISMATCH`、`TASK_NOT_CLAIMED_BY_CLIENT`、
+`IDEMPOTENCY_CONFLICT`。所有错误使用本文 §7 的统一 JSON 结构。
+
+解析表只保存候选观察、最终决策、非敏感服务商/模型指纹和审计时间。不保存模型 API
+Key、完整提示词/响应、原始 XML、订单号、收货信息、Cookie 或 Token。旧 Client 不调用
+本命令，原四个接口的路径和语义不变。本命令不提供 GET、进度查询、心跳或轮询能力。
+
 ## 6. 幂等怎么做
 
 `[必须]` 建一张表记录处理过的键：
@@ -264,7 +315,9 @@ CREATE TABLE idempotency_keys (
 - 键相同、哈希不同 → 返回 `409 IDEMPOTENCY_CONFLICT`；
 - 键不存在 → 正常处理，然后连同响应一起写入，**和业务写入在同一事务**。
 
-不这么做的话，Client 网络超时重发就会产生两条结果。
+不这么做的话，Client 网络超时重发就会产生两条结果。规格解析还要同时依靠
+`purchase_spec_resolutions` 的业务唯一键防止换一个 HTTP 键重复决策；观察、决策和
+`idempotency_keys` 必须在同一事务收敛。
 
 ## 7. 错误格式
 
@@ -318,10 +371,17 @@ Client 契约里散落的 Admin 侧硬要求，汇总在这里，**可以直接
 - [ ] 采购任务的 `quantity`、`max_price_cent` 必有值，后者是人民币订单总价上限的分整数
 - [ ] 可以预先指派 live 任务给可见 Client，但领取时不向只声明 `dry_run` 的客户端返回 live 任务
 - [ ] `result` / `failure` 幂等：同键同内容返回同结果
+- [ ] `spec-resolution` 校验 64 KiB、schema、字段长度、1～100 候选和连续短编号
+- [ ] 重新计算候选快照哈希和确定性幂等键，不信任 Client 自报哈希
+- [ ] 相同任务、尝试、候选快照只保存一条解析记录；同内容返回首次响应，不同内容返回 `409`
+- [ ] 只有 matched 返回请求内候选的逐字副本；不接受模型生成规格
+- [ ] uncertain / rejected / failed 安全停止且可幂等重放，置信度保留 NULL 语义
+- [ ] 规格解析不修改任务状态和 PDD 主数据，不提供 GET、轮询、租约或心跳
+- [ ] 规格解析审计不含原始 XML、订单、收货信息和任何凭据
 - [ ] 同键不同内容返回 `409`
 - [ ] **任务已取消，仍接受结果**
 - [ ] **任务已重派，仍接受结果**
 - [ ] **同一任务接受多个客户端的多份结果**
 - [ ] 只有从未分配过的任务才返回 `403`
-- [ ] `claim` / `result` / `failure` 都刷新 `last_seen_at`
+- [ ] `claim` / `result` / `failure` / `spec-resolution` 都刷新 `last_seen_at`
 - [ ] token 不进日志

docs/client/03-data-model.md

@@ -200,7 +200,7 @@ CREATE INDEX idx_pdd_tasks_visible_list
 |---|---|
 | `[必须]` 状态机没有 `pending` | 起点是 `claimed`，见 §7 |
 | `[必须]` 已完成任务永久保留 | `succeeded` / `failed` / `cancelled` 的记录**不删**。崩溃恢复防重复下单依赖历史记录，见 §7.3 |
-| `[必须]` 本地不保存 Admin 侧状态 | Client 拿到任务就做完，中途不查 Admin 怎么想。Admin 取消了、重派了，Client 一律不感知，照做完照提交，见 [04 接口契约](04-admin-api-contract.md) §1 |
+| `[必须]` 本地不保存 Admin 侧状态 | Client 拿到任务就做完，中途不查 Admin 调度状态。采购规格无法精确选择时可以提交一次候选解析命令，但它不返回取消、重派等状态，见 [04 接口契约](04-admin-api-contract.md) §1、§7.1 |
 | `[必须]` 提交一定会被接受 | Admin 必须无条件接受已派发过的结果，见 [04](04-admin-api-contract.md) §6.1。所以本地不需要"提交被拒"的处理分支 |
 
 **关于"永久保留"：** 任务记录不设保留期，一直留着。界面上的“删除”只写入
@@ -274,6 +274,27 @@ CREATE INDEX idx_task_runs_task
 `result_data` 保存这次成功采集的完整结果；`pdd_tasks.pdd_data` 只保存最新结果。
 这样重新采集可以更新当前数据，同时仍能按 `attempt_no` 追查旧结果。
 
+### 4.1 采购运行时规格解析的持久化边界
+
+[接口契约 §7.1](04-admin-api-contract.md) 定义了一个与 `task_runs.attempt_id` 绑定的一次性
+规格解析命令。Admin 的 `purchase_spec_resolutions` 是服务端候选观察和最终决策的权威
+审计；Client 本地仍必须在发送前保存以下最小信息，后续由工单 #257 增加 SQLite migration
+和 Repository：
+
+- `task_id`（本地外键）与 `attempt_id`；
+- 完整且大小受限的请求 JSON、确定性 `Idempotency-Key` 和请求哈希；
+- `candidate_snapshot_hash`、Admin `resolution_id`、outcome、source、可空置信度；
+- matched 时 Admin 返回的候选短编号、原始文字和 options，以及收到时间。
+
+这类请求需要同步取得响应才能决定本次采购是否继续，**不能伪装成普通结果 Outbox**；
+但发送前仍必须持久化，网络重试只能重放相同键和相同内容。原始
+`pdd_tasks.admin_payload`、`target_color/target_size` 永远不覆盖；解析结果只是当前
+`task_runs` 的执行期有效规格。进入过 `irreversible_action_at` 的运行不得新建或重放解析
+以继续采购，只能核对订单。
+
+#254 只冻结接口和 Admin 审计模型，当前 Client SQLite schema 不在本工单改动。未实现
+#257 的旧 Client 继续按“规格不匹配即失败”运行，不调用新接口，也不会出现半持久化状态。
+
 ## 5. `outbox_events`
 
 保存等待提交 Admin 的可靠事件。
@@ -369,6 +390,10 @@ def save_result_and_enqueue(
 <remote_task_id>:<attempt_id>:failure-v1    # 提交失败/人工处理
 ```
 
+运行时规格解析不进入本表的普通结果 Outbox。它的确定性键是
+`spec-resolution-v1:<identity-sha256>`，完整算法见 [接口契约 §7.1](04-admin-api-contract.md)；
+#257 必须把该键和原请求保存到独立的执行期解析记录后才发送。
+
 ```python
 _KEY_SUFFIX = {
     "collect_result": "result-v1",

docs/client/04-admin-api-contract.md

@@ -12,8 +12,9 @@
 
 **核心：Admin 是调度器，Client 是执行器，执行器不参与调度决策。**
 
-- Client 的任务流程只有三个动作：领一个任务、提交结果、提交失败。
-  设置页另有一个幂等 Client 登记动作。**没有任何"去问 Admin 现在怎么想"的调用。**
+- Client 的常规任务流程只有三个动作：领一个任务、提交结果、提交失败。
+  采购规格无法精确选择时，允许在同一次执行中额外提交一次 §7.1 规格解析命令；
+  设置页另有一个幂等 Client 登记动作。**没有任何“去问 Admin 现在怎么想”的状态查询。**
 - Client 拿到任务就做完，中途不管任务是否被取消、是否被重派。
 - Admin 负责任务的创建、更新、取消和派发（含重派），这些 Client 一律不感知。
 - 结果提交必须幂等；网络重试不能创建重复结果。
@@ -43,7 +44,7 @@ X-Request-Id: <uuid>
 Content-Type: application/json
 ```
 
-结果和失败提交额外携带：
+结果、失败和运行时规格解析提交额外携带：
 
 ```http
 Idempotency-Key: <stable-key>
@@ -410,9 +411,153 @@ Idempotency-Key: task-id:attempt-id:failure-v1
 - `[必须]` §6.1 的无条件接受规则同样适用于本接口。
 - `[必须]` Admin 决定是否创建新的执行机会，但对已经可能下单的任务不得通过普通重试触发再次购买。
 
+### 7.1 采购运行时规格解析命令
+
+“运行时规格解析”是指：Client 已经打开当前 PDD 商品并选中颜色，但任务目标尺码
+无法与页面上的可购买尺码精确对应时，把这一刻的候选快照交给 Admin 做一次受审计的
+规格决策。它是**一次性 POST 业务命令**，不是任务状态查询、心跳或轮询；Client 不得
+用它询问任务是否取消、是否重派或 AI 是否完成。
+
+```http
+POST /api/v1/client/tasks/{task_id}/spec-resolution
+Idempotency-Key: spec-resolution-v1:<identity-sha256>
+```
+
+请求体 schema v1：
+
+```json
+{
+  "schema_version": 1,
+  "task_version": 3,
+  "attempt_id": "attempt-uuid",
+  "pdd_goods_id": "937122477375",
+  "original_options": {"color": "黑色", "size": "60公斤"},
+  "selected_color": "黑色",
+  "target_size": "60公斤",
+  "candidates": [
+    {
+      "candidate_id": "c1",
+      "raw_text": "120斤",
+      "options": {"color": "黑色", "size": "120斤"}
+    },
+    {
+      "candidate_id": "c2",
+      "raw_text": "130斤",
+      "options": {"color": "黑色", "size": "130斤"}
+    }
+  ],
+  "candidate_snapshot_hash": "64位小写十六进制 SHA-256",
+  "observed_at": "2026-08-17T08:00:00Z"
+}
+```
+
+字段和大小限制：
+
+| 字段 | 规则 |
+|---|---|
+| 整个 JSON 请求体 | UTF-8 编码后最多 64 KiB；未知字段允许忽略但不得改变已知字段含义 |
+| `schema_version` | v1 固定为 `1`；未知主版本拒绝，不猜测兼容 |
+| `task_version` | 正整数，必须等于领取到的任务版本 |
+| `attempt_id` | 1～191 个字符，同一次 `task_runs` 执行稳定复用 |
+| `pdd_goods_id` | 1～191 个字符，必须等于任务商品 |
+| `original_options` | 1～16 个字符串键值；键和值各 1～191 个字符，保持领取任务时的动态规格原文 |
+| `selected_color` / `target_size` | 各 1～191 个字符，不允许控制字符 |
+| `candidates` | 1～100 条，只提交当前颜色下页面显示为可购买的尺码，保持页面顺序 |
+| `candidate_id` | 严格按数组顺序使用 `c1`、`c2` … `c100`，不得跳号或重复 |
+| `raw_text` | PDD 页面原始尺码文字，1～191 个字符，不允许控制字符 |
+| `options` | v1 只含非空 `color`、`size`；`color` 必须等于 `selected_color`，`size` 必须逐字等于 `raw_text` |
+| `candidate_snapshot_hash` | 按下述算法计算的 64 位小写十六进制 SHA-256 |
+| `observed_at` | 带时区 ISO 8601；推荐 UTC |
+
+候选短编号由 Client 按页面顺序生成，Admin 必须逐项验证编号、原文和 options，不能
+接受模型自行增加、改写或重新编号后的规格。快照哈希使用长度前缀，避免分隔符碰撞：
+
+```text
+frame(value) = UTF-8 字节长度的十进制文本 + ":" + value
+material = frame("spec-resolution-v1")
+         + frame(pdd_goods_id)
+         + frame(selected_color)
+         + frame(候选数量的十进制文本)
+         + 依页面顺序为每条候选追加：
+           frame(candidate_id) + frame(raw_text)
+           + frame(options.color) + frame(options.size)
+candidate_snapshot_hash = lowercase_hex(sha256(UTF-8(material)))
+```
+
+幂等键同样是确定值，不直接拼接可能很长的任务编号：
+
+```text
+identity_material = frame(task_id) + frame(attempt_id)
+                  + frame(candidate_snapshot_hash) + frame("spec-resolution-v1")
+Idempotency-Key = "spec-resolution-v1:" + lowercase_hex(sha256(UTF-8(identity_material)))
+```
+
+Admin 必须重新计算两个哈希。相同业务身份
+`task_id + attempt_id + candidate_snapshot_hash` 只对应一条解析记录；相同键和相同内容
+返回第一次保存的完整响应，相同键或相同业务身份携带不同内容返回
+`409 IDEMPOTENCY_CONFLICT`。网络超时可以用原键和原请求重放，但 Client 不得修改内容后
+沿用旧键，也不得循环请求等待结果。
+
+成功处理统一返回 `200 OK`。`failed` 是已经持久化的业务结论，不是 HTTP 500：
+
+```json
+{
+  "schema_version": 1,
+  "resolution_id": "psr-uuid",
+  "outcome": "matched",
+  "source": "ai",
+  "candidate_snapshot_hash": "请求中的同一哈希",
+  "match": {
+    "candidate_id": "c1",
+    "raw_text": "120斤",
+    "options": {"color": "黑色", "size": "120斤"}
+  },
+  "confidence_bps": 9300,
+  "reason": "目标重量与候选范围唯一对应",
+  "resolved_at": "2026-08-17T08:00:01Z"
+}
+```
+
+| `outcome` | 含义 | `match` |
+|---|---|---|
+| `matched` | 规则、AI 或历史解析得到唯一且通过服务端门禁的请求内候选 | 必须是请求候选的逐字副本 |
+| `uncertain` | 有分析结果，但不能唯一、安全地选中一个候选 | `null` |
+| `rejected` | 请求结构有效，但业务规则明确拒绝自动选择 | `null` |
+| `failed` | 解析服务超时、格式错误或其他已审计失败 | `null` |
+
+`source` 只允许 `rule`、`ai`、`reused` 或 `null`；`confidence_bps` 为 `0～10000`
+整数或 `null`，`null` 表示该来源没有可比较的置信度，不能当作 0。`reason` 最多 500
+个字符。只有 `matched` 可以返回非空 `match`，其编号、原文和 options 必须逐字来自
+本次请求；响应不得包含模型生成的新规格。Client 仍须在继续前重新读取页面、复算快照并
+精确核对，不能因为 Admin 返回 matched 就跳过既有数量、总价、地址、不可逆标记和单次
+提交门禁。
+
+稳定错误至少包括：
+
+| HTTP | `error.code` | 场景 |
+|---|---|---|
+| `400` | `INVALID_BODY` | 非法 JSON 或请求体超过 64 KiB |
+| `400` | `INVALID_SPEC_RESOLUTION_SCHEMA` | `schema_version` 不支持 |
+| `422` | `INVALID_SPEC_RESOLUTION_REQUEST` | 字段长度、候选数量、候选编号或 options 无效 |
+| `422` | `SPEC_RESOLUTION_HASH_MISMATCH` | 快照哈希或确定性幂等键与字段不一致 |
+| `404` | `TASK_NOT_FOUND` | 任务不存在 |
+| `422` | `TASK_NOT_PURCHASE` | 不是采购任务 |
+| `409` | `TASK_VERSION_CONFLICT` | 请求任务版本与已领取版本不一致 |
+| `422` | `PDD_GOODS_MISMATCH` | PDD 商品 ID 与任务不一致 |
+| `403` | `TASK_NOT_CLAIMED_BY_CLIENT` | 该 Client 从未领取过此任务 |
+| `409` | `IDEMPOTENCY_CONFLICT` | 相同幂等身份提交了不同内容 |
+| `503` | `SPEC_RESOLUTION_UNAVAILABLE` | 在解析记录落库前 Admin 暂不可用，可有限重试原请求 |
+
+任务已取消、重派或结束本身不是本命令的查询条件；只要该 Client 曾领取任务且任务身份
+仍能核对，Admin 可以保存解析审计，但**不得修改任务状态**。候选观察先用短事务持久化；
+规则/AI 调用不得占用数据库事务，最终决策和安全重放响应必须与 `idempotency_keys` 在同一
+短事务提交。该记录不得覆盖 `pdd_products.skus_json`，也不得
+保存原始无障碍 XML、截图、订单号、收货信息、Cookie、Token 或 API Key。旧 Client 不
+调用本接口，继续按“规格不匹配即提交失败”的既有流程运行。
+
 ## 8. 幂等与重试
 
-- `[必须]` 结果和失败提交必须使用持久化的 `Idempotency-Key`，格式见 [03 数据模型](03-data-model.md) §5.2。
+- `[必须]` 结果、失败和运行时规格解析提交必须使用持久化的 `Idempotency-Key`；前两者格式见 [03 数据模型](03-data-model.md) §5.2，规格解析格式见 §7.1。
 - `[必须]` Client 在发送前将完整请求写入 Outbox；重试使用相同键和相同内容。
 - `[必须]` `claim` 需要 Admin 保证重复请求不会一次分配出多个任务。
 - `[建议]` 对 `429`、`500` 和 `503` 使用有上限的指数退避，并遵守 `Retry-After`。
@@ -420,13 +565,14 @@ Idempotency-Key: task-id:attempt-id:failure-v1
 
 ## 9. Mock Admin 要求
 
-`MockAdminGateway` 与 HTTP 实现暴露同一应用层接口。登记和三个任务方法都必须使用同一契约：
+`MockAdminGateway` 与 HTTP 实现暴露同一应用层接口。登记、三个常规任务方法和一次性规格解析命令都必须使用同一契约：
 
 ```text
 register_client(client, capabilities)             # §4.1
 claim_next(client, capabilities)                  # §5
 submit_result(task_id, idempotency_key, result)   # §6
 submit_failure(task_id, idempotency_key, failure) # §7
+resolve_purchase_spec(task_id, idempotency_key, observation) # §7.1
 ```
 
 Mock 必须支持：
@@ -436,6 +582,7 @@ Mock 必须支持：
 - 网络超时和暂时故障；
 - 幂等重复提交（相同键相同内容）；
 - 幂等冲突（相同键不同内容）；
+- 规格解析的 matched / uncertain / rejected / failed，以及候选哈希不一致；
 - **提交一个 Admin 侧已取消的任务，仍返回 `accepted: true`**（用来验证 §6.1）；
 - 结果校验失败。
 
@@ -457,7 +604,9 @@ Mock 测试通过不能替代与真实 Admin 的契约测试。
 
 - 任务分「指定分配」和「无主」两种，`claim` 两种都返回，指定的优先。
   采集任务不指定，采购任务可指定可留空。Client 不读全局任务池。见 §5.1。
-- **没有租约、没有心跳、没有状态回查。** 任务流程只有 §5 / §6 / §7 三个调用；设置页另有 §4.1 的幂等登记调用。
+- **没有租约、没有心跳、没有状态回查。** 常规任务流程仍是 §5 / §6 / §7；
+  §7.1 只是在同一次采购规格无法精确选择时提交候选并同步取得持久化决策，设置页另有
+  §4.1 的幂等登记调用。
 - Admin 必须无条件接受已派发过的 Client 提交的结果。见 §6.1。
 
 改动这张表里任何一条，都属于会影响业务结果的变更，必须先更新工单并经用户确认。