Add docs, scripts, skills, commands, and taskmaster config to repo
Includes: - docs/: architecture, block-schema, migration-plan, product-specification - scripts/: bidi_table, decompose-decisions, extract-claims, seed-knowledge, etc. - skill-legal-decision/: SKILL.md + references + block-schema - skill-legal-assistant/: SKILL.md - skill-legal-docx/: SKILL.md + references - .claude/commands/: bidi-table skill - .taskmaster/: task config + PRDs - .gitignore: exclude legacy/, kiryat-yearim/, node_modules/, memory/ Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
82
docs/architecture.md
Normal file
82
docs/architecture.md
Normal file
@@ -0,0 +1,82 @@
|
||||
# System Architecture — Legal Decision Assistant
|
||||
|
||||
## Components
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Nautilus Server │
|
||||
│ 158.178.131.193 │
|
||||
│ │
|
||||
│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │
|
||||
│ │ Coolify │ │ Traefik │ │ ezer-mishpati-web│ │
|
||||
│ │ (manage) │ │ (proxy) │ │ (upload UI) │ │
|
||||
│ └──────────┘ └──────────┘ └──────────────────┘ │
|
||||
│ │
|
||||
│ ┌──────────────────┐ ┌──────────────────────────┐ │
|
||||
│ │ PostgreSQL │ │ Redis │ │
|
||||
│ │ + pgvector │ │ (task queue) │ │
|
||||
│ │ (legal-ai-postgres│ │ (legal-ai-redis) │ │
|
||||
│ └──────────────────┘ └──────────────────────────┘ │
|
||||
│ │
|
||||
│ ┌──────────┐ ┌──────────┐ │
|
||||
│ │ Gitea │ │ n8n │ │
|
||||
│ │ (code) │ │ (automate│ │
|
||||
│ └──────────┘ └──────────┘ │
|
||||
│ │
|
||||
│ ┌──────────────────────────────────────────────┐ │
|
||||
│ │ Claude Code (via SSH or API) │ │
|
||||
│ │ — Skills: legal-decision, legal-docx │ │
|
||||
│ │ — MCP: postgres, n8n, cloudflare, chrome │ │
|
||||
│ └──────────────────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
|
||||
External:
|
||||
← Claude API (embeddings, analysis)
|
||||
← Cloudflare DNS (*.nautilus.marcusgroup.org)
|
||||
← User (Putty SSH / Browser)
|
||||
```
|
||||
|
||||
## Data Flow
|
||||
|
||||
```
|
||||
1. Document Upload
|
||||
User → ezer-mishpati-web → file storage → n8n trigger
|
||||
→ classify document → store metadata in PostgreSQL
|
||||
→ generate embeddings → store in pgvector
|
||||
|
||||
2. Decision Writing
|
||||
Claude Code → read source materials from DB
|
||||
→ generate structure DOCX (12 blocks)
|
||||
→ write each block with appropriate model/parameters
|
||||
→ validate against block-schema
|
||||
→ export final DOCX
|
||||
|
||||
3. Precedent Search (RAG)
|
||||
Query → generate embedding → pgvector similarity search
|
||||
→ return relevant paragraphs/decisions
|
||||
→ Claude analyzes relevance → present to user
|
||||
```
|
||||
|
||||
## Database Schema — 4 Layers
|
||||
|
||||
### Layer 1: Core
|
||||
appeals, parties, panels, documents
|
||||
|
||||
### Layer 2: Decision
|
||||
decisions, decision_blocks, decision_paragraphs, claims
|
||||
|
||||
### Layer 3: Legal Knowledge
|
||||
case_law, case_law_citations, statutory_provisions, transition_phrases, lessons_learned
|
||||
|
||||
### Layer 4: Semantic Search (RAG)
|
||||
document_embeddings, paragraph_embeddings, case_law_embeddings
|
||||
(all using pgvector vector(1536) columns)
|
||||
|
||||
## Technology Choices
|
||||
- **Database**: PostgreSQL 15 + pgvector 0.8.1
|
||||
- **Embedding model**: TBD (Claude/OpenAI ada-002/local)
|
||||
- **Automation**: n8n (workflow engine)
|
||||
- **Code repository**: Gitea (self-hosted)
|
||||
- **Deployment**: Coolify (Docker management)
|
||||
- **Proxy**: Traefik v3.6 (auto-SSL)
|
||||
- **Frontend**: ezer-mishpati-web (static HTML + API)
|
||||
125
docs/audit-report.md
Normal file
125
docs/audit-report.md
Normal file
@@ -0,0 +1,125 @@
|
||||
# דוח ביקורת תיקים — עוזר משפטי
|
||||
**תאריך:** 2 באפריל 2026
|
||||
**סורק:** Claude Code + סריקה אוטומטית של legacy vault
|
||||
|
||||
---
|
||||
|
||||
## סיכום כללי
|
||||
|
||||
| נתון | ערך |
|
||||
|------|-----|
|
||||
| סה"כ תיקים | 19 |
|
||||
| תיקים בארכיון | 16 |
|
||||
| תיקים פעילים | 3 |
|
||||
| סה"כ קבצים (ארכיון) | 319~ |
|
||||
| סה"כ קבצים (פעילים) | 125~ |
|
||||
| תיקים עם החלטה סופית | 6 |
|
||||
| תיקים עם טיוטה בלבד | 5 |
|
||||
| תיקים ללא החלטה | 8 |
|
||||
|
||||
---
|
||||
|
||||
## סטטוס תיקים
|
||||
|
||||
### תיקים עם החלטה סופית (6)
|
||||
|
||||
| תיק | מספר | סוג | תוצאה | קבצים |
|
||||
|-----|------|-----|-------|-------|
|
||||
| הכט | 1180-1181 | רישוי | דחייה | 12 |
|
||||
| אפרים אבי | 8255-25 | היטל השבחה | דחייה | 17 |
|
||||
| עומר דרוויש | 8007-24 | היטל השבחה | — | 17 |
|
||||
| אייל מבורך | 1113/25 | רישוי | — | 18 |
|
||||
| שטרית | 1128/25 | רישוי | — | 26 |
|
||||
| קרית יערים-2 | 1194/25+1199/25 | רישוי | — | 32 |
|
||||
|
||||
### תיקים עם טיוטה בלבד (5)
|
||||
|
||||
| תיק | מספר | סוג | הערות | קבצים |
|
||||
|-----|------|-----|-------|-------|
|
||||
| בית הכרם | 1126/25+1141/25 | תמ"א 38 | טיוטה 9 (סופית למעשה) | 31 |
|
||||
| אזורים | 8141-23 | היטל השבחה | טיוטה | 8 |
|
||||
| אבו זאהריה | 8107-25 | היטל השבחה | טיוטה | 32 |
|
||||
| רמת שלמה | 9005-24 | פיצויים ס' 197 | טיוטות | 35 |
|
||||
| קרית יערים-1 | 1130/25 | רישוי | טיוטת מבנה | 70+ |
|
||||
|
||||
### תיקים ללא החלטה (8)
|
||||
|
||||
| תיק | מספר | סוג | קבצים |
|
||||
|-----|------|-----|-------|
|
||||
| משכן אליהו | 8047-24 | היטל השבחה | 15 |
|
||||
| ערר 8070-25 | 8070-25 | היטל השבחה | 24 |
|
||||
| מרפסות שירות | 8136-24 | היטל השבחה | 13 |
|
||||
| רישוי 1184-25 | 1184/25 | רישוי | 8 |
|
||||
| ערר 1195-25 | 1195-25 | רישוי | 6 |
|
||||
| ערר 1200-25 | 1200/25 | רישוי | 6 |
|
||||
| בלוי | 1107/06/25 | תמ"א 38 | 25 |
|
||||
| תחכמוני | 8027-25 | היטל השבחה | 23 |
|
||||
|
||||
---
|
||||
|
||||
## התפלגות לפי סוג ערר
|
||||
|
||||
| סוג | כמות | עם החלטה | ללא החלטה |
|
||||
|-----|------|---------|----------|
|
||||
| רישוי ובנייה (1xxx) | 9 | 4 | 5 |
|
||||
| היטל השבחה (8xxx) | 8 | 2 | 6 |
|
||||
| תמ"א 38 | 2 | 0 | 2 |
|
||||
| פיצויים ס' 197 (9xxx) | 1 | 0 | 1 |
|
||||
|
||||
---
|
||||
|
||||
## התפלגות סוגי מסמכים (ארכיון)
|
||||
|
||||
| סוג מסמך | כמות | הערות |
|
||||
|----------|------|-------|
|
||||
| החלטות (סופיות + ביניים + טיוטות) | 70~ | כולל כל הגרסאות |
|
||||
| כתבי ערר | 49~ | חלקם כפולים (PDF + MD) |
|
||||
| כתבי תשובה / תגובות | 47~ | כולל השלמות טיעון |
|
||||
| פרוטוקולים ותמלולים | 23~ | ועדה מקומית + ערר |
|
||||
| שומות | 17~ | בעיקר תיקי היטל השבחה |
|
||||
| חוות דעת מומחים | 5~ | אדריכל, מהנדס, רעש |
|
||||
| תכניות | 1~ | — |
|
||||
| הגשות | 2~ | — |
|
||||
| אחר (ניתוחים, קטלוגים, MD) | 106~ | — |
|
||||
|
||||
---
|
||||
|
||||
## פערים שזוהו
|
||||
|
||||
### פערים קריטיים
|
||||
1. **בית הכרם** — מסווג כ"טיוטה" אבל למעשה טיוטה 9 היא הגרסה הסופית. צריך לעדכן סטטוס ל-final
|
||||
2. **קרית יערים-2** — יש החלטה מוגמרת ב-01_Projects אבל לא ב-04_Archive. צריך לוודא שזו הגרסה הסופית
|
||||
|
||||
### פערים במטאדטה
|
||||
3. **הכט, הכרם** — חסרים שמות צדדים ב-DB (appellants/respondents ריקים)
|
||||
4. **8 תיקים** — חסרים תאריכי דיון (hearing_date) ותאריכי החלטה (decision_date)
|
||||
5. **כל התיקים** — חסר permit_number
|
||||
|
||||
### כפילויות
|
||||
6. **רוב המסמכים קיימים בשני פורמטים** — PDF + MD. ה-MD הוא טקסט מחולץ. עדיף לייבא את שני הפורמטים: PDF כקובץ מקורי, MD כטקסט מחולץ מוכן
|
||||
|
||||
### מסמכים גדולים (דורשים תשומת לב ב-OCR)
|
||||
7. כתב ערר אזורים 8141-23 — 9.2MB
|
||||
8. כתב ערר מבורך 1113-25 — 9.3MB
|
||||
9. כתב ערר קובר (קרית יערים-1) — 8.6MB
|
||||
10. חוות דעת אדריכל רמת שלמה — 7.4MB
|
||||
|
||||
---
|
||||
|
||||
## המלצות לשלב הבא
|
||||
|
||||
### עדיפות ראשונה — תיקים עם החלטה סופית
|
||||
לייבא קודם את 6 התיקים עם החלטות סופיות + בית הכרם (טיוטה 9):
|
||||
1. הכט 1180-1181
|
||||
2. בית הכרם 1126/25
|
||||
3. אפרים אבי 8255-25
|
||||
4. עומר דרוויש 8007-24
|
||||
5. אייל מבורך 1113/25
|
||||
6. שטרית 1128/25
|
||||
7. קרית יערים-2 1194/25+1199/25
|
||||
|
||||
### עדיפות שנייה — ניצול קבצי MD
|
||||
רוב המסמכים כבר מחולצים ל-Markdown. זה חוסך OCR — אפשר לייבא את ה-MD ישירות כ-extracted_text
|
||||
|
||||
### עדיפות שלישית — עדכון מטאדטה
|
||||
להשלים שמות צדדים, תאריכים, ומספרי היתר לכל 19 התיקים
|
||||
574
docs/block-schema.md
Normal file
574
docs/block-schema.md
Normal file
@@ -0,0 +1,574 @@
|
||||
# Block Schema — ארכיטקטורת מסמך החלטת ועדת ערר
|
||||
|
||||
מסמך זה מגדיר את המבנה הפורמלי של החלטת ועדת ערר לתכנון ובניה. הוא משמש כמקור סמכותי להגדרת בלוקים, משקלות, פרמטרי עיבוד, וכללי ולידציה.
|
||||
|
||||
**הפניה:** SKILL.md סעיפים 11-12 מכילים סיכום מהיר והנחיות תהליך. מסמך זה מכיל את ההגדרות המלאות.
|
||||
|
||||
---
|
||||
|
||||
## 1. יסודות תיאורטיים
|
||||
|
||||
ארכיטקטורת המסמך מבוססת על שילוב של ארבעה frameworks מוכרים:
|
||||
|
||||
### CREAC — מתודולוגיית כתיבה משפטית
|
||||
Conclusion → Rule → Explanation → Application → Conclusion.
|
||||
מקור: Columbia Law School, Legal Writing methodology.
|
||||
**מיפוי:** חל על בלוק י (דיון) ובלוק יא (סיכום). בלוק י פותח במסקנה (C), מציג כלל משפטי (R), מסביר באמצעות פסיקה (E), מיישם על העובדות (A), וחוזר למסקנה (C). בלוק יא = C אחרון בלבד.
|
||||
|
||||
### Federal Judicial Center — Judicial Writing Manual
|
||||
מגדיר תפקוד פונקציונלי לכל חלק בהחלטה שיפוטית:
|
||||
- **Orientation** (אוריינטציה) — מי, מה, איפה → בלוקים א-ה
|
||||
- **Framing** (מסגור) — הקשר עובדתי ותכנוני → בלוק ו
|
||||
- **Argumentation** (טיעון) — עמדות הצדדים → בלוק ז
|
||||
- **Procedural record** (תיעוד הליכי) — מה עשינו → בלוק ח
|
||||
- **Deliberation** (דיון) — ניתוח משפטי → בלוקים ט-י
|
||||
- **Disposition** (החלטה) — תוצאה אופרטיבית → בלוק יא
|
||||
|
||||
### DITA — Darwin Information Typing Architecture
|
||||
סטנדרט OASIS להגדרת סוגי תוכן מובנים. מספק:
|
||||
- **Content model** — אילו אלמנטים מותרים בכל בלוק
|
||||
- **Constraints** — מה אסור (חשוב יותר ממה שמותר)
|
||||
- **Specialization** — ירושה מסוג בסיסי עם התאמות
|
||||
- **Relationships** — תלויות בין בלוקים
|
||||
|
||||
### Akoma Ntoso / LegalDocumentML
|
||||
סטנדרט OASIS בינלאומי למסמכים משפטיים מובנים (UN/DESA). מספק:
|
||||
- **Semantic mapping** — כל בלוק ממופה לרכיב מוכר בסטנדרט
|
||||
- **Document class** — "judgment" (פסק דין / החלטה)
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 2. הגדרות בלוקים
|
||||
|
||||
### Block א: כותרת מוסדית / Institutional Header
|
||||
|
||||
**ID:** `block-alef`
|
||||
**Akoma Ntoso:** `meta > identification`
|
||||
**CREAC role:** none
|
||||
**Functional purpose (JWM):** Orientation — מזהה את המוסד, התיק והגורם המחליט.
|
||||
|
||||
**Content model:**
|
||||
- Types: template-field
|
||||
- Elements: טבלה 2 טורים (מוסד | מספרי תיק)
|
||||
- Sources: מערכת ניהול תיקים
|
||||
|
||||
**Constraints:**
|
||||
- MUST: שם מוסד, מספר תיק, מספר תכנית/בקשה
|
||||
- MUST NOT: תוכן מהותי כלשהו
|
||||
- Dependencies: none
|
||||
|
||||
**Weight:** 1% (קבוע, לא משתנה בין סוגי עררים)
|
||||
|
||||
**Processing:**
|
||||
- Generation type: template-fill
|
||||
- Temperature: 0 | Thinking: off | Effort: min | Model: script
|
||||
|
||||
|
||||
### Block ב: הרכב הוועדה / Panel Composition
|
||||
|
||||
**ID:** `block-bet`
|
||||
**Akoma Ntoso:** `meta > references > TLCPerson`
|
||||
**CREAC role:** none
|
||||
**Functional purpose (JWM):** Orientation — מזהה את ההרכב המחליט. חשוב לביקורת שיפוטית (הרכב כשיר).
|
||||
|
||||
**Content model:**
|
||||
- Types: template-field
|
||||
- Elements: "בפני:" + יו"ר + חברים
|
||||
- Sources: מערכת ניהול
|
||||
|
||||
**Constraints:**
|
||||
- MUST: יו"ר + לפחות חבר אחד
|
||||
- MUST NOT: תוכן מהותי
|
||||
- Dependencies: none
|
||||
|
||||
**Weight:** 1% (קבוע)
|
||||
|
||||
**Processing:**
|
||||
- Generation type: template-fill
|
||||
- Temperature: 0 | Thinking: off | Effort: min | Model: script
|
||||
|
||||
|
||||
### Block ג: צדדים / Parties
|
||||
|
||||
**ID:** `block-gimel`
|
||||
**Akoma Ntoso:** `meta > references > TLCPerson` (appellants, respondents)
|
||||
**CREAC role:** none
|
||||
**Functional purpose (JWM):** Orientation — מזהה את הצדדים וב"כ. מגדיר את מסגרת הדיון.
|
||||
|
||||
**Content model:**
|
||||
- Types: template-field
|
||||
- Elements: עוררים + "נגד" + משיבים + ב"כ
|
||||
- Sources: כתב ערר, כתב תשובה
|
||||
|
||||
**Constraints:**
|
||||
- MUST: שם כל צד, "נגד" כמפריד
|
||||
- MUST NOT: תוכן מהותי, תיאור הערר
|
||||
- Dependencies: none
|
||||
|
||||
**Weight:** 1% (קבוע)
|
||||
|
||||
**Processing:**
|
||||
- Generation type: template-fill
|
||||
- Temperature: 0 | Thinking: off | Effort: min | Model: script
|
||||
|
||||
|
||||
### Block ד: כותרת "החלטה" / Decision Title
|
||||
|
||||
**ID:** `block-dalet`
|
||||
**Akoma Ntoso:** `body > judgment > header`
|
||||
**CREAC role:** none
|
||||
**Functional purpose (JWM):** Orientation — סימון פורמלי של תחילת ההחלטה.
|
||||
|
||||
**Content model:**
|
||||
- Types: template-field
|
||||
- Elements: מילה אחת: "החלטה"
|
||||
- Sources: none
|
||||
|
||||
**Constraints:**
|
||||
- MUST: David 16pt, bold, מרכז
|
||||
- Dependencies: none
|
||||
|
||||
**Weight:** 0% (שורה אחת)
|
||||
|
||||
**Processing:**
|
||||
- Generation type: template-fill
|
||||
- Temperature: 0 | Thinking: off | Effort: min | Model: script
|
||||
|
||||
|
||||
### Block ה: פתיחה / Opening
|
||||
|
||||
**ID:** `block-he`
|
||||
**Akoma Ntoso:** `body > judgment > introduction`
|
||||
**CREAC role:** C (מסקנה ראשונית — הצגת מה לפנינו)
|
||||
**Functional purpose (JWM):** Orientation — מכוון את הקורא למהות הערר במשפט אחד. מגדיר "להלן" מרכזיים.
|
||||
|
||||
**Content model:**
|
||||
- Types: narrative (1-2 סעיפים)
|
||||
- Elements: numbered-para עם הגדרות "להלן"
|
||||
- Sources: כתב ערר, החלטת ועדה מקומית
|
||||
|
||||
**Constraints:**
|
||||
- MUST: "לפנינו...", הגדרת הוועדה המקומית, הגדרת התכנית/הבקשה, הגדרת המגרש
|
||||
- MUST NOT: ניתוח, ערכי שיפוט, ציטוטים מצדדים
|
||||
- Dependencies: block-gimel (שמות צדדים להגדרות)
|
||||
|
||||
**Weight:** 1% (קבוע — 1-2 סעיפים)
|
||||
|
||||
**Processing:**
|
||||
- Generation type: paraphrase
|
||||
- Temperature: 0.2 | Thinking: low | Effort: low | Model: sonnet
|
||||
|
||||
|
||||
### Block ו: רקע עובדתי / Factual Background ("פתח דבר")
|
||||
|
||||
**ID:** `block-vav`
|
||||
**Akoma Ntoso:** `body > judgment > background`
|
||||
**CREAC role:** none (עובדות בלבד, לא ניתוח)
|
||||
**Functional purpose (JWM):** Framing — מספק את התשתית העובדתית שעליה נבנה הדיון. השופט חייב להבין את המציאות בשטח לפני שקורא טענות.
|
||||
|
||||
**Content model:**
|
||||
- Types: narrative, citation-block, image-placeholder
|
||||
- Elements: numbered-para, blockquote (ציטוט מפרוטוקול), image-box
|
||||
- Sources: כתבי טענות, תשריטים, פרוטוקולים, החלטות קודמות, GIS
|
||||
|
||||
**סדר תוכן פנימי:**
|
||||
1. מקרקעין — מיקום, שטח, מאפיינים
|
||||
2. סביבת מקרקעין — בנייה סמוכה, אופי
|
||||
3. 📷 תמונה: מיקום GIS
|
||||
4. היסטוריה תכנונית — תכניות, החלטות (עובדות יבשות בלבד)
|
||||
5. מהות הבקשה/תכנית
|
||||
6. 📷 תמונה: תשריט
|
||||
7. ציטוט מפרוטוקול ועדה מקומית
|
||||
8. החלטת הוועדה + תנאים
|
||||
9. 📷 תמונה: צילום אוויר (אופציונלי)
|
||||
10. הגשת הערר
|
||||
|
||||
**Constraints:**
|
||||
- MUST: מקרקעין, מהות הבקשה, החלטת הוועדה, הגשת הערר
|
||||
- MUST: לפחות 2 תמונות (מיקום + תשריט)
|
||||
- MUST: ציטוט מפרוטוקול הוועדה המקומית
|
||||
- ⚠️ **MUST NOT ("רקע ניטרלי"):** ציטוטים ישירים מצדדים, מילות ערך/שיפוט ("חריג", "חטא", "בעייתי"). החלטות קודמות = עובדה יבשה ("ביום X נדחתה תכנית Y"), ללא נימוקים וציטוטים מהן.
|
||||
- Dependencies: block-he (הגדרות "להלן")
|
||||
|
||||
**Weight:**
|
||||
|
||||
| סוג ערר | משקל | הערות |
|
||||
|---------|------|-------|
|
||||
| רישוי — דחייה | 15-25% | רקע מפורט עם הקשר תכנוני |
|
||||
| רישוי — קבלה | 30-40% | כולל ציטוט מפרוטוקול |
|
||||
| רישוי — קבלה חלקית | 25-35% | כולל ציטוט מפרוטוקול |
|
||||
| היטל השבחה | 6-18% | רקע מצומצם |
|
||||
|
||||
**Weight methodology:**
|
||||
- Communicative weight (40%): גבוה — מספק את "התמונה" לשופט שלא מכיר את התיק
|
||||
- Reader attention (20%): בינוני-גבוה — primacy effect, הקורא קשוב בהתחלה
|
||||
- Judicial review (25%): גבוה — שופט בודק שהעובדות מלאות ומדויקות
|
||||
- Empirical (15%): מבוסס על מדידת החלטות דפנה (3.2 ב-SKILL.md)
|
||||
|
||||
**Processing:**
|
||||
- Generation type: reproduction (העתקה נאמנה ממקורות)
|
||||
- Cognitive complexity: lookup (ארגון, לא ניתוח)
|
||||
- Accuracy: high-precision
|
||||
- Temperature: 0 | Thinking: off | Effort: low | Model: sonnet
|
||||
|
||||
|
||||
### Block ז: טענות הצדדים / Parties' Claims
|
||||
|
||||
**ID:** `block-zayin`
|
||||
**Akoma Ntoso:** `body > judgment > arguments`
|
||||
**CREAC role:** none (הצגת טענות, לא ניתוח)
|
||||
**Functional purpose (JWM):** Argumentation — מציג את עמדות הצדדים בנאמנות, כך שהקורא יבין את המחלוקת לפני שקורא את ההכרעה.
|
||||
|
||||
**Content model:**
|
||||
- Types: narrative
|
||||
- Elements: section-heading ("תמצית טענות הצדדים"), sub-headings (לכל צד), numbered-para
|
||||
- Sources: כתב ערר, כתב תשובה — **כתבי טענות מקוריים בלבד** (לא השלמות טיעון)
|
||||
|
||||
**סדר קבוע:**
|
||||
1. כותרת: "תמצית טענות הצדדים"
|
||||
2. "טענות העוררים" (אם כמה עוררים — תתי-כותרות לכל אחד)
|
||||
3. "עמדת הוועדה המקומית"
|
||||
4. "עמדת מבקשי ההיתר" / "עמדת מגישי התכנית"
|
||||
|
||||
**Constraints:**
|
||||
- MUST: כל טענה בסעיף נפרד, גוף שלישי ("העורר טוען כי...")
|
||||
- MUST: כל צד בפרק נפרד, סדר קבוע
|
||||
- MUST NOT: ניתוח, מסקנות, הערכת הוועדה ("טענה זו חלשה...")
|
||||
- MUST NOT: תוכן מהשלמות טיעון (→ block-chet)
|
||||
- Dependencies: block-vav (מספור רציף)
|
||||
|
||||
**Weight:**
|
||||
|
||||
| סוג ערר | משקל | הערות |
|
||||
|---------|------|-------|
|
||||
| רישוי — דחייה | 30-40% | טענות מפורטות |
|
||||
| רישוי — קבלה | 20-30% | כולל השלמות |
|
||||
| רישוי — קבלה חלקית | 25-30% | |
|
||||
| היטל השבחה | 13-25% | |
|
||||
|
||||
**Weight methodology:**
|
||||
- Communicative weight (40%): בינוני — הצגה, לא הכרעה
|
||||
- Reader attention (20%): נמוך-בינוני — scanning attention, הקורא מחפש טענות ספציפיות
|
||||
- Judicial review (25%): גבוה — שופט בודק ש"נשמעו כל הצדדים"
|
||||
- Empirical (15%): מבוסס על מדידת החלטות דפנה
|
||||
|
||||
**Processing:**
|
||||
- Generation type: paraphrase (סיכום נאמן בשפה של דפנה)
|
||||
- Cognitive complexity: medium-synthesis (קיבוץ וסידור טענות)
|
||||
- Accuracy: high-precision (לא לפספס טענה, לא לעוות)
|
||||
- Temperature: 0.1 | Thinking: low | Effort: medium | Model: sonnet
|
||||
|
||||
|
||||
### Block ח: הליכים בפני ועדת הערר / Proceedings
|
||||
|
||||
**ID:** `block-chet`
|
||||
**Akoma Ntoso:** `body > judgment > proceedings` (custom extension)
|
||||
**CREAC role:** none (תיעוד, לא ניתוח)
|
||||
**Functional purpose (JWM):** Procedural record — מתעד שהוועדה פעלה כדין ונתנה מלוא יום בבית דין. קריטי ל"מבחן השופט" — שופט בעתמ"ם בודק שהצדדים קיבלו הזדמנות הוגנת.
|
||||
|
||||
**Content model:**
|
||||
- Types: narrative, image-placeholder
|
||||
- Elements: section-heading ("ההליכים בפני ועדת הערר"), numbered-para, image-box
|
||||
- Sources: פרוטוקול דיון, תמונות סיור, החלטות ביניים, השלמות טיעון
|
||||
|
||||
**סדר כרונולוגי:**
|
||||
1. דיון — תאריך, נוכחים
|
||||
2. סיור — תאריך, תיאור
|
||||
3. 📷 תמונה: צילומים מהסיור
|
||||
4. השלמות טיעון — עם תוכן מפורט (כל השלמה = סעיף נפרד)
|
||||
5. החלטות ביניים
|
||||
6. תגובות לתגובות — כרונולוגי
|
||||
7. 📷 תמונה: הדמיות/חתכים (אם צורפו)
|
||||
8. עררים מקבילים (אם יש)
|
||||
|
||||
**Constraints:**
|
||||
- MUST: תאריכים מדויקים, כרונולוגיה ברורה
|
||||
- MUST: תוכן השלמות טיעון מפורט — כל השלמה בסעיף נפרד עם תמצית תוכן
|
||||
- MUST NOT: ניתוח או הערכה של ההשלמות ("טענה חזקה/חלשה")
|
||||
- Dependencies: block-zayin (מספור רציף)
|
||||
- References: block-zayin (הפניה לטענות מקוריות כשיש חפיפה)
|
||||
|
||||
**Weight:**
|
||||
|
||||
| סוג ערר | משקל | הערות |
|
||||
|---------|------|-------|
|
||||
| ערר פשוט (ללא השלמות) | 3-5% | דיון + סיור בלבד |
|
||||
| ערר מורכב (השלמות רבות) | 8-15% | כמו אריאלי: 31 סעיפים |
|
||||
| היטל השבחה | 2-4% | בדרך כלל מינימלי |
|
||||
|
||||
**Weight methodology:**
|
||||
- Communicative weight (40%): נמוך-בינוני — תיעוד, לא הכרעה
|
||||
- Reader attention (20%): נמוך — scanning, אלא אם יש ממצאים חדשים מסיור/השלמות
|
||||
- Judicial review (25%): **גבוה מאוד** — שופט בודק שנתנו procedural fairness
|
||||
- Empirical (15%): מגוון רחב — תלוי בכמות ההשלמות
|
||||
|
||||
**Processing:**
|
||||
- Generation type: reproduction + paraphrase (תאריכים מדויקים + תמצית תוכן)
|
||||
- Cognitive complexity: low (סידור כרונולוגי)
|
||||
- Accuracy: high-precision (תאריכים, שמות מסמכים)
|
||||
- Temperature: 0 | Thinking: off | Effort: low | Model: sonnet
|
||||
|
||||
|
||||
### Block ט: תכניות חלות / Applicable Plans (אופציונלי)
|
||||
|
||||
**ID:** `block-tet`
|
||||
**Akoma Ntoso:** `body > judgment > motivation > background` (extended)
|
||||
**CREAC role:** R (Rule — הצגת הכללים המשפטיים/תכנוניים)
|
||||
**Functional purpose (JWM):** Deliberation (preliminary) — מציג את המסגרת הנורמטיבית שלאורה ייבחנו הטענות. בלוק גשר בין עובדות לניתוח.
|
||||
|
||||
**Content model:**
|
||||
- Types: narrative, citation-block
|
||||
- Elements: section-heading, numbered-para, blockquote (ציטוט מהוראות תכנית)
|
||||
- Sources: הוראות תכנית (PDF), נספחי בינוי, החלטות מרכזות
|
||||
|
||||
**Constraints:**
|
||||
- MUST: ציטוט ישיר מהוראות תכנית עם הדגשת (bold) מילים מכריעות
|
||||
- MUST NOT: ניתוח מעמיק (→ block-yod), הכרעה בין פרשנויות
|
||||
- Dependencies: block-chet (מספור), block-vav (הגדרות תכניות)
|
||||
- Condition: **אופציונלי** — רק כשיש מורכבות תכנונית (תכניות סותרות, תמ"א 38 + שימור, פרשנות)
|
||||
|
||||
**Weight:**
|
||||
|
||||
| מתי קיים | משקל |
|
||||
|----------|------|
|
||||
| תמ"א 38 + שימור | 8-12% |
|
||||
| פרשנות תכנית | 5-10% |
|
||||
| לא קיים | 0% |
|
||||
|
||||
**Weight methodology:**
|
||||
- Communicative weight (40%): בינוני — הנחת תשתית נורמטיבית
|
||||
- Reader attention (20%): נמוך — טכני, אלא אם פרשנות שנויה במחלוקת
|
||||
- Judicial review (25%): בינוני — שופט בודק שהוועדה הבינה את הדין
|
||||
- Empirical (15%): אריאלי — 14 סעיפים; בית הכרם — משולב בדיון
|
||||
|
||||
**Processing:**
|
||||
- Generation type: guided-synthesis (ציטוט + ניתוח ראשוני)
|
||||
- Cognitive complexity: medium (פרשנות טקסט משפטי)
|
||||
- Accuracy: precision + interpretation
|
||||
- Temperature: 0.2 | Thinking: medium | Effort: medium | Model: opus
|
||||
|
||||
|
||||
### Block י: דיון והכרעה / Discussion and Decision
|
||||
|
||||
**ID:** `block-yod`
|
||||
**Akoma Ntoso:** `body > judgment > motivation`
|
||||
**CREAC role:** **full-CREAC** — C (מסקנה בפתיחה) → R (כלל משפטי) → E (ציטוט פסיקה) → A (יישום על העובדות) → C (מסקנת ביניים)
|
||||
**Functional purpose (JWM):** Deliberation — ליבת ההחלטה. כאן הוועדה מנתחת, מאזנת, ומכריעה. זהו ה-ratio decidendi.
|
||||
|
||||
**Content model:**
|
||||
- Types: narrative, citation-block, image-placeholder
|
||||
- Elements: numbered-para (אסה רציפה ללא כותרות משנה), blockquote (ציטוטי פסיקה ותכנית), image-box
|
||||
- Sources: **כל** הבלוקים הקודמים + פסיקה + skill
|
||||
|
||||
**מבנה פנימי (לפי סוג ערר — ראה SKILL.md סעיף 7.3):**
|
||||
- דחייה: שכבות הגנה (concentric circles)
|
||||
- קבלה: נימוק-נימוק
|
||||
- קבלה חלקית: מיפוי מתחים + ניתוח נושאי
|
||||
- היטל השבחה: פתיחה ישירה עם מסקנה
|
||||
|
||||
**Constraints:**
|
||||
- MUST: מסקנה בפתיחת הדיון (לא בסוף)
|
||||
- MUST: מענה לכל טענה שהוצגה בבלוק ז
|
||||
- MUST: ציטוט פסיקה בבלוקים ארוכים (200-600 מילים)
|
||||
- ⚠️ **MUST NOT ("ללא כפילות"):** חזרה על עובדות/טענות מבלוקים קודמים. השתמש בהפניות: "כאמור בסעיף X לעיל", "כפי שפורט", "כפי שציינו"
|
||||
- MUST NOT: כותרות משנה (חריג: נושאים נפרדים לחלוטין)
|
||||
- Dependencies: **ALL** previous blocks (ה-ט)
|
||||
|
||||
**Weight:**
|
||||
|
||||
| סוג ערר | משקל | הערות |
|
||||
|---------|------|-------|
|
||||
| רישוי — דחייה | 37-50% | פתיחה רחבה + שכבות |
|
||||
| רישוי — קבלה | 35-45% | נימוק-נימוק |
|
||||
| רישוי — קבלה חלקית | 40-47% | מיפוי מתחים + ניתוח נושאי |
|
||||
| היטל השבחה | 32-48% | ציטוטי פסיקה מרובים |
|
||||
|
||||
**Weight methodology:**
|
||||
- Communicative weight (40%): **מקסימלי** — זהו ה-ratio decidendi, תכלית ההחלטה
|
||||
- Reader attention (20%): **גבוה** — deep reading, הקורא מחפש את הנימוקים
|
||||
- Judicial review (25%): **מקסימלי** — שופט בוחן סבירות, מידתיות, התייחסות לטענות
|
||||
- Empirical (15%): 35-50% באופן עקבי בכל החלטות דפנה
|
||||
|
||||
**Processing:**
|
||||
- Generation type: **rhetorical-construction** (בניית טיעון, איזון, רטוריקה)
|
||||
- Cognitive complexity: **high-reasoning** (CREAC מלא, שכבות, חידוד)
|
||||
- Accuracy: **precision + creativity** (ניתוח מדויק + ביטוי אלגנטי)
|
||||
- Temperature: **0.4** | Thinking: **max (budget 16K+)** | Effort: **max** | Model: **opus בלבד**
|
||||
|
||||
|
||||
### Block יא: סיכום / סוף דבר / Summary
|
||||
|
||||
**ID:** `block-yod-alef`
|
||||
**Akoma Ntoso:** `body > judgment > decision`
|
||||
**CREAC role:** C (Conclusion אחרון — תמצית אופרטיבית)
|
||||
**Functional purpose (JWM):** Disposition — ההוראה האופרטיבית שמבצעים. זה מה שהצדדים צריכים לדעת "מה עכשיו."
|
||||
|
||||
**Content model:**
|
||||
- Types: narrative
|
||||
- Elements: section-heading ("סיכום"/"סוף דבר"), numbered-para, sub-items (א. ב. ג.)
|
||||
- Sources: block-yod (מסקנות)
|
||||
|
||||
**מבנה לפי תוצאה (ראה SKILL.md סעיף 8):**
|
||||
- דחייה: "הערר נדחה" + תתי-סעיפים + פסקה חמה (רישוי בלבד)
|
||||
- קבלה: "הערר מתקבל בכפוף ל..." + פרוזה
|
||||
- קבלה חלקית: "הערר מתקבל באופן חלקי" + 2-3 הוראות אופרטיביות
|
||||
- היטל השבחה: יבש
|
||||
|
||||
**Constraints:**
|
||||
- MUST: תוצאה ברורה (נדחה/מתקבל/מתקבל חלקית)
|
||||
- MUST NOT (בקבלה חלקית): חזרה על נימוקים — ההנמקה כבר בדיון
|
||||
- Dependencies: block-yod (מסקנות)
|
||||
|
||||
**Weight:**
|
||||
|
||||
| סוג ערר | משקל |
|
||||
|---------|------|
|
||||
| דחייה | 2-9% |
|
||||
| קבלה | 3-5% |
|
||||
| קבלה חלקית | 2-3% |
|
||||
| היטל השבחה | 3-4% |
|
||||
|
||||
**Processing:**
|
||||
- Generation type: paraphrase (עיבוד מסקנות בלוק י)
|
||||
- Cognitive complexity: low
|
||||
- Accuracy: high-precision (הוראות חייבות להיות חד-משמעיות)
|
||||
- Temperature: 0.1 | Thinking: low | Effort: low | Model: sonnet
|
||||
|
||||
|
||||
### Block יב: חתימות / Signatures
|
||||
|
||||
**ID:** `block-yod-bet`
|
||||
**Akoma Ntoso:** `conclusions > signature`
|
||||
**CREAC role:** none
|
||||
**Functional purpose (JWM):** Authentication — אישור פורמלי של ההחלטה.
|
||||
|
||||
**Content model:**
|
||||
- Types: template-field
|
||||
- Elements: "ניתנה פה אחד" + תאריך עברי/לועזי + טבלת חתימות
|
||||
- Sources: none
|
||||
|
||||
**Constraints:**
|
||||
- MUST: "ניתנה פה אחד", תאריך, יו"ר + מזכיר/ה
|
||||
- Dependencies: none
|
||||
|
||||
**Weight:** 1% (קבוע)
|
||||
|
||||
**Processing:**
|
||||
- Generation type: template-fill
|
||||
- Temperature: 0 | Thinking: off | Effort: min | Model: script
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 3. כללי גזירת פרמטרים
|
||||
|
||||
פרמטרי העיבוד נגזרים ממאפייני התוכן, לא נקבעים שרירותית:
|
||||
|
||||
### Temperature — נגזר מסוג הייצור
|
||||
|
||||
| Generation type | Temperature | נימוק |
|
||||
|----------------|-------------|-------|
|
||||
| template-fill | 0 | אין צורך בשפה — מילוי שדות |
|
||||
| reproduction | 0 | נאמנות מוחלטת למקור. אפס יצירתיות |
|
||||
| paraphrase | 0.1 | מרווח מינימלי לניסוח בשפה של דפנה |
|
||||
| guided-synthesis | 0.2 | גמישות בארגון וחיבור מקורות, לא בתוכן |
|
||||
| analytical-reasoning | 0.3-0.4 | צריך ליצור קשרים בין עקרונות משפטיים |
|
||||
| rhetorical-construction | 0.4-0.5 | טווח ביטוי רחב לכתיבה משכנעת ואלגנטית |
|
||||
|
||||
### Thinking budget — נגזר ממורכבות קוגניטיבית
|
||||
|
||||
| Cognitive task | Budget | נימוק |
|
||||
|---------------|--------|-------|
|
||||
| template-fill / lookup | off | אין צורך בחשיבה |
|
||||
| sequential-extraction | low | חילוץ מידע חד-שלבי |
|
||||
| multi-source-integration | medium | צריך להצליב מקורות |
|
||||
| legal-analysis-with-CREAC | max (16K+) | חשיבה רב-שלבית: מסקנה → כלל → הסבר → יישום |
|
||||
|
||||
### Model — נגזר מדרישת דיוק
|
||||
|
||||
| Accuracy profile | Model | נימוק |
|
||||
|-----------------|-------|-------|
|
||||
| factual-precision | sonnet | מהיר, מדויק לחילוץ עובדות |
|
||||
| precision + interpretation | opus | נדרש לפרשנות תכנית / ציטוט מובנה |
|
||||
| precision + creativity | opus | נדרש לניתוח משפטי מורכב ורטוריקה |
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 4. מתודולוגיית משקלות
|
||||
|
||||
משקל כל בלוק נקבע על ידי שקלול 4 גורמים:
|
||||
|
||||
### 4.1 Communicative Weight (40%)
|
||||
מה חלקו של הבלוק בתכלית ההחלטה? ההחלטה באה לעשות דבר אחד: להכריע במחלוקת ולנמק. בלוק י (דיון) הוא ליבת התכלית. בלוקים א-ד (כותרות) הם עטיפה.
|
||||
|
||||
### 4.2 Reader Attention Distribution (20%)
|
||||
מבוסס על מחקרי F-pattern ו-primacy/recency:
|
||||
- **פתיחה** (בלוקים ה-ו): קשב גבוה (primacy effect)
|
||||
- **אמצע** (בלוקים ז-ח): scanning — הקורא מחפש טענות ספציפיות
|
||||
- **דיון** (בלוק י): deep reading — הקורא מחפש נימוקים
|
||||
- **סיום** (בלוק יא): קשב גבוה (recency effect)
|
||||
|
||||
### 4.3 Judicial Review Requirement (25%)
|
||||
מה שופט בבית משפט לעניינים מנהליים יבדוק ("מבחן השופט"):
|
||||
- **תשתית עובדתית** (בלוק ו): מלאה ומדויקת?
|
||||
- **שמיעת צדדים** (בלוקים ז-ח): נתנו מלוא יום בבית דין?
|
||||
- **סבירות ומידתיות** (בלוק י): ההכרעה מנומקת ומאוזנת?
|
||||
- **התייחסות לטענות** (בלוק י): כל טענה קיבלה מענה?
|
||||
|
||||
### 4.4 Empirical Basis (15%)
|
||||
מבוסס על מדידה מהחלטות שפורסמו:
|
||||
- הכט 1180-1181 (דחייה, 02.2026)
|
||||
- בית הכרם 1126/25 (קבלה חלקית, 03.2026)
|
||||
- אריאלי 1078+1083 (קבלה, 03.2026)
|
||||
|
||||
המשקלות ב-SKILL.md סעיף 3.2 (יחסי הזהב) משמשים כבסיס אמפירי שאומת על ידי שלושת הגורמים האנליטיים.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 5. כללי ולידציה
|
||||
|
||||
### 5.1 סדר בלוקים
|
||||
- בלוקים חייבים להופיע בסדר א עד יב
|
||||
- בלוקים א-ה ויב נדרשים בכל החלטה
|
||||
- בלוק ט אופציונלי (רק כשיש מורכבות תכנונית)
|
||||
|
||||
### 5.2 Content Constraints
|
||||
- **רקע ניטרלי (בלוק ו):** אם סעיף מכיל ציטוט ישיר מצד או מילת שיפוט → לא שייך כאן
|
||||
- **טענות מקוריות בלבד (בלוק ז):** רק מכתבי ערר/תשובה. השלמות → בלוק ח
|
||||
- **ללא כפילות (בלוק י):** הפניה לבלוקים קודמים, לא חזרה. חריג: "נשוב על כך כי..." (חזרה מכוונת עם שכבה חדשה)
|
||||
- **הליכים ללא הערכה (בלוק ח):** תיעוד מה הוגש, לא הערכה של חוזק הטענות
|
||||
|
||||
### 5.3 Weight Compliance
|
||||
- משקל כל בלוק (ספירת מילים / סה"כ) צריך להיות בטווח המוגדר **±10%**
|
||||
- אם בלוק י < 30% → flag: דיון לא מפותח מספיק
|
||||
- אם בלוק ו > 35% → flag: רקע מנופח, בדוק שאין תוכן טענתי
|
||||
|
||||
### 5.4 Structural Integrity
|
||||
- מספור סעיפים רציף מ-1 עד הסוף, ללא איפוס בין בלוקים
|
||||
- כל הגדרת "להלן" חייבת להופיע לפני השימוש הראשון בה
|
||||
- כל טענה בבלוק ז חייבת לקבל מענה בבלוק י (ישיר או "למעלה מן הצורך")
|
||||
- כותרות פרקים: David 14pt, bold, קו תחתון, מרכז
|
||||
- כותרות משנה: David 12pt, bold, מרכז, ללא קו תחתון
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 6. גרף תלויות בין בלוקים
|
||||
|
||||
```
|
||||
א (כותרת) → עצמאי
|
||||
ב (הרכב) → עצמאי
|
||||
ג (צדדים) → עצמאי
|
||||
ד (כותרת) → עצמאי
|
||||
ה (פתיחה) → תלוי ב: ג (שמות צדדים להגדרות "להלן")
|
||||
ו (רקע) → תלוי ב: ה (הגדרות). מספור ממשיך מ-ה.
|
||||
ז (טענות) → תלוי ב: ו (מספור). מפנה ל: ה, ו (הגדרות)
|
||||
ח (הליכים) → תלוי ב: ז (מספור). מפנה ל: ז (טענות מקוריות)
|
||||
ט (תכניות) → תלוי ב: ח (מספור). אופציונלי. מפנה ל: ו (הגדרות תכניות)
|
||||
י (דיון) → תלוי ב: **כל** הבלוקים ה-ט. מפנה ל: כולם.
|
||||
יא (סיכום) → תלוי ב: י (מסקנות). מפנה ל: י בלבד.
|
||||
יב (חתימות) → עצמאי
|
||||
```
|
||||
43
docs/case-migration-tracker.md
Normal file
43
docs/case-migration-tracker.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# מעקב העברת תיקים מ-Legacy למערכת החדשה
|
||||
|
||||
נוצר: 2026-04-04
|
||||
|
||||
## תיקים עם החלטה סופית
|
||||
|
||||
| # | מספר תיק | שם | סוג | חומרי מקור | הועבר? | הערות |
|
||||
|---|----------|-----|------|------------|--------|-------|
|
||||
| 1 | 1180-1181 | הכט | רישוי | ערר(2), תשובה(3), פרוטוקול(1) | V | |
|
||||
| 2 | 1126-25 | בית הכרם תמ"א 38 | רישוי | ערר(4), תשובה(6), פרוטוקול(5) | V | |
|
||||
| 3 | 8255-25 | אפרים אבי | בל"מ | ערר(1), תשובה(1), פסיקה(2) | | |
|
||||
| 4 | 8047-24 | משכן אליהו | היטל השבחה | ערר(2), תשובה(2), פרוטוקול(2) | | |
|
||||
| 5 | 8007-24 | עומר דרוויש | שומה מכריעת | ערר(2), תשובה(2), פרוטוקול(2) | | |
|
||||
| 6 | 8141-23 | אזורים | היטל השבחה | ערר(1), תשובה(1), פרוטוקול(1) | | |
|
||||
| 7 | 9005-24 | רמת שלמה | פיצויים | ערר(4), תשובה(4), פרוטוקול(2), חוו"ד(3), פסיקה(2) | | |
|
||||
| 8 | 1113-25 | אייל מבורך | רישוי | פרוטוקול(2) | | |
|
||||
| 9 | 1128-25 | שטרית | רישוי | ערר(1), תשובה(2), פרוטוקול(1), פסיקה(3) | | |
|
||||
| 10 | 1130-25 | קרית יערים-1 | רישוי | ערר(4), תשובה(16), פרוטוקול(28) | | |
|
||||
| 11 | 1194+1199 | קרית יערים-2 | רישוי | ערר(10), תשובה(8), פרוטוקול(7) | | |
|
||||
| 12 | 1130-25 | ליבמן | רישוי | ערר(2), תשובה(6), פרוטוקול(4) | | |
|
||||
|
||||
## תיקים בטיוטה / בתהליך
|
||||
|
||||
| # | מספר תיק | שם | סוג | חומרי מקור | הועבר? | הערות |
|
||||
|---|----------|-----|------|------------|--------|-------|
|
||||
| 1 | 8107-25 | אבו זאהריה | היטל השבחה | ערר(6), תשובה(8), פרוטוקול(4) | | טיוטה + הערות נאוה |
|
||||
| 2 | 8027-25 | תחכמוני 20 | היטל השבחה | ערר(7), תשובה(1), פרוטוקול(2) | | טיוטת DOCX + תכנון מפורט |
|
||||
| 3 | 8070-25 | — | היטל השבחה | ערר(1), תשובה(2), פרוטוקול(2) | | |
|
||||
| 4 | 8136-24 | מרפסות שירות | היטל השבחה | ערר(1), תשובה(1), פרוטוקול(1) | | |
|
||||
| 5 | 1184-25 | — | רישוי | ערר(1), תשובה(2), פרוטוקול(1) | | |
|
||||
| 6 | 1195-25 | — | רישוי | ערר(1), תשובה(2) | | |
|
||||
| 7 | 1200-25 | — | רישוי | ערר(1), תשובה(2) | | |
|
||||
| 8 | 1107-25 | בלוי | רישוי | ערר(2), תשובה(4), פרוטוקול(1), פסיקה(8) | | חומר פסיקתי עשיר |
|
||||
|
||||
## סיכום
|
||||
|
||||
| מדד | כמות |
|
||||
|-----|------|
|
||||
| סה"כ תיקים | 20 |
|
||||
| עם החלטה סופית | 12 |
|
||||
| בטיוטה/תהליך | 8 |
|
||||
| הועברו | 2 |
|
||||
| ממתינים | 18 |
|
||||
148
docs/decision-block-mapping.md
Normal file
148
docs/decision-block-mapping.md
Normal file
@@ -0,0 +1,148 @@
|
||||
# מיפוי מדויק של 3 החלטות לבלוקים
|
||||
|
||||
**תאריך:** 2 באפריל 2026
|
||||
**שיטה:** קריאה מלאה מילה-במילה עם אימות ספירת מילים
|
||||
|
||||
---
|
||||
|
||||
## 1. הכט 1180-1181 (דפנה תמיר, דחייה, רישוי)
|
||||
|
||||
**מקור:** data/training/היתר בניה-בית שמש-1180+1181-החלטה.docx
|
||||
**שורות:** 105 | **מילים:** 4,433
|
||||
|
||||
| שורות | בלוק | תוכן | הערות |
|
||||
|-------|------|------|-------|
|
||||
| שורה 1 | ה — פתיחה | "לפנינו שני עררים..." הגדרות להלן | פתיחה קלאסית |
|
||||
| שורות 2-11 | ו — רקע | הבניין, התכנית, הבקשה, חתימות, התנגדויות, תקנה 37 | רקע מינימלי ~470 מילים |
|
||||
| שורה 12 | ז — כותרת | "תמצית טענות הצדדים" | — |
|
||||
| שורות 13-24 | ז — טענות עוררים | 11 טענות: המצאה, לובי, זכויות, מדרגות, חניות, עץ, רוב, סדובסקי, חזרה מחתימה, הידברות | — |
|
||||
| שורות 25-34 | ז — עמדת ועדה + משיבים | "עמדת המשיבים" → "הוועדה המקומית" (8 טענות): תואמת תכנית, רוב, היבטים תכנוניים, המצאה, חזרה, תכנית אושרה, חניות, עץ | — |
|
||||
| שורות 35-46 | ז — מבקשי היתר | 11 טענות: המצאה, חתימות, לובי, רוב, תכנית, זכויות, חניות, עץ, הידברות | — |
|
||||
| שורה 47 | י — כותרת | "דיון והכרעה" | — |
|
||||
| שורות 48-96 | י — דיון | פתיחה עם מסקנה → ס' 152 → פסיקה (נגאח, הימנותא, דסטגר, קרן-נכסים) → סטייה מתכנית → מדרגות, דלת, עץ, חניות → סמכות ועדה מקומית → פנייה לעוררת | **אין בלוק ט נפרד** — ניתוח ס' 152 והפסיקה משולב בדיון |
|
||||
| שורה 97 | יא — כותרת | "סיכום" | — |
|
||||
| שורות 98-104 | יא — סיכום | 6 תתי-סעיפים אופרטיביים: אין זכות ערר, תואמת תכנית, אין סטיה, לא נפל פגם, טענות קנייניות, עץ | — |
|
||||
| שורה 105 | יב — חתימות | "ניתנה פה אחד היום, כ"ב שבט תשפ"ו, 09 פברואר 2026" | — |
|
||||
|
||||
**בלוקים קיימים:** ה, ו, ז, י, יא, יב
|
||||
**בלוקים חסרים:** ח (הליכים), ט (תכניות — משולב בדיון)
|
||||
|
||||
---
|
||||
|
||||
## 2. בית הכרם 1126/25+1141/25 (דפנה תמיר, קבלה חלקית, רישוי)
|
||||
|
||||
**מקור:** data/uploads/ARAR-25-08-1126.docx (גרסה סופית מנבו)
|
||||
**שורות:** 183 | **מילים:** 6,249
|
||||
|
||||
| שורות | בלוק | תוכן | הערות |
|
||||
|-------|------|------|-------|
|
||||
| שורות 1-7 | — מטא-דאטה נבו | ספרות, חקיקה שאוזכרה | **לא חלק מההחלטה** |
|
||||
| שורה 8 | ה — פתיחה | "לפנינו שני עררים..." + הגדרות | — |
|
||||
| שורה 9 | ו — כותרת | "רקע" | — |
|
||||
| שורות 10-56 | ו — רקע | מקרקעין, תכניות (911, 10038, 16000), בקשה להיתר, החלטת ועדת משנה + התנגדויות (מצוטטות), תיקונים, שטחים, מרפסות, פיתוח, נגישות | רקע מפורט מאוד ~1,100 מילים. **כולל ציטוט מפרוטוקול ועדת המשנה** |
|
||||
| שורות 57-59 | ח — הליכים | דיון 9.12.2025, החלטת ביניים, השלמת טיעון 3.2.2026 | **בלוק ח קיים!** אבל קצר (3 שורות). מופיע **לפני** הטענות |
|
||||
| שורה 60 | ז — כותרת | "תמצית טענות הצדדים" | — |
|
||||
| שורות 61-76 | ז — טענות עוררים | מרכז קהילתי (ראייה אזורית, חניה, עיר גנים), תושבים (פגמי פרסום, חריגת שטחים, ס' 6.5 תמ"א 38, שימור, עצים, בור מים, חניה, פרטיות) | — |
|
||||
| שורות 77-84 | ז — עמדת ועדה מקומית | תואמת 10038, חניה (מגרש כלוא, כופר חניה), שטחים, שימור | — |
|
||||
| שורות 85-91 | ז — מבקשי היתר | היקף 126%, תואמת, צמצום 42%, חניה, שימור, ראייה אזורית | — |
|
||||
| שורה 92 | י — כותרת | "דיון והכרעה" | — |
|
||||
| שורות 93-102 | י — **מיפוי מתחים** | 6 מתחים: בית בודד, מדיניות, שימור, קווי בניין, מגרש כלוא, חריג לסביבה | **פתיחה ייחודית לקבלה חלקית** |
|
||||
| שורות 103-113 | י — ניתוח תכניות | 10038, 16000 (תכנית אב), 911, שימור, ס' 4.1.2.2(5), ס' 6.5.9 | **אין בלוק ט נפרד** — משולב בדיון |
|
||||
| שורות 114-149 | י — ניתוח נושאי | חניה (5166ב, כופר, מגרש כלוא, רכבת קלה), קווי בניין (שימור vs מרחק), מטרדי בנייה (ערר 1192/18, ערר 1156/18), עצים, בור מים | — |
|
||||
| שורות 150-177 | י — ציטוט ערר מובשוביץ + התחדשות עירונית | ציטוט נרחב (~400 מילים) מערר מובשוביץ, ספרות (גדרון ונמדר), פסיקה (לזובסקי, ערר 76/14) | — |
|
||||
| שורה 178 | יא — כותרת | "סיכום" | — |
|
||||
| שורות 179-181 | יא — סיכום | "מתקבל באופן חלקי" + 2 הוראות: בחינת מרווח, תכנית ארגון אתר | **סיכום מינימלי** — 88 מילים |
|
||||
| שורות 182-183 | — מטא-דאטה נבו | "נוסח מסמך זה כפוף..." | **לא חלק מההחלטה** |
|
||||
|
||||
**בלוקים קיימים:** ה, ו, ח (קצר, לפני טענות), ז, י, יא
|
||||
**בלוקים חסרים:** ט (משולב בדיון)
|
||||
|
||||
**ממצאים ייחודיים:**
|
||||
- ח מופיע **לפני** ז (שונה מהכט ואריאלי)
|
||||
- פתיחת דיון = "מיפוי מתחים" — 6 מתחים בתבליטים
|
||||
- סיכום מינימלי — הוראות אופרטיביות בלבד
|
||||
- ציטוט ארוך מערר מובשוביץ (~400 מילים)
|
||||
|
||||
---
|
||||
|
||||
## 3. אריאלי 1078+1083/24 (שרית אריאלי, קבלה, רישוי)
|
||||
|
||||
**מקור:** data/uploads/ARAR-24-1078-44.docx (גרסה מנבו)
|
||||
**שורות:** 171 | **מילים:** 10,748
|
||||
|
||||
| שורות | בלוק | תוכן | הערות |
|
||||
|-------|------|------|-------|
|
||||
| שורות 1-13 | א-ד — כותרת | הרכב, צדדים, חקיקה, "החלטה" | — |
|
||||
| שורות 15-16 | ה — פתיחה | "עניינה של החלטה זו..." + הגדרות | **שונה מדפנה** — לא "לפנינו" |
|
||||
| שורה 17 | ו — כותרת | **"פתח דבר"** | **כותרת ייחודית לאריאלי** |
|
||||
| שורות 18-32 | ו — רקע | מקרקעין (מוסררה), היסטוריה תכנונית (2015, 2017, 2020, 2023), שימור (אתר 3890), סביבה (GIS), עוררים | רקע מפורט ~1,500 מילים |
|
||||
| שורה 33 | ז — כותרת | "טענות הצדדים" | **לא** "תמצית טענות הצדדים" |
|
||||
| שורות 34-39 | ז — עוררים 1083 | שימור, מסה, תמ"א 38, ועדת שימור, מרחב ציבורי | — |
|
||||
| שורות 40-42 | ז — עורר 1078 | נוף להר הבית, גובה | — |
|
||||
| שורות 43-49 | ז — ועדה מקומית | תואמת, שימור, חניה, מקלט | — |
|
||||
| שורות 50-55 | ז — **עמדת ועדת שימור** | לא עקבית, שינוי עמדות | **צד נוסף** שלא קיים בדפנה |
|
||||
| שורות 56-62 | ז — מבקש היתר | מגרש ייחודי, מרחקים, מקלט, סטודנטים | — |
|
||||
| שורה 63 | ח — כותרת | **"ההליכים בפני וועדת הערר"** | — |
|
||||
| שורות 64-66 | ח — דיון | דיון 10.11.2024, טענות, מבקש היתר | — |
|
||||
| שורות 67-69 | ח — סיור | סיור 18.3.2025, אדריכלית דינור, תצפית | — |
|
||||
| שורות 70-75 | ח — החלטת ביניים + עמדת שימור | חתכי בינוי, חלופה, עמדת שימור 31.12.2025 | — |
|
||||
| שורות 76-86 | ח — השלמות טיעון | מבקש היתר 1.1.2026, השוואת בניינים ברחוב הע"ח, חלופה להנמכה, תגובת עוררים 12.1.26, עמדת שימור 1.2.26 | — |
|
||||
| שורות 87-92 | ח — תגובות נוספות | תגובת עוררים להשלמה, עמדת שימור סופית | **ח = 30 שורות, ~2,900 מילים** |
|
||||
| שורה 93 | ט — כותרת | **"התכניות החלות על המקרקעין"** | — |
|
||||
| שורות 94-97 | ט — תכניות סטטוטוריות | 3188 (1985), 3188א (1993), 3188ב (1995) | — |
|
||||
| שורות 98-104 | ט — ערר מעלומי | ציטוט נרחב מערר מעלומי על אופי שימורי | — |
|
||||
| שורות 105-113 | ט — תמ"א 38 + 10038 + רבדים | סעיף 19, שלושה רבדים של שימור, שיקול דעת | **ט = 21 שורות, ~1,800 מילים** |
|
||||
| שורה 114 | י — כותרת | **"דיון והכרעה:"** | נקודתיים בסוף — ייחודי |
|
||||
| שורות 115-117 | י — מסקנה בפתיחה | "שוכנענו כי הבקשה מהווה בינוי מאסיבי..." | CREAC — מסקנה קודם |
|
||||
| שורות 118-149 | י — ניתוח | אינטרס חיזוק, סבירות, חזית חמישית, דירוג, שימור חזיתות, ערר אדלר, מובשוביץ | — |
|
||||
| שורות 150-157 | י — תקדים שלילי + דרך המלך | תכנית נקודתית, התנהלות גורמי מקצוע | — |
|
||||
| שורות 158-164 | י — נושאים נוספים | נוף (עורר 1078), מקלט, זכות עמידה, פרסום | — |
|
||||
| שורה 165 | יא — כותרת | **"סוף דבר"** | **לא** "סיכום" — שונה מדפנה |
|
||||
| שורות 166-168 | יא — סיכום | "העררים מתקבלים" + הוראות: בקשה מתוקנת, גובה, קווי בניין, יח"ד | — |
|
||||
| שורה 169 | יב — חתימות | "ניתנה פה אחד, ט"ו ניסן תשפ"ו, 02 אפריל 2026" | — |
|
||||
| שורות 170-171 | — מטא-דאטה נבו | "נוסח מסמך זה כפוף..." | **לא חלק מההחלטה** |
|
||||
|
||||
**בלוקים קיימים:** ה, ו, ז, ח (מורחב — 30 שורות), ט (נפרד), י, יא, יב
|
||||
**כל הבלוקים המהותיים קיימים — זו ההחלטה השלמה ביותר**
|
||||
|
||||
**ממצאים ייחודיים:**
|
||||
- פתיחה "עניינה של החלטה זו" (לא "לפנינו")
|
||||
- כותרת רקע "פתח דבר" (לא "רקע")
|
||||
- כותרת טענות "טענות הצדדים" (לא "תמצית טענות הצדדים")
|
||||
- כותרת סיכום "סוף דבר" (לא "סיכום")
|
||||
- בלוק ח מורחב (30 שורות) — דיון + סיור + השלמות + תגובות
|
||||
- בלוק ט נפרד — תכניות + רבדי שימור + תמ"א 38
|
||||
- צד נוסף בטענות: "עמדת ועדת שימור"
|
||||
- CREAC מפורש בדיון — מסקנה בפתיחה ("שוכנענו כי...")
|
||||
|
||||
---
|
||||
|
||||
## סיכום השוואתי
|
||||
|
||||
### סדר בלוקים
|
||||
|
||||
| בלוק | הכט (דחייה) | בית הכרם (חלקית) | אריאלי (קבלה) |
|
||||
|------|------------|-----------------|---------------|
|
||||
| ה — פתיחה | "לפנינו" | "לפנינו" | "עניינה של" |
|
||||
| ו — רקע | "רקע" (אין כותרת) | "רקע" | "פתח דבר" |
|
||||
| ח — הליכים | **לא קיים** | **לפני ז** (3 שורות) | **אחרי ז** (30 שורות) |
|
||||
| ז — טענות | "תמצית טענות הצדדים" | "תמצית טענות הצדדים" | "טענות הצדדים" |
|
||||
| ט — תכניות | **משולב בדיון** | **משולב בדיון** | **נפרד** |
|
||||
| י — דיון | מסקנה → ס' 152 → פסיקה → יישום | מיפוי מתחים → ניתוח נושאי | CREAC מפורש |
|
||||
| יא — סיכום | "סיכום" (6 סעיפים) | "סיכום" (2 הוראות) | "סוף דבר" (הוראות) |
|
||||
|
||||
### מה קובע אילו בלוקים קיימים
|
||||
|
||||
| בלוק | כלל | פירוט |
|
||||
|------|-----|-------|
|
||||
| ח — הליכים | **מותנה** — רק כשהיו הליכים מעבר לדיון פשוט | סיור = סמן חזק לבלוק ח מפורט. השלמות טיעון רבות / החלטות ביניים = בלוק ח קצר. דיון פשוט (הצדדים טענו ונגמר) = אין בלוק ח |
|
||||
| ט — תכניות | **תמיד קיים** — רישום התכניות החלות הוא חובה | רישום התכניות: תמיד, כחלק מהרקע (ו) או כפרק נפרד. ניתוח התכניות: בדיון (י), רק כשרלוונטי. פרק ט נפרד רק כשהמורכבות התכנונית מצדיקה ניתוח מקדים (כמו באריאלי — 3 תכניות שימור + 3 רבדים) |
|
||||
|
||||
### מה צריך לתקן ב-parser
|
||||
|
||||
1. פתיחה: לזהות גם "עניינה של" ולא רק "לפנינו"
|
||||
2. רקע: לזהות גם "פתח דבר" כנוסף ל-"רקע"
|
||||
3. טענות: לזהות גם "טענות הצדדים" בלי "תמצית"
|
||||
4. סיכום: לזהות גם "סוף דבר"
|
||||
5. מטא-דאטה נבו: לסנן שורות 1-7 ו-182-183 של בית הכרם, 170-171 של אריאלי
|
||||
6. ח לפני ז: בבית הכרם ח מופיע לפני ז — ה-parser צריך לתמוך בזה
|
||||
50
docs/migration-plan.md
Normal file
50
docs/migration-plan.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# Migration Plan — Dafna Vault → Nautilus
|
||||
|
||||
## Source
|
||||
- Obsidian vault at `/opt/apps/vaults/dafna-tamir/`
|
||||
- Claude memory at `/home/chaim/.claude/projects/-opt-apps-vaults-dafna-tamir/memory/`
|
||||
- 229MB compressed (excluding node_modules, .git)
|
||||
|
||||
## Target
|
||||
- PostgreSQL on Nautilus (legal-ai-postgres)
|
||||
- File storage on Nautilus
|
||||
- Gitea repository for code/scripts
|
||||
|
||||
## What to Migrate
|
||||
|
||||
### Knowledge (Priority 1 — enables RAG immediately)
|
||||
| Source | Target Table | Records |
|
||||
|--------|-------------|---------|
|
||||
| memory/legal-decision-lessons.md | lessons_learned | ~12 lessons |
|
||||
| SKILL.md section 5.2 | transition_phrases | ~30 phrases |
|
||||
| Published decisions (citations) | case_law | ~20 cases |
|
||||
| SKILL.md section 6.9 | statutory_provisions | ~10 statutes |
|
||||
|
||||
### Appeals (Priority 2)
|
||||
| Source | Target Table | Records |
|
||||
|--------|-------------|---------|
|
||||
| 01_Projects/*/README.md | appeals | 3 active |
|
||||
| 04_Archive/*/README.md | appeals | 14 archived |
|
||||
| All case headers | parties | ~50 |
|
||||
| All case headers | panels | ~17 |
|
||||
|
||||
### Documents (Priority 3)
|
||||
| Source | Target Table | Records |
|
||||
|--------|-------------|---------|
|
||||
| */חומרי-מקור/**/*.pdf | documents | ~200 PDFs |
|
||||
| */חומרי-מקור/**/*.md | documents | ~100 MDs |
|
||||
| */החלטה/*.docx | documents | ~10 DOCXs |
|
||||
|
||||
### Decisions (Priority 4)
|
||||
| Source | Target Table | Records |
|
||||
|--------|-------------|---------|
|
||||
| הכט published PDF | decisions + blocks + paragraphs | 1 complete |
|
||||
| בית הכרם Draft 9 | decisions + blocks + paragraphs | 1 complete |
|
||||
| קרית יערים draft | decisions + blocks | 1 in progress |
|
||||
|
||||
### Embeddings (Priority 5)
|
||||
| Source | Target Table | Records |
|
||||
|--------|-------------|---------|
|
||||
| All MD source docs | document_embeddings | ~500 chunks |
|
||||
| Decision paragraphs | paragraph_embeddings | ~300 paragraphs |
|
||||
| Case law summaries | case_law_embeddings | ~20 summaries |
|
||||
566
docs/product-specification.md
Normal file
566
docs/product-specification.md
Normal file
@@ -0,0 +1,566 @@
|
||||
# איפיון מוצר — עוזר משפטי
|
||||
|
||||
## מסמך זה
|
||||
מסמך איפיון מוצר (Product Specification) למערכת "עוזר משפטי" — כלי AI לכתיבת החלטות ועדת ערר לתכנון ובניה.
|
||||
|
||||
**מצב:** הושלם — עבר סקירת מומחה ותוקן
|
||||
**תאריך התחלה:** 2 באפריל 2026
|
||||
**בעל המוצר:** חיים מרכוס
|
||||
|
||||
---
|
||||
|
||||
## סעיף 0: בחירת מתודולוגיית איפיון
|
||||
|
||||
### השאלה
|
||||
מי המומחה המתאים להגדיר מוצר AI שמבצע עבודה מקצועית מורכבת (כתיבת החלטות משפטיות)?
|
||||
|
||||
### שתי הגישות
|
||||
|
||||
#### גישה א: מנהל מוצר (Product Manager)
|
||||
**מתמחה ב:** הגדרת "מה" — user stories, features, prioritization, go-to-market.
|
||||
**מתודולוגיות:** Lean Product, Jobs To Be Done (JTBD), Design Thinking.
|
||||
**חוזק:** מתרגם צורך עסקי למפרט טכני. מגדיר MVP. מתעדף features.
|
||||
**חולשה:** לא מתמחה בניתוח תהליכי עבודה מורכבים, לא מודד יעילות, לא מתכנן workflow אופטימלי.
|
||||
|
||||
#### גישה ב: מהנדס תעשייה וניהול (Industrial & Systems Engineer)
|
||||
**מתמחה ב:** הגדרת "איך" — ניתוח תהליכים, מדידת זמנים, זיהוי צווארי בקבוק, אופטימיזציה.
|
||||
**מתודולוגיות:** Systems Engineering (INCOSE SE Handbook), Business Process Modeling (BPMN), Value Stream Mapping, Human-Machine Teaming.
|
||||
**חוזק:** מפרק תהליך מורכב לשלבים מדידים. מזהה איפה AI מוסיף ערך ואיפה לא. מתכנן ממשק אדם-מכונה. מודד KPIs.
|
||||
**חולשה:** פחות מתמחה בחוויית משתמש (UX) ובתעדוף עסקי.
|
||||
|
||||
### ההמלצה: גישה משולבת עם דגש על הנדסת מערכות
|
||||
|
||||
**הנימוק:**
|
||||
המוצר שלנו הוא לא אפליקציה צרכנית אלא **כלי עבודה מקצועי** שמחליף/מסייע בתהליך מורכב. הבעיה המרכזית היא לא "אילו features לבנות" אלא **"איך דפנה עובדת ואיפה AI נכנס לתהליך"**. זו בדיוק ההתמחות של הנדסת תעשייה ומערכות.
|
||||
|
||||
**סימוכין אקדמיים:**
|
||||
|
||||
1. **INCOSE Systems Engineering Handbook (2023, 5th ed.)** — מגדיר שכלי AI מקצועי דורש קודם כל "Operational Concept" — תיאור מלא של תהליך העבודה לפני ואחרי הכנסת המערכת (Chapter 4.2: Stakeholder Needs and Requirements).
|
||||
|
||||
2. **Parasuraman, R., Sheridan, T.B., & Wickens, C.D. (2000). "A Model for Types and Levels of Human Interaction with Automation."** IEEE Transactions on Systems, Man, and Cybernetics. — מגדיר 10 רמות אוטומציה (LOA) בין "האדם עושה הכל" ל-"המכונה עושה הכל". המפתח: לכל שלב בתהליך צריך להגדיר את רמת האוטומציה הנכונה. לא הכל צריך להיות אוטומטי.
|
||||
|
||||
3. **Daugherty, P.R. & Wilson, H.J. (2018). "Human + Machine: Reimagining Work in the Age of AI."** Harvard Business Review Press. — מגדיר מודל "collaborative intelligence" שבו AI ואדם משלימים זה את זה. רלוונטי כי דפנה לא רוצה שה-AI יחליף אותה — היא רוצה שיעזור לה.
|
||||
|
||||
4. **Endsley, M.R. (2017). "From Here to Autonomy: Lessons Learned from Human-Automation Research."** Human Factors. — מזהיר מ-"automation complacency" — כשאנשים סומכים יותר מדי על AI ומפסיקים לבדוק. קריטי בהקשר משפטי שבו דפנה חייבת לקרוא ולאשר כל מילה.
|
||||
|
||||
**מסקנה:** נשתמש בגישת **Systems Engineering** כמסגרת ראשית, עם רכיבים מ-Product Management לתעדוף ו-MVP.
|
||||
|
||||
---
|
||||
|
||||
## טבלת מעקב איפיון
|
||||
|
||||
| סעיף | נושא | סטטוס | הערות |
|
||||
|------|------|-------|-------|
|
||||
| סעיף 0 | בחירת מתודולוגיה | ✅ מלא | הנדסת מערכות + ניהול מוצר |
|
||||
| סעיף 1 | חזון המוצר | ✅ מלא | בעיה, חזון, פתרון, משתמשים, מדדי הצלחה, scope |
|
||||
| סעיף 2 | בעלי עניין | ✅ מלא | חיים (מפעיל), דפנה (מגיהה+חותמת), שופט (מבחן עליון), חברי ועדה, מזכירות, צדדים |
|
||||
| סעיף 3 | תהליך עבודה נוכחי | ✅ מלא | נקודת כניסה, חומרים, תהליך, זמנים, צוואר בקבוק |
|
||||
| סעיף 4 | תהליך עבודה עתידי | ✅ מלא | 7 שלבים: קלט → עיבוד → תוצאה → סיעור מוחות (אם צריך) → כתיבה → פלט → למידה |
|
||||
| סעיף 5 | רמות אוטומציה | ✅ מלא | 3 רמות (אוטומטי/שיתופי/אנושי), מיפוי 11 שלבים, 7 עקרונות עיצוב, 4 סיכונים |
|
||||
| סעיף 6 | דרישות פונקציונליות | ✅ מלא | 40 דרישות ב-8 שלבים (כולל שלב 6 הגהת דפנה), כולן מבוססות על סעיפים 1-5 |
|
||||
| סעיף 7 | דרישות לא-פונקציונליות | ✅ מלא | 12 דרישות: שפה, ביצועים, דיוק, אבטחה, זמינות, ממשק |
|
||||
| סעיף 8 | גרסה מינימלית (MVP) | ✅ מלא | אין MVP — מוצר מלא בלבד. תוכנית הסמכה ב-4 שלבים |
|
||||
| סעיף 9 | מדדי הצלחה | ✅ מלא | 6 מדדים: אחוז שינוי, זמן, אפס הזיות, מענה לטענות, משקלות, ניטרליות |
|
||||
| סעיף 10 | סיכונים ומגבלות | ✅ מלא | 10 סיכונים עם מנגנוני הגנה, 4 מגבלות ידועות |
|
||||
|
||||
---
|
||||
|
||||
## סעיף 1: חזון המוצר (Product Vision)
|
||||
|
||||
### טבלת מעקב שאלות — סעיף 1
|
||||
|
||||
| שאלה | סטטוס | תשובה |
|
||||
|------|-------|-------|
|
||||
| מה הבעיה שהמוצר פותר? | ✅ מלא | חיים (עו"ד, עוזר משפטי של דפנה) לא מצליח להתאים את סגנון הכתיבה שלו לסגנון של דפנה. צריך כלי AI שכותב בדיוק כמו דפנה |
|
||||
| מי המשתמש העיקרי? | ✅ מלא | חיים — מפעיל המערכת מהתחלה עד טיוטה סופית. דפנה רק מגיהה ומתקנת אחרי. הגרסה הסופית שדפנה מפיצה חוזרת למערכת ללמידה |
|
||||
| מה התוצר הסופי שיוצא מהמערכת? | ✅ מלא | קובץ DOCX מעוצב, כמעט מוכן לחתימה. עיצוב עברי RTL עם כותרות — skill קיים לייצור DOCX. נדרשות התאמות קטנות |
|
||||
| מה "הצלחה" נראית? | ✅ מלא | מצב תקין: דפנה משנה/מוסיפה עד 10% מהטקסט. הצלחה מלאה: 98% מהטקסט נשאר כמו שהמערכת כתבה |
|
||||
| מה מחוץ ל-scope? | ✅ מלא | המערכת רק כותבת החלטות. לא ניהול תיקים, לא תזמון, לא מיילים. מקבלת קבצים (PDF/DOCX/MD) ומסתמכת **רק** על מה שקיבלה — אסור לה להמציא מקורות או לצטט דברים שלא במסמכים |
|
||||
|
||||
### הבעיה
|
||||
דפנה תמיר, יו"ר ועדת ערר לתכנון ובניה מחוז ירושלים, נושאת עומס תיקים רב. חיים מרכוס הוא העוזר המשפטי שלה — עורך דין שמנסח עבורה טיוטות החלטות שדפנה עוברת עליהן, מתקנת, מגיהה ומתאימה לסגנונה לפני שהיא חותמת.
|
||||
|
||||
**הבעיה המרכזית:** לחיים יש סגנון כתיבה משפטי משלו שלא תואם את הסגנון הייחודי של דפנה. הפער בסגנון גורם לדפנה לבזבז זמן רב על תיקון והתאמה — בדיוק הזמן שהעוזר אמור לחסוך לה.
|
||||
|
||||
**מה שצריך:** כלי AI שמחליף את שלב הכתיבה הראשוני של חיים — כותב טיוטה ראשונית **בדיוק בסגנון של דפנה**, כך שדפנה מקבלת טיוטה שדורשת מינימום תיקונים.
|
||||
|
||||
**העיקרון:** מינימום זמן, מקסימום תוצר.
|
||||
|
||||
### משפט חזון
|
||||
כלי AI שכותב טיוטות החלטות ועדת ערר **בדיוק בסגנון של דפנה תמיר** — מקבל חומרי מקור ומוציא DOCX מעוצב כמעט מוכן לחתימה, כך שדפנה צריכה לשנות מינימום.
|
||||
|
||||
### הפתרון
|
||||
מערכת "עוזר משפטי" שמחליפה את שלב כתיבת הטיוטה הראשונית:
|
||||
|
||||
**קלט:** קבצים (PDF/DOCX/MD) מסוג כתבי בי-דין — ערר, תשובה, תגובה, פרוטוקול, תכנית, היתר, פסקי דין, החלטות.
|
||||
|
||||
**תהליך:** המערכת קוראת את החומר, מנתחת, ומנסחת החלטה בסגנון דפנה לפי ארכיטקטורת 12 בלוקים.
|
||||
|
||||
**פלט:** קובץ DOCX מעוצב — טיוטה כמעט מוכנה לחתימה.
|
||||
|
||||
**כלל ברזל:** המערכת מסתמכת **רק** על מסמכים שקיבלה בפועל. אסור לה להמציא מקורות, לצטט דברים שלא במסמכים, או להוסיף פסיקה שלא סופקה.
|
||||
|
||||
**לולאת למידה:** הגרסה הסופית שדפנה מפיצה (אחרי הגהה ותיקונים) חוזרת למערכת — כך המערכת לומדת מהפער בין הטיוטה שלה לגרסה הסופית ומשתפרת עם הזמן.
|
||||
|
||||
### משתמשים
|
||||
- **משתמש ראשי:** חיים מרכוס (עו"ד, עוזר משפטי) — מפעיל את המערכת מהתחלה עד טיוטה סופית
|
||||
- **משתמש עקיף:** דפנה תמיר (עו"ד, יו"ר ועדת ערר) — מקבלת את הטיוטה, מגיהה, מתקנת, חותמת
|
||||
|
||||
### מדדי הצלחה
|
||||
- **מצב תקין (target):** דפנה משנה/מוסיפה עד 10% מהטקסט
|
||||
- **הצלחה מלאה (stretch):** עד 5% שינוי
|
||||
|
||||
**הערה:** לפי מחקר Endsley (2017), מומחים בדרגת ההזדהות של דפנה כמעט תמיד ישנו ניסוחים — לא כי הם שגויים, אלא כי זו הדרך שלהם "לאמץ" את הטקסט. לכן יעד 2% לא ריאלי. יעד 5% מאפשר לדפנה מרחב אישי תוך שמירה על יעילות גבוהה. המדד יתכייל לאחר 5 החלטות ראשונות.
|
||||
|
||||
### מחוץ ל-scope
|
||||
- ניהול תיקים, תזמון דיונים, שליחת מיילים
|
||||
- חיפוש פסיקה באינטרנט — רק מה שסופק כמסמך
|
||||
- החלטה אוטונומית — דפנה תמיד קוראת, מגיהה וחותמת
|
||||
|
||||
---
|
||||
|
||||
## סעיף 2: בעלי עניין (Stakeholders)
|
||||
|
||||
### טבלת מעקב שאלות — סעיף 2
|
||||
|
||||
| שאלה | סטטוס | תשובה |
|
||||
|------|-------|-------|
|
||||
| מי מעורב בתהליך מלבד חיים ודפנה? | ✅ מלא | השופט — בעל עניין שקט. כל החלטה עלולה לעמוד לביקורת שיפוטית בעתמ"ם ובעליון |
|
||||
| מה השופט בודק? | ✅ מלא | הנמקה מלאה, תשתית עובדתית, סבירות ומידתיות, פרוצדורה תקינה, ציטוט מדויק |
|
||||
| האם יש עוד בעלי עניין? | ✅ מלא | מזכירות (מפיצה בלבד), חברי ועדה (דיון לפני הכתיבה, לא מעורבים בכתיבה), צדדים (רואים רק אחרי פרסום) |
|
||||
|
||||
### בעלי עניין
|
||||
|
||||
| תפקיד | שם | מעורבות | צורך עיקרי |
|
||||
|-------|-----|---------|-----------|
|
||||
| מפעיל המערכת | חיים מרכוס, עו"ד | מפעיל יום-יום — מהקמת תיק עד טיוטה סופית | טיוטה בסגנון דפנה, מינימום זמן, מקסימום תוצר |
|
||||
| יו"ר ועדת הערר | דפנה תמיר, עו"ד | מקבלת טיוטה, מגיהה, מתקנת, חותמת | טיוטה שדורשת מינימום שינויים (יעד: עד 10%) |
|
||||
| **בעל עניין שקט: השופט** | שופט בית משפט מנהלי | לא משתמש במערכת, אבל כל החלטה חייבת לעמוד בביקורתו | — |
|
||||
|
||||
### "מבחן השופט" — הדרישה העליונה של המוצר
|
||||
|
||||
כל החלטה שהמערכת מייצרת חייבת לעמוד בביקורת שיפוטית של שופט בית משפט לעניינים מנהליים (ובערעור — בית המשפט העליון). בפועל השופט בודק:
|
||||
|
||||
1. **הנמקה מלאה** — כל טענה שהועלתה קיבלה מענה. התעלמות מטענה = עילת ביטול.
|
||||
2. **תשתית עובדתית** — העובדות מוצגות נכון, מלאות, לא מוטות. רקע לא ניטרלי = חשש למשוא פנים.
|
||||
3. **סבירות ומידתיות** — ההכרעה סבירה לאור הטענות והעובדות. לא מספיק "נדחה" — צריך להסביר למה ולמה זה מידתי.
|
||||
4. **פרוצדורה תקינה** — כל הצדדים קיבלו הזדמנות להשמיע קולם. דיון התקיים. הזדמנויות לטעון ניתנו.
|
||||
5. **ציטוט מדויק** — כל הפניה לפסיקה, חקיקה או מסמך חייבת להיות מדויקת ומבוססת על מה שסופק בפועל.
|
||||
|
||||
**זו לא דרישה סגנונית — זו הדרישה העליונה של המוצר.**
|
||||
|
||||
### בעלי עניין נוספים (לא משתמשים במערכת)
|
||||
|
||||
| תפקיד | מעורבות | השלכה על המוצר |
|
||||
|-------|---------|---------------|
|
||||
| חברי ועדת הערר | דיון פרונטלי לפני הכתיבה — לא מעורבים בכתיבה עצמה | המערכת צריכה לקלוט את פרוטוקול הדיון כקלט |
|
||||
| מזכירות הוועדה | מפיצה את ההחלטה הסופית בלבד | אין השלכה על המוצר |
|
||||
| הצדדים (עוררים/משיבים) | רואים את ההחלטה רק אחרי פרסום | אין השלכה ישירה, אבל הם אלה שעלולים לעתור — חוזר ל"מבחן השופט" |
|
||||
|
||||
---
|
||||
|
||||
## סעיף 3: תהליך העבודה הנוכחי (As-Is Process)
|
||||
|
||||
### טבלת מעקב שאלות — סעיף 3
|
||||
|
||||
| שאלה | סטטוס | תשובה |
|
||||
|------|-------|-------|
|
||||
| מתי המערכת נכנסת לתמונה? | ✅ מלא | אחרי שהדיון הסתיים — כל הצדדים טענו בכתב ובעל פה, הוועדה דנה, ועכשיו צריך לכתוב החלטה |
|
||||
| מה החומרים שעל השולחן ברגע הזה? | ✅ מלא | כל מסמך שנמסר לוועדה: כתב ערר, כתב תשובה (ועדה מקומית + משיבים), פרוטוקולים, השלמות טיעון |
|
||||
| מה אתה (חיים) עושה היום צעד אחרי צעד כשאתה כותב טיוטה? | ✅ מלא | קורא את כל החומר → כותב פתח דבר/רקע → ממשיך צעד אחרי צעד. סדר הפרקים משתנה לפי סוג ההחלטה |
|
||||
| כמה זמן התהליך לוקח היום? | ✅ מלא | שבוע לטיוטה שלמה. יעד: יום אחד |
|
||||
| מה הכי קשה / לוקח הכי הרבה זמן? | ✅ מלא | סיכום הטענות והדיון. בעיקר הדיון (בלוק י) — הוא צוואר הבקבוק |
|
||||
|
||||
### נקודת הכניסה
|
||||
המערכת נכנסת לתמונה **אחרי** שכל השלבים הבאים הסתיימו:
|
||||
- כתבי הערר הוגשו ✅
|
||||
- כתבי תשובה/תגובה הוגשו ✅
|
||||
- השלמות טיעון (אם היו) הוגשו ✅
|
||||
- דיון פרונטלי בוועדת הערר התקיים ✅
|
||||
- הוועדה דנה פנימית והחליטה על הכיוון ✅
|
||||
|
||||
**עכשיו** — צריך לכתוב את ההחלטה. כאן המערכת נכנסת.
|
||||
|
||||
### תהליך העבודה הנוכחי (ללא המערכת)
|
||||
|
||||
1. **קריאת כל החומר** — כתבי ערר, תשובות, פרוטוקולים, השלמות
|
||||
2. **כתיבת פתיחה ורקע** (בלוקים ה-ו) — הגדרות, עובדות, תכניות
|
||||
3. **סיכום טענות** (בלוק ז) — לכל צד בנפרד — **לוקח הרבה זמן**
|
||||
4. **הליכים** (בלוק ח) — אם היו סיור/השלמות/החלטות ביניים
|
||||
5. **דיון** (בלוק י) — **צוואר הבקבוק** — ניתוח משפטי, פסיקה, יישום, הכרעה
|
||||
6. **סיכום** (בלוק יא) — הוראות אופרטיביות
|
||||
7. **שליחה לדפנה** — דפנה מגיהה, מתקנת, חותמת
|
||||
|
||||
**זמן נוכחי:** שבוע לטיוטה שלמה
|
||||
**יעד:** יום אחד
|
||||
|
||||
### ניתוח מבנה 3 החלטות — ממצאים
|
||||
|
||||
מניתוח הכט (דחייה), בית הכרם (קבלה חלקית), אריאלי (קבלה) עולה:
|
||||
|
||||
**בלוקים קבועים (תמיד קיימים):**
|
||||
- ה — פתיחה (אבל בניסוחים שונים: "לפנינו" / "עניינה של החלטה זו")
|
||||
- ו — רקע / "פתח דבר" (היקף משתנה: 3% עד 18%)
|
||||
- ז — טענות הצדדים
|
||||
- י — דיון והכרעה
|
||||
- יא — סיכום / סוף דבר
|
||||
- יב — חתימות
|
||||
|
||||
**בלוקים מותנים (תלויים בתיק):**
|
||||
- ח — הליכים: קיים כשהיו הליכים מורכבים (דיון + סיור + השלמות רבות). באריאלי = 27% מההחלטה
|
||||
- ט — תכניות/מסגרת נורמטיבית: קיים כשיש מורכבות תכנונית או שאלה משפטית (ס' 152). בהכט = 32%
|
||||
|
||||
**⚠ ממצא טכני:** ה-parser הנוכחי לא זיהה את בלוקים ה ו-ו של אריאלי כי הפתיחה שלה ("עניינה של החלטה זו") שונה מ-"לפנינו", וכותרת הרקע ("פתח דבר") לא הייתה בדפוסי החיפוש. דורש תיקון.
|
||||
|
||||
---
|
||||
|
||||
## סעיף 4: תהליך העבודה העתידי (To-Be Process)
|
||||
|
||||
### טבלת מעקב שאלות — סעיף 4
|
||||
|
||||
| שאלה | סטטוס | תשובה |
|
||||
|------|-------|-------|
|
||||
| איך אתה רואה את התהליך עם המערכת? | ✅ מלא | מינימום ממשק, אבל חייב man-in-the-middle לפני הדיון |
|
||||
| מה השלב שחייב אדם? | ✅ מלא | הזנת התוצאה שדפנה קבעה (דחייה/קבלה/חלקית) — לפני שהמערכת כותבת את הדיון |
|
||||
| מי קובע את התוצאה? | ✅ מלא | דפנה — היא השופטת. היא מעבירה לחיים את ההחלטה |
|
||||
| מה דפנה מעבירה? | ✅ מלא | לא קבוע — לפעמים רק "נדחה/התקבל", לפעמים מנומק יותר |
|
||||
| מה קורה עם הנימוקים של דפנה? | ✅ מלא | אם דפנה נותנת נימוק — ישר לכתיבה. אם רק תוצאה — סיעור מוחות בין חיים למערכת על בסיס החומר המשפטי כדי לגבש את הכיוון. לא מתחילים לכתוב דיון לפני שיש כיוון מדויק |
|
||||
|
||||
### תהליך העבודה העתידי
|
||||
|
||||
**שלב 1 — קלט (חיים)**
|
||||
חיים מעלה למערכת את כל המסמכים שנמסרו לוועדה (PDF/DOCX/MD).
|
||||
|
||||
**שלב 2 — עיבוד אוטומטי (מערכת)**
|
||||
המערכת קוראת את כל החומר, מזהה צדדים, מסווגת מסמכים, מחלצת טענות.
|
||||
|
||||
**שלב 3 — הזנת תוצאה (חיים) ← man-in-the-middle**
|
||||
חיים מזין את התוצאה שדפנה קבעה:
|
||||
- סוג: דחייה / קבלה / קבלה חלקית
|
||||
- נימוק: אם דפנה נתנה → ישר לשלב 4ב
|
||||
|
||||
**שלב 4א — סיעור מוחות (חיים + מערכת) ← רק אם אין נימוק**
|
||||
אם דפנה נתנה רק תוצאה בלי נימוק — המערכת וחיים מנהלים שיח:
|
||||
- המערכת מציגה את הטענות המרכזיות מהחומר
|
||||
- חיים והמערכת דנים על בסיס מה מגיעים לתוצאה
|
||||
- **לא מתחילים לכתוב דיון לפני שיש כיוון מדויק**
|
||||
- התוצר: מסמך כיוון קצר — מה הנימוקים המרכזיים, באיזה סדר, מה הפסיקה הרלוונטית
|
||||
|
||||
**שלב 4ב — כתיבת טיוטה (מערכת)**
|
||||
המערכת כותבת את ההחלטה בלוק אחרי בלוק, בסגנון דפנה, לפי התוצאה והכיוון שנקבעו.
|
||||
|
||||
**שלב 5 — פלט (חיים)**
|
||||
חיים מקבל DOCX מעוצב — טיוטה כמעט מוכנה.
|
||||
|
||||
**שלב 6 — הגהה ותיקונים (דפנה)**
|
||||
דפנה קוראת, מתקנת, מגיהה, חותמת.
|
||||
|
||||
**שלב 7 — לולאת למידה (מערכת)**
|
||||
הגרסה הסופית שדפנה מפיצה חוזרת למערכת — המערכת לומדת מהפער.
|
||||
|
||||
---
|
||||
|
||||
## סעיף 5: רמות אוטומציה (Levels of Automation)
|
||||
|
||||
### בסיס אקדמי
|
||||
|
||||
הניתוח מבוסס על 9 מקורות אקדמיים (ביבליוגרפיה מלאה בנספח):
|
||||
|
||||
| מקור | תרומה |
|
||||
|------|-------|
|
||||
| פרסורמן, שרידן וויקנס (2000) | מודל 10 רמות אוטומציה × 4 שלבי עיבוד מידע |
|
||||
| אנדסלי (2017) | סיכוני שאננות אוטומציה — דווקא מומחים רגישים יותר |
|
||||
| קאמינגס (2004) | הטיית אוטומציה — commission errors ו-omission errors |
|
||||
| סורדין (2018) | שלוש רמות AI במשפט: תומך / מחליף / משבש |
|
||||
| רילינג (2020) | הבחנה בין פרוצדורלי (אוטומטי) לשיקול דעת (אנושי) |
|
||||
| CEPEJ (2018) | חמישה עקרונות אתיים ל-AI בשיפוט — "under user control" |
|
||||
| INCOSE (2023) | הקצאת פונקציות דינמית — לפי מורכבות, סיכון, עומס |
|
||||
|
||||
### שלוש רמות אוטומציה
|
||||
|
||||
| רמה | שם | תיאור | LOA (פרסורמן) |
|
||||
|------|-----|-------|--------------|
|
||||
| **א — אוטומטי** | המערכת מבצעת, מדווחת לאדם | 7-9 |
|
||||
| **ב — שיתופי** | המערכת מנסחת טיוטה, האדם מאשר/עורך/דוחה | 4-5 |
|
||||
| **ג — אנושי** | האדם מבצע, המערכת מספקת מידע בלבד | 1-3 |
|
||||
|
||||
### מיפוי דו-ממדי: רמות אוטומציה × שלבי עיבוד מידע (Parasuraman 2000)
|
||||
|
||||
| שלב עבודה | שלב עיבוד (Parasuraman) | רמה |
|
||||
|-----------|------------------------|-----|
|
||||
| קריאת מסמכים וסיווג | Information Acquisition | א — אוטומטי |
|
||||
| חילוץ טענות | Information Acquisition + Analysis | ב — שיתופי |
|
||||
| חיפוש תקדימים | Information Analysis | ב — שיתופי |
|
||||
| גיבוש נימוקים | Information Analysis + Decision Selection | ב — שיתופי |
|
||||
| **קביעת תוצאה** | **Decision Selection** | **ג — אנושי** |
|
||||
| כתיבת בלוקים ה-ח | Action Implementation | ב — שיתופי |
|
||||
| כתיבת דיון (י) | Action Implementation (high-stakes) | ב — שיתופי |
|
||||
| ייצוא DOCX | Action Implementation (low-stakes) | א — אוטומטי |
|
||||
|
||||
### מיפוי שלבי העבודה לרמות אוטומציה
|
||||
|
||||
| שלב | תוכן | רמה | נימוק |
|
||||
|-----|-------|-----|-------|
|
||||
| קריאת מסמכים וסיווג | זיהוי סוג מסמך, חילוץ מטא-דאטה | **א — אוטומטי** | פרוצדורלי, ניתן לביקורת, סיכון נמוך |
|
||||
| חילוץ טענות | סיכום טענות מכתבי טענות | **ב — שיתופי** | דורש נאמנות למקור — AI מנסח, אדם מוודא |
|
||||
| כתיבת רקע (בלוק ו) | עובדות, תכניות | **ב — שיתופי** | חובת ניטרליות — AI מנסח, אדם בודק |
|
||||
| כתיבת טענות (בלוק ז) | סיכום טענות בגוף שלישי | **ב — שיתופי** | נאמנות למקור |
|
||||
| כתיבת הליכים (בלוק ח) | תיעוד כרונולוגי | **ב — שיתופי** | בעיקר עובדתי אבל דורש דיוק |
|
||||
| חיפוש תקדימים | RAG — מציאת פסיקה דומה | **ב — שיתופי** | AI מציע 3-5 חלופות, אדם בוחר (קאמינגס) |
|
||||
| **קביעת תוצאה** | דחייה/קבלה/חלקית | **ג — אנושי בלבד** | **החלטה שיפוטית — דפנה בלבד** |
|
||||
| **גיבוש נימוקים** | סיעור מוחות על הכיוון | **ב — שיתופי** | AI מציג טענות ומציע כיוונים, חיים מחליט. אופציונלי גם כשיש נימוק |
|
||||
| כתיבת דיון (בלוק י) | ניתוח משפטי, CREAC | **ב — שיתופי** | AI מנסח על בסיס הכיוון שנקבע, אדם עורך |
|
||||
| כתיבת סיכום (בלוק יא) | הוראות אופרטיביות | **ב — שיתופי** | נגזר מהדיון, אבל חייב לשקף הכרעה מדויקת |
|
||||
| ייצוא DOCX | עיצוב מסמך | **א — אוטומטי** | טכני לחלוטין |
|
||||
|
||||
### עקרונות עיצוב (מבוססי מחקר)
|
||||
|
||||
| עיקרון | מקור | יישום |
|
||||
|--------|------|-------|
|
||||
| **"אדם בלולאה"** | אנדסלי (2017) | דפנה קובעת תוצאה, חיים מאשר כיוון — לפני שהמערכת כותבת |
|
||||
| **שקיפות** | אנדסלי (2017), CEPEJ (2018) | כל טיוטה מציגה מקורות. רמת ודאות ליד תקדימים |
|
||||
| **מעורבות אקטיבית** | אנדסלי (2017) | חובת מעבר מבלוק לבלוק — אין "ייצר הכל" בלחיצה |
|
||||
| **הצגת חלופות** | קאמינגס (2004) | חיפוש תקדימים מחזיר 3-5 חלופות, לא "התקדים הנכון" |
|
||||
| **כפייה קוגניטיבית** | קאמינגס (2004) | חיים מזין כיוון **לפני** שרואה טיוטת דיון |
|
||||
| **אחריותיות** | CEPEJ (2018) | החלטה נושאת חתימת דפנה. תיעוד שנעשה שימוש ב-AI |
|
||||
| **הקצאה דינמית** | INCOSE (2023) | ככל שהמשימה קרובה יותר להכרעה — פחות אוטומציה |
|
||||
|
||||
### סיכונים שזוהו
|
||||
|
||||
| סיכון | מקור | מנגנון הגנה |
|
||||
|-------|------|------------|
|
||||
| **שאננות אוטומציה** — דפנה מפסיקה לבדוק טיוטות | אנדסלי | לולאת למידה: השוואת טיוטה לגרסה סופית מודדת כמה דפנה שינתה |
|
||||
| **הטיית אוטומציה** — חיים מאמץ תקדים שגוי | קאמינגס | כלל ברזל: רק מה שסופק כמסמך. + הצגת חלופות |
|
||||
| **שחיקת מיומנות** — חיים מפסיק ללמוד לכתוב | פרסורמן | סיעור מוחות חובה לפני כל דיון |
|
||||
| **לולאת חיזוק** — החלטות עתידיות ידמו לעבר | אלטרס (2016) | כל החלטה חדשה מבוססת על חומרי המקור, לא על תבנית |
|
||||
|
||||
---
|
||||
|
||||
## סעיף 6: דרישות פונקציונליות
|
||||
|
||||
### טבלת מעקב שאלות — סעיף 6
|
||||
|
||||
| שאלה | סטטוס | תשובה |
|
||||
|------|-------|-------|
|
||||
| מה פורמטי הקלט? | ✅ מלא | PDF, DOCX, MD — כל מסמך שנמסר לוועדה (מסעיף 1) |
|
||||
| מה סוגי המסמכים? | ✅ מלא | ערר, תשובה, תגובה, פרוטוקול, תכנית, היתר, פסקי דין, החלטות (מסעיף 1) |
|
||||
| מה הפלט? | ✅ מלא | DOCX מעוצב RTL, כמעט מוכן לחתימה (מסעיף 1) |
|
||||
| מה סוגי הערר? | ✅ מלא | רישוי (1xxx), היטל השבחה (8xxx), פיצויים (9xxx) — סגנון שונה לכל אחד |
|
||||
| מה שלבי התהליך? | ✅ מלא | 7 שלבים כולל man-in-the-middle (מסעיף 4) |
|
||||
| מה רמות האוטומציה? | ✅ מלא | 3 רמות: אוטומטי/שיתופי/אנושי (מסעיף 5) |
|
||||
|
||||
### דרישות פונקציונליות — לפי שלבי התהליך
|
||||
|
||||
#### שלב 1: קלט מסמכים
|
||||
|
||||
| מזהה | דרישה | עדיפות |
|
||||
|------|-------|--------|
|
||||
| ק-1 | המערכת מקבלת קבצי PDF, DOCX, MD | חובה |
|
||||
| ק-2 | המערכת מחלצת טקסט מלא מכל מסמך (כולל OCR לסרוקים) | חובה |
|
||||
| ק-3 | המערכת מסווגת כל מסמך לסוג (ערר/תשובה/פרוטוקול וכו') | חובה |
|
||||
| ק-4 | המערכת מזהה את הצדדים (עוררים, משיבים, ועדה, מבקשי היתר) | חובה |
|
||||
| ק-5 | המערכת מזהה את סוג הערר (רישוי/השבחה/פיצויים) לפי מספר התיק | חובה |
|
||||
| ק-6 | המערכת מודדת גודל כל החומרים בטוקנים ומתריעה אם חורגים מ-80% של context window | חובה |
|
||||
| ק-7 | כשחומרים חורגים — המערכת מפעילה אסטרטגיית סיכום/חלוקה עם סדר עדיפויות (ערר ותשובה קודם לנספחים) | חובה |
|
||||
| ק-8 | **הגנת prompt injection** — הפרדה בין הוראות מערכת לתוכן מסמכים. סניטיזציה של קלט ממסמכי צדדים חיצוניים | חובה |
|
||||
| ק-9 | **איחוד תיקים** — המערכת תומכת בתיק שמאחד כמה עררים (כמו 1078+1083). בלוק ה מגדיר כמה מספרי תיק, בלוק ז מכסה טענות של כל העוררים | רצוי |
|
||||
|
||||
#### שלב 2: עיבוד וניתוח
|
||||
|
||||
| מזהה | דרישה | עדיפות |
|
||||
|------|-------|--------|
|
||||
| ע-1 | המערכת מחלצת טענות מכתבי טענות — לפי צד | חובה |
|
||||
| ע-2 | המערכת מזהה תכניות חלות על המקרקעין | חובה |
|
||||
| ע-3 | המערכת מזהה פסיקה שמצוטטת במסמכים | חובה |
|
||||
| ע-4 | המערכת מציגה סיכום חומרים לחיים לפני כתיבה | חובה |
|
||||
|
||||
#### שלב 3: הזנת תוצאה (man-in-the-middle)
|
||||
|
||||
| מזהה | דרישה | עדיפות |
|
||||
|------|-------|--------|
|
||||
| ת-1 | חיים מזין את התוצאה שדפנה קבעה: דחייה / קבלה / קבלה חלקית | חובה |
|
||||
| ת-2 | חיים מזין נימוק (אם דפנה נתנה) — טקסט חופשי | חובה |
|
||||
| ת-3 | אם אין נימוק — המערכת מפעילה שלב סיעור מוחות (שלב 4א). גם אם יש נימוק — חיים יכול לבקש סיעור מוחות כאופציה | חובה |
|
||||
|
||||
#### שלב 4א: סיעור מוחות (כשאין נימוק)
|
||||
|
||||
| מזהה | דרישה | עדיפות |
|
||||
|------|-------|--------|
|
||||
| ס-1 | המערכת מציגה את הטענות המרכזיות מהחומר | חובה |
|
||||
| ס-2 | המערכת מציעה 2-3 כיוונים אפשריים לנימוק (לא המלצה אחת) | חובה |
|
||||
| ס-3 | חיים והמערכת מנהלים שיח עד שמגיעים לכיוון מוסכם | חובה |
|
||||
| ס-4 | התוצר: מסמך כיוון — נימוקים מרכזיים, סדר, פסיקה רלוונטית | חובה |
|
||||
| ס-5 | **לא מתחילים לכתוב דיון לפני שיש כיוון מאושר** | חובה |
|
||||
|
||||
#### שלב 4ב: כתיבת טיוטה
|
||||
|
||||
| מזהה | דרישה | עדיפות |
|
||||
|------|-------|--------|
|
||||
| כ-0 | המערכת ממלאת אוטומטית בלוקים א-ד (כותרת, הרכב, צדדים, "החלטה") ויב (חתימות) ממטא-דאטה של התיק | חובה |
|
||||
| כ-1 | המערכת כותבת בלוק אחרי בלוק לפי סדר: ה → ו → ז → ח → ט → י → יא | חובה |
|
||||
| כ-2 | כל בלוק נכתב בסגנון דפנה — טון, ביטויי מעבר, מבנה | חובה |
|
||||
| כ-3 | סגנון הכתיבה מותאם לסוג הערר (חם לרישוי, קר להשבחה) | חובה |
|
||||
| כ-4 | בלוק ח נכתב רק אם היו הליכים מעבר לדיון פשוט (סיור/השלמות) | חובה |
|
||||
| כ-5 | בלוק ט — רישום תכניות תמיד. פרק נפרד רק כשמורכבות תכנונית מצדיקה | חובה |
|
||||
| כ-6 | בלוק י — CREAC: מסקנה בפתיחה, כלל, הסבר, יישום, מסקנה | חובה |
|
||||
| כ-7 | בלוק י — מענה לכל טענה שהוצגה בבלוק ז | חובה |
|
||||
| כ-8 | **כלל ברזל: המערכת מצטטת רק מה שסופק כמסמך** | חובה |
|
||||
| כ-9 | רקע ניטרלי (בלוק ו) — ניטרליות לקסיקלית (אין מילות שיפוט) **וגם** מבנית (סדר הצגת עובדות מאוזן, אורך יחסי של סעיפים לא מטה, בחירת עובדות לא סלקטיבית) | חובה |
|
||||
| כ-10 | ללא כפילות (בלוק י) — הפניות לבלוקים קודמים, לא חזרה | חובה |
|
||||
| כ-11 | משקלות בלוקים לפי יחסי הזהב (סוג ערר × תוצאה) | חובה |
|
||||
| כ-12 | **שמירת מצב ביניים** — אחרי כל בלוק שנכתב, המצב נשמר ב-DB. חיים יכול להפסיק ולהמשיך מחר | חובה |
|
||||
| כ-13 | **recovery** — אם המערכת נופלת, חיים ממשיך מהבלוק האחרון שנשמר | חובה |
|
||||
| כ-14 | **חזרה אחורה** — חיים יכול לחזור לבלוק קודם ולכתוב אותו מחדש. בלוקים תלויים מתעדכנים בהתאם | חובה |
|
||||
| כ-15 | **ניהול גרסאות** — כל בלוק שומר היסטוריית גרסאות. חיים יכול לחזור לגרסה קודמת של בלוק ספציפי | רצוי |
|
||||
|
||||
#### שלב 5: פלט
|
||||
|
||||
| מזהה | דרישה | עדיפות |
|
||||
|------|-------|--------|
|
||||
| פ-0 | **בדיקת QA אוטומטית לפני ייצוא** — ולידציה של: כל הפניה מוולדת (grounding), כל טענה נענתה, רקע ניטרלי, משקלות בטווח, מספור רציף. אם נכשל — לא מייצא, מציג דוח שגיאות | חובה |
|
||||
| פ-1 | ייצוא DOCX מעוצב — גופן David, RTL, כותרות, מספור סעיפים רציף | חובה |
|
||||
| פ-2 | מקומות תמונה מסומנים (GIS, תשריט, סיור) | רצוי |
|
||||
| פ-3 | הגדרות "להלן" מופיעות לפני השימוש הראשון | חובה |
|
||||
|
||||
#### שלב 6: הגהת דפנה ותיקונים
|
||||
|
||||
| מזהה | דרישה | עדיפות |
|
||||
|------|-------|--------|
|
||||
| ה-1 | חיים שולח את ה-DOCX לדפנה (מייל / שיתוף קובץ — מחוץ למערכת) | חובה |
|
||||
| ה-2 | דפנה מגיהה ומתקנת ב-Word — עם track changes | חובה |
|
||||
| ה-3 | חיים מעלה את הגרסה הסופית (DOCX שדפנה חתמה) בחזרה למערכת | חובה |
|
||||
| ה-4 | המערכת מזהה שזו גרסה סופית (לא טיוטה) ומפעילה את לולאת הלמידה | חובה |
|
||||
| ה-5 | שמירת הגרסה הסופית ב-DB עם קישור לטיוטה המקורית | חובה |
|
||||
|
||||
#### שלב 7: לולאת למידה
|
||||
|
||||
| מזהה | דרישה | עדיפות |
|
||||
|------|-------|--------|
|
||||
| ל-1 | קליטת גרסה סופית (שדפנה חתמה) בחזרה למערכת | חובה |
|
||||
| ל-2 | השוואת טיוטה לגרסה סופית — זיהוי מה שונה | חובה |
|
||||
| ל-3 | חילוץ לקחים — ביטויי מעבר חדשים, דפוסי כתיבה שהשתנו, שגיאות חוזרות | חובה |
|
||||
| ל-4 | עדכון בסיס הידע: הוספת ביטויים חדשים ל-transition_phrases, עדכון יחסי זהב, עדכון דוגמאות ב-RAG | חובה |
|
||||
| ל-5 | **מנגנון עדכון:** לא fine-tuning אלא עדכון RAG index + few-shot examples + prompt engineering. הגרסה הסופית הופכת לדוגמה שה-prompt מפנה אליה | חובה |
|
||||
| ל-6 | מנגנון rollback — אם עדכון מדרדר איכות (אחוז שינוי עולה), חזרה למצב קודם | חובה |
|
||||
|
||||
---
|
||||
|
||||
## סעיף 7: דרישות לא-פונקציונליות
|
||||
|
||||
| מזהה | קטגוריה | דרישה | עדיפות |
|
||||
|------|---------|-------|--------|
|
||||
| לפ-1 | שפה | כל הממשק, הפלט והשיח בעברית | חובה |
|
||||
| לפ-2 | שפה | תמיכה מלאה ב-RTL — בממשק, ב-DOCX, ובטבלאות | חובה |
|
||||
| לפ-3 | ביצועים | טיוטה שלמה תוך שעות (לא ימים) — יעד: יום עבודה אחד כולל סיעור מוחות | חובה |
|
||||
| לפ-4 | ביצועים | חיפוש תקדימים (RAG) — תשובה תוך 10 שניות | רצוי |
|
||||
| לפ-4א | ביצועים | כתיבת בלוק בודד — עד 5 דקות לבלוקים ה-ט, עד 15 דקות לבלוק י (opus + thinking) | רצוי |
|
||||
| לפ-4ב | ביצועים | כתיבה אסינכרונית — חיים מפעיל כתיבת בלוק וממשיך לעבוד. התראה כשהבלוק מוכן | רצוי |
|
||||
| לפ-5 | דיוק | **מנגנון grounding** — כל הפניה לפסיקה/חקיקה/מסמך מקושרת למסמך מקור ספציפי עם citation tracking | חובה |
|
||||
| לפ-5א | דיוק | **ולידציה אוטומטית** — כל ציטוט/הפניה נבדק מול המסמכים שסופקו. הפניה שלא עוברת ולידציה = נחסמת (לא נכנסת לטיוטה) | חובה |
|
||||
| לפ-5ב | דיוק | **מדד: 0% הפניות לא מוולדות** — לא שאין הזיות, אלא שכל הזיה נתפסת לפני שנכנסת לטיוטה | חובה |
|
||||
| לפ-6 | דיוק | ציטוטים — נאמנות מוחלטת למקור. לא לשנות מילים, לא לקצר בלי לציין | חובה |
|
||||
| לפ-7 | אבטחה | חומרי התיקים חסויים — לא נשלחים לשירותים חיצוניים מלבד Anthropic API | חובה |
|
||||
| לפ-8 | אבטחה | ניהול סודות דרך Infisical — לא hardcoded | חובה |
|
||||
| לפ-9 | זמינות | המערכת רצה על שרת Nautilus — זמינה 24/7 | רצוי |
|
||||
| לפ-10 | תחזוקה | גיבוי DB יומי אוטומטי | חובה |
|
||||
| לפ-11 | ממשק | מינימום ממשק — עבודה דרך Claude Code (CLI), לא דרך web UI | חובה |
|
||||
| לפ-12 | מעקב | כל פעולה מתועדת — מי הזין, מתי, מה שונה | רצוי |
|
||||
|
||||
---
|
||||
|
||||
## סעיף 8: MVP — גרסה מינימלית
|
||||
|
||||
### אין MVP — מוצר מלא בלבד
|
||||
|
||||
**אין גרסה מצומצמת.** כל הדרישות הפונקציונליות והלא-פונקציונליות הכרחיות. המערכת עובדת במלואה או לא עובדת.
|
||||
|
||||
**הנימוק:** המוצר פועל בסביבת אמת — החלטות משפטיות שעומדות לביקורת שיפוטית. טעות (ציטוט שגוי, טענה שלא נענתה, רקע לא ניטרלי) היא לא באג שאפשר לתקן בגרסה הבאה — היא עלולה להגיע לבית המשפט העליון.
|
||||
|
||||
### מגבלת scope גרסה ראשונה
|
||||
|
||||
**הגרסה הראשונה מכסה רישוי ובנייה (1xxx) והיטל השבחה (8xxx) בלבד.**
|
||||
|
||||
אין נתוני אימון לפיצויים (9xxx) — המערכת לא תקבל תיקי פיצויים עד שנלמד מהחלטות מהסוג הזה. כשתיק פיצויים מוזן — המערכת מתריעה ומסרבת לכתוב.
|
||||
|
||||
**קריטריונים להרחבה לפיצויים:**
|
||||
- לפחות 3 החלטות סופיות מסוג 9xxx נקלטו ופורקו
|
||||
- parser מכויל לסוג הזה
|
||||
- יחסי זהב מוגדרים
|
||||
|
||||
### תוכנית השקה — לא MVP אלא מבחן הסמכה
|
||||
|
||||
במקום "MVP → שיפור" — תהליך של **מבחן הסמכה** לפני שימוש אמיתי:
|
||||
|
||||
| שלב | תוכן | קריטריון מעבר |
|
||||
|-----|-------|--------------|
|
||||
| שלב א — פיתוח | בניית כל 42 הדרישות | כל הדרישות ממומשות |
|
||||
| שלב ב — מבחן על תיק שהושלם | המערכת כותבת החלטה לתיק שכבר יש לו החלטה סופית (למשל הכט) | השוואת הטיוטה להחלטה הסופית — פער קטן מ-10% |
|
||||
| שלב ג — מבחן על תיק חי | המערכת כותבת טיוטה לתיק אמיתי שדפנה טרם כתבה | דפנה בודקת — אם שינתה פחות מ-10% → עובר |
|
||||
| שלב ד — שימוש מבצעי | שימוש שוטף עם לולאת למידה | יעד: 98% ללא שינוי |
|
||||
|
||||
---
|
||||
|
||||
## סעיף 9: מדדי הצלחה (KPIs)
|
||||
|
||||
| מדד | תקין | הצלחה | מדידה |
|
||||
|-----|------|-------|-------|
|
||||
| **אחוז שינוי** — כמה דפנה משנה מהטיוטה | עד 10% | עד 5% | ראה הגדרה מתמטית למטה. יתכייל אחרי 5 החלטות |
|
||||
|
||||
### הגדרה מתמטית: אחוז שינוי
|
||||
|
||||
**שיטת מדידה:** word-level edit distance (Levenshtein על מילים, לא תווים)
|
||||
|
||||
**נוסחה:**
|
||||
```
|
||||
אחוז_שינוי = (מספר_מילים_שהשתנו / סך_מילים_בטיוטה_המקורית) × 100
|
||||
```
|
||||
|
||||
**מה נספר כ"שינוי":**
|
||||
- **הוספת מילה** = 1 שינוי
|
||||
- **מחיקת מילה** = 1 שינוי
|
||||
- **החלפת מילה** = 1 שינוי
|
||||
- **הוספת סעיף שלם** = מספר המילים בסעיף החדש
|
||||
- **מחיקת סעיף שלם** = מספר המילים בסעיף שנמחק
|
||||
|
||||
**מה לא נספר:**
|
||||
- שינויי פיסוק (נקודה, פסיק) = 0
|
||||
- שינויי רווח/שורה חדשה = 0
|
||||
- שינוי סדר סעיפים (ללא שינוי תוכן) = 0
|
||||
|
||||
**דוגמה:**
|
||||
- טיוטה: 5,000 מילים
|
||||
- דפנה שינתה 400 מילים (200 מחיקות, 100 הוספות, 100 החלפות)
|
||||
- אחוז שינוי: 400/5,000 × 100 = **8%** → עומד ביעד (≤10%)
|
||||
| **זמן לטיוטה** — מרגע העלאת חומרים עד DOCX | יום עבודה | חצי יום | מדידת זמן מקצה לקצה |
|
||||
| **הפניות לא מוולדות** — ציטוטים/מקורות שלא עברו ולידציה מול מסמכים שסופקו | 0% | 0% | ולידציה אוטומטית עם grounding — כל הפניה מקושרת למסמך מקור |
|
||||
| **מענה לכל טענה** — כל טענה בבלוק ז מקבלת מענה בבלוק י | 100% | 100% | בדיקת קישור טענה ← מענה |
|
||||
| **משקלות בלוקים** — בטווח יחסי הזהב ±10% | עומד | עומד | ספירת מילים אוטומטית |
|
||||
| **רקע ניטרלי** — בלוק ו ללא מילות שיפוט או ציטוטי צדדים | עובר ולידציה | עובר ולידציה | סקריפט ולידציה אוטומטי |
|
||||
|
||||
---
|
||||
|
||||
## סעיף 10: סיכונים ומגבלות
|
||||
|
||||
| סיכון | חומרה | הסתברות | מנגנון הגנה |
|
||||
|-------|-------|---------|------------|
|
||||
| **הזיית מקור** — המערכת מצטטת פסק דין שלא קיים | קריטית | בינונית | כלל ברזל: רק מה שסופק. ולידציה אוטומטית של כל הפניה |
|
||||
| **רקע לא ניטרלי** — מילות שיפוט ברקע | גבוהה | בינונית | סקריפט ולידציה + רשימת מילים אסורות |
|
||||
| **טענה ללא מענה** — טענה מבלוק ז שלא נענתה בבלוק י | גבוהה | בינונית | קישור אוטומטי טענה ← מענה + בדיקת כיסוי |
|
||||
| **שאננות אוטומציה** — דפנה מפסיקה לבדוק טיוטות | גבוהה | גבוהה | מדידת אחוז שינוי בלולאת למידה — אם יורד מתחת ל-1% → התראה |
|
||||
| **הטיית אוטומציה** — חיים מאמץ תקדים שגוי | גבוהה | בינונית | הצגת 3-5 חלופות, לא המלצה אחת |
|
||||
| **סגנון לא מתאים** — המערכת כותבת בסגנון חיים ולא בסגנון דפנה | גבוהה | גבוהה בהתחלה | למידה מ-7 החלטות סופיות + לולאת למידה מתמשכת |
|
||||
| **שינוי פסיקה** — תקדים שהמערכת מסתמכת עליו בוטל/שונה | גבוהה | נמוכה | המערכת מסתמכת רק על מה שסופק — לא מחפשת באינטרנט |
|
||||
| **תלות ב-API** — Anthropic API לא זמין | בינונית | נמוכה | אין workaround — המערכת לא עובדת בלי API |
|
||||
| **חוסר בנתוני אימון** — אין החלטות לפיצויים (9xxx) | בינונית | ודאי | צריך להמתין עד שיהיו החלטות מהסוג הזה |
|
||||
| **מורכבות חריגה** — תיק עם 10+ צדדים או 50+ מסמכים | בינונית | נמוכה | אין מגבלה טכנית אבל אין ניסיון — צריך בדיקה |
|
||||
| **חריגת context window** — תיק מורכב עם חומרים רבים שחורגים מ-context window | קריטית | בינונית-גבוהה | מדידת גודל חומרים בטוקנים לפני עיבוד. אסטרטגיית chunking/summarization למסמכים ארוכים. סף התראה כשמתקרבים ל-80% מה-context. סדר עדיפויות: מסמכים קריטיים (ערר, תשובה) לפני נספחים |
|
||||
| **prompt injection ממסמכי מקור** — מסמכים מצדדים חיצוניים יכולים להכיל טקסט שמשפיע על ה-LLM | גבוהה | נמוכה | הפרדה בין הוראות מערכת לתוכן מסמכים. סניטיזציה של קלט. flagging של דפוסים חשודים |
|
||||
|
||||
### מגבלות ידועות
|
||||
|
||||
| מגבלה | השלכה |
|
||||
|-------|-------|
|
||||
| אין החלטות פיצויים (9xxx) לאימון | המערכת לא תוכל לכתוב החלטות פיצויים עד שנלמד מהן |
|
||||
| רק 7 החלטות סופיות לאימון | הסגנון עלול להיות לא מדויק — ישתפר עם כל החלטה שחוזרת מדפנה |
|
||||
| המערכת לא בודקת עדכניות פסיקה | אם תקדים בוטל — המערכת לא תדע. חיים אחראי לבדוק |
|
||||
| המערכת לא מחפשת פסיקה באינטרנט | רק מה שסופק כמסמך — יתרון (אין הזיות) וחיסרון (עלולה לפספס) |
|
||||
Reference in New Issue
Block a user