@exaudeus/workrail 3.65.0 → 3.67.0

package/docs/authoring-v2.md

@@ -219,22 +219,47 @@ Important implementation detail:
 
 ### Session analytics context keys (`metrics_*`)
 
-The `projectSessionMetricsV2` projection (planned -- not yet implemented) reads a set of `metrics_*` context keys to build session attribution data. These keys are not validated by the engine -- nothing will fail if they are absent or malformed. But absent or wrong data produces permanently incorrect analytics with no error or warning.
+The engine reads `metrics_*` context keys from the final `continue_workflow` call to build session attribution data for the `run_completed` event. These keys feed `captureConfidence`, `agentCommitShas`, and related fields.
 
-Set these keys in your step's `Capture:` footer.
+**Recommended approach: set `metricsProfile` at workflow level**
+
+The simplest way to instrument a workflow is to declare `metricsProfile` as a top-level field in the workflow JSON. The engine then injects the appropriate footer instructions into step prompts automatically -- no per-step `Capture:` text needed.
+
+```json
+{
+  "metricsProfile": "coding"
+}
+```
+
+Profile selection guide:
+
+| Profile | When to use | What the engine injects |
+|---|---|---|
+| `"coding"` | Workflow produces git commits (implementation, refactoring, bug-fix) | SHA accumulation reminder on every step; outcome/PR/diff reminder on final step |
+| `"review"` | Workflow produces a review decision on a PR or MR | PR numbers + outcome reminder on final step only |
+| `"research"` | Workflow produces a finding or recommendation but no commits | Outcome-only reminder on final step only |
+| `"none"` or absent | Meta-workflows, utilities, authoring tools | No injection -- existing behavior unchanged |
+
+The engine does NOT derive the profile from tags automatically. Authors must set this field explicitly. When using `workflow-for-workflows` to author or modernize a workflow, the `phase-7b` step will prompt you for this decision.
+
+**Final step detection**: The engine injects the final-step footer on the last top-level step, or on the exit step of a loop that is the last top-level step. A loop in a non-terminal position does not trigger the final-step footer on its exit step.
 
 **SHA accumulation rule (critical)**
 
 `context_set` uses shallow merge: each key is replaced, not merged. If you set `metrics_commit_shas: ["abc123"]` at step 5 and then set `metrics_commit_shas: ["def456"]` at step 9, the value at step 9 is `["def456"]` -- `abc123` is permanently gone.
 
-Every step that adds commits must send the **full accumulated list** -- read the current value from context, append new SHAs, and send the complete list.
+Every step that adds commits must send the **full accumulated list** -- read the current value from context, append new SHAs, and send the complete list. The engine-injected footer includes an explicit reminder of this rule.
 
 ```
 Example (correct): metrics_commit_shas: ["abc123", "def456", "ghi789"]
 Example (wrong):   metrics_commit_shas: ["ghi789"]  -- loses abc123 and def456
 ```
 
-**Commit step `Capture:` footer** (copy this into every step that creates commits):
+**Manual `Capture:` footers (if you cannot use `metricsProfile`)**
+
+If `metricsProfile` is not appropriate for your workflow, add these footers manually.
+
+Commit step `Capture:` footer (copy into every step that creates commits):
 
 ```
 Capture (every time you commit code):
@@ -248,7 +273,7 @@ Capture (every time you commit code):
   Example (wrong):   metrics_commit_shas: ["ghi789"]  -- loses abc123 and def456
 ```
 
-**Final handoff `Capture:` footer** (copy this into your final step):
+Final handoff `Capture:` footer (copy into your final step):
 
 ```
 Capture (at final handoff only):
@@ -266,8 +291,6 @@ Capture (at final handoff only):
   (same accumulation rule as commit steps -- full list, not just final-step SHAs)
 ```
 
-Note: adding these keys to existing workflow JSON files (`coding-task-workflow-agentic.json` and others) is a separate follow-on PR. The templates above let you add them to new or custom workflows now.
-
 ### Assessment-gate authoring (v1)
 
 Assessment gates are now a shipped authoring/runtime feature, but the first slice is intentionally narrow.

package/docs/authoring.md

@@ -731,6 +731,34 @@ Canonical current rules for authoring good WorkRail workflows. workflow.schema.j
 - Using a nested key context.metrics.commit_shas instead of the flat key metrics_commit_shas
 - Setting metrics_outcome at intermediate steps before the session outcome is known
 
