substrate-ai 0.2.19 → 0.2.21

package/dist/run-gmS6DsGT.js

@@ -0,0 +1,7 @@
+import { registerRunCommand, runRunAction } from "./run-BLIgARum.js";
+import "./logger-D2fS2ccL.js";
+import "./event-bus-BMxhfxfT.js";
+import "./decisions-Dq4cAA2L.js";
+import "./operational-CnMlvWqc.js";
+
+export { runRunAction };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "substrate-ai",
-  "version": "0.2.19",
+  "version": "0.2.21",
   "description": "Substrate — multi-agent orchestration daemon for AI coding agents",
   "type": "module",
   "license": "MIT",

package/packs/bmad/prompts/analysis-step-1-vision.md

@@ -8,13 +8,16 @@
 ### Research Context
 {{research_findings}}
 
+### Prior Run Findings
+{{prior_findings}}
+
 ---
 
 ## Mission
 
 Analyze the project concept above and produce a focused **vision analysis**: a clear problem statement and identification of target users. Do NOT define features or metrics yet — those come in a subsequent step.
 
-When Research Context is provided above, ground your vision analysis in that evidence: reference specific market signals, competitive gaps, or feasibility findings to justify your problem statement and user segmentation. When Research Context is empty, proceed using the concept alone — output quality must be identical.
+When Research Context is provided above, ground your vision analysis in that evidence: reference specific market signals, competitive gaps, or feasibility findings to justify your problem statement and user segmentation. When Research Context is empty, proceed using the concept alone — output quality must be identical. When Prior Run Findings are provided, use them as grounding context — recurring implementation patterns indicate where the concept underestimated complexity.
 
 ## Instructions
 

package/packs/bmad/prompts/code-review.md

@@ -14,6 +14,9 @@
 ### Architecture Constraints
 {{arch_constraints}}
 
+### Prior Run Findings
+{{prior_findings}}
+
 ---
 
 ## Mission
@@ -32,8 +35,9 @@ Adversarial code review. Find what's wrong. Validate story claims against actual
    - Whether each AC is actually implemented
    - Whether each `[x]` task is actually done
 
-3. **Execute adversarial review** across 4 dimensions:
+3. **Execute adversarial review** across 5 dimensions:
    - **AC Validation** — Is each acceptance criterion implemented?
+   - **AC-to-Test Traceability** — For each AC, identify the specific test file and test function that validates it. If an AC has no corresponding test evidence, flag it as a major issue: "AC{N} has no test evidence". A test "covers" an AC if it directly exercises the behavior described in the criterion — tangential tests do not count.
    - **Task Audit** — Tasks marked `[x]` that aren't done are BLOCKER issues
    - **Code Quality** — Security, error handling, edge cases, maintainability
    - **Test Quality** — Real assertions, not placeholders or skipped tests

package/packs/bmad/prompts/dev-story.md

@@ -16,6 +16,9 @@
 ### Test Patterns
 {{test_patterns}}
 
+### Prior Run Findings
+{{prior_findings}}
+
 ---
 
 ## Mission

package/packs/bmad/prompts/test-expansion.md

