omh-ralph-driver

OMH Ralph Driver——用于经验证执行的协调者手册

当你是负责调度循环的协调者时，请与 omh-ralph 一起加载此技能。omh-ralph 由带角色标签的 workers（执行者／验证者／架构师）加载，涵盖每个任务的 delegate_task 调用中必须遵守的铁律。本技能涵盖你作为调度者要做的事：计划结构、迭代节奏、并行批处理、证据收集、验证者调度、违规处理、提交规范，以及最终的架构师审核关卡。

这两种技能面向不同读者，承担不同职责。不要将它们合并——工作者的上下文非常宝贵；调度者手册不应随每个子 Agent 一起传递。

本技能是 ralph 对应的 omh-ralplan-driver，后者是 ralplan（设计循环）的调度者手册。两者的关系一贯如此：每种方法都有工作者侧技能（在 delegate_task 中使用）和驱动者侧技能（由协调者在调度之间使用）。

何时使用 ralph，何时直接编写代码

以下情况使用 ralph：

• 你有一份包含 5 个或更多可独立验收任务的计划（来自 omh-ralplan 或手动编写）。
• 质量验证比耗时更重要——每个任务的输出都必须经过证据评定，后续任务才能基于其构建。
• 你希望在多个工作单元间设置清晰的检查点（避免上下文膨胀）。
• 有些任务彼此独立，可以并行批处理。

以下情况不要使用 ralph：

• 工作只有一个步骤，或显而易见，可以直接编写。
• 还没有计划——在调用 ralph 前先运行 omh-ralplan（如果目标显而易见，则先运行 omh-deep-interview）。
• 用户希望跳过验证（这种情况并不常见；通常意味着工作量小到可以直接完成）。

一次 ralph 运行的流程

iter 1: pick eligible tasks → dispatch executors (parallel where safe)
        → gather evidence → dispatch verifiers (parallel) → mark passes/fails
        → update state → release lock → exit

iter 2: re-invoke. Read state. Pick next batch. Same cycle.

...

iter N: all tasks pass → Step 7 final architect review → mark complete.

每轮迭代之间，协调者的工作是：选对批次，为每位执行者编写合适的上下文，收集正确的证据，解析验证者的判定，并决定是重试还是继续。

五步手册

1. 阅读计划，确认其符合 ralph 的要求

ralph 计划是一份编号任务清单，每项任务都包含：

• 清晰的标题。
• 足够精炼的说明，确保没有先前上下文的执行者也能实现。
• 可测试的验收标准。 ralph 的计划审核关卡会拒绝“实现已完成”这类笼统标准。
• 依赖关系（必须先完成哪些其他任务）。
• 涉及的文件（用于规划并行批次——见第 3 步）。

如果计划来自 omh-ralplan，它的结构适用于设计，而非 ralph。以方案中的“MV slice”部分为起点；你可能需要将其转换为 ralph 的任务格式。请按正确的任务结构编写 .omh/plans/ralph-plan.md（如果该计划源自某个特定的 ralplan 实例，则编写 .omh/plans/ralplan-<slug>.md）。

无需预先以同等详细程度编写每项任务——计划可以逐步扩展。ralph 的计划审核关卡会在首次调用时解析现有内容；执行期间发现的新任务通过状态中的 discovered: true 标记加入。

2. 为每次迭代选择合适的批次

每次 ralph 迭代只处理一个工作单元。一个“工作单元”可以是：

• 一个任务（当下一个符合条件的任务是唯一可执行的任务，或与其他符合条件的任务有共同的文件范围时）
• 一批 2-4 个任务（当多个互不依赖的任务符合条件，且涉及的文件集合互不重叠时）

符合条件 = passes: false 且所有依赖项均已满足。

涉及的文件集合互不重叠 = 任务不会修改相同文件。查看计划中的“Files to modify/create”列表。如果两个符合条件的任务都会修改 bin/janus-new-being，它们就不适合并行执行——该文件的修改只能由其中一个任务负责。如果一个任务涉及 migrations/lib.py，另一个涉及 bin/_lineage.py，则适合并行执行。

