尧图网站建设 
oh-my-openagent ulw-loop validation-batch Schema 解析审查边界的声明、校验与强制执行【免费下载链接】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导读本文以仓库中 ulw-loop gajae-adoption 证据集 的task-3.md证据为主线深入剖析 oh-my-openagent 的omo-codex插件组件ulw-loop中 validation-batch验证批次schema 的完整设计它如何在创建计划时声明审查边界review boundary、在解析期执行哪些结构性校验、产生哪些带类型错误码的失败分支以及如何在 checkpoint/steering 流程中被强制执行。读完本文你将掌握--validation-batch-json的 JSON 结构、五个校验错误码的触发条件以及对应源码与测试证据的定位方式。一、什么是 validation-batch比普通完成门槛更严格的审查边界在ulw-loopdurable repo-native multi-goal orchestration组件中普通目标goal的完成只需通过checkpoint解析的质量门quality gate。而 validation-batch 是可选的审查边界它把一组目标捆绑为一个批次声明其中一个是批次最终目标finalGoalId并约定——只有该批次内其他成员目标全部完成或 superseded-resolved、所有成员的成功准则success criteria全部 pass、且质量门的覆盖计数与重算的成员准则一致时批次最终目标才允许关闭。组件 README 中的定义packages/omo-codex/plugin/components/ulw-loop/README.md明确指出Validation batches are optional review boundaries declared at plan creation with--validation-batch-json. The batch-final goal cannot complete until every other member is complete or superseded-resolved, every member criterion is pass, and a quality gates coverage counts match the recomputed member criteria.也就是说validation-batch 是更严格的完成门stricter review boundaries而不是更弱的完成门——这一点在 task-5 文档同步证据 中被作为验收要求单独确认Confirmed validation batches are described as stricter review boundaries, not weaker completion gates.二、声明方式create-goals 的 --validation-batch-json 参数2.1 CLI 入口validation-batch 在创建计划plan时一次性声明通过create-goals子命令的--validation-batch-json参数传入。CLI 参数在 cli-arg-parser.ts 中被登记为带值 flagVALUE_FLAGS中包含--validation-batch-json并由 cli-subcommands.ts 的createGoals读取后透传给领域层const validationBatchesJson readValue(argv, --validation-batch-json); // ... ...(validationBatchesJson undefined ? {} : { validationBatchesJson }),基本用法来自 task-3 的真实 QA 命令omo-agent-toolkit ulw-loop create-goals \ --brief $- Goal alpha\n- Goal beta \ --validation-batch-json [{batchId:VB001,memberIds:[G001-goal-alpha,G002-goal-beta],finalGoalId:G002-goal-beta}] \ --json2.2 JSON schema三个必填字段每个批次对象只有三个字段结构非常精简源码 validation-batch.ts字段类型约束含义batchIdstring必填、非空白、批次内唯一批次标识如VB001memberIdsstring[]必填、至少 2 个、元素非空白、批次内不重复参与该批次的成员目标 idfinalGoalIdstring必填、必须出现在memberIds中批次最终目标被 gate 的目标顶级要求--validation-batch-json的值必须是一个 JSON 数组--validation-batch-json must be a JSON array.数组中的每一项必须是对象validation batch entries must be objects.。在领域层plan-crud.ts 调用parseValidationBatches解析并校验成功后写入plan.validationBatchesconst validationBatches await parseValidationBatches(args.validationBatchesJson, goals); if (validationBatches ! undefined) plan.validationBatches validationBatches;这正是 task-3 RED 阶段记录的第一处缺陷的修复点——此前createUlwLoopPlan直接忽略了validationBatchesJson导致plan.validationBatches缺失。三、解析期校验规则与错误码体系3.1 校验规则源码级validation-batch.ts 的validateBatches在创建计划时一次性执行全部结构校验规则如下批次 id 唯一duplicate validation batch id: id成员 id 去重批次内memberIds出现重复即失败finalGoalId 必须是成员finalGoalId must be a member成员必须存在于目标集合引用不存在的 goal id 即失败跨批次成员不得重叠同一个 goal id 出现在多个 validation-batch 中即失败。3.2 五个带类型错误码的失败分支reviewer-fix 阶段reviewer-fix-report.md为 validation-batch 分支确定了专用类型化错误码替换了原先笼统的错误处理。完整清单错误码触发条件对应校验规则ULW_LOOP_VALIDATION_BATCH_INVALID结构性无效顶层不是 JSON 数组、条目不是对象、缺少batchId/finalGoalId、成员少于 2 个、批次 id 重复、批次内成员重复通用兜底码ULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN成员 id 引用了不存在的目标规则 4ULW_LOOP_VALIDATION_BATCH_FINAL_NOT_MEMBERfinalGoalId不在该批次memberIds中规则 3ULW_LOOP_VALIDATION_BATCH_OVERLAP同一目标出现在多个批次中规则 5ULW_LOOP_VALIDATION_BATCH_OPEN批次最终目标尝试关闭但仍有其他成员未完成/未解决checkpoint/steering 期强制门ULW_LOOP_VALIDATION_BATCH_CRITERIA_PENDING/ULW_LOOP_VALIDATION_BATCH_GATE_MISMATCH批次成员准则仍有 pending或质量门criteriaCoverage计数与重算的成员准则数不一致checkpoint 期强制门task-3 的 Reviewer-fix CLI 用例确认了前四类行为confirmedULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN,ULW_LOOP_VALIDATION_BATCH_FINAL_NOT_MEMBER,ULW_LOOP_VALIDATION_BATCH_OVERLAP, and retainedULW_LOOP_VALIDATION_BATCH_INVALIDfor duplicate/too-small structural invalidity.——即重复成员与过小批次member 少于 2继续归入INVALID而不是细分码。源码中错误通过统一的fail(message, code)助手抛出默认码为ULW_LOOP_VALIDATION_BATCH_INVALID最终以UlwLoopError携带类型化码 详情对象如{ batchId, open }、{ batchId, pending }向外暴露。四、解析之后的强制执行checkpoint 与 steering 联动validation-batch 的生命周期不止于创建期校验。task-3 只覆盖 schema 的解析与校验task-4 记录了对它的强制执行4.1 checkpoint 期的三个强制门validation-batch.ts 暴露三个守卫函数requireBatchFinalReady(plan, goal)当目标恰是某批次的finalGoalId时若存在其他未解决unresolved成员抛出ULW_LOOP_VALIDATION_BATCH_OPEN——真实 QA 中G002-goal-beta是批次最终目标但G001-goal-alpha仍 pending 时checkpoint 被拒绝并返回该码requireAllValidationBatchesClosed(plan, closingGoalId?)聚合完成前不允许任何批次保持开放requireBatchGate(plan, goal, gate)批次最终目标的质量门必须满足——所有成员的成功准则均 pass否则ULW_LOOP_VALIDATION_BATCH_CRITERIA_PENDING且gate.criteriaCoverage.totalCriteria/passCount必须与逐成员重算的准则总数/通过数一致否则ULW_LOOP_VALIDATION_BATCH_GATE_MISMATCH。4.2 steering 期的成员一致性维护steer对批次成员执行 split/supersede 时updateBatchesAfterSupersedevalidation-batch.ts会把被拆分的成员替换为后继目标replacementIds若被拆的是finalGoalId则取replacementIds的最后一个作为新最终目标batchUpdateLedgerEntry在成员关系变化时生成batch_updated账本条目validation-batch.ts。task-4 的真实 QA 验证了这一点对G001-goal-alpha执行 split 后批次成员变为G004,G002-goal-beta。五、TDD 证据RED/GREEN 与真实 CLI 表面验证task-3.md 本身是一份 TDD测试驱动开发证据记录其方法论值得作为质量基线复述5.1 RED实现前的失败观察运行npm test -- validation-batch cli-validation-batch实现前观察到三类失败createUlwLoopPlan忽略validationBatchesJsonplan.validationBatches缺失未知成员 id 未被拒绝缺少MEMBER_UNKNOWN校验CLI JSON 输出未包含 validation batches。5.2 GREEN组件门历史原始门npm test -- validation-batch cli-validation-batch plan-crud cli-create-goalsnpm run typechecknpm run build→ 4 个测试文件、31 个测试通过TypeScript strict 检查通过构建通过。Reviewer-fix 门npm test -- steering-batch cli-steering-batch validation-batch cli-validation-batchnpm run check 全量npm test→ 5 个聚焦文件 / 22 个测试通过npm run check通过全组件套件 40 文件 / 418 测试通过。5.3 Real-surface QA构建后的真实 CLI在全新的mktemp临时 git 仓库中运行构建产物dist/cli.js执行本文 2.1 节的create-goals命令后断言观察到plan.validationBatches[0].batchId VB001并以validation batch create ok VB001作为 transcript 摘要输出。task-6 的端到端生命周期进一步覆盖了创建含VB001的三目标计划 → 完成 G001 自动推进到 G002 → 应用两提案批次 → 完成 G002 推进到 G003 → G003 同时作为批次最终目标与聚合最终目标完成 → 发出batch_closed的完整闭环task-6.md。5.4 相关测试文件围绕该功能的测试均位于组件测试目录test/validation-batch.test.ts解析与校验单元测试test/cli-validation-batch.test.tsCLI 表面测试test/validation-batch-checkpoint.test.tscheckpoint 强制门测试test/steering-batch.test.tssteering 批次原子性测试六、与其他证据工件的关联task-3 只是 gajae-adoption 证据集的一个切片。完整脉络可沿 .omo/evidence/20260721-ulw-loop-gajae-adoption/README.md 展开task-1.mdcheckpoint 自动推进--no-advance回退task-2.md原子批次 steering--proposals-json拒绝时零写入task-4.mdvalidation-batch 的 checkpoint/steering 强制执行task-5.md文档与ULW_LOOP_HELP同步task-6.md 与reviewer-fix-report.md全量门 构建 CLI 生命周期 独立评审修复。注意reviewer-fix-report.md明确声明其对 task-2/task-3/task-6 中涉及评审阻塞项细节的历史记录具有取代supersede效力——本文引用的五类错误码即以其为准。七、实践要点小结声明时机validation-batch 只能在create-goals时通过--validation-batch-json声明运行时无法追加每个批次必须满足至少 2 个成员 finalGoalId 必须是成员的最低结构要求。校验是 fail-closed 的任何一条规则不满足都会在创建计划时整体拒绝不会生成部分计划跨批次重叠与未知成员分别以OVERLAP/MEMBER_UNKNOWN精确报错。错误码可编程消费CLI 的--json输出携带ULW_LOOP_VALIDATION_BATCH_*类型化码Agent 可按码分支处理而不是解析自由文本。强制执行覆盖全生命周期schema 校验只是入口批次最终目标关闭时的 open-member 检查、成员准则 pass 检查、gate 覆盖计数一致性检查以及 steering 拆分后的成员一致性维护batch_updated审计共同构成完整的审查边界语义。验证路径可复现npm test -- validation-batch cli-validation-batch是聚焦该功能的 Vitest 入口全量验证则运行组件级的npm run check npm test与仓库根级的bun run test:codex。【免费下载链接】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），仅供参考 oh-my-openagent ulw-loop validation-batch Schema 解析：审查边界的声明、校验与强制执行
oh-my-openagent ulw-loop validation-batch Schema 解析审查边界的声明、校验与强制执行【免费下载链接】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导读本文以仓库中 ulw-loop gajae-adoption 证据集 的task-3.md证据为主线深入剖析 oh-my-openagent 的omo-codex插件组件ulw-loop中 validation-batch验证批次schema 的完整设计它如何在创建计划时声明审查边界review boundary、在解析期执行哪些结构性校验、产生哪些带类型错误码的失败分支以及如何在 checkpoint/steering 流程中被强制执行。读完本文你将掌握--validation-batch-json的 JSON 结构、五个校验错误码的触发条件以及对应源码与测试证据的定位方式。一、什么是 validation-batch比普通完成门槛更严格的审查边界在ulw-loopdurable repo-native multi-goal orchestration组件中普通目标goal的完成只需通过checkpoint解析的质量门quality gate。而 validation-batch 是可选的审查边界它把一组目标捆绑为一个批次声明其中一个是批次最终目标finalGoalId并约定——只有该批次内其他成员目标全部完成或 superseded-resolved、所有成员的成功准则success criteria全部 pass、且质量门的覆盖计数与重算的成员准则一致时批次最终目标才允许关闭。组件 README 中的定义packages/omo-codex/plugin/components/ulw-loop/README.md明确指出Validation batches are optional review boundaries declared at plan creation with--validation-batch-json. The batch-final goal cannot complete until every other member is complete or superseded-resolved, every member criterion is pass, and a quality gates coverage counts match the recomputed member criteria.也就是说validation-batch 是更严格的完成门stricter review boundaries而不是更弱的完成门——这一点在 task-5 文档同步证据 中被作为验收要求单独确认Confirmed validation batches are described as stricter review boundaries, not weaker completion gates.二、声明方式create-goals 的 --validation-batch-json 参数2.1 CLI 入口validation-batch 在创建计划plan时一次性声明通过create-goals子命令的--validation-batch-json参数传入。CLI 参数在 cli-arg-parser.ts 中被登记为带值 flagVALUE_FLAGS中包含--validation-batch-json并由 cli-subcommands.ts 的createGoals读取后透传给领域层const validationBatchesJson readValue(argv, --validation-batch-json); // ... ...(validationBatchesJson undefined ? {} : { validationBatchesJson }),基本用法来自 task-3 的真实 QA 命令omo-agent-toolkit ulw-loop create-goals \ --brief $- Goal alpha\n- Goal beta \ --validation-batch-json [{batchId:VB001,memberIds:[G001-goal-alpha,G002-goal-beta],finalGoalId:G002-goal-beta}] \ --json2.2 JSON schema三个必填字段每个批次对象只有三个字段结构非常精简源码 validation-batch.ts字段类型约束含义batchIdstring必填、非空白、批次内唯一批次标识如VB001memberIdsstring[]必填、至少 2 个、元素非空白、批次内不重复参与该批次的成员目标 idfinalGoalIdstring必填、必须出现在memberIds中批次最终目标被 gate 的目标顶级要求--validation-batch-json的值必须是一个 JSON 数组--validation-batch-json must be a JSON array.数组中的每一项必须是对象validation batch entries must be objects.。在领域层plan-crud.ts 调用parseValidationBatches解析并校验成功后写入plan.validationBatchesconst validationBatches await parseValidationBatches(args.validationBatchesJson, goals); if (validationBatches ! undefined) plan.validationBatches validationBatches;这正是 task-3 RED 阶段记录的第一处缺陷的修复点——此前createUlwLoopPlan直接忽略了validationBatchesJson导致plan.validationBatches缺失。三、解析期校验规则与错误码体系3.1 校验规则源码级validation-batch.ts 的validateBatches在创建计划时一次性执行全部结构校验规则如下批次 id 唯一duplicate validation batch id: id成员 id 去重批次内memberIds出现重复即失败finalGoalId 必须是成员finalGoalId must be a member成员必须存在于目标集合引用不存在的 goal id 即失败跨批次成员不得重叠同一个 goal id 出现在多个 validation-batch 中即失败。3.2 五个带类型错误码的失败分支reviewer-fix 阶段reviewer-fix-report.md为 validation-batch 分支确定了专用类型化错误码替换了原先笼统的错误处理。完整清单错误码触发条件对应校验规则ULW_LOOP_VALIDATION_BATCH_INVALID结构性无效顶层不是 JSON 数组、条目不是对象、缺少batchId/finalGoalId、成员少于 2 个、批次 id 重复、批次内成员重复通用兜底码ULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN成员 id 引用了不存在的目标规则 4ULW_LOOP_VALIDATION_BATCH_FINAL_NOT_MEMBERfinalGoalId不在该批次memberIds中规则 3ULW_LOOP_VALIDATION_BATCH_OVERLAP同一目标出现在多个批次中规则 5ULW_LOOP_VALIDATION_BATCH_OPEN批次最终目标尝试关闭但仍有其他成员未完成/未解决checkpoint/steering 期强制门ULW_LOOP_VALIDATION_BATCH_CRITERIA_PENDING/ULW_LOOP_VALIDATION_BATCH_GATE_MISMATCH批次成员准则仍有 pending或质量门criteriaCoverage计数与重算的成员准则数不一致checkpoint 期强制门task-3 的 Reviewer-fix CLI 用例确认了前四类行为confirmedULW_LOOP_VALIDATION_BATCH_MEMBER_UNKNOWN,ULW_LOOP_VALIDATION_BATCH_FINAL_NOT_MEMBER,ULW_LOOP_VALIDATION_BATCH_OVERLAP, and retainedULW_LOOP_VALIDATION_BATCH_INVALIDfor duplicate/too-small structural invalidity.——即重复成员与过小批次member 少于 2继续归入INVALID而不是细分码。源码中错误通过统一的fail(message, code)助手抛出默认码为ULW_LOOP_VALIDATION_BATCH_INVALID最终以UlwLoopError携带类型化码 详情对象如{ batchId, open }、{ batchId, pending }向外暴露。四、解析之后的强制执行checkpoint 与 steering 联动validation-batch 的生命周期不止于创建期校验。task-3 只覆盖 schema 的解析与校验task-4 记录了对它的强制执行4.1 checkpoint 期的三个强制门validation-batch.ts 暴露三个守卫函数requireBatchFinalReady(plan, goal)当目标恰是某批次的finalGoalId时若存在其他未解决unresolved成员抛出ULW_LOOP_VALIDATION_BATCH_OPEN——真实 QA 中G002-goal-beta是批次最终目标但G001-goal-alpha仍 pending 时checkpoint 被拒绝并返回该码requireAllValidationBatchesClosed(plan, closingGoalId?)聚合完成前不允许任何批次保持开放requireBatchGate(plan, goal, gate)批次最终目标的质量门必须满足——所有成员的成功准则均 pass否则ULW_LOOP_VALIDATION_BATCH_CRITERIA_PENDING且gate.criteriaCoverage.totalCriteria/passCount必须与逐成员重算的准则总数/通过数一致否则ULW_LOOP_VALIDATION_BATCH_GATE_MISMATCH。4.2 steering 期的成员一致性维护steer对批次成员执行 split/supersede 时updateBatchesAfterSupersedevalidation-batch.ts会把被拆分的成员替换为后继目标replacementIds若被拆的是finalGoalId则取replacementIds的最后一个作为新最终目标batchUpdateLedgerEntry在成员关系变化时生成batch_updated账本条目validation-batch.ts。task-4 的真实 QA 验证了这一点对G001-goal-alpha执行 split 后批次成员变为G004,G002-goal-beta。五、TDD 证据RED/GREEN 与真实 CLI 表面验证task-3.md 本身是一份 TDD测试驱动开发证据记录其方法论值得作为质量基线复述5.1 RED实现前的失败观察运行npm test -- validation-batch cli-validation-batch实现前观察到三类失败createUlwLoopPlan忽略validationBatchesJsonplan.validationBatches缺失未知成员 id 未被拒绝缺少MEMBER_UNKNOWN校验CLI JSON 输出未包含 validation batches。5.2 GREEN组件门历史原始门npm test -- validation-batch cli-validation-batch plan-crud cli-create-goalsnpm run typechecknpm run build→ 4 个测试文件、31 个测试通过TypeScript strict 检查通过构建通过。Reviewer-fix 门npm test -- steering-batch cli-steering-batch validation-batch cli-validation-batchnpm run check 全量npm test→ 5 个聚焦文件 / 22 个测试通过npm run check通过全组件套件 40 文件 / 418 测试通过。5.3 Real-surface QA构建后的真实 CLI在全新的mktemp临时 git 仓库中运行构建产物dist/cli.js执行本文 2.1 节的create-goals命令后断言观察到plan.validationBatches[0].batchId VB001并以validation batch create ok VB001作为 transcript 摘要输出。task-6 的端到端生命周期进一步覆盖了创建含VB001的三目标计划 → 完成 G001 自动推进到 G002 → 应用两提案批次 → 完成 G002 推进到 G003 → G003 同时作为批次最终目标与聚合最终目标完成 → 发出batch_closed的完整闭环task-6.md。5.4 相关测试文件围绕该功能的测试均位于组件测试目录test/validation-batch.test.ts解析与校验单元测试test/cli-validation-batch.test.tsCLI 表面测试test/validation-batch-checkpoint.test.tscheckpoint 强制门测试test/steering-batch.test.tssteering 批次原子性测试六、与其他证据工件的关联task-3 只是 gajae-adoption 证据集的一个切片。完整脉络可沿 .omo/evidence/20260721-ulw-loop-gajae-adoption/README.md 展开task-1.mdcheckpoint 自动推进--no-advance回退task-2.md原子批次 steering--proposals-json拒绝时零写入task-4.mdvalidation-batch 的 checkpoint/steering 强制执行task-5.md文档与ULW_LOOP_HELP同步task-6.md 与reviewer-fix-report.md全量门 构建 CLI 生命周期 独立评审修复。注意reviewer-fix-report.md明确声明其对 task-2/task-3/task-6 中涉及评审阻塞项细节的历史记录具有取代supersede效力——本文引用的五类错误码即以其为准。七、实践要点小结声明时机validation-batch 只能在create-goals时通过--validation-batch-json声明运行时无法追加每个批次必须满足至少 2 个成员 finalGoalId 必须是成员的最低结构要求。校验是 fail-closed 的任何一条规则不满足都会在创建计划时整体拒绝不会生成部分计划跨批次重叠与未知成员分别以OVERLAP/MEMBER_UNKNOWN精确报错。错误码可编程消费CLI 的--json输出携带ULW_LOOP_VALIDATION_BATCH_*类型化码Agent 可按码分支处理而不是解析自由文本。强制执行覆盖全生命周期schema 校验只是入口批次最终目标关闭时的 open-member 检查、成员准则 pass 检查、gate 覆盖计数一致性检查以及 steering 拆分后的成员一致性维护batch_updated审计共同构成完整的审查边界语义。验证路径可复现npm test -- validation-batch cli-validation-batch是聚焦该功能的 Vitest 入口全量验证则运行组件级的npm run check npm test与仓库根级的bun run test:codex。【免费下载链接】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），仅供参考