# 案例审核规范

创建人员：management.admin
文件职责：记录 `project-info` 项目案例审核员必须遵守的本地审核规范，覆盖研报案例的设计审核、执行审核、存储归档审核、输出审核、结论边界审核和复审。
管理规范/模板：../../common/ana-doc/案例审核规范.md；../../common/ana-doc/案例分析环境创建指南.md。
引用文件：案例分析规范.md；数据抓取脚本说明.md；案例存储体系.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；研报体系/研报解析架构.md；研报体系/研报分析架构.md；../项目配置清单.md。
记录方式：项目本地审核规范；审核口径变化时更新，并同步项目变更记录。

## 1. 基本口径

本项目所有案例审核员必须同时遵守 `../../common/ana-doc/案例审核规范.md` 和本文件。`laoshen` 是本项目案例审核员，同时兼任案例分析开发审核员；案例分析开发相关审核结论统一写入 `ana-doc/案例审计报告.md`。

审核员的目标不是只看 summary，而是确认案例是否真的按设计执行、证据是否可追溯、存储是否可复核、结论是否不过读、问题是否闭环。

本文件负责把 `研报解析架构.md` 和 `研报分析架构.md` 中的研报专业要求转化为 ana 案例体系的审核口径。行业目录内的 `案例审核规范.md` 默认只作为继承入口和行业补充检查，不应复制本文件的阶段门、审核类型、阻断条件和问题闭环规则。

审核时必须区分研报方法母版和行业本地方案：

1. `研报体系/研报解析架构.md` 是研报解析指导思想和方法母版，不作为某个行业输出文件清单、子行业拆分、公司范围或执行细节的日常修改对象。
2. `<行业>研报解析方案.md` 是该行业具体实施的指导性文档。行业输出文档架构、稳定中文文件名、子行业三件套、公司文档范围、数据表和暗线入口，应以行业方案为准。
3. 审核员发现某行业输出结构、文件清单、子行业拆分或执行策略不清时，应要求分析员修复行业本地方案和案例设计，不应直接要求修改 `研报解析架构.md`。
4. 只有规则明显需要跨行业长期适用，且提交方明确说明母版级影响范围时，才进入 `研报解析架构.md` 母版维护审核；否则母版不应被行业个案反复修改。

## 2. 审核范围

审核员至少检查：

1. 设计是否明确案例来源、目标、边界、证据要求、输出物和验收方式。
2. 执行是否按设计完成，证据路径是否可打开、可追溯。
3. 文件、证据、输出和 manifest 是否按 `案例存储体系.md` 归档。
4. 研报观点是否被拆成事实、数据、观点、假设和缺口，而不是直接当事实。
5. 结论是否降读，是否避免交易建议、收益承诺和未经验证的强因果判断。
6. K 线、成交量、市场背景、替代解释、市场反向补漏是否按任务需要纳入。
7. 暗线、事件链、意图判断是否与普通行业事实分离。
8. 单篇定位、批量最低产物、`unresolved_data_gap.csv`、`source_gap_audit.csv` 和冲突观点分账是否完整。
9. 是否存在从其他项目复制的旧内容、旧路径、旧结果包或旧业务结论。
10. 是否遵守“主体内容落文档和结果包，窗口只展示摘要和证据入口”的上下文保护要求。
11. 涉及外部抓取、本地 MySQL 导出或市场反向补漏脚本时，是否遵守 `数据抓取脚本说明.md`，脚本产物是否有 manifest、参数、SQL、hash、输出路径和只读边界。
12. 审核请求引用的正式文档、条目 ID、结果包和证据入口是否在提交审核前已经落地；如无法证明提交前已存在，必须标记为补录风险或时序缺陷，不得直接给出无条件通过。

审核前置核查要求：

1. 审核员接到设计审核、执行审核、输出审核或复审请求后，必须先核查消息中列出的审核对象是否真实存在。
2. 前置核查至少记录：消息 ID、消息创建时间、审核对象路径、条目 ID、文件位置或行号、当前文件修改状态、是否存在提交后补录风险。
3. 若审核对象在正式文档中不存在，审核结论只能为 `需补充`、`退回修改` 或 `HELD`，不得用消息摘要替代正式文档进行审核。
4. 若审核对象当前存在但无法确认是否在提交前已存在，审计报告必须写明“提交前落地状态无法证明”，结论不得高于有条件通过，除非后续重新提交审核。
5. 若确认存在提交后补录、先执行后补设计、先提交后补证据等时序倒置，必须作为审计问题记录，要求分析员按补录后的当前版本重新提交审核。

来源聊天记录审核口径：

