docs: 新增 PRD v0.9.1、决策记录与 MVP 需求分析

- PRD v0.9.1：补充政府采购体系依据（87 号令），异常低价口径按体系分层
- decisions.md：D1 首发 IT 集成、A1 需求分析 G1–G10、T1 国产云端模型路由
- docs/analysis：范围与角色、用户旅程、功能需求、领域模型、
  IT 集成领域知识、缺口清单、苏采云样本分析

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

docs/analysis/01-scope-roles.md

@@ -0,0 +1,88 @@
+# 01 · MVP 范围与角色
+
+> 依据：PRD v0.9 第 5、6、9 章；D1（IT 集成先行）。本文只覆盖 **MVP**，V1 及以后的功能仅在边界处提及。
+
+## 1. MVP 一句话
+
+**用户上传一份 IT 集成招标文件，拿到一份能逐条回到原文的结构化检查清单；递交前上传投标文件，系统对照清单逐项核对，用户逐条确认后导出一份带留痕的检查报告。**
+
+链路：`新建项目 → 上传招标文件 → 解读 → 确认清单 → 上传投标文件 → 检查 → 逐项确认 → 导出报告`
+
+## 2. 范围边界
+
+### 2.1 MVP 包含
+
+| 模块 | 功能 | PRD 出处 |
+|---|---|---|
+| M2 | 文件上传与解析（PDF / Word / 扫描件 OCR） | M2 P0 |
+| M2 | 结构化提取：资格条件、废标 / 无效条款、评分办法、关键日期与递交要求 | M2 P0 |
+| M2 | 原文回链（页码 + 原句高亮）；无出处结果进「待确认」区 | M2 P0 |
+| M2 | 项目检查清单生成，用户可增删改并留痕 | M2 P0 |
+| M3 | 响应完整性检查（未响应 / 负偏离未说明 / 漏项） | M3 P0 |
+| M3 | 形式要件检查（格式、签章位置与有无、命名、份数、递交方式） | M3 P0 |
+| M3 | 资质匹配检查（过期 / 等级不足 / 未覆盖） | M3 P0 |
+| M3 | 人工确认三态 + 就绪状态 | M3 P0 |
+| M3 | 检查报告 PDF 导出 | M3 P0 |
+| M5 | 服务协议中的围串标禁止条款（仅协议文本，无功能） | M5 P0 |
+| M6 | 项目工作台、项目状态流 | M6 P0 |
+| M6 | 额度计量、明细、80% / 100% 提醒；失败不扣点 | M6 P0 |
+| 商业 | 免费版 + 专业版 | 第 9 章 |
+
+### 2.2 分析中新增、已确认纳入 MVP
+
+这些是 PRD 没写、但 MVP 链路跑不通或明显缺一块的部分。2026-11-02 已全部按建议确认（`docs/decisions.md` A1），详见 `06-gaps-and-questions.md`：
+
+| 项 | 原因 | 建议 |
+|---|---|---|
+| 多包 / 多标段 | IT 集成采购常分包，资格、限价、参数都按包区分 | **纳入**，否则清单会混入不投的包 |
+| 最小资质库 | M3 资质匹配是 P0，但资产库在 M6 是 P1 | **纳入轻量版**（手工录入 + 有效期） |
+| 报价形式检查 | 超预算 / 最高限价是法定无效情形，且不涉及「建议报价」 | **升为 P0** |
+| 补遗追加（简化版） | 真实项目几乎都有补遗；完整的影响分析是 P1 | 纳入「追加解析 + 来源标注」，不做自动影响分析 |
+| 账号、套餐开通、支付 | PRD 没写 | 见 G8、G9 |
+| 运营后台 | 开通套餐、调额度、看漏报反馈，都需要内部工具 | **纳入最小版** |
+
+### 2.3 MVP 明确不做
+
+- M1 商机筛选全部、M4 标书生成全部、M5 查重功能全部。
+- M2 答疑澄清辅助、补遗自动影响分析（P1）。
+- M3 报价合理性（低价）风险检查、行业规则包的版本化运营（P1；MVP 只内置一套 IT 集成规则，但报告中保留版本字段）。
+- 团队协作、角色权限、团队版（V1）。
+- 移动端（PRD 7：移动端只做进度查看与提醒，MVP 不单独适配，只保证响应式页面可用）。
+- 电子投标递交、CA 加密文件解析（产品只处理加密前的 Word / PDF 稿）。
+
+## 3. 角色
+
+### 3.1 外部用户
+
+| 角色 | 画像 | MVP 中能做什么 |
+|---|---|---|
+| 访客 | 通过搜索 / 推荐进来的投标人员 | 浏览定价页、注册 |
+| 免费版用户 | 个人 / 小微投标人、来评估的企业投标岗 | 解读 3 次（单份限页）、检查 1 个项目，完整体验一次链路 |
+| 专业版用户 | 中小企业投标专员（PRD 主力用户），1 个账号 | 解析 500 次 / 年额度内不限项目；最小资质库 |
+
+MVP 没有团队，「账号 = 用户 = 企业主体下唯一成员」。数据模型仍按「企业主体（租户）→ 成员」设计，给 V1 团队版留出空间，见 `04-domain-model.md`。
+
+**关键人物（来自 PRD 第 3 章）**：
+
+- **投标专员（主用户）**：上传文件、核对清单、处理检查结论。目标是别废标、别熬夜。要满足他们，需要把每条结论的出处做好、页面上一眼能看到还剩几个致命项。
+- **投标主管 / 老板（付费决策人）**：一般不在 MVP 里直接操作，但会看检查报告、决定续费。要满足他们，需要报告专业、可以拿来归档，免费版的报告就要让人愿意付费。
+
+### 3.2 内部角色
+
+| 角色 | MVP 中能做什么 |
+|---|---|
+| 运营管理员 | 用户与企业查询、开通 / 续费套餐、额度调整（带原因留痕）、查看「漏报 / 误报」反馈 |
+| 规则维护者（可由运营兼任） | 维护内置 IT 集成规则清单，MVP 阶段可以直接改配置文件，不做界面 |
+
+## 4. 计费单位在 MVP 中的口径
+
+PRD 8.2 和 8.3 的口径不完全一致（见 G5），2026-11-02 确认按下面的口径执行（`docs/decisions.md` A1）：
+
+| 动作 | 扣点 | 不扣点 |
+|---|---|---|
+| 解读一份招标文件 / 补遗 | 1 次「解析」 | 解析失败、超时、用户取消 |
+| 对一个项目做一次全量检查 | 1 次「检查」；专业版的「检查」从解析额度中扣 | 检查中断、系统异常；同一项目 24 小时内复查 |
+| 解析投标文件 | 算在本次「检查」里，不另外扣 | — |
+| 免费版 | 解读 3 次；限 1 个项目，这个项目内检查和复查不限次数 | — |
+
+MVP 不做线上加量包，额度不够时由运营后台人工调整（G6）。

docs/analysis/02-user-journeys.md

