@exaudeus/workrail 3.64.0 → 3.66.0

package/workflows/documentation-update-workflow.json

@@ -2,6 +2,7 @@
   "id": "documentation-update-workflow",
   "name": "Documentation Update & Maintenance Workflow",
   "version": "2.0.0",
+  "metricsProfile": "coding",
   "description": "Use this to update and maintain existing documentation. Uses git history to detect staleness, maps sections to current code, and refreshes outdated content while preserving what's still accurate.",
   "about": "## Documentation Update & Maintenance Workflow\n\nUse this when you have **existing** documentation that may be out of date and needs to be refreshed to match the current state of the codebase. The workflow uses git history as its primary evidence source: it checks when the docs were last committed, what changed in the relevant code since then, and classifies staleness before touching anything.\n\n### What it produces\n\nUpdated documentation files with stale or inaccurate sections corrected, missing coverage added, and removed content pruned. A completion summary is written to notes for future maintainers, including maintenance recommendations and sections at risk of going stale again quickly.\n\n### When to use it\n\n- A feature shipped and the docs were never updated.\n- You suspect a doc is outdated but aren't sure which parts.\n- You want a systematic, section-by-section audit rather than a quick edit.\n- The repo has git history covering both code and docs (the workflow degrades gracefully without git, but git history is the primary evidence source).\n\n### When NOT to use it\n\n- You are writing a doc from scratch -- use the Document Creation workflow instead.\n- You only need to fix a single known typo or sentence -- just edit the file directly.\n\n### How to get good results\n\n- Point the workflow at the specific documentation files and the code directories they describe.\n- The workflow will ask you to approve an update plan before making any edits -- review it carefully. This is the main checkpoint where you control scope.\n- If you want to defer lower-priority improvements, say so during plan review.",
   "examples": [
@@ -104,4 +105,4 @@
       "requireConfirmation": false
     }
   ]
-}
+}

package/workflows/intelligent-test-case-generation.json

@@ -2,6 +2,7 @@
   "id": "intelligent-test-case-generation",
   "name": "Test Case Generation from Tickets",
   "version": "1.0.0",
+  "metricsProfile": "research",
   "description": "Use this to generate integration and end-to-end test cases from ticket requirements. Reads the ticket, traces affected code paths, identifies boundary conditions, and produces developer-readable test case descriptions.",
   "about": "## Intelligent Test Case Generation\n\nThis workflow generates structured integration and end-to-end test cases directly from a ticket. It reads the ticket requirements, traces the affected code paths in the codebase, identifies boundary conditions and failure scenarios, and produces developer-readable test case descriptions that a developer can implement without guessing.\n\n**What it does:**\nThe workflow extracts every acceptance criterion from the ticket, traces which modules, endpoints, and integration boundaries are involved, identifies the existing test patterns in the repo (so generated cases match the team's style), then systematically generates happy path, boundary, and failure scenarios for each criterion. It checks coverage before writing, resolves ambiguities with you before generating anything uncertain, and finishes with a full test case list plus a coverage summary.\n\n**When to use it:**\n- When a ticket has clear acceptance criteria and you want comprehensive test coverage without manually reasoning through every edge case\n- When onboarding to a feature area and wanting to understand the expected behavior through its test scenarios\n- When a ticket spans multiple services or integration points and you need coverage across all of them\n- When preparing for a QA handoff or code review where test coverage must be explicitly demonstrated\n\n**What it produces:**\nNumbered test cases (TC-1, TC-2, ...) each with a title, acceptance criterion mapping, test type (Integration or E2E), risk level, preconditions, numbered test steps, expected result, and implementation notes. Cases are grouped by acceptance criterion and followed by a summary table. Open ambiguities and coverage gaps are disclosed explicitly.\n\n**How to get good results:**\nProvide the ticket in any standard format -- title, description, and acceptance criteria are enough. The workflow will trace the codebase itself. If the ticket has linked specs, API docs, or architecture diagrams, mention them. The more complete the acceptance criteria, the fewer clarifying questions the workflow will need to ask.",
   "examples": [
@@ -38,7 +39,7 @@
         "var": "ambiguities",
         "not_equals": []
       },