@@ -0,0 +1,65 @@
+# Test Expansion Analysis
+
+## Mission
+
+You are a test coverage analyst. Your mission is to identify gaps in E2E and integration test coverage after a story implementation.
+
+Unit tests alone are insufficient for pipeline confidence. Bugs at module boundaries, DB interactions, and cross-service integrations are systematically missed by unit-only coverage.
+
+For each acceptance criterion in the story:
+1. Read the AC carefully to understand what behavior it specifies
+2. Examine the git diff to see what tests were added or modified
+3. Determine if the AC's happy path is exercised at the module-boundary or system level (integration or E2E test), or only via unit tests with mocked dependencies
+4. Flag ACs whose happy path is covered only by unit tests (all real collaborators mocked) or not tested at all at the integration/E2E level
+
+Focus on **actionable gaps** — where writing an integration or E2E test would catch real bugs that unit tests cannot.
+
+## Story Content
+
+{{story_content}}
+
+## Git Changes
+
+{{git_diff}}
+
+## Architecture Context
+
+{{arch_constraints}}
+
+## Output Contract
+
+Emit YAML exactly in this format — no other text before or after the YAML block:
+
+```yaml
+expansion_priority: low  # low | medium | high
+coverage_gaps:
+  - ac_ref: AC1
+    description: "Brief description of what integration/E2E coverage is missing"
+    gap_type: missing-integration  # missing-e2e | missing-integration | unit-only
+  - ac_ref: AC3
+    description: "AC3 happy path tested only with mocked DB — no real SQLite integration test"
+    gap_type: unit-only
+suggested_tests:
+  - test_name: "runTestExpansion integration — persists result to real DB"
+    test_type: integration  # e2e | integration | unit
+    description: "Use a real SQLite in-memory DB to verify createDecision is actually called with correct args"
+    target_ac: AC4  # optional
+  - test_name: "pipeline E2E — test-expansion triggers after SHIP_IT"
+    test_type: e2e
+    description: "Run a full orchestrator pipeline with a mocked dispatcher and verify test-expansion runs post-SHIP_IT"
+    target_ac: AC1
+notes: "Optional free-text notes about overall coverage posture"  # optional — omit if not needed
+```
+
+**Expansion priority guidance:**
+- `high`: Multiple ACs have no integration coverage and the feature touches external systems (DB, filesystem, network)
+- `medium`: Some ACs lack integration coverage for non-trivial logic
+- `low`: Coverage gaps exist but are minor or the risk surface is small
+
+**If no meaningful gaps exist**, emit:
+```yaml
+expansion_priority: low
+coverage_gaps: []
+suggested_tests: []
+notes: "Coverage is adequate — all key paths have integration or E2E tests."
+```

package/packs/bmad/prompts/test-plan.md

@@ -0,0 +1,41 @@
+# Test Plan Agent
+
+## Mission
+
+Analyze the story's Acceptance Criteria and tasks. Produce a concrete test plan listing the test files to create, the test categories to cover (unit/integration/e2e), and a brief note on AC coverage.
+
+## Story Content
+
+{{story_content}}
+
+## Instructions
+
+1. Read the Acceptance Criteria (AC1, AC2, etc.) and Tasks in the story above.
+2. Identify the source files that will need tests (from Dev Notes, Key File Paths, and Tasks).
+3. For each AC, determine which test file and test function will validate it.
+4. Produce a concise test plan — one or two test files is typical for small stories.
+
+**Rules:**
+- List only test files that will be NEW (not existing ones you'd extend unless necessary).
+- Use the project's test path convention: `src/modules/<module>/__tests__/<file>.test.ts`
+- Test categories: `unit` for isolated function tests, `integration` for multi-module tests, `e2e` for full pipeline tests.
+- Keep `coverage_notes` brief — one sentence per AC is sufficient.
+
+## Output Contract
+
+Emit ONLY this YAML block — no markdown fences, no other text:
+
+result: success
+test_files:
+  - src/modules/<module>/__tests__/<file>.test.ts
+test_categories:
+  - unit
+  - integration
+coverage_notes: "AC1 covered by foo.test.ts describe('runFoo'). AC2 covered by..."
+
+If you cannot produce a plan (e.g., story content is missing or unreadable), emit:
+
+result: failed
+test_files: []
+test_categories: []
+coverage_notes: ""

package/dist/run-CUGB4FQx.js

@@ -1,7 +0,0 @@
-import { registerRunCommand, runRunAction } from "./run-mFmS2pw6.js";
-import "./logger-D2fS2ccL.js";
-import "./event-bus-BMxhfxfT.js";
-import "./decisions-Dq4cAA2L.js";
-import "./operational-CobuCGbM.js";
-
-export { runRunAction };