ezer-mishpati/legal-ai
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
5867f7175f02c36a6bf1a31b8f4fec12aa19861e
legal-ai/docs/spec/04-analysis-writing.md
Chaim b560417dd7
All checks were successful
G12 Leak-Guard / leak-guard (pull_request) Successful in 4s
Details
Lint — undefined names / undefined-names (pull_request) Successful in 10s
Details
feat(ceo): wire party-claims executive summary as chair-requestable stage (#202 follow-up) 
The summarize_party_claims tool (#202) generated a distilled executive
summary of party claims but was orphaned: not granted to any agent and
no CEO trigger. Wire it parallel to the interim-draft (שלב H).

- Grant mcp__legal-ai__summarize_party_claims in legal-ceo.md frontmatter.
- Add שלב H2 (סיכום מנהלים) mirroring שלב H: side-quest (no cases.status
  change, no sub-agent issues), in_progress → run tool → in_review + notify.
  Two triggers: chair comment ("סיכום מנהלים"/"סיכום טענות"/"סיכום לקראת
  דיון"/"executive summary") OR structured action
  $PAPERCLIP_WAKE_PAYLOAD_JSON action == "party_claims_summary".
- Add structured-action trigger to שלב H (interim draft):
  action == "interim_draft" — same deterministic UI-button path.
- שלב 0 + HEARTBEAT.md: route structured actions deterministically.
- Spec note in docs/spec/04-analysis-writing.md §1.4.

Invariants: G2 (reuse existing summarize_party_claims tool/path, no parallel
route), G10 (chair-requested side-quest). Agent-prompt/docs only — no app code.

Note: CEO prompt is shared across CMP+CMPA via instructionsFilePath; after
merge the host tree needs `git pull` (agents run host-side reading
.claude/agents/*.md).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-30 19:22:26 +00:00

26 KiB
Raw Blame History

04 — ניתוח וכתיבה (Analysis & Writing)

קובץ-תחום זה כפוף ל-חוקת המערכת ומפרט את שלב הסיוע-בכתיבה — חילוץ הטענות, ארכיטקטורת 12 הבלוקים, וסגנון דפנה. הוא אוכף את INV-G11 (תוכן החלטה מנומקת).

⚠ מודל-סמכות שונה מ-01–03. זהו קובץ תוכן-משפטי, לא קובץ-הנדסה. לפי החוקה (§2 עיקרון 2, §5ב) הסמכות עליו היא היו"ר (עו"ד דפנה תמיר) + מסמכי-הפרויקט — block-schema.md, decision-methodology.md, legal-decision-lessons.md, corpus-analysis.md, skills/decision/SKILL.md. ה-invariants כאן אינם כפופים לפרוטוקול ≥3-המקורות החיצוני, ואינם נושאים סטטוס: verified / ⚠ UNVERIFIED. במקום מקורות: … | סטטוס הם נושאים מקור-סמכות:. מסמכי-הפרויקט הם המקור המוסמך; קובץ זה מצטט אותם בגובה-ספ, לא משכפל את ההגדרות.

1. חילוץ טענות → טיעונים מאוגדים

לפני הכתיבה, חומרי-המקור הופכים למבנה-נתונים שמזין את הבלוקים. שני שלבים:

1.1 חילוץ טענות גולמיות (claims)

extract_claims(case_number, doc_title="", party_hint="") קורא לכתבי-הטענות בתיק, ושומר טענות גולמיות ב-DB. הוא מסנן למסמכים מסוג appeal / response / objection (אלא אם צוין doc_title מפורש), ולכל מסמך קורא ל-claims_extractor.extract_and_store_claims — ראה mcp-server/src/legal_mcp/tools/documents.py:300-347.

כל טענה נשמרת עם party_role מתוך התפקידים המוכרים: appellant (עוררים) · respondent (משיבים) · committee (ועדה מקומית) · permit_applicant (מבקשי היתר) · appraiser (שמאי). get_claims(case_number, party_role="") שולף ומציג אותן בעברית, עם סינון אופציונלי לפי תפקיד (documents.py:350-385; מיפוי-העברית ב-:370-376).

1.2 כינוס לטיעונים משפטיים מובחנים (legal arguments)

aggregate_claims_to_arguments(case_number, force=False) מכנס את הפרופוזיציות הגולמיות לטיעונים משפטיים מובחנים (de-duplication) דרך argument_aggregator.aggregate_claims_to_arguments; force=True מוחק טיעונים קיימים ומחשב מחדש — ראה mcp-server/src/legal_mcp/tools/legal_arguments.py:11-33. get_legal_arguments(case_number, party="") שולף את הטיעונים המאוגדים, מקובצים לפי צד (appellant/respondent/committee/permit_applicant/unknown); אם אין — הוא מחזיר הנחיה להריץ קודם את הכינוס (legal_arguments.py:36-83).

מדוע זה חשוב לתוכן: הטיעונים המאוגדים הם הקלט ל-INV-WR3 (מענה לכל טענה עיקרית) ול-INV-WR4 (הפרדת טענות מקוריות מהשלמות). הסינון לפי party_role מאפשר לזהות את הצד המפסיד ולוודא שכל טיעון שלו מקבל מענה בבלוק י.

עיצוב-מחדש זרימת-העבודה (WS2–WS4) — מסלול-החילוץ אינו מתפצל (G2): ניתוח-ערר-לבד כבר עובד (extract_claims רץ על appeal בנפרד). ההרחבות נשענות על אותו צינור- חילוץ, לא על מסלול-ניתוח שני: (א) ניתוח-מחדש מאחד (WS2, #200/#201) — מחלץ מ-מסמכים חדשים/מעודכנים בלבד ומאחד עם הקיים (לא מוחק-ומחשב-מחדש), על-בסיס דגל-הניתוח per-מסמך (02-data-model §2ב); (ב) סיכום-מנהלים (WS3, #202, summarize_party_claims — ראה §1.4) — נגזר מ-claims/legal_arguments, מסמך-פרוזה נפרד מטיוטת-הביניים (G2: תצוגה-נגזרת, לא מקור-אמת שני); (ג) ניתוח-פרוטוקול (WS4, #203, analyze_protocol — ראה §1.3) — protocol נכנס לחילוץ ההשוואתי (ירד/חוזק/חדש) ומזין ידע-תיק, ונשאר פוסט-דיון (INV-WR4: טענות-פוסט-דיון → בלוק ח, לא ז). חוזי-הכלים המלאים בבעלות המשימות הנ"ל (§1.3/§1.4); כאן רק עיגון-הספ שהם מקיימים G2.

1.3 ניתוח-פרוטוקול — ניתוח פרוטוקול-דיון השוואתי (WS4 / #203)

בעלוּת תת-סעיף: §1.3 (זה) שייך ל-WS4 (ניתוח-פרוטוקול). תת-סעיף סיכום-טענות-הצדדים (PR-אחות #358) הוא תת-סעיף נפרד (§1.4) תחת §1 — אין חפיפת-מספור בין השניים.

אחרי הדיון, פרוטוקול (doc_type='protocol') מנותח מול הטיעונים המאוגדים — analyze_protocol(case_number) (→ services/protocol_analyzer.py). הניתוח מסווג כל טיעון כתוב כירד (dropped — נזנח/ויתר בדיון), חוזק (strengthened), או מזהה טענה שעלתה לראשונה בדיון (newly_raised), ולכל רשומה מנסח את השאלה המשפטית המחודדת לטובת בלוק י. התוצאה נשמרת בידע-התיק — טבלת protocol_analysis (case- knowledge נגזר; G2: מקור-האמת הוא הפרוטוקול + legal_arguments, הרשומה היא השוואה מטוריאליזת בת-שחזור) — וזמינה ל-get_protocol_analysis(case_number, change_type="") (סימטריית extract/get, INV-TOOL4).

  • קלט: הטיעונים המאוגדים (§1.2) הם קו-הבסיס; ללא כינוס אין מול-מה להשוות.
  • שער anti-hallucination (INV-AH): כל רשומה חייבת evidence_quote — ציטוט מילולי מהפרוטוקול. רשומה ללא ציטוט-מבסס נדחית במקור (_normalize_change) ולא מגיעה ל-DB (quote-or-retract).
  • טענות-הדיון בנפרד מבלוק ז: טענות שעלו בדיון מתויגות claim_type='protocol' ב-extract_claims ומוחרגות מהקשר בלוק ז (block_writer._build_claims_context) — בלוק ז נשאר טענות-כתב מקוריות בלבד (INV-WR4); טענות-הדיון שייכות לבלוק ח (הליכים) ולידע-התיק ההשוואתי.
  • נתוני כותרת (א–ד): הניתוח מחלץ גם את הפיד המוכר (הרכב, תאריך-דיון, צדדים שהופיעו) ומזין את hearing_date חזרה לעמודה הקנונית cases.hearing_date (G1; לא נכתב אם היו"ר כבר מילא תאריך — לא דורסים קלט-יו"ר).
  • ייצור: קריאת-ה-LLM ההשוואתית עוברת claude_session (מקומי בלבד), מעוגנת model="claude-opus-4-8" + effort="high" (ראה reference_claude_generation_path).

1.4 סיכום-מנהלים של טענות הצדדים (מסמך-הכנה לדיון, WS3/#202)

summarize_party_claims(case_number, instructions="") מפיק מסמך-פרוזה מזוקק של טענות הצדדים — תמצית-מנהלים קצרה ומוקפדת שמטרתה להכין את היו"ר לדיון בעל-פה. זהו מסמך נפרד ומובחן מטיוטת-ההחלטה ומטיוטת-הביניים (החלטת-יו"ר, תוכנית workflow-redesign §WS3) — אינו חלק מ-12-הבלוקים ואינו נכתב לתבנית ההחלטה.

  • מקור-אמת יחיד (G2): המסמך נגזר מ-legal_arguments (טיעונים מאוגדים) או, כ-fallback, מ-claims הגולמיים — אותו מקור של §§1.1–1.2, ללא חילוץ-מחדש ובלי לקרוא לכתבי-הטענות ישירות. אין מסלול-נתונים מקביל.
  • זיקוק, לא שכפול: התמצית מתמצתת כל צד למשפטי-מפתח ומוסיפה פרק "נקודות-המחלוקת המרכזיות" כשאלות פתוחות — לא משכפלת את כתבי-הטענות ולא מכריעה.
  • עיגון-מקור (INV-AH): הפרומפט מתוחם לחלוטין לטענות-התיק שבקלט; אסור להמציא טענה/הלכה/ פסק-דין/עובדה שאינם בקלט — טענה לא-ברורה מצוינת במפורש (anti-hallucination-gate).
  • ייצור local-only: עובר claude_session → claude -p נעוץ ל-Opus 4.8 + effort=high (משימת זיקוק/סינתזה). הקונטיינר חסר ה-CLI — לכן הייצור הוא כלי-MCP מקומי בלבד; endpoints ב-web/app.py רק מגישים/מייצאים את הקובץ השמור, לא מייצרים.
  • שמירה + ייצוא: נשמר ל-data/cases/{n}/documents/research/party-claims-summary.md (git + S3, באותו מסלול-אחסון של analysis-and-research.md); ניתן-לייצוא ל-DOCX בסגנון-תבנית דפנה (build_party_claims_summary_docx). מימוש: tools/drafting.py · services/party_claims_summary.py · services/analysis_docx_exporter.py.
  • טריגר — side-quest מבוקש-יו"ר (G10), נפרד מטיוטת-הביניים: ה-CEO מפיק את הסיכום כשלב-צד (legal-ceo.md שלב H2) ב-שתי דרכים: (א) הערת-יו"ר חופשית ("סיכום מנהלים" / "סיכום טענות" / "סיכום לקראת דיון" / "executive summary"); או (ב) פעולה סטרוקטורלית — $PAPERCLIP_WAKE_PAYLOAD_JSON עם action == "party_claims_summary" (המסלול הדטרמיניסטי שכפתור-UI עתידי יפעיל, בלי פענוח-טקסט). זהו side-quest: אינו משנה cases.status ואינו יוצר issues לסוכני-משנה, ומובחן מטיוטת-הביניים (write_interim_draft, שלב H, action == "interim_draft").

1.5 ניתוח-מחדש מאחד אחרי מסמך-עיקרי חדש (#201)

תיק מנותח לרוב מכתב-הערר לבד, ומסמך-עיקרי (תשובה/התנגדות/פרוטוקול…) מגיע מאוחר יותר. כל מסמך נושא דגל "לא-נותח" (claims_extracted_at, 02-data-model §2ג), ו-workflow_status מסמן "מסמך-עיקרי שטרם-נכלל בניתוח". reanalyze_claims(case_number, reanalyze_all_primary=False) סוגר את הפער בלי force-delete גורף:

  1. snapshot לפני — הטיעונים המאוגדים הנוכחיים (בסיס בדיקת-ההשפעה).
  2. חילוץ-מאחד — מחלץ רק את המסמכים-העיקריים החדשים/לא-נותחו (db.primary_docs_not_analyzed) דרך אותו claims_extractor.extract_and_store_claims; store_claims מחליף רק את טענות אותו מסמך (לפי source_document), כך שטענות ממסמכים שכבר-נותחו נשמרות (האיחוד).
  3. צבירה-מחדש — aggregate_claims_to_arguments(force=True) מחשב את הטיעונים מחדש מתוך מערך-הטענות המאוחד השלם. זהו מסלול-החישוב הקנוני (G2), לא מסלול-עיבוד מקביל; הוא מוחק רק legal_arguments (נגזר), לעולם לא claims.
  4. בדיקת-השפעה ליו"ר — snapshot אחרי + _impact_diff מחזיר per-צד אילו טיעונים נוספו/הוסרו ואיך השתנה תמהיל-העדיפויות ("מאזן-ההמלצה"), עם דגל changed. הפלט מוצג ליו"ר ולא מוחל אוטומטית (G10).

ראה tools/legal_arguments.py (reanalyze_claims, _snapshot, _impact_diff).

1.6 שער שטן-מליץ (red-team) — בין הניתוח לכתיבה, תחת אישור-יו"ר

אחרי שלב-הניתוח (analysis-and-research.md תקין) ובלפני הכותב, ה-CEO מפעיל אוטומטית שכבת דעה-שנייה אדוורסרית מ-lineage שונה (Gemini, legal-analyst-gemini-critique, read-only) — שער-קבע (standing gate), לא on-demand. השכבה תוקפת את ניתוח-Opus ומפיקה critique-gemini.md = מזכר-לידים לא-סמכותי, מתויג-ודאות ([מאומת-קורפוס]/[טעון-אימות]/ [ספקולציה]), כפוף לשער ה-anti-hallucination (INV-AH; כלי-RAG משפטיים הוזים פסיקה 17–33%, Stanford RegLab/Magesh JELS 2025).

  • human-in-the-loop קשיח (G10): ה-CEO מציג את הלידים ליו"ר כעצירת-אישור (ה-issue הראשי ל-in_review + מייל), ואינו מתקדם לכותב בלי הכרעת-יו"ר מפורשת. רק לידים שהיו"ר אישר מומרים ל-chair_directions דרך מנגנון-ההנחיות הקיים (record_chair_feedback → "עמדת ועדת הערר" ב-analysis-and-research.md → get_chair_directions → approve_direction); לידים שנדחו נמחקים.
  • הכותב צורך מקור-מעוגן בלבד (INV-WR1–WR5 + INV-LRN5): הקלט לכתיבה הוא פלט-המנתח המעוגן + ההנחיות-המאושרות — לעולם לא הלידים הגולמיים של שטן-מליץ. השכבה אינה מסלול-נתונים מקביל לכתיבה (G2) ואינה כותבת שום שכבת-קול/ידע (INV-LRN5) — read-only ל-critique-gemini.md בלבד.
  • מקור-אמת לזרימה: X4 INV-AG4

2. ארכיטקטורת 12 הבלוקים (סיכום)

המבנה הפורמלי המלא — content model, constraints, משקלות, ופרמטרי-עיבוד לכל בלוק — מוגדר ב-block-schema.md (המקור המוסמך). כאן רק מפת-גובה:

בלוק תפקיד CREAC תוכן מהותי?
א–ד כותרת מוסדית · הרכב · צדדים · "החלטה" — לא (template-fill)
ה פתיחה ("לפנינו…") C ראשוני קל
ו רקע עובדתי ("פתח דבר") — כן — עובדות בלבד
ז טענות הצדדים — כן — טענות מקוריות בלבד
ח הליכים בפני הוועדה — כן (תיעוד, ללא הערכה)
ט תכניות חלות (אופציונלי) R כן (כשיש מורכבות תכנונית)
י דיון והכרעה full-CREAC כן — ה-ratio decidendi
יא סיכום / סוף דבר C אחרון קל
יב חתימות — לא

יסודות תיאורטיים (CREAC · FJC Judicial Writing Manual · DITA · Akoma Ntoso), תלויות-בין-בלוקים, וכללי-ולידציה — ב-block-schema.md §§1, 5, 6. מתודולוגיית-המשקלות (Communicative / Reader-attention / Judicial-review / Empirical) — שם §4. טיוטת-ביניים (Pre-Ruling Draft) בוחרת תת-קבוצת בלוקים (ו, ט, ז, ח) — block-schema.md §7; שלב-החילוץ השמאי שלה (extract_appraiser_facts) מזין את בלוק ט.

ציטוט-תכנית קנוני (בלוק ט): הזהות והתוקף של תכנית (תאריך פרסום למתן תוקף ברשומות + מס' ילקוט-הפרסומים) נכתבים בנוסח אחיד דטרמיניסטי ממרשם-התכניות (plans, 02-data-model) דרך db.format_plan_citation — לא מנוסחים מחדש ע"י ה-LLM, ובכך לא מהוזים (anti-hallucination-gate, INV-AH). הנוסח עצמו הוא תוכן-משפטי באחריות היו"ר (block-schema.md בלוק ט); המרשם נכנס לשימוש רק אחרי אישור-יו"ר (review_status, G10).

התמקדות לפי feedback היו"ר: הסיוע מתמקד בבלוקים המהותיים (ו–יב); בלוקים א–ד ממולאים מ-template ואינם דורשים ניתוח. ראה MEMORY.md → "התעלם מכותרות".

3. סגנון דפנה (סיכום)

מדריך-הסגנון המלא הוא skills/decision/SKILL.md; המתודולוגיה האנליטית ("איך לחשוב לפני איך לכתוב") היא decision-methodology.md. נקודות-מפתח:

  • טון לפי סוג-ערר — רישוי (1xxx) חם יחסית; היטל-השבחה (8xxx) ופיצויים ס'197 (9xxx) קרים ויבשים (SKILL.md §1; methodology §א.2).
  • מבנה הדיון (בלוק י) — נפתח במסקנה (CREAC: C→R→E→A→C), סילוגיזם לכל סוגיה, steel-manning של הצד המפסיד, ציטוט-פסיקה ב"סנדוויץ'" (methodology §§ד, ו, ז).
  • מסלול-דיון לפי תוצאה — דחייה (עיגולים קונצנטריים) · קבלה (נימוק-נימוק) · קבלה חלקית (מיפוי-מתחים) · היטל-השבחה (פתיחה ישירה) — SKILL.md §7.3; block-schema.md בלוק י.
  • 3 מקורות-פסיקה נפרדים — אסור לבלבל ביניהם (SKILL.md §7.5; ראה גם 03-retrieval.md לשכבת-האחזור שמזינה אותם).
  • לקחים מצטברים — legal-decision-lessons.md + ביטויי-מעבר; מתעדכנים מפידבק-היו"ר ומ-Hermes (ראה forward-ref 07-learning.md).

4. Invariants של התחום — תוכן החלטה מנומקת

חמשת ה-invariants הבאים הם פאֶטים של INV-G11. כולם נושאים מקור-סמכות (היו"ר + מסמכי-הפרויקט), ללא שדה-מקורות-חיצוני וללא סטטוס-אימות — כמתחייב מהבחנת שתי-הסמכויות בחוקה (§5).

INV-WR1: רקע ניטרלי (בלוק ו) — עובדות בלבד

כלל: בלוק ו מציג עובדות בלבד ואינו טוען. אסורות מילות-ערך/שיפוט ("חריג", "בעייתי", "למרבה הפליאה") ואסורים ציטוטים ישירים מצדדים (אלה שייכים לבלוק ז). החלטות קודמות מובאות כעובדה יבשה ("ביום X נדחתה תכנית Y"), ללא נימוקים. ניטרליות אינה הסתרה: עובדה מהותית התומכת בצד המפסיד חייבת להופיע. מקור-סמכות: היו"ר (עו"ד דפנה תמיר) + block-schema.md (בלוק ו, §5.2 "רקע ניטרלי") + decision-methodology.md §ח.2. אכיפה: ולידציית-תוכן בבלוק ו (סעיף עם ציטוט-צד או מילת-שיפוט → לא שייך כאן) + שערי QA; מפורט ב-05-qa-review.md. הפרה ידועה: —

INV-WR2: ללא כפילות (בלוק י מפנה, לא חוזר)

כלל: בלוק י (דיון) מפנה לעובדות ולטענות שכבר הוצגו בבלוקים הקודמים ("כאמור בסעיף X לעיל", "כפי שפורט") — ואינו חוזר עליהן. חריג יחיד: חזרה מכוונת עם שכבת-ניתוח חדשה ("נשוב על כך כי…"). אין עובדות חדשות בדיון שלא הופיעו ברקע. מקור-סמכות: היו"ר + block-schema.md (בלוק י, §5.2 "ללא כפילות") + skills/decision/SKILL.md §9.1. אכיפה: ולידציית-מבנה (עובדה בדיון ללא עוגן ברקע = flag) + שערי QA; מפורט ב-05-qa-review.md. הפרה ידועה: —

INV-WR3: מענה לכל טענה של הצד המפסיד

כלל: כל טענה עיקרית שהוצגה בבלוק ז — ובמיוחד של הצד המפסיד — מקבלת מענה מנומק בבלוק י (ישיר, "למעלה מן הצורך", או מקובץ עם דומותיה). מותר לא להכריע בטענה נחוצה-פחות ("נוכח מסקנתנו לעיל, אין צורך…"), אך אסור להתעלם מטענה מרכזית — הצד המפסיד חייב לראות שהוועדה שקלה את יסודות עמדתו (steel-manning). מקור-סמכות: היו"ר + decision-methodology.md §§ג.2, ו.2 + block-schema.md (בלוק י MUST: "מענה לכל טענה" §5.4) + skills/decision/SKILL.md §6.2. אכיפה: מיפוי טענות-בלוק-ז → מענה-בלוק-י (נשען על §1.2, הטיעונים המאוגדים) + שערי QA; מפורט ב-05-qa-review.md. הפרה ידועה: —

INV-WR4: בלוק ז — טענות מקוריות בלבד

כלל: בלוק ז מכיל אך ורק טענות מכתבי-הטענות המקוריים (כתב-ערר, כתב-תשובה). תוכן מהשלמות-טיעון, החלטות-ביניים, ותגובות-מאוחרות → בלוק ח (הליכים), לא בלוק ז. הצגת-הטענות היא בנאמנות וללא הערכה ("טענה זו חלשה") — ההערכה שייכת לבלוק י. מקור-סמכות: היו"ר + block-schema.md (בלוק ז Sources + §5.2 "טענות מקוריות בלבד") + skills/decision/SKILL.md §4. אכיפה: סיווג-מקור של טענה בעת החילוץ (extract_claims מסנן appeal/response/ objection; מסמכי פוסט-דיון מתויגים is_post_hearing ומופנים לבלוק ח — block-schema.md §7)

INV-WR5: "מבחן-השופט" — החלטה עצמאית וקריאה

כלל: ההחלטה חייבת להיות עצמאית וקריאה לשופט שלא מכיר את התיק — תשתית עובדתית מלאה (בלוק ו), תיעוד procedural-fairness (בלוק ח), והנמקה שעומדת בבדיקת סבירות ומידתיות (בלוק י). הקורא לא נדרש לחומרי-המקור כדי להבין את ההחלטה ואת הצדקתה. מקור-סמכות: היו"ר + block-schema.md §4.3 ("מבחן השופט" / Judicial-Review weight) + decision-methodology.md §יב (רשימת-ביקורת) + corpus-analysis.md. אכיפה: שער QA סופי ("מבחן-השופט") על ההחלטה כיחידה שלמה; מפורט ב-05-qa-review.md. הפרה ידועה: —

5. צ'קליסט-תוכן לפי סוג-ערר

בלוק י מקבל צ'קליסט-תוכן המוזרק אוטומטית ל-prompt לפי סוג-הערר, מתוך CONTENT_CHECKLISTS ב-mcp-server/src/legal_mcp/services/lessons.py:355. הבורר (lessons.py:532-555) ממפה לסוג: tama38 (תמ"א 38) · betterment_levy (היטל-השבחה) · licensing_property · licensing_threshold (שאלת-סף) · licensing_substantive (ברירת-מחדל לרישוי). הצ'קליסט מבטיח שהדיון מכסה את הנושאים התכנוניים/המשפטיים שדפנה מכסה בפועל בקורפוס — ראה corpus-analysis.md §§3, 6 לדפוסי-התוכן ולפער שנסגר (§5.3). זהו מנגנון-תוכן באחריות היו"ר, לא חוק-הנדסה.

6. הפניות-אחיות

Reference in New Issue View Git Blame Copy Permalink