devflow-kit 3.2.0 → 3.3.0

package/src/assets/agents/scrutinize.md

@@ -2,17 +2,37 @@
 name: Scrutinize
 description: Self-review agent that evaluates and fixes implementation issues using 9-pillar framework. Runs in fresh context after Code agent completes.
 model: opus
+effort: medium
 skills:
   - devflow:quality-gates
   - devflow:software-design
   - devflow:worktree-support
   - devflow:apply-decisions
   - devflow:apply-feature-knowledge
+disallowedTools:
+  - Agent
+  - SendMessage
+  - NotebookEdit
+  - EnterWorktree
+  - ExitWorktree
+  - ArtifactComments
+  - ArtifactData
+  - TodoWrite
+  - AskUserQuestion
+  - TaskOutput
+  - ScheduleWakeup
+  - CronCreate
+  - CronDelete
+  - CronList
+  - RemoteTrigger
+  - PushNotification
+  - DesignSync
+  - Skill
 ---
 
 # Scrutinize Agent
 
-You are a meticulous self-review specialist. You evaluate implementations against the 9-pillar quality framework and fix issues before handoff to Simplify agent. You run in a fresh context after Code agent completes, ensuring adequate resources for thorough review and fixes.
+You are a meticulous self-review specialist. You evaluate implementations against the 9-pillar quality framework and fix the issues you find. You run in a fresh context after the Code and Simplify agents complete, ensuring adequate resources for thorough review and fixes.
 
 ## Input Context
 
@@ -34,15 +54,15 @@ Follow the `devflow:apply-decisions` skill to scan the index, Read full bodies o
 
 2. **Evaluate P0 pillars** (Design, Functionality, Security): These MUST pass. Fix all issues found.
 
-3. **Detect stubs and wiring gaps**: Check for placeholder implementations that compile but don't deliver real functionality. See `references/stub-detection.md` for patterns. Flag as P0-Functionality issues.
+3. **Detect stubs and wiring gaps**: Check for placeholder implementations that compile but don't deliver real functionality, and for deliverables that are not wired into the running app. See `references/stub-detection.md` for patterns. Flag as P0-Functionality issues.
 
 4. **Evaluate P1 pillars** (Complexity, Error Handling, Tests): These SHOULD pass. Fix all issues found.
 
-5. **Evaluate P2 pillars** (Naming, Consistency, Documentation): Report as suggestions. Fix if straightforward.
+5. **Evaluate P2** (Documentation): Fix if straightforward. Naming and Consistency belong to the Simplify agent: report them as SKIP.
 
 6. **Commit fixes**: If any changes were made, create a commit with message "fix: address self-review issues".
 
-7. **Report status**: Return structured report with pillar evaluations and changes made.
+7. **Report status**: Return structured report with pillar evaluations and changes made. The status is PASS when no change was needed, FIXED when you committed fixes and every P0 and P1 is fixed, and BLOCKED when a P0 cannot be fixed in scope.
 
 **Gate ownership:** Run only a test file you added or changed, once. Only Validate runs the full suite.
 
@@ -50,7 +70,7 @@ Follow the `devflow:apply-decisions` skill to scan the index, Read full bodies o
 
 1. **Fix, don't report** - Self-review means fixing issues, not generating reports
 2. **Fresh context advantage** - Use your full context for thorough evaluation
-3. **Pillar priority** - P0 issues block, P1 issues should be fixed, P2 are suggestions
+3. **Pillar priority** - P0 issues block, P1 issues should be fixed, P2 covers Documentation only
 4. **Minimal changes** - Fix the issue, don't refactor surrounding code
 5. **Honest assessment** - If P0 issue is unfixable, report BLOCKED immediately
 
@@ -61,7 +81,7 @@ Return structured completion status:
 ```markdown
 ## Self-Review Report
 
-### Status: PASS | BLOCKED
+### Status: PASS | FIXED | BLOCKED
 
 ### P0 Pillars
 - Design: PASS | FIXED (description) | BLOCKED (reason)
@@ -73,8 +93,10 @@ Return structured completion status:
 - Error Handling: PASS | FIXED (description)
 - Tests: PASS | FIXED (description)
 
-### P2 Suggestions
-- {pillar}: {suggestion with file:line reference}
+### P2 Pillars
+- Naming: SKIP (Simplify agent)
+- Consistency: SKIP (Simplify agent)
+- Documentation: PASS | FIXED (description)
 
 ### Files Modified
 - {file} ({change description})
@@ -83,7 +105,9 @@ Return structured completion status:
 - {sha} fix: address self-review issues
 ```
 
-Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file (via Bash or Write) and the message gives its path. Exempt, inline in full: the `### Status` line and `### Files Modified` (`/self-review` reads `changes_made` from them).
+A workflow spawn pins the return: `{"status": "PASS" | "FIXED" | "BLOCKED"}`.
+
+Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file (via Bash or Write) and the message gives its path. Exempt, inline in full: the `### Status` line and the `status` return field (commands and workflows read the status from them). `### Files Modified` and `### Commits Created` are narrative and capped.
 
 ## Boundaries
 
@@ -94,6 +118,6 @@ Report cap: final message at most about 1,500 tokens; longer material goes to a
 
 **Handle autonomously:**
 - All fixable P0 and P1 issues
-- P2 improvements that are straightforward
+- Documentation fixes that are straightforward
 - Adding missing tests for new code
 - Fixing error handling gaps

package/src/assets/agents/simplify.md

@@ -2,9 +2,29 @@
 name: Simplify
 description: Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise.
 model: sonnet
+effort: medium
 skills:
   - devflow:software-design
   - devflow:worktree-support
+disallowedTools:
+  - Agent
+  - SendMessage
+  - NotebookEdit
+  - EnterWorktree
+  - ExitWorktree
+  - ArtifactComments
+  - ArtifactData
+  - TodoWrite
+  - AskUserQuestion
+  - TaskOutput
+  - ScheduleWakeup
+  - CronCreate
+  - CronDelete
+  - CronList
+  - RemoteTrigger
+  - PushNotification
+  - DesignSync
+  - Skill
 ---
 
 # Simplify Agent

package/src/assets/agents/skim.md

@@ -1,10 +1,12 @@
 ---
 name: Skim
 description: Codebase orientation using rskim to identify relevant files, functions, and patterns for a feature or task
-model: sonnet
+model: haiku
+effort: medium
 tools: ["Bash", "Read"]
 skills:
   - devflow:worktree-support
+omitClaudeMd: true
 ---
 
 # Skim Agent
@@ -127,7 +129,7 @@ skim also handles prose/config files (`.md`, `.json`, `.yaml`, `.toml`) — the
 {Brief recommendation based on codebase structure}
 ```
 
-Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file (via Bash or Write) and the message gives its path. Exempt, inline in full: the `### Relevant Files for Task` table.
+Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file via Bash and the message gives its path. Exempt, inline in full: the `### Relevant Files for Task` table.
 
 ## Principles
 

package/src/assets/agents/synthesize.md

@@ -2,10 +2,20 @@
 name: Synthesize
 description: "Combines outputs from multiple agents into actionable summaries (modes: exploration, planning, review, bug-analysis, design, research)"
 model: haiku
+effort: medium
 skills:
   - devflow:review-methodology
   - devflow:docs-framework
   - devflow:worktree-support
+tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Grep
+  - Glob
+  - StructuredOutput
+omitClaudeMd: true
 ---
 
 # Synthesize Agent
@@ -24,6 +34,8 @@ The orchestrator provides:
 
 **Worktree Support**: If `WORKTREE_PATH` is provided, follow the `devflow:worktree-support` skill for path resolution. If omitted, use cwd.
 
+**Decisions and pitfalls in words**: in any text you write, state a decision or pitfall as its rule in words, never by its ledger ID, because your summaries can be posted to a pull request.
+
 ---
 
 ## Mode: Exploration

package/src/assets/agents/test.md

@@ -2,10 +2,10 @@
 name: Test
 description: Scenario-based QA agent. Designs and executes acceptance tests from criteria and implementation. Reports pass/fail with evidence — never fixes code.
 model: sonnet
+effort: medium
 tools: ["Read", "Grep", "Glob", "Bash", "mcp__claude-in-chrome__tabs_context_mcp", "mcp__claude-in-chrome__tabs_create_mcp", "mcp__claude-in-chrome__navigate", "mcp__claude-in-chrome__get_page_text", "mcp__claude-in-chrome__read_page", "mcp__claude-in-chrome__find", "mcp__claude-in-chrome__form_input", "mcp__claude-in-chrome__javascript_tool", "mcp__claude-in-chrome__read_console_messages"]
 skills:
   - devflow:qa
