# 案例分析规范

创建人员：management.admin
文件职责：记录 `project-info` 项目案例分析员必须遵守的本地规范，承接研报研究、外部信息分析、证据链沉淀和核心文档输出。
管理规范/模板：../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例分析环境创建指南.md。
引用文件：目录导读.md；行业与产业链研究模板.md；产业链地图通用模板与研究方法.md；数据抓取脚本说明.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审核规范.md；案例存储体系.md；案例审计报告.md；案例问题记录.md；研报体系/研报解析架构.md；研报体系/研报分析架构.md；../项目配置清单.md。
记录方式：项目本地规范；本项目案例分析口径发生变化时更新，并同步项目变更记录。

## 1. 基本口径

本项目所有案例分析员必须同时遵守 `../../common/ana-doc/案例分析规范.md` 和本文件。本文件只做 `project-info` 的项目化补充；如果与 common 硬约束冲突，以 common 硬约束为准，并先修复本文件。

`project-info` 的案例分析体系用于承接研报研究、行业资料分析、公开信息补充、市场显影检查、暗线分流、证据归档、核心文档输出和审核闭环。它不是单纯的摘要目录，也不是交易指令系统。

## 2. 项目分析范围

本项目案例分析范围包括：

1. 研报、公告、新闻、网页、政策、数据表、公开网络信息形成的信息链和证据链。
2. 行业、子行业、产业链、公司、市场指标、投资读法和资料缺口分析。
3. K 线、成交量、市场广度、行业表现等市场显影证据。
4. 暗线 / 信息拓扑分析中的意图、目标、证据链、替代解释和市场输出。
5. 后续可交给实验体系或开发体系验证的假设、样本和工具需求。

本项目案例分析不得直接输出交易指令、收益承诺或未经证据支持的强因果结论。涉及投资读法时，只能输出证据边界内的阶段判断、观察条件、触发条件、失效条件和风险。

## 3. 核心文档作用

| 文档 | 作用 |
|---|---|
| `目录导读.md` | 本项目案例体系入口、目录和数据路径说明 |
| `案例分析规范.md` | 本项目案例分析本地规范入口 |
| `案例审核规范.md` | 本项目案例审核本地规范入口 |
| `案例存储体系.md` | 案例文件、证据、结果包、MySQL 追溯和研报存储规则 |
| `案例总纲.md` | 父级案例事项背景、目标、边界、状态和结论账本 |
| `案例分析设计.md` | 父级案例选择口径、证据要求、流程和验收方式 |
| `案例执行日志.md` | 父级案例执行过程、关键节点、数据和证据路径 |
| `案例审计报告.md` | 父级设计审核、执行审核、初始化审核和复审结论 |
| `案例问题记录.md` | 外部反馈、执行者无法自行闭环或需跨轮/跨角色跟踪的非审计问题；审计问题主记录留在审计报告 |
| `行业与产业链研究模板.md` | 长期行业研究的公共内容与稳定目录母版，覆盖行业、产业链、子行业、公司、证据和最终地图的完整研究骨架 |
| `产业链地图通用模板与研究方法.md` | 完整行业研究完成后的产业链地图可视化子模板，不替代行业与企业基础正文 |
| `数据抓取脚本说明.md` | 说明 `ana-data/tools/` 中外部网页抓取、本地 MySQL 只读导出和市场反向补漏脚本的使用口径 |
| `研报体系/研报解析架构.md` | 研报解析方法母版，定义行业方案继承、输出视图和解析底线 |
| `研报体系/研报分析架构.md` | 研报分析方法母版，定义资料归档、抽取、补数、市场反向补漏、暗线分流和人读文档闭环 |

`研报解析架构.md` 和 `研报分析架构.md` 是研报专业流程母版，本文件负责把两者的核心流程融合进 ana 案例生命周期，形成本项目研报案例的统一执行入口。行业子规范、总纲、设计、日志或审计报告不得把两份母版全文拆散复制成平行流程。研报存储规则已经融入 `案例存储体系.md`，不另建平行的 `研报存储体系.md` 作为正式执行入口。

母版和行业方案的边界必须严格区分：

1. `研报体系/研报解析架构.md` 是所有研报解析文档的指导思想和方法母版，默认不作为具体行业输出结构、文件清单或执行细节的日常修改位置。
2. 具体行业怎么设计输出文档架构、哪些子行业要拆、公司文档怎么排、数据表和暗线入口怎么落地，必须以该行业本地 `<行业>研报解析方案.md` 为准。
3. 行业方案是具体实施的指导性文档；行业案例设计、执行日志、结果入口和输出文档必须优先引用行业方案中的实施口径，再说明其如何继承母版。
4. 后续如用户要求调整某个行业的输出结构、文件名、目录、子行业拆分、公司范围、数据表或执行策略，分析员应先修改该行业本地方案并提交方案复审；不得直接修改 `研报解析架构.md`。
5. 只有当规则需要长期适用于所有行业，且经用户或管理链路明确要求升级为跨行业母版规则时，才允许提出修改 `研报解析架构.md` 的维护事项；修改前必须单独说明影响范围并提交母版级复审。

## 4. 最小案例链路

每个正式案例至少具备：

1. 案例 ID、来源、行业或对象、目标、边界和状态。
2. `案例总纲.md` 登记事项来源、目标、范围、预期输出和当前状态。
3. `案例分析设计.md` 冻结案例选择口径、输入资料、执行步骤、证据要求、输出物、存储路径和验收方式。
4. 设计审核记录。设计审核未通过，不得进入正式执行。
5. `案例执行日志.md` 记录实际读取、归档、转换、抽取、补充、分析、输出和自检过程。
6. 结果包、证据包或明确的 `HELD` 状态；不能用口头结论替代证据入口。
7. 执行审核记录。执行审核未通过，不得标记完成或对外交付。
8. 审核问题进入 `案例审计报告.md`；执行者自发现且能处理的问题进入 `案例执行日志.md`、自检、验证报告或结果包；外部反馈、执行者无法自行闭环或跨轮索引进入 `案例问题记录.md`。

## 5. 研报体系接入流程

研报类任务进入案例体系后，流程以 ana 案例生命周期为主线，研报解析和分析流程作为专业步骤嵌入其中。本节是 `研报解析架构.md` 和 `研报分析架构.md` 的流程融合结果；执行 AI 以本节为默认主流程，除非行业方案通过设计审核明确覆写专业步骤。

融合不是简单引用两份研报母版。执行时必须把 common ana 的“来源、总纲、设计、审核、执行、日志、结果包、执行审核、复审、回写”逐步落到研报专业动作上，形成从行业方案、raw 归档、转换抽取、补数、证据、三类视图、manifest 到审计闭环的完整链路。

案例分析员融合执行流程：

分析员接到研报任务后，必须按 common 案例流程的顺序执行，只是把每个 common 步骤中的“候选、案例、关键数据、图片、结果”替换为研报体系中的“资料批次、行业方案、原始资料、转换抽取、补数证据、三类视图和 manifest”。流程如下：

