oh-my-hermes四态状态表深入Plan·not run与Test·verified的本质区别【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermesoh-my-hermes 是一款面向 Hermes Agent 的 All in one 插件集编码智能、长期记忆与模型优化的工作流于一体。它最硬核的设计就是证据优先的四态状态表除非亲眼看到工作发生否则绝不宣称工作已完成。这篇文章从状态表的两个极端——Plan · not run与Test · verified——切入帮你用最短时间看懂为什么计划就绪和验证通过之间隔着一条不可跨越的证据鸿沟。为什么需要四态状态表市面上大多数 AI 编码工具只有一种状态complete。但执行器说自己干完了和有人真的检查过结果是两回事把它们都写成完成正是误导的根源。oh-my-hermes 用两个正交的轴重新定义了状态阶段轴PhaseRoute→Plan→Code→Setup→Test→Review→Ship描述工作走到了哪一步置信度轴Confidencenot run、running、reported done、verified等描述 OMH真正知道了什么。两轴拼接后就得到了人读得懂的标签比如Plan · not run、Code · running、Test · verified。这个设计的完整源码在 src/evidence/labels.py注释里写得很直白Code单独一个词无法说明 OMH 是亲眼看着执行器跑完的还是仅仅为它写好了一份 prompt——而绝大多数情况恰好是后者。四态状态表速查一分钟看懂每行含义官方文档中的原表如下完整上下文见 README.md你看到的它意味着Plan · not runprompt 或 plan 已就绪。还没有任何东西运行过。Code · running执行器正在运行OMH 正盯着它。Code · reported done执行器自称完成了。没有人检查结果。Test · verified测试、review 或 CI 门禁确实通过了。底层的线协议值wire value从未改变prepared_not_observed对应not runcompleted对应reported done状态词表定义在 src/coding/status_board.py 的STATUS_VOCABULARY中。所有界面聊天、状态板、路由摘要、菜单栏共用同一套标签解析方不受影响。一个关键细节失败关闭fail closed任何无法识别的状态值都会保守地回落到not run而不是渲染成发生过的工作。换句话说OMH 宁可说没跑过也不会说跑过了。这是整个四态体系的信任基石。Plan · not run工作还没发生这是状态表的起点。Plan · not run表示路由、prompt、计划文件都已准备完毕处于ready to run的待命状态但进程还不存在没有任何一行代码被实际执行它对应的线协议值是prepared_not_observed——已准备、未观测到。你可以把它理解为工单已经打印好、放在了待办桌上但工人还没有拿起工具。 此时看到Plan · not run不要担心是不是卡住了它只是如实告诉你一切就绪尚未开始。Code · reported done自称完成 ≠ 检查通过这是整张状态表里最容易踩坑的一行。执行器executor报告我完成了OMH 只是观测到了这个声称从未观测到结果本身。reported done这个标签的设计刻意把声称者写进了标签里一个自我报告的单元和一个通过门禁的单元在界面上永远不会长得一样。这正是 src/evidence/labels.py 注释中强调的承重标签——如果两者渲染相同用户就无法区分自称干完和真的检查过了。Test · verified证据的终点站Test · verified是状态表中唯一代表检查通过的状态。要走到这一步必须满足一次真实的测试、review 或 CI 门禁实际运行并通过了验证凭据verification receipt只有在其版本、命令、环境与记录完全匹配时才会被复用。配套的技能 skills/omh-verification-gate/SKILL.md 更进一步当声称中带有无关联的 TODO/stub 标记、被压制且无原因的测试、或fixed / verified / passing这类没有命令证据支撑的措辞时验证门禁会直接拒绝完成并指出违规类别、具体片段和补救方式。️本质区别一句话总结维度Plan · not runTest · verified时态将来时——工作还没有发生过去时——工作已被观测发生证据强度零只有计划最高门禁实测通过你该做什么放心等待或检查路由是否被卡住可以放心进入下一阶段核心结论两者的区别不在进度条走了多远而在证据是否被观测到。前者是 OMH 在说我什么都没看到后者是 OMH 在说我亲眼看到它通过了。动手验证如何快速上手四态状态表安装 oh-my-hermes 后发起一次编码委派任务在 Hermes 终端的 HUD 中观察每条委派泳道的状态行模型、effort、轮次、token、成本都会实时刷新留意状态流转顺序Plan · not run→Code · running→Code · reported done→Test · verified注意reported done与verified之间的停顿那正是门禁在检查遇到异常状态时直接读状态板源码 src/coding/status_board.py 与标签模块 src/evidence/labels.py每个值都有注释说明其存在的原因。更多架构细节可参考 docs/ARCHITECTURE.md能力全景见 docs/CAPABILITIES.md。四态状态表看似只是四个标签实则是 oh-my-hermes 把诚实写进了每一行界面——这也是它和其他 AI 编码插件最本质的差别。【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-hermes四态状态表深入：Plan·not run与Test·verified的本质区别
oh-my-hermes四态状态表深入Plan·not run与Test·verified的本质区别【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermesoh-my-hermes 是一款面向 Hermes Agent 的 All in one 插件集编码智能、长期记忆与模型优化的工作流于一体。它最硬核的设计就是证据优先的四态状态表除非亲眼看到工作发生否则绝不宣称工作已完成。这篇文章从状态表的两个极端——Plan · not run与Test · verified——切入帮你用最短时间看懂为什么计划就绪和验证通过之间隔着一条不可跨越的证据鸿沟。为什么需要四态状态表市面上大多数 AI 编码工具只有一种状态complete。但执行器说自己干完了和有人真的检查过结果是两回事把它们都写成完成正是误导的根源。oh-my-hermes 用两个正交的轴重新定义了状态阶段轴PhaseRoute→Plan→Code→Setup→Test→Review→Ship描述工作走到了哪一步置信度轴Confidencenot run、running、reported done、verified等描述 OMH真正知道了什么。两轴拼接后就得到了人读得懂的标签比如Plan · not run、Code · running、Test · verified。这个设计的完整源码在 src/evidence/labels.py注释里写得很直白Code单独一个词无法说明 OMH 是亲眼看着执行器跑完的还是仅仅为它写好了一份 prompt——而绝大多数情况恰好是后者。四态状态表速查一分钟看懂每行含义官方文档中的原表如下完整上下文见 README.md你看到的它意味着Plan · not runprompt 或 plan 已就绪。还没有任何东西运行过。Code · running执行器正在运行OMH 正盯着它。Code · reported done执行器自称完成了。没有人检查结果。Test · verified测试、review 或 CI 门禁确实通过了。底层的线协议值wire value从未改变prepared_not_observed对应not runcompleted对应reported done状态词表定义在 src/coding/status_board.py 的STATUS_VOCABULARY中。所有界面聊天、状态板、路由摘要、菜单栏共用同一套标签解析方不受影响。一个关键细节失败关闭fail closed任何无法识别的状态值都会保守地回落到not run而不是渲染成发生过的工作。换句话说OMH 宁可说没跑过也不会说跑过了。这是整个四态体系的信任基石。Plan · not run工作还没发生这是状态表的起点。Plan · not run表示路由、prompt、计划文件都已准备完毕处于ready to run的待命状态但进程还不存在没有任何一行代码被实际执行它对应的线协议值是prepared_not_observed——已准备、未观测到。你可以把它理解为工单已经打印好、放在了待办桌上但工人还没有拿起工具。 此时看到Plan · not run不要担心是不是卡住了它只是如实告诉你一切就绪尚未开始。Code · reported done自称完成 ≠ 检查通过这是整张状态表里最容易踩坑的一行。执行器executor报告我完成了OMH 只是观测到了这个声称从未观测到结果本身。reported done这个标签的设计刻意把声称者写进了标签里一个自我报告的单元和一个通过门禁的单元在界面上永远不会长得一样。这正是 src/evidence/labels.py 注释中强调的承重标签——如果两者渲染相同用户就无法区分自称干完和真的检查过了。Test · verified证据的终点站Test · verified是状态表中唯一代表检查通过的状态。要走到这一步必须满足一次真实的测试、review 或 CI 门禁实际运行并通过了验证凭据verification receipt只有在其版本、命令、环境与记录完全匹配时才会被复用。配套的技能 skills/omh-verification-gate/SKILL.md 更进一步当声称中带有无关联的 TODO/stub 标记、被压制且无原因的测试、或fixed / verified / passing这类没有命令证据支撑的措辞时验证门禁会直接拒绝完成并指出违规类别、具体片段和补救方式。️本质区别一句话总结维度Plan · not runTest · verified时态将来时——工作还没有发生过去时——工作已被观测发生证据强度零只有计划最高门禁实测通过你该做什么放心等待或检查路由是否被卡住可以放心进入下一阶段核心结论两者的区别不在进度条走了多远而在证据是否被观测到。前者是 OMH 在说我什么都没看到后者是 OMH 在说我亲眼看到它通过了。动手验证如何快速上手四态状态表安装 oh-my-hermes 后发起一次编码委派任务在 Hermes 终端的 HUD 中观察每条委派泳道的状态行模型、effort、轮次、token、成本都会实时刷新留意状态流转顺序Plan · not run→Code · running→Code · reported done→Test · verified注意reported done与verified之间的停顿那正是门禁在检查遇到异常状态时直接读状态板源码 src/coding/status_board.py 与标签模块 src/evidence/labels.py每个值都有注释说明其存在的原因。更多架构细节可参考 docs/ARCHITECTURE.md能力全景见 docs/CAPABILITIES.md。四态状态表看似只是四个标签实则是 oh-my-hermes 把诚实写进了每一行界面——这也是它和其他 AI 编码插件最本质的差别。【免费下载链接】oh-my-hermesAll in one plugin for Hermes Agent ⚚ the coding intelligence, a long-term memory system and model optimized workflow packages项目地址: https://gitcode.com/GitHub_Trending/ohm/oh-my-hermes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考