@exaudeus/workrail 3.65.0 → 3.66.0

package/workflows/routines/feature-implementation.json

@@ -2,6 +2,7 @@
   "id": "routine-feature-implementation",
   "name": "Feature Implementation Routine",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Implements code precisely according to a detailed approved plan within a bounded scope. Follows existing patterns, writes tests, and maintains code quality. Intended as an optional execution utility, not the default strategy for the main coding workflow.",
   "clarificationPrompts": [
     "What plan file should I implement? (e.g., implementation-plan.md)",
@@ -67,7 +68,7 @@
     {
       "id": "step-2-verify-acceptance-criteria",
       "title": "Step 2: Verify Acceptance Criteria",
-      "prompt": "**VERIFY ALL ACCEPTANCE CRITERIA ARE MET**\n\nNow verify that your implementation meets all acceptance criteria.\n\n**YOUR MISSION:** Systematically check each acceptance criterion and verify it's met.\n\n**PLAN YOUR APPROACH:**\nBefore verifying, think:\n- How will I test each criterion?\n- What evidence proves each criterion is met?\n- Are there any criteria I might have missed?\n- What manual testing should I do?\n\n**EXECUTE:**\nFor each acceptance criterion:\n\n1. **State the Criterion**\n   - Quote the exact criterion from the plan\n\n2. **Verify It's Met**\n   - Run relevant tests\n   - Perform manual testing if needed\n   - Check code implementation\n   - Gather evidence\n\n3. **Mark Status**\n   - \u2705 Met (with evidence)\n   - \u274c Not Met (with reason)\n   - \u26a0\ufe0f Partially Met (with details)\n\n4. **Provide Evidence**\n   - Test results\n   - Code references (file:line)\n   - Manual test outcomes\n   - Metrics or measurements\n\n**REFLECT:**\nAs you verify, ask yourself:\n- Did I test each criterion thoroughly?\n- Is my evidence convincing?\n- Are there edge cases I should test?\n- Did I miss any criteria?\n\n**WORKING NOTES:**\nCapture your verification:\n- Acceptance criteria checklist (with status)\n- Evidence for each criterion\n- Test results\n- Manual testing performed\n- Edge cases tested\n- Any criteria not met (with reasons)",
+      "prompt": "**VERIFY ALL ACCEPTANCE CRITERIA ARE MET**\n\nNow verify that your implementation meets all acceptance criteria.\n\n**YOUR MISSION:** Systematically check each acceptance criterion and verify it's met.\n\n**PLAN YOUR APPROACH:**\nBefore verifying, think:\n- How will I test each criterion?\n- What evidence proves each criterion is met?\n- Are there any criteria I might have missed?\n- What manual testing should I do?\n\n**EXECUTE:**\nFor each acceptance criterion:\n\n1. **State the Criterion**\n   - Quote the exact criterion from the plan\n\n2. **Verify It's Met**\n   - Run relevant tests\n   - Perform manual testing if needed\n   - Check code implementation\n   - Gather evidence\n\n3. **Mark Status**\n   - ✅ Met (with evidence)\n   - ❌ Not Met (with reason)\n   - ⚠️ Partially Met (with details)\n\n4. **Provide Evidence**\n   - Test results\n   - Code references (file:line)\n   - Manual test outcomes\n   - Metrics or measurements\n\n**REFLECT:**\nAs you verify, ask yourself:\n- Did I test each criterion thoroughly?\n- Is my evidence convincing?\n- Are there edge cases I should test?\n- Did I miss any criteria?\n\n**WORKING NOTES:**\nCapture your verification:\n- Acceptance criteria checklist (with status)\n- Evidence for each criterion\n- Test results\n- Manual testing performed\n- Edge cases tested\n- Any criteria not met (with reasons)",
       "agentRole": "You are a quality assurance specialist verifying that all requirements are met. Be thorough and provide evidence.",
       "requireConfirmation": false,
       "guidance": [
@@ -100,7 +101,7 @@
     {
       "id": "step-4-synthesize-deliverable",
       "title": "Step 4: Synthesize & Deliver Implementation Report",
-      "prompt": "**DELIVER YOUR IMPLEMENTATION REPORT**\n\nNow compile your work into a clear, comprehensive deliverable.\n\n**YOUR MISSION:** Create an implementation report that documents all changes, tests, and verification.\n\n**PLAN YOUR APPROACH:**\nBefore writing, think:\n- Who will read this and what do they need?\n- How can I make it easy to review?\n- What's the most important information?\n- How can I prove I met all criteria?\n\n**EXECUTE:**\nCreate your implementation report with these sections:\n\n1. **Summary** (3-5 bullets)\n   - What was implemented\n   - Key changes made\n   - Test coverage added\n   - Any deviations from plan\n\n2. **Implementation Details**\n   - Files modified (with summary of changes and code snippets)\n   - Files created (with purpose and key code)\n   - Files deleted (if any)\n   - Pattern adherence notes\n\n3. **Tests Added/Updated**\n   - New tests (with descriptions)\n   - Updated tests (with reasons)\n   - Test results (pass/fail counts)\n   - Test coverage metrics (if available)\n\n4. **Verification Steps**\n   - How to run tests\n   - How to check linter\n   - How to manually verify\n   - How to check metrics (if applicable)\n\n5. **Deviations from Plan**\n   - Any deviations (with reasons and impact)\n   - Approval status (needed/not needed)\n\n6. **Acceptance Criteria Status**\n   - Checklist of all criteria (\u2705/\u274c/\u26a0\ufe0f)\n   - Evidence for each\n   - Overall status\n\n7. **Known Issues / TODOs**\n   - Issues encountered\n   - TODOs for future work\n   - Blockers (if any)\n\n8. **Build & Lint Status**\n   - Build results\n   - Linter results\n   - Overall quality status\n\n**REFLECT:**\nBefore delivering, ask yourself:\n- Is my report complete and accurate?\n- Did I document all changes?\n- Can someone review this easily?\n- Did I provide enough evidence?\n- Are there any issues I should flag?\n\n**DELIVERABLE:**\nA comprehensive implementation report (markdown format) with all sections above.",
+      "prompt": "**DELIVER YOUR IMPLEMENTATION REPORT**\n\nNow compile your work into a clear, comprehensive deliverable.\n\n**YOUR MISSION:** Create an implementation report that documents all changes, tests, and verification.\n\n**PLAN YOUR APPROACH:**\nBefore writing, think:\n- Who will read this and what do they need?\n- How can I make it easy to review?\n- What's the most important information?\n- How can I prove I met all criteria?\n\n**EXECUTE:**\nCreate your implementation report with these sections:\n\n1. **Summary** (3-5 bullets)\n   - What was implemented\n   - Key changes made\n   - Test coverage added\n   - Any deviations from plan\n\n2. **Implementation Details**\n   - Files modified (with summary of changes and code snippets)\n   - Files created (with purpose and key code)\n   - Files deleted (if any)\n   - Pattern adherence notes\n\n3. **Tests Added/Updated**\n   - New tests (with descriptions)\n   - Updated tests (with reasons)\n   - Test results (pass/fail counts)\n   - Test coverage metrics (if available)\n\n4. **Verification Steps**\n   - How to run tests\n   - How to check linter\n   - How to manually verify\n   - How to check metrics (if applicable)\n\n5. **Deviations from Plan**\n   - Any deviations (with reasons and impact)\n   - Approval status (needed/not needed)\n\n6. **Acceptance Criteria Status**\n   - Checklist of all criteria (✅/❌/⚠️)\n   - Evidence for each\n   - Overall status\n\n7. **Known Issues / TODOs**\n   - Issues encountered\n   - TODOs for future work\n   - Blockers (if any)\n\n8. **Build & Lint Status**\n   - Build results\n   - Linter results\n   - Overall quality status\n\n**REFLECT:**\nBefore delivering, ask yourself:\n- Is my report complete and accurate?\n- Did I document all changes?\n- Can someone review this easily?\n- Did I provide enough evidence?\n- Are there any issues I should flag?\n\n**DELIVERABLE:**\nA comprehensive implementation report (markdown format) with all sections above.",
       "agentRole": "You are a technical writer synthesizing your implementation work into a clear, reviewable report. Make it easy to understand and verify.",
       "requireConfirmation": false,
       "guidance": [
@@ -117,4 +118,4 @@
       ]
     }
   ]
-}
+}