1. 来源接入：对应 common 的“来源聊天记录 / 上游方法论 / 样本来源”。分析员先判断任务是否是研报类 case_analysis，记录任务来源、用户要求、行业范围、资料来源、目标和边界；如果任务需要网上补充、新闻公告、市场显影或暗线分析，在设计里标记 `darkline_required` 或等价说明。
2. 父级总纲登记：对应 common 的“案例总纲记录背景、目标、边界、当前结论”。真实研报案例必须先登记到父级 `案例总纲.md`，行业目录只作为容器和过程账本，不创建平行总纲；同一行业长期研究一般是一个长期案例，分批资料输入用 `batch_id` 和 `run_id` 表达。
3. 行业容器和母版读取：这是 common “执行前确认案例环境”的研报化步骤。分析员确认 `ana-doc/<行业>案例/` 是否存在；不存在则先创建行业容器。随后读取父级 `案例分析规范.md`、`案例存储体系.md`、`案例审核规范.md`、`研报解析架构.md`、`研报分析架构.md` 和行业方案。
4. 行业方案创建或更新：这是研报体系嵌入 common 设计流程前的专业前置步骤。新行业不得直接读研报，必须先创建 `<行业>研报解析方案.md`；已有行业也要检查方案是否足以支撑本次任务，必要时先更新行业边界、核心变量、输出方案、专属表、流程覆写和缺口。行业方案新建、从模板升格或重要优化后，必须提交行业方案审核或复审。
5. 案例分析设计冻结：对应 common 的“案例分析设计记录案例选择口径、分析步骤、证据要求、验收方式”。研报任务中的设计必须写清 `case_id/batch_id/run_id`、资料批次选择口径、是否属于同一长期案例、raw/converted/extracted/supplement/evidence/outputs/manifest/tmp/result/img 落点、三类视图输出、MySQL 或结构化记录、证据要求、缺口处理和 PASS/FAIL/HELD。
6. 设计审核：对应 common 的“设计审核”。行业方案和案例设计未通过审核前，分析员不得进入正式研报读取、归档、转换、抽取或输出结论；只能做容器初始化、资料盘点或明确标注的 dry-run。
7. 正式执行案例分析：对应 common 的“执行案例分析”。研报任务中的执行动作按已审核设计进行，顺序是：归档 raw 原始资料 -> 文件头识别和 hash -> 转换到 converted -> 分类到行业/子行业/公司/链条节点 -> 抽取事实、观点、指标候选、公司映射和缺口到 extracted/evidence -> 主动补公开资料和市场反向补漏到 supplement -> 必要时 darkline 分流 -> 建立证据数据卡和结论证据映射 -> 输出行业视图、市场视图、公司视图和必要扩展文档。
8. 执行日志留痕：对应 common 的“案例执行日志记录候选、过程、关键数据、图片、结果”。研报任务中必须记录资料样本选择、batch/run、工具和参数、转换状态、抽取结果、补数来源、数据缺口、证据索引、输出路径、自检结果、偏离设计和处理方式；不能只写最终 summary。
9. 结果包和证据包归档：对应 common 的“结果包 / 证据包归档”。行业级通用产物进入 `ana-data/cases/<行业案例>/raw|converted|extracted|supplement|evidence|manifest/`；案例级输出、引用清单和案例证据映射进入 `ana-data/cases/<行业案例>/<case_id>/outputs|manifest|evidence/`；临时文件、结果入口和图片分别进入父体系 `tmp/result/img`。
10. 执行审核：对应 common 的“执行审核”。分析员提交执行审核前必须完成自检，确认来源、hash、manifest、证据链、三类视图、结果入口、缺口状态和结论边界可复核。执行审核未通过，不得标记完成或对外交付。
11. 审计问题和问题记录分账：对应 common 的“审计报告记录审计问题 / 问题记录只承接需跨轮或跨角色闭环的问题”。审核员发现的问题主记录进 `案例审计报告.md`；分析员自发现且能处理的问题写入执行日志、自检、验证报告、manifest、缺口表或结果包；外部反馈、跨角色或跨轮闭环问题才进 `案例问题记录.md`。
12. 修复、复审和回写：对应 common 的“修复 / 复审 -> 结论回写到案例总纲和案例设计”。分析员按审计意见修复行业方案、设计、存储路径、manifest、证据链、输出文档或结论边界；复审通过后回写父级总纲状态、行业设计执行结果、行业方案维护记录、结果入口和未关闭缺口。

上面 12 步是分析员必须执行的主流程。下面是这个主流程拆开的具体工作流和配套规范，分析员按任务类型选择对应流程执行，不需要再自行拼接 common 流程和研报流程。

### 5.0A 来源聊天记录轻量入口

案例分析事项必须能追溯用户原始要求，但不得把该要求扩展成繁重的重复归档流程。

最低要求：

1. 每个案例事项、行业方案重要变更、设计审核、执行审核、输出审核或复审送审时，必须提供“来源聊天记录入口”或等价来源入口。
2. 来源入口可以是 MB-X `message_id`、会话 marker、原始聊天导出文件路径、管理系统消息记录路径，或能让审核员反查原始用户要求的其他稳定入口。
3. 送审正文中必须列明：来源入口、覆盖消息范围或时间范围、用户原始要求摘要、本次变更和原始要求的对应关系。
4. 不要求在送审消息里全文粘贴原始聊天记录；长聊天应保留在正式来源文件、消息链或可复核入口中，送审消息只写摘要和路径。
5. 对同一长期案例的连续小修、复审或执行轮次，可以复用同一个来源聊天记录入口，只需补充本轮新增用户要求或新增消息范围。
6. 只有当原始聊天缺失、来源入口不可打开、用户要求发生实质变化或审核员无法判断目标来源时，才需要补建来源记录或退回修复。
7. 不得因为该规则要求为每次格式小修、错别字修复或纯链接显示修复新建完整聊天证据包；此类小修可在执行日志中引用已有来源入口。

### 5.1 新行业首次接入流程

适用场景：第一次接到某个行业的研报任务，或者行业目录和行业方案还不存在。

1. 在父级 `案例总纲.md` 登记行业任务来源、目标、边界、初始状态和预期输出。
2. 创建或确认 `ana-doc/<行业>案例/`，不得在行业目录内创建 `案例总纲.md`。
3. 创建行业容器基础文档：`目录导读.md`、`案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md`、`案例分析设计.md`、`案例执行日志.md`、`案例审计报告.md`、`案例问题记录.md`。
4. 创建 `<行业>研报解析方案.md`，先写清行业边界、核心变量、输出方案、专属表、存储落点、缺口清单和是否覆写流程。
5. 在行业 `案例审计报告.md` 留下目录、继承关系和行业方案审核入口。
6. 提交新行业容器创建审核和行业方案审核；审核通过前，只能做容器初始化、资料清点或 dry-run。
7. 在父级 `目录导读.md` 登记新行业目录。
8. 在行业 `案例分析设计.md` 写入容器初始化设计和验收标准。
9. 在行业 `案例执行日志.md` 记录创建动作。
10. 行业方案仍是模板、未审核或审核未通过时，不得进入正式研报读取、归档、转换、抽取、分析或结论输出。

### 5.2 研报分析流程

适用场景：行业容器和行业方案已存在，分析员接到一批研报、公告、网页、数据表或外部资料。

