@exaudeus/workrail 3.11.0 → 3.11.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@exaudeus/workrail",
-  "version": "3.11.0",
+  "version": "3.11.1",
   "description": "Step-by-step workflow enforcement for AI agents via MCP",
   "license": "MIT",
   "repository": {

package/spec/authoring-spec.json

@@ -578,8 +578,8 @@
             "prompt.composition",
             "workflow.definition"
           ],
-          "rule": "Use extension points when a workflow wants stable customization slots rather than hardcoding routine or binding references inline.",
-          "why": "Extension points make customization explicit, inspectable, and project-overridable.",
+          "rule": "Use extension points when a workflow wants stable project-overridable delegation seams rather than hardcoding bound routine or workflow names inline.",
+          "why": "Extension points make delegated customization explicit, inspectable, and project-overridable without conflating rebinding with routine injection.",
           "enforcement": [
             "advisory"
           ],
@@ -602,11 +602,15 @@
           ],
           "checks": [
             "Declare extension points at the workflow level when bindings are part of the contract.",
-            "Avoid hidden or undocumented binding slots in prompts."
+            "Avoid hidden or undocumented binding slots in prompts.",
+            "Prefer `templateCall` when the real goal is reusable inline routine structure, visible injected steps, or parent-step confirmation behavior.",
+            "Use extension points only when the seam is intentionally delegated and may need project-level rebinding."
           ],
           "antiPatterns": [
             "Hardcoding team-customizable routine names in prompt text without an extension-point declaration",
-            "Using `{{wr.bindings.*}}` tokens in a workflow that declares no extension points"
+            "Using `{{wr.bindings.*}}` tokens in a workflow that declares no extension points",
+            "Using extension points where `templateCall` would better represent the parent workflow's real structure",
+            "Expecting `{{wr.bindings.*}}` to change which routine gets injected inline"
           ]
         }
       ]
@@ -682,6 +686,36 @@
         }
       ]
     },