边缘情况——共享导入。 即使文件互不重叠，如果任务 A 编写了任务 B 要导入的辅助函数，也可能需要先完成任务 A。在编写计划时，应在依赖声明中明确这一点；如果遗漏，任务 B 的执行器会在任务进行中指出这项依赖。

合适的批次大小。 2-4 个任务。同一批次中安排五个或更多任务，会让你自己的上下文窗口难以处理执行器报告，并分派验证器。

3. 为执行器分派充足的上下文

每个执行器都会获得一个全新的子 Agent。子 Agent 不会记得之前的迭代、对话或任务。分派时应提供它们所需的全部信息。

执行器分派上下文必须包含：

• 项目根目录和分支。 使用绝对路径，不要使用相对路径。
• 先前状态。 之前的迭代中已完成哪些任务、目前存在哪些文件，以及有哪些辅助函数／库可供导入。
• 先前任务的相关经验。 提供执行器需要遵循的注意事项、命名约定和架构选择。
• 任务本身。 完整标题、描述和验收标准。
• 必读内容。 规范设计、先前任务的输出，以及可供参照的类似兄弟任务的绝对路径。
• TDD 指示。 先编写失败的测试，确认测试失败后再实现，确认测试通过后运行完整测试套件并提交。每次执行器分派都必须明确写出。
• 提交元数据。 作者身份、提交消息格式、分支。
• 请勿修改 。 并行批次中这一点至关重要。参见下文 P3。

在目标中使用 [omh-role:executor] 标记——OMH 插件会通过 pre_llm_call 钩子自动注入执行器角色提示词。不要手动内联角色文本。

执行器 goal 字段的完整模板——包含 TDD 指示、了解兄弟任务的禁止修改要求、提交元数据，以及针对不同失败类别的重试变体——位于 references/executor-goal-template.md。调整其中的变量，保留模板结构。

4. 在分派验证器前，使用 omh_gather_evidence 收集证据

所有执行器完成后，使用 omh_gather_evidence 运行项目实际的测试／构建／lint 命令。这会生成结构化的 {results, all_pass, summary} 对象，供验证器据此评估。

重要： 验证器不会自行运行证据收集。证据收集应由编排器完成，这样你就能在验证器读取执行器的报告前，确认其声明与实际情况相符。

允许列表注意事项。 omh_gather_evidence 会根据令牌前缀允许列表检查命令（~/.hermes/plugins/omh/config.yaml → evidence_tool.allowlist_prefixes）。常见的项目测试命令，例如 uv run --with pytest --with pyyaml -m pytest，与 uv run pytest 不匹配，因为 --with 会破坏前缀匹配。可以选择：

• 使用匹配的前缀：uv run pytest <args>（首选——将 pytest 保留为项目开发依赖，这样就不需要 --with pytest）。
• 在 OMH 配置中添加自定义前缀。
• 使用项目本地脚本包装命令。

如果 gather_evidence 拒绝执行命令，表现为 exit_code: -1, output: "Command not in allowlist"。分派验证器之前，请重新构造命令。

5. 并行派发验证器（按任务批量处理）

对于每项已完成的任务，派发一个验证器子 Agent，并提供：

• [omh-role:verifier] 标记（会自动注入验证器角色提示词）。
• 任务的验收标准（让验证器依据规范评分，而不是依据执行者对规范的理解）。
• 完整的证据输出（验证器 MUST 看到真实的测试结果，而不是转述的成功声明）。
• 要检查的文件路径。
• 超出“测试通过”范围的具体关键检查（例如：“验证不匹配标志的检查是否发生在任何文件系统写入之前——如果不是，带部分标志的调用会破坏状态”）。

验证器通过批量 delegate_task(tasks=[...]) 并行运行——与 Round 2 ralplan 评审一样节省实际耗时。

验证器会返回以下结果之一：

