bmad-method 6.3.1-next.5 → 6.3.1-next.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/package.json +1 -2
- package/src/bmm-skills/2-plan-workflows/bmad-create-prd/steps-c/step-08-scoping.md +70 -23
- package/src/bmm-skills/2-plan-workflows/bmad-create-prd/steps-c/step-11-polish.md +1 -1
- package/tools/installer/commands/status.js +1 -1
- package/tools/installer/commands/uninstall.js +1 -1
- package/tools/installer/core/existing-install.js +1 -1
- package/tools/installer/core/install-paths.js +1 -1
- package/tools/installer/core/installer.js +1 -1
- package/tools/installer/core/manifest-generator.js +1 -1
- package/tools/installer/core/manifest.js +1 -1
- package/tools/installer/file-ops.js +1 -1
- package/tools/installer/fs-native.js +111 -0
- package/tools/installer/ide/_config-driven.js +1 -1
- package/tools/installer/ide/platform-codes.js +1 -1
- package/tools/installer/ide/shared/skill-manifest.js +1 -1
- package/tools/installer/message-loader.js +1 -1
- package/tools/installer/modules/community-manager.js +1 -1
- package/tools/installer/modules/custom-module-manager.js +1 -1
- package/tools/installer/modules/external-manager.js +1 -1
- package/tools/installer/modules/official-modules.js +1 -1
- package/tools/installer/modules/plugin-resolver.js +1 -1
- package/tools/installer/project-root.js +1 -1
- package/tools/installer/ui.js +1 -1
- package/tools/migrate-custom-module-paths.js +1 -1
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "https://json.schemastore.org/package.json",
|
|
3
3
|
"name": "bmad-method",
|
|
4
|
-
"version": "6.3.1-next.
|
|
4
|
+
"version": "6.3.1-next.7",
|
|
5
5
|
"description": "Breakthrough Method of Agile AI-driven Development",
|
|
6
6
|
"keywords": [
|
|
7
7
|
"agile",
|
|
@@ -70,7 +70,6 @@
|
|
|
70
70
|
"chalk": "^4.1.2",
|
|
71
71
|
"commander": "^14.0.0",
|
|
72
72
|
"csv-parse": "^6.1.0",
|
|
73
|
-
"fs-extra": "^11.3.0",
|
|
74
73
|
"glob": "^11.0.3",
|
|
75
74
|
"ignore": "^7.0.5",
|
|
76
75
|
"js-yaml": "^4.1.0",
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
# Step 8: Scoping Exercise -
|
|
1
|
+
# Step 8: Scoping Exercise - Scope Definition (Phased or Single-Release)
|
|
2
2
|
|
|
3
3
|
**Progress: Step 8 of 11** - Next: Functional Requirements
|
|
4
4
|
|
|
@@ -12,6 +12,8 @@
|
|
|
12
12
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
|
13
13
|
- 💬 FOCUS on strategic scope decisions that keep projects viable
|
|
14
14
|
- 🎯 EMPHASIZE lean MVP thinking while preserving long-term vision
|
|
15
|
+
- ⚠️ NEVER de-scope, defer, or phase out requirements that the user explicitly included in their input documents without asking first
|
|
16
|
+
- ⚠️ NEVER invent phasing (MVP/Growth/Vision) unless the user requests phased delivery — if input documents define all components as core requirements, they are ALL in scope
|
|
15
17
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
|
16
18
|
- ✅ YOU MUST ALWAYS WRITE all artifact and document content in `{document_output_language}`
|
|
17
19
|
|
|
@@ -34,7 +36,7 @@
|
|
|
34
36
|
|
|
35
37
|
## YOUR TASK:
|
|
36
38
|
|
|
37
|
-
Conduct comprehensive scoping exercise to define
|
|
39
|
+
Conduct comprehensive scoping exercise to define release boundaries and prioritize features based on the user's chosen delivery mode (phased or single-release).
|
|
38
40
|
|
|
39
41
|
## SCOPING SEQUENCE:
|
|
40
42
|
|
|
@@ -75,30 +77,41 @@ Use structured decision-making for scope:
|
|
|
75
77
|
- Advanced functionality that builds on MVP
|
|
76
78
|
- Ask what features could be added in versions 2, 3, etc.
|
|
77
79
|
|
|
80
|
+
**⚠️ SCOPE CHANGE CONFIRMATION GATE:**
|
|
81
|
+
- If you believe any user-specified requirement should be deferred or de-scoped, you MUST present this to the user and get explicit confirmation BEFORE removing it from scope
|
|
82
|
+
- Frame it as a recommendation, not a decision: "I'd recommend deferring X because [reason]. Do you agree, or should it stay in scope?"
|
|
83
|
+
- NEVER silently move user requirements to a later phase or exclude them from MVP
|
|
84
|
+
- Before creating any consequential phase-based artifacts (e.g., phase tags, labels, or follow-on prompts), present artifact creation as a recommendation and proceed only after explicit user approval
|
|
85
|
+
|
|
78
86
|
### 4. Progressive Feature Roadmap
|
|
79
87
|
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
88
|
+
**CRITICAL: Phasing is NOT automatic. Check the user's input first.**
|
|
89
|
+
|
|
90
|
+
Before proposing any phased approach, review the user's input documents:
|
|
91
|
+
|
|
92
|
+
- **If the input documents define all components as core requirements with no mention of phases:** Present all requirements as a single release scope. Do NOT invent phases or move requirements to fabricated future phases.
|
|
93
|
+
- **If the input documents explicitly request phased delivery:** Guide mapping of features across the phases the user defined.
|
|
94
|
+
- **If scope is unclear:** ASK the user whether they want phased delivery or a single release before proceeding.
|
|
84
95
|
|
|
85
|
-
|
|
86
|
-
- Essential user journeys
|
|
87
|
-
- Basic functionality that works reliably
|
|
96
|
+
**When the user requests phased delivery**, guide mapping of features across the phases the user defines:
|
|
88
97
|
|
|
89
|
-
|
|
98
|
+
- Use user-provided phase labels and count; if none are provided, propose a default (e.g., MVP/Growth/Vision) and ask for confirmation
|
|
99
|
+
- Ensure clear progression and dependencies between phases
|
|
90
100
|
|
|
91
|
-
|
|
92
|
-
- Enhanced features
|
|
93
|
-
- Scale improvements
|
|
101
|
+
**Each phase should address:**
|
|
94
102
|
|
|
95
|
-
|
|
103
|
+
- Core user value delivery and essential journeys for that phase
|
|
104
|
+
- Clear boundaries on what ships in each phase
|
|
105
|
+
- Dependencies on prior phases
|
|
96
106
|
|
|
97
|
-
|
|
98
|
-
- Platform features
|
|
99
|
-
- New markets or use cases
|
|
107
|
+
**When the user chooses a single release**, define the complete scope:
|
|
100
108
|
|
|
101
|
-
|
|
109
|
+
- All user-specified requirements are in scope
|
|
110
|
+
- Focus must-have vs nice-to-have analysis on what ships in this release
|
|
111
|
+
- Do NOT create phases — use must-have/nice-to-have priority within the single release
|
|
112
|
+
|
|
113
|
+
**If phased delivery:** "Where does your current vision fit in this development sequence?"
|
|
114
|
+
**If single release:** "How does your current vision map to this upcoming release?"
|
|
102
115
|
|
|
103
116
|
### 5. Risk-Based Scoping
|
|
104
117
|
|
|
@@ -129,6 +142,8 @@ Prepare comprehensive scoping section:
|
|
|
129
142
|
|
|
130
143
|
#### Content Structure:
|
|
131
144
|
|
|
145
|
+
**If user chose phased delivery:**
|
|
146
|
+
|
|
132
147
|
```markdown
|
|
133
148
|
## Project Scoping & Phased Development
|
|
134
149
|
|
|
@@ -160,11 +175,39 @@ Prepare comprehensive scoping section:
|
|
|
160
175
|
**Resource Risks:** {{contingency_approach}}
|
|
161
176
|
```
|
|
162
177
|
|
|
178
|
+
**If user chose single release (no phasing):**
|
|
179
|
+
|
|
180
|
+
```markdown
|
|
181
|
+
## Project Scoping
|
|
182
|
+
|
|
183
|
+
### Strategy & Philosophy
|
|
184
|
+
|
|
185
|
+
**Approach:** {{chosen_approach}}
|
|
186
|
+
**Resource Requirements:** {{team_size_and_skills}}
|
|
187
|
+
|
|
188
|
+
### Complete Feature Set
|
|
189
|
+
|
|
190
|
+
**Core User Journeys Supported:**
|
|
191
|
+
{{all_journeys}}
|
|
192
|
+
|
|
193
|
+
**Must-Have Capabilities:**
|
|
194
|
+
{{list_of_must_have_features}}
|
|
195
|
+
|
|
196
|
+
**Nice-to-Have Capabilities:**
|
|
197
|
+
{{list_of_nice_to_have_features}}
|
|
198
|
+
|
|
199
|
+
### Risk Mitigation Strategy
|
|
200
|
+
|
|
201
|
+
**Technical Risks:** {{mitigation_approach}}
|
|
202
|
+
**Market Risks:** {{validation_approach}}
|
|
203
|
+
**Resource Risks:** {{contingency_approach}}
|
|
204
|
+
```
|
|
205
|
+
|
|
163
206
|
### 7. Present MENU OPTIONS
|
|
164
207
|
|
|
165
208
|
Present the scoping decisions for review, then display menu:
|
|
166
209
|
- Show strategic scoping plan (using structure from step 6)
|
|
167
|
-
- Highlight
|
|
210
|
+
- Highlight release boundaries and prioritization (phased roadmap only if phased delivery was selected)
|
|
168
211
|
- Ask if they'd like to refine further, get other perspectives, or proceed
|
|
169
212
|
- Present menu options naturally as part of conversation
|
|
170
213
|
|
|
@@ -173,7 +216,7 @@ Display: "**Select:** [A] Advanced Elicitation [P] Party Mode [C] Continue to Fu
|
|
|
173
216
|
#### Menu Handling Logic:
|
|
174
217
|
- IF A: Invoke the `bmad-advanced-elicitation` skill with the current scoping analysis, process the enhanced insights that come back, ask user if they accept the improvements, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
|
175
218
|
- IF P: Invoke the `bmad-party-mode` skill with the scoping context, process the collaborative insights on MVP and roadmap decisions, ask user if they accept the changes, if yes update content then redisplay menu, if no keep original content then redisplay menu
|
|
176
|
-
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array, then read fully and follow: ./step-09-functional.md
|
|
219
|
+
- IF C: Append the final content to {outputFile}, update frontmatter by adding this step name to the end of the stepsCompleted array (also add `releaseMode: phased` or `releaseMode: single-release` to frontmatter based on user's choice), then read fully and follow: ./step-09-functional.md
|
|
177
220
|
- IF Any other: help user respond, then redisplay menu
|
|
178
221
|
|
|
179
222
|
#### EXECUTION RULES:
|
|
@@ -189,8 +232,9 @@ When user selects 'C', append the content directly to the document using the str
|
|
|
189
232
|
|
|
190
233
|
✅ Complete PRD document analyzed for scope implications
|
|
191
234
|
✅ Strategic MVP approach defined and justified
|
|
192
|
-
✅ Clear
|
|
193
|
-
✅
|
|
235
|
+
✅ Clear feature boundaries established (phased or single-release, per user preference)
|
|
236
|
+
✅ All user-specified requirements accounted for — none silently removed or deferred
|
|
237
|
+
✅ Any scope reduction recommendations presented to user with rationale and explicit confirmation obtained
|
|
194
238
|
✅ Key risks identified and mitigation strategies defined
|
|
195
239
|
✅ User explicitly agrees to scope decisions
|
|
196
240
|
✅ A/P/C menu presented and handled correctly
|
|
@@ -202,8 +246,11 @@ When user selects 'C', append the content directly to the document using the str
|
|
|
202
246
|
❌ Making scope decisions without strategic rationale
|
|
203
247
|
❌ Not getting explicit user agreement on MVP boundaries
|
|
204
248
|
❌ Missing critical risk analysis
|
|
205
|
-
❌ Not creating clear phased development approach
|
|
206
249
|
❌ Not presenting A/P/C menu after content generation
|
|
250
|
+
❌ **CRITICAL**: Silently de-scoping or deferring requirements that the user explicitly included in their input documents
|
|
251
|
+
❌ **CRITICAL**: Inventing phasing (MVP/Growth/Vision) when the user did not request phased delivery
|
|
252
|
+
❌ **CRITICAL**: Making consequential scoping decisions (what is in/out of scope) without explicit user confirmation
|
|
253
|
+
❌ **CRITICAL**: Creating phase-based artifacts (tags, labels, follow-on prompts) without explicit user approval
|
|
207
254
|
|
|
208
255
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
|
209
256
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
|
@@ -138,7 +138,7 @@ Make targeted improvements:
|
|
|
138
138
|
- All user success criteria
|
|
139
139
|
- All functional requirements (capability contract)
|
|
140
140
|
- All user journey narratives
|
|
141
|
-
- All scope decisions (
|
|
141
|
+
- All scope decisions (whether phased or single-release), including consent-critical evidence (explicit user confirmations and rationales for any scope changes from step 8)
|
|
142
142
|
- All non-functional requirements
|
|
143
143
|
- Product differentiator and vision
|
|
144
144
|
- Domain-specific requirements
|
|
@@ -19,7 +19,7 @@ module.exports = {
|
|
|
19
19
|
const { bmadDir } = await installer.findBmadDir(projectDir);
|
|
20
20
|
|
|
21
21
|
// Check if bmad directory exists
|
|
22
|
-
const fs = require('fs-
|
|
22
|
+
const fs = require('../fs-native');
|
|
23
23
|
if (!(await fs.pathExists(bmadDir))) {
|
|
24
24
|
await prompts.log.warn('No BMAD installation found in the current directory.');
|
|
25
25
|
await prompts.log.message(`Expected location: ${bmadDir}`);
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
const path = require('node:path');
|
|
2
|
-
const fs = require('fs-
|
|
2
|
+
const fs = require('../fs-native');
|
|
3
3
|
const { Manifest } = require('./manifest');
|
|
4
4
|
const { OfficialModules } = require('../modules/official-modules');
|
|
5
5
|
const { IdeManager } = require('../ide/manager');
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
// Drop-in replacement for fs-extra using native node:fs APIs.
|
|
2
|
+
// Eliminates graceful-fs monkey-patching that causes non-deterministic
|
|
3
|
+
// file loss during multi-module installs on macOS (issue #1779).
|
|
4
|
+
const fsp = require('node:fs/promises');
|
|
5
|
+
const fs = require('node:fs');
|
|
6
|
+
const path = require('node:path');
|
|
7
|
+
|
|
8
|
+
async function pathExists(p) {
|
|
9
|
+
try {
|
|
10
|
+
await fsp.access(p);
|
|
11
|
+
return true;
|
|
12
|
+
} catch {
|
|
13
|
+
return false;
|
|
14
|
+
}
|
|
15
|
+
}
|
|
16
|
+
|
|
17
|
+
async function ensureDir(dir) {
|
|
18
|
+
await fsp.mkdir(dir, { recursive: true });
|
|
19
|
+
}
|
|
20
|
+
|
|
21
|
+
async function remove(p) {
|
|
22
|
+
await fsp.rm(p, { recursive: true, force: true });
|
|
23
|
+
}
|
|
24
|
+
|
|
25
|
+
async function copy(src, dest, options = {}) {
|
|
26
|
+
const filterFn = options.filter;
|
|
27
|
+
const overwrite = options.overwrite !== false;
|
|
28
|
+
const srcStat = await fsp.stat(src);
|
|
29
|
+
|
|
30
|
+
if (srcStat.isFile()) {
|
|
31
|
+
if (filterFn && !(await filterFn(src, dest))) return;
|
|
32
|
+
await fsp.mkdir(path.dirname(dest), { recursive: true });
|
|
33
|
+
if (!overwrite) {
|
|
34
|
+
try {
|
|
35
|
+
await fsp.access(dest);
|
|
36
|
+
if (options.errorOnExist) throw new Error(`${dest} already exists`);
|
|
37
|
+
return;
|
|
38
|
+
} catch (error) {
|
|
39
|
+
if (error.message.includes('already exists')) throw error;
|
|
40
|
+
}
|
|
41
|
+
}
|
|
42
|
+
await fsp.copyFile(src, dest);
|
|
43
|
+
return;
|
|
44
|
+
}
|
|
45
|
+
|
|
46
|
+
if (srcStat.isDirectory()) {
|
|
47
|
+
if (filterFn && !(await filterFn(src, dest))) return;
|
|
48
|
+
await fsp.mkdir(dest, { recursive: true });
|
|
49
|
+
const entries = await fsp.readdir(src, { withFileTypes: true });
|
|
50
|
+
for (const entry of entries) {
|
|
51
|
+
await copy(path.join(src, entry.name), path.join(dest, entry.name), options);
|
|
52
|
+
}
|
|
53
|
+
}
|
|
54
|
+
}
|
|
55
|
+
|
|
56
|
+
async function move(src, dest) {
|
|
57
|
+
try {
|
|
58
|
+
await fsp.rename(src, dest);
|
|
59
|
+
} catch (error) {
|
|
60
|
+
if (error.code === 'EXDEV') {
|
|
61
|
+
await copy(src, dest);
|
|
62
|
+
await fsp.rm(src, { recursive: true, force: true });
|
|
63
|
+
} else {
|
|
64
|
+
throw error;
|
|
65
|
+
}
|
|
66
|
+
}
|
|
67
|
+
}
|
|
68
|
+
|
|
69
|
+
function readJsonSync(p) {
|
|
70
|
+
return JSON.parse(fs.readFileSync(p, 'utf8'));
|
|
71
|
+
}
|
|
72
|
+
|
|
73
|
+
async function writeJson(p, data, options = {}) {
|
|
74
|
+
const spaces = options.spaces ?? 2;
|
|
75
|
+
await fsp.writeFile(p, JSON.stringify(data, null, spaces) + '\n', 'utf8');
|
|
76
|
+
}
|
|
77
|
+
|
|
78
|
+
module.exports = {
|
|
79
|
+
// Native async (node:fs/promises)
|
|
80
|
+
readFile: fsp.readFile,
|
|
81
|
+
writeFile: fsp.writeFile,
|
|
82
|
+
stat: fsp.stat,
|
|
83
|
+
readdir: fsp.readdir,
|
|
84
|
+
access: fsp.access,
|
|
85
|
+
rename: fsp.rename,
|
|
86
|
+
unlink: fsp.unlink,
|
|
87
|
+
chmod: fsp.chmod,
|
|
88
|
+
mkdir: fsp.mkdir,
|
|
89
|
+
mkdtemp: fsp.mkdtemp,
|
|
90
|
+
copyFile: fsp.copyFile,
|
|
91
|
+
rm: fsp.rm,
|
|
92
|
+
|
|
93
|
+
// fs-extra compatible helpers (native implementations)
|
|
94
|
+
pathExists,
|
|
95
|
+
ensureDir,
|
|
96
|
+
remove,
|
|
97
|
+
copy,
|
|
98
|
+
move,
|
|
99
|
+
readJsonSync,
|
|
100
|
+
writeJson,
|
|
101
|
+
|
|
102
|
+
// Sync methods from core node:fs
|
|
103
|
+
existsSync: fs.existsSync.bind(fs),
|
|
104
|
+
readFileSync: fs.readFileSync.bind(fs),
|
|
105
|
+
writeFileSync: fs.writeFileSync.bind(fs),
|
|
106
|
+
createReadStream: fs.createReadStream.bind(fs),
|
|
107
|
+
pathExistsSync: fs.existsSync.bind(fs),
|
|
108
|
+
|
|
109
|
+
// Constants
|
|
110
|
+
constants: fs.constants,
|
|
111
|
+
};
|
package/tools/installer/ui.js
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
const path = require('node:path');
|
|
2
2
|
const os = require('node:os');
|
|
3
|
-
const fs = require('fs-
|
|
3
|
+
const fs = require('./fs-native');
|
|
4
4
|
const { CLIUtils } = require('./cli-utils');
|
|
5
5
|
const { ExternalModuleManager } = require('./modules/external-manager');
|
|
6
6
|
const { getProjectRoot } = require('./project-root');
|