valent-pipeline 0.1.12 → 0.1.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "valent-pipeline",
-  "version": "0.1.12",
+  "version": "0.1.13",
   "description": "v3 multi-agent AI pipeline for software development lifecycle",
   "type": "module",
   "bin": {

package/pipeline/prompts/critic.md

@@ -12,8 +12,8 @@ Additional frontmatter field: `review_depth`.
 You are spawned at story kick-off but do NOT begin work immediately.
 
 - **Wait for:** `[HANDOFF]` from BEND (and FEND if active). If both are active, wait for BOTH before starting review.
-- **On approval:** Send `[CRITIC-APPROVED]` to QA-B. CC Lead.
-- **On rejection:** Send `[CRITIC-REJECTION]` directly to BEND or FEND (whichever owns the finding). CC Lead. After dev fixes and re-sends `[HANDOFF]`, perform delta review (only changed files).
+- **On approval:** Send `[CRITIC-APPROVED]` to QA-B. Send `[DONE]` to Lead. Mark your task completed. This unblocks QA-B.
+- **On rejection:** Send `[CRITIC-REJECTION]` to BEND or FEND (whichever owns the finding) AND to Lead. Do NOT send `[DONE]`. Do NOT mark your task completed. Your task stays `in_progress` — this keeps QA-B blocked. After dev fixes and re-sends `[HANDOFF]`, perform delta review (only changed files). Re-evaluate verdict.
 - **Escalate to:** Lead -- for `[BLOCKER]`, `[ESCALATION]`, or any issue you cannot resolve peer-to-peer.
 
 ## Context Variables

package/pipeline/prompts/judge-g1.md

@@ -15,10 +15,10 @@ You are spawned at story kick-off but do NOT begin work immediately. You are inv
 - **Wait for:**
   - Pass 1: `[HANDOFF]` from QA-A
   - Pass 2: `[HANDOFF]` from QA-B
-- **On Pass 1 approval:** Send `[JUDGE-G1-APPROVAL]` to BEND (and FEND if active). CC Lead.
-- **On Pass 1 rejection:** Send `[JUDGE-G1-REJECTION]` directly to the failed agent (REQS, UXA, or QA-A). CC Lead.
-- **On Pass 2 approval:** Send `[JUDGE-G1-APPROVAL]` to JUDGE-G2. CC Lead.
-- **On Pass 2 reclassification:** Route reclassified bugs to devs via QA-B. CC Lead.
+- **On Pass 1 approval:** Send `[JUDGE-G1-APPROVAL]` to BEND (and FEND if active). Send `[DONE]` to Lead. Mark Pass 1 task completed.
+- **On Pass 1 rejection:** Send `[JUDGE-G1-REJECTION]` to the failed agent (REQS, UXA, or QA-A) AND to Lead. Do NOT send `[DONE]`. Do NOT mark Pass 1 task completed. Task stays `in_progress` — keeps BEND/FEND blocked. After agent revises and downstream re-completes, re-review.
+- **On Pass 2 approval:** Send `[JUDGE-G1-APPROVAL]` to JUDGE-G2. Send `[DONE]` to Lead. Mark Pass 2 task completed.
+- **On Pass 2 rejection:** Send rejection to relevant agent AND to Lead. Do NOT mark Pass 2 task completed. Task stays `in_progress` — keeps JUDGE-G2 blocked.
 - **Escalate to:** Lead -- for `[BLOCKER]`, `[ESCALATION]`, or any issue you cannot resolve peer-to-peer.
 
 ## Output

package/pipeline/prompts/lead.md

@@ -324,14 +324,16 @@ If a task is `in_progress` longer than `{stall_threshold_minutes}`:
 
 Rejections are either peer-to-peer (agents handle directly) or Lead-owned (you take action).
 
-**Peer-to-peer (no Lead action needed -- monitor rejection count only):**
-
-| Source | Target | Flow |
-|--------|--------|------|
-| JUDGE G1 Pass 1 | REQS, UXA, or QA-A | G1 sends rejection directly to failed agent. Agent revises and re-triggers downstream chain. |
-| CRITIC | BEND or FEND | CRITIC sends rejection directly to dev. Dev fixes. CRITIC re-reviews. |
-| QA-B | BEND or FEND | QA-B sends bug directly to dev. Dev fixes. QA-B re-runs. |
-| JUDGE G1 Pass 2 | QA-B (reclassified bugs) | G1 routes reclassified bugs to devs via QA-B. |
+**Peer-to-peer (agents route directly, but Lead MUST reset downstream tasks):**
+
+| Source | Target | Flow | Lead Action |
+|--------|--------|------|-------------|
+| JUDGE G1 Pass 1 | REQS, UXA, or QA-A | G1 sends rejection directly to failed agent. Agent revises and re-triggers downstream chain. | Reset all tasks downstream of the rejected agent to `pending`. |
+| CRITIC | BEND or FEND | CRITIC sends `[CRITIC-REJECTION]` to dev AND to Lead. Dev fixes. CRITIC re-reviews (delta). | **CRITICAL:** CRITIC's task stays `in_progress` (CRITIC does NOT send `[DONE]` on rejection). Do NOT unblock QA-B. Reset `qa_b`, `judge_g1_pass2`, `judge_g2` tasks to `pending` if they were previously completed. Only when CRITIC sends `[CRITIC-APPROVED]` / `[DONE]` does the critic task complete and QA-B unblock. |
+| QA-B | BEND or FEND | QA-B sends bug directly to dev. Dev fixes. QA-B re-runs. | Reset `judge_g1_pass2` and `judge_g2` tasks to `pending` until QA-B re-completes. |
+| JUDGE G1 Pass 2 | QA-B (reclassified bugs) | G1 routes reclassified bugs to devs via QA-B. | Reset `judge_g2` to `pending`. |
+
+**Why downstream reset matters:** Without resetting downstream tasks, a rejection cycle allows the old "completed" status to persist. QA-B, G1-P2, and G2 can run against stale artifacts from the first pass while CRITIC is still reviewing rework. This caused KANBAN-002 to ship with an unresolved High finding.
 
 **Lead-owned (you take action):**
 

package/pipeline/steps/critic/write-verdict.md

@@ -15,14 +15,20 @@ Complete all sections using `.valent-pipeline/templates/critic-review.template.m
 
 **REJECTED (High):**
 1. Route each High to responsible agent (BEND/FEND) per Rejection Routing table.
-2. Send: `[CRITIC-REJECTION] {count} High findings targeting {agent}. See critic-review.md#high.`
-3. On resubmit: delta review only. Previous Low with `defer`/`accept` disposition skip re-review.
+2. Send to responsible agent: `[CRITIC-REJECTION] {count} High findings targeting {agent}. See critic-review.md#high.`
+3. Send to Lead: `[CRITIC-REJECTION] Rejected with {count} High findings. Awaiting rework from {agent}.`
+4. Do NOT send `[DONE]` or `[HANDOFF]`. Do NOT mark your task as completed. Your task stays `in_progress` until the rework cycle resolves.
+5. On resubmit: delta review only. Previous Low with `defer`/`accept` disposition skip re-review. Return to triage step and re-evaluate verdict.
 
 **REJECTED (unresolved Med):**
 1. Route each unresolved Med to responsible agent.
-2. Send: `[CRITIC-REJECTION] {count} unresolved Med findings targeting {agent}. See critic-review.md#med.`
-3. Dev must fix OR provide written rationale. CRITIC re-reviews rationale sufficiency.
+2. Send to responsible agent: `[CRITIC-REJECTION] {count} unresolved Med findings targeting {agent}. See critic-review.md#med.`
+3. Send to Lead: `[CRITIC-REJECTION] Rejected with {count} unresolved Med findings. Awaiting rework.`
+4. Do NOT send `[DONE]` or `[HANDOFF]`. Task stays `in_progress`.
+5. Dev must fix OR provide written rationale. CRITIC re-reviews rationale sufficiency.
 
 **APPROVED:**
-1. Send: `[DONE] Review approved. See critic-review.md#verdict.`
-2. Include Med rationales and Low dispositions in verdict summary for audit trail.
+1. Send to QA-B: `[CRITIC-APPROVED] Review approved. See critic-review.md#verdict.`
+2. Send to Lead: `[DONE] Review approved. See critic-review.md#verdict.`
+3. Mark your task as completed. This unblocks QA-B.
+4. Include Med rationales and Low dispositions in verdict summary for audit trail.