• APPROVE / PASS — 任务的 passes 标志变为 true。
• REQUEST_CHANGES / FAIL — 记录判定结果，根据反馈重试执行者。跟踪违规次数（见下文 P5）。

验证器 goal 字段的完整模板——包括逐字提供验收标准的要求、粘贴证据的格式、同级任务边界检查、违规分类以及判定示例——见 references/verifier-goal-template.md。

陷阱（P1–P10）

这些是 ralph 派发者容易陷入的失败模式。编号用于交叉引用；保留缺号供未来补充。

P1 — 计划必须符合 ralph 的形态，而不是设计文档的形态

omh-ralplan 会生成一份 stance.md——一份设计文档。Ralph 需要的是一份带有可测试验收标准的任务列表。

如果直接让 ralph 处理 stance，它的规划门要么会进行较弱的解析（提取看起来像任务的编号章节），要么会直接拒绝。先将 stance 的 MV 切片转换为规范的 ralph 计划。

转换过程是机械性的：

• Stance 的 MV 切片条目 → ralph 任务（一项对应一个任务）。
• Stance 的测试支持项 → 任务验收标准（stance 中明确给出的内容应原样保留）。
• Stance 中的“depends on”描述 → 任务的 dependencies: 字段。
• Stance 的文件路径 → 任务的 files: 列表（用于并行批次规划）。

将 ralph 计划写入 .omh/plans/ralph-plan.md 或 .omh/plans/ralplan-<slug>.md。Ralph 的规划门可以找到任一文件。

转换示例（来自 2026-04-27 的 janus 运行）。 Stance 的 “MV slice plan”部分列出了 13 项工作，分布在 NOW（约 3.5 小时，在下一次配置前捕获 lineage）／NEXT（+72 小时，更新工具）／DEFERRED（后续版本）。最终的 ralph 计划将每项工作都写成如下形态的任务：

### Task 4 — bin/janus-new-being: version stamp + seed-history snapshot

**Files to modify:**
- `bin/janus-new-being`

**Files to create:**
- `bin/tests/test_janus_new_being_lineage.py`

**Description:**
Patch `bin/janus-new-being` provisioning logic to write lineage data
per the stance's NOW slice item 2. After successful provisioning,
write `<profile>/.janus/version`, snapshot rendered template + plugin
tree to `<profile>/.janus/seed-history/v1/` via post-write disk-read,
compute MANIFEST with content hashes per file...

**Acceptance criteria (verbatim from stance test affordance):**

    def test_provision_writes_v1_lineage(tmp_path):
        profile = tmp_path / "alice-janus"
        # ... provision invocation ...
        assert (profile / ".janus" / "version").read_text().strip() == "v1"
        seed = profile / ".janus" / "seed-history" / "v1"
        assert (seed / "SOUL.md").exists()
        ...