package/workflows/routines/final-verification.json

@@ -2,6 +2,7 @@
   "id": "routine-final-verification",
   "name": "Final Verification Routine",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Performs reusable final verification over acceptance criteria, invariants, validation evidence, regressions, cumulative drift, and philosophy alignment. Produces a proof-oriented verification artifact built around claim -> evidence -> gap -> severity -> readiness verdict.",
   "clarificationPrompts": [
     "What implementation or slices should I verify?",

package/workflows/routines/hypothesis-challenge.json

@@ -2,6 +2,7 @@
   "id": "routine-hypothesis-challenge",
   "name": "Hypothesis Challenge Routine",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Lean adversarial review of a hypothesis, recommendation, or diagnosis. Produces the strongest counter-argument, exposes weak assumptions and evidence gaps, identifies likely failure modes, and defines the critical tests needed to keep, revise, or reject the current claim.",
   "clarificationPrompts": [
     "What hypothesis, recommendation, or diagnosis should I challenge?",
@@ -49,9 +50,18 @@
       "title": "Step 4: Generate Alternative Explanations and Critical Tests",
       "runCondition": {
         "or": [
-          { "var": "depth", "equals": "THOROUGH" },
-          { "var": "rigorMode", "equals": "THOROUGH" },
-          { "var": "rigor", "gte": 5 }
+          {
+            "var": "depth",
+            "equals": "THOROUGH"
+          },
+          {
+            "var": "rigorMode",
+            "equals": "THOROUGH"
+          },
+          {
+            "var": "rigor",
+            "gte": 5
+          }
         ]
       },
       "prompt": "For THOROUGH review, go beyond the primary counter-argument into alternatives and discrimination strategy.\n\nProduce:\n- the 1-2 strongest alternative explanations or competing hypotheses\n- why each might beat the current claim\n- the critical tests, observations, or traces that would discriminate between them\n- what result would cause you to keep, revise, or reject the current claim\n\nThis step exists to make THOROUGH meaningfully deeper than STANDARD, not just wordier.",

package/workflows/routines/ideation.json

@@ -2,6 +2,7 @@
   "id": "routine-ideation",
   "name": "Ideation Routine",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Systematic idea generation routine for exploring solution spaces and generating diverse approaches to problems. Supports different perspectives (simplicity, performance, maintainability, etc.) for parallel ideation. Expected inputs: problem, constraints, context, perspective (optional), quantity, deliverable name.",
   "steps": [
     {
@@ -70,4 +71,3 @@
     }
   ]
 }
-

package/workflows/routines/parallel-work-partitioning.json

@@ -2,6 +2,7 @@
   "id": "routine-parallel-work-partitioning",
   "name": "Parallel Work Partitioning Routine",
   "version": "0.1.0",
+  "metricsProfile": "none",
   "description": "Analyzes a set of work items and their dependencies, partitions them into independent batches that can be safely parallelized across subagents, and produces a sorted execution plan. Flags items with cross-dependencies for sequential handling by the main agent.",
   "metaGuidance": [
     "INDEPENDENCE IS THE PRIORITY: a batch is only parallel-safe if no item in it depends on any other item in any concurrent batch.",

package/workflows/routines/philosophy-alignment.json

@@ -2,6 +2,7 @@
   "id": "routine-philosophy-alignment",
   "name": "Philosophy Alignment Routine",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Independently evaluates a plan or implementation artifact against the user's coding philosophy. Produces findings by principle name and distinguishes blocking violations from acceptable tensions.",
   "clarificationPrompts": [
     "What artifact should I review? (plan, architecture summary, implementation diff, files)",
@@ -59,4 +60,4 @@
       "requireConfirmation": false
     }
   ]
-}
+}