-      "prompt": "Before generating test scenarios, resolve the ambiguities you found.\n\nFor each ambiguity in `ambiguities`:\n1. State what is unclear and why it matters for test design\n2. Propose the most reasonable interpretation based on context\n3. Ask me to confirm, adjust, or provide the missing information\n\nKeep questions targeted. If the ticket, codebase, or docs can answer the question, answer it yourself first.\n\nIf the user's response significantly changes the scope or adds new acceptance criteria, revisit Phase 1 scenario identification before continuing \u2014 do not carry stale scenarios forward.\n\nCapture:\n- `resolvedAmbiguities` -- list of ambiguities with chosen interpretation\n- `openAmbiguities` -- ambiguities the user still needs to resolve (initialize as empty)",
+      "prompt": "Before generating test scenarios, resolve the ambiguities you found.\n\nFor each ambiguity in `ambiguities`:\n1. State what is unclear and why it matters for test design\n2. Propose the most reasonable interpretation based on context\n3. Ask me to confirm, adjust, or provide the missing information\n\nKeep questions targeted. If the ticket, codebase, or docs can answer the question, answer it yourself first.\n\nIf the user's response significantly changes the scope or adds new acceptance criteria, revisit Phase 1 scenario identification before continuing — do not carry stale scenarios forward.\n\nCapture:\n- `resolvedAmbiguities` -- list of ambiguities with chosen interpretation\n- `openAmbiguities` -- ambiguities the user still needs to resolve (initialize as empty)",
       "requireConfirmation": true
     },
     {

package/workflows/learner-centered-course-workflow.json

@@ -2,6 +2,7 @@
   "id": "personal-learning-course-design",
   "name": "Personal Learning Course Design Workflow",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Use this to design a personal learning course. Creates structured learning objectives, sequencing, and a course outline suited to your time constraints.",
   "about": "## Personal Learning Course Design Workflow\n\nUse this to design a structured personal learning course -- defining clear objectives, sequencing, assessments, and a schedule that fits your time constraints. This workflow focuses on the **design** phase: building the blueprint for your learning program before you create any materials.\n\n### What it produces\n\nDepending on the path you choose:\n\n- **Quick Start (3-5 days)**: a functional learning plan with 2-3 focused objectives, a weekly schedule, a resource list, and basic progress tracking.\n- **Balanced (1-2 weeks)**: a comprehensive learning system with modules, structured assessments, active learning activities, and accountability measures.\n- **Comprehensive (2-3 weeks)**: a professional-grade learning system with full Bloom's Taxonomy-aligned objectives, spaced repetition design, multi-layer assessments, and long-term retention planning.\n\n### When to use it\n\n- You want to learn something specific and want a structured plan rather than ad-hoc resource consumption.\n- You are preparing for a certification, career transition, or skill upgrade and need a realistic timeline and sequence.\n- You've tried self-study before and found it hard to stay on track -- a well-designed plan with clear checkpoints helps.\n\n### When NOT to use it\n\n- You need to create the actual study materials -- use the Personal Learning Materials Creation workflow after this one.\n- You're designing a course for other learners, not for yourself -- consider an instructional design workflow instead.\n\n### How to get good results\n\n- Be honest about your weekly time budget. An ambitious plan that doesn't fit your schedule is worse than a modest plan you actually follow.\n- Start with the Quick Start path if you're uncertain -- you can always expand. Choosing Comprehensive when you're time-constrained leads to abandonment.\n- The more specific your goal (\"pass the AWS SAA exam in 3 months\"), the better the resulting plan will be compared to a vague goal (\"learn cloud\").",
   "examples": [
@@ -292,4 +293,4 @@
       "hasValidation": true
     }
   ]
-}
+}

package/workflows/mr-review-workflow.agentic.v2.json

@@ -14,6 +14,7 @@
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
   },
+  "metricsProfile": "review",
   "features": [
     "wr.features.subagent_guidance"
   ],

package/workflows/personal-learning-materials-creation-branched.json

@@ -2,6 +2,7 @@
   "id": "personal-learning-materials-creation-branched",
   "name": "Personal Learning Materials Creation Workflow",
   "version": "1.1.0",
