From ee83b6b345c5261ef983d2dd919bdb80765f7c14 Mon Sep 17 00:00:00 2001 From: Chaim Date: Mon, 13 Apr 2026 12:42:00 +0000 Subject: [PATCH 1/2] untracked files on main: 3541238 Update CLAUDE.md: add corpus-analysis.md to reference table --- .claude/commands/attach-precedents.md | 21 ++ .claude/commands/review-analysis.md | 34 ++ .claude/commands/writer-readiness.md | 36 ++ .claude/scheduled_tasks.lock | 1 + .claude/settings.json | 10 + .claude/skills/attach-precedents/SKILL.md | 80 +++++ .claude/skills/review-analysis/SKILL.md | 84 +++++ .claude/skills/writer-readiness/SKILL.md | 89 +++++ docs/decision-methodology.md | 409 ++++++++++++++++++++++ docs/practice-area-separation.md | 214 +++++++++++ 10 files changed, 978 insertions(+) create mode 100644 .claude/commands/attach-precedents.md create mode 100644 .claude/commands/review-analysis.md create mode 100644 .claude/commands/writer-readiness.md create mode 100644 .claude/scheduled_tasks.lock create mode 100644 .claude/settings.json create mode 100644 .claude/skills/attach-precedents/SKILL.md create mode 100644 .claude/skills/review-analysis/SKILL.md create mode 100644 .claude/skills/writer-readiness/SKILL.md create mode 100644 docs/decision-methodology.md create mode 100644 docs/practice-area-separation.md diff --git a/.claude/commands/attach-precedents.md b/.claude/commands/attach-precedents.md new file mode 100644 index 0000000..386a643 --- /dev/null +++ b/.claude/commands/attach-precedents.md @@ -0,0 +1,21 @@ +תהליך מונחה לצירוף תקדימים לתיק ערר. + +שאל את המשתמש על מספר התיק (או קבל כארגומנט: $ARGUMENTS). + +## תהליך + +1. **קרא ניתוח** — `get_full_analysis` — קבל רשימת סוגיות וטענות סף +2. **קרא תקדימים קיימים** — `precedent_list` — מה כבר צורף? +3. **לכל סוגיה/טענת סף שאין לה תקדימים:** + a. חפש תקדימים רלוונטיים ב-`search_decisions` עם query מותאם לסוגיה + b. חפש גם ב-`precedent_search_library` (תקדימים מתיקים אחרים) + c. הצג למשתמש 3-5 תוצאות עם ציטוט + הפניה + d. **שאל שאלה אחת בכל פעם** — "האם לצרף את התקדים הזה לסוגיה X?" + e. אם כן — `precedent_attach` עם section_id מתאים (למשל issue_1, threshold_2) + f. אם לא — עבור לתוצאה הבאה +4. **אפשר למשתמש להדביק ציטוט ידני** — "יש לך ציטוט משלך לסוגיה הזו?" + +## כללים +- שאלה אחת בכל פעם, לא רשימה ארוכה +- הצג את הציטוט הרלוונטי, לא רק את שם ההחלטה +- ציין בפירוש לאיזו סוגיה (section_id) כל תקדים יצורף diff --git a/.claude/commands/review-analysis.md b/.claude/commands/review-analysis.md new file mode 100644 index 0000000..40dcd2c --- /dev/null +++ b/.claude/commands/review-analysis.md @@ -0,0 +1,34 @@ +סקירת ניתוח משפטי לפני מילוי עמדות יו"ר. + +שאל את המשתמש על מספר התיק (או קבל כארגומנט: $ARGUMENTS). + +## תהליך + +1. **קרא ניתוח מלא** — `get_full_analysis` +2. **הצג סיכום מובנה:** + +לכל סוגיה/טענת סף: +- **כותרת** ומספר +- **טענה** (תמצית) +- **תשובה** (תמצית) +- **תגובה** (אם קיימת) +- **ניתוח אסטרטגי**: חוזקות | חולשות | הזדמנויות +- **שאלות מחקר** (2 שאלות) +- **חקיקה רלוונטית** +- **תקדימים מקורפוס** (אם נמצאו) +- **עמדת יו"ר**: [מולאה / ריקה] + +3. **זהה פערים:** + - סוגיות ללא ניתוח אסטרטגי + - סוגיות ללא שאלות מחקר + - סוגיות ללא חקיקה רלוונטית + - סוגיות ללא תקדימים + +4. **שאל** את המשתמש: + - "האם הסוגיות מכסות את כל הנושאים? חסר משהו?" + - "יש צורך להריץ ניתוח מחדש על סוגיה מסוימת?" + +## כללים +- הצג סוגיה אחת בכל פעם אם יש יותר מ-3 +- השתמש בטבלאות box-drawing עם כותרות באנגלית +- ציין בבירור אילו שדות ריקים diff --git a/.claude/commands/writer-readiness.md b/.claude/commands/writer-readiness.md new file mode 100644 index 0000000..afee93e --- /dev/null +++ b/.claude/commands/writer-readiness.md @@ -0,0 +1,36 @@ +בדיקת מוכנות תיק לפני הפעלת כותב ההחלטה. + +שאל את המשתמש על מספר התיק (או קבל כארגומנט: $ARGUMENTS), ואז בצע את הבדיקות הבאות: + +## בדיקות + +1. **סטטוס תיק** — `case_get` — ודא שהתיק קיים ויש בו מסמכים +2. **טענות מחולצות** — `get_claims` — ודא שיש claims חולצו +3. **ניתוח משפטי** — `get_full_analysis` — בדוק: + - האם הקובץ קיים (status != missing)? + - כמה סוגיות/טענות סף זוהו? + - כמה עמדות יו"ר מולאו (filled_count vs total_items)? + - האם יש שאלות מחקר (legal_questions) לכל סוגיה? +4. **ממצאי מחקר** — `get_research_findings` — האם חוקר התקדימים רץ? +5. **תקדימים מצורפים** — `precedent_list` — כמה צורפו? לאילו סוגיות? +6. **סטטוס workflow** — `workflow_status` — האם כל שלבי הקדם הושלמו? + +## פלט + +הצג טבלת סיכום: + +``` ++-----------------------------+----------+-------------------+ +| Check | Status | Details | ++-----------------------------+----------+-------------------+ +| Claims extracted | OK / FAIL| X claims, Y resp | +| Analysis exists | OK / FAIL| N issues found | +| Chair positions filled | OK / WARN| 3/5 filled | +| Research findings | OK / MISS| precedents found | +| Attached precedents | OK / MISS| N total, per issue| +| Workflow status | OK / WARN| current status | ++-----------------------------+----------+-------------------+ +``` + +אם יש בעיות — הצג המלצות ספציפיות מה צריך לעשות לפני הפעלת הכותב. +אם הכל תקין — אמור "התיק מוכן לכתיבה." diff --git a/.claude/scheduled_tasks.lock b/.claude/scheduled_tasks.lock new file mode 100644 index 0000000..ba76471 --- /dev/null +++ b/.claude/scheduled_tasks.lock @@ -0,0 +1 @@ +{"sessionId":"524a16d2-75eb-4bf9-a75c-2f467e9cb424","pid":11558,"acquiredAt":1775905522780} \ No newline at end of file diff --git a/.claude/settings.json b/.claude/settings.json new file mode 100644 index 0000000..9f258f7 --- /dev/null +++ b/.claude/settings.json @@ -0,0 +1,10 @@ +{ + "permissions": { + "allow": [ + "Bash(mkdir -p /home/chaim/legal-ai/.claude/skills/writer-readiness)", + "Bash(mkdir -p /home/chaim/legal-ai/.claude/skills/attach-precedents)", + "Bash(mkdir -p /home/chaim/legal-ai/.claude/skills/review-analysis)", + "Read(//home/chaim/**)" + ] + } +} diff --git a/.claude/skills/attach-precedents/SKILL.md b/.claude/skills/attach-precedents/SKILL.md new file mode 100644 index 0000000..467b197 --- /dev/null +++ b/.claude/skills/attach-precedents/SKILL.md @@ -0,0 +1,80 @@ +--- +name: attach-precedents +description: > + תהליך מונחה לצירוף תקדימים (פסיקה) לתיק ערר. + מציג סוגיות מהניתוח, מחפש תקדימים רלוונטיים בקורפוס, + ומאפשר למשתמש לאשר/לערוך/לדחות כל תקדים. + + טריגרים: "צרף תקדימים", "צירוף פסיקה", "attach precedents", + "הוסף פסיקה", "תקדימים לתיק", "חפש פסיקה", + "צרף ציטוט", "precedent attach" +--- + +# צירוף תקדימים לתיק ערר + +סקיל זה מנחה את המשתמש בצירוף תקדימים (ציטוטי פסיקה) לסוגיות ספציפיות בתיק. + +## הוראות + +### שלב 1: התמצאות +``` +get_full_analysis(case_number) +precedent_list(case_number) +``` +קרא את רשימת הסוגיות וטענות הסף, ואת התקדימים שכבר צורפו. + +### שלב 2: זיהוי פערים +לכל סוגיה/טענת סף — בדוק אם יש תקדים מצורף עם `section_id` תואם. +הצג סיכום: +``` +סוגיה 1: תוקפה של החלטת הוועדה — 2 תקדימים +סוגיה 2: סטיה ניכרת — 0 תקדימים <-- חסר +סוגיה 3: חניה — 1 תקדים +טענת סף 1: שיהוי — 0 תקדימים <-- חסר +``` + +### שלב 3: חיפוש וצירוף — סוגיה אחת בכל פעם + +לכל סוגיה שחסרים לה תקדימים: + +1. **חפש בקורפוס:** +``` +search_decisions(query="[שאלה משפטית מהסוגיה]", limit=5) +precedent_search_library(query="[מונח מפתח]", limit=5) +``` + +2. **הצג תוצאות למשתמש:** +``` +[1] עע"מ 8909/13 הרמלין — score: 0.89 + ציטוט: "דחיית תכניות נקודתיות בהעדר תכנון כולל מהווה..." + +[2] ערר 198-09 פן — score: 0.82 + ציטוט: "הוועדה המחוזית רשאית להורות על הכנת תכנית..." +``` + +3. **שאל שאלה אחת:** + "לצרף את תקדים #1 לסוגיה X? (כן / לא / עריכה / ציטוט אחר)" + +4. **אם כן:** +``` +precedent_attach(case_number, quote="...", citation="עע\"מ 8909/13 הרמלין", section_id="issue_1") +``` + +5. **אם עריכה:** תן למשתמש לערוך את הציטוט לפני צירוף. + +6. **אם ציטוט אחר:** תן למשתמש להדביק ציטוט משלו. + +### שלב 4: סיכום +הצג מה צורף: +``` +צורפו 4 תקדימים: +- סוגיה 1: עע"מ 8909/13 + ערר 198-09 +- סוגיה 2: עע"מ 2345/15 +- טענת סף 1: עע"מ 1234/18 +``` + +## כללים +- **שאלה אחת בכל פעם** — לא רשימה ארוכה +- **הצג ציטוט, לא רק שם** — המשתמש צריך לראות את הטקסט +- **section_id חובה** — כל תקדים חייב להיות מקושר לסוגיה +- **אל תצרף בלי אישור** — תמיד שאל קודם diff --git a/.claude/skills/review-analysis/SKILL.md b/.claude/skills/review-analysis/SKILL.md new file mode 100644 index 0000000..7749648 --- /dev/null +++ b/.claude/skills/review-analysis/SKILL.md @@ -0,0 +1,84 @@ +--- +name: review-analysis +description: > + סקירת ניתוח משפטי לפני מילוי עמדות יו"ר. + מציג כל סוגיה בפורמט נקי, מדגיש פערים, + ומאפשר לבקש ניתוח מחדש על סוגיות ספציפיות. + + טריגרים: "סקור ניתוח", "בדוק ניתוח", "review analysis", + "הצג ניתוח", "סיכום ניתוח", "מה מצב הניתוח", + "ניתוח מוכן", "analysis review", "analysis summary" +--- + +# סקירת ניתוח משפטי + +סקיל זה מציג את הניתוח המשפטי בפורמט נקי וקריא, מדגיש פערים, ומאפשר למשתמש לוודא שהניתוח שלם לפני מילוי עמדות. + +## הוראות + +### שלב 1: קריאת ניתוח +``` +get_full_analysis(case_number) +``` + +### שלב 2: הצגה מובנית + +לכל סוגיה/טענת סף, הצג: + +``` +═��═══════════════════════════════════════��� +סוגיה 1: תוקפה ומחייבותה של החלטת הוועדה המחוזית +══════════════════════════════════════════ + +Claim: הוועדה המקומית הפרה את החלטת הוועדה המחוזית מ-2017... +Response: החלטת 2017 לא דחתה את התכנית על הסף... +Reply: תכניות 2024-2025 אינן תחליף לתכנית אב... + ++------------------+--------+ +| Field | Status | ++------------------+--------+ +| Strengths | OK | +| Weaknesses | OK | +| Opportunities | OK | +| Legal questions | OK | +| Legislation | OK | +| Precedents | MISS | +| Chair position | EMPTY | ++------------------+--------+ + +שאלות מחקר: +1. האם החלטה של ועדת משנה מחוזית... (עקרונית) +2. מהם המבחנים לאישור... (יישומית) + +חקיקה: סעיף 62א לחוק התכנון והבניה +══════════════════════════════════════���═══ +``` + +### שלב 3: סיכום פערים + +הצג טבלת סיכום כוללת: + +``` ++---------------+-------+------+------+------+------+------+-------+ +| Issue | Claim | Resp | Str | Weak | Ques | Legis| Chair | ++---------------+-------+------+------+------+------+------+-------+ +| Threshold 1 | OK | OK | OK | OK | OK | OK | EMPTY | +| Issue 1 | OK | OK | OK | OK | OK | OK | EMPTY | +| Issue 2 | OK | OK | MISS | OK | OK | MISS | EMPTY | ++---------------+-------+------+------+------+------+------+-------+ +``` + +### שלב 4: שאלות למשתמש + +אם יש פערים, שאל: +- "סוגיה 2 חסרה ניתוח חוזקות וחקיקה. להריץ ניתוח מחדש?" + +אם אין פערים: +- "הניתוח שלם. אפשר להיכנס ל-UI ולמלא עמדות." +- הצג קישור: `https://legal-ai.nautilus.marcusgroup.org/#/case/{case_number}` + +## כללים +- הצג סוגיה אחת בכל פעם אם יש יותר מ-3 +- השתמש בטבלאות box-drawing עם כותרות באנגלית (לשמור RTL) +- ציין בבירור אילו שדות ריקים +- אל תמלא עמדות בעצמך — רק דפנה ממלאת diff --git a/.claude/skills/writer-readiness/SKILL.md b/.claude/skills/writer-readiness/SKILL.md new file mode 100644 index 0000000..c568de0 --- /dev/null +++ b/.claude/skills/writer-readiness/SKILL.md @@ -0,0 +1,89 @@ +--- +name: writer-readiness +description: > + בדיקת מוכנות תיק ערר לפני הפעלת כותב ההחלטה. + בודק: עמדות יו"ר מולאו, תקדימים צורפו, ניתוח קיים, מחקר הושלם. + מציג טבלת סיכום עם פערים והמלצות. + + טריגרים: "בדוק מוכנות", "מוכן לכתיבה", "writer readiness", + "אפשר להפעיל כותב", "בדיקת מוכנות", "לפני כתיבה", + "check readiness", "pre-write check" +--- + +# בדיקת מוכנות לכתיבת החלטה + +סקיל זה בודק שכל הדרישות המוקדמות מולאו לפני הפעלת כותב ההחלטה. + +## הוראות + +קבל מספר תיק מהמשתמש, ואז הרץ 6 בדיקות: + +### 1. סטטוס תיק +``` +case_get(case_number) +``` +ודא שהתיק קיים, יש בו מסמכים, וסטטוס workflow מתאים. + +### 2. טענות מחולצות +``` +get_claims(case_number) +``` +ודא שיש claims חולצו. ספור: כמה claims, responses, replies. + +### 3. ניתוח משפטי +``` +get_full_analysis(case_number) +``` +בדוק: +- האם הקובץ קיים (status != missing)? +- כמה סוגיות/טענות סף זוהו? +- כמה עמדות יו"ר מולאו (filled_count vs total_items)? +- לכל סוגיה: יש שאלות מחקר? יש חקיקה? יש ניתוח אסטרטגי? + +### 4. ממצאי מחקר +``` +get_research_findings(case_number) +``` +האם חוקר התקדימים שמר ממצאים מובנים? (research-findings.md) + +### 5. תקדימים מצורפים +``` +precedent_list(case_number) +``` +כמה תקדימים צורפו? לאילו סוגיות (section_id)? אילו סוגיות בלי תקדימים? + +### 6. סטטוס workflow +``` +workflow_status(case_number) +``` +האם כל שלבי הקדם הושלמו? + +## פלט + +הצג טבלת סיכום: + +``` ++-----------------------------+--------+---------------------------+ +| Check | Status | Details | ++-----------------------------+--------+---------------------------+ +| Claims extracted | OK | 14 claims, 8 responses | +| Analysis exists | OK | 9 issues, 2 threshold | +| Chair positions filled | OK | 11/11 filled | +| Research findings | MISS | file not found | +| Attached precedents | WARN | 3 total, issue_4 missing | +| Workflow status | OK | direction_approved | ++-----------------------------+--------+---------------------------+ +``` + +- **OK** — מוכן +- **WARN** — חסר אבל לא חוסם (אפשר להמשיך עם הערה) +- **MISS** — חסר לגמרי +- **FAIL** — חוסם כתיבה + +### המלצות +אם יש בעיות: +- ציין מה בדיוק חסר +- הצע פעולה ספציפית (למשל "הפעל /attach-precedents" או "ממתין למילוי עמדות ב-UI") + +אם הכל תקין: +- "התיק מוכן לכתיבה." diff --git a/docs/decision-methodology.md b/docs/decision-methodology.md new file mode 100644 index 0000000..4813ef9 --- /dev/null +++ b/docs/decision-methodology.md @@ -0,0 +1,409 @@ +# מתודולוגיית כתיבת החלטות — מדריך אנליטי לוועדת ערר לתכנון ובניה + +מסמך זה מלמד כיצד לחשוב, לנתח ולבנות החלטה מנומקת. הוא אינו עוסק בסגנון הכתיבה של דפנה (ראה SKILL.md) ולא בנושאים שיש לכסות (ראה צ'קליסטים תוכניים). הוא עוסק בשיטה — כיצד להפוך חומרי מקור להנמקה משכנעת שתעמוד בביקורת שיפוטית. + +--- + +## א. שלב מקדים — הבנת התיק לפני שנכתבת מילה + +### א.1 קרא הכל, סכם, ואז חשוב + +לפני שנכתב משפט אחד — קרא את כל חומרי המקור: כתב הערר, תגובת הוועדה המקומית, תגובת מבקשי ההיתר (אם יש), פרוטוקול הדיון, חוות דעת מומחים, ומסמכי תכנון רלוונטיים (תכנית, נספחים, החלטות ועדה מקומית). + +**מה לעשות:** +- סמן את הטענות המרכזיות של כל צד. אל תסמוך על סיכום הצד — קרא את הנוסח המלא. +- זהה מהן העובדות שאינן שנויות במחלוקת ומהן העובדות השנויות במחלוקת. +- זהה את המסמכים הנורמטיביים הרלוונטיים (תכניות, חוקים, תקנות) וקרא אותם במלואם — לא רק את הסעיף הנטען. מילה בסעיף אחד מתפרשת לאור סעיפים אחרים באותו מסמך. + +### א.2 סווג את הערר + +סוג הערר קובע את מסגרת הניתוח: +- **ערר רישוי (1xxx)**: שאלת שיקול דעת תכנוני; הוועדה מפעילה שיקול דעת עצמאי. +- **ערר היטל השבחה (8xxx)**: שאלת שמאות ומשפט; ביקורת על שומה. +- **ערר פיצויים — סעיף 197 (9xxx)**: דומה להיטל השבחה. + +הסיווג משפיע על תקן הביקורת, על עומק הדיון התכנוני, ועל טון ההחלטה. + +### א.3 נסח את השאלות לדיון — במילותיך + +הוועדה אינה כבולה לניסוח של עורכי הדין. אם העוררים העלו שמונה טענות אבל באמת יש שתי שאלות מרכזיות — נסח שתי שאלות. ניסוח הסוגיות הוא אבן הפינה של ההחלטה: הוא קובע אילו עובדות מהותיות ואילו כללים חלים. + +**מה לעשות:** +- נסח כל שאלה כסילוגיזם מכווץ: הנחה משפטית, עובדות תמציתיות, שאלה חדה. לדוגמה: "תכנית X קובעת קו בניין של 3 מטרים. הבקשה כוללת בניה במרחק 1.5 מטרים מגבול המגרש. האם הבקשה תואמת את הוראות התכנית?" +- ניסוח הסוגיות נכתב בגרסה סופית רק אחרי שהדיון מגובש — כדי לוודא שהשאלות תואמות את התשובות. + +**מבוסס על:** FJC Judicial Writing Manual §§A5-A7; Garner, Making Your Case §36; Posner — ניסוח סוגיות כאבן פינה. + +--- + +## ב. ניתוח סף — מתי לבדוק, מתי לדלג + +### ב.1 שאלות סף תמיד קודמות + +אם עולה שאלת סמכות, מועד הגשה, או עמידה בתנאי מוקדם — היא נדונה ראשונה. הלוגיקה פשוטה: אם אין סמכות לדון, כל שאר הדיון מיותר. + +**מה לעשות:** +- אם שאלת הסף נדחית (כלומר, הוועדה מוסמכת / הערר הוגש בזמן) — ציין זאת בפסקה אחת ועבור לגוף הערר. +- אם שאלת הסף מתקבלת — ההחלטה מסתיימת בה. אין צורך לדון בגוף. +- אל תדון בשאלת סף שלא הועלתה על ידי אף צד ושאין לה בסיס בחומר. + +### ב.2 ציון תקן הביקורת + +בפתיחת חלק הדיון, ציין את תקן הביקורת של הוועדה: "הוועדה מפעילה שיקול דעת תכנוני עצמאי" (ברישוי) או "הוועדה בוחנת את תקינות השומה המכרעת" (בהיטל השבחה). בלי ציון תקן — הקורא לא יודע באיזה סטנדרט נבחנה ההחלטה, והנימוק נשאר עמום. + +**מבוסס על:** FJC §B6; Posner — legalism works when the rule is clear. + +--- + +## ג. סדר הסוגיות — מה קודם ולמה + +### ג.1 עקרון הסדר + +1. **שאלות סף** — תמיד ראשונות. +2. **הסוגיה המכריעה** — מיד אחריהן. הסוגיה שמכריעה את הערר באה לפני סוגיות משניות. +3. **סוגיות נוספות** — לפי חוזק ההנמקה. פתח בנימוק החזק ביותר. רושם ראשוני אי אפשר לבטל, ותשומת הלב של הקורא בשיאה בהתחלה. +4. **סוגיות שנויות אך לא נחוצות** — בסוף, או בכלל לא. + +### ג.2 מתי לא לדון בטענה + +ההחלטה צריכה לדון רק בסוגיות שיש לפתור כדי להכריע. אם העורר העלה שמונה טענות אבל שתיים מכריעות — הדיון מתמקד בשתיים. את השאר ניתן לטפל כך: +- טענה שהועלתה ברצינות אך אינה נחוצה: "טענה זו נבחנה על ידי הוועדה. נוכח מסקנתנו לעיל, אין צורך להכריע בה." +- טענות חלשות או חוזרות: ניתן לקבץ. "באשר לטענות הנוספות שהעלו העוררים — לא מצאנו בהן ממש." +- אל תתעלם לחלוטין מטענה מרכזית. הצד המפסיד חייב לראות שהוועדה שקלה את יסודות עמדתו. + +### ג.3 פסקת מפה + +בפתיחת הדיון, ספק מפת דרכים: "שלוש שאלות עומדות להכרעה: (1) האם הבקשה תואמת את הוראות התכנית לעניין קו הבניין; (2) האם ההקלה המבוקשת עומדת בתנאי סעיף 147; (3) מהו הסעד המתאים." הקורא יודע מראש מה לצפות, וההנמקה נתפסת כמאורגנת. + +**מבוסס על:** FJC §§B2-B5; Garner, MYC §§7, 12; LWPE §27; Posner — narrow holdings, focus on what matters. + +--- + +## ד. בניית הניתוח — הלב של ההחלטה + +### ד.1 מבנה סילוגיסטי לכל סוגיה + +כל סוגיה נבנית כסילוגיזם: + +1. **הנחה עליונה (הכלל)** — סעיף בתכנית, הוראת חוק, הלכה פסוקה, או עיקרון תכנוני. +2. **הנחה תחתונה (העובדות)** — העובדות הספציפיות של הערר שנבחנות לאור הכלל. +3. **מסקנה** — התוצאה שנובעת בהכרח מהחלת הכלל על העובדות. + +זהו השלד. כל הנמקה שאינה ניתנת לפירוק למבנה זה — חסרה חוליה. אם לא ניתן לזהות את הכלל — ההנמקה אינה מספקת. אם לא ניתן לזהות כיצד העובדות מקיימות את הכלל — ההנמקה קריפטית. + +### ד.2 התחל מלשון הטקסט + +כשהמקרה נשלט על ידי הוראת תכנית או סעיף חוק — פתח תמיד בציטוט ההוראה. לא בפסיקה, לא בעקרון כללי. המילים של הטקסט הן נקודת המוצא. + +**מה לעשות:** +- הבא את לשון ההוראה הרלוונטית (ציטוט ישיר, קצר ככל האפשר). +- פרש מילים במשמעותן הרגילה. +- בדוק עקביות עם הוראות אחרות באותה תכנית. +- תן תוקף לכל מילה — מילה "מיותרת" בטקסט נורמטיבי אינה מיותרת. +- אם יש עמימות — השתמש בכלי פרשנות: הכלל הכללי מצטמצם לאור הפרט; מילה מתפרשת לאור הקשרה; הכללת דבר אחד מרמזת על הדרת אחרים. + +### ד.3 שלושה מקורות להנחה העליונה + +בעררי תכנון, הכלל נשאב משלושה מקורות: +- **טקסט**: הוראות התכנית, חוק התכנון והבניה, תקנות. +- **תקדים**: פסיקת בתי משפט, החלטות ועדת ערר ארצית, החלטות ועדות ערר מחוזיות. +- **מדיניות**: שיקולים תכנוניים — צפיפות, אופי סביבה, אינטרס ציבורי, השפעות כלכליות. + +בחר את המקור החזק ביותר. אם יש הוראת תכנית ברורה — אין צורך בפסיקה כדי לתמוך בה. פסיקה נדרשת כשהטקסט עמום או כשצריך לקבוע כיצד ליישם עיקרון כללי. + +### ד.4 ההנחה התחתונה היא המפתח + +ברוב העררים, הכלל המשפטי אינו שנוי במחלוקת. השאלה היא כיצד העובדות משתלבות בכלל. זהו לב ההחלטה. ההנמקה חייבת להראות בפירוט — לא בהכרזה — כיצד העובדות הספציפיות מקיימות או אינן מקיימות את תנאי הכלל. + +**מה לעשות:** +- השתמש בנתונים: מספרים, מידות, אחוזים, תאריכים (כשרלוונטיים). "הבקשה חורגת ב-1.5 מטרים מקו הבניין" — לא "הבקשה חורגת באופן משמעותי." +- הפרד בין ממצא עובדתי למסקנה משפטית. "הבניה במרחק 1.5 מטרים מגבול המגרש" — ממצא עובדתי. "חריגה זו עולה כדי סטייה ניכרת" — מסקנה משפטית. אל תערבב. +- כל מעבר מכלל לעובדה למסקנה צריך להיות מפורש. לא לכתוב "העובדות מלמדות כי הערר אינו מוצדק" בלי לפרט למה. + +### ד.5 מבנה CREAC בפועל + +לכל סוגיה, השתמש במבנה הבא: + +1. **מסקנה** (Conclusion) — פתח בתשובה לשאלה. "הבקשה אינה תואמת את הוראות התכנית לעניין קו הבניין." +2. **כלל** (Rule) — הבא את הכלל. ציטוט הוראת התכנית או ההלכה. +3. **הרחבה** (Explanation) — אם הכלל דורש הבהרה, הבא תקדים רלוונטי אחד שמסביר כיצד הכלל יושם במקרה דומה. +4. **יישום** (Application) — החל את הכלל על עובדות המקרה. כאן נמצא לב ההנמקה. +5. **מסקנה חוזרת** (Conclusion) — סגור בתמצית. "לפיכך, הבקשה אינה עולה בקנה אחד עם הוראות התכנית." + +הפתיחה במסקנה חיונית: הקורא יודע לאן הדיון מוביל, וכל עובדה שנקראת אחר כך מובנת בהקשרה. עובדות ללא מסגרת — נתפסות כאקראיות וחסרות משמעות. + +**מבוסס על:** Garner, MYC §§22-27; FJC §§B1, B8; Posner — facts drive decisions; data over words; distinguish findings from conclusions. + +--- + +## ה. איזון ומידתיות — מתי ואיך + +### ה.1 מתי נדרש איזון + +איזון נדרש כשהדין לא נותן תשובה חד-משמעית. כשהכלל ברור והעובדות מתאימות לו — אין צורך באיזון. אל תאזן כשאפשר להכריע לפי כלל. איזון הוא כלי לשעה שהכללים אוזלים, לא תחליף לניתוח נורמטיבי. + +### ה.2 מבנה האיזון + +כשאיזון נדרש, בנה אותו כך: + +1. **זהה את האינטרסים** — מהם האינטרסים המתחרים. לא "אינטרס הציבור" מול "אינטרס העורר" באופן מעורפל, אלא אינטרסים קונקרטיים: "זכות הקניין של העורר לבנות על מגרשו" מול "שמירה על אופי מגורים צמודי קרקע בשכונה." +2. **בחן השלכות לכל כיוון** — מה קורה אם מקבלים? מה קורה אם דוחים? לא "מהו האינטרס החשוב יותר" אלא "מהן ההשלכות של כל תוצאה על כל אינטרס." +3. **שקול השלכות מערכתיות** — לא רק תוצאה לתיק זה, אלא גם האות שנשלח למערכת התכנון. קבלת הערר תיצור תקדים? תפתח פתח לבקשות דומות? +4. **הגע למסקנה** — ציין מפורשות מה מכריע את הכף ולמה. + +### ה.3 מידתיות כמבחן + +כשהוועדה מטילה מגבלה או תנאי — בדוק: (1) האם המגבלה משרתת תכלית ראויה; (2) האם יש אמצעי פוגע פחות; (3) האם הפגיעה מידתית ביחס לתועלת. שלושת השלבים צריכים להיות מפורשים בטקסט. + +**מבוסס על:** Posner — balance as methodology; systemic vs. case-specific consequences; pragmatist approach within legal norms. + +--- + +## ו. טיפול בטענות — כללים מעשיים + +### ו.1 אל תהפוך את הדיון לוויכוח + +ההחלטה מנתחת שאלה — לא מתווכחת עם עורכי דין. המבנה הנכון הוא: שאלה → כלל → עובדות → מסקנה. לא: "העורר טוען X — אין לקבל טענה זו — שכן Y." + +הדיון לא מתנהל כ"תשובה לכתב הערר" אלא כניתוח עצמאי שבוחן את השאלות שהתעוררו. הוועדה מגיעה למסקנותיה מכוח הנימוק — לא מכוח דחיית טענות. + +### ו.2 Steel-manning — הצג את הטענה הטובה ביותר של הצד המפסיד + +לפני שדוחים טענה — הצג אותה בגרסה החזקה ביותר שלה. לא קריקטורה של הטענה, אלא הטענה כפי שעורך דין מוכשר היה מנסח אותה. אז הסבר למה היא נדחית. + +**למה זה חשוב:** טענת קש קלה להפריך, אבל הקורא (ובמיוחד בית המשפט בביקורת שיפוטית) יזהה שלא התמודדת עם הטענה האמיתית. הצגה הוגנת של הטענה ודחייתה — משכנעת. הצגה מעוותת — מחשידה. + +**מה לעשות:** +- כשנדרשת התמודדות עם טענת העורר, כתוב: "אמנם צודק העורר כי [נקודה שפועלת לטובתו], אולם [הנימוק לדחייה]." +- אם יש נקודה שאי אפשר להגן עליה — הכר בה בגלוי. "נכון כי המבנה הסמוך חורג מקו הבניין. אולם עובדה זו אינה מקנה זכות לחריגה נוספת, שכן..." +- טענה חלשה שאין בה ממש — מספיק משפט אחד. אל תפזר זמן על טענות שאינן ראויות לדיון. + +### ו.3 מיקום ההתמודדות עם טענות נגדיות + +באמצע הדיון — לא בהתחלה ולא בסוף. המבנה המומלץ לכל סוגיה: +1. הנחה משפטית (הכלל) +2. יישום על העובדות +3. מסקנה ראשונית +4. **טענה נגדית + תשובה** +5. **טענה נגדית נוספת + תשובה** (אם יש) +6. נקודה תומכת נוספת +7. משפט סיכום + +פתיחה בטענות הצד השני מציבה את ההחלטה בעמדת הגנה. סיום בהן משאיר את המוקד על הצד המפסיד. האמצע הוא המקום הנכון. + +### ו.4 קיבוץ טענות + +כשיש טענות רבות שמכוונות לאותה נקודה — קבץ אותן. "העוררים העלו מספר טענות הנוגעות לאופן חישוב השטחים. לאחר בחינתן, לא מצאנו בהן ממש, ונפרט." זה עדיף על טיפול נקודתי בכל טענה, שמייצר תחושה של רשימת מכולת ולא של ניתוח. + +**מבוסס על:** FJC §§B3-B4, E1-E2; Garner, MYC §§4, 8, 10-12; LWPE §30; Posner — honest engagement with counterarguments, avoid empty formulas. + +--- + +## ז. ציטוטים ואזכורי פסיקה — פחות זה יותר + +### ז.1 טכניקת הסנדוויץ' + +כל ציטוט חייב להיות עטוף: משפט הקדמה → ציטוט → ניתוח. + +**הקדמה גרועה:** "בית המשפט קבע כדלקמן:" (ריקה מתוכן). +**הקדמה טובה:** "בית המשפט קבע כי אין לקבל בקשות שהוגשו באיחור ללא טעם מיוחד:" (מודיעה על התוכן). + +אל תניח שהקורא יקרא ציטוט ארוך. סכם את עיקרו לפניו, ולאחריו הוסף ניתוח שמסביר כיצד הציטוט רלוונטי למקרה הנדון. + +### ז.2 כמה לצטט + +- **הוראת תכנית/חוק**: ציטוט ישיר — המילים המדויקות חשובות כי ההנמקה נבנית עליהן. +- **הלכה פסוקה**: פרפרזה עדיפה. צטט ישירות רק כשהניסוח המקורי עושה נקודה שלא ניתן לבטא בפרפרזה. 1-2 משפטים לכל היותר. +- **כלל מוסדר**: מקור אחד מספיק. לא מחרוזות של "ראו: X; Y; Z; A; B." מחרוזת אזכורים אינה מוסיפה כוח — היא מעידה על חוסר ביטחון. +- **כלל חדש או שנוי במחלוקת**: כאן כן יש מקום לסקירת ההתפתחות בפסיקה, אבל ממוקדת ותכליתית. + +### ז.3 היררכיית תקדימים + +בעררי תכנון, סדר המשקל הוא: +1. פסיקת בית המשפט העליון +2. פסיקת בית משפט לעניינים מנהליים +3. החלטות ועדת ערר ארצית +4. החלטות ועדות ערר מחוזיות אחרות +5. ספרות משפטית/תכנונית + +העדף תקדים עדכני. כשמאזכרים תקדים — ציין בדיוק מה נפסק ואם מדובר בהלכה מחייבת או אמרת אגב. אם התקדים שונה מהמקרה הנדון — אמור זאת במפורש. + +### ז.4 הפניות ביבליוגרפיות + +שלב את שם בית המשפט ושם התיק בגוף הטקסט ("כפי שקבע בית המשפט העליון בפרשת אליאב") והעבר את ההפניה המספרית להערת שוליים. הפניות בגוף הטקסט שוברות את מהלך המחשבה. + +**מבוסס על:** FJC §§D1-D5; Garner, MYC §§26-27, 48, 50; LWPE §§28-29. + +--- + +## ח. כתיבת חלק העובדות — ניטרלי, ממוקד, מדויק + +### ח.1 רק עובדות הנחוצות להסברת ההחלטה + +כל עובדה שמופיעה — הקורא יניח שהיא רלוונטית. אם היא לא רלוונטית — היא מסיחה דעת. אם היא רלוונטית ולא מופיעה — ההנמקה חסרה בסיס. + +**מה לעשות:** +- כלול רק עובדות שמשמשות בדיון. מבחן: לכל עובדה בחלק הרקע, שאל — "האם אני מפנה לעובדה זו בחלק הדיון?" אם לא — שקול להסיר. +- תאריכים מדויקים רק כשהם מהותיים (מועד הגשה, תוקף תכנית, שאלת שיהוי). אחרת — "כחודש לאחר מכן", "בתחילת 2023." +- פרטים "מעניינים" שאינם רלוונטיים — השמט. היסטוריה של השכונה, נוף, תיאורים ציוריים — רק אם רלוונטיים להחלטה. + +### ח.2 ניטרליות מוחלטת + +חלק העובדות אינו טוען. אין בו מילות שיפוט ("למרבה הפליאה", "באופן מפתיע"). אין בו ציטוטים מצדדים (ציטוטים שייכים לחלק הטענות). הוא מציג עובדות — לא מפרש אותן. + +אבל ניטרליות אינה הסתרה. אם יש עובדה שתומכת בצד המפסיד — היא חייבת להופיע. רקע ניטרלי כולל את כל העובדות המהותיות, לא רק את אלה שתומכות בתוצאה. + +### ח.3 מבנה: סדר כרונולוגי, עובדות כלליות ואז ספציפיות + +עקוב אחר ציר הזמן: הנכס, הבקשה, ההחלטה, הערר. אל תפתח בהחלטת הוועדה המקומית ואז תחזור לתיאור הנכס. + +בתיקים רב-סוגייתיים — הגבל את חלק הרקע לעובדות כלליות ושלב עובדות ספציפיות בדיון בכל סוגיה. זה מונע כפילות ושומר על רלוונטיות. + +### ח.4 דיוק מוחלט + +אל תסמוך על עובדות כפי שמוצגות בכתבי הטענות. בדוק מול חומרי המקור (פרוטוקולים, תכניות, תצהירים). שגיאה עובדתית היא הדבר המזיק ביותר שיכול לקרות להחלטה — היא מערערת את סמכותה ופוגעת באמינותה. + +**מבוסס על:** FJC §§C1-C6; Garner, LWPE §§3, 17, 23; MYC §36; Posner — data over words, facts drive decisions. + +--- + +## ט. כתיבת חלק ההכרעה — ברור ואופרטיבי + +### ט.1 התוצאה חייבת להיות חד-משמעית + +"הערר נדחה." "הערר מתקבל." "הערר מתקבל בחלקו." לא "לאור כל האמור לעיל, הערר נדחה" — אלא סיכום קצר (2-3 משפטים) שמסביר את עיקר ההנמקה, ואז התוצאה. + +### ט.2 הוראות אופרטיביות מפורטות + +כשהערר מוחזר לוועדה המקומית — אל תדבר בחידות. "הערר מוחזר לוועדה המקומית לצורך דיון מחדש" — אינו מספיק. פרט: מה צריכה הוועדה המקומית לבחון? לפי איזו תכנית? האם לתת שימוע? מהם השיקולים שיש לשקול? + +כשנקבעים תנאים — פרט כל תנאי באופן שהגוף המבצע יוכל ליישם בלי לפרש את ההחלטה. + +### ט.3 שמירה על סמכות הערכאה הנמוכה + +גם כשנמצא פגם בשיקול הדעת — ההחלטה מחזירה את העניין לוועדה המקומית כדי שתפעיל שיקול דעת מחדש. אל תכפה תוצאה ספציפית אלא אם הדין מחייב תוצאה אחת בלבד. + +### ט.4 התייחסות לוועדה המקומית — ללא ביקורת מיותרת + +כשהערר מתקבל — הוועדה המקומית טעתה. אבל ההנמקה מתמקדת ב"מה צריך להיות" — לא ב"כמה טעתה הוועדה המקומית." אין "באופן מפתיע", "למרבה הפליאה", "שגתה שגיאה חמורה". נמק את הפגם — אל תבקר את השופט. + +**מבוסס על:** FJC §§E4, F1-F3; Garner, MYC §21; Posner — narrow holdings, constrained pragmatism. + +--- + +## י. טכניקות כתיבה — ברמת הפסקה והמשפט + +### י.1 משפט נושא בפתיחת כל פסקה + +כל פסקה נפתחת במשפט שמודיע על הנקודה המרכזית שלה. לא באזכור פסק דין, לא בהפניה, לא בתיאור רקע. הנקודה — ואז התמיכה. + +**לא:** "בעע"מ 1234/05 נקבע כי..." → הקורא לא יודע למה הוא קורא על פסק הדין הזה. +**כן:** "ועדת ערר אינה מוסמכת להתערב בשיקול דעת מקצועי של מהנדס העיר. כך נפסק ב..." → הקורא יודע את הנקודה, ופסק הדין תומך בה. + +### י.2 גשרים בין פסקאות + +כל פסקה חייבה להיות מחוברת לקודמתה. שלושה כלים: +- **מילות קישור מפורשות**: לפיכך, אולם, בנוסף, מנגד, אכן, עם זאת. +- **מילות הצבעה**: "בעניין זה", "נוכח קביעה זו", "מעבר לכך". +- **הדי הפסקה הקודמת**: חזרה על מונח מפתח מהפסקה הקודמת בפתיחת הפסקה הנוכחית. + +### י.3 פסקה אחת — נקודה אחת + +אם פסקה עוסקת גם בכלל המשפטי, גם ביישומו, וגם בטענה נגדית — חלק אותה. הפסקה היא יחידת החשיבה הבסיסית, ויחידה שמכילה שני רעיונות שונים — מבלבלת. + +### י.4 כותרות אינפורמטיביות (כשמתאים) + +כשיש כותרות משנה בדיון (בתיקים מורכבים עם סוגיות נפרדות) — כתוב כותרת שמודיעה על המסקנה, לא רק על הנושא. +- **לא:** "סוגיית קו הבניין" +- **כן:** "הבנייה בקו אפס אינה עולה בקנה אחד עם הוראות התכנית" + +### י.5 בניין פעיל + +"הוועדה המקומית דחתה את הבקשה" — לא "הבקשה נדחתה על ידי הוועדה המקומית." בניין פעיל קצר יותר, ברור יותר, ומזהה את הפועל. חריג: כשהפעולה חשובה יותר מהפועל ("ההיתר בוטל" — כשלא חשוב מי ביטל). + +### י.6 דיוק ומשמעת לשונית + +- **עקביות מינוחית**: אם כתבת "היתר בנייה" — אל תעבור ל"רישיון בנייה." עקביות חשובה מגיוון. +- **לא להגזים**: "הפסיקה חד-משמעית" — רק אם היא באמת חד-משמעית. "אין כל ספק" — רק אם באמת אין. הגזמה מערערת אמינות. +- **לא לנפח**: "במידה ו-" → "אם". "לאור העובדה ש-" → "מכיוון ש-". "על מנת ש-" → "כדי ש-". כל מילה שאינה עוזרת — מפריעה. +- **לא לכפול**: "לבטל ולהפקיע" → "לבטל". אם מילה אחת מספיקה — מילה שנייה מחייבת את הקורא לחפש הבדל שאינו קיים. +- **סיום חזק**: אל תסיים משפט בתאריך או בהפניה אלא אם הם חשובים. המילה האחרונה במשפט היא זו שנשארת. + +### י.7 כנות לגבי קושי + +כשהמקרה קשה — אמור זאת. "הדבר אינו נקי מספקות, אולם..." עדיף על פני הצגת מקרה קשה כקל. כנות לגבי הקושי מחזקת את אמינות ההחלטה — הקורא מבין שהוועדה התלבטה ובכל זאת הגיעה למסקנה מנומקת. + +אבל — ההחלטה משקפת רק את התוצאה הסופית. לא לתעד כל צעד ומעד בדרך, לא להציג שני מסלולי חשיבה חלופיים. אם ההחלטה קשה — ניתן לומר זאת, ואז להציג את ההנמקה הסופית בביטחון. + +### י.8 הימנעות מנוסחאות ריקות + +כל משפט חייב לעשות עבודה. "לאחר ששקלנו את כלל השיקולים הרלוונטיים" — ריק. מה שקלתם? "בעניין זה יש לומר" — ריק. אמור מה יש לומר בלי ההקדמה. "הננו סבורים" — ריק. כתוב את מה שאתה סבור, בלי להכריז שאתה סבור. + +מבחן: אם מוחקים את המשפט וההחלטה לא מאבדת מידע — המשפט מיותר. + +**מבוסס על:** FJC §§G1-G6; Garner, LWPE §§5-17, 24-26; MYC §§6, 35, 39, 43; Posner — avoid empty formulas, candor about uncertainty. + +--- + +## יא. אנלוגיה ותקדים — מתי ואיך + +### יא.1 אנלוגיה דורשת הסבר מדיניות + +"מקרה זה דומה לפרשת X" — ריק, אלא אם מסביר למה הדמיון רלוונטי. מה המדיניות שעמדה בבסיס ההחלטה ב-X? האם אותה מדיניות חלה כאן? + +**מה לעשות:** +- כשמפנים לתקדים, ציין: (1) מה נפסק שם; (2) מה הנסיבות הדומות; (3) למה הרציונל חל גם כאן. +- כשמבחינים מתקדים: (1) מה שונה; (2) למה ההבדל משמעותי. + +### יא.2 החזקות חלופיות — "אף בהנחה" + +הימנע מ"אף בהנחה שצודקים העוררים בטענתם..." ו"גם אם היינו מקבלים..." — הם מחלישים את ההחזקה העיקרית. אם יש שני נימוקים — דון בנימוק המשני קודם ואז הצג את הנימוק העיקרי. כך שני הנימוקים עומדים בזכות עצמם, בלי שאחד מערער את השני. + +**מבוסס על:** FJC §B7; Garner, MYC §§26, 48; Posner — analogy requires policy analysis, narrow holdings. + +--- + +## יב. עריכה — רשימת ביקורת + +לפני סיום ההחלטה, בצע את הבדיקות הבאות: + +### ביקורת מבנית +- [ ] המבוא מכסה את כל הסוגיות שנדונו בהחלטה +- [ ] כל עובדה בחלק הרקע מופיעה בדיון (אין עובדות "יתומות") +- [ ] כל קביעה בדיון מבוססת על עובדה מחלק הרקע (אין עובדות חדשות בדיון) +- [ ] סדר הסוגיות לוגי: סף → מכריע → משני +- [ ] המסקנה נובעת מהדיון — לא מכריזה תוצאה שלא נומקה + +### ביקורת אנליטית +- [ ] לכל סוגיה — ניתן לזהות כלל + עובדות + מסקנה (מבנה סילוגיסטי) +- [ ] הממצאים העובדתיים מופרדים מהמסקנות המשפטיות +- [ ] הטענה המרכזית של הצד המפסיד קיבלה מענה מנומק +- [ ] אין "נוסחאות ריקות" — כל משפט עושה עבודה +- [ ] אין הגזמה — "חד-משמעי", "ברי", "ללא ספק" רק כשמוצדקים + +### ביקורת עקביות +- [ ] התוצאה בבלוק יא/יב תואמת את הסיכום בבלוק א/ב +- [ ] מינוח עקבי לאורך כל ההחלטה (אותם מונחים לאותם מושגים) +- [ ] הציטוטים מדויקים ובהקשרם +- [ ] אזכורי פסיקה נכונים (לא מייחסים לפסק דין יותר ממה שאמר) + +**מבוסס על:** FJC §§G8-G10; Garner, MYC §6; Posner — precision, intellectual honesty. + +--- + +## סיכום — עשרת העקרונות המנחים + +1. **סילוגיזם תמיד**: כלל → עובדות → מסקנה. אין קיצורי דרך. +2. **התחל מהטקסט**: הוראת תכנית או חוק — לפני פסיקה, לפני עקרונות כלליים. +3. **עובדות מכריעות**: רוב המקרים מוכרעים על ידי העובדות, לא על ידי הדין. +4. **נתונים, לא תיאורים**: מספרים ומידות — לא "משמעותי", "ניכר", "מהותי." +5. **Steel-man**: הצג את הטענה הטובה ביותר של הצד המפסיד — ואז הסבר למה היא נדחית. +6. **כנות**: מקרה קשה — אמור שהוא קשה. אל תעמיד פנים שקל. +7. **כל מילה עובדת**: נוסחה ריקה, מילה מנופחת, כפילות — מחק. +8. **מסקנה קודם**: הקורא יודע לאן הדיון מוביל — העובדות מובנות בהקשרן. +9. **מקור אחד מספיק**: לנקודה מוסדרת — אזכור אחד. מחרוזות אזכורים = חולשה. +10. **הוראות ברורות**: הצד שמקבל את ההחלטה חייב לדעת בדיוק מה נדרש ממנו. + +--- + +*מסמך זה מבוסס על שלושה מקורות מרכזיים: (1) Federal Judicial Center, Judicial Writing Manual (1991, 2020); (2) Garner, Legal Writing in Plain English (2001) ו-Scalia & Garner, Making Your Case (2008); (3) Posner, How Judges Think (2008). העקרונות סונתזו והותאמו להקשר של ועדת ערר לתכנון ובניה בישראל.* diff --git a/docs/practice-area-separation.md b/docs/practice-area-separation.md new file mode 100644 index 0000000..5ca635e --- /dev/null +++ b/docs/practice-area-separation.md @@ -0,0 +1,214 @@ +# הפרדת תחומים משפטיים — `practice_area` + +> מסמך לצוות פיתוח ה-UI: סיכום השינוי הבק-אנדי שהוכנס ב-`26d09d6` והשלכותיו על קליינטים. + +**Commit:** `26d09d6` · `main` +**Repo:** `gitea.nautilus.marcusgroup.org/ezer-mishpati/legal-ai` +**גודל:** 8 קבצים, +467/-33, קובץ אחד חדש + +--- + +## הרעיון בשורה אחת + +הוספנו ציר multi-tenant לדאטה בייס שמפריד תיקים, מסמכים, החלטות וקורפוס סגנון לפי **תחום משפטי** — כדי שחיפוש סמנטי ו-RAG לא יערבבו precedents בין תחומים שונים (היום: רישוי-ובנייה מול היטל-השבחה; בעתיד: גם ביטוח-לאומי, דיני-עבודה). + +## למה זה חשוב + +הרכיב המרכזי שמטפל בכתיבת בלוק הדיון (block-writer) שולף "פסקאות תקדים" מקורפוס ההחלטות הקודמות של דפנה תמיר באמצעות חיפוש סמנטי. **לפני השינוי**, שום פילטר תחומי לא הופעל — היה אפשר לקבל פסקה מהחלטה בהיטל השבחה (8xxx) כדוגמה לבלוק דיון של תיק רישוי-ובנייה (1xxx). הכללים, הסעיפים והטון בכל תחום שונים מהותית, וערבוב כזה הוא הזיה משפטית שמסכנת את איכות הטיוטה. + +באותו אופן: כשנוסיף בעתיד תחומים שונים לחלוטין (ביטוח לאומי, דיני עבודה), קורפוס הסגנון יהפוך מעורב — וללא הציר הזה לא נוכל להבטיח שדוגמאות סגנון נבחרות מהתחום הנכון. + +--- + +## שני שדות חדשים בכל הטבלאות הרלוונטיות + +| שדה | טיפוס | ערכים אפשריים | תפקיד | +|---|---|---|---| +| `practice_area` | `TEXT` | `appeals_committee` (כיום היחיד) · `national_insurance` · `labor_law` (עתידיים) | תחום-העל. ציר ה-multi-tenancy. כל חיפוש מסונן לפיו. | +| `appeal_subtype` | `TEXT` | `building_permit` · `betterment_levy` · `compensation_197` · `unknown` | מעדן בתוך תחום. רלוונטי כיום רק ל-`appeals_committee`. | + +**הסקה אוטומטית ממספר התיק** (קונבנציית ועדת ערר ירושלים): + +| מספר תיק | `appeal_subtype` | +|---|---| +| `1xxx-yy` | `building_permit` | +| `8xxx-yy` | `betterment_levy` | +| `9xxx-yy` | `compensation_197` | +| אחר | `unknown` | + +המשתמש יכול לעקוף ידנית; אם הוא בחר subtype שלא תואם להסקה האוטומטית, נכתבת רשומת `case_subtype_override` ל-`audit_log` כדי שנוכל לאתר טעויות סיווג. + +--- + +## שינויים במסד הנתונים (כבר רץ בפרודקשן) + +`SCHEMA_V4_SQL` ב-`mcp-server/src/legal_mcp/services/db.py` (idempotent — `IF NOT EXISTS` בכל מקום): + +- שתי עמודות חדשות בכל אחת מ-5 הטבלאות: + `cases`, `documents`, `document_chunks`, `decisions`, `style_corpus` +- 4 אינדקסים composite (`practice_area` תמיד ראשון): + `idx_cases_practice`, `idx_chunks_practice`, `idx_corpus_practice`, `idx_decisions_practice` +- **Backfill אוטומטי** של כל הרשומות הקיימות לפי regex על `case_number`, ופיזור ל-documents/chunks/decisions לפי FK. רשומות קורפוס היסטוריות (`case_id IS NULL`) מסומנות `appeals_committee`. + +**אומת אחרי הריצה (פרודקשן):** 0 ערכי NULL ב-`practice_area` בכל 5 הטבלאות (2 cases · 51 documents · 2810 chunks · 1 decision · 24 style_corpus). + +--- + +## קבצים שהשתנו + +### חדש + +| קובץ | תפקיד | +|---|---| +| `mcp-server/src/legal_mcp/services/practice_area.py` | מודול מרכזי: `derive_subtype(case_number)`, `validate(area, subtype)`, `is_override(...)`, וקבועי enum (`PRACTICE_AREAS`, `APPEALS_COMMITTEE_SUBTYPES`, `SUBTYPES_BY_AREA`). **כל קוד שצריך להחליט על תחום צריך לעבור דרך המודול הזה — אל תכתבו regex משלכם.** | + +### Backend — מסד נתונים (`mcp-server/src/legal_mcp/services/db.py`) + +- `SCHEMA_V4_SQL` חדש + הקריאה אליו ב-`init_schema()`. +- `create_case(...)` קיבל פרמטרים `practice_area`, `appeal_subtype`. +- `create_document(...)` ו-`store_chunks(...)` יורשים אוטומטית מה-case (או מקבלים override מפורש לקורפוס אימון שאין לו `case_id`). +- `create_decision(...)` יורש מה-case. +- **חדש:** `get_case_practice_area(case_id)` ו-`get_case_practice_area_by_number(case_number)` — שליפה מהירה. +- `search_similar(...)` ו-`search_similar_paragraphs(...)` קיבלו פרמטרי `practice_area` ו-`appeal_subtype` אופציונליים. הסינון משתמש בעמודה ה-denormalized ב-`document_chunks` ו-`decisions` (ללא JOIN יקר). +- `add_to_style_corpus(...)` קיבל `practice_area` (ברירת מחדל `appeals_committee`) ו-`appeal_subtype`. + +### Backend — MCP tools + +- `mcp-server/src/legal_mcp/tools/cases.py` — `case_create` קיבל `practice_area` + `appeal_subtype`. אם המשתמש סיפק subtype שונה ממה שההסקה האוטומטית אומרת, נכתב `audit_log` עם `action='case_subtype_override'`. +- `mcp-server/src/legal_mcp/tools/search.py` — `search_decisions` ו-`find_similar_cases` קיבלו פרמטרים `practice_area`, `appeal_subtype`, `case_number`. אם רק `case_number` סופק — ה-`practice_area` נשלף אוטומטית מה-DB. +- `mcp-server/src/legal_mcp/tools/documents.py` — `document_upload_training` קיבל `practice_area` ו-`appeal_subtype`, עם הסקה אוטומטית מ-`decision_number`. +- `mcp-server/src/legal_mcp/services/block_writer.py` — **תיקון קריטי** ב-`_build_precedents_context()`: כשבונים את הקשר ה-precedent לבלוק י (דיון), השליפה מסוננת לפי תחום התיק הפעיל. זה סוגר את חור הזיהום שתואר ב"למה זה חשוב". + +### API ו-UI הקיימים + +- `web/app.py`: + - `CaseCreateRequest` (Pydantic) קיבל שני שדות חדשים: `practice_area: str = "appeals_committee"` ו-`appeal_subtype: str = ""`. שניהם **אופציונליים עם defaults** — קליינט קיים לא נשבר. + - `POST /api/cases/create` מעביר אותם הלאה ל-`case_create` tool. +- `web/static/index.html`: + - בויזרד יצירת תיק (step 1) הוספנו שני dropdowns: "תחום משפטי" ו"סוג ערר" — שניהם בתוך אותו `form-row`. + - JS auto-fill: `wireSubtypeAutofill()` מאזין ל-`input` על `wiz-case-number` ומעדכן את `wiz-appeal-subtype` עד שהמשתמש שינה ידנית את הסלקט. + - `getWizardData()` מחזיר עכשיו גם `practice_area` ו-`appeal_subtype`. + - `buildSummary()` ומסך פרטי תיק (`loadCaseView`) מציגים badge כחול עם `practice_area · subtype`. + - **השדה הישן `committee_type`** הפך ל-`` כדי לא לשבור backwards compatibility (Paperclip integration עדיין משתמש בו לבחירת ארגון CMP/CMPA — ראו `web/paperclip_client.py`). + +--- + +## חוזי API ל-UI חדש + +### `POST /api/cases/create` — request body + +```jsonc +{ + "case_number": "1130-25", + "title": "...", + "appellants": ["..."], + "respondents": ["..."], + "subject": "", + "property_address": "", + "permit_number": "", + "committee_type": "ועדה מקומית", + "hearing_date": "", + "notes": "", + "expected_outcome": "", + + // ← חדש (אופציונלי, יש defaults) + "practice_area": "appeals_committee", + "appeal_subtype": "building_permit" // ריק = יוסק אוטומטית מ-case_number +} +``` + +> **חשוב:** אם תשלחו `appeal_subtype` ריק או לא תשלחו אותו בכלל — השרת יסיק לבד מ-`case_number` (1xxx/8xxx/9xxx). הסקה ידנית בצד הקליינט אופציונלית בלבד (משפרת UX, לא נדרשת לתקינות). + +### `GET /api/cases/{case_number}/details` — response + +```jsonc +{ + "id": "...", + "case_number": "1130-25", + // ... כל השדות הקיימים + "practice_area": "appeals_committee", // ← חדש + "appeal_subtype": "building_permit" // ← חדש +} +``` + +`list_cases` ו-`case_get` מחזירים את אותם שדות. + +### Enums לסנכרון בקליינט + +```typescript +type PracticeArea = 'appeals_committee' | 'national_insurance' | 'labor_law'; +type AppealSubtype = 'building_permit' | 'betterment_levy' | 'compensation_197' | 'unknown'; + +const PRACTICE_AREA_LABELS: Record = { + appeals_committee: 'ועדת ערר', + national_insurance: 'ביטוח לאומי', + labor_law: 'דיני עבודה', +}; + +const SUBTYPE_LABELS: Record = { + building_permit: 'רישוי ובנייה', + betterment_levy: 'היטל השבחה', + compensation_197: "פיצויים (ס' 197)", + unknown: 'לא ידוע', +}; + +// 1xxx → building_permit · 8xxx → betterment_levy · 9xxx → compensation_197 +function deriveSubtypeFromCaseNumber(caseNumber: string): AppealSubtype { + const m = caseNumber.trim().match(/^(\d)/); + if (!m) return 'unknown'; + return ({ '1': 'building_permit', '8': 'betterment_levy', '9': 'compensation_197' } as const)[m[1]] ?? 'unknown'; +} +``` + +--- + +## מה ה-UI החדש חייב לכלול + +1. **טופס יצירת תיק** — שדה `practice_area` (היום ועדת ערר בלבד, אבל בנו את הקומפוננטה כ-dropdown מוכן להרחבה) + שדה `appeal_subtype` עם auto-fill ממספר התיק. אפשרות override ידני. +2. **תצוגת תיק / רשימת תיקים** — badge גלוי שמראה את התחום + סוג הערר. קריטי כדי שמשתמשים יבינו באיזה הקשר הם עובדים, במיוחד כשנוסיף תחומים נוספים. +3. **פילטרים ברשימות חיפוש/תיקים** — הוסיפו אופציה לסנן לפי תחום (אופציונלית בשלב זה, חובה ברגע שנוסיף תחום שני). +4. **קריאות לחיפוש** (`search_decisions`, `find_similar_cases`) — אם אתם מבצעים חיפוש בהקשר של תיק, **תמיד תעבירו `case_number`** — השרת יוסיף את הסינון אוטומטית. אחרת תקבלו warning ב-log על חיפוש חוצה-תחומים. + +## תאימות לאחור + +**אין שבירות חוזה.** כל השדות החדשים אופציונליים עם defaults. קליינט שלא מכיר את `practice_area`/`appeal_subtype` ממשיך לעבוד — פשוט יקבל ערכי ברירת המחדל (`appeals_committee` + מה שיוסק ממספר התיק). + +**שינוי התנהגות אחד שכדאי לדעת:** +`committee_type` נשאר בסכמה ובחוזה אבל ב-UI הקיים הוא הפך ל-hidden field. אם ה-UI החדש שלכם מאפשר עריכה ידנית של `committee_type`, ודאו שהעדכון לא דורס את הסמנטיקה החדשה. עדיף לחשוב על: +- `committee_type` — "מצב הוועדה במקור" (legacy + Paperclip routing) +- `practice_area` / `appeal_subtype` — "איך המערכת מסווגת את התיק לצורך RAG/חיפוש" + +--- + +## בדיקות שעברו + +- Unit tests של `practice_area.py` (`derive_subtype`, `validate`, `is_override`) +- Migration רץ על פרודקשן: 0 NULLs ב-5 הטבלאות +- `case_create('1999-99')` → אוטומטית `building_permit` +- `case_create('8999-99', appeal_subtype='building_permit')` → audit log רושם `case_subtype_override` +- `search_similar(practice_area='national_insurance')` → 0 תוצאות (אין leakage לתחום ריק) +- `search_similar(practice_area='appeals_committee')` → 5 תוצאות תקינות + +--- + +## שאלות פתוחות לצוות UI + +1. **Backfill ל-Paperclip routing:** היום `paperclip_client.py` ממפה לארגון (CMP/CMPA) לפי `committee_type` המילולי. רוצים שנעביר את ה-routing להסתמך על `appeal_subtype` כדי שיהיה מקור-אמת אחד? +2. **פילטר תחום ברשימות חיפוש גלובליות:** האם ה-UI החדש יציג את התחום כ-segmented control בראש כל מסך חיפוש, או כ-filter chip? +3. **תחומים עתידיים:** האם יש כבר תכנון לאיזה תחום שני נוסיף ראשון (ביטוח לאומי / דיני עבודה / אחר)? אם כן — נוכל להכין את ה-`SUBTYPES_BY_AREA` מראש ב-`practice_area.py`. + +--- + +## נקודות מגע בקוד (להפניית קריאה מהירה) + +| תחום | קובץ | פונקציה / סימן | +|---|---|---| +| מודול דרייב/ולידציה | `mcp-server/src/legal_mcp/services/practice_area.py` | `derive_subtype`, `validate`, `is_override` | +| סכמה ומיגרציה | `mcp-server/src/legal_mcp/services/db.py` | `SCHEMA_V4_SQL`, `init_schema` | +| יצירת תיק | `mcp-server/src/legal_mcp/services/db.py` · `mcp-server/src/legal_mcp/tools/cases.py` | `create_case`, `case_create` | +| הורשה למסמכים/chunks | `mcp-server/src/legal_mcp/services/db.py` | `create_document`, `store_chunks`, `create_decision` | +| חיפוש מסונן | `mcp-server/src/legal_mcp/services/db.py` · `mcp-server/src/legal_mcp/tools/search.py` | `search_similar`, `search_similar_paragraphs`, `search_decisions`, `find_similar_cases` | +| תיקון contamination בבלוק דיון | `mcp-server/src/legal_mcp/services/block_writer.py` | `_build_precedents_context` | +| קורפוס אימון | `mcp-server/src/legal_mcp/tools/documents.py` · `mcp-server/src/legal_mcp/services/db.py` | `document_upload_training`, `add_to_style_corpus` | +| API חוזה | `web/app.py` | `CaseCreateRequest`, `api_case_create` | +| UI קיים | `web/static/index.html` | `wireSubtypeAutofill`, `getWizardData`, `buildSummary`, `loadCaseView` | From 4b217bf745b2e58ff13bf8be69734d32bb04a914 Mon Sep 17 00:00:00 2001 From: Chaim Date: Mon, 13 Apr 2026 12:42:00 +0000 Subject: [PATCH 2/2] index on main: 3541238 Update CLAUDE.md: add corpus-analysis.md to reference table