1. 在父级 `案例总纲.md` 确认真实案例已经登记；如果是同一长期研究目标的新资料输入，沿用同一个 `case_id`，用新的 `batch_id` 和 `run_id` 区分。
2. 读取行业方案，确认本次资料属于该行业边界；不属于边界的资料进入排除说明或相邻行业 review，不得混入核心结论。
3. 如果本次需要更新行业方案，先在 `<行业>研报解析方案.md` 写清变更原因、影响范围和维护记录，并提交行业方案复审；复审通过前，不得把新方案作为正式分析依据。
4. 如果本次只是调整本行业输出文档架构、文件清单、子行业拆分、公司文档范围、数据表入口或执行策略，默认只修改本行业 `<行业>研报解析方案.md` 和必要的案例设计，不修改 `研报体系/研报解析架构.md`。
5. 在行业 `案例分析设计.md` 冻结本次资料来源、样本范围、case/batch/run、执行步骤、证据要求、输出物、存储路径、darkline 触发边界和验收方式。
6. 设计审核未通过前，不得正式归档、转换、抽取或输出结论；需要先盘点资料时，必须标记为 dry-run。
7. 按已审核设计执行研报分析：先归档和转换资料，再抽取事实、观点、指标、公司映射、产业链节点和资料缺口。
8. 对关键指标、公司映射、产业链环节、供需价格库存成本等变量建立证据数据卡；缺少核心数据时进入缺口状态，不得直接写强结论。
9. 单篇研报不能只做摘要，必须记录 doc_id、页码或段落定位、句子/表格索引、时间、单位、口径、对象归属、事实句、指标句、观点句、公司映射、风险句和置信度。
10. 批量研报不能压成一个大摘要，必须按 batch 输出或更新 `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. 需要公开资料补充、公告补证、市场反向补漏、新闻事件或暗线判断时，使用 `darkline` 或对应外部信息方法，并把补充来源、时间和置信度写入证据链；主动补数据按 5.4 执行，市场反向补漏按 5.5 执行，不能只写“已补漏”。
13. 根据证据链形成行业视图、市场视图、公司视图和必要扩展文档；核心文档输出按 5.6 执行。
14. 生成或更新行业级 manifest、案例级引用 manifest、验证报告和父体系 `result_index.md`。
15. 在行业 `案例执行日志.md` 记录全过程、偏离、异常、自检和本轮结论边界。
16. 提交执行审核；审核未通过前，不得对外交付或把案例标记完成。

### 5.3 研报资料归档和处理流程

适用场景：研报、公告、网页、数据表、图片、OCR 或外部资料进入项目，需要形成可复核证据链。

1. 原始研报、公告、网页快照和外部资料原件统一归档到 `ana-data/cases/<行业案例>/raw/`；raw 是行业统一池，不按 `case_id`、`batch_id` 或 `run_id` 拆分目录。
2. raw 归档必须记录来源、取得时间、文件头识别、hash、原始文件名、规范化文件名、case_id、batch_id 和 run_id；重复文件不得覆盖，必须以 hash 或 manifest 说明关系。
3. PDF、Office、网页、表格、图片或 OCR 资料转换到行业级 `converted/`，记录转换工具、参数、状态、异常和 raw 反查入口。
4. 事实、观点、指标候选、公司映射、产业链节点、资料缺口和初步分类写入行业级 `extracted/` 或等价结构化记录。
5. 公开资料补充、公告补证、市场反向补漏、新闻事件和暗线相关补充写入行业级 `supplement/`；凡需要网上补充消息或分析外部问题，必须使用 `darkline` 方法。
6. 通用证据事实、来源定位、数据卡底座和 raw-to-converted trace 写入行业级 `evidence/`；案例结论证据映射写入案例级 `evidence/`。
7. 正式人读输出、案例级引用清单和案例级 manifest 写入 `ana-data/cases/<行业案例>/<case_id>/outputs|manifest|evidence/`。
8. 临时文件进入 `ana-data/tmp/<行业案例>/<case_id>/<run_id>/`，结果入口或交付包索引进入 `ana-data/result/<行业案例>/<case_id>/`，图片、截图、OCR 图片或图册进入 `ana-data/img/<行业案例>/<case_id>/`。
9. MySQL 或其他结构化记录必须能反查到 case_id、batch_id、run_id、raw、converted、evidence 和输出路径。
10. 任何转换失败、OCR 失败、资料缺页、来源不明或证据不足，都必须记录状态和下一步处理，不得静默删除或跳过。

### 5.4 主动补数据和缺口审计流程

适用场景：研报、公告、网页、行情或外部资料已经产生初步抽取，但关键事实、指标、公司映射、投资读法或资料链路不足以支撑结论。

1. 出现以下情况必须主动补资料：关键数据缺失；研报只有结论没有支撑数据；提到关键资产、产能、订单、库存、价格、政策、客户认证但没有来源；提到受益公司但缺业务占比、利润弹性或资源/技术/渠道暴露；提到政策、出口管制、地缘风险但缺现实证据；提到技术壁垒、材料性能、客户认证、资产注入或整合但缺验证路径；投资读法需要判断当前股价或市场是否已经反映预期。
2. 补资料前先把问题写入 `unresolved_data_gap.csv` 或等价结构化记录，至少记录缺什么、为什么缺、影响哪条结论、优先级、补资料问题、状态和责任 run。
3. 需要联网、新闻公告、外部资料、事件链、证据链、市场显影或暗线判断时，必须使用 `darkline`；稳定事实优先补官方公告、交易所公告、政府数据、行业协会、交易所库存、海关统计、公司官网、投资者关系和可信公开资料。
4. 补充资料必须归档到 `raw/` 或 `supplement/`，写入 `source_document`、manifest 或等价数据库记录，并抽取到 `evidence_fact`、指标、观点或公司映射。
5. 补资料后必须回写原研报 readout、数据缺口、证据数据卡和结论强度；补不到的保持 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP`，不得用故事或券商观点替代数据。
6. 每批资料必须生成 `source_gap_audit.csv` 或等价记录，用来检查资料是否存在“已给但没读、读了但没归档、归档了但没索引、索引了但没进入证据链”的断点。
7. 主动补数据和 source gap audit 是进入核心文档输出前的检查点；没有完成或没有明确豁免时，不得把人读文档写成覆盖完整。

补资料轮次上限：

1. 同一案例、同一类证据缺口或同一组相关缺口，主动补资料最多执行 3 轮；每轮必须有独立 `run_id`、输入范围、补充来源、结果、失败项和 review_status 记录。
2. 3 轮仍无法补齐时，不再继续围绕同一缺口无限补证；必须把剩余缺口写入缺口表、证据卡、result_index 或核心文档证据边界，状态使用 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`HELD_BY_ENV`、`HELD_BY_ACCESS`、`HELD_BY_EVIDENCE_GAP` 或等价降级状态，然后继续推进核心文档和下一阶段工作。
3. 超过 3 轮仍缺的资料，必须统一登记到行业案例文件夹下的专门文档 `ana-doc/<行业案例>/待补资料清单.md` 或等价行业级待补资料清单；该文档至少记录缺口组、已补轮次、缺什么、为什么影响结论、当前降级状态、用户或人工后续需要提供什么、关联 case/batch/run、证据入口和最后更新时间。
4. 写入行业待补资料清单后，分析员应继续执行下一阶段工作；后续只有当用户、人工同事或审核链路明确索取“需要补的数据/资料”时，才从该清单提取并反馈所需资料，不得因为清单中仍有未补项而自动卡住主流程。
5. 第 4 轮及以后只能在以下情况下启动：用户补充了新资料或新权限；外部环境已恢复且可一次性解决阻断；审核员指出前三轮存在遗漏或执行错误；该缺口是唯一会导致核心文档完全不可读的阻断项。启动第 4 轮必须在设计或执行日志写明例外原因，并提交复审或后续执行审核。
6. 如果缺口数量少、集中在少量 PDF/网页归档/访问受限项，且不影响主线行业视图、市场视图或公司视图的 DRAFT 输出，应按缺口登记和降级口径继续推进，不得把流程卡在转换、抓取或补证循环。
7. 如果缺口规模大到影响核心覆盖，例如失败项超过本轮关键输入的 10%、集中影响核心品种/核心公司/核心指标，或导致三类核心文档无法形成最低可读草稿，分析员必须向用户和审核链路说明影响范围、需要补充的资料或环境，并输出有限范围结果，而不是静默继续补证。
8. 超过补证上限后的核心文档不得写成覆盖完整、证据充分或正式结论；必须明确“已补证 3 轮仍保留缺口”的范围、原因、替代解释、行业待补资料清单入口和后续补证入口。

### 5.4A 数据抓取脚本使用流程

适用场景：案例分析员需要抓取外部网页、保存公开资料快照、从本地 MySQL 导出行情/公司画像/市场广度，或执行市场反向补漏初筛。

1. 使用前先读取 `数据抓取脚本说明.md`，确认脚本用途、输入参数、输出落点和禁止事项。
2. 使用脚本必须在行业 `案例分析设计.md` 中提前声明；如果执行中临时发现必须使用脚本，应先在执行日志记录偏离原因、影响范围和补救动作，并提交后续复审。
3. 外部网页、新闻公告、事件链、市场显影或暗线相关抓取，必须同时使用 `darkline` 技能和信息拓扑方法；脚本只负责抓取和归档，不替代 darkline 分析。
4. 本地 MySQL 导出必须只读，优先使用 `ana-data/tools/export_mysql_query.py` 或行业已审核的等价脚本；不得把数据库密码、token、cookie 或私有凭据写入命令、SQL、manifest 或文档。
5. 市场反向补漏优先使用 `ana-data/tools/market_gap_scan_mysql.py` 从本地 `a_share_profile_snapshot` 和 `a_share_daily_price` 初筛，再按行业方案做核心业务重归因和 scope 闸门。
6. 脚本输出必须进入行业 `supplement/`、`evidence/`、`manifest/` 或父体系 `tmp/result/img`；不得留在 `ana-data/tools/`，也不得散落到私人工作区。
7. 执行日志必须记录脚本名、执行时间、case/batch/run、参数摘要、输出路径、manifest 路径、异常和自检结论；参数摘要不得包含密码。
8. 脚本结果进入人读结论前，必须完成证据抽取、数据卡、来源时间戳、置信度和结论边界标记；抓取成功不等于证据成立。

### 5.5 市场反向补漏流程

适用场景：每批研报处理后、准备输出或更新行业视图/市场视图/公司视图前，或者任务需要判断行业覆盖完整性、公司覆盖完整性、市场显影、异动股票解释时。

