From df3b9d10920651254182d60fbc525412199aad31 Mon Sep 17 00:00:00 2001
From: 1 <wentingyear@gmail.com>
Date: Thu, 25 Jun 2026 20:37:46 +0800
Subject: [PATCH] fix: add analysis and experiment systems

---
 ana-doc/案例审核规范.md        |  137 ++
 exp-data/tmp/.gitkeep    |    1 
 ana-doc/案例分析规范.md        |  221 +++
 exp-doc/实验执行日志.md        |   84 +
 exp-doc/实验问题记录.md        |   71 +
 ana-data/img/.gitkeep    |    1 
 ana-doc/案例总纲.md          |   61 +
 mbx.project.yaml         |   39 
 ana-doc/案例存储体系.md        |  135 ++
 mbx.project.yaml.bak     |   73 
 exp-doc/实验总纲.md          |   95 +
 项目事项计划.md                |   26 
 ana-doc/案例审计报告.md        |   76 +
 exp-data/result/.gitkeep |    1 
 ana-doc/案例执行日志.md        |   71 +
 项目事项总纲.md                |   26 
 项目执行日志.md                |   61 +
 项目变更记录.md                |   26 
 exp-data/raw/.gitkeep    |    1 
 ana-data/cases/.gitkeep  |    1 
 .mbx/messages.jsonl      |    4 
 ana-data/result/.gitkeep |    1 
 exp-doc/实验审计规范.md        |  444 +++++++
 exp-doc/实验规范.md          |  492 ++++++++
 exp-doc/实验设计.md          |  116 ++
 ana-data/tmp/.gitkeep    |    1 
 exp-doc/目录导读.md          |   46 
 ana-doc/案例分析设计.md        |   84 +
 exp-data/img/.gitkeep    |    1 
 项目事项审计报告.md              |   26 
 ana-doc/案例问题记录.md        |   58 +
 exp-doc/实验审核规范.md        |  444 +++++++
 exp-doc/实验存储体系.md        |  254 ++++
 exp-doc/实验审计报告.md        |   77 +
 项目配置清单.md                |   12 
 ana-doc/目录导读.md          |   49 
 36 files changed, 3,292 insertions(+), 24 deletions(-)

