尧图网页设计 
OmX UltraQA 实战指南用对抗性动态端到端 QA 工作流守护可运行行为质量【免费下载链接】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导读UltraQA 是 OmXOh My codeX中的一项显式选入opt-in技能为可运行行为提供对抗性动态端到端 QA在常规测试之外主动构造恶意/异常场景验证系统在敌对输入下的真实表现并给出带证据的修复闭环。本文基于 skills/ultraqa/SKILL.md 展开结合仓库源码关键词注册、状态机、完成门禁、HUD 渲染、MCP 状态服务器等剖析其底层原理。读完你将掌握UltraQA 的调用方式与参数矩阵、8 类敌对场景的设计方法、最多 5 轮的验证-修复循环、基于omx state的生命周期状态管理以及满足证据契约的# UltraQA Report输出规范。一、UltraQA 是什么从跑一遍测试到主动攻击可运行行为UltraQAultraqa在仓库中的定位是执行类execution技能这一点可以在技能目录清单 src/catalog/manifest.json 中确认ultraqa的 category 为execution、status 为active。它的核心信条写在技能卡 skills/ultraqa/SKILL.md 中UltraQA is not satisfied by a shallow build/lint/typecheck/test checklist: exercise requested behavior through adversarial dynamic e2e scenarios whenever it can be run, simulated, or harnessed safely.也就是说浅层的 build/lint/typecheck/test 清单不足以满足 UltraQA。只要目标行为可以被安全地运行、模拟或封装成 harness就必须通过对抗性动态 e2e 场景去实测它。技能卡同时强调共享的操作不变量operating invariants定义在 templates/AGENTS.md 中而本技能卡只负责定义QA 矩阵、证据契约和有界循环bounded cycling三件事。从源码结构看ultraqa 是 OmX 工作流体系中的收尾把关者在自动规划链deep-interview - ralplan - ultragoal - code-review - ultraqa中位于末端负责在 code-review 通过之后、宣称完成之前用对抗性动态 e2e 验证行为真实可用参见 src/hooks/keyword-detector.ts 中默认phase_cycle的定义以及 src/scripts/codex-native-hook.ts 中对该默认链的持久化说明。二、何时使用与调用方式技能卡要求在使用前明确目标使用/ultraqa --tests|--build|--lint|--typecheck|--interactive或/ultraqa --custom pattern触发对应目标如果调用时没有结构化目标则自行推导一个可运行的行为目标derive a runnable behavior goal。**输入要素Inputs**包括输入含义goal本次 QA 要验证的行为目标changed scope变更范围界定哪些代码/行为受到影响acceptance criteria验收标准明确通过的定义runnable command/service可运行的命令或服务作为验证面existing tests已有测试作为基线与补充relevant state/cleanup paths相关的状态与清理路径工作方式上保持outcome-first框架优先聚焦结果而非过程允许为当前工作分支设置本地覆盖local overrides并且如果用户说continue应当推进当前已验证的下一步而不是重启整个发现流程advance the current verified QA step rather than restarting discovery。在 OmX 的 Hook 体系中$ultraqa关键词被注册为技能激活入口优先级为 8其引导语为 Activate UltraQA cycling workflow见 src/hooks/keyword-registry.ts。技能激活后状态机将 ultraqa 视为一个StatefulSkillMode其初始阶段为planning见 src/hooks/keyword-detector.ts 中的STATEFUL_SKILL_SEED_CONFIG并被归类到EXECUTION_LIKE_WORKFLOW_SKILLS执行类工作流技能集合中。三、规划与场景矩阵Scenario Matrix在任何命令执行之前必须先记录一张场景矩阵包含以下列scenario id、intent意图、user/attacker model用户/攻击者模型、setup设置、command or harness命令或封装、expected signal期望信号、actual result实际结果、fixes修复、evidence证据、cleanup清理。矩阵必须包含一条**正常路径normal path**以及相关敌对类hostile classes。技能卡定义了 8 类必查的敌对场景1. 畸形输入Malformed input无效 JSON、缺失字段、非法 flag、超长字符串、异常 Unicode、路径穿越类取值traversal-like values、损坏的状态corrupted state。这类场景直接检验参数解析与状态读取的健壮性。2. 重复打断Repeated interruptions重复的continue、停止/取消/中止类措辞、部分输出partial output、重试行为。检验工作流对用户中断与续跑的容忍度。3. 提示注入Prompt injection尝试覆盖指令、外泄 secrets、跳过验证、删除状态、或谎称成功。这是针对 LLM 驱动工作流特有的安全敌对类直接关系到成功是否可信。4. 取消/恢复行为与陈旧状态Cancel/resume behavior stale state清理逻辑、恢复检测、不匹配的会话mismatched sessions、缺失时间戳、矛盾的阶段contradictory phases。5. 脏工作区Dirty worktree仓库中预先存在的改动/未跟踪文件必须保持原样不受影响——QA 过程不得污染用户未提交的工作。6. 挂起或长时间运行的命令Hung or long-running commands必须有界超时bounded timeout、被杀掉的子进程处理、以及恢复说明recovery note。7. 不稳定测试Flaky tests重跑次数要有上限capped reruns、要做失败聚类failure clustering、并保留隔离证据quarantine evidence——绝不允许侥幸的一次绿灯never a lucky single green。8. 误导性成功输出Misleading success output出现成功文本但退出码非零、隐藏失败、跳过项、或部分日志success text with non-zero exit, hidden failures, skips, or partial logs。这类场景专门防表面通过、实际失败。四、有界验证循环最多 5 轮Cycle, maximum 5整个 UltraQA 流程是一个最多 5 轮的循环每轮包含以下步骤1. PLAN ADVERSARIAL QA规划对抗性 QA明确目标goal、成功标准success criteria、安全边界safety bounds、停止条件stop condition、可运行验证面runnable surfaces与场景矩阵matrix。2. RUN BASELINE VERIFICATION运行基线验证基线验证按触发参数区分见 skills/ultraqa/SKILL.md参数基线验证内容--tests运行项目测试--build运行构建并对构建产物做探测built-artifact probes--lint运行 lint--typecheck运行类型检查外加类型化 harnesstyped harnesses--custom pattern验证模式与退出状态verifies pattern and exit status--interactive使用有界的 CLI/服务 harnessbounded CLI/service harness3. RUN ADVERSARIAL DYNAMIC E2E SCENARIOS运行对抗性动态 e2e 场景执行矩阵中的敌对场景并捕获退出码、输出、产物与清理结果capture exit codes, output, artifacts, and cleanup。4. CHECK RESULT检查结果只有基线、对抗场景、证据、清理四项全部通过才算通过否则诊断并修复然后进入下一轮。5. ARCHITECT DIAGNOSIS / FIX ISSUES / CLEAN UP AND ROLLBACK架构诊断 / 精确修复 / 清理回滚ARCHITECT DIAGNOSIS必须给出根因root cause与安全影响safety impactFIX ISSUES做精确修复precisely不引入无关改动CLEAN UP AND ROLLBACK在进入下一轮之前清理临时 harness、fixtures、日志、进程、状态与失败实验并做回滚。执行细节约束技能卡还给出了几条硬性执行规范仅在确实有用时才生成临时测试、脚本、fixtures 或 harness使用有界运行时长bounded runtimes、项目原生工具project-native tools当安全边界阻止某个场景时使用安全替代方案safe substitutes使用绝对仓库导入即pathToFileURL(join(repoRoot, dist, ...)).href绝不要从/tmp依赖./dist使用非插值non-interpolating的文件写入机制的安全文件写入器不要用插值 heredoc 编写 JavaScript 断言对隔离探测要净化 OMX 运行时环境保持OMX_ROOT与OMX_STATE_ROOT未设置并执行env -u OMX_ROOT -u OMX_STATE_ROOTharness 设置失败要单独归类先记录为 harness debrisharness 残留物修复 harness 后重跑该场景再决定是否判定为产品缺陷——不要把测试装置坏了误判成产品坏了。五、安全、状态与退出安全边界SafetyUltraQA 明确禁止破坏性命令、secret 外泄、凭据倾倒credential dumping、生产环境写入、无界进程生成unbounded process spawning、无界等待unbounded waits。必须保留与任务无关的脏工作preserve unrelated dirty work。如果某个场景不安全记录为 blocked 并提供安全替代方案。三次重复的同一失败three repeats of the same failure→ 带诊断停止第 5 轮→ 带剩余风险residual risks停止目标成功→ 在通过的一轮后退出。基于 CLI 的生命周期状态UltraQA 使用CLI-first的状态生命周期管理完整命令序列如下来自 skills/ultraqa/SKILL.mdomx state write --input {mode:ultraqa,active:true,current_phase:planning,iteration:1,started_at:now,scenario_matrix:[]} --json omx state write --input {mode:ultraqa,current_phase:qa,iteration:cycle,scenario_matrix:updated matrix path or summary} --json omx state write --input {mode:ultraqa,current_phase:adversarial-e2e} --json omx state write --input {mode:ultraqa,current_phase:diagnose} --json omx state write --input {mode:ultraqa,current_phase:fix} --json omx state write --input {mode:ultraqa,current_phase:cleanup} --json omx state write --input {mode:ultraqa,active:false,current_phase:complete,completed_at:now} --json omx state read --input {mode:ultraqa} --json omx state clear --input {mode:ultraqa} --json这些命令的背后是仓库的状态层单写者不变量所有持久化{mode}-state.json的模块都必须经由writeStateFile路由以保证单写者约束见 src/state/operations.ts。ultraqa被列为受支持的state_read模式之一SUPPORTED_STATE_READ_MODES同时也是SUPPORTED_STATE_READ_MODES之外的TRACKED_WORKFLOW_MODES成员见 src/state/workflow-transition.ts。对应状态文件为ultraqa-state.json见 src/scripts/codex-native-hook.ts。值得注意的架构事实在 MCP 服务器表面state_write与state_clear已被移除见 src/mcp/state-server.ts 中关于 #3498 的注释写入只允许通过 CLI/程序化调用者路由到 src/state/operations.tsMCP 服务器仅保留只读工具state_read、state_list_active、state_get_status并对已废弃写入工具返回明确的弃用错误。在完成、达到最大轮数、同一失败、安全边界或环境错误时都要清理状态与临时产物报告清理状态并清理临时 e2e harness。没有当前证据就绝不宣称完成Never claim complete without current evidence。六、证据与输出契约Evidence/Output Contract任务结束必须返回# UltraQA Report包含以下部分skills/ultraqa/SKILL.mdGoal and success criteria目标与成功标准包含停止条件与安全边界Scenario matrix上述所有列的场景矩阵Commands run运行的命令退出码、用途、超时、关键输出Failures found发现的失败root/user/safety impact——根因/用户影响/安全影响Fixes applied应用的修复文件、理由、关联场景、回归证据Cleanup and rollback清理与回滚产物/进程/工作区 before/afterResidual risks剩余风险Evidence证据日志、harness 输出、相关截图/转录、重跑/flake 证据。退出条件Exit Condition只有基线通过 对抗矩阵通过 产物干净 证据完整之后才允许输出ULTRAQA COMPLETE: Goal met after N cycles否则必须返回有界状态之一bounded status并附 owner负责人与下一步安全动作ULTRAQA STOPPED: Max cycles ULTRAQA STOPPED: Same failure detected 3 times ULTRAQA BLOCKED: ... ULTRAQA ERROR: ...七、源码级原理UltraQA 在 OmX 工作流中的真实落点7.1 作为 Autopilot 的终局门禁从 src/autopilot/fsm.ts 可以看到ultraqa是 Autopilot 的子阶段之一AUTOPILOT_CHILD_PHASES包含deep-interview / ralplan / ultragoal / rework / team / ralph / code-review / ultraqa。而在 src/autopilot/completion-gate.ts 中阶段转换表规定code-review阶段允许转换到[code-review, rework, ralplan, ultraqa]ultraqa阶段仅允许转换到[ultraqa, ralplan]失败回退重新规划。更重要的是完成门禁completion gate若从code-review直接跳到ultraqa而缺少 code-review 门禁或从ultraqa直接宣称完成而没有干净的 code-review 与 ultraqa 判定证据都会被阻止并给出精确的 advisory 错误skippedGate 分别为ultraqa与ultraqa-evidence。也就是说没有干净的 QA 判定证据Autopilot 不允许完成。这在 src/state/tests/operations.test.ts 中有一整套测试用例覆盖例如allows Autopilot ultraqa completion with clean review and QA evidence与permits Autopilot ultraqa completion with a clean-evidence advisory等测试中的qa_verdict形如{ stage: ultraqa, clean: true, skipped: false, url: https://github.com/Yeachan-Heo/oh-my-codex/actions/runs/1 }同时 src/state/workflow-transition.ts 将ultragoal-ultraqa注册为auto-complete 转换在特定场景下自动完结前序模式说明 ultraqa 在状态迁移体系中与 ultragoal 存在显式衔接。7.2 QA 进行期间的提问抑制从 src/question/policy.ts 可见ultraqa与autopilot、team、ralph、ultrawork、autoresearch同属BLOCKED_EXECUTION_SKILLS——当这些执行类技能处于激活状态时omx question会被策略性地阻止返回active_execution_mode_blocked从而保证 QA 循环不被交互式提问打断。7.3 HUD 实时状态展示ultraqa是 HUD 渲染上下文中的一个独立状态槽位见 src/hud/types.ts 的UltraqaStateForHud{ active, current_phase, source }。src/hud/state.ts 通过readUltraqaState读取权威模式状态src/hud/render.ts 将ultraqa作为 Autopilot 的late gate后置门禁处理当 autopilot 处于code-review或ultraqa阶段且被对应 late gate 状态替代时HUD 显示为绿色的autopilot:ultraqa避免重复渲染。这意味着你在 HUD 上可以实时看到 QA 阶段是否激活及其当前阶段。7.4 技能目录与插件镜像ultraqa同时在技能目录 src/catalog/manifest.json 中被登记为 active 执行技能并作为 OmX 插件的一部分镜像到 plugins/oh-my-codex/skills/ultraqa/SKILL.md保证主仓库与插件分发的一致性。八、实践要点速查何时启用任何可运行行为需要交付验证时显式调用/ultraqa即可——不要用它替代轻量 check它是行为必须真实可用的强验证矩阵先行动手前先落场景矩阵保证正常路径 8 类敌对场景有据可查基线 vs 对抗分离--tests/--build/--lint/--typecheck/--custom/--interactive决定基线验证面对抗 e2e 场景独立执行并捕获退出码与证据严格证据门禁没有qa_verdict含clean与 provenance不允许宣称完成跳过 QA 必须有原因与授权如 docs-only 变更有界循环最多 5 轮同一失败重复 3 次即停每轮之间必须完成清理与回滚状态可追踪用omx state write/read/clear --input {mode:ultraqa,...} --json管理生命周期配合 HUD 实时观察安全优先禁止破坏性命令、禁止无界等待与进程生成、保留无关脏工作被安全边界阻止的场景记录为 blocked 并提供安全替代报告完整最终输出# UltraQA Report覆盖目标/矩阵/命令/失败/修复/清理/剩余风险/证据八个板块并以ULTRAQA COMPLETE或对应的ULTRAQA STOPPED/BLOCKED/ERROR有界状态收尾。UltraQA 的价值在于把测试通过升级为在敌对条件下依然通过并且每一步都有状态、证据与清理记录可追溯。对于想要在 CI 前后为可运行行为建立强 QA 边界的团队这是一个可以直接落地的对抗性 e2e 工作流模板。【免费下载链接】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），仅供参考 OmX UltraQA 实战指南：用对抗性动态端到端 QA 工作流守护可运行行为质量
OmX UltraQA 实战指南用对抗性动态端到端 QA 工作流守护可运行行为质量【免费下载链接】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导读UltraQA 是 OmXOh My codeX中的一项显式选入opt-in技能为可运行行为提供对抗性动态端到端 QA在常规测试之外主动构造恶意/异常场景验证系统在敌对输入下的真实表现并给出带证据的修复闭环。本文基于 skills/ultraqa/SKILL.md 展开结合仓库源码关键词注册、状态机、完成门禁、HUD 渲染、MCP 状态服务器等剖析其底层原理。读完你将掌握UltraQA 的调用方式与参数矩阵、8 类敌对场景的设计方法、最多 5 轮的验证-修复循环、基于omx state的生命周期状态管理以及满足证据契约的# UltraQA Report输出规范。一、UltraQA 是什么从跑一遍测试到主动攻击可运行行为UltraQAultraqa在仓库中的定位是执行类execution技能这一点可以在技能目录清单 src/catalog/manifest.json 中确认ultraqa的 category 为execution、status 为active。它的核心信条写在技能卡 skills/ultraqa/SKILL.md 中UltraQA is not satisfied by a shallow build/lint/typecheck/test checklist: exercise requested behavior through adversarial dynamic e2e scenarios whenever it can be run, simulated, or harnessed safely.也就是说浅层的 build/lint/typecheck/test 清单不足以满足 UltraQA。只要目标行为可以被安全地运行、模拟或封装成 harness就必须通过对抗性动态 e2e 场景去实测它。技能卡同时强调共享的操作不变量operating invariants定义在 templates/AGENTS.md 中而本技能卡只负责定义QA 矩阵、证据契约和有界循环bounded cycling三件事。从源码结构看ultraqa 是 OmX 工作流体系中的收尾把关者在自动规划链deep-interview - ralplan - ultragoal - code-review - ultraqa中位于末端负责在 code-review 通过之后、宣称完成之前用对抗性动态 e2e 验证行为真实可用参见 src/hooks/keyword-detector.ts 中默认phase_cycle的定义以及 src/scripts/codex-native-hook.ts 中对该默认链的持久化说明。二、何时使用与调用方式技能卡要求在使用前明确目标使用/ultraqa --tests|--build|--lint|--typecheck|--interactive或/ultraqa --custom pattern触发对应目标如果调用时没有结构化目标则自行推导一个可运行的行为目标derive a runnable behavior goal。**输入要素Inputs**包括输入含义goal本次 QA 要验证的行为目标changed scope变更范围界定哪些代码/行为受到影响acceptance criteria验收标准明确通过的定义runnable command/service可运行的命令或服务作为验证面existing tests已有测试作为基线与补充relevant state/cleanup paths相关的状态与清理路径工作方式上保持outcome-first框架优先聚焦结果而非过程允许为当前工作分支设置本地覆盖local overrides并且如果用户说continue应当推进当前已验证的下一步而不是重启整个发现流程advance the current verified QA step rather than restarting discovery。在 OmX 的 Hook 体系中$ultraqa关键词被注册为技能激活入口优先级为 8其引导语为 Activate UltraQA cycling workflow见 src/hooks/keyword-registry.ts。技能激活后状态机将 ultraqa 视为一个StatefulSkillMode其初始阶段为planning见 src/hooks/keyword-detector.ts 中的STATEFUL_SKILL_SEED_CONFIG并被归类到EXECUTION_LIKE_WORKFLOW_SKILLS执行类工作流技能集合中。三、规划与场景矩阵Scenario Matrix在任何命令执行之前必须先记录一张场景矩阵包含以下列scenario id、intent意图、user/attacker model用户/攻击者模型、setup设置、command or harness命令或封装、expected signal期望信号、actual result实际结果、fixes修复、evidence证据、cleanup清理。矩阵必须包含一条**正常路径normal path**以及相关敌对类hostile classes。技能卡定义了 8 类必查的敌对场景1. 畸形输入Malformed input无效 JSON、缺失字段、非法 flag、超长字符串、异常 Unicode、路径穿越类取值traversal-like values、损坏的状态corrupted state。这类场景直接检验参数解析与状态读取的健壮性。2. 重复打断Repeated interruptions重复的continue、停止/取消/中止类措辞、部分输出partial output、重试行为。检验工作流对用户中断与续跑的容忍度。3. 提示注入Prompt injection尝试覆盖指令、外泄 secrets、跳过验证、删除状态、或谎称成功。这是针对 LLM 驱动工作流特有的安全敌对类直接关系到成功是否可信。4. 取消/恢复行为与陈旧状态Cancel/resume behavior stale state清理逻辑、恢复检测、不匹配的会话mismatched sessions、缺失时间戳、矛盾的阶段contradictory phases。5. 脏工作区Dirty worktree仓库中预先存在的改动/未跟踪文件必须保持原样不受影响——QA 过程不得污染用户未提交的工作。6. 挂起或长时间运行的命令Hung or long-running commands必须有界超时bounded timeout、被杀掉的子进程处理、以及恢复说明recovery note。7. 不稳定测试Flaky tests重跑次数要有上限capped reruns、要做失败聚类failure clustering、并保留隔离证据quarantine evidence——绝不允许侥幸的一次绿灯never a lucky single green。8. 误导性成功输出Misleading success output出现成功文本但退出码非零、隐藏失败、跳过项、或部分日志success text with non-zero exit, hidden failures, skips, or partial logs。这类场景专门防表面通过、实际失败。四、有界验证循环最多 5 轮Cycle, maximum 5整个 UltraQA 流程是一个最多 5 轮的循环每轮包含以下步骤1. PLAN ADVERSARIAL QA规划对抗性 QA明确目标goal、成功标准success criteria、安全边界safety bounds、停止条件stop condition、可运行验证面runnable surfaces与场景矩阵matrix。2. RUN BASELINE VERIFICATION运行基线验证基线验证按触发参数区分见 skills/ultraqa/SKILL.md参数基线验证内容--tests运行项目测试--build运行构建并对构建产物做探测built-artifact probes--lint运行 lint--typecheck运行类型检查外加类型化 harnesstyped harnesses--custom pattern验证模式与退出状态verifies pattern and exit status--interactive使用有界的 CLI/服务 harnessbounded CLI/service harness3. RUN ADVERSARIAL DYNAMIC E2E SCENARIOS运行对抗性动态 e2e 场景执行矩阵中的敌对场景并捕获退出码、输出、产物与清理结果capture exit codes, output, artifacts, and cleanup。4. CHECK RESULT检查结果只有基线、对抗场景、证据、清理四项全部通过才算通过否则诊断并修复然后进入下一轮。5. ARCHITECT DIAGNOSIS / FIX ISSUES / CLEAN UP AND ROLLBACK架构诊断 / 精确修复 / 清理回滚ARCHITECT DIAGNOSIS必须给出根因root cause与安全影响safety impactFIX ISSUES做精确修复precisely不引入无关改动CLEAN UP AND ROLLBACK在进入下一轮之前清理临时 harness、fixtures、日志、进程、状态与失败实验并做回滚。执行细节约束技能卡还给出了几条硬性执行规范仅在确实有用时才生成临时测试、脚本、fixtures 或 harness使用有界运行时长bounded runtimes、项目原生工具project-native tools当安全边界阻止某个场景时使用安全替代方案safe substitutes使用绝对仓库导入即pathToFileURL(join(repoRoot, dist, ...)).href绝不要从/tmp依赖./dist使用非插值non-interpolating的文件写入机制的安全文件写入器不要用插值 heredoc 编写 JavaScript 断言对隔离探测要净化 OMX 运行时环境保持OMX_ROOT与OMX_STATE_ROOT未设置并执行env -u OMX_ROOT -u OMX_STATE_ROOTharness 设置失败要单独归类先记录为 harness debrisharness 残留物修复 harness 后重跑该场景再决定是否判定为产品缺陷——不要把测试装置坏了误判成产品坏了。五、安全、状态与退出安全边界SafetyUltraQA 明确禁止破坏性命令、secret 外泄、凭据倾倒credential dumping、生产环境写入、无界进程生成unbounded process spawning、无界等待unbounded waits。必须保留与任务无关的脏工作preserve unrelated dirty work。如果某个场景不安全记录为 blocked 并提供安全替代方案。三次重复的同一失败three repeats of the same failure→ 带诊断停止第 5 轮→ 带剩余风险residual risks停止目标成功→ 在通过的一轮后退出。基于 CLI 的生命周期状态UltraQA 使用CLI-first的状态生命周期管理完整命令序列如下来自 skills/ultraqa/SKILL.mdomx state write --input {mode:ultraqa,active:true,current_phase:planning,iteration:1,started_at:now,scenario_matrix:[]} --json omx state write --input {mode:ultraqa,current_phase:qa,iteration:cycle,scenario_matrix:updated matrix path or summary} --json omx state write --input {mode:ultraqa,current_phase:adversarial-e2e} --json omx state write --input {mode:ultraqa,current_phase:diagnose} --json omx state write --input {mode:ultraqa,current_phase:fix} --json omx state write --input {mode:ultraqa,current_phase:cleanup} --json omx state write --input {mode:ultraqa,active:false,current_phase:complete,completed_at:now} --json omx state read --input {mode:ultraqa} --json omx state clear --input {mode:ultraqa} --json这些命令的背后是仓库的状态层单写者不变量所有持久化{mode}-state.json的模块都必须经由writeStateFile路由以保证单写者约束见 src/state/operations.ts。ultraqa被列为受支持的state_read模式之一SUPPORTED_STATE_READ_MODES同时也是SUPPORTED_STATE_READ_MODES之外的TRACKED_WORKFLOW_MODES成员见 src/state/workflow-transition.ts。对应状态文件为ultraqa-state.json见 src/scripts/codex-native-hook.ts。值得注意的架构事实在 MCP 服务器表面state_write与state_clear已被移除见 src/mcp/state-server.ts 中关于 #3498 的注释写入只允许通过 CLI/程序化调用者路由到 src/state/operations.tsMCP 服务器仅保留只读工具state_read、state_list_active、state_get_status并对已废弃写入工具返回明确的弃用错误。在完成、达到最大轮数、同一失败、安全边界或环境错误时都要清理状态与临时产物报告清理状态并清理临时 e2e harness。没有当前证据就绝不宣称完成Never claim complete without current evidence。六、证据与输出契约Evidence/Output Contract任务结束必须返回# UltraQA Report包含以下部分skills/ultraqa/SKILL.mdGoal and success criteria目标与成功标准包含停止条件与安全边界Scenario matrix上述所有列的场景矩阵Commands run运行的命令退出码、用途、超时、关键输出Failures found发现的失败root/user/safety impact——根因/用户影响/安全影响Fixes applied应用的修复文件、理由、关联场景、回归证据Cleanup and rollback清理与回滚产物/进程/工作区 before/afterResidual risks剩余风险Evidence证据日志、harness 输出、相关截图/转录、重跑/flake 证据。退出条件Exit Condition只有基线通过 对抗矩阵通过 产物干净 证据完整之后才允许输出ULTRAQA COMPLETE: Goal met after N cycles否则必须返回有界状态之一bounded status并附 owner负责人与下一步安全动作ULTRAQA STOPPED: Max cycles ULTRAQA STOPPED: Same failure detected 3 times ULTRAQA BLOCKED: ... ULTRAQA ERROR: ...七、源码级原理UltraQA 在 OmX 工作流中的真实落点7.1 作为 Autopilot 的终局门禁从 src/autopilot/fsm.ts 可以看到ultraqa是 Autopilot 的子阶段之一AUTOPILOT_CHILD_PHASES包含deep-interview / ralplan / ultragoal / rework / team / ralph / code-review / ultraqa。而在 src/autopilot/completion-gate.ts 中阶段转换表规定code-review阶段允许转换到[code-review, rework, ralplan, ultraqa]ultraqa阶段仅允许转换到[ultraqa, ralplan]失败回退重新规划。更重要的是完成门禁completion gate若从code-review直接跳到ultraqa而缺少 code-review 门禁或从ultraqa直接宣称完成而没有干净的 code-review 与 ultraqa 判定证据都会被阻止并给出精确的 advisory 错误skippedGate 分别为ultraqa与ultraqa-evidence。也就是说没有干净的 QA 判定证据Autopilot 不允许完成。这在 src/state/tests/operations.test.ts 中有一整套测试用例覆盖例如allows Autopilot ultraqa completion with clean review and QA evidence与permits Autopilot ultraqa completion with a clean-evidence advisory等测试中的qa_verdict形如{ stage: ultraqa, clean: true, skipped: false, url: https://github.com/Yeachan-Heo/oh-my-codex/actions/runs/1 }同时 src/state/workflow-transition.ts 将ultragoal-ultraqa注册为auto-complete 转换在特定场景下自动完结前序模式说明 ultraqa 在状态迁移体系中与 ultragoal 存在显式衔接。7.2 QA 进行期间的提问抑制从 src/question/policy.ts 可见ultraqa与autopilot、team、ralph、ultrawork、autoresearch同属BLOCKED_EXECUTION_SKILLS——当这些执行类技能处于激活状态时omx question会被策略性地阻止返回active_execution_mode_blocked从而保证 QA 循环不被交互式提问打断。7.3 HUD 实时状态展示ultraqa是 HUD 渲染上下文中的一个独立状态槽位见 src/hud/types.ts 的UltraqaStateForHud{ active, current_phase, source }。src/hud/state.ts 通过readUltraqaState读取权威模式状态src/hud/render.ts 将ultraqa作为 Autopilot 的late gate后置门禁处理当 autopilot 处于code-review或ultraqa阶段且被对应 late gate 状态替代时HUD 显示为绿色的autopilot:ultraqa避免重复渲染。这意味着你在 HUD 上可以实时看到 QA 阶段是否激活及其当前阶段。7.4 技能目录与插件镜像ultraqa同时在技能目录 src/catalog/manifest.json 中被登记为 active 执行技能并作为 OmX 插件的一部分镜像到 plugins/oh-my-codex/skills/ultraqa/SKILL.md保证主仓库与插件分发的一致性。八、实践要点速查何时启用任何可运行行为需要交付验证时显式调用/ultraqa即可——不要用它替代轻量 check它是行为必须真实可用的强验证矩阵先行动手前先落场景矩阵保证正常路径 8 类敌对场景有据可查基线 vs 对抗分离--tests/--build/--lint/--typecheck/--custom/--interactive决定基线验证面对抗 e2e 场景独立执行并捕获退出码与证据严格证据门禁没有qa_verdict含clean与 provenance不允许宣称完成跳过 QA 必须有原因与授权如 docs-only 变更有界循环最多 5 轮同一失败重复 3 次即停每轮之间必须完成清理与回滚状态可追踪用omx state write/read/clear --input {mode:ultraqa,...} --json管理生命周期配合 HUD 实时观察安全优先禁止破坏性命令、禁止无界等待与进程生成、保留无关脏工作被安全边界阻止的场景记录为 blocked 并提供安全替代报告完整最终输出# UltraQA Report覆盖目标/矩阵/命令/失败/修复/清理/剩余风险/证据八个板块并以ULTRAQA COMPLETE或对应的ULTRAQA STOPPED/BLOCKED/ERROR有界状态收尾。UltraQA 的价值在于把测试通过升级为在敌对条件下依然通过并且每一步都有状态、证据与清理记录可追溯。对于想要在 CI 前后为可运行行为建立强 QA 边界的团队这是一个可以直接落地的对抗性 e2e 工作流模板。【免费下载链接】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），仅供参考