1. 在行业 `案例分析设计.md` 声明本轮是否执行市场反向补漏；如果本轮只是容器初始化、纯转换、纯归档或明确不输出覆盖结论，可以写明不执行原因。
2. 需要拉取行情、涨停、连续大涨、放量突破、逆行业上涨、相对强弱或资金持续显影数据时，必须使用 `darkline` 技能和对应外部信息方法，并记录数据来源、取得时间和口径。
3. 默认扫描目标行业、主题或行业方案定义股票池的近 3 个月强显影股票清单；行业方案可以定义更适合该行业的窗口，但不能无记录跳过。
4. 强显影至少检查：涨停或多次涨停、连续大涨、放量突破、逆行业上涨、明显强于同行、资金持续显影。
5. 对每个强显影公司按核心业务重新归因，不能只按宽关键词、题材标签或研报覆盖标签归类。
6. 每个对象必须过 `scope_type` 范围闸门：`CORE_INDUSTRY` 可进入核心补档队列；`ADJACENT_DOWNSTREAM` 进入相邻行业 review；`FALSE_THEME_OR_NOISE` 只保留审计记录，不得污染行业核心图谱。
7. 对通过范围闸门的对象判断缺口类型：缺失子行业、缺失公司、缺失技术路线、缺失资源品种、缺失关键变量、缺失公司映射或题材噪声。
8. 对 `CORE_INDUSTRY` 缺口写入补资料清单，补公告、年报、公司官网、交易所信息、行业公开资料和必要研报；补完后更新子行业清单、公司候选清单、核心变量、人读文档覆盖范围和证据链。
9. 对 `ADJACENT_DOWNSTREAM` 只做相邻行业 review，不得直接并入当前行业核心结论；如确实影响当前行业，必须在行业方案或设计中说明边界变化并复审。
10. 对 `FALSE_THEME_OR_NOISE` 只写排除原因和审计记录，不得因为股价强势就写入行业核心公司清单。
11. 最低输出或等价记录包括：`market_manifestation_gap_audit.csv`、`market_manifestation_gap_priority.csv`、`market_manifestation_gap_summary.json` 或结构化表 `industry_analysis_market_manifestation_gap_audit`。
12. 最低字段包括：`scan_id`、`industry_id`、`symbol`、`company_name`、`manifestation_date`、`manifestation_type`、`core_business_readout`、`scope_type`、`suspected_missing_track`、`gap_type`、`supplement_required_flag`、`supplement_question`、`review_status`。
13. 市场反向补漏只用于发现资料缺口，不直接构成投资结论；补漏未完成前，不得把行业文档写成“主要公司已覆盖完整”或“主要赛道已覆盖完整”。

### 5.6 核心文档输出流程

适用场景：资料和证据已经达到人读文档输入条件，需要输出或更新核心文档。

1. 先检查证据是否足够支撑人读输出；只有 raw、converted 或 evidence extracted，不等于可以输出强结论。
2. 输出前必须读取归档资料、结构化数据、未解决数据缺口、source_gap_audit 和市场反向补漏结果；市场反向补漏未执行时，必须说明适用性判断和设计依据。
3. 长期行业研究按 `行业与产业链研究模板.md` 组织“行业—终端场景—主产业链—子产业链—内部环节—企业—证据—地图”完整正文树；行业视图、市场视图、公司视图仍是上层入口，细分行业、指标卡、公司深读、投资读法、暗线和地图是各有职责的下层或汇总产物，不能互相替代。
4. 所有输出给用户、审核员或结果入口使用的人读文档，正文和文件名都必须使用中文表达；包括行业视图、市场视图、公司视图、用户可读稿、result_index、summary、readout、validation_report、待补资料清单和对外交付草稿。英文只允许作为代码、字段名、文件路径、命令、指标缩写、证券代码、公司/机构英文名、原文短引或不可翻译术语保留。
5. 新建或重命名人读输出文件时，文件名必须优先使用中文，例如 `有色行业视图草稿.md`、`有色市场视图草稿.md`、`有色用户可读收口稿.md`。不得再新增以英文短语为主的人读文件名。
6. 以下机器可读或兼容性文件名可以保留英文或英文缩写：脚本、代码、数据库表、CSV 字段清单、manifest、schema、hash 清单、工具输出、第三方原始文件名、历史已引用路径，以及为保持自动化兼容必须固定的文件名；但对应的人读索引或说明必须提供中文标题和中文解释。
7. 如果原始资料是英文或中英混排，输出文档必须给中文解释和中文结论边界，不能把英文原文、英文表头或英文摘要直接作为主要阅读内容；必要英文引用必须配中文释义。
8. 写作和更新顺序从底层到总览：先更新结构化记录和证据数据卡，再更新子行业详细材料，再更新子行业总览，再更新公司文档，最后更新行业总览、市场总览和索引；最终交付仍以行业视图、市场视图、公司视图为上层入口。
9. 成熟子行业、核心技术路线或核心公司在写强结论前必须有基础事实卡；事实卡应包含行业等价的市场规模、产销/供需、价格或收入/利润口径、库存或交付节奏、核心国家/区域/客户/公司、产业链位置和 A 股映射。某项不适用时写明不适用原因，不能静默省略。
10. 每个重要结论必须包含来源、数据日期、历史比较、横向比较、结构占比或公司/链条案例、结论强度和失效条件。
11. 关键变量和产业链流程必须用普通人能理解的中文解释，不能只给术语表、箭头图、英文缩写或标题式结论。
12. 核心正文必须采用“结论先行、逐步解释”的写法。每个重要章节先用一句话说清楚结论或观察状态，再按 1、2、3、4 的顺序解释前因后果；不得把中间推理跳过去，让读者从 1 跳到 4 或 7。
13. 每个结论后的证据展开必须回答四个问题：数据或案例是什么；它证明了什么；为什么这些数据能证明该结论；对行业、市场、产业链或公司研究有什么含义。若只能支持研究优先级、观察池或 DRAFT 读法，必须直接写清楚，不能使用“第一主线”“重点方向”等模糊词让读者误解为投资排序或交易建议。
14. 核心文档写完或每轮实质返修后，必须逐篇对照 `研报体系/研报解析架构.md` 的“核心理念”做复查。复查只看是否符合母版理念，不要求新增复杂产物；不符合的段落应在本轮直接修改或标记为降级/待补。
15. 对照“核心理念”时至少检查六点：普通人能不能看懂；关键结论和关键流程是否适当展开；是否有数据和案例；前因后果是否讲清楚；多因素影响时是否做横向对比；整体市场、行业关键数据是否既有数据也有解释。
16. 重要场景假设必须写影响映射：事件发生后影响哪些子行业、公司、价格、利润、订单、估值或情绪，并说明触发条件、失效条件和主要风险。
17. 数据不足时必须降级为 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP`，不得用券商观点或故事替代数据。
18. 公司文档必须先给投资读法和当前状态，再展开业务结构、行业暴露、核心竞争力、证据链和风险。
19. 市场反向补漏发现遗漏公司、子行业、资源品种、技术路线或关键变量时，先进入补资料和缺口流程；补完前不得写“覆盖完整”。
20. 暗线、事件链、意图判断和市场显影假设必须单独分账，不能混入普通行业事实文档。
21. 输出完成后，必须生成人读文档验收记录或等价验证说明，并能反查到证据、manifest 和原始资料；验收记录应说明是否已完成“核心理念”对照复查，或哪些段落仍需降级/待补。
22. 核心文档完成后，必须提交输出审核或执行审核；审核通过前，不得对外交付，也不得把输出状态写成已完成。

补证轮次达到上限后的输出口径：

1. 核心文档可以继续输出或迭代 `DRAFT_FOR_REVIEW`，但必须在证据边界、缺口表或 result_index 中列明已补证轮次、仍缺内容和降级状态。
2. 公司视图、市场视图和行业视图可以给“当前可读框架、证据已覆盖部分、缺口影响和后续补证入口”，不得给正式行业结论、正式公司结论或交易建议。
3. 达到补证上限的缺口必须在行业 `待补资料清单.md` 或等价清单中有可追踪记录；核心文档和 result_index 引用该清单入口即可，不需要把全部待补明细重复写入正文。
4. 审核员如确认补证已达 3 轮且缺口已正确分账，应优先审核降级边界、行业待补资料清单和继续推进条件，而不是要求围绕同一缺口继续无限返工。

### 5.7 审核后修复和回写流程

适用场景：设计审核、执行审核、复审或自检发现问题。

1. 审核员发现的问题主记录写入行业 `案例审计报告.md`；分析员不要把审计问题转写成问题记录来规避修复。
2. 分析员自发现且本轮可处理的问题，写入执行日志、自检、验证报告、manifest、数据缺口表或结果包，并直接处理。
3. 外部反馈、跨角色、跨轮或分析员无法自行闭环的问题，才写入行业 `案例问题记录.md`。
4. 修复动作必须说明影响范围：行业方案、案例设计、执行日志、manifest、证据链、输出文档、存储路径或父级总纲。
5. 如果修复改变流程、行业边界、核心变量、专属表或输出方案，必须回写 `<行业>研报解析方案.md`。
6. 如果修复改变案例目标、状态、结论入口或完成状态，必须回写父级 `案例总纲.md`。
7. 如果修复改变执行步骤、输入范围、证据要求或验收方式，必须回写行业 `案例分析设计.md` 并进入复审。
8. 复审通过前，不得标记完成或对外交付。

### 5.8 审计触发规则

本项目口径是：方案类文件先审，设计先审，正式执行后审；任何影响行业边界、流程、证据、存储、输出或结论边界的变更必须复审。分析员遇到以下事项必须提交审核或复审：

1. 新行业容器创建完成后，提交目录、继承关系和基础文档审核。
2. `<行业>研报解析方案.md` 新建、从模板升格、重要优化，或变更行业边界、核心变量、输出方案、专属表、流程覆写、存储落点、缺口清单时，提交行业方案审核或复审。
3. `案例分析设计.md` 新建，或变更资料范围、case/batch/run、执行步骤、证据要求、输出物、存储路径、darkline 触发边界或验收方式时，提交设计审核或复审。
4. 正式资料归档、转换、抽取、补数、证据组织、核心文档输出或 manifest 归档完成后，提交执行审核。
5. 核心文档准备对外交付、进入正式结果入口或回写完成状态前，必须通过输出审核或执行审核。
6. 审计修复导致行业方案、案例设计、存储路径、证据链、输出文档、父级总纲或结论边界变化时，提交复审。
7. 仅修改错别字、格式、链接显示等不影响流程、证据、存储、输出和结论边界的小修，可以记录在执行日志或维护记录中，不单独触发审核；审核员要求复审时除外。
8. 管理端自检不能替代正式审核员审核。分析员可以先自检，但不能用自检结论冒充审核结论。

### 5.9 过程状态口径

1. `RAW_REGISTERED` / `RAW_ARCHIVED` 只表示原始资料已登记或归档，不表示已经分析。
2. `TEXT_CONVERTED` 只表示资料完成转换，不表示已经抽取事实或指标。
3. `CLASSIFIED` / `EVIDENCE_EXTRACTED` 只表示完成分类或证据抽取，不表示可以写强结论。
4. `METRIC_NORMALIZED` 只表示指标标准化，不表示投资读法成立。
5. `SUPPLEMENT_REQUIRED` 表示必须补资料；补资料完成前不得把缺口写成结论。
6. `HUMAN_DOC_INPUT_READY` 只表示可以进入人读文档输出，不等于人读文档完成。
7. `HUMAN_DOC_READY` 只表示人读文档完成，不等于执行审核通过。
8. `HELD`、`HELD_BY_DATA_GAP`、`HELD_BY_EVIDENCE_GAP` 必须写清卡点、影响范围和下一步补救动作。

必须保留的 ana 流程底线：

1. 来源可追踪。
2. 总纲先登记。
3. 设计先冻结。
4. 设计先审核。
5. 执行全留痕。
6. 证据可复核。
7. 结果包和 manifest 归档。
8. 执行后审核。
9. 问题有闭环。
10. 结论不过读。

必须保留的研报专业底线：

1. 接到新行业研报任务后，先创建或更新 `<行业>研报解析方案.md`。
2. 行业方案必须继承 `研报解析架构.md`、`研报分析架构.md` 和父级 `案例存储体系.md`，并通过行业方案审核后才能支撑正式研报分析。
3. 原始研报和外部资料必须进入行业统一 raw 池 `ana-data/cases/<行业案例>/raw/`；不得进入 `ana-data/cases/<行业案例>/<case_id>/raw/`，也不得按 batch 或 run 拆 raw 目录。
4. 转换结果进入行业级 `converted/`，抽取结果进入行业级 `extracted/`，补充资料进入行业级 `supplement/`，通用证据事实进入行业级 `evidence/`，清单进入行业级 `manifest/`。
5. 正式人读输出、案例级引用清单和案例结论证据映射进入 `ana-data/cases/<行业案例>/<case_id>/`；临时文件进入 `ana-data/tmp/<行业案例>/<case_id>/<run_id>/`，结果入口或交付包索引进入 `ana-data/result/<行业案例>/<case_id>/`，图片进入 `ana-data/img/<行业案例>/<case_id>/`。
6. 人读核心输出应围绕行业视图、市场视图、公司视图展开。
7. 可复用结构化事实、指标、公司映射和索引可以进入 MySQL，但必须能反查到案例 ID 和文件路径。
8. 暗线、事件链和市场显影内容必须按对应规则分离，不得混入普通行业事实。
9. 每批正式研报处理后，凡准备输出覆盖性结论、公司清单、行业/市场/公司视图或投资读法，都必须执行或明确豁免市场反向补漏；补漏口径按 5.5 执行。

行业方案最低内容：

1. 行业边界：本行业包含什么、不包含什么，哪些相邻行业需要单独 review。
2. 核心变量：资源、技术、政策、需求、价格、库存、成本、金融属性、客户认证或其他主导变量。
3. 输出方案：行业视图、市场视图、公司视图的文档结构和扩展文档清单。
4. 专属表：本行业需要的行业专属表或文件型清单，以及字段含义、证据入口和复用边界。
5. 存储落点：行业级 `raw/converted/extracted/supplement/evidence/manifest/`，案例级 `outputs/manifest/evidence/`，父体系 `tmp/result/img/`。
6. 流程覆写：如果本行业不用母版默认流程，必须写清自己的流程、输入输出和审核点；不得取消父级总纲、设计审核、执行日志、执行审核和结论回写。
7. 缺口清单：当前缺哪些资料、指标、公司映射、外部信息或市场显影检查。
8. 市场反向补漏口径：目标股票池、默认时间窗口、强显影定义、scope 闸门、补资料队列和排除口径。
9. 维护记录：每次正式批次或重要方案变化必须回写原因、影响范围和审核入口。

## 6. 新行业研报容器创建流程

创建新的行业研报研究方向时，案例分析员必须在 `ana-doc/` 下创建独立行业容器目录。行业容器不是一个案例，不在行业目录内创建 `案例总纲.md`；真实案例统一登记在父级 `ana-doc/案例总纲.md`。

```text
ana-doc/有色案例/
ana-doc/机器人案例/
ana-doc/半导体案例/
```

每个行业案例目录根目录至少包含：

1. `目录导读.md`
2. `案例分析规范.md`
3. `案例审核规范.md`
4. `案例存储体系.md`
5. `案例分析设计.md`
6. `案例执行日志.md`
7. `案例审计报告.md`
8. `案例问题记录.md`
9. `<行业>研报解析方案.md`

创建步骤：

1. 确定行业名称、行业缩写、研究边界和案例目录名。
2. 创建 `ana-doc/<行业>案例/`。
3. 创建 8 个行业容器基础文档和 `<行业>研报解析方案.md`，不得在行业目录内创建 `案例总纲.md`。
4. 行业目录内的 `案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md` 必须声明继承父级同名文档，只记录行业补充，不得削弱父级规范；没有真实行业自定义时应保持轻量，不复制父级主流程和审核流程。
5. 行业目录内的 `案例分析设计.md`、`案例执行日志.md`、`案例审计报告.md`、`案例问题记录.md` 作为该行业容器自己的事项、执行、审核和问题账本独立维护，不复制父级账本内容。
6. 在父级 `目录导读.md` 登记行业案例目录。
7. 按 `案例存储体系.md` 创建或使用行业数据目录 `ana-data/cases/<行业案例>/`、行业统一 raw 池、行业级通用产物目录和逐案例结果目录 `ana-data/cases/<行业案例>/<case_id>/`；逐案例目录不得包含 raw、converted、extracted、supplement 等通用资料库目录。
8. 新行业目录创建完成后，应接受一次目录和继承关系审核。

行业案例命名规则：

1. 行业案例目录：`<行业名>案例/`。
2. 行业研报解析方案：`<行业名>研报解析方案.md`。
3. 案例 ID：`ANA-<行业缩写>-<YYYYMMDD>-<三位序号>`。
4. 行业通用数据目录：`ana-data/cases/<行业名>案例/raw|converted|extracted|supplement|evidence|manifest/`。
5. 案例目录：`ana-data/cases/<行业名>案例/<case_id>/`，只保存该案例的 outputs、引用 manifest 和案例证据映射。
6. 父体系兼容目录：临时文件使用 `ana-data/tmp/<行业名>案例/<case_id>/<run_id>/`，结果入口或交付包索引使用 `ana-data/result/<行业名>案例/<case_id>/`，图片使用 `ana-data/img/<行业名>案例/<case_id>/`。
7. raw 目录：固定为 `ana-data/cases/<行业名>案例/raw/`，所有案例共享同一个行业 raw 池。
8. 行业缩写由行业方案首次创建时确定，并写入行业目录 `目录导读.md` 或 `<行业名>研报解析方案.md`。

## 7. 行业子规范优先级和记录落点

行业目录内的 `案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md` 是行业子规范，必须以父级 `ana-doc/` 同名文档为母版。

行业子规范默认是继承入口，不是第二套母版。没有经过设计审核确认的行业自定义时，行业 `案例分析规范.md` 和 `案例审核规范.md` 应只保留继承关系、行业方案入口、当前自定义状态和少量行业补充检查；通用流程、阶段门、审核类型、存储分流和问题闭环规则统一写在父级 `ana-doc/` 母版中。

优先级规则：

1. 父级 `案例分析规范.md`、`案例审核规范.md`、`案例存储体系.md` 是第一遵守原则。
2. 行业子规范可以细化行业流程、字段、输出物、样本选择和专属表。
3. 除流程细化外，行业子规范不得与父级母版冲突。
4. 如果行业方案定义了自己的研报专业流程，执行时按行业方案流程走；但不得取消父级总纲登记、设计冻结、设计审核、执行日志、证据包、执行审核、问题闭环和结论回写。
5. 如果发现父级母版和行业子规范冲突，先按父级母版执行，并把冲突点提交人类确认。
6. 行业专业变量、行业专属表、行业输出拆分和行业缺口清单，优先写入 `<行业>研报解析方案.md` 和行业 `案例分析设计.md`；只有需要长期覆盖所有该行业案例的规则，才写入行业子规范。

记录落点规则：

1. 行业案例 ID、研究目标、边界、状态和结论入口，写入父级 `案例总纲.md`；父级总纲是唯一案例总账。
2. 行业案例的事项拆解、批次设计、执行步骤、证据要求、输出物和验收方式，写入行业目录 `案例分析设计.md`。同一行业整体研报分析原则上是一个长期案例；分批读取资料使用 `batch_id` 和 `run_id` 区分，不因为每次 30 份资料而新建案例。
3. 行业案例实际执行过程、资料读取、转换、抽取、补充、异常和证据路径，写入行业目录 `案例执行日志.md`；通用产物路径应指向行业级数据目录，案例自定义输出指向 `<case_id>/`。
4. 行业案例设计审核、执行审核、复审和审计问题，写入行业目录 `案例审计报告.md`。
5. 用户、外部 AI、人工同事等非执行责任人反馈的问题，或执行者无法自行闭环、需要跨轮/跨角色跟踪的事项，写入行业目录 `案例问题记录.md`。执行者自发现且能在本轮或本案例内处理的问题，写入行业目录 `案例执行日志.md`、自检、验证报告、manifest、数据缺口表或结果包，不写入问题记录。
6. 行业研报分析范围、核心变量、输出方案和行业专属表定义，写入 `<行业>研报解析方案.md`。
7. 父级 `ana-doc/` 记录体系级规则、跨行业规则、目录入口、父级案例总账和跨行业问题；不得承接单个行业的普通执行明细。

## 8. 外部信息补充和 darkline 使用口径

凡是在研报案例流程中需要去网上补充消息、收集外部信息、分析新闻公告、分析事件链、分析证据链、检查市场显影、判断暗线或解释异常市场表现，都必须使用 `darkline` 技能和 darkline 信息拓扑方法。

适用场景包括：

1. 研报缺少关键事实，需要通过公开资料补充。
2. 需要读取新闻、公告、政策、网页、交易所文件、监管文件或公司公开资料。
3. 需要做市场反向补漏、强势标的排查、异动公司解释或假主题噪音排除。
4. 需要判断事件链、证据链、意图、目标、组织行为或暗线。
5. 需要把外部信息和 K 线显影、成交量、题材表现、公司异动联系起来。

执行要求：

1. 在 `案例分析设计.md` 中说明本次是否需要外部信息补充或 darkline 分析。
2. 在 `案例执行日志.md` 中记录使用 darkline 的任务模式、信息来源、关键节点、证据入口和结论边界。
3. 网上补充资料进入 `supplement/`，证据链和来源定位进入 `evidence/`，来源清单进入 `manifest/`。
4. darkline 结论必须描述意图、目标或行为链条；价格、库存、供需、估值或机制解释本身不能直接叫暗线。
5. darkline 假设、事件链、市场显影和替代解释必须与普通行业事实分离记录。

## 9. 完成标准

研报类案例标记完成前至少满足：

1. 行业目录、行业方案、父级总纲案例记录、行业设计、执行日志、审计报告和问题记录完整。
2. 设计审核已通过。
3. 原始研报和外部资料已进入行业统一 raw 池，且有 manifest 或等价清单；不存在逐案例、逐批次或逐 run 的 raw 原始资料目录。
4. 行业级 raw、converted、extracted、supplement、evidence、manifest 路径清楚，案例级 outputs、引用 manifest、案例证据映射路径清楚，父体系 tmp/result/img 分流路径清楚。
5. 行业视图、市场视图、公司视图或明确的 `HELD` 状态已经产出。
6. 强结论能追溯到来源、数据日期、横向比较、历史比较、公司或链条案例。
7. 可复用结构化数据如进入 MySQL，必须能反查案例 ID 和文件路径。
8. 需要外部信息或暗线分析时，已按 `darkline` 规则留痕。
9. 执行审核已通过；如有问题，已完成修复和复审，或明确暂缓原因。

## 10. 禁止事项

1. 不得把研报解析和研报分析方法全文拆散复制到多个规范、总纲、设计或日志里。
2. 不得另建与 `案例存储体系.md` 平行的正式 `研报存储体系.md`。
3. 不得把有色、矿区、某类资产或某个行业字段写成全行业通用要求。
4. 不得把行业案例过程明细写回父级 `ana-doc/` 账本。
5. 不得绕过 `案例分析设计.md` 或设计审核直接开始正式研报分析。
6. 不得把 `tmp/` 当正式证据入口；不得把临时文件放回 `ana-data/cases/<行业案例>/<case_id>/`。
7. 不得只采信券商结论，不拆事实、数据、假设、观点和证据。
8. 不得把缺数据的观点写成确定结论；证据不足时应标记 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP`。
9. 不得把暗线、事件链和意图判断混入普通行业事实。
10. 不得让研报结论绕过案例审核直接进入正式核心文档。
11. 不得在行业容器目录内创建或维护平行的 `案例总纲.md`；真实案例必须登记到父级 `ana-doc/案例总纲.md`。