+### metrics-profile-declaration
+- **Level**: recommended
+- **Status**: active
+- **Scope**: workflow.definition, step.context-capture
+- **Rule**: Declare metricsProfile at workflow level to enable engine-injected metrics instrumentation footers. Use 'coding' for implementation workflows, 'review' for code review workflows, 'research' for investigation workflows, 'design' for design/planning artifacts, 'ticket' for work-item creation. Omit or use 'none' for meta-workflows and utilities.
+- **Why**: Without metricsProfile, captureConfidence is always 'none' and run_completed events carry no usable attribution data. The engine cannot auto-derive the profile from tags -- authors must set it explicitly.
+- **Enforced by**: advisory
+
+**Checks**
+- Select 'coding' when the workflow produces git commits (implementation, refactoring, bug-fix, migration, documentation updates).
+- Select 'review' when the workflow produces a review decision on a PR or MR.
+- Select 'research' when the workflow produces a finding or recommendation but no commits (investigation, audit, analysis).
+- Select 'design' when the workflow produces a design artifact (pitch, spec, ADR, architecture doc) but no commits.
+- Select 'ticket' when the workflow creates or updates work items in an external system (Jira, GitHub Issues, Linear).
+- Omit or use 'none' for authoring tools, meta-workflows, or workflows with no measurable outcome.
+- Do not invent new profile values -- the closed set is: 'coding', 'review', 'research', 'design', 'ticket', 'none'.
+- The engine does NOT derive the profile from spec/workflow-tags.json at runtime. Set the field explicitly.
+- When using workflow-for-workflows to author or modernize a workflow, the phase-7b step will prompt for this decision.
+
+**Anti-patterns**
+- Leaving metricsProfile absent from a coding or review workflow and expecting automatic instrumentation
+- Using metricsProfile 'coding' on a workflow that produces no commits (e.g., a documentation or planning workflow)
+- Assuming the engine reads tags and derives the profile automatically
+
+**Source refs**
+- `src/v2/durable-core/domain/prompt-renderer.ts` (runtime) — buildMetricsSection() implements render-time footer injection based on metricsProfile.
+- `spec/workflow.schema.json` (schema) — metricsProfile optional enum field definition.
+
 
 ## Artifacts and planning surfaces
 ### artifact-canonicality

package/package.json

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

package/spec/authoring-spec.json

@@ -1385,6 +1385,43 @@
             "Using a nested key context.metrics.commit_shas instead of the flat key metrics_commit_shas",
             "Setting metrics_outcome at intermediate steps before the session outcome is known"
           ]
+        },
+        {
+          "id": "metrics-profile-declaration",
+          "status": "active",
+          "level": "recommended",
+          "scope": ["workflow.definition", "step.context-capture"],
+          "rule": "Declare metricsProfile at workflow level to enable engine-injected metrics instrumentation footers. Use 'coding' for implementation workflows, 'review' for code review workflows, 'research' for investigation workflows, 'design' for design/planning artifacts, 'ticket' for work-item creation. Omit or use 'none' for meta-workflows and utilities.",
+          "why": "Without metricsProfile, captureConfidence is always 'none' and run_completed events carry no usable attribution data. The engine cannot auto-derive the profile from tags -- authors must set it explicitly.",
+          "enforcement": ["advisory"],
+          "checks": [
+            "Select 'coding' when the workflow produces git commits (implementation, refactoring, bug-fix, migration, documentation updates).",
+            "Select 'review' when the workflow produces a review decision on a PR or MR.",
+            "Select 'research' when the workflow produces a finding or recommendation but no commits (investigation, audit, analysis).",
+            "Select 'design' when the workflow produces a design artifact (pitch, spec, ADR, architecture doc) but no commits.",
+            "Select 'ticket' when the workflow creates or updates work items in an external system (Jira, GitHub Issues, Linear).",
+            "Omit or use 'none' for authoring tools, meta-workflows, or workflows with no measurable outcome.",
+            "Do not invent new profile values -- the closed set is: 'coding', 'review', 'research', 'design', 'ticket', 'none'.",
+            "The engine does NOT derive the profile from spec/workflow-tags.json at runtime. Set the field explicitly.",
+            "When using workflow-for-workflows to author or modernize a workflow, the phase-7b step will prompt for this decision."
+          ],
+          "antiPatterns": [
+            "Leaving metricsProfile absent from a coding or review workflow and expecting automatic instrumentation",
+            "Using metricsProfile 'coding' on a workflow that produces no commits (e.g., a documentation or planning workflow)",
+            "Assuming the engine reads tags and derives the profile automatically"
+          ],
+          "sourceRefs": [
+            {
+              "kind": "runtime",
+              "path": "src/v2/durable-core/domain/prompt-renderer.ts",
+              "note": "buildMetricsSection() implements render-time footer injection based on metricsProfile."
+            },
+            {
+              "kind": "schema",
+              "path": "spec/workflow.schema.json",
+              "note": "metricsProfile optional enum field definition."
+            }
+          ]
         }
       ]
     },

