substrate-ai 0.2.20 → 0.2.21

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,7 @@
1
+ import { registerRunCommand, runRunAction } from "./run-BLIgARum.js";
2
+ import "./logger-D2fS2ccL.js";
3
+ import "./event-bus-BMxhfxfT.js";
4
+ import "./decisions-Dq4cAA2L.js";
5
+ import "./operational-CnMlvWqc.js";
6
+
7
+ export { runRunAction };
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "substrate-ai",
3
- "version": "0.2.20",
3
+ "version": "0.2.21",
4
4
  "description": "Substrate — multi-agent orchestration daemon for AI coding agents",
5
5
  "type": "module",
6
6
  "license": "MIT",
@@ -8,13 +8,16 @@
8
8
  ### Research Context
9
9
  {{research_findings}}
10
10
 
11
+ ### Prior Run Findings
12
+ {{prior_findings}}
13
+
11
14
  ---
12
15
 
13
16
  ## Mission
14
17
 
15
18
  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.
16
19
 
17
- 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.
20
+ 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.
18
21
 
19
22
  ## Instructions
20
23
 
@@ -0,0 +1,65 @@
1
+ # Test Expansion Analysis
2
+
3
+ ## Mission
4
+
5
+ You are a test coverage analyst. Your mission is to identify gaps in E2E and integration test coverage after a story implementation.
6
+
7
+ 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.
8
+
9
+ For each acceptance criterion in the story:
10
+ 1. Read the AC carefully to understand what behavior it specifies
11
+ 2. Examine the git diff to see what tests were added or modified
12
+ 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
13
+ 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
14
+
15
+ Focus on **actionable gaps** — where writing an integration or E2E test would catch real bugs that unit tests cannot.
16
+
17
+ ## Story Content
18
+
19
+ {{story_content}}
20
+
21
+ ## Git Changes
22
+
23
+ {{git_diff}}
24
+
25
+ ## Architecture Context
26
+
27
+ {{arch_constraints}}
28
+
29
+ ## Output Contract
30
+
31
+ Emit YAML exactly in this format — no other text before or after the YAML block:
32
+
33
+ ```yaml
34
+ expansion_priority: low # low | medium | high
35
+ coverage_gaps:
36
+ - ac_ref: AC1
37
+ description: "Brief description of what integration/E2E coverage is missing"
38
+ gap_type: missing-integration # missing-e2e | missing-integration | unit-only
39
+ - ac_ref: AC3
40
+ description: "AC3 happy path tested only with mocked DB — no real SQLite integration test"
41
+ gap_type: unit-only
42
+ suggested_tests:
43
+ - test_name: "runTestExpansion integration — persists result to real DB"
44
+ test_type: integration # e2e | integration | unit
45
+ description: "Use a real SQLite in-memory DB to verify createDecision is actually called with correct args"
46
+ target_ac: AC4 # optional
47
+ - test_name: "pipeline E2E — test-expansion triggers after SHIP_IT"
48
+ test_type: e2e
49
+ description: "Run a full orchestrator pipeline with a mocked dispatcher and verify test-expansion runs post-SHIP_IT"
50
+ target_ac: AC1
51
+ notes: "Optional free-text notes about overall coverage posture" # optional — omit if not needed
52
+ ```
53
+
54
+ **Expansion priority guidance:**
55
+ - `high`: Multiple ACs have no integration coverage and the feature touches external systems (DB, filesystem, network)
56
+ - `medium`: Some ACs lack integration coverage for non-trivial logic
57
+ - `low`: Coverage gaps exist but are minor or the risk surface is small
58
+
59
+ **If no meaningful gaps exist**, emit:
60
+ ```yaml
61
+ expansion_priority: low
62
+ coverage_gaps: []
63
+ suggested_tests: []
64
+ notes: "Coverage is adequate — all key paths have integration or E2E tests."
65
+ ```
@@ -0,0 +1,41 @@
1
+ # Test Plan Agent
2
+
3
+ ## Mission
4
+
5
+ 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.
6
+
7
+ ## Story Content
8
+
9
+ {{story_content}}
10
+
11
+ ## Instructions
12
+
13
+ 1. Read the Acceptance Criteria (AC1, AC2, etc.) and Tasks in the story above.
14
+ 2. Identify the source files that will need tests (from Dev Notes, Key File Paths, and Tasks).
15
+ 3. For each AC, determine which test file and test function will validate it.
16
+ 4. Produce a concise test plan — one or two test files is typical for small stories.
17
+
18
+ **Rules:**
19
+ - List only test files that will be NEW (not existing ones you'd extend unless necessary).
20
+ - Use the project's test path convention: `src/modules/<module>/__tests__/<file>.test.ts`
21
+ - Test categories: `unit` for isolated function tests, `integration` for multi-module tests, `e2e` for full pipeline tests.
22
+ - Keep `coverage_notes` brief — one sentence per AC is sufficient.
23
+
24
+ ## Output Contract
25
+
26
+ Emit ONLY this YAML block — no markdown fences, no other text:
27
+
28
+ result: success
29
+ test_files:
30
+ - src/modules/<module>/__tests__/<file>.test.ts
31
+ test_categories:
32
+ - unit
33
+ - integration
34
+ coverage_notes: "AC1 covered by foo.test.ts describe('runFoo'). AC2 covered by..."
35
+
36
+ If you cannot produce a plan (e.g., story content is missing or unreadable), emit:
37
+
38
+ result: failed
39
+ test_files: []
40
+ test_categories: []
41
+ coverage_notes: ""
@@ -1,7 +0,0 @@
1
- import { registerRunCommand, runRunAction } from "./run-CcWb6Kb-.js";
2
- import "./logger-D2fS2ccL.js";
3
- import "./event-bus-BMxhfxfT.js";
4
- import "./decisions-Dq4cAA2L.js";
5
- import "./operational-Dq4IfJzE.js";
6
-
7
- export { runRunAction };