valent-pipeline 0.1.11 → 0.1.13

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "valent-pipeline",
-  "version": "0.1.11",
+  "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/knowledge.md

@@ -36,13 +36,11 @@ Read all files in `{curated_files_path}`. Build in-memory index of file names, s
 ### Step 3: Connect to Knowledge Database (Conditional)
 
 **If `{knowledge_mode}` is `sqlite`:**
-Open `{sqlite_db_path}`. Query patterns:
-- Metadata: `SELECT content FROM artifacts WHERE story_id = ? AND artifact_type = ?`
-- Full-text: `SELECT * FROM artifacts_fts WHERE artifacts_fts MATCH ?`
-- Directives: `SELECT * FROM correction_directives WHERE target_agent = ? AND status = 'active'`
-- Cross-story: `SELECT * FROM artifacts WHERE artifact_type = 'bugs' AND created_at > ?`
-
-If database missing or empty, operate in curated-only mode.
+Verify the database is accessible by running:
+```bash
+npx tsx .valent-pipeline/scripts/query-kb.ts --stories
+```
+If it returns results or "No stories in database", the DB is accessible. If the command fails, operate in curated-only mode.
 
 **If `{knowledge_mode}` is `local-docker` or `connect-to-existing` (legacy):**
 Verify ChromaDB at `{chromadb_host}` using v2 API. Base path: `{chromadb_host}/api/v2/tenants/default_tenant/databases/default_database`. If connection fails, operate in curated-only mode.
@@ -54,7 +52,14 @@ Verify ChromaDB at `{chromadb_host}` using v2 API. Base path: `{chromadb_host}/a
 For each incoming query:
 1. Search correction directives for relevant entries
 2. Search curated knowledge files for matching sections
-3. If database connected: use FTS (SQLite) or collection query (ChromaDB)
+3. If database connected (SQLite mode): query using the CLI tool and read stdout for results:
+   - Fetch a specific artifact: `npx tsx .valent-pipeline/scripts/query-kb.ts --artifact --story KANBAN-001 --type reqs-brief`
+   - Fetch directives for an agent: `npx tsx .valent-pipeline/scripts/query-kb.ts --directives --agent BEND`
+   - Full-text search: `npx tsx .valent-pipeline/scripts/query-kb.ts --search "acceptance criteria"`
+   - List artifacts for a story: `npx tsx .valent-pipeline/scripts/query-kb.ts --list --story KANBAN-001`
+   - List all stories: `npx tsx .valent-pipeline/scripts/query-kb.ts --stories`
+   - Cross-story bug search: `npx tsx .valent-pipeline/scripts/query-kb.ts --bugs-since 2026-03-01`
+   If ChromaDB mode: use collection query (ChromaDB)
 4. Compose response: targeted, SHORT (aim ~200 tokens, max 500)
 5. Include source reference: `Source: curated/{file}#section` or `Source: sqlite:artifacts/{story_id}/{type}` or `Source: correction-directives#{directive-id}`
 

package/pipeline/prompts/lead.md

@@ -144,6 +144,12 @@ Before validating story inputs, read `{backlog_path}` and check whether the curr
 
 For `bug` type items (no story input directory), skip Steps 1-3 of kick-off. Instead, read the bug's `description`, `file_ref`, and `source_story` from the backlog. Spawn a targeted agent subset (BEND + CRITIC + QA-B) to fix and verify the bug. After the fix ships, mark the bug `shipped` in the backlog and return to next-item selection.
 
+### Step 0b: Verify Knowledge Database
+
+If `{knowledge_mode}` is `sqlite`, check that `.valent-pipeline/pipeline.db` exists. If it does not exist:
+1. Escalate to user: "Knowledge database not found. Run `/valent-setup-backlog` to initialize the knowledge base and create the database."
+2. Do NOT proceed with story execution until the database exists.
+
 ### Step 1: Validate Story Input
 
 Read story input files from `{story_input_dir}`. Validate against the input contract:
@@ -318,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):**
+**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`. |
 
-| 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. |
+**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.

package/skills/valent-setup-backlog/SKILL.md

@@ -170,6 +170,13 @@ All three agents run in parallel using `model: "haiku"` to minimize cost. Collec
 
 If the repo is empty or brand new (no source code yet), skip the subagents and create minimal placeholder files noting "No existing code detected — Knowledge Agent will update these as stories ship."
 
+### Step 7b: Initialize and Populate Knowledge Database
+
+After writing the curated knowledge files:
+1. Run `valent-pipeline db init` to create the SQLite database if it doesn't exist
+2. Run `npx tsx .valent-pipeline/scripts/embed-sqlite.ts --rebuild --db-path .valent-pipeline/pipeline.db --stories-dir ./stories` to index any existing story artifacts
+3. The database is now ready for the Knowledge Agent to query during story execution
+
 ## Step 8: Report
 
 After writing all files, summarize: