---
name: feature-impact
description: >-
  "מה זה שובר?" — ניתוח השפעה חובה לפני ותוך כדי הוספת תכונה חדשה או שינוי
  התנהגות במנהל חלוקה. יש לטעון את הסקיל הזה בכל פעם שמבקשים "תוסיף", "תעשה
  שיהיה אפשר", "כפתור חדש", "תכונה", "שנה את ההתנהגות", או כל שינוי שנוגע
  ליותר מפונקציה אחת — לפני שכותבים קוד. הוא מכריח לענות על שלוש שאלות:
  (1) מה השינוי יכול לשבור (נתונים, סנכרון בין 2 מחשבים, מצב בשרת ימות, זרימות
  קיימות, בדיקות ולינטים); (2) אילו כפתורים/מצבים במסך רלוונטיים במצב החדש ואילו
  צריכים להינעל, להיעלם או להופיע; (3) מה חסר כדי שהתכונה תהיה שלמה במסכים
  אחרים (הגדרות, היסטוריה, אקסל, הדפסה, תגים, סנכרון, תיעוד, בדיקות). משלים את
  כלל ה-Impact Analysis המדורג (זיכרון feedback-impact-analysis) בצ'ק-ליסט קונקרטי
  של הפרויקט הזה. לא מחליף את tzintuk-check / selection-rule / db-migration —
  מפנה אליהם כשהשינוי נוגע לתחומם.
---

# feature-impact — "מה זה שובר, מה נשאר רלוונטי, מה חסר"

יהודה (המשתמש) **לא מתכנת**. הסקיל הזה הוא לי: לחשוב לפני שאני נוגע בקוד, ולסיים
תכונה שלמה ולא חצי. ההיקף לפי כלל ה-Impact Analysis המדורג (זיכרון
`feedback-impact-analysis`): שינוי **מקומי** ⇒ סעיף 1 בקצרה ומימוש; שינוי **בעל השפעה**
(פונקציה בכמה מקומות / שינוי התנהגות) ⇒ סעיפים 1–2; שינוי **מערכתי** (API, state, מודל
נתונים, זרימה, מסך מרכזי, מנגנון משותף) ⇒ כל שלושת הסעיפים, כתובים לפני הקוד.

## 0. איפה הידע (לא לחפש מחדש)
- `CLAUDE.md` = ארכיטקטורה, כללים עסקיים והכרעות קבועות, המלכודות. **קרא את המקטע של
  המסך שנוגעים בו** לפני שאלות. הפירוט ההיסטורי לפי גרסה (מה תוקן, למה) — `docs/היסטוריית_גרסאות_מפורטת.md`;
  פתוחים/חשדות/"לאמת בשטח" — `NEXT_TASK.md`; מפת כל התיעוד — `docs/README.md`.
- הצינתוקים: סקיל `tzintuk-check` (9 זרימות, 30+ אינווריאנטים, בודק אוטומטי) — חובה כשנוגעים
  ב-`tabs/tzintukim.py` / `utils/yemot.py`. מי-מקבל: `selection-rule`. סכימה/סנכרון: `db-migration`.
  בנייה/שחרור/מלכודות: `manhal-haluka`. צילומים: `visual-check`.
- מצב הקו של ימות (תבניות, שלוחות, מה באמת בשרת): `yemot-line-state` + MCP `pitron-ivr`
  **לקריאה בלבד**.

## 1. מה זה יכול לשבור — לעבור על כל שורה ולענות "לא רלוונטי" או "כן: איך מטפלים"

**נתונים (עדיפות ראשונה):**
- טבלה/עמודה/setting חדשים? ⇒ מיגרציה אוטומטית + תאימות לאחור (`db-migration`). setting חדש:
  מסונכרן או פר-מחשב (`EXCLUDED_SETTINGS`)? סוד (סיסמה/מפתח) — לא לקבצים שנכנסים ל-git.
- שינוי משמעות של שדה קיים (למשל `template_id` שמשמש גם לתזמון) ⇒ כל מי שקורא אותו.
- רשומות **ישנות** (מגרסה קודמת) — האם הזרימה החדשה מטפלת בהן? (דוגמה 3.22: תזמון ישן על
  התבנית הראשית עדיין חוסם שליחה; תזמון חדש לא.)

**שני מחשבים (סנכרון):**
- הפעולה יכולה לקרות בו-זמנית משני מחשבים? LWW לפי `status_ts` — האם חותמת עתידית/כפילות
  אפשרית? האם ה-op החדש נזרע ב-snapshot (`seed`)?
- מצב "בשרת" משותף (תבנית של ימות, רשימה שמורה, תזמון) — שני המחשבים חייבים **להתכנס**
  לאותו אובייקט (אימוץ-לפי-תיאור, setting מסונכרן), אחרת נולדות תבניות-תאומות (תקרית 3/9).

**השרת של ימות (אם נוגעים בצינתוקים):**
- פקודה חדשה: האם היא **מחייגת** (⇒ `_DIAL_COMMANDS`, פעם אחת, בלי retry)? קריאה/כתיבה בטוחה
  ל-retry? מה קורה על 418 (נטפרי) / ‎-1 (אין תשובה — אולי כבר בוצע)?
- שדה של UpdateTemplate/ext.ini — מתועד? השרת של **הקו הזה** מקבל אותו? (REPEAT נדחה.) לאמת
  דרך MCP לפני שסומכים. **אסור לכתוב לשורש הקו.**