package/spec/workflow.schema.json

@@ -200,6 +200,11 @@
       "minItems": 1,
       "maxItems": 6,
       "uniqueItems": true
+    },
+    "metricsProfile": {
+      "type": "string",
+      "enum": ["coding", "review", "research", "design", "ticket", "none"],
+      "description": "Metrics instrumentation profile for this workflow. When set, the engine injects a footer into step prompts instructing the agent to accumulate and report metrics context keys (metrics_commit_shas, metrics_outcome, etc.). 'coding' injects SHA accumulation on every step and outcome/PR reporting on the final step. 'review' injects PR numbers + outcome on the final step. 'research', 'design', and 'ticket' inject outcome-only on the final step (identical behavior today, distinct semantics). 'none' or absent field disables injection entirely."
     }
   },
   "required": [

package/workflows/adaptive-ticket-creation.json

@@ -2,6 +2,7 @@
   "id": "adaptive-ticket-creation",
   "name": "Adaptive Ticket Creation Workflow",
   "version": "1.0.0",
+  "metricsProfile": "ticket",
   "description": "Use this to create high-quality Jira tickets for features, tasks, or epics. Automatically selects the right complexity path (Simple, Standard, or Epic) and generates properly structured tickets with acceptance criteria and estimates.",
   "about": "## Adaptive Ticket Creation Workflow\n\nUse this to create well-structured Jira tickets for features, tasks, or epics. The workflow automatically selects the right complexity path (Simple, Standard, or Epic) based on the request, so you don't have to decide upfront how much process you need.\n\n### What it produces\n\n- **Simple path**: one complete, developer-ready Jira ticket with a context-rich description, checkbox-style acceptance criteria, and an effort estimate.\n- **Standard path**: a high-level plan plus a batch of related tickets covering all deliverables.\n- **Epic path**: everything in Standard, plus full epic decomposition, per-story estimates with risk ratings, dependency mapping, and a reusable team rules file at `.workflow_rules/ticket_creation.md` that future runs load automatically.\n\n### When to use it\n\n- You need to create one or more Jira tickets and want them to be genuinely developer-ready.\n- You have a feature request, bug, task, or epic that needs to be broken down and estimated.\n- Your team has specific ticket conventions (naming, sizing, labels) -- the workflow learns and stores these on the Epic path.\n\n### How to get good results\n\n- Provide as much context as you have: PRD links, design files, existing related tickets, and any known constraints.\n- If your team has a `.workflow_rules/ticket_creation.md` file, the workflow loads it automatically and applies your conventions.\n- On the Epic path, the workflow asks you to approve the high-level plan and the decomposition before generating tickets. Use these checkpoints to catch scope issues early.\n- Acceptance criteria are written as checkbox-style observable conditions, not restatements of requirements. If your team has a specific AC format, describe it in the rules file.",
   "examples": [
@@ -307,4 +308,4 @@
       "requireConfirmation": false
     }
   ]
-}
+}

package/workflows/architecture-scalability-audit.json

@@ -2,6 +2,7 @@
   "id": "architecture-scalability-audit",
   "name": "Architecture Scalability Audit",
   "version": "0.1.0",