@@ -0,0 +1,54 @@
+# 02 · 用户旅程（MVP）
+
+> 样例场景统一使用 IT 集成项目：「某市政务服务中心智慧大厅建设项目（政府采购 · 公开招标 · 分 2 个包）」。原型阶段沿用这个场景。
+
+## J1 · 首次体验（免费版，完整跑一遍）
+
+**目标**：注册 7 日内拿到第一份检查报告（PRD 第 10 章「激活」指标）。
+
+| # | 用户动作 | 系统响应 | 关键体验点 / 风险 |
+|---|---|---|---|
+| 1 | 手机号注册，填写企业名称 | 创建企业主体和账号，发放免费额度（解读 3 次、检查 1 个项目） | 注册不要求上传营业执照（G9） |
+| 2 | 新建项目，上传招标文件 PDF（186 页） | 校验格式和页数，超限时提示升级；创建解析任务并预扣 1 次解析 | 页数上限要在上传前就提示，不要等解析失败 |
+| 3 | 等待 | 分阶段显示进度：文本提取 / OCR → 章节识别 → 要素提取 → 出处定位 | 目标 10 分钟内完成；用户可以离开页面，完成后站内通知 |
+| 4 | 识别到分包，选择「我投 1 包」 | 清单只保留通用项和 1 包的项，2 包的项折叠隐藏 | 分包识别错了，用户可以手工更正 |
+| 5 | 浏览清单：资格 / 无效条款 / 评分 / 日期与递交 / 技术参数 | 每条都能点开看原文：左边是清单，右边是 PDF，原句高亮 | **最重要的建立信任的时刻**，回链必须准 |
+| 6 | 处理「待确认」区（没定位到出处的条目） | 用户逐条采纳、修改或删除 | 默认不进正式清单 |
+| 7 | 确认清单 | 清单状态变为「已确认」，可以进入检查 | 不确认也能检查，但会提示（G7） |
+| 8 | 上传投标文件（商务册、技术册、报价册，共 3 个 Word） | 发起检查，扣 1 次检查 | 支持一个项目有多个投标文件分册 |
+| 9 | 看检查结果 | 按「致命 / 重要 / 提示」分组；每条结论两侧出处对照（招标原文 ↔ 投标原文） | 「未找到响应」的条目要写清楚找过哪些文件、哪些章节 |
+| 10 | 逐条处理：已确认无误 / 已修改 / 忽略并注明原因 | 致命项清零后，项目显示「就绪」 | 支持批量处理「提示」级 |
+| 11 | 导出 PDF 报告 | 报告首页写明检查覆盖范围和免责声明；报告随项目归档 | 免费版报告带「免费版」角标，但不能降低报告的可用性 |
+| 12 | — | 额度用完，提示升级专业版 | 升级时机：拿到报告之后，而不是拿到之前 |
+
+## J2 · 真实项目迭代（专业版）
+
+| # | 场景 | 系统行为 |
+|---|---|---|
+| 1 | 采购人发布补遗（修改了投标截止时间、一项 ★ 参数） | 用户在项目中「追加招标文件」→ 扣 1 次解析 → 新提取的条目标注来源「补遗 1」并加入清单；日期类字段以最新文件为准，同时提示用户核对。MVP 不自动判断哪些条目被补遗作废，由用户自己删除或修改（自动影响分析是 P1） |
+| 2 | 修改投标文件后重新检查 | 24 小时内复查不扣点；上次已处理的结论，如果问题仍在，就沿用原来的处理状态并标「沿用」；问题消失则自动关闭；新问题标「新增」 |
+| 3 | 资质库里有证书在投标截止日前过期 | 资质匹配给出「过期」预警，有效期以项目的投标截止日为准，不以今天为准 |
+| 4 | 项目递交 | 用户手动标记「已递交」；项目锁定为只读，可以再导出报告 |
+| 5 | 中标 / 未中标之后 | 用户手动「归档」（MVP 不记录中标结果，V1 以后再考虑） |
+
+## J3 · 额度提醒与升级
+
+| 触发 | 行为 |
+|---|---|
+| 额度用到 80% | 站内提醒 + 短信（G14 建议）；额度页显示本期已用、剩余、按功能分布 |
+| 额度用完 | 发起解析 / 检查时拦截；免费版提示升级专业版，专业版提示联系客服加额度（MVP 不做线上加量包，G6） |
+| 解析失败 | 预扣的额度自动退回；明细中显示「失败退回」 |
+
+## J4 · 删除数据
+
+| 动作 | 行为 |
+|---|---|
+| 删除项目 | 二次确认后删除项目下的文件、清单、检查结果、报告；保留一条不含业务内容的审计记录和额度流水（保留策略见 G10） |
+| 注销账号 | 删除企业主体下的全部业务数据；订单和发票记录按财务要求保留 |
+
+## J5 · 反馈漏报 / 误报
+
+支撑 PRD 第 10 章「信任」指标：
+
+- 每条检查结论都可以「反馈：判断有误」；清单页可以「反馈：有遗漏的要求」。
+- 反馈进运营后台，逐条复盘，再迭代规则。这个指标只给内部用，界面上不展示统计数字。

docs/analysis/03-functional-requirements.md