1. 设计审核、执行审核、输出审核和重要复审必须核查送审正文或正式文档中是否给出来源聊天记录入口或等价来源入口。
2. 合格来源入口可以是 MB-X `message_id`、会话 marker、原始聊天导出文件路径、管理系统消息记录路径，或能反查用户原始要求的稳定入口。
3. 审核员核查重点是：来源入口是否可追溯、覆盖消息范围或时间范围是否清楚、用户原始要求摘要是否与本次设计/执行/输出一致、本次变更是否能对应原始要求。
4. 审核员不得要求分析员在送审消息中全文粘贴长聊天记录；长聊天可以保留在正式来源文件、消息链或可复核入口中。
5. 同一长期案例的连续小修、复审或执行轮次，可以复用既有来源聊天记录入口；审核员只需核查本轮是否补充新增用户要求或新增消息范围。
6. 若来源入口缺失、不可打开、覆盖范围不清，或设计/输出目标与来源聊天明显不一致，应作为阻断或需补充问题处理。
7. 对错别字、格式、链接显示等不影响目标、流程、证据、输出和结论边界的小修，不得因未新建完整聊天证据包而加码退回；可要求在执行日志中引用既有来源入口。
8. 送审事项引用“用户要求、用户反馈、用户确认、用户补充”等内容时，审核员必须核查用户原文入口：关键聊天原文、聊天记录路径、案例总纲来源位置或可追溯的 `message_id`。只有分析员转述而没有用户原文入口时，不得给出通过结论，应要求补充来源入口；该要求只补来源依据，不要求重跑分析、补资料或新增执行轮次。
9. 审核员必须核对送审变更、方案或输出是否符合用户原文意思，并在审计记录中区分“用户明确要求”“分析员基于用户要求的推导”和“分析员自行新增的执行方案”。摘要和原文冲突时，以用户原文为准。

## 3. 审核类型

研报案例至少覆盖以下审核类型：

1. 新行业容器创建审核：检查 `<行业>案例/` 目录、基础文档、行业方案、父级导读登记和审计入口是否完整，并确认行业目录没有平行的 `案例总纲.md`。
2. 行业方案审核：检查 `<行业>研报解析方案.md` 是否继承研报解析架构、研报分析架构和父级案例存储体系。
3. 案例设计审核：检查目标、边界、输入资料、执行步骤、证据要求、输出物、存储路径和验收方式是否完整。
4. 执行过程审核：检查执行日志是否能还原研报读取、转换、抽取、补充、分析、输出和归档全过程。
5. 存储归档审核：检查行业级 `raw/`、`converted/`、`extracted/`、`supplement/`、`evidence/`、`manifest/`，案例级 `outputs/`、`manifest/`、`evidence/`，以及父体系 `tmp/`、`result/`、`img/` 是否按规则使用。
6. 输出文档审核：检查行业视图、市场视图、公司视图和扩展文档是否有证据支撑。
7. 结论边界审核：检查强结论、投资读法、公司判断、行业判断是否过读。
8. 复审：检查前次审计问题是否被修复，是否产生新问题；行业方案、案例设计、存储路径、证据链、输出文档或结论边界发生实质变化时，也必须进入复审。

行业子审核规范使用规则：

1. 行业 `案例审核规范.md` 必须声明继承父级 `案例审核规范.md`、父级 `案例分析规范.md`、父级 `案例存储体系.md` 和两份研报方法母版。
2. 没有行业自定义审核点时，行业 `案例审核规范.md` 只记录继承关系、当前覆写状态和少量行业补充检查。
3. 行业专业审核点应来自 `<行业>研报解析方案.md`、行业 `案例分析设计.md` 和已通过的设计审核，不能削弱父级阶段门、阻断条件、证据追溯、存储归档和结论边界要求。
4. 如果行业子审核规范和父级审核规范冲突，审核员先按父级审核规范执行，并把冲突点作为审计问题或规范维护事项处理。

## 4. 研报分析流程审核

审核员必须按 `案例分析规范.md` 的“案例分析员融合执行流程”检查研报案例，不得只看最终 summary。