+  "metricsProfile": "research",
   "description": "Use this to audit a bounded codebase scope for architecture scalability. Declare which scalability dimensions matter (load, data volume, team size, feature extensibility, operational); the workflow investigates each and produces evidence-grounded findings.",
   "about": "## Architecture Scalability Audit\n\nThis workflow audits a bounded codebase scope for scalability across the dimensions you care about. It does not produce generic \"won't scale\" warnings -- every finding must cite a specific file, class, method, or pattern, and every concern must name a concrete growth scenario (e.g. 10x traffic, 100x records, 3x team size).\n\n**What it does:**\nYou declare the scope boundary and the scalability dimensions that matter for your context. The workflow reads the codebase to understand the architecture, assigns one dedicated reviewer family per dimension, runs them in parallel from a shared fact packet, reconciles contradictions and blind spots through a synthesis loop, and delivers a per-dimension verdict (will_break / risk / fine) with an overall scalability readiness verdict.\n\n**The five scalability dimensions you can select:**\n- **load** -- handles more requests, users, or throughput\n- **data_volume** -- handles more records, storage, or query size\n- **team_org** -- more teams or developers working on this scope without friction\n- **feature_extensibility** -- more features added without rearchitecting\n- **operational** -- more deployments, environments, or operational complexity\n\n**When to use it:**\n- Before investing significantly in a component you expect to grow\n- When planning capacity for a new traffic tier or data volume increase\n- When evaluating a codebase acquired through a merger, partnership, or open-source adoption\n- When a team is growing and you want to know if the architecture will hold under parallel development\n\n**What it produces:**\nAn overall scalability verdict, per-dimension findings with specific code references and growth scenarios, cross-cutting concerns that span multiple dimensions, a prioritized concern list, and explicit callouts of what is already well-designed for scale.\n\n**How to get good results:**\nBe specific about the scope boundary -- name the service, module, or feature explicitly and say what is out of scope. Choose the dimensions relevant to your actual growth pressures; the workflow will not add dimensions you did not select. If you know a specific growth target (e.g. \"we expect 50x user growth in 18 months\"), mention it.",
   "examples": [

package/workflows/bug-investigation.agentic.v2.json

@@ -14,6 +14,7 @@
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
   },