diff --git a/.mbx/messages.jsonl b/.mbx/messages.jsonl
index 0ea3fd1..23cbc7f 100644
--- a/.mbx/messages.jsonl
+++ b/.mbx/messages.jsonl
@@ -38,3 +38,7 @@
 {"schema_version":"1.0","event_id":"evt_20260624003333098_72a7efce","event_type":"managed_session.repaired","scope":"project","project_id":"project-info","role_instance_id":"case_analysis.analyst","created_at":"2026-06-24T00:33:33+08:00","status":"completed","actor":{"type":"runtime","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"MB-X managed session runtime"},"message_id":null,"result":{"managed_session_key":"project-info.laoyan","project_id":"project-info","role_instance_id":"case_analysis.analyst","ai_id":"laoyan","provider_session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","details":["managed_session_key: project-info.laoyan","project_id: project-info","role_id: case_analysis.analyst","ai_id: laoyan","provider: codex","provider_session_id: 019ef54e-6978-76d3-bb78-081fa2c4b188","cwd: D:\\manage_system\\project-info","registry_status: idle"]}}
 {"schema_version":"1.0","event_id":"evt_20260624003333113_16a3987a","event_type":"managed_session.repaired","scope":"project","project_id":"project-info","role_instance_id":"experiment.reviewer","created_at":"2026-06-24T00:33:33+08:00","status":"completed","actor":{"type":"runtime","project_id":"project-info","role_id":"experiment.reviewer","role_instance_id":"experiment.reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"MB-X managed session runtime"},"message_id":null,"result":{"managed_session_key":"project-info.laoshen","project_id":"project-info","role_instance_id":"experiment.reviewer","ai_id":"laoshen","provider_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","details":["managed_session_key: project-info.laoshen","project_id: project-info","role_id: experiment.reviewer","ai_id: laoshen","provider: codex","provider_session_id: 019ef550-45ac-7b43-aa24-2731d01dba9b","cwd: D:\\manage_system\\project-info","registry_status: idle"]}}
 {"schema_version":"1.0","event_id":"evt_20260624010850490_23a3034b","event_type":"governance.refreshed","scope":"project","project_id":"project-info","created_at":"2026-06-24T01:08:50+08:00","actor":{"type":"management","project_id":null,"role_id":null,"session_id":"workspace-admin","provider":"codex","name":"管理端"},"ext":{"roles":["case_analysis.analyst","experiment.reviewer","case_analysis.reviewer","experiment.experimenter","dev.developer.ana","dev.reviewer.ana","dev.developer.exp","dev.reviewer.exp"]}}
+{"schema_version":"1.0","event_id":"evt_20260625203332759_27d48100","event_type":"system.enabled","scope":"project","project_id":"project-info","created_at":"2026-06-25T20:33:32+08:00","actor":{"type":"management","project_id":null,"role_id":null,"session_id":"workspace-admin","provider":"codex","name":"管理端"},"ext":{"system_id":"case_analysis"}}
+{"schema_version":"1.0","event_id":"evt_20260625203332762_149690d5","event_type":"config.changed","scope":"project","project_id":"project-info","created_at":"2026-06-25T20:33:32+08:00","actor":{"type":"management","project_id":null,"role_id":null,"session_id":"workspace-admin","provider":"codex","name":"管理端"},"ext":{"operation":"system.enable","system_id":"case_analysis"}}
+{"schema_version":"1.0","event_id":"evt_20260625203333501_320ef5cb","event_type":"system.enabled","scope":"project","project_id":"project-info","created_at":"2026-06-25T20:33:33+08:00","actor":{"type":"management","project_id":null,"role_id":null,"session_id":"workspace-admin","provider":"codex","name":"管理端"},"ext":{"system_id":"experiment"}}
+{"schema_version":"1.0","event_id":"evt_20260625203333503_843b4f8f","event_type":"config.changed","scope":"project","project_id":"project-info","created_at":"2026-06-25T20:33:33+08:00","actor":{"type":"management","project_id":null,"role_id":null,"session_id":"workspace-admin","provider":"codex","name":"管理端"},"ext":{"operation":"system.enable","system_id":"experiment"}}
diff --git a/ana-data/cases/.gitkeep b/ana-data/cases/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/ana-data/cases/.gitkeep
@@ -0,0 +1 @@
+
diff --git a/ana-data/img/.gitkeep b/ana-data/img/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/ana-data/img/.gitkeep
@@ -0,0 +1 @@
+
diff --git a/ana-data/result/.gitkeep b/ana-data/result/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/ana-data/result/.gitkeep
@@ -0,0 +1 @@
+
diff --git a/ana-data/tmp/.gitkeep b/ana-data/tmp/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/ana-data/tmp/.gitkeep
@@ -0,0 +1 @@
+
diff --git "a/ana-doc/\346\241\210\344\276\213\345\210\206\346\236\220\350\247\204\350\214\203.md" "b/ana-doc/\346\241\210\344\276\213\345\210\206\346\236\220\350\247\204\350\214\203.md"
new file mode 100644
index 0000000..f45a35d
--- /dev/null
+++ "b/ana-doc/\346\241\210\344\276\213\345\210\206\346\236\220\350\247\204\350\214\203.md"
@@ -0,0 +1,221 @@
+# 案例分析规范
+
+创建人员：Codex  
+文件职责：定义案例分析体系的定位、核心流程、证据链要求、文档职责、审计闭环和问题处理边界。  
+管理规范/模板：../../全局规范.md；../../体系说明.md；../../体系创建流程.md。  
+引用文件：案例分析环境创建指南.md；案例存储体系创建指南.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md；案例审核规范.md；案例审计报告模版.md；案例问题记录模版.md。  
+记录方式：全局案例分析规范；案例分析流程或审计口径变化时更新。
+
+统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地案例分析规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。
+
+## 1. 定位
+
+案例分析体系用于管理一类“对具体案例做全流程分析、复盘、解释和校验”的事项。
+
+案例可以来自：
+
+1. 方法论或笔记。
+2. 交易、需求、用户、工程、业务流程。
+3. 样本数据。
+4. 人工标注。
+5. AI 发现的异常或候选。
+
+案例分析不是代码实现，也不是单纯写总结。它要把“为什么选这个案例、怎么分析、每一步依据是什么、最后结果是什么、是否符合原始方法论”都留下证据链。
+
+## 2. 核心目标
+
+案例分析体系要达成：
+
+1. 能追踪案例起因和原始要求。
+2. 能复核案例为什么被选中。
+3. 能复核每一步判断或操作是否按规则发生。
+4. 能看到中间关键节点的数据、图片或文本证据。
+5. 能判断最终结论有没有过读。
+6. 能让审核员和人类读者快速理解案例前因后果。
+
+## 3. 核心流程
+
+默认流程：
+
+```text
+来源聊天记录 / 上游方法论 / 样本来源
+-> 案例总纲记录背景、目标、边界、当前结论
+-> 案例分析设计记录案例选择口径、分析步骤、证据要求、验收方式
+-> 设计审核
+-> 执行案例分析
+-> 案例执行日志记录候选、过程、关键数据、图片、结果
+-> 结果包 / 证据包归档
+-> 执行审核
+-> 审计报告记录审计问题 / 问题记录承接非审计问题或审计索引
+-> 修复 / 复审
+-> 结论回写到案例总纲和案例设计
+```
+
+设计审核未通过，不得进入正式执行。
+
+执行审核未通过，不得把案例标记为完成或可交付。
+
+### 3.0 本地案例分析流程优先级
+
+common 案例分析规范规定案例体系底线和默认流程，项目本地 `ana-doc/案例分析规范.md` 可以设计更适合本项目的案例分析流程。
+
+本地案例流程设计必须满足案例体系硬约束：来源聊天和上游依据可追踪、目标和边界清楚、案例选择口径冻结、关键判断有证据、设计和执行有审核闭环、结论不过读。
+
+本地流程可以做两类调整：
+
+1. 新增流程：例如新增逐图验收流程、人工回填流程、交易案例复盘流程。
+2. 修改默认流程：例如把案例设计、执行、验收、复盘步骤拆分、合并或替换为项目内更合适的步骤。
+
+如果只是新增流程，只要不违反案例体系硬约束即可放行。  
+如果是修改默认流程，必须在本地 `案例分析规范.md`、`案例分析设计.md` 或对应案例事项中写清楚覆盖范围、替换原因、输入输出、关键证据链和审核点。
+
+本地案例流程一旦设计完成并通过审核，执行时以本地流程为准；案例审核员也应按已通过的本地流程审计执行结果。只有发现本地流程违反案例体系硬约束时，才回到 common 案例分析规范要求整改。
+
+### 3.1 案例分析设计流程
+
+设计流程负责回答“为什么分析、分析什么、怎么分析、怎么验收”。
+
+设计流程至少包括：
+
+1. 记录来源聊天、上游方法论、样本来源和事项背景。
+2. 在案例总纲中登记案例分析目标、边界、当前状态和预期结论形式。
+3. 在案例分析设计中冻结案例选择口径、分析步骤、证据要求、图片要求、数据输出和验收方式。
+4. 明确是否需要防未来函数、是否需要人工复核关键触发点、是否需要逐图验收。
+5. 提交设计审核。
+
+设计审核通过后，执行员应按冻结设计执行；如执行中发现设计不合理，应记录偏离原因，并回到设计修订和复审，不得直接换口径继续跑。
+
+### 3.2 案例分析执行流程
+
+执行流程负责回答“实际怎么跑、每一步证据在哪里、结果如何复核”。
+
+执行流程必须按逐案例证据链留痕：
+
+```text
+读取已审核通过的案例分析设计
+-> 生成或读取候选池
+-> 记录候选池来源、筛选条件和筛选结果
+-> 选择具体案例并记录入选理由
+-> 为每个案例记录背景数据和背景图片
+-> 按设计逐步执行关键判断或操作
+-> 每一步记录规则、触发条件、数据路径、图片路径和结论
+-> 记录最终结果、异常、偏离和复盘结论
+-> 生成结果包 / 证据包
+-> 回写案例执行日志、案例总纲和案例分析设计
+-> 提交执行审核
+```
+
+执行流程的重点是证明“确实按设计做了”，不是只输出最终 summary。对交易、图形、流程操作类案例，关键判断点应尽量有图片或可视化支撑；没有图片时，必须有可复核的数据路径和计算说明。
+
+## 4. 全流程留痕原则
+
+案例分析必须尽量做到“人能沿着证据链重走一遍”。
+
+关键留痕点：
+
+1. 起因：为什么要分析这批案例。
+2. 方法论来源：使用了哪个笔记、规则、文档或上游结论。
+3. 候选池：候选案例从哪里来，怎么筛出来。
+4. 具体案例：每个案例的 ID、主体、日期/阶段、背景。
+5. 关键判断：每一步判断对应什么规则。
+6. 关键证据：每一步判断对应的数据、图片、文本或表格路径。
+7. 操作过程：如果案例包含操作，必须记录操作时间、触发条件、数量或动作。
+8. 结果：最终收益、成败、分类、误判、异常或复盘结论。
+9. 审计：审核员如何复核，发现什么问题。
+
+## 5. 图片和可视化原则
+
+案例分析如果涉及图形、时间序列、交易、过程状态或行为路径，应优先提供图片或可视化证据。
+
+图片不是装饰，而是帮助人快速复核。
+
+图片应尽量标注：
+
+1. 案例 ID。
+2. 关键日期或时间。
+3. 触发规则。
+4. 买入、卖出、开始、结束、异常点等关键动作。
+5. 对照基准或背景。
+
+如果没有图片，也必须说明用什么数据证据替代。
+
+## 6. 交易 / 策略类案例的特殊要求
+
+如果案例是交易或策略类，必须至少记录：
+
+1. 候选日。
+2. 候选池。
+3. 入选原因。
+4. 买入触发条件。
+5. 买入时间和价格。
+6. 卖出触发条件。
+7. 卖出时间和价格。
+8. 持仓变化。
+9. 单案例账户或等价流水。
+10. 最终收益和风险。
+
+审核员不能只看结果表，应按规则人工复核关键买点和卖点是否真的触发。
+
+是否需要防未来函数，按案例目标判断。如果案例目标是理解历史形态，可以不要求实盘级防未来；如果案例目标是验证可交易收益或实时决策，必须检查未来函数。
+
+## 7. 文档职责
+
+案例总纲：
+
+记录所有案例分析事项的背景、目标、方法论来源、状态和当前结论。
+
+案例分析设计：
+
+记录案例选择口径、分析流程、证据要求、执行步骤和验收方式。
+
+案例执行日志：
+
+记录每个案例的实际分析过程、关键节点、数据路径、图片路径、结果和偏离。
+
+案例审计报告：
+
+记录设计审核、执行审核、复审结果，以及审核员发现的问题、证据、影响、修复建议和复审要求。
+
+案例问题记录：
+
+记录非审计来源的案例选择、数据、证据链、判断、结论问题；对需要跨轮跟踪的审计问题只记录索引或关联。
+
+案例存储体系：
+
+记录案例数据、图片、结果包、账户表、过程表、索引表如何存放和读取。
+
+## 8. 不应过度加码
+
+以下内容通常不应阻断：
+
+1. 图片样式不够漂亮，但关键点可读。
+2. 字段命名不完全一致，但映射清楚。
+3. 非核心备注缺失。
+4. 不影响结论的格式问题。
+5. 案例暂时未工程化。
+
+以下内容应阻断：
+
+1. 案例目标和来源聊天记录不一致。
+2. 候选池口径和实际执行不一致。
+3. 关键买点、卖点、判断点没有证据。
+4. 结果和流水对不上。
+5. 用未来条件支持实时决策结论。
+6. 图片或数据路径缺失，导致无法复核关键结论。
+7. 结论超过案例证据。
+
+## 9. 完成标准
+
+一个案例分析事项完成，至少满足：
+
+1. 案例总纲有背景、目标、来源和当前结论。
+2. 案例分析设计通过审核。
+3. 案例执行日志记录关键过程。
+4. 结果包或证据包有入口。
+5. 关键数据和图片可读。
+6. 审计报告通过。
+7. 如有非审计问题，问题记录已关闭或明确暂缓；如有审计问题，审计报告已有复审结论或明确暂缓原因。
+
+## 10. 一句话
+
+案例分析体系的核心是：让 AI 像分析员一样把一件事按规则跑完整，并把每一步为什么这么做、证据在哪里、结果怎么来的都留下来。
diff --git "a/ana-doc/\346\241\210\344\276\213\345\210\206\346\236\220\350\256\276\350\256\241.md" "b/ana-doc/\346\241\210\344\276\213\345\210\206\346\236\220\350\256\276\350\256\241.md"
new file mode 100644
index 0000000..847a7bb
--- /dev/null
+++ "b/ana-doc/\346\241\210\344\276\213\345\210\206\346\236\220\350\256\276\350\256\241.md"
@@ -0,0 +1,84 @@
+# 案例分析设计
+
+创建人员：<创建人员>  
+文件职责：作为案例分析体系的项目级设计账本，记录案例选择口径、分析流程、证据要求、执行步骤和验收方式。  
+管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例分析设计模版.md。  
+引用文件：案例总纲.md；案例执行日志.md；案例审计报告.md；案例存储体系.md。  
+记录方式：append-only 案例分析设计；新增设计或修订追加到文件末尾。
+
+## 1. 当前设计总览
+
+| 设计 ID | 所属案例事项 | 目标 | 状态 | 设计审计 |
+|---|---|---|---|---|
+| <DESIGN-ID> | <ANA-ID> | <目标> | 未开始 | 未审计 |
+
+## 2. 设计记录模板
+
+### <YYYY-MM-DD HH:mm:ss> <DESIGN-ID>：<设计标题>
+
+所属案例事项：
+<ANA-ID / 名称>
+
+创建人员：
+<创建人员>
+
+来源聊天记录：
+```text
+<粘贴关键聊天记录，或写明案例总纲中的来源位置>
+```
+
+目标对齐说明：
+<说明本设计如何满足案例总纲目标；如有取舍，写明原因>
+
+案例选择口径：
+<候选案例从哪里来，如何筛选，为什么这些案例代表当前目标>
+
+分析对象：
+<股票 / 用户 / 模块 / 流程 / 事件 / 其他>
+
+全流程步骤：
+
+1. <候选来源与候选池生成>
+2. <具体案例选择>
+3. <关键判断或操作步骤>
+4. <结果记录>
+5. <复盘与结论>
+
+逐案例执行流程：
+```text
+<写清每个案例实际执行时的证据链顺序，例如：
+候选池记录 -> 入选理由 -> 背景数据/图片 -> 关键判断 1 -> 关键判断 2 -> 操作/标注 -> 结果复核 -> 结论回写>
+```
+
+执行流程冻结说明：
+<说明设计审核通过后，执行员必须按上述流程执行；如需偏离，必须记录偏离原因并进入复审>
+
+证据要求：
+
+1. <每个案例必须保留哪些数据>
+2. <每个案例必须保留哪些图片或可视化>
+3. <每个关键判断必须指向什么证据>
+
+图片要求：
+<如需要图片，说明每类图片要标注哪些关键点；如不需要，说明替代证据>
+
+数据输出：
+<case_index、case_step_trace、operation_ledger、image_manifest、summary 等>
+
+验收方式：
+<如何判断本设计执行成功；人工验收、审计通过、样本覆盖、图表齐全等>
+
+未来函数 / 泄漏判断：
+<本案例目标是否要求防未来函数；如果要求，写明检查方式；如果不要求，写明原因>
+
+设计审计状态：
+未审计 / 审计通过 / 审计不通过 / 暂缓
+
+设计审计入口：
+<案例审计报告.md 中 AUDIT-ID>
+
+执行日志入口：
+<案例执行日志.md 中 LOG-ID>
+
+当前结论：
+<当前设计是否可执行>
diff --git "a/ana-doc/\346\241\210\344\276\213\345\255\230\345\202\250\344\275\223\347\263\273.md" "b/ana-doc/\346\241\210\344\276\213\345\255\230\345\202\250\344\275\223\347\263\273.md"
new file mode 100644
index 0000000..81ed9f4
--- /dev/null
+++ "b/ana-doc/\346\241\210\344\276\213\345\255\230\345\202\250\344\275\223\347\263\273.md"
@@ -0,0 +1,135 @@
+# 案例存储体系创建指南
+
+创建人员：Codex  
+文件职责：指导项目内案例分析体系如何记录数据、图片、结果包、表结构和读取方式。  
+管理规范/模板：../../全局规范.md；../../体系说明.md；案例分析规范.md。  
+引用文件：案例分析环境创建指南.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md；案例审计报告模版.md。  
+记录方式：存储体系创建指南；案例数据存储口径变化时更新。
+
+## 1. 定位
+
+案例存储体系负责回答：
+
+1. 案例数据放在哪里。
+2. 图片和图册放在哪里。
+3. 每个表有哪些字段。
+4. 一个案例的证据链怎么串起来。
+5. 审核员怎么找到并复核关键数据。
+
+## 2. 推荐目录
+
+```text
+ana-data/
+  cases/
+    <CASE-ID>/
+      data/
+      img/
+      notes/
+  result/
+    <PACK-ID>/
+  img/
+    individual/
+    by_type/
+  tmp/
+```
+
+## 3. 核心表
+
+建议至少维护以下表，字段可按项目扩展。
+
+路径口径：表内 `input_path`、`output_path`、`image_path`、`evidence_pack_path` 等路径默认使用项目根目录相对路径，例如 `ana-data/result/<PACK-ID>/case_index.csv`。如果项目另有路径基准，必须在本地 `案例存储体系.md` 写清楚，避免审核员按不同目录解析路径。
+
+### 3.1 case_index.csv
+
+| 字段 | 含义 |
+|---|---|
+| case_id | 案例唯一 ID |
+| case_name | 案例名称 |
+| case_type | 案例类型 |
+| source_id | 来源方法论、笔记、样本或聊天要求 ID |
+| target_object | 分析对象，如股票、用户、模块、流程等 |
+| anchor_date_or_time | 案例关键锚点日期或时间 |
+| status | 未开始 / 进行中 / 待审核 / 完成 / 暂缓 |
+| result_summary | 当前结果摘要 |
+| evidence_pack_path | 证据包路径 |
+| audit_id | 审计报告 ID |
+
+### 3.2 case_step_trace.csv
+
+| 字段 | 含义 |
+|---|---|
+| trace_id | 步骤证据 ID |
+| case_id | 所属案例 |
+| step_order | 步骤顺序 |
+| step_name | 步骤名 |
+| rule_or_reason | 使用的规则或判断原因 |
+| input_path | 输入数据路径 |
+| output_path | 输出数据路径 |
+| image_path | 图片证据路径 |
+| decision | 本步骤判断或动作 |
+| reviewer_note | 审核备注 |
+
+### 3.3 operation_ledger.csv
+
+如果案例包含操作或交易，建议维护操作流水。
+
+| 字段 | 含义 |
+|---|---|
+| operation_id | 操作 ID |
+| case_id | 所属案例 |
+| operation_time | 操作时间 |
+| operation_type | 买入 / 卖出 / 选择 / 排除 / 标记 / 其他 |
+| trigger_rule | 触发规则 |
+| trigger_evidence_path | 触发证据 |
+| quantity | 数量，可为空 |
+| price_or_value | 价格或数值，可为空 |
+| result | 操作结果 |
+
+### 3.4 image_manifest.csv
+
+| 字段 | 含义 |
+|---|---|
+| image_id | 图片 ID |
+| case_id | 所属案例 |
+| image_type | 候选图 / 操作图 / 结果图 / 汇总图 / 审计图 |
+| image_path | 图片路径 |
+| marked_points | 图上标注的关键点 |
+| source_data_path | 生成图片的数据 |
+| generated_by | 生成者 |
+| generated_at | 生成时间 |
+
+## 4. 图片要求
+
+图片必须服务复核。
+
+建议至少包含：
+
+1. 候选阶段图：说明为什么案例进入候选。
+2. 关键判断图：说明哪里满足规则。
+3. 操作阶段图：说明何时买入、卖出、进入、退出或标记。
+4. 结果图：说明最终走势、效果或失败点。
+
+如果项目不涉及图片，应在存储体系中说明替代证据。
+
+## 5. 结果包要求
+
+每个正式结果包至少包含：
+
+1. 主表。
+2. case_index。
+3. case_step_trace。
+4. image_manifest，如有图片。
+5. summary。
+6. readout 或说明文档。
+
+结果包入口必须回写到案例总纲、案例分析设计和案例执行日志；审计结论回写到案例审计报告。
+
+## 6. 禁止事项
+
+禁止：
+
+1. 只有 summary，没有案例级明细。
+2. 图片存在但没有 manifest。
+3. 操作流水没有触发证据。
+4. 证据路径指向临时目录但当作正式证据。
+5. 结果包没有回写入口。
diff --git "a/ana-doc/\346\241\210\344\276\213\345\256\241\346\240\270\350\247\204\350\214\203.md" "b/ana-doc/\346\241\210\344\276\213\345\256\241\346\240\270\350\247\204\350\214\203.md"
new file mode 100644
index 0000000..c7091d6
--- /dev/null
+++ "b/ana-doc/\346\241\210\344\276\213\345\256\241\346\240\270\350\247\204\350\214\203.md"
@@ -0,0 +1,137 @@
+# 案例审核规范
+
+创建人员：Codex  
+文件职责：定义案例分析体系的审核范围、审核流程、设计审核、执行审核、证据链审核和问题阻断标准。  
+管理规范/模板：../../全局规范.md；../../体系说明.md；案例分析规范.md。  
+引用文件：案例审计报告模版.md；案例问题记录模版.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md。  
+记录方式：案例审核规范；案例审核口径变化时更新。
+
+统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地案例审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。
+
+## 1. 审核定位
+
+案例审核检查案例分析是否真的按目标和设计完成。
+
+审核重点是：
+
+1. 设计是否能满足目标。
+2. 执行是否按设计走。
+3. 每个关键判断是否有证据。
+4. 结果是否和过程、数据、图片一致。
+5. 结论是否过读。
+
+## 2. 设计审核
+
+设计审核在正式执行前进行。
+
+必须检查：
+
+1. 案例总纲是否记录来源聊天和上游依据。
+2. 案例目标是否清楚。
+3. 案例选择口径是否能满足目标。
+4. 全流程步骤是否覆盖从候选到结论。
+5. 证据要求是否足够支撑复核。
+6. 是否说明是否需要防未来函数或等价泄漏检查。
+7. 验收方式是否明确。
+
+设计审核不通过，不得进入正式执行。
+
+如果案例事项使用项目本地案例流程，设计审核必须先判断本地流程是否满足 common 案例体系硬约束。新增流程重点检查输入输出、证据链和审核点；修改默认流程重点检查覆盖范围、替换原因、关键证据链和结论边界，且不得削弱来源追踪、案例选择口径、关键证据、审计闭环和不过读要求。
+
+本地流程通过设计审核后，执行审核以该本地流程为准；审核员不得用 common 默认步骤重复卡已被本地流程合法替换的细节。
+
+## 3. 执行审核
+
+执行审核在案例执行后进行。
+
+必须检查：
+
+1. 执行是否按设计进行。
+2. 候选来源和候选池是否对得上。
+3. 具体案例是否来自设计约定范围。
+4. 每个关键判断是否有数据或图片证据。
+5. 如果有操作，操作触发条件是否真的成立。
+6. 结果表、流水、图片、summary 是否互相一致。
+7. 关键路径是否可读、无乱码、非临时伪正式产物。
+8. 结论是否没有超过证据。
+
+执行审核不通过，不得把案例事项标记为完成。
+
+## 4. 交易 / 策略类案例审核
+
+如果案例包含交易、买卖或收益结论，审核员必须额外检查：
+
+1. 候选日是否正确。
+2. 候选池是否按设计生成。
+3. 入选原因是否有图或数据证据。
+4. 买入点是否满足买入规则。
+5. 卖出点是否满足卖出规则。
+6. 账户流水是否能解释持仓和收益。
+7. 如果目标是收益验证，是否存在未来函数或数据泄漏。
+
+审核员不能只看 summary，应抽查或全查关键买卖点。
+
+## 5. 不应阻断的问题
+
+以下问题一般不阻断：
+
+1. 图片样式一般但关键点可读。
+2. 字段名不完全一致但映射清楚。
+3. 不影响结论的备注缺失。
+4. 非关键案例的轻微说明不足。
+5. 后续工程化尚未开始。
+
+## 6. 必须阻断的问题
+
+以下问题必须阻断：
+
+1. 设计目标和来源聊天不一致。
+2. 执行没有按设计走，且未说明偏离。
+3. 候选池和案例选择口径不一致。
+4. 关键判断缺证据。
+5. 图片或数据路径缺失导致无法复核。
+6. 操作流水和结果不一致。
+7. 使用未来信息支持实时决策或收益结论。
+8. 结论明显过读。
+
+## 7. 审核输出
+
+审核结果写入 `案例审计报告.md`。
+
+审核员发现的问题，主记录写入 `案例审计报告.md`。
+
+如果案例分析事项包含案例分析开发，案例分析开发的方案审核、实现审核、测试验收和复审结论也统一写入 `ana-doc/案例审计报告.md`，不另写到 `dev-doc/开发审计报告.md`。
+
+案例分析开发中的临时草稿脚本可以不做独立代码审核；但只要代码用于生成正式案例结论、案例筛选、图表证据、账户流水、验收包、结果包、审计辅助报告或可复用工具，就必须纳入案例审核。审核重点不是把轻量脚本套成重型开发流程，而是确认案例证据可信：
+
+1. 输入案例、样本范围、过滤条件是否和案例设计一致。
+2. 输出图片、表格、流水、summary、manifest 或等价结果包是否能和案例执行日志对上。
+3. 候选、入选、买入、卖出、退出、结论标签是否和案例规则一致。
+4. 代码是否改写原始证据、污染正式数据或覆盖不可变结果。
+5. 至少抽查关键案例，必要时人工复算 1-3 个操作点或关键行。
+6. 是否需要防未来函数或数据泄漏必须按案例目标判断；涉及交易、买卖、收益验证、实时判断或自动动作时必须检查，后验理解、图形归纳、案例复盘、方法论总结类案例可以不作为实盘时点安全审核，但结论必须降读。
+
+只有问题需要跨轮跟踪、跨案例汇总或由案例分析员长期处理时，才在 `案例问题记录.md` 中建立索引或关联，不重复全文。
+
+审核报告至少包含：
+
+1. 审核 ID。
+2. 审核类型：设计审核 / 执行审核 / 复审。
+3. 审核对象。
+4. 审核依据。
+5. 检查结果。
+6. 问题清单。
+7. 结论：通过 / 不通过 / 暂缓。
+8. 是否允许进入下一阶段。
+
+## 8. 审核边界
+
+审核员可以运行只读检查脚本、打开图片、读取表格、人工计算关键触发点。
+
+审核员可以维护项目本地 `案例审核规范.md`，仅限修正案例审核流程、审计口径和阻断标准；不得借此修改被审的案例分析规范、案例设计、执行日志、结果包或主产物。
+
+审核员不得直接改被审计主产物来掩盖问题。
+
+如确需修改案例分析执行规范，应创建规范维护事项，或额外授予案例体系维护 / 规范维护角色，并记录原因、影响范围和复审入口。
+
+审核员应抓真问题，不把边角料升级成阻断。
diff --git "a/ana-doc/\346\241\210\344\276\213\345\256\241\350\256\241\346\212\245\345\221\212.md" "b/ana-doc/\346\241\210\344\276\213\345\256\241\350\256\241\346\212\245\345\221\212.md"
new file mode 100644
index 0000000..83250df
--- /dev/null
+++ "b/ana-doc/\346\241\210\344\276\213\345\256\241\350\256\241\346\212\245\345\221\212.md"
@@ -0,0 +1,76 @@
+# 案例审计报告
+
+创建人员：<创建人员>  
+文件职责：作为案例分析体系的项目级审计账本，记录案例设计审核、执行审核、复审结果和问题清单。  
+管理规范/模板：../../全局规范.md；../../common/ana-doc/案例审核规范.md；../../common/ana-doc/案例审计报告模版.md。  
+引用文件：案例总纲.md；案例分析设计.md；案例执行日志.md；案例问题记录.md；案例存储体系.md。  
+记录方式：append-only 案例审计报告；每次设计审核、执行审核和复审追加到文件末尾。
+
+固定口径：案例审核员发现的问题完整记录在本文；只有需要跨轮跟踪、跨案例汇总或长期处理时，才在 `案例问题记录.md` 中建立索引，不重复全文。
+
+## 1. 当前审计总览
+
+| 审计 ID | 审计对象 | 审计类型 | 审核员 | 结论 | 时间 |
+|---|---|---|---|---|---|
+| <AUDIT-ID> | <对象> | 设计审核 / 执行审核 / 复审 | <审核员> | 待审计 | <YYYY-MM-DD HH:mm:ss> |
+
+## 2. 审计记录模板
+
+### <YYYY-MM-DD HH:mm:ss> <AUDIT-ID>：<审计标题>
+
+审计对象：
+<ANA-ID / DESIGN-ID / LOG-ID / PACK-ID>
+
+审计类型：
+设计审核 / 执行审核 / 复审
+
+审核员：
+<审核员>
+
+来源聊天记录 / 上游依据：
+<粘贴关键聊天记录，或写明案例总纲、上游文档、聊天记录路径>
+
+依据文档：
+
+1. `../../全局规范.md`
+2. `../../common/ana-doc/案例分析规范.md`
+3. `../../common/ana-doc/案例审核规范.md`
+4. `案例总纲.md`
+5. `案例分析设计.md`
+6. `案例执行日志.md`
+
+检查结果：
+
+| 检查项 | 结果 | 说明 |
+|---|---|---|
+| 来源聊天记录已进入总纲 | PASS / FAIL / N/A |  |
+| 设计目标对齐来源要求 | PASS / FAIL / N/A |  |
+| 案例选择口径合理 | PASS / FAIL / N/A |  |
+| 全流程步骤覆盖候选到结论 | PASS / FAIL / N/A |  |
+| 执行按设计进行 | PASS / FAIL / N/A |  |
+| 候选来源和候选池可追踪 | PASS / FAIL / N/A |  |
+| 关键判断有证据 | PASS / FAIL / N/A |  |
+| 图片或替代证据可读 | PASS / FAIL / N/A |  |
+| 操作流水和结果一致 | PASS / FAIL / N/A |  |
+| 未来函数 / 泄漏检查符合目标 | PASS / FAIL / N/A |  |
+| 结论没有过读 | PASS / FAIL / N/A |  |
+| 证据链可追踪 | PASS / FAIL / N/A |  |
+
+发现问题：
+
+1. <如无写“无”>
+
+审计结论：
+通过 / 不通过 / 暂缓
+
+是否阻断：
+是 / 否
+
+是否允许进入下一阶段：
+是 / 否
+
+建议动作：
+<下一步>
+
+复审要求：
+<是否需要复审>
diff --git "a/ana-doc/\346\241\210\344\276\213\346\200\273\347\272\262.md" "b/ana-doc/\346\241\210\344\276\213\346\200\273\347\272\262.md"
new file mode 100644
index 0000000..98c4c37
--- /dev/null
+++ "b/ana-doc/\346\241\210\344\276\213\346\200\273\347\272\262.md"
@@ -0,0 +1,61 @@
+# 案例总纲
+
+创建人员：<创建人员>  
+文件职责：作为案例分析体系的项目级滚动账本，记录所有案例分析事项的背景、目标、方法论来源、状态和当前结论。  
+管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例总纲模版.md。  
+引用文件：案例分析规范.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；案例存储体系.md。  
+记录方式：append-only 案例总纲；新增案例分析事项、阶段结论和最终结论追加到文件末尾。
+
+## 1. 当前案例分析总览
+
+| 案例事项 ID | 名称 | 来源 | 目标 | 状态 | 当前结论 | 审计状态 |
+|---|---|---|---|---|---|---|
+| <ANA-ID> | <名称> | <来源聊天 / 方法论 / 样本> | <目标> | 未开始 | 待分析 | 未审计 |
+
+## 2. 记录模板
+
+### <YYYY-MM-DD HH:mm:ss> <ANA-ID>：<案例分析事项名称>
+
+创建人员：
+<创建人员>
+
+来源聊天记录：
+```text
+<粘贴关键聊天记录，或写明聊天记录路径>
+```
+
+方法论 / 上游依据：
+<笔记、规则、文档、样本包、上游结论>
+
+背景：
+<为什么要做这批案例分析>
+
+目标：
+<希望通过案例分析验证、理解或沉淀什么>
+
+边界：
+<本轮做什么，不做什么>
+
+案例范围：
+<案例类型、时间范围、样本范围、对象范围>
+
+当前状态：
+未开始 / 进行中 / 待审核 / 完成 / 暂缓 / 取消
+
+当前结论：
+<当前可读结论；没有结论时写“暂无”>
+
+设计入口：
+<案例分析设计.md 中 DESIGN-ID>
+
+执行日志入口：
+<案例执行日志.md 中 LOG-ID / CASE-ID>
+
+结果包入口：
+<ana-data/result/...>
+
+审计入口：
+<案例审计报告.md 中 AUDIT-ID>
+
+非审计问题 / 审计问题索引入口：
+<案例问题记录.md 中 ISSUE-ID；如无写“无”>
diff --git "a/ana-doc/\346\241\210\344\276\213\346\211\247\350\241\214\346\227\245\345\277\227.md" "b/ana-doc/\346\241\210\344\276\213\346\211\247\350\241\214\346\227\245\345\277\227.md"
new file mode 100644
index 0000000..4e78433
--- /dev/null
+++ "b/ana-doc/\346\241\210\344\276\213\346\211\247\350\241\214\346\227\245\345\277\227.md"
@@ -0,0 +1,71 @@
+# 案例执行日志
+
+创建人员：<创建人员>  
+文件职责：作为案例分析体系的项目级执行账本，记录案例分析实际执行过程、关键节点、数据路径、图片路径、结果和偏离。  
+管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例执行日志模版.md。  
+引用文件：案例总纲.md；案例分析设计.md；案例审计报告.md；案例问题记录.md；案例存储体系.md。  
+记录方式：append-only 案例执行日志；每次执行、重跑、修复和结果包生成追加到文件末尾。
+
+## 1. 当前执行总览
+
+| 日志 ID | 所属设计 | 案例范围 | 状态 | 结果包 | 审计 |
+|---|---|---|---|---|---|
+| <LOG-ID> | <DESIGN-ID> | <范围> | 未开始 |  | 未审计 |
+
+## 2. 执行记录模板
+
+### <YYYY-MM-DD HH:mm:ss> <LOG-ID>：<执行标题>
+
+所属案例事项：
+<ANA-ID>
+
+关联设计：
+<DESIGN-ID>
+
+执行人员：
+<执行人员>
+
+执行目标：
+<本次执行要完成什么>
+
+输入：
+<方法论文档、候选池、数据源、图片源、上游结果>
+
+执行过程：
+
+1. <关键步骤 1>
+2. <关键步骤 2>
+
+关键节点记录：
+
+| 节点 | 说明 | 数据路径 | 图片路径 | 结论 |
+|---|---|---|---|---|
+| 候选来源 | <如何得到候选> | <path> | <path> | <结论> |
+| 案例选择 | <为什么选这些案例> | <path> | <path> | <结论> |
+| 关键判断 | <按什么规则判断> | <path> | <path> | <结论> |
+| 操作 / 动作 | <如有买卖、标记、排除等动作> | <path> | <path> | <结论> |
+| 结果复盘 | <最终结果> | <path> | <path> | <结论> |
+
+逐案例证据链记录：
+
+| 案例 ID | 候选来源 | 入选理由 | 背景证据 | 关键判断 / 操作 | 数据路径 | 图片路径 | 结果 | 是否符合设计 |
+|---|---|---|---|---|---|---|---|---|
+| <CASE-ID> | <候选池或上游来源> | <为什么选中> | <背景数据或背景图> | <按设计逐步记录关键判断或操作> | <path> | <path> | <结果> | 是 / 否；如否说明偏离 |
+
+输出：
+<结果包、表、图片、readout、summary>
+
+偏离设计：
+<如无写“无”；如有，说明原因和影响>
+
+自检结果：
+<文件是否存在、行数是否合理、图片是否可读、关键证据是否齐全>
+
+执行结果 / 结论回写：
+<本次执行最终结果；如影响案例总纲或设计，写明已回写位置或待回写原因>
+
+当前状态：
+完成 / 部分完成 / 失败 / 暂缓
+
+审计入口：
+<案例审计报告.md 中 AUDIT-ID>
diff --git "a/ana-doc/\346\241\210\344\276\213\351\227\256\351\242\230\350\256\260\345\275\225.md" "b/ana-doc/\346\241\210\344\276\213\351\227\256\351\242\230\350\256\260\345\275\225.md"
new file mode 100644
index 0000000..e536eba
--- /dev/null
+++ "b/ana-doc/\346\241\210\344\276\213\351\227\256\351\242\230\350\256\260\345\275\225.md"
@@ -0,0 +1,58 @@
+# 案例问题记录
+
+创建人员：<创建人员>  
+文件职责：作为案例分析体系的问题闭环账本，记录非审计来源的案例设计、执行、数据、证据链问题；对需要跨轮跟踪的审计问题只记录索引或关联。  
+管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例问题记录模版.md。  
+引用文件：案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例存储体系.md。  
+记录方式：append-only 案例问题记录；新问题、修复、复审和关闭追加到文件末尾。
+
+口径说明：审核员在设计审核、执行审核和复审中发现的问题，主记录写入 `案例审计报告.md`；本文件只在需要跨轮跟踪时记录审计问题索引。案例分析员、执行者、人工同事或其他非审计角色发现的问题，主记录写入本文件。
+
+## 1. 当前问题总览
+
+| 问题 ID | 所属案例 | 类型 | 严重级别 | 状态 | 责任方 |
+|---|---|---|---|---|---|
+| <ISSUE-ID> | <ANA-ID / CASE-ID> | <类型> | P0 / P1 / P2 / P3 | 未处理 | <责任方> |
+
+## 2. 问题记录模板
+
+### <YYYY-MM-DD HH:mm:ss> <ISSUE-ID>：<问题标题>
+
+所属案例事项：
+<ANA-ID / CASE-ID / DESIGN-ID / LOG-ID>
+
+问题类型：
+设计问题 / 执行问题 / 数据问题 / 图片问题 / 证据链问题 / 结论过读 / 未来函数 / 待归因
+
+严重级别：
+P0 阻断 / P1 重要 / P2 一般 / P3 建议
+
+发现人：
+<发现人>
+
+来源类型：
+非审计反馈 / 审计问题索引
+
+关联审计：
+<案例审计报告.md 中 AUDIT-ID；非审计反馈可写无>
+
+证据：
+<文件、表、图片、日志路径，或粘贴关键片段>
+
+问题描述：
+<问题是什么>
+
+影响：
+<影响案例结论、流程、证据链、可复核性还是只是建议>
+
+建议修复：
+<建议怎么修，不要无边界加码>
+
+当前状态：
+未处理 / 修复中 / 待复审 / 已关闭 / 暂缓
+
+复审结论：
+<复审结果；未复审写“待复审”>
+
+关闭条件：
+<什么条件下可以关闭>
diff --git "a/ana-doc/\347\233\256\345\275\225\345\257\274\350\257\273.md" "b/ana-doc/\347\233\256\345\275\225\345\257\274\350\257\273.md"
new file mode 100644
index 0000000..19bf09a
--- /dev/null
+++ "b/ana-doc/\347\233\256\345\275\225\345\257\274\350\257\273.md"
@@ -0,0 +1,49 @@
+# ana-doc 目录导读
+
+创建人员：Codex  
+文件职责：说明 `common/ana-doc` 目录下案例分析体系规范、创建指南、模板和审计文档的用途。  
+管理规范/模板：../../全局规范.md；../../体系说明.md；案例分析规范.md。  
+引用文件：案例分析规范.md；案例分析环境创建指南.md；本目录下全部 `*模版.md` 和 `*指南.md` 文件。  
+记录方式：目录入口文档；新增或删除本目录正式文档时同步更新。
+
+## 1. 目录定位
+
+本目录保存通用案例分析体系。
+
+案例分析体系负责管理“基于规则、方法论、笔记、现象或样本，对具体案例做全流程复盘和证据链分析”的事项。
+
+它强调：
+
+1. 起因和原始要求必须留痕。
+2. 案例选择、判断、操作、结果必须能追踪。
+3. 关键步骤要有数据或图片证据。
+4. 审核员能按证据链复核每一步是否对得上。
+
+## 2. 文件清单
+
+| 文件 | 类型 | 作用 |
+|---|---|---|
+| 案例分析规范.md | 全局规范 | 定义案例分析体系定位、流程、证据链、边界和问题闭环 |
+| 案例分析环境创建指南.md | 创建指南 | 指导项目管理员在项目内创建案例分析环境 |
+| 案例存储体系创建指南.md | 创建指南 | 指导案例数据、图片、账户/过程表、结果包如何存储和索引 |
+| 案例总纲模版.md | 模板 | 创建项目级案例总账本，记录案例背景、目标、方法论来源和当前结论 |
+| 案例分析设计模版.md | 模板 | 创建项目级案例分析设计账本，记录案例选择口径、全流程步骤和验收方式 |
+| 案例执行日志模版.md | 模板 | 创建项目级案例执行日志，记录每个案例关键节点、数据和结果 |
+| 案例审核规范.md | 审核规范 | 定义案例设计审核、执行审核、证据链审核和阻断标准 |
+| 案例审计报告模版.md | 模板 | 创建项目级案例审计报告，记录审核结果、问题和是否通过 |
+| 案例问题记录模版.md | 模板 | 创建非审计来源案例问题闭环账本；审计问题只做索引 |
+
+## 3. 推荐使用顺序
+
+项目启用案例分析体系时：
+
+1. 先读 `../../全局规范.md`。
+2. 再读 `../../体系说明.md`。
+3. 读 `案例分析规范.md`。
+4. 按 `案例分析环境创建指南.md` 创建项目内 `ana-doc/`、`ana-data/` 和本地规范。
+5. 如案例涉及图片、表格、交易流水、过程数据，按 `案例存储体系创建指南.md` 创建存储结构。
+6. 用模板创建案例总纲、案例分析设计、案例执行日志、案例审计报告和案例问题记录。
+7. 每个案例按设计执行并写执行日志。
+8. 审核员按 `案例审核规范.md` 做设计审核和执行审核。
+
+所有案例分析文档默认采用 append-only 方式维护：最新案例、执行、审计和问题记录追加到对应文件末尾。审核员发现的问题主记录写入案例审计报告；案例问题记录只承接非审计问题或审计问题索引。
diff --git a/exp-data/img/.gitkeep b/exp-data/img/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/exp-data/img/.gitkeep
@@ -0,0 +1 @@
+
diff --git a/exp-data/raw/.gitkeep b/exp-data/raw/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/exp-data/raw/.gitkeep
@@ -0,0 +1 @@
+
diff --git a/exp-data/result/.gitkeep b/exp-data/result/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/exp-data/result/.gitkeep
@@ -0,0 +1 @@
+
diff --git a/exp-data/tmp/.gitkeep b/exp-data/tmp/.gitkeep
new file mode 100644
index 0000000..8b13789
--- /dev/null
+++ b/exp-data/tmp/.gitkeep
@@ -0,0 +1 @@
+
diff --git "a/exp-doc/\345\256\236\351\252\214\345\255\230\345\202\250\344\275\223\347\263\273.md" "b/exp-doc/\345\256\236\351\252\214\345\255\230\345\202\250\344\275\223\347\263\273.md"
new file mode 100644
index 0000000..e8f075d
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\345\255\230\345\202\250\344\275\223\347\263\273.md"
@@ -0,0 +1,254 @@
+# 实验存储体系创建指南
+
+创建人员：Codex  
+文件职责：指导 AI 在具体项目中创建实验体系的数据存储文档、数据目录、表 schema、读取方式和结果包组织方式。  
+管理规范/模板：common/exp-doc/实验规范.md；本文件是创建指南，不是单次实验模板。  
+引用文件：../../管理系统说明.md；实验规范.md；实验环境创建指南.md。
+
+## 1. 定位
+
+本指南用于回答：
+
+```text
+当一个项目启用实验体系时，实验数据应该放哪里、怎么存、怎么读、怎么追踪、表 schema 怎么写。
+```
+
+项目内应创建一个 `exp-doc/实验存储体系.md`。
+
+`实验存储体系.md` 不是单次实验归档表，而是该项目实验数据的长期存储合同。
+
+创建项目级存储体系时，不得复制其他项目的专有路径、业务名词、历史实验名或旧数据口径。示例表名、字段名和对象名必须改成当前项目可解释的中性名称。
+
+## 2. 项目目录要求
+
+项目启用实验体系时，至少应创建：
+
+```text
+<project>/
+  exp-doc/
+    目录导读.md
+    实验规范.md
+    实验审计规范.md
+    实验存储体系.md
+    实验审计报告.md
+    实验问题记录.md
+    实验总纲.md
+    实验设计.md
+    实验执行日志.md
+  exp-data/
+    result/
+    img/
+    raw/
+    tmp/
+```
+
+目录职责：
+
+| 目录 | 作用 |
+|---|---|
+| `exp-doc/` | 存实验文档、实验总纲、实验设计、审计报告、项目实验存储体系 |
+| `exp-data/result/` | 存每次实验结果包，建议按 `run_id` 分目录 |
+| `exp-data/img/` | 存图片、图表、业务图、人工验收图等可视化资产 |
+| `exp-data/raw/` | 存原始输入快照、外部下载文件、原始响应、人工原始回执 |
+| `exp-data/tmp/` | 存临时中间文件；不可作为正式结论入口 |
+
+如果项目已有数据库，结构化数据优先进入数据库；文件系统保留原始证据、快照、图表和可读结果包。
+
+## 3. 实验存储体系文档必须包含什么
+
+项目内的 `exp-doc/实验存储体系.md` 至少应包含：
+
+1. 数据存储目标和范围。
+2. 目录结构说明。
+3. 数据流说明。
+4. 结果包组织规则。
+5. 图片和图表存储规则。
+6. 表清单。
+7. 每张表的 schema，精确到字段。
+8. 主键、唯一键、去重和版本规则。
+9. 数据读取方式。
+10. 临时数据和正式数据边界。
+11. 审计和复核入口。
+
+## 4. 数据流规则
+
+推荐数据流：
+
+```text
+raw source
+-> cleaned/input snapshot
+-> experiment intermediate
+-> result package
+-> structured table / database
+-> audit/readout
+```
+
+每一层都要能追溯：
+
+1. 来自哪个实验。
+2. 来自哪个 run。
+3. 来自哪个 source snapshot。
+4. 由哪个脚本、AI 或人工步骤产生。
+5. 后续应该怎么读。
+
+## 5. 结果包规则
+
+结果包建议路径：
+
+```text
+exp-data/result/<run_id>/
+```
+
+每个结果包至少应包含：
+
+| 文件 | 作用 |
+|---|---|
+| `summary.json` 或 `summary.md` | 记录关键结论、关键计数、状态 |
+| `output_manifest.csv/json` | 记录结果包内所有资产路径、类型、行数、hash |
+| `readout.md` | 可选，人读版结论和边界 |
+| `input_manifest.csv/json` | 可选，记录输入快照 |
+| `schema_or_contract_reference` | 可写在 manifest 字段里，指向 schema 文档 |
+
+结果包入口应回写到实验总纲和实验设计。
+
+结果包内部资产清单应能被 `实验存储体系.md` 中的表清单或 manifest 解释。
+
+## 6. 图片和图表存储规则
+
+图片建议路径：
+
+```text
+exp-data/img/<experiment_id>/<run_id>/
+```
+
+图片文件名应尽量包含：
+
+1. 样本 ID。
+2. 标的或对象 ID。
+3. 日期或窗口。
+4. 图类型。
+
+例如：
+
+```text
+CASE001_OBJECT001_2024-01-05_event_review.png
+```
+
+图片必须能从表或 manifest 反查：
+
+1. 这张图对应哪个样本。
+2. 这张图用于证明什么。
+3. 这张图由哪个 run 生成。
+4. 这张图是否进入人工验收。
+
+## 7. 表清单要求
+
+`实验存储体系.md` 必须有表清单。
+
+表清单建议字段：
+
+| 字段 | 说明 |
+|---|---|
+| table_name | 表名或文件名 |
+| storage_backend | `mysql/csv/json/sqlite/parquet/image/other` |
+| storage_path_or_table | 文件路径或数据库表名 |
+| table_role | `raw/input/intermediate/output/audit/manifest/index` |
+| row_grain | 一行代表什么 |
+| primary_key | 主键 |
+| unique_key | 唯一约束 |
+| producer | 生产者 |
+| consumer | 消费者 |
+| update_mode | `append/upsert/overwrite_snapshot/manual` |
+| official_flag | 是否正式数据 |
+| retention_policy | 保留策略 |
+
+## 8. schema 字段要求
+
+每张结构化表必须写字段级 schema。
+
+字段 schema 至少包含：
+
+| 字段 | 说明 |
+|---|---|
+| field_name | 字段名 |
+| data_type | 类型 |
+| required | 是否必填 |
+| nullable | 是否允许空 |
+| enum_values | 枚举值，如无则为空 |
+| meaning | 字段含义 |
+| source | 字段来源 |
+| time_semantics | 时间口径，如 as-of、event-time、generated-time |
+| example | 示例 |
+| notes | 注意事项 |
+
+涉及时序决策、事件、时间窗口、外部信息时，必须写清时间口径，避免把未来可见信息当成当时可见信息。
+
+## 9. ID 和追踪字段
+
+推荐所有核心表保留以下追踪字段：
+
+```text
+experiment_id
+run_id
+step_id
+artifact_id
+source_snapshot_id
+producer
+produced_at
+record_hash
+source_file_path
+source_file_sha256
+```
+
+原则：
+
+1. 不要用 `run_id` 当业务主键。
+2. 不要用中文标题、display name、人工摘要当唯一键。
+3. 同一对象多轮实验不得随意生成不同业务 ID。
+4. 新结论不得覆盖旧结论，应用版本、状态或 run 记录留痕。
+
+## 10. 数据读取方式
+
+`实验存储体系.md` 必须说明人和 AI 如何读取数据。
+
+至少写清：
+
+1. 人优先看哪些文档。
+2. AI 优先读哪些 manifest 或表。
+3. 结果包从哪里进入。
+4. 图片从哪里进入。
+5. 数据库表怎么查询。
+6. 单个样本如何从结果表追到原始证据。
+
+推荐读取路径：
+
+```text
+实验总纲
+-> 实验设计
+-> 结果包入口
+-> output_manifest
+-> schema/table registry
+-> 具体数据表或图片
+-> 审计报告
+```
+
+## 11. 临时数据和正式数据边界
+
+`tmp/` 只放临时文件。
+
+临时文件不能作为正式结论入口。
+
+如果临时结果要进入结论，必须移动到正式结果包或数据库，并在 manifest/schema 中登记。
+
+## 12. 审计要求
+
+实验存储体系审计重点：
+
+1. 结果包能否找到。
+2. 关键数据是否能追到来源。
+3. 表 schema 是否写到字段级。
+4. 图片是否能从样本或结果表反查。
+5. 临时数据是否被误当正式结果。
+6. 时间口径是否清楚。
+
+审计不应把存储体系变成重型 gate。存储体系的目标是让人和 AI 能找到、读懂、复核数据，不是给主流程层层加码。
diff --git "a/exp-doc/\345\256\236\351\252\214\345\256\241\346\240\270\350\247\204\350\214\203.md" "b/exp-doc/\345\256\236\351\252\214\345\256\241\346\240\270\350\247\204\350\214\203.md"
new file mode 100644
index 0000000..f783d76
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\345\256\241\346\240\270\350\247\204\350\214\203.md"
@@ -0,0 +1,444 @@
+# 实验审核规范
+
+创建人员：Codex  
+文件职责：定义实验设计审核、实验执行审核、复审、问题归因、通过标准和审计报告记录规则。  
+管理规范/模板：common/exp-doc/实验规范.md；本文件是实验审核专用规范。  
+引用文件：../../管理系统说明.md；实验规范.md；实验总纲模版.md；实验设计模版.md；
+
+统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地实验审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。
+
+## 1. 定位
+
+实验审核是实验事项的质量关口。
+
+它不负责替执行者重新做实验，也不负责无边界地增加要求。
+
+它只回答：
+
+1. 实验目标是否清楚。
+2. 实验设计是否能满足目标。
+3. 实验是否按设计执行。
+4. 关键数据、代码、案例、产物是否对得上。
+5. 是否存在会影响结论的真 bug、样本污染、口径替换或结论过读。
+6. 如果实验目标要求时点安全，是否存在未来函数。
+7. 当前结论能不能成立，最多能读到什么程度。
+
+## 1A. 全局审核规范和项目本地审核规范
+
+`common/exp-doc/实验审核规范.md` 是全局通用审核规范。
+
+所有项目的审核员都必须遵守本文件。每个项目创建实验环境时都必须创建项目本地 `exp-doc/实验审计规范.md`。项目本地审计规范默认可以很短，只引用本文件并声明必须遵守；如果补充项目特化规则，不能违反本文件的硬约束。具体审核流程可以按 1A.1 设计本地版本。
+
+实验审核员可以维护项目本地 `exp-doc/实验审计规范.md`，仅限修正实验审核流程、审计口径和阻断标准；不得借此修改被审的 `实验规范.md`、实验总纲、实验设计、执行日志、结果包或主产物。如确需修改实验执行规范，应创建规范维护事项，或额外授予实验体系维护 / 规范维护角色。
+
+项目本地审核规范允许补充：
+
+1. 项目专用审核样本口径。
+2. 项目专用结果包检查项。
+3. 项目专用数据源、图表、案例的复核方式。
+4. 项目专用问题分级细则。
+5. 项目专用审核记录位置。
+
+项目本地审核规范不得削弱：
+
+1. 审核必须先看目标和来源聊天记录。
+2. 审核必须检查实验设计能否满足目标。
+3. 审核必须检查执行是否按设计走。
+4. 审核必须检查结论是否过读。
+5. 审核必须抓真问题，不得吹毛求疵或层层加码。
+
+如果项目本地审核规范与 common 审核规范冲突，审核员必须在审计报告中指出，并要求先修项目本地审核规范；冲突未解决前，不应通过受影响实验。
+
+### 1A.1 本地实验流程审核口径
+
+项目可以设计本地实验流程。审核员先审核流程设计是否满足 common 硬约束，再审核执行是否按已通过的本地流程完成。
+
+如果本地流程只是新增流程，审核重点是输入输出、证据链、责任角色和审核点是否清楚。  
+如果本地流程修改 common 默认流程，审核重点是覆盖范围、替换原因、证据链和结论边界是否写清，且不得削弱目标、来源聊天、执行日志、审计闭环和不过读要求。
+
+本地流程通过设计审核后，执行审核以该本地流程为准；审核员不得再用 common 默认步骤重复卡已被本地流程合法替换的细节。
+
+## 2. 审核原则
+
+### 2.1 目标优先
+
+审核实验设计时，必须先看实验总纲里的来源聊天记录、实验目标和实验设计。
+
+判断设计是否合理，以“能否满足它自己声明的目标”为主。
+
+如果目标缺失或不清楚，必须反馈 `目标缺失 / 目标不清`，不能替实验者假设一个目标后继续审核。
+
+如果来源聊天记录里的用户要求和实验目标或实验设计不一致，必须反馈 `来源要求不一致`。不能只按实验设计本身审核。
+
+### 2.2 只抓真问题
+
+实验审核不吹毛求疵。
+
+只有会影响目标、结论、数据、流程、可复核性或下游使用的问题，才作为审计问题。
+审核员发现的审计问题主记录写入实验审计报告；如需跨轮跟踪，再在实验问题记录中建立索引。
+
+如果实验事项包含实验开发，实验开发的方案审核、实现审核、测试验收和复审结论也统一写入 `exp-doc/实验审计报告.md`，不另写到 `dev-doc/开发审计报告.md`。
+
+实验开发中的临时草稿脚本可以不做独立代码审核；但只要代码用于生成正式实验结果、候选池、收益统计、图表、验收包、结果包、结论 readout 或可复用工具，就必须纳入实验审核。审核重点不是把轻量脚本套成重型开发流程，而是确认结果可信：
+
+1. 输入数据、样本范围、过滤条件是否和实验设计一致。
+2. 输出表、图片、summary、manifest 或等价结果包是否能和执行日志对上。
+3. 抽样、baseline、分组、统计口径、买卖规则或候选规则是否和实验目标一致。
+4. 代码是否改写原始证据、污染正式数据或覆盖不可变结果。
+5. 至少抽查关键样本，必要时人工复算 1-3 个样本或关键行。
+6. 是否需要防未来函数必须按实验目标判断，具体按 2.5“未来函数按目标判断”执行。
+
+以下内容默认不作为阻断问题：
+
+1. 文案不漂亮。
+2. 命名风格不统一但不影响读法。
+3. 可选优化项。
+4. 与目标无关的边角料。
+5. 审核员个人偏好的额外实验。
+
+### 2.3 不层层加码
+
+审核员不能把轻量实验强行升级成重型发布流程。
+
+如果当前目标只是观察、探索、验收图形或验证一个局部现象，不应要求它补齐全链路工程发布证明。
+
+但如果实验结论要升级为正式规则、实时决策策略、工程主链或长期方法论，必须补齐对应证据。
+
+### 2.4 结论范围必须和证据范围一致
+
+窄样本只能读成窄样本结论。
+
+小样本验收不能读成全市场规则成立。
+
+结构解释成立不能读成预测 ready。
+
+工程 smoke 通过不能读成 full-history 正式通过。
+
+### 2.5 未来函数按目标判断
+
+不是所有实验都必须防未来函数。
+
+是否需要防未来函数，必须由实验目标决定：
+
+1. 涉及时序决策、收益率、预测、实时筛选、回放、自动动作的实验，必须防未来函数。
+2. 后验理解、图形归纳、案例复盘、方法论总结类实验，可以不按实盘时点安全审核，但结论必须降读。
+3. 如果实验设计没有说明是否需要防未来函数，设计审核应要求补清楚。
+
+### 2.6 复杂审核可以拆分，但必须可追踪
+
+如果实验审计很复杂，审核员可以分步骤审计，也可以按需使用辅助 AI 或 subagent。
+
+要求：
+
+1. 审核员必须在实验审计报告中记录本次审计拆分了哪些检查步骤。
+2. 辅助 AI 或 subagent 的发现必须由主审核员复核后再写入最终结论。
+3. 不得直接转发未经复核的碎片结论。
+4. 拆分审计不能变成额外加码，只能用于降低复杂审计的漏查风险。
+
+### 2.7 乱码和文件可读性
+
+审计过程中如果发现正式文档、执行日志、结果表、图片说明、manifest 或审计证据链上的关键文件存在乱码、编码错误、无法读取、路径失效，必须报告。
+
+如果乱码或不可读文件影响目标、设计、执行过程或结论判断，审计不得通过；如果不影响当前结论，可以记录为一般问题或建议。
+
+## 3. 审核类型
+
+### 3.1 设计审核
+
+设计审核发生在实验执行前。
+
+输入：
+
+1. 实验总纲。
+2. 实验设计。
+3. 实验总纲中的关键来源聊天记录。
+4. 原理来源文档。
+5. 必要的前序实验或数据说明。
+
+输出：
+
+1. `通过`：设计能回答目标，可以执行。
+2. `不通过`：设计不能回答目标，必须修改后复审。
+3. `HELD`：缺关键资料，暂时不能审核。
+
+设计审核必须记录到项目：
+
+```text
+<project>/exp-doc/实验审计报告.md
+```
+
+### 3.2 执行审核
+
+执行审核发生在实验执行后。
+
+输入：
+
+1. 已审核通过的实验设计。
+2. 执行日志。
+3. 结果包入口。
+4. 关键数据、图表、summary、manifest 或等价产物。
+5. 必要的脚本、代码、配置和样本案例。
+
+输出：
+
+1. `通过`：执行和证据足以支撑当前结论，实验可完成。
+2. `不通过`：存在影响结论的问题，必须修复、补证据或重跑。
+3. `HELD`：证据缺失，暂时不能判断。
+
+执行审核必须记录到项目：
+
+```text
+<project>/exp-doc/实验审计报告.md
+```
+
+### 3.3 复审
+
+当设计或执行审核不通过后，执行者修复问题，再进入复审。
+
+复审只关注：
+
+1. 原问题是否已修复。
+2. 修复是否引入新问题。
+3. 是否需要重跑或补充结果包。
+4. 结论是否需要降读。
+
+## 4. 设计审核流程
+
+标准流程：
+
+```text
+读取实验总纲
+-> 读取实验设计
+-> 对比来源聊天记录、实验目标和实验设计
+-> 确认目标和原理来源
+-> 检查设计是否能回答目标
+-> 检查数据、样本、对照、边界是否支撑目标
+-> 检查防偏差要求是否足够
+-> 检查输出产物是否方便复核
+-> 写入实验审计报告
+-> 通过则允许执行；不通过则退回修改
+```
+
+设计审核重点：
+
+1. 目标是否清楚。
+2. 原理来源是否写清。
+3. 来源聊天记录、实验目标、实验设计是否一致。
+4. 方法是否能回答目标。
+5. 样本和对照是否合理。
+6. 关键边界是否写清。
+7. 是否需要防未来函数的判断是否合理。
+8. 样本污染、source 切换等风险是否被处理。
+9. 输出产物是否足够让人复核。
+10. PASS / FAIL / HELD 标准是否能机械判断。
+
+## 5. 执行审核流程
+
+标准流程：
+
+```text
+确认设计审核已通过
+-> 读取执行日志
+-> 读取结果包和关键产物
+-> 核对输入、输出、样本、时间范围
+-> 核对执行过程流水和中间数据路径
+-> 核对实现是否按设计执行
+-> 抽查关键案例或样本
+-> 按实验目标判断是否需要检查未来函数
+-> 检查时点错位、样本污染和必要的未来函数风险
+-> 检查结论是否过读
+-> 写入实验审计报告
+-> 通过则实验完成；不通过则退回修复或重跑
+```
+
+执行审核重点：
+
+1. 是否按已审核设计执行。
+2. 结果包是否真实存在，关键产物是否可读。
+3. 执行日志是否记录关键中间过程，不只是开始和结束。
+4. 需要复核的中间数据是否落盘，并能从执行日志追到路径。
+5. summary、日志、结果表、图表是否互相对得上。
+6. source snapshot、样本池、时间范围是否和设计一致。
+7. 关键代码或规则是否和设计一致。
+8. 关键样例、冻结案例、人工验收样本是否对得上。
+9. 是否按实验目标处理未来函数要求。
+10. 如果目标要求时点安全，是否有未来函数、PIT 泄漏、时点错位。
+11. 是否有样本污染、对照缺失、proxy 冒充真实目标。
+12. 结论是否超过证据支持范围。
+
+执行审核硬口径：
+
+1. 如果实验执行日志缺少关键节点流水，导致审核员无法从输入追到中间处理、再追到最终结果，执行审核不得通过。
+2. 如果关键节点产生了会影响结论的中间数据，但没有落盘或没有在执行日志中给出可追踪路径，执行审核不得通过。
+3. 如果结果包只有 summary/readout，缺少支撑结论的关键中间表、结果表、图表、manifest 或等价证据，执行审核不得通过。
+4. 如果某个中间节点确实没有独立数据产物，执行日志必须说明原因；审核员确认该说明不影响复核后，才允许通过。
+5. 审核员不能只看执行者口头结论或最终 summary，必须检查关键节点日志和关键数据是否能串成审计链。
+
+## 6. 默认检查清单
+
+每次审核默认至少检查：
+
+| 检查项 | 核心问题 |
+|---|---|
+| 目标 | 实验到底要证明什么 |
+| 来源聊天 | 用户原始要求、实验目标、实验设计是否一致 |
+| 设计 | 方法是否能满足目标 |
+| 数据 | 数据源、样本、时间范围是否合理 |
+| 对照 | 是否需要对照组、边界样本或负样本 |
+| 实现 | 代码、规则、人工步骤是否按设计执行 |
+| 过程 | 执行过程流水、关键中间数据路径是否完整 |
+| 产物 | 结果包、summary、manifest、图表是否存在且对得上 |
+| 案例 | 关键样本是否能人工复核 |
+| 偏差 | 是否按目标处理未来函数、样本污染、时点错位 |
+| 结论 | 是否存在过读 |
+
+## 7. 问题分类
+
+审核发现问题时，必须明确问题类型。
+
+允许类型：
+
+1. `实验设计问题`：目标、方法、样本、对照、验收标准不合理。
+2. `执行问题`：没有按设计执行，或执行记录缺失。
+3. `数据 / 产物问题`：输入缺失、产物为空、旧包污染、summary 和数据对不上。
+4. `代码实现问题`：脚本、算法、字段、分支和设计不一致。
+5. `流程 / 调度问题`：执行顺序、重跑、缓存、source 切换、结果包归档错误。
+6. `结论过读`：结论超过证据支持范围。
+7. `待归因`：证据不足，暂时不能判断根因。
+
+如果是 `待归因`，必须写清下一步要查什么，不能直接转给执行者“修 bug”。
+
+## 8. 严重级别
+
+问题严重级别分为：
+
+1. `阻断`：会推翻结论、必须重跑、或不能进入下一阶段。
+2. `重要`：不一定推翻结论，但会明显影响可信度或下游使用。
+3. `一般`：需要记录或后续处理，但不阻断当前目标。
+4. `建议`：非问题，只是改进建议。
+
+只有 `阻断` 和必要的 `重要` 问题应阻止实验完成。
+
+## 9. 未来函数和时点审核
+
+未来函数不是所有实验的统一硬要求。
+
+如果实验涉及预测、收益率、回放、自动动作或任何实时决策判断，必须检查未来函数。
+
+如果实验是后验理解、案例复盘、图形归纳、方法论总结，应检查结论是否降读，而不是强制按实盘时点安全否决实验。
+
+审核员要判断：
+
+1. 触发条件在决策时点是否已经可见。
+2. 买卖点、候选池、过滤条件是否用了当天收盘后或未来数据。
+3. 指标窗口是否包含了当前还不可见的数据。
+4. 人工案例是否按当时可见信息执行。
+5. 结果解释是否把后验确认当成实时触发。
+
+如果实验目标和实际结论发生错位，例如设计说只是后验理解，结论却写成可实时使用或 prediction ready，必须按结论过读处理。
+
+## 10. 通过条件
+
+设计审核通过条件：
+
+1. 目标清楚。
+2. 来源聊天记录、实验目标、实验设计一致；如不一致，已明确处理。
+3. 设计能回答目标。
+4. 数据和样本能支撑目标。
+5. 是否需要防未来函数的判断清楚。
+6. 输出产物和验收标准清楚。
+7. 没有会明显污染结论的设计缺陷。
+
+执行审核通过条件：
+
+1. 已按设计执行。
+2. 关键产物存在并可复核。
+3. 关键计数、样本、图表、日志对得上。
+4. 未发现会推翻结论的真 bug。
+5. 如果目标要求时点安全，未发现会影响结论的未来函数。
+6. 未发现会影响结论的样本污染。
+7. 结论边界写清，没有过读。
+
+## 11. 不能通过的情况
+
+出现以下任一情况，默认不能通过：
+
+1. 目标不清。
+2. 来源聊天记录、实验目标、实验设计不一致且未处理。
+3. 设计不能回答目标。
+4. 代码能跑但和设计不一致。
+5. 结果包缺关键产物。
+6. summary 和底层数据对不上。
+7. 样本或 source 被替换但没有记录。
+8. 在需要时点安全的实验中，存在未来函数且影响结论。
+9. 结论从窄样本过读成广泛成立。
+10. 问题根因还没定位清楚。
+
+## 12. 实验审计报告记录规则
+
+每次审核完成后，必须写入对应项目：
+
+```text
+<project>/exp-doc/实验审计报告.md
+```
+
+如果项目没有该文件，应按 `实验审计报告模版.md` 创建。
+
+实验审计报告是项目级滚动账本，不是单次审核文件。每次设计审核、执行审核或复审都必须追加到文件末尾，最新内容在最后；历史审计不得删除，只能追加复审或替代说明。
+
+审核员发现的问题应在实验审计报告中记录完整问题、证据、影响、是否阻断、修复建议和复审要求。实验问题记录只在需要跨轮跟踪时登记索引或关联，不替代审计报告的问题清单。
+
+审计报告至少记录：
+
+1. 审计 ID。
+2. 审计类型：设计审核、执行审核或复审。
+3. 实验事项 ID 和实验名称。
+4. 审核人。
+5. 审核时间，精确到秒。
+6. 审核结论：通过、不通过或 HELD。
+7. 审核依据文件。
+8. 关键发现。
+9. 问题清单和严重级别。
+10. 是否允许进入下一阶段。
+11. 结论边界。
+12. 来源聊天记录、实验目标、实验设计一致性判断。
+13. 是否需要防未来函数，以及判断理由。
+14. 需要回写到总纲、设计、方法论、需求或下一轮实验的内容。
+
+## 13. 审核输出口径
+
+审核员对外汇报时，默认先说结论。
+
+推荐格式：
+
+```text
+结论：通过 / 不通过 / HELD
+是否有阻断问题：有 / 无
+关键发现：...
+影响：...
+建议：...
+下一步：...
+```
+
+如果没有问题，应明确说“未发现会影响当前目标和结论的阻断问题”，不要扩大成“绝对没问题”。
+
+## 14. 审核边界
+
+审核员不应做以下事：
+
+1. 为了严谨而无限加实验。
+2. 把低价值格式问题升成阻断。
+3. 把探索实验强行按发布实验审核。
+4. 把自己没查到的数据问题转嫁给人工。
+5. 只看执行方 summary，不追关键证据。
+6. 明知目标缺失还替实验者脑补目标。
+7. 直接改写被审计实验主产物、主表或正式结果包。
+
+审核员应做以下事：
+
+1. 抓住影响结论的关键问题。
+2. 明确问题类型和严重级别。
+3. 给出可执行修复建议。
+4. 让人能快速追到证据。
+5. 审核通过前，确保设计或执行已经满足当前实验目标。
+6. 必要时运行证据链上的只读脚本或检查脚本，但不得用审计脚本替代执行方正式产物。
diff --git "a/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\346\212\245\345\221\212.md" "b/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\346\212\245\345\221\212.md"
new file mode 100644
index 0000000..e00bf4a
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\346\212\245\345\221\212.md"
@@ -0,0 +1,77 @@
+# 实验审计报告模版
+
+创建人员：<填写创建人员或 AI>  
+文件职责：记录项目内所有实验设计审核、执行审核或复审的依据、结论、问题、证据和复审状态。  
+管理规范/模板：common/exp-doc/实验审核规范.md；项目本地 exp-doc/实验审计规范.md；本文件由 common/exp-doc/实验审计报告模版.md 实例化。  
+引用文件：<填写实验总纲、实验设计、执行日志、结果包入口、实验存储体系、实验审计规范>
+
+## 0. 当前审计总览
+
+- 当前最新审计：<audit_id / 状态>
+- 当前未通过审计：<audit_id / 问题摘要>
+- 当前待复审事项：<audit_id / 复审条件>
+
+## 1. 固定审计口径
+
+- 维护方式：append-only；每次设计审核、执行审核、复审都追加到文件末尾，最新内容在最后。
+- 历史审计处理：不得删除；如被后续复审替代，追加替代说明。
+- 审计重点：抓真问题，避免为模板形式吹毛求疵；但目标、设计、执行、证据链和结论边界必须一致。
+- 审计问题记录：审核员发现的问题完整记录在本文；只有需要跨轮跟踪、跨实验汇总或长期处理时，才在 `实验问题记录.md` 中建立索引，不重复全文。
+
+## 2. 审计记录追加区
+
+## <YYYY-MM-DD HH:mm:ss> <audit_id>：<实验名称>
+
+- 审计类型：<设计审核/执行审核/复审>
+- 实验事项 ID：<填写>
+- 实验设计 ID：<填写；设计审核必填，执行审核引用已通过设计>
+- run_id：<填写；执行审核必填，设计审核可为空>
+- 审核人：<填写>
+- 审计结论：<通过/不通过/HELD>
+
+### 审计依据
+
+| 依据类型 | 路径/说明 |
+|---|---|
+| 实验总纲 | <填写> |
+| 实验设计 | <填写> |
+| 来源聊天记录 | <填写实验总纲中的聊天记录位置或摘录> |
+| 执行日志 | <填写> |
+| 结果包 | <填写> |
+| 实验存储体系 | <填写> |
+| 其他 | <填写> |
+
+### 设计审核项
+
+- 目标是否清楚：<通过/不通过/不适用>
+- 设计是否能回答目标：<通过/不通过/不适用>
+- 来源聊天要求、实验目标、实验设计是否一致：<通过/不通过/说明>
+- 数据和样本是否支撑目标：<通过/不通过/不适用>
+- 防偏差设计是否足够：<通过/不通过/不适用>
+- 产物是否方便复核：<通过/不通过/不适用>
+
+### 执行审核项
+
+- 是否按设计执行：<通过/不通过/不适用>
+- 输入输出是否对得上：<通过/不通过/不适用>
+- 关键数据是否可追踪：<通过/不通过/不适用>
+- 是否存在真 bug：<无/有；说明>
+- 是否需要防未来函数：<是/否/不适用；必须和实验设计一致>
+- 如需防未来函数，是否存在未来函数或时间口径错误：<无/有/不适用；说明>
+- 结论是否过读：<无/有；说明>
+
+### 问题清单
+
+| 问题 ID | 类型 | 严重度 | 证据 | 影响 | 建议处理 |
+|---|---|---|---|---|---|
+| <ISSUE-001> | <设计/执行/数据/代码/结论/其他> | <阻断/重要/一般> | <路径/说明> | <填写> | <填写> |
+
+### 审计边界和结论
+
+- 本次审计覆盖：<填写>
+- 本次审计未覆盖：<填写>
+- 可以读成：<填写>
+- 不应过读为：<填写>
+- 是否需要复审：<是/否>
+- 复审入口：<路径>
+- 结论回写建议：<填写>
diff --git "a/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\350\247\204\350\214\203.md" "b/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\350\247\204\350\214\203.md"
new file mode 100644
index 0000000..f783d76
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\345\256\241\350\256\241\350\247\204\350\214\203.md"
@@ -0,0 +1,444 @@
+# 实验审核规范
+
+创建人员：Codex  
+文件职责：定义实验设计审核、实验执行审核、复审、问题归因、通过标准和审计报告记录规则。  
+管理规范/模板：common/exp-doc/实验规范.md；本文件是实验审核专用规范。  
+引用文件：../../管理系统说明.md；实验规范.md；实验总纲模版.md；实验设计模版.md；
+
+统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地实验审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。
+
+## 1. 定位
+
+实验审核是实验事项的质量关口。
+
+它不负责替执行者重新做实验，也不负责无边界地增加要求。
+
+它只回答：
+
+1. 实验目标是否清楚。
+2. 实验设计是否能满足目标。
+3. 实验是否按设计执行。
+4. 关键数据、代码、案例、产物是否对得上。
+5. 是否存在会影响结论的真 bug、样本污染、口径替换或结论过读。
+6. 如果实验目标要求时点安全，是否存在未来函数。
+7. 当前结论能不能成立，最多能读到什么程度。
+
+## 1A. 全局审核规范和项目本地审核规范
+
+`common/exp-doc/实验审核规范.md` 是全局通用审核规范。
+
+所有项目的审核员都必须遵守本文件。每个项目创建实验环境时都必须创建项目本地 `exp-doc/实验审计规范.md`。项目本地审计规范默认可以很短，只引用本文件并声明必须遵守；如果补充项目特化规则，不能违反本文件的硬约束。具体审核流程可以按 1A.1 设计本地版本。
+
+实验审核员可以维护项目本地 `exp-doc/实验审计规范.md`，仅限修正实验审核流程、审计口径和阻断标准；不得借此修改被审的 `实验规范.md`、实验总纲、实验设计、执行日志、结果包或主产物。如确需修改实验执行规范，应创建规范维护事项，或额外授予实验体系维护 / 规范维护角色。
+
+项目本地审核规范允许补充：
+
+1. 项目专用审核样本口径。
+2. 项目专用结果包检查项。
+3. 项目专用数据源、图表、案例的复核方式。
+4. 项目专用问题分级细则。
+5. 项目专用审核记录位置。
+
+项目本地审核规范不得削弱：
+
+1. 审核必须先看目标和来源聊天记录。
+2. 审核必须检查实验设计能否满足目标。
+3. 审核必须检查执行是否按设计走。
+4. 审核必须检查结论是否过读。
+5. 审核必须抓真问题，不得吹毛求疵或层层加码。
+
+如果项目本地审核规范与 common 审核规范冲突，审核员必须在审计报告中指出，并要求先修项目本地审核规范；冲突未解决前，不应通过受影响实验。
+
+### 1A.1 本地实验流程审核口径
+
+项目可以设计本地实验流程。审核员先审核流程设计是否满足 common 硬约束，再审核执行是否按已通过的本地流程完成。
+
+如果本地流程只是新增流程，审核重点是输入输出、证据链、责任角色和审核点是否清楚。  
+如果本地流程修改 common 默认流程，审核重点是覆盖范围、替换原因、证据链和结论边界是否写清，且不得削弱目标、来源聊天、执行日志、审计闭环和不过读要求。
+
+本地流程通过设计审核后，执行审核以该本地流程为准；审核员不得再用 common 默认步骤重复卡已被本地流程合法替换的细节。
+
+## 2. 审核原则
+
+### 2.1 目标优先
+
+审核实验设计时，必须先看实验总纲里的来源聊天记录、实验目标和实验设计。
+
+判断设计是否合理，以“能否满足它自己声明的目标”为主。
+
+如果目标缺失或不清楚，必须反馈 `目标缺失 / 目标不清`，不能替实验者假设一个目标后继续审核。
+
+如果来源聊天记录里的用户要求和实验目标或实验设计不一致，必须反馈 `来源要求不一致`。不能只按实验设计本身审核。
+
+### 2.2 只抓真问题
+
+实验审核不吹毛求疵。
+
+只有会影响目标、结论、数据、流程、可复核性或下游使用的问题，才作为审计问题。
+审核员发现的审计问题主记录写入实验审计报告；如需跨轮跟踪，再在实验问题记录中建立索引。
+
+如果实验事项包含实验开发，实验开发的方案审核、实现审核、测试验收和复审结论也统一写入 `exp-doc/实验审计报告.md`，不另写到 `dev-doc/开发审计报告.md`。
+
+实验开发中的临时草稿脚本可以不做独立代码审核；但只要代码用于生成正式实验结果、候选池、收益统计、图表、验收包、结果包、结论 readout 或可复用工具，就必须纳入实验审核。审核重点不是把轻量脚本套成重型开发流程，而是确认结果可信：
+
+1. 输入数据、样本范围、过滤条件是否和实验设计一致。
+2. 输出表、图片、summary、manifest 或等价结果包是否能和执行日志对上。
+3. 抽样、baseline、分组、统计口径、买卖规则或候选规则是否和实验目标一致。
+4. 代码是否改写原始证据、污染正式数据或覆盖不可变结果。
+5. 至少抽查关键样本，必要时人工复算 1-3 个样本或关键行。
+6. 是否需要防未来函数必须按实验目标判断，具体按 2.5“未来函数按目标判断”执行。
+
+以下内容默认不作为阻断问题：
+
+1. 文案不漂亮。
+2. 命名风格不统一但不影响读法。
+3. 可选优化项。
+4. 与目标无关的边角料。
+5. 审核员个人偏好的额外实验。
+
+### 2.3 不层层加码
+
+审核员不能把轻量实验强行升级成重型发布流程。
+
+如果当前目标只是观察、探索、验收图形或验证一个局部现象，不应要求它补齐全链路工程发布证明。
+
+但如果实验结论要升级为正式规则、实时决策策略、工程主链或长期方法论，必须补齐对应证据。
+
+### 2.4 结论范围必须和证据范围一致
+
+窄样本只能读成窄样本结论。
+
+小样本验收不能读成全市场规则成立。
+
+结构解释成立不能读成预测 ready。
+
+工程 smoke 通过不能读成 full-history 正式通过。
+
+### 2.5 未来函数按目标判断
+
+不是所有实验都必须防未来函数。
+
+是否需要防未来函数，必须由实验目标决定：
+
+1. 涉及时序决策、收益率、预测、实时筛选、回放、自动动作的实验，必须防未来函数。
+2. 后验理解、图形归纳、案例复盘、方法论总结类实验，可以不按实盘时点安全审核，但结论必须降读。
+3. 如果实验设计没有说明是否需要防未来函数，设计审核应要求补清楚。
+
+### 2.6 复杂审核可以拆分，但必须可追踪
+
+如果实验审计很复杂，审核员可以分步骤审计，也可以按需使用辅助 AI 或 subagent。
+
+要求：
+
+1. 审核员必须在实验审计报告中记录本次审计拆分了哪些检查步骤。
+2. 辅助 AI 或 subagent 的发现必须由主审核员复核后再写入最终结论。
+3. 不得直接转发未经复核的碎片结论。
+4. 拆分审计不能变成额外加码，只能用于降低复杂审计的漏查风险。
+
+### 2.7 乱码和文件可读性
+
+审计过程中如果发现正式文档、执行日志、结果表、图片说明、manifest 或审计证据链上的关键文件存在乱码、编码错误、无法读取、路径失效，必须报告。
+
+如果乱码或不可读文件影响目标、设计、执行过程或结论判断，审计不得通过；如果不影响当前结论，可以记录为一般问题或建议。
+
+## 3. 审核类型
+
+### 3.1 设计审核
+
+设计审核发生在实验执行前。
+
+输入：
+
+1. 实验总纲。
+2. 实验设计。
+3. 实验总纲中的关键来源聊天记录。
+4. 原理来源文档。
+5. 必要的前序实验或数据说明。
+
+输出：
+
+1. `通过`：设计能回答目标，可以执行。
+2. `不通过`：设计不能回答目标，必须修改后复审。
+3. `HELD`：缺关键资料，暂时不能审核。
+
+设计审核必须记录到项目：
+
+```text
+<project>/exp-doc/实验审计报告.md
+```
+
+### 3.2 执行审核
+
+执行审核发生在实验执行后。
+
+输入：
+
+1. 已审核通过的实验设计。
+2. 执行日志。
+3. 结果包入口。
+4. 关键数据、图表、summary、manifest 或等价产物。
+5. 必要的脚本、代码、配置和样本案例。
+
+输出：
+
+1. `通过`：执行和证据足以支撑当前结论，实验可完成。
+2. `不通过`：存在影响结论的问题，必须修复、补证据或重跑。
+3. `HELD`：证据缺失，暂时不能判断。
+
+执行审核必须记录到项目：
+
+```text
+<project>/exp-doc/实验审计报告.md
+```
+
+### 3.3 复审
+
+当设计或执行审核不通过后，执行者修复问题，再进入复审。
+
+复审只关注：
+
+1. 原问题是否已修复。
+2. 修复是否引入新问题。
+3. 是否需要重跑或补充结果包。
+4. 结论是否需要降读。
+
+## 4. 设计审核流程
+
+标准流程：
+
+```text
+读取实验总纲
+-> 读取实验设计
+-> 对比来源聊天记录、实验目标和实验设计
+-> 确认目标和原理来源
+-> 检查设计是否能回答目标
+-> 检查数据、样本、对照、边界是否支撑目标
+-> 检查防偏差要求是否足够
+-> 检查输出产物是否方便复核
+-> 写入实验审计报告
+-> 通过则允许执行；不通过则退回修改
+```
+
+设计审核重点：
+
+1. 目标是否清楚。
+2. 原理来源是否写清。
+3. 来源聊天记录、实验目标、实验设计是否一致。
+4. 方法是否能回答目标。
+5. 样本和对照是否合理。
+6. 关键边界是否写清。
+7. 是否需要防未来函数的判断是否合理。
+8. 样本污染、source 切换等风险是否被处理。
+9. 输出产物是否足够让人复核。
+10. PASS / FAIL / HELD 标准是否能机械判断。
+
+## 5. 执行审核流程
+
+标准流程：
+
+```text
+确认设计审核已通过
+-> 读取执行日志
+-> 读取结果包和关键产物
+-> 核对输入、输出、样本、时间范围
+-> 核对执行过程流水和中间数据路径
+-> 核对实现是否按设计执行
+-> 抽查关键案例或样本
+-> 按实验目标判断是否需要检查未来函数
+-> 检查时点错位、样本污染和必要的未来函数风险
+-> 检查结论是否过读
+-> 写入实验审计报告
+-> 通过则实验完成；不通过则退回修复或重跑
+```
+
+执行审核重点：
+
+1. 是否按已审核设计执行。
+2. 结果包是否真实存在，关键产物是否可读。
+3. 执行日志是否记录关键中间过程，不只是开始和结束。
+4. 需要复核的中间数据是否落盘，并能从执行日志追到路径。
+5. summary、日志、结果表、图表是否互相对得上。
+6. source snapshot、样本池、时间范围是否和设计一致。
+7. 关键代码或规则是否和设计一致。
+8. 关键样例、冻结案例、人工验收样本是否对得上。
+9. 是否按实验目标处理未来函数要求。
+10. 如果目标要求时点安全，是否有未来函数、PIT 泄漏、时点错位。
+11. 是否有样本污染、对照缺失、proxy 冒充真实目标。
+12. 结论是否超过证据支持范围。
+
+执行审核硬口径：
+
+1. 如果实验执行日志缺少关键节点流水，导致审核员无法从输入追到中间处理、再追到最终结果，执行审核不得通过。
+2. 如果关键节点产生了会影响结论的中间数据，但没有落盘或没有在执行日志中给出可追踪路径，执行审核不得通过。
+3. 如果结果包只有 summary/readout，缺少支撑结论的关键中间表、结果表、图表、manifest 或等价证据，执行审核不得通过。
+4. 如果某个中间节点确实没有独立数据产物，执行日志必须说明原因；审核员确认该说明不影响复核后，才允许通过。
+5. 审核员不能只看执行者口头结论或最终 summary，必须检查关键节点日志和关键数据是否能串成审计链。
+
+## 6. 默认检查清单
+
+每次审核默认至少检查：
+
+| 检查项 | 核心问题 |
+|---|---|
+| 目标 | 实验到底要证明什么 |
+| 来源聊天 | 用户原始要求、实验目标、实验设计是否一致 |
+| 设计 | 方法是否能满足目标 |
+| 数据 | 数据源、样本、时间范围是否合理 |
+| 对照 | 是否需要对照组、边界样本或负样本 |
+| 实现 | 代码、规则、人工步骤是否按设计执行 |
+| 过程 | 执行过程流水、关键中间数据路径是否完整 |
+| 产物 | 结果包、summary、manifest、图表是否存在且对得上 |
+| 案例 | 关键样本是否能人工复核 |
+| 偏差 | 是否按目标处理未来函数、样本污染、时点错位 |
+| 结论 | 是否存在过读 |
+
+## 7. 问题分类
+
+审核发现问题时，必须明确问题类型。
+
+允许类型：
+
+1. `实验设计问题`：目标、方法、样本、对照、验收标准不合理。
+2. `执行问题`：没有按设计执行，或执行记录缺失。
+3. `数据 / 产物问题`：输入缺失、产物为空、旧包污染、summary 和数据对不上。
+4. `代码实现问题`：脚本、算法、字段、分支和设计不一致。
+5. `流程 / 调度问题`：执行顺序、重跑、缓存、source 切换、结果包归档错误。
+6. `结论过读`：结论超过证据支持范围。
+7. `待归因`：证据不足，暂时不能判断根因。
+
+如果是 `待归因`，必须写清下一步要查什么，不能直接转给执行者“修 bug”。
+
+## 8. 严重级别
+
+问题严重级别分为：
+
+1. `阻断`：会推翻结论、必须重跑、或不能进入下一阶段。
+2. `重要`：不一定推翻结论，但会明显影响可信度或下游使用。
+3. `一般`：需要记录或后续处理，但不阻断当前目标。
+4. `建议`：非问题，只是改进建议。
+
+只有 `阻断` 和必要的 `重要` 问题应阻止实验完成。
+
+## 9. 未来函数和时点审核
+
+未来函数不是所有实验的统一硬要求。
+
+如果实验涉及预测、收益率、回放、自动动作或任何实时决策判断，必须检查未来函数。
+
+如果实验是后验理解、案例复盘、图形归纳、方法论总结，应检查结论是否降读，而不是强制按实盘时点安全否决实验。
+
+审核员要判断：
+
+1. 触发条件在决策时点是否已经可见。
+2. 买卖点、候选池、过滤条件是否用了当天收盘后或未来数据。
+3. 指标窗口是否包含了当前还不可见的数据。
+4. 人工案例是否按当时可见信息执行。
+5. 结果解释是否把后验确认当成实时触发。
+
+如果实验目标和实际结论发生错位，例如设计说只是后验理解，结论却写成可实时使用或 prediction ready，必须按结论过读处理。
+
+## 10. 通过条件
+
+设计审核通过条件：
+
+1. 目标清楚。
+2. 来源聊天记录、实验目标、实验设计一致；如不一致，已明确处理。
+3. 设计能回答目标。
+4. 数据和样本能支撑目标。
+5. 是否需要防未来函数的判断清楚。
+6. 输出产物和验收标准清楚。
+7. 没有会明显污染结论的设计缺陷。
+
+执行审核通过条件：
+
+1. 已按设计执行。
+2. 关键产物存在并可复核。
+3. 关键计数、样本、图表、日志对得上。
+4. 未发现会推翻结论的真 bug。
+5. 如果目标要求时点安全，未发现会影响结论的未来函数。
+6. 未发现会影响结论的样本污染。
+7. 结论边界写清，没有过读。
+
+## 11. 不能通过的情况
+
+出现以下任一情况，默认不能通过：
+
+1. 目标不清。
+2. 来源聊天记录、实验目标、实验设计不一致且未处理。
+3. 设计不能回答目标。
+4. 代码能跑但和设计不一致。
+5. 结果包缺关键产物。
+6. summary 和底层数据对不上。
+7. 样本或 source 被替换但没有记录。
+8. 在需要时点安全的实验中，存在未来函数且影响结论。
+9. 结论从窄样本过读成广泛成立。
+10. 问题根因还没定位清楚。
+
+## 12. 实验审计报告记录规则
+
+每次审核完成后，必须写入对应项目：
+
+```text
+<project>/exp-doc/实验审计报告.md
+```
+
+如果项目没有该文件，应按 `实验审计报告模版.md` 创建。
+
+实验审计报告是项目级滚动账本，不是单次审核文件。每次设计审核、执行审核或复审都必须追加到文件末尾，最新内容在最后；历史审计不得删除，只能追加复审或替代说明。
+
+审核员发现的问题应在实验审计报告中记录完整问题、证据、影响、是否阻断、修复建议和复审要求。实验问题记录只在需要跨轮跟踪时登记索引或关联，不替代审计报告的问题清单。
+
+审计报告至少记录：
+
+1. 审计 ID。
+2. 审计类型：设计审核、执行审核或复审。
+3. 实验事项 ID 和实验名称。
+4. 审核人。
+5. 审核时间，精确到秒。
+6. 审核结论：通过、不通过或 HELD。
+7. 审核依据文件。
+8. 关键发现。
+9. 问题清单和严重级别。
+10. 是否允许进入下一阶段。
+11. 结论边界。
+12. 来源聊天记录、实验目标、实验设计一致性判断。
+13. 是否需要防未来函数，以及判断理由。
+14. 需要回写到总纲、设计、方法论、需求或下一轮实验的内容。
+
+## 13. 审核输出口径
+
+审核员对外汇报时，默认先说结论。
+
+推荐格式：
+
+```text
+结论：通过 / 不通过 / HELD
+是否有阻断问题：有 / 无
+关键发现：...
+影响：...
+建议：...
+下一步：...
+```
+
+如果没有问题，应明确说“未发现会影响当前目标和结论的阻断问题”，不要扩大成“绝对没问题”。
+
+## 14. 审核边界
+
+审核员不应做以下事：
+
+1. 为了严谨而无限加实验。
+2. 把低价值格式问题升成阻断。
+3. 把探索实验强行按发布实验审核。
+4. 把自己没查到的数据问题转嫁给人工。
+5. 只看执行方 summary，不追关键证据。
+6. 明知目标缺失还替实验者脑补目标。
+7. 直接改写被审计实验主产物、主表或正式结果包。
+
+审核员应做以下事：
+
+1. 抓住影响结论的关键问题。
+2. 明确问题类型和严重级别。
+3. 给出可执行修复建议。
+4. 让人能快速追到证据。
+5. 审核通过前，确保设计或执行已经满足当前实验目标。
+6. 必要时运行证据链上的只读脚本或检查脚本，但不得用审计脚本替代执行方正式产物。
diff --git "a/exp-doc/\345\256\236\351\252\214\346\200\273\347\272\262.md" "b/exp-doc/\345\256\236\351\252\214\346\200\273\347\272\262.md"
new file mode 100644
index 0000000..0fcf649
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\346\200\273\347\272\262.md"
@@ -0,0 +1,95 @@
+# 实验总纲模版
+
+创建人员：<填写创建人员或 AI>  
+文件职责：记录项目内所有实验事项的背景、目标、主线口径、阶段结论、结果包入口和下一步；对应管理系统里的事项总纲账本。  
+管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验总纲模版.md 实例化。  
+引用文件：<填写实验规范、实验设计、实验执行日志、实验审计报告、实验存储体系、来源聊天记录或上游文档>
+
+## 0. 当前总览
+
+> 本节用于人和 AI 快速进入当前状态，可以随最新进展更新；详细实验记录仍必须追加到文件末尾。
+
+- 当前主线：<当前实验主线或研究方向>
+- 当前最新实验：<实验事项 ID / 名称 / 状态>
+- 当前有效结论：<只写已被结果和审核支持的结论>
+- 当前阻断项：<无/待补数据/设计未审/执行未审/其他>
+- 当前下一步：<下一步动作>
+- 关键入口：<实验设计.md / 实验执行日志.md / 实验审计报告.md / 结果包索引>
+
+## 1. 固定口径和长期约定
+
+- 项目名称：<填写项目名称>
+- 项目路径：<相对路径或项目标识>
+- 实验记录维护方式：append-only；新实验、新结论、新修订追加到文件末尾，最新内容在最后。
+- 历史记录处理：历史结论不得删除；如失效，追加“失效/降读/替代”说明并指向证据。
+- 路径规则：项目内文件默认使用相对路径；不要默认写本机绝对路径。
+- 关键来源聊天记录规则：用户原始要求或其可打开路径必须进入对应实验块的背景。
+
+## 2. 实验记录追加区
+
+> 从这里开始按时间顺序追加。不要把最新实验插到文件开头；不要为每个实验创建独立总纲文件。  
+> 推荐结构参考长期滚动账本：背景 -> 目标 -> 设计入口 -> 结果入口 -> 关键结果 -> 当前读法 -> 下一步。
+
+## <YYYY-MM-DD> <实验事项 ID>：<实验名称>
+
+- 创建人员：<填写>
+- 创建时间：<YYYY-MM-DD HH:mm:ss>
+- 当前状态：<未开始/设计中/待设计审核/设计审核通过/执行中/待执行审核/完成/暂停/取消>
+- 当前结论：<未形成/阶段结论/完成结论>
+
+### 背景、由来和关键聊天记录
+
+- 背景：<为什么要做>
+- 由来：<来自哪个讨论、需求、方法论、前序实验或异常>
+- 原理来源：<上游文档、案例、数据观察或聊天路径>
+- 关键来源聊天记录：<粘贴最重要原文，或给出可直接打开的路径>
+- 聊天要求摘要：<把用户要求压成要点，方便审核员对照>
+
+### 目标和边界
+
+- 主目标：<本实验最核心要回答的问题>
+- 次目标：<可选>
+- 不属于本轮目标：<明确不验证什么>
+- 数据边界：<数据范围、时间范围、样本范围>
+- 方法边界：<本轮使用/不使用的方法>
+- 结论边界：<本轮最多能说明什么>
+
+### 设计、执行和审计入口
+
+- 实验设计：`实验设计.md` 中 <设计 ID / 小节标题>
+- 执行日志：`实验执行日志.md` 中 <run_id / 小节标题>
+- 设计审核：`实验审计报告.md` 中 <audit_id / 小节标题>
+- 执行审核：`实验审计报告.md` 中 <audit_id / 小节标题>
+- 非审计问题 / 审计问题索引：`实验问题记录.md` 中 <issue_id / 小节标题；如无填写无>
+
+### 结果包和关键证据入口
+
+- 结果包：<路径>
+- summary/readout：<路径>
+- 核心表：<路径>
+- 核心图或可视化证据：<路径>
+- manifest/hash/输入快照：<路径>
+
+### 关键结果
+
+- <关键指标 1>：<取值和读法>
+- <关键指标 2>：<取值和读法>
+- <关键异常或缺口>：<无/说明>
+
+### 当前读法
+
+- 可以读成：<证据支持的结论>
+- 不能读成：<防止过读>
+- 降读/失效记录：<如无填写无；如有说明原因和替代结论>
+
+### 下一步
+
+- 下一步动作：<继续实验/补数据/补对照/回写方法论/进入实现/暂停>
+- 继续条件：<满足什么条件才继续>
+- 停止条件：<满足什么条件必须停止或降级>
+
+### 结论回写
+
+- 回写目标：<方法论/需求/代码/数据/下一轮实验/暂停说明>
+- 回写内容：<填写>
+- 回写状态：<待回写/已回写/不回写>
diff --git "a/exp-doc/\345\256\236\351\252\214\346\211\247\350\241\214\346\227\245\345\277\227.md" "b/exp-doc/\345\256\236\351\252\214\346\211\247\350\241\214\346\227\245\345\277\227.md"
new file mode 100644
index 0000000..be86605
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\346\211\247\350\241\214\346\227\245\345\277\227.md"
@@ -0,0 +1,84 @@
+# 实验执行日志模版
+
+创建人员：<填写创建人员或 AI>  
+文件职责：记录项目内所有实验实际执行过程、关键输入输出、异常、重跑和下一步动作。  
+管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验执行日志模版.md 实例化。  
+引用文件：<填写实验总纲、实验设计、实验审计报告、执行脚本或数据路径>
+
+## 0. 当前执行总览
+
+- 当前最新 run：<run_id / 状态>
+- 当前可用结果包：<run_id / 路径>
+- 当前失败或暂停 run：<run_id / 原因>
+- 当前下一步：<重跑/复审/回写/暂停>
+
+## 1. 固定执行口径
+
+- 维护方式：append-only；每次执行、重跑、人工操作、异常处理都追加到文件末尾，最新内容在最后。
+- 历史 run 处理：不得删除；失败 run 标记失败/降读/暂停，并保留结果包或失败证据入口。
+- 执行前置：对应实验设计必须已通过设计审核，除非明确是探索性预跑或环境 smoke。
+- 路径规则：项目内文件默认使用相对路径。
+
+## 2. 执行日志追加区
+
+> 从这里开始按时间顺序追加。执行日志可以简洁，但必须写清输入、关键中间过程、中间数据位置、输出、关键计数、异常和下一步。
+
+## <YYYY-MM-DD HH:mm:ss> <run_id>：<实验名称>
+
+- 实验事项 ID：<填写>
+- 实验设计 ID：<填写>
+- 执行人：<填写>
+- 执行类型：<正式执行/重跑/抽样/smoke/人工操作/复验>
+- 当前状态：<运行中/成功/失败/中断/暂停/降读>
+- 结果包目录：<路径>
+
+### 执行动作
+
+- 执行入口：<脚本路径、命令、人工流程或工具名>
+- 工作目录：<路径/不适用>
+- 关键参数：<填写>
+- 配置版本：<配置路径、hash 或摘要；如不适用说明>
+
+### 输入
+
+- 输入快照/数据版本：<路径、hash、日期或版本；如不适用说明>
+- 上游依赖：<设计 ID、前序 run、外部文件、人工回执>
+
+### 执行过程流水
+
+> 必填。不要只写“已跑完”。每个能影响结论的关键节点都要有记录；如果节点产生中间数据，必须写路径。中间数据若后续审计需要复核，应保存到 `exp-data/result/<run_id>/intermediate/` 或等价正式结果包目录，不要只留在临时目录。
+
+| step_id | 时间 | 动作 | 输入/依赖 | 中间数据或输出 | 关键计数/校验 | 状态 | 备注 |
+|---|---|---|---|---|---|---|---|
+| STEP-001 | <时间> | <读取/冻结输入> | <路径> | <路径> | <row_count/hash> | <PASS/FAIL/HELD> | <说明> |
+| STEP-002 | <时间> | <清洗/特征/聚合/筛选/人工标注等关键处理> | <路径> | <路径> | <row_count/hash> | <PASS/FAIL/HELD> | <说明> |
+| STEP-003 | <时间> | <生成结果/图片/报告> | <路径> | <路径> | <row_count/count/hash> | <PASS/FAIL/HELD> | <说明> |
+
+### 输出
+
+- summary/readout：<路径>
+- 核心输出表：<路径>
+- 中间表/中间结果：<路径；如无，说明为什么不需要>
+- 核心图表或可视化：<路径>
+- manifest/hash：<路径>
+- 其他产物：<路径>
+
+### 关键计数和自检
+
+| 检查项 | 目标 | 实际结果 | 状态 | 证据路径 |
+|---|---|---|---|---|
+| <字段存在/行数合理/样本覆盖/图路径存在/无未来函数等按目标需要的检查> | <填写> | <填写> | <PASS/FAIL/HELD/不适用> | <路径> |
+
+### 偏离、异常和处理
+
+- 是否偏离设计：<否/是；说明>
+- 异常：<无/说明>
+- 影响范围：<无/步骤/结果包/结论>
+- 处理动作：<无/补跑/重跑/降读/暂停>
+- 是否需要复审：<是/否>
+
+### 当前读法和下一步
+
+- 当前读法：<PASS/FAIL/HELD/降读/失效>
+- 不能读成：<防止过读>
+- 下一步：<提交执行审核/补数据/重跑/回写总纲/暂停>
diff --git "a/exp-doc/\345\256\236\351\252\214\350\247\204\350\214\203.md" "b/exp-doc/\345\256\236\351\252\214\350\247\204\350\214\203.md"
new file mode 100644
index 0000000..0d21671
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\350\247\204\350\214\203.md"
@@ -0,0 +1,492 @@
+# 实验规范
+
+创建人员：Codex  
+文件职责：定义通用实验体系的文档结构、实验设计流程、实验执行流程、审计入口和模板使用规则。  
+管理规范/模板：项目通用实验体系架构文档；本文件不是模板文档，模板文档放在 `common/exp-doc/*模版.md`。  
+引用文件：../../管理系统说明.md；../../体系说明.md；../pro-doc/需求规范.md；../dev-doc/编码规范.md；历史实验总纲、实验设计、实验计划、执行约定已去项目化抽象。
+
+统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地实验规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。
+
+## 1. 定位
+
+实验是一种事项类型。
+
+实验不是单纯跑脚本，也不是只看 summary。实验必须把一个问题从“为什么要做”推进到“怎么验证、怎么执行、证据在哪里、结论能读到什么程度、是否通过审核”。
+
+实验体系的目标：
+
+1. 让实验目标、背景、原理来源可追踪。
+2. 让实验设计能证明总纲里的目标。
+3. 让实验执行过程、关键数据、结果包可复核。
+4. 让设计和执行都经过审核，具体审核规则见 `实验审核规范.md`。
+5. 让总纲、设计、执行日志、审计报告能用统一 ID 串成证据链。
+6. 让结论能回写到方法论、需求、代码、数据或下一轮实验。
+
+## 1A. 全局规范和项目本地规范
+
+`common/exp-doc/实验规范.md` 是全局通用实验规范。
+
+所有项目的实验员都必须遵守本文件。每个项目创建实验环境时都必须创建项目本地 `exp-doc/实验规范.md`。项目本地规范默认可以很短，只引用本文件并声明必须遵守；如果补充项目特化规则，不能违反本文件的硬约束。具体流程可以按 1A.1 设计本地版本。
+
+项目本地 `实验规范.md` 即使没有额外项目规则，也必须说明本项目核心实验文档的作用和入口，至少覆盖：`实验总纲.md`、`实验设计.md`、`实验执行日志.md`、`实验存储体系.md`、`实验审计报告.md`、`实验问题记录.md`。这样实验员进入项目后，不需要回头翻 common 文档也能知道本项目实验证据链怎么走。
+
+项目本地规范允许补充：
+
+1. 项目目录映射。
+2. 项目专用数据源和结果包路径。
+3. 项目专用命名规则。
+4. 项目专用实验类型和轻重流程区分。
+5. 项目专用角色分工。
+
+项目本地规范不得削弱：
+
+1. 实验必须有目标和边界。
+2. 实验设计和执行必须可追踪。
+3. 设计和执行必须有审核闭环。
+4. 关键来源聊天记录必须能被审核员看到。
+5. 结论不得超过证据范围。
+
+如果项目本地规范与 common 规范冲突，必须先修项目本地规范；冲突未解决前，不应把对应实验标为完成。
+
+### 1A.1 本地实验流程优先级
+
+common 实验规范规定底线和默认流程，项目本地 `实验规范.md` 可以设计更贴合项目的实验流程。
+
+本地流程设计必须先满足 common 硬约束：目标和边界清楚、来源聊天记录可见、设计和执行可追踪、设计和执行有审核闭环、结论不过读。
+
+本地流程可以做两类调整：
+
+1. 新增流程：例如新增项目专用样本验收流程、人工复核流程、案例回放流程。
+2. 修改默认流程：例如把 common 默认步骤拆分、合并、替换为项目内更合适的步骤。
+
+如果只是新增流程，只要不违反 common 硬约束即可放行。  
+如果是修改默认流程，必须在本地 `实验规范.md` 或对应实验设计中写清楚覆盖范围、替换原因、输入输出、关键证据链和审核点。
+
+本地流程一旦设计完成并通过审核，执行时以本地流程为准；审核员也应按已通过的本地流程审计执行结果。只有发现本地流程违反 common 硬约束时，才回到 common 规范要求整改。
+
+## 2. 适用范围
+
+适用于以下事项：
+
+1. 理论验证实验。
+2. 策略实验。
+3. 数据实验。
+4. 工程验证实验。
+5. 性能实验。
+6. 样本验收实验。
+7. 案例分析实验。
+8. 外部信息或人工反馈验证实验。
+
+临时探索如果要被后续引用为结论，必须补齐为正式实验记录。
+
+## 3. 核心文档
+
+实验体系的正式文档分为核心文档和模板文档。
+
+核心文档用于说明体系和记录具体实验。
+
+模板文档用于创建新项目或新实验时实例化，不是具体实验结论。
+
+### 3.1 实验规范
+
+`实验规范.md` 是实验体系架构文档。
+
+它负责说明：
+
+1. 实验体系有哪些核心文档。
+2. 实验设计和执行的标准流程。
+3. 实验总纲、实验设计、执行日志、结果包、审计报告分别负责什么。
+4. 什么情况下实验可以结束。
+
+### 3.1A 实验环境创建指南
+
+`实验环境创建指南.md` 是项目启用实验体系时的初始化手册。
+
+它负责说明：
+
+1. 新项目要创建哪些实验目录。
+2. 项目级实验入口、实验存储体系、审计报告和问题记录怎么建。
+3. 单个实验事项如何从总纲、设计、执行日志开始。
+4. 什么情况下实验员环境算 ready。
+
+如果一个 AI 要在新项目里创建实验员工作环境，应先读 `实验环境创建指南.md`，再实例化具体模板。
+
+### 3.2 实验总纲
+
+实验总纲是实验事项入口，对应管理系统里的“事项总纲”。
+
+项目内默认只有一个 `exp-doc/实验总纲.md`，用于持续记录所有实验事项的背景、目标、边界、状态、结果包入口和结论。不要默认按实验 ID 创建多份 `<EXP-ID>_实验总纲.md`，否则 AI 和审核员容易漏看版本和上下文。
+
+实验总纲必须采用滚动账本方式维护：新实验、新结论、新修订追加到文件末尾，最新内容在最后。文件开头可以维护“当前总览”和固定入口，但不得把最新实验插到前面，也不得覆盖历史记录。
+
+实验总纲必须包含事项总纲要求的字段：
+
+1. 实验事项 ID。
+2. 实验名称。
+3. 背景、由来和原理。
+4. 创建人员。
+5. 创建时间，精确到秒。
+6. 希望达成的目标。
+7. 当前状态。
+8. 当前结论。
+9. 唯一事项 ID。
+10. 事项名称。
+11. 完整来源聊天记录或来源记录路径。
+
+实验总纲还应补充：
+
+1. 原理来源。
+2. 本轮边界。
+3. 实验设计入口。
+4. 结果包入口。
+5. 审计入口。
+
+### 3.3 实验设计
+
+实验设计已经合并原“实验设计”和“实验计划”的职责。
+
+原因：设计回答“如何验证目标”，计划回答“如何分步骤执行”。两者必须绑定，否则容易出现设计和执行脱节。
+
+项目内默认只有一个 `exp-doc/实验设计.md`，用于持续记录所有实验的设计、步骤、依赖、产物和判定标准。新实验应追加到该文件，不要默认按实验 ID 创建多份设计文件。
+
+实验设计必须采用滚动账本方式维护：新设计、新修订、执行结果回填追加到文件末尾，最新内容在最后。设计可以有顶部“当前设计总览”，但详细设计块必须按时间顺序追加，不能用单实验表单替代长期账本。
+
+实验设计对应管理系统里的“事项计划”，必须包含事项计划要求的字段：
+
+1. 所属事项名称。
+2. 所属事项 ID。
+3. 执行人。
+4. 创建时间，精确到秒。
+5. 目标。
+6. 当前状态。
+7. 当前结论。
+8. 唯一步骤 ID。
+9. 步骤名称。
+10. 来源聊天记录，可为空。
+
+实验设计还应包含：
+
+1. 假设或要验证的问题。
+2. 数据源和样本范围。
+3. 实验组、对照组和边界样本。
+4. 方法步骤。
+5. 防偏差要求；是否需要防未来函数必须由实验目标决定。
+6. 输出产物。
+7. PASS / FAIL / HELD 判定。
+8. 设计审核记录。
+
+### 3.4 实验执行日志
+
+实验执行日志记录实际执行过程。
+
+项目内默认只有一个 `exp-doc/实验执行日志.md`，用于持续记录所有实验 run、输入、关键中间过程、中间数据路径、输出、异常、自检和重跑记录。新 run 应追加到该文件，不要默认按实验 ID 创建多份执行日志。
+
+实验执行日志同样采用 append-only 方式维护；每次运行、重跑、失败、暂停、人工操作和复验都追加到文件末尾，最新内容在最后。
+
+它负责回答：
+
+1. 哪天、谁、运行了什么。
+2. 用了什么输入。
+3. 中间过程做了哪些关键处理。
+4. 中间数据或中间表存在哪里。
+5. 生成了什么输出。
+6. 关键计数和关键异常是什么。
+7. 是否偏离设计。
+
+执行日志可以简洁，但不能只写“已跑完”。凡是会影响实验结论的关键节点，都要在执行日志中留下可追踪记录。
+
+最低要求：
+
+1. 记录输入冻结或输入快照路径。
+2. 记录每个关键处理节点，例如清洗、特征生成、过滤、抽样、人工标注、模型运行、结果聚合、画图、summary/readout 生成。
+3. 记录每个关键节点的输入、关键中间过程、中间数据路径和输出。
+4. 记录关键计数，例如输入行数、过滤后行数、样本数、图数量、失败数、命中数。
+5. 记录关键校验，例如 schema、路径存在、hash、样本覆盖、目标相关防偏差检查。
+6. 记录异常、偏离设计、补跑、重跑、降读和复审需求。
+
+如果中间数据是审计员或后续实验复核结论所必需的，应保存到 `exp-data/result/<run_id>/intermediate/` 或项目内等价正式结果包目录，并在执行日志中写明路径。`exp-data/tmp/` 只适合临时脚本和临时缓存，不能作为正式证据入口。
+
+### 3.5 实验结果包
+
+实验结果包是产物目录，不是必备模板文档。
+
+结果包入口和状态应回写到实验总纲。
+
+预期产物、实际产物、验收标准和关键读法应回写到实验设计。
+
+数据文件、图表、日志、summary 等资产应符合项目内 `实验存储体系.md` 的规则。
+
+如果某个结果包特别复杂，可以在结果包目录内临时放 readme，但它不是实验体系必备模板。
+
+结果包应能回答：
+
+1. 结果包在哪里。
+2. 输入快照是什么。
+3. 输出文件有哪些。
+4. 关键指标是什么。
+5. 自检结果是什么。
+6. 哪些结论可以读，哪些不能读。
+7. 如何复跑或复核。
+
+### 3.6 实验存储体系
+
+实验存储体系是项目级数据存储合同，不是单次实验模板。
+
+项目启用实验体系时，应按 `实验存储体系创建指南.md` 创建项目内 `exp-doc/实验存储体系.md`。
+
+它负责回答：
+
+1. 实验数据存在哪里。
+2. 结果包怎么组织。
+3. 图片和图表怎么存。
+4. 表清单是什么。
+5. 每张表的 schema 和字段含义是什么。
+6. 数据怎么读、怎么取、怎么追到原始来源。
+
+### 3.7 实验审核和实验审计报告
+
+实验审核的详细规则见 `实验审核规范.md`。
+
+实验审计报告覆盖设计审核和执行审核。
+
+设计和执行都必须审核。审核未通过时，不得把实验标为完成。
+
+审核结果必须记录到对应项目的 `exp-doc/实验审计报告.md`。
+
+实验审计报告采用 append-only 方式维护；每次设计审核、执行审核和复审都追加到文件末尾，最新内容在最后。
+
+### 3.8 实验问题记录
+
+实验问题记录用于记录非审计人员在实验过程中发现的问题，也用于登记需要跨轮跟踪的审计问题索引。
+
+审核员在设计审核、执行审核和复审中发现的问题，主记录写入 `实验审计报告.md`；只有需要跨轮跟踪、跨实验汇总或由执行者长期处理时，才在 `实验问题记录.md` 中建立索引，不重复全文。
+
+实验员、执行 AI、人工同事或其他非审计角色发现的问题，主记录写入 `实验问题记录.md`。
+
+实验问题记录采用 append-only 方式维护；新问题、修复、复验和关闭记录都追加到文件末尾，最新内容在最后。
+
+问题必须区分：
+
+1. 设计问题。
+2. 执行问题。
+3. 数据问题。
+4. 代码问题。
+5. 结论过读。
+6. 需要下一轮实验的问题。
+
+### 3.9 结论回写
+
+结论回写是实验收尾动作，不是必备独立模板文档。
+
+结论回写应记录在实验总纲和实验审计报告里。
+
+常见回写目标：
+
+1. 方法论文档。
+2. 需求文档。
+3. 代码实现方案。
+4. 数据存储规范。
+5. 下一轮实验总纲。
+6. 放弃或暂停说明。
+
+如果某个实验产生大量跨文档回写动作，可以在项目内临时建立回写清单，但它不属于实验体系必备模板。
+
+## 4. 模板文档
+
+`common/exp-doc` 下应提供以下模板：
+
+1. `实验环境创建指南.md`。
+2. `实验总纲模版.md`。
+3. `实验设计模版.md`。
+4. `实验执行日志模版.md`。
+5. `实验存储体系创建指南.md`。
+6. `实验审核规范.md`。
+7. `实验审计报告模版.md`。
+8. `实验问题记录模版.md`。
+实验体系不强制提供实验导读或实验总纲列表模板。项目如果需要实验目录索引，可在项目总索引里维护；AI 审查实验时直接读取实验总纲。
+
+创建新项目或新实验体系时，应按这些模板实例化项目内的实验文档。默认实例化为项目级账本文件：`实验总纲.md`、`实验设计.md`、`实验执行日志.md`，而不是每个实验一份独立文件。
+
+这些项目级账本默认学习长期滚动实验文档的写法：顶部保留当前总览和固定口径，正文按时间追加实验块。字段完整性服务于追踪和审计，不应把文档写成难读的厚重表单。
+
+模板文档开头也必须保留管理系统要求的文件头：
+
+1. 创建人员。
+2. 文件职责。
+3. 管理规范或模板。
+4. 引用文件。
+
+项目内文档引用项目内文件时，应默认使用相对路径，避免写入依赖个人机器的绝对路径。只有跨项目、跨磁盘或引用 common 规范时，才允许使用绝对路径，并应说明原因。
+
+## 5. 实验状态
+
+实验状态建议统一使用：
+
+1. `未开始`：已登记，未设计。
+2. `设计中`：正在写实验总纲或实验设计。
+3. `待设计审核`：设计完成，等待审核。
+4. `设计审核未通过`：设计存在阻断问题，需要修改。
+5. `设计审核通过`：可以进入执行。
+6. `执行中`：正在跑实验或整理结果。
+7. `待执行审核`：执行完成，等待审核。
+8. `执行审核未通过`：执行或结果存在阻断问题，需要修复或重跑。
+9. `完成`：执行审核通过，结论和结果包已归档。
+10. `暂停`：因数据、方向、资源或上游问题暂停。
+11. `取消`：实验不再执行。
+
+## 6. 实验设计流程
+
+实验设计流程必须有审核闭环。
+
+标准流程：
+
+```text
+提出实验问题
+-> 创建实验总纲
+-> 编写实验设计
+-> 设计自检
+-> 提交设计审核
+-> 审核员审核
+-> 审核通过：设计完成，进入执行
+-> 审核不通过：修改总纲或实验设计，再次提交审核
+```
+
+设计审核的检查项、问题分级、通过条件和记录方式，按 `实验审核规范.md` 执行。
+
+## 7. 实验执行流程
+
+实验执行流程也必须有审核闭环。
+
+标准流程：
+
+```text
+确认设计审核通过
+-> 准备输入数据和执行环境
+-> 执行实验步骤
+-> 记录执行日志
+-> 生成结果包
+-> 执行自检
+-> 提交执行审核
+-> 审核员审核
+-> 审核通过：实验完成，结论可归档
+-> 审核不通过：修复、补证据或重跑，再次提交审核
+```
+
+执行审核的检查项、问题分级、通过条件和记录方式，按 `实验审核规范.md` 执行。
+
+执行审核通过前，实验不得标记为完成。
+
+## 8. 证据链要求
+
+每个正式实验必须用统一 ID 串起证据链。
+
+最低要求：
+
+1. `experiment_id`：实验事项唯一 ID，必须出现在实验总纲、实验设计、执行日志、审计报告、结果包或 manifest。
+2. `step_id`：实验设计里的步骤 ID，必须能在执行日志和审计报告里被引用。
+3. `run_id`：每次实际执行的运行 ID，必须能从执行日志追到结果包。
+4. `audit_id`：每次审核 ID，必须能追到对应实验、设计版本、执行 run 或复审对象。
+5. `source_chat_record`：关键来源聊天记录，必须在实验总纲背景中保存原文或路径。
+
+推荐证据链：
+
+```text
+实验总纲 experiment_id + source_chat_record
+-> 实验设计 experiment_id + step_id
+-> 执行日志 experiment_id + step_id + run_id
+-> 结果包 run_id
+-> 审计报告 audit_id + experiment_id + step_id/run_id
+```
+
+如果证据链断裂，审核员必须指出断在哪一环。
+
+## 9. 来源聊天记录要求
+
+实验总纲的背景中必须包含最重要的来源聊天记录。
+
+可以保存原文，也可以保存明确路径，但必须能让审核员看到用户原始要求。
+
+最低要求：
+
+1. 实验总纲必须记录关键聊天原文或路径。
+2. 实验设计必须说明如何承接这些聊天要求。
+3. 审计报告必须检查聊天要求、实验目标、实验设计是否一致。
+4. 不一致时必须提出，不能只按实验设计本身审核。
+
+## 10. 防偏差要求
+
+实验设计和执行中必须显式考虑以下风险：
+
+1. 未来函数。
+2. 样本污染。
+3. 幸存者偏差。
+4. 只看成功样本。
+5. 源数据切换但未记录。
+6. 规则执行和文档描述不一致。
+7. 结论过读。
+8. 把探索结果误读成正式结论。
+
+不是每个实验都需要防未来函数。
+
+是否必须防未来函数，应根据实验目标判断：
+
+1. 如果实验目标涉及时序决策、预测、收益率、回放、实时筛选、自动动作，必须检查未来函数。
+2. 如果实验目标是后验理解、图形归纳、案例复盘、方法论总结，可以不按实时决策时点安全要求审核，但结论必须降读，不能写成可实时使用或 prediction ready。
+3. 如果实验目标没有说明是否需要时点安全，设计审核应要求补清楚。
+
+其他偏差如果会影响结论，也必须记录处理方式。
+
+## 11. 数据和结果归档
+
+实验产物应尽量形成结果包。
+
+结果包至少应包含：
+
+1. `summary` 或结果说明。
+2. 输入数据说明。
+3. 输出数据说明。
+4. 关键表或图。
+5. 自检结果。
+6. 审核入口或审核结论。
+
+大文件可以只记录索引、路径和 hash，不要求全部塞进文档。
+
+## 12. 结论边界
+
+实验结论必须写清：
+
+1. 本轮证明了什么。
+2. 本轮没有证明什么。
+3. 哪些结果可以进入下游。
+4. 哪些结果只能作为观察。
+5. 哪些问题需要下一轮实验。
+
+禁止把“样本看起来不错”直接写成“规则已成立”。
+
+## 13. 轻量实验
+
+轻量实验可以减少文档数量，但不能没有目标、边界和结果记录。
+
+轻量实验最低要求：
+
+1. 在实验总纲或导读里登记。
+2. 写清目标和边界。
+3. 记录结果位置。
+4. 写清结论不能读到什么程度。
+
+如果轻量实验结果要进入正式决策，必须补齐实验设计、结果包入口和产物清单、审核报告。
+
+## 14. 交付标准
+
+一个正式实验完成的最低标准：
+
+1. 实验总纲存在。
+2. 实验设计存在，并通过设计审核。
+3. 实验执行日志或等价执行记录存在。
+4. 结果包存在，且入口已回写到实验总纲和实验设计。
+5. 实验审计报告存在，并通过执行审核。
+6. 结论边界明确。
+7. 来源聊天记录、实验目标、实验设计已经由审核员确认一致，或已明确记录不一致及处理方式。
+8. 必要结论已回写或记录待回写。
+
+缺少执行审核通过结论时，实验状态只能是 `待执行审核`、`执行审核未通过`、`暂停` 或 `HELD`，不能标为 `完成`。
diff --git "a/exp-doc/\345\256\236\351\252\214\350\256\276\350\256\241.md" "b/exp-doc/\345\256\236\351\252\214\350\256\276\350\256\241.md"
new file mode 100644
index 0000000..92d643c
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\350\256\276\350\256\241.md"
@@ -0,0 +1,116 @@
+# 实验设计模版
+
+创建人员：<填写创建人员或 AI>  
+文件职责：记录项目内所有实验的设计、步骤、依赖、产物、判定标准、设计审核和执行结果回填；对应管理系统里的事项计划账本。  
+管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验设计模版.md 实例化。  
+引用文件：<填写实验总纲、实验执行日志、实验审计报告、实验存储体系、来源聊天记录或上游文档>
+
+## 0. 当前设计总览
+
+> 本节用于快速查看当前正在推进的实验设计，可以随最新进展更新；详细设计记录仍必须追加到文件末尾。
+
+- 当前最新设计：<设计 ID / 实验事项 ID / 状态>
+- 当前可执行设计：<设计 ID 列表；必须已通过设计审核>
+- 当前阻断设计：<设计 ID / 阻断原因>
+- 当前下一步：<设计修订/等待审核/进入执行/暂停>
+
+## 0A. 文档定位和证据索引职责
+
+- 本文件是项目内具体实验设计与证据索引主入口。
+- 它负责回答：每个实验想解决什么问题、怎么验证、当前状态是什么、关键证据和结果包在哪里。
+- 实验总纲回答“为什么做和最后怎么读”；实验设计回答“具体怎么做、证据在哪里、结果包是什么”。
+- 后续新增实验、修订实验边界、回填执行结果，都应追加到本文件末尾，不得覆盖历史设计。
+
+## 1. 固定设计口径
+
+- 维护方式：append-only；新设计、新修订、新执行回填追加到文件末尾，最新内容在最后。
+- 旧设计处理：不得删除；若失效，追加“失效/降读/被替代”说明。
+- 设计与计划合并：本文件同时记录“要怎么验证”和“按什么步骤执行”。
+- 设计审核要求：设计审核通过后才能执行；未通过则追加修订块，不覆盖旧设计。
+- 路径规则：项目内文件默认使用相对路径。
+
+## 2. 实验设计追加区
+
+> 从这里开始按时间顺序追加。结构尽量像可执行计划，不要写成厚重需求文档。  
+> 每个实验设计块必须能回答：为什么这样跑、用什么数据、怎么判定、产物在哪里、审核状态是什么。
+
+## <YYYY-MM-DD> <设计 ID>：<实验名称>
+
+- 所属实验事项：<实验事项 ID / 名称>
+- 创建人员：<填写>
+- 创建时间：<YYYY-MM-DD HH:mm:ss>
+- 当前状态：<设计中/待设计审核/设计审核通过/执行中/完成/暂停/取消>
+- 当前结论：<当前阶段结论>
+- 来源聊天记录：<引用实验总纲中的关键聊天记录；如无说明原因>
+
+### 当前约定
+
+- 本轮要验证：<核心问题>
+- 本轮不验证：<排除范围>
+- 与来源聊天要求的一致性：<逐条说明如何承接用户要求>
+- 前置依赖：<前序实验、数据、文档、人工反馈>
+
+### 实验方法和样本
+
+- 核心假设：<填写>
+- 数据源：<数据路径、表、接口、版本>
+- 样本范围：<时间、对象、过滤条件>
+- 实验组：<如何构造>
+- 对照组：<如何构造；如不需要，说明原因>
+- 边界样本：<容易误判或需要专门观察的样本>
+- 防偏差要求：<样本污染、源数据切换、口径替换等>
+- 是否需要防未来函数：<是/否/不适用>
+- 判断理由：<根据实验目标说明为什么需要或不需要>
+
+### 执行顺序
+
+1. <步骤 ID>：<步骤名称；输入；输出；判定>
+2. <步骤 ID>：<步骤名称；输入；输出；判定>
+3. <步骤 ID>：<步骤名称；输入；输出；判定>
+
+### 字段、指标和状态
+
+| 名称 | 类型 | 定义 | 来源 | 计算/判定口径 | 输出位置 | 备注 |
+|---|---|---|---|---|---|---|
+| <字段/状态/指标> | <字段/状态/指标> | <填写> | <输入表/脚本/人工/外部> | <填写> | <结果包/summary/readout> | <可为空> |
+
+### 输出产物
+
+- 结果包目录：<路径>
+- 核心输出表：<路径/文件名>
+- 核心图表：<路径/文件名>
+- summary/readout：<路径/文件名>
+- manifest/输入快照：<路径/文件名>
+- 执行日志：`实验执行日志.md` 中 <run_id / 小节标题>
+
+### 判定标准
+
+- PASS：<什么结果算通过>
+- FAIL：<什么结果算失败>
+- HELD：<什么情况下只能暂挂，不能判断>
+- 降读规则：<结果不充分时如何降读>
+- 停止或转向条件：<什么情况下不继续跑，改为补数据/改设计/暂停>
+
+### 风险和不做事项
+
+- 关键风险：<样本不足、口径不稳、源数据缺失、计算成本高、人工审核未回收等>
+- 阻断项：<没有这些就不能继续的前置条件>
+- 可接受缺口：<不影响本轮目标的小缺口>
+- 本轮不做：<明确不做的事情>
+
+### 设计审核
+
+- 设计审核状态：<待审核/通过/未通过>
+- 审核人：<填写>
+- 审核时间：<YYYY-MM-DD HH:mm:ss>
+- 审核结论：<填写>
+- 未通过问题：<如无填写无>
+- 复审记录：<路径或摘要>
+
+### 执行结果回填
+
+- run_id：<填写；未执行则待补>
+- 结果包：<路径；未执行则待补>
+- 关键结果：<摘要>
+- 当前读法：<PASS/FAIL/HELD/降读/失效>
+- 是否纳入实验总纲结论：<是/否；说明>
diff --git "a/exp-doc/\345\256\236\351\252\214\351\227\256\351\242\230\350\256\260\345\275\225.md" "b/exp-doc/\345\256\236\351\252\214\351\227\256\351\242\230\350\256\260\345\275\225.md"
new file mode 100644
index 0000000..160b512
--- /dev/null
+++ "b/exp-doc/\345\256\236\351\252\214\351\227\256\351\242\230\350\256\260\345\275\225.md"
@@ -0,0 +1,71 @@
+# 实验问题记录模版
+
+创建人员：<填写创建人员或 AI>  
+文件职责：记录项目内非审计来源的实验设计、执行、数据、代码、结论问题及闭环状态；对需要跨轮跟踪的审计问题只记录索引或关联。  
+管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验问题记录模版.md 实例化。  
+引用文件：<填写实验审计报告、执行日志、实验总纲、实验设计>
+
+## 0. 当前问题总览
+
+- 当前开放问题数：<填写>
+- 当前阻断问题：<issue_id / 摘要>
+- 当前最新关闭问题：<issue_id / 摘要>
+- 当前下一步：<修复/复验/降读/暂停>
+
+## 1. 固定问题闭环口径
+
+- 维护方式：append-only；新问题、修复、复验、关闭都追加到文件末尾，最新内容在最后。
+- 历史问题处理：不得删除；误报也应追加“误报/不处理/降读”说明。
+- 问题分级：阻断 / 重要 / 一般。
+- 问题类型：设计 / 执行 / 数据 / 代码 / 结论 / 流程。
+- 审计问题口径：审核员发现的问题主记录写入 `实验审计报告.md`；本文件只记录需要跨轮跟踪的审计问题索引，不重复全文。
+- 非审计问题口径：实验员、执行 AI、人工同事或其他非审计角色发现的问题，主记录写入本文件。
+
+## 2. 问题记录追加区
+
+## <YYYY-MM-DD HH:mm:ss> <issue_id>：<问题标题>
+
+- 实验事项 ID：<填写>
+- 实验设计 ID：<填写>
+- run_id：<填写；如无写不适用>
+- 发现人：<填写>
+- 来源类型：<非审计反馈 / 审计问题索引>
+- 关联审计：<实验审计报告.md 中 audit_id；非审计反馈可写无>
+- 类型：<设计/执行/数据/代码/结论/流程>
+- 严重度：<阻断/重要/一般>
+- 当前状态：<待修/修复中/待复验/已关闭/暂停/误报>
+
+### 问题描述
+
+<写清问题是什么，不要只写现象。>
+
+### 证据
+
+- 证据路径：<路径>
+- 关键现象：<摘要>
+- 复现方式：<如适用>
+
+### 影响
+
+- 影响范围：<设计/执行/结果包/结论/下游>
+- 是否阻断实验完成：<是/否；说明>
+- 是否需要降读：<是/否；说明>
+
+### 建议修法
+
+<写清要改什么、由谁改、验收方式是什么。>
+
+### 修复和复验记录
+
+- 修复人：<填写>
+- 修复时间：<YYYY-MM-DD HH:mm:ss>
+- 修复内容：<填写>
+- 复验人：<填写>
+- 复验时间：<YYYY-MM-DD HH:mm:ss>
+- 复验结论：<通过/不通过/HELD>
+
+### 关闭结论
+
+- 是否关闭：<是/否>
+- 关闭原因：<填写>
+- 后续跟踪：<无/下一轮实验/长期观察>
diff --git "a/exp-doc/\347\233\256\345\275\225\345\257\274\350\257\273.md" "b/exp-doc/\347\233\256\345\275\225\345\257\274\350\257\273.md"
new file mode 100644
index 0000000..36c5be3
--- /dev/null
+++ "b/exp-doc/\347\233\256\345\275\225\345\257\274\350\257\273.md"
@@ -0,0 +1,46 @@
+# exp-doc 目录导读
+
+创建人员：Codex  
+文件职责：说明 `common/exp-doc` 目录下实验规范和实验模板文档的用途。  
+管理规范/模板：../../管理系统说明.md；../../体系说明.md；common/exp-doc/实验规范.md。  
+引用文件：实验规范.md；本目录下全部 `*模版.md` 文件。
+
+## 1. 目录定位
+
+本目录保存通用实验体系规范和实验体系模板。
+
+`实验规范.md` 是体系说明文件，不是模板。
+
+`*模版.md` 文件用于新项目或新实验事项创建时实例化对应实验文档。
+
+## 2. 文件清单
+
+| 文件 | 类型 | 作用 |
+|---|---|---|
+| 实验规范.md | 体系规范 | 说明实验体系核心流程、文档职责和审计闭环 |
+| 实验环境创建指南.md | 创建指南 | 指导 AI 在项目中创建完整实验员工作环境 |
+| 实验总纲模版.md | 模板 | 创建项目级实验总纲滚动账本 |
+| 实验设计模版.md | 模板 | 创建项目级实验设计滚动账本 |
+| 实验执行日志模版.md | 模板 | 创建项目级实验执行日志滚动账本 |
+| 实验存储体系创建指南.md | 创建指南 | 指导项目创建实验存储体系文档、数据目录、schema 和读取规则 |
+| 实验审核规范.md | 审核规范 | 定义实验设计审核、执行审核、复审和审计报告记录规则；项目内应实例化为 `实验审计规范.md` |
+| 实验审计报告模版.md | 模板 | 创建项目级实验审计报告滚动账本 |
+| 实验问题记录模版.md | 模板 | 创建项目级实验非审计问题闭环滚动账本；审计问题只做索引 |
+
+## 3. 使用顺序
+
+创建正式实验事项时，建议顺序：
+
+1. 先按 `实验环境创建指南.md` 在项目中创建实验环境。
+2. 用 `实验总纲模版.md` 创建项目级实验总纲。
+3. 用 `实验设计模版.md` 创建项目级实验设计。
+4. 设计审核通过后执行实验。
+5. 用 `实验执行日志模版.md` 记录执行。
+6. 将结果包入口回写到实验总纲和实验设计。
+7. 按 `实验存储体系创建指南.md` 建立或更新项目内 `实验存储体系.md`，并按该体系归档结果资产。
+8. 按 common `实验审核规范.md` 和项目本地 `实验审计规范.md` 审核设计和执行，并用 `实验审计报告模版.md` 创建或更新项目 `实验审计报告.md`。
+9. 非审计来源问题用 `实验问题记录模版.md` 处理闭环；审计员发现的问题主记录写入实验审计报告，必要时在问题记录中建索引。结论回写记录到实验总纲和审计报告。
+
+项目实验入口不再强制使用单独导读或总纲列表模板；AI 直接读取实验总纲即可。项目如果已有总索引，可在总索引里放实验总纲入口。
+
+所有项目级实验文档默认采用 append-only 方式维护：最新实验、最新设计、最新 run、最新审计和最新问题记录都追加到对应文件末尾。
diff --git a/mbx.project.yaml b/mbx.project.yaml
index 1fd7b63..bce4c4d 100644
--- a/mbx.project.yaml
+++ b/mbx.project.yaml
@@ -436,8 +436,23 @@
   name: 案例分析体系
   template: ana-doc
   status: enabled
-  dirs: []
-  docs: {}
+  dirs:
+  - ana-doc
+  - ana-data
+  - ana-data/cases
+  - ana-data/result
+  - ana-data/img
+  - ana-data/tmp
+  docs:
+    guide: ana-doc/目录导读.md
+    spec: ana-doc/案例分析规范.md
+    review_spec: ana-doc/案例审核规范.md
+    overview: ana-doc/案例总纲.md
+    design: ana-doc/案例分析设计.md
+    log: ana-doc/案例执行日志.md
+    audit: ana-doc/案例审计报告.md
+    issues: ana-doc/案例问题记录.md
+    storage: ana-doc/案例存储体系.md
   roles:
   - case_analysis.analyst
   - case_analysis.reviewer
@@ -445,8 +460,24 @@
   name: 实验体系
   template: exp-doc
   status: enabled
-  dirs: []
-  docs: {}
+  dirs:
+  - exp-doc
+  - exp-data
+  - exp-data/raw
+  - exp-data/result
+  - exp-data/img
+  - exp-data/tmp
+  docs:
+    guide: exp-doc/目录导读.md
+    spec: exp-doc/实验规范.md
+    review_spec: exp-doc/实验审核规范.md
+    audit_spec: exp-doc/实验审计规范.md
+    storage: exp-doc/实验存储体系.md
+    overview: exp-doc/实验总纲.md
+    design: exp-doc/实验设计.md
+    log: exp-doc/实验执行日志.md
+    audit: exp-doc/实验审计报告.md
+    issues: exp-doc/实验问题记录.md
   roles:
   - experiment.reviewer
   - experiment.experimenter
diff --git a/mbx.project.yaml.bak b/mbx.project.yaml.bak
index fb127f7..a3f6c6f 100644
--- a/mbx.project.yaml.bak
+++ b/mbx.project.yaml.bak
@@ -146,12 +146,15 @@
     id: 019ef550-45ac-7b43-aa24-2731d01dba9b
     status: active
     created_at: '2026-06-24T00:30:59+08:00'
-    updated_at: '2026-06-24T00:30:59+08:00'
+    updated_at: '2026-06-24T00:32:59+08:00'
     created_by: workspace-admin
     provider: codex
-    delivery_mode: interactive
-    process_id: 62456
+    delivery_mode: codex_app_server_remote_tui
+    process_id: 34248
     session_file: C:\Users\Administrator\.codex3\sessions\2026\06\24\rollout-2026-06-24T00-28-59-019ef550-45ac-7b43-aa24-2731d01dba9b.jsonl
+    thread_id: 019ef550-45ac-7b43-aa24-2731d01dba9b
+    app_server_url: ws://127.0.0.1:4570
+    remote_tui_pid: 34248
   status: active
   audit_entry: ana-doc/案例审计报告.md
   assigned_by: management.admin
@@ -193,12 +196,15 @@
     id: 019ef54e-6978-76d3-bb78-081fa2c4b188
     status: active
     created_at: '2026-06-24T00:28:58+08:00'
-    updated_at: '2026-06-24T00:28:58+08:00'
+    updated_at: '2026-06-24T00:32:26+08:00'
     created_by: workspace-admin
     provider: codex
-    delivery_mode: interactive
-    process_id: 47920
+    delivery_mode: codex_app_server_remote_tui
+    process_id: 59724
     session_file: C:\Users\Administrator\.codex3\sessions\2026\06\24\rollout-2026-06-24T00-26-57-019ef54e-6978-76d3-bb78-081fa2c4b188.jsonl
+    thread_id: 019ef54e-6978-76d3-bb78-081fa2c4b188
+    app_server_url: ws://127.0.0.1:4570
+    remote_tui_pid: 59724
   status: active
   assigned_by: management.admin
   assignment_reason: project-info 初始化：laoyan 负责股市信息实验执行与对应开发。
@@ -237,12 +243,15 @@
     id: 019ef54e-6978-76d3-bb78-081fa2c4b188
     status: active
     created_at: '2026-06-24T00:28:58+08:00'
-    updated_at: '2026-06-24T00:28:58+08:00'
+    updated_at: '2026-06-24T00:32:26+08:00'
     created_by: workspace-admin
     provider: codex
-    delivery_mode: interactive
-    process_id: 47920
+    delivery_mode: codex_app_server_remote_tui
+    process_id: 59724
     session_file: C:\Users\Administrator\.codex3\sessions\2026\06\24\rollout-2026-06-24T00-26-57-019ef54e-6978-76d3-bb78-081fa2c4b188.jsonl
+    thread_id: 019ef54e-6978-76d3-bb78-081fa2c4b188
+    app_server_url: ws://127.0.0.1:4570
+    remote_tui_pid: 59724
   status: active
   dev_target: ana
   assigned_by: management.admin
@@ -285,12 +294,15 @@
     id: 019ef550-45ac-7b43-aa24-2731d01dba9b
     status: active
     created_at: '2026-06-24T00:30:59+08:00'
-    updated_at: '2026-06-24T00:30:59+08:00'
+    updated_at: '2026-06-24T00:32:59+08:00'
     created_by: workspace-admin
     provider: codex
-    delivery_mode: interactive
-    process_id: 62456
+    delivery_mode: codex_app_server_remote_tui
+    process_id: 34248
     session_file: C:\Users\Administrator\.codex3\sessions\2026\06\24\rollout-2026-06-24T00-28-59-019ef550-45ac-7b43-aa24-2731d01dba9b.jsonl
+    thread_id: 019ef550-45ac-7b43-aa24-2731d01dba9b
+    app_server_url: ws://127.0.0.1:4570
+    remote_tui_pid: 34248
   status: active
   dev_target: ana
   audit_entry: ana-doc/案例审计报告.md
@@ -337,12 +349,15 @@
     id: 019ef54e-6978-76d3-bb78-081fa2c4b188
     status: active
     created_at: '2026-06-24T00:28:58+08:00'
-    updated_at: '2026-06-24T00:28:58+08:00'
+    updated_at: '2026-06-24T00:32:26+08:00'
     created_by: workspace-admin
     provider: codex
-    delivery_mode: interactive
-    process_id: 47920
+    delivery_mode: codex_app_server_remote_tui
+    process_id: 59724
     session_file: C:\Users\Administrator\.codex3\sessions\2026\06\24\rollout-2026-06-24T00-26-57-019ef54e-6978-76d3-bb78-081fa2c4b188.jsonl
+    thread_id: 019ef54e-6978-76d3-bb78-081fa2c4b188
+    app_server_url: ws://127.0.0.1:4570
+    remote_tui_pid: 59724
   status: active
   dev_target: exp
   assigned_by: management.admin
@@ -385,12 +400,15 @@
     id: 019ef550-45ac-7b43-aa24-2731d01dba9b
     status: active
     created_at: '2026-06-24T00:30:59+08:00'
-    updated_at: '2026-06-24T00:30:59+08:00'
+    updated_at: '2026-06-24T00:32:59+08:00'
     created_by: workspace-admin
     provider: codex
-    delivery_mode: interactive
-    process_id: 62456
+    delivery_mode: codex_app_server_remote_tui
+    process_id: 34248
     session_file: C:\Users\Administrator\.codex3\sessions\2026\06\24\rollout-2026-06-24T00-28-59-019ef550-45ac-7b43-aa24-2731d01dba9b.jsonl
+    thread_id: 019ef550-45ac-7b43-aa24-2731d01dba9b
+    app_server_url: ws://127.0.0.1:4570
+    remote_tui_pid: 34248
   status: active
   dev_target: exp
   audit_entry: exp-doc/实验审计报告.md
@@ -418,8 +436,23 @@
   name: 案例分析体系
   template: ana-doc
   status: enabled
-  dirs: []
-  docs: {}
+  dirs:
+  - ana-doc
+  - ana-data
+  - ana-data/cases
+  - ana-data/result
+  - ana-data/img
+  - ana-data/tmp
+  docs:
+    guide: ana-doc/目录导读.md
+    spec: ana-doc/案例分析规范.md
+    review_spec: ana-doc/案例审核规范.md
+    overview: ana-doc/案例总纲.md
+    design: ana-doc/案例分析设计.md
+    log: ana-doc/案例执行日志.md
+    audit: ana-doc/案例审计报告.md
+    issues: ana-doc/案例问题记录.md
+    storage: ana-doc/案例存储体系.md
   roles:
   - case_analysis.analyst
   - case_analysis.reviewer
diff --git "a/\351\241\271\347\233\256\344\272\213\351\241\271\345\256\241\350\256\241\346\212\245\345\221\212.md" "b/\351\241\271\347\233\256\344\272\213\351\241\271\345\256\241\350\256\241\346\212\245\345\221\212.md"
index 94746f5..5637680 100644
--- "a/\351\241\271\347\233\256\344\272\213\351\241\271\345\256\241\350\256\241\346\212\245\345\221\212.md"
+++ "b/\351\241\271\347\233\256\344\272\213\351\241\271\345\256\241\350\256\241\346\212\245\345\221\212.md"
@@ -444,3 +444,29 @@
   - 模板源：D:\manage_system\common
   - 角色数量：8
   - 刷新角色：case_analysis.analyst, experiment.reviewer, case_analysis.reviewer, experiment.experimenter, dev.developer.ana, dev.reviewer.ana, dev.developer.exp, dev.reviewer.exp
+
+## 2026-06-25T20:33:32+08:00 启用体系 case_analysis
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 case_analysis，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：case_analysis
+  - 新增目录：ana-doc, ana-data, ana-data/cases, ana-data/result, ana-data/img, ana-data/tmp
+  - 新增文档：ana-doc/目录导读.md, ana-doc/案例分析规范.md, ana-doc/案例审核规范.md, ana-doc/案例总纲.md, ana-doc/案例分析设计.md, ana-doc/案例执行日志.md, ana-doc/案例审计报告.md, ana-doc/案例问题记录.md, ana-doc/案例存储体系.md
+  - 新增角色：none
+
+## 2026-06-25T20:33:33+08:00 启用体系 experiment
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 experiment，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：experiment
+  - 新增目录：exp-doc, exp-data, exp-data/raw, exp-data/result, exp-data/img, exp-data/tmp
+  - 新增文档：exp-doc/目录导读.md, exp-doc/实验规范.md, exp-doc/实验审核规范.md, exp-doc/实验审计规范.md, exp-doc/实验存储体系.md, exp-doc/实验总纲.md, exp-doc/实验设计.md, exp-doc/实验执行日志.md, exp-doc/实验审计报告.md, exp-doc/实验问题记录.md
+  - 新增角色：none
diff --git "a/\351\241\271\347\233\256\344\272\213\351\241\271\346\200\273\347\272\262.md" "b/\351\241\271\347\233\256\344\272\213\351\241\271\346\200\273\347\272\262.md"
index e557fcf..42291ee 100644
--- "a/\351\241\271\347\233\256\344\272\213\351\241\271\346\200\273\347\272\262.md"
+++ "b/\351\241\271\347\233\256\344\272\213\351\241\271\346\200\273\347\272\262.md"
@@ -432,3 +432,29 @@
   - 模板源：D:\manage_system\common
   - 角色数量：8
   - 刷新角色：case_analysis.analyst, experiment.reviewer, case_analysis.reviewer, experiment.experimenter, dev.developer.ana, dev.reviewer.ana, dev.developer.exp, dev.reviewer.exp
+
+## 2026-06-25T20:33:32+08:00 启用体系 case_analysis
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 case_analysis，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：case_analysis
+  - 新增目录：ana-doc, ana-data, ana-data/cases, ana-data/result, ana-data/img, ana-data/tmp
+  - 新增文档：ana-doc/目录导读.md, ana-doc/案例分析规范.md, ana-doc/案例审核规范.md, ana-doc/案例总纲.md, ana-doc/案例分析设计.md, ana-doc/案例执行日志.md, ana-doc/案例审计报告.md, ana-doc/案例问题记录.md, ana-doc/案例存储体系.md
+  - 新增角色：none
+
+## 2026-06-25T20:33:33+08:00 启用体系 experiment
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 experiment，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：experiment
+  - 新增目录：exp-doc, exp-data, exp-data/raw, exp-data/result, exp-data/img, exp-data/tmp
+  - 新增文档：exp-doc/目录导读.md, exp-doc/实验规范.md, exp-doc/实验审核规范.md, exp-doc/实验审计规范.md, exp-doc/实验存储体系.md, exp-doc/实验总纲.md, exp-doc/实验设计.md, exp-doc/实验执行日志.md, exp-doc/实验审计报告.md, exp-doc/实验问题记录.md
+  - 新增角色：none
diff --git "a/\351\241\271\347\233\256\344\272\213\351\241\271\350\256\241\345\210\222.md" "b/\351\241\271\347\233\256\344\272\213\351\241\271\350\256\241\345\210\222.md"
index 443e3fc..29b50e3 100644
--- "a/\351\241\271\347\233\256\344\272\213\351\241\271\350\256\241\345\210\222.md"
+++ "b/\351\241\271\347\233\256\344\272\213\351\241\271\350\256\241\345\210\222.md"
@@ -428,3 +428,29 @@
   - 模板源：D:\manage_system\common
   - 角色数量：8
   - 刷新角色：case_analysis.analyst, experiment.reviewer, case_analysis.reviewer, experiment.experimenter, dev.developer.ana, dev.reviewer.ana, dev.developer.exp, dev.reviewer.exp
+
+## 2026-06-25T20:33:32+08:00 启用体系 case_analysis
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 case_analysis，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：case_analysis
+  - 新增目录：ana-doc, ana-data, ana-data/cases, ana-data/result, ana-data/img, ana-data/tmp
+  - 新增文档：ana-doc/目录导读.md, ana-doc/案例分析规范.md, ana-doc/案例审核规范.md, ana-doc/案例总纲.md, ana-doc/案例分析设计.md, ana-doc/案例执行日志.md, ana-doc/案例审计报告.md, ana-doc/案例问题记录.md, ana-doc/案例存储体系.md
+  - 新增角色：none
+
+## 2026-06-25T20:33:33+08:00 启用体系 experiment
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 experiment，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：experiment
+  - 新增目录：exp-doc, exp-data, exp-data/raw, exp-data/result, exp-data/img, exp-data/tmp
+  - 新增文档：exp-doc/目录导读.md, exp-doc/实验规范.md, exp-doc/实验审核规范.md, exp-doc/实验审计规范.md, exp-doc/实验存储体系.md, exp-doc/实验总纲.md, exp-doc/实验设计.md, exp-doc/实验执行日志.md, exp-doc/实验审计报告.md, exp-doc/实验问题记录.md
+  - 新增角色：none
diff --git "a/\351\241\271\347\233\256\345\217\230\346\233\264\350\256\260\345\275\225.md" "b/\351\241\271\347\233\256\345\217\230\346\233\264\350\256\260\345\275\225.md"
index d9788d4..182cfd6 100644
--- "a/\351\241\271\347\233\256\345\217\230\346\233\264\350\256\260\345\275\225.md"
+++ "b/\351\241\271\347\233\256\345\217\230\346\233\264\350\256\260\345\275\225.md"
@@ -415,3 +415,29 @@
   - 模板源：D:\manage_system\common
   - 角色数量：8
   - 刷新角色：case_analysis.analyst, experiment.reviewer, case_analysis.reviewer, experiment.experimenter, dev.developer.ana, dev.reviewer.ana, dev.developer.exp, dev.reviewer.exp
+
+## 2026-06-25T20:33:32+08:00 启用体系 case_analysis
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 case_analysis，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：case_analysis
+  - 新增目录：ana-doc, ana-data, ana-data/cases, ana-data/result, ana-data/img, ana-data/tmp
+  - 新增文档：ana-doc/目录导读.md, ana-doc/案例分析规范.md, ana-doc/案例审核规范.md, ana-doc/案例总纲.md, ana-doc/案例分析设计.md, ana-doc/案例执行日志.md, ana-doc/案例审计报告.md, ana-doc/案例问题记录.md, ana-doc/案例存储体系.md
+  - 新增角色：none
+
+## 2026-06-25T20:33:33+08:00 启用体系 experiment
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 experiment，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：experiment
+  - 新增目录：exp-doc, exp-data, exp-data/raw, exp-data/result, exp-data/img, exp-data/tmp
+  - 新增文档：exp-doc/目录导读.md, exp-doc/实验规范.md, exp-doc/实验审核规范.md, exp-doc/实验审计规范.md, exp-doc/实验存储体系.md, exp-doc/实验总纲.md, exp-doc/实验设计.md, exp-doc/实验执行日志.md, exp-doc/实验审计报告.md, exp-doc/实验问题记录.md
+  - 新增角色：none
diff --git "a/\351\241\271\347\233\256\346\211\247\350\241\214\346\227\245\345\277\227.md" "b/\351\241\271\347\233\256\346\211\247\350\241\214\346\227\245\345\277\227.md"
index a5a1f80..b1b8354 100644
--- "a/\351\241\271\347\233\256\346\211\247\350\241\214\346\227\245\345\277\227.md"
+++ "b/\351\241\271\347\233\256\346\211\247\350\241\214\346\227\245\345\277\227.md"
@@ -412,3 +412,64 @@
   - 模板源：D:\manage_system\common
   - 角色数量：8
   - 刷新角色：case_analysis.analyst, experiment.reviewer, case_analysis.reviewer, experiment.experimenter, dev.developer.ana, dev.reviewer.ana, dev.developer.exp, dev.reviewer.exp
+
+## 2026-06-25T20:33:32+08:00 启用体系 case_analysis
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 case_analysis，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：case_analysis
+  - 新增目录：ana-doc, ana-data, ana-data/cases, ana-data/result, ana-data/img, ana-data/tmp
+  - 新增文档：ana-doc/目录导读.md, ana-doc/案例分析规范.md, ana-doc/案例审核规范.md, ana-doc/案例总纲.md, ana-doc/案例分析设计.md, ana-doc/案例执行日志.md, ana-doc/案例审计报告.md, ana-doc/案例问题记录.md, ana-doc/案例存储体系.md
+  - 新增角色：none
+
+## 2026-06-25T20:33:33+08:00 启用体系 experiment
+
+- 动作：system.enabled
+- 项目：project-info
+- 执行者：workspace-admin
+- 结果：完成
+- 摘要：项目启用体系 experiment，并按模板补齐目录、文档和默认角色。
+- 详情：
+  - 体系：experiment
+  - 新增目录：exp-doc, exp-data, exp-data/raw, exp-data/result, exp-data/img, exp-data/tmp
+  - 新增文档：exp-doc/目录导读.md, exp-doc/实验规范.md, exp-doc/实验审核规范.md, exp-doc/实验审计规范.md, exp-doc/实验存储体系.md, exp-doc/实验总纲.md, exp-doc/实验设计.md, exp-doc/实验执行日志.md, exp-doc/实验审计报告.md, exp-doc/实验问题记录.md
+  - 新增角色：none
+
+## 2026-06-25 20:36:00 PROJECT-INFO-SYSTEM-DOCS-REPAIR：补齐案例分析体系和实验体系目录
+
+所属项目：
+project-info / info
+
+执行人员：
+management.admin
+
+动作类型：
+体系环境补建 / 模板实例化 / 治理复验
+
+执行目标：
+补齐已登记但未完整落地的 `ana-doc/ana-data` 与 `exp-doc/exp-data`，使案例分析体系和实验体系具备正式工作入口。
+
+执行过程：
+
+1. 核查 `python -m mbx.cli system status --project project-info`，确认 `case_analysis`、`experiment`、`dev` 已在机器配置中启用。
+2. 核查项目根目录，发现此前缺少 `ana-doc/`、`ana-data/`、`exp-doc/`、`exp-data/`，仅存在开发体系配套的 `dev-doc/ana-doc` 与 `dev-doc/exp-doc`。
+3. 执行 `mbx system enable` 重新登记并创建案例分析体系目录、数据目录和文档映射。
+4. 执行 `mbx system enable` 重新登记并创建实验体系目录、数据目录和文档映射。
+5. 使用 `common/ana-doc` 与 `common/exp-doc` 模板实例化项目本地体系文档，替换 MB-X 初始占位文档。
+6. 执行 `python -m mbx.cli validate --project project-info --governance`，结果通过，warnings=0。
+
+关键输出：
+
+- 案例分析体系入口：`ana-doc/`、`ana-data/cases/`、`ana-data/result/`、`ana-data/img/`、`ana-data/tmp/`
+- 实验体系入口：`exp-doc/`、`exp-data/raw/`、`exp-data/result/`、`exp-data/img/`、`exp-data/tmp/`
+- 治理校验：OK，warnings=0
+
+异常 / 偏离：
+
+- 初始创建时只完成了体系配置、角色和会话绑定，未完整落地根目录体系文档与数据目录；本次已补齐。
+
+当前状态：完成。
diff --git "a/\351\241\271\347\233\256\351\205\215\347\275\256\346\270\205\345\215\225.md" "b/\351\241\271\347\233\256\351\205\215\347\275\256\346\270\205\345\215\225.md"
index 9c595b8..857a5db 100644
--- "a/\351\241\271\347\233\256\351\205\215\347\275\256\346\270\205\345\215\225.md"
+++ "b/\351\241\271\347\233\256\351\205\215\347\275\256\346\270\205\345\215\225.md"
@@ -45,6 +45,18 @@
 
 | 目录 | 类型 | 说明 |
 |---|---|---|
+| ana-doc/ | system:case_analysis | 案例分析体系 |
+| ana-data/ | system:case_analysis | 案例分析体系 |
+| ana-data/cases/ | system:case_analysis | 案例分析体系 |
+| ana-data/result/ | system:case_analysis | 案例分析体系 |
+| ana-data/img/ | system:case_analysis | 案例分析体系 |
+| ana-data/tmp/ | system:case_analysis | 案例分析体系 |
+| exp-doc/ | system:experiment | 实验体系 |
+| exp-data/ | system:experiment | 实验体系 |
+| exp-data/raw/ | system:experiment | 实验体系 |
+| exp-data/result/ | system:experiment | 实验体系 |
+| exp-data/img/ | system:experiment | 实验体系 |
+| exp-data/tmp/ | system:experiment | 实验体系 |
 | ai-laoyan/ | ai-workspace | laoyan 私有工作空间 |
 | ai-laoshen/ | ai-workspace | laoshen 私有工作空间 |
 | ai-laoyan/ | role-private | case_analysis.analyst 绑定工作空间 |

--
Gitblit v1.9.3