Update knowledge files with corpus analysis and feedback system docs
- CLAUDE.md: added corpus-analysis.md to reference table, documented chair feedback system - block-schema.md: added content_checklist constraint to block-yod - legal-decision-lessons.md: added lessons 12-16 from corpus analysis (planning discussion, 5 subtypes, feedback system) - SKILL.md: added section 12 (content checklists, planning discussion patterns, chair feedback) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
11
CLAUDE.md
11
CLAUDE.md
@@ -42,6 +42,7 @@
|
||||
| [`docs/block-schema.md`](docs/block-schema.md) | הגדרת 12 בלוקים — content model, constraints, processing params | **לפני כל כתיבת החלטה** |
|
||||
| [`docs/migration-plan.md`](docs/migration-plan.md) | תוכנית מעבר vault → DB — טבלאות, עדיפויות, כמויות | לפני ייבוא נתונים |
|
||||
| [`docs/legal-decision-lessons.md`](docs/legal-decision-lessons.md) | לקחים מ-3 החלטות — מה עבד, מה השתנה, ביטויי מעבר חדשים | **לפני כל כתיבת החלטה** |
|
||||
| [`docs/corpus-analysis.md`](docs/corpus-analysis.md) | ניתוח שיטתי של 24 החלטות — מפת תוכן, דפוסי דיון תכנוני, פערים | **לפני כל כתיבת החלטה** |
|
||||
| [`docs/memory.md`](docs/memory.md) | הקשר כללי — skills, פרויקטים שהושלמו, מבנה vault | להתמצאות כללית |
|
||||
| [`skills/decision/SKILL.md`](skills/decision/SKILL.md) | מדריך סגנון מלא של דפנה — טון, מבנה, ביטויים, מתודולוגיה | **לפני כל כתיבת החלטה** |
|
||||
|
||||
@@ -107,6 +108,16 @@
|
||||
3. **"ללא כפילות"** — בלוק י (דיון) מפנה לבלוקים קודמים, לא חוזר עליהם
|
||||
4. **"טענות מקוריות בלבד"** — בלוק ז = מכתבי טענות מקוריים בלבד. השלמות → בלוק ח
|
||||
5. **ארכיטקטורת 12 בלוקים** — ראה `docs/block-schema.md`
|
||||
6. **צ'קליסט תוכן** — בלוק י מקבל צ'קליסט תוכן אוטומטי לפי סוג הערר (ראה `lessons.py: CONTENT_CHECKLISTS`)
|
||||
|
||||
## הערות יו"ר (Chair Feedback)
|
||||
|
||||
מנגנון לתיעוד הערות דפנה על טיוטות:
|
||||
- **DB**: טבלת `chair_feedback` (case_id, block_id, feedback_text, category, lesson_extracted)
|
||||
- **API**: `GET/POST /api/feedback`, `PATCH /api/feedback/{id}/resolve`
|
||||
- **MCP tools**: `record_chair_feedback`, `list_chair_feedback`
|
||||
- **UI**: דף ניהול ב-`/feedback` (ב-Next.js)
|
||||
- **קטגוריות**: missing_content, wrong_tone, wrong_structure, factual_error, style, other
|
||||
|
||||
## יו"ר: עו"ד דפנה תמיר
|
||||
- מדריך סגנון מלא: `skills/decision/SKILL.md`
|
||||
|
||||
@@ -371,6 +371,7 @@ Conclusion → Rule → Explanation → Application → Conclusion.
|
||||
- MUST: מסקנה בפתיחת הדיון (לא בסוף)
|
||||
- MUST: מענה לכל טענה שהוצגה בבלוק ז
|
||||
- MUST: ציטוט פסיקה בבלוקים ארוכים (200-600 מילים)
|
||||
- MUST: **צ'קליסט תוכן** — הפרומפט מזריק `{content_checklist}` אוטומטית לפי סוג הערר (מתוך `lessons.py: CONTENT_CHECKLISTS`). ראה `docs/corpus-analysis.md` לדפוסי תוכן לפי סוג.
|
||||
- ⚠️ **MUST NOT ("ללא כפילות"):** חזרה על עובדות/טענות מבלוקים קודמים. השתמש בהפניות: "כאמור בסעיף X לעיל", "כפי שפורט", "כפי שציינו"
|
||||
- MUST NOT: כותרות משנה (חריג: נושאים נפרדים לחלוטין)
|
||||
- Dependencies: **ALL** previous blocks (ה-ט)
|
||||
|
||||
@@ -161,3 +161,44 @@ Our skill was "over-indexed" on one case type (הכט = rejected appeal). The co
|
||||
- Created `create-decision-structure.cjs` script for generating structure DOCX
|
||||
- Key innovation from Arieli: "ההליכים בפני ועדת הערר" as separate section (Block ח)
|
||||
- "Judge Test": every block written as if administrative court judge reads cold
|
||||
|
||||
---
|
||||
|
||||
## Lessons from Systematic Corpus Analysis (24 decisions, April 2026)
|
||||
|
||||
### Source
|
||||
- All 24 proofread decisions in `/data/training/proofread/`
|
||||
- Full analysis: [`docs/corpus-analysis.md`](corpus-analysis.md)
|
||||
- Date: April 2026
|
||||
|
||||
### 12. System Learned Style but Not Substantive Content
|
||||
- **Problem:** Dafna reviewed Kiryat Yearim draft and noted missing planning discussion in block-yod
|
||||
- **Root cause:** The block-yod prompt taught CREAC methodology and "answer all claims" but never said "in licensing cases, include comprehensive planning discussion"
|
||||
- **Fix:** Content checklists added to `lessons.py` (`CONTENT_CHECKLISTS`), injected into block-yod prompt via `{content_checklist}`
|
||||
- **Applied to:** `lessons.py`, `block_writer.py`
|
||||
|
||||
### 13. Corpus Composition — All Licensing, No Betterment Levy
|
||||
- All 24 training decisions are licensing/construction (1xxx)
|
||||
- Zero betterment levy (8xxx) decisions in corpus
|
||||
- Not a current priority gap — focusing on licensing first
|
||||
|
||||
### 14. Planning Discussion Patterns in Licensing Decisions
|
||||
- **Always present** when the appeal reaches substantive planning questions
|
||||
- **Never present** when the appeal is purely jurisdictional or property-based
|
||||
- **Structure**: broad planning context → direct plan provision citations (200-600 words) → application to specific case → planning conclusion
|
||||
- **Deepest planning**: פרומר (pure plan interpretation), לבנון (height/building appendix), בית הכרם (multi-plan TAMA 38)
|
||||
- **No planning**: טלי-אביב (property only), גבאי (jurisdiction only)
|
||||
|
||||
### 15. Five Appeal Subtypes Identified (Not Just Three)
|
||||
Licensing appeals are not homogeneous — the discussion structure varies significantly:
|
||||
1. **Substantive licensing** — full planning discussion + legal analysis (majority of cases)
|
||||
2. **Threshold/jurisdiction** — legal analysis only, no planning
|
||||
3. **Property-focused** — תימוכין קנייניים, minimal planning
|
||||
4. **TAMA 38** — balancing public interest + planning + neighbor impact
|
||||
5. **Deviant use (שימוש חורג)** — deep plan interpretation across multiple plans
|
||||
|
||||
### 16. Chair Feedback System Established
|
||||
- DB table `chair_feedback` records Dafna's comments on drafts
|
||||
- Categories: missing_content, wrong_tone, wrong_structure, factual_error, style, other
|
||||
- MCP tools + UI page for recording and reviewing feedback
|
||||
- First entry: Kiryat Yearim — missing planning discussion (2026-04-12)
|
||||
|
||||
@@ -499,3 +499,39 @@ description: This skill should be used when writing legal decisions (החלטו
|
||||
| תיבות תמונה | מסגרת עם shading אפור בהיר (fill: "F0F0F0"), טקסט "📷 תמונה: [תיאור]" | ShadingType.CLEAR |
|
||||
| חתימות | טבלה ללא גבולות (`visuallyRightToLeft: true`), 2 טורים | כמו בתבנית ב-create-legal-doc.js |
|
||||
| כותרת מוסדית | טבלה ללא גבולות, 2 טורים: ימין=מוסד, שמאל=מספרי תיק | `visuallyRightToLeft: true` |
|
||||
|
||||
|
||||
## 12. צ'קליסט תוכן לפי סוג ערר
|
||||
|
||||
> נוסף אפריל 2026 בעקבות ניתוח שיטתי של 24 החלטות. ראה: `docs/corpus-analysis.md`
|
||||
|
||||
הפרומפט של בלוק י מקבל **צ'קליסט תוכן** אוטומטי לפי סוג הערר (`lessons.py: CONTENT_CHECKLISTS`). זה מבטיח שהדיון יכסה את הנושאים הנדרשים — לא רק סגנון ומתודולוגיה, אלא תוכן ענייני.
|
||||
|
||||
### 12.1 חמישה תת-סוגי רישוי (לא שלושה)
|
||||
ניתוח הקורפוס חשף שלתיקי רישוי יש 5 תת-סוגים שונים מבחינת מבנה הדיון:
|
||||
|
||||
| תת-סוג | מה בדיון | דוגמאות |
|
||||
|---------|---------|---------|
|
||||
| **רישוי מהותי** | דיון תכנוני מקיף + משפטי | רוב ההחלטות |
|
||||
| **סף/סמכות** | משפטי בלבד, ללא תכנון | גבאי, ירושלים שקופה |
|
||||
| **קנייני** | תימוכין קנייניים, מינימום תכנון | טלי-אביב, הראל 1043 |
|
||||
| **תמ"א 38** | איזון אינטרסים + תכנון + שכנות | בית הכרם |
|
||||
| **שימוש חורג** | פרשנות תכניות מרובות | תורן |
|
||||
|
||||
### 12.2 דיון תכנוני — מתי ואיך
|
||||
**מתי חובה:** כשהערר מגיע לדיון מהותי (לא סף/סמכות, לא קנייני טהור).
|
||||
|
||||
**מבנה טיפוסי (מהקורפוס):**
|
||||
1. הקשר תכנוני רחב — תכניות חלות, ייעוד, סביבה (2-8 סעיפים)
|
||||
2. ציטוט ישיר מהוראות תכנית — בלוקים של 200-600 מילים עם "הדגשת הח"מ"
|
||||
3. יישום על המקרה — הוראה → עובדה → מסקנה
|
||||
4. מסקנה תכנונית — תואם/סוטה, מוצדק/לא
|
||||
|
||||
**נושאים שמופיעים בתדירות גבוהה:**
|
||||
- חניה (8/24 החלטות) — הנושא התכנוני הנפוץ ביותר, עומק של 5-15 סעיפים
|
||||
- קווי בניין (7/24) — כולל ניתוח סטייה ניכרת
|
||||
- ניתוח הוראות תכנית (18/24) — כמעט תמיד
|
||||
- פגיעה בשכנים (5/24) — צל, פרטיות, רעש
|
||||
|
||||
### 12.3 הערות יו"ר
|
||||
הערות דפנה על טיוטות מתועדות במערכת `chair_feedback` (DB + API + UI ב-`/feedback`). כל הערה מסווגת לקטגוריה ומפיקה לקח שמשפר את ההחלטות הבאות.
|
||||
|
||||
Reference in New Issue
Block a user