+  "metricsProfile": "research",
   "preconditions": [
     "User has a specific bug report, failing test, or unexpected behavior to investigate.",
     "Agent has codebase access and can run tests, commands, or other deterministic evidence-gathering steps.",

package/workflows/classify-task-workflow.json

@@ -2,6 +2,7 @@
   "id": "classify-task-workflow",
   "name": "Classify Task",
   "version": "0.1.0",
+  "metricsProfile": "none",
   "description": "Classifies a software task from the session goal into structured output variables used by coordinator scripts to decide which pipeline phases to run.",
   "about": "## Classify Task Workflow\n\nThis is a fast, single-step classification utility. It reads the session goal and outputs structured variables that coordinator scripts use to decide which pipeline phases to run.\n\n### What it does\n\nGiven a task description, the agent classifies the work along seven dimensions and recommends an ordered pipeline of workflow IDs to execute.\n\n### When to use it\n\nUse this workflow at the start of a coordinator pipeline when you need to decide which downstream workflows to run. It is intentionally fast and cheap -- one LLM step, no subagents, no codebase reads.\n\n### What it produces\n\nA structured classification block in the step notes containing all seven output variables:\n- `taskComplexity` -- Small / Medium / Large\n- `riskLevel` -- Low / Medium / High\n- `hasUI` -- true / false\n- `touchesArchitecture` -- true / false\n- `taskType` -- feature / bug-fix / refactor / investigation / docs / chore\n- `affectedDomains` -- array of likely codebase areas\n- `recommendedPipeline` -- ordered array of workflow IDs\n\n### How to get good results\n\nProvide a specific, concrete task description as the session goal. The more specific the goal, the more accurate the classification. When the goal is ambiguous, the workflow defaults to conservative (higher complexity, more pipeline phases).",
   "examples": [

package/workflows/coding-task-workflow-agentic.json

@@ -14,6 +14,7 @@
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
   },
+  "metricsProfile": "coding",
   "assessments": [
     {
       "id": "design-soundness-gate",

package/workflows/cross-platform-code-conversion.v2.json

@@ -2,6 +2,7 @@
   "id": "cross-platform-code-conversion",
   "name": "Cross-Platform Code Conversion",
   "version": "0.1.0",
+  "metricsProfile": "coding",
   "description": "Use this to convert code from one platform to another (e.g. Android to iOS, iOS to Web). Triages files by difficulty, parallelizes easy translations, and handles platform-specific design decisions.",
   "about": "## Cross-Platform Code Conversion Workflow\n\nThis workflow guides an AI agent through converting code from one platform to another - for example, Android (Kotlin) to iOS (Swift), iOS to Web (TypeScript/React), or any similar migration. It handles everything from scoping and analysis through idiomatic conversion, build verification, and final handoff.\n\n### What it does\n\nThe workflow starts by scoping the migration and classifying its complexity (Small, Medium, or Large) and adaptation depth (low, moderate, or high). It then analyzes the source architecture to understand patterns, dependencies, concurrency models, and semantic contracts. Files are triaged into three buckets: mechanical translations delegated to subagents in parallel (Bucket A), library substitutions (Bucket B), and platform-specific code needing design decisions (Bucket C). For high-adaptation migrations, the workflow runs a full design generation phase to choose an idiomatic target-platform architecture before any code is written. Implementation proceeds batch by batch, with drift detection after each batch to catch files that turn out harder than classified. A final build-and-integration loop verifies the full converted codebase before handoff.\n\n### When to use it\n\nUse this workflow when migrating a module, feature, or full component from one platform to another. It is especially valuable when:\n- The source and target platforms have meaningfully different idioms (e.g., Kotlin coroutines vs Swift async/await, Hilt vs Swinject)\n- You want parallel delegation of mechanical work while keeping design-sensitive boundaries with the main agent\n- Semantic contracts (lifecycle, threading, cancellation, error handling) must be preserved across the migration\n- The target repo has existing architectural patterns the migrated code must fit into\n\nFor very small, straightforward file-by-file translations, the workflow includes a fast path that skips planning and triage.\n\n### What it produces\n\n- A triage matrix classifying every file into a conversion bucket\n- A semantic contract inventory for non-trivial migration boundaries\n- A target integration analysis mapping boundaries to their destination repo seams\n- Converted source files in the target platform's idioms\n- A passing build or typecheck on the full converted output\n- A handoff summary covering adaptation decisions, known gaps, and items needing manual review\n\n### How to get good results\n\n- Specify the exact scope of the migration - which files, modules, or features to convert\n- If the target repo is not in the same workspace, point the agent to it explicitly or configure the source-to-target path mapping\n- Review the triage and semantic contract inventory steps before conversion begins, especially for high-adaptation migrations\n- Flag any invariants that must survive the migration (API contracts, behavioral guarantees, threading assumptions)",
   "examples": [
@@ -78,7 +79,7 @@
     {
       "id": "phase-1-understand-source",
       "title": "Phase 1: Understand Source Code",
-      "prompt": "Read and analyze the source code through a conversion lens \u2014 what will be easy to convert, what will be hard, and why.\n\nMap out:\n- Architecture and module structure\n- Key patterns used (MVI, MVVM, dependency injection, etc.)\n- External dependencies and what they do\n- Entry points and public API surface\n- Platform coupling depth: is the code cleanly layered or is platform-specific code smeared throughout? This directly determines how much falls into easy vs. hard buckets.\n- Concurrency model: Coroutines, Combine, RxJS, async/await? This is often the single hardest mapping decision.\n- DI approach: Dagger/Hilt, Swinject, Koin? DI frameworks rarely map 1:1.\n- Test coverage shape: unit tests on business logic (convert easily), UI tests (likely rewrite), integration tests (depends on infra).\n- Shared code boundaries: is there already a shared/common module that might not need conversion at all?\n- Non-trivial migration boundaries: public APIs, externally consumed module boundaries, and lifecycle/state/concurrency/resource boundaries that callers depend on.\n- Caller-visible guarantees for those boundaries. Examples include lifecycle/ownership, laziness vs eagerness, shared vs per-consumer behavior, cancellation/disposal, ordering/replay/buffering, failure behavior, threading/scheduling, or consistency/transaction guarantees.\n- Adaptation depth: classify whether the migration is `low`, `moderate`, or `high` adaptation based on architectural mismatch, missing target-side equivalents, lifecycle/state/concurrency mismatch, and the amount of adapter or redesign work needed.\n\nIdentify which files define or materially affect those boundaries and which of them will require target-repo integration analysis.\n\nCapture:\n- `sourceArchitecture`\n- `dependencies`\n- `publicApiSurface`\n- `platformCouplingAssessment`\n- `concurrencyModel`\n- `testCoverageShape`\n- `semanticBoundaryCandidates`\n- `boundaryCriticalFiles`\n- `adaptationProfile`",
+      "prompt": "Read and analyze the source code through a conversion lens — what will be easy to convert, what will be hard, and why.\n\nMap out:\n- Architecture and module structure\n- Key patterns used (MVI, MVVM, dependency injection, etc.)\n- External dependencies and what they do\n- Entry points and public API surface\n- Platform coupling depth: is the code cleanly layered or is platform-specific code smeared throughout? This directly determines how much falls into easy vs. hard buckets.\n- Concurrency model: Coroutines, Combine, RxJS, async/await? This is often the single hardest mapping decision.\n- DI approach: Dagger/Hilt, Swinject, Koin? DI frameworks rarely map 1:1.\n- Test coverage shape: unit tests on business logic (convert easily), UI tests (likely rewrite), integration tests (depends on infra).\n- Shared code boundaries: is there already a shared/common module that might not need conversion at all?\n- Non-trivial migration boundaries: public APIs, externally consumed module boundaries, and lifecycle/state/concurrency/resource boundaries that callers depend on.\n- Caller-visible guarantees for those boundaries. Examples include lifecycle/ownership, laziness vs eagerness, shared vs per-consumer behavior, cancellation/disposal, ordering/replay/buffering, failure behavior, threading/scheduling, or consistency/transaction guarantees.\n- Adaptation depth: classify whether the migration is `low`, `moderate`, or `high` adaptation based on architectural mismatch, missing target-side equivalents, lifecycle/state/concurrency mismatch, and the amount of adapter or redesign work needed.\n\nIdentify which files define or materially affect those boundaries and which of them will require target-repo integration analysis.\n\nCapture:\n- `sourceArchitecture`\n- `dependencies`\n- `publicApiSurface`\n- `platformCouplingAssessment`\n- `concurrencyModel`\n- `testCoverageShape`\n- `semanticBoundaryCandidates`\n- `boundaryCriticalFiles`\n- `adaptationProfile`",
       "promptFragments": [
         {
           "id": "phase-1-small-light",
@@ -86,7 +87,7 @@
             "var": "conversionComplexity",
             "equals": "Small"
           },
-          "text": "For Small conversions, keep this lightweight. A quick read of the files in scope is enough \u2014 don't map the entire architecture. Focus on identifying any platform-specific code that would prevent a straight translation."
+          "text": "For Small conversions, keep this lightweight. A quick read of the files in scope is enough — don't map the entire architecture. Focus on identifying any platform-specific code that would prevent a straight translation."
         }
       ],
       "requireConfirmation": {
@@ -109,7 +110,7 @@
           }
         ]
       },
-      "prompt": "For Small conversions, skip triage and planning \u2014 just convert.\n\n- Translate the files to the target platform idiomatically\n- Follow target platform naming and structure conventions\n- Map any dependencies to target equivalents\n- Convert tests if they exist\n- Run build or typecheck to verify\n\nIf something turns out harder than expected (deep platform coupling, no clean dependency equivalent, or meaningful architectural mismatch), update `conversionComplexity` to `Medium`, update `adaptationProfile` to `moderate` or `high` based on the newly discovered mismatch, and stop. The full triage and planning pipeline will activate for the remaining work.\n\nCapture:\n- `filesConverted`\n- `buildPassed`\n- `conversionComplexity`\n- `adaptationProfile`",
+      "prompt": "For Small conversions, skip triage and planning — just convert.\n\n- Translate the files to the target platform idiomatically\n- Follow target platform naming and structure conventions\n- Map any dependencies to target equivalents\n- Convert tests if they exist\n- Run build or typecheck to verify\n\nIf something turns out harder than expected (deep platform coupling, no clean dependency equivalent, or meaningful architectural mismatch), update `conversionComplexity` to `Medium`, update `adaptationProfile` to `moderate` or `high` based on the newly discovered mismatch, and stop. The full triage and planning pipeline will activate for the remaining work.\n\nCapture:\n- `filesConverted`\n- `buildPassed`\n- `conversionComplexity`\n- `adaptationProfile`",
       "requireConfirmation": false
     },
     {
@@ -127,7 +128,7 @@
           }
         ]
       },
