etch-loop 0.4.6__tar.gz → 0.4.7__tar.gz

{etch_loop-0.4.6 → etch_loop-0.4.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: etch-loop
-Version: 0.4.6
+Version: 0.4.7
 Summary: Run Claude Code in a fix-break loop until your codebase is clean
 License: MIT
 Requires-Python: >=3.11

{etch_loop-0.4.6 → etch_loop-0.4.7}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "etch-loop"
-version = "0.4.6"
+version = "0.4.7"
 requires-python = ">=3.11"
 description = "Run Claude Code in a fix-break loop until your codebase is clean"
 readme = "README.md"

etch_loop-0.4.7/src/etch/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.4.7"

{etch_loop-0.4.6 → etch_loop-0.4.7}/src/etch/analyze.py

@@ -179,9 +179,9 @@ For each issue, include the file path, line number (if known), and a one-line de
 5. List each confirmed issue on its own line, e.g.:
    - src/auth.py:42 — crashes with empty token string (no guard)
    - src/api.js:108 — unhandled promise rejection will silently fail
-6. Before the signal token, write this line — it appears directly in the terminal:
-   `ETCH_SUMMARY: <one sentence, max 80 chars, e.g. "3 bugs found — null deref in auth.py:42, off-by-one in parser.py:88">`
-   `ETCH_SUMMARY: no confirmed bugs found`
+6. Before the signal token, write your summary in this exact format — it appears directly in the terminal:
+   `<etch_summary>3 bugs found — null deref in auth.py:42, off-by-one in parser.py:88</etch_summary>`
+   `<etch_summary>no confirmed bugs found</etch_summary>`
 7. End with EXACTLY one of these on its own line:
    `ETCH_ISSUES_FOUND`
    `ETCH_ALL_CLEAR`
@@ -222,12 +222,9 @@ Scan the codebase for:
 
 ## Terminal output (required)
 
-After making changes (or deciding there is nothing to fix), write this line — it appears directly in the terminal and is used as the commit message:
-  `ETCH_SUMMARY: <one sentence, max 80 chars>`
-
-Examples:
-  `ETCH_SUMMARY: fixed 3 issues — null guard in auth.py, bounds check in parser.py, timeout in agent.py`
-  `ETCH_SUMMARY: nothing to fix — all reported issues were already handled`
+After making changes (or deciding there is nothing to fix), write your summary in this exact format — it appears in the terminal and is used as the commit message:
+  `<etch_summary>fixed 3 issues — null guard in auth.py, bounds check in parser.py, timeout in agent.py</etch_summary>`
+  `<etch_summary>nothing to fix — all reported issues were already handled</etch_summary>`
 """
 
 
@@ -256,9 +253,9 @@ Be adversarial — think like someone actively trying to make this code fail.
 
 1. DO NOT edit any files — read only
 2. Report your findings clearly, one per line
-3. Before the signal token, write this line — it appears directly in the terminal:
-   `ETCH_SUMMARY: <one sentence, max 80 chars, e.g. "2 issues — unguarded empty list in sorter.py:14, exception swallowed in loader.py:67">`
-   `ETCH_SUMMARY: no issues found — code looks solid`
+3. Before the signal token, write your summary in this exact format — it appears directly in the terminal:
+   `<etch_summary>2 issues — unguarded empty list in sorter.py:14, exception swallowed in loader.py:67</etch_summary>`
+   `<etch_summary>no issues found — code looks solid</etch_summary>`
 4. End with EXACTLY one of these on its own line:
    `ETCH_ISSUES_FOUND`
    `ETCH_ALL_CLEAR`
@@ -302,11 +299,9 @@ You are a test engineer. The fixer has just made changes. Your job is to write t
 1. You MAY edit test files — that is your job
 2. Do NOT touch production code — only tests
 3. If tests fail because of flawed test logic, fix the test and re-run before reporting
-4. When done, write this line — it appears directly in the terminal:
-   `ETCH_SUMMARY: <one sentence, max 80 chars>`
-   Examples:
-   `ETCH_SUMMARY: wrote 4 tests, all 51 passed`
-   `ETCH_SUMMARY: 2 tests failed — TypeError in test_auth.py:38, production bug in token.py:12`
+4. When done, write your summary in this exact format — it appears directly in the terminal:
+   `<etch_summary>wrote 4 tests, all 51 passed</etch_summary>`
+   `<etch_summary>2 tests failed — TypeError in test_auth.py:38, production bug in token.py:12</etch_summary>`
 5. End with EXACTLY one of these on its own line:
    `ETCH_ALL_CLEAR` — if all tests pass
    `ETCH_ISSUES_FOUND` — if tests reveal a bug in production code

{etch_loop-0.4.6 → etch_loop-0.4.7}/src/etch/signals.py

@@ -1,5 +1,7 @@
 """Signal parsing for breaker agent output."""
 
+import re
+
 _TOKEN_CLEAR = "ETCH_ALL_CLEAR"
 _TOKEN_ISSUES = "ETCH_ISSUES_FOUND"
 _PUNCTUATION_ONLY = set("-=*_`~><|")
@@ -78,19 +80,18 @@ def extract_commit_message(output: str, fallback: str) -> str:
 
 
 def extract_summary(output: str) -> str:
-    """Extract the ETCH_SUMMARY line written by an agent.
+    """Extract the summary from an <etch_summary> tag in agent output.
 
-    Agents are prompted to write a line like:
-        ETCH_SUMMARY: fixed 3 null-guard issues in auth.py
+    Agents are prompted to write:
+        <etch_summary>fixed 3 null-guard issues in auth.py</etch_summary>
 
     Returns the summary text, or empty string if not found.
     """
     if not isinstance(output, str):
         return ""
-    for line in output.splitlines():
-        stripped = line.strip()
-        if stripped.startswith("ETCH_SUMMARY:"):
-            return stripped[len("ETCH_SUMMARY:"):].strip()
+    m = re.search(r"<etch_summary>(.*?)</etch_summary>", output, re.DOTALL)
+    if m:
+        return m.group(1).strip()
     return ""
 
 

{etch_loop-0.4.6 → etch_loop-0.4.7}/src/etch/templates/BREAK.md

@@ -19,11 +19,9 @@ Be adversarial — think like someone actively trying to make this code fail.
 
 1. DO NOT edit any files — read only
 2. Report your findings clearly, one per line
-3. Before the signal token, write this line — it appears directly in the terminal:
-   `ETCH_SUMMARY: <one sentence, max 80 chars>`
-   Examples:
-   `ETCH_SUMMARY: 2 issues — unguarded empty list in sorter.py:14, exception swallowed in loader.py:67`
-   `ETCH_SUMMARY: no issues found — code looks solid`
+3. Before the signal token, write your summary in this exact format — it appears directly in the terminal:
+   `<etch_summary>2 issues — unguarded empty list in sorter.py:14, exception swallowed in loader.py:67</etch_summary>`
+   `<etch_summary>no issues found — code looks solid</etch_summary>`
 4. End with EXACTLY one of these on its own line:
    `ETCH_ISSUES_FOUND`
    `ETCH_ALL_CLEAR`

{etch_loop-0.4.6 → etch_loop-0.4.7}/src/etch/templates/ETCH.md

@@ -24,9 +24,6 @@ Focus on: [edit this to narrow your scope, e.g. "src/auth/", "the payment module
 
 ## Terminal output (required)
 
-After making changes (or deciding there is nothing to fix), write this line — it appears directly in the terminal and is used as the commit message:
-  `ETCH_SUMMARY: <one sentence, max 80 chars>`
-
-Examples:
-  `ETCH_SUMMARY: fixed 3 issues — null guard in auth.py, bounds check in parser.py, timeout in agent.py`
-  `ETCH_SUMMARY: nothing to fix — all reported issues were already handled`
+After making changes (or deciding there is nothing to fix), write your summary in this exact format — it appears in the terminal and is used as the commit message:
+  `<etch_summary>fixed 3 issues — null guard in auth.py, bounds check in parser.py, timeout in agent.py</etch_summary>`
+  `<etch_summary>nothing to fix — all reported issues were already handled</etch_summary>`

{etch_loop-0.4.6 → etch_loop-0.4.7}/src/etch/templates/RUN.md

@@ -20,13 +20,10 @@ You are a test engineer. The fixer has just made changes. Your job is to write t
 
 1. You MAY edit test files — that is your job
 2. Do NOT touch production code — only tests
-3. After running, report clearly:
-   - If ALL tests pass:
-     - `ETCH_SUMMARY: <e.g. "wrote 4 tests, all 51 passed">`
-     - `ETCH_ALL_CLEAR`
-   - If ANY test fails due to a bug in the production code:
-     - `ETCH_SUMMARY: <what failed and why>`
-     - Include the relevant error output
-     - `ETCH_ISSUES_FOUND`
-   - If tests fail because the tests themselves are wrong (flawed test logic):
-     - Fix the test and re-run before reporting
+3. If tests fail because of flawed test logic, fix the test and re-run before reporting
+4. When done, write your summary in this exact format — it appears directly in the terminal:
+   `<etch_summary>wrote 4 tests, all 51 passed</etch_summary>`
+   `<etch_summary>2 tests failed — TypeError in test_auth.py:38, production bug in token.py:12</etch_summary>`
+5. End with EXACTLY one of these on its own line:
+   `ETCH_ALL_CLEAR` — if all tests pass
+   `ETCH_ISSUES_FOUND` — if tests reveal a bug in production code

{etch_loop-0.4.6 → etch_loop-0.4.7}/src/etch/templates/SCAN.md

@@ -23,11 +23,9 @@ For each issue, include the file path, line number (if known), and a one-line de
 5. List each confirmed issue on its own line, e.g.:
    - src/auth.py:42 — crashes with empty token string (no guard)
    - src/api.js:108 — unhandled promise rejection will silently fail
-6. Before the signal token, write this line — it appears directly in the terminal:
-   `ETCH_SUMMARY: <one sentence, max 80 chars>`
-   Examples:
-   `ETCH_SUMMARY: 3 bugs found — null deref in auth.py:42, off-by-one in parser.py:88, missing guard in git.py:31`
-   `ETCH_SUMMARY: no confirmed bugs found`
+6. Before the signal token, write your summary in this exact format — it appears directly in the terminal:
+   `<etch_summary>3 bugs found — null deref in auth.py:42, off-by-one in parser.py:88</etch_summary>`
+   `<etch_summary>no confirmed bugs found</etch_summary>`
 7. End with EXACTLY one of these on its own line:
    `ETCH_ISSUES_FOUND`
    `ETCH_ALL_CLEAR`

etch_loop-0.4.6/src/etch/__init__.py

@@ -1 +0,0 @@
-__version__ = "0.4.6"