feat(dag): publish deterministic workflow routing

docs/agents/dag-routing-evolve-summary.md

@@ -0,0 +1,94 @@
+# AHE 提示词修订 — DAG Orchestration Router
+
+## 1. 范围与职责
+
+让父对话从实时模板库选择一个主参考和自治档位，再把必要的跨领域保障组合进同一个 YAML DAG。
+
+## 2. 组件地图（修改前）
+
+- 常驻 Router 决定是否使用 DAG 和积木顺序，但不知道配置仓库已经收敛为七个领域及 `full`/`lite`。
+- 配置仓库 README 保存了档位规则，但 README 不在运行时模板发布包内。
+- `guide(topic="patterns")` 仍提供 Deep Review、Large Engineering 等另一套路线名称。
+- `workflow(action="list")` 只显示名称、标题和大小，隐藏了模板的目标。
+
+## 3. 评估笔记
+
+YAML 字段契约和文件式 authoring 已经明确；缺口在选择信息的所有权和可见性。修订不增加 Schema、积木种类或运行时状态，只删除平行路由语言并让现有模板目标进入选择面。
+
+## 4. 失败模式类
+
+### P1 — 路由权威分裂
+
+- 证据：新模板目录只在配置 README 中，常驻 Router 和 patterns guide 使用两套旧分类。
+- 根因：模板目录更新没有同步到模型真正常驻的工作流指导层。
+- 组件层级：工作流指导。
+
+### P2 — 参考库被新建路径绕过
+
+- 证据：`/dag-flow` 明示优先 fresh blocks；用户反馈表现为模型猜测 YAML 和路线。
+- 根因：命令入口没有先读取实时模板目录。
+- 组件层级：命令工作流指导。
+
+### P3 — 候选信息不足
+
+- 证据：`list` 输出缺少 `config.objective`，必须逐个 `read` 才能判断目标。
+- 根因：工具输出契约没有携带模板已经声明的选择证据。
+- 组件层级：工具输出契约。
+
+### P4 — lite 子节点越权选路
+
+- 证据：七个 lite 模板曾要求第一个子节点自行“升级 full”，但子节点既不拥有路由权，也不能阻止后续写入。
+- 根因：档位前提只写成自然语言提示，没有连接到现有 verdict condition 与父会话 wake。
+- 组件层级：配置模板拓扑、配置 CI 契约。
+
+## 5. 变更清单
+
+### chg-1 — 一个主参考加一条风险升级规则
+
+- 失败证据：P1。
+- 根因：常驻 Router 不认识领域交付物和档位边界。
+- 针对性修复：按最终交付物选择一个主参考；仅在全部低风险条件成立时使用 `lite`，任一高风险信号选择 `full`。
+- 预测影响：领域和档位选择稳定；风险是边界任务升级为 `full`，由模板裁剪抵消成本。
+- 组件层级：工作流指导。
+
+### chg-2 — patterns 只处理跨领域冲突
+
+- 失败证据：P1。
+- 根因：按需 guide 又定义了一套完整路线。
+- 针对性修复：删除六个旧 playbook；只说明如何在一个主参考中加入最小 secondary assurance。
+- 预测影响：同一目标不再拼接两套完整路线或启动多个 workflow。
+- 组件层级：按需工作流指导。
+
+### chg-3 — 库优先并显示 objective
+
+- 失败证据：P2、P3。
+- 根因：命令偏向从零生成，候选列表缺少目标。
+- 针对性修复：常驻 Router 先 `list`、再 `read`；`/dag-flow` 只委托 Router；列表显示每个模板的 `objective`。
+- 预测影响：已发布参考会先于自由生成被采用；无匹配参考时仍可使用 blocks 逃生口。
+- 组件层级：命令工作流指导、工具输出契约。
+
+### chg-4 — lite 前提失效时先阻断
+
+- 失败证据：P4。
+- 根因：子节点同时承担取证和重新选路，且没有结构化停止条件。
+- 针对性修复：七个 lite 模板在取证后增加 reporting review gate；所有后续路径均受 gate 支配，非 `ACCEPT` 会唤醒父会话并跳过后续。子节点和按需 guide 只要求 verdict、证据及 required actions；父 Router 在 workflow 完成后决定是否用新节点 ID `extend`。
+- 预测影响：运行中发现迁移、并发、安全或发布边界时不会继续写入，也不会由子节点猜测 full 路线。
+- 组件层级：配置模板拓扑、配置 CI 契约。
+
+### chg-5 — Router 单独拥有执行模式与控制选择
+
+- 失败证据：按需 policy/interface guides 重复 direct、task、workflow 选择规则，并曾要求 child 输出 `next_action`。
+- 根因：路由规则被放进三个组件，加载按需 guide 会覆盖 resident Router 的较新判断。
+- 针对性修复：policy/interface 只引用 Router 并保留各自的 tier、YAML、checkpoint 与恢复契约；工具字段和示例只接受 `list` 返回的精确名称或 YAML 路径；catalog 拒绝 child 中的 route 名、`next_action` 和具体控制操作。
+- 预测影响：加载任何 guide 不会改变已选择的执行模式；child 只能报告证据和 required actions。
+- 组件层级：resident Router、按需 guides、配置 CI 契约。
+
+## 6. 证伪计划
+
+- 小型明确功能应选 development-lite；出现跨模块迁移时应翻转为 development-full。
+- 可复现单点缺陷应选 debug-lite；未知根因或并发/持久化边界应翻转为 debug-full。
+- 需要修改代码的安全问题应保持 development/debug 主参考并加入安全保障；只要安全报告时才以 security-audit 为主。
+- 删除 gate→qualification 边、把 writer 放在 gate 前、绕过 gate 支配链或让 child 选择 full route 时，catalog 契约测试必须失败。
+- 删除 `list` 的 objective 输出后，列表契约测试必须失败；删除 Router 的领域或风险规则后，提示词契约测试必须失败。
+- 删除 lite gate 的 parent report、让后续节点绕过 gate，或重新加入子节点选路文本时，配置目录门禁必须失败。
+- 若实测仍跳过模板库，先回滚并重写 chg-3 的入口约束，不在 Router 叠加更多同义规则。