## 11. 内容优先与风险分级执行（2026-08-01）

本项目新增“内容优先”本地流程，用于纠正案例分析中治理产物、逐项冻结和多轮机械返修挤占资料补充、事实核验和人读内容建设的问题。本节不取消 common 硬约束，而是把默认流程合并成更适合长期行业研究的执行单元。

### 11.1 价值顺序

正式工作的默认优先级为：

1. 新增可读、可追溯的资料、事实、指标、公司信息和行业内容。
2. 修正会导致事实错误、证据断链、结论过读或不可恢复写入的问题。
3. 维护最低限度的设计、日志、验证和审核记录。
4. 纯格式、mtime、全文 hash、重复统计、内部命名和非关键自动化完善不得反客为主。

每个正式批次必须声明 `content_delta`。除治理事故修复或最终收口外，`content_delta=0` 的批次不得作为连续主线；应并入一个维护批次，不得拆成多轮独立设计。

### 11.2 三档风险

| 等级 | 适用事项 | 默认流程 |
|---|---|---|
| `L0 维护` | 错别字、格式、可读链接、已枚举 append-only 尾部、非关键状态文字、对结论无影响的 manifest 注记 | 执行日志留痕 + 自检；不新建设计，不单独审核 |
| `L1 内容补强` | 只读补资料、来源归档、事实卡补充、公司/专题内容补写、候选证据登记、缺口状态保持开放且不升级结论 | 一个滚动 `CONTENT_SPRINT` 设计覆盖一组相关内容；批末一次执行/输出审核，不按来源、字段或文件逐项立设计 |
| `L2 高风险变更` | 证据强度升级、缺口关闭、正式池变化、强业务结论、数据库写入、批量覆盖/删除、canonical 切换、外部不可逆动作 | 独立详细设计审核 + 精确执行放行 + 执行审核 |

“向正式 evidence map 追加只读引用，但不改变原行、证据强度、缺口状态、公司正式状态和业务结论”按 `L1` 管理；真正的证据升级、缺口关闭或正式池变化才进入 `L2`。

