docs(architecture): 物理数据模型 v0.1，确认 DM1–DM7

- data-model.md：约定、租户隔离落地、按模块的表清单、额度流水语义、
  清单项与检查的建模、删除流程、对象存储布局
- schema-draft.sql：40 张表的建表草案（PostgreSQL 16+）
- schema-draft-test.sql：租户隔离、额度流水、审计、删除等 16 项行为测试
- 回写架构 §3.2/§3.11/§9/§12、05 §3、FR-M2-05、FR-M3-03

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

docs/architecture/architecture.md

@@ -1,7 +1,7 @@
 # 技术架构设计 v0.3
 
 > 依据：PRD v0.9.1 第 7 章（非功能需求）、`docs/analysis/`（功能需求、领域模型、样本结论）、`docs/decisions.md`（T1 及各阶段决策）、参考项目分析 `ref-bid-engine-analysis.md`。
-> 状态：v0.3。v0.2 的选型已全部确认；v0.3 新增 §3.14：MVP 的表结构先按多人、多登录方式建，给以后的团队版、企业版、飞书 / 企业微信登录留结构（AR11、AR12，已确认）。
+> 状态：v0.3。v0.2 的选型已全部确认；v0.3 新增 §3.14：MVP 的表结构先按多人、多登录方式建，给以后的团队版、企业版、飞书 / 企业微信登录留结构（AR11、AR12，已确认）。物理数据模型见 `data-model.md`（DM1–DM7，已确认）。
 > - 已确认（2026-11-03）：T2–T5；AR1、AR3、AR5–AR9 按建议；AR2 改为 Vue 3 + Vite。
 > - 已确认：AR4 修订后的建议（引入 Valkey，只存可以丢的数据，§6.1）；AR10 不引入带样式的 UI 框架（§4.3）。至此选型全部确认。
 > - 确认后写入 `docs/decisions.md`；构建、运行、测试命令等工程骨架搭好后回填到 AGENTS.md。
@@ -158,7 +158,8 @@ flowchart LR
 | `report` | 检查报告的生成与归档 | FR-M3-09 |
 | `qualification` | 最小资质库 | FR-M6-08 |
 | `audit` | 审计事件 | FR-M6-07 |
-| `ops` | 运营后台接口 | FR-M6-09 |
+| `ops` | 运营后台接口、误报 / 漏报反馈 | FR-M6-09 |
+| `notification` | 站内通知（解析 / 检查完成、额度提醒、开通） | FR-M2-02、FR-M6-03 |
 
 每个模块内部分三层：
 
@@ -312,7 +313,7 @@ flowchart LR
 - **调试开关**：「跳过登录」之类的开关只在测试配置里存在；生产环境检测到这类开关会直接退出。
 - **加密**：
   - 传输：全链路 TLS。
-  - 存储：云盘和 OSS 开服务端加密。文件另做**信封加密**，每个租户（或每个项目）一把数据密钥，删除时销毁密钥，备份里的数据也就随之不可读，用来落实 G10 的「彻底删除」。
+  - 存储：云盘和 OSS 开服务端加密。文件另做**信封加密**，每个项目一把数据密钥（资质附件用企业级密钥，DM4），删除时销毁密钥，备份里的数据也就随之不可读，用来落实 G10 的「彻底删除」。
   - 模型供应商的 API Key 加密存储。
 - **运营后台**：独立应用、独立登录，加 IP 白名单和二次验证，所有操作都写审计。
 - **日志脱敏**：日志和监控里只出现编号和哈希，不出现文档内容、引文、金额；有专门的脱敏中间件，加上测试。
@@ -788,7 +789,8 @@ docs/                  # 现有文档
 - 业务表里记录「谁」的字段（创建人、确认人、处理人）都指向 `user_account`，不指向成员身份；人不做物理删除。
 - 出处（Citation）存：文档编号、规范化 PDF 的哈希、页码、句子编号、字符范围、坐标框数组（`quads`）。
 - AI 值和人工值分开存（§3.8）；状态字段用枚举，不用自由文本。
-- 文字层的逐字数据量大，存在对象存储里；数据库里只存句子和块的索引，以及校验要用的文本。
+- 文字层（逐字坐标、格式、句子切分）存在对象存储里，按页分片；**句子不进数据库**（DM1），数据库只存页摘要和出处快照（原句、坐标框）。
+- 完整的表结构见 `data-model.md` 和 `schema-draft.sql`。
 
 ## 10. 编码前要做的技术验证
 
@@ -835,6 +837,6 @@ S1–S4 风险最高，建议先做；S8（桌面外壳 PoC）等桌面版立项
 ## 12. 下一步
 
 1. 做技术验证 S1–S4，结论写进本文件，并据此确定 FR-M2-05、FR-M2-06 的目标值。
-2. 物理数据建模：在 04 领域模型的基础上细化表结构，重点是清单项、出处、问题、额度流水，以及 §3.14 的人 / 登录方式 / 成员身份、项目成员。
+2. ~~物理数据建模~~：✅ 已完成，见 `data-model.md`、`schema-draft.sql`（DM1–DM7 已确认）。
 3. 定接口契约：先写核心接口的 OpenAPI 定义，前后端据此并行开发。
 4. 搭工程骨架：仓库结构、CI、Compose 一键启动、一个贯通「上传 → 解析 → 显示清单」的最小链路。