|
| 1 | +# Development Plan: responsible-vibe (kiro-inspiration branch) |
| 2 | + |
| 3 | +*Generated on 2025-08-11 by Vibe Feature MCP* |
| 4 | +*Workflow: [epcc](https://mrsimpson.github.io/responsible-vibe-mcp/workflows/epcc)* |
| 5 | + |
| 6 | +## Goal |
| 7 | +Enhance responsible-vibe-mcp to natively support long-term structured requirements and design documents, inspired by Kiro's approach to maintaining consistency across development phases. |
| 8 | + |
| 9 | +## Explore |
| 10 | +### Tasks |
| 11 | +- [x] Document Kiro's spec-driven development approach |
| 12 | +- [x] Analyze EARS-notation requirements format |
| 13 | +- [x] Understand Kiro's design document structure |
| 14 | +- [x] Explore task-specific conversation spawning concept |
| 15 | +- [x] Analyze current responsible-vibe-mcp architecture |
| 16 | +- [x] Identify integration touchpoints and opportunities |
| 17 | +- [x] Evaluate potential challenges and constraints |
| 18 | +- [x] Define project artifact structure and templates |
| 19 | +- [x] Design artifact management system |
| 20 | +- [x] Explore setup_project_docs tool concept |
| 21 | +- [x] Define template formats and options |
| 22 | +- [ ] Consider testing strategy externalization |
| 23 | +- [ ] Design architecture document structure |
| 24 | + |
| 25 | +### Completed |
| 26 | +- [x] Created development plan file |
| 27 | +- [x] Document Kiro's spec-driven development approach (initial understanding) |
| 28 | +- [x] Analyze EARS-notation requirements format |
| 29 | +- [x] Understand Kiro's design document structure |
| 30 | +- [x] Explore task-specific conversation spawning concept |
| 31 | +- [x] Identify key architectural challenge: workflow-agnostic artifacts |
| 32 | +- [x] Define project artifact structure and templates |
| 33 | +- [x] Design artifact management system |
| 34 | +- [x] Evaluate potential challenges and constraints |
| 35 | +- [x] Explore setup_project_docs tool concept |
| 36 | +- [x] Define template formats and options |
| 37 | +- [x] Consider testing strategy externalization |
| 38 | +- [x] Finalize template refinements (architecture linking, requirements simplification) |
| 39 | +- [x] Explore setup_project_docs tool concept |
| 40 | +- [x] Define template formats and options |
| 41 | + |
| 42 | +## Plan |
| 43 | + |
| 44 | +### Phase Entrance Criteria: |
| 45 | +- [x] Kiro's approach is thoroughly understood and documented |
| 46 | +- [x] Current responsible-vibe-mcp architecture is analyzed |
| 47 | +- [x] Integration opportunities and challenges are identified |
| 48 | +- [x] Multiple integration options have been explored and evaluated |
| 49 | + |
| 50 | +### Implementation Strategy |
| 51 | + |
| 52 | +**Core Enhancement**: Add structured project artifacts to responsible-vibe-mcp with template-based creation and workflow integration. |
| 53 | + |
| 54 | +**Refined Architecture:** |
| 55 | +- **Document Location**: `.vibe/docs/` folder for all project artifacts |
| 56 | +- **Separate Management**: Project docs independent of PlanManager (plan focuses on workflow) |
| 57 | +- **Simplified Templates**: Start with 2 options per document type |
| 58 | + |
| 59 | +**Key Components to Build:** |
| 60 | +1. **setup_project_docs Tool**: Creates project artifacts with template selection |
| 61 | +2. **Template System**: Manages simplified template set |
| 62 | +3. **Workflow Integration**: Enhances workflow instructions with artifact references |
| 63 | +4. **ProjectDocsManager**: New component for artifact management (separate from PlanManager) |
| 64 | + |
| 65 | +**Template Set:** |
| 66 | +- **Architecture**: arc42, freestyle |
| 67 | +- **Requirements**: ears, freestyle |
| 68 | +- **Design**: comprehensive, freestyle |
| 69 | + |
| 70 | +**File Structure:** |
| 71 | +``` |
| 72 | +.vibe/ |
| 73 | +├── docs/ |
| 74 | +│ ├── architecture.md |
| 75 | +│ ├── requirements.md |
| 76 | +│ └── design.md |
| 77 | +└── development-plan-{branch}.md |
| 78 | +``` |
| 79 | + |
| 80 | +### Implementation Challenges & Solutions |
| 81 | + |
| 82 | +**Challenge 1: Template Management** |
| 83 | +- *Issue*: Managing multiple template formats and keeping them maintainable |
| 84 | +- *Solution*: Use consistent template structure with instructional comments, version templates separately |
| 85 | + |
| 86 | +**Challenge 2: Workflow Backward Compatibility** |
| 87 | +- *Issue*: Existing workflows shouldn't break if artifacts don't exist |
| 88 | +- *Solution*: Make artifact references optional, graceful degradation in instructions |
| 89 | + |
| 90 | +**Challenge 3: File Path Resolution** |
| 91 | +- *Issue*: Consistent artifact paths across different project structures |
| 92 | +- *Solution*: Use .vibe/docs/ directory consistently, resolve paths relative to project root |
| 93 | + |
| 94 | +**Challenge 4: Template Selection UX** |
| 95 | +- *Issue*: Users need to understand template options without overwhelming choice |
| 96 | +- *Solution*: Simplified template set (2 options each), opinionated defaults |
| 97 | + |
| 98 | +### Dependencies & Integration Points |
| 99 | + |
| 100 | +**Existing Components to Modify:** |
| 101 | +- `start_development` handler: Add artifact detection and setup guidance |
| 102 | +- Workflow YAML files: Add variable substitution |
| 103 | +- Instruction generator: Handle variable substitution |
| 104 | + |
| 105 | +**New Components to Create:** |
| 106 | +- `ProjectDocsManager`: Separate artifact management (not PlanManager) |
| 107 | +- `TemplateManager`: Template loading and rendering |
| 108 | +- `setup_project_docs` tool handler: Tool implementation |
| 109 | +- Template files: Simplified set (arc42/freestyle, ears/freestyle, comprehensive/freestyle) |
| 110 | + |
| 111 | +### Success Criteria |
| 112 | +- [ ] setup_project_docs tool creates properly formatted documents |
| 113 | +- [ ] Workflow instructions correctly reference artifact files |
| 114 | +- [ ] Existing workflows continue to work without artifacts |
| 115 | +- [ ] Template comments guide LLM to create appropriate content |
| 116 | +- [ ] Integration works seamlessly with start_development flow |
| 117 | + |
| 118 | +### Completed |
| 119 | +- [x] Design setup_project_docs tool interface and parameters |
| 120 | +- [x] Create template system architecture and template definitions |
| 121 | +- [x] Design workflow instruction enhancement mechanism |
| 122 | +- [x] Plan artifact file management and path resolution |
| 123 | +- [x] Define opinionated defaults and template options |
| 124 | +- [x] Design error handling for missing/invalid templates |
| 125 | +- [x] Plan integration with existing start_development flow |
| 126 | +- [x] Identify implementation challenges and solutions |
| 127 | +- [x] Define success criteria and integration points |
| 128 | +- [x] Refine architecture based on user feedback (separate from PlanManager, .vibe/docs/, simplified templates) |
| 129 | + |
| 130 | +### Completed |
| 131 | +*None yet* |
| 132 | + |
| 133 | +## Code |
| 134 | + |
| 135 | +### Phase Entrance Criteria: |
| 136 | +- [ ] Integration approach is clearly defined and documented |
| 137 | +- [ ] Implementation strategy is broken down into specific tasks |
| 138 | +- [ ] Technical architecture decisions are made |
| 139 | +- [ ] User experience and API design are specified |
| 140 | + |
| 141 | +### Implementation Tasks |
| 142 | +- [x] Create simplified template files (arc42/freestyle, ears/freestyle, comprehensive/freestyle) |
| 143 | +- [x] Implement TemplateManager class for loading and rendering templates |
| 144 | +- [x] Create ProjectDocsManager class for artifact management (separate from PlanManager) |
| 145 | +- [x] Add setup_project_docs tool to server tool handlers |
| 146 | +- [x] Fix tool parameter issues (make all parameters mandatory, ensure enum options are exposed) |
| 147 | +- [x] Move templates to resources directory (like workflows) for proper build inclusion |
| 148 | +- [x] Update TemplateManager to use resource path resolution strategy |
| 149 | +- [x] Add comprehensive unit tests for template system and artifact management |
| 150 | +- [x] Implement workflow instruction variable substitution ($ARCHITECTURE_DOC, etc.) |
| 151 | +- [x] Enhance start_development to detect missing artifacts and guide setup |
| 152 | +- [x] Refactor to use centralized ProjectDocsManager.getVariableSubstitutions() |
| 153 | +- [x] Make template discovery dynamic based on file system structure |
| 154 | +- [x] Add artifact path resolution for .vibe/docs/ folder |
| 155 | +- [x] Implement error handling for invalid template selections |
| 156 | +- [x] Update workflow YAML files with artifact references |
| 157 | +- [x] Test integration with existing workflows (epcc, waterfall, greenfield) |
| 158 | + |
| 159 | +### Completed |
| 160 | +- ✅ **Project Documentation Template System** - Complete end-to-end system for managing project artifacts |
| 161 | +- ✅ **Dynamic Template Discovery** - File system-based template detection with zero maintenance |
| 162 | +- ✅ **Workflow Document Integration** - All workflows now reference appropriate project documents |
| 163 | +- ✅ **Intelligent Artifact Setup** - Smart guidance for missing documents based on workflow analysis |
| 164 | +- ✅ **Comprehensive Testing** - Full test coverage and successful integration testing |
| 165 | +- ✅ **Documentation and Release** - Updated README, created CHANGELOG, and committed all changes |
| 166 | + |
| 167 | +## Commit |
| 168 | + |
| 169 | +### Phase Entrance Criteria: |
| 170 | +- [x] Core integration functionality is implemented and tested |
| 171 | +- [x] Documentation is updated to reflect new capabilities |
| 172 | +- [x] Integration works with existing workflows |
| 173 | +- [x] Code quality standards are met |
| 174 | + |
| 175 | +### Tasks |
| 176 | +- [x] Run final test suite to ensure no regressions |
| 177 | +- [x] Update README.md with new project documentation features |
| 178 | +- [x] Update CHANGELOG.md with feature additions |
| 179 | +- [x] Verify all new files are properly included in build |
| 180 | +- [x] Clean up any temporary or debug code |
| 181 | +- [x] Prepare conventional commit message |
| 182 | +- [x] Create final commit with all changes |
| 183 | +- [x] Investigate test regression - conversation mocking appears broken |
| 184 | +- [x] Fix test setup issues to restore test functionality (added mock project documents) |
| 185 | +- [x] Fix remaining 4 failing tests in start-development-artifact-detection.test.ts (added templateManager mock) |
| 186 | +- [x] Verify all tests pass after fixes (205/205 tests passing! 🎉) |
| 187 | +- [x] Refactor test code to eliminate repetition and make it DRY |
| 188 | + |
| 189 | +### Completed |
| 190 | +*None yet* |
| 191 | + |
| 192 | +## Key Decisions |
| 193 | + |
| 194 | +### Architectural Decision: **Project-Level Artifacts with Opinionated Structure** |
| 195 | +- **Requirements and Design are project artifacts** (not workflow-specific) |
| 196 | +- **Structure is project-defined and consistent** (e.g., EARS format for requirements) |
| 197 | +- **Created once with opinionated format, maintained consistently** |
| 198 | +- **All workflows work with same structured artifacts** |
| 199 | + |
| 200 | +### Implementation Decisions: |
| 201 | +1. **Creation Timing**: Create artifacts on `start_development()` if they don't exist |
| 202 | +2. **Workflow Integration**: Embed file paths directly in workflow instructions |
| 203 | + - Example: "note requirements in $REQUIREMENTS_DOC" in explore phase |
| 204 | + - Example: "Respect the design from $DESIGN_DOC" in code phase |
| 205 | +3. **Numbering**: Let LLM handle requirement numbering, provide template instructions |
| 206 | +4. **Cross-References**: No bidirectional references needed between artifacts |
| 207 | + |
| 208 | +### Enhanced Concept: **setup_project_docs Tool** |
| 209 | +- **Template Selection**: Choose formats for different document types |
| 210 | +- **Example**: `setup_project_docs(architecture: arc42, requirements: ears, design: freestyle)` |
| 211 | +- **Three Document Types**: |
| 212 | + - **Architecture**: High-level structure, context, boundaries (arc42, c4model, freestyle) |
| 213 | + - **Requirements**: User needs and acceptance criteria (ears, user-stories, freestyle) |
| 214 | + - **Design**: Technical implementation details (structured, freestyle) |
| 215 | +- **Template Examples**: Add concrete examples in document comments |
| 216 | + |
| 217 | +### Final Implementation Decisions: |
| 218 | +1. **Opinionated Defaults**: Provide sensible defaults (likely arc42 + ears + comprehensive) |
| 219 | + |
| 220 | +### Dynamic Workflow Analysis Approach |
| 221 | +**Decision**: Instead of hardcoding which workflows require artifacts, dynamically analyze workflow content to detect document variable references (`$ARCHITECTURE_DOC`, `$REQUIREMENTS_DOC`, `$DESIGN_DOC`). |
| 222 | + |
| 223 | +**Rationale**: |
| 224 | +- More flexible and accurate than hardcoded workflow restrictions |
| 225 | +- Automatically adapts to workflow changes without code updates |
| 226 | +- Only validates documents that are actually referenced |
| 227 | +- Supports custom workflows without modification |
| 228 | + |
| 229 | +**Implementation**: |
| 230 | +- Load workflow and convert to string for analysis |
| 231 | +- Get available document variables from `ProjectDocsManager.getVariableSubstitutions()` |
| 232 | +- Search for document variables using string matching |
| 233 | +- Derive variable-to-document mapping from centralized substitutions |
| 234 | +- Validate only referenced documents exist |
| 235 | +- Provide targeted guidance for missing referenced documents |
| 236 | + |
| 237 | +### Dynamic Template Discovery |
| 238 | +**Decision**: Replace hardcoded template names with dynamic file system discovery. |
| 239 | + |
| 240 | +**Rationale**: |
| 241 | +- Eliminates maintenance burden of updating code when templates are added/removed |
| 242 | +- Templates are discovered automatically from file structure |
| 243 | +- Supports extensibility without code changes |
| 244 | +- Single source of truth: the file system itself |
| 245 | + |
| 246 | +**Implementation**: |
| 247 | +- `TemplateManager.getAvailableTemplates()` scans template directories |
| 248 | +- Server configuration uses dynamic enums based on discovered templates |
| 249 | +- Template validation uses discovered templates instead of hardcoded lists |
| 250 | +- Template descriptions generated dynamically with fallbacks for unknown templates |
| 251 | + |
| 252 | +### Workflow Document Integration |
| 253 | +**Decision**: Strategically inject document variable references into workflow default instructions. |
| 254 | + |
| 255 | +**Rationale**: |
| 256 | +- Provides contextual guidance referencing relevant project documents |
| 257 | +- Makes workflows document-aware without breaking existing functionality |
| 258 | +- Enables intelligent artifact setup guidance based on workflow analysis |
| 259 | + |
| 260 | +**Implementation**: |
| 261 | +- **waterfall**: All documents referenced in requirements, design, implementation, qa phases |
| 262 | +- **greenfield**: All documents referenced in ideation, architecture, plan, code phases |
| 263 | +- **epcc**: All documents referenced in explore, plan, code phases |
| 264 | +- **minor**: Requirements and design documents in explore, implement phases |
| 265 | +- **bugfix**: Requirements and design documents in reproduce, analyze, fix phases |
| 266 | +- Dynamic workflow analysis detects document references automatically |
| 267 | +- `start_development` provides targeted setup guidance for missing referenced documents |
| 268 | +2. **No Template Switching**: Users edit files manually after creation, no tool support |
| 269 | +3. **Integrated Flow**: start_development instructs LLM to use docs, calls setup_project_docs if missing |
| 270 | +4. **Testing Strategy**: Embedded in design document with instructional comments |
| 271 | +5. **Testing Focus**: Guide LLM to document testing concepts/strategy, not actual test cases |
| 272 | +6. **Architecture Separation**: Design document links to ./ARCHITECTURE.md rather than repeating content |
| 273 | +7. **Requirements Simplification**: No task references in requirements, focus on user needs |
| 274 | + |
| 275 | +### Benefits: |
| 276 | +- **Consistency**: Same format across all workflows |
| 277 | +- **Simplicity**: No complex state management or whats_next modifications |
| 278 | +- **Traceability**: Tasks can reference requirements consistently |
| 279 | +- **Persistence**: Artifacts survive workflow changes |
| 280 | +- **Workflow Integration**: Natural integration through instruction templating |
| 281 | + |
| 282 | +## Notes |
| 283 | + |
| 284 | +## Notes |
| 285 | + |
| 286 | +### User Testing Feedback: |
| 287 | +- **MCP Inspector Testing**: User tested setup_project_docs tool and identified issues: |
| 288 | + - Template options were not pre-filled in metadata (fixed by making enums explicit) |
| 289 | + - Parameters should be mandatory rather than optional (fixed by removing .optional()) |
| 290 | + - Templates not found in dist directory (fixed by moving to resources/ like workflows) |
| 291 | +- **Tool now properly exposes**: arc42/freestyle, ears/freestyle, comprehensive/freestyle options |
| 292 | +- **All parameters are required**: architecture, requirements, design must all be specified |
| 293 | +- **Templates are resources**: Moved from src/templates to resources/templates for proper build inclusion |
| 294 | +- **Resource path resolution**: Uses same strategy as WorkflowManager for finding templates |
| 295 | + |
| 296 | +### Current responsible-vibe-mcp Architecture: |
| 297 | +- **Workflow/Phase-driven**: Structured development phases with state transitions |
| 298 | +- **Plan File**: Markdown-based long-term memory with tasks, decisions, and notes |
| 299 | +- **Conversation State**: Tracks current phase and provides contextual instructions |
| 300 | +- **Tool-based Coordination**: LLM calls tools to get guidance and transition phases |
| 301 | + |
| 302 | +--- |
| 303 | +*This plan is maintained by the LLM. Tool responses provide guidance on which section to focus on and what tasks to work on.* |
0 commit comments