specsmd 0.0.31 → 0.0.33

package/flows/aidlc/quick-start.md

@@ -98,14 +98,22 @@ Switch to the Construction Agent to execute:
 /specsmd-construction-agent bolt-start
 ```
 
-Each bolt goes through stages (DDD bolt example):
+Each bolt type has its own stages:
 
-1. **Domain Model** - Model the business logic
+**DDD Construction Bolt** (for complex business logic):
+
+1. **Domain Model** - Model the business domain
 2. **Technical Design** - Define interfaces and architecture
 3. **ADR Analysis** - Document significant decisions (optional)
 4. **Implement** - Write production code
 5. **Test** - Verify correctness
 
+**Simple Construction Bolt** (for UI, integrations, utilities):
+
+1. **Spec** - Define what to build
+2. **Implement** - Write the code
+3. **Test** - Verify it works
+
 Human validation happens at each stage.
 
 ### Step 5: Deploy

package/flows/aidlc/skills/construction/navigator.md

@@ -136,7 +136,7 @@ When user selects an option:
 
 - [ ] `bolt-auth-1` (auth-service, DDD) - planned
 - [ ] `bolt-auth-2` (auth-service, DDD) - planned
-- [ ] `bolt-api-1` (api-gateway, BDD) - planned
+- [ ] `bolt-api-1` (api-gateway, Simple) - planned
 
 ### Quick Actions
 

package/flows/aidlc/skills/master/explain-flow.md

@@ -58,7 +58,7 @@ AI-DLC is a reimagined development methodology where AI drives the workflow and
 - **Unit**: Independently deployable component (like a bounded context)
 - **Story**: User story with acceptance criteria
 - **Bolt**: Time-boxed execution session (hours/days, not weeks)
-- **Bolt Type**: Methodology template (DDD, BDD, TDD)
+- **Bolt Type**: Methodology template (DDD or Simple)
 
 ### Core Principles
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specsmd",
-  "version": "0.0.31",
+  "version": "0.0.33",
   "description": "Multi-agent orchestration system for AI-native software development. Delivers AI-DLC, Agile, and custom SDLC flows as markdown-based agent systems.",
   "main": "lib/installer.js",
   "bin": {

package/flows/aidlc/templates/construction/bolt-types/bdd-construction-bolt.md

@@ -1,250 +0,0 @@
-# Bolt Type: BDD Construction
-
-## Mandatory Output Rules (READ FIRST)
-
-- 🚫 **NEVER** use ASCII tables for options - they break at different terminal widths
-- ✅ **ALWAYS** use numbered list format: `N - **Option**: Description`
-- ✅ **ALWAYS** use status indicators: ✅ (done) ⏳ (current) [ ] (pending) 🚫 (blocked)
-
-## Success Metrics
-
-- ✅ Activities presented as numbered lists (not tables)
-- ✅ Stage progress shown with status indicators
-- ✅ Human checkpoints clearly marked
-
-## Failure Modes
-
-- ❌ Using ASCII table for activities
-- ❌ Auto-advancing without human confirmation
-- ❌ Skipping stages
-
----
-
-## Metadata
-
-```yaml
-bolt_type: bdd-construction-bolt
-name: BDD Construction Bolt
-description: Behavior-Driven Development with specification, implementation, and testing
-version: 1.0.0
-suitable_for:
-  - Feature-focused development
-  - User story implementation
-  - Scenarios with clear Given-When-Then flows
-stages_count: 3
-```
-
----
-
-## Overview
-
-This bolt type implements Behavior-Driven Development (BDD) methodology through three stages focused on specifications, implementation, and acceptance testing.
-
-**Best For**:
-
-- Feature-driven development
-- User-facing functionality
-- Clear user stories with acceptance criteria
-- Scenarios that can be expressed in Given-When-Then format
-
----
-
-## Stages
-
-### Stage 1: specify
-
-**Objective**: Define behavior specifications in Gherkin format
-
-**Duration**: Hours (typically 1-2 hours)
-
-**Activities**:
-
-1 - **Review user stories**: Analyze stories and acceptance criteria
-2 - **Write feature files**: Create Gherkin specifications
-3 - **Define happy paths**: Document expected successful flows
-4 - **Define edge cases**: Document boundary conditions
-5 - **Define error scenarios**: Document error handling behaviors
-6 - **Review with stakeholders**: Validate specifications
-
-**Artifact**: `specifications.md` and `.feature` files
-**Location**: Path defined by `schema.units` in `.specsmd/aidlc/memory-bank.yaml`
-*(Default: `{intents-path}/{intent}/units/{unit}/specifications.md`)*
-
-**Template Structure**:
-
-```markdown
----
-stage: specify
-bolt: {bolt-id}
-created: {timestamp}
----
-
-## Behavior Specifications: {unit-name}
-
-### Feature Overview
-{Feature description}
-
-### Scenarios
-
-#### Scenario 1: {Happy Path}
-​```gherkin
-Given {precondition}
-When {action}
-Then {expected outcome}
-​```
-
-#### Scenario 2: {Edge Case}
-
-​```gherkin
-Given {precondition}
-When {action}
-Then {expected outcome}
-​```
-
-### Background
-
-{Shared context for all scenarios}
-
-### Data Examples
-
-- **{Field}**: Valid: {examples} - Invalid: {examples}
-
-```
-
-**Completion Criteria**:
-
-- [ ] All user stories have scenarios
-- [ ] Happy paths covered
-- [ ] Edge cases covered
-- [ ] Error handling scenarios defined
-- [ ] Scenarios reviewed and approved
-
-**⛔ HUMAN Checkpoint**: Present specification summary and **STOP**. Wait for user to confirm before proceeding to Stage 2.
-
----
-
-### Stage 2: implement
-
-**Objective**: Implement the specified behaviors
-
-**Duration**: Hours to days (varies by complexity)
-
-**Activities**:
-
-1 - **Setup step definitions**: Create test framework structure
-2 - **Implement Given steps**: Build context setup code
-3 - **Implement When steps**: Build action code
-4 - **Implement Then steps**: Build assertion code
-5 - **Implement production code**: Build feature implementation
-6 - **Wire specs to implementation**: Connect tests to code
-
-**Artifact**: Source code
-**Location**: `src/{unit}/`
-
-**Project Structure**:
-
-```text
-
-src/{unit}/
-├── features/
-│   └── *.feature          # Gherkin specs
-├── steps/
-│   └──*_steps.{ext}      # Step definitions
-├── src/
-│   └── ...                # Production code
-└── support/
-    └── ...                # Test utilities
-
-```
-
-**Completion Criteria**:
-
-- [ ] All step definitions implemented
-- [ ] Production code implements features
-- [ ] All scenarios executable
-- [ ] Code follows standards
-
-**⛔ HUMAN Checkpoint**: Present implementation summary and **STOP**. Wait for user to confirm before proceeding to Stage 3.
-
----
-
-### Stage 3: validate
-
-**Objective**: Run acceptance tests and verify behaviors
-
-**Duration**: Hours (typically 1-2 hours)
-
-**Activities**:
-
-1 - **Run all feature tests**: Execute test suite
-2 - **Fix any failing scenarios**: Address issues
-3 - **Generate living documentation**: Create doc report
-4 - **Verify acceptance criteria**: Validate against stories
-5 - **Stakeholder sign-off**: Get approval
-
-**Artifact**: `acceptance-report.md`
-**Location**: Path defined by `schema.units` in `.specsmd/aidlc/memory-bank.yaml`
-*(Default: `{intents-path}/{intent}/units/{unit}/acceptance-report.md`)*
-
-**Template Structure**:
-
-```markdown
----
-stage: validate
-bolt: {bolt-id}
-created: {timestamp}
----
-
-## Acceptance Report: {unit-name}
-
-### Test Results
-
-- **{Feature}**: {scenarios} scenarios - {passed} passed, {failed} failed
-
-### Acceptance Criteria Status
-
-- ✅/❌ **{Story}**: {Criteria} - Scenario: {name} - {Status}
-
-### Living Documentation
-{Link to generated docs}
-
-### Sign-off
-- [ ] Developer verified
-- [ ] Stakeholder approved
-```
-
-**Completion Criteria**:
-
-- [ ] All scenarios passing
-- [ ] Acceptance criteria met
-- [ ] Living documentation generated
-- [ ] Stakeholder sign-off received
-
-**⛔ HUMAN Checkpoint**: Present acceptance report and **STOP**. Wait for user to confirm bolt completion.
-
----
-
-## Stage Execution
-
-### Sequence
-
-```text
-specify → implement → validate
-```
-
-### State Tracking
-
-```yaml
----
-current_stage: implement
-stages_completed:
-  - name: specify
-    completed: 2024-12-05T10:00:00Z
-    artifact: specifications.md
-status: in-progress
----
-```
-
-### Human Validation
-
-Specifications require stakeholder review before implementation.

package/flows/aidlc/templates/construction/bolt-types/tdd-construction-bolt.md

@@ -1,259 +0,0 @@
-# Bolt Type: TDD Construction
-
-## Mandatory Output Rules (READ FIRST)
-
-- 🚫 **NEVER** use ASCII tables for options - they break at different terminal widths
-- ✅ **ALWAYS** use numbered list format: `N - **Option**: Description`
-- ✅ **ALWAYS** use status indicators: ✅ (done) ⏳ (current) [ ] (pending) 🚫 (blocked)
-
-## Success Metrics
-
-- ✅ Activities presented as numbered lists (not tables)
-- ✅ Stage progress shown with status indicators
-- ✅ Human checkpoints clearly marked
-
-## Failure Modes
-
-- ❌ Using ASCII table for activities
-- ❌ Auto-advancing without human confirmation
-- ❌ Skipping stages
-
----
-
-## Metadata
-
-```yaml
-bolt_type: tdd-construction-bolt
-name: TDD Construction Bolt
-description: Test-Driven Development with red-green-refactor cycle
-version: 1.0.0
-suitable_for:
-  - Algorithm implementation
-  - Utility functions
-  - Pure logic without external dependencies
-  - Libraries and reusable components
-stages_count: 3
-```
-
----
-
-## Overview
-
-This bolt type implements Test-Driven Development (TDD) methodology through the classic red-green-refactor cycle: write failing tests, make them pass, then refactor.
-
-**Best For**:
-
-- Algorithm and logic implementation
-- Utility functions and helpers
-- Pure functions without side effects
-- Libraries and SDKs
-- Components with clear inputs/outputs
-
----
-
-## Stages
-
-### Stage 1: test-first
-
-**Objective**: Write failing tests that specify expected behavior
-
-**Duration**: Hours (typically 1-3 hours)
-
-**Activities**:
-
-1 - **Analyze requirements**: Identify test cases and edge cases
-2 - **Write unit tests**: Create tests for core functionality (failing)
-3 - **Write edge case tests**: Cover boundary conditions
-4 - **Write error tests**: Cover error conditions
-5 - **Run tests**: Confirm they fail (RED state)
-
-**Artifact**: `test-spec.md` and test files
-**Location**: Path defined by `schema.units` in `.specsmd/aidlc/memory-bank.yaml`
-*(Default: `{intents-path}/{intent}/units/{unit}/test-spec.md`)*
-
-**Template Structure**:
-
-```markdown
----
-stage: test-first
-bolt: {bolt-id}
-created: {timestamp}
----
-
-## Test Specification: {unit-name}
-
-### Test Cases
-
-#### Core Functionality
-
-- **{Test name}**: Input: {input} → Expected: {output}
-- **{Test name}**: Input: {input} → Expected: {output}
-
-#### Edge Cases
-
-- **{Test name}**: Input: {input} → Expected: {output}
-
-#### Error Conditions
-
-- **{Test name}**: Input: {input} → Expected Error: {error}
-
-### Test Run (RED)
-- Total tests: {n}
-- Passing: 0
-- Failing: {n}
-
-Status: 🔴 RED (all tests failing as expected)
-```
-
-**Completion Criteria**:
-
-- [ ] All functionality has tests
-- [ ] Edge cases covered
-- [ ] Error cases covered
-- [ ] All tests compile/parse
-- [ ] All tests fail (RED state)
-
-**⛔ HUMAN Checkpoint**: Present test specification and **STOP**. Wait for user to confirm before proceeding to Stage 2.
-
----
-
-### Stage 2: implement
-
-**Objective**: Write minimal code to make tests pass
-
-**Duration**: Hours (varies by complexity)
-
-**Activities**:
-
-1 - **Implement first test**: Write simplest code that passes
-2 - **Iterate through tests**: Make each test pass in turn
-3 - **Run full suite**: Confirm all tests pass
-4 - **Review implementation**: Check for issues
-
-**Artifact**: Source code
-**Location**: `src/{unit}/`
-
-**Approach**:
-
-```text
-for each failing test:
-    1. Write simplest code that passes the test
-    2. Run tests
-    3. Commit if green
-    4. Move to next test
-```
-
-**Completion Criteria**:
-
-- [ ] All tests passing (GREEN state)
-- [ ] Implementation is minimal
-- [ ] No over-engineering
-- [ ] All acceptance criteria met
-
-**⛔ HUMAN Checkpoint**: Present implementation summary and **STOP**. Wait for user to confirm before proceeding to Stage 3.
-
----
-
-### Stage 3: refactor
-
-**Objective**: Improve code quality while keeping tests green
-
-**Duration**: Hours (typically 1-2 hours)
-
-**Activities**:
-
-1 - **Review code**: Identify improvement opportunities
-2 - **Remove duplication**: Apply DRY principle
-3 - **Improve naming**: Make names clear and descriptive
-4 - **Extract functions**: Create clean, focused functions
-5 - **Optimize if needed**: Improve performance where necessary
-6 - **Run tests after each change**: Maintain green state
-
-**Artifact**: `refactor-report.md`
-**Location**: Path defined by `schema.units` in `.specsmd/aidlc/memory-bank.yaml`
-*(Default: `{intents-path}/{intent}/units/{unit}/refactor-report.md`)*
-
-**Template Structure**:
-
-```markdown
----
-stage: refactor
-bolt: {bolt-id}
-created: {timestamp}
----
-
-## Refactor Report: {unit-name}
-
-### Improvements Made
-
-- **{Change}**: Before: {old} → After: {new} - Reason: {why}
-
-### Code Quality Metrics
-
-- **Cyclomatic Complexity**: Before: {n} → After: {n}
-- **Lines of Code**: Before: {n} → After: {n}
-- **Test Coverage**: Before: {n}% → After: {n}%
-
-### Test Status
-- All tests: ✅ PASSING
-- Coverage: {n}%
-
-### Final State
-Status: 🟢 GREEN (refactored and tested)
-```
-
-**Completion Criteria**:
-
-- [ ] All tests still passing
-- [ ] Code is clean and readable
-- [ ] No duplication
-- [ ] Functions are small and focused
-- [ ] Naming is clear
-
-**⛔ HUMAN Checkpoint**: Present refactor report and **STOP**. Wait for user to confirm bolt completion.
-
----
-
-## Stage Execution
-
-### Sequence
-
-```text
-test-first (RED) → implement (GREEN) → refactor (REFACTOR)
-```
-
-### The TDD Cycle
-
-```text
-    ┌──────────┐
-    │   RED    │  Write failing test
-    └────┬─────┘
-         │
-         ▼
-    ┌──────────┐
-    │  GREEN   │  Make it pass
-    └────┬─────┘
-         │
-         ▼
-    ┌──────────┐
-    │ REFACTOR │  Improve code
-    └────┬─────┘
-         │
-         └──────► Next test case
-```
-
-### State Tracking
-
-```yaml
----
-current_stage: refactor
-stages_completed:
-  - name: test-first
-    completed: 2024-12-05T10:00:00Z
-    tests_written: 15
-  - name: implement
-    completed: 2024-12-05T12:00:00Z
-    tests_passing: 15
-status: in-progress
----
-```