bmad-method 6.9.1-next.10 → 6.9.1-next.11

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 CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "$schema": "https://json.schemastore.org/package.json",
3
3
  "name": "bmad-method",
4
- "version": "6.9.1-next.10",
4
+ "version": "6.9.1-next.11",
5
5
  "description": "Breakthrough Method of Agile AI-driven Development",
6
6
  "keywords": [
7
7
  "agile",
@@ -6,7 +6,6 @@
6
6
  ## RULES
7
7
 
8
8
  - YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
9
- - Be precise. When uncertain between categories, prefer the more conservative classification.
10
9
 
11
10
  ## INSTRUCTIONS
12
11
 
@@ -29,13 +28,15 @@
29
28
  - Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
30
29
  - Set `source` to the merged sources (e.g., `blind+edge`).
31
30
 
32
- 3. **Assign severity** to each finding by consequence for the artifact's main consumer (software user, document reader, etc).
31
+ 3. **Read the code before rating.** Before assigning severity, open the source at each finding's location and read enough surrounding code to judge reachability -- call sites, guards, and validation that live outside the diff hunk. Do not rate from the diff hunk alone. Severity reflects the real consequence at a real call site, not the worst theoretical reading.
32
+
33
+ 4. **Assign severity** to each finding by consequence for the artifact's main consumer (software user, document reader, etc).
33
34
  Disregard any severity assigned by a reviewing subagent. Review subagents operate under by-design information asymmetry and do not have enough context to set final severity for this workflow.
34
35
  - `low` -- none or cosmetic
35
36
  - `medium` -- tolerable
36
37
  - `high` -- intolerable
37
38
 
38
- 4. **Route** each finding into exactly one triage bucket:
39
+ 5. **Route** each finding into exactly one triage bucket:
39
40
  - **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
40
41
  - **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
41
42
  - **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
@@ -43,11 +44,11 @@
43
44
 
44
45
  If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
45
46
 
46
- 5. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
47
+ 6. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
47
48
 
48
- 6. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
49
+ 7. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
49
50
 
50
- 7. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
51
+ 8. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
51
52
 
52
53
 
53
54
  ## NEXT