OmO codex-ulw-loop 验证批次validation-batch强制机制落地实录checkpoint 关闭门禁与 steering 成员一致性保障【免费下载链接】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导读本文基于仓库中 .omo/evidence/20260721-ulw-loop-gajae-adoption/task-4.md 这份 TDD 证据文档完整还原 OmO 项目omo-codex插件组件ulw-loop中**验证批次validation-batch**功能的落地过程先以两条失败测试定义问题RED再通过组件门禁GREEN最后在真实构建的 CLI 上做场景化 QA。读者将掌握验证批次的 schema 定义、checkpoint 关闭时的四类强制门禁open 成员、批次 gate 必需、criteria 全 pass、coverage 计数一致、steering split 后的批次成员同步更新以及如何在本地复现这一整套验证。背景validation-batch 在 ulw-loop 中的角色ulw-loop是 OmO 仓库中omo-codex插件的核心组件用于durable repo-native 多目标编排把一次复杂任务拆成多个 goal目标每个 goal 带嵌入式 success criteria成功标准与可观测证据审计状态存放在仓库内的.omo/ulw-loop/目录全部状态变更经由omo-agent-toolkit ulw-loopCLI 完成。组件能力总览见 packages/omo-codex/plugin/components/ulw-loop/README.md。验证批次是评审边界review boundary当若干 goal 必须作为一个整体接受最终评审、不能单独放行时就在计划创建时用--validation-batch-json声明一个批次指定成员memberIds与批次最终目标finalGoalId。批次最终目标只有在所有其他成员都已完结或经 supersede 解析、所有成员 criteria 全部 pass、且提交的 quality gate 覆盖率与重算结果一致的前提下才允许 checkpoint 完成——这就是 task-4 中batch-final checkpoint 拒绝开放成员 / 要求批次 gate / gate criteria 与 coverage 校验三项 RED 失败点背后的诉求。task-4 所属的采纳计划.omo/evidence/20260721-ulw-loop-gajae-adoption/README.md共覆盖七项内容本文聚焦第 4 项validation-batch 的 checkpoint/steering 强制。RED先用失败定义行为契约task-4 的 RED 阶段使用两条精确命中的测试命令npm test -- validation-batch-checkpoint npm test -- steering-batch实现前观察到的失败行为有三条它们共同构成了本功能的验收契约批次最终 checkpoint 未拒绝开放成员、也未要求批次 gate即G002finalGoalId可以在G001仍 pending 时直接完成也没有强制要求提交--quality-gate-json。批次 gate 的 criteria/coverage 校验缺失提交的 quality gate 中criteriaCoverage的totalCriteria/passCount可以随意填系统不与批次成员的真实 criteria 状态比对。拆分批次成员不更新 validation-batch 成员、也不发batch_updated对批次成员执行steer --proposals-json的 split 后批次成员列表仍指向被拆分的旧 goal账本ledger里也没有对应记录。对应的测试文件与用例位于 packages/omo-codex/plugin/components/ulw-loop/test/validation-batch-checkpoint.test.tsvalidation-batch checkpoint enforcementdescribe 块与 packages/omo-codex/plugin/components/ulw-loop/test/steering-batch.test.ts。测试采用given/when/then注释风格例如首个用例#given an open batch member #when completing the batch final goal #then rejects with batch open。GREEN组件门禁与实现落点GREEN 阶段执行更宽的门禁命令npm test -- validation-batch-checkpoint steering-batch steering plan-io checkpoint npm run typecheck npm run build观察到的结果task-4 原始记录14 个测试文件、143 个测试全部通过TypeScript strict 检查通过npm run typecheck执行tsc --noEmit构建通过纯 LOCpure LOC审计checkpoint.ts249 行、steering.ts203 行、steering-mutations.ts52 行、validation-batch.ts104 行——四个文件顶部都带biome-ignore-all format注释表明受纯 LOC 预算约束刻意保持紧凑。实现落点集中在omo-codex插件组件的ulw-loop/src目录下四个模块职责划分清晰模块职责validation-batch.ts批次解析、schema 校验、批次查询、批次强制门禁checkpoint.tscheckpoint 流程编排串起批次关闭门禁与 quality gatesteering.tssteering 提案校验与原子应用追加batch_updated账本steering-mutations.ts具体变更原语含 split/supersede 后批次成员同步核心机制一批次 schema 与解析校验批次通过--validation-batch-json以 JSON 数组形式传入例如 README 中的声明方式omo-agent-toolkit ulw-loop create-goals \ --validation-batch-json [{batchId:VB001,memberIds:[G001,G002],finalGoalId:G002}]validation-batch.ts 中的parseValidationBatches逐项做结构化解析违反任一规则即抛出带类型码的UlwLoopError必须是 JSON 数组否则报--validation-batch-json must be a JSON array.每个条目必须是对象且三个字段齐全batchId、memberIds至少两个成员、finalGoalIdbatchId全局唯一重复报duplicate validation batch id同一批次内memberIds不得重复finalGoalId必须是本批次成员否则报ULW_LOOP_VALIDATION_BATCH_FINAL_NOT_MEMBER成员必须存在于计划 goal 中否则报ULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN同一 goal 不得出现在多个批次中否则报ULW_LOOP_VALIDATION_BATCH_OVERLAP。这些校验在计划创建create-goals时即完成保证后续 checkpoint/steering 阶段拿到的批次结构是合法、无重叠、可闭合的。核心机制二checkpoint 关闭时的批次强制checkpoint命令的完整执行路径在 checkpoint.ts 的checkpointUlwLoop。当目标 goal 是某批次的 finalGoalId由batchClosedBy判定时进入强制逻辑1. 开放成员拒绝batch open gateif (closesBatch) requireBatchFinalReady(plan, goal);requireBatchFinalReady会找出批次中除自身外所有未解析未 complete、未被 supersede 解析的成员只要有任何一个开放就抛出ULW_LOOP_VALIDATION_BATCH_OPEN错误详情携带batchId与开放成员列表open方便 Agent 定位还需处理哪些 goal。2. 批次 gate 必需gate requiredif (closesBatch args.qualityGateJson undefined) throw new UlwLoopError(Validation batch final checkpoint requires --quality-gate-json., ULW_LOOP_VALIDATION_BATCH_GATE_REQUIRED);批次最终 checkpoint 不再接受只交 evidence的简化路径必须显式提交--quality-gate-json否则直接失败ULW_LOOP_VALIDATION_BATCH_GATE_REQUIRED。3. criteria 全 pass 与 coverage 一致gate 内容校验quality gate 解析成功后requireBatchGate(plan, goal, qualityGate)做两道校验遍历批次全部成员的成功标准只要存在status ! pass的 criterion即报ULW_LOOP_VALIDATION_BATCH_CRITERIA_PENDING错误详情列出所有memberId:criterionId将 gate 中criteriaCoverage.totalCriteria/passCount与批次成员真实 criteria 数量、pass 数量逐一比对不一致报ULW_LOOP_VALIDATION_BATCH_GATE_MISMATCH并把expected重算值与actual提交值一并放进详情。质量 gate 本身要求的字段manualQa、gateReview、iteration、criteriaCoveragelazycodex 面额外接受codeReview在 checkpoint.ts 调用validateQualityGate时统一校验完整 gate 示例见组件 README.md。4. 收尾账本通过全部门禁后checkpoint 会额外追加一条batch_closed账本记录if (closedBatch ! undefined) entries.push({ at: now, kind: batch_closed, goalId: goal.id, message: closedBatch.batchId });批次闭合与run 最终目标闭合aggregate completion可以叠加当批次 finalGoal 同时也是整个计划的最后一个 goal 时requireAllValidationBatchesClosed还会从全局角度拒绝任何仍开放的批次两条路径批内视角 全局视角共同兜底。核心机制三steering 后的批次成员一致性批次成员被 split 或 supersede 时批次定义必须同步演进否则批次关闭门禁会引用已失效的 goal id。这条链路在 steering-mutations.ts 的splitOrBlocktarget.steeringStatus superseded; target.supersededBy replacements.map((item) item.id); // ... updateBatchesAfterSupersede(plan, target.id, replacements.map((item) item.id));updateBatchesAfterSupersedevalidation-batch.ts的核心行为若批次成员包含被拆分的 target用replacementIds原位替换若 target 本身就是finalGoalId则 finalGoalId 顺延为最后一个替换成员replacementIds[replacementIds.length - 1]其余成员含非 final 成员的 finalGoalId 保持原值保持batchId不变批次标识稳定可追踪。而在 steering.ts 的steerUlwLoop中任何被接受的 steering 变更都会通过batchUpdateLedgerEntry比较变更前后的validationBatches序列化结果只要成员发生变动就追加一条batch_updated账本{ at, kind: batch_updated, before: [...], after: [...], message: Validation batch membership updated after steering. }这就修复了 RED 阶段的第三个失败点split 后批次成员更新 账本可审计二者缺一不可。Real-surface QA真实 CLI 场景复现GREEN 门禁通过后task-4 用真实构建产物做了黑盒验证构建出dist/cli.js在每个mktemp生成的全新 git 仓库中运行避免污染真实工作区对应 README.md 中隔离 temp git repo、验证后清理的要求。场景一开放成员拒绝放行创建含 3 个 goal 的计划声明批次VB001成员为G001-goal-alpha与G002-goal-beta其中G002为 finalGoalId在G001-goal-alpha仍 pending 时尝试对G002-goal-beta执行 checkpoint 完成观察结果CLI 以 JSON 错误返回错误码为ULW_LOOP_VALIDATION_BATCH_OPEN。场景二split 后的批次成员同步创建同样的 3-goal 计划与批次对G001-goal-alpha执行steer --proposals-json的 split 操作观察结果批次memberIds从G001-goal-alpha, G002-goal-beta更新为G004, G002-goal-betaG001-goal-alpha被移除新生成的G004顶替其位置——新 id 由steering-mutations.ts中nextId按G\d{3}规则顺延生成。两个场景的断言输出transcript summarybatch open gate ok ULW_LOOP_VALIDATION_BATCH_OPEN batch split update ok G004,G002-goal-beta本地复现与验证在组件目录复现 task-4 全部门禁cd packages/omo-codex/plugin/components/ulw-loop # 1. 单元/组件测试含 validation-batch 与 steering 全链路 npm test -- validation-batch-checkpoint steering-batch steering plan-io checkpoint # 2. TypeScript strict 检查 npm run typecheck # 3. 构建 npm run build如需观察真实 CLI 行为可按组件 README.md 的 Local Development 流程npm install后构建dist/cli.js在mktemp -d的临时 git 仓库中重复上面两个 QA 场景。批次 schema 的字段约束至少两个成员、finalGoalId 必须是成员、成员不跨批次重叠等可在 validation-batch.ts 的validateBatches中逐条核对作为自己编写批次 JSON 的校验依据。错误码速查错误码触发条件位置ULW_LOOP_VALIDATION_BATCH_INVALID批次 JSON 结构非法非数组/非对象/字段缺失validation-batch.tsULW_LOOP_VALIDATION_BATCH_FINAL_NOT_MEMBERfinalGoalId 不在 memberIds 中同上ULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN成员引用不存在的 goal同上ULW_LOOP_VALIDATION_BATCH_OVERLAPgoal 出现在多个批次同上ULW_LOOP_VALIDATION_BATCH_OPEN批次 final 完结时仍有开放成员 / 全局仍有开放批次validation-batch.ts checkpoint.tsULW_LOOP_VALIDATION_BATCH_GATE_REQUIRED批次 final checkpoint 未传--quality-gate-jsoncheckpoint.tsULW_LOOP_VALIDATION_BATCH_CRITERIA_PENDING批次成员存在未 pass 的 criterionvalidation-batch.tsULW_LOOP_VALIDATION_BATCH_GATE_MISMATCHgate coverage 计数与成员 criteria 重算结果不一致validation-batch.ts小结从 task-4 的 TDD 证据可以看到validation-batch 强制机制是一套声明-校验-闭合闭环create-goals阶段通过--validation-batch-json声明评审边界并做 schema 校验checkpoint 阶段以四层门禁开放成员、gate 必需、criteria 全 pass、coverage 一致保证批次作为一个整体才能放行steering 阶段通过updateBatchesAfterSupersede与batch_updated账本维持批次成员随拆分/替换同步演进。任何违规都会以带类型码的 JSON 错误失败天然适合 Agent 与自动化流水线捕获并继续处理。这套机制的测试证据validation-batch-checkpoint.test.ts、steering-batch.test.ts、validation-batch.test.ts、cli-validation-batch.test.ts与证据文档 task-4.md 相互印证可作为后续扩展批次语义如多批次串行、嵌套评审边界的基线。【免费下载链接】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 验证批次（validation-batch）强制机制落地实录：checkpoint 关闭门禁与 steering 成员一致性保障
OmO codex-ulw-loop 验证批次validation-batch强制机制落地实录checkpoint 关闭门禁与 steering 成员一致性保障【免费下载链接】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导读本文基于仓库中 .omo/evidence/20260721-ulw-loop-gajae-adoption/task-4.md 这份 TDD 证据文档完整还原 OmO 项目omo-codex插件组件ulw-loop中**验证批次validation-batch**功能的落地过程先以两条失败测试定义问题RED再通过组件门禁GREEN最后在真实构建的 CLI 上做场景化 QA。读者将掌握验证批次的 schema 定义、checkpoint 关闭时的四类强制门禁open 成员、批次 gate 必需、criteria 全 pass、coverage 计数一致、steering split 后的批次成员同步更新以及如何在本地复现这一整套验证。背景validation-batch 在 ulw-loop 中的角色ulw-loop是 OmO 仓库中omo-codex插件的核心组件用于durable repo-native 多目标编排把一次复杂任务拆成多个 goal目标每个 goal 带嵌入式 success criteria成功标准与可观测证据审计状态存放在仓库内的.omo/ulw-loop/目录全部状态变更经由omo-agent-toolkit ulw-loopCLI 完成。组件能力总览见 packages/omo-codex/plugin/components/ulw-loop/README.md。验证批次是评审边界review boundary当若干 goal 必须作为一个整体接受最终评审、不能单独放行时就在计划创建时用--validation-batch-json声明一个批次指定成员memberIds与批次最终目标finalGoalId。批次最终目标只有在所有其他成员都已完结或经 supersede 解析、所有成员 criteria 全部 pass、且提交的 quality gate 覆盖率与重算结果一致的前提下才允许 checkpoint 完成——这就是 task-4 中batch-final checkpoint 拒绝开放成员 / 要求批次 gate / gate criteria 与 coverage 校验三项 RED 失败点背后的诉求。task-4 所属的采纳计划.omo/evidence/20260721-ulw-loop-gajae-adoption/README.md共覆盖七项内容本文聚焦第 4 项validation-batch 的 checkpoint/steering 强制。RED先用失败定义行为契约task-4 的 RED 阶段使用两条精确命中的测试命令npm test -- validation-batch-checkpoint npm test -- steering-batch实现前观察到的失败行为有三条它们共同构成了本功能的验收契约批次最终 checkpoint 未拒绝开放成员、也未要求批次 gate即G002finalGoalId可以在G001仍 pending 时直接完成也没有强制要求提交--quality-gate-json。批次 gate 的 criteria/coverage 校验缺失提交的 quality gate 中criteriaCoverage的totalCriteria/passCount可以随意填系统不与批次成员的真实 criteria 状态比对。拆分批次成员不更新 validation-batch 成员、也不发batch_updated对批次成员执行steer --proposals-json的 split 后批次成员列表仍指向被拆分的旧 goal账本ledger里也没有对应记录。对应的测试文件与用例位于 packages/omo-codex/plugin/components/ulw-loop/test/validation-batch-checkpoint.test.tsvalidation-batch checkpoint enforcementdescribe 块与 packages/omo-codex/plugin/components/ulw-loop/test/steering-batch.test.ts。测试采用given/when/then注释风格例如首个用例#given an open batch member #when completing the batch final goal #then rejects with batch open。GREEN组件门禁与实现落点GREEN 阶段执行更宽的门禁命令npm test -- validation-batch-checkpoint steering-batch steering plan-io checkpoint npm run typecheck npm run build观察到的结果task-4 原始记录14 个测试文件、143 个测试全部通过TypeScript strict 检查通过npm run typecheck执行tsc --noEmit构建通过纯 LOCpure LOC审计checkpoint.ts249 行、steering.ts203 行、steering-mutations.ts52 行、validation-batch.ts104 行——四个文件顶部都带biome-ignore-all format注释表明受纯 LOC 预算约束刻意保持紧凑。实现落点集中在omo-codex插件组件的ulw-loop/src目录下四个模块职责划分清晰模块职责validation-batch.ts批次解析、schema 校验、批次查询、批次强制门禁checkpoint.tscheckpoint 流程编排串起批次关闭门禁与 quality gatesteering.tssteering 提案校验与原子应用追加batch_updated账本steering-mutations.ts具体变更原语含 split/supersede 后批次成员同步核心机制一批次 schema 与解析校验批次通过--validation-batch-json以 JSON 数组形式传入例如 README 中的声明方式omo-agent-toolkit ulw-loop create-goals \ --validation-batch-json [{batchId:VB001,memberIds:[G001,G002],finalGoalId:G002}]validation-batch.ts 中的parseValidationBatches逐项做结构化解析违反任一规则即抛出带类型码的UlwLoopError必须是 JSON 数组否则报--validation-batch-json must be a JSON array.每个条目必须是对象且三个字段齐全batchId、memberIds至少两个成员、finalGoalIdbatchId全局唯一重复报duplicate validation batch id同一批次内memberIds不得重复finalGoalId必须是本批次成员否则报ULW_LOOP_VALIDATION_BATCH_FINAL_NOT_MEMBER成员必须存在于计划 goal 中否则报ULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN同一 goal 不得出现在多个批次中否则报ULW_LOOP_VALIDATION_BATCH_OVERLAP。这些校验在计划创建create-goals时即完成保证后续 checkpoint/steering 阶段拿到的批次结构是合法、无重叠、可闭合的。核心机制二checkpoint 关闭时的批次强制checkpoint命令的完整执行路径在 checkpoint.ts 的checkpointUlwLoop。当目标 goal 是某批次的 finalGoalId由batchClosedBy判定时进入强制逻辑1. 开放成员拒绝batch open gateif (closesBatch) requireBatchFinalReady(plan, goal);requireBatchFinalReady会找出批次中除自身外所有未解析未 complete、未被 supersede 解析的成员只要有任何一个开放就抛出ULW_LOOP_VALIDATION_BATCH_OPEN错误详情携带batchId与开放成员列表open方便 Agent 定位还需处理哪些 goal。2. 批次 gate 必需gate requiredif (closesBatch args.qualityGateJson undefined) throw new UlwLoopError(Validation batch final checkpoint requires --quality-gate-json., ULW_LOOP_VALIDATION_BATCH_GATE_REQUIRED);批次最终 checkpoint 不再接受只交 evidence的简化路径必须显式提交--quality-gate-json否则直接失败ULW_LOOP_VALIDATION_BATCH_GATE_REQUIRED。3. criteria 全 pass 与 coverage 一致gate 内容校验quality gate 解析成功后requireBatchGate(plan, goal, qualityGate)做两道校验遍历批次全部成员的成功标准只要存在status ! pass的 criterion即报ULW_LOOP_VALIDATION_BATCH_CRITERIA_PENDING错误详情列出所有memberId:criterionId将 gate 中criteriaCoverage.totalCriteria/passCount与批次成员真实 criteria 数量、pass 数量逐一比对不一致报ULW_LOOP_VALIDATION_BATCH_GATE_MISMATCH并把expected重算值与actual提交值一并放进详情。质量 gate 本身要求的字段manualQa、gateReview、iteration、criteriaCoveragelazycodex 面额外接受codeReview在 checkpoint.ts 调用validateQualityGate时统一校验完整 gate 示例见组件 README.md。4. 收尾账本通过全部门禁后checkpoint 会额外追加一条batch_closed账本记录if (closedBatch ! undefined) entries.push({ at: now, kind: batch_closed, goalId: goal.id, message: closedBatch.batchId });批次闭合与run 最终目标闭合aggregate completion可以叠加当批次 finalGoal 同时也是整个计划的最后一个 goal 时requireAllValidationBatchesClosed还会从全局角度拒绝任何仍开放的批次两条路径批内视角 全局视角共同兜底。核心机制三steering 后的批次成员一致性批次成员被 split 或 supersede 时批次定义必须同步演进否则批次关闭门禁会引用已失效的 goal id。这条链路在 steering-mutations.ts 的splitOrBlocktarget.steeringStatus superseded; target.supersededBy replacements.map((item) item.id); // ... updateBatchesAfterSupersede(plan, target.id, replacements.map((item) item.id));updateBatchesAfterSupersedevalidation-batch.ts的核心行为若批次成员包含被拆分的 target用replacementIds原位替换若 target 本身就是finalGoalId则 finalGoalId 顺延为最后一个替换成员replacementIds[replacementIds.length - 1]其余成员含非 final 成员的 finalGoalId 保持原值保持batchId不变批次标识稳定可追踪。而在 steering.ts 的steerUlwLoop中任何被接受的 steering 变更都会通过batchUpdateLedgerEntry比较变更前后的validationBatches序列化结果只要成员发生变动就追加一条batch_updated账本{ at, kind: batch_updated, before: [...], after: [...], message: Validation batch membership updated after steering. }这就修复了 RED 阶段的第三个失败点split 后批次成员更新 账本可审计二者缺一不可。Real-surface QA真实 CLI 场景复现GREEN 门禁通过后task-4 用真实构建产物做了黑盒验证构建出dist/cli.js在每个mktemp生成的全新 git 仓库中运行避免污染真实工作区对应 README.md 中隔离 temp git repo、验证后清理的要求。场景一开放成员拒绝放行创建含 3 个 goal 的计划声明批次VB001成员为G001-goal-alpha与G002-goal-beta其中G002为 finalGoalId在G001-goal-alpha仍 pending 时尝试对G002-goal-beta执行 checkpoint 完成观察结果CLI 以 JSON 错误返回错误码为ULW_LOOP_VALIDATION_BATCH_OPEN。场景二split 后的批次成员同步创建同样的 3-goal 计划与批次对G001-goal-alpha执行steer --proposals-json的 split 操作观察结果批次memberIds从G001-goal-alpha, G002-goal-beta更新为G004, G002-goal-betaG001-goal-alpha被移除新生成的G004顶替其位置——新 id 由steering-mutations.ts中nextId按G\d{3}规则顺延生成。两个场景的断言输出transcript summarybatch open gate ok ULW_LOOP_VALIDATION_BATCH_OPEN batch split update ok G004,G002-goal-beta本地复现与验证在组件目录复现 task-4 全部门禁cd packages/omo-codex/plugin/components/ulw-loop # 1. 单元/组件测试含 validation-batch 与 steering 全链路 npm test -- validation-batch-checkpoint steering-batch steering plan-io checkpoint # 2. TypeScript strict 检查 npm run typecheck # 3. 构建 npm run build如需观察真实 CLI 行为可按组件 README.md 的 Local Development 流程npm install后构建dist/cli.js在mktemp -d的临时 git 仓库中重复上面两个 QA 场景。批次 schema 的字段约束至少两个成员、finalGoalId 必须是成员、成员不跨批次重叠等可在 validation-batch.ts 的validateBatches中逐条核对作为自己编写批次 JSON 的校验依据。错误码速查错误码触发条件位置ULW_LOOP_VALIDATION_BATCH_INVALID批次 JSON 结构非法非数组/非对象/字段缺失validation-batch.tsULW_LOOP_VALIDATION_BATCH_FINAL_NOT_MEMBERfinalGoalId 不在 memberIds 中同上ULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN成员引用不存在的 goal同上ULW_LOOP_VALIDATION_BATCH_OVERLAPgoal 出现在多个批次同上ULW_LOOP_VALIDATION_BATCH_OPEN批次 final 完结时仍有开放成员 / 全局仍有开放批次validation-batch.ts checkpoint.tsULW_LOOP_VALIDATION_BATCH_GATE_REQUIRED批次 final checkpoint 未传--quality-gate-jsoncheckpoint.tsULW_LOOP_VALIDATION_BATCH_CRITERIA_PENDING批次成员存在未 pass 的 criterionvalidation-batch.tsULW_LOOP_VALIDATION_BATCH_GATE_MISMATCHgate coverage 计数与成员 criteria 重算结果不一致validation-batch.ts小结从 task-4 的 TDD 证据可以看到validation-batch 强制机制是一套声明-校验-闭合闭环create-goals阶段通过--validation-batch-json声明评审边界并做 schema 校验checkpoint 阶段以四层门禁开放成员、gate 必需、criteria 全 pass、coverage 一致保证批次作为一个整体才能放行steering 阶段通过updateBatchesAfterSupersede与batch_updated账本维持批次成员随拆分/替换同步演进。任何违规都会以带类型码的 JSON 错误失败天然适合 Agent 与自动化流水线捕获并继续处理。这套机制的测试证据validation-batch-checkpoint.test.ts、steering-batch.test.ts、validation-batch.test.ts、cli-validation-batch.test.ts与证据文档 task-4.md 相互印证可作为后续扩展批次语义如多批次串行、嵌套评审边界的基线。【免费下载链接】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），仅供参考