+    {
+      "id": "references",
+      "title": "Workflow references",
+      "rules": [
+        {
+          "id": "references-are-for-runtime-companion-material",
+          "status": "active",
+          "level": "recommended",
+          "scope": [
+            "workflow.references",
+            "workflow.definition"
+          ],
+          "rule": "Declare references only for documents the running workflow may genuinely need while executing its task.",
+          "why": "References are surfaced to the agent at workflow start and become part of the workflow hash. Maintainer-only or authoring-only references add cognitive load and hash churn without improving runtime execution.",
+          "enforcement": [
+            "advisory"
+          ],
+          "checks": [
+            "Keep references that materially help the running workflow perform its task.",
+            "Prefer rubrics, target-system specs, policies, or playbooks that constrain runtime judgment.",
+            "If removing a reference would not make the running workflow materially worse at execution, remove it."
+          ],
+          "antiPatterns": [
+            "Adding workflow-schema references to ordinary execution workflows that are not authoring or validation workflows",
+            "Adding authoring-spec or provenance references to workflows whose runtime task is unrelated to workflow authoring",
+            "Using references to justify a workflow's design to maintainers instead of helping the running agent do the task"
+          ]
+        }
+      ]
+    },
     {
       "id": "response-supplements",
       "title": "Response supplements and delivery-owned guidance",

package/spec/production-readiness-audit-rubric.md

@@ -0,0 +1,43 @@
+## Production Readiness Audit Rubric
+
+Use this rubric when running the bundled `production-readiness-audit` workflow.
+
+### Coverage domains
+
+- Debugging and correctness
+- Runtime readiness
+- Technical debt and maintainability
+- Philosophy and repo-pattern alignment
+- Tests and observability
+- Security and performance when the audited scope materially touches them
+
+### Finding classes
+
+- **Confirmed**: supported by primary evidence such as code, tests, build output, runtime traces, or a directly checked artifact
+- **Plausible**: directionally concerning, but not yet strong enough to drive the verdict alone
+- **Rejected**: weakened or disproved by fuller context or direct evidence
+
+### Verdicts
+
+- **ready**: no material blockers, no major unresolved gaps, and confidence is strong enough for the audited scope
+- **ready_with_conditions**: broadly shippable, but bounded conditions or follow-up work still matter
+- **not_ready**: blockers or major risks make shipping irresponsible right now
+- **inconclusive**: the scope or evidence is too weak for a clean readiness call
+
+### Confidence bands
+
+- **High**: coverage is materially adequate and serious claims are backed by primary evidence
+- **Medium**: most important areas are covered, but some uncertainty or weaker proof remains
+- **Low**: major gaps, contradictions, or thin evidence still cap the verdict
+
+### Severity discipline
+
+- Do not upgrade a claim to blocker status just because multiple subagents agree
+- Do not flatten real contradictions into a single confident story without adjudication
+- Do not call a scope production-ready when a material coverage gap still weakens the verdict
+
+### Synthesis discipline
+
+- Treat delegated output as evidence, not final truth
+- Say what changed your mind, what you rejected, and why
+- Keep the final handoff decision-focused rather than implementation-focused

package/workflows/production-readiness-audit.json

@@ -0,0 +1,354 @@
+{
+  "id": "production-readiness-audit",
+  "name": "Production Readiness Audit (v2 • Evidence-Driven Readiness Review)",
+  "version": "0.1.0",
+  "description": "Audit a bounded codebase scope for debugging risk, runtime readiness, stale or misleading implementation surfaces, technical debt, and anything else that would keep it from being honestly production-ready.",
+  "recommendedPreferences": {
+    "recommendedAutonomy": "guided",
+    "recommendedRiskPolicy": "conservative"
+  },
+  "features": [
+    "wr.features.subagent_guidance"
+  ],
+  "references": [
+    {
+      "id": "audit-rubric",
+      "title": "Production Readiness Audit Rubric",
+      "source": "./spec/production-readiness-audit-rubric.md",
+      "purpose": "Canonical coverage, evidence, confidence, and verdict rubric for this workflow.",
+      "authoritative": true,
+      "resolveFrom": "package"
+    }
+  ],
+  "preconditions": [
+    "The user provides a target scope or the agent can infer a bounded scope from the request.",
+    "The agent can inspect the code, surrounding context, and deterministic evidence needed to assess readiness honestly.",
+    "A human will consume the final verdict, findings, or remediation order."
+  ],
+  "metaGuidance": [
+    "DEFAULT BEHAVIOR: self-execute with tools. Ask only for true scope decisions, missing external artifacts, or permissions you cannot resolve yourself.",
+    "V2 DURABILITY: keep workflow truth in output.notesMarkdown and explicit context fields. Human-facing markdown artifacts are optional companions only.",
+    "OWNERSHIP: the main agent owns the fact packet, synthesis, severity calibration, verdict, and remediation order. Delegated work is evidence, not authority.",
+    "SUBAGENT DISCIPLINE: use a few explicit fan-out and fan-in checkpoints rather than scattered optional subagent calls.",
+    "READINESS MODEL: first understand and bound the scope, then state a readiness hypothesis, then freeze a neutral readiness fact packet, then let reviewer families challenge it in parallel, then reconcile contradictions explicitly.",
+    "COVERAGE LEDGER: track audit domains as `checked`, `uncertain`, `not_applicable`, `contradicted`, or `needs_followup`. Do not finalize with unresolved material gaps unless you name them clearly.",
+    "VERDICTS: allow `ready`, `ready_with_conditions`, `not_ready`, and `inconclusive`. Do not force a cleaner answer than the evidence supports.",
+    "BOUNDARY: this workflow audits and prioritizes. It must not drift into implementation planning or patch sequencing unless the user explicitly asks."
+  ],
+  "steps": [
+    {
+      "id": "phase-0-understand-and-classify",
+      "title": "Phase 0: Understand and Classify",
+      "promptBlocks": {
+        "goal": "Build the minimum complete understanding needed to audit readiness honestly.",
+        "constraints": [
+          [
+            { "kind": "ref", "refId": "wr.refs.notes_first_durability" }
+          ],
+          "Use tools first. Ask only for true scope or permission gaps you cannot resolve yourself.",
+          "Separate in-scope code from adjacent noise before you classify rigor or risk."
+        ],
+        "procedure": [
+          "Locate the real target surface, likely entry points, critical paths, public contracts, invariants, data or runtime surfaces, and affected consumers that matter.",
+          "Find the repo patterns and philosophy sources that should shape the audit, and state what production-ready should mean for this scope instead of assuming a generic bar.",
+          "Classify `scopeShape`, `riskLevel`, `rigorMode`, `criticalSurfaceTouched`, and `needsSimulation` after exploration, not before.",
+          "Run a context-clarity check with concrete scores for boundary clarity, production-bar clarity, philosophy clarity, and verification clarity.",
+          "If rigor and uncertainty justify it, spawn TWO WorkRail Executors in parallel running `routine-context-gathering` with complementary completeness/depth focus, then synthesize what changed."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Audit scope, production bar, classification, clarity scores, and what is still unknown.",
+          "context": "Capture scopeShape, riskLevel, rigorMode, contextSummary, candidateFiles, criticalPaths, productionBar, contextUnknownCount, criticalSurfaceTouched, needsSimulation, and openQuestions."
+        },
+        "verify": [
+          "The classification is driven by evidence, not vibes.",
+          "Open questions are real human-decision gaps only.",
+          "If scope is whole-codebase or risk is High, treat confirmation as a real review barrier."
+        ]
+      },
+      "requireConfirmation": {
+        "or": [
+          { "var": "scopeShape", "equals": "whole_codebase" },
+          { "var": "riskLevel", "equals": "High" }
+        ]
+      }
+    },
+    {
+      "id": "phase-1-state-readiness-hypothesis",
+      "title": "Phase 1: State Readiness Hypothesis",
+      "promptBlocks": {
+        "goal": "State your current readiness hypothesis before the reviewer families challenge it.",
+        "constraints": [
+          "Keep this short and falsifiable.",
+          "This is a reference point, not a position to defend."
+        ],
+        "procedure": [
+          "Write your current best guess about the likely readiness verdict direction.",
+          "Name the issue category or failure mode you are most worried about right now.",
+          "Say what would most likely make your current view wrong."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Current readiness hypothesis and the strongest reason it might be wrong.",
+          "context": "Capture readinessHypothesis."
+        },
+        "verify": [
+          "The hypothesis is concrete enough that later synthesis can say what changed your mind."
+        ]
+      },
+      "requireConfirmation": false
+    },
+    {
+      "id": "phase-2-freeze-fact-packet-and-select-reviewers",
+      "title": "Phase 2: Freeze Fact Packet and Select Reviewer Families",
+      "promptBlocks": {
+        "goal": "Freeze a neutral readiness fact packet and decide how much reviewer-family parallelism is warranted.",
+        "constraints": [
+          [
+            { "kind": "ref", "refId": "wr.refs.notes_first_durability" }
+          ],
+          "The fact packet is the primary truth for downstream reviewer families.",
+          "Keep `readinessHypothesis` as a hypothesis to challenge, not a frame to defend.",
+          "Keep any live audit artifact optional. Workflow truth lives in notes and context."
+        ],
+        "procedure": [
+          "Create a neutral `readinessFactPacket` containing: scope purpose and expected behavior, key entry points and runtime surfaces, critical invariants and failure costs, data and deployment assumptions, changed or risky seams, test/observability posture, repo patterns and philosophy constraints, and explicit open unknowns.",
+          "Include realism signals directly in the fact packet: likely dead code paths, fixture or fake-data dependence, placeholder behavior, stale comments or docs, and any seams that look misleadingly complete.",
+          "Initialize `coverageLedger` for these domains: `debugging_correctness`, `runtime_operability`, `artifact_realism`, `maintainability_debt`, `tests_observability`, `philosophy_patterns`, `security_performance`.",
+          "Perform a preliminary self-audit from the fact packet before choosing reviewer families.",
+          "Reviewer family options: `correctness_debugging`, `runtime_operability`, `artifact_realism`, `maintainability_debt`, `tests_observability`, `philosophy_patterns`, `security_performance`, `false_positive_skeptic`, `missed_issue_hunter`.",
+          "Selection guidance: QUICK = no bundle by default unless ambiguity still feels material; STANDARD = 4 or 5 families by default; THOROUGH = 6 or 7 families by default.",
+          "Always include `correctness_debugging`, `runtime_operability`, and `artifact_realism` unless clearly not applicable. Include `security_performance` when the scope touches auth, permissions, input trust boundaries, secrets, network surfaces, data exposure, resource intensity, latency-sensitive flows, or unbounded work. Include `tests_observability` in STANDARD and THOROUGH unless clearly not applicable. Include `philosophy_patterns` when the repo or user philosophy is strong enough to judge honestly. Include `missed_issue_hunter` in THOROUGH. Include `false_positive_skeptic` when blocker or major-grade findings already look plausible or severity inflation risk is non-trivial.",
+          "Set `needsReviewerBundle` explicitly. Set `coverageUncertainCount` as the number of coverage domains not yet safely closed: `uncertain` + `contradicted` + `needs_followup`. Initialize `contradictionCount`, `blindSpotCount`, and `falsePositiveRiskCount` to `0` if no reviewer-family bundle will run."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Neutral readiness fact packet, preliminary self-audit, selected reviewer families, and why the bundle is sized the way it is.",
+          "context": "Capture readinessFactPacket, coverageLedger, selectedReviewerFamilies, needsReviewerBundle, coverageUncertainCount, contradictionCount, blindSpotCount, falsePositiveRiskCount, needsSimulation."
+        },
+        "verify": [
+          "The fact packet is concrete enough that downstream reviewer families can use it without regathering broad context.",
+          "The workflow has a clear reason for whether `needsReviewerBundle` is true or false."
+        ]
+      },
+      "promptFragments": [
+        {
+          "id": "phase-2-quick",
+          "when": { "var": "rigorMode", "equals": "QUICK" },
+          "text": "Keep the fact packet compact. QUICK should not manufacture a giant ceremony layer."
+        },
+        {
+          "id": "phase-2-thorough",
+          "when": { "var": "rigorMode", "equals": "THOROUGH" },
+          "text": "For THOROUGH rigor, make the hidden-risk surfaces explicit: blind spots, fake confidence vectors, and production assumptions that would hurt if wrong."
+        }
+      ],
+      "requireConfirmation": false
+    },
+    {
+      "id": "phase-3-reviewer-family-bundle",
+      "title": "Phase 3: Parallel Reviewer Family Bundle",
+      "runCondition": {
+        "var": "needsReviewerBundle",
+        "equals": true
+      },
+      "promptBlocks": {
+        "goal": "Run the selected reviewer families in parallel from the same readiness fact packet, then synthesize their output as evidence rather than conclusions.",
+        "constraints": [
+          [
+            { "kind": "ref", "refId": "wr.refs.notes_first_durability" }
+          ],
+          [
+            { "kind": "ref", "refId": "wr.refs.synthesis_under_disagreement" }
+          ],
+          "Each reviewer family must use `readinessFactPacket` as primary truth.",
+          "Use `readinessHypothesis` only as comparison context.",
+          "Reviewer-family outputs are raw evidence, not canonical audit state."
+        ],
+        "procedure": [
+          "Before delegating, restate the current `readinessHypothesis` and say which reviewer family is most likely to challenge it.",
+          "Each reviewer family must return: top findings, strongest evidence, biggest uncertainty, likely false-confidence vector, and what would most likely falsify its current conclusion.",
+          "Family missions: `correctness_debugging` = logic defects, contradictory state, failure paths, unsafe assumptions, and strongest debugging leads; `runtime_operability` = production behavior, concurrency/state flow, deployment assumptions, resilience, rollback pain, and observability under failure; `artifact_realism` = stale code, dead seams, placeholder behavior, misleading comments/docs, fake-data dependence, and surfaces that look complete but are not; `maintainability_debt` = complexity, duplication, brittle seams, drift, and future-change cost; `tests_observability` = test adequacy, verification blind spots, logging/monitoring gaps, hidden failure modes, and rollout confidence; `philosophy_patterns` = architectural consistency, repo-pattern drift, and principle tension; `security_performance` = trust boundaries, auth/permission mistakes, secrets handling, unsafe inputs, data exposure, expensive paths, unbounded work, and performance cliffs likely to matter in production; `false_positive_skeptic` = challenge overreach, weak evidence, or severity inflation; `missed_issue_hunter` = search for an important issue family the others may miss.",
+          "Mode-adaptive parallelism: STANDARD = spawn FOUR WorkRail Executors simultaneously for the selected families; THOROUGH = spawn SIX WorkRail Executors simultaneously for the selected families.",
+          "After receiving outputs, explicitly synthesize: what reviewer families confirmed, what was genuinely new, what appeared weak or overreached, and what changed your mind or did not.",
+          "Build a compact `familyEvidenceLedger` for each selected family covering its strongest concern, strongest evidence, biggest uncertainty, and what could make it wrong."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Reviewer-family synthesis, contradictions, blind spots, false-positive challenges, and the family evidence ledger.",
+          "context": "Capture familyEvidenceLedger, familyFindingsSummary, contradictionCount, blindSpotCount, falsePositiveRiskCount, coverageUncertainCount, and needsSimulation."
+        },
+        "verify": [
+          "The same fact packet was used as primary truth across reviewer families.",
+          "Reviewer-family output is not treated as self-finalizing.",
+          "Contradictions, blind spots, and false-positive risks are reflected structurally in context."
+        ]
+      },
+      "requireConfirmation": false
+    },
+    {
+      "id": "phase-4-evidence-and-contradiction-loop",
+      "type": "loop",
+      "title": "Phase 4: Evidence and Contradiction Loop",
+      "loop": {
+        "type": "while",
+        "conditionSource": {
+          "kind": "artifact_contract",
+          "contractRef": "wr.contracts.loop_control",
+          "loopId": "readiness_synthesis_loop"
+        },
+        "maxIterations": 4
+      },
+      "body": [
+        {
+          "id": "phase-4a-targeted-follow-up",
+          "title": "Targeted Follow-Up Bundle",
+          "promptBlocks": {
+            "goal": "If contradictions, blind spots, or important coverage gaps remain, run only the smallest targeted follow-up needed.",
+            "constraints": [
+              [
+                { "kind": "ref", "refId": "wr.refs.parallelize_cognition_serialize_synthesis" }
+              ],
+              "Prefer one compact targeted bundle over repeated broad delegation moments.",
+              "Do not regather broad context unless a contradiction proves the original fact packet is insufficient.",
+              "Targeted follow-up output is evidence only and must still be synthesized by the main agent."
+            ],
+            "procedure": [
+              "Before delegating, state the current likely readiness verdict, the strongest unresolved concern, and what result would change your mind.",
+              "If `contradictionCount > 0`, run targeted challenge or validation aimed at the specific disagreement.",
+              "If `coverageUncertainCount > 0` or `blindSpotCount > 0`, run the smallest reviewer-family or context follow-up needed to close the gap.",
+              "If `needsSimulation = true`, include `routine-execution-simulation`.",
+              "If `falsePositiveRiskCount > 0`, include `routine-hypothesis-challenge`.",
+              "If philosophy tension is materially affecting severity or verdict quality, include `routine-philosophy-alignment`.",
+              "If no trigger fires, do not delegate this step."
+            ],
+            "outputRequired": {
+              "notesMarkdown": "What targeted follow-up ran, why it was needed, and what it resolved or failed to resolve."
+            },
+            "verify": [
+              "Only the smallest targeted bundle needed was run.",
+              "No broad context regather happened without an explicit contradiction-driven reason."
+            ]
+          },
+          "requireConfirmation": false
+        },
+        {
+          "id": "phase-4b-canonical-synthesis",
+          "title": "Canonical Synthesis and Coverage Update",
+          "promptBlocks": {
+            "goal": "Turn reviewer-family evidence and follow-up work into one canonical readiness state.",
+            "constraints": [
+              "If a blocker-grade or major-grade finding is still only plausible, say so plainly instead of silently upgrading it.",
+              "If a domain remains uncertain, carry that uncertainty into the final verdict."
+            ],
+            "procedure": [
+              "Revisit `readinessHypothesis`: say what the evidence confirmed, what it challenged, what changed your mind, what held firm, and what you explicitly reject.",
+              "Apply this decision table: if multiple reviewer families independently surface the same serious issue with compatible evidence, treat it as strongly supported; if severities disagree, default upward only when the lower-severity position lacks concrete counter-evidence; if one family says false positive and another says valid issue, explicitly adjudicate the disagreement in notes before finalization; if simulation reveals a new operational risk, add a new finding and re-evaluate verdict confidence.",
+              "Update the findings ledger and classify each material finding as Confirmed, Plausible, or Rejected.",
+              "Update the coverage ledger honestly: move a domain to `checked` only when evidence is materially adequate; keep it `uncertain` if disagreement or missing evidence still affects verdict quality; use `not_applicable` only when the scope truly does not engage that area; clear `contradicted` only when the contradiction is explicitly resolved.",
+              "Cap `finalConfidenceBand` downward when unresolved blind spots still cover materially risky space, and prefer `inconclusive` later if those blind spots remain decision-relevant without a cheap next check."
+            ],
+            "outputRequired": {
+              "notesMarkdown": "Canonical findings ledger update, readiness-hypothesis comparison, coverage update, and confidence update.",
+              "context": "Capture findingsLedger, confirmedFindingsCount, plausibleFindingsCount, rejectedFindingsCount, blockerCount, majorGapCount, coverageLedger, coverageUncertainCount, contradictionCount, blindSpotCount, falsePositiveRiskCount, finalConfidenceBand, needsEvidenceRefinement."
+            },
+            "verify": [
+              "Decision-driving findings are explicitly classified.",
+              "Coverage status matches the actual evidence quality."
+            ]
+          },
+          "requireConfirmation": false
+        },
+        {
+          "id": "phase-4c-loop-decision",
+          "title": "Synthesis Loop Decision",
+          "promptBlocks": {
+            "goal": "Decide whether the evidence-and-contradiction loop should continue.",
+            "constraints": [
+              "Use the trigger rules, not vibes."
+            ],
+            "procedure": [
+              "Continue if `contradictionCount > 0`.",
+              "Otherwise continue if `coverageUncertainCount > 0` and the uncertainty materially affects the verdict.",
+              "Otherwise continue if `falsePositiveRiskCount > 0` for a serious finding, or if `blindSpotCount > 0` for uncovered materially risky space.",
+              "Otherwise continue if `needsEvidenceRefinement = true`.",
+              "Otherwise stop."
+            ],
+            "outputRequired": {
+              "artifact": "Emit a `wr.loop_control` artifact for `readiness_synthesis_loop` with `decision` set to `continue` or `stop`."
+            },
+            "verify": [
+              "The output preserves the loop-control contract without forcing one decision in the example."
+            ]
+          },
+          "outputContract": {
+            "contractRef": "wr.contracts.loop_control"
+          },
+          "requireConfirmation": false
+        }
+      ]
+    },
+    {
+      "id": "phase-5-final-validation",
+      "title": "Phase 5: Final Validation",
+      "promptBlocks": {
+        "goal": "Stress-test the current readiness verdict before final handoff.",
+        "constraints": [
+          [
+            { "kind": "ref", "refId": "wr.refs.adversarial_challenge_rules" }
+          ],
+          [
+            { "kind": "ref", "refId": "wr.refs.synthesis_under_disagreement" }
+          ],
+          "Validation output is evidence to synthesize, not automatic authority."
+        ],
+        "procedure": [
+          "Run final validation if any of these are true: `criticalSurfaceTouched = true`, `needsSimulation = true`, `falsePositiveRiskCount > 0`, `blindSpotCount > 0`, `coverageUncertainCount > 0`, or `finalConfidenceBand != High`.",
+          "Before delegating, state: what is your current verdict, where are you least confident, and what finding would most likely change your mind now.",
+          "Set the current readiness verdict first: `ready`, `ready_with_conditions`, `not_ready`, or `inconclusive`.",
+          "Use `inconclusive` deliberately when material coverage uncertainty or unresolved blind spots remain and there is no bounded next check that would resolve them cheaply.",
+          "Mode-adaptive validation: QUICK = self-validate and optionally spawn ONE WorkRail Executor running `routine-hypothesis-challenge` if a serious uncertainty remains; STANDARD = if validation is required and delegation is available, spawn TWO WorkRail Executors simultaneously running `routine-hypothesis-challenge` and either `routine-execution-simulation` or `routine-final-verification`; THOROUGH = if validation is required and delegation is available, spawn THREE WorkRail Executors simultaneously running `routine-hypothesis-challenge`, `routine-execution-simulation` when needed, and `routine-final-verification`.",
+          "After receiving validator output, explicitly synthesize what was confirmed, what was new, what appears weak, and whether your verdict changed.",
+          "State explicitly whether the verdict is being limited by unresolved contradictions, unresolved false-positive risk, blind spots, or coverage uncertainty."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Validation synthesis, verdict stress test, and any conditions the verdict still depends on.",
+          "context": "Capture finalVerdict, finalConfidenceBand, validationSummary, followUpCount, and verdictConditions."
+        },
+        "verify": [
+          "If multiple validators still raise serious concerns, confidence is downgraded and synthesis is reopened.",
+          "If exactly one validator raises a concern, it is adjudicated before finalization.",
+          "If no validator can materially break the current verdict and the evidence is internally consistent, proceed to handoff."
+        ]
+      },
+      "requireConfirmation": {
+        "or": [
+          { "var": "finalConfidenceBand", "equals": "Low" },
+          { "var": "finalVerdict", "equals": "inconclusive" }
+        ]
+      }
+    },
+    {
+      "id": "phase-6-final-handoff",
+      "title": "Phase 6: Final Handoff",
+      "promptBlocks": {
+        "goal": "Deliver the final production-readiness handoff for a human decision-maker.",
+        "constraints": [
+          "This workflow informs a decision. It does not approve a release or make code changes by itself.",
+          "Do not drift into implementation planning, patch sequencing, or PR execution unless the user explicitly asks."
+        ],
+        "procedure": [
+          "Summarize the target scope, audit intent, final verdict, and confidence band.",
+          "List blocker-grade findings, major gaps, strongest remaining uncertainties, top confirmed findings, and plausible but unresolved findings that still matter.",
+          "Call out the strongest debugging leads, runtime or operational risks, artifact-realism concerns such as stale code or fake completeness, and the most important technical-debt themes.",
+          "Summarize the coverage ledger, especially any domains still uncertain or needing follow-up.",
+          "Give a remediation order and verification or monitoring follow-ups. Mention human-facing companion artifacts only if you actually created them."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Decision-ready final handoff covering verdict, confidence, findings, coverage gaps, and recommended remediation order."
+        },
+        "verify": [
+          "The handoff is verdict-first and evidence-aware.",
+          "Open uncertainty is disclosed rather than hidden."
+        ]
+      },
+      "requireConfirmation": false
+    }
+  ]
+}

package/workflows/workflow-for-workflows.v2.json

@@ -1,25 +1,30 @@
 {
   "id": "workflow-for-workflows",
-  "name": "Workflow Authoring Workflow (Lean, References-First)",
-  "version": "2.0.0",
-  "description": "Guides an agent through authoring or modernizing a WorkRail workflow: understand the task, choose the shape, draft or revise the JSON, validate with real validators, review the method, and optionally refine.",
+  "name": "Workflow Authoring Workflow (Quality Gate v2)",
+  "version": "2.1.0",
+  "description": "Guides an agent through authoring or modernizing a WorkRail workflow with a stronger quality gate: understand the task, define effectiveness targets, design both workflow and quality architecture, draft, validate, simulate execution, run adversarial review, redesign if needed, and only then hand off.",
   "recommendedPreferences": {
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
   },
+  "features": [
+    "wr.features.subagent_guidance"
+  ],
   "preconditions": [
     "User has a recurring task or problem a workflow should solve, or an existing workflow that should be modernized.",
     "Agent has access to file creation, editing, and terminal tools.",
-    "Agent can run workflow validators (npm run validate:registry or equivalent)."
+    "Agent can run workflow validators such as `npm run validate:registry` or equivalent."
   ],
   "metaGuidance": [
     "REFERENCE HIERARCHY: treat workflow-schema as legal truth for structure. Treat authoring-spec as canonical current guidance for what makes a workflow good. Treat authoring-provenance as optional maintainer context only.",
     "META DISTINCTION: you are authoring or modernizing a workflow, not executing one. Keep the authored workflow's concerns separate from this meta-workflow's execution.",
+    "QUALITY-GATE ROLE: this workflow is the trust gate for other workflows. It must optimize not only for validity and modern authoring, but also for task effectiveness, false-confidence resistance, and future maintainability.",
     "DEFAULT BEHAVIOR: self-execute with tools. Only ask the user for business decisions about the workflow being authored or modernized, not things you can learn from the schema, authoring spec, or example workflows.",
     "AUTHORED VOICE: prompts in the authored workflow must be user-voiced. No middleware narration, no pseudo-DSL, no tutorial framing, no teaching-product language.",
-    "VOICE ADAPTATION: the lean coding workflow is one voice example, not the universal template. Copy structural patterns, not domain language. Adapt vocabulary and tone to the authored workflow's domain.",
-    "VOICE EXAMPLES: Coding: 'Review the changes in this MR.' Ops: 'Check whether the pipeline is healthy.' Content: 'Read the draft and check the argument.' NOT: 'The system will now perform a comprehensive analysis of...'",
+    "BASELINE DISCIPLINE: choose both an authoring baseline and an outcome baseline whenever possible. Copy structural patterns, not domain language.",
     "VALIDATION GATE: validate with real validators, not regex approximations. When validator output and authoring assumptions conflict, runtime wins.",
+    "DEEP REVIEW: authoring integrity and outcome effectiveness are separate concerns. A workflow is not ready unless both pass.",
+    "THOROUGH MODE: for complex or high-trust workflow work, prefer the deepest review path: state economy audit, execution simulation, adversarial review, and redesign if hard gates fail.",
     "ARTIFACT STRATEGY: the workflow JSON file is the primary output. Intermediate notes go in output.notesMarkdown. Do not create extra planning artifacts unless the workflow is genuinely complex.",
     "V2 DURABILITY: use output.notesMarkdown as the primary durable record. Do not mirror execution state into CONTEXT.md or markdown checkpoint files.",
     "ANTI-PATTERNS TO AVOID IN AUTHORED WORKFLOWS: no pseudo-function metaGuidance, no learning-path branching, no satisfaction-score loops, no heavy clarification batteries, no regex-as-primary-validation, no celebration phases.",
@@ -76,28 +81,120 @@
     },
     {
       "id": "lean-coding-workflow",
-      "title": "Lean Coding Workflow (Modern Example)",
+      "title": "Lean Coding Workflow (Modern Authoring Baseline)",
       "source": "workflows/coding-task-workflow-agentic.lean.v2.json",
       "resolveFrom": "package",
-      "purpose": "Current modern example of a well-authored workflow. Inspect for patterns, voice, loop semantics, prompt fragments, and delegation policy.",
+      "purpose": "Strong modern example for engine-native authoring patterns, loop semantics, prompt density, and bounded delegation.",
+      "authoritative": false
+    },
+    {
+      "id": "mr-review-workflow",
+      "title": "MR Review Workflow (Outcome Baseline Example)",
+      "source": "workflows/mr-review-workflow.agentic.v2.json",
+      "resolveFrom": "package",
+      "purpose": "Strong example of hypothesis, neutral fact packet, reviewer families, contradiction synthesis, and final validation.",
+      "authoritative": false
+    },
+    {
+      "id": "readiness-audit-workflow",
+      "title": "Production Readiness Audit (Audit Baseline Example)",
+      "source": "workflows/production-readiness-audit.json",
+      "resolveFrom": "package",
+      "purpose": "Example of a thorough evidence-driven audit workflow with explicit reviewer-family structure and confidence handling.",
       "authoritative": false
     }
   ],
   "steps": [
     {
-      "id": "phase-0-understand",
-      "title": "Phase 0: Understand the Workflow to Author or Modernize",
-      "prompt": "Before you write anything, understand what you're working on.\n\nStart by reading:\n- `workflow-schema` reference (legal structure)\n- `authoring-spec` reference (canonical authoring rules)\n- `authoring-guide-v2` reference (current v2 authoring principles)\n- `workflow-authoring-reference` reference (detailed structure patterns)\n- `lean-coding-workflow` reference (modern example to inspect)\n\nRead `routines-guide` too if you think the authored workflow may need delegation or template injection.\n\nThen decide what kind of authoring task this is:\n- `authoringMode`: `create` or `modernize_existing`\n\nIf `authoringMode = create`, understand:\n- What recurring task or problem should this workflow solve?\n- Who runs it and how often?\n- What does success look like?\n- What constraints exist (tools, permissions, domain rules)?\n\nIf `authoringMode = modernize_existing`, understand:\n- Which workflow file is being updated?\n- What should stay the same about its purpose?\n- What feels stale, legacy, repetitive, or misaligned with current authoring guidance?\n- What constraints apply to the modernization (keep file path, preserve compatibility, avoid broad rewrites, etc.)?\n- Which modern example should act as the primary baseline, if any?\n\nFor `modernize_existing`, make an explicit baseline decision before architecture work:\n- choose exactly one `primaryBaseline` when a single modern example fits well\n- optional `secondaryBaselines` may be used for supporting patterns only\n- if no single baseline fits, set `primaryBaseline = none` and explain whether you are using a hybrid baseline or reasoning directly from schema + authoring guidance\n- list `patternsToBorrow` and `patternsToAvoid`\n\nRule:\n- baselines are models, not templates. Copy structural patterns, not another workflow's domain voice.\n\nExplore first. Use tools to understand the existing workflow, surrounding docs, and relevant domain context. Ask the user only what you genuinely cannot figure out yourself.\n\nThen classify:\n- `workflowComplexity`: Simple (linear, few steps) / Medium (branches, loops, or moderate step count) / Complex (multiple loops, delegation, extension points, many steps)\n- `rigorMode`: QUICK (simple linear workflow, low risk) / STANDARD (moderate complexity or domain risk) / THOROUGH (complex architecture, high stakes, needs review loops)\n\nCapture:\n- `authoringMode`\n- `workflowComplexity`\n- `rigorMode`\n- `taskDescription`\n- `intendedAudience`\n- `successCriteria`\n- `domainConstraints`\n- `targetWorkflowPath` (required for `modernize_existing`, otherwise empty)\n- `modernizationGoals` (required for `modernize_existing`, otherwise empty)\n- `primaryBaseline` (for `modernize_existing`, otherwise empty)\n- `secondaryBaselines` (for `modernize_existing`, otherwise empty)\n- `baselineDecisionRationale` (for `modernize_existing`, otherwise empty)\n- `patternsToBorrow` (for `modernize_existing`, otherwise empty)\n- `patternsToAvoid` (for `modernize_existing`, otherwise empty)\n- `openQuestions` (only real questions that need user input)",
+      "id": "phase-0-understand-and-classify",
+      "title": "Phase 0: Understand and Classify the Authoring Task",
+      "promptBlocks": {
+        "goal": "Understand what workflow you are authoring or modernizing, and classify the task before you design anything.",
+        "constraints": [
+          [
+            { "kind": "ref", "refId": "wr.refs.notes_first_durability" }
+          ],
+          "Explore first. Ask the user only what you genuinely cannot determine with tools and references.",
+          "Choose baselines as models, not templates. Copy structural patterns, not another workflow's domain voice."
+        ],
+        "procedure": [
+          "Read the schema, authoring spec, v2 authoring guides, and the strongest relevant example workflows.",
+          "Decide `authoringMode`: `create` or `modernize_existing`.",
+          "Classify the target workflow archetype: `review_audit`, `coding_execution`, `diagnostic_investigation`, `planning_design`, `linear_operational`, or `content_analysis`.",
+          "Classify `workflowComplexity`: Simple, Medium, or Complex. Classify `rigorMode`: QUICK, STANDARD, or THOROUGH.",
+          "Choose an `authoringBaseline` for engine-native authoring quality and an `outcomeBaseline` for the kind of job the authored workflow should perform. If no good baseline exists for one of them, set it to `none` and explain why.",
+          "If `authoringMode = modernize_existing`, identify what must stay the same about purpose, what feels stale, and what modernization constraints apply."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Task understanding, baseline choices, patterns to borrow or avoid, and any real open questions.",
+          "context": "Capture authoringMode, workflowArchetype, workflowComplexity, rigorMode, taskDescription, intendedAudience, successCriteria, domainConstraints, targetWorkflowPath, modernizationGoals, authoringBaseline, outcomeBaseline, baselineDecisionRationale, authoringPatternsToBorrow, outcomePatternsToBorrow, patternsToAvoid, openQuestions."
+        },
+        "verify": [
+          "The task is understood well enough to design the workflow without guessing blindly.",
+          "Both authoring and outcome baselines are explicit, or their absence is justified."
+        ]
+      },
       "requireConfirmation": true
     },
     {
-      "id": "phase-1-shape",
-      "title": "Phase 1: Choose the Workflow Shape",
+      "id": "phase-1-define-effectiveness-target",
+      "title": "Phase 1: Define the Effectiveness Target",
+      "promptBlocks": {
+        "goal": "Define what success should feel like for the authored workflow, not just what fields it should contain.",
+        "constraints": [
+          "Be specific about user satisfaction and dangerous false-confidence outcomes.",
+          "Distinguish a technically valid workflow from a satisfying one."
+        ],
+        "procedure": [
+          "State what result the authored workflow should reliably produce for its user.",
+          "List the criteria that would make the workflow feel genuinely satisfying in practice.",
+          "Name the biggest likely failure mode and the most dangerous false-confidence mode.",
+          "State what would make the workflow technically correct but still disappointing."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Effectiveness target, satisfaction criteria, failure modes, and false-confidence risks.",
+          "context": "Capture effectivenessTarget, userSatisfactionCriteria, primaryFailureMode, dangerousFalseConfidenceModes, likelyWeakOutcomeModes, and trustRisk."
+        },
+        "verify": [
+          "The authored workflow now has a clear outcome bar, not just an authoring bar."
+        ]
+      },
+      "requireConfirmation": false
+    },
+    {
+      "id": "phase-2-design-workflow-architecture",
+      "title": "Phase 2: Design the Workflow Architecture",
       "runCondition": {
         "var": "workflowComplexity",
         "not_equals": "Simple"
       },
-      "prompt": "Decide the architecture before you write JSON.\n\nBased on what you learned in Phase 0, decide:\n\n1. **Step structure**: how many phases, what each one does, what order\n2. **Loops**: does any phase need iteration? If so, what are the exit rules and max iterations?\n\nLoop design heuristics:\n- Add a loop ONLY when: (a) a quality gate may fail on first pass (validation, review), (b) each pass adds measurable value (progressive refinement), or (c) external feedback requires re-execution.\n- Do NOT loop when: (a) the agent can get it right in one pass with sufficient context, or (b) the full workflow is cheap enough to re-run entirely.\n- Every loop needs: an explicit exit condition (not vibes), a bounded maxIterations, and a decision step with outputContract.\n- Sensible defaults: validation ≈ 2-3, review/refinement ≈ 2, user-feedback ≈ 2-3 with confirmation gate. Go higher only with explicit justification in your notes.\n3. **Confirmation gates**: where does the user genuinely need to approve before proceeding? Don't add confirmations as ceremony.\n4. **Delegation and reuse**: for each phase, decide between direct execution, routine delegation, template injection, or no special mechanism. If a routine or template is not used, say why not. Keep delegation bounded and keep ownership with the main agent.\n5. **Prompt composition**: will any steps need promptFragments for rigor-mode branching? Will any steps share enough structure to use templates?\n6. **Extension points**: are there customizable slots that projects might want to override (e.g., a verification routine, a review routine)?\n7. **References**: should the authored workflow declare its own references to external docs?\n8. **Artifacts**: what does each step produce? Which artifact is canonical for which concern?\n9. **metaGuidance**: what persistent behavioral rules should the agent see on start and resume?\n\nIf `authoringMode = modernize_existing`, also decide:\n- should this workflow be preserved mostly in place, restructured selectively, or rewritten more substantially?\n- which existing steps, loops, references, or metaGuidance should stay because they still fit the workflow's purpose?\n- which legacy patterns or repetitive sections should be removed or reshaped?\n- whether the file path should stay the same or whether a new variant/file is genuinely warranted\n- how each major old phase or behavior maps to the new workflow: `keep`, `merge`, `remove`, or `replace`\n\nFor `modernize_existing`, create a compact legacy mapping in your notes. For each major old phase or behavior, record:\n- source step or behavior\n- disposition: `keep` / `merge` / `remove` / `replace`\n- rationale\n- destination in the new workflow, if any\n\nFor routine and template decisions, create a compact audit in your notes. For each meaningful phase or concern, record:\n- chosen mechanism: direct / routine / template / none\n- why it helps or why it would be overkill\n- the ownership boundary that stays with the main agent\n\nWrite the shape as a structured outline in your notes. Include:\n- Phase list with titles and one-line goals\n- Which phases loop and why\n- Which phases have confirmation gates and why\n- Context variables that flow between phases\n- Artifact ownership (which artifact is canonical for what)\n- for `modernize_existing`: whether the plan is preserve-in-place, restructure, or rewrite-biased and why\n\nDon't write JSON yet.\n\nCapture:\n- `workflowOutline`\n- `loopDesign`\n- `confirmationDesign`\n- `delegationDesign`\n- `artifactPlan`\n- `contextModel` (the context variables the workflow will use and where they're set)\n- `voiceStrategy` (domain vocabulary, authority posture: directive/collaborative/supervisory, density calibration)\n- `routineAudit`\n- `delegationBoundaries`\n- `templateInjectionPlan`\n- `modernizationStrategy` (for `modernize_existing`: preserve_in_place / restructure / rewrite, otherwise empty)\n- `legacyMapping` (for `modernize_existing`, otherwise empty)\n- `behaviorPreservationNotes` (for `modernize_existing`, otherwise empty)",
+      "promptBlocks": {
+        "goal": "Decide the workflow architecture before you write JSON.",
+        "constraints": [
+          "Separate workflow architecture from quality-gate architecture. This phase is about the authored workflow itself.",
+          "Keep delegation bounded and keep ownership with the main agent."
+        ],
+        "procedure": [
+          "Decide the phase list, one-line goal for each phase, and overall ordering.",
+          "Design loops with explicit exit rules, bounded maxIterations, and real reasons for another pass.",
+          "Decide confirmation gates, delegation vs template injection vs direct execution, promptFragments, references, artifacts, and metaGuidance.",
+          "If `authoringMode = modernize_existing`, decide whether the plan is preserve-in-place, restructure, or rewrite, and map legacy behaviors as `keep`, `merge`, `remove`, or `replace`."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Structured workflow outline, loop design, confirmation design, delegation design, artifact plan, and modernization mapping.",
+          "context": "Capture workflowOutline, loopDesign, confirmationDesign, delegationDesign, artifactPlan, contextModel, voiceStrategy, routineAudit, delegationBoundaries, templateInjectionPlan, modernizationStrategy, legacyMapping, and behaviorPreservationNotes."
+        },
+        "verify": [
+          "The authored workflow architecture is coherent before JSON drafting begins."
+        ]
+      },
+      "promptFragments": [
+        {
+          "id": "phase-2-simple-direct",
+          "when": { "var": "workflowComplexity", "equals": "Simple" },
+          "text": "For Simple workflows, keep the architecture linear and compact. Do not invent loops or ceremony unless the task truly needs them."
+        }
+      ],
       "requireConfirmation": {
         "or": [
           { "var": "workflowComplexity", "not_equals": "Simple" },
@@ -106,22 +203,71 @@
       }
     },
     {
-      "id": "phase-2-draft",
-      "title": "Phase 2: Draft or Revise the Workflow",
-      "prompt": "Write the workflow JSON file.\n\nUse the outline from Phase 1 and produce the best first pass you can. If `authoringMode = create`, draft a new workflow. If `authoringMode = modernize_existing`, revise the existing workflow so it keeps the right intent while removing stale structure, legacy patterns, or unnecessary repetition. Phase 3 will catch structural issues, so focus on getting the shape and voice right. Follow these rules:\n\n1. The schema (`workflow-schema` reference) defines what is structurally legal. Do not invent fields.\n2. The authoring spec (`authoring-spec` reference) defines what is good. Follow its active rules.\n3. Write prompts in the user's voice. The opening sentence of each step should sound like a direct ask, not system narration.\n4. Calibrate prompt density to the step's needs. Not all steps need the same level of detail:\n   - Sparse (expert audience, clear task): direct ask + capture footer only.\n   - Focused (expert audience, ambiguous task): direct ask + key criteria or trade-offs + capture.\n   - Guided (broad audience, clear task): direct ask + enumerated sub-steps + capture.\n   - Scaffolded (broad audience, ambiguous task): direct ask + context frame + sub-steps + heuristic + capture.\n   Default to Focused if unsure. Vary density across steps -- uniform density is a smell.\n5. Keep protocol requirements explicit. If a step must emit a specific artifact or capture specific context, say that plainly.\n6. Use promptFragments for conditional rigor-mode branches instead of duplicating entire steps.\n7. Loop decision steps must use `outputContract` with `wr.contracts.loop_control` and allow both `continue` and `stop` in the output example.\n8. Loops must have explicit exit rules, bounded maxIterations, and a clear reason for another pass.\n9. Confirmation gates are for real human decisions, not routine ceremony.\n10. metaGuidance should be clean behavioral rules, not pseudo-functions or teaching prose.\n11. Do not use regex validationCriteria as the primary quality gate. Use real validators.\n12. If you are modernizing, preserve what still fits the workflow's purpose. Do not rewrite just because a workflow is old.\n\nIf `authoringMode = create`, ask the user what filename to use if they haven't specified one.\nIf `authoringMode = modernize_existing`, default to editing `targetWorkflowPath` unless there is a strong reason to create a new variant or file.\n\nWrite the file. Do not explain the JSON back to the user field by field.\n\nCapture:\n- `workflowFilePath`\n- `draftComplete`",
+      "id": "phase-3-design-quality-architecture",
+      "title": "Phase 3: Design the Quality-Gate Architecture",
+      "promptBlocks": {
+        "goal": "Design how the authored workflow will avoid shallow results, false confidence, and state bloat.",
+        "constraints": [
+          "This phase is about the authored workflow's quality model, not its basic phase list.",
+          "Prefer explicit quality structure over hoping the agent will infer it."
+        ],
+        "procedure": [
+          "Decide whether the authored workflow needs a hypothesis step, neutral fact packet, reviewer or validator families, contradiction loop, final validation bundle, or explicit blind-spot handling.",
+          "Design the confidence model, blind-spot model, and state economy plan.",
+          "Decide the hard-gate dimensions that would make the authored workflow unsafe or unsatisfying if they fail.",
+          "Write the redesign triggers that should force architectural revision rather than cosmetic refinement."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Quality architecture, confidence model, blind-spot model, state economy plan, and hard-gate triggers.",
+          "context": "Capture qualityArchitecture, confidenceModel, blindSpotModel, stateEconomyPlan, reviewBundlePlan, qualityGateTriggers, and hardGateModel."
+        },
+        "verify": [
+          "The authored workflow has an explicit plan for false-confidence resistance and quality review."
+        ]
+      },
+      "requireConfirmation": {
+        "or": [
+          { "var": "rigorMode", "equals": "THOROUGH" },
+          { "var": "workflowComplexity", "equals": "Complex" }
+        ]
+      }
+    },
+    {
+      "id": "phase-4-draft-or-revise",
+      "title": "Phase 4: Draft or Revise the Workflow",
+      "promptBlocks": {
+        "goal": "Write the workflow JSON file using the architecture and quality model you already chose.",
+        "constraints": [
+          "The schema defines what is legal. The authoring spec defines what is good.",
+          "Write prompts in the user's voice. Vary prompt density by step needs rather than using one density everywhere.",
+          "If you are modernizing, preserve what still fits the workflow's purpose. Do not rewrite just because a workflow is old."
+        ],
+        "procedure": [
+          "If `authoringMode = create` and no filename was specified, ask the user for the filename before writing.",
+          "If `authoringMode = modernize_existing`, default to editing `targetWorkflowPath` unless there is a strong reason to create a new variant or file.",
+          "Write the workflow file. Keep protocol requirements explicit, loops bounded, confirmations meaningful, and metaGuidance clean."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Draft status and any notable authoring choices that are important to later review.",
+          "context": "Capture workflowFilePath and draftComplete."
+        },
+        "verify": [
+          "The workflow file exists and reflects the chosen architecture rather than an improvised one."
+        ]
+      },
       "promptFragments": [
         {
-          "id": "phase-2-simple-fast",
+          "id": "phase-4-simple-fast",
           "when": { "var": "workflowComplexity", "equals": "Simple" },
-          "text": "No shape outline exists for Simple workflows -- Phase 1 was skipped. Decide the step list now and draft directly. Keep it linear, 3-5 steps, no loops unless the task genuinely needs iteration. metaGuidance is optional for Simple workflows."
+          "text": "For Simple workflows, keep the file compact and linear. Do not create extra metaGuidance or loops unless the task truly needs them."
         }
       ],
       "requireConfirmation": false
     },
     {
-      "id": "phase-3-validate",
+      "id": "phase-5-validate",
       "type": "loop",
-      "title": "Phase 3: Validate and Fix",
+      "title": "Phase 5: Structural Validation Loop",
       "loop": {
         "type": "while",
         "conditionSource": {
@@ -133,76 +279,267 @@
       },
       "body": [
         {
-          "id": "phase-3a-run-validation",
+          "id": "phase-5a-run-validation",
           "title": "Run Validation",
-          "prompt": "Run the real workflow validators against the drafted workflow.\n\nUse the available validation tools or commands (e.g., `npm run validate:registry`, schema validation, or the MCP validation surface). Do not rely on reading the JSON and eyeballing it.\n\nIf validation passes cleanly, say so and move to the loop decision.\n\nIf validation fails:\n1. List the actual errors.\n2. Fix each one in the workflow file.\n3. Re-run validation to confirm the fixes worked.\n\nIf the validator reports something that conflicts with your authoring assumptions, the validator (runtime) wins. Update your understanding.\n\nCapture:\n- `validationErrors`\n- `validationPassed`",
+          "promptBlocks": {
+            "goal": "Run the real workflow validators against the drafted workflow.",
+            "constraints": [
+              "Do not rely on reading the JSON and eyeballing it.",
+              "If runtime and authoring assumptions conflict, runtime wins."
+            ],
+            "procedure": [
+              "Run the available validation tools or commands such as `npm run validate:registry`, schema validation, or the MCP validation surface.",
+              "If validation fails, list the actual errors, fix them in the workflow file, and re-run validation.",
+              "If validation passes cleanly, say so plainly."
+            ],
+            "outputRequired": {
+              "notesMarkdown": "Validation results, actual errors if any, and what was fixed.",
+              "context": "Capture validationErrors and validationPassed."
+            },
+            "verify": [
+              "Validation results are based on real validators, not approximations."
+            ]
+          },
           "promptFragments": [
             {
-              "id": "phase-3a-thorough",
+              "id": "phase-5a-thorough",
               "when": { "var": "rigorMode", "equals": "THOROUGH" },
-              "text": "After fixing structural errors, also check the workflow against the authoring spec rules manually. Score each active required-level rule as pass/fail and fix any failures before moving on."
+              "text": "After structural validation passes, also check the workflow manually against required-level authoring-spec rules and fix any failures before moving on."
             }
           ],
           "requireConfirmation": false
         },
         {
-          "id": "phase-3b-loop-decision",
+          "id": "phase-5b-loop-decision",
           "title": "Validation Loop Decision",
-          "prompt": "Decide whether validation needs another pass.\n\n- If all errors are fixed and validation passes: stop.\n- If you fixed errors but haven't re-validated yet: continue.\n- If you've hit the iteration limit: stop and record what remains.\n\nEmit the loop-control artifact in this shape (`decision` must be `continue` or `stop`):\n```json\n{\n  \"artifacts\": [{\n    \"kind\": \"wr.loop_control\",\n    \"decision\": \"continue or stop\"\n  }]\n}\n```",
-          "requireConfirmation": false,
+          "promptBlocks": {
+            "goal": "Decide whether structural validation needs another pass.",
+            "constraints": [
+              "Use validator state, not vibes."
+            ],
+            "procedure": [
+              "If all errors are fixed and validation passes, stop.",
+              "If you fixed errors but have not re-validated yet, continue.",
+              "If you hit the iteration limit, stop and record what remains."
+            ],
+            "outputRequired": {
+              "artifact": "Emit a `wr.loop_control` artifact for `validation_loop` with `decision` set to `continue` or `stop`."
+            },
+            "verify": [
+              "The loop decision matches the actual validation state."
+            ]
+          },
           "outputContract": {
             "contractRef": "wr.contracts.loop_control"
-          }
+          },
+          "requireConfirmation": false
         }
       ]
     },
     {
-      "id": "phase-3-escalation",
+      "id": "phase-5-escalation",
       "title": "Validation Escalation",
       "runCondition": {
         "var": "validationPassed",
         "equals": false
       },
-      "prompt": "Validation did not pass after the maximum number of attempts.\n\nCheck whether the last validation run actually passed. If `validationPassed` is false or if you're uncertain, list the remaining errors and your assessment of their severity.\n\nThen present the options:\n1. Proceed with known issues documented in handoff notes.\n2. Stop here so the user can intervene manually.\n\nDo not silently continue with a broken workflow.",
+      "promptBlocks": {
+        "goal": "Do not silently continue with a structurally broken workflow.",
+        "constraints": [
+          "Present the situation honestly."
+        ],
+        "procedure": [
+          "List the remaining validation errors and assess their severity.",
+          "Present the options: proceed with known issues documented, or stop so the user can intervene manually."
+        ]
+      },
       "requireConfirmation": true
     },
     {
-      "id": "phase-4-review",
-      "title": "Phase 4: Method Review",
-      "prompt": "The workflow is valid. Now check whether it's actually good.\n\nScore each dimension 0-2 with one sentence of evidence:\n\n- `voiceClarity`: 0 = prompts are direct user-voiced asks in the workflow's domain vocabulary, 1 = mostly user-voiced but borrows vocabulary from other domains or has middleware narration, 2 = reads like system documentation or sounds like a different domain\n- `ceremonyLevel`: 0 = confirmations only at real decision points, 1 = one or two unnecessary gates, 2 = over-asks the user or adds routine ceremony\n- `loopSoundness`: 0 = loops have explicit exit rules, bounded iterations, and real decision steps, 1 = minor issues with exit clarity, 2 = vibes-only exit conditions or unbounded loops (score 0 if no loops)\n- `delegationBoundedness`: 0 = delegation is bounded and explicit or absent, 1 = one delegation could be tighter or a good routine/template opportunity was missed, 2 = open-ended or ownership-transferring delegation, or routine/template choices are unjustified (score 0 if no delegation and no reuse need exists)\n- `legacyPatterns`: 0 = no legacy anti-patterns, 1 = minor legacy residue, 2 = pseudo-DSL, learning paths, satisfaction loops, or regex-as-gate present\n- `artifactClarity`: 0 = clear what each artifact is for and which is canonical, 1 = mostly clear, 2 = ambiguous artifact ownership\n- `modeFit`: 0 = the workflow fits the selected `authoringMode`, 1 = minor creation/modernization mismatch remains, 2 = the workflow still reads like the wrong mode entirely\n- `modernizationDiscipline`: 0 = valuable behavior was preserved and legacy structure was removed cleanly, 1 = minor mismatch or over/under-preservation, 2 = either valuable behavior was lost or legacy structure still dominates (score 0 for `create` mode)\n\nIf the total score is 0-3: the workflow is ready.\nIf the total score is 4-6: fix the worst dimensions before proceeding.\nIf the total score is 7+: this needs significant rework. Fix the worst dimensions here, re-validate, and record what you would change if you could redraft from scratch.\n\nIf `authoringMode = modernize_existing`, check explicitly:\n- does the updated workflow preserve the right purpose?\n- did you remove legacy structure without rewriting valuable behavior away?\n- does the final workflow still align with `primaryBaseline` and `patternsToBorrow` without copying domain language?\n- does the final workflow respect the `legacyMapping`, especially for anything marked keep or merge?\n- do the routine/template choices still match the `routineAudit` and stay bounded?\n- do any prompts, captures, or handoff notes still assume this was a brand-new workflow?\n\nFix any issues directly in the workflow file. Re-run validation if you changed structure.\n\nCapture:\n- `reviewScores`\n- `reviewPassed`\n- `fixesApplied`",
-      "promptFragments": [
+      "id": "phase-6-quality-gate-loop",
+      "type": "loop",
+      "title": "Phase 6: Quality-Gate Loop",
+      "loop": {
+        "type": "while",
+        "conditionSource": {
+          "kind": "artifact_contract",
+          "contractRef": "wr.contracts.loop_control",
+          "loopId": "quality_gate_loop"
+        },
+        "maxIterations": 2
+      },
+      "body": [
         {
-          "id": "phase-4-quick-skip",
-          "when": { "var": "rigorMode", "equals": "QUICK" },
-          "text": "For QUICK rigor, do a fast pass on voiceClarity and legacyPatterns only. Skip the full rubric unless something looks off."
+          "id": "phase-6a-state-economy-audit",
+          "title": "State Economy Audit",
+          "promptBlocks": {
+            "goal": "Check whether every context field in the authored workflow earns its keep.",
+            "constraints": [
+              "A field is justified only if it materially affects routing, synthesis, confidence, or handoff quality.",
+              "Do not keep bookkeeping fields just because they sound organized."
+            ],
+            "procedure": [
+              "For each meaningful captured context field, record where it is set, where it is consumed, what decision or outcome it influences, and what gets worse if it is removed.",
+              "Classify each field as `keep`, `wire`, or `remove`.",
+              "Fix weak or unused fields directly in the workflow file."
+            ],
+            "outputRequired": {
+              "notesMarkdown": "State field audit with keep/wire/remove decisions and any fixes applied.",
+              "context": "Capture stateFieldAudit, unusedOrWeakFields, and stateEconomyPassed."
+            },
+            "verify": [
+              "Weak or unused fields are either wired meaningfully or removed."
+            ]
+          },
+          "requireConfirmation": false
         },
         {
-          "id": "phase-4-thorough-extra",
-          "when": { "var": "rigorMode", "equals": "THOROUGH" },
-          "text": "Also review:\n- Are the context captures complete and correctly named?\n- Do runConditions and promptFragment conditions use the right variables?\n- Is the metaGuidance minimal and non-redundant?\n- Would this workflow make sense to an agent that has never seen it before?"
+          "id": "phase-6b-execution-simulation",
+          "title": "Execution Simulation",
+          "promptBlocks": {
+            "goal": "Simulate what would happen if the authored workflow ran on the user's real task.",
+            "constraints": [
+              "This is about practical utility, not only context-flow correctness.",
+              "Flag places where the workflow would produce paperwork, generic output, or false confidence instead of value."
+            ],
+            "procedure": [
+              "Trace the authored workflow step by step against the user's actual task or the closest realistic scenario.",
+              "For each step, ask: what would the agent actually do, what context would it have, what would it likely produce, and what would the next step inherit?",
+              "Identify likely weak steps, likely unsatisfying outputs, and likely false-confidence modes.",
+              "Fix issues directly in the workflow file when the right improvement is clear."
+            ],
+            "outputRequired": {
+              "notesMarkdown": "Execution simulation findings, likely weak steps, unsatisfying outputs, false-confidence risks, and any fixes applied.",
+              "context": "Capture simulationFindings, likelyWeakSteps, likelyUnsatisfyingOutputs, falseConfidenceFindings, and outcomeEffectivenessPassed."
+            },
+            "verify": [
+              "The simulation judges likely usefulness, not just structural legality."
+            ]
+          },
+          "promptFragments": [
+            {
+              "id": "phase-6b-quick",
+              "when": { "var": "rigorMode", "equals": "QUICK" },
+              "text": "For QUICK rigor, keep the simulation compact but still answer where the workflow would likely disappoint the user if it disappointed them at all."
+            }
+          ],
+          "requireConfirmation": false
         },
         {
-          "id": "phase-4-trace-walkthrough",
-          "when": { "var": "rigorMode", "not_equals": "QUICK" },
-          "text": "After scoring the rubric, trace through the workflow with the user's original task as the test scenario. For each step:\n- What context variables does it need? Are they available from prior steps?\n- What would the agent actually do given only the prompt and references?\n- What does it produce? Does the next step have everything it needs?\n\nFlag any context flow gaps, naming mismatches, or steps where the agent wouldn't know what to do. Fix them in the workflow file."
+          "id": "phase-6c-adversarial-quality-review",
+          "title": "Adversarial Quality Review",
+          "promptBlocks": {
+            "goal": "Review the authored workflow as a quality gate, not just as a valid JSON file.",
+            "constraints": [
+              "Authoring integrity and outcome effectiveness are separate concerns. Score both.",
+              "Reviewer-family or validator output is evidence, not authority."
+            ],
+            "procedure": [
+              "Score these dimensions 0-2 with one sentence of evidence each: `voiceClarity`, `ceremonyLevel`, `loopSoundness`, `delegationBoundedness`, `artifactClarity`, `taskEffectiveness`, `falseConfidenceResistance`, `stateMinimality`, `coverageSharpness`, `domainFit`, `handoffUtility`, and `modernizationDiscipline`.",
+              "If delegation is available and rigor is THOROUGH, run an adversarial review bundle with these lenses: `engine_native_reviewer`, `task_effectiveness_reviewer`, `state_economy_reviewer`, `false_confidence_reviewer`, `domain_fit_reviewer`, and `maintainer_reviewer`.",
+              "Synthesize what the review confirmed, what it challenged, and what changed your mind.",
+              "Set hard-gate failures whenever any of these are materially weak: `taskEffectiveness`, `falseConfidenceResistance`, `stateMinimality`, `coverageSharpness`, `domainFit`, or `handoffUtility`.",
+              "Set `authoringIntegrityPassed = true` only if structural and authoring-quality dimensions are all acceptable. Set `outcomeEffectivenessPassed = true` only if the workflow is likely to achieve satisfying results for the user."
+            ],
+            "outputRequired": {
+              "notesMarkdown": "Quality review scores, adversarial review findings, hard-gate failures, and the current redesign severity.",
+              "context": "Capture reviewScores, hardGateFailures, authoringIntegrityPassed, outcomeEffectivenessPassed, qualityReviewSummary, and redesignSeverity."
+            },
+            "verify": [
+              "Hard gates reflect real user-trust risk, not cosmetic imperfections."
+            ]
+          },
+          "promptFragments": [
+            {
+              "id": "phase-6c-standard",
+              "when": { "var": "rigorMode", "equals": "STANDARD" },
+              "text": "For STANDARD rigor, you may keep the review self-executed unless uncertainty remains material. If you do delegate, prefer a small adversarial bundle."
+            },
+            {
+              "id": "phase-6c-thorough",
+              "when": { "var": "rigorMode", "equals": "THOROUGH" },
+              "text": "For THOROUGH rigor, assume the first review is not enough. Use adversarial reviewer lanes unless a hard limitation makes them impossible."
+            }
+          ],
+          "requireConfirmation": false
+        },
+        {
+          "id": "phase-6d-redesign-and-revalidate",
+          "title": "Redesign and Revalidate",
+          "promptBlocks": {
+            "goal": "If hard gates fail, redesign the workflow instead of polishing around the problem.",
+            "constraints": [
+              "Minor cosmetic refinement is not enough when task effectiveness or false-confidence resistance is weak.",
+              "If structure changes, re-run real validators before leaving this step."
+            ],
+            "procedure": [
+              "If `authoringIntegrityPassed` and `outcomeEffectivenessPassed` are both true and `hardGateFailures` is empty, say that no redesign is needed.",
+              "Otherwise classify the needed redesign severity as `minor`, `architectural`, or `unsafe_to_ship` and apply the necessary fixes directly to the workflow file.",
+              "If the redesign changed structure, run the real validators again and update the validation state before leaving this step."
+            ],
+            "outputRequired": {
+              "notesMarkdown": "Redesign actions taken, why they were needed, and whether revalidation passed.",
+              "context": "Capture redesignApplied, validationPassed, and remainingConcerns."
+            },
+            "verify": [
+              "Structural redesign problems are handled as redesign problems, not cosmetic ones."
+            ]
+          },
+          "requireConfirmation": false
+        },
+        {
+          "id": "phase-6e-quality-loop-decision",
+          "title": "Quality Loop Decision",
+          "promptBlocks": {
+            "goal": "Decide whether the quality-gate loop needs another pass.",
+            "constraints": [
+              "Use hard gates and actual remaining concerns, not vibes."
+            ],
+            "procedure": [
+              "Continue if `authoringIntegrityPassed = false`.",
+              "Otherwise continue if `outcomeEffectivenessPassed = false`.",
+              "Otherwise continue if `hardGateFailures` is not empty.",
+              "Otherwise continue if `redesignSeverity` is `architectural` or `unsafe_to_ship` and you have not yet re-reviewed the redesigned workflow.",
+              "Otherwise continue if `validationPassed = false` after redesign.",
+              "Otherwise stop."
+            ],
+            "outputRequired": {
+              "artifact": "Emit a `wr.loop_control` artifact for `quality_gate_loop` with `decision` set to `continue` or `stop`."
+            },
+            "verify": [
+              "The workflow does not stop while hard trust problems remain."
+            ]
+          },
+          "outputContract": {
+            "contractRef": "wr.contracts.loop_control"
+          },
+          "requireConfirmation": false
         }
-      ],
-      "requireConfirmation": false
+      ]
     },
     {
-      "id": "phase-5-refine",
-      "title": "Phase 5: Refinement",
-      "runCondition": {
-        "var": "rigorMode",
-        "not_equals": "QUICK"
+      "id": "phase-7-final-trust-handoff",
+      "title": "Phase 7: Final Trust Handoff",
+      "promptBlocks": {
+        "goal": "Summarize the authored or modernized workflow as a trust decision, not just a file edit.",
+        "constraints": [
+          "Keep it concise. The workflow file is the deliverable, not the summary."
+        ],
+        "procedure": [
+          "State the workflow file path and name, whether it was created or modernized, and what it does in one sentence.",
+          "Summarize the step structure, loops, confirmations, and delegation profile.",
+          "Report validation status, authoring-integrity status, and outcome-effectiveness status.",
+          "Set a final `workflowReadinessVerdict`: `ready`, `ready_with_conditions`, or `not_ready`.",
+          "List the main improvements, residual weaknesses, trust risks if any, and how to test the workflow."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "Final trust handoff covering readiness verdict, validation status, strengths, residual weaknesses, and testing guidance.",
+          "context": "Capture workflowReadinessVerdict, trustRiskSummary, knownFailureModes, and residualWeaknesses."
+        },
+        "verify": [
+          "The final handoff makes clear whether WorkRail should trust this workflow."
+        ]
       },
-      "prompt": "The workflow is valid and reviewed. Check whether any of these improvements are worth making:\n\n1. **Prompt fragments**: are there steps with near-identical prompts that differ only by rigor mode or `authoringMode`? Extract the differences into promptFragments.\n2. **Extension points**: are there slots that different teams or projects would want to customize? Declare them.\n3. **References**: should the workflow point at external documents the agent should be aware of during execution?\n4. **Deduplication**: is there repeated prose across steps that could be moved to metaGuidance or a shared pattern?\n5. **Context templates**: are there simple variable substitutions that would make prompts cleaner?\n\nOnly make changes that genuinely improve the workflow. Do not refine for the sake of refining.\n\nIf `authoringMode = modernize_existing`, prefer refinements that remove leftover legacy wording or mismatched structure over cosmetic rewrites.\n\nIf you change anything, re-run validation.\n\nCapture:\n- `refinementsApplied`\n- `finalValidationPassed`",
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-6-handoff",
-      "title": "Phase 6: Handoff",
-      "prompt": "Summarize what you authored or updated.\n\nInclude:\n- workflow file path and name\n- whether you created a new workflow or modernized an existing one\n- what the workflow does (one sentence)\n- step count and structure overview\n- loops, confirmations, and delegation if any\n- validation status\n- for modernization: the main improvements and any legacy residue still left intentionally\n- any known limitations or future improvements\n- how to test it: where to place the file and how to run it\n\nKeep it concise. The workflow file is the deliverable, not the summary.",
       "notesOptional": true,
       "requireConfirmation": false
     }

package/workflows/wr.discovery.json

@@ -11,26 +11,6 @@
     "wr.features.capabilities",
     "wr.features.subagent_guidance"
   ],
-  "extensionPoints": [
-    {
-      "slotId": "candidate_generation",
-      "purpose": "Let me swap in a different way of generating candidate directions without forking the whole workflow.",
-      "default": "routine-tension-driven-design",
-      "acceptedKinds": ["routine", "workflow"]
-    },
-    {
-      "slotId": "direction_review",
-      "purpose": "Let me swap in a different way of pressure-testing the selected direction without giving up parent workflow synthesis.",
-      "default": "routine-design-review",
-      "acceptedKinds": ["routine", "workflow"]
-    },
-    {
-      "slotId": "final_validation",
-      "purpose": "Let me swap in a different final challenge or validation pass before handoff.",
-      "default": "routine-hypothesis-challenge",
-      "acceptedKinds": ["routine", "workflow"]
-    }
-  ],
   "preconditions": [
     "I can tell you what problem, opportunity, or decision I want help thinking through.",
     "You can keep durable state in `output.notesMarkdown` and `continue_workflow` context keys.",
@@ -453,56 +433,48 @@
     },
     {
       "id": "phase-3b-candidates-deep",
-      "title": "Phase 3b: Candidate Generation (Injected Routine)",
+      "title": "Phase 3b: Candidate Generation Setup",
       "runCondition": {
         "var": "rigorMode",
         "not_equals": "QUICK"
       },
       "promptBlocks": {
-        "goal": "Run the configured candidate-generation approach and produce `design-candidates.md` for me.",
+        "goal": "Set up the injected candidate-generation pass so it produces the right kind of candidate set for this path.",
         "constraints": [
-          "Candidate generation is a bounded cognitive phase. You still own selection and synthesis at the parent workflow level.",
-          "The generated candidate set should reflect the selected path and current decision criteria."
+          "The next step injects the reusable candidate-generation routine inline.",
+          "Record any path-specific bias or extra rigor expectation before the injected routine runs."
         ],
         "procedure": [
-          "Choose the execution mode that is most likely to produce a strong candidate set here. If you can get there well yourself, follow the bounded candidate-generation implementation referenced by `{{wr.bindings.candidate_generation}}` and produce `design-candidates.md` directly.",
-          "If delegation is likely to give you a clearly better spread of options or a stronger challenge pass, spawn ONE WorkRail Executor running `{{wr.bindings.candidate_generation}}` with the current path, tensions, landscape packet, problem frame, and decision criteria, then capture the resulting candidate set in `design-candidates.md`. If you do not delegate, keep going yourself and record why that is enough."
+          "State what the injected candidate-generation routine must emphasize for this path and why.",
+          "For `design_first`, require at least one direction that meaningfully reframes the problem instead of only packaging obvious solutions.",
+          "For `landscape_first`, require the candidate set to clearly reflect landscape precedents, constraints, and contradictions rather than drifting into free invention.",
+          "For `THOROUGH`, require one extra push if the first spread still feels clustered or too safe.",
+          "Write these expectations into `designDocPath` so the later synthesis can judge whether the injected routine met them."
         ],
         "verify": [
-          "`design-candidates.md` exists and contains a genuinely differentiated candidate set rather than minor variations on one idea."
+          "The path-specific expectations for candidate generation are explicit before the injected routine runs."
         ]
       },
-      "promptFragments": [
-        {
-          "id": "p3b-design-reframe",
-          "when": {
-            "var": "pathRecommendation",
-            "equals": "design_first"
-          },
-          "text": "Because this is `design_first`, make sure the candidate set includes at least one direction that meaningfully reframes the problem instead of only packaging obvious solutions."
-        },
-        {
-          "id": "p3b-landscape-ground",
-          "when": {
-            "var": "pathRecommendation",
-            "equals": "landscape_first"
-          },
-          "text": "Because this is `landscape_first`, make sure the candidate set clearly reflects landscape precedents, constraints, and contradictions rather than drifting into free invention."
-        },
-        {
-          "id": "p3b-thorough-depth",
-          "when": {
-            "var": "rigorMode",
-            "equals": "THOROUGH"
-          },
-          "text": "Because this is a `THOROUGH` pass, do not stop at the first good spread. Push once more if the set still feels clustered or too safe."
+      "requireConfirmation": false
+    },
+    {
+      "id": "phase-3c-candidates-deep-core",
+      "title": "Phase 3c: Candidate Generation (Injected Routine)",
+      "runCondition": {
+        "var": "rigorMode",
+        "not_equals": "QUICK"
+      },
+      "templateCall": {
+        "templateId": "wr.templates.routine.tension-driven-design",
+        "args": {
+          "deliverableName": "design-candidates.md"
         }
-      ],
+      },
       "requireConfirmation": false
     },
     {
-      "id": "phase-3c-select-direction",
-      "title": "Phase 3c: Challenge and Select Direction",
+      "id": "phase-3d-select-direction",
+      "title": "Phase 3d: Challenge and Select Direction",
       "promptBlocks": {
         "goal": "Read `design-candidates.md`, challenge the leading option, and make the final selection for me.",
         "constraints": [
@@ -515,7 +487,7 @@
         "procedure": [
           "Compare candidates against `pathRecommendation` and `decisionCriteria`: which candidate best fits, which candidate is the strongest alternative, and what evidence or stakeholder tension the top candidate still risks missing.",
           "Self-produce the strongest argument against the leading option.",
-          "If `delegationAvailable = true` and (`rigorMode != QUICK` or `pathRecommendation = full_spectrum`), decide whether a delegated challenge is likely to sharpen the decision enough to be worth the extra step. If yes, spawn ONE WorkRail Executor running `{{wr.bindings.final_validation}}` against the leading option. If not, keep the challenge in your own hands and say why.",
+          "If `delegationAvailable = true` and (`rigorMode != QUICK` or `pathRecommendation = full_spectrum`), decide whether a delegated challenge is likely to sharpen the decision enough to be worth the extra step. If yes, spawn ONE WorkRail Executor running `routine-hypothesis-challenge` against the leading option. If not, keep the challenge in your own hands and say why.",
           "If `delegationAvailable = true` and `rigorMode = THOROUGH`, decide whether an execution simulation would materially sharpen the decision. If yes, you may also spawn ONE WorkRail Executor running `routine-execution-simulation`.",
           "Choose `selectedDirection` and `runnerUpDirection`.",
           "Record `acceptedTradeoffs`, `identifiedFailureModes`, and what would trigger a switch.",
@@ -579,19 +551,11 @@
         {
           "id": "phase-4a-review-core",
           "title": "Direction Review Core",
-          "promptBlocks": {
-            "goal": "Run the configured direction review approach and produce `design-review-findings.md`.",
-            "constraints": [
-              "You remain responsible for interpreting the findings.",
-              "Treat the selected direction and its known tradeoffs as input context, not as guaranteed truth."
-            ],
-            "procedure": [
-              "Choose the execution mode that is most likely to produce a useful review here. If direct execution is enough, follow the bounded review implementation referenced by `{{wr.bindings.direction_review}}` and produce `design-review-findings.md`.",
-              "If delegation is likely to surface better weaknesses or hidden tradeoffs, spawn ONE WorkRail Executor running `{{wr.bindings.direction_review}}` with the selected direction, accepted tradeoffs, failure modes, and path context, then capture the resulting findings in `design-review-findings.md`. If you do not delegate, record why direct review is enough."
-            ],
-            "verify": [
-              "`design-review-findings.md` exists and reflects an actual review pass, not a placeholder."
-            ]
+          "templateCall": {
+            "templateId": "wr.templates.routine.design-review",
+            "args": {
+              "deliverableName": "design-review-findings.md"
+            }
           },
           "requireConfirmation": false
         },
@@ -852,7 +816,7 @@
         ],
         "procedure": [
           "Validate that the selected path still makes sense in hindsight, the chosen direction still beats the strongest alternative, the remaining uncertainty is named honestly, and the design doc is complete enough for a human to use.",
-          "If a serious unresolved concern remains and `delegationAvailable = true`, decide whether a delegated final challenge is likely to change the result or sharpen the caveats. If yes, spawn ONE WorkRail Executor running `{{wr.bindings.final_validation}}` against the final recommendation. If not, keep the challenge in your own hands and record why.",
+          "If a serious unresolved concern remains and `delegationAvailable = true`, decide whether a delegated final challenge is likely to change the result or sharpen the caveats. If yes, spawn ONE WorkRail Executor running `routine-hypothesis-challenge` against the final recommendation. If not, keep the challenge in your own hands and record why.",
           "Set these keys in the next `continue_workflow` call's `context` object: `finalConfidenceBand`, `residualRiskCount`, `handoffReady`."
         ],
         "verify": [