| 阶段 | 审核重点 | 阻断条件 |
|---|---|---|
| `G0` 任务接入 | 来源聊天、目标、边界是否进入总纲或设计 | 来源不明、目标和用户要求不一致 |
| `G1` 行业容器 | 行业目录是否存在，是否无平行 `案例总纲.md` | 行业过程明细写回父级或行业内建总纲 |
| `G2` 行业方案 | `<行业>研报解析方案.md` 是否从模板升格为可执行方案 | 方案缺失、仍是模板、没有行业边界和输出方案 |
| `G3` 案例登记与设计 | 父级总纲是否登记真实案例，行业设计是否冻结 batch/run | 没有父级总纲，或把每批资料误建成新案例 |
| `G4` 设计审核 | 设计审核是否先于正式执行 | 未审核就正式分析 |
| `G5` 资料归档与转换 | raw、converted、manifest、hash、文件头识别是否完整 | raw 未归档、路径不可复核、转换状态不清 |
| `G6` 抽取与补数 | evidence、extracted、supplement、缺口和 darkline 是否按需处理 | 观点当事实、缺关键数据却写强结论 |
| `G7` 人读输出 | 行业视图、市场视图、公司视图是否有证据支撑 | 只有标题式结论或三类视图缺失 |
| `G8` 自检与归档 | tmp/result/img 分流、manifest、验证报告是否完整 | 临时文件当证据，缺 result 入口或图片 manifest |
| `G9` 执行审核与回写 | 审计、复审、总纲/设计/方案回写是否完成 | 未复审就标记完成或对外交付 |

分析流程审核要求：

| 审核面 | 必查问题 | 阻断条件 |
|---|---|---|
| 案例分析员融合执行流程 | 是否按 `案例分析规范.md` 的“案例分析员融合执行流程”执行，覆盖来源、总纲、设计、设计审核、执行、日志、结果包、执行审核、修复复审和回写 | 研报流程只写专业处理步骤，缺少 common 生命周期任一硬控制点 |
| ana 来源和总纲 | 研报任务来源、目标、行业、边界是否先进入父级总纲 | 只有行业方案或输出文档，父级总纲没有来源入口 |
| ana 设计冻结 | 行业设计是否写清 `case_id/batch_id/run_id`、输入范围、执行步骤、证据要求、输出和验收 | 设计只是标题或任务描述，不能指导执行 |
| 研报行业方案 | `<行业>研报解析方案.md` 是否把行业边界、核心变量、输出方案、专属表、流程覆写和缺口写清 | 方案仍是模板，或只引用母版但无行业展开 |
| 研报归档转换 | raw、converted、source_document、conversion_status、hash、文件头识别是否可追溯 | 只读资料、不归档，或转换结果无法反查 raw |
| 研报抽取补数 | extracted、evidence、supplement、数据卡、缺口、`unresolved_data_gap`、`source_gap_audit` 和 darkline 分流是否存在 | 观点直接进结论，缺核心数据却没有缺口状态 |
| 人读输出 | 行业视图、市场视图、公司视图是否从证据链生成 | 三类视图缺失，或细分文档替代顶层视图 |
| 存储分流 | 行业级通用产物、案例级输出、父体系 `tmp/result/img` 是否各归其位 | raw 或通用产物落入逐案例目录，tmp 被当正式证据 |
| 审计闭环 | 执行日志、审计报告、修复、复审、总纲/设计/方案回写是否完整 | 未复审就交付，或审计问题没有主记录 |

行业方案审核必须单独给结论。审核员至少检查：

1. 方案是否明确本行业包含和不包含的范围。
2. 方案是否列出核心子行业、技术路线、商业模式、产业链分层或主导变量。
3. 方案是否说明行业视图、市场视图、公司视图和扩展文档怎么输出。
4. 方案是否定义行业专属表、文件型清单或明确本轮暂不建表。
5. 方案是否说明 raw、converted、extracted、supplement、evidence、manifest、outputs、tmp、result、img 的落点。
6. 方案是否说明是否覆写母版流程；如果覆写，是否保留父级总纲、设计审核、执行日志、执行审核、问题闭环和结论回写。
7. 方案是否明确缺口清单、市场反向补漏和 darkline 触发边界。
8. 方案是否仍写着“模板”“待正式任务补齐”等不能支撑正式执行的状态。若仍是模板，只能允许容器初始化或体系 dry-run，不得允许正式研报分析。
9. 行业输出文档架构、文件清单、子行业拆分、公司文档范围、数据表和暗线入口是否落在 `<行业>研报解析方案.md` 或已审核设计中，而不是要求修改 `研报解析架构.md` 才能执行。

管理端自检和正式审核必须区分。Codex 或管理端可以做体系维护自检，但自检结论不能冒充 `case_analysis.reviewer / laoshen` 的正式审核结论；正式放行仍以项目配置清单中的审核员角色为准。

方案、设计和输出复审触发规则：

