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>

docs/product-specification.md

@@ -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 החלטות סופיות לאימון | הסגנון עלול להיות לא מדויק — ישתפר עם כל החלטה שחוזרת מדפנה |
+| המערכת לא בודקת עדכניות פסיקה | אם תקדים בוטל — המערכת לא תדע. חיים אחראי לבדוק |
+| המערכת לא מחפשת פסיקה באינטרנט | רק מה שסופק כמסמך — יתרון (אין הזיות) וחיסרון (עלולה לפספס) |