@exaudeus/workrail 3.39.0 → 3.41.0

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

@@ -1,648 +0,0 @@
-{
-  "id": "coding-task-workflow-agentic",
-  "name": "Agentic Task Dev Workflow (Lean)",
-  "version": "1.1.0",
-  "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"
-  },
-  "assessments": [
-    {
-      "id": "design-soundness-gate",
-      "purpose": "The selected design approach is committed with rationale. No unresolved ambiguity remains about what to build.",
-      "dimensions": [
-        {
-          "id": "design_soundness",
-          "purpose": "Design decision is made, tradeoffs are recorded, and there is no remaining ambiguity about the chosen approach.",
-          "levels": [
-            "low",
-            "high"
-          ]
-        }
-      ]
-    },
-    {
-      "id": "design-gaps-gate",
-      "purpose": "A deliberate scan for unconsidered alternatives, unhandled edge cases, or untracked risks has been completed.",
-      "dimensions": [
-        {
-          "id": "design_gaps",
-          "purpose": "Active scan completed: either no material gaps were found, or any found were addressed or explicitly filed.",
-          "levels": [
-            "low",
-            "high"
-          ]
-        }
-      ]
-    },
-    {
-      "id": "plan-completeness-gate",
-      "purpose": "Every slice has a defined scope and verifiable acceptance criterion. No slice is vague or open-ended.",
-      "dimensions": [
-        {
-          "id": "plan_completeness",
-          "purpose": "Slices have clear boundaries and acceptance criteria. The agent knows what done looks like for each.",
-          "levels": [
-            "low",
-            "high"
-          ]
-        }
-      ]
-    },
-    {
-      "id": "invariant-clarity-gate",
-      "purpose": "Invariants and non-goals are explicit enough to verify against during and after implementation.",
-      "dimensions": [
-        {
-          "id": "invariant_clarity",
-          "purpose": "Named invariants are checkable in the implementation. Non-goals are stated and will prevent scope creep.",
-          "levels": [
-            "low",
-            "high"
-          ]
-        }
-      ]
-    },
-    {
-      "id": "plan-gaps-gate",
-      "purpose": "A deliberate scan for missing slices, untracked risks, or acceptance criteria mismatches has been completed.",
-      "dimensions": [
-        {
-          "id": "plan_gaps",
-          "purpose": "Active scan completed: either no material gaps were found, or any found were addressed or explicitly filed.",
-          "levels": [
-            "low",
-            "high"
-          ]
-        }
-      ]
-    },
-    {
-      "id": "build-correctness-gate",
-      "purpose": "The implementation compiles and passes all relevant tests.",
-      "dimensions": [
-        {
-          "id": "build_correctness",
-          "purpose": "Build succeeds and tests pass. No compilation errors or failing assertions.",
-          "levels": [
-            "low",
-            "high"
-          ]
-        }
-      ]
-    },
-    {
-      "id": "invariant-preservation-gate",
-      "purpose": "Invariants identified during planning still hold in the implemented code.",
-      "dimensions": [
-        {
-          "id": "invariant_preservation",
-          "purpose": "Each named invariant from the plan has been verified in the implementation.",
-          "levels": [
-            "low",
-            "high"
-          ]
-        }
-      ]
-    },
-    {
-      "id": "implementation-gaps-gate",
-      "purpose": "A deliberate scan for gaps, issues, or improvements surfaced during implementation has been completed.",
-      "dimensions": [
-        {
-          "id": "implementation_gaps",
-          "purpose": "Active scan completed: gaps found are either fixed inline, filed as follow-up tickets, or explicitly deferred with rationale.",
-          "levels": [
-            "low",
-            "high"
-          ]
-        }
-      ]
-    }
-  ],
-  "preconditions": [
-    "User provides a task description or equivalent objective.",
-    "Agent has codebase read access and can run the tools needed for analysis and validation.",
-    "A deterministic validation path exists (tests, build, or an explicit verification strategy).",
-    "If the task touches critical paths, rollback or containment strategy can be defined."
-  ],
-  "metaGuidance": [
-    "DEFAULT BEHAVIOR: self-execute with tools. Only ask the user for business decisions, missing external artifacts, or permissions you cannot resolve.",
-    "V2 DURABILITY: use output.notesMarkdown as the primary durable record. Do NOT mirror execution state into CONTEXT.md or any markdown checkpoint file.",
-    "ARTIFACT STRATEGY: `implementation_plan.md` drives execution. `spec.md`, when created, is canonical for observable behavior and serves as the verification anchor. Do not create extra artifacts unless they materially improve handoff.",
-    "OWNERSHIP & DELEGATION: the main agent owns strategy, decisions, synthesis, and implementation. Delegate only bounded cognitive routines via WorkRail Executor. Never hand off full task ownership or rely on named Builder/Researcher identities.",
-    "SUBAGENT SYNTHESIS: treat subagent output as evidence, not conclusions. State your hypothesis before delegating, then interrogate what came back: what was missed, wrong, or new? Say what changed your mind or what you still reject, and why.",
-    "PARALLELISM: when reads, audits, or delegations are independent, run them in parallel inside the phase. Parallelize cognition; serialize synthesis and canonical writes.",
-    "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.",
-    "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": [
-    {
-      "id": "authoring-spec",
-      "title": "Authoring Specification",
-      "source": "./spec/authoring-spec.json",
-      "purpose": "Canonical rules and constraints for workflow authoring. Consult when making structural decisions about workflow design.",
-      "authoritative": true,
-      "resolveFrom": "package"
-    },
-    {
-      "id": "workflow-schema",
-      "title": "Workflow JSON Schema",
-      "source": "./spec/workflow.schema.json",
-      "purpose": "The JSON schema that all workflow definitions must conform to. Use as the structural contract reference.",
-      "authoritative": true,
-      "resolveFrom": "package"
-    },
-    {
-      "id": "authoring-provenance",
-      "title": "Workflow Authoring Provenance",
-      "source": "./spec/authoring-spec.provenance.json",
-      "purpose": "Source-of-truth map showing what is canonical, derived, and non-canonical in workflow authoring guidance.",
-      "authoritative": false,
-      "resolveFrom": "package"
-    }
-  ],
-  "steps": [
-    {
-      "id": "phase-0-understand-and-classify",
-      "title": "Phase 0: Understand & Classify",
-      "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"
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-1a-hypothesis",
-      "title": "Phase 1a: State Hypothesis",
-      "runCondition": {
-        "and": [
-          {
-            "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`",
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-1b-design-quick",
-      "title": "Phase 1b: Lightweight Design (QUICK)",
-      "runCondition": {
-        "and": [
-          {
-            "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)",
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-1b-design-deep",
-      "title": "Phase 1b: Design Generation (Injected Routine — Tension-Driven Design)",
-      "runCondition": {
-        "and": [
-          {
-            "var": "taskComplexity",
-            "not_equals": "Small"
-          },
-          {
-            "var": "rigorMode",
-            "not_equals": "QUICK"
-          }
-        ]
-      },
-      "templateCall": {
-        "templateId": "wr.templates.routine.tension-driven-design",
-        "args": {
-          "deliverableName": "design-candidates.md"
-        }
-      }
-    },
-    {
-      "id": "phase-1c-challenge-and-select",
-      "title": "Phase 1c: Challenge and Select",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "prompt": "Read `design-candidates.md`, compare it to your original guess, and make the call.\n\nBe explicit about three things:\n- what the design work confirmed\n- what changed your mind\n- what you missed the first time\n\nThen pressure-test the leading option:\n- what's the strongest case against it?\n- what assumption breaks it?\n\nAfter the challenge batch, say:\n- what changed your mind\n- what didn't\n- which findings you reject and why\n\nPick the approach yourself. Don't hide behind the artifact. If the simplest thing works, prefer it. If the front-runner stops looking right after challenge, switch.\n\nCapture:\n- `selectedApproach` — chosen design with rationale tied to tensions\n- `runnerUpApproach` — next-best option and why it lost\n- `architectureRationale` — tensions resolved vs accepted\n- `pivotTriggers` — conditions under which you'd switch to the runner-up\n- `keyRiskToMonitor` — failure mode of the selected approach\n- `acceptedTradeoffs`\n- `identifiedFailureModes`",
-      "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."
-        },
-        {
-          "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."
-        }
-      ],
-      "assessmentRefs": [
-        "design-soundness-gate",
-        "design-gaps-gate"
-      ],
-      "assessmentConsequences": [
-        {
-          "when": {
-            "anyEqualsLevel": "low"
-          },
-          "effect": {
-            "kind": "require_followup",
-            "guidance": "Address whichever gate scored low: design_soundness low -- the design decision is still ambiguous; commit to an approach and record the rationale before proceeding. design_gaps low -- the gap scan was not completed or found unaddressed gaps; either resolve them or explicitly file them before proceeding."
-          }
-        }
-      ],
-      "requireConfirmation": {
-        "or": [
-          {
-            "var": "automationLevel",
-            "equals": "Low"
-          },
-          {
-            "var": "taskComplexity",
-            "equals": "Large"
-          },
-          {
-            "var": "riskLevel",
-            "equals": "High"
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-2-design-review",
-      "type": "loop",
-      "title": "Phase 2: Design Review",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "loop": {
-        "type": "while",
-        "conditionSource": {
-          "kind": "artifact_contract",
-          "contractRef": "wr.contracts.loop_control",
-          "loopId": "design_review_loop"
-        },
-        "maxIterations": 2
-      },
-      "body": [
-        {
-          "id": "phase-2a-pre-assess-design-review",
-          "title": "Pre-Assess Design Review",
-          "prompt": "Before the detailed design review, state your current assessment in 2-4 sentences.\n\nSay:\n- what you think the strongest part of the selected design is right now\n- what you think the weakest part is right now\n- which tradeoff or failure mode worries you most\n\nThis is your reference point for interpreting the review findings.\n\nSet this key in the next `continue_workflow` call's `context` object:\n- `designReviewAssessment`",
-          "requireConfirmation": false
-        },
-        {
-          "id": "phase-2b-design-review-core",
-          "title": "Design Review Core",
-          "templateCall": {
-            "templateId": "wr.templates.routine.design-review",
-            "args": {
-              "deliverableName": "design-review-findings.md"
-            }
-          },
-          "requireConfirmation": false
-        },
-        {
-          "id": "phase-2c-synthesize-design-review",
-          "title": "Synthesize Design Review Findings",
-          "prompt": "Read `design-review-findings.md` and turn the review into workflow-owned decisions.\n\nCompare it against `designReviewAssessment`:\n- what did the review confirm?\n- what did it surface that you missed?\n- what changed your mind and what held firm?\n\nIf the findings are real, fix the design before you continue (`selectedApproach`, `architectureRationale`, `pivotTriggers`, `acceptedTradeoffs`, `identifiedFailureModes`).\n\nAfter any extra challenge, synthesize explicitly:\n- which findings actually matter\n- what changed in the design\n- what you reject and why\n\nFor any finding that changes the decision, classify it as:\n- `Confirmed`: you checked it against primary evidence (code, artifacts, spec, tests/build, or direct workflow context)\n- `Plausible`: interesting, but not verified enough to drive the decision yet\n- `Rejected`: contradicted by fuller context or direct evidence\n\nSubagent agreement alone is not enough for `Confirmed`.\n\nCapture:\n- `designFindings`\n- `designRevised`",
-          "promptFragments": [
-            {
-              "id": "phase-2c-challenge-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."
-            }
-          ],
-          "requireConfirmation": false
-        },
-        {
-          "id": "phase-2d-loop-decision",
-          "title": "Design Review Loop Decision",
-          "prompt": "Decide whether the design needs another pass.\n\nIf `designFindings` is non-empty and the design was revised, keep going so the revision gets checked.\nIf `designFindings` is empty, stop.\nIf you've hit the limit, stop and record the remaining concerns.\n\nThen emit the required loop-control artifact in this shape (`decision` must be `continue` or `stop`):\n```json\n{\n  \"artifacts\": [{\n    \"kind\": \"wr.loop_control\",\n    \"decision\": \"continue\"\n  }]\n}\n```",
-          "requireConfirmation": false,
-          "outputContract": {
-            "contractRef": "wr.contracts.loop_control"
-          }
-        }
-      ]
-    },
-    {
-      "id": "phase-3-plan-and-test-design",
-      "title": "Phase 3: Slice, Plan, and Test Design",
-      "runCondition": {
-        "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\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.",
-      "assessmentRefs": [
-        "plan-completeness-gate",
-        "invariant-clarity-gate",
-        "plan-gaps-gate"
-      ],
-      "assessmentConsequences": [
-        {
-          "when": {
-            "anyEqualsLevel": "low"
-          },
-          "effect": {
-            "kind": "require_followup",
-            "guidance": "Address whichever gate scored low: plan_completeness low -- one or more slices lack clear boundaries or verifiable acceptance criteria; sharpen them before implementation begins. invariant_clarity low -- invariants or non-goals are too vague to verify against; make them concrete. plan_gaps low -- the gap scan was not completed or found unaddressed gaps; resolve or file them before proceeding."
-          }
-        }
-      ],
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-3b-spec",
-      "title": "Phase 3b: Spec (Observable Behavior)",
-      "runCondition": {
-        "and": [
-          {
-            "var": "taskComplexity",
-            "not_equals": "Small"
-          },
-          {
-            "or": [
-              {
-                "var": "taskComplexity",
-                "equals": "Large"
-              },
-              {
-                "var": "riskLevel",
-                "equals": "High"
-              }
-            ]
-          }
-        ]
-      },
-      "prompt": "Write `spec.md`.\n\nKeep it about what the feature does from the outside, not how you plan to build it.\n\nInclude:\n1. Feature summary\n2. Acceptance criteria\n3. Non-goals\n4. External API / interface contract if it matters\n5. Edge cases and failure modes\n6. How each acceptance criterion will be verified\n\nKeep it tight. If something can't be verified, it doesn't belong as an acceptance criterion.\n\n`spec.md` is canonical for observable behavior.",
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-4-plan-audit",
-      "type": "loop",
-      "title": "Phase 4: Plan Audit (Review, Fix, Decide)",
-      "runCondition": {
-        "and": [
-          {
-            "var": "taskComplexity",
-            "not_equals": "Small"
-          },
-          {
-            "var": "rigorMode",
-            "not_equals": "QUICK"
-          }
-        ]
-      },
-      "loop": {
-        "type": "while",
-        "conditionSource": {
-          "kind": "artifact_contract",
-          "contractRef": "wr.contracts.loop_control",
-          "loopId": "plan_audit_loop"
-        },
-        "maxIterations": 2
-      },
-      "body": [
-        {
-          "id": "phase-4a-audit-and-refocus",
-          "title": "Audit Plan and Apply Fixes",
-          "prompt": "Audit the plan and fix it in the same pass.\n\nLook for:\n- missing work\n- weak assumptions and risks\n- invariant gaps\n- bad slice boundaries\n- philosophy violations or tensions\n- regressions from things you already fixed\n- mismatches between `implementation_plan.md` and `spec.md` if there is a spec\n\nBefore you delegate, say what looks weakest right now and what you trust least.\n\nAfter the audit batch, synthesize explicitly:\n- what multiple auditors agreed on\n- what only one auditor raised\n- what you reject and why\n- what changed in the plan because of the audit\n\nFor any finding that changes the plan, classify it as:\n- `Confirmed`: you checked it against primary evidence (code, plan/spec artifacts, tests/build, or direct workflow context)\n- `Plausible`: interesting, but not verified enough to change the plan yet\n- `Rejected`: contradicted by fuller context or direct evidence\n\nSubagent agreement alone is not enough for `Confirmed`.\n\nThen fix the plan immediately:\n- update `implementation_plan.md`\n- update `spec.md` if acceptance criteria or other observable behavior changed\n- update `slices` if the shape changed\n- move out-of-scope work into `followUpTickets`\n- track resolved findings (cap at 10, drop oldest)\n\nCapture:\n- `planFindings`\n- `planConfidence`\n- `resolvedFindings`\n- `followUpTickets`\n\nIf the plan drifted, fix the plan. Don't just keep going.",
-          "promptFragments": [
-            {
-              "id": "phase-4a-delegation-quick",
-              "when": {
-                "var": "rigorMode",
-                "equals": "QUICK"
-              },
-              "text": "Do this yourself."
-            },
-            {
-              "id": "phase-4a-delegation-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"
-              },
-              "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."
-            }
-          ],
-          "requireConfirmation": false
-        },
-        {
-          "id": "phase-4b-loop-decision",
-          "title": "Loop Exit Decision",
-          "prompt": "Decide whether the plan needs another pass.\n\nIf `planFindings` is non-empty, keep going.\nIf it's empty, stop — but say what you checked so the clean pass means something.\nIf you've hit the limit, stop and record what still bothers you.\n\nThen emit the required loop-control artifact in this shape (`decision` must be `continue` or `stop`):\n```json\n{\n  \"artifacts\": [{\n    \"kind\": \"wr.loop_control\",\n    \"decision\": \"continue\"\n  }]\n}\n```",
-          "requireConfirmation": true,
-          "outputContract": {
-            "contractRef": "wr.contracts.loop_control"
-          }
-        }
-      ]
-    },
-    {
-      "id": "phase-5-small-task-fast-path",
-      "title": "Phase 5: Small Task Fast Path",
-      "runCondition": {
-        "var": "taskComplexity",
-        "equals": "Small"
-      },
-      "prompt": "For Small tasks, fast does not mean shallow. Every item below is required.\n\n**1. Confirm all wiring points with tools.**\nDon't assume a file you create is reachable. Check every public entry point:\n- Does the new symbol need to be exported from an index file?\n- Does it need to be imported and registered somewhere (CLI command map, router, DI container, plugin registry)?\n- Is there a test file that needs to reference it?\nTrace the full call path from the public interface down to your new code before writing anything.\n\n**2. Implement the smallest correct change.**\nChange exactly what needs changing. No drive-by refactors, no extra abstractions.\n\n**3. Verify end-to-end.**\n- Run build and tests. Both must pass.\n- Manually trace the new behavior through the public entry point (e.g. run the CLI command, check the export resolves, hit the endpoint). If you can't do this deterministically with tools, say why.\n- Apply the user's coding philosophy as the review lens. Flag any violation by principle name.\n\n**4. Produce a handoff note.**\nOutput a notes artifact containing a JSON fenced block with the following fields.\nThe daemon reads this block to run `git commit` and `gh pr create` -- write it exactly as shown:\n\n```json\n{\n  \"commitType\": \"feat\",\n  \"commitScope\": \"mcp\",\n  \"commitSubject\": \"imperative mood, max 72 chars total with type(scope): prefix, no period\",\n  \"prTitle\": \"same as full commit first line\",\n  \"prBody\": \"markdown with ## Summary (bullets) and ## Test plan (checklist)\",\n  \"followUpTickets\": [],\n  \"filesChanged\": [\"src/path/to/file.ts\", \"tests/unit/file.test.ts\"]\n}\n```\n\nFields:\n- `commitType`: feat / fix / chore / refactor / docs / test / perf (pick one)\n- `commitScope`: product area only (console / mcp / workflows / engine / schema / docs)\n- `commitSubject`: imperative mood, max 72 chars total with type(scope): prefix, no period\n- `prTitle`: same as full commit first line\n- `prBody`: markdown with ## Summary (bullets) and ## Test plan (checklist)\n- `followUpTickets`: list of deferred items, or empty array\n- `filesChanged`: list of every file you created or modified (required -- do not omit)\n\nThe daemon will use this artifact to run git commit and open the PR. Do not commit or push yourself.\n\nDo not create heavyweight planning artifacts unless risk unexpectedly grows.",
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-6-implement-slices",
-      "type": "loop",
-      "title": "Phase 6: Implement Slice-by-Slice",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "loop": {
-        "type": "forEach",
-        "items": "slices",
-        "itemVar": "currentSlice",
-        "indexVar": "sliceIndex",
-        "maxIterations": 20
-      },
-      "body": [
-        {
-          "id": "phase-6a-implement-slice",
-          "title": "Implement Slice",
-          "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
-        },
-        {
-          "id": "phase-6b-verify-slice",
-          "title": "Verify Slice",
-          "runCondition": {
-            "var": "verifyNeeded",
-            "equals": true
-          },
-          "prompt": "Take a fresh look at what you just changed.\n\nCheck whether:\n- it matches the plan's intent, not just the letter\n- it hides assumptions or skips edge cases\n- invariants still hold\n- it regressed against the user's philosophy\n- multiple unverified slices now need to be reviewed together\n- `unexpectedScopeChange` was just harmless integration work or real plan drift\n\nIf any of `specialCaseIntroduced`, `unplannedAbstractionIntroduced`, or `unexpectedScopeChange` is true, or if tests/build were shaky, run the verification batch before you decide this slice is done.\n\nAfter the verification batch, synthesize explicitly:\n- what multiple reviewers agreed on\n- what only one reviewer raised\n- what you reject and why\n- whether the drift was harmless integration work or real plan drift\n\nFor any finding that changes whether this slice is accepted, classify it as:\n- `Confirmed`: you checked it against primary evidence (code, plan/spec artifacts, tests/build, or direct workflow context)\n- `Plausible`: interesting, but not verified enough to accept or block the slice yet\n- `Rejected`: contradicted by fuller context or direct evidence\n\nSubagent agreement alone is not enough for `Confirmed`.\n\nSay where you're least confident.\n\nIf the slice drifted materially, update `implementation_plan.md` and `spec.md` if observable behavior changed. If the drift changed boundaries or makes the current plan unreliable, stop and go back to planning.\n\nIf the concerns are serious, stop and go back to planning or ask me. Don't wave this through just because the code exists.\n\nCapture:\n- `verificationFindings`\n- `verificationFailed`",
-          "promptFragments": [
-            {
-              "id": "phase-6b-delegation-quick",
-              "when": {
-                "var": "rigorMode",
-                "equals": "QUICK"
-              },
-              "text": "Do the verification yourself."
-            },
-            {
-              "id": "phase-6b-delegation-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"
-              },
-              "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"
-              },
-              "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"
-              }
-            ]
-          }
-        }
-      ]
-    },
-    {
-      "id": "phase-7-final-verification",
-      "type": "loop",
-      "title": "Phase 7: Final Verification Barrier (Verify, Fix, Re-Verify)",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "loop": {
-        "type": "while",
-        "conditionSource": {
-          "kind": "artifact_contract",
-          "contractRef": "wr.contracts.loop_control",
-          "loopId": "final_verification_loop"
-        },
-        "maxIterations": 2
-      },
-      "body": [
-        {
-          "id": "phase-7a-final-verification-core",
-          "title": "Run Final Verification Batch",
-          "templateCall": {
-            "templateId": "wr.templates.routine.final-verification",
-            "args": {
-              "deliverableName": "final-verification-findings.md"
-            }
-          },
-          "requireConfirmation": false
-        },
-        {
-          "id": "phase-7b-fix-and-summarize",
-          "title": "Synthesize Findings, Fix, and Re-Verify",
-          "prompt": "Read `final-verification-findings.md` and decide what actually needs fixing.\n\nDon't rubber-stamp it. The verifier is evidence, not the decision.\n\nIf `spec.md` exists, use it as the verification anchor and make sure every acceptance criterion is actually met.\n\nThis loop is verify, fix, then re-verify. If you fix anything here, the next pass exists to prove the fixes worked.\n\nSynthesize the verification output explicitly:\n- what the verifier found\n- what you agree with\n- what you reject and why\n- what changed because of the fixes\n\nFor any finding that changes final acceptance, classify it as:\n- `Confirmed`: you checked it against primary evidence (code, spec, tests/build, or direct workflow context)\n- `Plausible`: interesting, but not verified enough to accept or block final signoff yet\n- `Rejected`: contradicted by fuller context or direct evidence\n\nSubagent agreement alone is not enough for `Confirmed`.\n\nFix what has to be fixed now, rerun the affected verification, and update:\n- `implementation_plan.md` if the execution shape changed\n- `spec.md` if acceptance criteria, observable behavior, or external contracts changed\n\nCapture:\n- `integrationFindings`\n- `integrationPassed`\n- `regressionDetected`",
-          "assessmentRefs": [
-            "build-correctness-gate",
-            "invariant-preservation-gate",
-            "implementation-gaps-gate"
-          ],
-          "assessmentConsequences": [
-            {
-              "when": {
-                "anyEqualsLevel": "low"
-              },
-              "effect": {
-                "kind": "require_followup",
-                "guidance": "Address whichever gate scored low: build_correctness low -- the build or tests are still failing; fix them before this step can complete. invariant_preservation low -- one or more invariants from the plan are violated; fix the implementation. implementation_gaps low -- the gap scan was not completed or found unaddressed gaps; fix them inline, file as follow-up tickets, or explicitly defer with rationale."
-              }
-            }
-          ],
-          "requireConfirmation": false
-        },
-        {
-          "id": "phase-7c-loop-decision",
-          "title": "Final Verification Loop Decision",
-          "prompt": "Decide whether final verification needs another pass or whether we're done.\n\nThis loop gets up to two verify/fix passes.\n- If verification found real issues and you fixed them, keep going so the fixes get re-verified.\n- If the issues are clean or resolved, stop.\n- If you've hit the limit, stop and record what remains.\n\nWhen you stop, include:\n- acceptance criteria status\n- invariant status\n- test/build summary\n- follow-up tickets\n- any philosophy tensions you accepted on purpose\n\n**Handoff block (required for daemon auto-commit):**\nInclude a JSON fenced block in your notes. The daemon reads this to run `git commit` and `gh pr create`:\n\n```json\n{\n  \"commitType\": \"feat\",\n  \"commitScope\": \"mcp\",\n  \"commitSubject\": \"imperative mood, max 72 chars total with type(scope): prefix, no period\",\n  \"prTitle\": \"same as full commit first line\",\n  \"prBody\": \"markdown with ## Summary (bullets) and ## Test plan (checklist)\",\n  \"followUpTickets\": [],\n  \"filesChanged\": [\"src/path/to/file.ts\", \"tests/unit/file.test.ts\"]\n}\n```\n\nFields: `commitType` (feat/fix/chore/refactor/docs/test/perf), `commitScope` (product area only: console/mcp/workflows/engine/schema/docs), `commitSubject` (imperative, <=72 chars including prefix, no period), `prTitle` (same as commit first line), `prBody` (markdown), `followUpTickets` (array), `filesChanged` (required -- every file created or modified).\n\nThen emit the required loop-control artifact in this shape (`decision` must be `continue` or `stop`):\n```json\n{\n  \"artifacts\": [{\n    \"kind\": \"wr.loop_control\",\n    \"decision\": \"continue\"\n  }]\n}\n```",
-          "requireConfirmation": true,
-          "outputContract": {
-            "contractRef": "wr.contracts.loop_control"
-          }
-        }
-      ]
-    }
-  ]
-}