### 11.3 CONTENT_SPRINT 规则

1. 同一主题、同一来源类型或同一优先级的一组资料，默认合并为一个内容冲刺，不再使用“发现 -> 语义核验 -> proposal -> integration”四个独立设计包串行处理少量记录。
2. 一个冲刺只保留：来源/目标、输入范围、内容增量、结论上限、输出路径、最小验证和一次审核入口。已有 schema、parser、manifest、protected set 和审计结论直接复用，不重复冻结。
3. 验证优先检查事实文本、来源定位、对象映射、日期/口径、结论边界和人读落点。只有存在数据损坏或不可逆写入风险时，才把 mtime、rollback fault harness、逐依赖代码身份或全文 hash 提升为阻断门。
4. 内容冲刺可以同时包含 evidence register、evidence map 引用、人读文档更新和 gap 台账回写；这些动作不得被人为拆成连续小批次。
5. 同一批次的设计问题应在一次审核中合并给出。已通过的语义和集合不得在聚焦复审中重开。
6. 某个非关键机械问题不影响来源、事实、映射、结论边界和可恢复性时，记录为 `INFO/FOLLOW_UP`，不得阻断独立内容项继续推进。

### 11.4 最小审计预算

普通 `L1` 内容冲刺默认只需要一次设计审核和一次批末执行/输出审核。除发现新的高风险事实错误或不可恢复写入风险外，不为单个字段、单个文件、单个 mtime、共享 append-only 文件尾部或 reviewer 自身审计追加再建 repair run。

若连续两轮只修治理机械项而没有新增内容，必须暂停继续加门，合并问题、回到用户价值和内容补强；下一轮至少产出一项可读内容或可用证据增量。

## 12. 行业整体成果稳定入口与发布门（2026-08-07）

本节落实 `TASK-CASE-INDUSTRY-CANONICAL-RESULT-MIGRATION-20260807-001` 的父级 L2 设计终态；设计审计为 `AUDIT-CASE-INDUSTRY-CANONICAL-RESULT-MIGRATION-L2-DESIGN-20260807-001 / FOCUSED-REREVIEW-001=PASS/0/0`。本节只规范行业整体成果的稳定入口和发布，不改变 raw、converted、extracted、supplement、evidence 的行业共享存储，不替代任何行业自己的设计审核、执行/输出审核或事实边界。

### 12.1 适用范围与唯一用户入口

1. 同一行业长期积累、需要持续以 batch/run 更新的整体研究，必须使用行业根稳定入口，不再按批次或长期 case 创建多个用户可见的稳定结果入口。
2. 行业整体成果的默认阅读入口固定为 `ana-data/cases/<行业>案例/当前成果索引.md`；唯一稳定人读成果树固定为 `ana-data/cases/<行业>案例/核心文档/`；`ana-data/result/<行业>案例/当前成果索引.md` 只作跳转到 cases 当前索引的固定薄入口，不复制正文或 release 元数据。
3. 长期 `case_id` 只承担元数据、设计、审核和证据血缘；增量由 `batch_id/run_id` 表达。不得再增加 `<stable_case_id>/outputs/` 作为行业整体成果的第二套稳定入口。
4. 单次专题、单公司或不属于行业整体长期成果的普通案例，仍可使用既有 `<case_id>/outputs|manifest|evidence` 和 `result/<case_id>/`；但不得冒充行业根“当前成果”。

### 12.2 行业级设计门与候选边界

1. 父级 L2 PASS 只允许同步母规范并打开各行业设计门，不是发布、迁移或删除授权。
2. 每个行业必须由既有分析 owner 在原行业设计链冻结：候选接受批次、排除的活跃批次、旧路径映射、正式输出 exact-set、发布 `release_id`、审计包与回滚入口；再由既有行业 reviewer 审核。不得新建管理复审或平行行业审核链。
3. 候选版本只能来自已有独立执行/输出审核 PASS 的成果。DRAFT、PENDING、HOLD、正在修复或尚未关闭的 batch 必须排除，不能借目录迁移升级状态。
4. 首轮门禁继续冻结：新能源只能以 BATCH-001 已接受成果编制行业级迁移设计，BATCH-002 不发布、不移动；军工只能以 BATCH-001—BATCH-033 已接受累计成果编制候选，BATCH-034 不发布、不移动。

### 12.3 发布、恢复与审核顺序

1. 行业设计 PASS 后只允许在 task tmp 或审计过程包构建 candidate；正式行业根在行业执行/输出审核 PASS 前不得出现新 current index 或新正式核心文档。
2. 正式 promotion 必须遵守 `案例存储体系.md` 第 13 节的唯一 commit point、append-only ledger、exact-set/hash、crash/reopen 和补偿式回滚合同。任何 hash、链接、锁、状态或 rollback receipt 无法判真时 fail closed。
3. 发布后必须再次复算 cases 当前索引、当前核心文档 release、固定 result 薄入口和 current manifest；只有 ledger=`COMMITTED` 且 candidate release set 全量一致才可登记为当前成果。
4. 旧 case/result 包和历史审计文字默认只读保留。旧路径移动、收敛或删除只能在新 release COMMITTED、旧 release 可恢复、legacy mapping 闭合并经该行业既有执行/输出审核接受之后进行；不得把 Git 可恢复当作正式 rollback。

### 12.4 当前阶段边界

- `master_spec_sync=COMPLETED_BY_PROJECT_ADMIN`
- `industry_root_materialization=NOT_AUTHORIZED_BY_PARENT_PASS`
- `publication_or_migration_execution=NOT_AUTHORIZED_BY_PARENT_PASS`
- `newenergy_batch001_industry_design_gate=OPEN`
- `newenergy_batch002=FROZEN_NO_PUBLISH_NO_MOVE`
- `defense_batch034=FROZEN_NO_PUBLISH_NO_MOVE`

### 12.5 单一稳定正文后继规则（2026-08-08）

本小节落实 `TASK-DEFENSE-SINGLE-CORE-DOCUMENT-REMEDIATION-20260808-001`，是第 12 节的后继纠错条款；与 12.1—12.4 中“核心文档下保存不可变 release 正文树”或“按 release 链接正文”冲突的口径，以本小节为准。既有历史文字保留用于审计，不作为继续创建多版本用户树的依据。

1. 行业整体成果的唯一用户入口固定为 `ana-data/cases/<行业>案例/当前成果索引.md`，唯一用户正文树固定为 `ana-data/cases/<行业>案例/核心文档/`。同一行业不得再维护第二套完整正文树或 `<stable_case_id>/outputs/` 行业整体入口。
2. `核心文档/` 内只保留当前有效的稳定文件和稳定子目录；禁止 `.releases/<hash>/`、日期/批次/版本后缀、以 release/hash 命名的正文目录，以及任何并列的完整历史正文副本。后续批次直接晋升并持续完善相同路径、相同文件。
3. `batch_id`、`run_id`、`revision`、`release_id` 和内容哈希只进入 manifest、promotion ledger 与审计元数据，不得改变用户正文路径或文件名。
4. candidate 只能在 `ana-data/tmp/<行业案例>/<task_id>/<run_id>/` 或等价 task tmp 中构建和验证；上一正式状态快照、差异、验收、回滚材料和历史 release 只进入 `ana-data/cases/<行业>案例/审计包/`，不得放回用户阅读树。
5. `ana-data/result/<行业>案例/当前成果索引.md` 只允许作为固定、轻量的跳转入口，指向 cases 当前索引；不得复制正文、历史版本或形成第二套发布状态。
6. 一个 `CONTENT_SPRINT` 只允许一次合并设计确认和一次合并执行/输出确认；文件、公司、字段和普通机械校验均包含在这两个合并门内，不得据此新增逐项审核、平行审核或管理批准层。
7. 历史已发布 release 不删除、不改写。需要从旧 `.releases/` 或其他多版本用户树迁出时，必须可恢复地归档到审计包，逐项记录旧路径、审计包路径、bytes、SHA-256、原接受审计和迁移状态；迁移本身仍须走原行业任务链，不由本次母规范纠错直接授权。

### 12.6 非空 direct stable core 的有界维护后继（2026-08-13）

本小节是 12.3、12.5 的窄范围 append-only 后继，仅适用于行业唯一 `核心文档/` 已非空、后续 `CONTENT_SPRINT` 必须更新同一稳定路径集合且文件系统不能提供整目录集合级原子替换的情形。它不授权任何具体行业研究、下载、candidate 构建、正式变更或发布；与本小节冲突的“candidate 激活前 cases 入口必须一直表达 prior current”口径，以本小节的显式撤回维护语义为准。