1. `<行业>研报解析方案.md` 新建、从模板升格、重要优化，或变更行业边界、核心变量、输出方案、专属表、流程覆写、存储落点、缺口清单时，必须审核或复审。
2. `案例分析设计.md` 新建，或变更资料范围、case/batch/run、执行步骤、证据要求、输出物、存储路径、darkline 触发边界或验收方式时，必须审核或复审。
3. 正式资料归档、转换、抽取、补数、证据组织、核心文档输出或 manifest 归档完成后，必须执行审核。
4. 核心文档准备对外交付、进入正式结果入口或回写完成状态前，必须通过输出审核或执行审核。
5. 仅修改错别字、格式、链接显示等不影响流程、证据、存储、输出和结论边界的小修，可以只抽查维护记录；如审核员判断影响可复核性，仍应要求复审。
6. 行业个案对输出文档架构、子行业文件、公司文件或数据表入口的调整，默认触发行业方案或案例设计复审；不得默认触发 `研报解析架构.md` 母版复审。

补证轮次上限审核口径：

1. 审核员发现资料、来源、PDF 转换、网页归档、市场数据或公司官方源仍有缺口时，必须先核查该缺口已补证几轮、每轮是否有 `run_id`、输入范围、结果、失败项和 review_status，而不是直接要求无限继续补资料。
2. 同一案例、同一类证据缺口或同一组相关缺口已完成 3 轮补证后，审核员必须优先核查行业 `待补资料清单.md` 或等价行业级待补资料清单；不得只看核心文档正文是否列完整明细。
3. 行业待补资料清单已记录缺口组、已补轮次、影响范围、降级状态、后续所需资料、证据入口和更新时间，且核心文档、result_index 或缺口摘要能反查该清单时，审核员不得因清单未清空而要求继续围绕同一缺口补第 4 轮。
4. 同一案例、同一类证据缺口或同一组相关缺口已完成 3 轮补证后，若分析员已把剩余缺口写入行业待补资料清单、缺口表、证据卡、result_index 或核心文档证据边界，并用 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`HELD_BY_ENV`、`HELD_BY_ACCESS`、`HELD_BY_EVIDENCE_GAP` 或等价状态降级，审核结论可以允许继续推进 DRAFT 输出。
5. 第 4 轮及以后补证只在有新资料、新权限、环境恢复、前三轮执行错误或核心文档完全不可读等例外情况下要求；审核员要求例外补证时，必须说明例外原因、影响范围和最小补证目标，并核查分析员是否在设计或执行日志写明例外依据。
6. 少量 PDF/网页归档/访问受限失败项已登记且不影响主线草稿可读性时，不应作为阻断项；应要求保留缺口状态、行业待补资料清单入口和正式输出前置条件。
7. 缺口规模大到影响核心覆盖，例如失败项超过本轮关键输入的 10%、集中影响核心品种/核心公司/核心指标，或导致三类核心文档无法形成最低可读草稿时，审核员应要求分析员向用户说明影响范围，并输出有限范围结果或请求补资料，而不是静默继续多轮补证。
8. 审核重点应从“缺口是否完全消失”转为“补证轮次是否达到上限、行业待补资料清单是否可追溯、结论是否正确降级、继续推进是否会误导用户”。

市场反向补漏审核要求：

1. 设计是否说明本轮是否需要市场反向补漏；如果不做，是否有清楚的适用性判断。
2. 需要做补漏时，是否使用 `darkline` 拉取或分析近 3 个月强显影股票清单，至少覆盖涨停或多次涨停、连续大涨、放量突破、逆行业上涨、明显强于同行、资金持续显影。
3. 是否按公司核心业务重新归因，而不是只按题材标签、宽关键词或研报覆盖标签归类。
4. 是否给每个对象标记 `scope_type`：`CORE_INDUSTRY`、`ADJACENT_DOWNSTREAM` 或 `FALSE_THEME_OR_NOISE`。
5. `CORE_INDUSTRY` 是否进入补资料清单；`ADJACENT_DOWNSTREAM` 是否单独 review；`FALSE_THEME_OR_NOISE` 是否只保留审计记录。
6. 是否产出 `market_manifestation_gap_audit.csv`、`market_manifestation_gap_priority.csv`、`market_manifestation_gap_summary.json` 或等价结构化表。
7. 是否把市场反向补漏用于发现缺口，而不是直接当作投资结论或公司推荐依据。

## 5. 设计审核

设计审核在正式执行前进行。行业方案未通过审核或复审时，设计审核不得放行；设计审核未通过，不得进入正式研报分析执行。

必须检查：