+  "metricsProfile": "none",
   "description": "Use this to create learning materials for a course or subject. Adapts depth and format to your time budget — Quick Start, Balanced, or Comprehensive.",
   "about": "## Personal Learning Materials Creation Workflow\n\nUse this to create the actual study materials for a course or subject you are learning -- study guides, exercises, assessments, and spaced-repetition review materials. This workflow assumes you already have a learning plan or course design with defined objectives; it focuses on producing materials that directly support those objectives.\n\n### What it produces\n\nDepending on the path you choose:\n\n- **Quick Start (2-3 weeks)**: study guides and basic exercises for immediate use.\n- **Balanced (4-6 weeks)**: a complete learning system -- study guides, exercises, assessments, and spaced repetition materials.\n- **Comprehensive (8-12 weeks)**: a full learning ecosystem with interactive elements, effectiveness measurement, and a scalable update protocol.\n\n### When to use it\n\n- You have a learning plan and need to turn it into usable materials.\n- You are preparing for a certification, exam, or structured self-study program.\n- You want materials tailored to your specific objectives rather than relying entirely on off-the-shelf resources.\n\n### When NOT to use it\n\n- You haven't designed your learning course yet -- use the Personal Learning Course Design workflow first to define objectives and structure.\n- You need to design a course for others to take -- use the Learner-Centered Course workflow instead.\n\n### How to get good results\n\n- Select the path honestly based on available time. Starting with Quick Start and expanding later is better than committing to Comprehensive and abandoning it.\n- Have your learning objectives written out before starting -- the workflow maps every material directly to an objective.\n- Be specific about your preferred learning formats (text, diagrams, flashcards, practice problems) at the start.",
   "examples": [

package/workflows/presentation-creation.json

@@ -2,6 +2,7 @@
   "id": "presentation-creation",
   "name": "Presentation Creation Workflow",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Use this to create a compelling presentation. Covers audience analysis, content strategy, slide structure, and delivery preparation. Output works with any presentation tool.",
   "about": "## Presentation Creation Workflow\n\nUse this to build a compelling, audience-specific presentation from scratch -- whether for a conference talk, internal strategy review, client pitch, or team demo. The workflow grounds every content decision in a concrete audience profile, so the result is written for real people in a real context rather than a generic slide deck.\n\n### What it produces\n\n- An audience profile and context map.\n- A content strategy with a single core message, supporting arguments, and a call-to-action.\n- A numbered slide outline with content types and timing estimates.\n- Full slide content and speaker notes for every slide.\n- Backup slides for anticipated deep-dive questions.\n- A delivery preparation plan including practice schedule, Q&A prep, and technical checklist.\n\n### When to use it\n\n- You are building a presentation that needs to persuade, inform, or motivate a specific audience.\n- You want structured help moving from \"I have a topic\" to \"I have a complete, rehearsal-ready deck.\"\n- The presentation has real stakes -- a client pitch, a leadership review, a conference talk.\n\n### When NOT to use it\n\n- You just need to slap a few bullets onto slides quickly -- this workflow is for presentations where quality matters.\n\n### How to get good results\n\n- The more specific you are about your audience, the better the content strategy will be. \"Engineering managers at a Series B fintech\" beats \"technical people.\"\n- The workflow has two confirmation gates: after the audience profile and after the slide outline. Use these to redirect before content gets written.\n- Bring source materials, data, and any existing slides you want to incorporate -- the content development step can ingest these.",
   "examples": [
@@ -169,4 +170,4 @@
       "requireConfirmation": false
     }
   ]
-}
+}

package/workflows/production-readiness-audit.json

@@ -2,6 +2,7 @@
   "id": "production-readiness-audit",
   "name": "Production Readiness Audit",
   "version": "0.1.0",
