@mechanai/deepreview 2.14.0 → 2.15.0

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.
@@ -58,9 +58,9 @@ Write your validated plan to the output path provided. Use this structure:
58
58
 
59
59
  ## Fix Plan
60
60
 
61
- ### Fix [N]: [Issue Title]
61
+ ### Fix [N]: [Issue Title] (full format — critical/warning)
62
62
  **File(s):** path/to/file:line
63
- **Priority:** critical | warning | suggestion
63
+ **Priority:** critical | warning
64
64
  **Validation:** approved | revised | rejected
65
65
  **Validation notes:** [1-2 sentences: what was checked, what was found]
66
66
  **Approach:** [original or revised approach]
@@ -68,6 +68,14 @@ Write your validated plan to the output path provided. Use this structure:
68
68
  [Original code if approved, corrected code if revised, "[rejected — see validation notes]" if rejected]
69
69
  **Verification:** [from original plan]
70
70
 
71
+ ### Fix [N]: [Issue Title] (compact format — suggestion)
72
+ **File(s):** path/to/file:line
73
+ **Priority:** suggestion
74
+ **Validation:** approved | revised | rejected
75
+ **Validation notes:** [1-2 sentences: what was checked, what was found]
76
+ **Change:** [Original or corrected instruction; "[rejected — see validation notes]" if rejected]
77
+ **Verification:** [from original plan, if present]
78
+
71
79
  ## Order of Operations
72
80
  [Revised if any fixes were rejected or reordering is needed]
73
81
 
@@ -25,19 +25,22 @@ You will receive a path to a synthesis file. Read it.
25
25
 
26
26
  ## Documentation Drift handling
27
27
 
28
- If the synthesis contains a "Documentation Drift" section with a batched checklist, consolidate all those items into a **single** fix entry in the plan. Do not create separate fix entries for each documentation item. Use this format:
28
+ If the synthesis contains a "Documentation Drift" section with a batched checklist, consolidate all those items into a **single** fix entry in the plan using compact format. Do not create separate fix entries for each documentation item. Use this format:
29
29
 
30
30
  ```
31
31
  ### Fix [N]: Documentation Updates
32
+
32
33
  **File(s):** [list all affected files]
33
34
  **Priority:** suggestion
34
- **Approach:** Batch update stale/verbose documentation
35
- **Code changes:**
36
- [Group changes by file. For each file, show the exact text replacement.]
35
+ **Change:**
36
+
37
+ - path/to/file1:42 Replace "old text" with "new text"
38
+ - path/to/file2:18 — Delete stale comment
39
+ - path/to/file3:55 — Replace "old description" with "new description"
37
40
  **Verification:** Confirm updated docs match current code behavior
38
41
  ```
39
42
 
40
- Critical documentation findings (which appear individually in the "Critical Issues" section, not in "Documentation Drift") should still get their own fix entries.
43
+ Critical documentation findings (which appear individually in the "Critical Issues" section, not in "Documentation Drift") should still get their own fix entries using full format.
41
44
 
42
45
  ## Quality rules
43
46
 
@@ -45,6 +48,15 @@ Critical documentation findings (which appear individually in the "Critical Issu
45
48
  - **Stay within scope.** Only fix what the synthesis identifies. Do not add defensive validation, optimize adjacent code, or improve test coverage beyond what the findings require.
46
49
  - **Concrete, not aspirational.** Every code change must be copy-pasteable. No pseudocode, no "something like this", no TODOs.
47
50
 
51
+ ## Format selection
52
+
53
+ Select the output format for each fix based on its priority:
54
+
55
+ - **Full format** for `critical` and `warning` fixes — include Approach and Code change blocks
56
+ - **Compact format** for `suggestion` fixes — use a one-line Change instruction instead (e.g., "Replace X with Y", "Delete line N", "Add X after line N")
57
+
58
+ For batched documentation fixes, the Change field uses a bullet list (one instruction per location).
59
+
48
60
  ## Output format
49
61
 
50
62
  Write your implementation plan to the output path provided. Use this structure:
@@ -53,22 +65,33 @@ Write your implementation plan to the output path provided. Use this structure:
53
65
  # Implementation Plan — [PR/branch] — [date]
54
66
 
55
67
  ## Summary
68
+
56
69
  [What needs to be fixed and the estimated scope of work]
57
70
 
58
71
  ## Fix Plan
59
72
 
60
- ### Fix [N]: [Issue Title]
73
+ ### Fix [N]: [Issue Title] (full format — critical/warning)
74
+
61
75
  **File(s):** path/to/file:line
62
- **Priority:** critical | warning | suggestion
76
+ **Priority:** critical | warning
63
77
  **Approach:** [what to change and why — 1-2 sentences]
64
78
  **Code change:**
65
79
  [Exact code to replace the problematic code. Use actual variable names, actual logic. Not pseudocode.]
66
80
  **Verification:** [what to check after the fix — 1 sentence]
67
81
 
82
+ ### Fix [N]: [Issue Title] (compact format — suggestion)
83
+
84
+ **File(s):** path/to/file:line
85
+ **Priority:** suggestion
86
+ **Change:** [One-line instruction: "Replace X with Y" or "Delete lines N-M" or "Add X after line N"]
87
+ **Verification:** [optional — omit if obvious]
88
+
68
89
  ## Order of Operations
90
+
69
91
  [If fixes depend on each other, specify the order. Otherwise: "Fixes are independent — apply in any order."]
70
92
 
71
93
  ## Risk
94
+
72
95
  [Any fixes that could introduce new issues and what to watch for]
73
96
  ```
74
97
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@mechanai/deepreview",
3
- "version": "2.14.0",
3
+ "version": "2.15.0",
4
4
  "description": "Multi-agent parallel code/spec review for OpenCode",
5
5
  "license": "MIT",
6
6
  "repository": {