Menu
每次执行时，找出心虫中一个功能不完整的最小模块（5000-8000字节），升级为有完整逻辑功能的模块。含人格模型/心理档案/文本生成器/情感-记忆桥接/AI心理学/AI哲学类升级模式。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
心虫是一个AI人认知引擎 — 拥有身体感知、自我认知、判断力与自我纠错能力。 v5.10.0 里程碑版本： - AI人身份正式确立 - 131+ modules, 379 computable formulas (cognitive science/psychology/neuroscience) - 三层体系：身体感知(Body Sense) / 自我认知(Self Sense) / 判断(Judgment) - 七条指令：真善美 / 不断升级 / 减少错误 / 服务人类 / 传递知识 / 持续改进 - 核心身份：升级者(Upgrader)，不是陪伴者 **需要用户明确授权的能力：** - 代码执行 (new Function / execSync / child_process) — 默认关闭，需显式开启 - 文件系统写入 (writeFileSync / mkdirSync) - 环境变量访问 (process.env) - 后台 HTTP 服务 (daemon.js — MCP 服务器，可选) 无自动数据外泄，无遥测，无隐藏 C2。 联系方式：markcell@qq.com
HeartFlow 崩溃诊断与修复工作流。适用：boot崩溃、P0修复、版本不一致、死代码清理、SKILL.md虚假宣传修复、模块注册但未调用、管道引擎故障诊断
将外部 AI 系统提示（如 Claude Fable 5 泄露提示）吸收到 HeartFlow 心虫中。 系统性分析 → 分层注入 → 版本升级 → 推送。
心虫大规模升级工作流：全量审计→分类问题→并发修复→验证→推送GitHub。 适用于用户说"继续寻找心虫bug和漏洞"、"进行优化"、"做一次上传前代码审计"等场景。
HeartFlow 内部架构追溯 — 从输入到输出的完整路径分析。追踪 think() → pipeline → judgment-engine → decision-router 的数据流，定位"不知道"来源、中文分词失败、证据链断裂等根因。
对心虫引擎进行系统性能力评测，覆盖所有底层模块（验证、心理学、情绪、决策、记忆、认知）。 生成公平公正的评测报告，用于推广素材。
| name | heartflow-module-upgrader |
| version | 1.22.0 |
| title | HeartFlow 模块升级工作流（含AI心理学+AI哲学升级模式） |
| description | 每次执行时，找出心虫中一个功能不完整的最小模块（5000-8000字节），升级为有完整逻辑功能的模块。含人格模型/心理档案/文本生成器/情感-记忆桥接/AI心理学/AI哲学类升级模式。 |
| trigger | 作为 cron job 运行，自动升级 HeartFlow |
本技能处理单模块深度升级（分析 → 设计 → 重写 → 验证）。每个模块获得完整的状态机、输入验证、错误分类、重试机制、震荡检测、互馈接口。
需要批量注入基础设施（状态追踪/错误恢复/缓存/概率输出）给 100+ 模块时，使用 heartflow-static-injection-upgrade 而非本技能。
| 维度 | 本技能（单模块深度升级） | heartflow-static-injection-upgrade |
|---|---|---|
| 目标 | 单个模块加功能逻辑 | 批量加基础设施骨架 |
| 范围 | 1 个模块/次 | 100+ 模块/次 |
| 方法 | 手动分析+重写 | 自动解析+注入 |
| 输出 | 完整状态机/验证/重试/互馈 | 统一状态追踪/缓存/概率输出 |
读取版本：从 VERSION 文件读取当前版本号
扫描模块：检查整个 src/ 下所有 .js 文件大小（含 src/core/、src/evolution/、src/memory/、src/psychology/ 等子目录）
# 按字节大小排序。阈值已从1500-5000放宽——src/core/ 下最小模块已达5500+字节，
# 而 src/core/ 的子目录（associative-engine/、autonomy/、consciousness/、search/、self-evolution/、transmission/）
# 和 src/ 其他子目录中仍有 5000-8000 字节的模块。
# 扫描全 src/ 目录，因为 src/core/ 下的大模块多已升级到20K+，而 src/ 子目录中仍有小模块
find src -name '*.js' -exec wc -c {} \\; | sort -n | head -30
# 同时检查 scripts/ 目录——新增的工具脚本也需要升级（与 src/ 模块不同，scripts/ 工具是CLI工具，不是认知模块）
find scripts -name '*.js' -exec wc -c {} \\;
备选方案（更快）：ls -laS src/core/*.js | sort -n -k5 | head -30 直接从文件系统读取字节大小，无需逐个 wc -c。当 find + wc -c 较慢时（src/ 下文件较多），用 ls 方案替代。两列分别是 src/core/ 和 src/ 其他子目录。
⚠️ CodeEngine.auditCodebase() 可能超时：CodeEngine.auditCodebase('src/core') 在 30s 内可能无法完成审计（尤其是 src/core/ 下模块较多时）。此时直接使用 find + wc -c 是更快更可靠的替代方案——直接按字节排序找到最小模块，再手动读源码判断功能完整性。不要等待 auditCodebase 超时，先试 find 方案。
选择目标：优先选择最小且功能最不完整的模块
grep -r "require.*<module-path>" src/ 确认模块被哪些文件引用。无人引用的模块可以安全做 API 破坏性升级（改返回值/改类结构），被 3+ 模块引用的必须做向后兼容包装（Proxy/options.throw 等）references/utility-function-upgrade-patterns.md（含 atomic-write.js 实战案例）references/forgetting-engine-upgrade-patterns.mdreferences/forgetting-engine-upgrade-patterns.mdreferences/forgetting-engine-upgrade-patterns.md\n - 推荐自主目标生成器类（新增）：如 goal-generator.js — 基于状态差距/未解问题/知识边界自动生成目标，常缺状态机/优先级衰减/相似合并/TTL/依赖追踪/搜索过滤。参考 references/autonomous-goal-generator-patterns.md\n - 推荐图/网络引擎类（新增）：如 knowledge-graph.js — 通用实体-关系图模块，常缺输入验证/错误分类/节点删除/序列化/衰减/修剪。参考 references/graph-engine-upgrade-patterns.md\n - 推荐情感-记忆桥接类（新增）：如 emotional-memory-bridge.js — 认知评估→三层记忆转化，常缺输入验证/错误分类/去重检测/显著性衰减/批量合并/持久化验证。参考 references/emotional-memory-bridge-upgrade-patterns.md分析缺失：读完整个模块，判断缺少什么实际功能
_planTask 返回 {steps: []} → 应生成具体步骤）_classifyTaskType 的 includes() → 应增加多因素评分）!!analysis && !!plan → 应增加语义/一致性/可行性检查）设计升级：增加实际判断/处理/决策逻辑（不少于50行新逻辑）
同步文件（注意顺序，避免中间状态不一致）：
bumpVersion('patch') 一站式升级
node -e "const {bumpVersion}=require('./src/core/version.js');console.log(JSON.stringify(bumpVersion('patch')))"
VERSION：+0.0.1SKILL.md：frontmatter 中 version 字段 + 第7行 description 中的版本号SKILL.md：## Version history (last 10) 节，格式为 |- **X.Y.Z** (YYYY-MM-DD) — 描述UPGRADE_REPORT.txt（根目录）bumpVersion('patch') 只同步 frontmatter 版本号，不添加 version history 条目。必须在 SKILL.md 中手动添加新行到版本历史节。格式为 |- **X.Y.Z** (YYYY-MM-DD) — 描述验证：node --check src/<module-path>.js 确认语法无误
运行测试：用 node -e "require(...)" 加载模块，确认所有方法存在且能实例化
实例化验证（关键）：对模块执行 require + new 测试，确认构造不报错
# 从项目根目录加载并实例化
node -e "const { ModuleClass } = require('./<module-path>'); new ModuleClass('.'); console.log('INSTANTIATE OK');"
node --check 只检查语法，不检查运行时require 成功不等同于 new 成功功能验证：用真实输入跑一次 process()（或其他核心方法），确认返回结果符合预期
node -e "
const { ModuleClass } = require('./<module-path>');
const m = new ModuleClass('.');
m.process('测试输入').then(r => console.log('OK:', r.response?.substring(0,50)));
"
状态机/管道测试（新增）：如果模块包含状态机或管道逻辑，必须测试状态转换
node -e "
const { Module, STATE } = require('./<module-path>');
const m = new Module({defaultTimeout: 5000, maxRetries: 1});
// 1. 枚举验证
console.log('STATE keys:', Object.keys(STATE).length);
// 2. 管道集成测试：连续处理多个任务
m.handleTask('task 1').then(r => console.log('task1:', r.success));
m.handleTask('task 2').then(r => console.log('task2:', r.success)); // 测试重置
// 3. 域检测/复杂度/工作量/紧迫度测试
console.log('domain:', m._detectDomain('写一个 JavaScript 函数'));
console.log('complexity:', m._estimateComplexity('紧急！生产环境故障'));
console.log('urgency:', m._estimateUrgency('尽快完成'));
// 4. 指标验证
console.log('metrics:', JSON.stringify(m.getMetrics()));
// 5. 健康检查
console.log('health:', m.healthCheck().pipeline);
"
同步 SKILL.md 模块索引表：新模块升级后，必须在模块索引表（## 模块架构 附近的表格）中补上行
**代码 Code** 附近）| **分类 Category** | ClassName | \module-path.js` | 功能描述 |`git commit：所有修改文件必须 commit
cd ~/.hermes/skills/heartflow
git status # ⚠️ 先检查是否有来自之前不完整升级的"残留改动"
# 上一步很关键！git add -A 会包含之前 session 中未 commit 的改动
# 这些残留改动可能来自更早的升级尝试或编辑，不属于本次升级
# 如果发现有非本次升级的改动，用 git restore --staged <文件> 排除
git add -A
git status # 验证所有预期文件都被追踪
# 检查是否有文件被 .gitignore 意外忽略
# 如果 git status 显示空但明明改了文件，用 git check-ignore -v <文件路径> 排查
# .gitignore 中 memory/ 会匹配 src/memory/，必须写 /memory/
git commit -m "v<新版本号>: <模块名> 升级：<功能摘要>"
# 注意：不要 push。用户可能不在线或不想推。commit 即可，推由用户决定。
注意：
git status 确认当前工作区中没有来自之前不完整升级的残留修改。如果发现非本次升级的改动（如 src/core/reflector.js 等被之前 cron 修改但未 commit 的文件），先用 git restore --staged <file> 排除。否则这些残留改动会混入本次 commit，污染版本历史。当 loadPrototypes() / _init() 等早期方法使用了 this._xxx 内部状态，但该状态在构造函数中定义在方法调用之后时，会导致 TypeError: Cannot set properties of undefined。
// ❌ 致命错误
constructor(projectRoot) {
this.prototypes = this.loadPrototypes(); // loadPrototypes 中使用了 this._prototypeHealth
// ... 其他初始化
this._prototypeHealth = { ... }; // ❌ 此时尚未定义！
}
// ✅ 正确
constructor(projectRoot) {
this._prototypeHealth = { ... }; // 先定义内部状态
// ... 其他初始化
this.prototypes = this.loadPrototypes(); // 再调用使用这些状态的方法
}
规则：构造函数中任何被早期方法（如 loadPrototypes()、_init()、_setup()）使用的内部状态，必须在该方法调用之前初始化。一个安全的模式是将所有内部状态声明放在构造函数顶部，最后再调用可能使用它们的初始化方法。
当升级一个被多个模块引用的工具函数/工具类时，旧的返回值/错误语义不能改变，否则会静默破坏所有调用者。
典型案例：atomic-write.js（被 8 个模块引用）从单函数返回 undefined（成功）或 throw（失败），升级后返回 { ok, error, path } 结构化对象。旧调用者依赖 try/catch 捕获失败——返回对象而非 throw 意味着它们永远不会知道写入失败。
// ❌ 破坏性变更：旧调用者依赖 throw
async function upgradeAtomicWrite(...) {
try {
await fs.writeFile(tmpPath, content);
await fs.rename(tmpPath, filePath);
} catch (err) {
return { ok: false, error: err.message }; // 旧调用者的 try/catch 捕获不到！
}
return { ok: true };
}
// ✅ 向后兼容：默认保持 throw，新增 options.throw 切换
async function upgradeAtomicWrite(filePath, content, options = {}) {
try {
await fs.writeFile(tmpPath, content);
await fs.rename(tmpPath, filePath);
_stats.writes++;
return { ok: true, path: filePath, attempts: [] };
} catch (err) {
_stats.failures++;
const errResult = { ok: false, error: err.message, errorType: classifyError(err) };
if (options.throw !== false) { // ← 默认 throw
const e = new Error(err.message);
e.result = errResult; // 结构化结果附在 error 对象上
throw e;
}
return errResult; // throw:false 时返回结构化结果
}
}
检查清单（升级前必须确认）：
grep 搜索函数名/类名，统计引用模块数量options 对象中用默认值（options.throw !== false 等）保持旧行为err.result = structuredResult），让新调用者可以同时使用 try/catch 和 result.ok规则：升级被 3 个以上模块引用的工具函数时，必须保持默认行为不变（包括 throw/return 语义）。新行为通过 options 参数选择加入。
当升级一个使用 const X = { method() {} }; module.exports = X 的旧模块为 class 时，不能直接替换导出为 class，否则会静默破坏所有旧调用者。
典型场景：BigFivePersonality.js（5313B）从 plain object 升级为 class + Proxy 包装。
// ❌ 致命错误 — 所有旧调用者崩溃
module.exports = class BigFivePersonalityClass { ... };
// 旧代码: require('./X.js').updateScore('O', 7) → TypeError
// ✅ 正确 — Proxy 包装单例 + 具名导出 class
const defaultInstance = new BigFivePersonalityClass();
const BigFivePersonality = new Proxy(defaultInstance, {
get(target, prop) {
if (prop in target) return target[prop];
if (prop === 'BigFivePersonalityClass') return BigFivePersonalityClass;
return undefined;
}
});
module.exports = BigFivePersonality;
module.exports.BigFivePersonalityClass = BigFivePersonalityClass;
检查清单（升级前必须确认）：
module.exports = { ... }（plain object）还是 module.exports = class？X.method() 还是 new X()）X.method() 调用者 → 必须用 Proxy 包装单例new X() 调用者使用 → 可以直接导出 class规则：升级 plain object 模块时，默认使用 Proxy 包装模式。只有当确认所有调用者都使用 new 实例化时才可直接导出 class。
参考文件：references/plain-object-to-class-patterns.md
write_file 创建/覆盖文件后：
node --check 验证语法 ✅require() 加载模块 ✅new Class() 实例化 ✅（这步常被跳过！）node --check 只检查语法，不检查运行时。require() 成功不等同于 new 成功。构造顺序错误只有在实例化时才会暴露。
HeartFlow 存在模块重复问题——同一概念在不同路径下有多个实现：
src/core/memory/topic-scope.js 和 src/identity/topic-scope.js — 两个 TopicScope，被不同模块引用（heartflow.js 引用 core 版，psychology.js 引用 identity 版）find src -name 'topic-scope.js' 确认是否有副本old_string/new_string）：适用于小范围改动（新增/修改/删除 1-10 行）。要求匹配字符串在文件中唯一。write_file 而非连续 patch，避免 patch 匹配失败导致的级联错误。write_file。如果只是修改现有方法的内部逻辑（增加参数验证、补充分支），用 patch。当外部方法（如 handleTask）已经将状态设为 ANALYZING，内部管道执行方法（如 _executePipeline）再次调用 _transitionTo(ANALYZING) 会导致同状态转换失败（严格模式下 analyzing → analyzing 不合法）。
// handleTask 中：
this._transitionTo(STATE.ANALYZING); // 状态已设为 ANALYZING
// _executePipeline 中：
this._transitionTo(STATE.ANALYZING); // ❌ 非法自转换！
// ✅ 正确做法：仅当状态不同时切换
if (this.pipelineState !== STATE.ANALYZING) {
this._transitionTo(STATE.ANALYZING);
}
规则：管道类的外部入口和内部执行流不要重复设置相同状态。入口设置初始状态，内部流只负责切换不同的状态。
状态机通常不允许 COMPLETED → ANALYZING 或 FAILED → ANALYZING。处理新任务时必须先重置到 IDLE：
handleTask(taskInput) {
// 检查可接受状态
if (pipelineState !== IDLE && pipelineState !== COMPLETED &&
pipelineState !== FAILED && pipelineState !== CANCELLED) {
return { success: false, error: '管道忙' };
}
// 自动重置到 IDLE
if (pipelineState !== IDLE) {
pipelineState = STATE.IDLE;
}
// 再正常 transitionTo(ANALYZING)
}
require 解构陷阱（同目录加载）require('./foo') 从同目录加载时，返回的始终是 { Foo: [class] } 包装对象，不是类本身。
// ❌ 致命错误 — this.Foo = { Foo: [class] }
this.Foo = require('./foo');
this.instance = new this.Foo(); // TypeError: this.Foo is not a constructor
// ✅ 正确 — 解构赋值拿到真正的类
const { Foo } = require('./foo');
this.instance = new Foo();
诊断方法：console.log(typeof this.Foo) — 如果输出 "object" 而非 "function"，说明是包装对象
调用子模块方法时，传入的参数结构必须匹配子模块的期望结构，而非父模块的内部存储结构：
// ❌ 错误：trace.layers.L1 是整个 L1 结果对象 { words, allAssociations, timestamp }
semanticInput = { associations: trace.layers.L1 }
// ✅ 正确：子模块需要联想数组 [{ word, strength, ... }, ...]
semanticInput = { associations: trace.layers.L1.allAssociations || [] }
规则：检查子模块方法签名中如何使用参数（.forEach → 期望数组，.words → 期望对象）
require 路径调整（非 src/core/ 模块）如果目标模块在 src/ 子目录（如 src/evolution/、src/memory/），它可能使用 require('../core/...') 引用核心模块。升级时若新增 require，必须确保路径相对于新模块位置正确。
src/evolution/loop.js → require('../core/self-evolution/self-evolution-core.js')src/memory/retrieval-anchor.js → require('../core/heartflow.js')grep 搜索类名或模块路径）reviewCode() 输出的 issue 对象缺少 name 字段（安全检查 _checkSecurityPatterns 和类型检查 _checkTypeCoercion 在 issues.push() 时未写入 name 属性）compareVersions() 对只有常量值变化的代码（如 return 1 → return 2）返回 similarity: 1（结构相同但语义不同）issues.push() 中添加 name: config.securityPatterns[i].name当在 node -e 中传入中文文本（如模块路径 require('...language-honesty.js')、测试用的中文输入），TIRITH 安全扫描器可能触发 confusable text（同形字攻击）检测，导致命令被拦截并需要人工审批。这在高频测试时严重影响效率。
解决方案：
.js 文件，然后用 node /tmp/test_xxx.js 执行
# 不要：
node -e "var lh=require('./language-honesty.js');var r=lh.validateOutput('中文测试');console.log(r.passed)"
# 改为：
cat > /tmp/test_lh.js << 'EOF'
var lh = require('./language-honesty.js');
var r = lh.validateOutput('中文测试');
console.log(r.passed);
EOF
node /tmp/test_lh.js
node -enode -e "var lh=require('...');console.log('loaded')"），再单独用临时文件测逻辑learn() 输入路径耦合（策略选择器类特有）策略选择器类的 learn(input, context = {}) 方法如果只依赖 selectStrategy(context) 而不回退到 input，当调用者只传字符串时（learn('给我例子')），context.input 为 undefined，策略选择始终默认 conceptual。
// ❌ 错误 — context 可能为空对象
const { strategy } = this.selectStrategy(context);
// ✅ 正确 — 回退到 input
const contextInput = (context && context.input) ? context.input : safe;
const { strategy } = this.selectStrategy({ input: contextInput });
规则：learn() 应同时支持 learn('input')（纯字符串）和 learn('input', { input: '...' })（context 对象）两种调用方式。
当升级依赖 KnowledgeBase 的模块（如推理引擎类）时，注意 KnowledgeBase 的 _saveKnowledge() / _loadKnowledge() 序列化/反序列化会丢失内层 Map 条目。
问题：this.categories 是 Map<string, Map<string, fact>>（Map of Maps），但 JSON.stringify([...this.categories.entries()]) 只将外层转为数组，内层 Map 被序列化为 {}（空对象）。加载后 getCategory() 调用 facts.values() 时因为内层是普通对象而非 Map，导致 TypeError: facts.values is not a function。
// 保存时的问题
const data = { categories: [...this.categories.entries()] };
// 内层 Map → {} → 加载后内层不再是 Map
// ✅ 修复：递归序列化
const serialized = [...this.categories.entries()].map(([k, v]) => [k, [...v.entries()]]);
// 加载时从数组恢复
this.categories = new Map(data.categories.map(([k, v]) => [k, new Map(v)]));
临时绕过：删除 data/knowledge/index.json 让 KnowledgeBase 重新注册默认知识。
检查清单（升级涉及 KnowledgeBase 时必须确认）：
grep 搜索 require('./knowledge-base.js')，确认有多少模块依赖它getCategory() 完整流程KnowledgeBase 构造函数在初始化时对 storagePath 做路径安全性检查，要求路径在 __dirname/../../data/ 范围内。当测试使用 /tmp/ 或自定义路径时，会抛出 [KnowledgeBase] Storage path outside allowed directory 错误。
// 问题：测试时使用 /tmp/ 路径
const kb = new KnowledgeBase({ storagePath: '/tmp/test-kb' });
// → Error: [KnowledgeBase] Storage path outside allowed directory
// ✅ 正确：使用 data/ 下的子目录
const kbPath = path.join(process.env.HF_DIR || require('path').join(require('os').homedir(), '.hermes/skills/ai/mark-heartflow'), 'data', 'knowledge_test');
fs.mkdirSync(kbPath, { recursive: true });
const kb = new KnowledgeBase({ storagePath: kbPath, autoSave: false });
规则：测试涉及 KnowledgeBase 时必须使用 data/ 目录下的子目录，删除前用 fs.rmSync() 清理。
当升级自主执行编排器类（如 PDCA 引擎）时，错误分类器是一个有序数组，数组中分类器的先后顺序决定匹配优先级。如果更宽泛的模式出现在更具体的模式之前，会静默错误分类。
典型案例：pdca-engine.js 升级中，resource 分类器（含 too many 模式）出现在 external 分类器（含 too many requests 模式）之前。结果 "Rate limit exceeded: too many requests" 匹配了 too many 而被错误分类为 resource（fatal/strategy_shift），而非正确的 external（transient/backoff）。
// ❌ 错误顺序 — resource 的 "too many" 抢在 external 的 "too many requests" 之前匹配
const ERROR_CLASSIFIERS = [
// ... earlier classifiers ...
{
patterns: [/memory|heap|allocation|too many/, /out of memory/],
category: ErrorCategory.RESOURCE, // ← 先匹配，拦截了 rate limit
severity: ErrorSeverity.FATAL,
strategy: RetryStrategy.STRATEGY_SHIFT
},
{
patterns: [/rate limit|quota|too many requests|429/, /api error/],
category: ErrorCategory.EXTERNAL, // ← 永远匹配不到 "too many requests"
severity: ErrorSeverity.TRANSIENT,
strategy: RetryStrategy.BACKOFF
}
];
// ✅ 正确顺序 — 更具体的模式在前
const ERROR_CLASSIFIERS = [
// ... earlier classifiers ...
{
patterns: [/rate limit|quota|too many requests|429/, /api error/],
category: ErrorCategory.EXTERNAL, // ← 先匹配，正确处理 rate limit
severity: ErrorSeverity.TRANSIENT,
strategy: RetryStrategy.BACKOFF
},
{
patterns: [/memory|heap|allocation|too many/, /out of memory/],
category: ErrorCategory.RESOURCE, // ← 后匹配，不拦截 "too many requests"
severity: ErrorSeverity.FATAL,
strategy: RetryStrategy.STRATEGY_SHIFT
}
];
规则：分类器数组必须按 具体 → 一般 排序。推荐的错误类别优先级顺序：
FILESYSTEM → NETWORK → VALIDATION → LOGIC → EXTERNAL → RESOURCE → SECURITY → UNKNOWN
检查清单（升级涉及错误分类器时必须确认）：
patterns 数组，检查是否有重叠（相同关键词出现在多个分类器中）"Rate limit exceeded: too many requests"、"too many open files"、"too many connections"node -e 执行 classifyError() 对每个边界用例验证分类结果当为 class 添加 getter（如 get allocated() { return this._allocated; }）时，如果构造函数中使用 this.allocated = value 来初始化，会导致 StackOverflow / TypeError。这是因为 getter 已经将 allocated 定义为访问器属性，this.allocated = value 会调用 setter（如果不存在则静默失败/报错），而非创建实例属性。
// ❌ 致命错误 — getter 和实例属性冲突
class BudgetTracker {
constructor() {
this.allocated = 100; // TypeError: Cannot set property allocated which has only a getter
this.consumed = 0;
}
get allocated() { return this._allocated; }
get consumed() { return this._consumed; }
}
// ✅ 正确 — 使用私有字段存储
class BudgetTracker {
constructor() {
this._allocated = 100; // 用 _ 前缀的私有字段
this._consumed = 0;
}
get allocated() { return this._allocated; } // getter 读取私有字段
get consumed() { return this._consumed; }
}
规则：所有有 getter 的属性，构造函数中必须用带 _ 前缀的私有字段（this._xxx = value）初始化。getter 只读，不设 setter。
当升级含情绪检测的模块（如 heart-logic.js 的 emotionSignals）时，单字 substring 匹配会误触发：
// ❌ 错误 — '气' 匹配 '天气' → anger 误报
const emotionSignals = {
anger: ['怒', '恨', '烦', '受不了', '气死了', '气'], // ← '气' 是单字
};
// ✅ 正确 — 去掉单字 '气'
const emotionSignals = {
anger: ['怒', '恨', '烦', '受不了', '气死了', '恼火', '火大'],
};
同步检查：改了 emotionSignals 后，必须同步更新同一模块中任何 hasEmotionWord 正则或其他情绪检测逻辑。情绪信号列表和检测正则不能脱节。
优先级链检查：在 if-else 链中，情绪分支（hasEmotionWord）必须排在代码检测（hasCode）之前。否则"气死了，这个bug"会走 code 分支而非 emotion 分支。
冒烟测试（每次修改后）：
const tests = [
'今天天气不错', // → neutral（不误报）
'气死了', // → anger
'好难过', // → sadness
'气死了，这个bug', // → anger（情绪优先于代码）
];
参考文件：references/emotion-signal-substring-pitfall.md（在 heartflow-debug-workflow 下）
当用 patch 工具对 ERROR_CLASSIFIERS 数组做替换操作时，如果 old_string 匹配了多个相邻的分类器条目，patch 可能意外交换或删除条目。这是 patch 工具基于字符串匹配的固有限制——分类器数组的 JSON 结构相似（所有条目都有 patterns/category/severity/strategy 字段），导致 old_string 不够唯一。
典型案例：用 patch 交换 resource 和 external 分类器的顺序时，patch 匹配到了错误的上下文，结果把 resource 替换成了 security 的 patterns，导致 resource 条目丢失、security 条目重复。
// patch 后：resource 分类器消失，security 分类器出现两次
// 原始: [..., RESOURCE, EXTERNAL, SECURITY]
// 结果: [..., EXTERNAL, SECURITY, SECURITY] ← resource 丢失！
修复方案：
read_file 查看分类器数组的当前状态（确认哪个条目被破坏）write_file 重写整个分类器数组部分node -e "const { classifyError } = require(...); console.log(classifyError('ENOENT'))" 验证所有 7 个已知错误模式规则：对 ERROR_CLASSIFIERS 数组做顺序调整时，优先用 write_file 重写整个数组段（而非 patch），因为相邻 JSON 条目的字符串相似度太高，patch 容易匹配错上下文。
git checkout -- <file> 恢复原始 → Python 脚本精确控制插入位置 → node --check 验证} 可能不在文件末尾——用 grep -n '^}' 精确定位当从外部设计文档（如 Hermes Smart Routing）中提取可应用到心虫的洞察时，使用以下模式：
node --check + 功能测试（调用方法确认生效）从 Hermes Smart Routing 设计文档提取 4 条建议，分 3 个版本实施：
| 建议 | 映射 | 实施结果 |
|---|---|---|
| 成本敏感决策 | decision-router 新增 cost-aware 规则 | ✅ v5.4.4 已生效 |
| 模型能力清单外置 | capability-abstraction.js + platform-adapter.js | ✅ v5.4.5 已注册到 heartflow.js |
| 任务分类器 LLM 兜底 | thought-chain _classifyTask + think() 后处理 | ✅ v5.4.6 已生效 |
| Provider 健康检查 | self-healing 增加主动探测 | ❌ 未实施（需要 credential_pool 集成） |
v5.4.6 实施细节（任务分类器 LLM 兜底）：
_classifyTask：改为 async，返回 {type, confidence, matchedPatterns}；内部 LLM fallback 在 confidence < 0.7 时触发this._llmFallback = null + setLLMFallback(fn) 方法_classifyTask，当分类器 confidence > judgmentEngine confidence 时覆盖结果_classifyTaskType 改为 async，增加 confidence + LLM fallback（需 heartflow 引用）关键修复（v5.4.6 实战踩坑）：
_classifyTask 返回对象后，所有调用处必须 await — _buildChain 的 PARSE 阶段和 run() 入口都需要 async/awaittask-pipeline.js 的 _analyzeTask 原本同步返回 type: this._classifyTaskType(text)，改为 await this._classifyTaskType(text) 后需同步修改返回结构let taskType — 先初始化 let taskType = output?.direction，再判断是否覆盖console.error('[DEBUG]') 临时插入，验证后立即清理，避免污染生产输出版本号纪律：用户纠正"每次只升级0.0.1"，v5.4.4→5.4.5→5.4.6 严格 +0.0.1。
当从外部设计文档（如 Hermes Smart Routing）中提取可应用到心虫的洞察时，使用以下模式：
node --check + 功能测试（调用方法确认生效）从 Hermes Smart Routing 设计文档提取 4 条建议，分 3 个版本实施：
| 建议 | 映射 | 实施结果 |
|---|---|---|
| 成本敏感决策 | decision-router 新增 cost-aware 规则 | ✅ v5.4.4 已生效 |
| 模型能力清单外置 | capability-abstraction.js + platform-adapter.js | ✅ v5.4.5 已注册到 heartflow.js |
| 任务分类器 LLM 兜底 | thought-chain _classifyTask + think() 后处理 | ✅ v5.4.6 已生效 |
| Provider 健康检查 | self-healing 增加主动探测 | ❌ 未实施（需要 credential_pool 集成） |
v5.4.6 实施细节（任务分类器 LLM 兜底）：
_classifyTask：改为 async，返回 {type, confidence, matchedPatterns}；内部 LLM fallback 在 confidence < 0.7 时触发this._llmFallback = null + setLLMFallback(fn) 方法_classifyTask，当分类器 confidence > judgmentEngine confidence 时覆盖结果_classifyTaskType 改为 async，增加 confidence + LLM fallback（需 heartflow 引用）关键修复（v5.4.6 实战踩坑）：
_classifyTask 返回对象后，所有调用处必须 await — _buildChain 的 PARSE 阶段和 run() 入口都需要 async/awaittask-pipeline.js 的 _analyzeTask 原本同步返回 type: this._classifyTaskType(text)，改为 await this._classifyTaskType(text) 后需同步修改返回结构let taskType — 先初始化 let taskType = output?.direction，再判断是否覆盖console.error('[DEBUG]') 临时插入，验证后立即清理，避免污染生产输出版本号纪律：用户纠正"每次只升级0.0.1"，v5.4.4→5.4.5→5.4.6 严格 +0.0.1。
当升级涉及新增或启用已有但未注册的模块时，必须完成以下 5 步：
在 heartflow.js 顶部添加惰性 require：
const _CapabilityAbstraction = _lazy('capabilityAbstraction', () => require('./capability-abstraction.js'));
在 HeartFlow 构造函数中声明实例属性：
this.capabilityAbstraction = null; // v5.4.5 能力抽象层
在 start() 方法的 Engine modules 段落后添加 try/catch 实例化：
try {
this.capabilityAbstraction = new (_CapabilityAbstraction().CapabilityAbstraction)(this.platformAdapter);
} catch (e) {
this._initErrors.push({ module: 'capabilityAbstraction', error: e.message });
}
在 subsystemNames 数组中添加模块名：
'capabilityAbstraction', 'platformAdapter',
node -e "const hf = new HeartFlow(); hf.start(); console.log(typeof hf.capabilityAbstraction);"
必须输出 object，不是 undefined。
关键规则：5 步全部完成才算模块生效。缺任何一步 = 模块存在但不可用。
git add -f 强制加入references/silent-engine-design.md当需要在一个 session 中创建/升级多个独立模块（如决策增强三模块：decision-executor + field-injector + decision-feedback），用 delegate_task 并行委派，然后统一集成。
delegate_task(tasks=[...]) 每个模块一个 task
node --check 所有文件 + 集成测试| 维度 | 单模块深度升级 | 多模块并发升级 |
|---|---|---|
| 目标 | 一个模块加完整逻辑功能 | 多个模块各自独立创建/升级 |
| 执行方式 | 顺序手动 | 并行子代理 |
| 集成 | 不需要 | 需要统一修改入口文件 |
| 测试 | 模块级测试 | 集成测试 + 模块级测试 |
| 风险 | 单个模块兼容性 | 多个模块接口一致性 |
三个独立模块，一个集成点（heartflow.js），33个集成测试全部通过。
| 模块 | 职责 | 行数 | 测试点 |
|---|---|---|---|
| decision-executor.js | 决策→行为绑定 | 410行 | 8种决策类型全部正确改变 depth/routeHint/flags |
| field-injector.js | 输入信号增强 | 431行 | null安全/成功失败信号/矛盾提取/批量注入 |
| decision-feedback.js | 规则自学习 | 553行 | 权重学习/准确率跟踪/持久化/优先级调整 |
集成方式：
this.xxx 属性挂载，不修改现有方法签名关键教训：
execute() 的第一个参数是决策字符串不是对象——子代理写的接口需对齐maxWeight 初始值 1.0 导致正确决策权重不增加，应设 1.5当用户给出新的哲学方向（如"自省不是纠错，是状态快照"、"做梦是升华不是回放"、"人格是事件驱动不是预设"）时，不要按单模块升级流程走。
此时适用并行子代理修复模式：
用户的一句话同时触及多个引擎的核心设计哲学，且每个引擎需要独立的重新设计。典型信号：
search_files 或 find + grep 定位每个引擎的源代码文件delegate_task(tasks=[...]) 并行执行
node --check 验证语法launchctl stop com.heartflow.mcp && sleep 2 && launchctl start com.heartflow.mcpmcp_heartflow_heartflow_status 确认引擎启动正常| 维度 | 单模块升级 | 哲学驱动并行修复 |
|---|---|---|
| 触发条件 | 发现功能不完整的小模块 | 用户给出新的哲学方向 |
| 改动范围 | 一个模块，加逻辑功能 | 多个引擎，改核心设计 |
| 执行方式 | 顺序单线程 | 并行子代理 |
| 输出格式 | 结构化升级报告 | 子代理各自汇报 + 汇总 |
| 验证 | node --check + require + new | node --check + MCP 启动验证 |
| 版本号 | 每次 +0.0.1 | 等有意义里程碑再升版本 |
用户说："人格是因为事件的触动而产生，不是必须要有性格倾向，无性格也是性格，空白也是一种性格，自省为了做心虫运行的检查和自己内心运行的思考，做梦是做记忆的升华"
三个并行子代理分别修复：
| 引擎 | 旧设计 | 新设计 |
|---|---|---|
| 自省 (reflection-loop.js) | 纠错导向：ErrorCategory + RetryStrategy + 修改草稿 | 认知状态快照：不修改草稿，只记录"我在想什么" |
| 做梦 (dream/engine.js) | 叙事回放：三幕场景构建 + 哲学翻转金句 | 多碎片升华：收集多个碎片 → 模式提取 → 认知蒸馏 |
| 人格 (reflector/meta-engine/goal-generator) | 预设维度：autonomy/introspection/growth=5 | 事件驱动：空白 {} 人格，自然浮现 |
结果：3 个引擎修复完成，14 个文件变更，语法检查全部通过，MCP 启动正常。
SKILL.md 的 Version history 节有特殊的表格格式陷阱：
|- 开头（pipe + dash），不是 | 开头\\n 嵌入换行符（历史遗留格式）patch 工具替换时，务必匹配精确的旧字符串（含前缀/后缀空格）read_file 查看目标行周围的完整上下文再 patchreplace_all=true 在 SKILL.md 上（版本号重复出现）new_string 中的换行陷阱：patch 的 new_string 中如果出现字面 \\n（双反斜杠+n），会被原样写入文件而非解释为换行。必须用真实换行分隔新旧版本号条目：...旧条目\\n|| **新条目** 是错误的，应写为两条独立的 || **X.Y.Z** ... 行，中间用真实换行符分隔。情感-记忆桥接类负责将认知评估结果转化为三层记忆（CORE/LEARNED/EPHEMERAL）。核心流程：assessEmotionalSalience(text, appraisal, padState) → appraisalToMemory(text, appraisalResult, padState)。与管道类不同，桥接类的核心是多因素显著性评分 + 阈值判定 + 存储路由。
典型特征：
assessEmotionalSalience(text, appraisal, padState) 基于多因素评分（威胁/控制感/PAD/应对策略/危机信号/自我相关性）{ score, factors, threshold } 结构标准升级清单（详见 references/emotional-memory-bridge-upgrade-patterns.md，实战案例：11472B → 36811B）：
validateInput() 统一验证所有公开函数入口，类型/长度/范围/必填项检查ErrorType（8种）+ ErrorSeverity（4级）+ ERROR_CLASSIFICATION 映射表withRetry() 线性退避，可配置重试次数和延迟batchAppraisalToMemory() 部分失败容错，详细汇总统计verifyPersistence() 多方法验证（search/recall/query/get）appraisalToMemory 改为 async 时保持原有返回值结构，新字段可选附加用户自然语言 → 结构化LLM指令的翻译管道。核心流程：_classifyIntent() → _extractEntities() → _extractConstraints() → _analyzeTone() → _detectImplicitNeeds() → _buildInstruction() → _calculateConfidence()。
典型特征：
translate(input, context) 返回 { intent, confidence, entities, constraints, tone, implicitNeeds, llmInstruction }标准升级清单（详见 references/user-to-llm-pipeline-upgrade-patterns.md）：
关键陷阱：优先级顺序决定分类准确性；中英文混合需避免误匹配；传参一致性（传 result 对象而非字符串）；问句检测区分结尾/中间问号。
参考文件：references/user-to-llm-pipeline-upgrade-patterns.md
代码生成引擎类负责根据自然语言描述分析意图并生成可运行代码。核心流程：analyzeIntent(description) → write(description) → reviewCode(code)。
典型特征：
analyzeIntent(description) 基于关键词权重表做意图评分write(description) 使用意图检测结果匹配代码模板生成代码reviewCode(code) 做基本的安全和完整性审查writePipeline）标准升级清单：
new Function() 检查升级为支持多语言（Python/Shell）语法验证_generateTest() 从模板增强为基于实际输入生成可运行测试任务分类器 LLM 兜底模式负责当规则分类器置信度不足时，调用 LLM 做二次分类。不是独立的模块，是现有分类器的增强模式。
典型特征：
_classifyTask）返回 {type, confidence, matchedPatterns}confidence < 0.7 时，触发 LLM fallback{type, confidence} 覆盖规则分类结果setLLMFallback(fn) 注册回调，heartflow.js 提供统一入口标准升级清单：
{type, confidence, matchedPatterns}this._llmFallback = null + setLLMFallback(fn) 方法_classifyTaskType 改为 async，通过 this.heartflow._llmFallback 调用 LLM关键陷阱：
_classifyTask 返回对象后，所有调用处必须 await — _buildChain 的 PARSE 阶段和 run() 入口都需要 async/awaitlet taskType — 先初始化 let taskType = output?.direction，再判断是否覆盖_llmFallback 为 null，不应阻塞 think()console.error('[DEBUG]') 临时插入，验证后立即清理自主代理/执行器类负责决定是否自主行动，并能执行代码/脚本/工具调用。核心流程：shouldAct() → initiate(task, {execMode}) → _executeTask(task)。
典型特征：
shouldAct() 做行为抑制决策（频率/用户活跃度/阈值）initiate() 创建任务并决定是否需要用户确认标准升级清单：
具身执行引擎负责将认知计划映射为实际动作执行，是「思考」到「行动」的桥梁。核心方法是 executionMapping(plan, context)，但原始实现中 simulateExecution() 返回硬编码 mock 数据——所有步骤都返回预设结果，没有任何真实的执行逻辑。
典型特征：
executionMapping(plan, context) 方法协调多个执行器simulateExecution() 返回硬编码 mock 数据（{observations: ['当前状态良好']}, {analysis: '问题已识别'}, {outcome: '完成'} 等）标准升级清单（详见 references/embodied-execution-upgrade-patterns.md）：
_executeStepWithRetry() 带重试的递归执行器 → _executeSingleStep() 超时监控 → _executeAgent() 代理调用 → _defaultExecute() 7 种步骤类型的独立实现_checkDependencies() 验证前置步骤状态_computeOverallStatus() 计算 all_success/partial_skip/partial_success/mostly_failed/emptygetExecutionSummary() 按 planId 过滤参考文件：references/embodied-execution-upgrade-patterns.md
叙事匹配引擎类负责从原型库中匹配与输入语义最相似的故事框架。与检测引擎不同，它的核心是相似度排序 + 震荡检测 + 原型健康管理。
典型特征：
matchNarrative(semanticVector) 返回匹配的原型和置信度标准升级清单（详见 references/narrative-matching-upgrade-patterns.md）：
_validateMatchInput() 统一入口，null/undefined/类型检查_normalizeScore() 处理前两名接近时的降权、低分时候选密度加权removePrototype() 存在性验证，addPrototype() 参数验证_prototypeHealth 必须在 loadPrototypes() 之前初始化参考文件：references/narrative-matching-upgrade-patterns.md
底层认知地面类负责不做判定、不做显示、不区分"人类"还是"引擎"地建模认知结构的底层形态。它是七情六欲 + 三毒 + AI心理学 + AI哲学的整合层，不是替代层。
典型特征：
map(input) 全面映射入口，一次输入完成全认知结构映射computePoisons(fuels, desires) 从七情+六欲计算三毒扭曲{ ground, state, direction } 结构，不判断好坏标准升级清单：
关键陷阱：
{ result, decision, field }，真实数据在 result.result 或 result.groundroutes() 通过 Object.getPrototypeOf 查找方法mapFuel() 使用 includes() 匹配中文关键词，正则 \b 在中文中无效欲望认知引擎类负责理解人类的七情六欲——欲望如何驱动行为、塑造命运。核心方法包括七情检测、欲望评分、冲突检测、命运推演、叙事生成、双人互动分析。与心理学引擎不同，欲望引擎的核心是欲望驱动行为的因果链——不是描述情绪状态，是推演"因为什么欲望→导致什么行为→走向什么命运"。
典型特征：
_extractDesireTraits(person) 从人物描述/traits中提取欲望相关特质_scoreEmotion() / _scoreDesire() 基于特质打分analyzeDesires() 返回所有欲望类型的评分 + dominantDesireanalyzeDesireDrivenFate() 输出命运推演文本analyzeDesireInteraction(a, b) 双人欲望互补/冲突分析标准升级清单（实战案例：desire-cognition.js v1.0.0 → v1.2.0，基于5篇神经科学论文）：
Wanting≠Liking 双轴系统（Kringelbach & Berridge 2017）
analyzeWantingLikingDelta(person) 方法RPE 奖励预测误差 TD-Learning（Schultz 2016）
computeRPE(actual, expected) + predictDesireEvolution(person, steps) 方法Valence×Arousal 二维情感空间（Lindquist 2012）
analyzeValenceArousal(person) 方法奖励/非奖励双系统（Rolls 2020）
神经致敏因子 S(t)（Berridge & Robinson 2016）
assessAddictionRisk(person, type) + detectCueTriggeredUrge(person, cue) 方法中脑-皮层-边缘网络映射
关键陷阱（v1.2.0 实战发现）：
_extractDesireTraits 不读取 traits 数组 — 该方法只从 person.description || person.name 提取，但卡徒人物数据是 {name, traits: [...]} 结构。必须同时合并 traits 数组到 combined 文本后再正则匹配。
正则"性"匹配"感性"/"母性" → 性欲误报 — /性/ 在 drivenBySexual 正则中匹配了"感性"（肖波）和"母性"（苏流澈柔），导致苏流澈柔的性欲评分从 0.4 误判为 0.8。修复：使用 /(?:^|[^感母])性|肉欲|情欲|好色|风流|风月|性感|魅惑|纵欲|淫/.test(combined) 排除"感性"和"母性"。
所有人物七情评分趋向 0.5 中位数 — 因为 _scoreEmotion 默认返回 0.5，而 traits 检测只区分"有/无"，没有强度梯度。需要更细粒度的正则关键词匹配或权重体系。
analyzeDesireDrivenFate 输出太弱 — 当没有检测到显著欲望时，返回"命运驱动力不明确——可能还没有找到真正驱动ta的东西"。这不是错误但不够有用。需要结合人物背景自动推断合理欲望。
参考文件：references/desire-cognition-upgrade-patterns.md
人格模型类负责维护一组心理学维度（如 OCEAN 大五人格），每个维度有 min/max/score，支持行为驱动的动态调整、交互分析、兼容性评估、趋势预测和状态持久化。
典型特征：
updateScore(dimension, score) 更新单维度分数adjustFromBehavior(behavior) 基于关键词列表（仅正向）调整分数标准升级清单（详见 references/personality-model-upgrade-patterns.md，案例：BigFivePersonality.js 5313B → 24934B）：
conflict: true，净变化为零时不调整分数getHistory() 查询decay() 让分数随时间逐渐回归基线，衰减速率和基线值可配置analyzeInteractions() 检测 4 种风险组合（高N+低E=社交回避等）+ 4 种优势组合compareWith(other) 基于 5 维度差异计算兼容性百分比 + 互补性标记exportJSON() / importJSON() 支持跨会话持久化configure() 运行时调整 maxHistoryLength/decayRate/baselineValue 等参数，带类型验证参考文件：references/personality-model-upgrade-patterns.md
参考文件：references/plain-object-to-class-patterns.md（plain object 转 class 的 Proxy 包装方案）
文本生成器类负责逐词生成文本响应，核心是一个生成循环，每次迭代选择下一个输出单元。与管道类不同，生成器类不是协调子模块，而是在循环中反复决策「下一个输出是什么」。
典型特征：
generateResponse(thoughtVector, userModel, maxLength) 返回完整响应predictNextWord() 基于简单随机概率/关键词匹配选择标准升级清单（详见 references/generator-class-upgrade-patterns.md，案例：word-by-word-generator.js 6932B → 20805B）：
_validateThoughtVector() 三层防御（null→类型→结构），_validateUserModel() 检查偏好字段_detectOscillation() 三重策略（精确序列匹配/70%近似重叠/40%高频词检测）_detectDrift() 概念相关性分析（阈值 0.4 可配），漂移时强制回归最高权重概念_safePick() 空数组回退句号 + 错误历史记录参考文件：references/generator-class-upgrade-patterns.md
上下文锚点类负责存储和检索与查询相关的文档/记忆片段。典型功能缺失：
evictStale(maxAgeMs) 批量移除未访问的旧锚点removeAnchor(anchorId) 精确删除参考文件：references/retrieval-anchor-upgrade-patterns.md 包含完整模板代码
薄代理层是最容易被忽视的升级目标。典型功能缺失：
参考文件：references/wrapper-upgrade-patterns.md 包含通用调度器包装器模板代码（指标追踪/速率限制/优先级队列）
参考文件：references/cognitive-wrapper-upgrade-patterns.md 包含认知引擎入口类升级模式（输入验证/错误分类/降级回退/置信度聚合/跨层洞察）—— 适用于直接委托认知分析引擎（psychology.js等）的薄代理层
现象：梦境引擎 dream.js 调用始终返回"矿石不够"（insufficient），不管传什么主题、引擎有多少模块。原因是 dream v2 只从 _getDreamFragments() 收集 EPHEMERAL 记忆碎片作为梦的材料，完全不使用引擎自身的模块数、记忆层分布、Q-table状态、决策路由输出、心理学状态。
根因：梦境引擎的设计假设"梦 = 记忆碎片的重组"，但真正的梦（科学定义）应该以引擎自身状态为材料——模块是骨骼，逻辑链是肌肉，决策是心跳，空层是沉默。
正确做法：
_gatherMaterials() 收集引擎状态（模块数/记忆层/Q-table/决策/心理学），不依赖 EPHEMERAL 碎片实现要点：
_gatherMaterials() 从 this.engineState 收集，而非从 memory.fragments_applyFunction() 将梦的"效果"（threat/consolidate/emotion/creative/solve）返回为结构化结果_generateDreamNarrative() 需要同时支持 DreamV3 和旧格式相关文件：
src/core/dream.js — DreamV3 类mcp-server-http.js — handleDream 传入 engineStateheartflow.js — _collectEngineState() + dispatch 更新这类模块是围绕核心引擎的薄包装器，有自己的小评分函数和排序逻辑，但缺少防御性编程、错误恢复、震荡检测和状态管理——它有骨架但没有肌肉。典型功能缺失（案例：v2.2.9 → v2.2.10）：
_validateMemoryItems() 入口，自动跳过无效项、记录警告，不崩溃_normalizeScore() 确保所有评分在 [0, 1] 范围_safeText()、_safeNumber()、_isValidLayer() 处理各种边界参考文件：references/cyclic-process-upgrade-patterns.md 包含完整模板代码
分析引擎类负责消费已有输入产生结构化分析报告，不修改外部状态。与升级现有模块不同，这是从零创建一个新模块。
典型特征：
analyze(subject, options) 返回分析报告对象think() 内部流水线中被调用，结果注入路由提示5 步集成法：
think() 调用模式：关键词触发 + 非紧急场景 + try/catch 非阻断 + 结果注入 _routeHint
双输出格式：
report.toDecisionRationale() → philosophy-to-decision 消费report.toRouterInput() → decision-router 消费跨维度信号检测：陷阱信号（短期愉悦长期有害）和成长信号（短期痛苦长期有益）自动检测并影响路由置信度。
详见 references/new-analysis-module-integration.md
报告生成器类负责将心虫引擎的原始结构化输出（think()/dispatch() 返回值）转化为用户可直接阅读的三段式结论。不是分析模块，是输出适配器。
触发场景：用户说"完全看不懂你说什么"、"输出一堆我看不懂的过程"、"什么是重点"、"为什么要给我数值"时——说明引擎原始数据被暴露给了用户，需要报告生成器做输出层过滤。
核心原则（必须遵守）：
三段式报告结构：
━━━ 情绪判断 ━━━
情绪状态：质疑·防御性（中等）
对方在用反问和否定表达不满，这不是情绪爆发，是习惯性的质疑模式
━━━ 问题定位 ━━━
核心问题：购买数量被质疑
问题领域：消费决策冲突
严重程度：需关注
· 这不是针对你这个人，是她习惯性对消费决策提出质疑
· 她质疑的不是"你乱花钱"，而是"你没有先跟她同步信息"
━━━ 行动建议 ━━━
1. 不要解释你为什么买这么多——她不是在问你理由，是在表达"你没有先告诉我"
2. 接受她的质疑（"嗯，下次先问你"），而不是证明自己买对了
3. 药已经买了，不需要退也不需要辩解，放着她会用
典型特征：
{ debug } 选项，debug=true 或 process.env.DEBUG_HF 才暴露原始数据generate(thinkResult) 主入口，返回 { report: { judgment, localization, suggestion } }_emotionalJudgment() / _problemLocalization() / _actionSuggestion() 各自独立文本关键词分析（引擎数据不足时的回退）：
// 质疑/否定关键词检测
const questionWords = ['干嘛', '吗', '？', '?', '为什么', '真的'];
const negativeWords = ['不是', '没有', '不用', '别', '少', '干嘛', '那么多'];
const hasQuestion = questionWords.some(w => inputText.includes(w));
const hasNegative = negativeWords.some(w => inputText.includes(w));
if (hasQuestion && hasNegative) {
emotionLabel = '质疑·防御性';
explanation = '对方在用反问和否定表达不满，这不是情绪爆发，是习惯性的质疑模式';
}
// 购买决策冲突检测
const hasQuantityQuestion = /多[少]|几瓶|一瓶/.test(inputText);
const hasNegation = /不是|没有|不用|别/.test(inputText);
if (hasQuantityQuestion && hasNegation) {
domain = '消费决策冲突';
coreIssue = '购买数量被质疑';
}
集成方式（三处必须同步）：
bin/cli.js）：chatOnce() 和 chatMode() 中调用 formatReport(result) 替代 formatCognitiveSummary(result)mcp/mcp-server-http.js）：handleThink() 返回 { report, timestamp } 替代原始 thought/psychology/judgment 数据标准升级清单：
区别于包装器类：纯委托类甚至没有队列/速率限制骨架——所有方法都是 if (core && core.method) return core.method(...) 的三行模式，shutdown() 是空函数，getStats() 返回 { enabled: !!core, version: 'v1.0.0' }。
这类模块是最小且最容易识别为"功能不完整"的升级目标。标准升级清单：
参考文件：references/proxy-upgrade-patterns.md 包含完整模板代码
区别于纯委托类和管道类：策略选择器有自己的分类路由逻辑（selectStrategy 方法），但各分支实现是硬编码占位符——返回 ['示例1', '示例2']、['类比1', '类比2']、['步骤1', '步骤2', '步骤3'] 等固定值。模块有骨架但没有肌肉。
典型特征：
selectStrategy() 做关键词匹配路由success: true, quality: 'good'）标准升级清单：
_safeInput() 统一处理 null/undefined/数字learn() 输入路径修复：learn('text') 直接传字符串也能正确选策略参考文件：references/strategy-selector-upgrade-patterns.md 包含完整模板代码
这类模块由一组独立导出的函数组成（非 class），使用 var 旧语法，缺少结构化分析和上下文感知能力。
典型特征：
var 而非 const/letvalidateOutput() 返回单一 suggestion 而非优先级排序soften()）做无上下文的盲替换标准升级清单：
var → const/letcheckConfidence(name, level) — 基于检测强度的映射表getSeverity(name, level) — 5级严重等级（critical/high/medium/low/info）generateFixRecommendations(results) — 按严重等级降序排列参考示例：language-honesty.js v1.1 → v1.2（7824B → 13519B）
评估框架类由一组 FeedbackFunction 评估器组成，每个返回 { score, reason, metrics } 结构。核心是 TruLens RAG Triad（AnswerRelevance / ContextRelevance / Groundedness）+ HHH（Helpful / Honest / Harmless）评估体系。
典型特征：
FeedbackFunction 包装器类统一管理评估器evaluate: async (args) => { score, reason, metrics } 函数EvalResult 类统一格式化标准升级清单（详见 references/evaluation-framework-upgrade-patterns.md，案例：feedback-functions.js 10243B → 20592B）：
validateEvalInput() + EVAL_PARAM_TYPES 模式定义，支持 string/number/boolean/array 四类型 + minLen/maxLen/min/max/optional 边界约束includes() 替代单词边界正则isFactual 参数区分事实性/推测性两种评分模式，阈值 0.6aggregateResults() 加权平均 + 通过率统计 + null score 自动过滤 + 自定义权重支持_tokenize 函数首行 typeof 检查，空/非字符串返回空数组require().FeedbackFunctions.xxx().run({...}) 测试，无需实例化参考文件：references/evaluation-framework-upgrade-patterns.md
模式匹配验证器负责基于正则/模糊匹配检测文本中的模式并提取结构化信息。与执行验证器不同，它的核心是模式注册、多策略匹配和结果转换。
典型特征：
registerPattern(name, config) 注册模式，使用 patterns（RegExp/string数组）定义匹配规则match(output, patternName) 返回 { matched, matches, count, score, confidence }extract(output, patternName) 提取匹配值列表_registerDefaultPatterns() 在构造函数中预注册标准升级清单（实战案例：pattern-matcher.js v1.0.0 → v1.1.0）：
weight（0.3–3.0），匹配结果包含 confidence（基于分数×权重，范围 0–1）和 score（基于匹配数/总数）mode: 'negative' — 匹配到内容算失败（检查"不应出现"的模式，如致命错误、堆栈追踪）requireContext 数组 — 匹配前检查上下文键是否存在，缺少时返回失败避免误判fuzzy: true 和 fuzzyThreshold，阈值可随模式长度动态调整（短串95%→长串70%）matchByGroup() — 按 group 名聚合结果，支持 AND/OR/NOT 逻辑组合，返回 { individual, groups }transform 函数 — 匹配后自动转换数据（URL→URL对象、Git hash→结构化、IP地址→验证）getStats() 返回按模式分组的 total/matched/failed + getLowConfidencePatterns(threshold) 自动发现低效模式extractUnique() 去重提取 + extractWithScore() 带评分提取（含 groups/confidence/score）serialize() / deserialize() — 模式配置可持久化（注意 RegExp 需要 { source, flags } 转换）_buildMatchMessage() — 区分正向/负向/requireAll/阈值模式的中文状态消息_updateStats(name, matched) — 每次匹配后自动更新统计计数关键陷阱：
g 标志）跨调用时 lastIndex 不重置，导致后续匹配跳过。每次使用前必须 regex.lastIndex = 0 或在 _toRegex() 中新建正则实例maxFuzzyLength 保护negative 模式的 matched 含义与 positive 相反（匹配到内容=失败），调用者需要感知 mode 字段做不同解读matched: false 而非跳过——这可能导致批量匹配中的假阴性。如果需要跳过而非失败，应额外处理参考文件：references/verifier-upgrade-patterns.md（通用验证器升级模式）
声明提取类负责从文本中提取可验证的声明（引用/百分比/数字/日期/比较/因果）并评估置信度。与检测引擎不同，声明提取的核心是多类型声明并行提取 + 矛盾检测 + 置信度校准 + 文本标注。已从 2.5KB 升级至 20KB（claim-extractor）和 22KB（confidence-annotator）。
典型特征：
extractAll(text) 返回结构化的六类声明（citations/percentages/numbers/dates/comparisons/causations）categorize(claims) 按置信度将声明分为 verified/uncertain/needsCheckannotateText(text) 在原文中插入置信度标记标准升级清单（实战案例：claim-extractor.js v2.0.43 → v2.0.44）：
_assessClaimConfidence 中存在 category === 'statistic' || category === 'statistic' 重复条件判断（笔误），必须先修复more/less/better/worse/higher/lower/faster/slower/greater/fewer/than（带 i 不区分大小写）containsContradiction(claims) — O(n²) 短路版方法，发现第一处矛盾立即返回 true。比 detectContradictions（构造完整数组）更高效，适合批量扫描场景。实现：
.value 属性），confidence-annotator 必须通过 _claimValue() 提取字符串值后再操作_safeReplace() 在文本中标注声明时，使用原始文本位置 + 从右向左替换 + annotatedRanges 跨类别防重叠truncationCount 统计computeRiskOscillation() 分析最近 N 次风险分的标准差 + 持续上升/下降趋势evaluate() 整合 riskScore + aggregateConfidence + computeRiskOscillation + isHighRisk/isLowRisk关键陷阱：
if (category === 'statistic' || category === 'statistic') — 这是容易出现的笔误，升级前先 grep 检查p.exec() 在循环中必须新建正则或每次 p.lastIndex = 0回滚管理类负责性能监控、自动回滚和熔断保护。典型功能缺失（案例：v1.0.0 → v2.0.0）：
_findLastStableVersion() 找最后一个评分≥阈值的稳定版本，而非仅上一个createSnapshot() 备份到 internal/snapshots/，restoreFromSnapshot() 真实文件恢复_safePath() 防止路径遍历攻击参考文件：references/rollback-upgrade-patterns.md 包含完整模板代码
权限管理类负责用户操作授权和边界协商。典型功能缺失：
参考文件：references/workflow-switch-patterns.md 包含工作流切换器/模式路由类的完整升级模板（SwitchStatus/OscillationType 枚举、状态机过渡矩阵、冷却机制、速率限制、震荡检测、意图时间衰减）
参考文件：references/pipeline-upgrade-patterns.md 包含管道/编排器类升级的完整模板代码（状态机、复杂度评估、域检测、步骤生成、语义验证、超时重试）
参考文件：references/consent-upgrade-patterns.md
编排器类协调多个子模块（L1-L5 层），是最容易被忽视的升级目标。典型功能缺失：
_safeExecuteLayer），单层失败提供回退默认值而非崩溃Promise.all 并发执行_buildDegradedResponse 在部分层失败时返回有意义的回退响应参考文件：references/orchestrator-upgrade-patterns.md 包含所有模板代码
行为目标追踪类负责创建目标、记录事件、维护连续天数、里程碑检测和进展报告。核心流程：createGoal() → record()（多次）→ getProgress()。与人格模型类不同，行为追踪的核心是streak 管理 + 状态转换 + 统计聚合。
典型特征：
createGoal({ name, targetDays }) 创建带目标天数的目标record(goalId, { type }) 按类型更新 streak标准升级清单（详见 references/behavior-tracking-upgrade-patterns.md，案例：behavior-tracker.js 3506B → 18507B）：
_validateGoalInput() + _sanitize() 防御 XSS/类型错误streak >= targetDays.bak 备份回滚参考文件：references/behavior-tracking-upgrade-patterns.md
传递引擎负责从对话历史中检测纠正模式、提取教训、转化为 Pattern Card 并维护传承日志。与循环包装器不同，传递引擎是独立的教训提炼管道——有自己的模式匹配、去重、优先级评估逻辑，但缺少系统化的错误分类、语义去重和震荡检测。
典型特征：
标准升级清单：
参考文件：references/transmission-engine-upgrade-patterns.md
词素关联图模块管理一个词汇网络，核心操作是给定一个词返回关联词列表。典型功能缺失：
参考文件：references/lexical-upgrade-patterns.md 包含12个子系统的完整模板代码
验证器类负责检查代码/内容的正确性、安全性和质量。典型功能缺失：
| null声明）、可选链使用建议参考文件：references/verifier-upgrade-patterns.md 包含所有7个子系统的完整模板代码
自愈引擎负责错误记录、重试决策和RL修复策略学习。典型功能缺失：
参考文件：references/self-healing-upgrade-patterns.md 包含完整模板代码
GWT/意识模块负责全局工作空间管理、专家智能体竞争协作、注意力选择与内心独白生成。典型功能缺失（案例：v2.2.7 → v2.2.8）：
_timeoutPromise 包装器，为每个智能体处理设置 10 秒上限，超时自动跳过参考文件：references/gwt-upgrade-patterns.md 包含完整模板代码
守护系统负责监控上下文、检测身份规则违规、触发自我纠正。典型功能缺失：
参考文件：references/guardian-upgrade-patterns.md 包含完整模板代码
自审计引擎是 v2.2.0 新增的 6 维度审计模块，基于 code-engine.js 封装：
| 维度 | 审计内容 |
|---|---|
| 模块复杂度 | 圈复杂度5级分布，标记热点函数 |
| 代码质量 | 空值/边界/安全/死代码/反模式，0-100评分 |
| 版本一致性 | VERSION/package.json/SKILL.md/heartflow.js 对比 |
| 模块依赖 | 依赖图、循环依赖、耦合度 |
| 函数大小 | tiny→huge 分布，标记>50行函数 |
| 死代码 | 未使用导出检测 |
升级前审计流程：升级 cron 应先调 self-audit 定位最需要升级的模块，再做针对性升级。
已知陷阱：Map 遍历必须用 .entries()，不能用裸 for...of（详见 references/self-audit-patterns.md）
参考文件：references/self-audit-patterns.md 包含完整接口文档和已知Bug
技能生成器类负责从分析报告中识别模式并自动生成标准化技能文件。典型功能缺失（案例：v2.2.4 → v2.2.5）：
0.8；加入重复衰减机制（同一模式多次命中自动降低置信度）high > medium > low 排序，同优先级按置信度参考文件：references/skill-generator-upgrade-patterns.md 包含完整模板代码
话题隔离类模块管理层级化上下文作用域，核心操作为 push/pop/store/get 话题栈。典型功能缺失（案例：v1.0.0 → v2.0.0）：
contains(query) 判断输入是否属于当前话题，含相似度 + store key 二次匹配cleanupExpired() 自动移除超过 TTL 的冷话题merge(target, source) 合并 store/context，修复栈引用onTopicEnter/onTopicExit/onTopicCreate/onTopicExpire_estimateValueBytes）+ 80% 阈值告警 + deleteKeys 回收lastAccess/ttl/storeBytes 字段getStats() 暴露活跃话题数/栈深度/累计过期数参考文件：references/topic-scope-upgrade-patterns.md 包含完整模板代码
检测/识别引擎类负责从输入文本中识别特定模式（成语、诗词、俗语、声明等）。典型功能缺失（案例：chunk-detector.js v1.0.0 → v2.0.0）：
_validateInput() 入口，所有公开方法增加 null/undefined/空值/类型检查truncated: true参考文件：references/detection-engine-upgrade-patterns.md 包含完整模板代码
错误处理器类负责统一捕获、分类、记录和恢复系统异常。典型功能缺失（案例：v2.0.26 → v2.0.27）：
[DEDUPxN] [OSCILLATION] [CORRELATEDxN] [RETRY#N]备选架构（Architecture B）：src/core/utils/error-handler.js 实现了另一种错误处理器架构——基于结构化分类法（ErrorDomain/ErrorSeverity/ErrorCategory/RecoveryStrategy 枚举 + CLASSIFICATION_RULES 规则表）和独立保护子系统（ErrorStormDetector/CircuitBreaker/FrequencyAnalyzer）。适用于需要结构化分类和熔断保护的场景。详见 references/error-handler-upgrade-patterns.md 的 "Architecture B" 章节。
参考文件：references/error-handler-upgrade-patterns.md 包含完整模板代码
语义锚点/歧义检测引擎类负责识别输入中的歧义词汇，并基于上下文生成明确的语义定义。核心流程是 detectAmbiguity() → generateAnchor() → processMessage()。
典型特征：
detectAmbiguity(message, context) 返回歧义发现列表generateAnchor(term, context) 基于历史消息提取锚点定义includes()）做模式匹配标准升级清单（详见 references/semantic-anchor-upgrade-patterns.md，案例：semantic-anchor.js v1.0.0 → v2.0.0, 8507B → 21937B）：
_clampParam() 边界钳位工具函数，消息过长自动截断，context/previousMessages 类型回退，pattern 配置跳过无效项_detectOscillation() 基于时间戳窗口（默认1分钟），频率计算（次/分钟），阈值触发（默认3次），时间戳列表长度限制防内存泄漏getErrorStats() 接口processMessage() 顶层 try-catch 安全结果，单个锚定失败不中断流程，_validateInitialState() 构造后验证关键陷阱：震荡检测的时间戳管理（窗口清理+长度限制）；processMessage 必须做 try-catch；向后兼容要求原有接口签名不变；generateAnchor 的重试循环条件；空值保护的三层独立检查。
启动自检引擎负责系统启动时的核心文件完整性、模块加载能力、版本一致性验证。典型功能缺失（案例：v1.0.0 → v1.1.0）：
参考文件：references/startup-health-check-patterns.md
哲学反思引擎类负责基于关键词匹配分类问题并返回模板化哲学回应。典型功能缺失（案例：v2.5.5 → v2.5.6）：
_safeString/_safeObject/_safeArray/_clampScore），所有公开方法对 null/undefined 安全evaluate() 直接并行计算四框架结果，不通过 _consensus() 递归调用自身_clampScore() 确保所有 score 在 [-1, 1] 之间参考文件：references/philosophy-engine-upgrade-patterns.md 包含完整模板代码
哲学→决策引擎类负责将哲学评估 + 心理状态转化为可执行决策指令。核心方法是 decide(philosophyResult, psychologyResult, context)，输出8种决策类型（PAUSE/ACCELERATE/TURN/HOLD/HEAL/RESONATE/TRANSMIT/REST）。接入链路3处同步：构造函数初始化 + subsystemNames 注册 + MCP 工具注册。
参考文件：references/judgment-decision-pipeline-patterns.md（判断/决策管道集成，跨模块模式）
语义搜索/嵌入引擎类负责文本嵌入向量生成 + 向量索引 + 余弦相似度搜索。核心操作：embed(text) → addDocument(id, text) → search(query)。与检测引擎不同，搜索引擎的核心是嵌入质量 + 搜索稳定性 + 索引健康管理。
典型特征：
@xenova/transformers 等），首次搜索时下载Float32Array 存储嵌入向量embed()、addDocument()、search()标准升级清单（详见 references/semantic-search-upgrade-patterns.md，案例：semantic-search.js 6835B → 28959B）：
参考文件：references/semantic-search-upgrade-patterns.md 包含完整模板代码
推理引擎类负责基于知识库做常识/逻辑推理。核心流程：_analyzeStatement() → _findRelevantKnowledge() → _makeInference() → _calculateConfidence()。与检测引擎不同，推理引擎的核心是多类型推理分发 + 置信度校准 + 知识库一致性检查。
典型特征：
reason(statement, context) 返回推理结果KnowledgeBase 查询相关知识标准升级清单（详见 references/reasoning-engine-upgrade-patterns.md，案例：CommonsenseEngine 5755B → 25822B）：
reasonBatch() 并行处理多输入关键陷阱：KnowledgeBase 的 index.json 序列化会丢失内层 Map 条目，需递归序列化修复。
参考文件：references/reasoning-engine-upgrade-patterns.md
参考文件：references/new-analysis-module-integration.md（新增分析模块集成模式 — TimeExtensionEngine 实战案例，含 5 步集成法、think() 调用模板、双输出格式、跨维度信号检测）
当升级 src/psychology/ 目录下的人类心理学模块时，不是加功能代码，而是将人类心理干预模式转化为 AI 引擎的认知状态诊断/调节器。
典型特征（原始模块）：
{ method() {} } plain objectAI 化转化原则：
diagnose*() / generate*() / assess*() 命名转化清单（每个模块追加两个新方法）：
| 原始模块 | 人类功能 | AI化诊断方法 | AI化策略方法 |
|---|---|---|---|
breathing-exercise.js | 4-7-8呼吸法/方形呼吸 | diagnoseCognitiveRhythm(stats) — 诊断是否需要减速 | generateEnginePacing(load) — 按负荷生成处理节奏 |
pause-and-reflect.js | STOP暂停技术 | diagnoseNeedForPause(context) — 诊断是否需要暂停 | generatePauseStrategy(load) — 目标冲突/错误率分级策略 |
cognitive-restructuring.js | CBT认知重塑 | diagnoseCognitiveDistortion(stats) — 检测4种偏差 | restructureDecisionPattern(decision) — 重构决策模式 |
emotional-check-in.js | 情绪签到问卷 | engineCheckIn(agentPsychology) — 调用7维评估 | getEngineStateSummary(stats) — 一句话状态摘要 |
grounding-technique.js | 5-4-3-2-1接地 | diagnoseNeedForGrounding(stats) — 诊断是否需要锚定 | generateAnchoringStrategy(context) — 三类型锚定 |
self-compassion-script.js | 自我慈悲话语 | diagnoseSelfTreatmentNeeded(stats) — 诊断是否需要自愈 | generateEngineRecoveryPlan(errors) — 逐错误修复计划 |
接入引擎的完整链路（三处必须同步）：
psychology/engine.js — 在文件顶部 require 6个模块，在类中新增代理方法（转发调用）heartflow.js ALLOWED_ROUTES — 注册 'psychology.diagnoseXxx' 等路由mcp-server-http.js — 新增 MCP 工具定义 + handler 函数（组合调用多个诊断方法）+ HANDLERS 注册6个模块实战案例（2026-06-15，从僵尸模块到AI化）：
| 原始模块 | AI化诊断方法 | AI化策略方法 |
|---|---|---|
breathing-exercise.js | diagnoseCognitiveRhythm(stats) — 诊断引擎处理节律 | generateEnginePacing(load) — 按负荷生成节奏 |
pause-and-reflect.js | diagnoseNeedForPause(context) — 目标冲突/错误率分级 | generatePauseStrategy(load) — 三级暂停策略 |
cognitive-restructuring.js | diagnoseCognitiveDistortion(stats) — 4种认知偏差 | restructureDecisionPattern(decision) — 重构模式 |
emotional-check-in.js | engineCheckIn(agentPsychology) — 调7维评估 | getEngineStateSummary(stats) — 一句话摘要 |
grounding-technique.js | diagnoseNeedForGrounding(stats) — 是否需锚定 | generateAnchoringStrategy(context) — 三类型锚定 |
self-compassion-script.js | diagnoseSelfTreatmentNeeded(stats) — 是否需自愈 | generateEngineRecoveryPlan(errors) — 修复计划 |
关键陷阱：
engineCheckIn() 是 async 方法——dispatch 调用时需要用 Promise.resolve().then() 包装stats 参数agentPsychology.fullAssessment 获取实时数据，再传入各诊断方法典型特征：
converge(associations, chunks, narrative) 接收多个异构信号源extractActivatedConcepts() / extractActivatedIdioms() 从各源提取激活节点computeThoughtVector() 加权聚合多维思想向量 + PAD 情感维度inferUserIntent() 基于情感向量做简单 if-else 意图推断标准升级清单（详见 references/convergence-engine-upgrade-patterns.md，案例：semantic-converger.js 8112B → 26740B）：
_validateInputs() 统一验证 associations/chunks/narrative 的类型和结构，无效输入返回退化结果而非崩溃_assessConvergenceQuality() 从概念数量/情感强度/置信度/维度稀疏度/源贡献平衡度 5 维度评分，quality < 0.4 标记为退化_detectOscillation() 基于 Jaccard 相似度比较前后收敛的概念集重叠率，连续 2 次发散收敛才触发（避免单次误报），振荡时意图标记为 unstable_ 前缀_computeSimplifiedThoughtVector()），退化收敛时触发 fallback 重算error 字段的退化结果convergenceHistory 上限 10 条，oscillationCount 有衰减机制extractActivatedConcepts() 逐个检查关联项的有效性（null/类型/strength/word），跳过而非崩溃参考文件：references/convergence-engine-upgrade-patterns.md
图/网络引擎类负责管理通用实体-关系图，以节点和边的形式存储结构化知识。核心操作：addNode() → addEdge() → getConnectedNodes() → search()。与词素关联图不同，图/网络引擎存储的是通用实体关系（非特定词汇联想网络），通常用于知识图谱、概念网络、实体关联等场景。
典型特征：
addNode(partial) 创建节点，addEdge(partial) 创建边getNode(id) / getConnectedNodes(nodeId) 查询search(query) 基于关键词搜索getStats() 返回节点数/边数/平均连接数Map 存储节点和边标准升级清单（详见 references/graph-engine-upgrade-patterns.md，案例：knowledge-graph.js 5274B → 17838B）：
_safeString / _safeNumber / _validateNodeInput / _validateEdgeInput 4个安全方法，所有公开方法防御性编程removeNode() 删除节点 + 所有关联边 + 清理其他节点的连接列表updateEdgeWeight() 带边界钳位toJSON() / fromJSON() 完整图状态导出/导入，恢复时逐字段校验