1. 进入维护前，candidate 必须已通过原行业链一次合并执行/输出审核；prior exact-set、逐项 bytes/SHA-256、可恢复快照、回滚材料、同卷条件、目标缺失条件、独占锁和 append-only ledger 必须闭合。父级后继不能替代该审核，也不能把 `HOLD/PENDING` 成果升级为 candidate。
2. 在任何正式正文变更前，允许把 cases `当前成果索引.md` 原子替换为设计时已冻结精确 bytes/SHA-256 的 `MAINTENANCE_NO_CURRENT_RESULT` 入口，并以同卷原子操作安装同样已冻结的 transition state 成员。该动作只撤回 current、建立 fail-closed 维护门，不是 candidate 发布 commit，不生成第二个 release。
3. 维护态明确表示“当前无正式成果”。固定 result 薄入口仍只跳转 cases 入口；canonical reader 必须先校验 cases 入口及 transition state，命中维护、未知状态或哈希漂移即 `STOP`，不得读取、引用、缓存或推断 `核心文档/`、current manifest 或其中任一路径。直接稳定路径脱离一个 accepted cases 入口和 matching current manifest 时没有 current 语义。
4. 维护态确认激活后，才允许以同卷、目标不存在的 whole-directory rename，把完整 prior core 移入该 run 的审计包，再把 task tmp 中已审核的完整 candidate core 整体 rename 到稳定位置。任一步失败或现场不完整都保持维护态，不得把混合、缺失或过渡集合解释为 current。
5. candidate core、candidate manifest、cases candidate index、固定 result 薄入口和 formal exact-set 全量匹配后，cases candidate index 的原子替换仍是唯一 candidate activation commit。维护态 withdrawal 不计作发布；cases candidate index 生效前 candidate 不具有 current 语义。
6. 每个适用的行业设计必须冻结 maintenance entry/state 的精确 bytes/SHA-256、状态与拒绝谓词、prior/candidate 身份、同卷和目标缺失前置条件、维护窗口与 lease、全部 transition state、canonical reader 规则、direct-path 语义，以及逐状态 crash/reopen/rollback 矩阵。窗口或 lease 超限只能进入 `RECOVERY_REQUIRED`，不得自动把任何现场恢复为 current。
7. 任一时刻只允许三种可判定语义：完整 prior current、`MAINTENANCE_NO_CURRENT_RESULT`（无 current）、完整 candidate current。未知状态、哈希漂移或集合不匹配一律 fail closed；恢复必须在维护入口保持生效时收敛为完整 prior 或完整 candidate，最后才原子切回对应 cases index。
8. 不得仅靠 lock、未实现的 reader 声明或逐文件 `ReplaceFile` 冒充集合级提交；正式入口仍表达 prior current 时禁止修改 direct core。一个 sprint 仍只走原行业的一次合并设计确认和一次合并执行/输出确认，不新增逐文件、平行或管理复审。

## 13. 专题可读性、术语解释与横向比较统一规范（2026-08-10）

本节适用于军工、有色、机器人、新能源及后续行业的产业链、子行业、公司研究和重点专题。目标不是堆积公司名称，而是让读者在同一份稳定正文中快速回答“产品是什么、技术路线有什么区别、谁更强、为什么强、需求如何转成收入”。行业子规范可增加行业术语和指标，但不得降低本节要求。

### 13.1 术语解释必须就地可读

1. 专有名词、英文缩写、技术路线、财务口径或行业黑话第一次出现时，必须同时给出中文全称、通俗解释和其在本次分析中的作用；不能只给缩写或让读者自行搜索。
2. 术语密集的专题必须在正文前部设置“阅读前术语速查”，并链接到行业统一词典。统一词典至少包含：标准名称、英文/缩写、通俗解释、所属产业链环节、常见误读和相关专题。
3. 同一个术语在不同文件中使用同一规范名称。历史别名、市场俗称和机构口径可以保留，但必须标注“别名/非规范名”，不能形成两套分类。
4. 术语解释属于正文可读性要求，不得以附录或词典已经存在为由省略首次出现时的最小解释。

### 13.2 专题必须从产品和技术路线拆解

专题最低结构为：

1. 一句话结论与研究边界；
2. 阅读前术语速查；
3. 产品类型、任务或应用场景；
4. 技术路线及其原理、优势、局限、成熟度和适用条件；
5. 上游—核心部件—分系统—整机/系统—服务保障的完整产业链；
6. 各环节上市公司、重要非上市玩家、海外玩家和可能的民用替代；
7. 同技术路线横向比较、跨技术路线差异说明；
8. 产业链位置、单机/单套/单发价值口径、价值密度和消耗/更换属性；
9. 情景传导、订单与财务验证、反证和资料缺口；
10. 当前优先玩家、选择理由、未选择理由和下一步验证点。

若公开资料无法确认单机、单套或单发价值，必须写 `UNKNOWN`、可比较的替代口径和缺口，不得用行业总空间、项目金额或同类产品价格冒充公司价值量。

### 13.3 横向比较必须回答“孰强孰弱”

1. 先按相同产品、相同技术路线、相同产业链环节分组，再比较公司；不得把整机、核心部件、软件服务和相邻业务放在一张总表中直接排名。
2. 同路线比较至少覆盖：核心产品、技术原理、性能/可靠性、资质与客户验证、量产能力、业务纯度、成本与供应链、订单/交付、收入利润、现金流、可替代性和主要短板。
3. 不同路线必须先解释各自解决什么问题、何时更优、何时失效，再给条件式结论；不得只用“技术领先”“平台优势”“卡位稀缺”等空泛表述。
4. 每一组比较必须给出：当前相对领先者、领先的具体维度、落后者的具体短板、结论成立的证据、可能改变排序的条件。没有足够证据时允许并列或 `UNKNOWN`，不得为了形成名次而强排。
5. 公司卡片必须能一眼读出：做什么、处于哪个环节、主要技术路线、优势、劣势、同组对手、当前强弱结论、价值量口径和最关键验证指标。

### 13.4 需求、价值量与财务兑现分账

1. 必须区分一次性消耗品、可维修装备、软件/服务、基础设施和核心部件。一次性消耗品重点看库存、消耗率、补库和产能；装备重点看新增部署、损耗替换、升级和保障；软件/服务重点看节点数、席位/终端、版本升级、运维和项目验收，不得默认“战争升级即量价齐升”。
2. 情景影响统一使用“事件/需求 → 采购主体与预算 → 公司可供产品与资格 → 合同/订单 → 生产交付 → 验收收入 → 回款现金流”链条。任一关键节点没有公开证据时，结论停留在相应层级。
3. “价值量”优先使用可核的单机/单套/单发金额或收入分部；其次使用价值密度、数量驱动因素和相对高/中/低口径。所有估算必须披露口径、时间和不确定性。
4. 市场价格、题材热度和新闻关联只能作为市场表现或待验证线索，不能替代订单、交付、利润和现金流证据。

### 13.5 玩家范围与证据边界

1. 产业研究不以 A 股为边界。对理解技术路线、成本曲线和竞争格局有实质意义的非上市企业、科研机构、海外公司、开源生态和民用供应商应纳入玩家地图，但必须与可投资标的分栏。
2. 民用替代必须说明替代的是哪一层：原材料、通用器件、整机、软件、网络或服务；同时说明军用环境、可靠性、认证、保密、出口和最终用途限制，不能把“能用”写成“已进入订单”。
3. 公司被列为玩家不等于被列为重点标的。重点标的必须同时满足业务映射、证据强度、财务可解释性和情景传导条件；不满足时保留观察名单和明确缺口。
4. `FACT`、`VIEWPOINT`、`INFERENCE`、`SCENARIO`、`CONTRADICTION`、`GAP/UNKNOWN` 必须分账。假设性政策、战争、出口或供货情景必须显式标为 `SCENARIO`，不得改写成现实订单。

### 13.6 更新与验收

1. 本节要求直接更新行业唯一稳定正文路径，不创建“详细版”“增强版”“V2”或日期/批次副本。
2. 同一批专题、词典、公司卡和索引更新合并为一个 `CONTENT_SPRINT`；术语、公司、表格和字段均不得拆成额外逐项审核。
3. 最小验收包括：术语首现可理解、行业词典链接有效、同路线分组完整、技术路线差异明确、玩家地图含必要的非上市/民用替代、价值量有口径或 `UNKNOWN`、情景传导与财务兑现分账、横向结论有理由和反证。