docs(architecture): 接口契约 v0.1，确认 API1–API5

- openapi.yaml：用户端 MVP 主流程的 OpenAPI 3.1 契约（64 个路径、81 个操作）
- api-design.md：约定、鉴权、页面与接口对应、扣点预览、任务与事件、上传、错误码
- data-model.md：清单项 spec 改为按类别分组

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/data-model.md

@@ -189,7 +189,7 @@ erDiagram
 | `edited_fields` | 人工改过哪些字段。重新解析对齐时，这些字段不动 |
 
 - **类别**：`categories` 可以有多个标签。CHECK 约束保证 ★ 条款一定带「无效 / 废标」标签（FR-M2-05）。
-- **类别特有字段**（05 §3.3）放在 `spec` 里，按类别用 Pydantic 校验。例如技术参数是 `{"param": "内存", "op": ">=", "value": 32, "unit": "GB", "device": "服务器"}`。规则引擎要用的字段都放在这里，常用的再提出来建索引。
+- **类别特有字段**（05 §3.3）放在 `spec` 里，**按类别分组**：一条清单项有几个类别，就可以有几组，每组用对应的 Pydantic 模型校验。例如 ★ 技术参数是 `{"tech_param": {"param": "内存", "op": ">=", "value": "32", "unit": "GB", "device": "服务器"}, "invalidity": {"source": "substantive_marker"}}`。规则引擎要用的字段都放在这里，常用的再提出来建索引。完整定义见 `openapi.yaml` 的 `ItemSpec`。
 - **重要性依据**：`importance_basis` 记下凭什么认定为 ★，可以是标注符号、法规列明或原文写明。`marking_rule_id` 指向文件自己的标注规则（07 F1）。
 - **区域**：`zone` 分待确认区和正式清单。进待确认区的原因写在 `pending_reason`：没有出处、置信度低、校验没通过、标注句没被覆盖（规则兜底生成的）、重新解析时没再出现。待确认区的条目不参与检查（FR-M2-07）。
 - **补遗**：
@@ -207,7 +207,7 @@ erDiagram
 |---|---|
 | 总价限价 | `project_field`，字段 `ceiling_total` |
 | 采购包限价 | `lot.ceiling_amount` |
-| 分项限价、单价上限 | 清单项，类别是「报价」（DM7），`spec = {"kind": "price_ceiling", "target": "<分项名>", "op": "<=", "value": "..."}` |
+| 分项限价、单价上限 | 清单项，类别是「报价」（DM7），`spec = {"price": {"kind": "item_ceiling", "target": "<分项名>", "op": "<=", "value": "..."}}` |
 
 报价形式检查读投标文件里的金额，和这三层比对。读到的金额写在问题的 `detail` 里，同时保留原文写法和出处。