@exaudeus/workrail 3.11.0 → 3.11.2

package/dist/manifest.json

@@ -1026,8 +1026,8 @@
       "bytes": 5976
     },
     "mcp/tools.js": {
-      "sha256": "aa364f3e613fc61a39fc7336a723231da06852d92ec7840a95327aa370e42e1c",
-      "bytes": 8360
+      "sha256": "bf9043c94b66e7692f70e9f5f36f408d40441bb69866bda4e7b0fd646eba6022",
+      "bytes": 8635
     },
     "mcp/transports/http-entry.d.ts": {
       "sha256": "35d313b120dcf38643de9462559163581b89943fe432706986252e8b698b9507",
@@ -1122,8 +1122,8 @@
       "bytes": 7206
     },
     "mcp/v2/tools.js": {
-      "sha256": "9fb084ad964296bf49e94327aacc8c55857822382f1636278143f8074572bc40",
-      "bytes": 10661
+      "sha256": "d2de769feb5bb8c6ddcd415594f7cf49380f13bae5ddc422445381adcef038a3",
+      "bytes": 10771
     },
     "mcp/validation/bounded-json.d.ts": {
       "sha256": "82203ac6123d5c6989606c3b5405aaea99ab829c8958835f9ae3ba45b8bc8fd5",

package/dist/mcp/tools.js

@@ -8,7 +8,7 @@ exports.WorkflowListInput = zod_1.z.object({});
 exports.WorkflowGetInput = zod_1.z.object({
     workflowId: zod_1.z
         .string()
-        .regex(/^[A-Za-z0-9_-]+$/, 'Workflow ID must contain only letters, numbers, hyphens, and underscores')
+        .regex(/^([a-z0-9_-]+|[a-z][a-z0-9_-]+\.[a-z][a-z0-9_-]+)$/, 'Workflow ID must be a valid legacy ID (e.g. my-workflow) or namespaced ID (e.g. wr.discovery)')
         .describe('The unique identifier of the workflow to retrieve'),
     mode: zod_1.z
         .enum(['metadata', 'preview'])
@@ -18,7 +18,7 @@ exports.WorkflowGetInput = zod_1.z.object({
 exports.WorkflowNextInput = zod_1.z.object({
     workflowId: zod_1.z
         .string()
-        .regex(/^[A-Za-z0-9_-]+$/, 'Workflow ID must contain only letters, numbers, hyphens, and underscores')
+        .regex(/^([a-z0-9_-]+|[a-z][a-z0-9_-]+\.[a-z][a-z0-9_-]+)$/, 'Workflow ID must be a valid legacy ID (e.g. my-workflow) or namespaced ID (e.g. wr.discovery)')
         .describe('The unique identifier of the workflow'),
     state: state_js_1.ExecutionStateSchema.describe('Serializable workflow execution state (authoritative). ' +
         'For the first call, use: { kind: "init" }. ' +
@@ -109,7 +109,7 @@ exports.WORKFLOW_TOOL_TITLES = {
 exports.CreateSessionInput = zod_1.z.object({
     workflowId: zod_1.z
         .string()
-        .regex(/^[A-Za-z0-9_-]+$/, 'Workflow ID must contain only letters, numbers, hyphens, and underscores')
+        .regex(/^([a-z0-9_-]+|[a-z][a-z0-9_-]+\.[a-z][a-z0-9_-]+)$/, 'Workflow ID must be a valid legacy ID (e.g. my-workflow) or namespaced ID (e.g. wr.discovery)')
         .describe('Workflow identifier (e.g., "bug-investigation", "mr-review")'),
     sessionId: zod_1.z
         .string()
@@ -120,14 +120,14 @@ exports.CreateSessionInput = zod_1.z.object({
         .describe('Initial session data. Can include dashboard, phases, etc.'),
 });
 exports.UpdateSessionInput = zod_1.z.object({
-    workflowId: zod_1.z.string().regex(/^[A-Za-z0-9_-]+$/, 'Workflow ID must contain only letters, numbers, hyphens, and underscores').describe('Workflow identifier'),
+    workflowId: zod_1.z.string().regex(/^([a-z0-9_-]+|[a-z][a-z0-9_-]+\.[a-z][a-z0-9_-]+)$/, 'Workflow ID must be a valid legacy ID (e.g. my-workflow) or namespaced ID (e.g. wr.discovery)').describe('Workflow identifier'),
     sessionId: zod_1.z.string().describe('Session identifier'),
     updates: zod_1.z
         .record(zod_1.z.unknown())
         .describe('Data to merge into session. Supports nested updates via dot notation.'),
 });
 exports.ReadSessionInput = zod_1.z.object({
-    workflowId: zod_1.z.string().regex(/^[A-Za-z0-9_-]+$/, 'Workflow ID must contain only letters, numbers, hyphens, and underscores').describe('Workflow identifier'),
+    workflowId: zod_1.z.string().regex(/^([a-z0-9_-]+|[a-z][a-z0-9_-]+\.[a-z][a-z0-9_-]+)$/, 'Workflow ID must be a valid legacy ID (e.g. my-workflow) or namespaced ID (e.g. wr.discovery)').describe('Workflow identifier'),
     sessionId: zod_1.z.string().describe('Session identifier'),
     path: zod_1.z
         .string()

package/dist/mcp/v2/tools.js

@@ -18,12 +18,12 @@ exports.V2ListWorkflowsInput = zod_1.z.object({
     workspacePath: workspacePathField.describe('Required. Absolute path to your current workspace directory (e.g. the "Workspace:" value from your system parameters). WorkRail uses this to resolve project-scoped workflow variants against the correct workspace for discovery-sensitive workflow listing. Shared MCP servers cannot infer this safely.'),
 });
 exports.V2InspectWorkflowInput = zod_1.z.object({
-    workflowId: zod_1.z.string().min(1).regex(/^[A-Za-z0-9_-]+$/, 'Workflow ID must contain only letters, numbers, hyphens, and underscores').describe('The workflow ID to inspect'),
+    workflowId: zod_1.z.string().min(1).regex(/^([a-z0-9_-]+|[a-z][a-z0-9_-]+\.[a-z][a-z0-9_-]+)$/, 'Workflow ID must be a valid legacy ID (e.g. my-workflow) or namespaced ID (e.g. wr.discovery)').describe('The workflow ID to inspect'),
     mode: zod_1.z.enum(['metadata', 'preview']).default('preview').describe('Detail level: metadata (name and description only) or preview (full step-by-step breakdown, default)'),
     workspacePath: workspacePathField.describe('Required. Absolute path to your current workspace directory (e.g. the "Workspace:" value from your system parameters). WorkRail uses this to resolve the correct project-scoped workflow variant for discovery-sensitive workflow inspection. Shared MCP servers cannot infer this safely.'),
 });
 exports.V2StartWorkflowInput = zod_1.z.object({
-    workflowId: zod_1.z.string().min(1).regex(/^[A-Za-z0-9_-]+$/, 'Workflow ID must contain only letters, numbers, hyphens, and underscores').describe('The workflow ID to start'),
+    workflowId: zod_1.z.string().min(1).regex(/^([a-z0-9_-]+|[a-z][a-z0-9_-]+\.[a-z][a-z0-9_-]+)$/, 'Workflow ID must be a valid legacy ID (e.g. my-workflow) or namespaced ID (e.g. wr.discovery)').describe('The workflow ID to start'),
     workspacePath: workspacePathField.describe('Required. Absolute path to your current workspace directory (e.g. the "Workspace:" value from your system parameters). WorkRail uses this to resolve the correct project-scoped workflow variant and to anchor the session to the correct repo for future resume_session discovery. Shared MCP servers cannot infer this safely.'),
 });
 exports.V2ContinueWorkflowInputShape = zod_1.z.object({

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@exaudeus/workrail",
-  "version": "3.11.0",
+  "version": "3.11.2",
   "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
+    }
+  ]
+}