fix(extractors): נטרול כלים בקריאות text→JSON — מניעת error_max_turns שמבזבז כסף #182

chaim · 2026-06-11T11:50:28Z

chaim commented

2026-06-11 11:50:28 +00:00

מה ולמה

9 המחלצים שמריצים claude_session.query_json לחילוץ/שיפוט/סיווג העבירו את ברירת-המחדל של ה-CLI (כל הכלים פעילים). המודל פלט מדי פעם stop_reason:"tool_use", מה שמפיל את --max-turns 1 ל-error_max_turns ומאלץ retry — ~$0.12-0.16 לניסיון, × 3.

נצפה ב-drain של חילוץ-ההלכות (legal-halacha-drain): 15 כשלי error_max_turns ב-error.log, כל אחד num_turns:2 / stop_reason:"tool_use" — בזבוז כסף נטו על קריאות שמעולם לא צריכות כלי.

התשתית לתיקון כבר קיימת: claude_session.query מקבל tools="" לנטרול כל הכלים, ושני מחלצים (digest_metadata_extractor, bulletin_splitter) כבר משתמשים בו (עבודת היומונים). כאן רק מיישרים את שאר המחלצים לאותו מסלול קנוני.

מתוקנים (11 קריאות, 9 קבצים): halacha_extractor (×3: extract/NLI/consolidate), corroboration, claims_extractor, argument_aggregator, appraiser_facts_extractor, learning_loop, qa_validator, brainstorm, style_metadata_extractor.

הערה: block_writer ו-style_analyzer משתמשים ב-query() ליצירת-טקסט (לא JSON) ונשארו מחוץ לתיקון הזה — אותו סיכון תיאורטי קיים, ניתן להרחיב בנפרד אם רוצים.

Invariants — הצהרה (חובה)

נוגע / מקיים: INV-G2 (מקור-אמת יחיד / סימטריה) — לא מסלול מקביל חדש אלא שימוש עקבי בפרמטר tools הקיים ב-claude_session.query, כך שמחלצים-אחים מתנהגים זהה. אין בליעה שקטה (כלל-הנדסה §6) — נתיבי הכשל/retry/fail-open נשמרים כפי שהיו. ללא שינוי-ספ.

צ'קליסט — פרוטוקול כתיבת-קוד

קראתי את docs/spec/00-constitution.md לפני הכתיבה
השינוי לא יוצר מסלול מקביל ליכולת קיימת (G2) ולא מתקן תסמין בקריאה (G1)
לא הוספתי מגע-Paperclip מחוץ ל-Platform Port (G12) — mcp-server/src נקי
אין בליעה שקטה של שגיאות — נתיבי הכשל נשמרים
בדקתי מול docs/spec/gap-audit.md — לא נוגע ב-GAP/FU ממופה
בדיקות עוברות
לא data-migration

אימות

py_compile נקי על כל 9 הקבצים.
pytest tests/test_halacha_coerce.py tests/test_halacha_quality.py → 60/60 עוברות (כולל test_nli_check_* שמדמה את query_json — המעבר של tools="" לא שובר את החתימה).
grep 'tools=""' מאשר נוכחות ב-11 הקריאות.

🤖 Generated with Claude Code