@@ -0,0 +1,241 @@
+# 03 · 功能需求（MVP）
+
+> 编号规则：`FR-<模块>-<序号>`。优先级沿用 PRD；标 **[新增]** 的是需求分析中补充的，已于 2026-11-02 确认（`docs/decisions.md` A1）。
+> 每条都写了验收标准；测试阶段直接据此编写用例。
+
+---
+
+## M2 · 招标文件解读
+
+### FR-M2-01 上传招标文件 · P0
+
+- 支持格式：PDF（文字版 / 扫描版）、DOCX、DOC、WPS。非 PDF 文件统一转成 PDF 后再处理，保证页码出处一致。
+- **按文件头识别真实格式，不看扩展名**：样本里 10 份都叫 `.doc`，实际有 DOCX、不压缩的 zip 形式 DOCX、旧版 DOC 三种（07 F2）。
+- 解析 Word 时**保留文字格式**（斜体、下划线、加粗），因为有的文件用格式标注实质性条款（07 F1）。
+- 一个项目可以上传多个招标文件，比如正文和附件分开的情况。每个文件标注类型：招标文件 / 补遗 / 澄清答复。
+- 单文件大小和页数上限按套餐区分，购买页和上传页都要写明（具体数字随 D2 一起定）。
+
+**验收**
+- 上传前就校验格式和页数，超出上限时直接说明原因和上限值，不创建任务、不扣点。
+- 加密或损坏的 PDF 能识别出来，提示用户换文件。
+
+### FR-M2-02 解析任务与进度 · P0
+
+- 解析是异步任务，状态有：排队中 → 解析中（分阶段）→ 成功 / 失败 / 已取消。
+- 发起时预扣 1 次解析；成功后结算；失败、超时、取消都退回。
+
+**验收**
+- 进度页显示当前阶段，用户离开后任务继续跑，完成或失败都发站内通知。
+- 失败可以重试，重试不重复扣点；额度明细里能看到「预扣 → 退回」两条记录。
+- 300 页以内目标 10 分钟完成（PRD 7，上线前压测回填）。
+
+### FR-M2-03 项目基本信息提取 · P0 [新增：拆出单列]
+
+提取项目名称、项目编号、采购人 / 招标人、代理机构、采购方式、预算金额 / 最高限价（按包）、包的划分、是否接受联合体、是否接受进口产品、是否专门面向中小企业、适用的法律体系（政府采购 / 招标投标）。
+
+**验收**：每个字段都带出处；用户可以修改，修改留痕。
+
+### FR-M2-04 分包识别与选择 · P0 [新增]
+
+- 识别包 / 标段，以及每个包的预算、限价、资格、参数；
+- 用户选择要投的包，清单按「通用 + 所选包」过滤。
+
+**验收**：没有分包时自动跳过这一步；分包识别错了用户能手工增删和归属。
+
+### FR-M2-05 结构化提取 · P0
+
+按五类生成清单项：PRD 的四类，加上 IT 集成需要的「技术参数」。字段定义见 `05-it-integration-domain.md` §3。
+
+| 类别 | 内容 |
+|---|---|
+| 资格条件 | 通用资格 + 特定资格 + 信用要求，以及每条要求的证明材料 |
+| 无效 / 废标条款 | 法规列明的情形 + 招标文件自己规定的情形 + 所有 ★ 实质性条款 |
+| 评分办法 | 评标方法、价格 / 技术 / 商务分值、每个评分项（分值、标准、证明材料）、中小企业价格扣除 |
+| 关键日期与递交 | 截止时间、开标时间、提疑 / 质疑截止、保证金、投标有效期、递交方式、份数、签章、密封 / 加密 |
+| 技术参数 | 参数项、要求值、比较方式（≥ ≤ = 包含 支持）、重要性（★ / ▲ / 一般）、所属包 |
+
+**验收**
+- 每条清单项至少有一个出处（文件 + 页码 + 原句）；没有出处的进「待确认」区（FR-M2-07）。
+- ★ 条款全部进入「无效 / 废标」类，同时保留在原来的类别里（同一条要求可以有多个类别标签）。
+- **实质性条款按文件自己的标注规则识别**：先找到「标注规则说明」（★ / * / 斜体加下划线 / 「必须」字样等），再按规则识别；不能写死成 ★（07 F1）。
+- 文件写明了实质性条款数量时（如「★ 项共 14 条」），和实际抽到的数量对比，不一致就提示用户。
+- 用 3 份以上真实 IT 集成招标文件做基准测试：人工标注的 ★ 条款**召回率**是主要指标（漏了就可能废标），具体目标在技术方案阶段定。
+
+### FR-M2-06 原文回链 · P0
+
+- 清单和原文并排显示，点击清单项就跳到对应页并高亮原句；一条可以有多个出处。
+- 扫描件按 OCR 文字坐标高亮。
+
+**验收**：抽查 50 条，出处页码正确率和高亮准确率都要达到目标值（技术方案阶段定）；出处无法定位时，宁可进「待确认」，也不能给一个错的页码。
+
+### FR-M2-07 待确认区 · P0
+
+- 没有出处、或模型置信度低于阈值的提取结果，放进待确认区，不进正式清单。
+- 用户操作：采纳（补上出处，或标注「人工确认、无出处」）/ 修改后采纳 / 丢弃。
+
+**验收**：待确认区的条目不参与 M3 检查。
+
+### FR-M2-08 项目检查清单 · P0
+
+- 解读结果自动生成清单，用户可以新增、修改、删除条目，所有修改都留痕（谁、什么时候、改前、改后）。
+- 清单整体状态：草稿 → 已确认；确认后再改，回到草稿并保留历史。
+- 用户新增的条目标注「人工添加」，可以没有出处。
+
+**验收**：任意一条都能查到完整的修改历史；删除是软删除，可以恢复。
+
+### FR-M2-09 关键日期展示 · P0 [新增：拆出单列]
+
+把关键日期汇总成项目时间线，在项目工作台显示倒计时。MVP 只做站内展示，不做主动提醒（截止日提醒放在 P1，和澄清辅助一起做）。
+
+### FR-M2-10 补遗追加（简化版）· P0 [新增]
+
+- 追加的补遗 / 澄清文件单独解析，扣 1 次解析；新提取的条目标注来源，并入清单。
+- 日期类字段以最新文件为准，在旧值上标「已被补遗 N 更新」，用户确认。
+- 不自动判断条目「新增 / 变更 / 作废」（P1）。
+
+---
+
+## M3 · 废标风险检查
+
+### FR-M3-01 上传投标文件 · P0
+
+- 一个项目可以上传多个投标文件分册（商务 / 技术 / 报价 / 资格证明），格式同 FR-M2-01。
+- 只处理加密前的 Word / PDF 稿；如果上传的是电子投标平台的加密格式，要识别出来并说明原因。
+- 分册可以对应到电子投标客户端的节点（如苏采云的资格审查、符合性审查、商务、技术、报价节点），具体怎么对应，等种子用户访谈后确定（G15）。
+- 投标文件有版本：每次重新上传都是新版本，检查结果关联到具体版本。
+
+### FR-M3-02 发起检查 · P0
+
+- 前提：项目至少有一份解析成功的招标文件。清单没确认时可以检查，但要提示「清单未确认，检查结果以当前清单为准」。
+- 按 `01-scope-roles.md` §4 的计费口径扣点；同一项目 24 小时内复查不扣点。
+- 每次检查产生一个「检查批次」，记下当时的清单版本、投标文件版本和规则版本。
+
+### FR-M3-03 响应完整性检查 · P0
+
+对每条清单项，在投标文件里找对应的响应：
+
+| 结论 | 含义 | 默认级别 |
+|---|---|---|
+| 已响应 | 找到了明确响应 | 不生成问题 |
+| 未找到响应 | 所有分册里都没找到 | 按清单项类别定（见下表） |
+| 负偏离未说明 | 偏离表或正文里有不满足的地方，但没有说明 | 同上 |
+| 疑似不满足 | 技术参数的响应值，按比较方式判断不满足要求（如要求 ≥ 32GB，响应 16GB） | 同上 |
+
+级别规则：
+
+| 清单项 | 致命 | 重要 | 提示 |
+|---|---|---|---|
+| ★ 条款、资格条件、无效 / 废标条款 | ✓ | | |
+| ▲ 参数、评分项缺证明材料 | | ✓ | |
+| 一般参数、其他 | | | ✓ |
+
+**验收**
+- 每个问题都带两边的出处：招标原文，和投标原文（「未找到」时写明找过哪些分册、哪些章节）。
+- 每个问题都对应一条清单项；用户能从问题跳到清单项，也能反过来。
+
+### FR-M3-04 形式要件检查 · P0
+
+分成两类，分开显示：
+
+- **可自动检查**：投标函、授权书等格式文件是否齐全，是否改动了格式文件里的固定文字；签字 / 盖章位置**有没有**（只看有无，不鉴定真伪，界面写明）；落款日期是否合理；文件里有没有出现其他项目的名称、编号或采购人（照搬旧标书留下的）。
+- **需人工核对**：份数、装订密封、递交方式、CA 加密等，文件里看不出来。这些生成「请核对」条目，用户勾选确认。
+
+### FR-M3-05 资质匹配检查 · P0
+
+- 每条资格条件和评分项要求的证明材料，都要在投标文件中找到对应材料。
+- 如果有资质库（FR-M6-08），再用投标截止日判断证书有没有过期，等级够不够。
+- 三种预警：过期 / 等级不足 / 未覆盖。资质数据只来自用户自己的资质库和投标文件，系统不从外部补数据。
+
+### FR-M3-06 报价形式检查 · P0 [新增：从 P1 拆出并升级]
+
+只检查**形式**，不评价报价是否合理，也不建议报价：
+
+- 投标报价是否超过限价，按三层检查：总价限价、采购包限价、分项限价 / 单价上限（07 F6）。超限在政府采购和招投标两个体系里都是法定无效 / 否决情形，见 05 §2；
+- 开标一览表和分项报价表的合计是否一致；大写和小写金额是否一致。注意：苏采云范本规定开标一览表和分项不一致时「不作无效处理，以开标一览表为准」，所以这项定为「重要」，不是「致命」，说明里要引用原文；
+- 只给一个报价（招标文件允许备选方案的除外）。
+
+**验收**：报价数字只从投标文件读取，界面上没有任何「建议报价 / 报价区间」的字样。
+
+### FR-M3-07 人工确认 · P0
+
+- 每个问题的状态：待处理 → 已确认无误 / 已修改 / 忽略（必须填原因）。
+- 还有没处理的「致命」问题时，项目就绪状态是「未就绪」，但**不阻止导出**。
+- 支持批量处理（仅限「提示」级）；每次处理都记录处理人和时间。
+- 每个问题都可以「反馈：判断有误」（J5）。
+
+### FR-M3-08 复查与状态沿用 · P0 [新增：明确规则]
+
+- 匹配规则：「清单项 + 问题类型」相同，就算同一个问题。
+- 问题还在：沿用上次的处理状态，标「沿用」；如果上次是「已修改」，改回「待处理」（说明没改好）。
+- 问题消失：自动关闭，标「本次已解决」；新出现的问题标「新增」。
+
+### FR-M3-09 检查报告导出 · P0
+
+PDF 报告内容：
+
+1. 首页：项目信息、投标文件版本、检查时间、规则版本、**检查覆盖范围**（查了什么、没查什么）、免责声明（辅助检查，不保证结果）；
+2. 汇总：各级别的问题数和处理状态；
+3. 问题明细：问题、出处、处理状态、处理人、时间、忽略原因；
+4. 附录：需人工核对的条目，以及勾选结果。
+
+**验收**：报告里不出现「通过 / 合格 / 保证」这类字样；生成的报告随项目归档，可以重复下载。
+
+---
+
+## M6 · 基础平台
+
+### FR-M6-01 项目工作台 · P0
+
+- 项目列表：名称、采购人、所投包、截止倒计时、状态、就绪状态、致命问题数。
+- 筛选：状态、截止时间区间；排序默认按截止时间。
+
+### FR-M6-02 项目状态流 · P0
+
+`跟进中 → 编制中 → 已检查 → 已递交 → 已归档`
+
+| 状态 | 进入条件 | 说明 |
+|---|---|---|
+| 跟进中 | 新建项目 | MVP 没有 M1，这个状态只是「刚创建」 |
+| 编制中 | 第一份招标文件解析成功 | 自动 |
+| 已检查 | 完成过至少一次检查 | 自动；另有「就绪 / 未就绪」标记 |
+| 已递交 | 用户手动标记 | 项目改为只读；可以撤销（留痕） |
+| 已归档 | 用户手动操作 | 可以随时撤销归档 |
+
+就绪状态和项目状态分开存：只有「已检查」状态才显示就绪状态（G7）。
+
+### FR-M6-03 额度计量 · P0
+
+- 额度账户按企业主体建；流水类型：发放 / 预扣 / 结算 / 退回 / 过期 / 人工调整（必须填原因）。
+- 额度页：本期已用、剩余、按功能分布，流水可以查到具体是哪个项目、哪个任务。
+- 用到 80%、100% 时站内提醒，同一阈值每个周期只提醒一次。
+
+**验收**：任何一笔扣点都能对应到一个任务；任何失败任务都没有净扣点。
+
+### FR-M6-04 账号与企业主体 · P0 [新增]
+
+- 手机号 + 验证码注册 / 登录；注册时填企业名称（MVP 不做企业认证，G9）。
+- 同一个手机号只能属于一个企业主体；风控：同一账号异地多设备并发登录时提示并限制（PRD 8.5）。
+
+### FR-M6-05 套餐与开通 · P0 [新增]
+
+- 免费版注册就有。
+- 专业版：用户在线提交开通申请（企业名称、开票信息）→ 对公转账 → 运营后台确认到账后开通，并开发票（G8）。线上自助支付以后再做。
+- 套餐到期后：数据保留，只读；额度清零（按 PRD，额度有效期跟着订阅周期走）。
+
+### FR-M6-06 数据删除 · P0
+
+见 J4；保留策略见 G10。
+
+### FR-M6-07 审计留痕 · P0
+
+- 记录的事件：清单修改、清单确认、问题处理、报告导出、项目状态变更、删除、额度人工调整。
+- MVP 只存储，不提供用户自助导出（P2）；运营后台可以查询。
+
+### FR-M6-08 最小资质库 · P0 [新增：从 P1 拆出]
+
+- 条目：资质名称、类型（资质证书 / 体系认证 / 软件著作权 / 其他）、等级、证书编号、发证机构、有效期起止、附件。
+- 只在 M3 资质匹配里用；完整的资产库（业绩、人员、历史标书）是 V1。
+
+### FR-M6-09 运营后台（最小版）· P0 [新增]
+
+用户 / 企业查询、套餐开通与续费、额度调整（带原因）、查看漏报 / 误报反馈、查看解析 / 检查任务的失败日志。

