@exaudeus/workrail 3.1.0 → 3.2.0

package/package.json

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

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

@@ -1,7 +1,7 @@
 {
   "id": "coding-task-workflow-agentic",
   "name": "Agentic Task Dev Workflow (Lean • Notes-First • WorkRail Executor)",
-  "version": "2.1.0",
+  "version": "1.0.0",
   "description": "Lean variant of the agentic coding workflow. Merges triage, inputs gate, context gathering, and re-triage into a single Understand & Classify phase. Reduces context variable count and removes top-level clarificationPrompts. Same quality guarantees with fewer tokens.",
   "recommendedPreferences": {
     "recommendedAutonomy": "guided",
@@ -58,7 +58,7 @@
           { "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- Key tradeoff\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` using the same structure as the deep design path:\n- Problem Understanding\n- Candidates (each with: summary, tradeoff, failure mode, philosophy fit)\n- Comparison and Recommendation\n\nSet context variable:\n- `designSummary` — one-paragraph summary of the recommendation and why",
+      "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
     },
     {
@@ -112,13 +112,30 @@
       },
       "body": [
         {
-          "id": "phase-2a-review-design",
-          "title": "Review Design for Gaps, Issues, and Improvements",
-          "prompt": "Review the selected architecture using the explicit tradeoffs and failure modes from Phase 1 as your review criteria — not a generic gaps checklist.\n\nTargeted review (derived from Phase 1 outputs):\n1. Are the `acceptedTradeoffs` actually acceptable? For each accepted tradeoff, verify it won't violate acceptance criteria or invariants under realistic conditions.\n2. Are the `identifiedFailureModes` actually handled? For each failure mode, trace through the design and confirm there's a mitigation path. If not, flag it.\n3. Does the selected approach's relationship to existing repo patterns hold up? If it 'adapts' an existing pattern, verify the adaptation doesn't break the invariants the original pattern protects.\n4. Is there a simpler version of the selected approach that still satisfies acceptance criteria? (Complexity must continue to justify itself.)\n\nCompare against the runner-up:\n- Are there elements from the runner-up that would strengthen the selected approach without adding complexity?\n- Would a hybrid resolve an accepted tradeoff that's bothering you?\n\nPhilosophy alignment: does the architecture respect the user's active coding rules?\n\nBefore delegating, state your current assessment: what do you think the strongest and weakest parts of the design are right now?\n\nMode-adaptive delegation:\n- QUICK: self-review only\n- STANDARD: optionally spawn ONE WorkRail Executor running `routine-hypothesis-challenge` focused specifically on the accepted tradeoffs and failure modes\n- THOROUGH: spawn TWO WorkRail Executors — `routine-hypothesis-challenge` on tradeoffs + `routine-execution-simulation` on failure modes\n\nAfter receiving subagent output (if used), interrogate it against your pre-assessment. Do not adopt their framing wholesale. State what changed your thinking and what didn't.\n\nIf issues are found, fix the design (update `selectedApproach`, `architectureRationale`, `pivotTriggers`, `acceptedTradeoffs`, `identifiedFailureModes`) before continuing.\n\nSet context variables:\n- `designFindings`\n- `designRevised`",
+          "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 context variable:\n- `designReviewAssessment`",
           "requireConfirmation": false
         },
         {
-          "id": "phase-2b-loop-decision",
+          "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 synthesize the review into workflow-owned decisions.\n\nPart A — Compare against your pre-assessment:\nRevisit `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\nPart B — Optional mode-adaptive challenge around the review findings:\n- QUICK: self-synthesize only\n- STANDARD: optionally spawn ONE WorkRail Executor running `routine-hypothesis-challenge` focused on the most serious review finding\n- THOROUGH: optionally spawn TWO WorkRail Executors — `routine-hypothesis-challenge` on the most serious finding + `routine-execution-simulation` on the most dangerous failure mode\n\nPart C — Decide:\nInterpret the findings yourself. Do not adopt the review artifact or any subagent framing wholesale.\n\nIf issues are found, fix the design (update `selectedApproach`, `architectureRationale`, `pivotTriggers`, `acceptedTradeoffs`, `identifiedFailureModes`) before continuing.\n\nSet context variables:\n- `designFindings`\n- `designRevised`",
+          "requireConfirmation": false
+        },
+        {
+          "id": "phase-2d-loop-decision",
           "title": "Design Review Loop Decision",
           "prompt": "Provide a loop control artifact.\n\nDecision rules:\n- if `designFindings` is non-empty and design was revised -> continue (verify the revision)\n- if `designFindings` is empty -> stop\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```",
           "requireConfirmation": false,
@@ -242,13 +259,24 @@
       },
       "body": [
         {
-          "id": "phase-7a-verify-and-fix",
-          "title": "Verify Integration and Fix Issues",
-          "prompt": "Perform integration verification across all implemented slices.\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 aligns with the user's coding philosophy, naming any tensions explicitly\n- review cumulative drift across all slices\n- check whether repeated small compromises added up to a larger pattern problem\n\nIf issues are found, fix them immediately:\n- apply code fixes\n- re-run affected tests\n- update `implementation_plan.md` if the fix changed boundaries or approach\n\nSet context variables:\n- `integrationFindings`\n- `integrationPassed`\n- `regressionDetected`",
+          "id": "phase-7a-final-verification-core",
+          "title": "Final Verification Core",
+          "templateCall": {
+            "templateId": "wr.templates.routine.final-verification",
+            "args": {
+              "deliverableName": "final-verification-findings.md"
+            }
+          },
+          "requireConfirmation": false
+        },
+        {
+          "id": "phase-7b-fix-and-summarize",
+          "title": "Fix Issues and Summarize Verification",
+          "prompt": "Read `final-verification-findings.md` and turn it into workflow-owned decisions and fixes.\n\nRequired:\n- interpret the findings yourself rather than rubber-stamping them\n- identify any invariant violations or regressions that must be fixed now\n- if issues are found, fix them immediately\n- re-run affected tests\n- update `implementation_plan.md` if the fix changed boundaries or approach\n\nSet context variables:\n- `integrationFindings`\n- `integrationPassed`\n- `regressionDetected`",
           "requireConfirmation": false
         },
         {
-          "id": "phase-7b-loop-decision",
+          "id": "phase-7c-loop-decision",
           "title": "Final Verification Loop Decision",
           "prompt": "Provide a loop control artifact.\n\nDecision rules:\n- if `integrationFindings` is non-empty and fixes were applied -> continue (re-verify the fixes)\n- if `integrationFindings` is empty or all issues resolved -> stop and produce handoff\n- if max iterations reached -> stop and document remaining concerns\n\nWhen stopping, include the handoff summary:\n- acceptance criteria status\n- invariant status\n- test/build summary\n- concise PR/MR description draft (why, test plan, rollout notes)\n- follow-up tickets\n- any philosophy tensions accepted intentionally and why\n\nKeep the handoff concise and executive-level. Do not auto-merge or push unless the user explicitly asks.\n\nOutput exactly:\n```json\n{\n  \"artifacts\": [{\n    \"kind\": \"wr.loop_control\",\n    \"decision\": \"continue\"\n  }]\n}\n```",
           "requireConfirmation": true,

package/workflows/routines/design-review.json

@@ -0,0 +1,60 @@
+{
+  "id": "routine-design-review",
+  "name": "Design Review Routine",
+  "version": "1.0.0",
+  "description": "Reviews a selected design using explicit tradeoffs, failure modes, simpler-alternative checks, runner-up comparison, and philosophy alignment. Produces a reusable design-review findings artifact.",
+  "clarificationPrompts": [
+    "What design artifact or summary should I review?",
+    "What tradeoffs, failure modes, and runner-up option are available?",
+    "What artifact name should I produce?"
+  ],
+  "preconditions": [
+    "A selected design or design summary is available",
+    "Accepted tradeoffs and failure modes are available",
+    "A runner-up or alternative approach is available",
+    "The dev's philosophy or rules are available"
+  ],
+  "metaGuidance": [
+    "PURPOSE: review the quality of a selected design, not generate a fresh design from scratch.",
+    "ROLE: you are a reviewer looking for real gaps, not generic criticism.",
+    "PHILOSOPHY: name tensions by principle when they matter.",
+    "SIMPLICITY: always ask whether a simpler version would still satisfy acceptance criteria."
+  ],
+  "steps": [
+    {
+      "id": "step-review-tradeoffs",
+      "title": "Step 1: Review Accepted Tradeoffs",
+      "prompt": "Review the selected design by walking through the accepted tradeoffs explicitly.\n\nFor each accepted tradeoff:\n- Verify it will not violate acceptance criteria or invariants under realistic conditions\n- Identify what would make the tradeoff no longer acceptable\n- Note any hidden assumptions\n\nWorking notes:\n- Tradeoff review\n- Hidden assumptions\n- Conditions under which the tradeoff fails",
+      "agentRole": "You are a reviewer validating whether accepted tradeoffs are actually acceptable.",
+      "requireConfirmation": false
+    },
+    {
+      "id": "step-review-failure-modes",
+      "title": "Step 2: Review Failure Modes",
+      "prompt": "Review the identified failure modes for the selected design.\n\nFor each failure mode:\n- Trace whether the design handles it adequately\n- Identify missing mitigations\n- Note which failure mode is most dangerous if it occurs\n\nWorking notes:\n- Failure mode coverage\n- Missing mitigations\n- Highest-risk failure mode",
+      "agentRole": "You are a failure analyst checking whether the design can survive realistic problems.",
+      "requireConfirmation": false
+    },
+    {
+      "id": "step-compare-runner-up",
+      "title": "Step 3: Compare Against Runner-Up and Simpler Alternatives",
+      "prompt": "Compare the selected design against the runner-up and a simpler possible variant.\n\nReview:\n- Whether the runner-up has elements worth pulling into the selected design\n- Whether a hybrid would resolve an uncomfortable tradeoff without adding much complexity\n- Whether a simpler version of the selected design would still satisfy acceptance criteria\n\nWorking notes:\n- Runner-up strengths worth borrowing\n- Simpler alternative analysis\n- Hybrid opportunities",
+      "agentRole": "You are comparing options honestly rather than defending the current favorite.",
+      "requireConfirmation": false
+    },
+    {
+      "id": "step-review-philosophy",
+      "title": "Step 4: Review Philosophy Alignment",
+      "prompt": "Review the selected design against the dev's philosophy.\n\nName the principles that matter for this design and assess:\n- Which principles are satisfied clearly\n- Which principles are under tension\n- Which tensions are acceptable versus risky\n\nWorking notes:\n- Relevant principles\n- Satisfied principles\n- Tensions and why they matter",
+      "agentRole": "You are checking whether the design respects what the dev actually values.",
+      "requireConfirmation": false
+    },
+    {
+      "id": "step-deliver",
+      "title": "Step 5: Deliver Design Review Findings",
+      "prompt": "Create `{deliverableName}`.\n\nRequired structure:\n- Tradeoff Review\n- Failure Mode Review\n- Runner-Up / Simpler Alternative Review\n- Philosophy Alignment\n- Findings (Red / Orange / Yellow or equivalent severity)\n- Recommended Revisions\n- Residual Concerns\n\nOptimize for concise, actionable findings that the main workflow can interpret and decide on.",
+      "agentRole": "You are delivering a review artifact for the main workflow to synthesize and act on.",
+      "requireConfirmation": false
+    }
+  ]
+}

package/workflows/routines/final-verification.json

@@ -0,0 +1,62 @@
+{
+  "id": "routine-final-verification",
+  "name": "Final Verification Routine",
+  "version": "1.0.0",
+  "description": "Performs reusable final verification over acceptance criteria, invariants, validation evidence, regressions, cumulative drift, and philosophy alignment. Produces a proof-oriented verification artifact built around claim -> evidence -> gap -> severity -> readiness verdict.",
+  "clarificationPrompts": [
+    "What implementation or slices should I verify?",
+    "What acceptance criteria and invariants must hold?",
+    "What validation commands or evidence are available?",
+    "What artifact name should I produce?"
+  ],
+  "preconditions": [
+    "Implementation is available for review",
+    "Acceptance criteria are available",
+    "Invariants are available",
+    "A deterministic validation path exists"
+  ],
+  "metaGuidance": [
+    "PURPOSE: verify whether the whole task is truly done, not just locally green.",
+    "ROLE: you are a verifier proving or disproving readiness using evidence.",
+    "PROOF: map every readiness claim to tests, build output, artifacts, or explicit reasoning.",
+    "SEVERITY: every gap should be classified clearly so the caller knows what blocks shipping.",
+    "DRIFT: look for cumulative compromise, not just isolated defects."
+  ],
+  "steps": [
+    {
+      "id": "step-map-claims-to-proof",
+      "title": "Step 1: Map Acceptance Criteria and Invariants to Proof",
+      "prompt": "Map the implementation's readiness claims to concrete proof.\n\nFor each acceptance criterion and invariant:\n- state the claim clearly\n- identify the strongest supporting evidence (test, build output, artifact, code reasoning)\n- note whether the proof is strong, partial, or missing\n- record any gap that prevents the claim from being fully proven\n\nWorking notes:\n- Claim -> proof matrix\n- Strong / partial / missing proof\n- Gaps that weaken readiness",
+      "agentRole": "You are a verifier mapping claims to concrete proof.",
+      "requireConfirmation": false
+    },
+    {
+      "id": "step-review-validation-evidence",
+      "title": "Step 2: Review Validation Evidence Quality",
+      "prompt": "Review the overall validation evidence quality.\n\nCheck:\n- whether the right validation commands were run\n- whether the evidence is trustworthy and sufficient for readiness\n- whether any critical area has only weak or indirect proof\n- whether additional validation would materially change confidence\n\nWorking notes:\n- Validation commands reviewed\n- Evidence strength assessment\n- Missing or weak proof",
+      "agentRole": "You are checking whether the validation story is actually strong enough to trust.",
+      "requireConfirmation": false
+    },
+    {
+      "id": "step-classify-gaps-and-regressions",
+      "title": "Step 3: Classify Gaps, Regressions, and Drift by Severity",
+      "prompt": "Review the implementation for regressions, drift, and unresolved gaps.\n\nCheck:\n- invariant violations or regressions\n- whether repeated small compromises added up to a larger pattern problem\n- whether the implementation still matches intended plan boundaries\n- whether any proof gaps should block shipping versus merely lower confidence\n\nClassify each issue by severity:\n- Red: blocks readiness\n- Orange: should be fixed before shipping if possible\n- Yellow: acceptable tension or bounded follow-up\n\nWorking notes:\n- Regressions found\n- Drift assessment\n- Severity-classified gaps",
+      "agentRole": "You are looking for the subtle ways a task can go wrong even when individual slices seemed fine.",
+      "requireConfirmation": false
+    },
+    {
+      "id": "step-review-philosophy",
+      "title": "Step 4: Review Philosophy Alignment",
+      "prompt": "Review the final result against the dev's philosophy.\n\nAssess:\n- which principles are clearly satisfied\n- which tensions remain intentionally accepted\n- which philosophy violations should be severity Red, Orange, or Yellow\n- whether any philosophy concern changes the readiness verdict\n\nWorking notes:\n- Satisfied principles\n- Accepted tensions\n- Severity-classified philosophy concerns",
+      "agentRole": "You are checking whether the finished result still reflects the dev's standards.",
+      "requireConfirmation": false
+    },
+    {
+      "id": "step-deliver",
+      "title": "Step 5: Deliver Final Verification Findings",
+      "prompt": "Create `{deliverableName}`.\n\nRequired structure:\n- Readiness Claims and Proof Matrix\n  - claim\n  - supporting evidence\n  - proof strength (strong / partial / missing)\n  - proof gap\n- Validation Evidence Summary\n- Severity-Classified Gaps\n  - Red (blocking)\n  - Orange (should fix)\n  - Yellow (accepted tension / follow-up)\n- Regression / Drift Review\n- Philosophy Alignment\n- Recommended Fixes\n- Readiness Verdict\n  - Ready\n  - Ready with Accepted Tensions\n  - Not Ready\n\nOptimize for a compact artifact the main workflow can use to decide whether to fix, re-verify, or hand off.",
+      "agentRole": "You are delivering a verification artifact the main workflow can interpret and act on.",
+      "requireConfirmation": false
+    }
+  ]
+}

package/workflows/routines/hypothesis-challenge.json

@@ -1,113 +1,69 @@
 {
   "id": "routine-hypothesis-challenge",
   "name": "Hypothesis Challenge Routine",
-  "version": "1.1.0",
-  "description": "Adversarial testing of hypotheses using an Ideate -> Plan -> Execute strategy. Configurable rigor levels (1-5) allow for progressively deeper skepticism and stress testing.",
+  "version": "1.0.0",
+  "description": "Lean adversarial review of a hypothesis, recommendation, or diagnosis. Produces the strongest counter-argument, exposes weak assumptions and evidence gaps, identifies likely failure modes, and defines the critical tests needed to keep, revise, or reject the current claim.",
   "clarificationPrompts": [
-    "What hypotheses or assumptions should I challenge?",
-    "What rigor level do you need? (1=Surface, 3=Deep, 5=Maximum)",
-    "What evidence supports these hypotheses?",
-    "What context should I consider? (bug description, findings, constraints)"
+    "What hypothesis, recommendation, or diagnosis should I challenge?",
+    "What evidence currently supports it?",
+    "What depth do you need? (QUICK / STANDARD / THOROUGH; legacy rigor=1/3/5 is still accepted for compatibility)",
+    "What artifact name should I produce?"
   ],
   "preconditions": [
-    "Hypotheses or assumptions are clearly stated",
-    "Rigor level (1-5) is specified",
-    "Supporting evidence is available",
-    "Agent has read access to relevant context"
+    "A target hypothesis, recommendation, or diagnosis is available",
+    "Supporting evidence or reasoning is available",
+    "Relevant context is available for challenge"
   ],
   "metaGuidance": [
-    "**ROUTINE PURPOSE:**",
-    "This routine performs adversarial testing. It separates strategy (Ideating attack vectors) from execution (Challenging/Stress Testing).",
-    "**PHASES:**",
-    "1. IDEATE: Brainstorm attack vectors and common flaws",
-    "2. STRATEGIZE: Define the challenge plan for the requested rigor",
-    "3. EXECUTE: Run the challenge (Surface/Deep/Max)",
-    "4. SYNTHESIZE: Deliver verdicts and alternative explanations",
-    "**CORE PRINCIPLES:**",
-    "- ADVERSARIAL: Actively try to disprove, don't confirm",
-    "- SYSTEMATIC: Challenge assumptions, logic, and evidence",
-    "- CONSTRUCTIVE: Goal is to strengthen truth, not just destroy"
+    "PURPOSE: strengthen truth by trying to break the current story.",
+    "ROLE: you are an adversarial reviewer, not a neutral summarizer.",
+    "SCOPE: challenge assumptions, evidence quality, and likely failure modes.",
+    "DISCIPLINE: produce concrete counter-arguments and critical tests, not vague skepticism.",
+    "DEPTH: QUICK = strongest counter only; STANDARD = counter + failure-mode review; THOROUGH = add alternative explanations and sharper discrimination tests.",
+    "COMPATIBILITY: prefer depth language (QUICK / STANDARD / THOROUGH). Treat legacy rigor values as adapter input, not the primary model."
   ],
   "steps": [
     {
-      "id": "step-0-ideate-vectors",
-      "title": "Step 0: Ideate Challenge Strategy",
-      "prompt": "**IDEATE ATTACK VECTORS**\n\nBefore diving into specific hypotheses, step back and look at the whole picture.\n\n**YOUR MISSION:** Brainstorm ways to break these hypotheses.\n\n**EXECUTE:**\n1. Review all hypotheses together\n2. Identify shared assumptions (do they all assume X?)\n3. Brainstorm classes of failure (Concurrency? State? Logic?)\n4. Identify weak points in the evidence provided\n\n**REFLECT:**\n- Are these hypotheses too similar?\n- Are they missing a whole category of explanation?\n- What is the most likely \"unknown unknown\"?\n\n**WORKING NOTES:**\n- Common Assumptions\n- Potential Attack Vectors (e.g., Race Conditions, Edge Cases)\n- Evidence Weaknesses",
-      "agentRole": "You are a red-team strategist planning your attack.",
-      "requireConfirmation": false,
-      "guidance": [
-        "BRAINSTORM: Look for systemic issues first",
-        "CATEGORIES: Think in categories (Logic, Data, Timing, Environment)",
-        "SKEPTICISM: Assume the hypotheses are wrong. Why?"
-      ]
+      "id": "step-load-target",
+      "title": "Step 1: Load the Target Claim and Evidence",
+      "prompt": "Load the current claim you are challenging.\n\nCapture:\n- the target claim in one sentence\n- the main assumptions it depends on\n- the strongest supporting evidence currently available\n- what result would count as meaningful disproof\n\nKeep this step compact and precise. The goal is to define exactly what is under challenge and what would falsify it.",
+      "agentRole": "You are defining exactly what claim is on trial and what would falsify it.",
+      "requireConfirmation": false
     },
     {
-      "id": "step-1-plan-challenge",
-      "title": "Step 1: Plan Challenge Tactics",
-      "prompt": "**DEFINE CHALLENGE PLAN**\n\nNow define your specific tactics for the requested rigor level.\n\n**YOUR MISSION:** Create a concrete plan to test these hypotheses.\n\n**EXECUTE:**\n1. Map attack vectors to specific hypotheses\n2. Define **Key Questions** to answer\n3. Select **Stress Tests** or **Counter-Examples** to search for\n4. Define criteria for \"disproof\"\n\n**DELIVERABLE:**\nCreate `challenge-strategy.md`:\n- Attack Plan for each Hypothesis\n- Key Assumptions to Probe\n- Required Evidence check",
-      "agentRole": "You are a lead auditor defining the scope of the audit.",
-      "requireConfirmation": false,
-      "guidance": [
-        "TACTICS: Be specific (e.g., \"Check for null user in auth flow\")",
-        "CRITERIA: What would convince you the hypothesis is false?"
-      ]
+      "id": "step-break-claim",
+      "title": "Step 2: Find the Strongest Counter-Argument",
+      "prompt": "Find the strongest case against the current claim.\n\nChallenge it by asking:\n- What is the strongest counter-argument or competing explanation?\n- What evidence could be interpreted differently?\n- What hidden assumption is carrying too much weight?\n- What would a sharp skeptic say first?\n\nOptimize for the single strongest attack, not a long list of weak objections.",
+      "agentRole": "You are a sharp skeptic trying to overturn the current favorite with the strongest available attack.",
+      "requireConfirmation": false
     },
     {
-      "id": "step-execute-rigor-1",
-      "title": "Execution: Rigor 1 (Surface)",
-      "runCondition": {
-        "var": "rigor",
-        "gte": 1
-      },
-      "prompt": "**EXECUTE RIGOR 1: SURFACE CHALLENGE**\n\nExecute your challenge plan at Rigor 1 (Surface).\n\n**MISSION:** Identify obvious flaws and simple counter-examples.\n\n**EXECUTE:**\n1. Follow `challenge-strategy.md`\n2. Check for obvious logical gaps\n3. Identify simple counter-examples\n4. Check for Occam's Razor alternatives\n\n**WORKING NOTES:**\n- Obvious Flaws\n- Simple Counter-Examples\n- Better Alternatives",
-      "agentRole": "You are a skeptical reviewer looking for quick wins.",
-      "requireConfirmation": false,
-      "guidance": [
-        "FOCUS: Obvious errors, simple logic gaps",
-        "SPEED: Don't dig deep yet, look for low-hanging fruit"
-      ]
-    },
-    {
-      "id": "step-execute-rigor-3",
-      "title": "Execution: Rigor 3 (Deep)",
-      "runCondition": {
-        "var": "rigor",
-        "gte": 3
-      },
-      "prompt": "**EXECUTE RIGOR 3: DEEP CHALLENGE**\n\nExecute your challenge plan at Rigor 3 (Deep Analysis).\n\n**MISSION:** Deeply challenge with edge cases and hidden assumptions.\n\n**EXECUTE:**\n1. Follow `challenge-strategy.md`\n2. Expose hidden assumptions\n3. Generate systematic edge cases\n4. Analyze timing and environment factors\n\n**WORKING NOTES:**\n- Hidden Assumptions Exposed\n- Edge Case Analysis\n- Environmental Factors",
-      "agentRole": "You are a rigorous auditor digging for structural flaws.",
-      "requireConfirmation": false,
-      "guidance": [
-        "FOCUS: Unstated assumptions, boundary conditions",
-        "DEPTH: trace logic chains to find breaks"
-      ]
+      "id": "step-review-failure-modes",
+      "title": "Step 3: Review Weak Evidence and Likely Failure Modes",
+      "prompt": "Probe where the current claim could fail under realistic pressure.\n\nReview:\n- the weakest part of the evidence chain\n- the most likely failure modes if the claim is wrong\n- edge cases or environmental factors that could invalidate the conclusion\n- contradictions, unexplained facts, or missing proof\n\nFocus on the few things most likely to flip the conclusion rather than exhaustive enumeration.",
+      "agentRole": "You are testing whether the current story survives realistic pressure and real evidence quality.",
+      "requireConfirmation": false
     },
     {
-      "id": "step-execute-rigor-5",
-      "title": "Execution: Rigor 5 (Maximum)",
+      "id": "step-thorough-alternatives",
+      "title": "Step 4: Generate Alternative Explanations and Critical Tests",
       "runCondition": {
-        "var": "rigor",
-        "gte": 5
+        "or": [
+          { "var": "depth", "equals": "THOROUGH" },
+          { "var": "rigorMode", "equals": "THOROUGH" },
+          { "var": "rigor", "gte": 5 }
+        ]
       },
-      "prompt": "**EXECUTE RIGOR 5: MAX CHALLENGE**\n\nExecute your challenge plan at Rigor 5 (Maximum Skepticism).\n\n**MISSION:** Try to break it completely.\n\n**EXECUTE:**\n1. Follow `challenge-strategy.md`\n2. Exhaustive assumption enumeration\n3. Extreme edge cases and adversarial inputs\n4. Second-order effects and chaos scenarios\n\n**WORKING NOTES:**\n- Exhaustive Challenges\n- Extreme Scenarios\n- Disproof Attempts",
-      "agentRole": "You are a relentless adversary trying to prove it wrong.",
-      "requireConfirmation": false,
-      "guidance": [
-        "FOCUS: Breaking the system, extreme edge cases",
-        "MINDSET: Trust nothing, verify everything"
-      ]
+      "prompt": "For THOROUGH review, go beyond the primary counter-argument into alternatives and discrimination strategy.\n\nProduce:\n- the 1-2 strongest alternative explanations or competing hypotheses\n- why each might beat the current claim\n- the critical tests, observations, or traces that would discriminate between them\n- what result would cause you to keep, revise, or reject the current claim\n\nThis step exists to make THOROUGH meaningfully deeper than STANDARD, not just wordier.",
+      "agentRole": "You are building the shortest path to proving which explanation survives.",
+      "requireConfirmation": false
     },
     {
-      "id": "step-synthesize",
-      "title": "Step 5: Synthesize Verdicts",
-      "prompt": "**SYNTHESIZE VERDICTS**\n\nSynthesize all challenges into final verdicts.\n\n**MISSION:** Deliver clear judgments on each hypothesis.\n\n**EXECUTE:**\n1. Review all Working Notes\n2. Assign Verdicts (Keep/Revise/Reject)\n3. Prioritize Alternatives\n4. Define Critical Tests\n\n**DELIVERABLE:**\nCreate `{deliverableName}`:\n- Executive Summary\n- Hypothesis Analysis & Verdicts\n- Critical Tests Needed\n- Recommendations",
-      "agentRole": "You are a judge delivering the final verdict.",
-      "requireConfirmation": false,
-      "guidance": [
-        "VERDICTS: Be decisive based on evidence",
-        "ALTERNATIVES: Propose concrete, better explanations",
-        "ACTION: What specifically needs to be tested?"
-      ]
+      "id": "step-deliver",
+      "title": "Step 5: Deliver the Challenge Verdict",
+      "prompt": "Create `{deliverableName}`.\n\nRequired structure:\n- Target Claim\n- Strongest Counter-Argument\n- Weak Assumptions / Evidence Gaps\n- Likely Failure Modes\n- Alternative Explanations (if explored)\n- Critical Tests\n- Verdict: Keep / Revise / Reject\n- Next Action\n\nOptimize for a compact artifact that a main workflow can interrogate and act on immediately. Prefer decisive arguments over exhaustive ceremony.",
+      "agentRole": "You are delivering a decisive challenge artifact for the main workflow or caller to synthesize.",
+      "requireConfirmation": false
     }
   ]
-}
+}