企业官网建设流程全解析

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-loop（Ultra 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 记录了完整计划范围：

1. checkpoint 自动推进（auto-advance）；
2. 原子化steer --proposals-json；
3. validation-batch schema；
4. validation-batch 的 checkpoint/steering 强制校验；
5. 文档与 help 同步；
6. 完整门禁与构建产物 CLI 的 QA（即 Task 6 本身）；
7. 最终验证波次 F1–F4。

其中第 1–5 项由先前的 commit 完成，证据文件为task-1.md至task-5.md；Task 6 则承担「收口」职责：从持久化状态恢复执行、检查并抢救遗留的未提交 diff、通过聚焦 QA 发现并修复两个真实 bug（TDD 方式），最后在隔离的临时 git 仓库中对真实构建出的 CLI 完成端到端验收。

从代码目录结构看，被验收的组件位于 packages/omo-codex/plugin/components/ulw-loop，它是一个独立的 Codex 插件组件：状态持久化在仓库内.omo/ulw-loop/下，通过omo-agent-toolkit ulw-loopCLI 变更，同时提供 CLI、skill 与四个 Codex hook（UserPromptSubmit、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.js）：

2.1 checkpoint 自动推进（auto-advance）

omo-agent-toolkit ulw-loop checkpoint用证据门禁一次目标迁移；默认情况下，通过检查点后自动启动下一个符合条件的 goal，--no-advance可保留传统的「先 checkpoint、再手动 complete-goals」两步流程。

• 可接受--status：complete、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-json）

omo-agent-toolkit ulw-loop steer支持两类输入：单个 proposal（--kind ...加 kind 专属参数）或--proposals-json一次性提交多个 proposal。关键约束：--kind与--proposals-json互斥，同时给出直接报错ULW_LOOP_STEERING_BATCH_CONFLICT（cli-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必须是本批次成员；
• 成员必须引用已存在的 goal（ULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN）；
• 同一 goal 不能出现在多个批次（ULW_LOOP_VALIDATION_BATCH_OVERLAP）；
• 批次内、批次间 id 均不得重复。

批次关闭（batch-final）的目标在完成时受三重强制（checkpoint.ts + validation-batch.ts）：

1. requireBatchFinalReady：其他成员必须全部 resolved，否则抛ULW_LOOP_VALIDATION_BATCH_OPEN；
2. 批次 final checkpoint 必须提供--quality-gate-json，否则抛ULW_LOOP_VALIDATION_BATCH_GATE_REQUIRED；
3. requireBatchGate：质量门禁的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 test

• npm run check=tsc --noEmit && biome check . && npm run build（package.jsonscripts.check），其中 build 为tsc -p tsconfig.build.json && bun build src/cli.ts --target node --format esm --outfile dist/cli.js；
• npm test运行 Vitest。

task-6-component-gate.txt记录了两次运行：

• 历史组件门禁：40 个测试文件 / 412 个用例全过；
• 评审修复后的组件门禁：npm run check（tsc、biome 82 文件、build 均过）+ 完整npm test：40 个测试文件 / 418 个用例全过（新增 6 个用例正是评审修复的回归测试）。

dist/cli.js的构建产物正是本任务 QA 的「真实构建 CLI 表面」。

3.2 仓库根级 Codex 门禁

在仓库根目录执行：

bun run test:codex

Task 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 个步骤：

1. create-goals：create-goals --validation-batch-json VB001，产出 3 个 goal +batch=VB001，version=1；
2. G001 关键 criteria + checkpoint complete：checkpoint=G001-goal-alpha->complete next=G002-goal-beta:in_progress active=G002-goal-beta——验证 auto-advance：完成 G001 后自动推进到 G002；
3. 原子 steering 批量：steer --proposals-json提交 2 条 proposal（未显式传--source，CLI 默认source=cli），结果steer accepted=true results=2 acceptedItems=2；
4. G002（非批次 final 成员）完成：checkpoint=G002-goal-beta->complete next=G003-goal-gamma:in_progress——再次验证自动推进；
5. 记录剩余 criteria 并落最终质量门禁产物：门禁产物位于.omo/evidence/ulw/session/G003-goal-gamma/a1，覆盖coverage=6/6；
6. G003 批次 final checkpoint：checkpoint=G003-goal-gamma->complete aggregate=complete next=omitted——G003 既是validation-batch 的 final又是aggregate 的 final，一次 checkpoint 同时触发批次关闭与聚合完成；
7. 最终 status --json：status aggregate=complete complete=3/3 criteriaPass=9/9；
8. 账本 batch_closed：账本中出现{"kind":"batch_closed","goalId":"G003-goal-gamma","message":"VB001"}（源码见 checkpoint.ts：批次 final 完成时额外追加batch_closed账本条目）；
9. 同一临时仓库、隔离 session 下验证失败关闭：当另一个成员（G001-goal-alpha）仍处于 pending 时尝试批次 final checkpoint，命令以FAIL_CODE=1退出，返回结构化的ULW_LOOP_VALIDATION_BATCH_OPEN错误，details.open明确列出未解决成员。

关于第 4 步需要澄清一个易误读点：G002 本身属于批次成员但非 final，所以它的完成不触发requireBatchFinalReady；只有 finalGoalId（G003）的 checkpoint 才受批次关闭强制约束。

5. 失败关闭探针与独立评审修复回归

5.1 失败关闭（fail-closed）设计

上述第 9 步体现的是组件的 fail-closed 原则：任何验证批次存在未解决成员时，批次 final 目标都不能被关闭。其实现核心在 validation-batch.ts 的requireBatchFinalReady：

export 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 一一对应：

1. 被拒批次账本：rejected batch 必须只追加恰好一条带索引的steering_rejected审计（源码 steering-batch.ts 的rejectedLedgerEntry，message 形如index 0: <reason>）；
2. 接受批次账本：accepted batch 用一条复数账本追加承载所有 fresh audit；
3. 冲突 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-256：

CODEX_CONFIG_BEFORE=780c740e287bda48609b5c9d5ee3ee2fc20434ce1a58c36692ec07e279a161d5 CODEX_CONFIG_AFTER=780c740e287bda48609b5c9d5ee3ee2fc20434ce1a58c36692ec07e279a161d5

前后哈希一致（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 failures）；
• task-6-e2e-transcript.txt：真实构建 CLI 的 9 步 E2E 会话记录；
• reviewer-fix-report.md/reviewer-fix-transcript.txt：独立评审修复报告与修复后会话记录。

8. 方法论总结：五段式组件验收清单

从 Task 6 提炼出的可复用验收模板：

这套验收的核心原则可以浓缩为三点：门禁要跑两级（组件 + 仓库）、CLI 必须用构建产物、任何用户级配置都不能被污染——这正是task-6.md判定「enough」的依据：它覆盖了真实构建 CLI 表面、组件测试套件、仓库 Codex 兼容门禁、auto-advance 新路径、原子 steering 批量路径、validation-batch 关闭、聚合完成、fail-closed 拒绝、独立评审回归修复以及真实 Codex 主目录隔离。

9. 局限与适用前提

task-6.md的 What was omitted 明确了两条边界，引用时应如实说明：

1. 未跑真实 Codex app-server/TUI 探针：本次 ulw-loop 任务只改动独立组件 CLI，计划要求 CLI-only 本地构建 QA，故未对 Codex 应用服务器/TUI 做 live 探针；
2. 未使用已发布包或真实 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