本文档是 darkline 案例数据的入口说明。它说明已有案例在哪里、数据库表怎么查、后续新增案例应如何记录。
历史案例已作为迁移数据导入新 darkline 体系。
文件入口：
data/legacy_case_import_20260624/
核心文件：
legacy_case_index.csv
legacy_case_import_summary.json
legacy_case_import_manifest.csv
case_body/*.md
读法：
legacy_case_index.csv 是案例索引。case_body/*.md 是每条案例的历史正文快照。legacy_case_import_summary.json 是导入统计和数据库校验结果。legacy_case_import_manifest.csv 是文件级 hash 和状态清单。边界：
长期可检索数据已写入同一 MySQL 数据库的 dl_ 命名空间。
当前入口表：
dl_case_import_batch
dl_case_record
dl_darkline_hypothesis
dl_chain_state
最常用查询：
SELECT case_id, case_title, case_family, case_level, current_status
FROM dl_case_record
WHERE import_batch_id = 'DL_LEGACY_CASE_IMPORT_20260624_V1'
ORDER BY case_order;
查看某条案例正文：
SELECT case_id, case_title, case_body_md
FROM dl_case_record
WHERE case_id = 'DLCASE_LEGACY_0001';
查看链路状态：
SELECT case_id, chain_clarity_status, reality_confirmation_status,
market_manifestation_status, validation_readout_status,
current_consumption_level
FROM dl_chain_state
WHERE case_id = 'DLCASE_LEGACY_0001';
新增案例必须同时满足“人能读”和“机器能查”两个要求。
流程：
1. 先写案例正文：按 B/C -> A -> M -> N/L -> 市场输出 -> 实际结果 -> 总结。
2. 再写案例索引：case_id、标题、层级、家族、当前状态、缺口。
3. 能入库的字段入库：假设、事件、证据、影响对象、显影、状态。
4. 附件放 data/ 对应批次目录：原文快照、图、表、manifest。
5. 每次判断变化新增版本，不覆盖旧判断。
新增案例正文最低结构：
## 案例标题
### B/C：最初看到的叶子
记录最初新闻、公告、异常现象或市场表现。
### A：反推出的暗线意图
必须写成意图、目标、人心或组织意志，不能写成机制标签。
### M：前置铺垫
如果 A 为真，B/C 之前应该发生过什么。
### N/L：后续行为
如果 A 为真，B/C 之后还应发生什么。
### 市场输出
落到哪个输出层：K线、风格、股票池、单票、其他。
### 实际结果
实际有没有显影，是否与预期一致。
### 替代解释
市场普涨、行业风、单票本体动能、其他暗线、数据缺口。
### 当前结论
能交付什么，不能交付什么，下一步查什么。
新增案例不能只留 Markdown。
最低入库要求：
dl_case_record：案例主记录和正文快照。
dl_darkline_hypothesis：反推的暗线假设。
dl_expected_line：至少 1 条应有之线。
dl_chain_state：链路状态、验证状态、消费等级。
如果进入证据链追踪，还要继续落：
source_document
event_node
expected_line
evidence
impact_target
manifestation_bridge
alternative_explanation
完整链路检查清单：
B/C 是否记录：最初看到的新闻、公告、异常现象或市场表现。
A 是否记录：反推出的暗线意图，必须是意图/目标/人心/组织意志。
M 是否记录：如果 A 为真，B/C 之前应该已经发生的铺垫。
N/L 是否记录：如果 A 为真，B/C 之后还应该发生的行为。
why 节点是否记录：为什么是这个时间、主体、动作，为什么之前没有。
evidence 是否记录：直接证据、侧证、反证和缺口。
impact_target 是否记录：落到 K线、风格、股票池、单票或其他输出层。
manifestation 是否记录：市场是否显影，何时显影，是否需要替代解释。
alternative 是否记录：市场普涨、行业风、单股动能、其他暗线、数据缺口。
chain_state 是否新增版本：判断变化只能新增，不覆盖旧状态。
没有证据的节点可以保留为 HELD，但不能空着不说明，也不能伪造成已经发生。
复用历史案例时必须先检查：
case_body_hash 是否和索引一致
current_status 是否仍为 LEGACY_IMPORTED_REVIEW
是否有新的 evidence / chain_state 版本
是否存在替代解释或旧结论过读
是否已经按当前方法论补齐关键 why 节点
没有复核前，只能作为 casebook 参考，不能作为规则、预测或条件器依据。
当前案例数据已经从“只保存案例正文”升级为 full archive。新增案例也应尽量按同一结构归档。
dl_case_reasoning_step 推理步骤和关键 why 节点
dl_expected_line 应有之线
dl_event_node 现实事件节点
dl_evidence 证据摘录和证据强度
dl_evidence_node_link 证据、事件、应有之线之间的多对多关系
dl_impact_target 影响对象
dl_manifestation_bridge 市场或输出层显影
dl_alternative_explanation 替代解释
只写 dl_darkline_hypothesis 不够。没有 full archive 的案例只能作为假设入口，不能作为已追踪完成案例。
从旧项目迁入的案例必须按新项目标准显式合规。
当前处理口径：
所有 legacy case 都必须通过结构链路检查：
case_record / hypothesis / reasoning_step / expected_line / evidence / event_node /
evidence_node_link / impact_target / manifestation_bridge / alternative_explanation / chain_state。
但结构完整不等于事实验证完整。老案例分两类：
CASEBOOK_FULL_CHAIN_IMPORTED：
旧案例迁入时已有事件节点、显影、替代解释等完整链路。
CASEBOOK_WITH_EXPLICIT_GAPS：
旧案例迁入时某些链路层缺失，已补入 *_GAP_REVIEW 记录。
这些 GAP 行是缺口标记，不是已验证事实。
禁止误读：
EVENT_NODE_ARCHIVE_GAP 不是现实事件。
HELD_BY_MARKET_MANIFESTATION_GAP 不是市场显影成立。
HELD_BY_ALTERNATIVE_EXPLANATION_GAP 不是替代解释已排除。
复用旧案例前，必须先看最新 dl_chain_state.validation_readout_status。如果是 CASEBOOK_WITH_EXPLICIT_GAPS，只能作为案例线索，不能作为完整暗线样板。