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/decisions.md

@@ -4,6 +4,20 @@
 
 ---
 
+## API1–API5 · 2026-11-03 · 接口契约的取舍：全部按建议
+
+依据 `docs/architecture/api-design.md` §9；契约文件 `openapi.yaml`。
+
+| # | 决策 | 理由 |
+|---|---|---|
+| API1 | 后端骨架搭好前以 `openapi.yaml` 为准，前后端据此同时开发；之后以 FastAPI 生成的文档为准，存成 `openapi.json` 提交，CI 检查是否最新，`openapi.yaml` 不再维护 | 避免两份契约长期并存、互相偏离；契约改动在合并请求里可见 |
+| API2 | 事件流（SSE）用 fetch 读取，不用 EventSource | EventSource 带不了 Bearer 头，桌面版用不了 |
+| API3 | 同一账号在其他设备已登录时，新设备登录先提示，用户确认后挤掉旧设备 | 落实 FR-M6-04「提示并限制」；「旧设备不退出就不让登录」会让换了电脑的用户登不上 |
+| API4 | 会扣点的接口都带「预期扣点」，和服务端当下算的不一致就拒绝、不扣点，并返回最新的扣点预览 | 红线 9：用户看到的扣点说明和实际扣点必须一致 |
+| API5 | 报告在后台生成，完成后推送事件 | 生成 PDF 要几秒到十几秒；api 只做短事务 |
+
+- **影响**：架构 §12 第 3 步完成；`data-model.md` 的清单项 `spec` 改为按类别分组。
+
 ## DM1–DM7 · 2026-11-03 · 物理数据模型的取舍：全部按建议
 
 依据 `docs/architecture/data-model.md` §9；建表脚本草案 `schema-draft.sql` 在 PostgreSQL 16 上跑通了 16 项行为测试。