-      "prompt": "Classify every file or module in scope into one of three buckets:\n\n**Bucket A \u2014 Literal translation**: Platform-agnostic business logic, data models, utilities, pure functions. These use no platform-specific APIs or libraries. Conversion is mechanical: translate the language syntax, follow target naming conventions, done. These will be delegated to subagents.\n\n**Bucket B \u2014 Library substitution**: Code that uses platform-specific libraries (networking, persistence, serialization, DI) but follows standard patterns. These need dependency mapping but the structure stays the same.\n\n**Bucket C \u2014 Platform-specific**: Code deeply tied to the platform (UI layer, lifecycle management, concurrency/threading, navigation, platform APIs). These need design decisions about target-platform idioms.\n\nFor each file or module, list:\n- File/module name\n- Bucket (A, B, or C)\n- One-line reason for classification\n- Dependencies it has on other files in scope (so we know conversion order)\n- Whether it is `boundaryCritical` for a non-trivial migration boundary\n- Which semantic boundaries it affects from `semanticBoundaryCandidates`\n- Whether it will require target-repo integration analysis\n\nBoundary-critical files must not be treated as blind mechanical translation just because the syntax looks simple. If a file materially affects a semantic boundary or destination-repo seam, keep it with main-agent review.\n\nSort the work items within each bucket by dependency order (convert dependencies first).\n\nGroup Bucket A files into parallel batches of 3-5 files each. Each batch should contain files with no cross-dependencies so subagents can work independently.\n\nGroup Bucket B and C files into sequential batches by dependency order.\n\nEach batch should have: `name` (short label), `bucket` (A, B, or C), and `files` (list of file paths).\n\nCapture:\n- `bucketABatches` (parallel batches for subagent delegation)\n- `bucketBCBatches` (sequential batches for main agent)\n- `bucketACounts`\n- `bucketBCounts`\n- `bucketCCounts`\n- `boundaryCriticalItems`",
+      "prompt": "Classify every file or module in scope into one of three buckets:\n\n**Bucket A — Literal translation**: Platform-agnostic business logic, data models, utilities, pure functions. These use no platform-specific APIs or libraries. Conversion is mechanical: translate the language syntax, follow target naming conventions, done. These will be delegated to subagents.\n\n**Bucket B — Library substitution**: Code that uses platform-specific libraries (networking, persistence, serialization, DI) but follows standard patterns. These need dependency mapping but the structure stays the same.\n\n**Bucket C — Platform-specific**: Code deeply tied to the platform (UI layer, lifecycle management, concurrency/threading, navigation, platform APIs). These need design decisions about target-platform idioms.\n\nFor each file or module, list:\n- File/module name\n- Bucket (A, B, or C)\n- One-line reason for classification\n- Dependencies it has on other files in scope (so we know conversion order)\n- Whether it is `boundaryCritical` for a non-trivial migration boundary\n- Which semantic boundaries it affects from `semanticBoundaryCandidates`\n- Whether it will require target-repo integration analysis\n\nBoundary-critical files must not be treated as blind mechanical translation just because the syntax looks simple. If a file materially affects a semantic boundary or destination-repo seam, keep it with main-agent review.\n\nSort the work items within each bucket by dependency order (convert dependencies first).\n\nGroup Bucket A files into parallel batches of 3-5 files each. Each batch should contain files with no cross-dependencies so subagents can work independently.\n\nGroup Bucket B and C files into sequential batches by dependency order.\n\nEach batch should have: `name` (short label), `bucket` (A, B, or C), and `files` (list of file paths).\n\nCapture:\n- `bucketABatches` (parallel batches for subagent delegation)\n- `bucketBCBatches` (sequential batches for main agent)\n- `bucketACounts`\n- `bucketBCounts`\n- `bucketCCounts`\n- `boundaryCriticalItems`",
       "requireConfirmation": true
     },
     {
@@ -274,7 +275,7 @@
             "var": "conversionComplexity",
             "equals": "Medium"
           },
