Features: - BMAD (Build Modular AI-driven Development) framework setup - BMM, BMB, CIS, Core modules configured - Story 1.1: Component trait with error handling - Workspace Cargo.toml with components crate - 31 tests passing (19 unit + 12 doc tests) Technical: - Component trait with compute_residuals, jacobian_entries, n_equations - ComponentError enum with thiserror - JacobianBuilder for sparse matrix construction - Object-safe trait supporting Box<dyn Component> - Comprehensive documentation and examples
3.8 KiB
3.8 KiB
Workflow Architecture
Purpose: Core structural patterns for BMAD workflows.
Structure
workflow-folder/
├── workflow.md # Entry point, configuration
├── steps-c/ # Create flow steps
│ ├── step-01-init.md
│ ├── step-02-[name].md
│ └── step-N-[name].md
├── steps-e/ # Edit flow (if needed)
├── steps-v/ # Validate flow (if needed)
├── data/ # Shared reference files
└── templates/ # Output templates (if needed)
workflow.md Standards
CRITICAL: workflow.md MUST be lean — entry point only.
❌ PROHIBITED:
- Listing all steps (defeats progressive disclosure)
- Detailed step descriptions (steps are self-documenting)
- Validation checklists (belong in steps-v/)
- Implementation details (belong in step files)
✅ REQUIRED:
- Frontmatter: name, description, web_bundle
- Goal: What the workflow accomplishes
- Role: Who the AI embodies
- Meta-context: Architecture background (if pattern demo)
- Core principles (step-file design, JIT loading, etc.)
- Initialization/routing: How to start, which step first
Progressive Disclosure: Users ONLY know about current step. workflow.md routes to first step, each step routes to next. No step lists in workflow.md!
Core Principles
1. Micro-File Design
- Each step: ~80-200 lines, focused
- One concept per step
- Self-contained instructions
2. Just-In-Time Loading
- Only current step in memory
- Never load future steps until 'C' selected
- Progressive disclosure = LLM focus
3. Sequential Enforcement
- Steps execute in order
- No skipping, no optimization
- Each step completes before next loads
4. State Tracking
For continuable workflows:
stepsCompleted: ['step-01-init', 'step-02-gather', 'step-03-design']
lastStep: 'step-03-design'
lastContinued: '2025-01-02'
Each step appends its name to stepsCompleted before loading next.
Execution Flow
Fresh Start:
workflow.md → step-01-init.md → step-02-[name].md → ... → step-N-final.md
Continuation:
workflow.md → step-01-init.md (detects existing) → step-01b-continue.md → [next step]
Frontmatter Variables
Standard
workflow_path: '{project-root}/_bmad/[module]/workflows/[name]'
thisStepFile: './step-[N]-[name].md'
nextStepFile: './step-[N+1]-[name].md'
outputFile: '{output_folder}/[output].md'
Module-Specific
bmb_creations_output_folder: '{project-root}/_bmad/bmb-creations'
Rules
- ONLY variables used in step body go in frontmatter
- All file references use
{variable}format - Paths within workflow folder are relative
Menu Pattern
### N. Present MENU OPTIONS
Display: "**Select:** [A] [action] [P] [action] [C] Continue"
#### Menu Handling Logic:
- IF A: Execute {task}, then redisplay menu
- IF P: Execute {task}, then redisplay menu
- IF C: Save to {outputFile}, update frontmatter, then load {nextStepFile}
- IF Any other: help user, then redisplay menu
#### EXECUTION RULES:
- ALWAYS halt and wait for user input
- ONLY proceed to next step when user selects 'C'
A/P not needed in: Step 1 (init), validation sequences, simple data gathering
Output Pattern
Every step writes BEFORE loading next:
- Plan-then-build: Steps append to plan.md → build step consumes plan
- Direct-to-final: Steps append directly to final document
See: output-format-standards.md
Critical Rules
- 🛑 NEVER load multiple step files simultaneously
- 📖 ALWAYS read entire step file before execution
- 🚫 NEVER skip steps or optimize the sequence
- 💾 ALWAYS update frontmatter when step completes
- ⏸️ ALWAYS halt at menus and wait for input
- 📋 NEVER create mental todos from future steps