omo-codex ulw-loop Task 6 收尾gates 真实面 QA 证据留档实战解析【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent本篇文章围绕 oh-my-openagent 仓库中.omo/evidence/20260721-ulw-loop-gajae-adoption/task-6.md这份 QA 收尾记录展开系统梳理 ulw-loopUltra Work Loop多目标编排组件的「完整门禁gates→ 真实构建 CLI 生命周期 → 失败关闭fail-closed探针 → 独立评审修复 → 证据与清理」五段式验收方法论。读完本文你将掌握如何在仓库内对组件级 CLI 做全链路验收理解checkpoint自动推进、steer --proposals-json原子批量、validation-batch 批次关闭等三大被采纳功能的实测口径并能直接复现npm run check npm test、根目录bun run test:codex与隔离临时仓库 E2E 三条 QA 命令链。1. 背景gajae 采纳计划与 Task 6 的定位task-6.md属于.omo/evidence/20260721-ulw-loop-gajae-adoption/证据目录对应一份被批准执行的 ulw-loop 采纳计划adoption plan的最后一个执行任务。该目录的 README 记录了完整计划范围checkpoint 自动推进auto-advance原子化steer --proposals-jsonvalidation-batch schemavalidation-batch 的 checkpoint/steering 强制校验文档与 help 同步完整门禁与构建产物 CLI 的 QA即 Task 6 本身最终验证波次 F1–F4。其中第 1–5 项由先前的 commit 完成证据文件为task-1.md至task-5.mdTask 6 则承担「收口」职责从持久化状态恢复执行、检查并抢救遗留的未提交 diff、通过聚焦 QA 发现并修复两个真实 bugTDD 方式最后在隔离的临时 git 仓库中对真实构建出的 CLI 完成端到端验收。从代码目录结构看被验收的组件位于 packages/omo-codex/plugin/components/ulw-loop它是一个独立的 Codex 插件组件状态持久化在仓库内.omo/ulw-loop/下通过omo-agent-toolkit ulw-loopCLI 变更同时提供 CLI、skill 与四个 Codex hookUserPromptSubmit、PreToolUse create_goal、PreToolUse spawn、Stop并不暴露 MCP server。2. 验收对象被采纳的三项功能与对应 CLI 面Task 6 实测的核心面就是组件真实构建产物dist/cli.js。先交代三项被采纳功能的 CLI 契约来源于 README.md 与 package.json 的 bin 声明omo-ulw-loop/ulw/ulw-loop三个命令名均指向dist/cli.js2.1 checkpoint 自动推进auto-advanceomo-agent-toolkit ulw-loop checkpoint用证据门禁一次目标迁移默认情况下通过检查点后自动启动下一个符合条件的 goal--no-advance可保留传统的「先 checkpoint、再手动 complete-goals」两步流程。可接受--statuscomplete、failed、blocked源码 checkpoint-continuation.ts 中checkpointStatus强制校验。必填--goal-id、--evidence非空校验ulw_loop_evidence_required见 checkpoint.ts。可选--codex-goal-json、--quality-gate-json、--print-template。2.2 原子 steering 批量--proposals-jsonomo-agent-toolkit ulw-loop steer支持两类输入单个 proposal--kind ...加 kind 专属参数或--proposals-json一次性提交多个 proposal。关键约束--kind与--proposals-json互斥同时给出直接报错ULW_LOOP_STEERING_BATCH_CONFLICTcli-steering.ts。--proposals-json必须是非空 JSON 数组数组中的每条对象需包含kind、evidence、rationale并按 kind 提供相应字段goalId、title、objective、criterionId、children/childGoals、replacements、order/pendingOrder等。支持的 mutation kinds 见 cli-steering.ts 的 help 文案add_subgoal、split_subgoal、reorder_pending、revise_pending_wording、revise_criterion、annotate_ledger、mark_blocked_superseded。2.3 validation-batch 验证批次在create-goals阶段通过--validation-batch-json声明可选验证批次作为目标之间的评审边界omo-agent-toolkit ulw-loop create-goals \ --validation-batch-json [{batchId:VB001,memberIds:[G001,G002,G003],finalGoalId:G003}]解析器validation-batch.ts强制以下 schema 约束batchId、finalGoalId必填memberIds至少 2 个finalGoalId必须是本批次成员成员必须引用已存在的 goalULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN同一 goal 不能出现在多个批次ULW_LOOP_VALIDATION_BATCH_OVERLAP批次内、批次间 id 均不得重复。批次关闭batch-final的目标在完成时受三重强制checkpoint.ts validation-batch.tsrequireBatchFinalReady其他成员必须全部 resolved否则抛ULW_LOOP_VALIDATION_BATCH_OPEN批次 final checkpoint 必须提供--quality-gate-json否则抛ULW_LOOP_VALIDATION_BATCH_GATE_REQUIREDrequireBatchGate质量门禁的criteriaCoverage.totalCriteria/passCount必须与重新计算的成员 criteria 总数一致否则抛ULW_LOOP_VALIDATION_BATCH_GATE_MISMATCH。此外steering 的 split/supersede 会保持批次成员一致性并在账本中追加batch_updated条目validation-batch.ts。3. 完整门禁gates组件层与仓库层两级验收Task 6 第一类证据是两级门禁。3.1 组件完整门禁在组件目录执行cd packages/omo-codex/plugin/components/ulw-loop npm run check npm testnpm run checktsc --noEmit biome check . npm run buildpackage.jsonscripts.check其中 build 为tsc -p tsconfig.build.json bun build src/cli.ts --target node --format esm --outfile dist/cli.jsnpm test运行 Vitest。task-6-component-gate.txt记录了两次运行历史组件门禁40 个测试文件 / 412 个用例全过评审修复后的组件门禁npm run checktsc、biome 82 文件、build 均过 完整npm test40 个测试文件 / 418 个用例全过新增 6 个用例正是评审修复的回归测试。dist/cli.js的构建产物正是本任务 QA 的「真实构建 CLI 表面」。3.2 仓库根级 Codex 门禁在仓库根目录执行bun run test:codexTask 6 记录显示该门禁在最终评审前与评审修复后各跑一次均为510 个测试、0 失败。这验证了组件改动没有破坏仓库内与 Codex 兼容性相关的其余模块。4. 真实构建 CLI 的 E2E 生命周期第二类证据是「真实构建 CLI 生命周期」在全新mktemp -d的 git 仓库中直接调用构建产物node packages/omo-codex/plugin/components/ulw-loop/dist/cli.js ulw-loop ...task-6-e2e-transcript.txt完整记录了这条主链路的 9 个步骤create-goalscreate-goals --validation-batch-json VB001产出 3 个 goal batchVB001version1G001 关键 criteria checkpoint completecheckpointG001-goal-alpha-complete nextG002-goal-beta:in_progress activeG002-goal-beta——验证 auto-advance完成 G001 后自动推进到 G002原子 steering 批量steer --proposals-json提交 2 条 proposal未显式传--sourceCLI 默认sourcecli结果steer acceptedtrue results2 acceptedItems2G002非批次 final 成员完成checkpointG002-goal-beta-complete nextG003-goal-gamma:in_progress——再次验证自动推进记录剩余 criteria 并落最终质量门禁产物门禁产物位于.omo/evidence/ulw/session/G003-goal-gamma/a1覆盖coverage6/6G003 批次 final checkpointcheckpointG003-goal-gamma-complete aggregatecomplete nextomitted——G003 既是validation-batch 的 final又是aggregate 的 final一次 checkpoint 同时触发批次关闭与聚合完成最终 status --jsonstatus aggregatecomplete complete3/3 criteriaPass9/9账本 batch_closed账本中出现{kind:batch_closed,goalId:G003-goal-gamma,message:VB001}源码见 checkpoint.ts批次 final 完成时额外追加batch_closed账本条目同一临时仓库、隔离 session 下验证失败关闭当另一个成员G001-goal-alpha仍处于 pending 时尝试批次 final checkpoint命令以FAIL_CODE1退出返回结构化的ULW_LOOP_VALIDATION_BATCH_OPEN错误details.open明确列出未解决成员。关于第 4 步需要澄清一个易误读点G002 本身属于批次成员但非 final所以它的完成不触发requireBatchFinalReady只有 finalGoalIdG003的 checkpoint 才受批次关闭强制约束。5. 失败关闭探针与独立评审修复回归5.1 失败关闭fail-closed设计上述第 9 步体现的是组件的 fail-closed 原则任何验证批次存在未解决成员时批次 final 目标都不能被关闭。其实现核心在 validation-batch.ts 的requireBatchFinalReadyexport function requireBatchFinalReady(plan: UlwLoopPlan, goal: UlwLoopItem): void { const batch batchClosedBy(plan, goal.id); if (batch undefined) return; const open batch.memberIds.filter((id) id ! goal.id !memberResolved(plan, id)); if (open.length 0) throw new UlwLoopError(Validation batch has unresolved members., ULW_LOOP_VALIDATION_BATCH_OPEN, { details: { batchId: batch.batchId, open } }); }这与requireAllValidationBatchesClosed聚合完成时要求所有批次关闭否则同样抛ULW_LOOP_VALIDATION_BATCH_OPEN共同构成双层防呆。5.2 独立评审发现的三个回归及修复口径README.md记录评审修复落在 commit80a57345f测试先行TDD三个回归点与 Task 6 的评审修复 QA 一一对应被拒批次账本rejected batch 必须只追加恰好一条带索引的steering_rejected审计源码 steering-batch.ts 的rejectedLedgerEntrymessage 形如index 0: reason接受批次账本accepted batch 用一条复数账本追加承载所有 fresh audit冲突 flag--kind与--proposals-json同时出现必须报ULW_LOOP_STEERING_BATCH_CONFLICT且 validation-batch 分支失败使用批准过的独立类型化错误码而非笼统的通用错误。评审修复 QA 的实测口径task-6.mdWhat was observed被拒批次的 goals 逐字节一致byte-identical且账本恰好多一条steering_rejected被接受批次重放时免审计audit-free由prepareBatch中的幂等键去重实现见 steering-batch.ts冲突 flag 以ULW_LOOP_STEERING_BATCH_CONFLICT失败所有 validation 错误码分支全部覆盖。对应测试cli-steering-batch.test.ts、validation-batch-checkpoint.test.ts组件测试目录test/下。6. 真实 Codex 主目录隔离验证Task 6 的第三类证据是「真实~/.codex/config.toml隔离性」在 E2E 与评审修复 QA 前后分别对用户真实~/.codex/config.toml计算 SHA-256CODEX_CONFIG_BEFORE780c740e287bda48609b5c9d5ee3ee2fc20434ce1a58c36692ec07e279a161d5 CODEX_CONFIG_AFTER780c740e287bda48609b5c9d5ee3ee2fc20434ce1a58c36692ec07e279a161d5前后哈希一致780c740e287bda48609b5c9d5ee3ee2fc20434ce1a58c36692ec07e279a161d5证明 built-CLI QA 与评审修复 QA 全程没有触碰真实 Codex 主目录配置。这正是「隔离 QA」的核心含义临时仓库 真实构建产物 不动用户环境。7. 清理与证据留档可复现的验收收尾Task 6 的最后一步是清理与归档task-6.md记录了完整清理清单历史失败尝试的临时仓库tmp.lEHDskyq7B、tmp.gGowhcocQp、tmp.1f0qwLD50a历史通过尝试的临时仓库/var/folders/.../tmp.zfDGIZoOCs评审修复失败尝试tmp.fCBvMuWI5m评审修复通过尝试tmp.q8CGMWc1hV。证据目录 .omo/evidence/20260721-ulw-loop-gajae-adoption 中Task 6 的产物包括task-6-component-gate.txt组件完整门禁原始输出40 文件 / 412 与 40 文件 / 418 两轮task-6-codex-gate.txt根级 Codex 门禁输出510 tests, 0 failurestask-6-e2e-transcript.txt真实构建 CLI 的 9 步 E2E 会话记录reviewer-fix-report.md/reviewer-fix-transcript.txt独立评审修复报告与修复后会话记录。8. 方法论总结五段式组件验收清单从 Task 6 提炼出的可复用验收模板阶段命令 / 动作判定标准组件门禁cd packages/omo-codex/plugin/components/ulw-loop npm run check npm testtsc Biome build Vitest 全绿根级门禁仓库根目录bun run test:codex全部 Codex 兼容测试通过真实 CLInode packages/omo-codex/plugin/components/ulw-loop/dist/cli.js ulw-loop ...在mktemp -dgit 仓库内完整生命周期走通、账本事件正确失败关闭隔离 session 构造未解决成员再提交批次 final checkpoint返回结构化错误码如ULW_LOOP_VALIDATION_BATCH_OPEN且退出码非 0隔离与清理QA 前后对~/.codex/config.toml求 SHA-256删除全部临时仓库哈希不变、无残留这套验收的核心原则可以浓缩为三点门禁要跑两级组件 仓库、CLI 必须用构建产物、任何用户级配置都不能被污染——这正是task-6.md判定「enough」的依据它覆盖了真实构建 CLI 表面、组件测试套件、仓库 Codex 兼容门禁、auto-advance 新路径、原子 steering 批量路径、validation-batch 关闭、聚合完成、fail-closed 拒绝、独立评审回归修复以及真实 Codex 主目录隔离。9. 局限与适用前提task-6.md的 What was omitted 明确了两条边界引用时应如实说明未跑真实 Codex app-server/TUI 探针本次 ulw-loop 任务只改动独立组件 CLI计划要求 CLI-only 本地构建 QA故未对 Codex 应用服务器/TUI 做 live 探针未使用已发布包或真实 Codex 插件缓存验收全程基于本地构建产物不是针对 npm 发布包或插件缓存路径的冒烟。因此本文全部命令与结论均以仓库当前源码与证据文件为准适用于「组件开发期本地验收」场景发布后形态的验证不在 Task 6 覆盖范围。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
omo-codex ulw-loop Task 6 收尾：gates + 真实面 QA + 证据留档实战解析
omo-codex ulw-loop Task 6 收尾gates 真实面 QA 证据留档实战解析【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent本篇文章围绕 oh-my-openagent 仓库中.omo/evidence/20260721-ulw-loop-gajae-adoption/task-6.md这份 QA 收尾记录展开系统梳理 ulw-loopUltra Work Loop多目标编排组件的「完整门禁gates→ 真实构建 CLI 生命周期 → 失败关闭fail-closed探针 → 独立评审修复 → 证据与清理」五段式验收方法论。读完本文你将掌握如何在仓库内对组件级 CLI 做全链路验收理解checkpoint自动推进、steer --proposals-json原子批量、validation-batch 批次关闭等三大被采纳功能的实测口径并能直接复现npm run check npm test、根目录bun run test:codex与隔离临时仓库 E2E 三条 QA 命令链。1. 背景gajae 采纳计划与 Task 6 的定位task-6.md属于.omo/evidence/20260721-ulw-loop-gajae-adoption/证据目录对应一份被批准执行的 ulw-loop 采纳计划adoption plan的最后一个执行任务。该目录的 README 记录了完整计划范围checkpoint 自动推进auto-advance原子化steer --proposals-jsonvalidation-batch schemavalidation-batch 的 checkpoint/steering 强制校验文档与 help 同步完整门禁与构建产物 CLI 的 QA即 Task 6 本身最终验证波次 F1–F4。其中第 1–5 项由先前的 commit 完成证据文件为task-1.md至task-5.mdTask 6 则承担「收口」职责从持久化状态恢复执行、检查并抢救遗留的未提交 diff、通过聚焦 QA 发现并修复两个真实 bugTDD 方式最后在隔离的临时 git 仓库中对真实构建出的 CLI 完成端到端验收。从代码目录结构看被验收的组件位于 packages/omo-codex/plugin/components/ulw-loop它是一个独立的 Codex 插件组件状态持久化在仓库内.omo/ulw-loop/下通过omo-agent-toolkit ulw-loopCLI 变更同时提供 CLI、skill 与四个 Codex hookUserPromptSubmit、PreToolUse create_goal、PreToolUse spawn、Stop并不暴露 MCP server。2. 验收对象被采纳的三项功能与对应 CLI 面Task 6 实测的核心面就是组件真实构建产物dist/cli.js。先交代三项被采纳功能的 CLI 契约来源于 README.md 与 package.json 的 bin 声明omo-ulw-loop/ulw/ulw-loop三个命令名均指向dist/cli.js2.1 checkpoint 自动推进auto-advanceomo-agent-toolkit ulw-loop checkpoint用证据门禁一次目标迁移默认情况下通过检查点后自动启动下一个符合条件的 goal--no-advance可保留传统的「先 checkpoint、再手动 complete-goals」两步流程。可接受--statuscomplete、failed、blocked源码 checkpoint-continuation.ts 中checkpointStatus强制校验。必填--goal-id、--evidence非空校验ulw_loop_evidence_required见 checkpoint.ts。可选--codex-goal-json、--quality-gate-json、--print-template。2.2 原子 steering 批量--proposals-jsonomo-agent-toolkit ulw-loop steer支持两类输入单个 proposal--kind ...加 kind 专属参数或--proposals-json一次性提交多个 proposal。关键约束--kind与--proposals-json互斥同时给出直接报错ULW_LOOP_STEERING_BATCH_CONFLICTcli-steering.ts。--proposals-json必须是非空 JSON 数组数组中的每条对象需包含kind、evidence、rationale并按 kind 提供相应字段goalId、title、objective、criterionId、children/childGoals、replacements、order/pendingOrder等。支持的 mutation kinds 见 cli-steering.ts 的 help 文案add_subgoal、split_subgoal、reorder_pending、revise_pending_wording、revise_criterion、annotate_ledger、mark_blocked_superseded。2.3 validation-batch 验证批次在create-goals阶段通过--validation-batch-json声明可选验证批次作为目标之间的评审边界omo-agent-toolkit ulw-loop create-goals \ --validation-batch-json [{batchId:VB001,memberIds:[G001,G002,G003],finalGoalId:G003}]解析器validation-batch.ts强制以下 schema 约束batchId、finalGoalId必填memberIds至少 2 个finalGoalId必须是本批次成员成员必须引用已存在的 goalULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN同一 goal 不能出现在多个批次ULW_LOOP_VALIDATION_BATCH_OVERLAP批次内、批次间 id 均不得重复。批次关闭batch-final的目标在完成时受三重强制checkpoint.ts validation-batch.tsrequireBatchFinalReady其他成员必须全部 resolved否则抛ULW_LOOP_VALIDATION_BATCH_OPEN批次 final checkpoint 必须提供--quality-gate-json否则抛ULW_LOOP_VALIDATION_BATCH_GATE_REQUIREDrequireBatchGate质量门禁的criteriaCoverage.totalCriteria/passCount必须与重新计算的成员 criteria 总数一致否则抛ULW_LOOP_VALIDATION_BATCH_GATE_MISMATCH。此外steering 的 split/supersede 会保持批次成员一致性并在账本中追加batch_updated条目validation-batch.ts。3. 完整门禁gates组件层与仓库层两级验收Task 6 第一类证据是两级门禁。3.1 组件完整门禁在组件目录执行cd packages/omo-codex/plugin/components/ulw-loop npm run check npm testnpm run checktsc --noEmit biome check . npm run buildpackage.jsonscripts.check其中 build 为tsc -p tsconfig.build.json bun build src/cli.ts --target node --format esm --outfile dist/cli.jsnpm test运行 Vitest。task-6-component-gate.txt记录了两次运行历史组件门禁40 个测试文件 / 412 个用例全过评审修复后的组件门禁npm run checktsc、biome 82 文件、build 均过 完整npm test40 个测试文件 / 418 个用例全过新增 6 个用例正是评审修复的回归测试。dist/cli.js的构建产物正是本任务 QA 的「真实构建 CLI 表面」。3.2 仓库根级 Codex 门禁在仓库根目录执行bun run test:codexTask 6 记录显示该门禁在最终评审前与评审修复后各跑一次均为510 个测试、0 失败。这验证了组件改动没有破坏仓库内与 Codex 兼容性相关的其余模块。4. 真实构建 CLI 的 E2E 生命周期第二类证据是「真实构建 CLI 生命周期」在全新mktemp -d的 git 仓库中直接调用构建产物node packages/omo-codex/plugin/components/ulw-loop/dist/cli.js ulw-loop ...task-6-e2e-transcript.txt完整记录了这条主链路的 9 个步骤create-goalscreate-goals --validation-batch-json VB001产出 3 个 goal batchVB001version1G001 关键 criteria checkpoint completecheckpointG001-goal-alpha-complete nextG002-goal-beta:in_progress activeG002-goal-beta——验证 auto-advance完成 G001 后自动推进到 G002原子 steering 批量steer --proposals-json提交 2 条 proposal未显式传--sourceCLI 默认sourcecli结果steer acceptedtrue results2 acceptedItems2G002非批次 final 成员完成checkpointG002-goal-beta-complete nextG003-goal-gamma:in_progress——再次验证自动推进记录剩余 criteria 并落最终质量门禁产物门禁产物位于.omo/evidence/ulw/session/G003-goal-gamma/a1覆盖coverage6/6G003 批次 final checkpointcheckpointG003-goal-gamma-complete aggregatecomplete nextomitted——G003 既是validation-batch 的 final又是aggregate 的 final一次 checkpoint 同时触发批次关闭与聚合完成最终 status --jsonstatus aggregatecomplete complete3/3 criteriaPass9/9账本 batch_closed账本中出现{kind:batch_closed,goalId:G003-goal-gamma,message:VB001}源码见 checkpoint.ts批次 final 完成时额外追加batch_closed账本条目同一临时仓库、隔离 session 下验证失败关闭当另一个成员G001-goal-alpha仍处于 pending 时尝试批次 final checkpoint命令以FAIL_CODE1退出返回结构化的ULW_LOOP_VALIDATION_BATCH_OPEN错误details.open明确列出未解决成员。关于第 4 步需要澄清一个易误读点G002 本身属于批次成员但非 final所以它的完成不触发requireBatchFinalReady只有 finalGoalIdG003的 checkpoint 才受批次关闭强制约束。5. 失败关闭探针与独立评审修复回归5.1 失败关闭fail-closed设计上述第 9 步体现的是组件的 fail-closed 原则任何验证批次存在未解决成员时批次 final 目标都不能被关闭。其实现核心在 validation-batch.ts 的requireBatchFinalReadyexport function requireBatchFinalReady(plan: UlwLoopPlan, goal: UlwLoopItem): void { const batch batchClosedBy(plan, goal.id); if (batch undefined) return; const open batch.memberIds.filter((id) id ! goal.id !memberResolved(plan, id)); if (open.length 0) throw new UlwLoopError(Validation batch has unresolved members., ULW_LOOP_VALIDATION_BATCH_OPEN, { details: { batchId: batch.batchId, open } }); }这与requireAllValidationBatchesClosed聚合完成时要求所有批次关闭否则同样抛ULW_LOOP_VALIDATION_BATCH_OPEN共同构成双层防呆。5.2 独立评审发现的三个回归及修复口径README.md记录评审修复落在 commit80a57345f测试先行TDD三个回归点与 Task 6 的评审修复 QA 一一对应被拒批次账本rejected batch 必须只追加恰好一条带索引的steering_rejected审计源码 steering-batch.ts 的rejectedLedgerEntrymessage 形如index 0: reason接受批次账本accepted batch 用一条复数账本追加承载所有 fresh audit冲突 flag--kind与--proposals-json同时出现必须报ULW_LOOP_STEERING_BATCH_CONFLICT且 validation-batch 分支失败使用批准过的独立类型化错误码而非笼统的通用错误。评审修复 QA 的实测口径task-6.mdWhat was observed被拒批次的 goals 逐字节一致byte-identical且账本恰好多一条steering_rejected被接受批次重放时免审计audit-free由prepareBatch中的幂等键去重实现见 steering-batch.ts冲突 flag 以ULW_LOOP_STEERING_BATCH_CONFLICT失败所有 validation 错误码分支全部覆盖。对应测试cli-steering-batch.test.ts、validation-batch-checkpoint.test.ts组件测试目录test/下。6. 真实 Codex 主目录隔离验证Task 6 的第三类证据是「真实~/.codex/config.toml隔离性」在 E2E 与评审修复 QA 前后分别对用户真实~/.codex/config.toml计算 SHA-256CODEX_CONFIG_BEFORE780c740e287bda48609b5c9d5ee3ee2fc20434ce1a58c36692ec07e279a161d5 CODEX_CONFIG_AFTER780c740e287bda48609b5c9d5ee3ee2fc20434ce1a58c36692ec07e279a161d5前后哈希一致780c740e287bda48609b5c9d5ee3ee2fc20434ce1a58c36692ec07e279a161d5证明 built-CLI QA 与评审修复 QA 全程没有触碰真实 Codex 主目录配置。这正是「隔离 QA」的核心含义临时仓库 真实构建产物 不动用户环境。7. 清理与证据留档可复现的验收收尾Task 6 的最后一步是清理与归档task-6.md记录了完整清理清单历史失败尝试的临时仓库tmp.lEHDskyq7B、tmp.gGowhcocQp、tmp.1f0qwLD50a历史通过尝试的临时仓库/var/folders/.../tmp.zfDGIZoOCs评审修复失败尝试tmp.fCBvMuWI5m评审修复通过尝试tmp.q8CGMWc1hV。证据目录 .omo/evidence/20260721-ulw-loop-gajae-adoption 中Task 6 的产物包括task-6-component-gate.txt组件完整门禁原始输出40 文件 / 412 与 40 文件 / 418 两轮task-6-codex-gate.txt根级 Codex 门禁输出510 tests, 0 failurestask-6-e2e-transcript.txt真实构建 CLI 的 9 步 E2E 会话记录reviewer-fix-report.md/reviewer-fix-transcript.txt独立评审修复报告与修复后会话记录。8. 方法论总结五段式组件验收清单从 Task 6 提炼出的可复用验收模板阶段命令 / 动作判定标准组件门禁cd packages/omo-codex/plugin/components/ulw-loop npm run check npm testtsc Biome build Vitest 全绿根级门禁仓库根目录bun run test:codex全部 Codex 兼容测试通过真实 CLInode packages/omo-codex/plugin/components/ulw-loop/dist/cli.js ulw-loop ...在mktemp -dgit 仓库内完整生命周期走通、账本事件正确失败关闭隔离 session 构造未解决成员再提交批次 final checkpoint返回结构化错误码如ULW_LOOP_VALIDATION_BATCH_OPEN且退出码非 0隔离与清理QA 前后对~/.codex/config.toml求 SHA-256删除全部临时仓库哈希不变、无残留这套验收的核心原则可以浓缩为三点门禁要跑两级组件 仓库、CLI 必须用构建产物、任何用户级配置都不能被污染——这正是task-6.md判定「enough」的依据它覆盖了真实构建 CLI 表面、组件测试套件、仓库 Codex 兼容门禁、auto-advance 新路径、原子 steering 批量路径、validation-batch 关闭、聚合完成、fail-closed 拒绝、独立评审回归修复以及真实 Codex 主目录隔离。9. 局限与适用前提task-6.md的 What was omitted 明确了两条边界引用时应如实说明未跑真实 Codex app-server/TUI 探针本次 ulw-loop 任务只改动独立组件 CLI计划要求 CLI-only 本地构建 QA故未对 Codex 应用服务器/TUI 做 live 探针未使用已发布包或真实 Codex 插件缓存验收全程基于本地构建产物不是针对 npm 发布包或插件缓存路径的冒烟。因此本文全部命令与结论均以仓库当前源码与证据文件为准适用于「组件开发期本地验收」场景发布后形态的验证不在 Task 6 覆盖范围。【免费下载链接】oh-my-openagentOmO: Just type mass ulw keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考