valent-pipeline 0.2.24 → 0.2.26

package/package.json

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

package/pipeline/docs/communication-standard.md

@@ -342,7 +342,7 @@ The decision block is written to `decisions.md` in the story directory. Any agen
 
 ### Time-box rule
 
-**2 exchanges maximum.** Each consulted agent gets one position statement and one optional rebuttal/clarification. If 2 exchanges do not resolve the issue, it is too complex for agent deliberation -- escalate to the user via the Human Escalation Protocol.
+**2 exchanges maximum.** Each consulted agent gets one position statement and one optional rebuttal/clarification. If 2 exchanges do not resolve the issue, it is too complex for agent deliberation -- escalate to the user via the Headless Escalation Protocol.
 
 ### Governance
 
@@ -352,9 +352,11 @@ The decision block is written to `decisions.md` in the story directory. Any agen
 
 ---
 
-## 7. Human Escalation Protocol
+## 7. Headless Escalation Protocol
 
-When the lead agent needs human input, it outputs a structured escalation block to the CLI and **blocks completely** until the user responds. There is no autonomous continuation on timeout.
+When the lead agent encounters a blocker requiring human input, it classifies the blocker, logs it to `{story_output_dir}/escalation-log.md`, outputs the structured escalation block to CLI for visibility, and moves to the next unblocked story. The pipeline does not pause for skippable blockers. Blocking escalations (quality gate failures) stop the current story cleanly before moving on.
+
+See `lead.md#headless-escalation-protocol` for full classification rules and behavior.
 
 ### Escalation block format
 
@@ -391,12 +393,14 @@ Need: Pick an option or provide guidance
 
 ### Rules
 
-- The pipeline **pauses completely** — no work continues while waiting for user input
-- The user responds directly in the CLI session; the lead incorporates the answer and resumes
+- **Skippable** blockers (missing inputs): pipeline logs the escalation and moves to the next unblocked story
+- **Blocking** failures (quality gate exhaustion): pipeline stops cleanly on this story, persists state, then moves to the next unblocked story if safe
+- If no unblocked stories remain, the pipeline stops cleanly with persisted state
 - Escalation is the **last resort** — the lead should attempt to resolve issues autonomously first (e.g., via the 2-tier rejection circuit breaker or Design Council deliberation)
-- All escalations are logged in `story-report.md` with timestamp, issue, and resolution
+- All escalations are logged in both `{story_output_dir}/escalation-log.md` and `story-report.md`
+- **Resume:** user fixes inputs, sets story status to `pending` in backlog, re-runs pipeline
 
-> **V4 research:** For headless/background pipeline execution, investigate Claude Dispatch (scheduled remote agents) and Slack integration (via MCP) as async escalation channels.
+> **V4 note:** Headless escalation is now implemented (skip-and-log). For async notification when escalations occur during headless runs, investigate Claude Dispatch (scheduled remote agents) and Slack integration (via MCP) as notification channels.
 
 ### Bad example
 
@@ -446,7 +450,9 @@ Agents should verify their output against this checklist before finalizing.
 ### Escalation blocks
 
 - [ ] Uses the exact `[ESCALATION]` format with separator lines
+- [ ] Includes `Classification: skippable | blocking` field
 - [ ] Issue is specific and one-line
 - [ ] Context references a file, not inline detail
 - [ ] Options are numbered, concrete, and actionable
 - [ ] Need statement tells the user exactly what is required
+- [ ] Escalation entry written to `{story_output_dir}/escalation-log.md`