diff --git a/.claude/agents/HEARTBEAT.md b/.claude/agents/HEARTBEAT.md
index ecdc99a..55d4841 100644
--- a/.claude/agents/HEARTBEAT.md
+++ b/.claude/agents/HEARTBEAT.md
@@ -222,18 +222,22 @@ python3 /home/chaim/legal-ai/scripts/notify.py \
 
 ---
 
-## §7. סטטוסי תיק תקפים (case status flow)
+## §7. סטטוסי תיק (case status flow)
 
-הסטטוסים שאתה עשוי לראות ב-`case.status` (לפי `legal-ceo.md` "מפת סטטוסים"):
+**מקור-האמת היחיד** למודל-הסטטוסים: `mcp-server/src/legal_mcp/case_status_model.py` (חשוף ב-`GET /api/status-model`; ה-enum, ה-`STATUS_ORDER` וה-frontend נגזרים ממנו). 12 הסטטוסים הקנוניים, לפי 5 השלבים:
 
 ```
-new → proofread → documents_ready → analyst_verified → research_complete*
+קליטה          : new · processing
+הכנה           : documents_ready
+ניתוח וכיוון    : analyst_verified · research_complete · outcome_set · direction_approved
    → [שער שטן-מליץ: red-team אוטומטי → עצירת-אישור לידים ע"י היו"ר]
-   → outcome_set → direction_approved → analysis_enriched → ready_for_writing
-   → drafted → qa_passed / qa_failed → exported
+כתיבת טיוטה     : qa_review · drafted
+סגירה          : exported · reviewed · final
 ```
 
-`research_complete` — **valid status** (לא legacy מחוסר תוקף). מנותב ע"י `legal-researcher.md` שלב 5 כשמחקר תקדימים רץ בנפרד מהמנתח (תרחיש מתקדם). ה-CEO יודע לטפל בו כאילו זה `analyst_verified` (ראה `legal-ceo.md` "מפת סטטוסים").
+`analyst_verified` ו-`research_complete` הם **סטטוסים קנוניים מהמעלה הראשונה** (לא legacy) — המנתח/חוקר מציבים אותם, ומקומם בשלב "ניתוח וכיוון". `research_complete` מנותב ע"י `legal-researcher.md` שלב 5 כשמחקר תקדימים רץ בנפרד מהמנתח; ה-CEO מטפל בו כמו `analyst_verified`.
+
+> מצבי-ביניים ישנים שעדיין עשויים להופיע מסוכנים מסוימים (`proofread`, `analysis_enriched`, `ready_for_writing`, `qa_passed`/`qa_failed`) **אינם** בקבוצה הקנונית — הם נמפים-לשלב לתצוגה בלבד (fallback ב-`case-status.ts`) ואינם ניתנים-לבחירה ידנית. אם נדרש לקבע אחד מהם — להוסיף ל-`case_status_model.py` (המקור-היחיד).
 
 > **שער שטן-מליץ (red-team) — שער-קבע אחרי הניתוח (ל-CEO).** ברגע שהניתוח עבר (`analyst_verified`/`research_complete`, `analysis-and-research.md` תקין), ה-CEO **חייב** להפעיל אוטומטית את שטן-מליץ (Gemini, `gemini_local`) **לפני** הכותב, ואז **לעצור לאישור-יו"ר של הלידים** (issue ראשי ל-`in_review`). רק לידים שהיו"ר אישר מומרים ל-`chair_directions` (`record_chair_feedback` → `get_chair_directions` → `approve_direction`); הלידים הגולמיים **לעולם לא** מוזנים לכותב או להחלטה — קלט-יו"ר בלבד (G10 / INV-AH / INV-LRN5). זרימה מלאה: `legal-ceo.md` "שלב A2"/"שלב A3". זה שער-קבע, לא on-demand.
 
diff --git a/.claude/agents/legal-ceo.md b/.claude/agents/legal-ceo.md
index 38e39b2..33dcd4c 100644
--- a/.claude/agents/legal-ceo.md
+++ b/.claude/agents/legal-ceo.md
@@ -806,7 +806,7 @@ ls data/cases/$CASE_NUMBER/documents/research/analysis-and-research.md
 | `proofread` | מגיה | → צור issue למנתח משפטי (ראה תבנית למטה) |
 | `documents_ready` | מנתח | → שלב A (בדיקות שלמות + שליליות + מתודולוגיה). אם עובר → עדכן ל-`analyst_verified`, ואז **שלב A2 (שער שטן-מליץ, אוטומטי)** — אל תקפוץ לשלב B לפני שהשער רץ והיו"ר אישר לידים (A3) |
 | `analyst_verified` | CEO (אחרי שלב A) | → **קודם שער שטן-מליץ:** אם אין `critique-gemini.md` → שלב A2 (הפעל שטן-מליץ אוטומטית). אם יש `critique-gemini.md` שטרם הוצג ליו"ר → שלב A3 (עצירת-אישור לידים). **רק אחרי שהיו"ר אישר/דחה לידים** → שלב B (סיכום + שאלת תוצאה לחיים). המנתח כבר ביצע את המחקר כחלק מהניתוח — אין ליצור issue לחוקר. |
