| | |
|---|
| | | 创建人员：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；产业链地图通用模板与研究方法.md；数据抓取脚本说明.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审核规范.md；案例存储体系.md；案例审计报告.md；案例问题记录.md；研报体系/研报解析架构.md；研报体系/研报分析架构.md；../项目配置清单.md。 |
|---|
| | | 记录方式：项目本地规范；本项目案例分析口径发生变化时更新，并同步项目变更记录。 |
|---|
| | | |
|---|
| | | ## 1. 基本口径 |
|---|
| | |
|---|
| | | | `案例执行日志.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. 最小案例链路 |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | 上面 12 步是分析员必须执行的主流程。下面是这个主流程拆开的具体工作流和配套规范，分析员按任务类型选择对应流程执行，不需要再自行拼接 common 流程和研报流程。 |
|---|
| | | |
|---|
| | | ### 5.0A 来源聊天记录轻量入口 |
|---|
| | | |
|---|
| | | 案例分析事项必须能追溯用户原始要求，但不得把该要求扩展成繁重的重复归档流程。 |
|---|
| | | |
|---|
| | | 最低要求： |
|---|
| | | |
|---|
| | | 1. 每个案例事项、行业方案重要变更、设计审核、执行审核、输出审核或复审送审时，必须提供“来源聊天记录入口”或等价来源入口。 |
|---|
| | | 2. 来源入口可以是 MB-X `message_id`、会话 marker、原始聊天导出文件路径、管理系统消息记录路径，或能让审核员反查原始用户要求的其他稳定入口。 |
|---|
| | | 3. 送审正文中必须列明：来源入口、覆盖消息范围或时间范围、用户原始要求摘要、本次变更和原始要求的对应关系。 |
|---|
| | | 4. 不要求在送审消息里全文粘贴原始聊天记录；长聊天应保留在正式来源文件、消息链或可复核入口中，送审消息只写摘要和路径。 |
|---|
| | | 5. 对同一长期案例的连续小修、复审或执行轮次，可以复用同一个来源聊天记录入口，只需补充本轮新增用户要求或新增消息范围。 |
|---|
| | | 6. 只有当原始聊天缺失、来源入口不可打开、用户要求发生实质变化或审核员无法判断目标来源时，才需要补建来源记录或退回修复。 |
|---|
| | | 7. 不得因为该规则要求为每次格式小修、错别字修复或纯链接显示修复新建完整聊天证据包；此类小修可在执行日志中引用已有来源入口。 |
|---|
| | | |
|---|
| | | ### 5.1 新行业首次接入流程 |
|---|
| | | |
|---|
| | | 适用场景：第一次接到某个行业的研报任务，或者行业目录和行业方案还不存在。 |
|---|
| | |
|---|
| | | 1. 在父级 `案例总纲.md` 确认真实案例已经登记；如果是同一长期研究目标的新资料输入，沿用同一个 `case_id`，用新的 `batch_id` 和 `run_id` 区分。 |
|---|
| | | 2. 读取行业方案，确认本次资料属于该行业边界；不属于边界的资料进入排除说明或相邻行业 review，不得混入核心结论。 |
|---|
| | | 3. 如果本次需要更新行业方案，先在 `<行业>研报解析方案.md` 写清变更原因、影响范围和维护记录，并提交行业方案复审；复审通过前，不得把新方案作为正式分析依据。 |
|---|
| | | 4. 在行业 `案例分析设计.md` 冻结本次资料来源、样本范围、case/batch/run、执行步骤、证据要求、输出物、存储路径、darkline 触发边界和验收方式。 |
|---|
| | | 5. 设计审核未通过前，不得正式归档、转换、抽取或输出结论；需要先盘点资料时，必须标记为 dry-run。 |
|---|
| | | 6. 按已审核设计执行研报分析：先归档和转换资料，再抽取事实、观点、指标、公司映射、产业链节点和资料缺口。 |
|---|
| | | 7. 对关键指标、公司映射、产业链环节、供需价格库存成本等变量建立证据数据卡；缺少核心数据时进入缺口状态，不得直接写强结论。 |
|---|
| | | 8. 单篇研报不能只做摘要，必须记录 doc_id、页码或段落定位、句子/表格索引、时间、单位、口径、对象归属、事实句、指标句、观点句、公司映射、风险句和置信度。 |
|---|
| | | 9. 批量研报不能压成一个大摘要，必须按 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` 或等价结构化记录。 |
|---|
| | | 10. 多篇资料之间存在支持、反对、重复观点或口径冲突时，优先分账记录冲突和证据来源，不得强行合并成单一结论。 |
|---|
| | | 11. 需要公开资料补充、公告补证、市场反向补漏、新闻事件或暗线判断时，使用 `darkline` 或对应外部信息方法，并把补充来源、时间和置信度写入证据链；主动补数据按 5.4 执行，市场反向补漏按 5.5 执行，不能只写“已补漏”。 |
|---|
| | | 12. 根据证据链形成行业视图、市场视图、公司视图和必要扩展文档；核心文档输出按 5.6 执行。 |
|---|
| | | 13. 生成或更新行业级 manifest、案例级引用 manifest、验证报告和父体系 `result_index.md`。 |
|---|
| | | 14. 在行业 `案例执行日志.md` 记录全过程、偏离、异常、自检和本轮结论边界。 |
|---|
| | | 15. 提交执行审核；审核未通过前，不得对外交付或把案例标记完成。 |
|---|
| | | 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 研报资料归档和处理流程 |
|---|
| | | |
|---|
| | |
|---|
| | | |
|---|
| | | 1. 先检查证据是否足够支撑人读输出；只有 raw、converted 或 evidence extracted，不等于可以输出强结论。 |
|---|
| | | 2. 输出前必须读取归档资料、结构化数据、未解决数据缺口、source_gap_audit 和市场反向补漏结果；市场反向补漏未执行时，必须说明适用性判断和设计依据。 |
|---|
| | | 3. 输出必须围绕行业视图、市场视图、公司视图展开，细分行业、指标卡、公司深读、投资读法和暗线文档只是扩展产物。 |
|---|
| | | 4. 写作和更新顺序从底层到总览：先更新结构化记录和证据数据卡，再更新子行业详细材料，再更新子行业总览，再更新公司文档，最后更新行业总览、市场总览和索引；最终交付仍以行业视图、市场视图、公司视图为上层入口。 |
|---|
| | | 5. 成熟子行业、核心技术路线或核心公司在写强结论前必须有基础事实卡；事实卡应包含行业等价的市场规模、产销/供需、价格或收入/利润口径、库存或交付节奏、核心国家/区域/客户/公司、产业链位置和 A 股映射。某项不适用时写明不适用原因，不能静默省略。 |
|---|
| | | 6. 每个重要结论必须包含来源、数据日期、历史比较、横向比较、结构占比或公司/链条案例、结论强度和失效条件。 |
|---|
| | | 7. 关键变量和产业链流程必须用普通人能理解的语言解释，不能只给术语表、箭头图或标题式结论。 |
|---|
| | | 8. 重要场景假设必须写影响映射：事件发生后影响哪些子行业、公司、价格、利润、订单、估值或情绪，并说明触发条件、失效条件和主要风险。 |
|---|
| | | 9. 数据不足时必须降级为 `DATA_GAP_REVIEW`、`DATA_PARTIAL`、`MECHANISM_ONLY` 或 `HELD_BY_EVIDENCE_GAP`，不得用券商观点或故事替代数据。 |
|---|
| | | 10. 公司文档必须先给投资读法和当前状态，再展开业务结构、行业暴露、核心竞争力、证据链和风险。 |
|---|
| | | 11. 市场反向补漏发现遗漏公司、子行业、资源品种、技术路线或关键变量时，先进入补资料和缺口流程；补完前不得写“覆盖完整”。 |
|---|
| | | 12. 暗线、事件链、意图判断和市场显影假设必须单独分账，不能混入普通行业事实文档。 |
|---|
| | | 13. 输出完成后，必须生成人读文档验收记录或等价验证说明，并能反查到证据、manifest 和原始资料。 |
|---|
| | | 14. 核心文档完成后，必须提交输出审核或执行审核；审核通过前，不得对外交付，也不得把输出状态写成已完成。 |
|---|
| | | 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. 核心文档完成后，必须提交输出审核或执行审核；审核通过前，不得对外交付，也不得把输出状态写成已完成。 |
|---|
| | | |
|---|
| | | 补证轮次达到上限后的输出口径： |
|---|
| | | |
|---|
| | |
|---|
| | | 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`、情景传导与财务兑现分账、横向结论有理由和反证。 |
|---|
