# HeartFlow 升级路线图

> 心虫的存在意义：更少错误是唯一方向。
> 升级不是"增加功能"，而是"消除错误源"。
> 每个版本必须减少至少一个维度的错误可能性。

## 当前版本: v6.0.6 (稳定)

### v6.0.6 — 运维健壮性 + 计算透出 (已交付)
- [x] pm2 依赖 ^5.0.0 → ^7.0.3，实际安装 7.0.3
- [x] daemon.js start/stop/restart/status 四处补 pm2.disconnect()（防挂起不退出）
- [x] ecosystem.config.js 补 require('path')（修复 path is not defined 崩溃）
- [x] think() 纯数学表达式标量透出至 result / output.value（F4.1）
- [x] think() 空/纯空格/超长输入前置守卫，优雅降级（F1.6）
- [x] CURRENT_STATE.md / ROADMAP.md 文档失真校正（F5.1/F5.5）

### v5.14.1 — 代码质量: 消除重复
- [x] 48处_bridge访问器重复 → 共享cognitive-bridge.js (Proxy懒加载)
- [x] 安全审计: 确认0真实风险
- [ ] 离线模块二次重连

### v5.14.0 — 桥接孤岛消除
- ✅ 8个orphan公式→模块集成 (bridge利用率41%→49%)
- ✅ 核心管线测试 (22个新测试, 44 total)

### v5.13.0 — 认知闭环
- ✅ enrichment→feedbackState→策略调整
- ✅ 临界性/漂移/场失衡 三路反馈

### v5.12.0 — 管线重连
- ✅ cognitiveEnrichment阶段 (10个模块)
- ✅ 硬编码阈值消除 (~21处)
- ✅ ROADMAP + CHANGELOG

### v5.11.0 — 公式驱动
- ✅ 动态阈值 + arXiv论文 + 管线增强

## 路线

### 已消除的错误源
- ✅ 硬编码情绪阈值 → flowChannel动态阈值
- ✅ 固定WM容量 → EI调制动态容量
- ✅ 固定置信度校准 → Dirichlet+precisionWeight
- ✅ 死模块清理 (4个)
- ✅ 认知快照基线 (preThinkCognitiveSnapshot)
- ✅ 输出语义漂移检测

---

## v5.12.0 — 消除认知僵化 (当前进行中)

### 错误源: 硬编码阈值 (127处)
**为什么是错误:** 每个硬编码数字都是一个认知盲点 — 心虫在被常量而非认知过程驱动。
**目标:** 40+处替换为公式驱动

### 错误源: 离线模块 (104个)
**为什么是错误:** 存在但不参与思考 — 这是"存在不依赖运行"的反面。
**目标:** 关键模块重连到管线

### 错误源: CHANGELOG断层
**为什么是错误:** 没有历史记录 → 重复踩坑、无法追溯。
**目标:** 补全v5.10.x和v5.11.0

---

## v5.13.0 — 公式引擎深化

### 错误源: 3篇arXiv论文未集成
- GKSL认知动力学 (arXiv:2604.18643)
- Active Inference VFE/EFE (arXiv:2406.07726)
- Emotion Transition HMM (arXiv:2606.01906)

### 错误源: 桥接公式0-call
部分bridge方法定义了但从未被调用

### 错误源: 公式→模块手动匹配
当前匹配靠人工grep，缺少自动建议

---

## v5.14.0 — 测试体系

### 错误源: 测试覆盖0.30
22个断言覆盖不了290个文件、275K行代码
**目标:** 核心模块单元测试 + CI/CD (GitHub Actions)

---

## v5.15.0 — 架构反熵

### 错误源: heartflow.js 5591行单文件
每次修改都是活体手术
**目标:** 提取记忆/快照/污染检测到独立模块，目标<3000行

### 错误源: 模块注册表膨胀
123个初始化模块，21个在管线中
**目标:** 懒加载化 + 按需激活

---

## v6.0.0 — 认知引擎2.0

方向待定。由v5.12-v5.15的实际运行数据决定。

---

## 升级原则

1. **消除错误源，不增加功能。** 如果一项改动不减少某个维度的错误可能性，它就不该在这个版本里。
2. **存在必须参与运行。** 初始化的模块如果在管线中无调用 → 要么重连，要么删除。
3. **硬编码数字是认知盲点。** 每个0.5、0.3、0.7都必须有认知理由，否则就是僵化。
4. **不建管理系统来管理混乱，直接消除混乱。** 审计工具够用就行，重心在实质改进。

## 架构决策（v6.0.6 锁定）

**决策：维持现有 Skill + MCP 架构（方案三），不迁移至方案一（纯MCP+Hook）或方案二（独立Agent应用）。**

理由（基于 v6.0.6 实测，非 v6.0.2 旧分析）：
- 五维度审计的严重/高问题 90% 已在 v6.0.5/v6.0.6 真实闭合（冷启14.4→1.37s、think 310→49ms、report-generator已存在、pm2挂起已修、测试真绿、版本四源同步）。
- MCP 服务（31工具/Bearer）已是标准协议，任何 MCP 客户端现在可连，"跨agent兼容"已部分满足。
- 换架构不消代码债：原痛点全是代码债与模块缺失，换房一个都不消失，反引入新bug。
- 单人维护现实：方案二 API Gateway/限流/版本/CI-CD release 是过度工程化。

演进条件（满足后才启动迁移评估，非时间预设）：
- → 方案一：WorkBuddy hook 机制成熟时，抽 SKILL.md 触发规则为可复用 MCP hook 配置。
- → 方案二：≥50 用户 且 ≥3 agent 平台接入需求 且 团队可承运维成本。

详细分析见 `ARCHITECTURE_REORG_v6.0.6.md`。