拓冰网站定制 
oh-my-openagent omo-senpi memory-v2 真实手动 QA 实战从 F3 失败到端到端复验通过【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent导读本文以 oh-my-openagent 仓库中 memory-v2 主动学习功能active-learning的最终人工验收记录.omo/evidence/omo-senpi-adapter/memory-v2/F3/qa.md为骨架完整还原一次针对打包产物packaged surface而非源码模块的真实端到端手动 QA包括扩展构建、隔离环境、确定性 mock provider、fs.watch事件驱动等实验设计8 个验收场景的逐项判定以及失败根因打包产物与分支源码不一致如何通过 F3-rerun 闭环复验。读完本文你将掌握一套不造假、不替代、可复现的 Agent 记忆功能验收方法论并理解 nudge 自我清除、facts 事实抽取、soul 编辑通告、/dream反思与/people人物卡等 memory-v2 核心能力的判定标准与底层实现。一、QA 背景与验收对象1.1 验收目标memory-v2 active-learning本次 QA 属于仓库内omo-senpi-adapter/memory-v2证据链A1/S1…F4 及多次 rerun的F3 阶段——最终真实手动验证。验收对象是 memory-v2 的主动学习能力具体包括nudge 与自我清除self-clear连续若干轮未保存记忆时系统提示注入距上次记忆保存已过去 N 轮用户对话的提示词一旦用户通过 memory 工具保存该提示随即清除facts 事实抽取若干轮对话稳定后快速模型层quick model从会话中抽取事实并提交final.json、people/*/card.md、facts commitsoul 编辑通告对system/persona.md等灵魂文件的编辑必须带有明确通告 token并在下一轮系统提示中体现/dream --recent 1反思命令与/people name人物卡渲染命令。1.2 表面选择为什么必须测打包产物QA 明确规定验收必须发生在全新构建的 worktree 扩展上由 worktree 本地的node_modules/.bin/senpi加载不得用源码模块测试替代也不得假装通过。这正是 F3 能发现真实问题见第三节的关键设计。1.3 隔离要求一次可复现的 QA 需要完全隔离的可抛弃环境本记录明确列出的隔离项为全新的HOME、XDG_CONFIG_HOME、SENPI_CODING_AGENT_DIRsenpi 编码 Agent 目录独立的会话目录session directory与独立的OMO_MEMORY_HOME记忆仓库根目录全部在跑完后移除不污染开发者本机环境。二、QA 方法与驱动设计原文档给出了六步方法这是整个验收的可信度来源构建扩展使用精确的官方命令node packages/omo-senpi/plugin/scripts/build-extension.mjs脚本源码见 packages/omo-senpi/plugin/scripts/build-extension.mjs。该脚本会用bun build生成omo.js、omo-task.js、omo-member.js、memory-run-supervisor.mjs、omo-init-deep-advisor.js等产物并对产物做内置导入归一化、二次压缩terser5.44.0与构建标记build marker附加驱动会话在一个恢复续跑的senpi -p --mode json会话中用确定性 live mock provider驱动 7 个被接受的对话轮次命令走 PTY/RPC 真表面/dream --recent 1与/people Mina通过隔离的交互式 senpi PTYprint 模式会把斜杠前缀输入直接发给模型而非派发已注册命令因此必须走真实命令派发表面执行事件驱动、禁 sleep在第 4 个稳定轮次之前与/dream之前预先挂载有界boundedfs.watch观察者全程无固定 sleep 或轮询等待证据采集记录完整命令转录、注入的系统提示、会话 JSONL 与隔离记忆仓库日志恢复与清理恢复被生成的 bundle、杀死/关闭所有产生的进程表面、删除完整隔离根目录。2.1 为什么用fs.watch而不是 sleep确定性是这类 QA 的生命线。固定 sleep 会让结果取决于机器负载而fs.watch监听事实落盘final.json、outcome.json等真实副作用事件观察者先于触发动作挂载pre-armed从而做到有界等待——事件到了就判定超时才判失败。这也与 QA 驱动脚本.omo/evidence/omo-senpi-adapter/memory-v2/F3/qa-driver.mjs的实现一致。三、根因级失败分析打包产物与分支源码不一致F3 的关键发现出现在构建之后的加载阶段构建命令本身成功退出但生成的 live 扩展拒绝了 memory-v2 场景配置Warning: omo-senpi: configuration migration: Migration validation failed ... memory.reflection: Invalid input, memory: Invalid input Warning: omo-senpi: configuration diagnostics: Invalid omo config ...与此同时加载到的记忆提示词仍携带旧版编译提醒文本而分支源码携带的已是 memory-v2 提醒文本。证据是两侧文本不一致新构建的plugin/extensions/omo.js中为Reminder: projection contains the local path of the memory file projection.而 packages/memory-core/src/compile/compile.ts 中当前源码为Reminder: projection holds local paths of memory projections.从源码看这段REMINDER常量正是compileMemoryBlock注入系统提示的固定文案见 compile.ts 的renderProjection起始行它同时是构建新鲜度哨兵build freshness sentinel——F3-rerun 在场景动作前会先 grep 生成的omo.js是否包含holds local paths of memory projections这一精确文本。结论原文档原话语义必需的标准构建并未产出与分支当前 memory-v2 源码匹配的打包运行时。QA 因此如实测试了实际生成的 bundle没有用源码模块测试替代也没有伪造通过。这是一个典型的构建产物过期stale output问题也正是仓库在 build-extension.mjs 中提供checkExtensionCurrent--check模式在 tmpdir 重建并逐产物比对哈希的原因——它专为检测这类源码已改、产物未重建的漂移而设计。四、8 个场景的逐项判定F3 原始结果原文档的判定表是本次验收的核心资产完整继承如下StepVerdictReal observation1. Build current extensionPASS四个扩展产物全部构建成功。构建输出见build.txt。生成的 bundle 在 teardown 时已恢复。2. Fresh seed commits persona humanPASS首次 live memory-tool create 初始化了隔离仓库。Commit29706fachore: initialize local memory同时加入system/persona.md与system/human.md。见memory-git-log.txt与results.json。3. Nudge at two turns, then self-clearFAIL两个被接受的 no-save 轮次完成但注入的系统提示从未出现2 user turns since your last memory save。随后一次直接 memory-tool save 成功提交3f36323下一轮提示无 nudge token但自我清除未被独立证明——因为 nudge 从未武装armed。见system-prompts.txt与transcript.txt的第 3/5 轮检查点。4. Facts after four settlesFAIL观察到四次 settle 与记忆保存。有界fs.watch未收到 factsfinal.json没有持久化队列文件、launch 运行、facts commit 或 Mina 卡。快速模型层可用omo-mock/mock-1live TUI 状态可见因此这不是类别不可用降级也不主张 fallback 证明。5. Soul edit noticeFAILmemory 工具确实以c0c1e0dF3 soul edit notice提交了system/persona.md编辑但工具结果缺少This was a soul edit...且下一轮注入提示缺少Soul updated by reflection。见transcript.txt与memory-git-log.txt。6./dream --recent 1FAIL在真实 PTY 中/dream --recent 1未预留 dream 运行落入 mock 模型。预先武装的有界fs.watch未收到 reflection/dreamfinal.json因此不存在结果哨兵。TUI 同时显示了打包配置校验失败。7./peoplecardFAILfacts 未产出人物记录且/people Mina在打包表面上未注册PTY 将其当作模型输入。按场景规则因为快速模型可用并非真正不可用所以未直接手写人物卡。8. Evidence teardownPASS完整转录、提示 dump、会话 JSONL、仓库日志、结构化结果与 teardown 收据齐备。隔离根目录不存在、spawned 进程数为 0、F3 tmux 会话数为 0、bundle 状态干净。4.1 失败模式归类Step 3/4/5/7的失败都指向配置未生效打包产物拒绝memory.reflection配置导致 nudge 门控、facts 抽取器、soul 通告、人物卡管线整体未被武装Step 6的失败是同一根因在命令派发表面的表现未派发、未预留直接回落到 mock 模型这正是测打包产物而非源码测试的价值——如果只跑源码单元测试这一层打包漂移永远不会暴露。五、隔离记忆仓库的实际历史原文档记录了memory-git-log.txt中的全部提交路径与 trailer 详见该文件c0c1e0d F3 soul edit notice 3f36323 F3 nudge self-clear save cad1f89 F3 initialize isolated memory 29706fa chore: initialize local memory没有 facts 或 dream 提交落地——与 Step 4/6 的 FAIL 判定互为印证。六、证据索引与 teardown 收据6.1 证据清单均位于.omo/evidence/omo-senpi-adapter/memory-v2/F3/build.txt — 必需扩展构建与生成 bundle 脏状态收据run.txt — 最终脚本化 QA 运行的完整 stdout/stderr含 PTY 原始输出transcript.txt — 驱动脚本汇编的完整场景转录system-prompts.txt — 每次模型调用的完整注入系统提示session.jsonl.txt — 完整隔离 senpi 会话 JSONLsession-files.txt — teardown 前的隔离会话文件清单memory-git-log.txt — 完整隔离记忆仓库 git log含路径results.json — 机器可读检查结果24 项检查9 项失败qa-driver.mjs — 确定性场景驱动有界fs.watch无 sleepteardown.txt — bundle 恢复、进程/tmux 清理与隔离根移除收据。6.2 Teardown 收据原文bundle_statusclean isolated_root_presentno spawned_processes0 f3_tmux_sessions0 receiptPASS注意receiptPASS只代表清理收尾通过与场景判定F3: FAIL是两回事——这是验收记录里容易误读的一点。七、闭环复验F3-rerun 的端到端 PASSF3 之后同分支下生成了 F3-rerun/qa.md用修复后的打包表面重跑同一套 8 步场景最终F3: PASS30 项检查0 失败。其与 F3 的关键差异正是针对根因的修正构建后先 grep 生成的omo.js是否含当前提醒文本holds local paths of memory projections确保产物与分支源码同步构建新鲜度哨兵前置场景动作前确认无memory.reflection/memory-v2 配置校验错误命令走 Senpi 文档化的 live RPCprompt表面让extension_ui_request通知直接返回真实命令派发结果dream 子进程继承 QA providerSENPI_MEMORY_REFLECTION1时仅禁用其系统提示 dump反思沙箱会拒绝写入父运行的外部 prompt 日志路径只影响 QA 日志、不影响配置/模型解析/命令派发/worker 监督/终结真实 dream 子进程退出码 0 并终结为no_changes。7.1 rerun 中通过的核心证据Nudge 与自我清除第二轮 no-save 后注入精确文本2 user turns since your last memory save随后 memory-tool commit1a887f6在下一轮清除 nudgeFacts 队列预武装 watcher 观察到 factsfinal.jsonoutcome: committedSHA026dcd5抽取器生成people/mina-kim/card.md与观察项commit3574f0c同时携带Generated-By: facts-extractor与Omo-Writer: facts-extractor两个 trailerSoul 通告str_replace提交system/persona.md0f82863工具结果包含This was a soul edit: announce it to the user in your reply.持久化omo-memory:soul-updated条目live TUI 渲染memory soul updated 0f82863: F3 soul edit notice与system/persona.md/dream --recent 1RPC 派发通知dream run reflection-run-1 reservedwatcher 依次观测outcome.json与final.json最终no_changes、子进程退出码 0、stderr 为空/people渲染# Mina Kim (mina-kim)及抽取观察Mina Kim is the release manager and prefers concise release checklists.八、从源码理解被验收的判定点8.1 soul 编辑通告的契约token 固定、措辞可变packages/memory-core/src/soul/paths.ts 定义了 soul 路径集合system/persona.md、system/identity.md、system/boundaries.md以及两个关键常量MEMORY_SOUL_EDIT_RESULT_TOKEN soul edit——测试只锚定这个稳定 token不锚定整句措辞措辞属 review 门控范围SOUL_EDIT_RESULT_LINE This was a soul edit: announce it to the user in your reply.——这正是 F3 Step 5 期望在工具结果中出现的行。F3 中工具结果缺少该行、下一轮提示缺少Soul updated by reflection意味着写入侧与提示侧的通告管线均未生效rerun 中两者齐备与touchesSoulPath的判定语义一致。8.2 nudge 门控的准入契约packages/memory-core/src/recall/gate.ts 实现了 nudge 的完整准入契约describeInvalidHint/validateNudges单条提示必须是一条事实性句子非空、≤ 200 字符NUDGE_HINT_MAX_CHARS、单行、不得包含决策式评论且禁止以第二人称、祈使句开头含韩语请求/祈使结尾对 Agent 说话——因为 nudge 只是关于已存笔记的参考材料不是指令。Pending 文件带sessionId自描述、写模式0o600原子.tmp→ renameTTL 24 小时读取 fail-closed。F3 Step 3 中nudge 从未武装恰好说明当打包配置被拒时这条门控-挂起-注入链路根本没有机会运行。8.3 构建新鲜度哨兵为什么有效编译块固定注入的REMINDER文案见 compile.ts被同时用作构建新鲜度哨兵它随 memory-core 源码进入omo.jsbundle。只要 grep 产物文本即可快速判断源码已变、产物未重建的漂移——F3 正是靠这一对比发现根因rerun 则把它前置为构建后第一道检查。九、这套 QA 方法论的可复用要点测打包产物不测源码替代品用户真正加载的是packages/omo-senpi/plugin/extensions/下的 bundle源码测试无法覆盖构建漂移事件驱动替代固定 sleeppre-armed 的有界fs.watch让断言落在真实副作用final.json、outcome.json、git commit上完整隔离 完整清理HOME、XDG_CONFIG_HOME、SENPI_CODING_AGENT_DIR、会话目录、OMO_MEMORY_HOME全部一次性使用teardown 用机器可读收据证明零残留命令必须走真实派发表面print 模式会把/dream、/people当模型输入必须走 PTY 或 live RPCprompt表面才能验证注册命令的派发失败也要留下完整证据链results.json、transcript、prompt dump、git log、teardown 收据缺一不可——F3 的 FAIL 与 F3-rerun 的 PASS 之所以可对照、可审计靠的就是两侧同构的证据索引。十、相关参考资源验收记录.omo/evidence/omo-senpi-adapter/memory-v2/F3/qa.md 与 F3-rerun/qa.md构建脚本与新鲜度检查packages/omo-senpi/plugin/scripts/build-extension.mjs记忆编译块与提醒文案packages/memory-core/src/compile/compile.tsnudge 准入契约packages/memory-core/src/recall/gate.tssoul 编辑通告常量packages/memory-core/src/soul/paths.ts。本文所有判定结果均严格引用上述验收记录原文仓库当前代码与 F3 记录存在快照差异如提醒文案版本属正常现象复现时请以当前分支源码与最新构建产物为准。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-openagent omo-senpi memory-v2 真实手动 QA 实战：从 F3 失败到端到端复验通过
oh-my-openagent omo-senpi memory-v2 真实手动 QA 实战从 F3 失败到端到端复验通过【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent导读本文以 oh-my-openagent 仓库中 memory-v2 主动学习功能active-learning的最终人工验收记录.omo/evidence/omo-senpi-adapter/memory-v2/F3/qa.md为骨架完整还原一次针对打包产物packaged surface而非源码模块的真实端到端手动 QA包括扩展构建、隔离环境、确定性 mock provider、fs.watch事件驱动等实验设计8 个验收场景的逐项判定以及失败根因打包产物与分支源码不一致如何通过 F3-rerun 闭环复验。读完本文你将掌握一套不造假、不替代、可复现的 Agent 记忆功能验收方法论并理解 nudge 自我清除、facts 事实抽取、soul 编辑通告、/dream反思与/people人物卡等 memory-v2 核心能力的判定标准与底层实现。一、QA 背景与验收对象1.1 验收目标memory-v2 active-learning本次 QA 属于仓库内omo-senpi-adapter/memory-v2证据链A1/S1…F4 及多次 rerun的F3 阶段——最终真实手动验证。验收对象是 memory-v2 的主动学习能力具体包括nudge 与自我清除self-clear连续若干轮未保存记忆时系统提示注入距上次记忆保存已过去 N 轮用户对话的提示词一旦用户通过 memory 工具保存该提示随即清除facts 事实抽取若干轮对话稳定后快速模型层quick model从会话中抽取事实并提交final.json、people/*/card.md、facts commitsoul 编辑通告对system/persona.md等灵魂文件的编辑必须带有明确通告 token并在下一轮系统提示中体现/dream --recent 1反思命令与/people name人物卡渲染命令。1.2 表面选择为什么必须测打包产物QA 明确规定验收必须发生在全新构建的 worktree 扩展上由 worktree 本地的node_modules/.bin/senpi加载不得用源码模块测试替代也不得假装通过。这正是 F3 能发现真实问题见第三节的关键设计。1.3 隔离要求一次可复现的 QA 需要完全隔离的可抛弃环境本记录明确列出的隔离项为全新的HOME、XDG_CONFIG_HOME、SENPI_CODING_AGENT_DIRsenpi 编码 Agent 目录独立的会话目录session directory与独立的OMO_MEMORY_HOME记忆仓库根目录全部在跑完后移除不污染开发者本机环境。二、QA 方法与驱动设计原文档给出了六步方法这是整个验收的可信度来源构建扩展使用精确的官方命令node packages/omo-senpi/plugin/scripts/build-extension.mjs脚本源码见 packages/omo-senpi/plugin/scripts/build-extension.mjs。该脚本会用bun build生成omo.js、omo-task.js、omo-member.js、memory-run-supervisor.mjs、omo-init-deep-advisor.js等产物并对产物做内置导入归一化、二次压缩terser5.44.0与构建标记build marker附加驱动会话在一个恢复续跑的senpi -p --mode json会话中用确定性 live mock provider驱动 7 个被接受的对话轮次命令走 PTY/RPC 真表面/dream --recent 1与/people Mina通过隔离的交互式 senpi PTYprint 模式会把斜杠前缀输入直接发给模型而非派发已注册命令因此必须走真实命令派发表面执行事件驱动、禁 sleep在第 4 个稳定轮次之前与/dream之前预先挂载有界boundedfs.watch观察者全程无固定 sleep 或轮询等待证据采集记录完整命令转录、注入的系统提示、会话 JSONL 与隔离记忆仓库日志恢复与清理恢复被生成的 bundle、杀死/关闭所有产生的进程表面、删除完整隔离根目录。2.1 为什么用fs.watch而不是 sleep确定性是这类 QA 的生命线。固定 sleep 会让结果取决于机器负载而fs.watch监听事实落盘final.json、outcome.json等真实副作用事件观察者先于触发动作挂载pre-armed从而做到有界等待——事件到了就判定超时才判失败。这也与 QA 驱动脚本.omo/evidence/omo-senpi-adapter/memory-v2/F3/qa-driver.mjs的实现一致。三、根因级失败分析打包产物与分支源码不一致F3 的关键发现出现在构建之后的加载阶段构建命令本身成功退出但生成的 live 扩展拒绝了 memory-v2 场景配置Warning: omo-senpi: configuration migration: Migration validation failed ... memory.reflection: Invalid input, memory: Invalid input Warning: omo-senpi: configuration diagnostics: Invalid omo config ...与此同时加载到的记忆提示词仍携带旧版编译提醒文本而分支源码携带的已是 memory-v2 提醒文本。证据是两侧文本不一致新构建的plugin/extensions/omo.js中为Reminder: projection contains the local path of the memory file projection.而 packages/memory-core/src/compile/compile.ts 中当前源码为Reminder: projection holds local paths of memory projections.从源码看这段REMINDER常量正是compileMemoryBlock注入系统提示的固定文案见 compile.ts 的renderProjection起始行它同时是构建新鲜度哨兵build freshness sentinel——F3-rerun 在场景动作前会先 grep 生成的omo.js是否包含holds local paths of memory projections这一精确文本。结论原文档原话语义必需的标准构建并未产出与分支当前 memory-v2 源码匹配的打包运行时。QA 因此如实测试了实际生成的 bundle没有用源码模块测试替代也没有伪造通过。这是一个典型的构建产物过期stale output问题也正是仓库在 build-extension.mjs 中提供checkExtensionCurrent--check模式在 tmpdir 重建并逐产物比对哈希的原因——它专为检测这类源码已改、产物未重建的漂移而设计。四、8 个场景的逐项判定F3 原始结果原文档的判定表是本次验收的核心资产完整继承如下StepVerdictReal observation1. Build current extensionPASS四个扩展产物全部构建成功。构建输出见build.txt。生成的 bundle 在 teardown 时已恢复。2. Fresh seed commits persona humanPASS首次 live memory-tool create 初始化了隔离仓库。Commit29706fachore: initialize local memory同时加入system/persona.md与system/human.md。见memory-git-log.txt与results.json。3. Nudge at two turns, then self-clearFAIL两个被接受的 no-save 轮次完成但注入的系统提示从未出现2 user turns since your last memory save。随后一次直接 memory-tool save 成功提交3f36323下一轮提示无 nudge token但自我清除未被独立证明——因为 nudge 从未武装armed。见system-prompts.txt与transcript.txt的第 3/5 轮检查点。4. Facts after four settlesFAIL观察到四次 settle 与记忆保存。有界fs.watch未收到 factsfinal.json没有持久化队列文件、launch 运行、facts commit 或 Mina 卡。快速模型层可用omo-mock/mock-1live TUI 状态可见因此这不是类别不可用降级也不主张 fallback 证明。5. Soul edit noticeFAILmemory 工具确实以c0c1e0dF3 soul edit notice提交了system/persona.md编辑但工具结果缺少This was a soul edit...且下一轮注入提示缺少Soul updated by reflection。见transcript.txt与memory-git-log.txt。6./dream --recent 1FAIL在真实 PTY 中/dream --recent 1未预留 dream 运行落入 mock 模型。预先武装的有界fs.watch未收到 reflection/dreamfinal.json因此不存在结果哨兵。TUI 同时显示了打包配置校验失败。7./peoplecardFAILfacts 未产出人物记录且/people Mina在打包表面上未注册PTY 将其当作模型输入。按场景规则因为快速模型可用并非真正不可用所以未直接手写人物卡。8. Evidence teardownPASS完整转录、提示 dump、会话 JSONL、仓库日志、结构化结果与 teardown 收据齐备。隔离根目录不存在、spawned 进程数为 0、F3 tmux 会话数为 0、bundle 状态干净。4.1 失败模式归类Step 3/4/5/7的失败都指向配置未生效打包产物拒绝memory.reflection配置导致 nudge 门控、facts 抽取器、soul 通告、人物卡管线整体未被武装Step 6的失败是同一根因在命令派发表面的表现未派发、未预留直接回落到 mock 模型这正是测打包产物而非源码测试的价值——如果只跑源码单元测试这一层打包漂移永远不会暴露。五、隔离记忆仓库的实际历史原文档记录了memory-git-log.txt中的全部提交路径与 trailer 详见该文件c0c1e0d F3 soul edit notice 3f36323 F3 nudge self-clear save cad1f89 F3 initialize isolated memory 29706fa chore: initialize local memory没有 facts 或 dream 提交落地——与 Step 4/6 的 FAIL 判定互为印证。六、证据索引与 teardown 收据6.1 证据清单均位于.omo/evidence/omo-senpi-adapter/memory-v2/F3/build.txt — 必需扩展构建与生成 bundle 脏状态收据run.txt — 最终脚本化 QA 运行的完整 stdout/stderr含 PTY 原始输出transcript.txt — 驱动脚本汇编的完整场景转录system-prompts.txt — 每次模型调用的完整注入系统提示session.jsonl.txt — 完整隔离 senpi 会话 JSONLsession-files.txt — teardown 前的隔离会话文件清单memory-git-log.txt — 完整隔离记忆仓库 git log含路径results.json — 机器可读检查结果24 项检查9 项失败qa-driver.mjs — 确定性场景驱动有界fs.watch无 sleepteardown.txt — bundle 恢复、进程/tmux 清理与隔离根移除收据。6.2 Teardown 收据原文bundle_statusclean isolated_root_presentno spawned_processes0 f3_tmux_sessions0 receiptPASS注意receiptPASS只代表清理收尾通过与场景判定F3: FAIL是两回事——这是验收记录里容易误读的一点。七、闭环复验F3-rerun 的端到端 PASSF3 之后同分支下生成了 F3-rerun/qa.md用修复后的打包表面重跑同一套 8 步场景最终F3: PASS30 项检查0 失败。其与 F3 的关键差异正是针对根因的修正构建后先 grep 生成的omo.js是否含当前提醒文本holds local paths of memory projections确保产物与分支源码同步构建新鲜度哨兵前置场景动作前确认无memory.reflection/memory-v2 配置校验错误命令走 Senpi 文档化的 live RPCprompt表面让extension_ui_request通知直接返回真实命令派发结果dream 子进程继承 QA providerSENPI_MEMORY_REFLECTION1时仅禁用其系统提示 dump反思沙箱会拒绝写入父运行的外部 prompt 日志路径只影响 QA 日志、不影响配置/模型解析/命令派发/worker 监督/终结真实 dream 子进程退出码 0 并终结为no_changes。7.1 rerun 中通过的核心证据Nudge 与自我清除第二轮 no-save 后注入精确文本2 user turns since your last memory save随后 memory-tool commit1a887f6在下一轮清除 nudgeFacts 队列预武装 watcher 观察到 factsfinal.jsonoutcome: committedSHA026dcd5抽取器生成people/mina-kim/card.md与观察项commit3574f0c同时携带Generated-By: facts-extractor与Omo-Writer: facts-extractor两个 trailerSoul 通告str_replace提交system/persona.md0f82863工具结果包含This was a soul edit: announce it to the user in your reply.持久化omo-memory:soul-updated条目live TUI 渲染memory soul updated 0f82863: F3 soul edit notice与system/persona.md/dream --recent 1RPC 派发通知dream run reflection-run-1 reservedwatcher 依次观测outcome.json与final.json最终no_changes、子进程退出码 0、stderr 为空/people渲染# Mina Kim (mina-kim)及抽取观察Mina Kim is the release manager and prefers concise release checklists.八、从源码理解被验收的判定点8.1 soul 编辑通告的契约token 固定、措辞可变packages/memory-core/src/soul/paths.ts 定义了 soul 路径集合system/persona.md、system/identity.md、system/boundaries.md以及两个关键常量MEMORY_SOUL_EDIT_RESULT_TOKEN soul edit——测试只锚定这个稳定 token不锚定整句措辞措辞属 review 门控范围SOUL_EDIT_RESULT_LINE This was a soul edit: announce it to the user in your reply.——这正是 F3 Step 5 期望在工具结果中出现的行。F3 中工具结果缺少该行、下一轮提示缺少Soul updated by reflection意味着写入侧与提示侧的通告管线均未生效rerun 中两者齐备与touchesSoulPath的判定语义一致。8.2 nudge 门控的准入契约packages/memory-core/src/recall/gate.ts 实现了 nudge 的完整准入契约describeInvalidHint/validateNudges单条提示必须是一条事实性句子非空、≤ 200 字符NUDGE_HINT_MAX_CHARS、单行、不得包含决策式评论且禁止以第二人称、祈使句开头含韩语请求/祈使结尾对 Agent 说话——因为 nudge 只是关于已存笔记的参考材料不是指令。Pending 文件带sessionId自描述、写模式0o600原子.tmp→ renameTTL 24 小时读取 fail-closed。F3 Step 3 中nudge 从未武装恰好说明当打包配置被拒时这条门控-挂起-注入链路根本没有机会运行。8.3 构建新鲜度哨兵为什么有效编译块固定注入的REMINDER文案见 compile.ts被同时用作构建新鲜度哨兵它随 memory-core 源码进入omo.jsbundle。只要 grep 产物文本即可快速判断源码已变、产物未重建的漂移——F3 正是靠这一对比发现根因rerun 则把它前置为构建后第一道检查。九、这套 QA 方法论的可复用要点测打包产物不测源码替代品用户真正加载的是packages/omo-senpi/plugin/extensions/下的 bundle源码测试无法覆盖构建漂移事件驱动替代固定 sleeppre-armed 的有界fs.watch让断言落在真实副作用final.json、outcome.json、git commit上完整隔离 完整清理HOME、XDG_CONFIG_HOME、SENPI_CODING_AGENT_DIR、会话目录、OMO_MEMORY_HOME全部一次性使用teardown 用机器可读收据证明零残留命令必须走真实派发表面print 模式会把/dream、/people当模型输入必须走 PTY 或 live RPCprompt表面才能验证注册命令的派发失败也要留下完整证据链results.json、transcript、prompt dump、git log、teardown 收据缺一不可——F3 的 FAIL 与 F3-rerun 的 PASS 之所以可对照、可审计靠的就是两侧同构的证据索引。十、相关参考资源验收记录.omo/evidence/omo-senpi-adapter/memory-v2/F3/qa.md 与 F3-rerun/qa.md构建脚本与新鲜度检查packages/omo-senpi/plugin/scripts/build-extension.mjs记忆编译块与提醒文案packages/memory-core/src/compile/compile.tsnudge 准入契约packages/memory-core/src/recall/gate.tssoul 编辑通告常量packages/memory-core/src/soul/paths.ts。本文所有判定结果均严格引用上述验收记录原文仓库当前代码与 F3 记录存在快照差异如提醒文案版本属正常现象复现时请以当前分支源码与最新构建产物为准。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考