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.
- {etch_loop-0.2.0 → etch_loop-0.2.1}/PKG-INFO +1 -1
- {etch_loop-0.2.0 → etch_loop-0.2.1}/pyproject.toml +1 -1
- etch_loop-0.2.1/src/etch/__init__.py +1 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/analyze.py +13 -11
- etch_loop-0.2.1/src/etch/templates/SCAN.md +32 -0
- etch_loop-0.2.0/src/etch/__init__.py +0 -1
- etch_loop-0.2.0/src/etch/templates/SCAN.md +0 -30
- {etch_loop-0.2.0 → etch_loop-0.2.1}/.github/workflows/workflow.yml +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/README.md +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/agent.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/cli.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/display.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/git.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/loop.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/prompt.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/signals.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/templates/BREAK.md +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/src/etch/templates/ETCH.md +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/tests/__init__.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/tests/test_git.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/tests/test_loop.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/tests/test_prompt.py +0 -0
- {etch_loop-0.2.0 → etch_loop-0.2.1}/tests/test_signals.py +0 -0
|
@@ -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
|
|
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.
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
-
|
|
179
|
-
|
|
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:108 — unhandled 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
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|
|
File without changes
|