docs/analysis/04-domain-model.md

@@ -0,0 +1,117 @@
+# 04 · 领域模型草案
+
+> 这是需求层面的概念模型，不是数据库设计。字段只列出决定业务规则的那些，物理建模留到技术架构阶段。
+> 核心是 PRD 第 5 章说的「**项目检查清单**」：M2 产出它，M3 拿它做核对，V1 的 M4 拿它做生成约束，M5 也挂在它上面。
+
+## 1. 实体关系
+
+```mermaid
+erDiagram
+    Tenant ||--o{ User : "成员"
+    Tenant ||--o{ Subscription : "订阅"
+    Tenant ||--|| QuotaAccount : "额度账户"
+    QuotaAccount ||--o{ QuotaEntry : "流水"
+    Tenant ||--o{ Qualification : "资质库"
+    Tenant ||--o{ Project : "投标项目"
+
+    Project ||--o{ Lot : "包/标段"
+    Project ||--o{ SourceDocument : "招标文件/补遗/投标文件"
+    SourceDocument ||--o{ ParseJob : "解析任务"
+    SourceDocument ||--o{ Citation : "被引用"
+    Project ||--|| Checklist : "项目检查清单"
+    Checklist ||--o{ ChecklistItem : "清单项"
+    ChecklistItem }o--o{ Citation : "出处"
+    ChecklistItem }o--o| Lot : "所属包(空=通用)"
+
+    Project ||--o{ CheckRun : "检查批次"
+    CheckRun ||--o{ Finding : "问题"
+    Finding }o--|| ChecklistItem : "对应清单项"
+    Finding }o--o{ Citation : "双方出处"
+    Finding |o--o| Finding : "沿用自上次"
+    CheckRun ||--o| Report : "检查报告"
+
+    QuotaEntry }o--o| ParseJob : "关联任务"
+    QuotaEntry }o--o| CheckRun : "关联任务"
+```
+
+所有业务实体都带 `tenant_id`，按租户隔离（PRD 7）。
+
+## 2. 实体说明
+
+| 实体 | 关键字段 | 说明 |
+|---|---|---|
+| **Tenant** 企业主体 | 名称、统一社会信用代码（可空）、当前套餐 | 额度和数据的归属单位（PRD 4.3：额度绑定企业主体） |
+| **User** 用户 | 手机号、所属租户、角色 | MVP 一个租户一个成员；角色字段先留着，给 V1 用 |
+| **Subscription** 订阅 | 套餐、起止日期、来源（注册赠送 / 人工开通 / 线上支付） | |
+| **QuotaAccount / QuotaEntry** 额度 | 单位（解析 / 检查 / 生成 / 查重）、类型（发放 / 预扣 / 结算 / 退回 / 过期 / 调整）、数量、关联任务、原因 | 只追加、不修改；余额由流水算出来 |
+| **Qualification** 资质 | 名称、类型、等级、证书号、发证机构、有效期、附件 | MVP 最小资质库 |
+| **Project** 投标项目 | 名称、编号、采购人、代理机构、采购方式、**法律体系**、截止时间、状态、所投包 | 基本信息来自 FR-M2-03，用户可以改 |
+| **Lot** 包 / 标段 | 包号、名称、预算、最高限价、是否投标 | 没有分包时只有一个默认包 |
+| **SourceDocument** 文档 | 角色（招标文件 / 补遗 / 澄清 / 投标分册）、分册名、版本号、原始文件、规范化 PDF、页数、解析状态 | 所有文件都转成规范化 PDF，作为出处页码的唯一依据 |
+| **ParseJob** 解析任务 | 状态、阶段、模型与提示词版本、耗时、失败原因 | 一份文档可以有多次任务（重试） |
+| **Citation** 出处 | 文档、页码、原句、坐标范围 | 「可复核」的载体；清单项和问题共用 |
+| **Checklist** 检查清单 | 状态（草稿 / 已确认）、版本号、确认人、确认时间 | 每个项目一份；每次确认生成新版本 |
+| **ChecklistItem** 清单项 | 类别标签（可以多个）、标题、要求原文、重要性（★ / ▲ / 一般）、所属包、证明材料要求、比较方式与要求值（参数类）、来源（AI / 人工 / 补遗 N）、状态（待确认区 / 正式 / 已删除）、置信度 | 见 05 §3 |
+| **CheckRun** 检查批次 | 清单版本、投标文件版本集合、规则版本、状态、是否扣点 | 可以复现「当时根据什么做的判断」 |
+| **Finding** 问题 | 类型（未响应 / 负偏离未说明 / 疑似不满足 / 形式 / 资质 / 报价形式 / 人工核对）、级别、说明、出处、处理状态、忽略原因、处理人、处理时间、沿用来源 | |
+| **Report** 报告 | 文件、生成时间、生成人 | 生成后不再改动；重新导出就生成新报告 |
+| **AuditEvent** 审计事件 | 操作人、动作、对象、修改前、修改后、时间 | 不在上图中，所有实体都会写 |
+| **Feedback** 反馈 | 对象（问题 / 清单）、类型（误报 / 漏报）、说明、处理状态 | 进运营后台 |
+
+## 3. 状态机
+
+### 3.1 项目
+
+```mermaid
+stateDiagram-v2
+    [*] --> 跟进中: 新建
+    跟进中 --> 编制中: 首份招标文件解析成功
+    编制中 --> 已检查: 完成首次检查
+    已检查 --> 已检查: 复查
+    已检查 --> 已递交: 用户标记
+    已递交 --> 已检查: 撤销递交(留痕)
+    已检查 --> 已归档: 用户归档
+    已递交 --> 已归档: 用户归档
+    已归档 --> 已检查: 撤销归档
+    已归档 --> 已递交: 撤销归档(原状态为已递交)
+```
+
+「就绪 / 未就绪」是项目上单独的一个标记，不是状态：只要最近一次检查批次里还有「待处理」的致命问题，就是未就绪。
+
+### 3.2 解析任务
+
+```mermaid
+stateDiagram-v2
+    [*] --> 排队中: 发起(预扣1次)
+    排队中 --> 解析中
+    排队中 --> 已取消: 用户取消(退回)
+    解析中 --> 成功: 结算
+    解析中 --> 失败: 退回
+    解析中 --> 已取消: 用户取消(退回)
+    失败 --> 排队中: 重试(重新预扣)
+```
+
+### 3.3 问题（Finding）
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待处理
+    待处理 --> 已确认无误
+    待处理 --> 已修改
+    待处理 --> 已忽略: 必填原因
+    已确认无误 --> 待处理: 撤销
+    已修改 --> 待处理: 撤销
+    已忽略 --> 待处理: 撤销
+    note right of 待处理
+      复查时：问题仍在 → 沿用状态(已修改改回待处理)
+      问题消失 → 本次已解决
+    end note
+```
+
+## 4. 关键设计约束
+
+1. **出处统一用规范化 PDF 的页码**：Word 没有稳定的页码，必须先转成 PDF。转换结果存下来，以后不要重新生成，否则老的出处会对不上。
+2. **清单有版本**：检查批次引用的是清单的某个版本，后面再改清单，不影响历史报告。
+3. **额度流水只追加**：账户余额由流水算出来，所以「失败不扣点」可以从流水验证。
+4. **AI 产出记录模型和提示词版本**：解析任务、检查批次都要记，这样漏报复盘时能知道是哪个版本出的问题。
+5. **租户隔离**：所有查询都必须带租户条件；私有化（P2）时一个部署就是一个租户，模型不需要改。

docs/analysis/05-it-integration-domain.md

@@ -0,0 +1,130 @@
+# 05 · IT 集成领域知识（M2 提取 schema 与 M3 规则种子）
+
+> D1 决定 IT 集成先行。本文是需求分析阶段整理的领域知识，用来确定 M2 提取什么、M3 检查什么。
+> **证据等级**：标「已核实」的条款本次查到了原文或权威转述；标「待核对」的是按通行理解整理的，进入规则配置前必须对照法规原文。所有规则还要用真实招标文件样本验证（§6）。
+
+## 1. 先判断项目适用哪个法律体系
+
+IT 集成项目的采购人大量是政府机关、事业单位，**多数走政府采购体系**；国企采购、含信息化的工程建设项目走招标投标体系。两套体系的术语、无效情形、审查流程都不一样，所以 M2 要先识别体系（FR-M2-03），M3 再按体系套用规则。
+
+| 维度 | 政府采购体系 | 招标投标体系 |
+|---|---|---|
+| 主要依据 | 《政府采购法》及实施条例；《政府采购货物和服务招标投标管理办法》（财政部令第 87 号，2017-10-01 起施行，已核实）；非招标方式按财政部令第 74 号、竞争性磋商按财库〔2014〕214 号 | 《招标投标法》及实施条例 |
+| 采购方式 | 公开招标、邀请招标、竞争性谈判、竞争性磋商、询价、单一来源、框架协议等 | 公开招标、邀请招标 |
+| 角色称呼 | 采购人、采购代理机构、供应商 / 投标人 | 招标人、招标代理机构、投标人 |
+| 不合格的叫法 | **投标无效**（竞争性磋商叫「无效响应」，文件也叫「响应文件」，见 07 F4） | **否决投标** / 废标 |
+| 审查环节 | 资格审查 → 符合性审查 → 比较评价 | 初步评审（形式 / 资格 / 响应性）→ 详细评审 |
+| 异常低价 | 87 号令第 60 条：报价明显低于其他投标人，可能影响质量或诚信履约，评标委员会应要求书面说明；不能证明报价合理的，作无效投标处理（**已核实**） | 实施条例第 51 条：投标报价低于成本的，应否决（待核对） |
+| 投标保证金上限 | 不超过采购项目预算金额的 2%（实施条例第 33 条，待核对） | 不超过招标项目估算价的 2%（实施条例第 26 条，待核对） |
+
+> ⚠️ **影响 PRD 口径**：PRD 1.5 和 M3 把「异常低价否决」完全归为《招标投标法》修订草案的「草案层」。但对走政府采购的 IT 集成项目，87 号令第 60 条已经是现行规定。见 `06-gaps-and-questions.md` G2。
+
+## 2. 法定的无效 / 否决情形（M3 规则的法规来源）
+
+### 2.1 政府采购：87 号令第 63 条，投标无效（待核对）
+
+1. 没有按招标文件规定提交投标保证金；
+2. 投标文件没有按招标文件要求签署、盖章；
+3. 不具备招标文件规定的资格要求；
+4. 报价超过招标文件规定的预算金额或最高限价；
+5. 投标文件含有采购人不能接受的附加条件；
+6. 法律、法规和招标文件规定的其他无效情形。
+
+### 2.2 招标投标：实施条例第 51 条，否决投标（待核对）
+
+1. 没有经过投标单位盖章和单位负责人签字；
+2. 联合体投标没有提交共同投标协议；
+3. 不符合国家或招标文件规定的资格条件；
+4. 同一投标人提交两个以上不同的投标文件或报价（招标文件要求提交备选投标的除外）；
+5. 报价低于成本或高于最高投标限价；
+6. 没有对招标文件的实质性要求和条件作出响应；
+7. 有串通投标、弄虚作假、行贿等违法行为（产品不检查这一项）。
+
+### 2.3 政府采购供应商的通用资格（《政府采购法》第 22 条，待核对）
+
+独立承担民事责任的能力；良好的商业信誉和健全的财务会计制度；履行合同必需的设备和专业技术能力；依法缴纳税收和社会保障资金的良好记录；参加政府采购活动前三年内没有重大违法记录；法律、行政法规规定的其他条件。招标文件通常还会要求信用查询（信用中国、中国政府采购网的失信记录）。
+
+## 3. M2 提取 schema（IT 集成）
+
+招标文件的章节名称和顺序各地不一样，**提取不能依赖章节编号**。常见结构：招标公告 → 投标人须知（含前附表）→ 评标办法（资格 / 符合性审查表、评分标准）→ 采购需求（技术参数）→ 合同条款 → 投标文件格式。
+
+### 3.1 项目基本信息
+
+| 字段 | 备注 |
+|---|---|
+| 项目名称、项目编号 | 编号也用来检查投标文件里有没有写错 |
+| 采购人、代理机构 | 同上 |
+| 法律体系、采购方式 | 决定使用哪套规则 |
+| 包划分；每个包的预算、最高限价 | 报价形式检查要用 |
+| 是否接受联合体、进口产品；是否专门面向中小企业 | |
+| 评标方法 | 综合评分法 / 最低评标价法 |
+
+### 3.2 清单项通用字段
+
+| 字段 | 说明 |
+|---|---|
+| 类别标签 | 资格 / 无效条款 / 评分 / 日期与递交 / 技术参数 / 格式文件（可以有多个） |
+| 要求原文 | 原句，不改写 |
+| 要求摘要 | AI 生成的简短说明，界面标注是 AI 生成 |
+| 重要性 | ★ 实质性 / ▲ 重要 / 一般。常见用 ★ 标实质性条款、用 ▲ 标重要指标，但**样本中 3 / 10 份用「斜体 + 下划线」标实质性条款**（07 F1），所以必须先提取文件里的「标注规则说明」原文，再按规则识别 |
+| 所属包 | 空表示所有包通用 |
+| 证明材料要求 | 例如「提供合同关键页复印件及中标通知书」 |
+| 出处 | 一个或多个 Citation |
+
+### 3.3 各类别特有字段
+
+| 类别 | 特有字段 |
+|---|---|
+| 资格 | 资格类型（通用 / 特定 / 信用）、有效期要求（如「近 3 个月社保缴纳证明」） |
+| 无效条款 | 来源（法规列明 / 招标文件规定 / ★ 条款引申） |
+| 评分 | 评分因素、分值、评分标准、所属部分（价格 / 技术 / 商务）、中小企业价格扣除规则 |
+| 日期与递交 | 日期类型（提疑截止 / 投标截止 / 开标 / 保证金截止）、具体时间；保证金金额与形式；投标有效期；递交方式（电子 / 纸质 / CA 加密）；正副本份数；签章要求；密封要求 |
+| 技术参数 | 参数名、要求值、单位、比较方式（≥ ≤ = 包含 支持 / 具备）、所属设备或系统 |
+| 格式文件 | 格式名称（投标函、开标一览表、授权委托书、偏离表、中小企业声明函等）、是否允许修改 |
+
+## 4. IT 集成投标文件的常见结构（M3 检查对象）
+
+投标函；开标一览表（报价一览表）；分项报价表；法定代表人身份证明 / 授权委托书；资格证明文件（营业执照、财务报告或银行资信证明、纳税和社保证明、无重大违法记录声明、信用查询截图）；技术参数响应 / 偏离表；商务条款响应 / 偏离表；技术方案；实施与售后服务方案；类似项目业绩证明；资质与认证证书；中小企业声明函；各类承诺函。
+
+## 5. M3 规则种子清单（IT 集成 v0）
+
+| # | 规则 | 依据类型 | 自动化程度 | 默认级别 |
+|---|---|---|---|---|
+| R01 | 投标函、开标一览表等要求签章的位置没有签字 / 盖章 | 法规（2.1-2 / 2.2-1） | 半自动（有无检测，用户复核） | 致命 |
+| R02 | 缺少授权委托书，或授权代表和签字人不一致 | 招标文件 | 自动 | 致命 |
+| R03 | 报价超过限价（总价 / 采购包 / 分项或单价三层） | 法规（2.1-4 / 2.2-5） | 自动 | 致命 |
+| R04 | 开标一览表和分项报价合计不一致；大写和小写金额不一致（苏采云范本：不一致时不作无效，以开标一览表为准） | 招标文件 | 自动 | 重要 |
+| R05 | ★ 条款未响应 / 负偏离 / 疑似不满足 | 招标文件 | 自动 | 致命 |
+| R06 | ▲ 参数未响应 / 疑似不满足 | 招标文件 | 自动 | 重要 |
+| R07 | 资格证明材料缺失 | 法规（2.1-3 / 2.2-3） | 自动 | 致命 |
+| R08 | 资格证明过期或时效不够（按投标截止日算） | 招标文件 | 自动（需要资质库或文件里的日期） | 致命 |
+| R09 | 投标有效期短于要求 | 招标文件 | 自动 | 致命 |
+| R10 | 投标保证金的金额、形式与要求不符，或缺少缴纳凭证 | 法规（2.1-1） | 半自动 | 致命 |
+| R11 | 出现附加条件，例如「价格不含税」「付款方式另议」 | 法规（2.1-5） | 半自动（语义识别，用户复核） | 重要 |
+| R12 | 联合体投标缺少共同投标协议 | 法规（2.2-2） | 自动 | 致命 |
+| R13 | 不接受进口产品，却响应了进口产品 | 招标文件 | 半自动 | 致命 |
+| R14 | 改动了格式文件里的固定文字 | 招标文件 | 自动（和格式模板比对） | 重要 |
+| R15 | **文件里出现其他项目的名称、编号或采购人**（照搬旧标书留下的） | 实践 | 自动 | 重要 |
+| R16 | 落款日期晚于投标截止日，或者明显不合理 | 实践 | 自动 | 提示 |
+| R17 | 中小企业声明函格式或内容和要求不符 | 招标文件 | 半自动 | 提示 |
+| R18 | 评分项要求的证明材料缺失 | 招标文件 | 自动 | 重要 |
+| R19 | 份数、装订密封、递交方式、CA 加密 | 招标文件 | 人工核对 | 提示 |
+| R20 | 电子平台操作：按期通过平台获取招标文件（确认函）、CA 证书有效、提交线上投标文件、开标后按时解密（07 F7） | 招标文件 | 人工核对 | 重要 |
+
+说明：「依据类型」写进报告，说明每条问题的来源；「实践」类规则在报告里只能用「风险提示」的措辞。
+
+## 6. 样本语料
+
+> **进展（2026-11-02）**：第一批 10 份苏采云样本已入库，见 `samples/tenders/`，分析结论见 `07-sample-findings.md`。还缺扫描件、补遗和招标投标体系的样本。
+
+原计划：在原型和技术选型之前，收集 **5–10 份公开的 IT 集成招标文件**（可以从中国政府采购网和各省的政府采购网下载，都是公开信息），要覆盖：
+
+- 公开招标 / 竞争性磋商；
+- 分包 / 不分包；
+- 文字 PDF / 扫描件；
+- 至少 1 份有补遗；
+- 至少 1 份走招标投标体系的国企信息化项目。
+
+用途：① 确认 §3 schema 够不够用；② 人工标注 ★ 条款，作为 M2 召回率的基准；③ 原型用的样例数据；④ 技术选型时做解析和 OCR 测试。
+
+如果能拿到对应的真实投标文件（脱敏后），可以作为 M3 的基准。这需要种子用户配合。

docs/analysis/06-gaps-and-questions.md

@@ -0,0 +1,93 @@
+# 06 · PRD 缺口与待确认问题
+
+> 需求分析中发现的 PRD 缺失、矛盾或需要拍板的地方。每条都给了建议；用户确认后结论写入 `docs/decisions.md`，并回填相关文档。
+> 优先级：🔴 阻塞 MVP 设计 / 🟡 影响 MVP 细节 / 🟢 留到后面的阶段
+>
+> **状态（2026-11-02）**：G1–G10 全部按建议确认（`docs/decisions.md` A1），G2 已出 PRD v0.9.1；G11 由 T1（国产云端模型 + 按场景路由）部分决策；G12–G14 留到技术架构阶段。
+
+## 需要用户拍板
+
+### 🔴 G1 · 法律体系的双轨识别
+
+- **问题**：PRD 的政策依据只覆盖《招标投标法》体系，但 IT 集成项目多数走政府采购体系，术语（投标无效 / 否决投标）、无效情形和审查流程都不一样。
+- **建议**：M2 识别项目适用的体系，M3 按体系套用规则，界面和报告的术语跟着项目体系走（见 05 §1）。PRD 1.5 补充政府采购体系的依据。
+- ✅ **已决策**：按建议执行，PRD v0.9.1 新增「政策三」。
+
+### 🔴 G2 · 「异常低价」的口径需要修订
+
+- **问题**：PRD 把「异常低价否决」完全归为草案层，但财政部令第 87 号第 60 条（现行有效，已核实）已经规定：报价明显偏低、又不能证明合理性的，作无效投标处理。对政府采购项目，这是**现行层**。
+- **建议**：PRD 的双层口径扩成按体系区分：政府采购体系的 87 号令第 60 条属于现行层；招标投标体系里，实施条例第 51 条的「低于成本否决」是现行层，修订草案的「异常低价否决」才是草案层。这一项本来是 P1，不影响 MVP 开发，但**对外宣传的口径**现在就要改。
+- ✅ **已决策**：已修订，见 `docs/招投标AI工具PRD-v0.9.1.html` 1.5、第 5 章表格、M3。
+
+### 🔴 G3 · 多包 / 多标段
+
+- **问题**：PRD 没有提到分包。IT 集成采购常分包，每个包的资格、限价、参数都不一样；不按包区分，清单会混入不投的包，报价检查也没法做。
+- **建议**：纳入 MVP（FR-M2-04）。
+
+### 🔴 G4 · 资质匹配的数据来源
+
+- **问题**：M3「资质匹配检查」是 P0，依赖「企业资质库」，但资产库在 M6 是 P1。
+- **建议**：MVP 做最小资质库（只有资质，没有业绩、人员、历史标书），手工录入、记录有效期（FR-M6-08）。同时，资质匹配首先核对投标文件里有没有对应的证明材料，资质库只用来判断过期和等级。
+
+### 🟡 G5 · 「检查」的计费口径
+
+- **问题**：PRD 8.2 说专业版「废标检查不限项目数（按解析额度计）」，8.3 又把「检查」定义成独立的计量单位；免费版是「1 个项目」，不是次数。
+- **建议**：「检查」是独立单位，展示给用户；专业版的检查从解析池扣，1 次检查 = 1 次解析；同一项目 24 小时内复查免费；投标文件的解析算在检查里，不另外扣。免费版 = 1 个项目，这个项目内的检查和复查不限次数（单份页数有限制）。
+
+### 🟡 G6 · 加量包是否在 MVP 里
+
+- **建议**：MVP 不做线上加量包，由运营后台人工调整额度（带原因）。种子期用户少，先看用量分布，再定加量包的档位（和 D2 一起定）。
+
+### 🟡 G7 · 清单确认是否卡住检查
+
+- **建议**：不卡。清单没确认也能检查，但检查页和报告首页都要写明「清单未经确认」。这和 PRD「决定权在用户」的原则一致。
+
+### 🟡 G8 · 专业版怎么开通和付款
+
+- **问题**：PRD 没写支付。企业客户普遍要对公转账和增值税专用发票。
+- **建议**：MVP 第一阶段：用户在线提交开通申请 → 对公转账或付款码 → 运营后台人工开通并开发票。线上自助支付（微信 / 支付宝）在付费用户数量起来之后再做。
+
+### 🟡 G9 · 要不要做企业认证
+
+- **建议**：MVP 注册只填企业名称，不做营业执照认证。PRD 8.5 的「额度绑定企业主体」先通过「一个手机号只属于一个企业 + 异地并发登录风控」来实现。企业认证随团队版（V1）一起上。
+
+### 🟡 G10 · 「用户可以删除」和「全程留痕」冲突
+
+- **问题**：PRD 7 要求用户能自助删除数据，4.1 要求全程留痕；修订草案还拟要求资料至少保存 15 年（尚在审议、未施行）。
+- **建议**：用户删除项目时，业务内容（文件、清单、报告）彻底删除；保留不含业务内容的审计记录（操作类型、时间、项目编号的哈希）和额度流水。15 年保存是招标投标**当事人**的义务，不是工具提供方的；产品可以提示用户自己归档报告，平台不替用户保管。等草案通过后再复核。
+
+## 需要在技术架构阶段决定
+
+### 🔴 G11 · 用哪个大模型，以及国内合规
+
+- **问题**：SaaS 面向国内企业，标书属于敏感经营数据。要考虑：① 调用境外模型会涉及数据出境；② 《生成式人工智能服务管理暂行办法》下的备案和登记义务；③ 企业版要求模型私有化部署（PRD 7）。
+- **建议**：技术架构阶段做模型选型时专门评估，倾向于选用已备案的国产模型，并能私有化部署；具体的合规结论要找法务确认。PRD 7 已经写了「SaaS 版数据不用于训练公共模型」，需要和模型供应商的协议对齐。
+- ✅ **部分决策（T1）**：全部使用国内云端国产模型，不出境；按场景路由到多模态 / 快速 / 深度思考模型。**还剩**：确认所选模型都已备案、供应商协议里写明「数据不用于训练」、本产品自身的登记义务（法务确认）、企业版私有化时用什么模型（P2）。
+
+### 🟡 G12 · 签章检测的技术可行性
+
+- **问题**：「签字盖章位置有无」需要在 PDF 和扫描件里识别印章、手写签名，这需要视觉能力，准确率不确定。
+- **建议**：技术阶段用样本语料验证多模态模型（T1）的识别效果；如果准确率不够，R01 先降级为「请核对签章位置」，按人工核对处理（报告里写明）。
+
+### 🟢 G13 · 运营后台
+
+PRD 没提运营后台，但开通套餐、调额度、看反馈都离不开。MVP 做最小版（FR-M6-09），可以用现成的后台框架快速搭。
+
+### 🟢 G14 · 通知渠道
+
+PRD M1 提到站内、邮件、企业微信推送；MVP 只有额度提醒和解析完成提醒，建议只做站内通知 + 短信（注册时已经有短信能力）。
+
+## 种子用户访谈时确认
+
+### 🟡 G15 · 苏采云投标文件的实际准备方式（来自样本分析 07 F3）
+
+- **问题**：苏采云的投标文件是在「政府采购客户端工具」里按节点拼装的，导出的文件加密。产品只能检查导入客户端之前的材料。
+- **要问种子用户**：各节点的材料是先在 Word 里写好再导入，还是直接在客户端里填？最后一版的 Word / PDF 能不能方便地拿出来？
+- **影响**：M3 的上传方式和分册设计（FR-M3-01）。如果多数用户直接在客户端里填，M3 的输入方式要重新设计。
+
+## 已在文档中直接处理（不需要确认）
+
+- PRD M6 状态流没说「已检查」和「未就绪」是什么关系 → 拆成「状态」和「就绪标记」两个字段（04 §3.1）。
+- 复查时上次的处理结果怎么办 → 定了沿用规则（FR-M3-08）。
+- 「未找到响应」的问题没有投标文件这一侧的出处 → 改为写明搜索过的范围（FR-M3-03）。
+- 形式要件里有些项从文件里看不出来（份数、密封）→ 单独作为「需人工核对」一类（FR-M3-04）。

docs/analysis/07-sample-findings.md

@@ -0,0 +1,107 @@
+# 07 · 样本语料分析（苏采云 10 份）
+
+> 样本：`samples/tenders/`（S01–S10，均为江苏政府采购项目，2026-10 至 11 月发布）。方法：抽取纯文本后用正则统计结构特征，再人工抽查原文。
+> 目的：用真实文件验证 `05-it-integration-domain.md` 的提取 schema 和 M3 规则种子。下面的结论按对需求的影响排序。
+
+## 1. 统计概览
+
+| ID | 方式 | ★ | ▲ | 「无效」相关表述 | 分包 | 实质性条款标注方式 |
+|---|---|---|---|---|---|---|
+| S01 | 公开招标 | 30 | 15 | 18 | 无 | ★ |
+| S02 | 公开招标 | 12 | 8 | 14 | 无 | ★ |
+| S03 | 公开招标 | 30 | 33 | 23 | 无 | ★（文件写明「★ 项共 14 条」） |
+| S04 | 公开招标 | 30 | 22 | 13 | 无 | ★ |
+| S05 | 公开招标 | 1 | 0 | 12 | 无 | 只有文字说明 |
+| S06 | 公开招标 | 0 | 16 | 14 | 无（有分项限价） | **斜体 + 下划线** |
+| S07 | 公开招标 | 8 | 45 | 11 | 无 | ★ 或 *，以及「必须」「应」等字样 |
+| S08 | 竞争性磋商 | 0 | 8 | 10 | 无 | **斜体 + 下划线**；另有「实质性要求响应及偏离表」 |
+| S09 | 竞争性磋商 | 3 | 0 | 10 | 无 | ★ + **斜体 + 下划线** |
+| S10 | 公开招标 | 5 | 0 | — | **3 个采购包** | ★ |
+
+★ / ▲ 的计数包含说明性文字里的符号，不等于条款数，只用来看分布。
+
+## 2. 对需求的影响
+
+### 🔴 F1 · 实质性条款不能只靠 ★ 识别
+
+- 10 份里有 3 份（S05、S06、S08）基本没有 ★ 标记。**S06、S08、S09 用「斜体且有下划线」标注实质性要求**（S09 同时也用 ★）；S07 同时用 ★、* 和「必须 / 应当」字样。
+- **纯文本抽取会丢掉斜体和下划线**，S06、S08 的实质性条款会被全部漏掉。
+- **影响**：
+  - FR-M2-05：识别实质性条款时，先从文件里找到「标注规则说明」（例如「加注 ★ 的为实质性要求」「斜体且有下划线部分为实质性要求」），再按说明去识别，不能写死成 ★。
+  - 技术架构：解析 Word 时要保留文字格式（斜体、下划线、加粗），不能只取纯文本。
+  - 有的文件写明了 ★ 条款总数（S03「★ 项共 14 条」），可以用来自动检查有没有漏抽；数量对不上就提示用户。
+
+### 🔴 F2 · 文件扩展名不可信
+
+- 10 份全部叫 `.doc`，实际是 DOCX 6 份、DOCX（不压缩的 zip）2 份、旧版 DOC（WPS 生成）2 份。
+- **影响**：FR-M2-01 要按文件头识别真实格式，不能看扩展名；旧版 DOC 必须支持。
+
+### 🔴 F3 · 苏采云的投标文件是在客户端工具里制作的
+
+- 流程：下载 `.kedt` 文件 → 导入「政府采购客户端工具」→ 按节点填写或上传材料（S09 写「上传至符合性审查节点」）→ 导出加密的 zip → 上传。
+- **影响**：用户在客户端里拼装的最终文件是加密的，产品读不了。M3 只能检查用户在**导入客户端之前**准备的各节点材料（Word / PDF）。这正好对应我们的「多个分册」设计，但分册应该能对应到客户端的节点（资格审查、符合性审查、商务、技术、报价）。**需要找种子用户确认他们实际怎么准备文件**（新增 G15）。
+
+### 🟡 F4 · 政府采购体系内部，术语也随采购方式变化
+
+| | 公开招标 | 竞争性磋商 |
+|---|---|---|
+| 文件 | 招标文件 / 投标文件 | 磋商文件 / 响应文件 |
+| 须知 | 投标人须知 | 供应商须知 |
+| 评审 | 评标方法与评标标准 | 评审方法与评审标准 |
+| 不合格 | 投标无效 | 无效响应 / 响应无效 |
+| 有效期 | 投标有效期 | 磋商有效期 |
+
+**影响**：界面和报告的术语要跟着「采购方式」走，不只是跟着法律体系走。
+
+### 🟡 F5 · 苏采云文件用统一的六章范本
+
+10 份都是：第一章 公告 / 邀请 → 第二章 须知 → 第三章 合同文本 → 第四章 采购需求 → 第五章 评标（评审）方法 → 第六章 投标（响应）文件格式。
+
+**影响**：可以按地区维护「范本画像」（江苏范本：第二章抽无效条款和递交要求，第四章抽技术参数，第五章抽评分项），提高抽取准确率；没匹配上范本时再走通用抽取。这是首发聚焦江苏的一个实际好处。
+
+### 🟡 F6 · 报价规则比预想的细
+
+- **限价有三层**：总价、采购包限价（S10）、分项限价（S06），还有单价上限（S10）。任何一层超了都是无效。→ R03 要按三层检查。
+- **开标一览表和分项报价不一致，不按无效处理**，以开标一览表为准（S01、S05、S06 原文都这么写）。→ R04 保持「重要」，说明写清楚依据。
+- **异常低价**：**10 份全部**写入了 87 号令第六十条的原文（「不能证明其报价合理性的……作为无效投标处理」），这已经是苏采云范本的标准条款；S10 还给了明确阈值「投标报价低于最高限价 50%」。→ 进一步印证 G2；P1 的报价合理性检查应该**优先从招标文件中读取阈值**，没有阈值时才提示。
+
+### 🟡 F7 · 苏采云平台特有的无效情形
+
+- 「未在规定期限内通过苏采云获取招标文件的，投标无效」（S03）；
+- 「未提供线上投标文件的，投标无效」（S04）；
+- 开标后远程解密失败，文件会被退回（S01）。
+
+**影响**：R19「需人工核对」清单要加上平台操作类条目（获取文件确认函、CA 证书有效、按时解密）。这类条目价值高，又最容易被新手漏掉。
+
+### 🟡 F8 · 信创 / 国产化要求很常见
+
+10 份里有 5 份涉及信创 / 国产化（S01、S02、S05、S07、S08），常以 ★ 条款出现，例如「设备采用国产自主可控 CPU 芯片……提供国产化适配承诺函」。商用密码、等级保护也常见。
+
+**影响**：证明材料的类型要比原来想的多：承诺函、官网参数截图、检测报告、认证证书。M3 资质匹配要能识别这些类型。
+
+### 🟢 F9 · 资格材料有明确的时间窗口
+
+例如「参加政府采购活动前半年内（2026 年 05 月–2026 年 10 月）任一月的纳税凭据」。
+
+**影响**：R08 判断时效时，要从原文解析出时间窗口，并对照投标截止日。
+
+### 🟢 F10 · 用声明函代替原件
+
+江苏的通用条款：「提交各类声明函、承诺函，不再同时提供原件……中标后核查」。资格证明很多是声明函。
+
+**影响**：资格检查对声明函类材料只检查「有没有、签章全不全」，不核实内容。这和产品「不编造、不鉴定」的原则一致。
+
+## 3. 对 MVP 范围的确认
+
+| 已确认的 MVP 决策 | 样本里的证据 |
+|---|---|
+| G1 体系识别 | 10 份都是政府采购；还要细分到采购方式（F4） |
+| G2 异常低价口径 | 10 份全部写入第六十条原文，S10 写了阈值（F6） |
+| G3 多包 | S10 有 3 个采购包，各自有限价 |
+| 报价形式检查升为 P0 | 三层限价，超限即无效（F6） |
+
+## 4. 下一步
+
+1. 补齐样本缺口：扫描件、补遗、招标投标体系、配套投标文件（见 `samples/tenders/README.md`）。
+2. 人工标注 S01–S10 的实质性条款，作为 M2 召回基准。先标 S03（文件写明有 14 条 ★ 项）和 S06（斜体下划线）这两份最难的。
+3. 技术架构阶段，用这 10 份做 Word 解析选型，重点是保留文字格式、支持旧版 DOC、能定位页码。

docs/analysis/README.md

@@ -0,0 +1,32 @@
+# 需求分析（MVP · IT 集成）
+
+> 阶段：需求分析 · 2026-11-02 · 依据：PRD v0.9 + D1（IT 集成先行）
+
+| 文档 | 内容 |
+|---|---|
+| [01-scope-roles.md](01-scope-roles.md) | MVP 范围边界、角色、计费口径 |
+| [02-user-journeys.md](02-user-journeys.md) | 五条用户旅程（首次体验、真实项目迭代、额度、删除、反馈） |
+| [03-functional-requirements.md](03-functional-requirements.md) | 功能需求和验收标准（FR-M2 / M3 / M6） |
+| [04-domain-model.md](04-domain-model.md) | 领域模型、状态机、关键设计约束 |
+| [05-it-integration-domain.md](05-it-integration-domain.md) | IT 集成领域知识：法律体系、提取 schema、M3 规则种子 R01–R19 |
+| [06-gaps-and-questions.md](06-gaps-and-questions.md) | PRD 缺口与待确认问题 G1–G15 |
+| [07-sample-findings.md](07-sample-findings.md) | 苏采云 10 份样本分析：实质性条款标注、文件格式、报价规则等 F1–F10 |
+
+## 主要发现
+
+1. **IT 集成多数走政府采购体系**，PRD 的政策依据只覆盖招标投标体系，产品要先识别项目适用的体系（G1）。
+2. **87 号令第 60 条已经规定了异常低价无效**，PRD 把它归为「草案层」，对政府采购项目来说不准确，对外宣传的口径要改（G2）。
+3. **MVP 跑通还缺四块**：多包、最小资质库、报价形式检查、运营后台（G3、G4、FR-M3-06、G13）。
+4. **「项目检查清单」要有版本、有出处、按包划分**，它是全产品数据设计的核心（04）。
+5. **最大的技术风险**：★ 条款召回率、原文回链准确率、签章检测、模型合规（G11、G12）。建议先收集 5–10 份公开的 IT 集成招标文件做语料（05 §6）。
+
+## 决策状态
+
+- 2026-11-02：G1–G10 全部按建议确认（`docs/decisions.md` A1）；G2 已出 PRD v0.9.1。
+- 2026-11-02：大模型策略定为国产云端模型 + 按场景路由（T1）。
+
+## 下一步
+
+1. ~~收集样本语料~~：第一批 10 份已入库（`samples/tenders/`），结论见 07。后续补扫描件、补遗、招标投标体系的样本，并人工标注实质性条款。
+2. 进入主题 / 品牌设计和原型设计（原型样例数据改用真实样本 S10，它有 3 个采购包）。
+3. 技术架构：模型路由层、文档规范化与出处定位、签章检测可行性（G12）。