拓冰网站定制 
omo-senpi mass-ulw DAG 规划门控工作流节点 prompt 契约校验与 spawn 策略对齐实战解析【免费下载链接】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-openagentmass-ulw 是 OmO 的图工程graph engineering入口其核心教义要求每个产生工作的图必须以验证波verification wave收尾、每个节点 prompt 必须满足 TASK/DELIVERABLE/SCOPE/VERIFY/STOP WHEN 契约。本文以仓库中的 QA 证据文档 .omo/evidence/20260818-mass-ulw-dag-gate/README.md 为主体剖析 omo-senpi 的workflowdag工具如何把这条规划教义落地成两道门P1 节点定义 advisory lint只警告、永不拒绝与 P2 子代理 spawn 策略对齐让 DAG 分发的 agent 子节点与直接taskspawn 走同一道规划门。读完你将掌握 dag 工具的 lint 规则细节、evaluateSpawnPolicy的 allow/deny/force 三态语义、调度器接线位置以及这套门控的完整验证方法论RED/GREEN 证据、真实表面 proof 脚本、e2e 驱动。背景mass-ulw 教义与 dag 工具的以图编程在 OmO 的规划工作流里用户只需在 prompt 中输入mass ulw关键字系统便会进入Universal Long-horizon WorkULW规划循环先产出 Prometheus 风格的规划文档含 waves、checkboxes、验收标准再由编排者通过workflowdag工具把计划拆成依赖图执行。mass-ulw 的规划参考对每个工作节点提出了一条prompt 契约TASK:标记——节点要完成的任务是什么DELIVERABLE:标记——产出物是什么SCOPE:标记——改动边界在哪里VERIFY:标记——如何验证STOP WHEN:标记——何时停止完成条件。同时一个产生工作的图必须以验证波verification wave收尾——即图中至少应存在一个语义为 verify/audit/qa 的节点。dag 工具工具名为workflow是 omo-senpi 中面向模型暴露的依赖图执行入口实现在 packages/omo-senpi/src/components/task/dag-tool.ts。它支持start/attach/snapshot/wait/cancel/retry/send/amend等动作节点仅在dependsOn前置完成后启动无关节点并行执行上限受 resident-child cap 约束start按 definition key 幂等同一 key 重新 start 会复用已有 runwait默认对活跃 run 采用监听式 detachdetachfalse恢复阻塞等待。正是围绕start动作2026-08-18 的feat/mass-ulw-dag-gate分支基线 origin/dev 4f65026b8实现了两道规划门控。P1 门控节点定义契约 advisory lint设计取向永不拒绝只出警告P1 的目标是在dag start时对每个节点定义做一次契约体检。其设计取向非常明确lint 是 advisory 的永不拒绝。dag 工具本质上是通用图执行器因此一个无视 prompt 契约的定义仍然可以运行——模型会在start结果中看到警告文本然后自行决定 cancel、修正定义、换新 key 重新启动。这把质量约束放到了模型可见的信息面上而不是在工具层硬性拦截避免破坏 dag 工具的通用性。核心实现位于 packages/omo-senpi/src/components/task/dag-lint.ts入口函数lintDagDefinitionNodes(nodes)对每个节点做三类检查TASK:标记缺失若prompt不匹配/TASK:/产出警告node X: prompt is missing the TASK: marker from the mass-ulw node prompt contract (TASK/DELIVERABLE/SCOPE/VERIFY/STOP WHEN)STOP WHEN条件缺失若prompt不匹配/STOP WHEN/产出警告node X: prompt is missing a STOP WHEN condition ...验证波缺失当节点数 ≥ 2 且没有任何节点的id或prompt匹配验证语义正则/\b(verify|verification|verifier|audit|validate|validation|qa)\b/i时产出警告run has N nodes but no verification node; a graph that produces work ends with a verification wave (mass-ulw planning reference)。从源码结构可以推断lint 只做浅层标记存在性检查不做语义深度校验——例如它不验证TASK:与DELIVERABLE:的先后顺序或内容完备性验证波检查也依赖节点 id/prompt 中出现验证语义关键词属于启发式匹配。这套规则刻意保持简单因为 lint 的目标是提醒而非代庖。警告如何进入模型视野在 dag-tool.ts 的startAction中lintDagDefinitionNodes(input.nodes)的结果被注入两条通道对应 dag-tool.ts模型可见文本当warnings.length 0时start结果文本追加Advisory warnings (fix the definition and re-start under a new key to clear them): ${warnings.join( | )}提示模型修正定义并在新 key 下重新 start 以清除警告结构化 payload结果details中携带warnings数组字段供 eval SDK 与上层程序化消费。真实表面证明证据文件 .omo/evidence/20260818-mass-ulw-dag-gate/p1-real-surface.txt 记录了 proof 脚本的输出。驱动脚本为 packages/omo-senpi/scripts/qa/dag-gate-proof.ts它用真实的createDagFileStorecreateDagManager组装出DagToolDeps直接调用runDagTool打印模型实际可见的文本与 payload违反契约的定义plan: draft the plan、build: build it2 节点模型可见文本Started dag run dag_66b1a453... (2 nodes). Advisory warnings (fix the definition and re-start under a new key to clear them): node plan: prompt is missing the TASK: marker ... | node plan: prompt is missing a STOP WHEN condition ... | node build: ... | run has 2 nodes but no verification node; ...warnings payload共5 条2 节点 × 2 条契约警告 1 条验证波警告与文档4 contract 1 verification-wave完全一致。合规定义plan与verify两个节点prompt 完整书写TASK:/DELIVERABLE:/SCOPE:/VERIFY:/STOP WHEN:模型可见文本Started dag run dag_87385711... (2 nodes).——无任何警告后缀warnings payload[]。这个 proof 脚本的价值在于它驱动的正是模型消费的真实表面真工具 真管理器而非 mock。合规示例中的节点 prompt 可以直接当作 dag 节点的书写范本TASK: draft the plan. DELIVERABLE: plan.md. SCOPE: write plan.md only. VERIFY: test -f plan.md. STOP WHEN: plan.md exists. TASK: verify the plan. DELIVERABLE: transcript. SCOPE: read-only. VERIFY: bun test. STOP WHEN: tests pass.P2 门控dag 分发的 spawn 策略与直接 task spawn 对齐问题调度器曾经绕过规划门P2 要修复的是一处语义漏洞在 dag 调度器内部agent 路由subagent_type节点此前直接从调度器启动子代理没有经过直接taskspawn 所经历的规划门plan gate 与 prompt 契约门。这意味着模型可以借助 dag 分发绕过momus/metis 仅在计划门打开时可 spawn之类的限制。修复后dag 的 agent 路由节点分发必须走evaluateSpawnPolicy——与直接taskspawn 完全相同的门。evaluateSpawnPolicy 的三态语义策略评估的单一组合点在 packages/senpi-task/src/tools/task/spawn-policy.ts 的evaluateSpawnPolicy(deps, subagentType, callerPrompt, sessionId)。它按顺序执行两步守卫返回三态 verdictexport type SpawnPolicyVerdict | { readonly kind: allow } | { readonly kind: deny; readonly message: string } | { readonly kind: force; readonly prompt: string }调用门invocation gateinvocationGateDenial(deps, name, sessionId)先检查该subagent_type在当前会话是否被调用限制拒绝例如 plan-gated 代理要求用户显式请求 ulw-plan 工作流。命中即返回deny。plan-review 契约门planReviewContractOutcome(deps, name, callerPrompt, sessionId)检查计划评审代理的 prompt 契约——命中拒绝返回deny需要改写 prompt 时返回force携带替换后的 prompt。两门皆过返回allow。典型拒绝消息来自 .omo/evidence/20260818-mass-ulw-dag-gate/plan-gated-e2e.txt 的真实输出Agent momus is plan-gated: it is available only after the user explicitly requests the ulw-plan workflow in this session, and no such request was made. Do not attempt to unlock this gate yourself - retrying this spawn will keep failing. Continue without plan review (self-review instead), or ask the user to start the workflow themselves by running /skill:ulw-plan or by asking for a plan in their own words.调度器接线startOwned 之前的最后一次准入检查dag 侧通过nodeSpawnPolicy注入点接入同一策略。调度器类型定义在 packages/senpi-task/src/dag/scheduler.tsexport type DagNodeSpawnPolicyVerdict | { readonly kind: allow } | { readonly kind: deny; readonly message: string } | { readonly kind: force; readonly prompt: string } export type DagNodeSpawnPolicy (node: { readonly nodeId: DagNodeId readonly subagentType: string readonly prompt: string readonly parentSessionId: string }) DagNodeSpawnPolicyVerdict它在每个节点 admission 时、startOwned之前评估一次。接线逻辑位于startSpecpackages/senpi-task/src/dag/scheduler.ts语义如下仅agent 路由节点node.route.kind ! category即带subagent_type咨询策略category路由节点不咨询与直接 spawn 中 category 走委派路由而非计划门的行为一致deny抛出DAG node X denied by spawn policy: message节点被拒绝startOwned永远不会被调用force用 verdict 携带的 prompt替换子代理实际收到的 prompt{ ...spec, prompt: verdict.prompt }即契约门强制改写子代理输入allow按原 spec 启动。观察到的行为来自证据文档一个subagent_type: momus的 dag 节点在拒绝策略下以拒绝消息失败且startOwned从未被调用forceverdict 会替换子代理实际收到的 promptcategory 路由节点从不咨询该策略——这是设计使然不是缺陷。e2e 证明plan-gated-agents-e2e仓库的规范 plan-gate 驱动是 packages/omo-senpi/scripts/qa/plan-gated-agents-e2e.mjs它针对构建好的插件 bundle 运行多个脚本化场景denial、sequence、read-unlock、retired-id、description、team-retired等并在驱动内部对真实 agent 目录做前后 digest 比对以证明沙箱隔离。本轮证据文件 .omo/evidence/20260818-mass-ulw-dag-gate/plan-gated-e2e.txt 记录了两个场景denial 场景task(subagent_type: momus, ...)在未请求 ulw-plan 的会话中直接被拒denial_present: true、no_child_spawned: true、exit_zero: true任务记录为空数组sequence 场景先解锁 plan gate 后第一次 spawn 被允许first_spawn_allowed: true子代理momus以omo-mock/mock-1完成评审随后在门关闭状态下第二次启动工作被拒second_denied_start_work: true且全程exactly_one_child: true、realSenpiCredentialsUntouched: true、informationalDirectoryDigestStable: true。验证方法论从 RED 到 GREEN 到回归RED/GREEN 证据链证据文档按 TDD 方式记录了完整证据链P1RED 阶段dag-lint.test.ts与dag-tool.test.ts的 warnings 测试在实现前失败模块缺失 /warningsundefinedGREEN 阶段同一批测试通过见 .omo/evidence/20260818-mass-ulw-dag-gate/p1-green.txt。P2RED 阶段scheduler.test.ts的策略测试失败节点完成而非被拒、force prompt 未生效GREEN 阶段调度器单测 dag-runtime.test.ts接线测试通过——拒绝策略经真实组合根composition root到达分发路径且无子进程启动。dag-runtime.test.ts的价值在于它从真实组合根驱动整个 dag 运行时证明策略确实在端到端路径上生效而不仅是单元层面。回归与 A/B 预存失败分析回归证据见 .omo/evidence/20260818-mass-ulw-dag-gate/regression.txtbun test packages/senpi-task1615 个测试通过1 skip / 0 fail5042 次 expectbun test packages/omo-senpi1922 个测试16 fail均为预存环境失败tsgo --noEmit两个包均通过附注dag-runtime.test.ts在 tsgo 下暴露一个与DagTerminalNodeResult.error相关的类型错误属于测试文件类型问题不影响实现面。A/B 对比完整 omo-senpi 套件分支 16 fail 与干净 origin/dev 基线 16 fail 完全同数分支受影响文件重跑 13 fail是基线集合的严格子集init-deep-advisor ×10、cli-local ×1、session_start ordering ×1、product-identity ×1。零 dag/task/scheduler/mass-ulw 区域失败分支新增 26 个测试全部通过。结论剩余失败均为 origin/dev 上环境依赖的预存失败与本改动无关。环境注意点skills-sync.test.ts依赖sync-skills.mjs已执行CI 的test:senpi会先构建。若在--ignore-scripts的全新 worktree 中直接跑测试会先出现 7 个无关失败直到执行一次node packages/omo-senpi/plugin/scripts/sync-skills.mjs。这是复现验证时容易踩的坑。残留风险与边界证据文档诚实记录了剩余风险momus prompt-contractforce路径目前只在调度器单元层面证明。live plan-gate e2e 覆盖的是直接 spawn 路径而非 dag 分发的 momus——因为仓库中尚不存在带 mock provider 的 dag e2e harness。也就是说dag 节点携带subagent_type: momus且命中forceverdict 时替换 prompt这一行为还缺一条真实组合根的 e2e 覆盖。隔离性证明在 e2e 驱动内部没有捕获任何 secrets/tokens/env dumpse2e 沙箱对真实 agent 目录做前后 digest 比对作为隔离证明包含在驱动自身逻辑中。总结两道门如何共同落地 mass-ulw 规划教义把两条链路并起来看mass-ulw DAG 规划门控形成了互补的两层防线advisory 层P1dag start时对每个节点定义做契约 lint产出模型可见的警告文本与结构化warningspayload。它不改执行语义——违反契约的图照跑但模型被明确告知哪里不符合 mass-ulw 节点 prompt 契约、哪里缺验证波从而有机会修正并换 key 重跑。强制层P2dag 的 agent 路由节点在startOwned前经过与直接taskspawn 相同的evaluateSpawnPolicy——invocation gate 拒绝未解锁的 plan-gated 代理plan-review 契约门要么拒绝要么用force改写子代理 promptcategory 路由节点刻意豁免。如果你要在 dag 定义中写出零警告的合规图请记住三条硬规则每个节点 prompt 必须含TASK:与STOP WHEN:标记理想情况写全 TASK/DELIVERABLE/SCOPE/VERIFY/STOP WHEN 五件套产生工作的图最后一个波必须是验证节点节点 id 或 prompt 含 verify/verification/audit/qa 等语义关键词start按 key 幂等修正定义后要用新 key重新启动才能清除警告。进一步阅读可参考 docs/reference/mass-ulw-protocol.md 与 docs/reference/prompt-async-gate-rfc.md以及 lint 规则与策略实现的测试佐证 packages/omo-senpi/src/components/task/dag-lint.test.ts、packages/omo-senpi/src/components/task/dag-tool.test.ts、packages/omo-senpi/src/components/task/dag-runtime.test.ts。【免费下载链接】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-senpi mass-ulw DAG 规划门控：工作流节点 prompt 契约校验与 spawn 策略对齐实战解析
omo-senpi mass-ulw DAG 规划门控工作流节点 prompt 契约校验与 spawn 策略对齐实战解析【免费下载链接】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-openagentmass-ulw 是 OmO 的图工程graph engineering入口其核心教义要求每个产生工作的图必须以验证波verification wave收尾、每个节点 prompt 必须满足 TASK/DELIVERABLE/SCOPE/VERIFY/STOP WHEN 契约。本文以仓库中的 QA 证据文档 .omo/evidence/20260818-mass-ulw-dag-gate/README.md 为主体剖析 omo-senpi 的workflowdag工具如何把这条规划教义落地成两道门P1 节点定义 advisory lint只警告、永不拒绝与 P2 子代理 spawn 策略对齐让 DAG 分发的 agent 子节点与直接taskspawn 走同一道规划门。读完你将掌握 dag 工具的 lint 规则细节、evaluateSpawnPolicy的 allow/deny/force 三态语义、调度器接线位置以及这套门控的完整验证方法论RED/GREEN 证据、真实表面 proof 脚本、e2e 驱动。背景mass-ulw 教义与 dag 工具的以图编程在 OmO 的规划工作流里用户只需在 prompt 中输入mass ulw关键字系统便会进入Universal Long-horizon WorkULW规划循环先产出 Prometheus 风格的规划文档含 waves、checkboxes、验收标准再由编排者通过workflowdag工具把计划拆成依赖图执行。mass-ulw 的规划参考对每个工作节点提出了一条prompt 契约TASK:标记——节点要完成的任务是什么DELIVERABLE:标记——产出物是什么SCOPE:标记——改动边界在哪里VERIFY:标记——如何验证STOP WHEN:标记——何时停止完成条件。同时一个产生工作的图必须以验证波verification wave收尾——即图中至少应存在一个语义为 verify/audit/qa 的节点。dag 工具工具名为workflow是 omo-senpi 中面向模型暴露的依赖图执行入口实现在 packages/omo-senpi/src/components/task/dag-tool.ts。它支持start/attach/snapshot/wait/cancel/retry/send/amend等动作节点仅在dependsOn前置完成后启动无关节点并行执行上限受 resident-child cap 约束start按 definition key 幂等同一 key 重新 start 会复用已有 runwait默认对活跃 run 采用监听式 detachdetachfalse恢复阻塞等待。正是围绕start动作2026-08-18 的feat/mass-ulw-dag-gate分支基线 origin/dev 4f65026b8实现了两道规划门控。P1 门控节点定义契约 advisory lint设计取向永不拒绝只出警告P1 的目标是在dag start时对每个节点定义做一次契约体检。其设计取向非常明确lint 是 advisory 的永不拒绝。dag 工具本质上是通用图执行器因此一个无视 prompt 契约的定义仍然可以运行——模型会在start结果中看到警告文本然后自行决定 cancel、修正定义、换新 key 重新启动。这把质量约束放到了模型可见的信息面上而不是在工具层硬性拦截避免破坏 dag 工具的通用性。核心实现位于 packages/omo-senpi/src/components/task/dag-lint.ts入口函数lintDagDefinitionNodes(nodes)对每个节点做三类检查TASK:标记缺失若prompt不匹配/TASK:/产出警告node X: prompt is missing the TASK: marker from the mass-ulw node prompt contract (TASK/DELIVERABLE/SCOPE/VERIFY/STOP WHEN)STOP WHEN条件缺失若prompt不匹配/STOP WHEN/产出警告node X: prompt is missing a STOP WHEN condition ...验证波缺失当节点数 ≥ 2 且没有任何节点的id或prompt匹配验证语义正则/\b(verify|verification|verifier|audit|validate|validation|qa)\b/i时产出警告run has N nodes but no verification node; a graph that produces work ends with a verification wave (mass-ulw planning reference)。从源码结构可以推断lint 只做浅层标记存在性检查不做语义深度校验——例如它不验证TASK:与DELIVERABLE:的先后顺序或内容完备性验证波检查也依赖节点 id/prompt 中出现验证语义关键词属于启发式匹配。这套规则刻意保持简单因为 lint 的目标是提醒而非代庖。警告如何进入模型视野在 dag-tool.ts 的startAction中lintDagDefinitionNodes(input.nodes)的结果被注入两条通道对应 dag-tool.ts模型可见文本当warnings.length 0时start结果文本追加Advisory warnings (fix the definition and re-start under a new key to clear them): ${warnings.join( | )}提示模型修正定义并在新 key 下重新 start 以清除警告结构化 payload结果details中携带warnings数组字段供 eval SDK 与上层程序化消费。真实表面证明证据文件 .omo/evidence/20260818-mass-ulw-dag-gate/p1-real-surface.txt 记录了 proof 脚本的输出。驱动脚本为 packages/omo-senpi/scripts/qa/dag-gate-proof.ts它用真实的createDagFileStorecreateDagManager组装出DagToolDeps直接调用runDagTool打印模型实际可见的文本与 payload违反契约的定义plan: draft the plan、build: build it2 节点模型可见文本Started dag run dag_66b1a453... (2 nodes). Advisory warnings (fix the definition and re-start under a new key to clear them): node plan: prompt is missing the TASK: marker ... | node plan: prompt is missing a STOP WHEN condition ... | node build: ... | run has 2 nodes but no verification node; ...warnings payload共5 条2 节点 × 2 条契约警告 1 条验证波警告与文档4 contract 1 verification-wave完全一致。合规定义plan与verify两个节点prompt 完整书写TASK:/DELIVERABLE:/SCOPE:/VERIFY:/STOP WHEN:模型可见文本Started dag run dag_87385711... (2 nodes).——无任何警告后缀warnings payload[]。这个 proof 脚本的价值在于它驱动的正是模型消费的真实表面真工具 真管理器而非 mock。合规示例中的节点 prompt 可以直接当作 dag 节点的书写范本TASK: draft the plan. DELIVERABLE: plan.md. SCOPE: write plan.md only. VERIFY: test -f plan.md. STOP WHEN: plan.md exists. TASK: verify the plan. DELIVERABLE: transcript. SCOPE: read-only. VERIFY: bun test. STOP WHEN: tests pass.P2 门控dag 分发的 spawn 策略与直接 task spawn 对齐问题调度器曾经绕过规划门P2 要修复的是一处语义漏洞在 dag 调度器内部agent 路由subagent_type节点此前直接从调度器启动子代理没有经过直接taskspawn 所经历的规划门plan gate 与 prompt 契约门。这意味着模型可以借助 dag 分发绕过momus/metis 仅在计划门打开时可 spawn之类的限制。修复后dag 的 agent 路由节点分发必须走evaluateSpawnPolicy——与直接taskspawn 完全相同的门。evaluateSpawnPolicy 的三态语义策略评估的单一组合点在 packages/senpi-task/src/tools/task/spawn-policy.ts 的evaluateSpawnPolicy(deps, subagentType, callerPrompt, sessionId)。它按顺序执行两步守卫返回三态 verdictexport type SpawnPolicyVerdict | { readonly kind: allow } | { readonly kind: deny; readonly message: string } | { readonly kind: force; readonly prompt: string }调用门invocation gateinvocationGateDenial(deps, name, sessionId)先检查该subagent_type在当前会话是否被调用限制拒绝例如 plan-gated 代理要求用户显式请求 ulw-plan 工作流。命中即返回deny。plan-review 契约门planReviewContractOutcome(deps, name, callerPrompt, sessionId)检查计划评审代理的 prompt 契约——命中拒绝返回deny需要改写 prompt 时返回force携带替换后的 prompt。两门皆过返回allow。典型拒绝消息来自 .omo/evidence/20260818-mass-ulw-dag-gate/plan-gated-e2e.txt 的真实输出Agent momus is plan-gated: it is available only after the user explicitly requests the ulw-plan workflow in this session, and no such request was made. Do not attempt to unlock this gate yourself - retrying this spawn will keep failing. Continue without plan review (self-review instead), or ask the user to start the workflow themselves by running /skill:ulw-plan or by asking for a plan in their own words.调度器接线startOwned 之前的最后一次准入检查dag 侧通过nodeSpawnPolicy注入点接入同一策略。调度器类型定义在 packages/senpi-task/src/dag/scheduler.tsexport type DagNodeSpawnPolicyVerdict | { readonly kind: allow } | { readonly kind: deny; readonly message: string } | { readonly kind: force; readonly prompt: string } export type DagNodeSpawnPolicy (node: { readonly nodeId: DagNodeId readonly subagentType: string readonly prompt: string readonly parentSessionId: string }) DagNodeSpawnPolicyVerdict它在每个节点 admission 时、startOwned之前评估一次。接线逻辑位于startSpecpackages/senpi-task/src/dag/scheduler.ts语义如下仅agent 路由节点node.route.kind ! category即带subagent_type咨询策略category路由节点不咨询与直接 spawn 中 category 走委派路由而非计划门的行为一致deny抛出DAG node X denied by spawn policy: message节点被拒绝startOwned永远不会被调用force用 verdict 携带的 prompt替换子代理实际收到的 prompt{ ...spec, prompt: verdict.prompt }即契约门强制改写子代理输入allow按原 spec 启动。观察到的行为来自证据文档一个subagent_type: momus的 dag 节点在拒绝策略下以拒绝消息失败且startOwned从未被调用forceverdict 会替换子代理实际收到的 promptcategory 路由节点从不咨询该策略——这是设计使然不是缺陷。e2e 证明plan-gated-agents-e2e仓库的规范 plan-gate 驱动是 packages/omo-senpi/scripts/qa/plan-gated-agents-e2e.mjs它针对构建好的插件 bundle 运行多个脚本化场景denial、sequence、read-unlock、retired-id、description、team-retired等并在驱动内部对真实 agent 目录做前后 digest 比对以证明沙箱隔离。本轮证据文件 .omo/evidence/20260818-mass-ulw-dag-gate/plan-gated-e2e.txt 记录了两个场景denial 场景task(subagent_type: momus, ...)在未请求 ulw-plan 的会话中直接被拒denial_present: true、no_child_spawned: true、exit_zero: true任务记录为空数组sequence 场景先解锁 plan gate 后第一次 spawn 被允许first_spawn_allowed: true子代理momus以omo-mock/mock-1完成评审随后在门关闭状态下第二次启动工作被拒second_denied_start_work: true且全程exactly_one_child: true、realSenpiCredentialsUntouched: true、informationalDirectoryDigestStable: true。验证方法论从 RED 到 GREEN 到回归RED/GREEN 证据链证据文档按 TDD 方式记录了完整证据链P1RED 阶段dag-lint.test.ts与dag-tool.test.ts的 warnings 测试在实现前失败模块缺失 /warningsundefinedGREEN 阶段同一批测试通过见 .omo/evidence/20260818-mass-ulw-dag-gate/p1-green.txt。P2RED 阶段scheduler.test.ts的策略测试失败节点完成而非被拒、force prompt 未生效GREEN 阶段调度器单测 dag-runtime.test.ts接线测试通过——拒绝策略经真实组合根composition root到达分发路径且无子进程启动。dag-runtime.test.ts的价值在于它从真实组合根驱动整个 dag 运行时证明策略确实在端到端路径上生效而不仅是单元层面。回归与 A/B 预存失败分析回归证据见 .omo/evidence/20260818-mass-ulw-dag-gate/regression.txtbun test packages/senpi-task1615 个测试通过1 skip / 0 fail5042 次 expectbun test packages/omo-senpi1922 个测试16 fail均为预存环境失败tsgo --noEmit两个包均通过附注dag-runtime.test.ts在 tsgo 下暴露一个与DagTerminalNodeResult.error相关的类型错误属于测试文件类型问题不影响实现面。A/B 对比完整 omo-senpi 套件分支 16 fail 与干净 origin/dev 基线 16 fail 完全同数分支受影响文件重跑 13 fail是基线集合的严格子集init-deep-advisor ×10、cli-local ×1、session_start ordering ×1、product-identity ×1。零 dag/task/scheduler/mass-ulw 区域失败分支新增 26 个测试全部通过。结论剩余失败均为 origin/dev 上环境依赖的预存失败与本改动无关。环境注意点skills-sync.test.ts依赖sync-skills.mjs已执行CI 的test:senpi会先构建。若在--ignore-scripts的全新 worktree 中直接跑测试会先出现 7 个无关失败直到执行一次node packages/omo-senpi/plugin/scripts/sync-skills.mjs。这是复现验证时容易踩的坑。残留风险与边界证据文档诚实记录了剩余风险momus prompt-contractforce路径目前只在调度器单元层面证明。live plan-gate e2e 覆盖的是直接 spawn 路径而非 dag 分发的 momus——因为仓库中尚不存在带 mock provider 的 dag e2e harness。也就是说dag 节点携带subagent_type: momus且命中forceverdict 时替换 prompt这一行为还缺一条真实组合根的 e2e 覆盖。隔离性证明在 e2e 驱动内部没有捕获任何 secrets/tokens/env dumpse2e 沙箱对真实 agent 目录做前后 digest 比对作为隔离证明包含在驱动自身逻辑中。总结两道门如何共同落地 mass-ulw 规划教义把两条链路并起来看mass-ulw DAG 规划门控形成了互补的两层防线advisory 层P1dag start时对每个节点定义做契约 lint产出模型可见的警告文本与结构化warningspayload。它不改执行语义——违反契约的图照跑但模型被明确告知哪里不符合 mass-ulw 节点 prompt 契约、哪里缺验证波从而有机会修正并换 key 重跑。强制层P2dag 的 agent 路由节点在startOwned前经过与直接taskspawn 相同的evaluateSpawnPolicy——invocation gate 拒绝未解锁的 plan-gated 代理plan-review 契约门要么拒绝要么用force改写子代理 promptcategory 路由节点刻意豁免。如果你要在 dag 定义中写出零警告的合规图请记住三条硬规则每个节点 prompt 必须含TASK:与STOP WHEN:标记理想情况写全 TASK/DELIVERABLE/SCOPE/VERIFY/STOP WHEN 五件套产生工作的图最后一个波必须是验证节点节点 id 或 prompt 含 verify/verification/audit/qa 等语义关键词start按 key 幂等修正定义后要用新 key重新启动才能清除警告。进一步阅读可参考 docs/reference/mass-ulw-protocol.md 与 docs/reference/prompt-async-gate-rfc.md以及 lint 规则与策略实现的测试佐证 packages/omo-senpi/src/components/task/dag-lint.test.ts、packages/omo-senpi/src/components/task/dag-tool.test.ts、packages/omo-senpi/src/components/task/dag-runtime.test.ts。【免费下载链接】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），仅供参考