**Dependencies:** none (Task 5 extends, but doesn't conflict)

让这套方法奏效的转换准则：

1. 验收标准原样取自 stance。 Stance 写明 test_provision_writes_v1_lineage_and_gh_config 测试通过时，ralph 计划就使用该确切的测试名称。这样，执行者会编写 stance 指定的测试，验证者也会依据 stance 自身的契约评分——不会因转述而产生偏差。

2. 明确列出涉及的文件。 每个任务的 files: 都准确列出要创建和修改的文件。这是之后进行并行批次规划（P2）的基础：编排器可以读取这些列表并检查触及范围是否互不重叠，而不必从描述文字中重新推导。

3. 根据共享的具体产物推断依赖关系，而不只看描述文字。 Stance 说 MANIFEST 格式是在 Task 4 中编写的；Task 8（包含 hash_equals_ancestor 的 lib.py）需要读取该格式。因此，Task 8 的 dependencies: [task-4] 是根据共享的文件格式推断出来的，而不是依据“Task 8 必须在 Task 4 之后执行”这句话。

4. 将 NOW／NEXT／DEFERRED 纳入优先级排序。 NOW 切片中的所有任务都设为 priority: 1 或 priority: 2（优先级为 2 的任务专门用于把关后续并行批次）。NEXT 任务设为 3-5。DEFERRED 条目不会作为 ralph 任务出现——它们不属于本次运行的工作范围。

5. 将每个任务的测试支持项展开为完整的 pytest 函数签名。 Stance 通常只会列出测试名称并简要说明形式；ralph 任务则会给执行者提供确切的函数名称和行为，因此他们不必重新推导。

转换本身就是一个关键步骤。 转换草率，无论之后的编排多么严谨，运行结果都会很草率。ralph 计划就是执行者实现、验证者据以评分的契约；如果计划含糊，循环产出的工作也会含糊。

对于包含 10 个以上任务的计划，预留 30-60 分钟进行转换。输出文件是 ralph 规划门解析的文件；运行期间，你不会再直接查看 stance。

P2 — 在派发前识别可并行的安全批次，而不是派发过程中

在每轮开始时，遍历所有符合条件的任务（passes: false 且依赖已满足）。对每一对任务，检查其触及范围是否互不重叠。标记可安全并行的任务集合，并通过一次批量 delegate_task 派发。

如果先派发一个任务，之后才考虑其他任务能否并行执行，那么这一轮节省时间的机会就已经错过了。正确的决策时机是在每轮开始时，此时你本来就在读取状态。

合适的批次大小是 2-4。依赖关系紧密时选 2；有多个互不依赖的任务时选 4。5 个以上会让编排器自身的上下文被执行者报告和并行验证者派发所挤占。

P3 — 在并行派发上下文中明确写明“DO NOT modify ”

派发并行执行器时，每个共享文件只能由一个任务负责。其他执行器必须导入（只读），但不得修改该文件。

在每个执行器的派发上下文中明确写出这一点：

DO NOT modify migrations/lib.py during this task — Task X owns that change. Import what you need; if a function isn't there yet, fall back to inline implementation that matches Task X's expected signature so they converge cleanly when both commits land.

没有这条指示，并行执行器就会争抢共享文件，产生冲突提交。有了这条指示，它们就会遵守边界，只提交各自的工作。

这条指示还应告诉每个执行器在提交前取消暂存其他任务的文件。否则，git add -A 会把相邻任务尚未提交的工作也一并纳入——参见 P9。

P4 — 在每个执行器的派发上下文中传递经验教训

每次迭代都会产生经验教训（易出错之处、命名约定、有效或无效的模式）。除非将这些内容写入派发上下文，否则下一次迭代的执行器不会看到它们。

在 ralph 状态的 completed_task_learnings 字段中维护每次迭代的经验教训列表，并在后续每个执行器的派发上下文中加入相关内容。

值得传递的示例：

• “TEST-INFRA：切勿用 hash(content) & 0xffff 为 tmpdir 命名——随机哈希值加上较小的模数会带来冲突风险。”
• “删除已跟踪文件时，使用 git rm -r（而非 rm -rf），以保留 git 历史记录。”
• “bin/janus-new-being 使用 uv shebang，没有 .py 后缀；新的 bin/* 脚本也应遵循相同模式。”
• “bin/_lineage.py 中的 classify() 函数提供的是判定标准（路径前缀模式 + Class-B 精确集合），而不是枚举列表。应复用它，不要重复定义分类规则。”

这些经验会通过派发上下文压缩并传递下去。omh-ralph 状态中的 completed_task_learnings 是权威存储位置。

P5 — 按类别区分执行器问题记录

验证器返回 REQUEST_CHANGES 时，原因属于以下一种：

1. 测试基础设施问题 — 测试本身有缺陷（例如 hash() & 0xffff 导致路径冲突、夹具竞争或测试运行器配置问题）。实现可能是正确的；只需修复测试。

2. 误读规范 — 执行器实现的内容与验收标准要求不同。需要修正实现。

3. 实现缺陷 — 执行器实现了正确的功能，但存在实际缺陷（逻辑错误、遗漏边界情况或安全问题）。

这三类问题的修复方式各不相同。测试基础设施问题的重试应只修改测试文件。误读规范的重试需要新的上下文，强调规范的实际要求。实现缺陷的重试则需要明确指出失败用例。

更新状态时，在错误指纹中标记问题类别：

"error_fingerprints": [
    {"category": "test-infra", "error_key": "hash-collision-in-tmpdir-naming", "round": 1},
    ...
]

（根据 omh-ralph 第 6 步）当相同的 (category, error_key) 重复三次时，3 次熔断机制就会触发。按类别标记可避免测试基础设施问题掩盖实际缺陷（或反之）。

P6 — 验证器必须读取真实证据，而非执行器的说法

派发验证器之前，务必先运行 omh_gather_evidence。将证据输出包含在验证器的派发上下文中。

如果跳过证据收集，验证器只会读取执行器的报告（“状态：已完成；5 项测试通过；提交 X”），没有可供评判的真实依据。执行器报告有时并不准确——可能是执行器确实遗漏了内容，也可能是测试因错误的原因而通过（例如，路径冲突导致崩溃，致使关键断言根本没有运行——参见本技能中的示例）。

由编排器运行证据收集的模式，才是让 ralph 验证可信的关键。

P7 — 最终架构师审查（Step 7）是合并关卡

所有任务通过后，ralph 的 Step 7 会调度一位架构师，根据原始计划／立场审查完整实现。

架构师会进行整体审查：

• 架构忠实度（实现是否遵循了设计？）
• 原则一致性（承载关键作用的原则是否体现在机制中，而不只是出现在文字说明里？）
• MV 切片就绪度（用户今晚是否真的能运行它？）
• 架构接缝（有哪些粗糙之处，哪些已明确延期？）
• 提交规范（git 历史是否足够干净，可以合并？）
• 测试支持缺口

这是协调器在交付可用于 PR 的分支之前的最终关卡。架构师可以给出以下结论：

• APPROVE — 批准合并。
• APPROVE_WITH_PROVISO — 合并前需要进行少量可折叠的补充（通常为 1-3 项明确列出的内容）。
• REQUEST_CHANGES — 存在无法交付的内容；新增任务并标记为 discovered: true。

将架构师的审查写入设计目录中的 <orchestrator>-architect-review.md（协调器自身的迭代级审查文件为 <orchestrator>-review.md；架构师审查是单独的产物）。

架构师最终审查的 goal 字段完整模板——包括差异范围检查、端到端 MV 切片追踪、原则触发审计、提交规范检查、结论校准指南以及已完成的审查示例（APPROVE_WITH_PROVISO 和 REQUEST_CHANGES）——位于 references/architect-final-review-template.md。

P8 — 每次操作后更新状态；每次退出时释放锁

根据 omh-ralph 的 Step 0/Step 8，状态文件 .omh/state/ralph--<instance_id>.json 和 .omh/state/ralph-tasks--<instance_id>.json 用于跟踪运行情况。.omh/state/ralph--<instance_id>.lock 中的锁可防止并发会话同时操作同一计划。

规范：

• 在迭代开始时获取锁（Step 0）。
• 每次执行器完成、每次验证器给出结论、每次任务状态转换后，都更新状态。
• 在每个退出点释放锁——成功、阻塞、取消、达到最大迭代次数、异常。封装迭代主体，确保即使发生错误也会触发解锁。

不要留下陈旧锁。如果锁由已退出的进程持有，下次调用 ralph 时会通过 held_by 显示这一情况——应提供取消并重试的选项，不要悄悄抢占锁。

P9 — 并行写入时的提交规范

三个执行器在协调器的一轮处理中向同一分支写入时，会看到彼此的部分状态（已提交的内容），但看不到彼此尚未提交的工作。如果某个执行器使用 git add -A 暂存提交内容，可能会把仍在进行中的其他执行器文件一并纳入。

并行调度执行器时的规范：

1. 要求每个执行器明确使用 git add 添加自己的特定文件，而不是使用 git add -A。文件名应与任务的 files: 字段一致。

2. 要求每个执行器在提交前检查 git status：如果出现其他任务的文件且尚未暂存，不要将其纳入提交。常见的同级任务文件包括：未跟踪的 init.py 存根、未跟踪的测试文件、正在编辑的 RELEASES.yaml。

3. 接受有时仍会发生内容误纳入。 发生时可以补救：通过交互式变基将范围过大的提交与遗漏的提交压缩在一起，或者添加后续历史说明提交来解释边界。

4. 在迭代日志中记录误纳入情况。 如果发现执行器报告“纳入了预先存在的未跟踪文件”，请将其标记出来，供架构师在 Step 7 检查提交规范。

这是经过惨痛教训才总结出的做法：有一次运行中，task-11 的提交通过 git add -A 吸收了 task-12 预期提交内容的约 60%。测试仍然通过；交付物也正确；但提交边界含糊不清。架构师将此列为可折叠的附加条件。

P10 — 插件/工具变更时，恢复与重启很重要

如果用户在不同迭代之间更改了插件或工具集 （添加工具、启用插件、修改 config.yaml），工具不会在当前会话中 即时注册，而是在 Agent 启动时注册。

如果用户说“我改了配置，现在可以用新工具了吗？”：

• 会话需要完全重启，而不只是点击“恢复”按钮 （某些聊天界面在“恢复”时会复用同一个 Agent 进程）。
• 检查函数 schema 进行验证——如果其中没有新工具，说明没有重新启动。
• 最快的确认方法是，如果这是与 OMH 相关的插件，则调用 omh_state(action="check", ...)——如果工具报错 “function not found”，说明插件尚未加载。

如果重启后工具确实仍未显示，请参阅相关技能 enabling-hermes-plugin-in-profile，了解完整的插件安装诊断流程。

状态管理速查表

# Step 0: check + lock
omh_state(action="cancel_check", mode="ralph", instance_id=instance_id)
lock = omh_state(action="lock", mode="ralph", lock_key=instance_id,
                  session_id=session_id, holder_note="...")

# Step 1: read state (or trigger planning gate)
state = omh_state(action="read", mode="ralph", instance_id=instance_id)
tasks = omh_state(action="read", mode="ralph-tasks", instance_id=instance_id)

# Step 2: planning gate (only on first invocation)
omh_state(action="write", mode="ralph-tasks", instance_id=instance_id, data={
    "tasks": [{"id": "task-1", "title": "...", "description": "...",
               "acceptance_criteria": "...", "priority": 1,
               "dependencies": [], "passes": False, "files": [...]}, ...]
})

# Step 3-5: per-iteration execution
# (delegate_task for executors, omh_gather_evidence, delegate_task for verifiers)

# Step 8: update state, exit
omh_state(action="write", mode="ralph", instance_id=instance_id, data={
    "active": True, "phase": "execute", "iteration": N, ...,
    "completed_task_learnings": [...]
})
omh_state(action="unlock", mode="ralph", lock_key=instance_id, session_id=session_id)

编排器任务完成的标准

• ralph-tasks 状态中的所有任务都标记为 passes: true。
• 第 7 步最终架构师审查结果为 APPROVE 或 APPROVE_WITH_PROVISO，并已纳入附带条件。
• 已写入 <orchestrator>-architect-review.md。
• .omh/logs/ralph-progress.md（或对应领域的文件）记录了迭代过程、遇到的故障次数以及关键经验。
• 状态标记为 phase: complete、active: false。
• 已释放锁。
• 用户可以从该分支创建 PR。

实例（2026-04-27，janus 迁移）

13 个任务的计划，5 次迭代，共出现 1 次故障，最终结果为 APPROVE_WITH_PROVISO。

• 迭代 1：3 个独立任务并行执行（RELEASES.yaml、AGENT.md 补丁、退役 janus-migration 技能）。全部 APPROVE。
• 迭代 2：单独执行 task-4（谱系信息捕获，关卡 5/6/8）。第 1 次故障是测试基础设施的哈希冲突。重试后 APPROVE。
• 迭代 3：3 个任务并行执行（gh-config、backfill-lineage、lib.py）。每个任务的派发说明都写明“DO NOT modify bin/_lineage.py — Task X owns it.”。本轮零故障。
• 迭代 4：3 个任务并行执行（janus-migrate 技能、janus-update CLI、pytest 测试框架）。零故障。
• 迭代 5：3 个任务并行执行（boot-context 接口、janus-contribute 存根、v2 迁移）。零故障。**一个提交规范问题：**task-11 通过 git add -A 将 task-12 的文件一并纳入。测试通过；已标记供架构师审查。
• 第 7 步：架构师给出 APPROVE_WITH_PROVISO，包含两个可合并处理的事项 （提交规范问题的 rebase + 缺少 migrations/README.md）。

最终结果：测试数从 0 增至 132，共提交 14 次实现改动。让 5 轮并行迭代中的 4 轮做到零故障的纪律是 P3 （“DO NOT modify ”）+ P4（前向经验编码）+ P6（编排器运行证据）。唯一一次故障出在 P5 测试基础设施上， 之后已顺利恢复。

维护自己的运行日志

每次 ralph 运行中出现新的陷阱或意外模式，都值得记录。维护一张简短的表格：

日期	领域	迭代次数	故障次数	意外情况	对此技能的修订

不要让此技能变成会话日志。请在其他地方记录 （你的底层环境、项目笔记、wiki）。只有当某个陷阱具有足够普遍的参考价值、值得让未来的编排器学习时，才修订此技能。

相关技能

• omh-ralph — 工作人员侧的规范，在每个 delegate_task 内加载。编排者必须阅读（一次即可， 以了解工作人员在做什么），但不会加载到工作人员 上下文中（它们会通过插件自动注入角色提示词）。
• omh-ralplan-driver — 设计循环的调度手册。如果尚无计划， 请在 ralph 之前使用。它也是驱动侧技能，但用于不同的方法 （共识设计与验证执行）。
• omh-ralplan — 工作人员侧的设计规范。仅在 delegate_task 内使用，并带有 [omh-role:planner|architect|critic] 标记。
• enabling-hermes-plugin-in-profile — 用于插件安装诊断流程的 同类技能。如果因 OMH 工具不在函数架构中而导致 ralph 运行受阻， 请引用此技能。
• subagent-driven-development — 未提供 OMH 插件时，用于计划的 更简单方案。架构模式相同，但不包含状态机制、角色注入或证据工具。

不可遗漏的内容

最关键的一点：运行证据的是编排者，而不是验证者。 始终要在 分派验证者之前调用 omh_gather_evidence。在验证者的上下文中 附上真实的测试输出。这是 ralph 的判定值得信赖的关键；否则， 就会出现两层执行者自我报告。

其次：“不要修改 ”这一纪律让每批 3 个并行任务得以顺利运行。 每次分派并行执行者时，都必须指出哪些文件属于其他执行者。否则， 并行任务会争用共享文件，一个任务的提交可能会包含另一个任务的工作。

第三：违规有不同类别。 测试基础设施问题 ≠ 误解规范 ≠ 实现错误。请标注类别；连续 3 次触发的断路器应针对同一 类别触发，而不只是同一任务。混淆类别会导致误报而中止 （更糟的是，也可能导致漏报，让真正的错误伪装成测试基础设施问题）。

第四：编排者应处于“迭代之间”的视角， 而不是深入某个具体任务。每次调用只处理一个任务这条铁律， 正是为了让你保持这种视角——选择任务批次、传递经验教训、 收集证据、分派验证者，以及决定重试还是继续。深入任务执行， 你就会变成执行者，整个循环的价值也会荡然无存。