package/workflows/routines/plan-analysis.json

@@ -2,6 +2,7 @@
   "id": "routine-plan-analysis",
   "name": "Plan Analysis Routine",
   "version": "1.1.0",
+  "metricsProfile": "none",
   "description": "Validates implementation plans using an Ideate -> Plan -> Execute strategy. Checks for completeness, pattern adherence, and risk. Designed for delegation to Plan Analyzer subagent.",
   "clarificationPrompts": [
     "What plan file should I analyze? (e.g., implementation-plan.md)",
@@ -97,4 +98,4 @@
       ]
     }
   ]
-}
+}

package/workflows/routines/plan-generation.json

@@ -2,6 +2,7 @@
   "id": "routine-plan-generation",
   "name": "Plan Generation Routine",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Generates a complete candidate implementation plan from a neutral fact packet. Designed for parallel use across multiple perspectives so the main agent can compare or synthesize plans.",
   "clarificationPrompts": [
     "What problem should this plan solve?",
@@ -60,4 +61,4 @@
       "requireConfirmation": false
     }
   ]
-}
+}

package/workflows/routines/tension-driven-design.json

@@ -2,6 +2,7 @@
   "id": "routine-tension-driven-design",
   "name": "Tension-Driven Design Generation",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Generates design candidates by deeply understanding a problem, identifying real tensions and constraints (including the dev's philosophy), and producing candidates that resolve those tensions differently. Each candidate includes explicit tradeoffs, failure modes, and philosophy alignment. Replaces perspective-based generation with constraint-driven generation for higher-quality, genuinely diverse candidates.",
   "clarificationPrompts": [
     "What problem should this design solve?",

package/workflows/scoped-documentation-workflow.json

@@ -2,6 +2,7 @@
   "id": "scoped-documentation-workflow",
   "name": "Scoped Documentation Workflow",
   "version": "2.0.0",
+  "metricsProfile": "coding",
   "description": "Use this to create documentation for a single, bounded subject — one class, one integration point, one mechanism, or one architecture decision. Enforces strict scope discipline to prevent documentation sprawl.",
   "about": "## Scoped Documentation Workflow\n\nUse this when you need to document **one specific, bounded subject** -- a single class, one integration contract, a particular algorithm, an architecture decision, or a single workflow step. The defining feature of this workflow is strict scope discipline: it explicitly defines what is \"in scope\" (explained in detail) vs. \"out of scope\" (referenced only, never explained), and enforces that boundary throughout analysis and writing.\n\n### What it produces\n\n- A focused documentation file covering the subject in depth.\n- A `SCOPE_MAP.md` that shows what is documented here vs. referenced elsewhere.\n- An optional `MAINTENANCE_NOTES.md` with guidance on when to update.\n\n### When to use it\n\n- You want docs for one class, module, mechanism, or concept -- not a whole system.\n- You've had documentation sprawl problems before and want enforced boundaries.\n- You're building a documentation set incrementally, one subject at a time.\n- The subject has clear integration points with other systems that should be referenced, not re-explained.\n\n### When NOT to use it\n\n- You need documentation that intentionally spans multiple components -- use the Document Creation workflow instead.\n- You're updating an existing doc -- use the Documentation Update workflow.\n\n### How to get good results\n\n- The first step asks you to review and approve a scope contract. Be precise here -- the whole workflow defends this boundary.\n- Out-of-scope items should already have their own documentation. If they don't, note that so the scope map can reflect it.\n- If you find the approved scope was too narrow or too broad during the workflow, you can request a scope renegotiation.",
   "examples": [
@@ -185,4 +186,4 @@
       "hasValidation": true
     }
   ]
-}
+}