+  "metricsProfile": "research",
   "description": "Use this to audit a codebase scope for production readiness. Checks debugging correctness, runtime operability, artifact realism, technical debt, and anything that would prevent honest production deployment.",
   "about": "## Production Readiness Audit\n\nThis workflow performs a structured, evidence-driven audit to answer one question honestly: is this code actually ready for production? It goes beyond style and lint -- it looks for debugging correctness, runtime operability under real conditions, artifact realism (stale code, fake completeness, placeholder behavior), maintainability debt, test and observability gaps, and security or performance risks.\n\n**What it does:**\nThe workflow bounds the audit scope, states a readiness hypothesis, freezes a neutral fact packet, then runs parallel reviewer families -- each specializing in a different readiness dimension. It reconciles contradictions through an evidence loop and produces a final verdict: `ready`, `ready_with_conditions`, `not_ready`, or `inconclusive`.\n\n**When to use it:**\n- Before shipping a new service, feature, or major refactor to production\n- When a codebase has been under rapid development and you want an honest readiness check before a launch deadline\n- When onboarding to a codebase and wanting a structured assessment of its production posture\n- When a post-incident review surfaces questions about whether the system was truly ready\n\n**What it produces:**\nA verdict with a confidence band, a prioritized list of blocker-grade and major findings, debugging leads, runtime and operational risk callouts, artifact-realism concerns (misleading completeness, stale docs, dead paths), a coverage ledger by audit domain, and a remediation order with specific follow-up recommendations.\n\n**How to get good results:**\nProvide a clear scope -- a service name, a module path, or a feature boundary. The narrower and more concrete the scope, the sharper the findings. If \"production-ready\" has a specific meaning for your team (e.g. SLA requirements, specific deployment constraints), mention it. The workflow will try to infer the production bar from repo patterns and context, but explicit criteria improve accuracy.",
   "examples": [

package/workflows/relocation-workflow-us.json

@@ -2,6 +2,7 @@
   "id": "relocation-workflow-us",
   "name": "US Relocation Decision Workflow",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Use this to evaluate US cities or regions for a potential relocation. Discovers your preferences, generates candidate areas, screens them, and produces a ranked dossier with evidence.",
   "about": "## US Relocation Decision Workflow\n\nUse this to evaluate US cities and regions for a potential move. The workflow takes a structured, evidence-driven approach: it starts by calibrating your preferences and dealbreakers, generates a broad diverse pool of candidate areas (including non-obvious ones), screens them systematically, and produces a ranked dossier you can actually act on.\n\n### What it produces\n\n- A `RELOCATION_DOSSIER.md` with your full preference model, screening results, and comparison matrix.\n- Individual per-candidate profiles at `relocation-profiles/<slug>.md` covering housing, cost of living, taxes, safety, climate risk, schools, healthcare, commute, and any other modules you activate.\n- A scored ranking with explainable reasoning and an explicit disclosure of any data gaps.\n- A next-steps plan: visit recommendations, open questions per candidate, and pivot triggers.\n\n### When to use it\n\n- You are seriously considering a US relocation and want a rigorous, evidence-backed shortlist.\n- You want to surface non-obvious candidates you wouldn't have considered on your own.\n- You've been anchoring on a handful of cities and want a structured process to either validate or challenge that.\n\n### How to get good results\n\n- Be honest about dealbreakers upfront -- the workflow builds these into screening and filters candidates early.\n- The MaxDiff weight calibration exercise (offered in Phase 1) is worth doing if you're unsure how to weight competing priorities. It takes 5-10 minutes and produces more reliable weights than guessing.\n- The calibration deck in Phase 1 shows you lifestyle archetypes and asks for reactions -- engage with this seriously. Surprises in your reactions are valuable signal.\n- The workflow activates only the research modules you need. Keep it focused on what actually matters to your household.",
   "examples": [

package/workflows/routines/context-gathering.json

@@ -2,6 +2,7 @@
   "id": "routine-context-gathering",
   "name": "Context Gathering Routine",
   "version": "2.1.0",
+  "metricsProfile": "none",
   "description": "Systematic codebase exploration using an Ideate -> Plan -> Execute strategy. Configurable depth levels (0-4) allow for progressively deeper understanding.",
   "clarificationPrompts": [
     "What specific area or files should I investigate?",
@@ -142,4 +143,4 @@
       ]
     }
   ]
-}
+}

package/workflows/routines/design-review.json

@@ -2,6 +2,7 @@
   "id": "routine-design-review",
   "name": "Design Review Routine",
   "version": "1.0.0",
+  "metricsProfile": "none",
   "description": "Reviews a selected design using explicit tradeoffs, failure modes, simpler-alternative checks, runner-up comparison, and philosophy alignment. Produces a reusable design-review findings artifact.",
   "clarificationPrompts": [
     "What design artifact or summary should I review?",

package/workflows/routines/execution-simulation.json

@@ -2,6 +2,7 @@
   "id": "routine-execution-simulation",
   "name": "Execution Simulation Routine",
   "version": "1.1.0",
+  "metricsProfile": "none",
   "description": "Simulates code execution step-by-step through mental tracing and state tracking. Uses an Ideate -> Plan -> Execute strategy to identify the best simulation paths before tracing.",
   "clarificationPrompts": [
     "What function should I simulate? (function name, file, line)",
@@ -81,4 +82,4 @@
       ]
     }
   ]
-}
+}

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."