1. 父级 `案例总纲.md` 是否记录来源聊天、上游依据、行业范围、目标和边界。
2. 是否确认行业案例目录；不存在时是否按新行业创建流程创建。
3. 是否读取父级 `案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md` 和研报方法母版。
4. 是否创建或更新 `<行业>研报解析方案.md`。
5. 行业方案是否说明行业边界、子行业、核心变量、人读输出、行业专属表和缺口。
6. 设计是否明确原始资料来源、样本范围、执行步骤、证据要求、输出物、存储路径和验收方式。
7. 设计是否把 `案例分析规范.md` 的“案例分析员融合执行流程”落成具体步骤，而不是只写阶段名或最终目标。
8. 是否说明是否需要外部信息补充、市场反向补漏或 darkline 分析；需要市场反向补漏时，是否写明近 3 个月强显影股票扫描口径、scope 闸门、补资料输出和不把市场显影直接当投资结论的边界。
9. 是否说明主动补数据触发条件、`unresolved_data_gap.csv`、`source_gap_audit.csv`、单篇/批量最低产物和冲突观点分账要求。
10. 是否说明 MySQL 或结构化记录的使用范围和追溯方式。
11. 如需使用 `ana-data/tools/` 脚本，是否说明脚本名、输入范围、关键词或 SQL 来源、输出路径、manifest、只读边界和复核方式。
12. 是否明确 `PASS / FAIL / HELD` 或等价验收标准。
13. 设计条目是否在提交设计审核前已经写入正式 `案例分析设计.md` 或行业子目录对应设计账本；审核员必须记录条目 ID、文件路径和行号。若设计条目为提交后补录，必须退回或要求重新提交审核。
14. 送审正文或设计条目是否给出来源聊天记录入口、覆盖范围和用户原始要求摘要；长期案例是否正确复用已有来源入口并补充本轮新增要求。

如果案例事项使用行业自定义流程，设计审核必须检查该流程是否满足父级案例体系硬约束。行业流程通过设计审核后，执行审核以已通过的行业流程为准；只有发现行业流程违反父级硬约束时，才要求整改。

## 6. 执行审核

执行审核在案例执行后进行。执行审核未通过，不得把案例事项标记为完成或可交付。

必须检查：

1. 执行是否按已审核通过的设计进行。
2. 执行日志是否记录资料归档、转换、抽取、补充、证据、输出和自检。
3. 执行日志是否能按“案例分析员融合执行流程”还原：来源总纲、行业方案、设计审核、raw 归档、转换抽取、补数分流、证据数据卡、人读输出、归档自检、执行审核。
4. 原始资料是否全部进入行业统一 raw 池 `ana-data/cases/<行业案例>/raw/`，且未被覆盖、改写。
5. 转换文本、表格、OCR、页面切分结果是否进入行业级 `converted/`。
6. 事实、指标、观点、公司映射、缺口是否进入行业级 `extracted/` 或等价结构化记录。
7. 外部公开资料补充和市场反向补漏是否进入行业级 `supplement/`，市场显影证据、范围闸门和补漏结论是否进入行业级 `evidence/` 或等价结构化记录。
8. 通用证据事实、数据卡底座、来源定位是否进入行业级 `evidence/`；案例结论证据映射是否进入案例级 `evidence/`。
9. 单篇研报是否保留 doc_id、页码或段落定位、句子/表格索引、时间、单位、口径、对象归属和置信度。
10. 批量研报是否输出或更新 `input_manifest.csv`、`conversion_status.csv`、`evidence_fact_table.csv`、`classification_summary.csv`、`unresolved_data_gap.csv`、`source_gap_audit.csv`、`batch_summary.md`、`next_action_list.csv` 或等价结构化记录。
11. 资料之间的支持、反对、重复观点和口径冲突是否分账记录，没有被强行合并。
12. 正式输出是否进入案例级 `outputs/`。
13. 行业级 `manifest/` 是否记录文件清单、来源清单、处理批次、执行轮次、hash 或等价摘要，并包含 `case_id`、`batch_id`、`run_id`；案例级 `manifest/` 是否记录本案例引用了哪些行业级资料。
14. 临时文件是否进入 `ana-data/tmp/<行业案例>/<case_id>/<run_id>/`，且没有被当成正式证据或正式结果入口。
15. 结果入口或交付包索引是否进入 `ana-data/result/<行业案例>/<case_id>/`；涉及图片时，图片、截图、OCR 图片或图册是否进入 `ana-data/img/<行业案例>/<case_id>/`。
16. MySQL 或结构化记录是否能反查案例 ID、原始资料、转换结果、证据和输出路径。
17. 如使用 `ana-data/tools/` 脚本，输出是否进入行业 `supplement/evidence/manifest` 或父体系 `tmp/result/img`，SQL 是否只读，manifest 是否记录脚本参数、输出路径和 row_count。
18. 结论是否没有超过证据。

执行审核还必须抽查本轮是否正确处理 `batch_id` 和 `run_id`：