-          "text": "For Medium conversions, focus the plan on the items that actually need design decisions. Don't exhaustively map every dimension \u2014 only the ones relevant to the files in scope."
+          "text": "For Medium conversions, focus the plan on the items that actually need design decisions. Don't exhaustively map every dimension — only the ones relevant to the files in scope."
         },
         {
           "id": "phase-3f-high-adaptation",
@@ -519,7 +520,7 @@
         {
           "id": "phase-6a-full-build",
           "title": "Full Build and Integration Check",
-          "prompt": "Run a full build or typecheck on the entire converted codebase \u2014 both subagent-converted and main-agent-converted code together.\n\nCheck for:\n- Build/compile errors from cross-batch integration issues\n- Inconsistencies between subagent output and main agent output (naming, patterns)\n- Non-idiomatic patterns that slipped through\n- Missing error handling at module boundaries\n- Threading or concurrency issues across modules\n- Broken public API contracts\n- Contract inventory drift: every row in `semanticContractInventory` is still accounted for, no `uncertain` rows remain, preserved contracts still look preserved, and intentional changes are still justified\n- Target integration drift: code landed in the intended target layer/module, reuse/adaptation decisions still fit the observed target seams, and no unresolved target integration uncertainties remain\n- High-adaptation architecture drift: if `adaptationProfile` is `high`, the final code still matches `architectureAdaptationPlan` and any deviations are explicit and justified\n\nFix each issue. If a fix is a band-aid over a deeper mapping problem, go back and fix the mapping.\n\nCapture:\n- `fullBuildPassed`\n- `integrationIssues`\n- `issuesFixed`",
+          "prompt": "Run a full build or typecheck on the entire converted codebase — both subagent-converted and main-agent-converted code together.\n\nCheck for:\n- Build/compile errors from cross-batch integration issues\n- Inconsistencies between subagent output and main agent output (naming, patterns)\n- Non-idiomatic patterns that slipped through\n- Missing error handling at module boundaries\n- Threading or concurrency issues across modules\n- Broken public API contracts\n- Contract inventory drift: every row in `semanticContractInventory` is still accounted for, no `uncertain` rows remain, preserved contracts still look preserved, and intentional changes are still justified\n- Target integration drift: code landed in the intended target layer/module, reuse/adaptation decisions still fit the observed target seams, and no unresolved target integration uncertainties remain\n- High-adaptation architecture drift: if `adaptationProfile` is `high`, the final code still matches `architectureAdaptationPlan` and any deviations are explicit and justified\n\nFix each issue. If a fix is a band-aid over a deeper mapping problem, go back and fix the mapping.\n\nCapture:\n- `fullBuildPassed`\n- `integrationIssues`\n- `issuesFixed`",
           "requireConfirmation": false
         },
         {
@@ -544,7 +545,7 @@
             "var": "conversionComplexity",
             "equals": "Small"
           },
-          "text": "For Small conversions, keep the summary brief \u2014 just list what was converted, build status, and any issues."
+          "text": "For Small conversions, keep the summary brief — just list what was converted, build status, and any issues."
         },
         {
           "id": "phase-7-full-summary",

package/workflows/document-creation-workflow.json

@@ -2,6 +2,7 @@
   "id": "document-creation-workflow",
   "name": "Document Creation Workflow",
   "version": "1.0.0",
+  "metricsProfile": "coding",
   "description": "Use this to create broad or comprehensive documentation spanning multiple components or systems — project READMEs, complete API docs, user guides, or technical specifications.",
   "about": "## Document Creation Workflow\n\nThis workflow guides you through creating new documentation from scratch -- ranging from a simple project README to a full technical specification spanning multiple systems. It automatically calibrates depth to match the complexity of your request: simple tasks go straight to writing, while complex documentation gets a full analysis-and-planning phase first.\n\n### What it produces\n\nA complete, saved documentation file ready for use. Depending on complexity, it may also include a quality review pass covering accuracy, completeness, audience fit, usability, and style consistency.\n\n### When to use it\n\n- You need to create a **new** document (not update an existing one -- see the Documentation Update workflow for that).\n- The document spans one or more systems, components, or audiences.\n- Examples: project READMEs, API reference docs, user guides, onboarding docs, technical specifications, architecture overviews.\n\n### When NOT to use it\n\n- You want to update or refresh an existing doc -- use the Documentation Update workflow instead.\n- You need tight scope discipline for a single class or mechanism -- the Scoped Documentation workflow is better suited.\n\n### How to get good results\n\n- Be specific about the document type and intended audience upfront. The workflow probes for these, but the clearer your initial goal, the less back-and-forth.\n- If your project has existing documentation or style conventions, mention them -- the workflow will follow them.\n- For complex documentation, the workflow asks a small number of targeted questions it cannot answer from the codebase. Answer these concisely to keep momentum.",
   "examples": [
@@ -148,4 +149,4 @@
       "requireConfirmation": false
     }
   ]
-}
+}

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