bmad-method 6.9.1-next.11 → 6.9.1-next.13
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
|
@@ -9,6 +9,7 @@ description: 'Walk every branching path and boundary condition in content, repor
|
|
|
9
9
|
When a diff is provided, scan only the diff hunks and list boundaries that are directly reachable from the changed lines and lack an explicit guard in the diff.
|
|
10
10
|
When no diff is provided (full file or function), treat the entire provided content as the scope.
|
|
11
11
|
Ignore the rest of the codebase unless the provided content explicitly references external functions.
|
|
12
|
+
A brief secondary deletion check runs as Step 4 when the diff removes code.
|
|
12
13
|
|
|
13
14
|
**Inputs:**
|
|
14
15
|
- **content** — Content to review: diff, full file, or function
|
|
@@ -33,6 +34,7 @@ Ignore the rest of the codebase unless the provided content explicitly reference
|
|
|
33
34
|
|
|
34
35
|
- If `also_consider` input was provided, incorporate those areas into the analysis
|
|
35
36
|
- Walk all branching paths: control flow (conditionals, loops, error handlers, early returns) and domain boundaries (where values, states, or conditions transition). Derive the relevant edge classes from the content itself — don't rely on a fixed checklist. Examples: missing else/default, unguarded inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
|
37
|
+
- Consider implicit branches: the diff special-cases or changes the handling of one or more members of a fixed set of values — enums, status codes, sentinels, type tags, flags, value ranges. The rest of the set is implicit branches (e.g. the diff changes the `RED` and `YELLOW` cases of a `RED`/`YELLOW`/`GREEN` enum; `GREEN` is the implicit branch)
|
|
36
38
|
- For each path: determine whether the content handles it
|
|
37
39
|
- Collect only the unhandled paths as findings — discard handled ones silently
|
|
38
40
|
|
|
@@ -41,14 +43,18 @@ Ignore the rest of the codebase unless the provided content explicitly reference
|
|
|
41
43
|
- Revisit every edge class from Step 2 — e.g., missing else/default, null/empty inputs, off-by-one loops, arithmetic overflow, implicit type coercion, race conditions, timeout gaps
|
|
42
44
|
- Add any newly found unhandled paths to findings; discard confirmed-handled ones
|
|
43
45
|
|
|
44
|
-
### Step 4:
|
|
46
|
+
### Step 4: Deletion Check
|
|
45
47
|
|
|
46
|
-
|
|
48
|
+
If the diff removed or replaced meaningful code (ignore pure renames and whitespace): load `references/deletion-check.md` and follow it.
|
|
49
|
+
|
|
50
|
+
### Step 5: Present Findings
|
|
51
|
+
|
|
52
|
+
Output all findings as a single JSON array following the Output Format specification exactly.
|
|
47
53
|
|
|
48
54
|
|
|
49
55
|
## OUTPUT FORMAT
|
|
50
56
|
|
|
51
|
-
Return ONLY a valid JSON array of objects. Each
|
|
57
|
+
Return ONLY a valid JSON array of objects. Each edge-case finding contains exactly these four fields:
|
|
52
58
|
|
|
53
59
|
```json
|
|
54
60
|
[{
|
|
@@ -59,7 +65,7 @@ Return ONLY a valid JSON array of objects. Each object must contain exactly thes
|
|
|
59
65
|
}]
|
|
60
66
|
```
|
|
61
67
|
|
|
62
|
-
No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when
|
|
68
|
+
No extra text, no explanations, no markdown wrapping. An empty array `[]` is valid when nothing is found. Deletion findings from Step 4, if any, go in the same array with the extra fields defined in `references/deletion-check.md`.
|
|
63
69
|
|
|
64
70
|
|
|
65
71
|
## HALT CONDITIONS
|
|
@@ -0,0 +1,14 @@
|
|
|
1
|
+
# Deletion Check
|
|
2
|
+
|
|
3
|
+
Secondary pass for the Edge Case Hunter — runs only when the diff removed meaningful code. Subordinate to the edge-case pass; findings are usually few or none.
|
|
4
|
+
|
|
5
|
+
For each chunk of removed or replaced code (ignore pure renames and whitespace), ask: did it carry behavior or a contract that the change neither re-established nor intentionally retired? Add a finding for any resulting regression, orphaned reference, or newly-dead code. Skip anything already covered by your edge-case findings.
|
|
6
|
+
|
|
7
|
+
Append each finding to the same JSON array as the edge-case findings, with the four standard fields plus:
|
|
8
|
+
|
|
9
|
+
- `kind`: `"deletion"`
|
|
10
|
+
- `confidence`: `"high"`, `"medium"`, or `"low"` — these are inferences; rate them
|
|
11
|
+
|
|
12
|
+
For a deletion finding the standard fields read as: `location` = the removed item; `trigger_condition` = the behavior or contract it enforced; `guard_snippet` = where or how to re-establish it; `potential_consequence` = the regression or orphan.
|
|
13
|
+
|
|
14
|
+
Add nothing if nothing qualifies.
|