尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

OmX 0.21 技能迁移实战指南:从 `$ralph` 循环模式迁移到 `$ultragoal` 多目标工作流

OmX 0.21 技能迁移实战指南:从 `$ralph` 循环模式迁移到 `$ultragoal` 多目标工作流 OmX 0.21 技能迁移实战指南从$ralph循环模式迁移到$ultragoal多目标工作流【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex在 OmXOh My codeX0.21 版本中$ralph技能已被正式移除取而代之的是$ultragoal。omx ralph命令行与 Ralph 持久化运行时本身并未受影响但技能层Skill Layer的$ralph入口已被统一收编为日落桩Sunset Stub指向功能更强的$ultragoal。本指南以 skills/ralph/SKILL.md 为核心骨架结合 skills/ultragoal/SKILL.md、release-notes-0.21.0.md 以及src/ultragoal、src/cli/ultragoal.ts等源码完整讲清为什么移除、如何迁移、$ultragoal的完整操作流、显式转向机制与最终完成闸门帮助你用更少的心智负担完成从单目标死循环到多目标持久化的升级。一、为什么$ralph被移除日落桩设计1.1 官方移除声明skills/ralph/SKILL.md 全文仅保留了最核心的迁移声明移除时间OMX 0.21替代方案改用$ultragoal迁移命令将$ralph替换为$ultragoal任务传递格式Task: {{ARGUMENTS}}。这并非简单的删功能而是一次能力等价迁移Ralph 的 loop-until-done循环直到完成行为本质上就是一次单目标的 ultragoal 运行。$ultragoal继承了 Ralph 的持久化与已验证完成承诺并在此基础上大幅扩展。1.2 统一的日落桩解析器从源码角度看$ralph的移除并不是散落在各处的硬编码报错而是由 src/hooks/sunset-stub.ts 中唯一的 SSOT单一事实来源统一收编。该文件中的REMOVED_SKILLS表记录了全部 25 个被移除技能的替换映射其中ralph的映射为ralph: { replacement: $ultragoal, message: Skill $ralph has been removed. Use $ultragoal instead. The omx ralph CLI and ralph persistence runtime are unaffected., },formatRemovedSkillError()会在命中移除表时输出包含removed与use字样的清晰报错便于 CI 与用户识别。这意味着技能层失效调用$ralph会硬报错并提示改用$ultragoalCLI 层不受影响omx ralph仍可运行其持久化模式依旧可用详见 src/cli/ralph.ts 中RALPH_HELP的说明删除链路清晰0.21.0 发布说明docs/release-notes-0.21.0.md明确将$ralph → $ultragoal列为带迁移桩的移除技能之一。1.3 与 Team 的边界回归在 0.21 之前omx team ralph曾作为内置的联动工作流存在但这一设计带来了大量桥接胶水代码linked-ralph-bridge、notify-hook 终端同步、清理/关闭特例等。docs/prs/dev-deprecate-team-ralph.md 记录了该 PR 的完整动机将team与ralph拆分为两个独立工具omx team ralph ...现在会以显式弃用错误拒绝用户必须分别使用omx team ...与omx ralph ...。这也与$ralph技能日落保持一致技能层统一导向$ultragoal而 CLI 层的 ralph 持久化运行时保持独立。二、$ultragoal是什么Ralph 的能力超集skills/ultragoal/SKILL.md 的定位是在 Codex goal 模式工件之上创建并执行仓库原生的持久化多目标计划Create and execute durable repo-native multi-goal plans over Codex goal mode artifacts。2.1 适用场景在以下任一场景中激活$ultragoalultragoal、create-goals、complete-goals持久化的多目标规划基于 Codex/goal的顺序执行。技能文档要求先阅读AGENTS.md中的durable-runtime-invariants-canonical-ssot章节模板见 templates/AGENTS.md以明确状态归属与 goal 工具的边界。2.2 持久化工件Artifacts所有状态都落在仓库原生的.omx/ultragoal/目录下三个核心文件分别是文件作用.omx/ultragoal/brief.md计划简报保存任务的原始说明.omx/ultragoal/goals.json目标清单保存分解后的全部子目标.omx/ultragoal/ledger.jsonl账本逐行追加记录计划创建、goal 完成/失败/重试、转向审计等事件这三个文件路径在 src/ultragoal/artifacts.ts 中定义为常量ULTRAGOAL_DIR、ULTRAGOAL_BRIEF、ULTRAGOAL_GOALS、ULTRAGOAL_LEDGER并在 src/cli/ultragoal.ts 的ULTRAGOAL_HELP中作为 Artifacts 一节对外公开。测试用例 src/ultragoal/tests/artifacts.test.ts 会断言plan_created等事件被写入 ledger验证了账本机制的可靠性。2.3 默认聚合目标模式Aggregate Mode新计划默认使用聚合 Codex goal 模式整个计划对应一个稳定的指针目标pointer objective而 OMX 在后台分别跟踪各个 story子故事。只有被显式要求时才使用--codex-goal-mode per-story。这一设计极大减少了与 Codex/goal的交互次数。在 src/cli/ultragoal.ts 中normalizeCodexGoalMode()只接受aggregate与per-story或per_story两个取值其余值直接抛出UltragoalError。2.4 关键约束不调用/goal clear技能文档明确不得从 shell 或该技能内部调用/goal clear。一次运行结束后操作者应在 Codex UI 中手动清除交互式 Codex goal才能在同线程内开启下一次运行。这一约束也在 CLI 帮助文本中重复强调Ultragoal does not call /goal clear or hidden thread/goal/clear routes。三、迁移路径从$ralph到$ultragoal迁移动作本身极其简单之前已移除之后推荐$ralph Task: {{ARGUMENTS}}$ultragoal并按下述流程创建/执行目标用一句概括Ralph 的循环直到完成是 ultragoal 单目标运行的一个退化特例因此单目标 ultragoal 运行可以复用 Ralph 提供的持久化与已验证完成承诺且默认获得目标账本、显式转向、最终质量闸门等新能力。四、$ultragoal完整操作流4.1 创建计划create只需一条命令然后检查生成结果omx ultragoal create-goals --brief brief omx ultragoal create-goals --brief-file path cat brief | omx ultragoal create-goals --from-stdin omx ultragoal create-goals --codex-goal-mode per-story --brief brief对应源码 src/cli/ultragoal.ts 中的create-goals分支其完整参数还包括--goal title::objective可重复传入直接追加手工拆解的目标标题与目标之间用::分隔--force覆盖已有计划--json以 JSON 输出计划对象与摘要。创建成功后会打印三个路径brief、goals、ledger。如果后续需要调整不要手工编辑持久化工件而应使用下方第 4.4 节介绍的显式转向steer机制。4.2 顺序执行execute技能文档给出的执行循环是重复运行omx ultragoal status直到报告所有目标完成。每一步如下运行omx ultragoal complete-goals并阅读其交接说明handoff调用get_goal仅当当前不存在活动的 Codex goal 时才用打印的负载调用create_goal否则继续匹配当前的聚合目标aggregate objective完成一个 OMX story并以真实工件与验证证据审计其 objective对中间聚合 story保持 Codex goal 为 active 状态并做检查点omx ultragoal checkpoint --goal-id id --status complete --evidence evidence --codex-goal-json fresh-get-goal-json-or-path对阻塞/失败 story使用--status blocked|failed并附 evidence失败后可继续执行omx ultragoal complete-goals --retry-failed重试对最终 story在调用update_goal({status: complete})之前先完成下方第 4.5 节的最终闸门随后再次调用get_goal用最新的完成快照做检查点。complete-goals是complete、next、start-next的别名。值得注意的细节是src/cli/ultragoal.ts 中assertUltragoalMutationAllowedFromCurrentProcess()会检查OMX_TEAM_WORKER环境变量Team worker 进程禁止执行任何 mutating 的 ultragoal 命令因为 ultragoal 状态属于 leader 所有worker 必须向上报告检查点证据而不是直接改写.omx/ultragoal/。4.3 最终完成与状态报告omx ultragoal status会汇总各目标的 complete/pending/in_progress/failed/review_blocked/needs_user_decision 数量并以*标记当前活动目标当所有目标完成后输出ultragoal: all goals complete反复出现外部授权阻塞时相关 story 会变为不可重试的needs_user_decision此时complete-goals --retry-failed会跳过它们并打印所需的外部决策而不是无限循环——这正是 Ralph loop 时代最需要人工干预的场景。4.4 显式转向steer唯一合法的计划变更通道只有当分解确实需要改变时才使用带证据的指令omx ultragoal steer --kind add_subgoal --title title --objective objective --evidence evidence --rationale reason --json omx ultragoal steer --directive-json ./steering.json --json支持的 mutation 类型共有六种定义见 src/ultragoal/artifacts.ts 的ULTRAGOAL_STEERING_MUTATION_KINDS--kind作用add_subgoal新增子目标split_subgoal拆分现有子目标reorder_pending调整待办顺序revise_pending_wording修订待办措辞annotate_ledger在账本上追加注释mark_blocked_superseded标记某目标被取代而阻塞关键规则普通自然语言不会改变计划steer会拒绝宽泛的自然语言变更请求见 src/cli/ultragoal.ts 中parseSteeringProposal()的报错每次转向都有 invariant 审计结构不变量、证据支撑的必要性、无更易完成路径并记录 accepted/rejected/deduped 结果到ledger.jsonl重复的结构化指令会去重idempotent避免反复触发同一变更。4.5 最终闸门与退出证据Final gate在宣告最终完成之前必须依次完成以下验证链运行针对性的 story 验证targeted story verification在变更文件上运行ai-slop-cleaner然后重新运行验证对照 brief/spec/已接受的转向审计所有架构/领域不变量与实现、测试、评审证据的一致性通过独立的code-reviewer与architect两条通道执行$code-review。若评审或不变量证明不干净不得更新 Codex goal而应记录持久化阻塞omx ultragoal record-review-blockers --goal-id id --title Resolve final code-review blockers --objective objective --evidence findings --codex-goal-json active-get-goal-json-or-path若一切干净调用update_goal({status: complete})、再次get_goal并以--quality-gate-json携带 cleaner、验证、评审与架构不变量证据做检查点。最终报告应包含goal ids/statuses、ledger/checkpoint 路径、最新的 goal 快照证据、评审结论以及任何阻塞项。绝不能仅凭 OMX 自身状态就宣称完成——完成与否必须由真实工件与验证证据背书。从源码看checkpoint命令接受--status complete|failed|blocked与可选的--quality-gate-json、--strict其中--strict保留 fail-closed 的 cohort 闸门ai-slop-cleaner、验证、带 independentReview 的 code-review、架构不变量闸门。测试 src/ultragoal/tests/artifacts.test.ts 会校验goal_completed、goal_failed、goal_retried事件写入 ledger并对过早声称聚合完成的检查点抛出错误。五、Phase/HUD 交接与 Team 桥接5.1 独立激活时的阶段声明独立激活$ultragoal时应声明最小且准确的阶段planning、executing、verifying、reviewing、checkpointing、blocked之一omx state write --input {mode:ultragoal,active:true,current_phase:planning} --json5.2 Autopilot 内部的阶段语义在 Autopilot 内激活时保持父模式激活并将current_phase设为ultragoal在 code-review 交接前将 Ultragoal 证据持久化到handoff_artifacts.ultragoal之下。只有当每个持久化目标都完成时才能把独立的 Ultragoal 标记为完成。5.3 可选的 Team 桥如需并行执行多个 story应使用独立的 Team 命令leader 使用最新的get_goal快照记录 Ultragoal 检查点具体桥接细节参见 Team 技能skills/team/SKILL.md。六、迁移后的检查清单确认已升级到 OMX 0.21omx version将提示词中的$ralph全部替换为$ultragoal首次运行omx ultragoal create-goals --brief ...并核对.omx/ultragoal/下三个工件按 4.2 的循环执行每步用checkpoint落账不直接手改工件需要变更分解时只走steer显式转向并核对 ledger 审计记录最终完成前跑完 4.5 的验证链与独立 code-review再update_goal并做完成快照检查点若使用 Team 并行确认 leader 持有 ultragoal 状态worker 不直接改写.omx/ultragoal/。七、深入阅读迁移声明原文skills/ralph/SKILL.mdUltragoal 完整操作规范skills/ultragoal/SKILL.md移除技能的统一解析器实现src/hooks/sunset-stub.tsUltragoal CLI 帮助与命令解析src/cli/ultragoal.ts持久化工件与转向不变量实现src/ultragoal/artifacts.ts账本与检查点行为测试src/ultragoal/tests/artifacts.test.ts0.21.0 发布说明docs/release-notes-0.21.0.mdteam 与 ralph 解耦的 PR 草案docs/prs/dev-deprecate-team-ralph.md一句话总结$ralph的移除不是功能的消失而是能力的升级——用$ultragoal以仓库原生工件、显式转向与验证闸门取代 Ralph 的单目标循环让持久化 已验证完成成为默认工作方式。【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表