这次改了什么
v0.10.0 把 LoopTrain 的核心玩法从”线索收集”正式升级为”NPC 时间线推理”。
线索系统从 8 条推倒重设计为 20 条，分为物理线索、NPC 主张、时间线观察、推理线索四类。新增 3 种观察行动（观察场景/盯住NPC/守点观察），玩家通过观察 NPC 行动构建时间线，发现 NPC 主张与客观事实的矛盾。
灰衣乘客现在会主动撒谎——声称自己一直在连接处，但玩家可以观察到他 14:04 经过二号车厢、14:06 进入三号车厢。小宁会隐瞒信息——声称一直坐着，但玩家可以观察到她 14:02 从三号车厢方向回来。
矛盾检测自动生成推理线索，推理线索影响游戏进程。成功条件从”收集 2 条线索”升级为 5 维度证据评分。失败后时间线记忆继承到下一轮，玩家可提前守点重新验证。
为什么要改
v0.9.0 的试玩版有一个根本问题：8 条线索全部互补递进，玩家不需要判读”谁在撒谎”。收集即可推进，没有推理压力。
同时，trial-timeline.json 定义了 9 个时间线事件，但 engine.js 完全没有引用——这些数据是死的。
这两个问题合在一起，意味着 LoopTrain 缺乏自己的核心差异化。普通互动叙事游戏是”和 NPC 对话，拿线索，推进剧情”，而 LoopTrain 应该是”观察 NPC 行动，构建时间线，用事实反证 NPC 的说法”。
v0.10.0 就是把这个差异化做出来。
设计取舍
known_clues 与 player_timeline 并存
最大的架构决策是：不推翻 known_clues，而是新增 player_timeline 与之并存。known_clues 继续管理物理线索（兼容现有 UI 和成功判定），player_timeline 管理 NPC 行动时间线（观察/主张/推理/记忆），通过 public_clue_id 字段同步两者。
选择并存而不是取代的原因：取代会破坏现有 Engine、测试、UI 和成功路径，风险太高。
推理线索固定判定
本迭代推理线索的判定结论是预写在数据里的，矛盾检测后自动取默认判定。许知微的判定交互（展示选项让玩家选）留给下个迭代。这个取舍让第一版逻辑实现简单，同时数据结构已完整预留许知微接口。
三条通关路径，门槛有意提高
所有路径都需要 actionable_location >= 1（地板划痕）。这提高了原路径门槛，但 clue_floor_panel_scratch 在检查声音来源时自动补充，不多一个玩家操作。三条路径 AP 消耗约 8AP（总 10AP），留 2AP 容错。
循环的价值是重新验证
失败继承时，观察过的时间点转为 memory 类型，current_loop_verified = false，counts_as_current_evidence = false。这意味着记忆不算本轮证据，但玩家可以提前守在 remembered 的时间点重新观察，获得本轮有效证据。这才是循环玩法的核心价值——不是简单重复，而是策略性验证。
实现结果
27 个文件变更，约 1926 行新增代码：
| 层 | 文件数 | 关键变更 |
|---|---|---|
| 数据层 | 6 | 17 事件 + 20 线索 + NPC 对话 + 指令注册 |
| Engine | 1 | 628→1261 行，10 新函数 |
| Server | 1 | POST /api/action/observe |
| Frontend | 2 | 观察 UI + 时间线 UI + 66 行 CSS |
| 测试 | 12 | 5 新测试 + 7 更新 |
| 脚本 | 1 | verify_slt.sh 服务器启动修复 |
| 文档 | 4 | VERSION + 3 稳态文档 |
测试结果：11 个引擎测试 + smoke test 7 section + 12 个 E2E 全通过，verify_slt.sh 全绿。
还存在的问题
- 许知微判定交互未实现（verdict_options 数据已预留，下迭代开发）
- 小宁母亲彩蛋未实现（数据结构预留但无触发逻辑）
- 三条通关路径需要实际游玩验证平衡
下一步计划
- 许知微判定交互：检测到矛盾时主动发起对话，展示判定选项，玩家选择生成推理线索
- 许知微时间线整理话术
- LLM Bridge 接入（许知微优先）
- 小宁母亲彩蛋触发逻辑