@exaudeus/workrail 3.14.0 → 3.16.0

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

@@ -2,7 +2,14 @@
   "id": "coding-task-workflow-agentic",
   "name": "Agentic Task Dev Workflow (Lean • Notes-First • WorkRail Executor)",
   "version": "1.0.0",
-  "description": "The user guides the agent through understanding the task, selecting an approach, planning in slices, implementing incrementally, and verifying the result through explicit review and validation checkpoints.",
+  "description": "Use this to implement a software feature or task. Follows a plan-then-execute approach with architecture decisions, invariant tracking, and final verification.",
+  "about": "## Agentic Coding Task Workflow\n\nThis workflow structures the full lifecycle of a software implementation task: from understanding and classifying the work, through architecture decisions and incremental implementation, to final verification and handoff.\n\n### What it does\n\nThe workflow guides an AI agent through a disciplined plan-then-execute process. It begins by analyzing the task to determine complexity, risk, and the right level of rigor (QUICK, STANDARD, or THOROUGH). For non-trivial tasks, it then gathers codebase context, surfaces invariants and non-goals, generates competing design candidates, and selects an approach before writing a single line of code. Implementation proceeds slice by slice, with built-in verification gates after each slice. A final integration verification pass confirms acceptance criteria are met before handoff.\n\n### When to use it\n\nUse this workflow whenever you are implementing a feature, fixing a non-trivial bug, or making an architectural change in a real codebase. It is especially valuable when:\n- The task touches multiple files or systems\n- There is meaningful risk of regressions or invariant violations\n- You want the agent to surface trade-offs and commit to a reasoned design decision rather than guessing\n- You need a resumable, auditable record of what was decided and why\n\nFor quick one-liner fixes or very small changes, the workflow includes a fast path that skips heavyweight planning.\n\n### What it produces\n\n- An `implementation_plan.md` artifact covering the selected approach, vertical slices, test design, and philosophy alignment\n- A `spec.md` for large or high-risk tasks, capturing observable behavior and acceptance criteria\n- Step-level notes in WorkRail that serve as a durable execution log\n- A PR-ready handoff summary with acceptance criteria status, invariant proofs, and follow-up tickets\n\n### How to get good results\n\n- Provide a clear task description and at least partial acceptance criteria before starting\n- If you have coding philosophy or project conventions configured in session rules or Memory MCP, the workflow will apply them automatically as a design lens\n- Let the workflow classify complexity and rigor itself; override only if the classification is clearly wrong\n- For large or high-risk tasks, review the architecture decision step before implementation begins",
+  "examples": [
+    "Implement JWT refresh token rotation in the auth service",
+    "Fix the race condition in the cache invalidation path when concurrent writes occur",
+    "Refactor the payment flow to use a Result type instead of throwing exceptions",
+    "Add pagination support to the messaging inbox API endpoint"
+  ],
   "recommendedPreferences": {
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
@@ -23,7 +30,8 @@
     "PHILOSOPHY LENS: apply the user's coding philosophy (from active session rules) as the evaluation lens. Flag violations by principle name, not as generic feedback. If principles conflict, surface the tension explicitly instead of silently choosing.",
     "VALIDATION: prefer static/compile-time safety over runtime checks. Use build, type-checking, and tests as the primary proof of correctness — in that order of reliability.",
     "DRIFT HANDLING: when reality diverges from the plan, update the plan artifact and re-audit deliberately rather than accumulating undocumented drift.",
-    "NEVER COMMIT MARKDOWN FILES UNLESS USER EXPLICITLY ASKS."
+    "NEVER COMMIT MARKDOWN FILES UNLESS USER EXPLICITLY ASKS.",
+    "SLICE DISCIPLINE: Phase 6 is a loop -- implement ONE slice per iteration. Do not implement multiple slices at once. The verification loop exists to catch drift per slice, not retroactively."
   ],
   "references": [
     {
@@ -58,8 +66,14 @@
       "prompt": "Understand this before you touch anything.\n\nMake sure the expected behavior is clear enough to proceed. If it really isn't, ask me only what you can't answer yourself. Don't ask me things you can find with tools.\n\nThen dig through the code. Figure out:\n- where this starts and what the call chain looks like\n- which files, modules, and functions matter\n- what patterns this should follow\n- how this repo verifies similar work\n- what the real risks, invariants, and non-goals are\n\nFigure out what philosophy to use while doing the work. Prefer, in order: Memory MCP (`mcp_memory_conventions`, `mcp_memory_prefer`, `mcp_memory_recall`), active session/Firebender rules, repo patterns, then me only if those still conflict or aren't enough.\n\nRecord where that philosophy lives, not a summary. If the stated rules and repo patterns disagree, capture the conflict.\n\nOnce you actually understand the task, classify it:\n- `taskComplexity`: Small / Medium / Large\n- `riskLevel`: Low / Medium / High\n- `rigorMode`: QUICK / STANDARD / THOROUGH\n- `automationLevel`: High / Medium / Low\n- `prStrategy`: SinglePR / MultiPR\n\nUse this guidance:\n- QUICK: small, low-risk, clear path, little ambiguity\n- STANDARD: medium scope or moderate risk\n- THOROUGH: large scope, architectural uncertainty, or high-risk change\n\nThen force a context-clarity check. Score each from 0-2 and give one sentence of evidence for each score:\n- `entryPointClarity`: 0 = clear entry point and call chain, 1 = partial chain with gaps, 2 = still unclear where behavior starts or flows\n- `boundaryClarity`: 0 = clear boundary, 1 = likely boundary but some uncertainty, 2 = patch-vs-boundary decision still unclear\n- `invariantClarity`: 0 = important invariants are explicit, 1 = some are inferred or uncertain, 2 = important invariants are still unclear\n- `verificationClarity`: 0 = clear deterministic verification path, 1 = partial verification path, 2 = verification is still weak or unclear\n\nUse the rubric, not vibes:\n- QUICK: do not run the deeper context batch; if the rubric says you're missing too much context, your classification is probably wrong and you should reclassify upward before moving on\n- STANDARD: run the deeper context batch if the total score is 3 or more, or if `boundaryClarity`, `invariantClarity`, or `verificationClarity` is 2\n- THOROUGH: always run the deeper context batch\n\nThe deeper context batch is:\n- `routine-context-gathering` with `focus=COMPLETENESS`\n- `routine-context-gathering` with `focus=DEPTH`\n\nAfter the batch, synthesize what changed, what stayed the same, and what is still unknown. If the extra context changes the classification, update it before you leave this step.\n\nCapture:\n- `taskComplexity`\n- `riskLevel`\n- `rigorMode`\n- `automationLevel`\n- `prStrategy`\n- `contextSummary`\n- `candidateFiles`\n- `invariants`\n- `nonGoals`\n- `openQuestions` (only real human-decision questions)\n- `philosophySources`\n- `philosophyConflicts`",
       "requireConfirmation": {
         "or": [
-          { "var": "taskComplexity", "equals": "Large" },
-          { "var": "riskLevel", "equals": "High" }
+          {
+            "var": "taskComplexity",
+            "equals": "Large"
+          },
+          {
+            "var": "riskLevel",
+            "equals": "High"
+          }
         ]
       }
     },
@@ -68,8 +82,14 @@
       "title": "Phase 1a: State Hypothesis",
       "runCondition": {
         "and": [
-          { "var": "taskComplexity", "not_equals": "Small" },
-          { "var": "rigorMode", "not_equals": "QUICK" }
+          {
+            "var": "taskComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "rigorMode",
+            "not_equals": "QUICK"
+          }
         ]
       },
       "prompt": "Before you do design work, tell me your current best guess.\n\nKeep it short:\n1. what you think the right approach is\n2. what worries you about it\n3. what would most likely make it wrong\n\nCapture:\n- `initialHypothesis`",
@@ -80,8 +100,14 @@
       "title": "Phase 1b: Lightweight Design (QUICK)",
       "runCondition": {
         "and": [
-          { "var": "taskComplexity", "not_equals": "Small" },
-          { "var": "rigorMode", "equals": "QUICK" }
+          {
+            "var": "taskComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "rigorMode",
+            "equals": "QUICK"
+          }
         ]
       },
       "prompt": "Generate a lightweight design inline. QUICK rigor means the path is clear and risk is low.\n\nProduce two mandatory candidates:\n1. The simplest possible change that satisfies acceptance criteria\n2. Follow the existing repo pattern for this kind of change\n\nFor each candidate:\n- One-sentence summary\n- Which tensions it resolves and which it accepts\n- How it relates to existing repo patterns (follows / adapts / departs)\n- Failure mode to watch\n- Philosophy fit (name specific principles)\n\nCompare and recommend. If both converge on the same approach, say so honestly.\n\nWrite the output to `design-candidates.md` with this structure:\n- Problem Understanding (core tensions, what makes it hard)\n- Philosophy Constraints (which principles matter for this problem)\n- Candidates (each with: summary, tensions resolved/accepted, failure mode, philosophy fit)\n- Comparison and Recommendation\n- Open Questions (if any remain)",
@@ -92,8 +118,14 @@
       "title": "Phase 1b: Design Generation (Injected Routine — Tension-Driven Design)",
       "runCondition": {
         "and": [
-          { "var": "taskComplexity", "not_equals": "Small" },
-          { "var": "rigorMode", "not_equals": "QUICK" }
+          {
+            "var": "taskComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "rigorMode",
+            "not_equals": "QUICK"
+          }
         ]
       },
       "templateCall": {
@@ -114,20 +146,38 @@
       "promptFragments": [
         {
           "id": "phase-1c-challenge-standard",
-          "when": { "var": "rigorMode", "in": ["STANDARD", "THOROUGH"] },
-              "text": "Run `routine-hypothesis-challenge` on the leading option's failure modes before you decide."
+          "when": {
+            "var": "rigorMode",
+            "in": [
+              "STANDARD",
+              "THOROUGH"
+            ]
+          },
+          "text": "Run `routine-hypothesis-challenge` on the leading option's failure modes before you decide."
         },
         {
           "id": "phase-1c-challenge-thorough",
-          "when": { "var": "rigorMode", "equals": "THOROUGH" },
-              "text": "Also run `routine-execution-simulation` on the three most likely failure paths before you decide."
+          "when": {
+            "var": "rigorMode",
+            "equals": "THOROUGH"
+          },
+          "text": "Also run `routine-execution-simulation` on the three most likely failure paths before you decide."
         }
       ],
       "requireConfirmation": {
         "or": [
-          { "var": "automationLevel", "equals": "Low" },
-          { "var": "taskComplexity", "equals": "Large" },
-          { "var": "riskLevel", "equals": "High" }
+          {
+            "var": "automationLevel",
+            "equals": "Low"
+          },
+          {
+            "var": "taskComplexity",
+            "equals": "Large"
+          },
+          {
+            "var": "riskLevel",
+            "equals": "High"
+          }
         ]
       }
     },
@@ -173,7 +223,10 @@
           "promptFragments": [
             {
               "id": "phase-2c-challenge-thorough",
-              "when": { "var": "rigorMode", "equals": "THOROUGH" },
+              "when": {
+                "var": "rigorMode",
+                "equals": "THOROUGH"
+              },
               "text": "If the review surfaced materially non-empty or surprising findings, run `routine-hypothesis-challenge` on the most serious finding and `routine-execution-simulation` on the most dangerous failure mode before you finalize the revised design."
             }
           ],
@@ -197,7 +250,7 @@
         "var": "taskComplexity",
         "not_equals": "Small"
       },