- אובייקטים שנשארים בשרת אחרי הפעולה (רשימה בתבנית, הקלטה, תזמון) — מי מנקה/דורס?

**זרימות קיימות:**
- אילו זרימות עוברות באותו קוד? (למשל: שליחה · בדיקה · שליחה חוזרת · תזמון · שיגור חכם · חלוקה
  קודמת · רשימה עצמאית · מעקב-חזרה · חידוש אחרי הפעלה · המחשב השני.) לכל אחת: "לא מושפעת" או
  "מושפעת: ...".
- שומרי-בטיחות קיימים (שומר שליחה-כפולה, `_changed_meanwhile`, `_retire_trackers`,
  `_results_belong_here`) — האם התכונה עוקפת אחד מהם?
- דיאלוג מודאלי חדש ⇒ הסנכרון רץ בתוכו: בדיקות-הקדם חייבות לחזור אחריו.
- worker/thread חדש ⇒ אסור לגעת בווידג'טים מתוכו; `start` מוחלף ב-no-op בבדיקות (I24).

**בדיקות ולינטים:**
- אילו בדיקות ב-`test_*.py` מניחות את ההתנהגות הישנה? (הרץ אותן **לפני** השינוי — baseline.)
- אילו לינטים ב-`check_tzintuk.py` יאדימו? לינט שאדום כי הכלל השתנה ⇒ עדכן את הלינט **ואת**
  `invariants.md`, לא תמחק.

## 2. המסך במצב החדש — מטריצת כפתורים/מצבים

לכל מסך שנוגעים בו, טבלה קצרה: **מצב** × **כפתור/רצועה** ⇒ גלוי / מוסתר / נעול / טקסט משתנה.
מצבים טיפוסיים בצינתוקים: לא-מוגדר · רשימה לא טעונה · טעונה · מעקב חי (poll) · מעקב-חזרה
(קלאסי) · תזמון ממתין (אחד / כמה / של המחשב השני / מגרסה ישנה) · קמפיין הסתיים · אין רשת.

שאלות חובה:
- הכפתור החדש — מתי הוא **חסר משמעות** (ולכן מוסתר) ומתי **מסוכן** (ולכן נעול עם הסבר)?
- כפתורים קיימים שהמצב החדש הופך ללא-רלוונטיים? (דוגמה: "בטל תזמון" יחיד כשיש כמה תזמונים ⇒
  שורה עם "בטל" לכל אחד.)
- כל טקסט שמבטיח משהו למפעיל ("המחשב לא חייב להיות דלוק", "מי שלא ענה ישמע…") — עדיין נכון?
- הודעות שגיאה: בשפה פשוטה, אומרות **מה לעשות**, ומבחינות בין רשת / נטפרי (`utils/netblock`) /
  השרת.
- `_update_metrics` / `refresh()` / `_reset_results` — האם ה-state החדש מתאפס/משתחזר נכון במעבר
  רשימה, בסנכרון, ובכניסה מחדש ללשונית?

## 3. מה חסר כדי שהתכונה תהיה שלמה — במסכים אחרים

לעבור על הרשימה ולסמן "לא רלוונטי" או "צריך":
- **הגדרות** — שדה/מתג/אימות (למשל אימות מספר מזוהה מול רשימת המאושרים).
- **היסטוריה** — הרשומה החדשה מוצגת? עם סטטוס בעברית (`status_he`)? פירוט לפי שם ומספר?
- **ייצוא אקסל / הדפסה / PDF** — עמודה חדשה? (`excel_utils`, `print_view`.)
- **"חלוקה ורישום"** — תג ליד השם (`_populate`) / הערה / ספירה.
- **המחשב השני** — רואה את התוצאה (op סנכרון, seed), ו**לא** מריץ אותה פעם שנייה (מי הבעלים? `device`).
- **חידוש אחרי הפעלה** — `_maybe_resume_tracking` / `_check_scheduled` מכירים את המצב החדש?
- **בדיקות** — סעיף ממוספר חדש ב-`test_tzintuk.py` (או `test_selection`/`test_sync`), לינט חדש
  כשהכלל ניתן לבדיקה סטטית.
- **תיעוד** — כלל/הכרעה קבועים בשורה-שתיים ב-`CLAUDE.md` (הפירוט `vX.YZ` — בראש חלק א' של `docs/היסטוריית_גרסאות_מפורטת.md`), מלכודת ב-`manhal-haluka/references/pitfalls.md` אם נלמדה,
  אינווריאנט ב-`tzintuk-check/references/invariants.md`, `NEXT_TASK.md` (מה נותר לאמת בשטח),
  `דיווח_תקלות.html` (מספר גרסה + מבנה מסך).
- **אימות** — בדיקה מדומה + צילום דרך `visual-check` (אימות הצילום רק דרך `gemini_task.py -f`),
  ומה **לא** ניתן לאמת בלי הקו האמיתי ⇒ לכתוב במפורש ליהודה.

## 4. פורמט הפלט (לפני הקוד, קצר)
```
היקף: מקומי / בעל השפעה / מערכתי
שובר: • … • …          (או "כלום מעבר ל-X")
מסך: מצב ⇒ כפתור: גלוי/מוסתר/נעול …
חסר להשלמה: • … • …
לא ניתן לאמת כאן: • …
```
ואז מימוש לפי סדר העדיפויות של הפרויקט: שלמות נתונים → כללים עסקיים → יציבות → UX → איכות קוד.