## מה ולמה 9 המחלצים שמריצים `claude_session.query_json` לחילוץ/שיפוט/סיווג העבירו את ברירת-המחדל של ה-CLI (כל הכלים פעילים). המודל פלט מדי פעם `stop_reason:"tool_use"`, מה שמפיל את `--max-turns 1` ל-**`error_max_turns`** ומאלץ retry — **~$0.12-0.16 לניסיון, × 3**. נצפה ב-drain של חילוץ-ההלכות (`legal-halacha-drain`): **15 כשלי `error_max_turns`** ב-`error.log`, כל אחד `num_turns:2` / `stop_reason:"tool_use"` — בזבוז כסף נטו על קריאות שמעולם לא צריכות כלי. התשתית לתיקון **כבר קיימת**: `claude_session.query` מקבל `tools=""` לנטרול כל הכלים, ושני מחלצים (`digest_metadata_extractor`, `bulletin_splitter`) כבר משתמשים בו (עבודת היומונים). כאן רק מיישרים את שאר המחלצים לאותו מסלול קנוני. **מתוקנים (11 קריאות, 9 קבצים):** `halacha_extractor` (×3: extract/NLI/consolidate), `corroboration`, `claims_extractor`, `argument_aggregator`, `appraiser_facts_extractor`, `learning_loop`, `qa_validator`, `brainstorm`, `style_metadata_extractor`. > הערה: `block_writer` ו-`style_analyzer` משתמשים ב-`query()` ליצירת-טקסט (לא JSON) ונשארו מחוץ לתיקון הזה — אותו סיכון תיאורטי קיים, ניתן להרחיב בנפרד אם רוצים. ## Invariants — הצהרה (חובה) - **נוגע / מקיים:** **INV-G2** (מקור-אמת יחיד / סימטריה) — לא מסלול מקביל חדש אלא שימוש עקבי בפרמטר `tools` הקיים ב-`claude_session.query`, כך שמחלצים-אחים מתנהגים זהה. **אין בליעה שקטה** (כלל-הנדסה §6) — נתיבי הכשל/retry/fail-open נשמרים כפי שהיו. ללא שינוי-ספ. ## צ'קליסט — פרוטוקול כתיבת-קוד - [x] קראתי את `docs/spec/00-constitution.md` לפני הכתיבה - [x] השינוי **לא** יוצר מסלול מקביל ליכולת קיימת (G2) ולא מתקן תסמין בקריאה (G1) - [x] **לא** הוספתי מגע-Paperclip מחוץ ל-Platform Port (G12) — `mcp-server/src` נקי - [x] אין בליעה שקטה של שגיאות — נתיבי הכשל נשמרים - [x] בדקתי מול `docs/spec/gap-audit.md` — לא נוגע ב-GAP/FU ממופה - [x] בדיקות עוברות - [x] לא data-migration ## אימות - `py_compile` נקי על כל 9 הקבצים. - `pytest tests/test_halacha_coerce.py tests/test_halacha_quality.py` → **60/60 עוברות** (כולל `test_nli_check_*` שמדמה את `query_json` — המעבר של `tools=""` לא שובר את החתימה). - `grep 'tools=""'` מאשר נוכחות ב-11 הקריאות. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

chaim added 1 commit 2026-06-11 11:50:28 +00:00

fix(extractors): disable tools on text→JSON claude_session calls (no error_max_turns)

G12 Leak-Guard / leak-guard (pull_request) Successful in 5s

Details

d05c1e3fce

כל קריאות text→JSON ב-9 המחלצים העבירו את ברירת-המחדל של ה-CLI (כל הכלים
פעילים). המודל פלט מדי פעם stop_reason:"tool_use", מה שמפיל את --max-turns 1
ל-error_max_turns ומאלץ retry — ~$0.12-0.16 לניסיון, × 3. נצפה ב-drain
חילוץ-ההלכות (legal-halacha-drain, ‎15 כשלי error_max_turns ב-error.log).

התשתית כבר קיימת: claude_session.query מקבל tools=""‎ לנטרול כל הכלים, ושני
מחלצים (digest_metadata_extractor, bulletin_splitter) כבר משתמשים בו. כאן רק
מיישרים את שאר המחלצים לאותו מסלול קנוני — אף קריאת חילוץ/שיפוט/סיווג טהורה
לא צריכה כלי.

מתוקנים (11 קריאות, 9 קבצים): halacha_extractor (×3: extract/NLI/consolidate),
corroboration, claims_extractor, argument_aggregator, appraiser_facts_extractor,
learning_loop, qa_validator, brainstorm, style_metadata_extractor.

Invariants: מקיים INV-G2 (מסלול קנוני יחיד; סימטריה בין מחלצים-אחים) — לא מסלול
מקביל חדש אלא שימוש עקבי בפרמטר הקיים. אין בליעה שקטה (§6) — נתיבי הכשל/retry
נשמרים. ללא שינוי-ספ.

בדיקות: 60/60 ב-tests/test_halacha_coerce.py + test_halacha_quality.py עוברות;
py_compile נקי על כל 9 הקבצים.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

chaim merged commit 33663b9816 into main

2026-06-11 11:53:46 +00:00

chaim referenced this issue from a commit

2026-06-11 11:53:46 +00:00

Merge pull request 'fix(extractors): נטרול כלים בקריאות text→JSON — מניעת error_max_turns שמבזבז כסף' (#182) from worktree-halacha-tools-disable into main

chaim deleted branch worktree-halacha-tools-disable

2026-06-11 11:53:46 +00:00

chaim referenced this pull request

2026-06-11 12:03:54 +00:00

fix(writer): נטרול כלים ב-block_writer + style_analyzer — השלמת #182 #183

chaim referenced this issue from a commit

2026-06-11 12:05:53 +00:00