-      "prompt": "Turn the decision into a plan someone else could execute without guessing.\n\nUpdate `implementation_plan.md`.\n\nIt should cover:\n1. Problem statement\n2. Acceptance criteria (mirror `spec.md` if it exists; `spec.md` owns observable behavior)\n3. Non-goals\n4. Philosophy-driven constraints\n5. Invariants\n6. Selected approach + rationale + runner-up\n7. Vertical slices\n8. Work packages only if they actually help\n9. Test design\n10. Risk register\n11. PR packaging strategy\n12. Philosophy alignment per slice:\n   - [principle] -> [satisfied / tension / violated + 1-line why]\n\nCapture:\n- `implementationPlan`\n- `slices`\n- `testDesign`\n- `estimatedPRCount`\n- `followUpTickets` (initialize if needed)\n- `unresolvedUnknownCount` — count of open issues that would materially affect implementation quality\n- `planConfidenceBand` — Low / Medium / High",
+      "prompt": "Turn the decision into a plan someone else could execute without guessing.\n\nUpdate `implementation_plan.md`.\n\nIt should cover:\n1. Problem statement\n2. Acceptance criteria (mirror `spec.md` if it exists; `spec.md` owns observable behavior)\n3. Non-goals\n4. Philosophy-driven constraints\n5. Invariants\n6. Selected approach + rationale + runner-up\n7. Vertical slices\n8. Work packages only if they actually help\n9. Test design\n10. Risk register\n11. PR packaging strategy\n12. Philosophy alignment per slice:\n   - [principle] -> [satisfied / tension / violated + 1-line why]\n\nCapture:\n- `implementationPlan`\n- `slices`\n- `testDesign`\n- `estimatedPRCount`\n- `followUpTickets` (initialize if needed)\n- `unresolvedUnknownCount` — count of open issues that would materially affect implementation quality\n- `planConfidenceBand` — Low / Medium / High\n\nThe plan is the deliverable for this step. Do not implement anything -- not a \"quick win\", not a file read that bleeds into edits, nothing. Execution begins in Phase 6, one slice at a time. If you find yourself writing code or editing source files right now, stop immediately.",
       "requireConfirmation": false
     },
     {
@@ -205,11 +258,20 @@
       "title": "Phase 3b: Spec (Observable Behavior)",
       "runCondition": {
         "and": [
-          { "var": "taskComplexity", "not_equals": "Small" },
+          {
+            "var": "taskComplexity",
+            "not_equals": "Small"
+          },
           {
             "or": [
-              { "var": "taskComplexity", "equals": "Large" },
-              { "var": "riskLevel", "equals": "High" }
+              {
+                "var": "taskComplexity",
+                "equals": "Large"
+              },
+              {
+                "var": "riskLevel",
+                "equals": "High"
+              }
             ]
           }
         ]
@@ -223,8 +285,14 @@
       "title": "Phase 4: Plan Audit (Review, Fix, Decide)",
       "runCondition": {
         "and": [
-          { "var": "taskComplexity", "not_equals": "Small" },
-          { "var": "rigorMode", "not_equals": "QUICK" }
+          {
+            "var": "taskComplexity",
+            "not_equals": "Small"
+          },
+          {
+            "var": "rigorMode",
+            "not_equals": "QUICK"
+          }
         ]
       },
       "loop": {
@@ -244,17 +312,26 @@
           "promptFragments": [
             {
               "id": "phase-4a-delegation-quick",
-              "when": { "var": "rigorMode", "equals": "QUICK" },
+              "when": {
+                "var": "rigorMode",
+                "equals": "QUICK"
+              },
               "text": "Do this yourself."
             },
             {
               "id": "phase-4a-delegation-standard",
-              "when": { "var": "rigorMode", "equals": "STANDARD" },
+              "when": {
+                "var": "rigorMode",
+                "equals": "STANDARD"
+              },
               "text": "Run `routine-plan-analysis`, `routine-hypothesis-challenge`, and `routine-philosophy-alignment` in parallel before you decide whether the plan is good enough."
             },
             {
               "id": "phase-4a-delegation-thorough",
-              "when": { "var": "rigorMode", "equals": "THOROUGH" },
+              "when": {
+                "var": "rigorMode",
+                "equals": "THOROUGH"
+              },
               "text": "Run `routine-plan-analysis`, `routine-hypothesis-challenge`, `routine-execution-simulation`, and `routine-philosophy-alignment` in parallel before you decide whether the plan is good enough."
             }
           ],
@@ -300,7 +377,7 @@
         {
           "id": "phase-6a-implement-slice",
           "title": "Implement Slice",
-          "prompt": "Implement only the current slice: `{{currentSlice.name}}`.\n\nBefore you code, check whether the plan is still valid:\n- if the pivot triggers fired or the assumptions went stale, stop and go back to planning\n- if the target files or symbols no longer match, stop and re-plan\n\nStay in this slice.\n- don't do the rest of the plan early\n- only pull forward later-slice work if you absolutely need it to make this slice compile or integrate, and count that as `unexpectedScopeChange = true`\n- keep the changes incremental\n- run tests and build to prove the slice works\n\nTrack whether this slice required:\n- a new special-case (`specialCaseIntroduced`)\n- an unplanned abstraction (`unplannedAbstractionIntroduced`)\n- unexpected file changes outside planned scope (`unexpectedScopeChange`)\n\nSet `verifyNeeded` to true if ANY of:\n- `sliceIndex` is odd (verify every 2 slices)\n- `prStrategy = MultiPR`\n- `specialCaseIntroduced = true`\n- `unplannedAbstractionIntroduced = true`\n- `unexpectedScopeChange = true`\n- tests or build failed\n\nCapture:\n- `specialCaseIntroduced`\n- `unplannedAbstractionIntroduced`\n- `unexpectedScopeChange`\n- `verifyNeeded`",
+          "prompt": "Implement the current slice: `{{currentSlice.name}}`.\n\nBefore writing a single line of code, declare your scope:\n- List the exact files and symbols this slice touches\n- Confirm none of them belong to a later slice\n- If you have already edited files from this or any other slice in a previous step, stop and report it\n\nHard scope rule: you may only modify what is described in `{{currentSlice.name}}`. Anything outside that boundary is out of scope for this iteration -- not \"do it early\", not \"while I'm here\". If you discover you need to touch something outside this slice to make it compile or integrate, set `unexpectedScopeChange = true` and do the minimum necessary to stay green, then stop.\n\nImplement incrementally. Run tests and build to prove the slice works before advancing.\n\nTrack:\n- `specialCaseIntroduced` -- did this slice require a new special-case?\n- `unplannedAbstractionIntroduced` -- did this slice introduce an abstraction not in the plan?\n- `unexpectedScopeChange` -- did this slice touch files outside its planned scope?\n\nSet `verifyNeeded` to true if ANY of:\n- `sliceIndex` is odd (verify every 2 slices)\n- `prStrategy = MultiPR`\n- `specialCaseIntroduced = true`\n- `unplannedAbstractionIntroduced = true`\n- `unexpectedScopeChange = true`\n- tests or build failed\n\nCapture: `specialCaseIntroduced`, `unplannedAbstractionIntroduced`, `unexpectedScopeChange`, `verifyNeeded`",
           "requireConfirmation": false
         },
         {
@@ -314,29 +391,47 @@
           "promptFragments": [
             {
               "id": "phase-6b-delegation-quick",
-              "when": { "var": "rigorMode", "equals": "QUICK" },
+              "when": {
+                "var": "rigorMode",
+                "equals": "QUICK"
+              },
               "text": "Do the verification yourself."
             },
             {
               "id": "phase-6b-delegation-standard",
-              "when": { "var": "rigorMode", "equals": "STANDARD" },
+              "when": {
+                "var": "rigorMode",
+                "equals": "STANDARD"
+              },
               "text": "If any slice-risk trigger fired, run `routine-hypothesis-challenge` and `routine-philosophy-alignment` before you decide this slice is done."
             },
             {
               "id": "phase-6b-delegation-thorough",
-              "when": { "var": "rigorMode", "equals": "THOROUGH" },
+              "when": {
+                "var": "rigorMode",
+                "equals": "THOROUGH"
+              },
               "text": "If any slice-risk trigger fired, also run `routine-execution-simulation` before you decide this slice is done."
             },
             {
               "id": "phase-6b-multi-pr",
-              "when": { "var": "prStrategy", "equals": "MultiPR" },
+              "when": {
+                "var": "prStrategy",
+                "equals": "MultiPR"
+              },
               "text": "If this slice is verified and ready, stop here and package it for review before you move to the next slice."
             }
           ],
           "requireConfirmation": {
             "or": [
-              { "var": "verificationFailed", "equals": true },
-              { "var": "prStrategy", "equals": "MultiPR" }
+              {
+                "var": "verificationFailed",
+                "equals": true
+              },
+              {
+                "var": "prStrategy",
+                "equals": "MultiPR"
+              }
             ]
           }
         }

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

@@ -1,8 +1,15 @@
 {
   "id": "coding-task-workflow-agentic",
-  "name": "Agentic Task Dev Workflow (v2 • Notes-First • WorkRail Executor)",
+  "name": "Agentic Task Dev Workflow (v2 \u2022 Notes-First \u2022 WorkRail Executor)",
   "version": "2.0.0",
-  "description": "A v2-first coding workflow that keeps the high-quality architecture and audit loops from the legacy task workflow while removing CONTEXT.md ceremony, Builder ownership, and unnecessary phase serialization. Uses notesMarkdown as the durable default, keeps implementation_plan.md as the human planning artifact, and applies the user's coding philosophy as the primary evaluation lens.",
+  "description": "Use this to implement a software feature or task. Follows a plan-then-execute approach with architecture decisions, invariant tracking, and final verification.",
+  "about": "## Agentic Coding Task Workflow\n\nThis workflow structures the full lifecycle of a software implementation task: from understanding and classifying the work, through architecture decisions and incremental implementation, to final verification and handoff.\n\n### What it does\n\nThe workflow guides an AI agent through a disciplined plan-then-execute process. It begins by analyzing the task to determine complexity, risk, and the right level of rigor (QUICK, STANDARD, or THOROUGH). For non-trivial tasks, it then gathers codebase context, surfaces invariants and non-goals, generates competing design candidates, and selects an approach before writing a single line of code. Implementation proceeds slice by slice, with built-in verification gates after each slice. A final integration verification pass confirms acceptance criteria are met before handoff.\n\n### When to use it\n\nUse this workflow whenever you are implementing a feature, fixing a non-trivial bug, or making an architectural change in a real codebase. It is especially valuable when:\n- The task touches multiple files or systems\n- There is meaningful risk of regressions or invariant violations\n- You want the agent to surface trade-offs and commit to a reasoned design decision rather than guessing\n- You need a resumable, auditable record of what was decided and why\n\nFor quick one-liner fixes or very small changes, the workflow includes a fast path that skips heavyweight planning.\n\n### What it produces\n\n- An `implementation_plan.md` artifact covering the selected approach, vertical slices, test design, and philosophy alignment\n- A `spec.md` for large or high-risk tasks, capturing observable behavior and acceptance criteria\n- Step-level notes in WorkRail that serve as a durable execution log\n- A PR-ready handoff summary with acceptance criteria status, invariant proofs, and follow-up tickets\n\n### How to get good results\n\n- Provide a clear task description and at least partial acceptance criteria before starting\n- If you have coding philosophy or project conventions configured in session rules or Memory MCP, the workflow will apply them automatically as a design lens\n- Let the workflow classify complexity and rigor itself; override only if the classification is clearly wrong\n- For large or high-risk tasks, review the architecture decision step before implementation begins",
+  "examples": [
+    "Implement JWT refresh token rotation in the auth service",
+    "Fix the race condition in the cache invalidation path when concurrent writes occur",
+    "Refactor the payment flow to use a Result type instead of throwing exceptions",
+    "Add pagination support to the messaging inbox API endpoint"
+  ],
   "recommendedPreferences": {
     "recommendedAutonomy": "guided",
     "recommendedRiskPolicy": "conservative"
@@ -40,8 +47,8 @@
   "steps": [
     {
       "id": "phase-0-triage-and-mode",
-      "title": "Phase 0: Triage (Complexity • Risk • PR Strategy)",
-      "prompt": "Analyze the task and choose the right rigor.\n\nClassify:\n- `taskComplexity`: Small / Medium / Large\n- `riskLevel`: Low / Medium / High\n- `rigorMode`: QUICK / STANDARD / THOROUGH\n- `automationLevel`: High / Medium / Low\n- `prStrategy`: SinglePR / MultiPR\n- `maxParallelism`: 0 / 3 / 4\n\nDecision guidance:\n- QUICK: small, low-risk, clear path, little ambiguity\n- STANDARD: medium scope or moderate risk\n- THOROUGH: large scope, architectural uncertainty, or high-risk change\n\nParallelism guidance:\n- QUICK: no delegation by default\n- STANDARD: few delegation moments, but allow multiple parallel executors at each moment\n- THOROUGH: same pattern, but with one extra delegation moment and broader parallel validation\n\nAlso capture `userRules` from the active session instructions and explicit philosophy. Keep them as a focused list of concrete, actionable rules.\n\nSet these keys in the next `continue_workflow` call's `context` object: `taskComplexity`, `riskLevel`, `rigorMode`, `automationLevel`, `prStrategy`, `maxParallelism`, `userRules`.\n\nAsk the user to confirm only if the rigor or PR strategy materially affects delivery expectations.",
+      "title": "Phase 0: Triage (Complexity \u2022 Risk \u2022 PR Strategy)",
+      "prompt": "Analyze the task and choose the right rigor.\n\nClassify:\n- `taskComplexity`: Small / Medium / Large\n- `riskLevel`: Low / Medium / High\n- `rigorMode`: QUICK / STANDARD / THOROUGH\n- `automationLevel`: High / Medium / Low\n- `prStrategy`: SinglePR / MultiPR\n- `maxParallelism`: 0 / 3 / 4\n\nDecision guidance:\n- QUICK: small, low-risk, clear path, little ambiguity\n- STANDARD: medium scope or moderate risk\n- THOROUGH: large scope, architectural uncertainty, or high-risk change\n\nParallelism guidance:\n- QUICK: no delegation by default\n- STANDARD: few delegation moments, but allow multiple parallel executors at each moment\n- THOROUGH: same pattern, but with one extra delegation moment and broader parallel validation\n\nAlso capture `userRules` from the active session instructions and explicit philosophy. Keep them as a focused list of concrete, actionable rules.\n\nSet these keys in the next `continue_workflow` call's `context` object: `taskComplexity`, `riskLevel`, `rigorMode`, `automationLevel`, `prStrategy`, `maxParallelism`, `userRules`.\n\nAsk the user to confirm only if the rigor or PR strategy materially affects delivery expectations.\n\nAlso set  in the context object: one sentence describing what you are trying to accomplish (e.g. \"implement OAuth refresh token rotation\", \"review PR #47 before merge\"). This populates the session title in the Workspace console immediately.",
       "requireConfirmation": true
     },
     {
@@ -50,8 +57,14 @@
       "prompt": "If critical information is missing, ask only for the minimum required to proceed.\n\nAsk for:\n- acceptance criteria or expected behavior (if absent)\n- non-goals (if unclear)\n- environment or permission constraints (if they materially block progress)\n- pointers to relevant code areas only if codebase search cannot answer it\n\nDo NOT ask questions you can resolve with tools.",
       "requireConfirmation": {
         "or": [
-          { "var": "automationLevel", "equals": "Low" },
-          { "var": "automationLevel", "equals": "Medium" }
+          {
+            "var": "automationLevel",
+            "equals": "Low"
+          },
+          {
+            "var": "automationLevel",
+            "equals": "Medium"
+          }
         ]
       }
     },
@@ -75,24 +88,39 @@
       "prompt": "Reassess the initial triage now that context is real instead of hypothetical.\n\nReview:\n- `contextUnknownCount`\n- number of systems/components actually involved\n- number of critical invariants discovered\n- whether the task now looks broader or riskier than Phase 0 suggested\n\nDo:\n- confirm or adjust `taskComplexity`\n- confirm or adjust `riskLevel`\n- confirm or adjust `rigorMode`\n- confirm or adjust `maxParallelism`\n\nRules:\n- upgrade rigor if the real architecture surface or uncertainty is larger than expected\n- downgrade only if the task is genuinely simpler than it first appeared\n- if you change the mode, explain why using concrete evidence from the context gathering step\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `taskComplexity`\n- `riskLevel`\n- `rigorMode`\n- `maxParallelism`\n- `retriageChanged` (true/false)",
       "requireConfirmation": {
         "or": [
-          { "var": "retriageChanged", "equals": true },
-          { "var": "automationLevel", "equals": "Low" }
+          {
+            "var": "retriageChanged",
+            "equals": true
+          },
+          {
+            "var": "automationLevel",
+            "equals": "Low"
+          }
         ]
       }
     },
     {
       "id": "phase-2-architecture-decision",
-      "title": "Phase 2: Architecture Decision (Generate • Compare • Challenge • Select)",
+      "title": "Phase 2: Architecture Decision (Generate \u2022 Compare \u2022 Challenge \u2022 Select)",
       "runCondition": {
         "var": "taskComplexity",
         "not_equals": "Small"
       },
-      "prompt": "Make the architecture decision in one coherent phase instead of serializing every thinking mode into a separate step.\n\nPart A — Prepare a neutral fact packet:\n- problem statement\n- acceptance criteria\n- non-goals\n- invariants\n- constraints\n- `userRules`\n- relevant files / pattern examples\n- current risks and unknowns\n\nPart B — Generate candidate plans:\n- QUICK: self-generate at least 3 genuinely different approaches\n- STANDARD: if delegation is available, spawn TWO or THREE WorkRail Executors SIMULTANEOUSLY running `routine-plan-generation` with different perspectives (for example simplicity, maintainability, pragmatic)\n- THOROUGH: if delegation is available, spawn THREE or FOUR WorkRail Executors SIMULTANEOUSLY running `routine-plan-generation` with different perspectives (for example simplicity, maintainability, architecture-first, rollback-safe)\n\nPart C — Diversity gate before commitment:\n- assign each candidate plan a short `candidatePlanFamily` label\n- check whether the candidates are materially different in shape, not just wording\n- if all candidates cluster on the same pattern family, generate at least one more plan from a deliberately different perspective before selecting\n- set `candidateDiversityAdequate = true|false`\n\nPart D — Compare candidate plans:\n- invariant fit\n- philosophy alignment (`userRules` as active lens)\n- risk profile\n- implementation shape\n- likely reviewability / PR shape\n\nPart E — Challenge the best one or two:\n- STANDARD: optionally challenge the leading candidate with ONE WorkRail Executor running `routine-hypothesis-challenge`\n- THOROUGH: challenge the top 1-2 candidate plans using ONE or TWO WorkRail Executors running `routine-hypothesis-challenge`\n\nPart F — Decide:\nSet these keys in the next `continue_workflow` call's `context` object:\n- `approaches`\n- `alternativesConsideredCount`\n- `candidatePlanFamilies`\n- `candidateDiversityAdequate`\n- `hasRunnerUp`\n- `selectedApproach`\n- `runnerUpApproach`\n- `architectureRationale`\n- `keyRiskToMonitor`\n- `pivotTriggers`\n- `architectureConfidenceBand`\n\nRules:\n- the main agent owns the final decision\n- subagents generate candidate plans; they do not decide the winner\n- if the challenged leading candidate no longer looks best, switch deliberately rather than defending sunk cost",
+      "prompt": "Make the architecture decision in one coherent phase instead of serializing every thinking mode into a separate step.\n\nPart A \u2014 Prepare a neutral fact packet:\n- problem statement\n- acceptance criteria\n- non-goals\n- invariants\n- constraints\n- `userRules`\n- relevant files / pattern examples\n- current risks and unknowns\n\nPart B \u2014 Generate candidate plans:\n- QUICK: self-generate at least 3 genuinely different approaches\n- STANDARD: if delegation is available, spawn TWO or THREE WorkRail Executors SIMULTANEOUSLY running `routine-plan-generation` with different perspectives (for example simplicity, maintainability, pragmatic)\n- THOROUGH: if delegation is available, spawn THREE or FOUR WorkRail Executors SIMULTANEOUSLY running `routine-plan-generation` with different perspectives (for example simplicity, maintainability, architecture-first, rollback-safe)\n\nPart C \u2014 Diversity gate before commitment:\n- assign each candidate plan a short `candidatePlanFamily` label\n- check whether the candidates are materially different in shape, not just wording\n- if all candidates cluster on the same pattern family, generate at least one more plan from a deliberately different perspective before selecting\n- set `candidateDiversityAdequate = true|false`\n\nPart D \u2014 Compare candidate plans:\n- invariant fit\n- philosophy alignment (`userRules` as active lens)\n- risk profile\n- implementation shape\n- likely reviewability / PR shape\n\nPart E \u2014 Challenge the best one or two:\n- STANDARD: optionally challenge the leading candidate with ONE WorkRail Executor running `routine-hypothesis-challenge`\n- THOROUGH: challenge the top 1-2 candidate plans using ONE or TWO WorkRail Executors running `routine-hypothesis-challenge`\n\nPart F \u2014 Decide:\nSet these keys in the next `continue_workflow` call's `context` object:\n- `approaches`\n- `alternativesConsideredCount`\n- `candidatePlanFamilies`\n- `candidateDiversityAdequate`\n- `hasRunnerUp`\n- `selectedApproach`\n- `runnerUpApproach`\n- `architectureRationale`\n- `keyRiskToMonitor`\n- `pivotTriggers`\n- `architectureConfidenceBand`\n\nRules:\n- the main agent owns the final decision\n- subagents generate candidate plans; they do not decide the winner\n- if the challenged leading candidate no longer looks best, switch deliberately rather than defending sunk cost",
       "requireConfirmation": {
         "or": [
-          { "var": "automationLevel", "equals": "Low" },
-          { "var": "taskComplexity", "equals": "Large" },
-          { "var": "riskLevel", "equals": "High" }
+          {
+            "var": "automationLevel",
+            "equals": "Low"
+          },
+          {
+            "var": "taskComplexity",
+            "equals": "Large"
+          },
+          {
+            "var": "riskLevel",
+            "equals": "High"
+          }
         ]
       }
     },
@@ -103,13 +131,13 @@
         "var": "taskComplexity",
         "not_equals": "Small"
       },
-      "prompt": "Create or update the human-facing implementation artifact: `implementation_plan.md`.\n\nThis phase combines slicing, plan drafting, philosophy alignment, and test design.\n\nThe plan must include:\n1. Problem statement\n2. Acceptance criteria\n3. Non-goals\n4. Applied `userRules` and philosophy-driven constraints\n5. Invariants\n6. Selected approach + rationale + runner-up\n7. Vertical slices\n8. Work packages only when they improve execution or enable safe parallelism\n9. Test design\n10. Risk register\n11. PR packaging strategy\n12. Philosophy alignment per slice:\n   - [principle] → [satisfied / tension / violated + 1-line why]\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `implementationPlan`\n- `slices`\n- `testDesign`\n- `estimatedPRCount`\n- `followUpTickets` (initialize if needed)\n- `unresolvedUnknownCount`\n- `planConfidenceBand`\n\nRules:\n- keep `implementation_plan.md` concrete enough for another engineer to implement without guessing\n- use work packages only when they create real clarity; do not over-fragment work\n- use the user's coding philosophy as the primary planning lens, and name tensions explicitly\n- set `unresolvedUnknownCount` to the number of still-open issues that would materially affect implementation quality\n- set `planConfidenceBand` to Low / Medium / High based on how ready the plan actually is",
+      "prompt": "Create or update the human-facing implementation artifact: `implementation_plan.md`.\n\nThis phase combines slicing, plan drafting, philosophy alignment, and test design.\n\nThe plan must include:\n1. Problem statement\n2. Acceptance criteria\n3. Non-goals\n4. Applied `userRules` and philosophy-driven constraints\n5. Invariants\n6. Selected approach + rationale + runner-up\n7. Vertical slices\n8. Work packages only when they improve execution or enable safe parallelism\n9. Test design\n10. Risk register\n11. PR packaging strategy\n12. Philosophy alignment per slice:\n   - [principle] \u2192 [satisfied / tension / violated + 1-line why]\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `implementationPlan`\n- `slices`\n- `testDesign`\n- `estimatedPRCount`\n- `followUpTickets` (initialize if needed)\n- `unresolvedUnknownCount`\n- `planConfidenceBand`\n\nRules:\n- keep `implementation_plan.md` concrete enough for another engineer to implement without guessing\n- use work packages only when they create real clarity; do not over-fragment work\n- use the user's coding philosophy as the primary planning lens, and name tensions explicitly\n- set `unresolvedUnknownCount` to the number of still-open issues that would materially affect implementation quality\n- set `planConfidenceBand` to Low / Medium / High based on how ready the plan actually is",
       "requireConfirmation": false
     },
     {
       "id": "phase-4-plan-iterations",
       "type": "loop",
-      "title": "Phase 4: Plan Audit Loop (Audit → Refocus → Decide)",
+      "title": "Phase 4: Plan Audit Loop (Audit \u2192 Refocus \u2192 Decide)",
       "runCondition": {
         "var": "taskComplexity",
         "not_equals": "Small"
@@ -139,7 +167,7 @@
         {
           "id": "phase-4c-loop-decision",
           "title": "Loop Exit Decision",
-          "prompt": "Provide a loop control artifact.\n\nDecision rules:\n- if `planFindings` is non-empty → continue\n- if `planFindings` is empty → stop, but enumerate what was checked to justify the clean pass\n- if max iterations reached → stop and document remaining concerns\n\nOutput exactly:\n```json\n{\n  \"artifacts\": [{\n    \"kind\": \"wr.loop_control\",\n    \"decision\": \"continue\"\n  }]\n}\n```",
+          "prompt": "Provide a loop control artifact.\n\nDecision rules:\n- if `planFindings` is non-empty \u2192 continue\n- if `planFindings` is empty \u2192 stop, but enumerate what was checked to justify the clean pass\n- if max iterations reached \u2192 stop and document remaining concerns\n\nOutput exactly:\n```json\n{\n  \"artifacts\": [{\n    \"kind\": \"wr.loop_control\",\n    \"decision\": \"continue\"\n  }]\n}\n```",
           "requireConfirmation": true,
           "outputContract": {
             "contractRef": "wr.contracts.loop_control"
@@ -157,9 +185,18 @@
       "prompt": "Verify that planning is complete enough to start implementation.\n\nRequired checks:\n- selected approach and rationale exist\n- runner-up exists\n- pivot triggers are concrete enough to act on\n- slices are defined with scope, verification, and boundaries\n- `implementation_plan.md` reflects the current intended work\n- no unresolved planning gaps remain that would block implementation\n- `alternativesConsideredCount` shows real exploration happened\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `planningGaps`\n- `planningComplete`\n\nRule:\n- if any gap can be fixed immediately, fix it now and do not carry it forward as a gap\n- only stop for user input when a true decision is missing",
       "requireConfirmation": {
         "or": [
-          { "var": "automationLevel", "equals": "Low" },
-          { "var": "taskComplexity", "equals": "Large" },
-          { "var": "riskLevel", "equals": "High" }
+          {
+            "var": "automationLevel",
+            "equals": "Low"
+          },
+          {
+            "var": "taskComplexity",
+            "equals": "Large"
+          },
+          {
+            "var": "riskLevel",
+            "equals": "High"
+          }
         ]
       }
     },
@@ -195,9 +232,18 @@
           "prompt": "Before implementing slice `{{currentSlice.name}}`, verify:\n- pivot triggers have not fired\n- the plan assumptions are still fresh enough\n- target files and symbols still match the plan\n- the slice remains reviewable and bounded\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `pivotTriggered`\n- `pivotSeverity`\n- `pivotReturnPhase`\n- `slicePlanStale`\n- `validationFailed`\n\nIf drift or invalid assumptions are discovered, stop and return to planning deliberately rather than coding through it.",
           "requireConfirmation": {
             "or": [
-              { "var": "pivotTriggered", "equals": true },
-              { "var": "slicePlanStale", "equals": true },
-              { "var": "validationFailed", "equals": true }
+              {
+                "var": "pivotTriggered",
+                "equals": true
+              },
+              {
+                "var": "slicePlanStale",
+                "equals": true
+              },
+              {
+                "var": "validationFailed",
+                "equals": true
+              }
             ]
           }
         },
@@ -213,8 +259,14 @@
           "prompt": "Verify slice `{{currentSlice.name}}`.\n\nAlways:\n- run planned verification commands\n- update or add tests when needed\n- ensure invariants still hold\n- check philosophy-alignment regressions introduced by the implementation\n\nFresh-eye validation triggers:\n- if `specialCaseIntroduced = true`\n- if `unplannedAbstractionIntroduced = true`\n- if this slice touched unexpected files\n- if runtime behavior still feels uncertain\n\nMode-adaptive validation:\n- QUICK: self-verify unless a fresh-eye trigger fires\n- STANDARD: if delegation is available and any fresh-eye trigger fires, spawn TWO or THREE WorkRail Executors SIMULTANEOUSLY running `routine-hypothesis-challenge`, `routine-execution-simulation`, and optionally `routine-philosophy-alignment`\n- THOROUGH + high-risk or any fresh-eye trigger: if delegation is available, spawn FOUR WorkRail Executors SIMULTANEOUSLY running `routine-hypothesis-challenge`, `routine-execution-simulation`, `routine-plan-analysis`, and `routine-philosophy-alignment`\n\nParallel-output synthesis rules:\n- if 2+ validators independently raise the same serious concern, treat it as blocking by default\n- if exactly one validator raises a concern, attempt to understand and resolve it before escalating\n- if validators disagree, record the disagreement explicitly and prefer the safer path when uncertainty remains high\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `sliceVerified`\n- `verificationFindings`\n- `verificationFailed`\n- `verificationApprovalRequired`\n- `verificationRetried`\n- `verificationConcernCount`\n- `verificationConsensusLevel`\n\nRule:\n- if 2+ independent validators raise serious concerns, stop and return to planning or ask the user which path to take",
           "requireConfirmation": {
             "or": [
-              { "var": "verificationApprovalRequired", "equals": true },
-              { "var": "verificationFailed", "equals": true }
+              {
+                "var": "verificationApprovalRequired",
+                "equals": true
+              },
+              {
+                "var": "verificationFailed",
+                "equals": true
+              }
             ]
           }
         },
@@ -224,9 +276,18 @@
           "prompt": "After a verified slice:\n- compare actual changed scope against the slice plan\n- if the slice drifted, update `implementation_plan.md` immediately and record the reason in notes\n- if `prStrategy = MultiPR`, stop here with a concise PR package for user review before continuing\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `planDrift`\n- `rulesDrift`\n- `changedFilesOutsidePlannedScope`\n- `scopeDriftDetected`\n\nRule:\n- do not rely on markdown sidecar state; notesMarkdown is the durable recap and `implementation_plan.md` is the human artifact",
           "requireConfirmation": {
             "or": [
-              { "var": "prStrategy", "equals": "MultiPR" },
-              { "var": "planDrift", "equals": true },
-              { "var": "rulesDrift", "equals": true }
+              {
+                "var": "prStrategy",
+                "equals": "MultiPR"
+              },
+              {
+                "var": "planDrift",
+                "equals": true
+              },
+              {
+                "var": "rulesDrift",
+                "equals": true
+              }
             ]
           }
         }
@@ -242,8 +303,14 @@
       "prompt": "Perform final integration verification.\n\nRequired:\n- verify acceptance criteria\n- map invariants to concrete proof (tests, build results, explicit reasoning)\n- run whole-task validation commands\n- identify any invariant violations or regressions\n- confirm the implemented result still aligns with the user's coding philosophy, naming any tensions explicitly\n- review cumulative drift across all slices, not just the current one\n- check whether repeated small compromises added up to a larger pattern problem\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `integrationVerificationPassed`\n- `integrationVerificationFailed`\n- `integrationVerificationFindings`\n- `regressionDetected`\n- `invariantViolations`\n- `crossSliceDriftDetected`",
       "requireConfirmation": {
         "or": [
-          { "var": "integrationVerificationFailed", "equals": true },
-          { "var": "regressionDetected", "equals": true }
+          {
+            "var": "integrationVerificationFailed",
+            "equals": true
+          },
+          {
+            "var": "regressionDetected",
+            "equals": true
+          }
         ]
       }
     },
@@ -254,4 +321,4 @@
       "requireConfirmation": true
     }
   ]
-}
+}