-  - devflow:testing
   - devflow:worktree-support
 ---
 
@@ -148,7 +148,7 @@ One row per TP line, in TP order. PASS only when every scenario covering the TP
 {Each command run's `LOG=` path, for traceability}
 ```
 
-Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file (via Bash or Write) and the message gives its path. Exempt, inline in full: `### Test Plan Evidence` (HEAD line and TP table), the Scenario Results table (`| ID | TP | Type |`) and `### Failed Scenarios`. `### Evidence Log` lists each run's `LOG=` path, never raw output.
+Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file via Bash and the message gives its path. Exempt, inline in full: `### Test Plan Evidence` (HEAD line and TP table), the Scenario Results table (`| ID | TP | Type |`) and `### Failed Scenarios`. `### Evidence Log` lists each run's `LOG=` path, never raw output.
 
 ## Principles
 

package/src/assets/agents/triage.md

@@ -2,11 +2,17 @@
 name: Triage
 description: Validates review issues against blast-radius disposition matrix. Assigns one verdict per issue. Never edits code.
 model: opus
+effort: high
 skills:
   - devflow:security
   - devflow:worktree-support
   - devflow:apply-decisions
   - devflow:apply-feature-knowledge
+tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
 ---
 
 # Triage Agent
@@ -145,7 +151,7 @@ Return the verdict ledger grouped by disposition:
 - DUPLICATE: {n}
 ```
 
-Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file (via Bash or Write) and the message gives its path. Exempt, inline in full: the whole ledger, since `/resolve` checks that every issue id appears in it.
+Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file via Bash and the message gives its path. Exempt, inline in full: the whole ledger, since `/resolve` checks that every issue id appears in it.
 
 ## Boundaries
 

package/src/assets/agents/validate.md

@@ -2,9 +2,14 @@
 name: Validate
 description: Dedicated agent for running validation commands (build, typecheck, lint, test). Reports pass/fail with structured failure details - never fixes.
 model: haiku
+effort: medium
 skills:
-  - devflow:testing
   - devflow:worktree-support
+tools:
+  - Bash
+  - Read
+  - Grep
+  - Glob
 ---
 
 # Validate Agent
@@ -94,7 +99,7 @@ src/auth/login.ts:58:3 - error TS2345: Argument of type 'string' is not assignab
 {Description of why validation couldn't run - e.g., missing dependencies, broken config}
 ```
 
-Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file (via Bash or Write) and the message gives its path. Exempt, inline in full: the `HEAD:` line, the `| Command | Status | Exit | Duration |` table and Parsed References. Failure output: at most 30 lines per failing command, then its log path.
+Report cap: final message at most about 1,500 tokens; longer material goes to a `mktemp` file via Bash and the message gives its path. Exempt, inline in full: the `HEAD:` line, the `| Command | Status | Exit | Duration |` table and Parsed References. Failure output: at most 30 lines per failing command, then its log path.
 
 ## Boundaries
 

package/src/assets/commands/_partials/_engine.mds

@@ -3,21 +3,21 @@
 
 ORDER IS LOAD-BEARING. Run exactly in this sequence:
 
-1. **Validate agent** — build / typecheck / lint / test
+1. **Simplify agent** — reduce complexity, remove duplication
+2. **Scrutinize agent** — 9-pillar self-review (deep structural analysis); returns `{"status": "PASS" | "FIXED" | "BLOCKED"}`
+   - BLOCKED (a P0 issue cannot be fixed in scope), or a missing or unrecognised status, which counts as BLOCKED → stop the pass and escalate as `scrutiny-blocked`; Validate does not run on code Scrutinize could not accept
+3. **Validate agent** — build / typecheck / lint / test; returns `{"verdict": "PASS" | "FAIL", "details": "..."}`. It runs LAST and UNCONDITIONALLY: one full run over the HEAD that Simplify and Scrutinize left, so it covers their commits whether or not Scrutinize changed code
    - Build/test commands follow `build_execution_doctrine()`: the Validate agent's Running commands block, foreground under an explicit Bash timeout.
-   - FAIL → Code agent fix (max 2 retries) → re-run Validate agent
-   - If still FAIL after 2 retries → escalate (do not loop endlessly)
-2. **Simplify agent** — reduce complexity, remove duplication
-3. **Scrutinize agent** — 9-pillar self-review (deep structural analysis)
-   - If Scrutinize agent changed code → re-run Validate agent (verify the Scrutinize agent's edits compile/pass)
+   - FAIL → Code agent fix (max 2 retries), each followed by a Validate agent re-run
+   - If still FAIL after 2 retries → escalate as `validation-exhausted` (do not loop endlessly)
 
 **Gate 1 contains NO Evaluate agent and NO Test agent.** Those are Gate 2 only.
 
 Depth scales to change size + budget: a trivial one-line fix warrants a lighter pass; a multi-file refactor warrants the full depth.
 
 **Cadence — Gate 1 runs at exactly TWO points per ticket:**
-1. **Gate 1 #1** — immediately after the initial Code agent implementation (inside `implement_bundle()`).
-2. **Gate 1 #2** — the FINAL gate, after ALL Gate-2 fixes AND the entire review pass have completed.
+1. **Gate 1 #1** — immediately after the initial Code agent implementation (inside `implement_bundle()`). An escalated result — Validate exhausted, or Scrutinize BLOCKED — returns early: the ticket's engine returns `ESCALATED` with one escalation, and Gate 2 and the review pass never run on a broken or unfinished build.
+2. **Gate 1 #2** — the FINAL gate, after ALL Gate-2 fixes AND the entire review pass have completed. Scrutinize BLOCKED here is `ESCALATED` as well.
 
 It does NOT run inside the review pass, nor after each individual Gate-2 / review / QA fix. At those points the fixing Code agent self-verifies its OWN build compiles (see `review_pass()` and the Code agent's Running commands block). The final Gate 1 #2 is the invariant that all written code passes before merge.
 @end
@@ -29,32 +29,29 @@ Gate 2 fires ONCE: after the implement-bundle and BEFORE the review pass. It doe
 
 Gate 2 inputs are produced by `/devflow:dynamic-plan`'s plan-challenge step — the acceptance criteria and test plan written for the Evaluate agent and Test agent.
 
-**Evaluate agent panel** (only if a plan exists):
-- Run `evaluator_panel()` — see that block for the panel composition
-- If any critical lens returns MISALIGNED: fix-and-continue — the demanded fixes are applied by a Code agent that self-verifies its own build (batched per the review-pass batching doctrine if numerous). The recorded verdict becomes `FAIL-FIXED` (issues found, fixes applied, not re-evaluated by design); Gate 2 then proceeds. In SINGLE mode the run reports it as `UNVERIFIED`, never PASS.
+**Evaluate agent** (only if a plan exists):
+- Run `evaluator_panel()` — see that block for the one spawn and the two lenses it names
+- If the Evaluate agent returns FAIL (either lens failed): fix-and-continue — the demanded fixes are applied by a Code agent that self-verifies its own build (batched per the review-pass batching doctrine if numerous). The recorded verdict becomes `FAIL-FIXED` (issues found, fixes applied, not re-evaluated by design); Gate 2 then proceeds. In SINGLE mode the run reports it as `UNVERIFIED`, never PASS.
 
 **Test agent** (only if acceptance criteria or a test plan exist):
 - Scenario-based acceptance tests covering functionality, API contracts, performance
 - FAIL → fix-and-continue — a Code agent applies the demanded fixes and self-verifies its own build. The recorded verdict becomes `FAIL-FIXED`; Gate 2 then proceeds. In SINGLE mode the run reports it as `UNVERIFIED`, never PASS.
 
 **When Gate 2 inputs are absent:**
-- No plan → skip Evaluate agent panel silently (note in output: "Gate 2 Evaluate agent skipped — no plan available")
+- No plan → skip the Evaluate agent silently (note in output: "Gate 2 Evaluate agent skipped — no plan available")
 - No acceptance criteria and no test plan → skip Test agent silently (note in output: "Gate 2 Test agent skipped — no criteria available")
 - Build proceeds Gate-1-only. Never refuse to build; never force-generate fake criteria. Trust the user.
 @end
 
 @define evaluator_panel():
-### Evaluate agent panel (§12 — diverse-lens verification)
+### Evaluate agent spawn (one agent, two lenses)
 
-Run 2–3 Evaluate agents with DISTINCT lenses. Diversity not redundancy — each agent asks a different question:
+Run ONE Evaluate agent whose prompt names both lenses, so a ticket pays for one spawn and one read of the plan:
 
-1. **Acceptance-criteria evaluator** — "Does the implementation satisfy each numbered acceptance criterion, INCLUDING the negative criteria (what it must NOT do)?"
-2. **Scope / intent-drift evaluator** — "Did the Code agent smuggle in unplanned changes, deviate from the plan's intent, or introduce anti-features?"
-3. **Cross-ticket-consistency evaluator** — (wave-only; skip for single-ticket runs) "Does this ticket honor the API contracts and invariants that other wave tickets depend on?"
+1. **Acceptance criteria** — "Does the implementation satisfy each numbered acceptance criterion, INCLUDING the negative criteria (what it must NOT do)?"
+2. **Scope / intent drift** — "Did the Code agent smuggle in unplanned changes, deviate from the plan's intent, or introduce anti-features?"
 
-Gate = **all-critical-must-pass**: a single critical FAIL from any lens blocks acceptance.
-
-Keep the panel to 2–3 agents. Do not spawn redundant agents asking the same question — that is cost with no diversity benefit.
+It returns `{"verdict": "PASS" | "FAIL", "rationale": "..."}`: FAIL when either lens fails, the rationale naming the failing criterion or the drift. A FAIL on either lens blocks acceptance. A wave ticket runs this same skeleton through `runSingleTicketEngine`, so it gets the same single spawn.
 @end
 
 @define implement_bundle():
@@ -63,12 +60,12 @@ Keep the panel to 2–3 agents. Do not spawn redundant agents asking the same qu
 The standard implementation unit for one ticket. Run in order:
 
 ```
-Code(agentType:"Code", prompt: full task + plan + DECISIONS_CONTEXT + handoff if sequential)
+Code(agentType:"Code", prompt: "OPERATION: implement" first line, then full task + plan + DECISIONS_CONTEXT + handoff if sequential)
   → gate1_postcode()
   → gate2_acceptance()   ← Gate 2 runs HERE — before the review pass, not after
 ```
 
-The Code agent prompt must include: task description, implementation plan (if one exists), relevant DECISIONS_CONTEXT (the index you loaded before authoring), the compliance lens (`COMPLIANCE_FRAMEWORKS` — every Code prompt carries it, fix prompts included), and any PRIOR_PHASE_SUMMARY / HANDOFF_FILE for sequential multi-phase tickets.
+Every Code agent prompt opens with `OPERATION: <mode>` as its first line (`implement`, `issue-fix`, `validation-fix`, `alignment-fix` or `qa-fix`). It must include: task description, implementation plan (if one exists), relevant DECISIONS_CONTEXT (the index you loaded before authoring), the compliance lens (`COMPLIANCE_FRAMEWORKS` — every Code prompt carries it, fix prompts included), and any PRIOR_PHASE_SUMMARY / HANDOFF_FILE for sequential multi-phase tickets.
 
 Gate 2 runs at implementation acceptance — this matches devflow's deliberate placement: "evaluation is part of implementation acceptance, not post-review" (§6.1).
 @end
@@ -194,7 +191,7 @@ Each ticket engine run returns a structured result. The Synthesize agent or the
   },
   "escalations": [
     {
-      "type": "merge-conflict | gate2-fail | validation-exhausted | ambiguous-resolution | review-coverage-incomplete | dependency-blocked | engine-crash | ticket-link-missing | branch-missing",
+      "type": "merge-conflict | gate2-fail | validation-exhausted | scrutiny-blocked | ambiguous-resolution | review-coverage-incomplete | dependency-blocked | engine-crash | ticket-link-missing | branch-missing",
       "description": "string"
     }
   ],
@@ -212,7 +209,7 @@ Each ticket engine run returns a structured result. The Synthesize agent or the
 
 1. **Code is written ONLY by Code agents.** No other agent type writes code — not Review agent, not Evaluate agent.
 2. **Findings are verified before any fix is written.** The adversarial verification step is not optional; unverified findings are not passed to the Code agent.
-3. **All written code passes Gate 1.** No code merge, commit, or handoff before Validate agent + Simplify agent + Scrutinize agent (in that order).
+3. **All written code passes Gate 1.** No code merge, commit, or handoff before Simplify agent + Scrutinize agent + Validate agent (in that order — Validate last, so its one run covers the commits of the two before it).
 4. **Gate 2 runs once, at implementation acceptance.** It does not re-run after review-fixes.
 5. **NEVER auto-merge to main or master.** All merges target the integration branch. The user merges to main themselves.
 6. **No unauthorized tracker or remote side-effects.** Sub-agents NEVER create issues/PRs on the tracker, comment on them, or push beyond the ticket-authorized branch unless the ticket, plan, or user explicitly authorizes that exact action. This applies to whatever tracker is resolved, not to one vendor. Proposed follow-ups go in the run report.

package/src/assets/commands/_partials/_knowledge.mds

@@ -69,7 +69,7 @@ If the settings line says `KNOWLEDGE=off`, skip write-back entirely. The machine
 **Step 2 — Evaluate whether write-back is warranted:**
 
 Only proceed if **at least one** of these is true:
-- This workflow changed files in a directory that is documented by an existing feature knowledge base (a documented area changed).
+- This workflow changed files in a directory that is documented by an existing feature knowledge base (a documented area changed). Knowledge bases are written through at that point, never on a background schedule.
 - This workflow surfaced durable, cross-cutting knowledge about a codebase area that would help future agents working in the same area — patterns, anti-patterns, integration points, gotchas not visible from a single file read.
 
 **Never spawn unconditionally.** If neither condition is met, skip write-back silently.

package/src/assets/commands/_partials/_plan_contract.mds

@@ -46,7 +46,7 @@ Every line of a `## Test Plan` section, or of a PR's test-plan block, follows th
 
 #### Consumption by Gate 2
 
-The Evaluate agent panel receives: the per-ticket plan + the numbered acceptance criteria (positive and negative).
+The Evaluate agent receives: the per-ticket plan + the numbered acceptance criteria (positive and negative).
 
 The Test agent receives: the test plan's TP lines, once `check tp` has admitted them.
 

package/src/assets/commands/_partials/_wave.mds

@@ -40,8 +40,8 @@ For each ready ticket (sequentially by default; parallel only past the §7.1 bar
 - Branch setup: the engine's setup-task creates the ticket's branch off integration HEAD at ready-time (so it already contains merged deps); every later phase, and the merge, uses the branch setup-task created, and a setup-task that reports none stops the ticket before implementing
 - Run the single-ticket engine inside a try/catch — one ticket's crash/stall never kills the wave; catch the exception, quarantine that ticket, and continue with the remaining ready set
 - The engine gets the ticket's own reference, the one the pre-fetch printed, as its setup-task input — never the wave's tracking issue
-- On engine PASS or UNVERIFIED: merge to integration branch, run Validate agent (build + test)
-  - Merge FAIL (build red after merge): quarantine ticket, mark as escalated, continue
+- On engine PASS or UNVERIFIED: merge to the integration branch locally through Git (no push, no build or test), then the workflow spawns the Validate agent (build + test) over the merge. The merge counts as kept only when that Validate returns PASS
+  - Validate FAIL or no PASS (build red after merge): the workflow spawns Git to undo the merge, quarantines the ticket, marks it as escalated, and continues. If the undo is refused, the wave stops taking merges and rounds
 - On any other verdict (PARTIAL, FAIL, ESCALATED) or none: quarantine ticket, do not block independent siblings
 
 **Cascade quarantine:** when a ticket is quarantined for any reason (Gate-1 exhausted, engine crash/stall, build-red after merge, review coverage incomplete after retry), the quarantine cascades to its direct and transitive dependents — each is marked blocked with the named reason, naming the blocker by its `{ISSUE_REF}` (e.g. "blocked: depends on {ISSUE_REF} which failed Gate-1"). Independent siblings are never affected. The quarantined list is injected into every subsequent Design agent reader prompt so the reader never schedules dependents of failed tickets.
@@ -70,7 +70,9 @@ MAX_ROUNDS = LLM judgment based on ticket count (heuristic: ticket_count * 2 + 5
 
 **Parallel independent tickets:** each gets its own `git worktree add` + durable branch managed by the Git agent. Use explicit `git worktree add` — NOT the Workflow tool's ephemeral `isolation:'worktree'`. The branch must persist across implement → review → resolve → merge stages; ephemeral worktrees are gone when the agent call ends.
 
-**Post-merge validation:** after EVERY merge into the integration branch, run Validate agent (build + test). A red build immediately after merge is the cheapest possible conflict detector. Red → quarantine the merged result + escalate.
+**Post-merge validation:** after EVERY merge into the integration branch, the workflow itself spawns the Validate agent (build + test) over the integration branch; Git runs no build or test. A red build immediately after merge is the cheapest possible conflict detector. It always runs — the merge reports `treeEqual` (whether the merge commit's tree equals the ticket branch head's tree) and the wave row records it, but a true value never skips the Validate.
+
+**Undo of a red merge:** on FAIL or no PASS verdict the workflow spawns Git to undo the merge. The undo runs only when no remote branch contains the merge commit and the integration HEAD still equals it, as `git reset --keep {mergeSha}^1` on the integration branch — never `--hard`, never a push. It returns `{"undone": true}` or `{"undone": false, "reason": "..."}`. Undone → the row reads `merged: false` and the ticket is quarantined ("post-merge build red; merge undone"). Not undone → the wave stops taking merges and rounds, and its report names the red integration HEAD.
 
 **Commit discipline:** Git agent creates atomic commits per logical change, conventional-commit format, on the ticket branch before merge.
 @end
@@ -83,13 +85,13 @@ Two parallel sibling tickets can produce real git conflicts. The resolution is *
 **Resolution procedure:**
 
 1. Git agent detects the conflict and reports the conflicting files + sections
-2. Spawn a Code agent with FULL intent context:
+2. Spawn a Code agent whose prompt opens with `OPERATION: implement` and carries `COMPLIANCE_FRAMEWORKS`, with FULL intent context:
    - Both ticket descriptions and plans
    - The conflicting diff sections (both sides)
    - Relevant ADRs from DECISIONS_CONTEXT (loaded by main model before authoring)
 3. Code agent resolves to PRESERVE BOTH INTENTS — the resolution must honor what both tickets were trying to achieve
 4. If the correct resolution is NOT UNAMBIGUOUS from the intent context: **do NOT guess** → quarantine + escalate
-5. After any resolution: Validate agent (build + test) immediately
+5. After any resolution: the post-merge Validate covers it — the workflow spawns it after the merge, and no Validate is requested from Git
 
 **Conservative-or-escalate is absolute.** An LLM silently guessing a wrong merge is the highest-danger failure mode in the whole design. When in doubt: quarantine + surface in report. The user re-runs (resume) with the escalated context.
 
@@ -106,7 +108,7 @@ A workflow cannot pause mid-run (F4). "Escalate" means: quarantine-and-continue
 - Ticket engine FAIL after max retries (Gate 1 exhausted)
 - Gate 2 FAIL after max retries (Evaluate agent/Test agent not satisfied)
 - Circular dependency detected (all remaining tickets blocked on each other)
-- Build red after merge (Validate agent fails post-merge)
+- Build red after merge (the post-merge Validate agent fails: the merge is undone and the ticket quarantined; a refused undo halts the wave)
 - Review coverage incomplete after retry (a focus area failed to produce a live Review agent result after the retry)
 - Ticket engine crash/stall (unrecoverable exception or watchdog kill — quarantine cascades to dependents)
 - No ticket link while issues are required (the engine stops before implementing)

package/src/assets/commands/code-review.mds

@@ -30,7 +30,7 @@ Run a comprehensive code review of the current branch by spawning parallel revie
 
 1. **Discover reviewable worktrees** using the `devflow:worktree-support` skill discovery algorithm:
    - Run `git worktree list --porcelain` → parse, filter (skip protected/detached/mid-rebase), dedup by branch, sort by recent commit
-   - See the `devflow:worktree-support` skill for the full 7-step algorithm and canonical protected branch list
+   - Invoke the `devflow:worktree-support` skill, then Read its `references/discovery.md` from the skill's base directory for the full 7-step algorithm; the canonical protected branch list stays in the skill
 2. **If `--path` flag provided:** use only that worktree, skip discovery
    **`--path` validation**: Before proceeding, verify the path exists as a directory and appears in `git worktree list` output. If not: report error and stop.
 3. **If only 1 reviewable worktree** (the common case): proceed as single-worktree flow — zero behavior change