ralph

[RALPH - 迭代 {{ITERATION}}/{{MAX}}]

您之前的尝试未能输出完成承诺。请继续处理该任务。

<Use_When>

• 任务需要保证完成并通过验证（而不仅仅是“尽力而为”）
• 用户说“ralph”、“不要停”、“必须完成”、“完成这个”或“继续直到完成”
• 工作可能跨越多次迭代，并需要在重试时保持持久性
• 任务受益于结构化的 PRD 驱动执行，并需要审查者签署确认 </Use_When>

<Do_Not_Use_When>

• 用户希望从想法到代码的完整自动化管道——请改用 autopilot
• 用户希望在承诺之前进行探索或规划——请改用 plan 技能
• 用户希望快速的一次性修复——直接委托给执行代理
• 用户希望手动控制完成——直接委托给执行代理
• 用户已有活跃的 Claude Code /goal 并且只希望监控该原生目标循环——明确采用现有的 /goal 或仅使用基于工件的 Ultragoal 笔记，而不是启动 Ralph 作为竞争的持久化循环 </Do_Not_Use_When>

<Why_This_Exists> 复杂任务经常无声无息地失败：部分实现被声明为“完成”，测试被跳过，边缘情况被遗忘。Ralph 通过以下方式防止这种情况：

1. 将工作分解为具有可测试验收标准的离散用户故事（prd.json）
2. 逐个故事迭代，直到每个故事都通过
3. 在多次迭代中追踪进度和学习成果（progress.txt）
4. 在完成前要求根据特定验收标准进行新的审查者验证 </Why_This_Exists>

<PRD_Mode> 默认情况下，ralph 以 PRD 模式运行。当 ralph 启动时，如果不存在 prd.json，则会自动生成一个脚手架 prd.json。活跃的临时 PRD 状态在会话作用域内的 .omc/state/sessions/{sessionId}/prd.json 中（当会话 ID 可用时）；传统的项目级 prd.json / .omc/prd.json 文件会在启动时作为迁移输入读取。

启动门控： Ralph 在启动时始终初始化和验证 prd.json。为了向后兼容，提示中的传统 --no-prd 文本会被清理，但它不再绕过 PRD 创建或验证。

去 AI 味（Deslop）选择退出： 如果 {{PROMPT}} 包含 --no-deslop，则完全跳过强制性的审查后去 AI 味（deslop）清理步骤。仅当该运行的清理范围明确排除时才使用此选项。

审查者选择： 在 Ralph 提示中传递 --critic=architect、--critic=critic 或 --critic=codex 以选择该运行的完成审查者。architect 是默认值。

