valent-pipeline 0.2.23 → 0.2.24

package/package.json

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

package/pipeline/steps/qa-b/file-bugs.md

@@ -28,10 +28,30 @@ Also file bugs for:
 
 Write to `{story_output_dir}/bugs.md`.
 
-## Step 8: Check for Regressions
+## Step 8: Check for Regressions and Pre-Existing Failures
+
+### 8a: Regressions (previously passing, now failing)
 
 Compare current test results against any previously passing tests. Flag any test that:
 - Previously passed (in prior story executions) and now fails
 - Was not modified as part of this story
 
-Regressions are **always P1 or P2** -- they indicate the story broke existing functionality.
+Regressions are **always P1 or P2** — they indicate the story broke existing functionality.
+
+### 8b: Pre-existing failures
+
+Every failing test in the full suite is a bug — regardless of whether it was already failing before this story. There is no "pre-existing" exemption.
+
+For each failure in the full test suite that was NOT already filed as a bug in Step 7 (story-specific) or Step 8a (regression):
+
+1. File a bug in `bugs.md` with category `pre-existing`
+2. Priority: **P3** (Major) — these are not attributable to the current story but they are real failures that degrade the test suite
+3. Route to BEND (default) or the agent whose code owns the failing test
+4. Include in the execution report under a **Pre-Existing Failures** section:
+   - Total count
+   - Per-file breakdown
+   - Whether the count grew, shrank, or stayed the same compared to the prior story's execution report
+
+**These bugs do NOT block the current story's ship decision.** They are filed for the retrospective to surface and for PM to consider when reprioritizing the backlog. JUDGE evaluates ship readiness based on story-specific bugs (Step 7) and regressions (Step 8a) only.
+
+**But the count matters.** If pre-existing failure count grew since the last shipped story, flag this in the execution report summary as: `⚠ Pre-existing failures grew from {N} to {M} (+{delta})`. This signal feeds into PM's sprint analysis and the retrospective's pattern detection.

package/pipeline/docs/prd-completion-audit-design.md

@@ -1,132 +0,0 @@
-# Design: Post-Implementation PRD Completion Audit
-
-**Status:** Proposal  
-**Scope:** Both epic and project mode  
-**Where it runs:** After all stories ship (Step 5 in valent-run-epic and valent-run-project), before writing the epic/project report.
-
-## Problem
-
-The epics-and-stories breakdown is done once, early, and may miss PRD requirements. Stories can also be cancelled or blocked during execution. There is currently no post-implementation check that verifies the full PRD was actually delivered. The existing pre-implementation readiness check (bmad-check-implementation-readiness) runs before any code is written and only validates that epics *claim* to cover FRs — it doesn't verify that shipped code actually delivers them.
-
-## Proposed Solution
-
-A new orchestration step (`sprint-prd-audit.md`) that runs at epic/project completion. It re-reads the PRD, extracts all functional requirements, and checks each against what was actually shipped — generating gap stories for anything missed.
-
-### Trigger Point
-
-Insert between the sprint loop exit and the report generation:
-
-- **valent-run-epic SKILL.md:** After Step 4 loop exits, before Step 5a (Write Epic Report)
-- **valent-run-project SKILL.md:** After Step 4 loop exits, before Step 5a (Write Project Report)
-
-### Step-by-Step Flow
-
-#### Step 1: Extract PRD Functional Requirements
-
-Read the PRD from `{prd_path}` (already a pipeline config variable). Extract every functional requirement (FR), keyed by FR number or section heading. Build a checklist:
-
-```
-FR1: [requirement text] → status: unchecked
-FR2: [requirement text] → status: unchecked
-...
-```
-
-Also extract non-functional requirements (NFRs) that have testable acceptance criteria.
-
-#### Step 2: Map Shipped Stories to FRs
-
-For each shipped story (from `{epic_progress_path}` or `{backlog_path}` where status = `shipped`):
-
-1. Read the story's `reqs-brief.md` from its output directory
-2. Extract which FRs the story claims to address (REQS agent already tags these during grooming)
-3. Mark those FRs as `covered` in the checklist
-
-For cancelled or blocked stories:
-- Extract their claimed FRs
-- Mark as `gap-cancelled` or `gap-blocked`
-
-#### Step 3: Cross-Reference with Test Evidence
-
-For each `covered` FR, verify that shipped test evidence exists:
-
-1. Query the calibration table for the covering story's test results
-2. Check that the story's QA-B test spec includes tests traceable to the FR
-3. If a FR is "covered" by a story but that story had no tests touching the FR, downgrade to `weak-coverage`
-
-#### Step 4: Generate Gap Report
-
-Produce `prd-audit-report.md` in the epic/project output directory:
-
-```markdown
-# PRD Completion Audit
-
-## Coverage Summary
-- Total FRs: {count}
-- Covered (with tests): {count}
-- Weak coverage (no direct tests): {count}
-- Gaps (cancelled/blocked story): {count}
-- Gaps (never mapped to a story): {count}
-- Coverage: {percentage}%
-
-## Gap Details
-
-### Never Mapped to a Story
-| FR | Requirement | Recommendation |
-|----|------------|----------------|
-| FR7 | [text] | Create story in epic {X} |
-
-### Lost to Cancelled/Blocked Stories
-| FR | Requirement | Original Story | Status | Recommendation |
-|----|------------|---------------|--------|----------------|
-| FR3 | [text] | KANBAN-005 | cancelled | Re-scope into new story |
-
-### Weak Coverage (no direct test evidence)
-| FR | Requirement | Covering Story | Recommendation |
-|----|------------|---------------|----------------|
-| FR9 | [text] | KANBAN-012 | Add targeted tests |
-```
-
-#### Step 5: Generate Gap Stories (Optional, User-Confirmed)
-
-If gaps exist:
-
-1. Present the gap report to the user
-2. Ask: "Generate backlog stories for {N} uncovered requirements?"
-3. If confirmed:
-   - For each gap FR, create a new story in `{backlog_path}` with:
-     - `type: story`
-     - `status: pending`
-     - `epic: {epic_id}` (or assign to most relevant epic in project mode)
-     - `title: "Implement FR{N}: {short description}"`
-     - `priority: {next available}`
-     - `source: prd-audit`
-   - Report the new story IDs
-   - These stories are available for the next epic/project run
-
-### Agent Usage
-
-This step is executed by Lead directly — no new agents needed. Lead already has access to read the PRD, backlog, story output directories, and the calibration DB. The step is read-heavy and analytical, not generative.
-
-If the PRD is large (sharded across multiple files), Lead reads all shards. Context pressure is manageable because this runs after all story agents are torn down.
-
-### Configuration
-
-Add to `pipeline-config.yaml` under `sprint:`:
-
-```yaml
-sprint:
-  prd_audit: true          # enable post-implementation PRD audit (default: true)
-  prd_audit_auto_stories: false  # auto-generate gap stories without user confirmation (default: false)
-```
-
-### Dependencies
-
-- REQS agent must tag FRs in `reqs-brief.md` during grooming (already does this)
-- PRD must use numbered/identifiable FR format (standard PRD template already requires this)
-- Calibration table must have test result data per story (already recorded during sprint review)
-
-### Open Questions
-
-1. Should the audit run per-sprint as well, or only at epic/project completion? Per-sprint would catch drift earlier but adds overhead.
-2. For project mode with multiple PRDs (one per epic), should the audit cross-reference all PRDs or just the one matching each epic?
-3. Should `weak-coverage` FRs block the epic/project completion report, or just be informational?