-| `research_complete` | מנתח / חוקר תקדימים (valid status — legacy + תרחישים מתקדמים) | → **קודם שער שטן-מליץ (A2/A3)** כמו ב-`analyst_verified`, ורק אחרי אישור-יו"ר ללידים → שלב B. **זה סטטוס תקף**, לא שגיאה. בזרימה הרגילה המנתח מגדיר `documents_ready`, אבל אם החוקר רץ בנפרד (`legal-researcher.md` שלב 5) הוא מעדכן ל-`research_complete`. אם תראה סטטוס זה, בדוק שגם `analysis-and-research.md` וגם `precedent-research.md` קיימים, ואז המשך לשער שטן-מליץ ואז §B. |
+| `research_complete` | מנתח / חוקר תקדימים (**סטטוס קנוני**, שלב "ניתוח וכיוון" — מקור-אמת: `case_status_model.py`) | → **קודם שער שטן-מליץ (A2/A3)** כמו ב-`analyst_verified`, ורק אחרי אישור-יו"ר ללידים → שלב B. **זה סטטוס תקף**, לא שגיאה. בזרימה הרגילה המנתח מגדיר `documents_ready`, אבל אם החוקר רץ בנפרד (`legal-researcher.md` שלב 5) הוא מעדכן ל-`research_complete`. אם תראה סטטוס זה, בדוק שגם `analysis-and-research.md` וגם `precedent-research.md` קיימים, ואז המשך לשער שטן-מליץ ואז §B. |
 | `outcome_set` | CEO (אחרי שחיים בחר) | → האם יש claim_handling? אם לא → שלב B המשך (טבלת bundle/skip). אם כן → שלב C |
 | `direction_approved` | CEO (אחרי שחיים אישר) | → צור issue למנתח (c26e9439) ל-pass 2: העמקת ניתוח ואימות פסיקה |
 | `analysis_enriched` | מנתח (pass 2) | → שלב D2: צור issue לכותב (7ed8686f) |
diff --git a/.claude/agents/legal-qa.md b/.claude/agents/legal-qa.md
index 4e09486..91c06b2 100644
--- a/.claude/agents/legal-qa.md
+++ b/.claude/agents/legal-qa.md
@@ -179,10 +179,11 @@ tools:
 בדוק `case_get(case_number).status` — הוא צריך להיות בערכים תקפים. הזרימה הכוללת:
 
 ```
-new → proofread → documents_ready → analyst_verified → research_complete (legacy/optional)
-   → outcome_set → direction_approved → analysis_enriched → ready_for_writing
-   → drafted (אתה כאן!) → qa_passed / qa_failed → exported
+new → processing → documents_ready → analyst_verified → research_complete
+   → outcome_set → direction_approved → qa_review → drafted (אתה כאן!)
+   → exported → reviewed → final
 ```
+(מקור-אמת יחיד: `case_status_model.py` / `GET /api/status-model`. `analyst_verified`+`research_complete` קנוניים, שלב "ניתוח וכיוון". מצבי-ביניים ישנים כמו `proofread`/`analysis_enriched`/`qa_passed` נמפים-לשלב לתצוגה בלבד.)
 
 ⚠️ **`research_complete` הוא valid status** (לא bug, לא legacy ערומה). ב-`legal-researcher.md` שלב 5 הוא הסטטוס שהחוקר מגדיר בסיום מחקר. אם תיק במצב זה נשלח אליך לפני `drafted` — דווח, אל תכשיל.
 
diff --git a/scripts/backfill_case_status_trim.py b/scripts/backfill_case_status_trim.py
index 677421a..7f8cbea 100644
--- a/scripts/backfill_case_status_trim.py
+++ b/scripts/backfill_case_status_trim.py
@@ -12,8 +12,6 @@ Mapping (removed → kept):
 
     uploading          → processing
     in_progress        → outcome_set
-    analyst_verified   → documents_ready
-    research_complete  → documents_ready
     brainstorming      → outcome_set
     analysis_enriched  → direction_approved
     ready_for_writing  → direction_approved
@@ -50,12 +48,14 @@ from legal_mcp.services import db  # noqa: E402
 logging.basicConfig(level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s")
 log = logging.getLogger("status-trim")
 
-# removed status → nearest preceding kept status
+# removed status → nearest preceding kept status.
+# NOTE (2026-06-30): analyst_verified + research_complete were RE-CANONICALISED
+# into the status model (legal_mcp/case_status_model.py, "thinking" phase) — they
+# are valid statuses again, so they were removed from this map. Do NOT downgrade
+# them; only genuinely-removed markers remain below.
 STATUS_MAP = {
     "uploading":         "processing",
     "in_progress":       "outcome_set",
-    "analyst_verified":  "documents_ready",
-    "research_complete": "documents_ready",
     "brainstorming":     "outcome_set",
     "analysis_enriched": "direction_approved",
     "ready_for_writing": "direction_approved",