陈旧状态检测与调解 (#3669)： 如果 PRD 因异常/非步骤 8 退出（崩溃、强制终止、在 /oh-my-claudecode:cancel 之前取消、会话结束）而未完成，Ralph 会在启动/恢复、延续上下文以及会话结束时显示明确的 [陈旧 PRD 警告]，其中包含未完成计数、上次修改年龄和陈旧指针信号（PRD branchName 已合并/消失）。完成状态绝不仅仅从 PR/分支/合并状态推断；git 状态仅作为警告信号。一个故事仅当 PRD 配置了可观察证据并且所有检查都通过时，才自动调解为 passes: true：

{
  " reconciliation": {
    "staleAfterMs": 7200000,
    "observableChecks": {
      "US-001": [
        { "type": "fileContains", "path": "src/landed.ts", "pattern": "LANDED_SYMBOL" },
        { "type": "gitGrep", "ref": "origin/dev", "pattern": "LANDED_SYMBOL" }
      ]
    }
  }
}

检查类型：fileExists / fileContains（工作树）和 gitGrep（特定引用上的内容——这是“通过主干上的内容验证”，而非 PR 状态）。没有配置检查的故事永远不会被自动标记。已调解的故事保持 architectVerified: false，并且在步骤 8 之前仍然需要步骤 7 的审查者验证；每个决定都会附加到 prd-reconciliation.jsonl 审计日志中，并总结在故事笔记中。 </PRD_Mode>

<PRD_Criterion_Amendments> 验收标准是 PRD 的完成权威：步骤 4 验证每个 ACTIVE 标准，步骤 7 根据它们进行审查。一个标准只能通过证据保留的修正路径来停止约束——绝不能通过静默删除或通过“满足”一个已被测量反驳的标准。

当实现证明一个标准在经验上是错误的时（例如，调度简报中的计数错误），请修正它：

1. 替换被反驳的标准为测量后的修正，或者当没有替代标准适用时取代它。
2. 在故事的 criterionAmendments 账本中记录修正。原始标准文本会逐字保留（绝不重写或删除），同时附上：
   • kind: "replaced" 或 "superseded"
   • original: 逐字记录的被反驳标准（记录修正时仍必须处于活跃状态）
   • replacement: 修正后的标准（仅限 replaced）
   • reason: 原始标准不再约束的原因
   • evidence: 反驳它的有限测量（例如“列举了 12 个设置器，而不是 16 个：...”）
   • authority: 进行修正的人（使用 ralph 会话 ID）
   • timestamp: ISO 8601 时间戳
3. 然后完成检查仅验证 ACTIVE 的标准；账本保留审计跟踪，以便审查者了解原始标准为何不再约束。

规则：

• 没有有限证据、原因、权威或时间戳的修正无效——PRD 在读取时以失败关闭，而不是被静默削弱。
• 仍然活跃的原始标准不能被修正；一个原始标准只能被修正一次。
• 编程路径：amendCriterion(dir, storyId, { original, replacement, reason, evidence, authority }) 和 supersedeCriterion(dir, storyId, { original, reason, evidence, authority })。
• 手动编辑的 PRD 必须保持相同的不变量；矛盾的账本（原始标准仍处于活跃状态，或修正两次）会使 PRD 无效。
• 这不是一个削弱目标的工具：它的存在是为了让“测量结果与计划不一致”的情况向测量结果靠拢，同时循环不会失去其约束力。 </PRD_Criterion_Amendments>

<Execution_Policy>

• 同时触发独立的代理调用——永远不要顺序等待独立的工作
• 对长时间运行的操作（安装、构建、测试套件）使用 run_in_background: true
• 在委托给代理时始终显式传递 model 参数
• 在第一次委托前阅读 docs/shared/agent-tiers.md 以选择正确的代理层级
• 交付完整的实现：不缩小范围，不部分完成，不删除测试以使其通过
• 如果提到了 Claude Code /goal，则仅将其视为原生会话循环的交接/证据源，并使用确定性冲突策略 refuse、adopt_existing 和 artifact_only，而不是非确定性的警告处理。Ralph 仍然是本次运行的 OMC 循环权威；不要声称 /goal 独立运行了测试或读取了文件，也不要把评估者的成功视为 Ralph 审查者验证的替代。 </Execution_Policy>

2. 选择下一个故事：读取活跃的 PRD 文件，并选择 passes: false 且优先级最高的故事。这是您当前的焦点。

3. 实现当前故事：

   • 在适当的层级委托给专家代理：
     • 简单查询：LOW 层级 (Haiku) ——“此函数返回什么？”
     • 标准工作：MEDIUM 层级 (Sonnet) ——“为此模块添加错误处理”
     • 复杂分析：HIGH 层级 (Opus) ——“调试此竞争条件”
   • 如果在实现过程中发现了子任务，将它们作为新故事添加到活跃的 PRD 文件中
   • 后台运行长时间操作：构建、安装、测试套件使用 run_in_background: true

4. 验证当前故事的验收标准： a. 对于故事中的每个活跃验收标准，使用新证据验证其是否满足 b. 运行相关检查（测试、构建、lint、类型检查）并读取输出 c. 如果实现证明标准在经验上是错误的（测量结果反驳了它），则不要将故事标记为完成，也不要静默删除或削弱标准。相反，通过 <PRD_Criterion_Amendments> 中描述的证据保留路径进行修正：在活跃标准中替换或取代它，并将原始标准（逐字）连同 kind、reason、evidence、authority 和 timestamp 附加到故事的 criterionAmendments 账本中。然后继续验证剩余的 ACTIVE 标准 d. 如果任何活跃标准未满足且未修正，则继续工作——不要将故事标记为完成

5. 将故事标记为完成： a. 当所有活跃验收标准都通过验证时，创建绑定版本的完成声明：设置 passes: true，并将 completionCriteriaRevision 设置为故事当前的 governingCriteriaRevision。不要设置 architectVerified；审查者的批准将单独绑定此项。 b. 在 progress.txt 中记录进度：实现了什么，更改了哪些文件，为未来迭代吸取的经验教训 c. 将发现的任何代码库模式添加到 progress.txt

6. 检查 PRD 完成状态： a. 读取活跃的 PRD 文件——所有故事都标记为 passes: true 了吗（并且没有未验证的活跃标准）？ b. 如果未全部完成，则返回步骤 2（选择下一个故事） c. 如果全部完成，则继续执行步骤 7（审查者验证）

7. 审查者验证（分层，针对验收标准）：

   • <5 个文件，<100 行，包含完整测试：STANDARD 层级最低要求（architect-medium / Sonnet）
   • 标准更改：STANDARD 层级（architect-medium / Sonnet）

   • 20 个文件或安全/架构更改：THOROUGH 层级（architect / Opus）

   • 如果使用 --critic=critic，则使用 Claude critic 代理进行批准检查
   • 如果使用 --critic=codex，则运行 omc ask codex --agent-prompt critic "..." 进行批准检查。Codex 批评者的提示必须包括：
     1. 来自 prd.json 的完整验收标准列表以供验证
     2. 指示评估实现是否最优——不仅正确，而且是否存在实现遗漏的更有意义的方法（更简单、更快、更可维护）
     3. 指示审查所有与更改相关的代码（调用者、被调用者、共享类型、相邻模块），而不仅仅是直接修改的文件
     4. ralph 会话期间更改的文件列表以供上下文参考
   • Ralph 最低要求：即使对于小更改，也至少使用 STANDARD 层级
   • 选定的审查者根据 prd.json 中的特定验收标准进行验证，而不是模糊的“完成了吗？”
   • 批准后：在同一轮中立即执行步骤 7.5。不要暂停向用户报告裁决——报告仅在步骤 8（/oh-my-claudecode:cancel）或拒绝（步骤 9）时进行。将批准的裁决视为报告检查点是一种礼貌性停止的反模式。

7.5 强制性去 AI 味（Deslop）清理步骤（在步骤 7 批准后无条件运行，除非 {{PROMPT}} 包含 --no-deslop）：

• 通过 Skill 工具调用 ai-slop-cleaner 技能：Skill("oh-my-claudecode:ai-slop-cleaner") ——它是一个 Skill，而不是代理。如果您错误地通过 Task(subagent_type="oh-my-claudecode:ai-slop-cleaner") 调用它，OMC 的 PreToolUse 钩子会拒绝该调用并显示正确的 Skill 工具标识符；不要替换为名称相似的代理。以标准模式（非 --review）在仅当前 Ralph 会话期间更改的文件上运行。

• 保持范围限定在 Ralph 更改的文件集内；不要将清理步骤扩大到不相关的文件。

• 如果审查者批准了实现但 deslop 清理步骤引入了后续编辑，请在继续之前将这些编辑保留在同一更改文件范围内。

  7.6 回归重验证：

• 在 deslop 清理步骤之后，为 Ralph 会话重新运行所有相关的测试、构建和 lint 检查。

• 读取输出并确认后 deslop 回归运行实际通过。

• 如果回归失败，则回滚清理器的更改或……

[为翻译而截断]