文档作用：说明“炒股笔记研究”这套体系的背景、目的、核心流程、文件分工、图片规范和工程化边界。后续所有围绕
天下模型沉淀/方法论/炒股笔记.md的研究、案例、验证和规则沉淀，都应优先遵循本文档。本文档会随着研究持续完善。
天下模型沉淀/方法论/炒股笔记.md 中的“无忌交易系统”不是代码需求文档，而是人的交易经验笔记。
人的交易经验通常有几个特点：
所以本体系不把 AI 当成纯程序员，不直接做：
笔记 -> 参数 -> 代码
而是让 AI 先作为分析师做：
笔记 -> 交易假设 -> 案例理解 -> 隐含条件 -> 规则卡 -> 代码
本体系的目标是：
研究炒股笔记
验证无忌交易系统里的经验在哪些情况下成立
补足笔记里没有写出来的隐含条件
沉淀成我们自己的高胜率 / 高收益率交易方案
当前基本假设：
先假设“无忌交易系统”章节说的是对的。
我们不急着否定，而是小心验证它在什么条件下对、为什么对、什么时候不对。
案例存储主文档：
mirror/交易系统/炒股笔记研究/炒股笔记案例存储体系.md
人工和 AI 共用的一页式追踪入口：
mirror/交易系统/炒股笔记研究/无忌研究证据链看板.md
baseline / proxy replay 口径版本冻结入口：
mirror/交易系统/炒股笔记研究/无忌baseline回放口径版本冻结.md
baseline 手工账本执行和审计入口：
mirror/交易系统/炒股笔记研究/无忌baseline手工账本执行与审计指南.md
后续所有正式案例都应尽量落入 MySQL 案例库，并保留 K 线图、源窗口、关键锚点和判断版本。
研究顺序：
先人工和案例验证
再沉淀规则卡
最后才考虑工程化
笔记条目不能直接等价为工程规则。
例如：
放量长上影
不能直接写成：
upper_shadow_ratio >= 0.4
必须先研究它在原笔记里的完整语义：
近期涨停
回调
底部承接
长期横盘或横盘涨停后调整回来
放量长上影
打到前高必须放量过前高量
很多笔记条目只是一个证据，不是完整结构。
单条规则可能表现一般，但多条规则组合起来才有效。
例如：
近期涨停后回调确认底部
单独太宽。
放量长上影
单独也太宽。
但组合后可能形成：
近期涨停后回调确认底部
+ 放量长上影测试抛压
+ 突破前高 / 放量突破
这才可能是完整结构。
因此本体系不要求每条笔记单独打赢。更重要的是判断它在交易结构里扮演什么角色。
每条笔记要先判定角色：
STRUCTURE_CORE 主结构规则
BACKGROUND_FILTER 背景过滤规则
CONFIRMATION_SIGNAL 确认规则
FALSE_SIGNAL_FILTER 假信号过滤规则
RISK_CONTROL 风险规则
EXECUTION_RULE 执行规则
POSITION_RULE 仓位规则
REVIEW_ONLY 暂只观察
然后再研究组合：
核心结构
+ 背景过滤
+ 确认信号
+ 假信号过滤
+ 风险控制
无忌交易系统应先被视为一个整体系统，而不是一组可以孤立验证的单条规则。
单条规则独立胜率低，不等于它在系统里无效。它可能只是：
背景过滤
候选池收窄
确认信号
假信号过滤
风险过滤
执行触发
因此后续研究不能只问：
某一条规则单独能不能赚钱？
更应该问：
这条规则在整体系统里承担什么角色？
加入 / 删除 / 替换这条规则后，整体系统表现是否变化？
它能否减少错误样本、提高组合质量、增强确认、降低尾部风险？
反例分析也只能服务于这个目标：找出缺失条件、错误翻译、适用边界和组合依赖。不能为了事后解释失败样本而编故事。
本体系的主位是人工研究和 AI 分析，不是把笔记直接翻译成脚本。
脚本只能用于：
取数
抽样
统计
画图
复核
批量检查
生成验收包
脚本不能替代：
语义理解
角色判断
图形阅读
案例归因
隐含条件发现
系统结构判断
工程化取舍
原因是：笔记来自人的经验，原文往往省略了上下文、隐含条件和盘感判断。若一开始就把笔记当需求文档写代码，容易出现三类问题：
把正确经验翻译错，误判路不通。
参数偶然跑好，但不理解为什么。
脚本有 bug 或逻辑错，却把错误结果当研究结论。
所以研究顺序必须是：
人工理解原文
-> 人工看案例和 K 线
-> 总结结构和隐含条件
-> 小规模数据验证
-> 必要时脚本辅助扩样本
-> 人工复核
-> 再考虑规则卡和工程化
模糊图形条件必须坚持人工主位：
长期横盘
底部承接
上方抛压测试
假突破 / 真突破
高位诱多 / 二次点火
这些词本质上是人的图形理解，不是天然等于一个固定参数。脚本可以提供候选、窗口统计、横盘天数、振幅、成交量和前高距离，但不能在研究早期用单一阈值直接否定案例。
例如 长期横盘 >= 60 个交易日 是工程扫描参考边界；在人工案例研究中，应同时保留：
strict_feature_pass_flag
manual_chart_judgement
manual_judgement_reason
manual_vs_strict_feature_conflict_flag
如果 strict 特征未过但图形语义成立，应保留为 review / manual confirmed 样本，后续再通过案例和实验判断是否需要新增更贴近人眼的工程规则。
无忌交易系统里的选股法只负责产生候选池，不直接产生最终买入标的池。
真正的买入决策发生在盘中分时买点层。
日线选股法
-> 候选池
-> 盘中分时确认
-> 买入执行
-> 卖点与风控
因此，在没有分时数据时，日线实验只能验证：
候选池质量
组合筛选质量
是否值得盘中盯
不能验证：
完整买入规则
完整卖出规则
完整仓位规则
完整无忌交易系统收益
后续所有日线实验结论必须带上这个边界。
每一轮研究的关键判断都必须能被其他人复核。
凡是影响结论的节点，都要留下数据、日志或样本证据：
原始笔记条目
语义解释
案例选择原因
K 线图路径
样本数据路径
人工判断记录
脚本输入输出
实验 summary / compare / manifest / readout
规则变化原因
被保留和被否决的结论
留痕目的不是堆材料，而是保证别人能回答：
这个结论从哪里来？
用了哪些样本？
哪些判断是人工做的？
哪些判断是脚本算的？
有没有可复验的数据？
如果结论错了，错在语义、样本、脚本还是规则？
禁止：
只写最终结论，不留中间判断。
只写口头解释，不留样本和图。
脚本跑完只记录结果，不记录输入、版本和边界。
人工改规则但不记录为什么改。
正式案例不能只给一张最终收益图。每一个影响案例读法的操作节点，都应尽量有图片证据支撑。
最低要求：
案例总览：一页式 case_story_board，按时间顺序串起候选、买入、卖出 / 持有、结果。后续优先做成图形化总览：包含时间线、关键节点、子图缩略图或明确的子图入口，不只做纯文字卡。
全景日 K：每个案例至少一张全景日 K 图，覆盖该案例所有买点、卖点和关键持有节点，并标出为什么选它。
候选入池：日 K 图，标出满足哪些 selector、参考锚点和图形条件；可与全景日 K 合并，但不能缺少“为什么入选”的标注。
买入动作：1 分钟分时 decision view，标出买入时间、买入价、买入份额、当时可见条件。
卖出动作：优先 1 分钟分时 decision view，标出卖出时间、卖出价、卖出份额、卖出理由；日 K 只作为趋势背景或无法取得分时数据时的降级图。
继续持有 / 不操作：只对影响结果的关键节点给 daily hold / intraday audit 图，说明为什么没卖或没买。
如果同一只股票同一天存在多个买点和卖点，优先合并到同一张 1 分钟分时图里，并用中文标注区分买入、止盈、风险卖、滚动卖和持有观察点。
图标题、图例、买卖理由、看图说明必须用中文。英文 selector / action code 可以保留为追溯字段，但不能作为同事验收的主说明。
图片必须分清两类视图：
decision_view：只能展示当时决策前可见的信息，用来防未来函数。
audit_view：允许展示后续走势，用来复盘结果和解释收益，不得反过来参与当时决策。
每张图都必须能追溯到：
case_id
symbol
trade_date
portfolio_case_id
order_id / event_id
anchor_id
chart_role
source_window_path
chart_path
decision_time
visibility_cutoff_time
decision_or_audit
如果关键操作缺图，案例不能按完整可审计案例通过，只能标记：
CHART_EVIDENCE_INCOMPLETE_REVIEW
当前版本流程如下，后续可持续完善：
炒股笔记原文
-> 笔记条目抽取
-> 单条语义解释
-> 条目角色判定
-> 单条样本观察
-> 多条组合假设
-> 组合样本观察
-> 正例 / 反例 / 边界例归因
-> 操作级图片证据链生成
-> 隐含条件总结
-> 人工复核
-> 规则沉淀
-> 工程化判断
从 炒股笔记.md 中拆出独立条目。
每条至少记录：
note_item_id
source_section
source_text
initial_reading
把笔记文字翻译成市场语言。
重点回答：
这句话在描述什么市场现象？
它是位置、量能、形态、承接、突破、过滤、执行，还是风险控制？
它有没有隐含条件？
不要默认每条都是买入规则。
先判断它是：
主结构
背景过滤
确认信号
假信号过滤
风险控制
执行规则
仓位规则
单条规则先找样本，但不要求单条必须有效。
观察重点：
它覆盖什么样的股票？
它更像成功前兆，还是失败过滤？
它是否过宽？
它是否只在某些市场环境下有用？
如果单条规则只是证据，应进一步组合。
组合假设至少写清：
combination_id
included_note_items
combination_logic
required_rules
optional_rules
forbidden_rules
组合样本要看：
是否比单条更窄
是否更符合图形语义
是否胜率 / 收益 / 尾部风险改善
是否只是样本过窄或行情偶然
不能只看成功案例。
每条或每组规则都要保留：
正例：规则明显成立且后续走势符合预期
反例：规则成立但后续失败
边界例：规则部分成立，判断困难
反常识例：看似利好但失败，或看似失败但成功
案例归因后，必须把“为什么选、为什么买、为什么卖、为什么不动”落到图片证据链。
执行口径：
1. 故事板：为每个正式案例生成一页式 case_story_board，作为同事验收主入口。后续优先做图形化故事板，至少包含时间线、关键动作节点、收益结果、关键子图入口；条件允许时嵌入候选 / 买入 / 卖出缩略图。
2. 选股阶段：为入选股票生成日 K 图，标出 selector、参考点、关键锚点。
3. 买入阶段：为每次买入生成分时 decision view，图上标买点、价格、仓位、当时可见条件。
4. 卖出阶段：为每次风险卖、止盈卖、滚动卖生成 decision view，图上标卖点、价格、仓位、触发规则。
5. 持有 / 不操作阶段：只对关键节点画图，例如该买没买、该卖没卖、止损线接近、破 5 日线、不过开盘价、放量滞涨。
6. 审计阶段：必要时生成 audit view，展示后续路径，但必须标明它只用于复盘。
7. 缺图阶段：关键节点缺图时，不允许把该案例读成完整可审计案例。
图片证据链的目的不是美化报告，而是让同事能只看图就复核：
这只股票为什么入池？
当时为什么可以买？
卖点是否按原文系统执行？
是否用了决策后才出现的信息？
收益是由买点、卖点、持有，还是市场环境贡献的？
图片不是只要求存在，还要能看懂和能反查。最低标注要求：
候选图：命中条件、关键位置、参考锚点。
买入图：买入时间、价格、仓位、触发条件。
卖出图：卖出时间、价格、仓位、卖出理由。
持有 / 不操作图：关键风险线、观察条件、为什么当时不动。
从案例里总结笔记没写出来的条件。
例如：
必须处于低位
必须有题材风
不能是高位长上影
长上影后不能放量滞涨
20 日横盘只能算短横盘
长期横盘至少 60 个交易日
人工复核不是要求人把所有规则写清，而是纠正 AI 的理解偏差。
人工重点看：
图形语义是否对
案例归因是否牵强
是否漏了明显盘面条件
是否把出货误读成试盘
是否把后验结果倒推成规则
只有经过案例、反例、组合、人工复核后，才进入规则沉淀。
规则沉淀不是代码，而是规则卡。
工程化只能发生在最后。
必须先有：
清晰语义
样本证据
失败边界
隐含条件
人工复核
规则卡
然后才进入代码实现。
笔记研究体系说明.md本文档。
作用：
定义整个研究体系的背景、目的、流程、文件职责、图片规范和工程化边界。
AI 和人开始研究前，应先阅读本文档。
无忌笔记研究总纲.md作用：
记录无忌笔记研究主线、阶段目标、当前结论、已完成条目、暂停条目、下一步方向。
它回答：
目前研究到哪一步？
哪些条目值得继续？
哪些条目已降读？
哪些组合最重要？
无忌笔记条目索引.md作用：
把炒股笔记拆成可追踪条目。
每个条目应记录：
note_item_id
source_text
source_section
rule_role
semantic_reading
related_combination_ids
research_status
无忌笔记案例库.md作用：
记录具体案例分析。
每个案例要尽量按故事讲清：
为什么选这个样本？
笔记条目如何命中？
图上发生了什么？
为什么它成功？
为什么它失败？
它暴露了什么隐含条件？
它支持或反驳了哪条笔记？
无忌笔记验证日志.md作用：
记录每一轮研究、实验、人工反馈、AI 修正过程。
它回答：
这轮看了什么？
发现了什么？
人反馈了什么？
AI 改了什么理解？
哪些结论被保留、修正或废弃？
无忌笔记规则沉淀.md作用：
记录已经相对稳定的规则卡和组合规则卡。
规则卡可以是单条，也可以是组合。
单条规则卡至少记录：
rule_card_id
source_note_item_id
rule_role
semantic_definition
success_cases
failure_cases
hidden_conditions
engineering_status
组合规则卡至少记录：
combination_id
included_note_items
combination_logic
required_rules
optional_rules
forbidden_rules
success_case_ids
failure_case_ids
hidden_conditions
confidence_level
engineering_status
案例研究不是只写结论，必须能复盘当时场景。后续用 ts 做正式案例时，默认按下面流程执行。
确定研究对象
-> 构造正例 / 反例 / 边界例
-> 生成 K 线图和源窗口
-> 标记关键锚点
-> 生成操作级图片证据链
-> 记录 AI / 人工判断
-> 写入 MySQL 案例库
-> 跑案例校验
-> 回写案例库 / 验证日志 / 数据索引
研究对象必须写清：
research_scope
research_object
source_note_items
expected_role_in_system
forbidden_reading
案例池至少包含：
正例
反例
边界例
反常识例（可选）
每个案例至少要保留：
case_id
symbol
window_start_date
window_end_date
signal_trade_date
entry_trade_date
K 线图
源窗口 CSV
关键锚点
操作级图片证据链
case_story_board
decision_view / audit_view 分账
visual_story
rule_implication
manual_review_focus
正式案例尽量写入 MySQL，表结构和字段合同见：
mirror/交易系统/炒股笔记研究/炒股笔记案例存储体系.md
当前主表：
ts_case_study_casepack
ts_case_study_case_header
ts_case_study_kline_window
ts_case_study_anchor
ts_case_study_asset
ts_case_study_judgment
ts_case_study_tag
入库边界：
案例入库不等于规则成立。
案例库不是买入规则库。
工程化只能消费规则沉淀和需求冻结后的内容。
判断版本边界：
后续每轮 AI / 观察员 / 用户 / 同事 更新判断时，必须新增 judgment_version。
不能覆盖旧判断。
不能把旧判断直接改成新结论。
必须能看到最初怎么看、后来为什么改、改成了什么。
推荐版本名：
AI_PREREVIEW_V1
AI_CHART_REVIEW_V1
OBSERVER_REVIEW_V1
USER_FEEDBACK_V1
RULE_IMPLICATION_V2
入库后必须校验案例是否能被别人复核。校验目标不是证明选股法有效，而是证明：
案例数据完整
图和源窗口存在
关键操作节点有图片证据链
decision_view 不包含决策后信息
audit_view 不反向参与决策
关键锚点可追踪
判断文本可复核
文件 hash / size 未漂移
工程化放行标记没有误开
轻量校验脚本：
mirror/dev/validate_ts_case_study_casepack_20260528.py
用法：
$env:TIANXIA_MYSQL_PWD='...'
python mirror/dev/validate_ts_case_study_casepack_20260528.py --casepack-id WUJI-CASEPACK0
校验输出：
ts_casepack_validation_<casepack_id>.json
ts_casepack_validation_<casepack_id>.csv
校验读法：
PASS：案例包结构完整，可以用于后续人工复核和二次分析。
WARN：有非阻断问题，需要标注后使用。
FAIL：案例包不能作为正式案例包消费。
收集、入库、校验完成后，至少回写：
无忌笔记案例库.md
无忌笔记验证日志.md
mirror/data/result/数据索引.md
observer/model/数据库索引数据.md（如新增表或重要数据）
如产生规则启发，写入：
无忌笔记规则沉淀.md
但只能写为：
PENDING_MANUAL_CONFIRMATION
RULE_IMPLICATION_ONLY
NOT_ENGINEERING_RULE
除非后续已经通过人工复核和实验验证。
图片目录：
mirror/交易系统/炒股笔记研究/image
用途：
专门存放炒股笔记研究相关案例图片。
要求：
decision_view 或 audit_view。不能用包含未来走势的 audit 图证明当时可以买或该卖。case_story_board，作为人工验收主入口。case_id / symbol / trade_date / order_id 或 event_id / chart_role / decision_time。建议命名：
CASE_{case_id}__{symbol}__{date}__{note_item_id}.png
例如：
CASE_WUJI_UPPER_0001__000001.SZ__20240520__NOTE_UPPER_SHADOW.png
本体系当前支持：
炒股笔记研究
案例分析
条目角色判定
组合假设验证
规则沉淀
工程化前置准备
本体系当前不支持：
直接生成买入规则
直接生成仓位规则
直接证明无忌交易系统有效
直接接账户回放作为最终结论
炒股笔记研究 是研究体系，不是绕过实验流程的新通道。
凡是进入以下工作，都必须继续遵守 mirror 既有实验流程：
数据实验
样本包生成
批量扫描
收益回放
严格对照
规则复验
工程化前验证
标准流程仍然是：
炒股笔记研究文档提出假设
-> 实验总纲记录背景、目标、原理来源
-> 实验计划记录设计、输入、输出、边界
-> 跑实验
-> 产出 result 包
-> 输出 summary / compare / manifest / readout
-> 结论归档
-> 回写炒股笔记研究文档
-> 必要时更新规则沉淀
也就是说：
炒股笔记研究体系负责提出假设、记录案例、沉淀规则。
实验总纲 / 实验计划 / result 包负责验证和审计。
禁止：
只在研究文档里写结论，不登记实验。
只看案例就升级工程规则。
用炒股笔记研究文档替代 summary / compare / manifest。
优先研究：
放量长上影
近期涨停后回调反复确认底部
放量突破
突破前高
一进二
强势股回调低吸
尤其优先研究组合：
近期涨停后回调确认底部
+ 放量长上影测试抛压
+ 放量突破 / 前高突破
原因：
前序实验显示，单条规则偏宽；
但组合后出现局部改善；
这说明笔记更可能是“多证据结构”，不是单参数规则。
后续每次有新发现，应判断写入位置：
无忌研究证据链看板.md。无忌笔记条目索引.md。无忌笔记案例库.md。无忌笔记验证日志.md。无忌笔记规则沉淀.md。image/。原则：
先理解，再验证；
先案例，再规则；
先规则卡，再代码。
本目录文档统一按 UTF-8 保存。Windows PowerShell 默认 Get-Content 读取 UTF-8 无 BOM 文件时可能显示成 鏃犲繉、鐐掕偂 这类 mojibake，但这不一定代表文件本体损坏。
后续读取、检查、摘录中文文档时必须显式使用 UTF-8：
Get-Content -LiteralPath <path> -Encoding UTF8
脚本读取统一使用：
Path(path).read_text(encoding="utf-8")
如果发现疑似乱码，先做字节级或 Python UTF-8 读取审计，确认是显示问题还是文件内容污染；不能继续向疑似乱码文档追加内容。
WUJI-BASELINE0 不再只记录候选池命中，而要记录完整系统实践：
市场环境
-> 日线候选池
-> 位置阶段
-> 分时买点
-> 风险卖点
-> 滚动止盈卖点
-> 收益结算
-> 成功 / 失败归因
买点、卖点和风控必须能被人审计，所以除基础 ts_case_study_* 案例表外，还应写入 baseline 专用表：
ts_baseline_run
ts_baseline_case_decision
ts_baseline_entry_exit_event
ts_baseline_trade_lot
ts_baseline_case_outcome
ts_baseline_audit_check
表结构和字段合同见：
mirror/交易系统/炒股笔记研究/炒股笔记案例存储体系.md
手工账本执行和审计步骤见：
mirror/交易系统/炒股笔记研究/无忌baseline手工账本执行与审计指南.md
完整系统收益统计必须再分两层，不能混读：
单票案例研究：
粒度 = 某股票 + 某 entry_trade_date。
用途 = 研究买点、卖点、风控、滚动卖法、失败原因和规则语义。
不能代表真实账户连续运行收益。
交易日组合系统 replay：
粒度 = 某交易日 + 当日完整候选池 + 组合持仓。
用途 = 统计完整交易系统收益、资金占用、同日多票、持仓重叠、组合回撤。
只有这一层才能回答“这套系统连续跑下来收益如何”。
没有分时买卖点的样本只能作为候选池案例，不能混入完整 baseline 收益。
WUJI-BASELINE2/3 这类单票复盘即使买卖链完整，也应读成“单票案例研究 / 买卖链复盘”。除非实验从某个交易日的完整候选池开始，统一执行最多持仓、资金分配、持仓重叠、风险和卖点，否则不得写成完整系统收益统计。
本流程是 WUJI-BASELINE0 之后的默认执行流程。它是初版，可随案例研究持续修正；但每次修正必须回写本文档或对应存储合同，不能只改脚本。
确定 baseline 版本
-> 确定候选来源和样本范围
-> 生成候选案例池
-> 按 as-of 规则做人工/AI 交易判断
-> 记录买点、卖点、风控和仓位变化
-> 用未来行情结算收益
-> 做成功 / 失败 / 边界归因
-> 生成 K 线图和必要的分时图
-> 写入 MySQL 案例表和 baseline 表
-> 跑校验脚本
-> 回写看板、验证日志、案例库、规则沉淀
如果脚本暂时不能严格执行 WUJI_BASELINE_V0_CURRENT_SYSTEM_CONTRACT，可以改用手工 / AI 手工账本 replay，但流程不能降级。
当前主版本名：
WUJI_BASELINE_V0_CURRENT_SYSTEM_CONTRACT_MANUAL_LEDGER_REPLAY
执行原则：
1. 从交易日完整候选池开始，不得随机指定单股代替系统运行。
2. 买点、卖点、风控、分批仓位、滚动卖法按无忌 baseline 原文语义执行。
3. 卖出裁决必须人工 / AI 手工账本主位；脚本只能提示卖出信号，不能直接把信号写成真实卖出订单。
4. A 股 `T+1` 是硬闸：T 日买入的新仓，最早只能从下一交易日开始真实卖出；T 日风险 / 止盈信号只能记录为 `T0_SIGNAL_NOT_SELLABLE`。
5. 脚本只允许辅助取数、画图、校验和计算，不得用未经确认的代理买点或代理卖点替代原文 baseline。
6. 如果某一步只能代理执行，必须先停止说明；不得边做边把代理结果写成 baseline。
7. 手工判断必须留痕：当时看到了什么、为什么买、为什么不买、为什么卖、为什么继续持有。
8. 每跑完一组仍按实验流程归档：result 包、MySQL / CSV 账本、验证日志、看板、改进假设。
最低产物：
baseline_candidate_ledger：候选池和是否进入观察。
baseline_order_ledger：每次买入、加仓、减仓、止盈、风险卖。
baseline_daily_account_ledger：连续账户日级资金、持仓、浮盈亏、回撤。
baseline_decision_log：关键判断理由和人工 / AI judgment version。
summary / manifest / readout：结果、文件、边界和下轮动作。
推进顺序：
先做 3 个代表性交易日：强盈利、强亏损、边界/未成交。
再做 10 个交易日，验证账本字段和校验流程。
再回放既有 61 个交易日候选池，不覆盖旧 proxy 包。
读法边界：
WUJI_PORTFOLIO_REPLAY_PROXY_V0 = 历史工程代理回放。
WUJI_BASELINE_V0_CURRENT_SYSTEM_CONTRACT_MANUAL_LEDGER_REPLAY = 当前要追的完整 baseline 手工账本回放。
两者不得混算收益，不得互相覆盖。
找案例不是只找上涨样本。每轮至少分三类：
正例：按 baseline 能解释为应该买 / 应该持有 / 应该卖出的样本。
反例：看起来符合部分条件，但按 baseline 应该过滤或失败的样本。
边界例：有争议、条件不完整、分时证据缺失或规则冲突的样本。
每个案例必须记录：
case_selection_reason
source_note_items
matched_baseline_components
missing_baseline_components
asof_available_fields
future_fields_for_evaluation_only
找案例时，遇到 长期横盘、底部承接、长上影测试抛压 这类模糊图形条件，应先生成宽候选和 K 线图，再由人工 / AI 看图标注语义。脚本阈值只能作为辅助字段，不能作为唯一入选或剔除理由。
交易判断必须按当时可见信息执行：
市场环境是否允许入场
日线候选池是否成立
位置阶段是否合适
分时买点是否出现
风险卖点是否触发
滚动止盈卖点是否触发
是否因为证据不足降级为候选池案例
WUJI-BASELINE0 默认同案并跑两套买点时间口径：
V0A_STRICT_TIME_WINDOW：只允许 10:40 前或 14:40 后买入。
V0B_ALL_DAY_ENTRY_ABLATION：全天允许买入，用于检验时间窗口限制的价值。
两版必须使用同一候选池、同一仓位、同一风控、同一卖点、同一收益计算；唯一变量是买入时间窗口。每只股票同一交易日最多买入一次。
如果没有分时数据或分时买卖点无法复核，只能写：
CANDIDATE_ONLY_NO_INTRADAY_EXECUTION
不得混入完整 baseline 收益统计。
收益率分两层：
候选池收益：从候选日 / 次日开始的 D1/D5/D10/D20 等后验观察，只用于评价候选质量。
完整系统收益：严格按记录下来的买入、卖出、风控、滚动止盈和仓位变化计算。
最终 baseline 统计只使用完整系统收益：
complete_system_return_pct
max_drawdown_pct
holding_days
win_loss_flag
risk_exit_flag
profit_take_exit_flag
system_rule_violation_flag
V0A_STRICT_TIME_WINDOW 和 V0B_ALL_DAY_ENTRY_ABLATION 必须分别记录收益率；同一案例如果两版都完成执行，应产生两条 outcome，分别进入各自统计。
基础场景写入：
ts_case_study_*
完整系统执行写入：
ts_baseline_run
ts_baseline_case_decision
ts_baseline_entry_exit_event
ts_baseline_trade_lot
ts_baseline_case_outcome
ts_baseline_audit_check
本地 result 包仍然保留，不得用 MySQL 替代原始产物。数据库负责长期查询和复核，result 包负责原始证据链和图表留存。
校验原理：
先证明案例能还原，再证明当时判断没有偷看未来，再证明收益能由买卖事件复算，最后人工复查语义是否符合无忌 baseline。
每轮至少校验：
案例数量和数据库行数一致
图、源窗口、summary、manifest 存在
买卖事件能还原收益
完整系统收益未混入候选池样本
未来字段没有进入 as-of 判断
判断版本是追加，不覆盖
engineering_allowed_flag = 0
推荐验证步骤：
1. 证据完整性校验：
检查 case、K 线图、分时图、源窗口、锚点、result 包、manifest、数据库记录是否都存在。
2. as-of 合法性校验：
检查 `baseline_action_decision` 只使用当时可见信息；未来收益、未来走势、事后归因只能出现在 outcome / posthoc 字段。
3. V0A / V0B 分账校验：
检查同一案例是否同时生成 `V0A_STRICT_TIME_WINDOW` 和 `V0B_ALL_DAY_ENTRY_ABLATION` 两套判断、事件和 outcome；
检查两版唯一差异是否只有买入时间窗口。
4. 交易事件复算校验：
用 entry / exit / tranche / position_pct 重新计算每段收益；
复核 `ts_baseline_case_outcome` 的收益率、持仓天数、最大回撤和胜负标记是否能复算。
5. 候选池和完整系统分账校验：
检查 `CANDIDATE_ONLY_NO_INTRADAY_EXECUTION`、`REVIEW_ONLY`、`DATA_GAP_HELD` 没有进入完整 baseline 收益统计。
6. 人工语义复查：
逐例查看 K 线图和分时图，确认市场环境、候选池、位置阶段、买点、卖点、风控、滚动卖法的解释是否符合 `WUJI_BASELINE_V0_CURRENT_SYSTEM_CONTRACT`。
7. 结论回写校验：
检查成功 / 失败 / 边界归因、判断版本、规则启发和下一步是否回写到看板、验证日志、案例库和规则沉淀。
从 WUJI_PORTFOLIO_REPLAY_PROXY_V0 和后续 WUJI_BASELINE_V0_CURRENT_SYSTEM_CONTRACT_MANUAL_LEDGER_REPLAY 开始，案例按组推进。proxy 组只记录代理回放启发；manual ledger 组才允许进入完整 baseline 收益讨论。默认每组 20 个交易日组合案例；如果样本不足，可以在 run_config 或手工账本说明中记录实际数量。
每跑完一组案例，必须做一次“改进假设记录”，但不能边跑边改 baseline。
记录原则：
1. 改进点必须来自具体案例、具体交易日、具体股票或具体 selector 组合。
2. 改进点只能写成假设，不得直接改 baseline。
3. 必须说明它可能改善系统的哪个环节：候选池、市场过滤、分时买点、风险卖、止盈卖、滚动卖、持仓延展。
4. 必须说明对应证据路径：result 包、case_id、portfolio_candidate_id、stock_outcome、trade_event、daily_hold_audit、K 线图或分时图。
5. 必须说明风险：可能减少大赢家、可能过拟合、可能只适用某个月份或某种行情。
6. 等累计到 `100` 个完整组合案例后，才做集中总结和 A/B 优先级判断。
最低记录字段：
improvement_hypothesis_id
source_run_id
source_case_id
source_candidate_id_or_symbol
source_selector_set_key
observed_problem_or_pattern
affected_system_component
evidence_path
possible_change
expected_effect
risk_of_change
status
next_ab_test_needed_flag
status 枚举：
HYPOTHESIS_ONLY
NEEDS_MORE_CASES
READY_FOR_AB_DESIGN
REJECTED_BY_CASES
MERGED_INTO_LARGER_HYPOTHESIS
记录位置：
主记录：无忌笔记验证日志.md
当前状态索引：无忌研究证据链看板.md
若后续沉淀成规则，再写入：无忌笔记规则沉淀.md
示例口径：
某类票总是 SELL_RISK_EXIT，不直接说该 selector 无效；应记录为“该 selector 在某种位置/市场环境下可能需要更严格的分时承接确认”。
某类 3-selector 组合表现强于 4-selector，不直接删除第 4 个 selector；应记录为“selector_count 不是单调增强，可能存在拥挤/后手问题”。
某些交易日整体失效，不直接否定系统；应记录为“market_up_count > 3000 过粗，可能需要补市场质量过滤”。
验证读法：
硬校验失败：案例包不能进入 baseline 统计。
人工语义存疑：案例保留，但标 `REVIEW_ONLY` 或新增 judgment version。
V0A / V0B 只有一版可复核：只能统计可复核版本，另一版标 `DATA_GAP_HELD`。
回写位置：
无忌研究证据链看板.md
无忌笔记验证日志.md
无忌笔记案例库.md
无忌笔记规则沉淀.md（仅限规则启发）
mirror/data/result/数据索引.md
observer/model/数据库索引数据.md（如新增表或重要数据）