packages/core/src/plugin/command/dag-flow.txt

@@ -9,12 +9,10 @@ Otherwise apply the resident Orchestration Router and route the
 request through one consolidated graph. `/dag-flow` explicitly selects DAG
 execution; the router still owns any material Decision Checkpoint.
 
-Prefer composable blocks for a fresh flow. Load
-`workflow(action="guide", topic="blocks")` only if the block contract is not
-already in context. Write one-off work to a task-local YAML file and pass its
-`spec_path`; a matching saved workflow name is also a valid `spec_path`. Preserve
-the task, user constraints, named roles, read-only limits, acceptance checks,
-and confirmed decisions in the objective and block instructions.
+Apply the Router's selected reference or fresh-block path. Preserve the task,
+user constraints, named roles, read-only limits, acceptance checks, and
+confirmed decisions in the objective and block instructions, then pass the
+task-local YAML file's `spec_path`.
 
 Validate the YAML path, then call the workflow tool with `action=start` in the
 first response after the route is ready. Printing a plan or YAML does not start it. Never invent

packages/core/src/plugin/command/orchestration-domains.md

@@ -1,140 +1,55 @@
-# Orchestration Domains
-
-Productized workflow playbooks for recurring heavy-task domains. Each playbook
-composes the existing primitives — profiles, review lifecycle, actionable
-checkpoints, bounded repair, and the pause-first replan protocol — into a
-repeatable graph shape. Resolve every role below as a capability slot per Role
-Resolution: prefer a configured agent whose contract matches (an explore-style
-scout, a reasoner-style logic prober, a review-style verdict gate, a
-verify-style test runner), fall back to `explore`, `build`, or `general`.
-
-Every playbook is a mix of the two accuracy axes from the Tiered Orchestration
-Doctrine — **breadth** (concurrent independent slices, standard tier) and
-**depth** (verdict-gated iteration, advanced-tier judge) — at a different
-ratio. Each heading names its ratio. Place decomposition, gate, verification,
-and arbitration nodes on the advanced tier (`required: true` or a
-`review`/`review-*` worker); leave the fan-out volume on the standard tier.
-
-## The Simulated Audit Loop
-
-Iteration in a DAG is NOT a cyclic edge and NOT a harness loop. It is a
-verdict-driven replan wave — the depth axis in its pure form:
-
-1. An audit node declares `output_schema` with a normalized `verdict` and
-   `report_to_parent: true`.
-2. On `REJECT` or `REVISE`, the wake delivers findings to the parent. Per the
-   Verdict Disposal Contract the parent MUST act in that turn: it issues
-   `control(pause)`, then `control(replan)` appending a correction node and a
-   NEW audit node under NEW ids (terminal nodes are immutable), wires
-   `depends_on` forward, then `control(resume)`. If the audit node was the
-   terminal leaf, `extend` a fresh audit wave instead.
-3. Repeat until the audit returns `ACCEPT`. The loop is bounded by
-   `max_node_replan_attempts` and `max_total_nodes` — on ceiling breach stop
-   with `BLOCKED` and report the residual findings instead of retrying the
-   identical plan.
-
-Every playbook below that says "audit loop" means exactly this mechanism.
-
-## Playbook: Deep Review
-
-Ratio: breadth then depth. Multi-role adversarial review of whether a code
-structure or design is sound, scaled by the Depth Ladder.
-
-- **Breadth wave** — fan out 3+ reviewers with genuinely conflicting mandates:
-  a prosecutor (argues the structure is wrong — coupling, hidden invariants,
-  failure modes), a defender (argues the current shape is justified —
-  constraints, history, cost of change), and dimension specialists
-  (architecture, correctness, testability) as scope demands. Every reviewer
-  MUST cite file:line evidence and list what it could not confirm as
-  `unverified_claims`.
-- **Verification wave (mandatory for module scope and larger)** — one or more
-  verify-style nodes check the disputed and `unverified_claims` items against
-  the actual code before any verdict. This is what separates a review from a
-  poll of opinions; skipping it lets an unproven assertion become a finding.
-- **Arbitration (advanced tier)** — fan in to one arbiter that rules
-  finding-by-finding on the VERIFIED evidence, not merely concatenating
-  reviews, and emits the actionable checkpoint shape (`verdict`, `findings`,
-  `required_actions`, `next_action`).
-- Pre-implementation structure reviews are `design` phase. Reviewing an actual
-  change requires the diff-phase hard contract:
-  `implementation → verification(PASS) → diff review` with fingerprint echo.
-- **Depth wave** — on `REVISE`/`REJECT`, drive corrections and concurrent
-  deep-dives into the confirmed problem areas through the audit loop. The
-  arbiter's report is the start of this wave, never the end of the task.
-
-## Playbook: Deep Speculation
-
-Ratio: breadth of parallel probes, then depth through the revision loop.
-Prophesy a whole design document — stress-test it end to end and emit an
-automated verdict with zero human gates in the middle.
-
-- Internalized grill method, run as graph roles instead of user Q&A: parallel
-  nodes over the same document — a logic simulator (walk the described system,
-  surface contradictions and boundary gaps), an adversarial interrogator
-  (produce the hardest material questions: hidden assumptions, falsifiers,
-  failure modes, evidence quality), and an alternatives prober (steelman one
-  competing shape).
-- A responder node answers the interrogation strictly from the document plus
-  codebase evidence, marking each question ANSWERED / GAP / CONTRADICTION.
-- An arbiter synthesizes everything into a structured prophecy: verdict,
-  ranked risks, unresolved gaps, and a concrete revision list — then the audit
-  loop applies revisions and re-speculates until ACCEPT.
-- Fully automated: no admission QA rounds with the user mid-flight. Reserve
-  interactive `GRILL` admission for before the workflow starts.
-
-## Playbook: Large Engineering
-
-Ratio: iterated breadth and depth — parallel packages, each gated, plus a
-final audited review. Turn an execution document (todo list, work ledger, or
-spec) into audited, parallel-safe delivery.
-
-1. **Deep analysis** — scout nodes map the affected surface; an analyst node
-   decomposes the document into work packages with explicit dependency edges
-   and disjoint write sets (the tickets: each package states its blocking
-   edges, not a bare list).
-2. **Orchestrate** — compile the packages into a graph: independent packages
-   fan out in parallel, dependent ones serialize, propose-then-assemble where
-   write sets may overlap.
-3. **Audit the plan** — a plan-audit node checks the decomposition itself:
-   missing edges, false parallelism, unstated assumptions, acceptance criteria
-   per package. `REJECT` re-orchestrates via the audit loop until the plan
-   passes.
-4. **Execute** — run the audited graph with the develop-profile phases each
-   package still needs; verification consumes each implementation before any
-   diff review.
-5. **Final adversarial review** — the Deep Review playbook over the assembled
-   result, with its own audit loop.
-6. **Deliverable** — a final assembler emits the outcome report: shipped
-   packages, evidence, residual risks.
-
-## Playbook: Solution Bake-off
-
-Ratio: pure breadth — N samples of the same goal, one advanced-tier judge.
-N competing approaches implemented or prototyped in parallel against the same
-acceptance criteria; a verify-style node exercises each candidate; one arbiter
-picks the winner on evidence and records why the losers lost.
-
-## Playbook: Root-Cause Diagnosis
-
-Ratio: breadth of hypotheses first, then depth on the leading survivor.
-Fan out one node per plausible hypothesis, each tasked to falsify its own
-hypothesis with concrete evidence; an arbiter eliminates, ranks survivors, and
-either declares the root cause or replans a deeper probe wave on the leading
-survivor.
-
-## Playbook: Audit Sweeps
-
-Ratio: pure breadth per sweep cell, with the audit loop supplying depth on
-hits. The same fan-out/arbiter/audit-loop shape covers recurring sweep
-domains: security surface audit (per-surface reviewers: input handling,
-authz, secrets, dependencies), regression matrix fan-out (one verify node per
-axis cell), and docs-code drift audit (per-document checkers comparing claims
-against the code, with fix waves through the audit loop).
-
-## Choosing and Combining
-
-Playbooks compose inside one live DAG: Large Engineering embeds Deep Review at
-its gate; Deep Speculation can front-load any of them. Selection still obeys
-Execution Mode Selection and the Depth Ladder — its wave count meets the
-ladder's minimum for the target size, and explicit user constraints always
-override the playbook shape.
+# Cross-domain Workflow Composition
+
+The resident Orchestration Router and the live workflow library own route and
+`full`/`lite` selection. This guide resolves only requests where several domain
+references appear relevant. Keep one primary reference and one workflow.
+
+## Pick the backbone by the final artifact
+
+- The requested deliverable is a product decision: keep product planning as
+  the backbone; technical feasibility is evidence, not a second design route.
+- The requested deliverable is an implementation-ready design: keep technical
+  design as the backbone; product context supplies constraints.
+- The requested deliverable is changed code: keep project development as the
+  backbone unless an unknown defect first requires causal diagnosis.
+- The requested deliverable is a defect repair: keep debug and repair as the
+  backbone; the repair, regression proof, and review stay in that graph.
+- The requested deliverable is a verdict: use code review for a pinned
+  implementation change, security or performance audit for those evidence
+  domains, and technical design when the object is a proposed system or
+  migration.
+
+Security, performance, and review are secondary assurance when the requested
+artifact remains implementation or repair. They become primary only when the
+requested artifact is their report or verdict. A secondary concern is never a
+second workflow for the same objective.
+
+## Add the smallest assurance slice
+
+Read the primary reference first. Read a secondary reference only to identify
+the minimum evidence lane or gate that changes acceptance. Put those blocks in
+one task-local YAML and retarget every copied instruction to the same scope and
+acceptance criteria. Do not append a complete second reference.
+
+- A security-sensitive feature keeps the development backbone and adds scoped
+  threat, authorization, secret, or supply-chain checks before final review.
+- A security defect keeps the debug backbone and adds exploitability and
+  boundary verification around the causal repair.
+- A performance repair keeps the debug or development backbone and adds a
+  repeatable baseline plus before/after measurement.
+- A review of a dependency or release change keeps the review backbone and adds
+  only the relevant upstream provenance and reachability evidence.
+
+Reuse one exploration result across consumers. Keep one verification fan-in
+for the final implementation fingerprint and one final review or synthesis;
+duplicate explore, verify, and verdict blocks are evidence drift, not extra
+assurance. Unordered writers still share one workspace, so give them disjoint
+write sets or serialize them with real dependencies.
+
+## Preserve lifecycle contracts
+
+Composition does not redefine block fields, verdicts, repair, or recovery.
+Load `guide(topic="blocks")` for YAML shapes and block semantics, and
+`guide(topic="policy")` for admission, verdict disposal, pause-first replan,
+and bounded repair. A non-ACCEPT verdict remains actionable in the same wake
+turn; do not invent a domain-specific retry loop.