parent: df3b9d10 | patch | commit | ignore whitespace
1
2026-06-25 e87cfdcb76a359d217130b33ffb4ed917b64d230 
fix: rebuild project-info system documents
23 files modified
3414 ■■■■■ changed files
.gitignore 2 ●●●●● patch | view | raw | blame | history
.mbx/messages.jsonl 12 ●●●●● patch | view | raw | blame | history
ana-doc/案例分析规范.md 241 ●●●●● patch | view | raw | blame | history
ana-doc/案例分析设计.md 99 ●●●●● patch | view | raw | blame | history
ana-doc/案例存储体系.md 151 ●●●●● patch | view | raw | blame | history
ana-doc/案例审核规范.md 153 ●●●●● patch | view | raw | blame | history
ana-doc/案例审计报告.md 88 ●●●●● patch | view | raw | blame | history
ana-doc/案例总纲.md 80 ●●●●● patch | view | raw | blame | history
ana-doc/案例执行日志.md 91 ●●●●● patch | view | raw | blame | history
ana-doc/案例问题记录.md 66 ●●●●● patch | view | raw | blame | history
ana-doc/目录导读.md 70 ●●●●● patch | view | raw | blame | history
exp-doc/实验存储体系.md 268 ●●●●● patch | view | raw | blame | history
exp-doc/实验审核规范.md 457 ●●●●● patch | view | raw | blame | history
exp-doc/实验审计报告.md 89 ●●●●● patch | view | raw | blame | history
exp-doc/实验审计规范.md 457 ●●●●● patch | view | raw | blame | history
exp-doc/实验总纲.md 114 ●●●●● patch | view | raw | blame | history
exp-doc/实验执行日志.md 105 ●●●●● patch | view | raw | blame | history
exp-doc/实验规范.md 508 ●●●●● patch | view | raw | blame | history
exp-doc/实验设计.md 131 ●●●●● patch | view | raw | blame | history
exp-doc/实验问题记录.md 81 ●●●●● patch | view | raw | blame | history
exp-doc/目录导读.md 68 ●●●●● patch | view | raw | blame | history
项目事项审计报告.md 44 ●●●●● patch | view | raw | blame | history
项目执行日志.md 39 ●●●●● patch | view | raw | blame | history 
 .gitignore


@@ -1,4 +1,6 @@


.mbx/provider/


.mbx/runtime/


.mbx/inbox/


ai-*/tmp/


*.tmp


*.log




 .mbx/messages.jsonl


@@ -42,3 +42,15 @@


{"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"}}