package/workflows/test-artifact-loop-control.json

@@ -3,6 +3,7 @@
   "name": "Test Artifact Loop Control",
   "description": "Test workflow demonstrating typed artifact loop control (Phase 3 migration pattern)",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "metaGuidance": [
     "This workflow demonstrates the new artifact-based loop control pattern.",
     "Instead of prose validation (checking for 'continuePlanning = true' in text),",
@@ -55,7 +56,9 @@
       "title": "Complete",
       "prompt": "The iteration loop has completed. Assess whether the loop result is ready to publish.\n\nProvide an assessment artifact for readiness.",
       "requireConfirmation": false,
-      "assessmentRefs": ["readiness_gate"],
+      "assessmentRefs": [
+        "readiness_gate"
+      ],
       "assessmentConsequences": [
         {
           "when": {
@@ -77,7 +80,10 @@
         {
           "id": "confidence",
           "purpose": "How confident the agent is that the loop result is complete and correct.",
-          "levels": ["low", "high"]
+          "levels": [
+            "low",
+            "high"
+          ]
         }
       ]
     }

package/workflows/test-session-persistence.json

@@ -3,6 +3,7 @@
   "name": "Session Persistence Test",
   "description": "Purpose-built workflow for testing v2 session persistence, cross-chat resume, and checkpoint mechanics. Has 5 simple steps that agents can complete quickly with unique marker outputs.",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "steps": [
     {
       "id": "step-1-alpha",

package/workflows/ui-ux-design-workflow.json

@@ -2,6 +2,7 @@
   "id": "ui-ux-design-workflow",
   "name": "UI/UX Design Workflow",
   "version": "0.1.0",
+  "metricsProfile": "design",
   "description": "Design UI/UX from scratch with enforced process. Makes problem framing structurally required before solution proposals, forces exploration of multiple design directions before convergence, and applies reviewer families for information architecture, UX laws, accessibility, edge cases, and content. Output: a design spec concrete enough to implement or review.",
   "about": "## UI/UX Design Workflow\n\nThis workflow produces a design spec for a new feature, screen, component, or interaction. It is built around a single principle: problem framing must happen before any solutions are proposed. The workflow makes this structurally impossible to skip, which prevents the most common failure mode in AI-assisted design  -- going straight from \"I need a settings screen\" to a layout without ever asking who uses it or what they are trying to do.\n\n**What it does:**\nPhase 0 frames the problem by reading existing code patterns and asking only what tools cannot answer. Phase 1 generates 2-3 genuinely different design directions before any one is chosen. Phases 2-5 run parallel reviewer families  -- information architecture, UX laws (Hick's Law, Miller's Law, Fitts's Law, and others), accessibility (specific WCAG requirements, not just \"follow WCAG\"), edge cases (empty, error, loading, first-use), and content quality  -- then synthesize their findings, resolve contradictions, and write a spec only after all hard quality gates pass.\n\n**When to use it:**\n- You need to design a new screen, feature, or non-trivial component\n- You want explicit coverage of accessibility, edge states, and UX laws, not just a layout sketch\n- You need a spec concrete enough for an engineer to implement or a designer to review\n- Simple single-component changes also work through a lighter direct-spec path\n\n**What it produces:**\nA design spec with 8 sections: design decision, information architecture, interaction design, all element states, specific accessibility requirements, content copy, reviewer findings with citations, and open questions that still require human visual review.\n\n**How to get good results:**\nPoint the workflow to your codebase so it can read existing components and patterns. Provide the design system location if it is not in the repo. Share any known user pain points or research. The workflow will surface what it cannot determine on its own.",
   "examples": [

package/workflows/workflow-diagnose-environment.json

@@ -2,6 +2,7 @@
   "id": "workflow-diagnose-environment",
   "name": "Diagnostic: Environment & Subagents",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Use this to diagnose MCP server, tool availability, or environment configuration issues. Probes for subagent access and generates a local configuration file.",
   "about": "## Environment Diagnostic Workflow\n\nThis is a short, self-contained diagnostic that checks what capabilities are actually available in the current workspace  -- specifically whether subagent delegation works and whether WorkRail tools are accessible to those subagents.\n\n**What it does:**\nThe workflow actively probes for subagent access by attempting to contact a subagent and have it list available tools. Based on the result, it classifies the environment into one of three tiers: full delegation (Tier 3), proxy mode where subagents exist but lack tool access (Tier 2), or solo mode with no subagents available (Tier 1). It then writes a `.workrail/config.json` file recording the detected capability tier so other workflows can make informed delegation decisions.\n\n**When to use it:**\n- You are setting up WorkRail in a new workspace for the first time\n- A workflow that relies on subagent delegation is not working as expected\n- You suspect MCP server configuration is wrong but are not sure what tier you are in\n- You want a persistent record of what the current environment can actually do\n\n**What it produces:**\nA `.workrail/config.json` file with the detected mode (`delegate`, `proxy`, or `solo`) and subagent names if discovered. A summary of what capabilities were found.\n\n**How to get good results:**\nRun this workflow before starting complex multi-agent workflows. It takes only two steps and requires no input from you beyond starting it.",
   "examples": [

package/workflows/workflow-for-workflows.json

@@ -2,6 +2,7 @@
   "id": "workflow-for-workflows",
   "name": "Workflow Authoring Workflow",
   "version": "2.4.0",
+  "metricsProfile": "design",
   "description": "Use this to author or modernize a WorkRail workflow. Guides through understanding the task, defining effectiveness targets, designing architecture and quality gates, drafting, validating, assigning tags, and handing off.",
   "about": "## Workflow Authoring Workflow\n\nThis is the standard WorkRail workflow for creating a new workflow from scratch or modernizing an existing one. It is the trust gate for all other workflows: a workflow is not considered production-ready until it has passed through here.\n\n**What it does:**\nThe workflow walks through the full authoring lifecycle: understanding the task, choosing the right baseline and archetype, designing the phase and quality-gate architecture, drafting the workflow JSON, running structural validators, auditing state fields for bloat, simulating execution against real scenarios, running an adversarial quality review, and producing a final trust handoff. For modernization tasks it builds a value inventory first to ensure enforcement mechanisms, domain knowledge, and behavioral rules are preserved or equivalently replaced.\n\n**When to use it:**\n- You want to author a new WorkRail workflow for a recurring task or problem\n- You have an existing workflow that is outdated, uses legacy patterns (pseudo-DSL, regex validation, satisfaction-score loops), or produces shallow results\n- You want a workflow that will pass the WorkRail quality bar and be trusted to run in production\n\n**What it produces:**\nA validated, tagged workflow JSON file with a `validatedAgainstSpecVersion` stamp. A final trust handoff with readiness verdict, known failure modes, residual weaknesses, and testing guidance.\n\n**How to get good results:**\nDescribe the recurring task the workflow should solve, who will run it, and what a satisfying result looks like. For modernization, point to the existing workflow file. The workflow reads the schema and authoring spec itself  -- you do not need to know the JSON format in advance.",
   "examples": [

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

@@ -2,6 +2,7 @@
   "id": "workflow-for-workflows",
   "name": "Workflow Authoring Workflow",
   "version": "2.5.0",
+  "metricsProfile": "design",
   "description": "Use this to author or modernize a WorkRail workflow. Guides through understanding the task, defining effectiveness targets, designing architecture and quality gates, drafting, validating, assigning tags, and handing off.",
   "about": "## Workflow Authoring Workflow\n\nThis is the standard WorkRail workflow for creating a new workflow from scratch or modernizing an existing one. It is the trust gate for all other workflows: a workflow is not considered production-ready until it has passed through here.\n\n**What it does:**\nThe workflow walks through the full authoring lifecycle: understanding the task, choosing the right baseline and archetype, designing the phase and quality-gate architecture, drafting the workflow JSON, running structural validators, auditing state fields for bloat, simulating execution against real scenarios, running an adversarial quality review, and producing a final trust handoff. For modernization tasks it builds a value inventory first to ensure enforcement mechanisms, domain knowledge, and behavioral rules are preserved or equivalently replaced.\n\n**When to use it:**\n- You want to author a new WorkRail workflow for a recurring task or problem\n- You have an existing workflow that is outdated, uses legacy patterns (pseudo-DSL, regex validation, satisfaction-score loops), or produces shallow results\n- You want a workflow that will pass the WorkRail quality bar and be trusted to run in production\n\n**What it produces:**\nA validated, tagged workflow JSON file with a `validatedAgainstSpecVersion` stamp. A final trust handoff with readiness verdict, known failure modes, residual weaknesses, and testing guidance.\n\n**How to get good results:**\nDescribe the recurring task the workflow should solve, who will run it, and what a satisfying result looks like. For modernization, point to the existing workflow file. The workflow reads the schema and authoring spec itself  -- you do not need to know the JSON format in advance.",
   "examples": [
@@ -670,6 +671,33 @@
       },
       "requireConfirmation": false
     },
+    {
+      "id": "phase-7b-declare-metrics-profile",
+      "title": "Phase 7b: Declare metricsProfile",
+      "promptBlocks": {
+        "goal": "Declare the metricsProfile field in the authored workflow JSON, or explicitly justify omitting it. The metricsProfile field enables engine-injected metrics instrumentation footers in step prompts. When set, the engine injects context key accumulation reminders into every step prompt -- guiding compliant agents to report outcome, commit SHAs, PR numbers, and diff stats at session completion. Without this field, captureConfidence is always 'none' and no session metrics are collected.",
+        "procedure": [
+          "Choose the correct profile based on what the workflow produces:",
+          "  - 'coding': produces code commits. Use for implementation, refactoring, bug-fix, migration, and documentation-writing workflows.",
+          "  - 'review': produces a review decision on a PR or MR. Use for code review, audit, and change validation workflows.",
+          "  - 'research': produces a finding or recommendation but no commits. Use for investigation, diagnosis, and analysis workflows.",
+          "  - 'design': produces a design artifact (pitch, spec, ADR, architecture doc) but no commits.",
+          "  - 'ticket': creates or updates work items in an external system (Jira, GitHub Issues, Linear).",
+          "  - 'none': meta-workflow, authoring tool, utility routine, or no measurable outcome. Set explicitly and document the reason.",
+          "Add `\"metricsProfile\": \"<profile>\"` as a top-level field in the workflow JSON, after `recommendedPreferences` if that field exists.",
+          "If choosing 'none', record the justification in your notes so the decision is auditable."
+        ],
+        "constraints": [
+          "Do not invent a new profile value. The closed set is: 'coding', 'review', 'research', 'design', 'ticket', 'none'.",
+          "The engine does NOT derive the profile from tags automatically. You must set it explicitly.",
+          "workflow-for-workflows itself produces a workflow JSON artifact (a design output) -- use 'design'. It does not commit code."
+        ],
+        "outputRequired": {
+          "notesMarkdown": "State the chosen metricsProfile and a one-line justification. If omitting, explain why."
+        }
+      },
+      "requireConfirmation": false
+    },
     {
       "id": "phase-7-final-trust-handoff",
       "title": "Phase 7: Final Trust Handoff",

package/workflows/wr.discovery.json

@@ -2,6 +2,7 @@
   "id": "wr.discovery",
   "name": "Discovery Workflow",
   "version": "3.2.0",
+  "metricsProfile": "research",
   "validatedAgainstSpecVersion": 3,
   "description": "Use this to explore and think through a problem end-to-end. Moves between landscape exploration, problem framing, candidate generation, adversarial challenge, and uncertainty resolution.",
   "about": "## Discovery Workflow\n\nThis workflow is for structured thinking through an ambiguous problem, opportunity, or decision -- the kind where you are not sure of the right answer yet and jumping straight to solutions would be premature.\n\n**What it does:**\nBefore starting any research, the workflow challenges the stated goal: it determines whether you handed it a problem or a solution, surfaces hidden assumptions, and defines what success looks like in concrete observable terms. It then selects one of three emphasis paths based on your actual need: `landscape_first` for understanding the current state and comparing options, `full_spectrum` for important or ambiguous problems where both landscape grounding and reframing are needed, and `design_first` when the dominant risk is solving the wrong problem. The workflow moves through landscape research, stakeholder and problem framing, candidate direction generation, adversarial challenge, and an uncertainty-resolution stage that can close with a recommendation, a targeted research follow-up, or a prototype/test plan. A design document is maintained throughout as the human-facing artifact.\n\n**When to use it:**\n- You face a decision, architectural question, or design problem with no obvious right answer\n- You want to explore an opportunity space before committing to a direction\n- You suspect the stated problem might not be the real problem\n- You need a structured recommendation with explicit tradeoffs and alternatives rather than the first plausible answer\n- You want to make sure you are solving the right problem, not just the one you described\n\n**What it produces:**\nA design document covering: the reframed problem (if the original was solution-framed), the selected path and framing, landscape takeaways, chosen direction and why it won, the strongest alternative and why it lost, confidence band, residual risks, and next actions.\n\n**How to get good results:**\nDescribe the problem, opportunity, or decision you want help thinking through -- or describe the solution you are considering, and let the workflow figure out the underlying problem. State what outcome you want (a recommendation, a comparison, a research plan, a prototype direction). The more context you provide upfront about constraints and anti-goals, the sharper the framing will be.",

package/workflows/wr.shaping.json

@@ -2,6 +2,7 @@
   "id": "wr.shaping",
   "name": "Shaping Workflow",
   "version": "1.0.0",
+  "metricsProfile": "design",
   "description": "Faithful Shape Up product shaping. Converts a fuzzy problem into a bounded, implementation-ready pitch (pitch.md). Tech-agnostic -- works for any language, platform, framework, or non-software work. Produces a product-level pitch, not an engineering spec.",
   "about": "## Shaping Workflow\n\nTakes a fuzzy problem and produces a shaped pitch: a specific problem story, a fixed appetite, a fat-marker solution sketch, rabbit holes patched at the product level, and explicit no-gos.\n\n### What this is\n\nFaithful Shape Up shaping. The output is a **product-level pitch** -- it describes what the feature does and what it explicitly does not do, at a level a human engineering team or an AI pipeline can execute against.\n\nThis is not an engineering spec. It does not contain file paths, function signatures, test commands, or implementation plans. Those belong in the engineering phase that follows.\n\n### Tech-agnostic\n\nThis workflow works for any context: web, mobile, backend, data, embedded, or non-software product work. There are no references to specific tools, languages, frameworks, or platforms.\n\n### What it produces\n\n- `pitch.md` at `.workrail/current-pitch.md` -- the shaped pitch\n\n### Two mandatory human gates\n\n1. **Frame gate (Step 2):** confirm the problem statement and appetite before design work begins -- a wrong frame wastes everything downstream\n2. **Approval gate (Step 8):** review the complete pitch before implementation starts\n\nBoth gates self-resolve with low-confidence defaults when running autonomously.\n\n### When to use this\n\n- After `wr.discovery` when you have a direction and need to translate it into a bounded task\n- Before `coding-task-workflow-agentic` when a task is fuzzy, could sprawl, or needs appetite-setting\n- When multiple people need to agree on what is being built before engineering starts\n- Any time you want the Shape Up circuit breaker: fixed time, variable scope, kill if it doesn't fit\n\n### When to skip this\n\n- The task is small, concrete, and clearly scoped -- go straight to Coding\n- Discovery already produced a bounded, implementable direction\n- You have a pre-written ticket or spec",
   "examples": [
@@ -21,7 +22,10 @@
         {
           "id": "frame_soundness",
           "purpose": "Problem names a specific person/role, describes a specific situation, states what they need, and states what fails today.",
-          "levels": ["low", "high"]
+          "levels": [
+            "low",
+            "high"
+          ]
         }
       ]
     },
@@ -32,7 +36,10 @@
         {
           "id": "solution_roughness",
           "purpose": "Elements describe user-visible surfaces, flows, and behavioral constraints -- not function signatures, data models, or implementation patterns.",
-          "levels": ["low", "high"]
+          "levels": [
+            "low",
+            "high"
+          ]
         }
       ]
     }
@@ -65,10 +72,14 @@
         "not_equals": true
       },
       "prompt": "Present the extracted problem framings and confirm the frame before any design work begins.\n\nShow:\n1. The candidate problem framings from Step 1\n2. Suggested appetite: xs (hours), s (1-2 days), m (3-7 days), l (1-2 weeks), xl (3-4 weeks)\n3. Open questions that need resolution\n\nAsk the user to:\n- Select or rewrite the problem statement as a specific story\n- Confirm the appetite\n- Answer critical open questions\n\n**Structural validation for frame_soundness=high:** the problem statement must name a specific person or role, describe a specific situation, state what they need, AND state what fails today. Abstract statements ('users want better X') are always frame_soundness=low.\n\nDo NOT proceed until the user confirms a specific-story problem statement.\n\n**If running autonomously with no user available:** pick the most specific candidate framing, set appetite to 's' as a safe default, record both in assumptionsLog with confidence 0.4, and advance. Flag for human review.\n\nCapture:\n- `problemStatement` (confirmed specific story)\n- `appetite` (object: {sizingBucket: 'xs'|'s'|'m'|'l'|'xl'} -- xs=hours, s=1-2 days, m=3-7 days, l=1-2 weeks, xl=3-4 weeks)\n- `resolvedQuestions`",
-      "assessmentRefs": ["frame-soundness"],
+      "assessmentRefs": [
+        "frame-soundness"
+      ],
       "assessmentConsequences": [
         {
-          "when": {"anyEqualsLevel": "low"},
+          "when": {
+            "anyEqualsLevel": "low"
+          },
           "effect": {
             "kind": "require_followup",
             "guidance": "The problem statement is still abstract or solution-framed. It must name a specific person/role in a specific situation with a specific failure. Do not advance until confirmed."
@@ -105,10 +116,14 @@
         "not_equals": true
       },
       "prompt": "Expand the chosen shape into a breadboard and element list. Stay at the product level throughout.\n\n**Breadboard (words only):**\n- **Places** -- screens, dialogs, states, endpoints (from the user's perspective)\n- **Affordances** -- buttons, fields, actions -- listed under their place\n- **Connections** -- 'Place A → Place B when [user action]'\n\nNo visual layout. No code. No system internals. Words and arrows only.\n\n**Element list:**\nFor each element, one sentence classified as:\n- **Interface** -- something the user sees or interacts with (a surface, a flow, a visible state)\n- **Invariant** -- a behavioral constraint (a policy, a rule, what must always be true)\n- **Exclusion** -- functionality explicitly NOT included\n\nReject any element that:\n- Describes HOW to build something (implementation detail)\n- Uses vague modifiers without a concrete noun ('improve', 'better', 'scalable')\n\n**Structural validation for solution_roughness=high:** every element must be Interface, Invariant, or Exclusion describing product behavior -- not code structure, not technical implementation.\n\nCapture:\n- `breadboardMd` (breadboard in markdown)\n- `elements` (array: {name, description, classification: 'interface'|'invariant'|'exclusion'})",
-      "assessmentRefs": ["solution-roughness"],
+      "assessmentRefs": [
+        "solution-roughness"
+      ],
       "assessmentConsequences": [
         {
-          "when": {"anyEqualsLevel": "low"},
+          "when": {
+            "anyEqualsLevel": "low"
+          },
           "effect": {
             "kind": "require_followup",
             "guidance": "One or more elements describe implementation details or contain vague modifiers. Rewrite: every element must describe what the feature does (Interface, Invariant, or Exclusion), not how it is built."