1. 同一研究目标的多次资料读取是否仍属于同一个案例。
2. batch 是否只表达输入批次，不表达新的行业案例。
3. run 是否只表达执行轮次，不替代设计审核或审计记录。
4. manifest、source_document、conversion_status、evidence_index 和案例输入清单中的 `case_id/batch_id/run_id` 是否一致。

## 7. 输出审核

输出审核在核心文档对外交付、进入正式结果入口或回写完成状态前进行。审核员必须检查人读文档是否真正满足研报体系的输出要求：

1. 行业视图是否讲清行业是什么、怎么运行、核心变量和产业链逻辑。
2. 市场视图是否讲清价格、库存、供需、政策、资金显影和市场阶段。
3. 公司视图是否讲清公司业务结构、行业暴露、核心竞争力、投资读法、风险和失效条件。
4. 关键结论是否有来源、数据日期、历史比较、横向比较、公司或链条案例。
5. 专业术语是否用普通人能理解的方式解释。
6. 研报观点、事实、推理、暗线假设和投资读法是否分账。
7. 数据不足时是否降级为 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP`。
8. 输出前是否读取市场反向补漏结果；如果发现遗漏公司、子行业、资源品种、技术路线或关键变量，是否先进入补资料和缺口流程。
9. 成熟子行业、核心技术路线或核心公司是否具备基础事实卡；缺失基础事实时是否降级，不直接写强结论。
10. 人读文档是否按结构化记录和证据数据卡 -> 子行业详细材料 -> 子行业总览 -> 公司文档 -> 行业/市场总览和索引的顺序更新，最终入口是否仍是行业视图、市场视图、公司视图。
11. 重要场景假设是否写清影响映射、触发条件、失效条件和主要风险。
12. 对外交付版本是否能从 `ana-data/result/<行业案例>/<case_id>/result_index.md` 进入，并能反查到 `outputs/`、证据映射和 manifest。
13. 已达 3 轮补证上限的缺口是否在行业 `待补资料清单.md` 或等价清单中明确列示，并能从核心文档、缺口表或 result_index 反查；如果清单字段充分且结论已降级，不应要求继续围绕同一缺口补第 4 轮，除非符合补证轮次上限审核口径中的例外条件。

## 8. 研报案例高风险问题清单

审核员必须重点发现以下问题：

1. 没有创建行业容器目录，把行业案例过程明细写回父级 `ana-doc/`，或在行业目录内创建平行的 `案例总纲.md`。
2. 行业子规范和父级 `案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md` 冲突。
3. 行业子审核规范或行业子分析规范复制父级通用流程后形成第二套母版，导致执行 AI 不清楚以父级还是子级为准。
4. 行业方案缺失，或行业方案没有继承研报解析架构、研报分析架构和父级案例存储体系。
5. 行业方案仍是模板、没有行业边界、没有输出方案或没有专属表/缺口定义，却开始正式研报分析。
6. 设计审核未通过就开始正式研报分析。
7. 案例设计没有写清目标、边界、资料来源、证据要求、输出文档和验收方式。
8. 案例设计只写阶段名或最终目标，没有把 ana 控制点和研报专业动作融合成可执行步骤。
9. 审核请求引用的设计、执行日志、审计对象、结果包或证据入口在提交审核时未落地，后续补录后冒充审核前记录。
10. 把同一长期行业案例的资料批次误拆成多个正式案例，或把不同研究目标误塞进同一个案例。
11. 原始研报没有进入行业统一 raw 池 `ana-data/cases/<行业案例>/raw/`，按 case/batch 分散存放 raw，或 raw 原始文件被覆盖、改写。
12. 转换文本、表格、OCR、抽取结果、补充资料没有进入行业级统一目录，或输出文档没有进入案例级 `outputs/`。
13. 临时文件没有进入父体系 `ana-data/tmp/<行业案例>/<case_id>/<run_id>/`，被放入案例资料目录，或被当成正式证据、正式结果入口。
14. 结果入口或交付包索引没有进入父体系 `ana-data/result/<行业案例>/<case_id>/`；涉及图片时图片没有进入 `ana-data/img/<行业案例>/<case_id>` 或缺少图片 manifest。
15. 没有 manifest、来源清单、证据索引或等价可追踪记录。
16. MySQL 结构化记录不能反查到行业级原始资料、转换结果、抽取结果、证据，或案例级输出路径。
17. 只采信券商结论，没有拆出事实、数据、假设、观点和证据。
18. 核心指标没有数据卡，或缺少数据日期、来源、历史比较、横向比较和结论强度。
19. 重要结论没有公司、项目、链条、数据或案例支撑。
20. 用故事、机制解释或专家观点替代指标数据。
21. 缺少市场反向补漏，或只写“已补漏”但没有近 3 个月强显影股票清单、核心业务重归因、scope 闸门、缺口清单和补充资料记录。
22. 行业边界被关键词污染，把相邻行业、下游噪音或伪主题纳入核心结论。
23. 暗线、事件链和意图判断混入普通行业事实。
24. 需要网上补充、外部信息、新闻公告、事件链、市场显影或暗线分析时，没有使用 `darkline` 技能。
25. 批量处理没有 `unresolved_data_gap.csv`、`source_gap_audit.csv`、`batch_summary.md`、`next_action_list.csv` 或等价记录。
26. 资料之间存在支持、反对、重复观点或口径冲突，但输出里被合并成单一结论。
27. 输出文档只有标题式结论，没有证据、推理、失效条件和结论边界。
28. 行业视图、市场视图、公司视图缺失，或被细分文档替代。
29. 公司文档没有投资读法、风险、证据链或当前状态判断。
30. 基础事实卡缺失、核心变量无数据卡、场景假设无影响映射，却输出强结论或投资读法。
31. 结论超过证据，资料不足却没有标记 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP`。
32. 审计问题没有进入 `案例审计报告.md`，需跨轮或跨角色跟踪的问题没有进入 `案例问题记录.md`，或执行者自发现且可处理的问题被误写入 `案例问题记录.md`。
33. 行业方案、案例设计、核心输出、存储路径、证据链或结论边界发生重要变化，但没有提交复审。
34. 核心文档输出完成后，没有通过输出审核或执行审核就对外交付、进入正式结果入口或回写完成状态。
35. 抓取脚本、SQL、网页快照、市场反向补漏结果或查询 CSV 留在 `ana-data/tools/`、私人工作区或未登记路径，没有进入规范落点。
36. 使用脚本执行写库 SQL、泄露数据库密码/token/cookie，或把市场显影扫描结果直接写成投资结论。