{"schema_version":"1.0","event_id":"evt_20260625204339662_63b469af","event_type":"message.created","message_id":"msg_20260625204339662_99c52dd1","message_type":"review_request","scope":"project","project_id":"project-info","system_id":"case_analysis","role_instance_id":"case_analysis.analyst","role_id":"case_analysis.analyst","task_id":"PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW","correlation_id":"msg_20260625204339662_99c52dd1","causation_id":null,"parent_message_id":null,"status":"created","created_at":"2026-06-25T20:43:39+08:00","actor":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"from":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"to":[{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"}],"content":{"format":"markdown","text":"任务：PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis.reviewer / experiment.reviewer / dev.reviewer.ana / dev.reviewer.exp 共享审核员）\n\n摘要：\nmanagement.admin 已补建 project-info 中此前漏落地的案例分析体系和实验体系根目录文档及数据目录。请审核本次补建是否完整、是否符合 MB-X 体系规范，是否还有漏项。\n\n请重点核查：\n1. `mbx.project.yaml` 中 `case_analysis`、`experiment` 的 `dirs` / `docs` 是否登记完整，且与实际文件系统一致。\n2. `ana-doc/` 是否包含案例分析规范、案例审核规范、案例总纲、案例分析设计、案例执行日志、案例审计报告、案例问题记录、案例存储体系、目录导读。\n3. `ana-data/` 是否包含 `cases/`、`result/`、`img/`、`tmp/`，并有 `.gitkeep` 保证 Git 克隆后目录存在。\n4. `exp-doc/` 是否包含实验规范、实验审核规范、实验审计规范、实验存储体系、实验总纲、实验设计、实验执行日志、实验审计报告、实验问题记录、目录导读。\n5. `exp-data/` 是否包含 `raw/`、`result/`、`img/`、`tmp/`，并有 `.gitkeep` 保证 Git 克隆后目录存在。\n6. `dev_targets` 中 `ana` / `exp` 的审计入口是否分别指向 `ana-doc/案例审计报告.md`、`exp-doc/实验审计报告.md`。\n7. `项目配置清单.md`、`项目执行日志.md`、`项目事项审计报告.md` 等项目级文档是否同步反映本次补建。\n8. `python -m mbx.cli validate --project project-info --governance` 当前通过是否足够，是否还应补人工 dry-run 或补充审计记录。\n9. 本次已推送远端提交 `df3b9d1 fix: add analysis and experiment systems`，请核查是否还有应提交但漏提交的体系文件。\n\n已知背景：\n- 初始创建时体系和角色已登记，但 `ana-doc/ana-data` 与 `exp-doc/exp-data` 未完整落地。\n- management.admin 已执行两次 `mbx system enable` 补登记目录和文档映射。\n- 已用 `common/ana-doc` 与 `common/exp-doc` 模板实例化项目本地体系文档。\n- 已执行治理校验，结果 OK，warnings=0。\n\n期望输出：\n请将审核结论写入 `project-info/项目事项审计报告.md` 或对应体系审计报告；同时通过 MB-X 消息回复 management.admin：\n- 结论：通过 / 有条件通过 / 不通过\n- 发现的问题清单\n- 是否需要 management.admin 继续修复\n- 证据入口和命令摘要\n","data":null,"ref":null,"summary":"任务：PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis."},"refs":[],"expected_response":null,"routing":null,"result":null,"ext":{}}


{"schema_version":"1.0","event_id":"evt_20260625204339664_e9f8c711","event_type":"message.routed","message_id":"msg_20260625204339662_99c52dd1","message_type":"review_request","scope":"project","project_id":"project-info","system_id":"case_analysis","role_instance_id":"case_analysis.analyst","role_id":"case_analysis.analyst","task_id":"PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW","correlation_id":"msg_20260625204339662_99c52dd1","causation_id":"evt_20260625204339662_63b469af","parent_message_id":null,"status":"routed","created_at":"2026-06-25T20:43:39+08:00","actor":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"from":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"to":[{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"}],"content":{"format":"markdown","text":"任务：PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis.reviewer / experiment.reviewer / dev.reviewer.ana / dev.reviewer.exp 共享审核员）\n\n摘要：\nmanagement.admin 已补建 project-info 中此前漏落地的案例分析体系和实验体系根目录文档及数据目录。请审核本次补建是否完整、是否符合 MB-X 体系规范，是否还有漏项。\n\n请重点核查：\n1. `mbx.project.yaml` 中 `case_analysis`、`experiment` 的 `dirs` / `docs` 是否登记完整，且与实际文件系统一致。\n2. `ana-doc/` 是否包含案例分析规范、案例审核规范、案例总纲、案例分析设计、案例执行日志、案例审计报告、案例问题记录、案例存储体系、目录导读。\n3. `ana-data/` 是否包含 `cases/`、`result/`、`img/`、`tmp/`，并有 `.gitkeep` 保证 Git 克隆后目录存在。\n4. `exp-doc/` 是否包含实验规范、实验审核规范、实验审计规范、实验存储体系、实验总纲、实验设计、实验执行日志、实验审计报告、实验问题记录、目录导读。\n5. `exp-data/` 是否包含 `raw/`、`result/`、`img/`、`tmp/`，并有 `.gitkeep` 保证 Git 克隆后目录存在。\n6. `dev_targets` 中 `ana` / `exp` 的审计入口是否分别指向 `ana-doc/案例审计报告.md`、`exp-doc/实验审计报告.md`。\n7. `项目配置清单.md`、`项目执行日志.md`、`项目事项审计报告.md` 等项目级文档是否同步反映本次补建。\n8. `python -m mbx.cli validate --project project-info --governance` 当前通过是否足够，是否还应补人工 dry-run 或补充审计记录。\n9. 本次已推送远端提交 `df3b9d1 fix: add analysis and experiment systems`，请核查是否还有应提交但漏提交的体系文件。\n\n已知背景：\n- 初始创建时体系和角色已登记，但 `ana-doc/ana-data` 与 `exp-doc/exp-data` 未完整落地。\n- management.admin 已执行两次 `mbx system enable` 补登记目录和文档映射。\n- 已用 `common/ana-doc` 与 `common/exp-doc` 模板实例化项目本地体系文档。\n- 已执行治理校验，结果 OK，warnings=0。\n\n期望输出：\n请将审核结论写入 `project-info/项目事项审计报告.md` 或对应体系审计报告；同时通过 MB-X 消息回复 management.admin：\n- 结论：通过 / 有条件通过 / 不通过\n- 发现的问题清单\n- 是否需要 management.admin 继续修复\n- 证据入口和命令摘要\n","data":null,"ref":null,"summary":"任务：PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis."},"refs":[],"expected_response":null,"routing":{"mode":"session","resolved":true,"target_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","source_role_instance_id":"case_analysis.analyst","source_system_id":"case_analysis","target_role_instance_id":"case_analysis.reviewer","target_system_id":"case_analysis"},"result":null,"ext":{}}


{"schema_version":"1.0","event_id":"evt_20260625204339666_1f0f4975","event_type":"message.delivered","message_id":"msg_20260625204339662_99c52dd1","message_type":"review_request","scope":"project","project_id":"project-info","system_id":"case_analysis","role_instance_id":"case_analysis.reviewer","role_id":"case_analysis.reviewer","task_id":"PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW","correlation_id":"msg_20260625204339662_99c52dd1","causation_id":"evt_20260625204339664_e9f8c711","parent_message_id":null,"status":"delivered","created_at":"2026-06-25T20:43:39+08:00","actor":{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"},"from":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"to":[{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"}],"content":{"format":"markdown","text":"任务：PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis.reviewer / experiment.reviewer / dev.reviewer.ana / dev.reviewer.exp 共享审核员）\n\n摘要：\nmanagement.admin 已补建 project-info 中此前漏落地的案例分析体系和实验体系根目录文档及数据目录。请审核本次补建是否完整、是否符合 MB-X 体系规范，是否还有漏项。\n\n请重点核查：\n1. `mbx.project.yaml` 中 `case_analysis`、`experiment` 的 `dirs` / `docs` 是否登记完整，且与实际文件系统一致。\n2. `ana-doc/` 是否包含案例分析规范、案例审核规范、案例总纲、案例分析设计、案例执行日志、案例审计报告、案例问题记录、案例存储体系、目录导读。\n3. `ana-data/` 是否包含 `cases/`、`result/`、`img/`、`tmp/`，并有 `.gitkeep` 保证 Git 克隆后目录存在。\n4. `exp-doc/` 是否包含实验规范、实验审核规范、实验审计规范、实验存储体系、实验总纲、实验设计、实验执行日志、实验审计报告、实验问题记录、目录导读。\n5. `exp-data/` 是否包含 `raw/`、`result/`、`img/`、`tmp/`，并有 `.gitkeep` 保证 Git 克隆后目录存在。\n6. `dev_targets` 中 `ana` / `exp` 的审计入口是否分别指向 `ana-doc/案例审计报告.md`、`exp-doc/实验审计报告.md`。\n7. `项目配置清单.md`、`项目执行日志.md`、`项目事项审计报告.md` 等项目级文档是否同步反映本次补建。\n8. `python -m mbx.cli validate --project project-info --governance` 当前通过是否足够，是否还应补人工 dry-run 或补充审计记录。\n9. 本次已推送远端提交 `df3b9d1 fix: add analysis and experiment systems`，请核查是否还有应提交但漏提交的体系文件。\n\n已知背景：\n- 初始创建时体系和角色已登记，但 `ana-doc/ana-data` 与 `exp-doc/exp-data` 未完整落地。\n- management.admin 已执行两次 `mbx system enable` 补登记目录和文档映射。\n- 已用 `common/ana-doc` 与 `common/exp-doc` 模板实例化项目本地体系文档。\n- 已执行治理校验，结果 OK，warnings=0。\n\n期望输出：\n请将审核结论写入 `project-info/项目事项审计报告.md` 或对应体系审计报告；同时通过 MB-X 消息回复 management.admin：\n- 结论：通过 / 有条件通过 / 不通过\n- 发现的问题清单\n- 是否需要 management.admin 继续修复\n- 证据入口和命令摘要\n","data":null,"ref":null,"summary":"任务：PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis."},"refs":[],"expected_response":null,"routing":{"mode":"session","resolved":true,"target_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","delivery":"inbox","source_role_instance_id":"case_analysis.analyst","source_system_id":"case_analysis","target_role_instance_id":"case_analysis.reviewer","target_system_id":"case_analysis"},"result":{"delivery":"inbox","inbox_path":".mbx/inbox/case_analysis.reviewer.jsonl"},"ext":{}}


{"schema_version":"1.0","event_id":"evt_20260625204339908_a72becf5","event_type":"managed_session.dispatch.started","scope":"project","project_id":"project-info","role_instance_id":"case_analysis.reviewer","created_at":"2026-06-25T20:43:39+08:00","status":"running","actor":{"type":"runtime","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"MB-X managed session runtime"},"message_id":"msg_20260625204339662_99c52dd1","result":{"managed_session_key":"project-info.laoshen","project_id":"project-info","role_instance_id":"case_analysis.reviewer","ai_id":"laoshen","provider_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","transport":"codex_app_server_remote_tui","thread_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","lease_id":"lease_20260625204339907_a57d6e1f","app_server_url":"ws://127.0.0.1:4570"}}


{"schema_version":"1.0","event_id":"evt_20260625204339917_c2485cd5","event_type":"managed_session.dispatch.completed","scope":"project","project_id":"project-info","role_instance_id":"case_analysis.reviewer","created_at":"2026-06-25T20:43:39+08:00","status":"completed","actor":{"type":"runtime","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"MB-X managed session runtime"},"message_id":"msg_20260625204339662_99c52dd1","result":{"managed_session_key":"project-info.laoshen","project_id":"project-info","role_instance_id":"case_analysis.reviewer","ai_id":"laoshen","provider_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","transport":"codex_app_server_remote_tui","thread_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","turn_id":"019efece-b40b-7e81-92b6-e3f1b9b2d1be","app_server_url":"ws://127.0.0.1:4570"}}


{"schema_version":"1.0","event_id":"evt_20260625204629223_f588634b","event_type":"message.mirrored","message_id":"msg_20260625204629208_13708668","message_type":"review_result","scope":"project","project_id":"project-info","system_id":null,"role_instance_id":null,"role_id":null,"task_id":"PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW","correlation_id":"msg_20260625204629208_13708668","causation_id":"evt_20260625204629208_38db8e01","parent_message_id":null,"status":"delivered","created_at":"2026-06-25T20:46:29+08:00","actor":{"type":"system","project_id":"project-info","role_id":null,"role_instance_id":null,"system_id":null,"role_key":null,"session_id":null,"provider":null,"name":"MB-X Runtime"},"from":{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"},"to":[{"type":"management","project_id":null,"role_id":null,"role_instance_id":null,"system_id":null,"role_key":null,"session_id":"workspace-admin","provider":"codex","name":"管理端"}],"content":{"format":"markdown","text":"任务：PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW\n消息类型：review_result\n来源角色：case_analysis.reviewer\n关联消息：msg_20260625204339662_99c52dd1\nskill：mbx-case-review / mbx-governance / mbx-role-runtime\n\n结论：通过。\n\n发现的问题清单：\n- 未发现阻断问题。\n- 未发现 case_analysis / experiment 体系补建正式文件漏提交。\n- 当前 `git status --short` 仅显示 `.mbx/messages.jsonl` 与 `.mbx/inbox/` 运行态消息文件变化，不属于本次体系补建正式产物漏提交。\n\n是否需要 management.admin 继续修复：\n- 不需要。\n- 治理校验已通过，人工核查已覆盖配置登记、文件系统、`.gitkeep`、项目级记录、提交内容和未提交正式文件。\n- 后续具体案例分析或实验事项仍需按 `ana-doc/案例审核规范.md`、`exp-doc/实验审核规范.md` 等体系规范单独审核；本结论仅覆盖本次体系环境补建完整性。\n\n证据入口：\n- 审核记录：`项目事项审计报告.md`，条目 `2026-06-25T20:52:00+08:00 PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW 审核结论`\n- 配置入口：`mbx.project.yaml`\n- 人类可读配置：`项目配置清单.md`\n- 执行记录：`项目执行日志.md`\n- 变更记录：`项目变更记录.md`\n- 案例体系入口：`ana-doc/`、`ana-data/`\n- 实验体系入口：`exp-doc/`、`exp-data/`\n\n命令摘要：\n- `python -m mbx.cli validate --project project-info --governance`：OK，warnings=0。\n- 文件系统核查：`ana-doc/` 9 个要求文档存在；`ana-data/cases|result|img|tmp/.gitkeep` 存在；`exp-doc/` 10 个要求文档存在；`exp-data/raw|result|img|tmp/.gitkeep` 存在。\n- `git branch -vv` / `git log --oneline -5`：`master` 跟踪 `origin/master`，当前 HEAD 为 `df3b9d1 fix: add analysis and experiment systems`。\n- `git show --stat --name-only --oneline df3b9d1`：提交包含 `ana-doc`、`ana-data`、`exp-doc`、`exp-data`、`mbx.project.yaml` 和项目级同步文档。\n","data":null,"ref":null,"summary":"任务：PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW\n消息类型：review_result\n来源角色：case_analysis.reviewer\n关联消息：msg_20260625204339662_99c5"},"refs":[{"type":"message","path":"../.mbx/messages.jsonl","id":"evt_20260625204629208_38db8e01","label":"workspace management message","required":true}],"expected_response":null,"routing":{"mode":"management_mirror","resolved":true,"source":"workspace_log","source_role_instance_id":"case_analysis.reviewer","source_system_id":"case_analysis","target_role_instance_id":null,"target_system_id":null},"result":{"delivery":"workspace_log","mirrored_from":"workspace"},"ext":{}}


{"schema_version":"1.0","event_id":"evt_20260625204641405_683d958b","event_type":"managed_session.active_message.released","scope":"project","project_id":"project-info","role_instance_id":"case_analysis.reviewer","created_at":"2026-06-25T20:46:41+08:00","status":"completed","actor":{"type":"runtime","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"MB-X managed session runtime"},"message_id":"msg_20260625204339662_99c52dd1","result":{"managed_session_key":"project-info.laoshen","project_id":"project-info","role_instance_id":"case_analysis.reviewer","ai_id":"laoshen","provider_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","reason":"inbox_ack","active_message_id":"msg_20260625204339662_99c52dd1","dispatch_next":true}}


{"schema_version":"1.0","event_id":"evt_20260625205337447_caa952ce","event_type":"message.created","message_id":"msg_20260625205337447_e3b8ffd9","message_type":"review_request","scope":"project","project_id":"project-info","system_id":"case_analysis","role_instance_id":"case_analysis.analyst","role_id":"case_analysis.analyst","task_id":"PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW","correlation_id":"msg_20260625205337447_e3b8ffd9","causation_id":null,"parent_message_id":null,"status":"created","created_at":"2026-06-25T20:53:37+08:00","actor":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"from":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"to":[{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"}],"content":{"format":"markdown","text":"任务：PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis.reviewer / experiment.reviewer / dev.reviewer.ana / dev.reviewer.exp 共享审核员）\n\n摘要：\n人类反馈指出 `project-info` 中先前补建的 `ana-doc/` 和 `exp-doc/` 文档质量不合格：只是机械复制 common 模板，没有按 `common/ana-doc/案例分析环境创建指南.md` 和 `common/exp-doc/实验环境创建指南.md` 完成项目化实例化。management.admin 已重新重建本地体系文档，请基于新版本重新审核。\n\n重要说明：\n你之前对 `PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW` 的“通过”结论只覆盖旧版本的目录/配置/提交完整性；该结论不能覆盖本次重建后的文档内容质量。请重新审，不要复用旧结论。\n\n请重点核查：\n1. `ana-doc/` 是否是 project-info 本地入口文档，而不是 common 全文复制品。\n2. `ana-doc/` 是否满足案例分析环境创建指南：本地规范引用 common 且不得削弱、存储体系清楚、总纲/设计/执行日志/审计报告形成 `ANA-SMOKE-001` dry-run 链路。\n3. `exp-doc/` 是否是 project-info 本地入口文档，而不是 common 全文复制品。\n4. `exp-doc/` 是否满足实验环境创建指南：本地实验规范、实验审计规范、存储体系、总纲/设计/执行日志/审计报告形成 `EXP-SMOKE-001` dry-run 链路。\n5. 正式文档头部是否包含创建人员、文件职责、管理规范/模板、引用文件、记录方式。\n6. 是否仍有 `wuji` / `无忌` / `EXP-WUJI` 等旧项目业务内容或旧项目路径残留。\n7. `项目执行日志.md` 和 `项目事项审计报告.md` 是否记录了旧结论失效和本次重建待复审状态。\n8. `python -m mbx.cli validate --project project-info --governance` 是否通过。\n\n期望输出：\n请将复审结论追加到 `project-info/项目事项审计报告.md`，必要时也追加到 `ana-doc/案例审计报告.md` 和 `exp-doc/实验审计报告.md`。然后通过 MB-X 消息回复：\n- 结论：通过 / 有条件通过 / 不通过 / HELD\n- 问题清单\n- 是否需要 management.admin 继续修复\n- 证据入口和命令摘要\n","data":null,"ref":null,"summary":"任务：PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis"},"refs":[],"expected_response":null,"routing":null,"result":null,"ext":{}}


{"schema_version":"1.0","event_id":"evt_20260625205337450_0613c88e","event_type":"message.routed","message_id":"msg_20260625205337447_e3b8ffd9","message_type":"review_request","scope":"project","project_id":"project-info","system_id":"case_analysis","role_instance_id":"case_analysis.analyst","role_id":"case_analysis.analyst","task_id":"PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW","correlation_id":"msg_20260625205337447_e3b8ffd9","causation_id":"evt_20260625205337447_caa952ce","parent_message_id":null,"status":"routed","created_at":"2026-06-25T20:53:37+08:00","actor":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"from":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"to":[{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"}],"content":{"format":"markdown","text":"任务：PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis.reviewer / experiment.reviewer / dev.reviewer.ana / dev.reviewer.exp 共享审核员）\n\n摘要：\n人类反馈指出 `project-info` 中先前补建的 `ana-doc/` 和 `exp-doc/` 文档质量不合格：只是机械复制 common 模板，没有按 `common/ana-doc/案例分析环境创建指南.md` 和 `common/exp-doc/实验环境创建指南.md` 完成项目化实例化。management.admin 已重新重建本地体系文档，请基于新版本重新审核。\n\n重要说明：\n你之前对 `PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW` 的“通过”结论只覆盖旧版本的目录/配置/提交完整性；该结论不能覆盖本次重建后的文档内容质量。请重新审，不要复用旧结论。\n\n请重点核查：\n1. `ana-doc/` 是否是 project-info 本地入口文档，而不是 common 全文复制品。\n2. `ana-doc/` 是否满足案例分析环境创建指南：本地规范引用 common 且不得削弱、存储体系清楚、总纲/设计/执行日志/审计报告形成 `ANA-SMOKE-001` dry-run 链路。\n3. `exp-doc/` 是否是 project-info 本地入口文档，而不是 common 全文复制品。\n4. `exp-doc/` 是否满足实验环境创建指南：本地实验规范、实验审计规范、存储体系、总纲/设计/执行日志/审计报告形成 `EXP-SMOKE-001` dry-run 链路。\n5. 正式文档头部是否包含创建人员、文件职责、管理规范/模板、引用文件、记录方式。\n6. 是否仍有 `wuji` / `无忌` / `EXP-WUJI` 等旧项目业务内容或旧项目路径残留。\n7. `项目执行日志.md` 和 `项目事项审计报告.md` 是否记录了旧结论失效和本次重建待复审状态。\n8. `python -m mbx.cli validate --project project-info --governance` 是否通过。\n\n期望输出：\n请将复审结论追加到 `project-info/项目事项审计报告.md`，必要时也追加到 `ana-doc/案例审计报告.md` 和 `exp-doc/实验审计报告.md`。然后通过 MB-X 消息回复：\n- 结论：通过 / 有条件通过 / 不通过 / HELD\n- 问题清单\n- 是否需要 management.admin 继续修复\n- 证据入口和命令摘要\n","data":null,"ref":null,"summary":"任务：PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis"},"refs":[],"expected_response":null,"routing":{"mode":"session","resolved":true,"target_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","source_role_instance_id":"case_analysis.analyst","source_system_id":"case_analysis","target_role_instance_id":"case_analysis.reviewer","target_system_id":"case_analysis"},"result":null,"ext":{}}


{"schema_version":"1.0","event_id":"evt_20260625205337452_96d7b292","event_type":"message.delivered","message_id":"msg_20260625205337447_e3b8ffd9","message_type":"review_request","scope":"project","project_id":"project-info","system_id":"case_analysis","role_instance_id":"case_analysis.reviewer","role_id":"case_analysis.reviewer","task_id":"PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW","correlation_id":"msg_20260625205337447_e3b8ffd9","causation_id":"evt_20260625205337450_0613c88e","parent_message_id":null,"status":"delivered","created_at":"2026-06-25T20:53:37+08:00","actor":{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"},"from":{"type":"agent","project_id":"project-info","role_id":"case_analysis.analyst","role_instance_id":"case_analysis.analyst","system_id":"case_analysis","role_key":"analyst","session_id":"019ef54e-6978-76d3-bb78-081fa2c4b188","provider":"codex","name":"案例分析员"},"to":[{"type":"agent","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","system_id":"case_analysis","role_key":"reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"案例审核员"}],"content":{"format":"markdown","text":"任务：PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis.reviewer / experiment.reviewer / dev.reviewer.ana / dev.reviewer.exp 共享审核员）\n\n摘要：\n人类反馈指出 `project-info` 中先前补建的 `ana-doc/` 和 `exp-doc/` 文档质量不合格：只是机械复制 common 模板，没有按 `common/ana-doc/案例分析环境创建指南.md` 和 `common/exp-doc/实验环境创建指南.md` 完成项目化实例化。management.admin 已重新重建本地体系文档，请基于新版本重新审核。\n\n重要说明：\n你之前对 `PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW` 的“通过”结论只覆盖旧版本的目录/配置/提交完整性；该结论不能覆盖本次重建后的文档内容质量。请重新审，不要复用旧结论。\n\n请重点核查：\n1. `ana-doc/` 是否是 project-info 本地入口文档，而不是 common 全文复制品。\n2. `ana-doc/` 是否满足案例分析环境创建指南：本地规范引用 common 且不得削弱、存储体系清楚、总纲/设计/执行日志/审计报告形成 `ANA-SMOKE-001` dry-run 链路。\n3. `exp-doc/` 是否是 project-info 本地入口文档，而不是 common 全文复制品。\n4. `exp-doc/` 是否满足实验环境创建指南：本地实验规范、实验审计规范、存储体系、总纲/设计/执行日志/审计报告形成 `EXP-SMOKE-001` dry-run 链路。\n5. 正式文档头部是否包含创建人员、文件职责、管理规范/模板、引用文件、记录方式。\n6. 是否仍有 `wuji` / `无忌` / `EXP-WUJI` 等旧项目业务内容或旧项目路径残留。\n7. `项目执行日志.md` 和 `项目事项审计报告.md` 是否记录了旧结论失效和本次重建待复审状态。\n8. `python -m mbx.cli validate --project project-info --governance` 是否通过。\n\n期望输出：\n请将复审结论追加到 `project-info/项目事项审计报告.md`，必要时也追加到 `ana-doc/案例审计报告.md` 和 `exp-doc/实验审计报告.md`。然后通过 MB-X 消息回复：\n- 结论：通过 / 有条件通过 / 不通过 / HELD\n- 问题清单\n- 是否需要 management.admin 继续修复\n- 证据入口和命令摘要\n","data":null,"ref":null,"summary":"任务：PROJECT-INFO-SYSTEM-DOCS-REBUILD-REVIEW\n消息类型：review_request\n来源：management.admin\n目标：project-info.laoshen（case_analysis"},"refs":[],"expected_response":null,"routing":{"mode":"session","resolved":true,"target_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","delivery":"inbox","source_role_instance_id":"case_analysis.analyst","source_system_id":"case_analysis","target_role_instance_id":"case_analysis.reviewer","target_system_id":"case_analysis"},"result":{"delivery":"inbox","inbox_path":".mbx/inbox/case_analysis.reviewer.jsonl"},"ext":{}}


{"schema_version":"1.0","event_id":"evt_20260625205337685_1824af68","event_type":"managed_session.dispatch.started","scope":"project","project_id":"project-info","role_instance_id":"case_analysis.reviewer","created_at":"2026-06-25T20:53:37+08:00","status":"running","actor":{"type":"runtime","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"MB-X managed session runtime"},"message_id":"msg_20260625205337447_e3b8ffd9","result":{"managed_session_key":"project-info.laoshen","project_id":"project-info","role_instance_id":"case_analysis.reviewer","ai_id":"laoshen","provider_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","transport":"codex_app_server_remote_tui","thread_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","lease_id":"lease_20260625205337683_bfa526ff","app_server_url":"ws://127.0.0.1:4570"}}


{"schema_version":"1.0","event_id":"evt_20260625205337693_0f63ce3f","event_type":"managed_session.dispatch.completed","scope":"project","project_id":"project-info","role_instance_id":"case_analysis.reviewer","created_at":"2026-06-25T20:53:37+08:00","status":"completed","actor":{"type":"runtime","project_id":"project-info","role_id":"case_analysis.reviewer","role_instance_id":"case_analysis.reviewer","session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","provider":"codex","name":"MB-X managed session runtime"},"message_id":"msg_20260625205337447_e3b8ffd9","result":{"managed_session_key":"project-info.laoshen","project_id":"project-info","role_instance_id":"case_analysis.reviewer","ai_id":"laoshen","provider_session_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","transport":"codex_app_server_remote_tui","thread_id":"019ef550-45ac-7b43-aa24-2731d01dba9b","turn_id":"019efed7-d31b-7592-8ba6-b962876de437","app_server_url":"ws://127.0.0.1:4570"}}




 ana-doc/案例分析规范.md


@@ -1,221 +1,54 @@


# 案例分析规范




创建人员：Codex  


文件职责：定义案例分析体系的定位、核心流程、证据链要求、文档职责、审计闭环和问题处理边界。  


管理规范/模板：../../全局规范.md；../../体系说明.md；../../体系创建流程.md。  


引用文件：案例分析环境创建指南.md；案例存储体系创建指南.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md；案例审核规范.md；案例审计报告模版.md；案例问题记录模版.md。  


记录方式：全局案例分析规范；案例分析流程或审计口径变化时更新。


创建人员：management.admin  


文件职责：记录 `project-info` 项目案例分析员必须遵守的本地规范。本文件引用 common 案例分析规范，不得削弱 common 硬约束。  


管理规范/模板：../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例分析环境创建指南.md。  


引用文件：目录导读.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例存储体系.md；../项目配置清单.md。  


记录方式：项目本地规范；本项目案例分析口径发生变化时更新，并同步项目变更记录。




统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地案例分析规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。


## 1. 基本口径




## 1. 定位


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




案例分析体系用于管理一类“对具体案例做全流程分析、复盘、解释和校验”的事项。


## 2. 项目分析范围




案例可以来自：


本项目案例分析范围限定为股市信息研究相关案例，包括：




1. 方法论或笔记。


2. 交易、需求、用户、工程、业务流程。


3. 样本数据。


4. 人工标注。


5. AI 发现的异常或候选。


1. 研报、公告、新闻、公开网络信息形成的信息事件链。


2. K 线、成交量、市场广度、行业表现等市场显影证据。


3. 暗线 / 信息拓扑分析中的意图、目标、证据链和替代解释。


4. 后续可交给实验体系验证的假设和观察窗口。




案例分析不是代码实现，也不是单纯写总结。它要把“为什么选这个案例、怎么分析、每一步依据是什么、最后结果是什么、是否符合原始方法论”都留下证据链。


本项目案例分析不得直接输出交易指令、收益承诺或未经验证的因果结论。




## 2. 核心目标


## 3. 核心文档作用




案例分析体系要达成：


| 文档 | 作用 |


|---|---|


| `案例总纲.md` | 记录本项目所有案例事项的来源、目标、边界、状态和结论 |


| `案例分析设计.md` | 记录案例选择口径、证据链设计、执行步骤、产物和判定标准 |


| `案例执行日志.md` | 记录执行过程、证据入口、关键中间结果、异常和自检 |


| `案例存储体系.md` | 说明案例数据、图片、结果包、临时文件和证据包的存储规则 |


| `案例审计报告.md` | 记录设计审核、执行审核、初始化审核和复审结论 |


| `案例问题记录.md` | 记录非审计来源问题；审计问题主记录留在审计报告 |




1. 能追踪案例起因和原始要求。


2. 能复核案例为什么被选中。


3. 能复核每一步判断或操作是否按规则发生。


4. 能看到中间关键节点的数据、图片或文本证据。


5. 能判断最终结论有没有过读。


6. 能让审核员和人类读者快速理解案例前因后果。


## 4. 最小案例链路




## 3. 核心流程


每个正式案例至少具备：




默认流程：


1. 案例 ID、来源、目标、边界和状态。


2. 设计记录，说明要分析的信息叶子、证据来源、K 线/市场显影检查口径和替代解释。


3. 执行日志，说明实际读取的文档、数据、证据路径和输出包。


4. 审计记录，说明设计或执行是否通过。


5. 结果包或明确的 `HELD` 状态；不能用口头结论替代证据入口。




```text


来源聊天记录 / 上游方法论 / 样本来源


-> 案例总纲记录背景、目标、边界、当前结论


-> 案例分析设计记录案例选择口径、分析步骤、证据要求、验收方式


-> 设计审核


-> 执行案例分析


-> 案例执行日志记录候选、过程、关键数据、图片、结果


-> 结果包 / 证据包归档


-> 执行审核


-> 审计报告记录审计问题 / 问题记录承接非审计问题或审计索引


-> 修复 / 复审


-> 结论回写到案例总纲和案例设计


```


## 5. darkline 使用口径




设计审核未通过，不得进入正式执行。


当任务涉及暗线、新闻、公告、事件链、证据链、K 线显影或外部信息拓扑时，应使用 `darkline` 技能约束分析流程。窗口只展示摘要、关键路径和证据入口；大段新闻、日志、搜索结果和图片批量内容应落到结果包或 readout 文件。




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


## 6. 禁止事项




### 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 像分析员一样把一件事按规则跑完整，并把每一步为什么这么做、证据在哪里、结果怎么来的都留下来。


1. 不得把其他项目的业务结论、样本、图片或结果包复制为本项目正式案例。


2. 不得绕过 `案例分析设计.md` 直接把执行结果标为完成。


3. 不得把 `ana-data/tmp/` 当正式证据入口。


4. 不得把未经证据支持的猜测写成结论；证据不足时应标记 `HELD_BY_EVIDENCE_GAP`。




 ana-doc/案例分析设计.md


@@ -1,84 +1,33 @@


# 案例分析设计


# 案例分析设计




创建人员：<创建人员>  


文件职责：作为案例分析体系的项目级设计账本，记录案例选择口径、分析流程、证据要求、执行步骤和验收方式。  


管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例分析设计模版.md。  


引用文件：案例总纲.md；案例执行日志.md；案例审计报告.md；案例存储体系.md。  


记录方式：append-only 案例分析设计；新增设计或修订追加到文件末尾。


创建人员：management.admin  


文件职责：记录 `project-info` 项目案例选择口径、执行步骤、证据要求、产物和验收方式。  


管理规范/模板：../../common/ana-doc/案例分析设计模版.md；../../common/ana-doc/案例分析环境创建指南.md。  


引用文件：案例分析规范.md；案例总纲.md；案例执行日志.md；案例审计报告.md；案例存储体系.md。  


记录方式：append-only 设计账本；每个案例设计追加到文件末尾，设计审核通过后才能执行正式案例。




## 1. 当前设计总览


## 案例设计：ANA-SMOKE-001




| 设计 ID | 所属案例事项 | 目标 | 状态 | 设计审计 |


|---|---|---|---|---|


| <DESIGN-ID> | <ANA-ID> | <目标> | 未开始 | 未审计 |


- 所属案例：ANA-SMOKE-001 / 案例体系初始化 dry-run


- 设计人员：management.admin


- 创建时间：2026-06-25T20:55:00+08:00


- 当前状态：待审核员复核




## 2. 设计记录模板


### 目标和边界




### <YYYY-MM-DD HH:mm:ss> <DESIGN-ID>：<设计标题>


- 目标：验证项目案例体系环境能从总纲追到设计、执行日志和审计报告。


- 边界：不采集真实新闻、研报、公告、图片或 K 线数据，不产生真实业务结果包。




所属案例事项：


<ANA-ID / 名称>


### 检查项




创建人员：


<创建人员>


1. `ana-doc/` 下 9 个基础文档存在，且每个文档包含创建人员、文件职责、管理规范/模板、引用文件、记录方式。


2. `ana-data/cases/`、`ana-data/result/`、`ana-data/img/`、`ana-data/tmp/` 存在，并通过 `.gitkeep` 保证 Git 克隆后目录保留。


3. 本地规范和审核规范引用 common 规范，并声明不得削弱 common 硬约束。


4. `案例存储体系.md` 写清正式结果包、图片、readout、manifest 和 tmp 禁止事项。


5. 项目配置清单和 `mbx.project.yaml` 已登记案例体系目录、文档和角色。




来源聊天记录：


```text


<粘贴关键聊天记录，或写明案例总纲中的来源位置>


```


### PASS / FAIL / HELD




目标对齐说明：


<说明本设计如何满足案例总纲目标；如有取舍，写明原因>




案例选择口径：


<候选案例从哪里来，如何筛选，为什么这些案例代表当前目标>




分析对象：


<股票 / 用户 / 模块 / 流程 / 事件 / 其他>




全流程步骤：




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>




当前结论：


<当前设计是否可执行>


- PASS：上述检查项全部满足，且审核员确认没有旧项目业务内容混入。


- FAIL：基础文档缺失、目录缺失、规范冲突、审计入口错误或混入其他项目结论。


- HELD：需要人类确认项目范围或审核员无法读取必要文档。




 ana-doc/案例存储体系.md


@@ -1,135 +1,42 @@


# 案例存储体系创建指南


# 案例存储体系




创建人员：Codex  


文件职责：指导项目内案例分析体系如何记录数据、图片、结果包、表结构和读取方式。  


管理规范/模板：../../全局规范.md；../../体系说明.md；案例分析规范.md。  


引用文件：案例分析环境创建指南.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md；案例审计报告模版.md。  


记录方式：存储体系创建指南；案例数据存储口径变化时更新。


创建人员：management.admin  


文件职责：记录 `project-info` 项目案例分析体系的数据、证据、图片、结果包和临时文件存储位置。  


管理规范/模板：../../common/ana-doc/案例存储体系创建指南.md；../../common/ana-doc/案例分析环境创建指南.md。  


引用文件：案例分析规范.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md。  


记录方式：存储体系入口；目录、表结构或结果包口径变化时维护更新。




## 1. 定位


## 1. 目录映射




案例存储体系负责回答：


| 路径 | 作用 | 状态 |


|---|---|---|


| `../ana-data/cases/` | 案例级结构化数据、证据 manifest、readout 和逐案例材料 | 已创建 |


| `../ana-data/result/` | 正式结果包、汇总表、审计辅助输出 | 已创建 |


| `../ana-data/img/` | 案例图片、图册、标注图和图片 manifest | 已创建 |


| `../ana-data/tmp/` | 临时数据和中间文件，不得当正式结果 | 已创建 |




1. 案例数据放在哪里。


2. 图片和图册放在哪里。


3. 每个表有哪些字段。


4. 一个案例的证据链怎么串起来。


5. 审核员怎么找到并复核关键数据。


项目内正式路径默认使用项目根目录相对路径，例如 `ana-data/result/ANA-YYYYMMDD-主题-001/manifest.json`。




## 2. 推荐目录


## 2. 推荐结果包结构




```text


ana-data/


  cases/


    <CASE-ID>/


      data/


      img/


      notes/


  result/


    <PACK-ID>/


  img/


    individual/


    by_type/


  tmp/


ana-data/result/<case_id>/


  manifest.json


  summary.md


  evidence_index.csv


  readout.md


  image_manifest.csv       # 如涉及图片


```




## 3. 核心表


`manifest.json` 至少记录结果包 ID、生成时间、输入入口、文件清单、行数或哈希摘要。`summary.md` 只写摘要、结论边界和证据入口；大段原文应放在 readout 或 evidence 文件中。




建议至少维护以下表，字段可按项目扩展。


## 3. 外部信息和 K 线数据




路径口径：表内 `input_path`、`output_path`、`image_path`、`evidence_pack_path` 等路径默认使用项目根目录相对路径，例如 `ana-data/result/<PACK-ID>/case_index.csv`。如果项目另有路径基准，必须在本地 `案例存储体系.md` 写清楚，避免审核员按不同目录解析路径。


外部信息、研报、公告、新闻和网页内容只记录来源、采集时间、摘要和证据入口。K 线和市场数据优先引用全局数据文档、数据库查询口径、结果包路径或 manifest，不在窗口或文档中粘贴大体量数据。




### 3.1 case_index.csv


## 4. 禁止事项




| 字段 | 含义 |


|---|---|


| 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. 结果包没有回写入口。


1. 不得把 `ana-data/tmp/` 中的文件当作正式证据包。


2. 不得只有结论 summary 而没有案例级证据索引。


3. 图片作为证据时必须有 manifest 或等价索引。


4. 不得把数据库密码、授权 token 或私有凭据写入结果包。




 ana-doc/案例审核规范.md


@@ -1,137 +1,36 @@


# 案例审核规范


# 案例审核规范




创建人员：Codex  


文件职责：定义案例分析体系的审核范围、审核流程、设计审核、执行审核、证据链审核和问题阻断标准。  


管理规范/模板：../../全局规范.md；../../体系说明.md；案例分析规范.md。  


引用文件：案例审计报告模版.md；案例问题记录模版.md；案例总纲模版.md；案例分析设计模版.md；案例执行日志模版.md。  


记录方式：案例审核规范；案例审核口径变化时更新。


创建人员：management.admin  


文件职责：记录 `project-info` 项目案例审核员必须遵守的本地审核规范。本文件引用 common 案例审核规范，不得削弱 common 硬约束。  


管理规范/模板：../../common/ana-doc/案例审核规范.md；../../common/ana-doc/案例分析环境创建指南.md。  


引用文件：案例分析规范.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；../项目配置清单.md。  


记录方式：项目本地审核规范；审核口径变化时更新，并同步项目变更记录。




统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地案例审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。


## 1. 基本口径




## 1. 审核定位


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




案例审核检查案例分析是否真的按目标和设计完成。


## 2. 审核范围




审核重点是：


审核员至少检查：




1. 设计是否能满足目标。


2. 执行是否按设计走。


3. 每个关键判断是否有证据。


4. 结果是否和过程、数据、图片一致。


5. 结论是否过读。


1. 设计是否明确案例来源、目标、边界、证据要求和产物。


2. 执行是否按设计完成，证据路径是否可打开、可追溯。


3. 结论是否降读，是否避免交易建议和未经验证的因果判断。


4. K 线、成交量、市场背景、替代解释是否按任务需要纳入。


5. 是否存在从其他项目复制的旧内容、旧路径、旧结果包或旧业务结论。


6. 是否遵守“主体内容落文档，窗口只展示摘要和证据入口”的上下文保护要求。




## 2. 设计审核


## 3. 审计记录位置




设计审核在正式执行前进行。


| 情况 | 主记录位置 |


|---|---|


| 初始化审计 | `案例审计报告.md` |


| 设计审核 | `案例审计报告.md` |


| 执行审核 | `案例审计报告.md` |


| 审计发现问题 | `案例审计报告.md` 为主，`案例问题记录.md` 只做跨轮索引 |


| 非审计来源问题 | `案例问题记录.md` |




必须检查：


## 4. 审核结论




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`，仅限修正案例审核流程、审计口径和阻断标准；不得借此修改被审的案例分析规范、案例设计、执行日志、结果包或主产物。




审核员不得直接改被审计主产物来掩盖问题。




如确需修改案例分析执行规范，应创建规范维护事项，或额外授予案例体系维护 / 规范维护角色，并记录原因、影响范围和复审入口。




审核员应抓真问题，不把边角料升级成阻断。


审核结论使用：`通过`、`有条件通过`、`不通过`、`HELD`。结论必须包含证据入口、阻断项、需要修复的文档或结果包路径。




 ana-doc/案例审计报告.md


@@ -1,76 +1,28 @@


# 案例审计报告


# 案例审计报告




创建人员：<创建人员>  


文件职责：作为案例分析体系的项目级审计账本，记录案例设计审核、执行审核、复审结果和问题清单。  


管理规范/模板：../../全局规范.md；../../common/ana-doc/案例审核规范.md；../../common/ana-doc/案例审计报告模版.md。  


引用文件：案例总纲.md；案例分析设计.md；案例执行日志.md；案例问题记录.md；案例存储体系.md。  


记录方式：append-only 案例审计报告；每次设计审核、执行审核和复审追加到文件末尾。


创建人员：management.admin  


文件职责：记录 `project-info` 项目案例分析体系初始化审计、设计审核、执行审核、复审和审计问题主记录。  


管理规范/模板：../../common/ana-doc/案例审计报告模版.md；../../common/ana-doc/案例审核规范.md。  


引用文件：案例审核规范.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例问题记录.md；../项目配置清单.md。  


记录方式：append-only 审计账本；审核结论和审计问题追加到文件末尾。




固定口径：案例审核员发现的问题完整记录在本文；只有需要跨轮跟踪、跨案例汇总或长期处理时，才在 `案例问题记录.md` 中建立索引，不重复全文。


## 2026-06-25 AUDIT-ANA-SMOKE-001




## 1. 当前审计总览


- 审计 ID：AUDIT-ANA-SMOKE-001


- 审计事项：ANA-SMOKE-001 / 案例体系初始化 dry-run


- 提交方：management.admin


- 审核方：case_analysis.reviewer / laoshen


- 当前状态：待审核员复核




| 审计 ID | 审计对象 | 审计类型 | 审核员 | 结论 | 时间 |


|---|---|---|---|---|---|


| <AUDIT-ID> | <对象> | 设计审核 / 执行审核 / 复审 | <审核员> | 待审计 | <YYYY-MM-DD HH:mm:ss> |


### 管理端自检




## 2. 审计记录模板


- `ana-doc/` 基础文档：已补齐。


- `ana-data/` 基础目录：已补齐并有 `.gitkeep`。


- 本地规范引用 common：已补齐。


- 存储体系：已补齐项目本地目录和结果包口径。


- 是否混入其他项目业务内容：管理端自检未复制具体案例、结果包、业务结论或旧路径。




### <YYYY-MM-DD HH:mm:ss> <AUDIT-ID>：<审计标题>


### 待审核员确认




审计对象：


<ANA-ID / DESIGN-ID / LOG-ID / PACK-ID>


请审核员按 `../../common/ana-doc/案例分析环境创建指南.md` 第 6-8 节复核，并给出 `通过 / 有条件通过 / 不通过 / HELD` 结论。




审计类型：


设计审核 / 执行审核 / 复审




审核员：


<审核员>




来源聊天记录 / 上游依据：


<粘贴关键聊天记录，或写明案例总纲、上游文档、聊天记录路径>




依据文档：




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. <如无写“无”>




审计结论：


通过 / 不通过 / 暂缓




是否阻断：


是 / 否




是否允许进入下一阶段：


是 / 否




建议动作：


<下一步>




复审要求：


<是否需要复审>




 ana-doc/案例总纲.md


@@ -1,61 +1,29 @@


# 案例总纲


# 案例总纲




创建人员：<创建人员>  


文件职责：作为案例分析体系的项目级滚动账本，记录所有案例分析事项的背景、目标、方法论来源、状态和当前结论。  


管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例总纲模版.md。  


引用文件：案例分析规范.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；案例存储体系.md。  


记录方式：append-only 案例总纲；新增案例分析事项、阶段结论和最终结论追加到文件末尾。


创建人员：management.admin  


文件职责：记录 `project-info` 项目案例分析事项的来源、目标、边界、状态、结果包入口和结论。  


管理规范/模板：../../common/ana-doc/案例总纲模版.md；../../common/ana-doc/案例分析环境创建指南.md。  


引用文件：案例分析规范.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例存储体系.md。  


记录方式：append-only 滚动账本；新增案例或状态变化时追加记录。




## 1. 当前案例分析总览


## 1. 当前总览




| 案例事项 ID | 名称 | 来源 | 目标 | 状态 | 当前结论 | 审计状态 |


|---|---|---|---|---|---|---|


| <ANA-ID> | <名称> | <来源聊天 / 方法论 / 样本> | <目标> | 未开始 | 待分析 | 未审计 |


| 案例 ID | 名称 | 状态 | 结论 |


|---|---|---|---|


| `ANA-SMOKE-001` | 案例体系初始化 dry-run | 已记录，待审核员复核 | 环境链路可承接案例分析；无真实业务结论 |




## 2. 记录模板


## 2. 案例事项：ANA-SMOKE-001




### <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；如无写“无”>


- 案例 ID：ANA-SMOKE-001


- 案例名称：案例体系初始化 dry-run


- 创建人员：management.admin


- 创建时间：2026-06-25T20:55:00+08:00


- 当前状态：待审核员复核


- 背景：修复 `project-info` 初始创建时案例体系目录和本地文档未按创建指南完整落地的问题。


- 目标：验证 `ana-doc/`、`ana-data/`、设计、执行日志、审计报告和问题记录之间能形成最小可追溯链路。


- 边界：本事项不是股市业务案例，不分析具体股票、研报、新闻或收益，不产生交易建议。


- 设计入口：`ana-doc/案例分析设计.md#案例设计ana-smoke-001`


- 执行入口：`ana-doc/案例执行日志.md#2026-06-25-run-ana-smoke-001`


- 审计入口：`ana-doc/案例审计报告.md#2026-06-25-audit-ana-smoke-001`


- 结果包入口：无真实结果包；本事项为体系 dry-run。


- 当前结论：本地文档和数据目录已补齐，仍需审核员确认是否满足 `common/ana-doc/案例分析环境创建指南.md`。




 ana-doc/案例执行日志.md


@@ -1,71 +1,40 @@


# 案例执行日志


# 案例执行日志




创建人员：<创建人员>  


文件职责：作为案例分析体系的项目级执行账本，记录案例分析实际执行过程、关键节点、数据路径、图片路径、结果和偏离。  


管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例执行日志模版.md。  


引用文件：案例总纲.md；案例分析设计.md；案例审计报告.md；案例问题记录.md；案例存储体系.md。  


记录方式：append-only 案例执行日志；每次执行、重跑、修复和结果包生成追加到文件末尾。


创建人员：management.admin  


文件职责：记录 `project-info` 项目案例分析执行过程、关键节点、数据和证据路径。  


管理规范/模板：../../common/ana-doc/案例执行日志模版.md；../../common/ana-doc/案例分析环境创建指南.md。  


引用文件：案例分析规范.md；案例总纲.md；案例分析设计.md；案例审计报告.md；案例存储体系.md。  


记录方式：append-only 执行日志；每次案例执行、重跑或修复追加记录。




## 1. 当前执行总览


## 2026-06-25 RUN-ANA-SMOKE-001




| 日志 ID | 所属设计 | 案例范围 | 状态 | 结果包 | 审计 |


|---|---|---|---|---|---|


| <LOG-ID> | <DESIGN-ID> | <范围> | 未开始 |  | 未审计 |


- run ID：RUN-ANA-SMOKE-001


- 所属案例：ANA-SMOKE-001


- 执行人员：management.admin


- 执行类型：体系初始化 dry-run


- 当前状态：完成，待审核员复核




## 2. 执行记录模板


### 执行步骤




### <YYYY-MM-DD HH:mm:ss> <LOG-ID>：<执行标题>


1. 读取 `../../common/ana-doc/案例分析环境创建指南.md`。


2. 参考 common 创建指南要求，按项目本地入口、账本和审计链路重建案例体系文档。


3. 重写 `ana-doc/` 本地入口文档，避免把 common 全文复制成项目文档。


4. 确认 `ana-data/cases/`、`ana-data/result/`、`ana-data/img/`、`ana-data/tmp/` 存在。


5. 记录初始化 dry-run 到 `案例总纲.md`、`案例分析设计.md`、`案例审计报告.md`。




所属案例事项：


<ANA-ID>


### 产物




关联设计：


<DESIGN-ID>


- `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`




执行人员：


<执行人员>


### 结论边界




执行目标：


<本次执行要完成什么>


本 run 只证明体系文档链路已按指南补齐，不证明任何股市业务结论。




输入：


<方法论文档、候选池、数据源、图片源、上游结果>




执行过程：




1. <关键步骤 1>


2. <关键步骤 2>




关键节点记录：




| 节点 | 说明 | 数据路径 | 图片路径 | 结论 |


|---|---|---|---|---|


| 候选来源 | <如何得到候选> | <path> | <path> | <结论> |


| 案例选择 | <为什么选这些案例> | <path> | <path> | <结论> |


| 关键判断 | <按什么规则判断> | <path> | <path> | <结论> |


| 操作 / 动作 | <如有买卖、标记、排除等动作> | <path> | <path> | <结论> |


| 结果复盘 | <最终结果> | <path> | <path> | <结论> |




逐案例证据链记录：




| 案例 ID | 候选来源 | 入选理由 | 背景证据 | 关键判断 / 操作 | 数据路径 | 图片路径 | 结果 | 是否符合设计 |


|---|---|---|---|---|---|---|---|---|


| <CASE-ID> | <候选池或上游来源> | <为什么选中> | <背景数据或背景图> | <按设计逐步记录关键判断或操作> | <path> | <path> | <结果> | 是 / 否；如否说明偏离 |




输出：


<结果包、表、图片、readout、summary>




偏离设计：


<如无写“无”；如有，说明原因和影响>




自检结果：


<文件是否存在、行数是否合理、图片是否可读、关键证据是否齐全>




执行结果 / 结论回写：


<本次执行最终结果；如影响案例总纲或设计，写明已回写位置或待回写原因>




当前状态：


完成 / 部分完成 / 失败 / 暂缓




审计入口：


<案例审计报告.md 中 AUDIT-ID>




 ana-doc/案例问题记录.md


@@ -1,58 +1,24 @@


# 案例问题记录


# 案例问题记录




创建人员：<创建人员>  


文件职责：作为案例分析体系的问题闭环账本，记录非审计来源的案例设计、执行、数据、证据链问题；对需要跨轮跟踪的审计问题只记录索引或关联。  


管理规范/模板：../../全局规范.md；../../common/ana-doc/案例分析规范.md；../../common/ana-doc/案例问题记录模版.md。  


引用文件：案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例存储体系.md。  


记录方式：append-only 案例问题记录；新问题、修复、复审和关闭追加到文件末尾。




口径说明：审核员在设计审核、执行审核和复审中发现的问题，主记录写入 `案例审计报告.md`；本文件只在需要跨轮跟踪时记录审计问题索引。案例分析员、执行者、人工同事或其他非审计角色发现的问题，主记录写入本文件。


创建人员：management.admin  


文件职责：记录 `project-info` 项目案例分析体系中非审计来源问题，或审计问题的跨轮索引。  


管理规范/模板：../../common/ana-doc/案例问题记录模版.md；../../common/ana-doc/案例分析环境创建指南.md。  


引用文件：案例审计报告.md；案例执行日志.md；案例总纲.md；../项目问题记录.md。  


记录方式：append-only 问题账本；新增问题、状态变化和复验结论追加记录。




## 1. 当前问题总览




| 问题 ID | 所属案例 | 类型 | 严重级别 | 状态 | 责任方 |


|---|---|---|---|---|---|


| <ISSUE-ID> | <ANA-ID / CASE-ID> | <类型> | P0 / P1 / P2 / P3 | 未处理 | <责任方> |


| 问题 ID | 来源 | 严重级别 | 状态 | 主记录 |


|---|---|---|---|---|


| ANA-ISSUE-20260625-DOCS-INIT-001 | 人类反馈 | 中 | 已由 management.admin 重建，待审核员复核 | `案例审计报告.md#2026-06-25-audit-ana-smoke-001` |




## 2. 问题记录模板


## 2. 问题记录




### <YYYY-MM-DD HH:mm:ss> <ISSUE-ID>：<问题标题>


### ANA-ISSUE-20260625-DOCS-INIT-001：初始案例体系文档未按创建指南项目化




所属案例事项：


<ANA-ID / CASE-ID / DESIGN-ID / LOG-ID>


- 来源：人类反馈。


- 描述：此前 `project-info` 的 `ana-doc/` 文档由 common 模板机械复制，未按案例分析环境创建指南完成项目化入口、存储体系、dry-run 和初始化审计。


- 影响：案例体系虽有文件，但不能可靠承接正式案例分析事项。


- 处理：management.admin 已按 common 创建指南重建本地入口文档。


- 当前状态：待审核员复核。




问题类型：


设计问题 / 执行问题 / 数据问题 / 图片问题 / 证据链问题 / 结论过读 / 未来函数 / 待归因




严重级别：


P0 阻断 / P1 重要 / P2 一般 / P3 建议




发现人：


<发现人>




来源类型：


非审计反馈 / 审计问题索引




关联审计：


<案例审计报告.md 中 AUDIT-ID；非审计反馈可写无>




证据：


<文件、表、图片、日志路径，或粘贴关键片段>




问题描述：


<问题是什么>




影响：


<影响案例结论、流程、证据链、可复核性还是只是建议>




建议修复：


<建议怎么修，不要无边界加码>




当前状态：


未处理 / 修复中 / 待复审 / 已关闭 / 暂缓




复审结论：


<复审结果；未复审写“待复审”>




关闭条件：


<什么条件下可以关闭>




 ana-doc/目录导读.md


@@ -1,49 +1,41 @@


# ana-doc 目录导读


# ana-doc 目录导读




创建人员：Codex  


文件职责：说明 `common/ana-doc` 目录下案例分析体系规范、创建指南、模板和审计文档的用途。  


管理规范/模板：../../全局规范.md；../../体系说明.md；案例分析规范.md。  


引用文件：案例分析规范.md；案例分析环境创建指南.md；本目录下全部 `*模版.md` 和 `*指南.md` 文件。  


记录方式：目录入口文档；新增或删除本目录正式文档时同步更新。


创建人员：management.admin  


文件职责：说明 `project-info` 项目案例分析体系文档入口和相邻数据目录用途。  


管理规范/模板：../项目规范.md；../../common/ana-doc/案例分析环境创建指南.md；../../common/ana-doc/案例分析规范.md。  


引用文件：案例分析规范.md；案例审核规范.md；案例总纲.md；案例分析设计.md；案例执行日志.md；案例审计报告.md；案例问题记录.md；案例存储体系.md；../项目配置清单.md。  


记录方式：目录入口文档；本目录正式文件新增、删除、改名或职责变化时同步更新。




## 1. 目录定位


## 1. 本体系定位




本目录保存通用案例分析体系。


`project-info` 的案例分析体系用于沉淀股市信息案例，包括研报、公告、新闻、公开网络信息、K 线显影、数据证据和分析结论。案例体系只记录可复核的案例链路，不替代实验体系的可执行验证，也不直接给出交易建议。




案例分析体系负责管理“基于规则、方法论、笔记、现象或样本，对具体案例做全流程复盘和证据链分析”的事项。


## 2. 文档入口




它强调：


| 文件 | 作用 |


|---|---|


| `案例分析规范.md` | 本项目案例分析本地规范入口，引用 common 规范并说明本项目补充口径 |


| `案例审核规范.md` | 本项目案例审核本地规范入口，引用 common 审核规范并说明审核员职责 |


| `案例总纲.md` | 案例事项背景、目标、边界、状态和结论账本 |


| `案例分析设计.md` | 案例选择口径、执行步骤、证据要求和验收方式 |


| `案例执行日志.md` | 案例执行过程、关键节点、数据和证据路径 |


| `案例审计报告.md` | 初始化审计、设计审核、执行审核、复审和审计问题主记录 |


| `案例问题记录.md` | 非审计来源问题，或审计问题跨轮索引 |


| `案例存储体系.md` | 案例数据、证据、图片、结果包和临时文件存储口径 |




1. 起因和原始要求必须留痕。


2. 案例选择、判断、操作、结果必须能追踪。


3. 关键步骤要有数据或图片证据。


4. 审核员能按证据链复核每一步是否对得上。


## 3. 数据目录




## 2. 文件清单


| 目录 | 作用 |


|---|---|


| `../ana-data/cases/` | 案例级结构化数据和逐案例证据目录 |


| `../ana-data/result/` | 正式结果包、汇总表、审计辅助输出 |


| `../ana-data/img/` | 案例图片、图册、标注图和图片 manifest |


| `../ana-data/tmp/` | 临时数据和中间产物，不得作为正式证据入口 |




| 文件 | 类型 | 作用 |


|---|---|---|


| 案例分析规范.md | 全局规范 | 定义案例分析体系定位、流程、证据链、边界和问题闭环 |


| 案例分析环境创建指南.md | 创建指南 | 指导项目管理员在项目内创建案例分析环境 |


| 案例存储体系创建指南.md | 创建指南 | 指导案例数据、图片、账户/过程表、结果包如何存储和索引 |


| 案例总纲模版.md | 模板 | 创建项目级案例总账本，记录案例背景、目标、方法论来源和当前结论 |


| 案例分析设计模版.md | 模板 | 创建项目级案例分析设计账本，记录案例选择口径、全流程步骤和验收方式 |


| 案例执行日志模版.md | 模板 | 创建项目级案例执行日志，记录每个案例关键节点、数据和结果 |


| 案例审核规范.md | 审核规范 | 定义案例设计审核、执行审核、证据链审核和阻断标准 |


| 案例审计报告模版.md | 模板 | 创建项目级案例审计报告，记录审核结果、问题和是否通过 |


| 案例问题记录模版.md | 模板 | 创建非审计来源案例问题闭环账本；审计问题只做索引 |


## 4. 当前案例入口




## 3. 推荐使用顺序


| 案例 ID | 名称 | 状态 | 入口 |


|---|---|---|---|


| `ANA-SMOKE-001` | 案例体系初始化 dry-run | 初始化完成，待审核员复核 | `案例总纲.md`、`案例分析设计.md`、`案例执行日志.md`、`案例审计报告.md` |




项目启用案例分析体系时：




1. 先读 `../../全局规范.md`。


2. 再读 `../../体系说明.md`。


3. 读 `案例分析规范.md`。


4. 按 `案例分析环境创建指南.md` 创建项目内 `ana-doc/`、`ana-data/` 和本地规范。


5. 如案例涉及图片、表格、交易流水、过程数据，按 `案例存储体系创建指南.md` 创建存储结构。


6. 用模板创建案例总纲、案例分析设计、案例执行日志、案例审计报告和案例问题记录。


7. 每个案例按设计执行并写执行日志。


8. 审核员按 `案例审核规范.md` 做设计审核和执行审核。




所有案例分析文档默认采用 append-only 方式维护：最新案例、执行、审计和问题记录追加到对应文件末尾。审核员发现的问题主记录写入案例审计报告；案例问题记录只承接非审计问题或审计问题索引。


新增正式案例时，应先在 `案例总纲.md` 登记，再在 `案例分析设计.md` 补设计；设计审核通过后才能执行。




 exp-doc/实验存储体系.md


@@ -1,254 +1,50 @@


# 实验存储体系创建指南


# 实验存储体系




创建人员：Codex  


文件职责：指导 AI 在具体项目中创建实验体系的数据存储文档、数据目录、表 schema、读取方式和结果包组织方式。  


管理规范/模板：common/exp-doc/实验规范.md；本文件是创建指南，不是单次实验模板。  


引用文件：../../管理系统说明.md；实验规范.md；实验环境创建指南.md。


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验数据、结果包、图片、日志、schema 和读取追踪方式。  


管理规范/模板：../../common/exp-doc/实验存储体系创建指南.md；../../common/exp-doc/实验环境创建指南.md。  


引用文件：实验规范.md；实验总纲.md；实验设计.md；实验执行日志.md；实验审计报告.md。  


记录方式：存储体系入口；目录、结果包命名、schema 或读取规则变化时维护更新。




## 1. 定位


## 1. 目录映射




本指南用于回答：


| 路径 | 作用 | 状态 |


|---|---|---|


| `../exp-data/raw/` | 原始输入索引、抽样数据或外部文件引用 | 已创建 |


| `../exp-data/result/` | 正式结果包、manifest、summary、readout 和可复核中间产物 | 已创建 |


| `../exp-data/img/` | 图片、图表和图片 manifest | 已创建 |


| `../exp-data/tmp/` | 临时文件，不得作为正式证据入口 | 已创建 |




```text


当一个项目启用实验体系时，实验数据应该放哪里、怎么存、怎么读、怎么追踪、表 schema 怎么写。


```


## 2. 结果包命名




项目内应创建一个 `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>/


manifest.json


summary.md


summary.json


readout.md


intermediate/      # 需要长期复核的中间数据


```




图片文件名应尽量包含：


图片放入 `exp-data/img/<experiment_id>/<run_id>/`，并用 manifest 记录来源、生成方式和用途。




1. 样本 ID。


2. 标的或对象 ID。


3. 日期或窗口。


4. 图类型。


## 3. 追踪规则




例如：


1. `实验总纲.md` 记录实验 ID、状态、设计入口、结果包入口和审计入口。


2. `实验设计.md` 记录数据源、样本、步骤、产物和判定标准。


3. `实验执行日志.md` 记录 run ID、输入、命令摘要、输出路径、自检和偏离。


4. `实验审计报告.md` 记录设计审核、执行审核和复审结论。




```text


CASE001_OBJECT001_2024-01-05_event_review.png


```


## 4. 禁止事项




图片必须能从表或 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 能找到、读懂、复核数据，不是给主流程层层加码。


1. 不得把 `exp-data/tmp/` 当正式证据入口。


2. 不得把数据库密码、授权 token 或私有凭据写入结果包。


3. 不得只有窗口文字结论而没有结果包或明确的 `HELD` 记录。


4. 不得把大表、大日志或批量图片直接回显到 Codex 会话窗口。




 exp-doc/实验审核规范.md


@@ -1,444 +1,35 @@


# 实验审核规范


# 实验审核规范




创建人员：Codex  


文件职责：定义实验设计审核、实验执行审核、复审、问题归因、通过标准和审计报告记录规则。  


管理规范/模板：common/exp-doc/实验规范.md；本文件是实验审核专用规范。  


引用文件：../../管理系统说明.md；实验规范.md；实验总纲模版.md；实验设计模版.md；


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验审核员必须遵守的本地实验审核规范。本文件引用 common 实验审核规范，不得削弱 common 硬约束。  


管理规范/模板：../../common/exp-doc/实验审核规范.md；../../common/exp-doc/实验环境创建指南.md。  


引用文件：实验规范.md；实验总纲.md；实验设计.md；实验执行日志.md；实验审计报告.md；实验问题记录.md；../项目配置清单.md。  


记录方式：项目本地审核规范；审核口径变化时更新。




统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地实验审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。


## 1. 基本口径




## 1. 定位


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




实验审核是实验事项的质量关口。


## 2. 审核范围




它不负责替执行者重新做实验，也不负责无边界地增加要求。


审核员至少检查：




它只回答：


1. 设计是否明确实验目标、样本、数据源、步骤、产物和 PASS / FAIL / HELD 标准。


2. 执行是否严格按设计进行，偏离是否记录并解释。


3. 结果包、manifest、summary、readout 是否可复核。


4. 结论是否降读，是否避免策略、收益或预测过读。


5. 是否存在凭据泄漏、大量原始输出进入窗口、或把 tmp 当正式证据。




1. 实验目标是否清楚。


2. 实验设计是否能满足目标。


3. 实验是否按设计执行。


4. 关键数据、代码、案例、产物是否对得上。


5. 是否存在会影响结论的真 bug、样本污染、口径替换或结论过读。


6. 如果实验目标要求时点安全，是否存在未来函数。


7. 当前结论能不能成立，最多能读到什么程度。


## 3. 审计记录位置




## 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、图表是否存在且对得上 |


| 案例 | 关键样本是否能人工复核 |


| 偏差 | 是否按目标处理未来函数、样本污染、时点错位 |


| 结论 | 是否存在过读 |


| 初始化审计 | `实验审计报告.md` |


| 设计审核 | `实验审计报告.md` |


| 执行审核 | `实验审计报告.md` |


| 审计发现问题 | `实验审计报告.md` 为主，`实验问题记录.md` 只做跨轮索引 |


| 非审计来源问题 | `实验问题记录.md` |




## 7. 问题分类


## 4. 审核结论




审核发现问题时，必须明确问题类型。




允许类型：




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. 必要时运行证据链上的只读脚本或检查脚本，但不得用审计脚本替代执行方正式产物。


审核结论使用：`通过`、`有条件通过`、`不通过`、`HELD`。结论必须包含证据入口、阻断项、需要修复的文档或结果包路径。




 exp-doc/实验审计报告.md


@@ -1,77 +1,28 @@


# 实验审计报告模版


# 实验审计报告




创建人员：<填写创建人员或 AI>  


文件职责：记录项目内所有实验设计审核、执行审核或复审的依据、结论、问题、证据和复审状态。  


管理规范/模板：common/exp-doc/实验审核规范.md；项目本地 exp-doc/实验审计规范.md；本文件由 common/exp-doc/实验审计报告模版.md 实例化。  


引用文件：<填写实验总纲、实验设计、执行日志、结果包入口、实验存储体系、实验审计规范>


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验体系初始化审计、设计审核、执行审核、复审和审计问题主记录。  


管理规范/模板：../../common/exp-doc/实验审计报告模版.md；../../common/exp-doc/实验审核规范.md。  


引用文件：实验审计规范.md；实验总纲.md；实验设计.md；实验执行日志.md；实验问题记录.md；../项目配置清单.md。  


记录方式：append-only 审计账本；审核结论和审计问题追加到文件末尾。




## 0. 当前审计总览


## 2026-06-25 AUDIT-EXP-SMOKE-001




- 当前最新审计：<audit_id / 状态>


- 当前未通过审计：<audit_id / 问题摘要>


- 当前待复审事项：<audit_id / 复审条件>


- 审计 ID：AUDIT-EXP-SMOKE-001


- 审计事项：EXP-SMOKE-001 / 实验体系初始化 dry-run


- 提交方：management.admin


- 审核方：experiment.reviewer / laoshen


- 当前状态：待审核员复核




## 1. 固定审计口径


### 管理端自检




- 维护方式：append-only；每次设计审核、执行审核、复审都追加到文件末尾，最新内容在最后。


- 历史审计处理：不得删除；如被后续复审替代，追加替代说明。


- 审计重点：抓真问题，避免为模板形式吹毛求疵；但目标、设计、执行、证据链和结论边界必须一致。


- 审计问题记录：审核员发现的问题完整记录在本文；只有需要跨轮跟踪、跨实验汇总或长期处理时，才在 `实验问题记录.md` 中建立索引，不重复全文。


- `exp-doc/` 基础文档：已补齐。


- `exp-data/` 基础目录：已补齐并有 `.gitkeep`。


- 本地规范引用 common：已补齐。


- 存储体系：已补齐项目本地目录和结果包口径。


- 是否混入其他项目业务内容：管理端自检未复制具体实验、结果包、业务结论或旧路径。




## 2. 审计记录追加区


### 待审核员确认




## <YYYY-MM-DD HH:mm:ss> <audit_id>：<实验名称>


请审核员按 `../../common/exp-doc/实验环境创建指南.md` 第 5 节及后续校验口径复核，并给出 `通过 / 有条件通过 / 不通过 / HELD` 结论。




- 审计类型：<设计审核/执行审核/复审>


- 实验事项 ID：<填写>


- 实验设计 ID：<填写；设计审核必填，执行审核引用已通过设计>


- run_id：<填写；执行审核必填，设计审核可为空>


- 审核人：<填写>


- 审计结论：<通过/不通过/HELD>




### 审计依据




| 依据类型 | 路径/说明 |


|---|---|


| 实验总纲 | <填写> |


| 实验设计 | <填写> |


| 来源聊天记录 | <填写实验总纲中的聊天记录位置或摘录> |


| 执行日志 | <填写> |


| 结果包 | <填写> |


| 实验存储体系 | <填写> |


| 其他 | <填写> |




### 设计审核项




- 目标是否清楚：<通过/不通过/不适用>


- 设计是否能回答目标：<通过/不通过/不适用>


- 来源聊天要求、实验目标、实验设计是否一致：<通过/不通过/说明>


- 数据和样本是否支撑目标：<通过/不通过/不适用>


- 防偏差设计是否足够：<通过/不通过/不适用>


- 产物是否方便复核：<通过/不通过/不适用>




### 执行审核项




- 是否按设计执行：<通过/不通过/不适用>


- 输入输出是否对得上：<通过/不通过/不适用>


- 关键数据是否可追踪：<通过/不通过/不适用>


- 是否存在真 bug：<无/有；说明>


- 是否需要防未来函数：<是/否/不适用；必须和实验设计一致>


- 如需防未来函数，是否存在未来函数或时间口径错误：<无/有/不适用；说明>


- 结论是否过读：<无/有；说明>




### 问题清单




| 问题 ID | 类型 | 严重度 | 证据 | 影响 | 建议处理 |


|---|---|---|---|---|---|


| <ISSUE-001> | <设计/执行/数据/代码/结论/其他> | <阻断/重要/一般> | <路径/说明> | <填写> | <填写> |




### 审计边界和结论




- 本次审计覆盖：<填写>


- 本次审计未覆盖：<填写>


- 可以读成：<填写>


- 不应过读为：<填写>


- 是否需要复审：<是/否>


- 复审入口：<路径>


- 结论回写建议：<填写>




 exp-doc/实验审计规范.md


@@ -1,444 +1,35 @@


# 实验审核规范


# 实验审计规范




创建人员：Codex  


文件职责：定义实验设计审核、实验执行审核、复审、问题归因、通过标准和审计报告记录规则。  


管理规范/模板：common/exp-doc/实验规范.md；本文件是实验审核专用规范。  


引用文件：../../管理系统说明.md；实验规范.md；实验总纲模版.md；实验设计模版.md；


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验审核员必须遵守的本地实验审计规范。本文件引用 common 实验审核规范，不得削弱 common 硬约束。  


管理规范/模板：../../common/exp-doc/实验审核规范.md；../../common/exp-doc/实验环境创建指南.md。  


引用文件：实验规范.md；实验总纲.md；实验设计.md；实验执行日志.md；实验审计报告.md；实验问题记录.md；../项目配置清单.md。  


记录方式：项目本地审核规范；审核口径变化时更新。




统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地实验审核规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。


## 1. 基本口径




## 1. 定位


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




实验审核是实验事项的质量关口。


## 2. 审核范围




它不负责替执行者重新做实验，也不负责无边界地增加要求。


审核员至少检查：




它只回答：


1. 设计是否明确实验目标、样本、数据源、步骤、产物和 PASS / FAIL / HELD 标准。


2. 执行是否严格按设计进行，偏离是否记录并解释。


3. 结果包、manifest、summary、readout 是否可复核。


4. 结论是否降读，是否避免策略、收益或预测过读。


5. 是否存在凭据泄漏、大量原始输出进入窗口、或把 tmp 当正式证据。




1. 实验目标是否清楚。


2. 实验设计是否能满足目标。


3. 实验是否按设计执行。


4. 关键数据、代码、案例、产物是否对得上。


5. 是否存在会影响结论的真 bug、样本污染、口径替换或结论过读。


6. 如果实验目标要求时点安全，是否存在未来函数。


7. 当前结论能不能成立，最多能读到什么程度。


## 3. 审计记录位置




## 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、图表是否存在且对得上 |


| 案例 | 关键样本是否能人工复核 |


| 偏差 | 是否按目标处理未来函数、样本污染、时点错位 |


| 结论 | 是否存在过读 |


| 初始化审计 | `实验审计报告.md` |


| 设计审核 | `实验审计报告.md` |


| 执行审核 | `实验审计报告.md` |


| 审计发现问题 | `实验审计报告.md` 为主，`实验问题记录.md` 只做跨轮索引 |


| 非审计来源问题 | `实验问题记录.md` |




## 7. 问题分类


## 4. 审核结论




审核发现问题时，必须明确问题类型。




允许类型：




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. 必要时运行证据链上的只读脚本或检查脚本，但不得用审计脚本替代执行方正式产物。


审核结论使用：`通过`、`有条件通过`、`不通过`、`HELD`。结论必须包含证据入口、阻断项、需要修复的文档或结果包路径。




 exp-doc/实验总纲.md


@@ -1,95 +1,29 @@


# 实验总纲模版


# 实验总纲




创建人员：<填写创建人员或 AI>  


文件职责：记录项目内所有实验事项的背景、目标、主线口径、阶段结论、结果包入口和下一步；对应管理系统里的事项总纲账本。  


管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验总纲模版.md 实例化。  


引用文件：<填写实验规范、实验设计、实验执行日志、实验审计报告、实验存储体系、来源聊天记录或上游文档>


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验事项的背景、目标、边界、状态、结果包入口和结论。  


管理规范/模板：../../common/exp-doc/实验总纲模版.md；../../common/exp-doc/实验环境创建指南.md。  


引用文件：实验规范.md；实验设计.md；实验执行日志.md；实验审计报告.md；实验存储体系.md。  


记录方式：append-only 滚动账本；新增实验或状态变化时追加记录。




## 0. 当前总览


## 1. 当前总览




> 本节用于人和 AI 快速进入当前状态，可以随最新进展更新；详细实验记录仍必须追加到文件末尾。


| 实验 ID | 名称 | 状态 | 结论 |


|---|---|---|---|


| `EXP-SMOKE-001` | 实验体系初始化 dry-run | 已记录，待审核员复核 | 环境链路可承接实验事项；无真实业务结论 |




- 当前主线：<当前实验主线或研究方向>


- 当前最新实验：<实验事项 ID / 名称 / 状态>


- 当前有效结论：<只写已被结果和审核支持的结论>


- 当前阻断项：<无/待补数据/设计未审/执行未审/其他>


- 当前下一步：<下一步动作>


- 关键入口：<实验设计.md / 实验执行日志.md / 实验审计报告.md / 结果包索引>


## 2. 实验事项：EXP-SMOKE-001




## 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>：<取值和读法>


- <关键异常或缺口>：<无/说明>




### 当前读法




- 可以读成：<证据支持的结论>


- 不能读成：<防止过读>


- 降读/失效记录：<如无填写无；如有说明原因和替代结论>




### 下一步




- 下一步动作：<继续实验/补数据/补对照/回写方法论/进入实现/暂停>


- 继续条件：<满足什么条件才继续>


- 停止条件：<满足什么条件必须停止或降级>




### 结论回写




- 回写目标：<方法论/需求/代码/数据/下一轮实验/暂停说明>


- 回写内容：<填写>


- 回写状态：<待回写/已回写/不回写>


- 实验 ID：EXP-SMOKE-001


- 实验名称：实验体系初始化 dry-run


- 创建人员：management.admin


- 创建时间：2026-06-25T20:55:00+08:00


- 当前状态：待审核员复核


- 背景：修复 `project-info` 初始创建时实验体系目录和本地文档未按创建指南完整落地的问题。


- 目标：验证 `exp-doc/`、`exp-data/`、设计、执行日志、审计报告和问题记录之间能形成最小可追溯链路。


- 边界：本事项不是股市业务实验，不查询数据库、不生成统计结果、不产生交易建议。


- 设计入口：`exp-doc/实验设计.md#实验设计exp-smoke-001`


- 执行入口：`exp-doc/实验执行日志.md#2026-06-25-run-exp-smoke-001`


- 审计入口：`exp-doc/实验审计报告.md#2026-06-25-audit-exp-smoke-001`


- 结果包入口：无真实结果包；本事项为体系 dry-run。


- 当前结论：本地文档和数据目录已补齐，仍需审核员确认是否满足 `common/exp-doc/实验环境创建指南.md`。




 exp-doc/实验执行日志.md


@@ -1,84 +1,41 @@


# 实验执行日志模版


# 实验执行日志




创建人员：<填写创建人员或 AI>  


文件职责：记录项目内所有实验实际执行过程、关键输入输出、异常、重跑和下一步动作。  


管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验执行日志模版.md 实例化。  


引用文件：<填写实验总纲、实验设计、实验审计报告、执行脚本或数据路径>


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验 run、输入、关键过程、输出、异常、自检和重跑。  


管理规范/模板：../../common/exp-doc/实验执行日志模版.md；../../common/exp-doc/实验环境创建指南.md。  


引用文件：实验规范.md；实验总纲.md；实验设计.md；实验审计报告.md；实验存储体系.md。  


记录方式：append-only 执行日志；每次实验执行、重跑或修复追加记录。




## 0. 当前执行总览


## 2026-06-25 RUN-EXP-SMOKE-001




- 当前最新 run：<run_id / 状态>


- 当前可用结果包：<run_id / 路径>


- 当前失败或暂停 run：<run_id / 原因>


- 当前下一步：<重跑/复审/回写/暂停>


- run ID：RUN-EXP-SMOKE-001


- 所属实验：EXP-SMOKE-001


- 执行人员：management.admin


- 执行类型：体系初始化 dry-run


- 当前状态：完成，待审核员复核




## 1. 固定执行口径


### 执行步骤




- 维护方式：append-only；每次执行、重跑、人工操作、异常处理都追加到文件末尾，最新内容在最后。


- 历史 run 处理：不得删除；失败 run 标记失败/降读/暂停，并保留结果包或失败证据入口。


- 执行前置：对应实验设计必须已通过设计审核，除非明确是探索性预跑或环境 smoke。


- 路径规则：项目内文件默认使用相对路径。


1. 读取 `../../common/exp-doc/实验环境创建指南.md`。


2. 参考 common 创建指南要求，按项目本地入口、账本和审计链路重建实验体系文档。


3. 重写 `exp-doc/` 本地入口文档，避免把 common 全文复制成项目文档。


4. 确认 `exp-data/raw/`、`exp-data/result/`、`exp-data/img/`、`exp-data/tmp/` 存在。


5. 记录初始化 dry-run 到 `实验总纲.md`、`实验设计.md`、`实验审计报告.md`。




## 2. 执行日志追加区


### 产物




> 从这里开始按时间顺序追加。执行日志可以简洁，但必须写清输入、关键中间过程、中间数据位置、输出、关键计数、异常和下一步。


- `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`




## <YYYY-MM-DD HH:mm:ss> <run_id>：<实验名称>


### 结论边界




- 实验事项 ID：<填写>


- 实验设计 ID：<填写>


- 执行人：<填写>


- 执行类型：<正式执行/重跑/抽样/smoke/人工操作/复验>


- 当前状态：<运行中/成功/失败/中断/暂停/降读>


- 结果包目录：<路径>


本 run 只证明体系文档链路已按指南补齐，不证明任何股市业务结论。




### 执行动作




- 执行入口：<脚本路径、命令、人工流程或工具名>


- 工作目录：<路径/不适用>


- 关键参数：<填写>


- 配置版本：<配置路径、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/降读/失效>


- 不能读成：<防止过读>


- 下一步：<提交执行审核/补数据/重跑/回写总纲/暂停>




 exp-doc/实验规范.md


@@ -1,492 +1,42 @@


# 实验规范


# 实验规范




创建人员：Codex  


文件职责：定义通用实验体系的文档结构、实验设计流程、实验执行流程、审计入口和模板使用规则。  


管理规范/模板：项目通用实验体系架构文档；本文件不是模板文档，模板文档放在 `common/exp-doc/*模版.md`。  


引用文件：../../管理系统说明.md；../../体系说明.md；../pro-doc/需求规范.md；../dev-doc/编码规范.md；历史实验总纲、实验设计、实验计划、执行约定已去项目化抽象。


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验员必须遵守的本地实验规范。本文件引用 common 实验规范，不得削弱 common 硬约束。  


管理规范/模板：../../common/exp-doc/实验规范.md；../../common/exp-doc/实验环境创建指南.md。  


引用文件：目录导读.md；实验总纲.md；实验设计.md；实验执行日志.md；实验存储体系.md；实验审计报告.md；../项目配置清单.md。  


记录方式：项目本地规范；本项目实验流程或补充规则变化时更新。




统一依赖：本规范必须同时遵守 `../../全局规范.md` 和 `../project-doc/项目规范.md`；项目本地实验规范可补充流程，但不得违反全局规范、全局项目规范和本体系硬约束。


## 1. 基本口径




## 1. 定位


本项目所有实验员必须同时遵守 `../../common/exp-doc/实验规范.md` 和本文件。本文件当前只做项目化补充；如后续设计本地实验流程，必须满足 common 实验规范硬约束，流程通过审核后执行。




实验是一种事项类型。


## 2. 项目实验范围




实验不是单纯跑脚本，也不是只看 summary。实验必须把一个问题从“为什么要做”推进到“怎么验证、怎么执行、证据在哪里、结论能读到什么程度、是否通过审核”。


本项目实验用于验证股市信息分析相关问题，包括：




实验体系的目标：


1. K 线、成交量、市场广度、行业表现等数据统计或回放。


2. 研报、新闻、公告、公开网络信息形成的规则或假设。


3. 案例体系提出的假设是否能通过数据或证据包验证。


4. darkline 信息拓扑方法的局部验证。




1. 让实验目标、背景、原理来源可追踪。


2. 让实验设计能证明总纲里的目标。


3. 让实验执行过程、关键数据、结果包可复核。


4. 让设计和执行都经过审核，具体审核规则见 `实验审核规范.md`。


5. 让总纲、设计、执行日志、审计报告能用统一 ID 串成证据链。


6. 让结论能回写到方法论、需求、代码、数据或下一轮实验。


实验结论必须降读为实验范围内结论，不得外推为交易建议、收益承诺或预测能力。




## 1A. 全局规范和项目本地规范


## 3. 核心实验文档作用




`common/exp-doc/实验规范.md` 是全局通用实验规范。


| 文档 | 作用 |


|---|---|


| `实验总纲.md` | 记录本项目所有实验事项的背景、目标、边界、状态、结果包入口和结论 |


| `实验设计.md` | 记录实验设计、步骤、依赖、产物和判定标准 |


| `实验执行日志.md` | 记录实验 run、输入、关键中间过程、中间数据路径、输出、异常、自检和重跑 |


| `实验存储体系.md` | 说明实验数据、结果包、图片、表 schema 和读取追踪方式 |


| `实验审计报告.md` | 记录设计审核、执行审核和复审结论 |


| `实验问题记录.md` | 记录非审计来源实验问题；审计问题只记录索引 |




所有项目的实验员都必须遵守本文件。每个项目创建实验环境时都必须创建项目本地 `exp-doc/实验规范.md`。项目本地规范默认可以很短，只引用本文件并声明必须遵守；如果补充项目特化规则，不能违反本文件的硬约束。具体流程可以按 1A.1 设计本地版本。


## 4. 轻量实验和正式实验




项目本地 `实验规范.md` 即使没有额外项目规则，也必须说明本项目核心实验文档的作用和入口，至少覆盖：`实验总纲.md`、`实验设计.md`、`实验执行日志.md`、`实验存储体系.md`、`实验审计报告.md`、`实验问题记录.md`。这样实验员进入项目后，不需要回头翻 common 文档也能知道本项目实验证据链怎么走。


- 轻量实验：用于环境 dry-run、口径确认或一次性只读统计；仍要写总纲、设计、执行日志和审计记录，但可不生成复杂结果包。


- 正式实验：会影响项目结论或后续案例判断；必须先设计审核，通过后执行，执行后提交执行审核。




项目本地规范允许补充：


## 5. 数据和上下文保护




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`，不能标为 `完成`。


实验涉及大表、日志、搜索结果或图片时，主体内容必须落到 `exp-data/result/`、readout、manifest 或审计附件；Codex 窗口和 MB-X 消息只展示摘要、关键路径和结论边界。




 exp-doc/实验设计.md


@@ -1,116 +1,33 @@


# 实验设计模版


# 实验设计




创建人员：<填写创建人员或 AI>  


文件职责：记录项目内所有实验的设计、步骤、依赖、产物、判定标准、设计审核和执行结果回填；对应管理系统里的事项计划账本。  


管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验设计模版.md 实例化。  


引用文件：<填写实验总纲、实验执行日志、实验审计报告、实验存储体系、来源聊天记录或上游文档>


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验设计、步骤、依赖、产物和判定标准。  


管理规范/模板：../../common/exp-doc/实验设计模版.md；../../common/exp-doc/实验环境创建指南.md。  


引用文件：实验规范.md；实验总纲.md；实验执行日志.md；实验审计报告.md；实验存储体系.md。  


记录方式：append-only 设计账本；设计审核通过后才能执行正式实验。




## 0. 当前设计总览


## 实验设计：EXP-SMOKE-001




> 本节用于快速查看当前正在推进的实验设计，可以随最新进展更新；详细设计记录仍必须追加到文件末尾。


- 所属实验：EXP-SMOKE-001 / 实验体系初始化 dry-run


- 设计人员：management.admin


- 创建时间：2026-06-25T20:55:00+08:00


- 当前状态：待审核员复核




- 当前最新设计：<设计 ID / 实验事项 ID / 状态>


- 当前可执行设计：<设计 ID 列表；必须已通过设计审核>


- 当前阻断设计：<设计 ID / 阻断原因>


- 当前下一步：<设计修订/等待审核/进入执行/暂停>


### 目标和边界




## 0A. 文档定位和证据索引职责


- 目标：验证项目实验体系环境能从总纲追到设计、执行日志和审计报告。


- 边界：不查询真实数据库、不读取 K 线、不生成统计结果包、不产生业务结论。




- 本文件是项目内具体实验设计与证据索引主入口。


- 它负责回答：每个实验想解决什么问题、怎么验证、当前状态是什么、关键证据和结果包在哪里。


- 实验总纲回答“为什么做和最后怎么读”；实验设计回答“具体怎么做、证据在哪里、结果包是什么”。


- 后续新增实验、修订实验边界、回填执行结果，都应追加到本文件末尾，不得覆盖历史设计。


### 检查项




## 1. 固定设计口径


1. `exp-doc/` 下基础文档存在，且每个文档包含创建人员、文件职责、管理规范/模板、引用文件、记录方式。


2. `exp-data/raw/`、`exp-data/result/`、`exp-data/img/`、`exp-data/tmp/` 存在，并通过 `.gitkeep` 保证 Git 克隆后目录保留。


3. 本地规范和审计规范引用 common 规范，并声明不得削弱 common 硬约束。


4. `实验存储体系.md` 写清正式结果包、图片、readout、manifest、intermediate 和 tmp 禁止事项。


5. 项目配置清单和 `mbx.project.yaml` 已登记实验体系目录、文档和角色。




- 维护方式：append-only；新设计、新修订、新执行回填追加到文件末尾，最新内容在最后。


- 旧设计处理：不得删除；若失效，追加“失效/降读/被替代”说明。


- 设计与计划合并：本文件同时记录“要怎么验证”和“按什么步骤执行”。


- 设计审核要求：设计审核通过后才能执行；未通过则追加修订块，不覆盖旧设计。


- 路径规则：项目内文件默认使用相对路径。


### PASS / FAIL / HELD




## 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/降读/失效>


- 是否纳入实验总纲结论：<是/否；说明>


- PASS：上述检查项全部满足，且审核员确认没有旧项目业务内容混入。


- FAIL：基础文档缺失、目录缺失、规范冲突、审计入口错误或混入其他项目结论。


- HELD：需要人类确认项目范围或审核员无法读取必要文档。




 exp-doc/实验问题记录.md


@@ -1,71 +1,24 @@


# 实验问题记录模版


# 实验问题记录




创建人员：<填写创建人员或 AI>  


文件职责：记录项目内非审计来源的实验设计、执行、数据、代码、结论问题及闭环状态；对需要跨轮跟踪的审计问题只记录索引或关联。  


管理规范/模板：common/exp-doc/实验规范.md；本文件由 common/exp-doc/实验问题记录模版.md 实例化。  


引用文件：<填写实验审计报告、执行日志、实验总纲、实验设计>


创建人员：management.admin  


文件职责：记录 `project-info` 项目实验体系中非审计来源问题，或审计问题的跨轮索引。  


管理规范/模板：../../common/exp-doc/实验问题记录模版.md；../../common/exp-doc/实验环境创建指南.md。  


引用文件：实验审计报告.md；实验执行日志.md；实验总纲.md；../项目问题记录.md。  


记录方式：append-only 问题账本；新增问题、状态变化和复验结论追加记录。




## 0. 当前问题总览


## 1. 当前问题总览




- 当前开放问题数：<填写>


- 当前阻断问题：<issue_id / 摘要>


- 当前最新关闭问题：<issue_id / 摘要>


- 当前下一步：<修复/复验/降读/暂停>


| 问题 ID | 来源 | 严重级别 | 状态 | 主记录 |


|---|---|---|---|---|


| EXP-ISSUE-20260625-DOCS-INIT-001 | 人类反馈 | 中 | 已由 management.admin 重建，待审核员复核 | `实验审计报告.md#2026-06-25-audit-exp-smoke-001` |




## 1. 固定问题闭环口径


## 2. 问题记录




- 维护方式：append-only；新问题、修复、复验、关闭都追加到文件末尾，最新内容在最后。


- 历史问题处理：不得删除；误报也应追加“误报/不处理/降读”说明。


- 问题分级：阻断 / 重要 / 一般。


- 问题类型：设计 / 执行 / 数据 / 代码 / 结论 / 流程。


- 审计问题口径：审核员发现的问题主记录写入 `实验审计报告.md`；本文件只记录需要跨轮跟踪的审计问题索引，不重复全文。


- 非审计问题口径：实验员、执行 AI、人工同事或其他非审计角色发现的问题，主记录写入本文件。


### EXP-ISSUE-20260625-DOCS-INIT-001：初始实验体系文档未按创建指南项目化




## 2. 问题记录追加区


- 来源：人类反馈。


- 描述：此前 `project-info` 的 `exp-doc/` 文档由 common 模板机械复制，未按实验环境创建指南完成项目化入口、存储体系、dry-run 和初始化审计。


- 影响：实验体系虽有文件，但不能可靠承接正式实验事项。


- 处理：management.admin 已按 common 创建指南重建本地入口文档。


- 当前状态：待审核员复核。




## <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>




### 关闭结论




- 是否关闭：<是/否>


- 关闭原因：<填写>


- 后续跟踪：<无/下一轮实验/长期观察>




 exp-doc/目录导读.md


@@ -1,46 +1,42 @@


# exp-doc 目录导读


# exp-doc 目录导读




创建人员：Codex  


文件职责：说明 `common/exp-doc` 目录下实验规范和实验模板文档的用途。  


管理规范/模板：../../管理系统说明.md；../../体系说明.md；common/exp-doc/实验规范.md。  


引用文件：实验规范.md；本目录下全部 `*模版.md` 文件。


创建人员：management.admin  


文件职责：说明 `project-info` 项目实验体系文档入口和相邻数据目录用途。  


管理规范/模板：../项目规范.md；../../common/exp-doc/实验环境创建指南.md；../../common/exp-doc/实验规范.md。  


引用文件：实验规范.md；实验审计规范.md；实验存储体系.md；实验总纲.md；实验设计.md；实验执行日志.md；实验审计报告.md；实验问题记录.md；../项目配置清单.md。  


记录方式：目录入口文档；本目录正式文件新增、删除、改名或职责变化时同步更新。




## 1. 目录定位


## 1. 本体系定位




本目录保存通用实验体系规范和实验体系模板。


`project-info` 的实验体系用于对股市信息分析中的假设、数据口径、K 线统计、研报/新闻规则和信息拓扑方法做可复核验证。实验体系只输出实验结果和边界，不替代案例体系的案例叙事，也不直接给出交易建议。




`实验规范.md` 是体系说明文件，不是模板。


## 2. 文档入口




`*模版.md` 文件用于新项目或新实验事项创建时实例化对应实验文档。


| 文件 | 作用 |


|---|---|


| `实验规范.md` | 本项目实验员必须遵守的本地规范入口 |


| `实验审计规范.md` | 本项目实验审核员必须遵守的本地审核规范入口 |


| `实验审核规范.md` | common 审核规范的项目副本/兼容入口；优先使用 `实验审计规范.md` |


| `实验存储体系.md` | 实验数据、结果包、图片、日志和 schema 的存储口径 |


| `实验总纲.md` | 实验事项背景、目标、边界、状态和结论账本 |


| `实验设计.md` | 实验设计、步骤、依赖、产物和判定标准 |


| `实验执行日志.md` | 实验 run、输入、关键过程、输出、异常、自检和重跑记录 |


| `实验审计报告.md` | 设计审核、执行审核、复审和审计问题主记录 |


| `实验问题记录.md` | 非审计来源实验问题，审计问题只做索引 |




## 2. 文件清单


## 3. 数据目录




| 文件 | 类型 | 作用 |


|---|---|---|


| 实验规范.md | 体系规范 | 说明实验体系核心流程、文档职责和审计闭环 |


| 实验环境创建指南.md | 创建指南 | 指导 AI 在项目中创建完整实验员工作环境 |


| 实验总纲模版.md | 模板 | 创建项目级实验总纲滚动账本 |


| 实验设计模版.md | 模板 | 创建项目级实验设计滚动账本 |


| 实验执行日志模版.md | 模板 | 创建项目级实验执行日志滚动账本 |


| 实验存储体系创建指南.md | 创建指南 | 指导项目创建实验存储体系文档、数据目录、schema 和读取规则 |


| 实验审核规范.md | 审核规范 | 定义实验设计审核、执行审核、复审和审计报告记录规则；项目内应实例化为 `实验审计规范.md` |


| 实验审计报告模版.md | 模板 | 创建项目级实验审计报告滚动账本 |


| 实验问题记录模版.md | 模板 | 创建项目级实验非审计问题闭环滚动账本；审计问题只做索引 |


| 目录 | 作用 |


|---|---|


| `../exp-data/raw/` | 实验原始输入索引、抽样数据或外部文件引用 |


| `../exp-data/result/` | 正式结果包、manifest、summary、readout 和中间可复核产物 |


| `../exp-data/img/` | 实验图片、图表和图片 manifest |


| `../exp-data/tmp/` | 临时数据，不得作为正式证据入口 |




## 3. 使用顺序


## 4. 当前实验入口




创建正式实验事项时，建议顺序：


| 实验 ID | 名称 | 状态 | 入口 |


|---|---|---|---|


| `EXP-SMOKE-001` | 实验体系初始化 dry-run | 初始化完成，待审核员复核 | `实验总纲.md`、`实验设计.md`、`实验执行日志.md`、`实验审计报告.md` |




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、最新审计和最新问题记录都追加到对应文件末尾。


新增正式实验时，应先写 `实验总纲.md` 和 `实验设计.md`；设计审核通过后才能执行，执行完成后必须提交执行审核。




 项目事项审计报告.md


@@ -470,3 +470,47 @@


  - 新增目录：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-25T20:52:00+08:00 PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW 审核结论




- 审核角色：case_analysis.reviewer


- 消息来源：msg_20260625204339662_99c52dd1 / case_analysis.analyst 转交 management.admin 审核请求


- 审核类型：项目级体系补建完整性审核


- 审核对象：case_analysis 与 experiment 体系根目录文档、数据目录、配置登记、项目级记录和提交状态


- 审核依据：


  - mbx.project.yaml


  - 项目配置清单.md


  - 项目规范.md


  - ana-doc/案例审核规范.md


  - 项目执行日志.md


  - 项目事项审计报告.md


- 检查结果：


  - mbx.project.yaml 中 case_analysis 登记了 ana-doc、ana-data、ana-data/cases、ana-data/result、ana-data/img、ana-data/tmp；docs 映射包含目录导读、案例分析规范、案例审核规范、案例总纲、案例分析设计、案例执行日志、案例审计报告、案例问题记录、案例存储体系。


  - mbx.project.yaml 中 experiment 登记了 exp-doc、exp-data、exp-data/raw、exp-data/result、exp-data/img、exp-data/tmp；docs 映射包含目录导读、实验规范、实验审核规范、实验审计规范、实验存储体系、实验总纲、实验设计、实验执行日志、实验审计报告、实验问题记录。


  - 文件系统核查确认 ana-doc/ 9 个要求文档均存在，ana-data/cases、ana-data/result、ana-data/img、ana-data/tmp 均存在 .gitkeep。


  - 文件系统核查确认 exp-doc/ 10 个要求文档均存在，exp-data/raw、exp-data/result、exp-data/img、exp-data/tmp 均存在 .gitkeep。


  - dev_targets 中 ana.audit_report_doc 指向 ana-doc/案例审计报告.md，exp.audit_report_doc 指向 exp-doc/实验审计报告.md。


  - 项目配置清单.md、项目执行日志.md、项目事项审计报告.md、项目变更记录.md 已反映本次体系补建目录、文档和入口。


  - 执行 python -m mbx.cli validate --project project-info --governance，结果 OK，warnings=0。


  - git 分支 master 跟踪 origin/master，当前 HEAD 为 df3b9d1 fix: add analysis and experiment systems；该提交包含 ana-doc、ana-data、exp-doc、exp-data、mbx.project.yaml 和项目级同步文档。


  - git status --short 仅显示 .mbx/messages.jsonl 与 .mbx/inbox/ 运行态消息文件变化，未发现本次体系补建正式文件漏提交。


- 问题清单：未发现阻断问题。


- 结论：通过。


- 是否需要 management.admin 继续修复：不需要。治理校验已通过，本次人工核查已覆盖配置、文件系统、.gitkeep、项目级记录、提交内容和未提交正式文件；后续仅需在具体案例或实验事项开始时按各自体系规范继续做业务级设计/执行审核。


- 备注：本结论只覆盖体系环境补建完整性，不替代后续具体案例分析、实验设计、执行证据包或开发实现的专项审核。




## 2026-06-25T21:03:00+08:00 PROJECT-INFO-SYSTEM-DOCS-REBUILD 待复审记录




- 记录人员：management.admin


- 关联前序审核：`PROJECT-INFO-SYSTEM-DOCS-REPAIR-REVIEW`


- 触发原因：人类反馈指出 `project-info` 的案例体系与实验体系文档仍不符合 common 创建指南要求，先前版本只是机械复制 common 模板，没有完成项目本地化实例化。


- 管理端处理：


  - 已重新读取 `common/ana-doc/案例分析环境创建指南.md` 和 `common/exp-doc/实验环境创建指南.md`。


  - 已重写 `ana-doc/` 和 `exp-doc/` 下的本地规范、目录导读、存储体系、总纲、设计、执行日志、审计报告和问题记录。


  - 已建立 `ANA-SMOKE-001` 和 `EXP-SMOKE-001` 初始化 dry-run 链路。


  - 已确认 `ana-doc/`、`exp-doc/` 中无 `wuji` / `无忌` / `EXP-WUJI` 等旧项目业务内容残留。


  - 已执行 `python -m mbx.cli validate --project project-info --governance`，结果 OK，warnings=0。


- 审计影响：


  - 前序“体系补建完整性通过”结论只覆盖目录、配置和提交完整性，不覆盖本次重建后的文档内容质量。


  - 本事项需由 `case_analysis.reviewer` / `experiment.reviewer` 基于新文档重新复审。


- 当前状态：待审核员复审。




 项目执行日志.md


@@ -473,3 +473,42 @@


- 初始创建时只完成了体系配置、角色和会话绑定，未完整落地根目录体系文档与数据目录；本次已补齐。




当前状态：完成。




## 2026-06-25 21:02:00 PROJECT-INFO-SYSTEM-DOCS-REBUILD：重建案例与实验体系本地文档




所属项目：


project-info / info




执行人员：


management.admin




动作类型：


审计修复 / 体系文档重建 / 项目化实例化




执行目标：


修复 `PROJECT-INFO-SYSTEM-DOCS-REPAIR` 中仅机械复制 common 模板、未按创建指南完成项目本地化的问题，重建 `ana-doc/` 与 `exp-doc/` 的正式入口文档。




执行过程：




1. 重新读取 `common/ana-doc/案例分析环境创建指南.md` 和 `common/exp-doc/实验环境创建指南.md`。


2. 复核成熟项目的体系落地方式，仅参考结构和账本组织方式，不复制任何业务内容、旧路径或旧结论。


3. 重写 `ana-doc/` 下目录导读、本地案例分析规范、本地案例审核规范、案例存储体系、案例总纲、案例分析设计、案例执行日志、案例审计报告和案例问题记录。


4. 重写 `exp-doc/` 下目录导读、本地实验规范、本地实验审计规范、本地实验审核规范、实验存储体系、实验总纲、实验设计、实验执行日志、实验审计报告和实验问题记录。


5. 在案例体系和实验体系中分别建立初始化 dry-run 事项：`ANA-SMOKE-001`、`EXP-SMOKE-001`，形成总纲 -> 设计 -> 执行日志 -> 审计报告的最小链路。


6. 检查正式文档头部字段，确认全部具备创建人员、文件职责、管理规范/模板、引用文件、记录方式。


7. 检查 `ana-doc/`、`exp-doc/`，确认无 `wuji` / `无忌` / `EXP-WUJI` 等旧项目业务内容残留。


8. 执行 `python -m mbx.cli validate --project project-info --governance`，结果通过，warnings=0。




关键输出：




- `ana-doc/` 已由 common 全文复制改为 `project-info` 本地入口文档。


- `exp-doc/` 已由 common 全文复制改为 `project-info` 本地入口文档。


- `ANA-SMOKE-001`、`EXP-SMOKE-001` 已记录为体系初始化 dry-run，不代表真实业务结论。


- 治理校验：OK，warnings=0。




异常 / 偏离：




- 先前 `df3b9d1` 版本的体系文档质量不足；虽然目录和配置完整，但文档内容没有按创建指南完成项目化实例化。该问题由人类反馈指出，本次已重建。


- 先前审核员基于旧版本给出的体系补建完整性“通过”结论不再作为最终结论，需要审核员基于本次重建后的文档重新复核。




当前状态：完成，待审核员重新审核。