diff --git a/.gitignore b/.gitignore index 547e9e5a..e29148ed 100644 --- a/.gitignore +++ b/.gitignore @@ -57,3 +57,6 @@ tools/template-test-generator/test-scenarios/ # Test Install Output z*/ + +# BMVCS Migration Planning (local only) +.bmvcs-migration/ diff --git a/src/modules/bmvcs/_module-installer/installer.js b/src/modules/bmvcs/_module-installer/installer.js new file mode 100644 index 00000000..17b55c36 --- /dev/null +++ b/src/modules/bmvcs/_module-installer/installer.js @@ -0,0 +1,23 @@ +// BMVCS Module Installer +// Handles VCS discovery during installation + +async function install(config) { + console.log('Installing BMVCS module...'); + + // Create VCS config directory if needed + const vcsConfigPath = config.vcs_config_location; + console.log(`VCS config will be stored at: ${vcsConfigPath}`); + + // Run VCS discovery if user opted in + if (config.run_vcs_discovery === true) { + console.log('Running VCS discovery...'); + console.log('Please activate VCS Adapter agent and run: *discover'); + } else { + console.log('VCS discovery skipped. Run later via VCS Adapter agent: *discover'); + } + + console.log('✅ BMVCS module installed successfully'); + return true; +} + +module.exports = { install }; diff --git a/src/modules/bmvcs/tasks/create-vcs-adapted-doc.md b/src/modules/bmvcs/tasks/create-vcs-adapted-doc.md new file mode 100644 index 00000000..edd5cc9d --- /dev/null +++ b/src/modules/bmvcs/tasks/create-vcs-adapted-doc.md @@ -0,0 +1,165 @@ +# Create VCS-Adapted Document Task + +## Purpose + +Adapt architecture and other documents based on the team's version control system configuration. + +## Prerequisites + +- VCS configuration must exist in `.bmad-core/vcs-config.yaml` +- If not, run `discover-vcs.md` task first + +## Task Instructions + +### Step 1: Load VCS Configuration + +```yaml +load_config: + file: .bmad-core/vcs-config.yaml + fallback: + if_missing: 'Execute discover-vcs.md task first' +``` + +### Step 2: Load Appropriate VCS Template + +Based on `vcs_config.workflow`: + +- `github-flow` → Load `vcs-adaptations/git-github-flow.yaml` +- `gitflow` → Load `vcs-adaptations/git-gitflow.yaml` +- `trunk-based` → Load `vcs-adaptations/git-trunk-based.yaml` +- `none` → Load `vcs-adaptations/no-vcs.yaml` +- `custom` or other → Load `vcs-adaptations/custom-generic.yaml` + +### Step 3: Apply Adaptations to Document + +#### For Architecture Documents: + +**If Git-based (GitHub Flow/GitFlow/Trunk):** + +```yaml +adaptations: + structure: + - Include branch strategy section + - Add CI/CD pipeline considerations + - Reference commit conventions + + terminology: + - Use Git terminology (branch, commit, merge) + - Include PR/MR workflow details +``` + +**If No VCS:** + +```yaml +adaptations: + structure: + - Single comprehensive document + - Date-based versioning + - All diagrams embedded + + terminology: + - Avoid version control terms + - Focus on deliverables +``` + +**If Custom VCS:** + +```yaml +adaptations: + structure: + - Ask user for preferred format + - Mirror their documentation style + + terminology: + - Use their VCS terminology + - Avoid Git-specific references +``` + +### Step 4: Document Sections Based on VCS + +#### GitHub Flow Additions: + +```markdown +## Development Workflow + +- Feature branches from main +- Pull requests for review +- Continuous deployment after merge + +## Architecture Decisions per Feature + +- Lightweight ADRs in feature branches +- Architecture evolves with each PR +``` + +#### GitFlow Additions: + +```markdown +## Release Architecture + +- Version-specific considerations +- Migration paths between versions +- Hotfix procedures + +## Branch-Specific Components + +- Features in development +- Release candidates +- Production hotfixes +``` + +#### Trunk-Based Additions: + +```markdown +## Feature Flag Architecture + +- Flag-gated components +- Progressive rollout strategy +- Flag retirement plan + +## Continuous Architecture + +- Small, incremental changes +- Always-deployable state +``` + +#### No VCS Additions: + +```markdown +## Complete Package Contents + +- All source code included +- Setup instructions +- No external dependencies + +## Delivery Structure + +- Single ZIP/folder +- Date-stamped versions +``` + +### Step 5: Adapt Language and Recommendations + +Based on VCS type, adjust: + +- Deployment strategies +- Testing approaches +- Documentation structure +- Team collaboration patterns + +## Output Format + +The adapted document should: + +1. Respect the team's existing VCS practices +2. Use appropriate terminology +3. Structure content for their workflow +4. Include VCS-specific best practices +5. Avoid imposing foreign concepts + +## Success Criteria + +- Document aligns with team's VCS workflow +- No Git assumptions for non-Git users +- Practical, actionable guidance +- Respects existing team processes diff --git a/src/modules/bmvcs/tasks/discover-vcs.md b/src/modules/bmvcs/tasks/discover-vcs.md new file mode 100644 index 00000000..861159eb --- /dev/null +++ b/src/modules/bmvcs/tasks/discover-vcs.md @@ -0,0 +1,187 @@ +# VCS Discovery Task + +## Purpose + +Identify and adapt to the team's version control system at project initialization. + +## Philosophy + +- Optimize for the 85-90% who use Git +- Remain open for the 10-15% with special needs +- Suggest best practices without forcing them + +## Task Instructions + +### Step 1: Initial Discovery + +```yaml +elicit: true +prompt: | + How does your team manage code versions? + + 1. Git with GitHub/GitLab/Bitbucket [MOST COMMON] + 2. Git with corporate server + 3. Other version control system + 4. No version control needed + 5. Custom/Complex setup + + Select a number (1-5): +``` + +### Step 2A: Git-Based Workflows (Options 1-2) + +If user selects Git-based: + +```yaml +elicit: true +prompt: | + Which Git workflow best describes your team's approach? + + 1. GitHub Flow - Simple feature branches with pull requests + → Best for: Web apps, continuous deployment + + 2. GitFlow - Structured branches (develop, release, hotfix) + → Best for: Versioned software, scheduled releases + + 3. Trunk-Based - Direct commits or very short branches + → Best for: Mature CI/CD, experienced teams + + 4. Not sure - I'd like a recommendation + → We'll ask a few questions to suggest the best fit + + 5. Custom Git workflow + → Describe your approach + + Select a number (1-5): +``` + +#### If "Not sure" (Option 4): + +```yaml +elicit: true +questions: + - 'How many developers on your team? (1, 2-5, 6+)' + - 'How often do you release? (Daily, Weekly, Monthly, Quarterly)' + - 'Do you have automated testing? (Yes/No)' + - 'Do you need to maintain multiple versions? (Yes/No)' + +recommendation_logic: | + - Solo or Daily releases + Automated tests → Trunk-Based + - Small team + Weekly/Monthly → GitHub Flow + - Large team or Multiple versions → GitFlow + - Default → GitHub Flow (safest choice) +``` + +#### If "Custom" (Option 5): + +```yaml +elicit: true +prompt: | + Please briefly describe your Git workflow: + (e.g., "We use feature branches but merge to staging first, then production") + + [Free text input] +``` + +### Step 2B: Other VCS (Option 3) + +```yaml +elicit: true +prompt: | + Which version control system do you use? + + 1. Subversion (SVN) + 2. Perforce + 3. Mercurial + 4. Team Foundation Server (TFS) + 5. Other (please specify) + + Select a number or describe: +``` + +### Step 2C: No VCS (Option 4) + +```yaml +confirm: | + Understood. BMAD will generate: + - Self-contained deliverables + - Date-versioned packages + - No commit messages or branch references + + Is this a prototype/one-time project? (Yes/No) +``` + +### Step 2D: Complex Setup (Option 5) + +```yaml +elicit: true +prompt: | + Please describe your version control setup: + (e.g., "Monorepo with custom tooling", "Multiple systems for different components") + + [Free text input] +``` + +### Step 3: Store Configuration + +Save the VCS configuration for all agents to access: + +```yaml +vcs_config: + type: [git|svn|perforce|none|custom] + workflow: [github-flow|gitflow|trunk-based|custom|none] + details: [user's custom description if provided] + + adaptations: + artifact_format: [branches|monolithic|platform-specific] + terminology: [git|generic|platform-specific] + commit_style: [conventional|team-specific|none] +``` + +### Step 4: Confirm Understanding + +```yaml +output: | + VCS Configuration Confirmed: + - System: {type} + - Workflow: {workflow} + - BMAD will adapt by: {key_adaptations} + + All agents will generate artifacts compatible with your setup. +``` + +## Success Criteria + +- 80% of users can select from predefined options +- 20% custom cases are handled gracefully +- Configuration is stored and accessible to all agents +- No Git assumptions for non-Git users +- Clear recommendations when requested + +## Agent Adaptations Based on VCS + +### For Architect Agent + +- Git + GitHub Flow: Suggest feature-based architecture docs +- Git + GitFlow: Support release-oriented planning +- No VCS: Generate comprehensive, dated documents +- Custom: Ask for preferred format + +### For Dev Agent + +- Git workflows: Generate appropriate commit messages +- No VCS: Package complete code solutions +- Custom: Follow described conventions + +### For SM Agent + +- Git + Trunk: Create small, atomic stories +- Git + GitFlow: Support epic-based stories +- No VCS: Create comprehensive story documents + +## Notes + +- This discovery happens ONCE at project start +- All agents read this configuration +- Can be updated if team process changes +- Default to GitHub Flow if uncertain (most common, safest) diff --git a/src/modules/bmvcs/tasks/validate-vcs-config.md b/src/modules/bmvcs/tasks/validate-vcs-config.md new file mode 100644 index 00000000..eecfe017 --- /dev/null +++ b/src/modules/bmvcs/tasks/validate-vcs-config.md @@ -0,0 +1,76 @@ +# Validate VCS Configuration Task + +## Purpose + +Validate that the VCS configuration file exists and contains valid settings. + +## Task Instructions + +### Step 1: Check Configuration Exists + +```yaml +check_file: .bmad/vcs-config.yaml +if_missing: | + VCS configuration not found. Please run VCS discovery first: + - Activate VCS Adapter agent + - Run: *discover +``` + +### Step 2: Validate Structure + +```yaml +validate_yaml: + required_fields: + - vcs_config.type + - vcs_config.workflow + - vcs_config.adaptations.artifact_format + - vcs_config.adaptations.terminology + - vcs_config.adaptations.commit_style +``` + +### Step 3: Validate Values + +```yaml +validate_values: + vcs_config.type: + allowed: [git, svn, perforce, mercurial, tfs, none, custom] + + vcs_config.workflow: + allowed: [github-flow, gitflow, trunk-based, custom, none] + + vcs_config.adaptations.artifact_format: + allowed: [branches, monolithic, platform-specific] + + vcs_config.adaptations.terminology: + allowed: [git, svn, generic, platform-specific, custom] + + vcs_config.adaptations.commit_style: + allowed: [conventional, team-specific, none] +``` + +### Step 4: Report Results + +```yaml +output: | + ✅ VCS Configuration Valid + + System: {type} + Workflow: {workflow} + Artifact Format: {artifact_format} + Terminology: {terminology} + Commit Style: {commit_style} +``` + +## Error Handling + +If validation fails: +- Report specific field with error +- Suggest correction +- Offer to re-run discovery + +## Success Criteria + +- Configuration file exists +- All required fields present +- All values within allowed ranges +- YAML syntax valid