## 9. 证据抽查方法

审核员不仅阅读结论，还要抽查证据链。

建议方法：

1. 从父级案例总纲追到行业目录案例设计、执行日志、审计报告和问题记录，确认链路完整。
2. 从输出文档反向追到案例级证据映射，再追到行业级 `evidence/`、`extracted/`、`converted/` 和 `raw/`。
3. 抽查 1-3 个强结论，确认来源、数据日期、横向比较、历史比较和公司案例是否存在。
4. 抽查 1-3 个公司或细分行业，确认公司映射、指标和投资读法没有过读。
5. 抽查 manifest 和文件路径，确认不是临时文件、私有工作区或旧项目路径。
6. 对涉及脚本或自动化输出的结果，检查输入范围、参数、输出路径和证据包是否与案例设计一致。
7. 对涉及市场显影或暗线的内容，检查是否使用 darkline，并与普通行业事实分离。
8. 对涉及 `ana-data/tools/` 的结果，抽查脚本 SQL 或参数、只读边界、row_count、hash、manifest 和输出文件是否能互相反查。

## 10. 审核结论

审核结论使用：

```text
通过
有条件通过
不通过
HELD
```

结论必须包含：

1. 审核 ID。
2. 审核类型：行业容器创建审核 / 行业方案审核 / 设计审核 / 执行审核 / 存储归档审核 / 输出审核 / 结论边界审核 / 复审。
3. 审核对象。
4. 审核依据。
5. 检查结果。
6. 问题清单。
7. 阻断项。
8. 需要修复的文档、结果包或路径。
9. 是否允许进入下一阶段。

`有条件通过` 只能用于不影响追溯、证据可信度和结论边界的轻微问题；凡影响证据链、存储归档、设计冻结、审核闭环或结论边界的问题，不得有条件通过。

## 11. 必须阻断的问题

以下问题必须阻断：

1. 设计目标和来源聊天不一致。
2. 设计审核未通过就执行正式案例。
3. 行业方案缺失且任务属于新行业研报案例。
4. 行业方案仍是模板或缺少行业边界、核心变量、输出方案、专属表/缺口定义，却进入正式分析。
5. 行业子规范违反父级规范或父级存储体系。
6. 原始资料未进入行业统一 raw 池，或无法确认来源、hash、路径。
7. 关键判断缺证据，导致无法复核。
8. manifest、证据索引或结果包缺失，导致链路断裂。
9. MySQL 或结构化记录无法反查原始资料、转换结果、证据和输出路径。
10. 使用未来信息支持实时判断、交易结论或收益结论。
11. 结论明显过读。
12. 暗线、事件链和普通行业事实混写并影响结论。
13. 需要外部信息、新闻公告、市场显影或暗线分析时未使用 `darkline`。
14. 批量研报分析缺少 `unresolved_data_gap.csv`、`source_gap_audit.csv`、核心 manifest 或证据索引，导致缺口、来源或批次无法复核。
15. 核心文档缺少行业视图、市场视图、公司视图，或基础事实卡、数据卡、证据链缺失导致强结论不可复核。

