Compare commits
6 Commits
44d5cf5667
...
61a12f5c8e
| Author | SHA1 | Date |
|---|---|---|
|
|
61a12f5c8e | |
|
|
eb4325fab9 | |
|
|
57ceaf9fa9 | |
|
|
1513b2d478 | |
|
|
4d48b0dbe1 | |
|
|
10dc25f43d |
Binary file not shown.
|
|
@ -0,0 +1,256 @@
|
||||||
|
# BMad Method PR #1: Ring of Fire (ROF) Sessions
|
||||||
|
|
||||||
|
**Feature Type**: Core workflow enhancement
|
||||||
|
**Status**: Draft for community review
|
||||||
|
**Origin**: tellingCube project (masemIT e.U.)
|
||||||
|
**Author**: Mario Semper (@sempre)
|
||||||
|
**Date**: 2025-11-23
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Summary
|
||||||
|
|
||||||
|
**Ring of Fire (ROF) Sessions** enable multi-agent collaborative sessions that run in parallel to the user's main workflow, allowing users to delegate complex multi-perspective analysis while continuing other work.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Problem Statement
|
||||||
|
|
||||||
|
Current BMad Method requires **sequential agent interaction**. When users need multiple agents to collaborate on a complex topic, they must:
|
||||||
|
- Manually orchestrate each agent conversation
|
||||||
|
- Stay in the loop for every exchange
|
||||||
|
- Wait for sequential responses before proceeding
|
||||||
|
- Context-switch constantly between tasks
|
||||||
|
|
||||||
|
This creates **bottlenecks** and prevents **parallel work streams**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Proposed Solution: Ring of Fire Sessions
|
||||||
|
|
||||||
|
A new command pattern that enables **scoped multi-agent collaboration sessions** that run while the user continues other work.
|
||||||
|
|
||||||
|
### Command Syntax
|
||||||
|
|
||||||
|
```bash
|
||||||
|
*rof "<topic>" --agents <agent-list> [--report brief|detailed|live]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Example Usage
|
||||||
|
|
||||||
|
```bash
|
||||||
|
*rof "API Refactoring Strategy" --agents dev,architect,qa --report brief
|
||||||
|
```
|
||||||
|
|
||||||
|
**What happens**:
|
||||||
|
1. Dev, Architect, and QA agents enter a collaborative session
|
||||||
|
2. They analyze the topic together (code review, design discussion, testing concerns)
|
||||||
|
3. When agents need tool access (read files, run commands), they request user approval
|
||||||
|
4. User continues working on other tasks in parallel
|
||||||
|
5. Session ends with consolidated report (brief: just recommendations, detailed: full transcript)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Key Features
|
||||||
|
|
||||||
|
### 1. User-Controlled Scope
|
||||||
|
- **Small**: 2 agents, 5-minute quick discussion
|
||||||
|
- **Large**: 10 agents, 2-hour deep analysis
|
||||||
|
- User decides granularity based on complexity
|
||||||
|
|
||||||
|
### 2. Approval-Gated Tool Access
|
||||||
|
- Agents can **discuss** freely within the session
|
||||||
|
- When agents need **tools** (read files, execute commands, make changes), they:
|
||||||
|
- Pause the session
|
||||||
|
- Request user approval
|
||||||
|
- Resume after user decision
|
||||||
|
|
||||||
|
**Why**: Maintains user control, prevents runaway agent actions
|
||||||
|
|
||||||
|
### 3. Flexible Reporting
|
||||||
|
|
||||||
|
| Mode | Description | Use Case |
|
||||||
|
|------|-------------|----------|
|
||||||
|
| `brief` | Final recommendations only | "Just tell me what to do" |
|
||||||
|
| `detailed` | Full transcript + recommendations | "Show me the reasoning" |
|
||||||
|
| `live` | Real-time updates as agents discuss | "I want to observe" |
|
||||||
|
|
||||||
|
**Default**: `brief` with Q&A available
|
||||||
|
|
||||||
|
### 4. Parallel Workflows
|
||||||
|
- User works on **Task A** while ROF session tackles **Task B**
|
||||||
|
- No context-switching overhead
|
||||||
|
- Efficient use of time
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Use Cases
|
||||||
|
|
||||||
|
### 1. Architecture Reviews
|
||||||
|
```bash
|
||||||
|
*rof "Evaluate microservices vs monolith for new feature" --agents architect,dev,qa
|
||||||
|
```
|
||||||
|
**Agents collaborate on**: Design trade-offs, implementation complexity, testing implications
|
||||||
|
|
||||||
|
### 2. Code Refactoring
|
||||||
|
```bash
|
||||||
|
*rof "Refactor authentication module" --agents dev,architect --report detailed
|
||||||
|
```
|
||||||
|
**Agents collaborate on**: Current code analysis, refactoring approach, migration strategy
|
||||||
|
|
||||||
|
### 3. Feature Planning
|
||||||
|
```bash
|
||||||
|
*rof "Plan user notifications feature" --agents pm,ux,dev --report brief
|
||||||
|
```
|
||||||
|
**Agents collaborate on**: Requirements, UX flow, technical feasibility, timeline
|
||||||
|
|
||||||
|
### 4. Quality Gates
|
||||||
|
```bash
|
||||||
|
*rof "Investigate test failures in CI/CD" --agents qa,dev --report live
|
||||||
|
```
|
||||||
|
**Agents collaborate on**: Root cause analysis, fix recommendations, regression prevention
|
||||||
|
|
||||||
|
### 5. Documentation Sprints
|
||||||
|
```bash
|
||||||
|
*rof "Document API endpoints" --agents dev,pm,ux
|
||||||
|
```
|
||||||
|
**Agents collaborate on**: Technical accuracy, user-friendly examples, completeness
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## User Experience Flow
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
sequenceDiagram
|
||||||
|
User->>River: *rof "Topic" --agents dev,architect
|
||||||
|
River->>Dev: Join ROF session
|
||||||
|
River->>Architect: Join ROF session
|
||||||
|
River->>User: Session started, continue your work
|
||||||
|
|
||||||
|
Dev->>Architect: Discuss approach
|
||||||
|
Architect->>Dev: Suggest alternatives
|
||||||
|
|
||||||
|
Dev->>User: Need to read auth.ts - approve?
|
||||||
|
User->>Dev: Approved
|
||||||
|
Dev->>Architect: After reading file...
|
||||||
|
|
||||||
|
Architect->>Dev: Recommendation
|
||||||
|
Dev->>River: Session complete
|
||||||
|
River->>User: Brief report: [Recommendations]
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Implementation Considerations
|
||||||
|
|
||||||
|
### Technical Requirements
|
||||||
|
- **Session state management**: Track active ROF sessions, participating agents
|
||||||
|
- **Agent context sharing**: Agents share knowledge within session scope
|
||||||
|
- **User approval workflow**: Clear prompt for tool requests
|
||||||
|
- **Report generation**: Brief/detailed/live output formatting
|
||||||
|
- **Workflow integration**: Link ROF findings to existing workflow plans/todos
|
||||||
|
|
||||||
|
### Open Questions for Community
|
||||||
|
|
||||||
|
1. **Integration**: Core BMad feature or plugin/extension?
|
||||||
|
2. **Concurrency**: How to handle file conflicts if multiple agents want to edit?
|
||||||
|
3. **Cost Model**: Guidance for LLM call budgeting with multiple agents?
|
||||||
|
4. **Session Limits**: Recommended max agents/duration?
|
||||||
|
5. **Agent Communication**: Free-form discussion or structured turn-taking?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Real-World Validation
|
||||||
|
|
||||||
|
**Origin Project**: tellingCube (BI dashboard, masemIT e.U.)
|
||||||
|
|
||||||
|
**Validation Scenario**:
|
||||||
|
- **Topic**: "Next steps for tellingCube after validation test"
|
||||||
|
- **Agents**: River (orchestrator), Mary (analyst), Winston (architect)
|
||||||
|
- **Report Mode**: Brief
|
||||||
|
- **Outcome**: Successfully analyzed post-validation roadmap with 3 scenarios (GO/CHANGE/NO-GO), delivered consolidated recommendations in 5 minutes
|
||||||
|
|
||||||
|
**User Feedback (Mario Semper)**:
|
||||||
|
> "This is exactly what I needed - I wanted multiple perspectives without having to orchestrate every conversation. The brief report gave me actionable next steps immediately."
|
||||||
|
|
||||||
|
**Documentation**: `docs/_masemIT/readme.md` in tellingCube repository
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Proposed Documentation Structure
|
||||||
|
|
||||||
|
```
|
||||||
|
.bmad-core/
|
||||||
|
features/
|
||||||
|
ring-of-fire.md # Feature specification
|
||||||
|
|
||||||
|
docs/
|
||||||
|
guides/
|
||||||
|
using-rof-sessions.md # User guide with examples
|
||||||
|
|
||||||
|
architecture/
|
||||||
|
agent-collaboration.md # Technical design
|
||||||
|
rof-session-management.md # State handling approach
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Benefits
|
||||||
|
|
||||||
|
✅ **Unlocks parallel workflows** - User productivity gains
|
||||||
|
✅ **Reduces context-switching** - Cognitive load reduction
|
||||||
|
✅ **Enables complex analysis** - Multi-perspective insights
|
||||||
|
✅ **Maintains user control** - Approval gates for tools
|
||||||
|
✅ **Scales flexibly** - From quick checks to deep dives
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Comparison to Existing Patterns
|
||||||
|
|
||||||
|
| Feature | Standard Agent Use | ROF Session |
|
||||||
|
|---------|-------------------|-------------|
|
||||||
|
| Agent collaboration | Sequential (one at a time) | Parallel (multiple simultaneously) |
|
||||||
|
| User involvement | Required for every exchange | Only for approvals |
|
||||||
|
| Parallel work | No (user waits) | Yes (user continues tasks) |
|
||||||
|
| Output | Chat transcript | Consolidated report |
|
||||||
|
| Use case | Single-perspective tasks | Multi-perspective analysis |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
1. **Community feedback** on approach and open questions
|
||||||
|
2. **Technical design** refinement (state management, agent communication)
|
||||||
|
3. **Prototype implementation** in BMad core or as extension
|
||||||
|
4. **Beta testing** with real projects (beyond tellingCube)
|
||||||
|
5. **Documentation** completion with examples
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Alternatives Considered
|
||||||
|
|
||||||
|
### Alt 1: "Breakout Session"
|
||||||
|
- **Pros**: Clear meeting metaphor
|
||||||
|
- **Cons**: Less evocative, doesn't convey "continuous collaborative space"
|
||||||
|
|
||||||
|
### Alt 2: "Agent Huddle"
|
||||||
|
- **Pros**: Short, casual
|
||||||
|
- **Cons**: Implies quick/informal only
|
||||||
|
|
||||||
|
### Alt 3: "Lagerfeuer" (original German name)
|
||||||
|
- **Pros**: Warm, campfire metaphor
|
||||||
|
- **Cons**: Poor i18n, hard to pronounce/remember for non-German speakers
|
||||||
|
|
||||||
|
**Chosen**: **Ring of Fire** - evokes continuous collaboration circle, internationally understood, memorable, shortcut "ROF" works well
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## References
|
||||||
|
|
||||||
|
- **Source Project**: tellingCube (https://github.com/masemIT/telling-cube) [if public]
|
||||||
|
- **Documentation**: `docs/_masemIT/readme.md`
|
||||||
|
- **Discussion**: [Link to BMad community discussion if applicable]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Contribution ready for review.** Feedback welcome! 🔥
|
||||||
|
|
@ -139,9 +139,6 @@ Comprehensive documentation for all BMM workflows organized by phase:
|
||||||
- Complete story lifecycle
|
- Complete story lifecycle
|
||||||
- One-story-at-a-time discipline
|
- One-story-at-a-time discipline
|
||||||
|
|
||||||
<<<<<<< Updated upstream
|
|
||||||
<<<<<<< Updated upstream
|
|
||||||
|
|
||||||
- **[Testing & QA Workflows](./test-architecture.md)** - Comprehensive quality assurance (1,420 lines)
|
- **[Testing & QA Workflows](./test-architecture.md)** - Comprehensive quality assurance (1,420 lines)
|
||||||
- Test strategy, automation, quality gates
|
- Test strategy, automation, quality gates
|
||||||
- TEA agent and test healing
|
- TEA agent and test healing
|
||||||
|
|
@ -149,14 +146,6 @@ Comprehensive documentation for all BMM workflows organized by phase:
|
||||||
|
|
||||||
**Total: 34 workflows documented across all phases**
|
**Total: 34 workflows documented across all phases**
|
||||||
|
|
||||||
=======
|
|
||||||
|
|
||||||
> > > > > > > Stashed changes
|
|
||||||
|
|
||||||
=======
|
|
||||||
|
|
||||||
> > > > > > > Stashed changes
|
|
||||||
|
|
||||||
### Advanced Workflow References
|
### Advanced Workflow References
|
||||||
|
|
||||||
For detailed technical documentation on specific complex workflows:
|
For detailed technical documentation on specific complex workflows:
|
||||||
|
|
@ -181,23 +170,9 @@ Quality assurance guidance:
|
||||||
|
|
||||||
<!-- Test Architect documentation to be added -->
|
<!-- Test Architect documentation to be added -->
|
||||||
|
|
||||||
<<<<<<< Updated upstream
|
|
||||||
|
|
||||||
<<<<<<< Updated upstream
|
|
||||||
|
|
||||||
- Test design workflows
|
- Test design workflows
|
||||||
- Quality gates
|
- Quality gates
|
||||||
- Risk assessment
|
- Risk assessment
|
||||||
- # NFR validation
|
|
||||||
=======
|
|
||||||
> > > > > > > Stashed changes
|
|
||||||
- Test design workflows
|
|
||||||
- Quality gates
|
|
||||||
- Risk assessment
|
|
||||||
- NFR validation
|
|
||||||
> > > > > > > Stashed changes
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## 🏗️ Module Structure
|
## 🏗️ Module Structure
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -133,7 +133,6 @@ The `sprint-status.yaml` file is the single source of truth for all implementati
|
||||||
### (BMad Method / Enterprise)
|
### (BMad Method / Enterprise)
|
||||||
|
|
||||||
```
|
```
|
||||||
<<<<<<< Updated upstream
|
|
||||||
PRD (PM) → Architecture (Architect)
|
PRD (PM) → Architecture (Architect)
|
||||||
→ create-epics-and-stories (PM) ← V6: After architecture!
|
→ create-epics-and-stories (PM) ← V6: After architecture!
|
||||||
→ implementation-readiness (Architect)
|
→ implementation-readiness (Architect)
|
||||||
|
|
@ -142,7 +141,6 @@ PRD (PM) → Architecture (Architect)
|
||||||
→ story loop (SM/DEV)
|
→ story loop (SM/DEV)
|
||||||
→ retrospective (SM)
|
→ retrospective (SM)
|
||||||
→ [Next Epic]
|
→ [Next Epic]
|
||||||
=======
|
|
||||||
Current Phase: 4 (Implementation)
|
Current Phase: 4 (Implementation)
|
||||||
Current Epic: Epic 1 (Authentication)
|
Current Epic: Epic 1 (Authentication)
|
||||||
Current Sprint: Sprint 1
|
Current Sprint: Sprint 1
|
||||||
|
|
@ -190,108 +188,12 @@ See: [workflow-status instructions](../workflows/workflow-status/instructions.md
|
||||||
|
|
||||||
See: [document-project reference](./workflow-document-project-reference.md)
|
See: [document-project reference](./workflow-document-project-reference.md)
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Story Lifecycle Visualization
|
|
||||||
|
|
||||||
```
|
|
||||||
┌─────────────────────────────────────────────────────────────┐
|
|
||||||
│ PHASE 4: IMPLEMENTATION (Iterative Story Lifecycle) │
|
|
||||||
└─────────────────────────────────────────────────────────────┘
|
|
||||||
|
|
||||||
┌─────────────────┐
|
|
||||||
│ Sprint Planning │ → Creates sprint-status.yaml
|
|
||||||
└────────┬────────┘ Defines story queue
|
|
||||||
│
|
|
||||||
├──────────────────────────────────────────┐
|
|
||||||
│ │
|
|
||||||
▼ │
|
|
||||||
┌─────────────────────┐ │
|
|
||||||
│ Epic Tech Context │ → Optional per epic │
|
|
||||||
│ (Once per epic) │ Provides technical │
|
|
||||||
└─────────────────────┘ guidance │
|
|
||||||
│ │
|
|
||||||
▼ │
|
|
||||||
┌─────────────────────────────────────────────────┤
|
|
||||||
│ FOR EACH STORY IN QUEUE: │
|
|
||||||
├─────────────────────────────────────────────────┤
|
|
||||||
│ │
|
|
||||||
▼ │
|
|
||||||
┌─────────────────┐ │
|
|
||||||
│ Create Story │ → Generates story file │
|
|
||||||
│ (TODO → IN PROGRESS) │
|
|
||||||
└────────┬────────┘ │
|
|
||||||
│ │
|
|
||||||
▼ │
|
|
||||||
┌─────────────────┐ │
|
|
||||||
│ Story Context │ → Assembles focused context │
|
|
||||||
└────────┬────────┘ │
|
|
||||||
│ │
|
|
||||||
▼ │
|
|
||||||
┌─────────────────┐ │
|
|
||||||
│ Dev Story │ → Implements + tests │
|
|
||||||
│ (IN PROGRESS) │ │
|
|
||||||
└────────┬────────┘ │
|
|
||||||
│ │
|
|
||||||
▼ │
|
|
||||||
┌─────────────────┐ │
|
|
||||||
│ Code Review │ → Senior dev review │
|
|
||||||
│ (IN PROGRESS → │ │
|
|
||||||
│ READY FOR REVIEW) │
|
|
||||||
└────────┬────────┘ │
|
|
||||||
│ │
|
|
||||||
┌────┴────┐ │
|
|
||||||
│ Result? │ │
|
|
||||||
└────┬────┘ │
|
|
||||||
│ │
|
|
||||||
┌────┼────────────────────┐ │
|
|
||||||
│ │ │ │
|
|
||||||
▼ ▼ ▼ │
|
|
||||||
APPROVED APPROVED REQUEST │
|
|
||||||
WITH COMMENTS CHANGES │
|
|
||||||
│ │ │ │
|
|
||||||
└─────────┴───────────────────┘ │
|
|
||||||
│ │
|
|
||||||
▼ │
|
|
||||||
┌─────────────────┐ │
|
|
||||||
│ Story Done │ → READY FOR REVIEW → DONE│
|
|
||||||
└────────┬────────┘ │
|
|
||||||
│ │
|
|
||||||
├─────────────────────────────────────┘
|
|
||||||
│ More stories?
|
|
||||||
│
|
|
||||||
▼
|
|
||||||
┌────────────────┐
|
|
||||||
│ Epic Complete? │
|
|
||||||
└────────┬───────┘
|
|
||||||
│
|
|
||||||
┌────┼────┐
|
|
||||||
│ │
|
|
||||||
Yes No
|
|
||||||
│ └──> Continue to next story
|
|
||||||
│
|
|
||||||
▼
|
|
||||||
┌─────────────────┐
|
|
||||||
│ Retrospective │ → Review epic, lessons learned
|
|
||||||
└─────────────────┘
|
|
||||||
│
|
|
||||||
▼
|
|
||||||
All epics done?
|
|
||||||
│
|
|
||||||
Yes → PROJECT COMPLETE
|
|
||||||
>>>>>>> Stashed changes
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Related Documentation
|
## Related Documentation
|
||||||
|
|
||||||
- [Phase 1: Analysis Workflows](./workflows-analysis.md)
|
- [Phase 1: Analysis Workflows](./workflows-analysis.md)
|
||||||
- [Phase 2: Planning Workflows](./workflows-planning.md)
|
- [Phase 2: Planning Workflows](./workflows-planning.md)
|
||||||
- [Phase 3: Solutioning Workflows](./workflows-solutioning.md)
|
- [Phase 3: Solutioning Workflows](./workflows-solutioning.md)
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## Troubleshooting
|
## Troubleshooting
|
||||||
|
|
||||||
**Q: Which workflow should I run next?**
|
**Q: Which workflow should I run next?**
|
||||||
|
|
@ -306,6 +208,4 @@ A: Not recommended. Complete one story's full lifecycle before starting the next
|
||||||
**Q: What if code review finds issues?**
|
**Q: What if code review finds issues?**
|
||||||
A: DEV runs `dev-story` to make fixes, re-runs tests, then runs `code-review` again until it passes.
|
A: DEV runs `dev-story` to make fixes, re-runs tests, then runs `code-review` again until it passes.
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
_Phase 4 Implementation - One story at a time, done right._
|
_Phase 4 Implementation - One story at a time, done right._
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@
|
||||||
|
|
||||||
code: bmm
|
code: bmm
|
||||||
name: "BMM: BMad Method Agile-AI Driven-Development"
|
name: "BMM: BMad Method Agile-AI Driven-Development"
|
||||||
default_selected: false # This module will be selected by default for new installations
|
default_selected: true # This module will be selected by default for new installations
|
||||||
|
|
||||||
header: "BMad Method™: Breakthrough Method of Agile-Ai Driven-Dev"
|
header: "BMad Method™: Breakthrough Method of Agile-Ai Driven-Dev"
|
||||||
subheader: "Agent and Workflow Configuration for this module"
|
subheader: "Agent and Workflow Configuration for this module"
|
||||||
|
|
|
||||||
|
|
@ -132,8 +132,12 @@ class ConfigCollector {
|
||||||
* Collect configuration for all modules
|
* Collect configuration for all modules
|
||||||
* @param {Array} modules - List of modules to configure (including 'core')
|
* @param {Array} modules - List of modules to configure (including 'core')
|
||||||
* @param {string} projectDir - Target project directory
|
* @param {string} projectDir - Target project directory
|
||||||
|
* @param {Object} options - Additional options
|
||||||
|
* @param {Map} options.customModulePaths - Map of module ID to source path for custom modules
|
||||||
*/
|
*/
|
||||||
async collectAllConfigurations(modules, projectDir) {
|
async collectAllConfigurations(modules, projectDir, options = {}) {
|
||||||
|
// Store custom module paths for use in collectModuleConfig
|
||||||
|
this.customModulePaths = options.customModulePaths || new Map();
|
||||||
await this.loadExistingConfig(projectDir);
|
await this.loadExistingConfig(projectDir);
|
||||||
|
|
||||||
// Check if core was already collected (e.g., in early collection phase)
|
// Check if core was already collected (e.g., in early collection phase)
|
||||||
|
|
@ -451,11 +455,21 @@ class ConfigCollector {
|
||||||
this.allAnswers = {};
|
this.allAnswers = {};
|
||||||
}
|
}
|
||||||
// Load module's config
|
// Load module's config
|
||||||
// First, try the standard src/modules location
|
// First, check if we have a custom module path for this module
|
||||||
let installerConfigPath = path.join(getModulePath(moduleName), '_module-installer', 'module.yaml');
|
let installerConfigPath = null;
|
||||||
let moduleConfigPath = path.join(getModulePath(moduleName), 'module.yaml');
|
let moduleConfigPath = null;
|
||||||
|
|
||||||
// If not found in src/modules, we need to find it by searching the project
|
if (this.customModulePaths && this.customModulePaths.has(moduleName)) {
|
||||||
|
const customPath = this.customModulePaths.get(moduleName);
|
||||||
|
installerConfigPath = path.join(customPath, '_module-installer', 'module.yaml');
|
||||||
|
moduleConfigPath = path.join(customPath, 'module.yaml');
|
||||||
|
} else {
|
||||||
|
// Try the standard src/modules location
|
||||||
|
installerConfigPath = path.join(getModulePath(moduleName), '_module-installer', 'module.yaml');
|
||||||
|
moduleConfigPath = path.join(getModulePath(moduleName), 'module.yaml');
|
||||||
|
}
|
||||||
|
|
||||||
|
// If not found in src/modules or custom paths, search the project
|
||||||
if (!(await fs.pathExists(installerConfigPath)) && !(await fs.pathExists(moduleConfigPath))) {
|
if (!(await fs.pathExists(installerConfigPath)) && !(await fs.pathExists(moduleConfigPath))) {
|
||||||
// Use the module manager to find the module source
|
// Use the module manager to find the module source
|
||||||
const { ModuleManager } = require('../modules/manager');
|
const { ModuleManager } = require('../modules/manager');
|
||||||
|
|
|
||||||
|
|
@ -435,8 +435,53 @@ If AgentVibes party mode is enabled, immediately trigger TTS with agent's voice:
|
||||||
// Quick update already collected all configs, use them directly
|
// Quick update already collected all configs, use them directly
|
||||||
moduleConfigs = this.configCollector.collectedConfig;
|
moduleConfigs = this.configCollector.collectedConfig;
|
||||||
} else {
|
} else {
|
||||||
|
// Build custom module paths map from customContent
|
||||||
|
const customModulePaths = new Map();
|
||||||
|
|
||||||
|
// Handle selectedFiles (from existing install path or manual directory input)
|
||||||
|
if (config.customContent && config.customContent.selected && config.customContent.selectedFiles) {
|
||||||
|
const { CustomHandler } = require('../custom/handler');
|
||||||
|
const customHandler = new CustomHandler();
|
||||||
|
for (const customFile of config.customContent.selectedFiles) {
|
||||||
|
const customInfo = await customHandler.getCustomInfo(customFile, path.resolve(config.directory));
|
||||||
|
if (customInfo && customInfo.id) {
|
||||||
|
customModulePaths.set(customInfo.id, customInfo.path);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
// Handle cachedModules (from new install path where modules are cached)
|
||||||
|
// Only include modules that were actually selected for installation
|
||||||
|
if (config.customContent && config.customContent.cachedModules) {
|
||||||
|
// Get selected cached module IDs (if available)
|
||||||
|
const selectedCachedIds = config.customContent.selectedCachedModules || [];
|
||||||
|
// If no selection info, include all cached modules (for backward compatibility)
|
||||||
|
const shouldIncludeAll = selectedCachedIds.length === 0 && config.customContent.selected;
|
||||||
|
|
||||||
|
for (const cachedModule of config.customContent.cachedModules) {
|
||||||
|
// For cached modules, the path is the cachePath which contains the module.yaml
|
||||||
|
if (
|
||||||
|
cachedModule.id &&
|
||||||
|
cachedModule.cachePath && // Include if selected or if we should include all
|
||||||
|
(shouldIncludeAll || selectedCachedIds.includes(cachedModule.id))
|
||||||
|
) {
|
||||||
|
customModulePaths.set(cachedModule.id, cachedModule.cachePath);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
// Get list of all modules including custom modules
|
||||||
|
const allModulesForConfig = [...(config.modules || [])];
|
||||||
|
for (const [moduleId] of customModulePaths) {
|
||||||
|
if (!allModulesForConfig.includes(moduleId)) {
|
||||||
|
allModulesForConfig.push(moduleId);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
// Regular install - collect configurations (core was already collected in UI.promptInstall if interactive)
|
// Regular install - collect configurations (core was already collected in UI.promptInstall if interactive)
|
||||||
moduleConfigs = await this.configCollector.collectAllConfigurations(config.modules || [], path.resolve(config.directory));
|
moduleConfigs = await this.configCollector.collectAllConfigurations(allModulesForConfig, path.resolve(config.directory), {
|
||||||
|
customModulePaths,
|
||||||
|
});
|
||||||
}
|
}
|
||||||
|
|
||||||
// Get bmad_folder from config (default to 'bmad' for backwards compatibility)
|
// Get bmad_folder from config (default to 'bmad' for backwards compatibility)
|
||||||
|
|
@ -905,10 +950,13 @@ If AgentVibes party mode is enabled, immediately trigger TTS with agent's voice:
|
||||||
const moduleTargetPath = path.join(bmadDir, moduleName);
|
const moduleTargetPath = path.join(bmadDir, moduleName);
|
||||||
await fs.ensureDir(moduleTargetPath);
|
await fs.ensureDir(moduleTargetPath);
|
||||||
|
|
||||||
|
// Get collected config for this custom module (from module.yaml prompts)
|
||||||
|
const collectedModuleConfig = moduleConfigs[moduleName] || {};
|
||||||
|
|
||||||
const result = await customHandler.install(
|
const result = await customHandler.install(
|
||||||
customInfo.path,
|
customInfo.path,
|
||||||
path.join(bmadDir, 'temp-custom'),
|
path.join(bmadDir, 'temp-custom'),
|
||||||
{ ...config.coreConfig, ...customInfo.config, _bmadDir: bmadDir },
|
{ ...config.coreConfig, ...customInfo.config, ...collectedModuleConfig, _bmadDir: bmadDir },
|
||||||
(filePath) => {
|
(filePath) => {
|
||||||
// Track installed files with correct path
|
// Track installed files with correct path
|
||||||
const relativePath = path.relative(path.join(bmadDir, 'temp-custom'), filePath);
|
const relativePath = path.relative(path.join(bmadDir, 'temp-custom'), filePath);
|
||||||
|
|
@ -939,8 +987,10 @@ If AgentVibes party mode is enabled, immediately trigger TTS with agent's voice:
|
||||||
await fs.remove(tempCustomPath);
|
await fs.remove(tempCustomPath);
|
||||||
}
|
}
|
||||||
|
|
||||||
// Create module config
|
// Create module config (include collected config from module.yaml prompts)
|
||||||
await this.generateModuleConfigs(bmadDir, { [moduleName]: { ...config.coreConfig, ...customInfo.config } });
|
await this.generateModuleConfigs(bmadDir, {
|
||||||
|
[moduleName]: { ...config.coreConfig, ...customInfo.config, ...collectedModuleConfig },
|
||||||
|
});
|
||||||
|
|
||||||
// Store custom module info for later manifest update
|
// Store custom module info for later manifest update
|
||||||
if (!config._customModulesToTrack) {
|
if (!config._customModulesToTrack) {
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue