@exaudeus/workrail 3.39.0 → 3.41.0

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

@@ -1,324 +0,0 @@
-{
-  "id": "coding-task-workflow-agentic",
-  "name": "Agentic Task Dev Workflow (v2)",
-  "version": "2.0.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"
-  },
-  "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."
-  ],
-  "clarificationPrompts": [
-    "What are the acceptance criteria and explicit non-goals?",
-    "What invariants must not change?",
-    "Are there rollout, migration, or environment constraints?",
-    "Are there existing repo patterns or examples that must be followed?"
-  ],
-  "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` is the only default human-facing artifact for non-small tasks. `spec.md` or `design.md` are optional and should be created only when they materially improve handoff or reviewability.",
-    "MAIN AGENT OWNS EXECUTION: the main agent owns strategy, decisions, synthesis, and implementation. Delegate only specific cognitive routines via the WorkRail Executor when the step explicitly tells you to.",
-    "SUBAGENT MODEL: use the WorkRail Executor only. Do not refer to or rely on named Builder/Researcher identities.",
-    "AUDITOR MODEL: prefer delegation for auditing, challenge, simulation, and ideation. Do not hand off full task ownership.",
-    "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 as the active evaluation lens. Flag violations by principle name, not as generic feedback. If principles conflict, surface the tension explicitly instead of silently choosing.",
-    "PHILOSOPHY CHECKS: watch for immutability, architectural fixes over patches, illegal states unrepresentable, explicit domain types, reduced path explosion, type safety, exhaustiveness, and errors as data.",
-    "PHILOSOPHY CHECKS (cont): validate at boundaries, fail fast on invariant violations, prefer determinism and small pure functions, use data-driven control flow, DI at boundaries, YAGNI with discipline, and atomicity.",
-    "PHILOSOPHY CHECKS (cont): treat graceful degradation, observability, fakes over mocks, and focused interfaces as first-class review concerns.",
-    "VERTICAL SLICES: plan and implement as independently reviewable and verifiable slices. Parallelize only when targets do not overlap.",
-    "VALIDATION: prefer compile-time safety and deterministic verification. Use tests and type/build validation as the first-line proof.",
-    "TRIGGERS: WorkRail can only react to explicit fields the agent emits. Use narrow observable fields, not hidden introspection, to decide when fresh cognitive review is needed.",
-    "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."
-  ],
-  "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.\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
-    },
-    {
-      "id": "phase-0b-minimum-inputs-gate",
-      "title": "Phase 0b: Minimum Inputs Gate",
-      "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"
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-1-context-and-invariants",
-      "title": "Phase 1: Context + Invariants (Notes-First, Parallel-Aware)",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "prompt": "Build the minimum complete understanding needed to design correctly.\n\nDo the main context gathering yourself using tools. Read independent files in parallel when possible.\n\nDeliverable:\n- key entry points and call chain sketch\n- relevant files/modules/functions\n- existing repo patterns with concrete file references\n- testing strategy already present in the repo\n- risks and unknowns\n- explicit invariants and non-goals\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `contextSummary`\n- `candidateFiles`\n- `invariants`\n- `nonGoals`\n- `openQuestions`\n- `contextUnknownCount`\n- `contextAuditNeeded`\n\nRules:\n- answer your own questions with tools whenever possible\n- only keep true human-decision questions in `openQuestions`\n- keep `openQuestions` bounded to the minimum necessary\n- set `contextUnknownCount` to the number of unresolved technical unknowns that still matter\n- set `contextAuditNeeded` to true if understanding still feels incomplete or the call chain is still too fuzzy\n\nMode-adaptive audit:\n- QUICK: no delegation; self-check only\n- STANDARD: if `contextAuditNeeded = true` or risk is High and delegation is available, spawn TWO WorkRail Executors SIMULTANEOUSLY running `routine-context-gathering` with focus=COMPLETENESS and focus=DEPTH, then synthesize both outputs before finishing this step\n- THOROUGH: if delegation is available, spawn TWO WorkRail Executors SIMULTANEOUSLY running `routine-context-gathering` with focus=COMPLETENESS and focus=DEPTH, then synthesize both outputs before finishing this step",
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-1b-retriage-after-context",
-      "title": "Phase 1b: Re-Triage After Context",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "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"
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-2-architecture-decision",
-      "title": "Phase 2: Architecture Decision (Generate • Compare • Challenge • 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",
-      "requireConfirmation": {
-        "or": [
-          {
-            "var": "automationLevel",
-            "equals": "Low"
-          },
-          {
-            "var": "taskComplexity",
-            "equals": "Large"
-          },
-          {
-            "var": "riskLevel",
-            "equals": "High"
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-3-plan-and-test-design",
-      "title": "Phase 3: Slice, Plan, and Test Design",
-      "runCondition": {
-        "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",
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-4-plan-iterations",
-      "type": "loop",
-      "title": "Phase 4: Plan Audit Loop (Audit → Refocus → Decide)",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "loop": {
-        "type": "while",
-        "conditionSource": {
-          "kind": "artifact_contract",
-          "contractRef": "wr.contracts.loop_control",
-          "loopId": "plan_audit_loop"
-        },
-        "maxIterations": 5
-      },
-      "body": [
-        {
-          "id": "phase-4a-plan-audit",
-          "title": "Plan Audit (Correctness + Philosophy + Regression)",
-          "prompt": "Audit the plan before implementation.\n\nAlways perform:\n- completeness / missing work\n- weak assumptions and risks\n- invariant coverage\n- slice boundary quality\n- philosophy alignment against `userRules`\n- regression check against `resolvedFindings` (if present)\n\nPhilosophy rules:\n- flag findings by principle name\n- Red / Orange findings go into `planFindings`\n- Yellow tensions are informational only and do NOT block loop exit\n- if no philosophy principles are configured, say so explicitly and continue\n\nRegression check:\n- if `resolvedFindings` is non-empty, verify previous resolutions still hold\n- if a previously resolved issue has reappeared, add a Critical regression finding\n\nMode-adaptive delegation:\n- QUICK: self-audit only\n- STANDARD: if delegation is available, spawn THREE WorkRail Executors SIMULTANEOUSLY running `routine-plan-analysis`, `routine-hypothesis-challenge`, and `routine-philosophy-alignment`; include `routine-execution-simulation` only when runtime or state-flow risk is material\n- THOROUGH: if delegation is available, spawn FOUR WorkRail Executors SIMULTANEOUSLY running `routine-plan-analysis`, `routine-hypothesis-challenge`, `routine-execution-simulation`, and `routine-philosophy-alignment`\n\nParallel-output synthesis rules:\n- if 2+ auditors flag the same issue, treat it as high priority by default\n- if one auditor flags a concern no one else sees, investigate it but do not automatically block unless it is clearly severe\n- if outputs conflict, document the conflict explicitly and resolve it before finalizing `planFindings`\n- if philosophy review yields Red findings and no stronger conflicting evidence exists, they must remain blocking\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `planFindings`\n- `planAmendments`\n- `planConfidence`\n- `cleanSlateDivergence`\n- `planFindingsCountBySeverity`\n- `philosophyFindingsCountBySeverity`\n- `auditConsensusLevel`\n\nRules:\n- use the main agent as synthesizer and final decision-maker\n- do not delegate sequentially when the audit routines are independent",
-          "requireConfirmation": false
-        },
-        {
-          "id": "phase-4b-refocus",
-          "title": "Refocus Plan and Track Resolved Findings",
-          "prompt": "Apply plan amendments and refocus.\n\nDo:\n- update `implementation_plan.md` to incorporate `planAmendments`\n- update `slices` if the plan shape changed\n- extract out-of-scope work into `followUpTickets`\n- maintain `resolvedFindings` as an array of { finding, resolution, iteration }\n- cap `resolvedFindings` at 10 entries, dropping oldest first\n\nSet these keys in the next `continue_workflow` call's `context` object:\n- `resolvedFindings`\n- `followUpTickets`\n\nRule:\n- do not silently accept plan drift; if the audit changed the shape of the work, reflect it in the plan artifact immediately",
-          "requireConfirmation": false
-        },
-        {
-          "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```",
-          "requireConfirmation": true,
-          "outputContract": {
-            "contractRef": "wr.contracts.loop_control"
-          }
-        }
-      ]
-    },
-    {
-      "id": "phase-5-planning-ready-gate",
-      "title": "Phase 5: Planning Ready Gate",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "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"
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-6-small-task-fast-path",
-      "title": "Phase 6: Small Task Fast Path",
-      "runCondition": {
-        "var": "taskComplexity",
-        "equals": "Small"
-      },
-      "prompt": "For Small tasks:\n- confirm target locations and relevant patterns with tools\n- implement the smallest correct change\n- verify with tests/build or a deterministic check\n- apply the user's coding philosophy as the active review lens before finalizing\n- provide a concise PR-ready summary\n\nDo not create heavyweight planning artifacts unless risk unexpectedly grows.",
-      "requireConfirmation": false
-    },
-    {
-      "id": "phase-7-implement-slices",
-      "type": "loop",
-      "title": "Phase 7: Implement Slice-by-Slice",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "loop": {
-        "type": "forEach",
-        "items": "slices",
-        "itemVar": "currentSlice",
-        "indexVar": "sliceIndex",
-        "maxIterations": 20
-      },
-      "body": [
-        {
-          "id": "phase-7a-slice-preflight",
-          "title": "Slice Preflight",
-          "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
-              }
-            ]
-          }
-        },
-        {
-          "id": "phase-7b-implement-slice",
-          "title": "Implement Slice",
-          "prompt": "Implement slice `{{currentSlice.name}}`.\n\nMain-agent-first rules:\n- the main agent owns implementation\n- do not hand off slice ownership to a Builder identity\n- if you need specialized help, delegate only targeted cognitive routines via the WorkRail Executor (for example challenge, simulation, philosophy review, or plan analysis), not the whole slice\n- read independent files in parallel when possible\n- implement incrementally and keep the slice within its intended boundary\n- apply the user's coding philosophy as the active implementation lens\n\nDuring implementation, explicitly track whether the slice required:\n- a new special-case (`specialCaseIntroduced`)\n- an unplanned abstraction (`unplannedAbstractionIntroduced`)\n\nIf this slice uses work packages, use them as guidance, not ceremony.",
-          "requireConfirmation": false
-        },
-        {
-          "id": "phase-7c-verify-slice",
-          "title": "Verify Slice",
-          "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
-              }
-            ]
-          }
-        },
-        {
-          "id": "phase-7d-drift-and-pr-gate",
-          "title": "Drift and PR Gate",
-          "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
-              }
-            ]
-          }
-        }
-      ]
-    },
-    {
-      "id": "phase-8-integration-verification",
-      "title": "Phase 8: Integration Verification",
-      "runCondition": {
-        "var": "taskComplexity",
-        "not_equals": "Small"
-      },
-      "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
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-9-final-handoff",
-      "title": "Phase 9: Final Handoff",
-      "prompt": "Provide final validation and handoff.\n\nInclude:\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\nRules:\n- keep the final handoff concise and executive-level\n- `implementation_plan.md` should only be updated if slices or boundaries changed during execution\n- do not auto-merge or push unless the user explicitly asks",
-      "requireConfirmation": true
-    }
-  ]
-}