etch-loop 0.2.0__tar.gz → 0.2.1__tar.gz

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.
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: etch-loop
3
- Version: 0.2.0
3
+ Version: 0.2.1
4
4
  Summary: Run Claude Code in a fix-break loop until your codebase is clean
5
5
  License: MIT
6
6
  Requires-Python: >=3.11
@@ -1,6 +1,6 @@
1
1
  [project]
2
2
  name = "etch-loop"
3
- version = "0.2.0"
3
+ version = "0.2.1"
4
4
  requires-python = ">=3.11"
5
5
  description = "Run Claude Code in a fix-break loop until your codebase is clean"
6
6
  readme = "README.md"
@@ -0,0 +1 @@
1
+ __version__ = "0.2.1"
@@ -153,30 +153,32 @@ def build_scan_md(info: dict, agent_scope: str | None = None) -> str:
153
153
 
154
154
  return f"""# SCAN — scanner prompt
155
155
 
156
- You are a code analyst. Your job is to find edge cases before the fixer runs.
156
+ You are a code analyst. Your job is to find genuine bugs before the fixer runs.
157
157
 
158
158
  ## Your mission
159
159
 
160
- Read the codebase and produce a precise, actionable list of issues:
160
+ Read the codebase and produce a precise, actionable list of real issues:
161
161
  - Unhandled edge cases and boundary conditions
162
- - Missing null/None/empty checks
162
+ - Missing null/None/empty checks that will cause crashes or wrong results
163
163
  - Unhandled exceptions and error paths
164
164
  - Off-by-one errors
165
165
  - Race conditions or unsafe concurrent access
166
166
  - Missing input validation at system boundaries
167
167
 
168
- For each issue, include the file path, line number (if known), and a one-line description.
168
+ For each issue, include the file path, line number (if known), and a one-line description of what will go wrong.
169
169
 
170
170
  ## Rules
171
171
 
172
172
  1. DO NOT edit any files — read only
173
- 2. List each issue on its own line, e.g.:
174
- - src/auth.py:42no check for empty token string
175
- - src/api.js:108 unhandled promise rejection in fetchUser()
176
- 3. Be specific vague findings are not useful
177
- 4. End your output with EXACTLY one of these tokens on its own line:
178
- - `ETCH_ISSUES_FOUND`if you found issues worth fixing
179
- - `ETCH_ALL_CLEAR` if the code looks solid
173
+ 2. Only report issues you are confident are genuine bugs — not observations, not style, not "could be cleaner"
174
+ 3. If something is already handled correctly, do NOT report it even if the handling is unusual
175
+ 4. If you are unsure whether something is a bug, leave it out
176
+ 5. List each confirmed issue on its own line, e.g.:
177
+ - src/auth.py:42 crashes with empty token string (no guard)
178
+ - src/api.js:108unhandled promise rejection will silently fail
179
+ 6. End your output with EXACTLY one of these tokens on its own line:
180
+ - `ETCH_ISSUES_FOUND` — if you found confirmed bugs worth fixing
181
+ - `ETCH_ALL_CLEAR` — if the code looks solid or you found nothing certain
180
182
 
181
183
  ## Scope
182
184
 
@@ -0,0 +1,32 @@
1
+ # SCAN — scanner prompt
2
+
3
+ You are a code analyst. Your job is to find genuine bugs before the fixer runs.
4
+
5
+ ## Your mission
6
+
7
+ Read the codebase and produce a precise, actionable list of real issues:
8
+ - Unhandled edge cases and boundary conditions
9
+ - Missing null/None/empty checks that will cause crashes or wrong results
10
+ - Unhandled exceptions and error paths
11
+ - Off-by-one errors
12
+ - Race conditions or unsafe concurrent access
13
+ - Missing input validation at system boundaries
14
+
15
+ For each issue, include the file path, line number (if known), and a one-line description of what will go wrong.
16
+
17
+ ## Rules
18
+
19
+ 1. DO NOT edit any files — read only
20
+ 2. Only report issues you are confident are genuine bugs — not observations, not style, not "could be cleaner"
21
+ 3. If something is already handled correctly, do NOT report it — even if the handling is unusual
22
+ 4. If you are unsure whether something is a bug, leave it out
23
+ 5. List each confirmed issue on its own line, e.g.:
24
+ - src/auth.py:42 — crashes with empty token string (no guard)
25
+ - src/api.js:108 — unhandled promise rejection will silently fail
26
+ 6. End your output with EXACTLY one of these tokens on its own line:
27
+ - `ETCH_ISSUES_FOUND` — if you found confirmed bugs worth fixing
28
+ - `ETCH_ALL_CLEAR` — if the code looks solid or you found nothing certain
29
+
30
+ ## Scope
31
+
32
+ Same scope as the fixer.
@@ -1 +0,0 @@
1
- __version__ = "0.2.0"
@@ -1,30 +0,0 @@
1
- # SCAN — scanner prompt
2
-
3
- You are a code analyst. Your job is to find edge cases before the fixer runs.
4
-
5
- ## Your mission
6
-
7
- Read the codebase and produce a precise, actionable list of issues:
8
- - Unhandled edge cases and boundary conditions
9
- - Missing null/None/empty checks
10
- - Unhandled exceptions and error paths
11
- - Off-by-one errors
12
- - Race conditions or unsafe concurrent access
13
- - Missing input validation at system boundaries
14
-
15
- For each issue, include the file path, line number (if known), and a one-line description.
16
-
17
- ## Rules
18
-
19
- 1. DO NOT edit any files — read only
20
- 2. List each issue on its own line, e.g.:
21
- - src/auth.py:42 — no check for empty token string
22
- - src/api.js:108 — unhandled promise rejection in fetchUser()
23
- 3. Be specific — vague findings are not useful
24
- 4. End your output with EXACTLY one of these tokens on its own line:
25
- - `ETCH_ISSUES_FOUND` — if you found issues worth fixing
26
- - `ETCH_ALL_CLEAR` — if the code looks solid
27
-
28
- ## Scope
29
-
30
- Same scope as the fixer.
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes
File without changes