## 12. 不应阻断的问题

以下问题一般不阻断，但可以记录为修正建议：

1. 文档格式不够美观，但关键路径和证据可读。
2. 字段名不完全一致但映射关系清楚。
3. 非关键备注缺失。
4. 非关键案例的轻微说明不足。
5. 后续工程化尚未开始。
6. 输出文档仍需润色，但证据链、结论边界和审核入口完整。

## 13. 审计记录位置

| 情况 | 主记录位置 |
|---|---|
| 初始化审计 | `案例审计报告.md` |
| 新行业容器创建审核 | 行业目录 `案例审计报告.md`；父级 `案例总纲.md` 登记相关案例入口 |
| 行业方案审核 | 行业目录 `案例审计报告.md` |
| 设计审核 | 行业目录或父级对应 `案例审计报告.md` |
| 执行审核 | 行业目录或父级对应 `案例审计报告.md` |
| 存储归档审核 | 行业目录或父级对应 `案例审计报告.md` |
| 输出审核 | 行业目录或父级对应 `案例审计报告.md` |
| 结论边界审核 | 行业目录或父级对应 `案例审计报告.md` |
| 复审 | 原审核记录所在 `案例审计报告.md` |
| 审计发现问题 | `案例审计报告.md` 为主，`案例问题记录.md` 只做跨轮索引 |
| 外部反馈、执行者无法自行闭环或需跨轮/跨角色跟踪的非审计问题 | `案例问题记录.md` |

审核员不得直接改被审计主产物来掩盖问题。如需修改规范，应创建规范维护事项或取得案例体系维护授权，并记录原因、影响范围和复审入口。

## 14. 风险分级审核与反过度加码（2026-08-01）

审核必须服务于事实可信、证据可追溯和结论不过读，不以增加审计条目、精确路径、自动化断言或返修轮次为目标。

### 14.1 审核优先级

1. 第一优先：来源是否真实、关键事实是否由来源承载、对象和时间口径是否正确、结论是否过读。
2. 第二优先：输出是否让用户获得新的行业、公司、市场或证据内容。
3. 第三优先：存储、manifest 和流程是否达到可追溯、可恢复的最低要求。
4. 纯格式、共享 append-only 文件整体 mtime、可解释的尾部追加、内部命名、非关键计数摘要和不会改变结论的工具实现差异通常不阻断。

### 14.2 按风险审查

- `L0`：抽查维护记录即可，不产生独立审计条目。
- `L1`：按内容冲刺审核；对关键来源和结论做全查或抽查 1-3 个代表项，核对内容增量、来源定位、对象映射和降读边界。默认不要求逐文件代码依赖身份、真实 I/O fault 注入、共享文件 whole-file mtime 或重复 exact-set authority。
- `L2`：对证据升级、缺口关闭、正式池、强结论、数据库写入、删除覆盖和 canonical 切换执行完整门禁。

### 14.3 阻断标准

只有下列问题可以阻断 `L1` 内容冲刺：

1. 来源不存在、无法定位或与事实文本不符。
2. 主体、指标、日期、单位、口径或公司/专题映射错误。
3. 输出遗漏关键限制，导致结论明显过读。
4. 执行会覆盖不可恢复数据，且没有最低可用备份或恢复办法。
5. 实际输出范围超出已审核内容冲刺范围。

其他问题原则上作为 `INFO/FOLLOW_UP`。审核员必须说明每个 blocker 属于“事实可信、证据追溯、结论边界、不可恢复写入”中的哪一类；不能归类的，不得作为 blocker。

### 14.4 一次给全与聚焦复审

1. 首轮审核应在当前可见证据范围内一次性列全阻断，不得每次返修只新增一个原本已可发现的机械问题。
2. 聚焦复审只检查前次 blocker 是否关闭；除新改动直接引入高风险问题外，不重开已通过集合、语义和边界。
3. shared append-only 文档以条目级身份或已冻结前缀判断，不因审核员追加审计造成 whole-file mtime/hash 变化而触发新 repair。
4. validator 出现 false-positive/false-negative 时，应先人工复核内容结果；若内容正确且无不可恢复风险，工具缺陷进入维护待办，不得自动否定内容产出。
5. 同一内容冲刺默认最多一次设计返修。需要第二次以上时，审核员必须说明新增 blocker 为什么首轮不可发现、为什么会影响事实或安全，以及是否可降为非阻断维护项。