מה חדש ב-Shipnest

שני תיקונים מחקירת התראת התעבורה של Vercel, ובהמשך היום — מקבץ ייעולי תשתית לקראת צירוף לקוחות גדולים. באפליקציית השליחים: מכשיר שה-session שלו פג המשיך לשדר מיקום כל 2 דקות לנצח (מאות בקשות כושלות ביום), כי מנגנון העצירה עבר דרך ה-stores שריקים כשהמשימה רצה ברקע ללא האפליקציה. מעכשיו משימת הרקע עוצרת את עצמה ישירות ברגע שה-session נדחה סופית, ומוחקת מיקומים שהצטברו בתור — פרטיות, סוללה, ופחות רעש. בדף הליקוט: מגבלת הקצב על קריאות התצוגה הועלתה מ-30 ל-120 לדקה (המגבלה משותפת לכל הטאבים מאחורי IP משרדי אחד).

• דף היום של השליח נטען מהר משמעותית: אינדקס חדש הוריד את שאילתת הביקורים מ-317ms ל-19ms (נמדד על השליח העמוס ביותר), והשליפה הפסיקה לגרור את כל נתוני ה-JSON הכבדים
• רשימת הנוכחות (מי מחובר) עברה לשאילתה משותפת אחת לכל הטאבים במקום שאילתה לכל חיבור כל 5 שניות — הפחתה מסיבית בעומס על מאגר החיבורים המשותף
• סנכרון משלוחי שותפים שולף מהמסד רק את השדות הנחוצים במקום 300 רשומות JSON מלאות כל 10 דקות
• כל קריאות ה-Lionwheel שנצפו בפרודקשן על המפתח הגלובלי הוסבו למפתח הפר-לקוח — הכרחי כשכמה לקוחות גדולים יחלקו את המערכת

כשל שליחה חולף כבר לא נבלע בשקט: כששאלת צפי/תיאום ללקוח נכשלת בדרך לקבוצת השליח (תקלת ספק רגעית), הלקוח לא קיבל דבר ואיש לא ידע. מעכשיו נכתבת מיד הודעה פנימית לצוות בתיבת הלקוח כדי שנציג יטפל. בנוסף, לבקשת הבעלים, ביטוי-שידור מותאם שמסתיים בסימן שאלה דורש מעכשיו שורה עצמאית מדויקת — 'שלכם?' לבדו יפעיל שידור, אבל 'זה גם לקוח שלכם' בתוך משפט לא (הביטוי עודכן בהגדרות בהתאם).

עשרה דיווחי כשל, שבעה שורשים. מנסח-התשובות שענה בקול עוזר-AI ('אני מוכן לעזור! אנא שתף...') במקום תוכן — הטקסט הזה הגיע ללקוחות כתשובת השליח; מעכשיו קול-עוזר מזוהה (תבניות + מבנה) ומסווג כתקלת מודל, וללקוח מגיעות רק מילות השליח. תשובת צפי נקייה ('היום') עוברת ישירות בלי מודל בכלל, ו'רגע/שניה' לא סוגרות בירור — התשובה האמיתית שאחריהן נקלטת. תשובה קצרה של לקוח לשאלת נציג סמוכה ('בראשון בע"ה יהיה' על 'יש איסוף היום?') לא נתפרת יותר לבירור ישן. הודעת 'כתובת לא מעודכנת' לא טוענת עוד 'המשלוח נמסר' לפני שנמסר בפועל. ותרחיש השידור הפסיק להרעיש: הודעות-הסבר ארוכות ומספרים שהגיעו רק מציטוט אנושי ישן לא מקבלים עוד תשובות שגיאה — בלי לגעת בליבת השידור שעובדת היטב.

בהתאם לדרישת ה-prominent disclosure של Google Play להרשאת מיקום ברקע: לפני בקשת הרשאות המיקום בתחילת משמרת, אפליקציית השליחים מציגה כעת הסבר חד-פעמי — אילו נתוני מיקום נאספים, לאיזו מטרה, ושהאיסוף נמשך גם כשהאפליקציה סגורה, עם אישור מפורש. דחיית ההסבר מבטלת את תחילת המשמרת בצורה נקייה. האישור נשמר ואינו מוצג שוב. נדרש לקראת קידום הגרסה ל-production track בחנות; הופץ כעדכון OTA להתקנות 1.3.0.

מתג חדש בהגדרות הלקוח (לקוחות ← לקוח ← הגדרות ← 'ניתוק מהבוט') ללקוחות שלא רוצים לתקשר עם הבוט. כשהמתג דולק, הבוט לא שולח ללקוח שום הודעה — לא בקבוצת הוואטסאפ המקושרת ולא בצ'אט האישי — ולא מבצע עבורו פעולות אוטונומיות. פנייה של הלקוח שהבוט מזהה (שאלת צפי, ערעור על מסירה וכו') נרשמת כהערה פנימית בשיחת ה-inbox של הלקוח עם סימון לא-נקרא, כך שנציג מטפל ידנית. דיווח שליח על משלוח של הלקוח (אין מענה, כתובת שגויה, כשל מסירה, נזק) — שהיה מגיע ללקוח כהודעת בוט — הופך גם הוא להערת צוות שמציינת במפורש שהלקוח מנותק מהבוט. האכיפה בנויה בשלוש שכבות: פתרון יעד הצ'אט מחזיר 'אין יעד' ללקוח מנותק (וכל המסלולים הקיימים כבר יודעים ליפול משם להערת צוות), מנוע התרחישים עוצר לפני כל פעולה וכותב את ההערה, ושער אחרון בשכבת השליחה חוסם כל הודעת בוט לצ'אט של לקוח מנותק — גם ממסלול עתידי שישכח לבדוק. שליחה ידנית של נציג מה-inbox איננה מושפעת, וכך גם הודעות סטטוס מתוזמנות ותיאום איסופים יומי (שנשלטים בהגדרות נפרדות).

• מתג 'ניתוק מהבוט' בהגדרות הלקוח — הבוט מפסיק לחלוטין להתכתב עם הלקוח
• כל פנייה או אירוע שהבוט מזהה נרשמים כהערה פנימית לצוות עם סימון לא-נקרא, לטיפול ידני
• אכיפה בשלוש שכבות כולל שער אחרון בשכבת השליחה — גם מסלול עתידי לא יוכל לשלוח ללקוח מנותק
• שליחות ידניות של נציגים, הודעות מתוזמנות ותיאום איסופים יומי אינם מושפעים

כשמייבאים קובץ מחדש מתוך היסטוריית היבוא, המערכת שחזרה את תאריך האיסוף המקורי — מהפעם הראשונה שהקובץ הועלה. אם המשתמש לא שינה אותו ידנית, תאריך ישן (לעיתים מחודש קודם) נשלח לליונוויל. ליונוויל מחייבים לפי תאריך האיסוף המתוכנן, ולכן המשלוחים נכנסו לחיוב של החודש הלא נכון. כעת יבוא חוזר מתייחס לעצמו כעבודה חדשה שקורית עכשיו: תאריך איסוף שכבר עבר נדחף אוטומטית להיום, ותאריך עתידי לגיטימי (הזמנה מוקדמת) נשמר. כשהתאריך נדחף, מוצגת אזהרה ברורה שמבקשת מהמשתמש לוודא את התאריך לפני יצירת המשלוחים. התיקון חל גם על פורטל הלקוחות (אותו רכיב יבוא משותף).

הודעה מתוזמנת עם מספר טלפון בפורמט שגוי נכשלת באותו אופן בדיוק בכל ניסיון — המספר לא משתנה בין ניסיונות. עד כה המערכת ניסתה אותה שלוש פעמים (שלושה מחזורי cron) ורשמה כל כישלון כשגיאה חמורה ששולחת התראת וואטסאפ למנהל, על תקלה שאיש לא יכול לתקן (הלקוח פשוט הקליד מספר שגוי). כעת כשל כזה מסומן כסופי כבר בניסיון הראשון — לא נוסה שוב — ונרשם כאזהרה בלבד, בלי התראה. אותה התנהגות חלה על תבנית Meta שבורה (שגיאה 132018), שגם היא כישלון קבוע פר-הודעה. כשלים חולפים (timeout, עומס אצל הספק, שגיאת שרת) ממשיכים לנסות שוב עד לתקרה ולהתריע — כי מטח שלהם בבת אחת הוא בדיוק האופן שבו נפילת ספק אמיתית מתגלה. (הלולאה האינסופית עצמה כבר נעצרה קודם בזכות מנגנון ה-claim האטומי; זה מסיר את הרעש שנותר.) בנוסף נסגר פער כפילות ותיק: הודעות 'משלוח ניזוק' ו'כשל מסירה' ללקוח נשלחו מחדש בכל פעם שהשליח הזכיר שוב את המשלוח (אותה הודעה שלוש פעמים בשלושה ימים) — נוסף חסם פר-משלוח: נזק פעם אחת בשבוע, כשל מסירה פעם ב-48 שעות, והחסם נרשם רק אחרי שליחה שהצליחה כדי לא להשתיק שליחה ראשונה לגיטימית.

• טלפון לא-תקין / תבנית שבורה = כישלון קבוע → מסומן סופי בניסיון הראשון, אזהרה במקום שגיאה, ללא התראת מנהל
• כשלים חולפים ממשיכים לנסות ולהתריע — כדי שנפילת ספק אמיתית עדיין תזוהה

מניתוח שיחות אמת (26/07-03/08). (1) שומר האמינות (שמונע דיווח על פעולה או הצגת נתונים בלי קריאת כלי) פספס מקרה: העוזר פתח 'משכתי את פרטי המשלוח [ברקוד]:' והציג טבלת פרטים שלמה ומומצאת (נמען, כתובת, לקוח שולח — כולם בדויים) בלי לקרוא לאף כלי. שני חורים תוקנו — הפועל 'משכתי' לא היה מזוהה, וקישור ברקוד בין 'המשלוח' לנקודתיים שיבש את הזיהוי. בנוסף נוסף זיהוי ישיר של **טבלת פרטי-משלוח** (שלוש שורות שדה או יותר) שהוצגה בלי קריאת כלי — היא נדחית אוטומטית, כי טבלה כזו יכולה להגיע רק מקריאה למערכת. הזיהוי צר בכוונה כדי לא לפגוע בהצעה לגיטימית ('רוצה שאביא את הפרטים?') או בטבלה שאינה משלוח. (2) 'מה ממוצע זמן המסירה של לקוח X' נענה עם סטטיסטיקה **גלובלית של כל הלקוחות** (getDeliveryTimeStats לא ידע לסנן לפי לקוח) — נצפה 0.1-0.7 ימים כשהממוצע האמיתי של אותו לקוח הוא 2.27. נוסף סינון לפי לקוח (customerName/customerId) ולפי שליח (driverName), והכלי מחזיר כעת גם overall — הממוצע/חציון הכולל לישות שנשאלה — לצד הפירוט לפי עיר. אומת מול נתוני הפרודקשן; כל 1,959 הטסטים עוברים. תרחיש תיאום-המסירה כבר לא מנחש משלוחים: המסווג היה רשאי להצמיד כל מספר שהופיע בחלון שיחה של 6 שעות — גם משורת צוות ישנה על משלוח אחר — ושיחת תיאום איסוף שניהלו נציגים סווגה כבקשת לקוח ונשלחה לשליח עם כל ה-burst הגולמי, כולל תגי צוות ותיוגים. מעכשיו התרחיש פועל רק כשהלקוח עצמו נקב במספר (או ציטט הודעת בוט שלנו), ההודעה לשליח מכילה רק את מילות הלקוח אחרי ניקוי שורות צוות, ואם לא נותר טקסט ממשי — הבוט לא יורה. (3) הובהרה לעוזר מטריצת יכולות-השליחה, בעקבות שיחה שבה סתר את עצמו — פעם 'שלחתי' ופעם 'אני לא יכול לשלוח'. האמת: הוא שולח טקסט חופשי לשליח (בקבוצה בלבד) וללקוח העסקי, ולנמען הקצה רק תבנית אישור קבועה — ואין כלי לטקסט חופשי ישיר לנמען. ההנחיות אוסרות עליו מעכשיו גם להכחיש יכולת בצורה גורפת וגם להמציא 'נשלח' על יעד שאינו נתמך; הסתייגות חייבת להיות ממוקדת ליעד ולסוג.

• טבלת פרטי-משלוח מומצאת בלי קריאת כלי נדחית אוטומטית (השומר הורחב, בזהירות מפני התרעות שווא)
• 'ממוצע זמן מסירה של לקוח X' מסונן כעת לפי לקוח — קודם הוחזר נתון גלובלי שגוי (0.1 מול 2.27 ימים)
• getDeliveryTimeStats תומך בסינון לפי לקוח/שליח ומחזיר overall כולל לצד פירוט הערים
• מטריצת יכולות-שליחה ברורה לעוזר: שולח לשליח (קבוצה) וללקוח העסקי, לנמען רק תבנית — בלי הכחשה גורפת ובלי 'נשלח' מומצא

Lionwheel לא מודיעה לנו כשמשלוח נמחק אצלה, ולכן משלוח כזה נשאר אצלנו 'פתוח' לנצח ומחזיר 404 בכל סנכרון. שתי תקלות שהתגלו בחקירה: (1) תור הסנכרון (רשת הביטחון שממשיכה למשוך משלוחים פתוחים) מוין לפי 'סנכרון מוצלח אחרון', אבל כשל 404/429 לא עדכן את החותמת הזו — כך שאותם משלוחים מתים נשארו בראש התור ונמשכו שוב בכל ריצה, בעוד אלפי משלוחים חיים שמאחוריהם לא נבדקו אף פעם (נמדד: 84 משלוחים מתים נמשכו ~50 פעם כל אחד בשבוע, בזמן ש-4,662 משלוחים חיים לא סונכרנו ולו פעם אחת). (2) מנגנון המחיקה האוטומטית שאמור לזהות משלוח תקוע כבר היה קיים, אבל סף הזיהוי היה 'לפחות 2 כשלים והכשל הראשון לפני 3+ ימים'. הוחלף בכלל שמבקש המשתמש: 404 ב-3 ימים קלנדריים שונים (שעון ישראל) לפני מחיקה — ניסיון יום אחרי יום, ובאישור השלישי המשלוח נמחק. נוספה עמודה חדשה (last_sync_attempt_at) שנחתמת בכל ניסיון סנכרון ומשמשת כ-cursor של התור, כך שמשלוח שנבדק — חי או מת — יורד לסוף התור והרשימה מתנקזת בסבב מלא.

• עמודה חדשה last_sync_attempt_at: נחתמת בכל ניסיון (כולל 404/429), ושני ה-crons ממיינים לפיה — משלוח מת כבר לא חוסם את התור
• מחיקה אוטומטית לפי כלל ברור: 404 ב-3 ימים שונים ⇒ מחיקה. שמרני יותר מהסף הקודם (58 מועמדים במקום 394) ותואם ל'ניסיון יום אחרי יום'
• תיקון רעב-התור: לפני התיקון רק ~6-211 משלוחים סונכרנו ביום מתוך תור של 5,048 פתוחים; כעת התור מתנקז בסבב במקום לחזור על אותם ראשי-תור
• התלות במשתנה הסביבה AUTO_RESOLVE_DRY_RUN נותרה — כל עוד הוא דלוק בפרודקשן, הקרון רק מדפיס 'היה מוחק' ולא מוחק בפועל

עמודת מועד הביקור (visitAt) נשמרת ב-UTC ללא אזור זמן, אבל הדוחות המירו אותה לשעון ישראל בכיוון ההפוך — כל דלי נחת שש שעות מוקדם מדי וחצה גבולות של יום ושעה. בפועל: ביקור ב-00:00 בישראל דווח כ-18:00 של היום הקודם, ו-8,459 מתוך 73,192 הביקורים ב-45 הימים האחרונים (כ-12%) שובצו ליום הלא-נכון. תוקן בדוח הנהגים הכולל (הסדרה היומית ומפת החום יום/שעה), בדוח הפרטני לנהג, ובסנכרון הלילי של תמונות עלות המשלוח. במקביל התגלה שגם קיבוץ נקודות ה-GPS לפי יום נעשה לפי יום-UTC בעוד ספירות הביקורים לפי יום-ישראל — כך שהמרחק והשעות של יום מסוים לא התיישרו עם מספר המשלוחים שלו בגבולות היום; שני הצירים אוחדו כעת ליום ישראל, וציר הזמן של הגרף מונה ימי ישראל.

• המרת אזור-זמן בשאילתות הגולמיות תוקנה: עמודת timestamp-without-tz דורשת הכרזת UTC לפני ההמרה לישראל — אחרת ההסטה 6 שעות
• ספירת המשלוחים, המרחק, השעות והימים הפעילים מקובצים כולם לפי יום ישראל ומיושרים זה לזה
• הסנכרון הלילי של עלויות (cost-snapshot-reconcile) חישב יום שגוי — כעת תואם למנוע החי, כך שביקורי גבול-יום מתקבעים במקום להיחשב 'תקועים' כל לילה

הגדרות מצב השידור-היזום (כיבוי המשיכה האוטומטית, וסטטוסי ההצלחה/כישלון שמתעדכנים בחזרה בחנות) נזרקו בשקט בכל שמירה — שדות אלה לא היו ברשימת השדות המותרים של ה-API, כך שהמתג 'כבה משיכה אוטומטית' נראה עובד בטופס אבל הערך מעולם לא נכתב למסד הנתונים, והחנות המשיכה להימשך אוטומטית במקביל לכפתור. השדות נוספו לרשימה המותרת (יצירה ועדכון כאחד) כך שהמצב נשמר. בנוסף נוסף מתג מצב ברור ישירות בכרטיס החנות בפורטל, ליד כתובת ה-Webhook של הכפתור: מעבר בין 'משיכה אוטומטית לפי סטטוס' ל'רק שידור יזום (כפתור)' בלחיצה אחת, בלי צורך להיכנס להגדרות מתקדמות ולטעון סטטוסים.

• באג: disablePolling וסטטוסי ה-write-back של אישופ/קונימבו הושמטו ב-Zod ולא נשמרו — תוקן בשתי הסכמות (POST+PUT)
• מתג מצב חדש בכרטיס החנות: 'רק שידור יזום (כפתור)' מול 'משיכה אוטומטית', עם שמירה מיידית ומיזוג על ההגדרות הקיימות

עד היום ה-SDK של Sentry היה מחווט באפליקציית השליחים אבל כבוי — שדה ה-DSN היה ריק, כך שקריסות אצל שליחים בשטח נעלמו בלי זכר. נוצר חשבון Sentry (אחסון EU), וה-DSN הוזן לפרופילי ה-build של preview ו-production. תיקוני ההקשחה מאתמול פורסמו יחד עם ההפעלה כעדכון OTA להתקנות הקיימות.

סבב הקשחה רוחבי באפליקציית השליחים ובצד השרת שלה לקראת השקת גרסה. נסגרו פערי אובדן-ראיות (כפתור חזרה פיזי שמחק תמונות POD בלי אישור, אזהרת 'אין הוכחת מסירה' שהתעלמה מהוכחות בתור הסנכרון, תמונות סגירת גוביינא שלא נשמרו לאחסון יציב), נוספה ולידציה לשדות צ'ק בגוביינא, רישום טוקן פוש קיבל retry עם backoff וה-endpoint שלו כבר לא קורס כשהמכשיר לא רשום, נוסף מנגנון עדכון-חובה (426) מקצה לקצה עם מסך חוסם, מצב משמרת מדווח כעת לשרת במפורש כך שדשבורד האדמין לא תלוי רק ב-GPS, נוספו מגבלות קצב לכל נקודות ההעלאה, ומסכי הסגירות יושרו למערכת העיצוב ולנגישות.

• כפתור חזרה פיזי באנדרואיד עובר דרך אישור-זריקה וניקוי קבצים בכל מסכי ההוכחות (POD/חתימה/גוביינא/כשל)
• מנגנון עדכון-חובה: השרת אוכף MOBILE_MIN_APP_VERSION ומחזיר 426, האפליקציה מציגה מסך עדכון חוסם — והתור האופליין שומר על הוכחות עד לעדכון
• רישום טוקן פוש עמיד: retry עם backoff בצד האפליקציה + טיפול במכשיר לא-רשום בצד השרת
• מצב משמרת מפורש (start/stop) נשמר בשרת — 'בשטח' בדשבורד האדמין כבר לא תלוי רק בדגימות GPS
• ולידציית שדות צ'ק בגוביינא (תאריך אמיתי, ספרות בלבד) ורשימת רווחים עם עימוד במקום רינדור מאות שורות
• מגבלות קצב פר-משתמש על כל נקודות ההעלאה (POD/חתימה/גוביינא/סגירות/מיקום)

כשהשיגור לליונוויל נכשל ברגע ייבוא הזמנה מחנות אישופ (למשל מכסת קצב 429), ההזמנה נשמרה כמשלוח ממתין כדי שלא תאבד — אבל שום מנגנון לא ניסה לשגר אותה שוב, ומנגנון מניעת הכפילויות דילג עליה לנצח, כך שתקלה רגעית תקעה הזמנה עד התערבות ידנית. מעכשיו סנכרון החנויות מזהה משלוחים ממתינים כאלה ומשגר אותם מחדש אוטומטית עם המתנה מדורגת בין ניסיונות (5 דקות עד 6 שעות), גם בחנויות שעובדות במצב push. כישלון קבוע — כתובת שגויה או מיצוי הניסיונות — מסומן על המשלוח עם סיבת הכשל כדי שהצוות יראה אותו במקום לולאה שקטה. בנוסף: זמן ההמתנה לשליחת WhatsApp הועלה מ-15 ל-30 שניות בשני הספקים (Meta ו-Green API), ו-timeout בודד כבר לא שולח התראת מערכת למנהל — התראה נשלחת רק כשמצטברים 3 ומעלה תוך 30 דקות באותו ספק, סימן לתקלה אמיתית ולא לרעש רגעי.

שני תיקונים מדיווחי כשל. נמען שכתב 'תודה, לא צריך אחרי שבת' (=צריך לפני שבת) קיבל מהבוט קביעה הפוכה — עיכוב אספקה והערת 'לא לספק לפני' לשליח. מעכשיו שומר דטרמיניסטי מזהה שלילת-צורך וחוסם כל כתיבת דחייה או הערת-שליח מאותה שיחה עד הכרעת נציג — כולל ניסיון חוזר של המודל בהודעה הבאה (נעילה עמידה של 48 שעות). בנוסף, הודעת בקשת-ביטול לשולח ציטטה את נימוק הנמען כלשונו — כולל 'עיכוב משמעותי וחריגה מה-SLA' — וחשפה תלונה על השירות שלנו; מסנן הניסוח מסיר כעת פסוקיות-אשמה על עיכוב/תקלה שלנו מכל הודעה לשולח, תוך שמירת סיבות לגיטימיות ('הזמינה בטעות', 'לא הגיע לנקודת האיסוף').

אחרי שאינטגרציות אישופ וקונימבו אומתו ועובדות בפרודקשן, הוסרו שני נתיבי האבחון הפנימיים הזמניים (platform-only, קריאה-בלבד) ששימשו לשליפת מבנה ההזמנה הגולמי מהספקים בזמן הפיתוח — /api/admin/eshop-probe ו-/api/admin/konimbo-probe. ניקוי scaffolding; אין השפעה על לקוחות.

שלוש יכולות חדשות בשאלות צפי מקבוצות לקוחות. משימת איסוף משובצת — הבוט שואל את שליח האיסוף בקבוצתו בניסוח איסוף; ללא שיבוץ — פתק לצוות (נדרשת התערבות אנושית). שאלת צפי על משלוח שנכשל בו ניסיון מסירה — הלקוח מקבל שורת סטטוס בטוחה (ללא שמות שליחים, לעולם) והסבר כשל בניסוח בטוח שממופה מקטגוריות ולא מהטקסט הגולמי, כולל 'מתוכנן ניסיון נוסף' רק כשבאמת מתוכנן. וכשהכשל הוא כתובת או טלפון שגויים שטרם עודכנו — הבוט לא שולח שליח לניסיון אבוד אלא מבקש מהלקוח את הפרט המעודכן: טלפון נקלט ונכתב אוטומטית, כתובת מועברת לצוות לעדכון. תרחיש הבקשה (address_fix_request) הוא opt-in פר-חברה.

• צפי איסוף נשאל אצל שליח האיסוף המשובץ — כמו צפי מסירה
• כשל מסירה מוסבר ללקוח בניסוח בטוח, בלי שמות שליחים ובלי טקסט גולמי
• כתובת/טלפון שגויים שטרם תוקנו — הלקוח מתבקש לשלוח את הפרט כתנאי לניסיון נוסף
• חבילה בניסיון שלישי או חוזרת לשולח — לעולם לא מובטח ניסיון נוסף

עד היום כל בירור ידני מדף המשלוח (בירור צפי, שאלה לשליח, בקשת תמונת מסירה) הפעיל תזכורות אוטומטיות לקבוצת השליח באופן קבוע — בלי שום מתג. כשנפתחו חמישה בירורים באותה קבוצה, כל מחזור הפיל חמש שורות 'תזכורת' זהות בתוך שניות, פעמיים-שלוש ביום, ואיש לא הבין מאיפה זה מגיע. מעכשיו תזכורות הן בחירה מפורשת לכל פנייה — כפתור פעמון ליד שליחת הבירור — והאפשרות שמורה למשתמש בדרגת בעלים בלבד. ברירת המחדל תמיד כבויה. גם מתגי הנדנוד בהגדרות הבוט (נדנוד שאלות צוות ונדנוד פר-תרחיש) נעולים כעת לדרגת בעלים, ושמירת הגדרות על ידי משתמש אחר משמרת את ערכי הבעלים ללא שינוי. השרת אוכף את ההגבלה בכל המסלולים, כולל בירור צפי מרובה מרשימת המשלוחים. באותו יום תוקנו גם שני כשלי שיוך-תשובות בקבוצות: תשובה שכולה תיוג (@) של אדם אינה נחשבת עוד תשובה לשום שאלה — עד היום תיוג של עמיתה הועבר לשליח כ'עדכון מהשולח' וסגר את הבירור, כך שהטלפון האמיתי שנשלח שתי דקות אחריו נזרק; ותשובה שנכתבת דקות ספורות אחרי ששאלו את הכותב שאלה אנושית בקבוצה — במיוחד כשהשאלה ציטטה הודעה שלו — משויכת לשיחה ההיא ולא לבירור ישן של הבוט, אחרי ששעות הקבלה של מחסן לאיסוף הוצגו ללקוח אחר כחלון המסירה של המשלוח שלו. בהמשך היום בוצעה ביקורת רגרסיה מלאה על כל 86 דוחות הכשלים ההיסטוריים: אפס רגרסיות — כל תיקון עבר אומת שהוא עדיין קיים, מכוסה בטסט ושהמסלול אליו שלם. שלוש נקודות חשיפה שנמצאו טופלו מיד: שומר 'השיחה הסמוכה' צומצם לבירורים מול שליחים בלבד (כדי שלא ישתיק אישור-טלפון מילולי של לקוח), מחרוזת הקישור בין דיווח-ללא-ברקוד לתווית שאחריו חולצה לקבוע משותף (שינוי ניסוח לא ישבור עוד את ההתאוששות בשקט), ותיעוד פנימי מיושן עודכן.

• כפתור פעמון חדש ליד כל בירור לשליח — מפעיל תזכורות לפנייה זו בלבד, מוצג לבעלים בלבד
• פניות קיימות שנפתחו לפני השינוי מפסיקות להזכיר מיד
• מתגי הנדנוד בהגדרות הבוט נעולים לדרגת בעלים; שמירה של נציג אינה דורסת אותם
• בירור שקט (ללא תזכורות) ממתין לתשובה 24 שעות במקום לנעול את המשלוח ל-4 ימים

לקוח ששאל על צפי מסירה קיבל בחזרה, מילה במילה, את תגובת הקבלן שכוונה בכלל לצוות — שאלה-נגדית תפעולית על החזרת המשלוח. מנגנון ניסוח-הבטוח ללקוח דווקא שפט נכון שאין בתשובה שום תוכן להעברה, אבל מנגנון הגיבוי — שנועד להגן מתקלת AI רגעית — דרס את השיפוט ושלח את הטקסט הגולמי. מעכשיו שני המצבים מופרדים: שיפוט 'אין מה להעביר' מציף הודעה פנימית לצוות בתיבת הלקוח (עם ציטוט תשובת השליח) ולא שולח ללקוח דבר, בעוד תקלת AI אמיתית ממשיכה ליהנות מהגיבוי. ההודעה שנשפטה כלא-מתאימה גם נעצרת מהמשך עיבוד, כך שתרחיש אחר לא יפעל עליה בטעות. אותו תיקון הוחל גם על תרחיש תיאום-מועד המקביל.

בטבלת המשלוחים בפורטל הלקוחות, לצד אייקון "מדבקה הודפסה" הקיים, מופיע מעתה אייקון מגן בכל שורה של משלוח שיש לו הוכחת מסירה. ריחוף על האייקון פותח את תמונות ההוכחה עצמן ישירות מהטבלה — בלי להיכנס לדף המשלוח — ולחיצה על תמונה פותחת אותה בגודל מלא בלשונית חדשה. בנוסף: שליחת WhatsApp דרך Meta שנכשלת בשגיאה חולפת של Meta (קוד 131000) מנוסה כעת שוב אוטומטית — במקום להיכשל מיידית ולהציף התראת מערכת על כל שיבוש רגעי בצד Meta. ובהמשך היום — המשתנה {details} (בלוק פרטי המשלוח המלא: מספר, שם נמען, רחוב, דירה/קומה, כניסה וקוד, עיר, טלפון והערת מסירה) זמין מעתה בכל תבניות תרחישי הבוט — בכל התרחישים ובכל סוגי ההודעות שנוגעות למשלוח מזוהה (הודעות פתיחה, העברות תשובה, אישורי קבלה, הודעות ביטול/תלונה/עיכוב לשולח, אישורי שידור ועוד) — ולא רק בהודעות הפתיחה כפי שהיה. התבניות שמעדכנות טלפון או כתובת מציגות ב-{details} את הערך המעודכן שנכתב זה עתה, ותבנית שמכילה {details} כשאין בלוק זמין נשלחת נקייה — בלי להשאיר את הטוקן בהודעה.

כרטיסיית התפעול בדף המשלוח גדלה לשמונה ומעלה שורות שרובן ריקות ("לא בוצע", "לא הוגדר") — רעש שמסיח מהמידע האמיתי. העיצוב החדש מיישם עיקרון פשוט: הכרטיסייה מציגה מצב, לא יכולות. שורה מופיעה רק לאירוע תפעולי שקרה בפועל — ליקוט פעיל, יעד שבת/אקספרס שהוגדר, תווית, בירור שנשלח, פנייה קיימת — עם כל הפקדים והשינויים שהאירוע עבר, לצמיתות. כל ההפעלות עברו לכפתור אחד: "הוספת אירוע" פותח תפריט מקובץ (תפעול / בירורים) של כל עשרת סוגי האירועים; בחירת אירוע שדורש הגדרה — פרשה, תאריך אקספרס, טקסט שאלה, תווית — עוברת לתת-מסך בתוך אותו תפריט, והאירוע מופיע בכרטיסייה מרגע הפעלתו. אירוע שאינו זמין מוצג מעומעם עם הסיבה כטקסט משנה ("לא משויך שליח", "המשלוח טרם נמסר"), ואירועי השליח מציגים את שם השליח. ליד כל סוג אירוע — גם בתפריט וגם בשורות — נוסף אייקון מידע שבריחוף מסביר את מהות האירוע ואופן השימוש בו. משלוח ללא אירועים מציג שורה שקטה אחת במקום ערימת שורות ריקות. הוחל על שתי הפריסות — דף המשלוח המלא וה-Drawer. ובהמשך היום חודד עיקרון בטיחות: שליחת בירור היא פעולת אל-חזור, ולכן בחירת בירור בתפריט אינה שולחת דבר — היא רק מוסיפה את השורה לכרטיסייה במצב "טרם נשלח", והשליחה בפועל נעשית במודע מכפתור השורה; טיוטה שנוספה בטעות ניתנת להסרה ב-X לפני שנשלח דבר. ובהמשך היום — עוזר ה-AI הפנימי למד לפתוח אירועים תפעוליים בשפה חופשית: "תברר צפי מול השליח על 26350496", "תשאל את הנמען אם קיבל", "תבקש תמונת מסירה", "תוודא כתובת", "תוסיף לליקוט", "תגדיר יעד שבת/אקספרס", "תצמיד תווית". בירורים ששולחים WhatsApp כפופים לחובת אישור מפורש מהמשתמש לפני השליחה (העוזר מציג מה יישלח ולמי ושואל), מכבדים את הרשאות המשתמש ואת אותם שומרי כפילות של הכרטיסייה, והתשובות נקלטות ומוצגות בדף המשלוח כרגיל. אגב כך הוקשח גם כלי פתיחת הפניות הקיים של העוזר: בדיקת הרשאה, ולידציית קטגוריה ורישום ביומן הפעילות — באותם כללים של פתיחת פנייה ידנית. בנפרד, בדוחות התשלום לשליחים פוצל שדה "חבילות נוספות" לשני שדות — "חבילות נוספות במסירה" ו"חבילות נוספות באיסוף" — בכרטיס דוח הרווחים של השליח, בדוח בפורטל השליח, בפירוט התשלום לסאב ובייצוא האקסל, כך שברור כמה מכספי החבילות הנוספות הגיע ממסירות וכמה מאיסופים. ובנפרד — תוקן הגורם למסך "משהו השתבש" שהופיע לאחרונה בעת פתיחת דף משלוח אחרי ביקור בדף ניהול השליחים (שני חלקים של המערכת שמרו נתוני שליחים באותו מטמון בצורות שונות, ופתיחת משלוח קרסה על הצורה הלא-צפויה); בנוסף, טאב שנשאר פתוח מלפני עדכון גרסה מתרענן מעתה אוטומטית פעם אחת כשהוא נתקל בקבצי גרסה ישנים, במקום להציג את מסך השגיאה הכללי. ובנפרד — הוקשחה התאמת אזורי החלוקה: עד היום אזורים שחלקו קידומת מספרית ("11" מול "11ב") נחשבו התאמה בכל המערכת — זיהוי טעויות מיון, אזהרת טרום-שיבוץ, סריקת מחסן, הצ'קליסט והמעוכבים בפורטל השליחים ותצוגת "אחראים באזור" בדף המשלוח — בגלל הקלה שנועדה לערים שמפוצלות לתתי-אזורים (ירושלים: "1- מרכז" ≈ "1- צפון"). מעתה ההקלה חלה רק כשעיר המשלוח היא אכן ישוב רב-אזורי; לכל שאר הישובים נדרשת התאמת אזור מדויקת, כך ששליח האחראי על 11ב אינו נחשב עוד אחראי על משלוחי אזור 11.

• הכרטיסייה מציגה רק אירועים שקרו במשלוח — אפס שורות ריקות
• כפתור "הוספת אירוע" אחד עם תפריט מקובץ של כל סוגי האירועים
• אירוע לא זמין מוסבר בטקסט משנה במקום להיעלם או להישאר סתום
• אייקון מידע ליד כל סוג אירוע — הסבר על מהות האירוע ואופן השימוש בריחוף
• אירוע שהופעל נשאר בכרטיסייה לצמיתות עם כל היסטוריית השינויים שלו
• עוזר ה-AI פותח אירועים תפעוליים בשפה חופשית — בירורים באישור מפורש בלבד

כרטיסיית התפעול בדף המשלוח מציגה כעת סקציית "בירורים" עם שתי פעולות מהירות: "אימות מסירה" שולח לנמען את תבנית בדיקת המסירה ("קיבלת את המשלוח?") ועוקב אחר תשובתו, ו"בירור צפי" שולח שאלת צפי לקבוצת ה-WhatsApp של השליח המשויך למשלוח (ברגל הרלוונטית — שליח האיסוף למשימת איסוף). ליד כל פעולה מוצג צ'יפ סטטוס חי — לא בוצע / ממתין לתשובה / נענה (עם התשובה המילולית) / הכחיש קבלה / לא נענה — ולחיצה עליו פותחת את היסטוריית הניסיונות המלאה: מתי נשלח, מי יזם (משתמש או הבוט), מה נענה וכמה תזכורות נשלחו. תשובת השליח נקלטת אוטומטית מהקבוצה (תגובת-ציטוט מזוהה דטרמיניסטית), בירור צפי שלא נענה מקבל תזכורות אוטומטיות בשעות הפעילות, וכפתור שאינו זמין מסביר למה (אין שליח משויך, אין קבוצה מקושרת, לא הוגדרה תבנית). ההיסטוריה כוללת גם בירורי צפי שהבוט פתח בעצמו בעקבות שאלות לקוחות — כך שכל סיפור הצפי של המשלוח במקום אחד. תשובת הנמען לאימות מסירה נשמרת מעתה גם במלואה (הטקסט עצמו, לא רק אישר/הכחיש), וכפתור האייקון הישן של בדיקת המסירה בכותרת הדף הוחלף בסקציה החדשה. בהמשך היום נוסף שלב 2 — הבירורים הפכו לשגרת עבודה ברמת רשימת המשלוחים: כל שורה נושאת צ'יפ בירורים חי ("בירור פתוח" בכתום, "נענה"/"אישר קבלה" בירוק, "הכחיש קבלה" באדום; ריחוף מציג את התשובה המילולית), נוסף פילטר "בירורים" (ממתין לתשובה / נענה ב-7 הימים האחרונים) שמסונכרן גם עם ספירות הפילטרים האחרים, ובסרגל הפעולות הגורפות נוסף "בירור צפי" מרוכז: בחירת משלוחים שולחת הודעה מאוחדת אחת לכל קבוצת שליח (לא הצפה של הודעה-לכל-משלוח), עם רשימת המשלוחים ובקשה לציין מספר משלוח ליד כל תשובה. שליח שעונה בציטוט עם מספרי משלוחים — כל תשובה נקשרת למשלוח שלה; תשובה קולקטיבית ("הכל עד 17:00") סוגרת את כולם; ותשובה ממוספרת גם בלי ציטוט נתפסת במנגנון קיבוץ-הברקודים הקיים. ובהמשך — שלב 3: שלושה סוגי בירור חדשים בסקציית הבירורים. "שאלה לשליח" — שאלה חופשית בכל נושא שנשלחת לקבוצת השליח עם פרטי המשלוח, והתשובה נקלטת ומוצגת כמו בירור צפי. "בקשת תמונת מסירה" — בקשה מהשליח לתמונת POD למשלוח שנמסר; הבירור נסגר רק בתמונה (טקסט כמו "מיד אשלח" לא סוגר אותו), והתמונה משויכת רק בזיהוי ודאי — ציטוט הבקשה שלנו או מספר המשלוח בכיתוב — נשמרת אוטומטית על המשלוח (סקציית התמונות, קטגוריית POD) וזמינה בלחיצה מההיסטוריה. "אימות כתובת" — הודעה ישירה לנמען (צ'אט 1:1) עם הכתובת הרשומה, כולל דירה/קומה/הערות, ובקשה לאשר או לתקן; התשובה נרשמת על המשלוח לטיפול הצוות — עדכון הכתובת נשאר החלטה אנושית, ונמען לעולם לא מקבל תזכורות אוטומטיות. כל הסוגים החדשים משתתפים גם בצ'יפ וּבפילטר "בירורים" ברשימת המשלוחים.

• אימות מסירה מול הנמען בלחיצה אחת — עם צ'יפ סטטוס חי והתשובה המילולית שחזרה
• בירור צפי לקבוצת השליח בלחיצה — התשובה נקלטת אוטומטית ומוצגת על המשלוח
• תזכורות אוטומטיות לשליח שלא ענה, בשעות הפעילות בלבד
• היסטוריית בירורים מלאה: מתי, מי יזם, מה נענה — כולל בירורים שהבוט פתח
• כפתור לא זמין מסביר בדיוק למה (אין שליח, אין קבוצה, חסרה תבנית)
• שלב 2: צ'יפ בירורים על כל שורה ברשימת המשלוחים + פילטר "ממתין לתשובה / נענה לאחרונה"
• שלב 2: בירור צפי מרוכז מסרגל הפעולות — הודעה מאוחדת אחת לכל קבוצת שליח
• שלב 2: תשובות ממוספרות-ברקוד ותשובות קולקטיביות בציטוט נסגרות אוטומטית על המשלוחים הנכונים
• שלב 3: שאלה חופשית לשליח עם מעקב תשובה
• שלב 3: בקשת תמונת מסירה — נסגרת רק בתמונה, שנשמרת אוטומטית על המשלוח
• שלב 3: אימות כתובת מול הנמען ב-1:1 — התשובה נרשמת, העדכון נשאר החלטה אנושית

סוכן איתר בחיפוש משלוח של שולח שאינו לקוח שלו, רק משום ששם הנמענת היה זהה לשם לקוחה שכן משויכת אליו. הסיבה: סינון המשלוחים של סוכן כלל מסלול-גיבוי לפי שם (למשלוחי legacy שאינם מקושרים לרשומת לקוח), שהשווה בטעות גם את שדה שם הנמען — ולא רק את שם השולח — מול שמות לקוחות הסוכן. כך כל משלוח שנשלח אל אדם ששמו זהה לשם לקוח של הסוכן דלף לרשימה, לחיפוש, למפה ולפתיחת המשלוח. התיקון הוחל על כל שבעת המסלולים שחולקים את הסינון: ההשוואה לפי שם נעשית מעתה מול שם השולח בלבד, ורק במשלוחים שאינם מקושרים לרשומת לקוח — משלוח מקושר נשפט לפי הקישור בלבד, כך שגם התנגשות שמות בין שתי רשומות לקוח אינה מדליפה. אומת מול נתוני האמת: התיקון מסיר בדיוק שבעה משלוחים דולפים ואינו מסתיר אף משלוח לגיטימי. ובהמשך תוקן ליקוי עמוק יותר בזיהוי משימות: גם משלוח-מסירה רגיל מורכב משתי רגליים — איסוף ומסירה — ולעיתים שליח משובץ רק על רגל האיסוף. עד היום העיצוב הסתמך רק על סוג המשימה של המשלוח, כך שדיווח של שליח-איסוף ('הנמענת לא מוצאת את האיסוף') הוצג לשולח עם כתובת היעד — כתובתו של השולח עצמו — בתוספת הצהרה שגויה ש'הכתובת שגויה'. מעכשיו הרגל שדרכה השליח המדווח מקושר למשלוח קובעת: שליח שכל הביקורים שלו על המשלוח הם איסוף מקבל התנהגות איסוף מלאה — בלוק כתובת המוצא, ניסוח איסוף, אי-כתיבת שדות יעד מתשובת השולח (בכל ארבעת התרחישים הכותבים), ואי-העברת הנחיות 'תחזירו' לשליח שמעולם לא אסף. תבנית 'כתובת שגויה' מציגה כעת את הדיווח האמיתי של השליח בניסוח בטוח ללקוח במקום ההצהרה הקבועה, והמסווג מחריג 'לא מוצא את החבילה/האיסוף' — קושי באיתור החבילה, לא בכתובת.

שלושה תיקונים משני אירועים. (1) נמען דיווח 'זו טעות, אני לא הנמענת' — כנראה מספר שגוי במשלוח. הבוט עדכן את השולח וביקש 'לעדכן פרטי נמען/טלפון או לבטל — השיבו כאן', אבל לא רשם בשום מקום שתשובה ממתינה: כשהשולח ענה בציטוט עם המספר הנכון, דבר לא קרה, והצוות עדכן ידנית 38 שעות אחר-כך. מעכשיו הפנייה נרשמת (48 שעות — עסקים עונים גם ביום העסקים הבא), טלפון מתוקן בתשובה נכתב למשלוח מיד באותו מסלול כתיבה של יתר התרחישים, והשולח מקבל אישור עם המספר החדש. ההודעה לשולח כוללת כעת גם את בלוק פרטי המשלוח המלא — כולל הטלפון הרשום אצלנו, שהוא בדרך כלל השדה שבו הטעות — כדי שיהיה מול מה לבדוק. (2) באותה שיחה, 'אומרת שלא קיבלה הודעה' סווג כטענת אי-מסירה — אבל היא לא קיבלה את ההודעה (כי המספר שגוי), לא את המשלוח. זיהוי מחלוקת המסירה מחריג כעת אי-קבלה שהמושא שלה הוא הודעה/סמס, על כל הצורות ('את ההודעה', 'שום הודעה', 'כל הודעה'), ועדיין מזהה הודעה שטוענת גם שהחבילה עצמה לא הגיעה — כולל בניסוח משותף ('לא קיבלה שום הודעה ושום חבילה'). (3) בקשת בירור-עיכוב שנועדה לשליח נשלחה לקבוצת לקוח — ולקוח אחר בכלל: קבוצת הוואטסאפ הרשומה על השליח הייתה בפועל קבוצת לקוח (שיבוש נתונים, יחיד מסוגו במערכת). נוסף שומר: קבוצה שרשומה גם על לקוח לעולם לא תקבל תוכן מופנה-שליח — תוכן כזה נושא פרטי נמענים של לקוחות אחרים; במקום זה הטיפול עובר לצוות. בהמשך היום תוקן גם קצה משלים: שליח שחזר על דיווח ('טלפון לא תקין') בזמן שהפנייה לשולח עדיין ממתינה קיבל שתיקה מוחלטת — מניעת-הכפילות צדקה כשלא פנתה לשולח שוב, אבל איש לא אמר לשליח שהעניין בטיפול, ונציגה נכנסה ושכפלה ידנית את הפנייה שהבוט כבר שלח. מעכשיו דיווח חוזר — כשהפנייה פתוחה כבר חצי שעה לפחות (כדי לא לענות לזנב הודעות של הדיווח המקורי) — נענה בשורה קצרה: 'הדיווח כבר הועבר לשולח וממתינים לתשובתו', פעם אחת לשעתיים לכל משלוח. הוחל על ארבעת תרחישי הדיווח (אין מענה, טלפון שגוי, כתובת שגויה, סירוב לקבל).

נמען התלונן שלא קיבל משלוח שסומן כנמסר וביקש תמונה. הבוט דיווח לקבוצת השליחה ('והשב כאן — מה קרה במסירה?'), והשליחה ענתה 'נמסר בארון חשמל לפני 3 ימים'. אבל הדיווח לא רשם בשום מקום שתשובה ממתינה — כך שהתשובה הייתה יתומה, ומנגנון אחר תפס אותה: היא שויכה כפתרון של פנייה פתוחה על משלוח אחר לגמרי, שולח לא-קשור קיבל 'עדכון מהשליח', והנמען ששאל — נשאר בלי כלום. שלושה תיקונים: (1) דיווח תלונת מסירה לקבוצת שליח פותח כעת פנייה ממתינה, כך שהתשובה משתייכת אליו. (2) התשובה מנותבת קודם כל לנמען שפתח את הבירור — בניסוח בטוח ללקוח (לעולם לא מילות השליח הגולמיות), ורק בתוך חלון 24 השעות של וואטסאפ; שיחת הנמען מסומנת לנציג בכל מקרה, כי תשובת השליח היא טענה ולא מסירה מאומתת, והתוכן נשמר גם בתיק המשלוח כרשומה עמידה. תשובה שאינה נושאת מידע ('רגע, אבדוק') לא סוגרת את הבירור — הוא נשאר פתוח לתשובה האמיתית. (3) שומר נוסף במנגנון שיוך דיווחי 'הסתדר': גם כשפנייה אחת בדיוק פתוחה בקבוצה, אם ההודעה האחרונה שלנו באותה קבוצה (עד רבע שעה) עסקה במשלוח אחר — הבוט שותק במקום לנחש; שני האירועים שנצפו הגיעו 6–11 דקות אחרי הודעה כזאת בדיוק. הביקורת ההנדסית תפסה לפני השחרור שתהליך התזכורות היה מבטל את הפנייה החדשה תוך רבע שעה — כי תלונת מסירה נפתחת מעצם טבעה על משלוח שכבר 'נמסר', והתהליך סוגר פניות על משלוחים סגורים; הוחרג. באותו יום תוקן גם סדר-הודעות הפוך שהשאיר שליח ללא מענה: שליח כתב 'אמ' (אין מענה), שלח צילום מדבקה שנייה אחר-כך, והוסיף 'והמקום נראה סגור' — שלוש הודעות, אפס תגובה. מנגנון השחזור הקיים ידע לחבר מדבקה שנשלחה לפני דיווח, אבל לא דיווח שנשלח לפני מדבקה. כעת, כשמגיעה הודעת מדבקה-בלבד שניות אחרי דיווח מאותו שולח שזוהה אך נכשל מחוסר מספר משלוח, השניים מחוברים והתרחיש רץ עם המספר ביד. שני תנאים קשיחים: הדיווח הקודם חייב להיות ללא מספר משלוח משלו, וחייבת להיות רשומת כשל תואמת ביומן ההחלטות לאותו טקסט בדיוק — כך שפטפוט או דיווח שכבר טופל לעולם לא ישוחזרו. ותוקן גם שידור-על-תלונה: נציגה שאלה 'מה עם האיסוף?', הקבלנית השיבה בציטוט 'זה לא משודר כאיסוף אז לא משובץ על שליח' — הסבר על שידור קיים בסוג שגוי — והבוט קרא את המילה 'משודר', שאב את מספר המשלוח מהודעת הנציגה המצוטטת, ושידר משימה חדשה (ובסוג שגוי) שהצוות נאלץ לבטל. מעכשיו: ביטוי שידור תצפיתי ('לא משודר', 'לא נסרק', 'לא מופיע לי') שמגיע כתגובת-ציטוט להודעה של אדם — בלי מספר משלוח משל הכותב — נקרא כהסבר ולא כבקשה, והבוט שותק; בקשה מפורשת ('תשדרו', 'שימו עלי') ממשיכה לעבוד בכל הקשר, כולל בציטוט הודעת נציג, וקבלן שפותח בעצמו ב'לא משודר' ממשיך לקבל את הזרימה הרגילה.

לקוח שאל בקבוצה 'מה קורה עם 26198708?', והבוט הפיק פתק פנימי שהמשלוח 'אינו משויך למשלוח שלו במערכת' — למרות שהוא כן. הסיבה: מבנה משפחת לקוחות. הקבוצה רשומה על לקוח-בן (קקאו טבעי) שהוא תת-לקוח של לקוח-אב (אלפהבית), והמשלוח שייך לאב. הבוט חיפש רק ב'לקוח + הילדים שלו' — לא כלל את האב — ולכן לא מצא. הניתוב ההפוך (החוצה) כבר עבד נכון: משלוח של אב בלי קבוצה משלו מנותב לקבוצת המשפחה היחידה; התיקון פשוט מַראה את זה גם פנימה. כעת, כששואלים בקבוצה על משלוח, הבוט מחפש בכל המשפחה שחולקת את הקבוצה — אב, בנים ואחים — אך ורק כשלמשפחה קבוצה אחת בדיוק, בדיוק כמו הכלל שכבר קיים בניתוב היוצא. כשלבנים יש קבוצות נפרדות (עסקים שונים) — ההיקף נשאר צר כדי שמשלוח של אח אחד לא יעלה בצ'אט של האחר. התיקון הוחל על שלושה תרחישים שמזהים משלוח לפי הלקוח (צפי מסירה, מחלוקת מסירה, ותיאום מועד — שהיה הצר ביותר). מבנה משפחה בעומק שלוש-שכבות נשאר בהיקף הצר כדי למנוע חשיפה לצ'אט הלא-נכון.

כששליח או קבלן מדווח שחסר לו פרט כתובת כדי למסור (מספר דירה, קומה, כניסה או קוד כניסה), הבוט בודק כעת מה יש לנו לפני שהוא פונה לשולח. אם הפרט קיים אצלנו — הוא נשלח לשליח מיד ('לפי הרישום שלנו למשלוח X: דירה 4'), בלי להטריד את השולח; אם באמת חסר אצלנו — נפתחת פנייה לשולח לאותו פרט ספציפי ('חסר אצלנו: קומה'), במקום להודיע לו סתם ש'הכתובת שגויה'. הרקע: קבלן כתב 'לא רשום מספר דירה, איפה להשאיר?' על משלוח שהיה בו מספר דירה, והבוט פנה לשולח בכל זאת; ובמקרה אחר שליח שאל 'קומה? דירה?' על משלוח שבו הפרטים באמת חסרו, ולא נעשה כלום. מדידה: מתוך 37 פניות כתובת ב-30 יום, ל-10 כבר הייתה דירה ול-12 קומה — כלומר בכשליש מהמקרים כבר החזקנו את הפרט. זיהוי איזה פרט חסר נעשה בקריאת AI ממוקדת; בכל ספק הבוט פונה לשולח כמו קודם. בנוסף, כשיש אישור גורף להניח ליד הדלת והבוט מאשר לשליח להניח מיד — ההודעה כוללת כעת גם קומה/דירה/כניסה/הערה, כדי שידע ליד איזו דלת. התרחיש 'כתובת שגויה/חסרה' כבוי כברירת מחדל ומופעל פר-לקוח.

• פרט כתובת שחסר לשליח ונמצא אצלנו — נשלח אליו מיד במקום להטריד את השולח
• פרט שבאמת חסר — פנייה ממוקדת לשולח על אותו פרט, לא 'כתובת שגויה' כללית
• אישור הנחה ליד הדלת כולל כעת קומה/דירה/כניסה כדי שהשליח ידע היכן

שליח צילם מדבקה של משלוח, קיבל רחוב/עיר/טלפון, ונתקע כשעה — כי מה שהיה צריך כדי למסור בפועל (קוד כניסה 0852#, 'להשאיר בארון חשמל') חי בהערת היעד החופשית, שהבוט מעולם לא הציג. מדידה על 26,574 משלוחים הראתה שזו לא פינה: השדות המובנים לכניסה/קוד מאוכלסים ב-0% ו-2% בלבד, בעוד הערת היעד מאוכלסת ב-40% מהמשלוחים — ו-59% מההערות שנדגמו קריטיות למסירה (קוד כניסה, 'להשאיר ליד הדלת', קוד שער, בית פרטי). כלומר השליח נתקע על אותו מחסור בכל משלוח כזה. בלוק פרטי המשלוח שהבוט שולח לשליח (וללקוח העסקי) כולל כעת גם כניסה, קוד כניסה, והערת המסירה של הנמען — שורה אחת, מכווצת ומוגבלת באורך. אותה תוספת הוחלה גם על הודעת שיבוץ האיסוף שהקבלן קורא כדי להחליט אם לקחת את האיסוף, שם הערת המוצא נושאת את אותו סוג מידע ('המחסן בכניסה האחורית, קוד 4417'). ההערות הפנימיות באמת (הערת שליח, הערה ארגונית, הערת משלוח, מחיר) נשארות מוסתרות מהקבוצה כפי שהיו. במקביל, התקציר האוטומטי שמנוסח ללקוח כשיש קושי במסירה כבר לא יבקש 'קוד כניסה' מתחת לבלוק שכבר מציג אותו בהערה.

עד היום פנייה של נמען על משלוח שחרג מימי ההפצה הסתיימה בהסלמה לנציג: מי שבאמת יודע איפה החבילה — השליח שמחזיק אותה — לא נשאל כלל, והתשובה ללקוח הייתה תלויה בכך שנציג יבחין בפתק. נוסף תרחיש 'עיכוב במסירה — בקשת צפי מהשליח': כשהמשלוח בסטטוס 'יצא להפצה' והנמען מדווח על עיכוב, נשלחת לקבוצת השליח בקשת צפי מסירה, וההסלמה לנציג נשארת במקביל. שלוש הגבלות מכוונות: התרחיש פועל אך ורק כשהמשלוח כבר בידי שליח המסירה — בסטטוסים מוקדמים יותר העיכוב הוא אצלנו ואין את מי לשאול, ולכן הבוט שותק; הוא נשלח רק לקבוצה מקושרת ולעולם לא לצ'אט פרטי; והוא מופעל רק בענף החריגה מההתחייבות, לא בכל שאלת 'מתי יגיע'. ההודעה לשליח מציינת תמיד כמה ימי עסקים המשלוח אצלו — מרגע השיבוץ אליו, לא מרגע שנקלט אצלנו — בדיוק כמו השורה שמפיק כפתור 'העתקה לקבלן' בעמוד פערי ההפצה, ובאותו חישוב ימי עסקים. הסיבה מהותית: משלוח ששכב אצלנו במחסן ארבעה ימים והועבר לשליח אתמול הוא עיכוב שלנו, ופתיחת הודעה במספר שאינו באחריותו מזמינה אותו להתעלם ממנה. הצגת המספר הנכון גם מגנה עליו וגם מחדדת לנו היכן העיכוב האמיתי. התרחיש כבוי כברירת מחדל ומופעל פר-לקוח בהגדרות → תרחישי בוט, כולל תבנית הודעה הניתנת לעריכה.

• בקשת צפי אוטומטית לקבוצת השליח כשנמען מדווח על חריגה מימי ההפצה
• ההודעה מציינת כמה ימי עסקים המשלוח אצל אותו שליח — מרגע השיבוץ אליו בלבד
• פועל רק כשהמשלוח כבר בידי שליח המסירה; כשהעיכוב אצלנו הבוט שותק
• כבוי כברירת מחדל — מופעל פר-לקוח בהגדרות → תרחישי בוט

בקבוצת שליח, נציגה התלוננה על משלוח 26308421 שהושאר מאחורי הדלת. השליח ענה 'לא השארתי מאחורי הדלת' ואז 'מסרתי ביד לבן שלה' — שתי הודעות שעוסקות באותו משלוח שהנציגה שאלה עליו. הבוט לקח את המשפט השני וגישר אותו ללקוח בננה כפתרון של פנייה פתוחה אחרת לגמרי, על משלוח 26208682 — שהוא בכלל משימת איסוף. הלקוחה ענתה 'זה איסוף' ונציגה נאלצה לכתוב 'מתנצלים, טעות של הבוט'. הסיבה: כשדיווח פתרון אינו מזכיר מספר משלוח ואינו מצטט הודעה, הקוד בחר את הפנייה הפתוחה האחרונה באותה קבוצה. מדידה על 30 יום הראתה שזה לא מקרה קצה אלא ברירת המחדל — אף אחד מ-19 דיווחי הפתרון לא הכיל מספר משלוח, ו-12 מהם נורו כששתי פניות או יותר היו פתוחות באותה קבוצה, כלומר הימור על מה שנאמר ללקוח משלם. באירוע עצמו היו שלוש פניות פתוחות. מעכשיו, כשדבר בהודעה אינו מזהה משלוח, הבוט מגשר רק אם פנייה אחת בדיוק פתוחה בקבוצה; אחרת הוא שותק והפנייה נשארת פתוחה לתשובה האמיתית שלה. נוסף שומר שני, בלתי תלוי: ניסוח של מסירה ('מסרתי', 'נמסר', 'סופק', 'הושאר') אינו יכול לפתור משימת איסוף — באיסוף אוספים, לא מוסרים. שני המשלוחים היחידים מסוג איסוף בדגימה קיבלו בדיוק דיווח כזה, כך שזו תבנית ולא תקלה בודדת. שני השומרים דטרמיניסטיים ואינם תלויים בשיפוט של מודל; מחיר מודע הוא ששליח שמסיים איסוף בניסוח 'מסרתי במחסן' לא ייצור עדכון אוטומטי — עדכון שהוחמץ זול בהרבה מעדכון שגוי.

פנייה נסגרת ברגע שהתשובה הראשונה מתקבלת, ומאותו רגע אין פנייה פתוחה בשיחה — כך שכל מה שהלקוח הוסיף מיד אחריה נפל בשקט ולא הגיע לאיש. מדידה על 30 יום: 99 מתוך 123 הפניות שנסגרו (80%) קיבלו הודעת המשך בתוך חמש דקות, וכולן נזרקו — מספרי טלפון נוספים ('0556710967 מספר נוסף'), תיקוני כתובת ('מספר בית לשנות גם ל- חמדת השקד 5'), הנחיות מסירה ('שישימו ליד הדלת זה בית פרטי'), וגם ההמשך של האירוע שפתח את כל הבירור הזה ('תתקשרו לפני, או שתשלחו ווטסאפ'). מעכשיו הודעה כזו מקבלת פתק פנימי בצ'אט העסקי שאומר במפורש שהיא לא בוצעה, ושיש לבדוק אם היא דורשת פעולה. הבוט אינו שולח דבר לשליח, אינו נוגע בפנייה, אינו כותב למשלוח, וההודעה ממשיכה בדרכה הרגילה — כך שבקשה שהיא באמת נושא חדש (למשל תיאום מועד אחר) עדיין פותחת תרחיש משלה. הריסון הזה הוא הלקח המרכזי: שלושה תכנונים שניסו להכריע אוטומטית אם הודעה כזו ממשיכה את התשובה או פותחת נושא חדש נפסלו כולם — איחוד לפי סמיכות בזמן גרם לגישור בליל ללקוח והוחזר לאחור; היצמדות לציטוט החייתה תוכן שהמערכת פסלה במכוון, כי פנייה נשארת פתוחה דווקא כשההודעה נשפטה כלא-תשובה; והעברה ישירה לשליח ייחסה הנחיה למשלוח הלא-נכון. השאלה עצמה דו-משמעית, ונציג שקורא את השיחה מכריע אותה בשנייה. מסונן דרך זיהוי הנחיה כדי שכל 'תודה' לא ייצור פתק, ופועל רק כשפנייה אחת בדיוק נסגרה — כששתיים נסגרו יחד אין דרך לייחס, והמערכת שותקת.

לקוחה ביקשה לבטל משלוח. ב-06:09 נשלחה לקבוצת השולח (ערוץ 2000) השאלה 'המשלוח טרם נאסף — האם לבטל?'; הצוות ביטל בפועל ב-06:38; וב-09:01 נשלחה לאותה קבוצה הודעה שנייה על אותו משלוח, שאמרה 'המשלוח כבר נאסף ונמצא בתהליך (בוטל), ולכן לא ניתן לבטלו'. ארבע תקלות נפרדות באותה הודעה, וכולן תוקנו. (1) הכפילות: מנגנון מניעת-הכפילות בדק אם פתק ה-AI של השיחה מכיל את הסימן 🛑 — אבל אותו שדה נדרס בכל מחזור עיבוד, ובנוסף הפתק שנכתב בענף 'פנייה חוזרת' כלל לא הכיל את הסימן. כלומר הדגל מחק את עצמו כבר בהודעה הבאה: ב-06:11 הוא עוד תפס (ותוך כדי מחק את עצמו), ב-06:21 פתק אחר דרס את מה שנשאר, וב-09:01 כבר לא היה דבר שיעצור שליחה שנייה. במקומו נרשם כעת ביומן העיבוד — יומן מוסף-בלבד שאינו נדרס — סימון של מה שהבוט **באמת שלח**, ולא של מה שהמודל ביקש; כך שדגל שהתרחיש שלו כבוי, או ששליחתו נכשלה, אינו חוסם בטעות את הניסיון הבא. חלון החסימה 24 שעות. אותה תקלה בדיוק הייתה קיימת גם בדגל תלונת המסירה (🔴) ובדגל הכתובת הלא-מעודכנת (📍) — ותוקנה בשלושתם יחד. (2) הסתירה: משלוח שכבר בוטל / נמסר / נכשל סופית מוגדר כעת כשלב נפרד שאין בו מה לבטל או לעצור — במצב כזה השולח אינו מקבל הודעה כלל, נכתב פתק מדויק לנציג, וגם התשובה לנמען מוחלפת: במקום להבטיח לו 'אנחנו בודקים מול השולח' (הבטחה שהקוד בדיוק החליט לא לקיים) הוא מקבל את הסטטוס בפועל. הנוסח לשולח חדל לטעון 'נמצא בתהליך' ומציין 'סטטוס נוכחי'. (3) ניסוח פנימי שדלף: תיאור הפנייה נכתב על ידי המודל, והוא הוסיף לו פריט-פעולה שמיועד לנציג שלנו ('— לבדוק מול השולח לאישור ביטול') — שנכנס כלשונו להודעה שהלקוח העסקי קרא. השורש היה בפרומפט עצמו, שהדגים למודל בדיוק את הצורה הזאת; הדוגמה תוקנה ונוסף כלל מפורש שהתיאור מצוטט למי שמחוץ לחברה ואסור שיכיל הנחיה. בנוסף נוסף ניקוי דטרמיניסטי כרשת ביטחון, שהוחל גם על שלושת הזרימות האחיות שמצטטות את אותו תיאור לשולח או לשליח (נמען שגוי, תלונת מסירה, כתובת לא-מעודכנת). (4) מספר המשלוח הופיע פעמיים — בכותרת ההודעה ובתוך התיאור — ומוסר כעת מהתיאור כשהוא בסוגריים; מספר שמשובץ בתוך המשפט נשאר במקומו במכוון, כדי לא לשבש את העברית. בנוסף, הפתק לנציג בפנייה חוזרת חדל לטעון שהשולח עודכן, שכן ייתכן שהניסיון הקודם נכשל או שלא היה צ'אט מקושר. (5) נוסף לכך — הבוט כתב על עצמו בלשון כפולה ('מצטער/ת', 'מבינ/ה', 'מתנצל/ת'), וזה הסימן הבולט ביותר שמסגיר ללקוח שמולו עומדת מכונה; לקוחות אכן שאלו בשיחה 'זאת תשובה של בוט?'. הפרומפט לא הגדיר לבוט זהות כלל, והדוגמאות שבו עצמן נכתבו בלוכסן — ולכן המודל חיקה אותן. מעתה הבוט מדבר על עצמו בלשון נקבה יחיד באופן עקבי ('מצטערת', 'מבינה', 'מתנצלת'), כמקובל בשירות לקוחות, והלוכסן בגוף ראשון נאסר במפורש. בפנייה אל הלקוח, שמגדרו אינו ידוע, הנוסח מנוסח מראש כך שלא יידרש מגדר כלל (שאלה במקום ציווי, לשון רבים מנומסת) — כך ש'אנא שמור/י על זמינות' הפך ל'אנא שמרו על זמינות', ו'האם את/ה X?' הפך ל'הגענו ל-X?'. (6) ובהמשך לכך — הפנייה אל הלקוח עצמו כבר אינה ניטרלית כברירת מחדל אלא מזהה את מגדרו לפי השם הפרטי: מודול חדש מכריע מגדר מול רשימות שמות (עברית, ערבית ורוסית בכתיב עברי), והתשובה מוזרקת להקשר שהמודל מקבל. שלוש החלטות תכנון: אין ניחוש מורפולוגי לפי סיומת — 'נגמר ב-ה' = נקבה' מפיל את משה, שלמה, יהודה ואריה, וגם הופך 'מאפיית רינה' לאישה; שם דו-מגדרי (אור, טל, שחר, עדן, יובל, עמית, שרון) מוכרז ככזה מראש ומוחזר כבלתי-מוכרע; ושם שאינו ברשימות נשאר בלתי-מוכרע והבוט מנסח בלי מגדר — פנייה במגדר שגוי גרועה מלוכסן. במדידה על 20,000 שמות נמענים אמיתיים מוכרעים 55% (33% נשים, 22% גברים); רוב הבלתי-מוכרעים הם שמות עסקים ('בית', 'מרכז', 'קרית') ושמות דו-מגדריים — כלומר בדיוק המקרים שבהם ניטרליות היא התשובה הנכונה. שני אותות גוברים על השם: אם הכותב חושף את מגדרו בהודעותיו ('אני בטוחה', 'הייתי צריך') — הבוט הולך אחרי מה שנכתב, שכן בעל הטלפון אינו תמיד הנמען הרשום; ואם התברר שאין זה הנמען כלל — חזרה לניסוח ניטרלי. נוסף סקריפט למדידת הכיסוי, שמדפיס את השמות הנפוצים שטרם הוכרעו כרשימת עבודה להרחבה. (7) ולבסוף — הבטחה שלישית שלא כובדה, שהתגלתה בבדיקת משלוח 26242993: הנמען דיווח ב-12:46 שהשליח לא העלה את החבילה ליישוב אלא הניח אותה במחסום, והבוט ענה 'פתחתי כרגע בירור דחוף מול הגורמים הרלוונטיים' — אך לא נפתח דבר. השליח סימן 'נמסר' ב-12:55, תשע דקות אחרי התלונה, והדיווח לקבוצת השליח היה מותנה בסטטוס 'נמסר/הושלם' בלבד. כלומר: בזמן שהתלונה נכתבה המשלוח היה 'יצא להפצה', ולכן לא נשלח דיווח — לא בפרומפט ולא בקוד — והדבר היחיד שקרה הוא הסלמה לנציג. השער הורחב וכולל כעת גם 'יצא להפצה': ברגע שהחבילה בידי שליח המסירה, תלונה על אופן המסירה היא שלו לענות עליה, וזהו דווקא החלון שבו התלונה הכי ניתנת לפעולה — השליח עדיין במסלול. נוסח הדיווח מותאם לסטטוס: לשליח שטרם סימן מסירה נכתב 'המשלוח נמצא אצלך כעת בהפצה' במקום 'המשלוח מסומן כנמסר על-ידך', שהיא האשמה בדבר שלא נטען; ותבנית פר-לקוח שנשמרה בעבר ומקודד בה המשפט הישן לא תשמש במצב הזה. במקביל תוקנה גם ההבטחה עצמה: הבוט אינו מצהיר עוד שפנה לשליח — האם הדיווח ייצא בפועל נקבע אחרי שהוא כבר ענה, לפי תנאים שאינם גלויים לו (שליח משובץ, קבוצה מקושרת, תרחיש מופעל) — ומבטיח רק את מה שנכון בכל מקרה: שהפנייה הועברה לבדיקה דחופה ושנחזור עם תשובה.

הזמנה שנוצרה בחנות אישופ בשעה 12:39 נקלטה אצלנו כמשלוח רק ב-15:43. הסיבה: חלון הזמן שנשלח ל-getorderlist נבנה לפי שעון השרת — ובוורסל השרת רץ ב-UTC — בעוד שאישופ קוראת את התאריכים לפי שעון ישראל. התוצאה היא חלון שמפגר בקביעות בשעתיים-שלוש (לפי שעון קיץ/חורף), כך שהזמנה נכנסה לטווח החיפוש רק אחרי שהשעון ב-UTC 'השלים' את הפער — כלומר כשלוש שעות אחרי שבוצעה. החלון נבנה כעת בשעון Asia/Jerusalem עם התחשבות בשעון קיץ, והזמנות נקלטות תוך דקות כמצופה. הובהר גם בתיעוד הקוד שהסינון של אישופ הוא לפי מועד יצירת ההזמנה — העברה של הזמנה ישנה לסטטוס המשדר לא מחזירה אותה לחלון, ולכן משיכה תקופתית אינה תחליף למצב Push (רישום Webhook על סטטוס מפעיל).

האיחוד שנוסף אתמול (תשובת לקוח/שליח שפוצלה לכמה הודעות מגושרת במלואה) הוחזר לאחור לאחר שגרם לתקלה בפרודקשן. שליח ענה קודם לשאלת נציג על משלוח אחר ("מארז"), אחר כך שלח "תכף אשלח לכם מסודר", ורק אז את הצפי האמיתי ("יום א"). האיחוד קיפל את שלושתן וגישר ללקוח "מארז / תכף אשלח לכם מסודר / יום א" כתשובת הצפי — הודעה חסרת פשר. ההגנות שנבנו לא תפסו את זה: ה"נושא האחר" היה שאלת נציג ולא גישור נוסף (ולכן תנאי "גישור יחיד פתוח" התקיים), ולהודעות לא היה מספר משלוח (ולכן החיתוך לפי משלוח לא ירה), ובדיקת ה-LLM על הטקסט המאוחד אישרה אותו כי הוא אכן הכיל צפי תקין. המסקנה: בלי מזהה משלוח בהודעות אין דרך אמינה לדעת שכל הודעה ברצף שייכת לאותה תשובה. הבאג המקורי (חצי תשובה שאבדה) חוזר להיות פתוח.

מניתוח שיחות אמת (20-21/07). (1) בשיחה על זיפ העוזר ענה נכון על שלוש שאלות כמות (186 משלוחים, 36 בטבריה — אומת, מדויק), ואז על השאלה הרביעית ('כמה פתוחים בטבריה') מסר בביטחון '12 משלוחים פתוחים' — **בלי לקרוא לאף כלי**. המספר האמיתי הוא 64. שומר האמינות תפס עד כה טענות ביצוע ('✅ נשלח') והצגת פרטי משלוח, אבל לא מספר בתשובה לשאלת 'כמה' — וזו בדיוק התשובה שנציג פועל לפיה. כעת מספר שנמסר כעובדה בלי שרצה כלי סופר נדחה אוטומטית והמודל נדרש לספור באמת. (2) התאמת שם שליח: המנגנון שתוקן לאחרונה (שמזהה שם מלא המפוצל לשם פרטי ומשפחה) הוא מכוון-רחב, ולכן שם קצר כמו 'אל אי' התאים במקרה ל-10 שליחים — כי 'אל' ו'אי' מופיעים בתוך שמות אחרים — והמערכת בחרה אחד שרירותי; הנציג ביקש 'אל איי שליחויות' וקיבל שליחה לא קשורה, בעוד השליח האמיתי היה באותה רשימה. נוסף דירוג התאמות: התאמה מדויקת גוברת על התאמה רציפה, וזו גוברת על צירוף-מילים מקרי, ושליח פעיל מועדף. כשההתאמה חלשה ויש מועמדים נוספים — הכלי מסמן זאת ומחזיר את החלופות במקום להציג ניחוש כעובדה. (3) עמוד הסטטיסטיקות של הצ׳אט העסקי נפל עם השגיאה 'Unexpected end of JSON input' בכל מעבר מ'שבוע' ל'חודש' או ל'3 חודשים'. הסיבה: השרת שלף את כל הודעות התקופה לזיכרון וחישב עליהן בקוד — כ-29 אלף הודעות בחודש — ומסד הנתונים סירב להחזיר תשובה בגודל כזה. שבוע הצליח במקרה כי הוא נכנס בדוחק מתחת לתקרה. כל החישוב (פילוח יומי, לפי משתמש, מפת השעות, קהלים, צ׳אטים עמוסים ושיעור ההכלה) הועבר לשאילתה עצמה, כך שחוזרות מאות שורות מסוכמות במקום עשרות אלפי הודעות — כל שלוש התקופות נטענות כעת בכחצי שנייה. המספרים אומתו מול החישוב הקודם ויצאו זהים. בנוסף, שגיאת שרת שמחזירה תשובה ריקה מוצגת כעת כהודעה קריאה במקום שגיאת דפדפן. דוח רווחי הנהגים עבר לסינון טננט ישירות על עמודת הביקור במקום דרך המשלוח — מדידה על הנהג העמוס ביותר הראתה שהניסוח הקודם אילץ סריקה סדרתית של כל 427 אלף הביקורים (209ms), והמעבר מפעיל את האינדקס הקיים ומוריד ל-31ms. שקילות שתי העמודות אומתה על כל השורות ונשמרה כסקריפט בדיקה חוזר.

• מספר שנמסר בלי שנספר בפועל נדחה אוטומטית — נצפה '12 פתוחים' כשהאמת 64
• דירוג התאמות שם שליח: מדויק > רציף > צירוף מילים מקרי, ושליח פעיל מועדף
• התאמה חלשה מסומנת ומחזירה חלופות במקום ניחוש שמוצג כעובדה
• סטטיסטיקות הצ׳אט העסקי: 'חודש' ו'3 חודשים' נטענים שוב, בכחצי שנייה

שלושה תיקונים מסקר העומסים. (1) הרשאות: התראת 'טעות מיון' שודרה לכל מי שמחובר ל-tenant, והיא כוללת ברקוד, שם לקוח, שם נהג ועיר יעד — כלומר סוכן שמשויך ללקוחות מסוימים קיבל התראות על לקוחות שאינם שלו, ויכול היה להיכנס מהן לכרטיס המשלוח. אותה בעיה בדיוק תוקנה כבר בערוץ עדכוני המשלוחים; הערוץ הזה נשכח. עכשיו כל אירוע נבדק מול היקף ההרשאות של הסוכן לפני שהוא נשלח, ובמקרה של תקלה במסד הנתונים ההתראה נחסמת ולא נשלחת. (2) ביצועים: שישה מנגנוני רענון אוטומטי המשיכו לפנות לשרת גם בטאבים מוסתרים — כולל שני מונים שיושבים בסרגל הצד, כלומר בכל עמוד ובכל טאב פתוח. הם היו התנועה הגדולה ביותר במערכת שאינה webhook. כעת הטיימר נעצר כשהטאב מוסתר ומתרענן מיד עם החזרה אליו, כך שמה שמוצג תמיד עדכני. (3) אמינות: תהליך מענה ה-AI ללקוח נהרג לעיתים באמצע בגלל מגבלת זמן, והשאיר פניות תקועות במצב 'בעיבוד' לנצח — הלקוח פשוט לא קיבל תשובה. עכשיו התהליך מפסיק לקחת פניות חדשות לפני מגבלת הזמן ומסיים בשלום, ובנוסף נוספה רשת ביטחון שמחזירה לתור פניות שנתקעו. פנייה ישנה מדי לא נענית באיחור אלא מסומנת לטיפול — מענה על הודעה מלפני שעתיים גרוע מלא לענות. בהמשך אותו סקר: (4) דוח התשלום לשליח שלף את הביקורים שלו מכל הלקוחות במערכת וסינן את הזרים בקוד — הסינון עבר לשאילתה עצמה, כך שהבידוד נאכף במסד הנתונים ולא בשכבת הקוד. (5) לצ׳אט ה-AI לא הייתה שום הגבלת קצב, ובנוסף בדיקת המכסה היומית קראה את המונה ורק אחר כך קידמה אותו — כך שכמה בקשות במקביל כולן ראו את אותו מספר, כולן עברו, והעודף חויב על המפתח של שיפינסט. הקידום עצמו הוא כעת הבדיקה. (6) חמשת סנכרוני החנויות רצו בסדר קבוע ובלי תקציב זמן, ולכן החנויות בסוף הרשימה לא סונכרנו כלל — לא באיחור — כי הריצה נקטעה תמיד באותה נקודה. הסדר עורבב והריצה מסתיימת מסודר, כולל דיווח כמה חנויות נדחו. (7) פורטל: מגבלת הכתובות המועדפות הועלתה מ-100 ל-500. לקוח הפצה הגיע לתקרה עם 97 כתובות שונות — כלומר שימוש לגיטימי ולא כפילויות — וכל ניסיון לשמור כתובת נוספת נכשל. התקרה נועדה למנוע התפוצצות של הרשימה, לא לשמש מכסה; היא גם הפסיקה להיות משוכפלת בין השרת למסך ההגדרות, כך שלא ייווצר מצב שהמסך חוסם במספר אחד והשרת בוחן אחר. לצד זה נוסף ייבוא כתובות מקובץ Excel: הלקוח מעלה טבלה, המערכת מזהה את העמודות לפי הכותרות בעברית או באנגלית, מתקנת שמות ערים לשם הרשמי מול מרשם היישובים (״ת״א״ הופך ל״תל אביב יפו״), ומדלגת על כתובות שכבר קיימות אצלו וכן על כפילויות בתוך הקובץ עצמו. לפני האישור מוצג בדיוק מה יקרה — כמה שורות ייובאו, כמה שמות ערים יתוקנו, לאילו שורות לא נמצא יישוב תואם וכמה שורות לא ייכנסו אם אין מספיק מקום עד התקרה. בנוסף נוספו ייצוא הרשימה הקיימת לאקסל והורדת קובץ תבנית, כך שאפשר להוריד, לערוך בנוחות ולהעלות בחזרה. פענוח הקובץ מתבצע בדפדפן ולא בשרת.

• סוכן מקבל התראות טעות-מיון רק על הלקוחות המשויכים אליו
• תקלה במסד הנתונים חוסמת את ההתראה במקום לשדר אותה לכולם
• טאב מוסתר לא פונה יותר לשרת — הטיימר נעצר ומתרענן עם החזרה לטאב
• מונה הלידים ומונה תובנות ה-AI בסרגל הצד הפסיקו לרוץ בכל טאב פתוח ברקע
• עמודי תיאום האיסופים, תמונת המחסן והמשתמשים — אותו טיפול
• מענה AI תקוע חוזר לתור אוטומטית במקום להישאר 'בעיבוד' לנצח
• פנייה ישנה מדי מסומנת לטיפול ידני ולא נענית באיחור
• דוח תשלום השליח מסונן לפי לקוח כבר בשאילתה — בידוד במסד הנתונים, לא בקוד
• הגבלת קצב לצ׳אט ה-AI (צוות ופורטל) — לפי משתמש ולא לפי כתובת IP
• המכסה היומית נתפסת אטומית — בקשות מקבילות לא חורגות יותר מהמכסה החינמית
• חנויות בסוף רשימת הסנכרון מסונכרנות סוף-סוף — הסדר מעורבב ויש תקציב זמן
• ריצת סנכרון שנגמר לה הזמן מדווחת כמה חנויות נדחו במקום לשתוק
• מגבלת הכתובות המועדפות בפורטל עלתה מ-100 ל-500
• ייבוא כתובות מועדפות מקובץ Excel, עם תיקון שמות ערים וזיהוי כפילויות
• ייצוא הרשימה לאקסל והורדת קובץ תבנית — עריכה בחוץ והעלאה בחזרה

בין ה-19 ל-21 ביולי הגיעו למנהל המערכת עשרות התראות WhatsApp, חלקן זהות לחלוטין ובאותה שנייה. הסיבה לא הייתה ריבוי תקלות אלא פגם בצינור ההתראות עצמו: למנגנון מניעת הכפילויות שתי שכבות — זיכרון מקומי ורשומת סימון במסד הנתונים — ורק השנייה חוצה בין הרצות מקבילות. כשהיא נכשלה, המערכת בחרה להמשיך ולשלוח בכל זאת. אלא שהסיבה כמעט תמיד לכישלון שלה היא שמסד הנתונים עצמו הוא התקלה — כלומר ההגנה כובתה בדיוק ברגע שבו כל מסלול במערכת נופל בו-זמנית וזקוק לה. כעת ההתנהגות הפוכה: כשלא ניתן לתאם בין ההרצות, נשלחת התראת תשתית אחת בלבד בכל רבע שעה והשאר מדוכאות. במקביל, כל שגיאות הקישוריות למסד הנתונים (P6000, P6001, P6004, P1001, P2024 ודומותיהן) מקובצות תחת מזהה אחד — תקלת תשתית אחת מייצרת התראה אחת, לא אחת לכל מסלול שנפל בגללה. בנוסף תוקנו שני מקורות רעש: (1) דחייה צפויה של ליונוויל בייבוא חוזר — 403 "מספר הזמנה כבר קיים" ו-429 חריגה ממכסת הקצב — נרשמה כשגיאת מערכת חמורה; ייבוא חוזר של קובץ בן 500 שורות ייצר כך 253 התראות רצופות שאין מה לעשות איתן. כעת הן נרשמות כאזהרה, עדיין מוצגות בסיכום הייבוא, וללא צירוף פרטי הנמען ללוגים. (2) הסנכרון מול בלדר סרק בכל הרצה את כלל המשלוחים של הלקוח — 212,611 שורות ו-480MB — כדי לאתר 3 משלוחים, וחרג ממגבלת הזמן של מסד הנתונים ולעיתים גם מזמן הריצה המרבי. נוסף אינדקס ייעודי; זמן השאילתה ירד מחריגה מוחלטת ל-3 מילישניות.

• כשל בתיאום ההתראות שולח מעתה התראה אחת לרבע שעה במקום מטח בלתי מוגבל
• כל שגיאות הקישוריות למסד הנתונים מקובצות להתראה אחת במקום אחת לכל מסלול
• דחיית ייבוא חוזר של ליונוויל (403/429) ירדה מדרגת שגיאה לאזהרה — ללא התראה וללא פרטי נמען בלוגים
• סנכרון בלדר: 3 מילישניות במקום חריגה מהזמן המרבי, בזכות אינדקס חלקי בן 16KB

יבוא של 710 שורות יצר 600 משלוחים בלבד, ואיש לא ידע. שלושה ליקויים נפרדים הצטברו לזה, וכולם תוקנו. (1) הדפדפן היה המנוע — הוא החזיק את השורות בזיכרון ושלח אותן לשרת במנות; המנה החמישית מעולם לא יצאה, ו-4 המנות שכן רצו נרשמו כארבע רשומות היסטוריה נפרדות שכל אחת מדווחת "150 מתוך 150 הצליחו" בירוק. כעת הבקשה הראשונה מעלה את כל הקובץ, השורות נשמרות לפני שנוצר משלוח אחד, וכל בקשה אחריה רק אומרת "המשך את היבוא הזה" — מה שנותר מחושב בשרת מהפרש בין השורות שהועלו לתוצאות שנרשמו. כך הנהג בר-החלפה: הדפדפן מוביל כל עוד הטאב פתוח, וקרון חדש מסיים יבוא נטוש. סגירת טאב מעכבת יבוא — כבר לא מאבדת אותו. (2) לקובץ לא הייתה שורת כותרות, והשורה הראשונה — הזמנה אמיתית — נבלעה ככותרות. כעת המערכת מזהה קובץ שמתחיל ישר בנתונים לפי ראיה חיובית (טלפון או שני שדות מספריים), ממציאה שמות עמודות בעצמה, ולא מקריבה שורה. (3) זיהוי הכפילויות נשען אך ורק על עמודת "מזהה הזמנה", ולקובץ הזה היא כלל לא מופתה — כך שהמערכת דיווחה "0 כפולים" בביטחון, כשהמשמעות האמיתית הייתה "לא הצלחתי לבדוק". ייבוא חוזר של הקובץ כדי להשלים את החסר היה יוצר 600 כפילויות בשקט. כעת נוספה בדיקה שנייה מול היסטוריית היבוא של אותו לקוח: הזהות של שורה נגזרת ממזהה ההזמנה וגם מטלפון+רחוב+מספר, והמערכת מציגה באנר "N מתוך M השורות כבר יובאו" עם כפתור להסרתן בלחיצה. בדיקה מול הקובץ האמיתי: 708 מתוך 710 שורות זוהו נכון. הבדיקה מייעצת בלבד ולעולם לא מדלגת לבד — משלוח חוזר לאותה כתובת הוא תרחיש לגיטימי אצל לקוחות עלוני השבת.

• כל שורות הקובץ נשמרות בשרת לפני יצירת המשלוח הראשון — היבוא ניתן לשחזור מרגע זה
• קרון חדש (resume-imports) מסיים יבוא שהדפדפן נטש — סגירת טאב, נפילת רשת או פונקציה שנהרגה
• רשומת היסטוריה אחת לכל יבוא, עם מספר השורות האמיתי של הקובץ — יבוא חלקי מזוהה מיד
• אסימון בעלות מבטיח שהדפדפן והקרון לא יעבדו על אותן שורות במקביל וייצרו כפילויות
• כל אזכור של פיצול פנימי הוסר מהממשק — שם הקובץ, ההתראה וההיסטוריה
• קובץ שמתחיל ישר בנתונים כבר לא מאבד את שורתו הראשונה
• באנר "כבר ייבאת את השורות האלה" עם הסרה בלחיצה — עובד גם לקבצים ללא מזהה הזמנה

לקוח הגיב בציטוט (swipe) על תמונת מדבקה של משלוח 26187386, עם מספרי טלפון מעודכנים. הבוט מעולם לא זיהה את מספר המשלוח בתמונה, ולכן לא ידע על איזה משלוח התשובה — אבל ה-fast-path של הטלפון, שמניח ש"relay יחיד פתוח = חד-משמעי", התעלם מהציטוט ושייך את הטלפונים ל-relay הפתוח היחיד (כתובת שגויה על משלוח 26329877 אחר לגמרי), ושידר אותם לשליח הלא-נכון. כעת, תשובה שמצטטת הודעה שאינה השאלה שלנו מנותבת אך ורק למשלוח שאותה הודעה עוסקת בו — ואם הבוט לא מצליח לזהות את המשלוח (כמו תמונה שלא בוצע עליה OCR), הוא שותק במקום לנחש. ציטוט הוא אות מיקוד מפורש: לגורם אנושי ברור מיד על מה התשובה מתייחסת; הבוט, שלא מזהה את המספר, חייב לשתוק. שמירה על ההתנהגות הדטרמיניסטית לתשובת-טלפון על גישור "אין מענה" (ללא תלות ב-LLM).

נבנה תרחיש בוט חדש (ניתן להפעלה ב-/settings/bot-scenarios, כבוי כברירת מחדל): כששליח/קבלן מדווח בקבוצתו שהנמען מסרב לקבל את המשלוח, הבוט מודיע ללקוח העסקי ושואל כיצד להמשיך — להחזיר, לתאם מחדש או ליצור קשר — ומעביר את תשובת הלקוח חזרה לשליח. עד כה דיווח כזה ("לקוח מסרב לקבל") לא זוהה על ידי אף תרחיש והשולח מעולם לא עודכן. שונה מ"אין מענה" (שם הנמען לא נמצא) ומכשל מסירה (שסוגר את המשלוח): כאן הנמען נוכח ומסרב, ויש החלטה אמיתית לשולח. מבנית זהה לגישור "אין מענה", ללא אפשרות ההשארה ליד הדלת שאינה רלוונטית לסירוב פנים-אל-פנים.

• תרחיש רשום עם toggle, כבוי כברירת מחדל (opt-in per-tenant)
• מילות טריגר: "מסרב לקבל", "לא מעוניין", "לא רוצה לקבל", "טוען שלא הזמין" ועוד
• מגשר לשולח ומחזיר את הנחייתו לשליח; מכבד את כל הגנות הגישור הקיימות (זיהוי משלוח, ניתוק שיחה, פנייה בקבוצות בלבד)

קבלן שאל "26377358 מה לאסוף?" (איזה מוצר/פריט לקחת באיסוף), והבוט השיב בפרטי הכתובת של המשלוח — כלומר ענה "מאיפה" על שאלת "מה". תוכן המשלוח (המוצר) אינו קיים אצלנו במערכת ואי אפשר לגזור אותו מפרטי המשלוח. חודדה הגדרת תרחיש "פרטי משלוח" כך ששאלה על תוכן/מהות המשלוח (מה לאסוף, מה בחבילה, איזה מוצר, כמה פריטים) אינה מזוהה כבקשת פרטים — הבוט שותק והצוות משיב, במקום לתת תשובה מטעה.

השלמת הסריקה שנפתחה בעקבות התקיעה בחיפוש דוח עמלות הסוכן. נסרקו 93 שדות חיפוש במערכת, ואחרי אימות פרטני נמצאו שישה מקומות שסבלו מאותה תבנית — חיפוש שמסנן רשימה גדולה בזיכרון ומצייר מחדש את כל התוצאות בכל הקשה. הארבעה האחרונים נסגרו כאן: שלושת בוררי הלקוחות (קישור לקוח-בן, קישור ללקוח-אב, חיבור לסאמיט) ותפריט הפילטרים המשותף — שמשמש את מסכי המשלוחים, הלקוחות, השליחים והלידים, ושרשימת ה'עיר' שלו נבנית מאגרגציה על כל המשלוחים ויכולה להגיע למאות ערים. בכולם מוצגות מעתה עד 50 שורות עם כפתור 'הצג הכל', כך שההקלדה נשארת חלקה. בדיאלוג הסאמיט תוקן בנוסף חיפוש ריבועי: כל שורה ברשימה סרקה את כל לקוחות הדייר כדי לזהות כפילות מזהה — הוחלף באינדקס שנבנה פעם אחת. שאר המערכת נמצאה נקייה: הטבלאות הראשיות (משלוחים, לקוחות, שליחים, לידים) כבר עובדות עם עימוד בצד שרת או טבלה מווירטואלית.

משתמשים ציינו שספירת ההודעות הנכנסות מלקוחות אינה רלוונטית לניתוח העבודה — מה שמעניין הוא כמה הודעות אנחנו שולחים ומי שולח אותן. כל הספירות בעמוד הסטטיסטיקות (סה"כ, גרף יומי, פילוח משתמשים, מפת חום, פילוח קהלים, צ'אטים עמוסים, וההשוואה לתקופה הקודמת) כוללות מעכשיו רק הודעות יוצאות — AI ואנשי צוות (מהמערכת, מוואטסאפ ומטלפון העסק) — והקטגוריה 'לקוחות (וואטסאפ)' הוסרה מהגרף ומהייצוא לאקסל. הודעות הלקוחות עדיין מזינות את מדדי האיכות שזקוקים להן כנקודת ייחוס: שיעור הכלה, זמן תגובה והודעות ממתינות למענה.

אחרי שהוגדל קצב סנכרון-הגיבוי (19/07), הדוח הנקי חשף שהריצות מייצרות יותר מאלף כשלי 429 ביום: ההנחה שקצב ליונוויל נשלט על ידי מספר הבקשות המקביליות הופרכה — המגבלה שלהם היא על נפח הבקשות. ריצה שנתקלת בקיר המשיכה לירות את כל ה-batch, שרפה את המכסה על ניסיונות אבודים וגזלה קיבולת גם מהפעולות האינטראקטיביות (יצירת משימות, דחיפות סטטוס). נוסף מפסק זרם לשני מסלולי הסנכרון (sync-recent ו-sync-open): אחרי חמישה כשלי 429 רצופים — כל אחד כבר אחרי ניסיון חוזר פנימי — הריצה נעצרת מיד, והריצה הבאה ממשיכה בדיוק מאותה נקודה (המיון לפי מועד סנכרון אחרון). כך הסנכרון שואב בקצב המרבי שליונוויל מרשה באותו רגע, בלי לנחש את המכסה ובלי לבזבז אותה, וגודל ה-batch נשאר תקרה לימים שבהם המכסה מרשה יותר.

כל פעולת ניהול על משמרת עובד מתועדת מעתה ביומן בלתי-נמחק: מי ביצע, מתי, ומה השתנה — כולל הערכים הישנים והחדשים של כל שדה. התיעוד מכסה עריכת שעות והפסקות, הוספת משמרת ידנית, מחיקה, אישור, דחייה והחתמת כניסה/יציאה שבוצעה ע"י מנהל עבור עובד. ציר-זמן של ההיסטוריה מוצג בתוך דיאלוג עריכת המשמרת, עם תרגום השינויים לעברית (למשל: הפסקה: 0 דק' ← 30 דק'). שמירה ללא שינוי אמיתי לא יוצרת רשומה. הפיצ'ר נולד מאירוע שבו שעות של עובד נערכו בטעות ולא היה ניתן לשחזר מי עשה מה — מעתה זה תמיד ניתן לבירור.

• כל עריכה נרשמת עם מבצע, זמן, וערכים ישן←חדש לכל שדה
• מכוסה: עריכה, הוספה ידנית, מחיקה, אישור, דחייה, החתמות מנהל
• ציר-זמן בתוך דיאלוג עריכת המשמרת
• שמירה ללא שינוי לא מרעישה את ההיסטוריה

ארבעה שיפורים בצ'אט הלקוחות העסקיים בעקבות משוב משתמשים. (1) העברה מרובת הודעות: 'בחר הודעות' בתפריט ההודעה פותח מצב בחירה בסגנון וואטסאפ — מסמנים עד 30 הודעות ומעבירים את כולן יחד לצ'אטים אחרים, בסדר הכרונולוגי; סימון 'הודעות שהועברו' מופיע פעם אחת בראש הצרור ולא על כל הודעה. (2) תגובת אימוג'י בלחיצה אחת: סמיילי בריחוף על הודעה (ושורת אימוג'ים בתפריט לחיצה-ארוכה במובייל) שולח את האימוג'י כתגובת ציטוט להודעה — מה שעד היום דרש 'השב' והקלדה ידנית. הספק (Green API) אינו תומך בשליחת ריאקציה נטיבית, ולכן הלקוח רואה הודעת תשובה עם האימוג'י ולא בועית ריאקציה. (3) צירוף קובץ בהדבקה ובגרירה: Ctrl+V עם תמונה או קובץ בלוח (למשל צילום מסך) פותח את דיאלוג השליחה עם הקובץ טעון והטקסט שהוקלד הופך לכיתוב; אפשר גם לגרור קובץ לאזור השיחה. (4) מפרידי תאריך: צ'יפ 'היום' / 'אתמול' / תאריך מלא מופיע בין הודעות כשמתחלף יום, כמו בוואטסאפ — במקום רצף אחד ללא התמצאות בזמן; בנוסף, בזמן גלילה צפה בראש הצ'אט תווית עם התאריך של ההודעות הנראות כרגע, והיא נעלמת כשהגלילה נעצרת.

• מצב בחירה מרובה: עד 30 הודעות בהעברה אחת, נשלחות בסדר כרונולוגי לכל יעד
• סימון 'הודעות שהועברו' פעם אחת בראש הצרור, לא על כל הודעה
• תגובת אימוג'י מהירה בריחוף ובתפריט — נשלחת כתגובת ציטוט (לספק אין ריאקציות נטיביות)
• Ctrl+V מדביק תמונה/קובץ ישירות לשיחה; הטיוטה שהוקלדה הופכת לכיתוב
• גרירת קובץ לאזור השיחה פותחת את דיאלוג הצירוף
• מפרידי 'היום' / 'אתמול' / תאריך מלא בציר ההודעות
• תווית תאריך צפה בראש הצ'אט בזמן גלילה — נעלמת כשהגלילה נעצרת

דוח הסנכרון באדמין הצטבר לאלפי רשומות rate_limit/timeout ישנות שאיש לא יכול היה לעשות איתן דבר: שגיאה חולפת היא תיעוד של קריאת API בודדת שנכשלה, לא מצב פתוח — אבל שום מנגנון לא סגר אותה, ומכיוון שה-crons מסנכרנים רק משלוחים פתוחים וטריים, ישות ישנה לעולם לא מנוסה שוב והשורה ישבה בדוח לנצח. שלושה תיקונים: (1) סנכרון מוצלח של משלוח סוגר מעכשיו את כל שגיאות הסנכרון הפתוחות שלו — לא רק not_found — כי קריאה שהצליחה זה עתה מפריכה את כולן; (2) ה-cron הלילי מסמן כפגות-תוקף (auto_expired) שגיאות חולפות שניסיון הכשל שלהן ישן מ-14 יום; (3) הצבר הקיים נוקה — 5,683 שורות ישנות נסגרו. שגיאות not_found (זרימת המחיקה האוטומטית) ו-forbidden (בעיית הרשאות שדורשת עין אנושית) לא נכללות בתפוגה. הדוח מציג מעכשיו רק כשלים עדכניים שאפשר לפעול לגביהם.

המקרה החי הראשון של דיווח-תלונה-לשליח חשף פער ניתוב: הלקוח התלונן שהמשלוח נמסר לכתובת הישנה — אבל השליח מסר בדיוק לכתובת שרשומה על המשלוח; האשם האמיתי הוא רשומות השולח, שממשיך להוציא הזמנות לכתובת שהנמען כבר ביקש לעדכן. הבוט מבצע כעת טריאז' אשמה לפני הדיווח: תלונת התנהלות/נזק של השליח (הונח במקום שגוי, ללא תיאום, נזק) ממשיכה לקבוצת השליח כולל התמונות; תלונת כתובת-לא-מעודכנת נשלחת דווקא לקבוצת הלקוח השולח — 📍 בקשה לעדכן את הכתובת ברשומותיו להזמנות הבאות, כולל הכתובת הנכונה כשהנמען מסר אותה. תבנית ההודעה לשולח ניתנת לעריכה בדף תרחישי הבוט, תחת אותו טוגל של תלונות המסירה. כשלא ברור מי אשם — הבוט לא מדווח לאף אחד והנציג מכריע.

ביקורת על 18 השעות הראשונות של תרחישי עדכון-השולח/שליח חשפה שתלונת מסירה אחת דווחה שלוש פעמים לקבוצת השליח: נציג סימן את השיחה 'טופל' בין הודעות הלקוח, היפוך הסטטוס איפס את מנגנון מניעת-הכפילויות, וכל הודעת המשך של הלקוח פתחה דיווח חדש. המנגנון בודק כעת את הערת ה-AI של השיחה בלבד, ללא תלות בסטטוס הטיפול — פנייה חוזרת באותו נושא מקבלת הערה 'הנמען חזר על הפנייה' במקום הודעה נוספת לקבוצה.

בתיאום עם קונימבו מומש 'שדר משלוח' — הלקוח לוחץ על הכפתור בהזמנה, וקונימבו דוחפת אותה לשיפנסט מיד, במקום משיכה אוטומטית. בניגוד לאישופ (endpoint פר-חנות), קונימבו שולחת את כל הלקוחות של כל הטננטים ל-endpoint גלובלי אחד, והזיהוי אצלנו נעשה לפי טוקן: לכל חיבור מונפק טוקן שהלקוח מעתיק להגדרות חברת השילוח בקונימבו. הטוקן נשמר מוצפן (להצגה חוזרת ללקוח) וה-SHA-256 שלו נשמר בעמודה מאונדקסת לחיפוש O(1) בקבלת ה-webhook (אותה גישה כמו מפתחות ה-API שלנו). ה-endpoint הגלובלי מזהה את החנות מהטוקן (מקבל אותו מ-header/query/body — גמיש, כי קונימבו טרם סגרו את התחבורה). הדחיפה נושאת רק את מספר ההזמנה, ולכן אנחנו מושכים את נתוני ההזמנה המלאים ב-GET /v1/orders/{id} עם הטוקן של החנות לפני היצירה, יוצרים משלוח ומשדרים לליונוויל, ואז מעדכנים את ההזמנה בקונימבו בחזרה: בהצלחה — סטטוס עם מספר המשלוח (מה שהלקוח רואה בממשק); בכישלון — סטטוס עם הסיבה. בפורטל נוסף לכרטיס חנות הקונימבו בלוק עם כתובת ה-Webhook והטוקן להעתקה, וכפתור 'צור טוקן / החלף טוקן'. השידור אידמפוטנטי (דדופ לפי מספר הזמנה) כך שדחיפה כפולה לא יוצרת משלוח כפול; המענה תמיד 200 אחרי אימות, כדי שלא ייווצר ניסיון חוזר.

• כפתור 'שדר משלוח' בקונימבו דוחף רק את מספר ההזמנה; שיפנסט מושכת את הנתונים המלאים ב-GET לפני היצירה
• endpoint גלובלי אחד לכל שיפנסט; זיהוי החנות לפי טוקן (SHA-256 מאונדקס לחיפוש מהיר)
• טוקן פר-לקוח, מוצפן להצגה חוזרת בפורטל עם כתובת ה-Webhook להעתקה
• דיווח חזרה להזמנה: הצלחה עם מספר המשלוח, כישלון עם הסיבה
• קונימבו שולחת token ו-order_id ב-query string (בלי headers מותאמים); ה-endpoint מקבל GET וגם POST
• אידמפוטנטי — דחיפה כפולה לא יוצרת משלוח כפול; מענה 200 מונע ניסיון חוזר

חיבור חנות קונימבו אמיתית ראשונה חשף שני פערים. (1) ייבוא ההזמנות מקונימבו יצר שורות מקומיות מתות עם ברקוד מזויף (KN-...) בלי שידור לליונוויל — בדיוק כמו הבאג שתוקן באישופ. כעת הייבוא עובר דרך הצינור המשותף של יצירת משלוח (createShipmentForTenant): שידור אמיתי לליונוויל, ברקוד אמיתי, פריטים, ודדופ אטומי (claim row) כמו ב-WooCommerce ואישופ. סנכרון המסירה חזרה לקונימבו נשמר. (2) קונימבו מחזירה HTTP 404 עם {status:not_found, message:'There are no orders for your query'} כשאין הזמנות חדשות — תשובת רשימה ריקה תקינה — אבל הקוד התייחס אליה ככישלון חיבור: כל מחזור סנכרון בלי הזמנה חדשה נרשם כשגיאה, צבר consecutiveFailures, שלח התראת מנהל, ובסוף היה משתיק את החנות ב-backoff. מכיוון שברוב חלונות ה-5 דקות אין הזמנה חדשה, חנות בריאה לחלוטין הייתה נראית שבורה. כעת listOrders מזהה את ה-404 הזה ומחזיר רשימה ריקה, בעוד 401/403/500 עדיין נזרקים כשגיאה אמיתית. בנוסף נוסף route אבחון פנימי (platform-only) לשליפת הזמנת קונימבו בודדת לפי מזהה (עוקף את חלון הסנכרון) לצורך בדיקה מקצה-לקצה.

• הזמנות קונימבו משודרות לליונוויל עם ברקוד אמיתי ופריטים — לא עוד שורות מקומיות מתות
• דדופ אטומי מונע יצירת שתי משימות ליונוויל לאותה הזמנה
• תוקן: '404 אין הזמנות' של קונימבו טופל ככישלון חיבור — סימן חנות תקינה ככושלת והשתיק אותה
• 401/403/500 עדיין מזוהים כשגיאות אמת

לקוח כתב בהודעה אחת שתי טענות אי-מסירה על שני משלוחים שונים ("25691330 ... לא קיבל ... 25981856 כתוב בוצע ולקוחה לא קיבלה כלום"). תרחיש טענת אי-מסירה לקח את המספר הראשון, פנה לנמען שלו בבקשת אישור, ובשקט השמיט את הטענה השנייה — כלומר פנה לנמען הלא-נכון על משלוח שהתלונה עליו הייתה של לקוח אחר. כעת, כשההודעה מזכירה יותר ממשלוח אחד בבירור, הבוט אינו מנחש על מי לפעול אלא פותח פתק לצוות עם ההודעה המלאה, כך שהצוות מטפל בשתי הטענות. משלוח יחיד (או משלוח שצוטט) עדיין מריץ את הזרימה המלאה. פנייה אוטומטית לנמען היא צעד רגיש, ולכן בכל עמימות עדיף פתק לצוות על פני ניחוש.

עד היום כל דיווח כשל מסירה מהשליח עדכן את הלקוח העסקי — כולל כשלים פנימיים שלנו: משלוח שהגיע לשליח בטעות מיון או שאינו באזור ההפצה שלו. לעדכן שולח ש"המשלוח לא נמסר" על טעות מיון שלנו זה גם שגוי (המשלוח פשוט ינותב מחדש) וגם מביך. כעת הדיווח עובר טריאז' לפני שמישהו מעודכן: כשל בצד השולח או הנמען (אין מענה, סירוב, כתובת שגויה) — הלקוח מעודכן עם הסיבה כרגיל; כשל פנימי (טעות מיון, מחוץ לאזור — מזוהה גם במילות מפתח דטרמיניסטיות וגם ב-AI) — נרשם פתק לצוות השירות בלבד והלקוח אינו מעודכן; וכשהסיבה לא ברורה — הבוט שואל את השליח בקבוצה "מה הסיבה?" ופועל לפי התשובה, כשבכל ספק ברירת המחדל היא פתק לצוות בלי לעדכן את הלקוח. גם שליח שלא ענה לשאלה בכלל לא נעלם: אחרי שש שעות נרשם פתק לצוות שהסיבה לא נמסרה. בנוסף נולד תרחיש חדש — "משלוח ניזוק": שליח שמדווח שמשלוח נשבר / נפגם / דולף / נקרע וחוזר, מפעיל עדכון לשולח עם תיאור ענייני של הנזק (מנוסח ללא האשמות וללא מידע פנימי) והודעה שהמשלוח מוחזר אליו.

• כשל פנימי (טעות מיון / לא באזור ההפצה) כבר לא מדווח לשולח — נרשם פתק לצוות בלבד
• סיבת כשל לא ברורה? הבוט שואל את השליח בקבוצה ומחליט לפי התשובה — בספק, פתק לצוות
• שליח שלא ענה לשאלת הסיבה — פתק אוטומטי לצוות אחרי שש שעות, שום כשל לא נעלם בשקט
• תרחיש חדש "משלוח ניזוק": דיווח נשבר/נפגם/דולף מעדכן את השולח שהמשלוח ניזוק וחוזר אליו

שני שיפורים בתרחיש השידור. (1) מדבקת משלוח נושאת גם את הברקוד שלנו וגם את המזהה שאנחנו משדרים אליו אצל הקבלן, וה-OCR קרא לעיתים את המזהה הזר — הקבוצה ראתה "מספר שזוהה: 2236987", מספר שלא אומר כלום לצוות. הזיהוי עצמו תמיד היה תקין (שני המספרים מובילים לאותו משלוח), אבל התצוגה בלבלה. כעת, כשהמערכת מאשרת שהמספר שנקרא הוא כינוי של אותו משלוח, מוצג הברקוד שלנו. קריאה שגויה באמת אינה נפתרת לכלום ונשארת כפי שנסרקה — אין כאן "תיקון" של OCR. (2) שידור מרובה בהודעה אחת הועלה מ-8 ל-16 משלוחים. קבלן שהדביק כ-35 ברקודים נאלץ לשלוח את היתרה ארבע פעמים. נמדד מהאירוע: 8 משלוחים ארכו כ-40 שניות, כ-5 שניות למשלוח, בעוד העבודה רצה ברקע אחרי שה-webhook כבר ענה — ולכן תקציב הריצה נקבע מפורשות ל-300 שניות ו-16 משלוחים (כ-80 שניות) יושבים בתוכו בהפרש גדול. לא הועלה יותר בכוונה: מגבלה גלויה שמסבירה את עצמה עדיפה על timeout שקט באמצע שידור, שבו חלק מהמשלוחים משודרים ואין תשובה כלל.

שני תיקונים בהעברת תשובות. (1) מילה בודדת ("בערב") נשלפה מתוך שיחה תפעולית חיה על איסוף בכתובת אחרת, ושויכה לבירור בן ארבע שעות על משלוח אחר לגמרי — השליח קיבל אותה כהנחיית השולח, בעוד ההודעה הבאה של הלקוח הייתה "בערב יהיה מאוחר". נבדק שסף זמן אינו פתרון: מדידה על 30 יום מראה ש-38% מהתשובות האמיתיות מגיעות אחרי שעתיים ו-25% אחרי ארבע שעות. לעומת זאת, מידת ההתקדמות של השיחה כן מפרידה — התשובה הקצרה הלגיטימית הרועשת ביותר הגיעה אחרי 11 הודעות ביניים, והשגויה אחרי 22. כעת תשובה קצרה מאוד שאינה מצטטת את השאלה ואינה מזכירה משלוח נפסלת כשהשיחה כבר התקדמה, ונשארת פתוחה לתשובה אמיתית. (2) תשובת השליח על צפי מסירה מועברת ללקוח בניסוח מסונן במקום כלשונה — שליח עונה לסדרן, לא ללקוח, ו-"היום, היום. הכל היום." יצא כצפי הרשמי. אותו מנגנון ניסוח שכבר משמש בתיאום מועד; אם לא נשאר תוכן בטוח, הטקסט המקורי עדיין עובר — צפי לא מלוטש עדיף על שתיקה.

עד היום הבוט של צ'אט לקוחות הקצה היה עיוור לתמונות: כל תמונה בלי הקשר חיובי מובהק גררה הסלמה שקטה לנציג — גם כשלקוחה שלחה צילום של השער שלה לצד 'נא להתקשר כדי שאפתח את השער' (מקרה אמת מהיום, משלוח 26352138). מעתה התמונות עצמן (עד 2 מהרצף האחרון) יורדות ממטא ומצורפות לבקשת הסיווג — הבוט רואה אותן: צילום הקשר (שער, דלת, בניין) מטופל כעזרה — ההוראה נרשמת לשליח כולל פרט ויזואלי מועיל ('שער חום כפול'), והלקוח מקבל תשובה; צילום של בעיה (חבילה פגומה, מוצר שגוי) מוסלם עם תיאור מדויק של מה שנראה; צילומי מסך נקראים כטקסט. עובד בכל שלושת ספקי ה-AI (Anthropic, Gemini, תואם-OpenAI). רשת ביטחון כפולה: כשל בהורדת תמונה מחזיר את הבוט לכללי העיוורון הזהירים, וגם שם רוככה ההתנהגות — הוראת מסירה טקסטואלית ברורה לצד תמונה שלא נבדקה מטופלת כרגיל עם הערה 'צורפה תמונה שלא נבדקה', במקום להעניש את הלקוח בשתיקה על צירוף תמונה מועילה.

• תמונות מהרצף האחרון (עד 2) מצורפות לסיווג — הבוט רואה ושופט אותן בעצמו
• צילום הקשר (שער/דלת/בניין) = עזרה: ההוראה נרשמת לשליח עם הפרט הוויזואלי, והלקוח נענה
• צילום בעיה (נזק/מוצר שגוי) = הסלמה עם תיאור מדויק של הנראה בתמונה
• כשל הורדה → נסיגה לכללים העיוורים, שרוככו: טקסט ברור + תמונה לא-נבדקת מטופל, לא מושתק
• בהמשך היום: תרחיש 'בקשת ביטול מהנמען — עדכון השולח' (הגדרות ← תרחישי בוט) — השולח מקבל שאלה לפי שלב המשלוח: טרם נאסף = 'ניתן לבטל, לאשר?'; כבר נאסף = 'לא ניתן לבטל — עצירה/החזרה?'; ההסלמה לנציג נשארת תמיד, והביטול בפועל לעולם לא אוטומטי
• תרחיש 'תלונת מסירה/נזק — דיווח לשליח': תלונה על משלוח שנמסר (הונח במקום שגוי / נזק) מדווחת אוטומטית לקבוצת השליח המשובץ — כולל העברת התמונות שהנמען צירף ככיתוב על הדיווח; רק בסטטוס נמסר/הושלם, רק לקבוצה מקושרת, וההסלמה לנציג נשארת

משלוח שנמסר בזמן הוצג בפאנל 'סטטוס צ'קליסט / עיכוב' כ'מעוכב 6 ימי עסקים', והופיע גם בטבלת פערי ההפצה. שתי סיבות נפרדות: (1) הפאנל בעמוד המשלוח חישב עיכוב משעון פערי-ההפצה בלי לבדוק שהמשלוח עדיין פתוח — השעון הוא sticky בכוונה, ולכן כל משלוח שנמסר 'צבר עיכוב' לנצח; מעתה החישוב מגודר לסטטוסי הפצה פתוחים, כמו בשאר המסכים. (2) בפערי ההפצה הסינון לפי סטטוס דווקא עבד — אבל הנתון עצמו היה שגוי: לפני תיקון ה-OCC מ-17/07, שני webhooks מקבילים ברגע המסירה יכלו לדרוס בשקט את סטטוס 'הושלם' חזרה ל'יצא להפצה' (בלי שום רישום), וגם אחרי התיקון — הד ישן מליונוויל שהגיע יותר מ-15 דקות אחרי המסירה (נצפו 56 דקות ואף 4 ימים) עקף את מגן הרגרסיה, פתח מחדש משלוחים שנמסרו ואף שלח ללקוח הודעת 'יצא להפצה' באיחור. המגן הורחב: כשביקור המסירה שלנו כבר הושלם בפועל, שום סטטוס לא-טרמינלי נכנס לא פותח מחדש את המשלוח, בלי תלות בחלון הזמן. בנוסף רוצף כל המצאי ההיסטורי: 18 משלוחים שנמסרו אך נשארו תקועים בסטטוס פתוח (חלקם מאז יולי 2025) אומתו אחד-אחד מול ליונוויל ותוקנו ל'הושלם' עם רישום מלא ביומן הפעילות.

שליח דיווח על בעיה, הבוט פנה ללקוח, ההודעה ללקוח לא נמסרה — והשליח נשאר בלי מענה. הבוט פעל נכון: הוא מדכא את האישור "מברר מול הלקוח" כשהשאלה לא הגיעה ליעדה, כדי לא להבטיח בירור שלא קרה. אבל התוצאה הייתה מבוי סתום שקט שאיש לא ידע עליו. כעת נכתב פתק לצוות בשרשור של השליח, המסביר שההודעה לא נמסרה (ככל הנראה מספר שאינו WhatsApp) ושהשליח ממתין למענה. בנוסף — הבוט מפסיק לנסות לשלוח למספרים שאינם ניידים: קו משרדי (02/03/04/08/09) או VoIP (077/078) אינם יכולים לקבל WhatsApp, ומתוך 440 לקוחות פעילים ל-23 מספר כזה הוא היעד היחיד. במקום שליחה שנדונה מראש לכישלון, הפנייה עוברת ישירות לטיפול הצוות.

כשהסירו שיבוץ של שליח או קבלן מתוך דף פרטי המשלוח (וגם ממסך האיסופים), ההסרה נשמרה רק אצלנו — בליונוויל המשימה נשארה משובצת לשליח הקודם. הסיבה: בקוד עדכון המשימה, הבלוק ששולח את ההסרה לליונוויל ישב בתוך ענף השיבוץ — ענף שרץ רק כשבוחרים שליח חדש — ולכן בפועל מעולם לא הופעל. הסרה דרך בורר השליחים ברשימת המשלוחים דווקא כן סונכרנה, ומכאן התחושה שזה עובד 'לפעמים'. מעתה כל הסרת שיבוץ שולחת לליונוויל את ניקוי השליח מהמשימה, בדיוק כמו במסלול ההמוני.

שורת 'קליטה' בציר הזמן של עמוד המשלוח הוצגה מתוך שדה שעון פערי-ההפצה, שנחתם כבר במעבר הראשון לסטטוס פעיל — כלומר ברגע האיסוף מבית העסק. משלוח שנאסף ונסרק למחסן רק כעבור כמה ימים הציג 'קליטה' עם תאריך האיסוף, זהה לשורת 'איסוף' שמעליה, במקום מועד הסריקה בפועל. מעתה השורה קוראת את תאריך הקליטה למחסן האמיתי (inInventoryAt), ומשלוח שטרם נקלט פשוט לא מציג שורת קליטה. עמודת 'תאריך קליטה מלקוח' בטבלת המשלוחים לא השתנתה — שם השדה הישן מוצג בכוונה ותחת שם מדויק.

כששיבצנו איסוף על קבלן הפצה, שיגור המשימה אליו בליונוויל התייחס אליה כמשלוח רגיל — כתובת היעד מופתה אצל הקבלן ככתובת האיסוף, וכדי שהכתובות יגיעו נכון היה צריך לבחור ידנית 'איסוף' בדיאלוג השיגור. הסיבה: משימת איסוף שנוצרה מהמערכת נולדה בליונוויל ללא סוג (task_type) — השדה נשמר עד היום רק אצלנו ולא נשלח אליהם. מעתה כל יצירת משלוח שולחת את הסוג לליונוויל, כך שאיסופים מתויגים כ'איסוף' מרגע היצירה — מה שאמור ליישר גם את ברירת המחדל של שיגור לקבלן. הסוג נקבע אך ורק ברגע היצירה; משימות קיימות אי אפשר לתקן בדיעבד, ושם הבחירה הידנית בדיאלוג נשארת.

כל כניסה של לקוח לדשבורד ירתה 21 שאילתות בבת אחת: ספירה נפרדת לכל אחד מ-12 קודי הסטטוס, ועוד שבע ספירות סיכום. ההנמקה שנרשמה בקוד הייתה ש'זמן התגובה נקבע לפי השאילתה האיטית ביותר, לא לפי מספרן' — נכון לגבי זמן תגובה, אבל לא לגבי מאגר החיבורים, שגודלו 10. כלומר טעינה אחת ביקשה בערך פי שניים מכל המאגר, ובכניסות מקבילות של כמה לקוחות זה מפסיק להיות דף איטי והופך לשגיאת timeout על המאגר — אותו כשל שנרשם ב-02/07. כל הספירות האלה מסננות ממילא את אותה עמודת סטטוס, ולכן GROUP BY אחד מחזיר את כולן: הדשבורד ירד ל-5 שאילתות. המספרים זהים לחלוטין, כולל שורות עם סטטוס ריק או לא מוכר שממשיכות להיספר תחת 'לא ידוע', והפילוח לפי קוד בפאנל הצדדי נשאר כשהיה. הלוגיקה חולצה לפונקציה משותפת עם בדיקות שמקבעות את השקילות.

תקלת הבוקר חשפה נקודה עיוורת: ה-webhook של Green API החזיר 500 כל דקה במשך כעשר שעות ואיש לא קיבל התראה, בעוד שטיימאאוטים חולפים של ספקים חיצוניים כן צלצלו — בדיוק הפוך מהרצוי. הסיבה: כל 500 לא-מטופל הועבר ללוגר עם notifyAdmin=false, בכוונה, כדי לא לשלוח WhatsApp על כל שגיאה בודדת. השיקול נכון, אבל 'לעולם לא להתריע' הפך מסלול ששבור ברציפות לבלתי-נראה. נוסף מונה כשלים פר-מסלול בחלון מתגלגל: שגיאה בודדת או שתיים לא מייצרות רעש, אבל מסלול שנכשל שוב ושוב מייצר התראה אחת — ואז שותק לשעה כדי לא להציף. הספירה ב-Redis (אותו חיבור של מגביל הקצב), כך שהסף גלובלי ולא נספר בנפרד בכל instance; בלי Redis יש נפילה חיננית לזיכרון. במקביל, שליפת המשלוח מליונוויל מקבלת ניסיון חוזר אחד — רק ל-GET, לעולם לא ל-POST/PUT, כדי שניסיון חוזר לא ייצור משלוח כפול — ותקרת הזמן של ה-webhook הועלתה כך שהשלבים המאוחרים לא ייקטעו בשקט באמצע.

• התראה על מסלול שנכשל ברציפות, במקום שקט מוחלט על 500 לא-מטופל
• שגיאה בודדת או שתיים לא מייצרות התראה — רק כשל מתמשך חוצה את הסף
• התראה אחת למסלול לשעה, כך שתקלה מתמשכת לא מציפה את הטלפון
• הספירה ב-Redis ולכן גלובלית לכל ה-instances; בלי Redis נפילה חיננית לזיכרון
• ניסיון חוזר לשליפת משלוח מליונוויל — רק לקריאות GET, לעולם לא ליצירה או לעדכון סטטוס
• תקרת הזמן של webhook ליונוויל הועלתה, כדי ששלבים מאוחרים לא ייקטעו בשקט

שני סטטוסים נשאו את השמות שהגיעו מאוצר המילים של המוביל ושימשו כזהות הקנונית שלנו: ROUNDTRIP_DELIVERED ו-FINAL_FAILED. הם הוחלפו ב-DELIVERED_PENDING_RETURN ו-UNDELIVERABLE — שמות שגם מתארים מדויק יותר מה קורה בפועל. שאר תשעת הסטטוסים לא נגעו: שישה מהם מונחים לוגיסטיים גנריים שקיימים בכל מערכת בעולם, ושלושה (סטטוסי המחסן) הם ממילא הרחבה של Shipnest. השינוי לא דרש מיגרציית נתונים ולא שבר אף מנוי webhook.

• אין מיגרציית נתונים — שורות קיימות שמחזיקות את הטוקן הישן ממשיכות להתנרמל דרך LEGACY_STATUS_ALIASES, ו-rawStatusValues מוסיף אותו לפילטרי SQL כך שהן עדיין נתפסות
• ה-webhook shipment.status_changed ממשיך לשלוח את הערכים הישנים דרך toOutboundStatus — מנויים קיימים לא מושפעים, וההחלפה תגיע בגרסת API הבאה עם הודעה מראש
• תוקן באג שהתגלה תוך כדי: עמוד המעקב הציבורי החזיק עותק כפול של טבלת הסטטוסים, שהיה מציג כל משלוח עם טוקן ישן כ'משלוח חדש'. הוחלף בייבוא מהמקור המשותף
• נוספו 7 טסטים שמצמידים את שלושת מנגנוני התאימות

מפתח API של פרודקשן לליונוויל היה כתוב במפורש בארבעה סקריפטים מאז ה-3 ביוני. המפתח הוחלף בקריאה ל-LIONWHEEL_API_KEY מהסביבה, ושלושת סקריפטי ה-probe (בדיקת שדות שיטתית ומנייה של endpoints לא מתועדים) הושבתו בחסימה קשיחה — ליונוויל עדכנה את תנאי השימוש שלה ב-20 ביולי, ונספח א' סעיף 7.2 אוסר במפורש על enumeration ו-probing. הקבצים נשמרו כרישום היסטורי ולא נמחקו. נוסף מסמך docs/development-chronology.md המתעד את סדר בניית המערכת מתוך היסטוריית ה-git. בהמשך היום נוקה גם התיעוד הציבורי: הוסרו טבלת קודי הסטטוס המספריים של ליונוויל ורשימת מגבלות ה-API שלהם, והוחלפו בתיאור התנהגות הסנכרון מצד Shipnest. בנוסף, כל שימוש במפתח הגלובלי המשותף נרשם עכשיו ללוג פעם אחת לכל call site, ומשתנה הסביבה LIONWHEEL_REQUIRE_TENANT_KEY מאפשר להפוך אותו לשגיאה קשיחה אחרי שכל הטננטים יוגדרו. לבסוף נוסף ל-pre-commit hook סורק credentials שחוסם commit שמוסיף מפתח או token בקוד — נבדק מול 60 הcommits האחרונים ללא התראות שווא. הרוטציה עצמה חסומה: בממשק של ליונוויל אין אפשרות להנפיק מפתח מחדש, כך שהמפתח הישן נשאר תקף עד שתטופל פנייה לתמיכה שלהם.

רוטציית ה-secrets של אינטגרציית Prisma-Vercel העבירה הבוקר את כתובת ה-Accelerate למשתנה DATABASE_PRISMA_DATABASE_URL, בעוד DATABASE_URL נדרס לכתובת postgres:// ישירה. התיקון הקודם עדכן את בניית ה-client כך שיעדיף את המשתנה החדש, אבל ההחלטה האם להחיל את הרחבת Accelerate המשיכה לקרוא את DATABASE_URL הגולמי בלבד — כך שה-client דיבר דרך Accelerate בלי ההרחבה שלו. התוצאה: כל שאילתה עם cacheStrategy נזרקה עם 'Unknown argument cacheStrategy', ובראשן שליפת ה-webhookSecret הפר-tenant — מה שהחזיר 500 על כל קריאה ל-webhook של Green API, אחת לדקה, וחסם כל הודעת WhatsApp נכנסת (ה-inbox, הבוט ומנוע התרחישים). שתי ההחלטות נגזרות עכשיו ממקור אמת יחיד, ונוסף טסט רגרסיה שמכסה בדיוק את הצירוף הזה.

אנחנו קוראים כל מה שקורה בקבוצות של הלקוחות והשליחים, אבל עד היום כמעט לא עשינו עם זה כלום: הבוט הגיב לכמה תרחישים וסגר את הפנייה, וכל השאר — פניות שירות, טענות כשל, אין מענה, טעויות כתובת, טעויות מיון, התכתבויות בקבוצות המחסן — נשאר קבור ב-inbox בלי שום קשר למשלוח שעליו דובר. הסיבה הטכנית: אף טבלת הודעות במערכת לא נשאה מזהה משלוח, ולכן 'תראה לי כל מה שנאמר על משלוח X' לא היה ניתן לשאילתה בכלל. נוספה שכבת קישור ייעודית, וכפתור חדש בכותרת דף המשלוח שפותח 'תיק המשלוח': ציר זמן אחד שמאחד את שיחות הקבוצות, בירורי הבוט, התראות הצוות, מחלוקות המסירה, הערות ה-AI וניסיונות המסירה — מקובץ לפי יום, עם סינון לפי סוג ומעבר לשיחה המלאה. הקישור דטרמיניסטי בלבד: הודעה נכנסת לתיק רק כשהיא מציינת מספר משלוח אמיתי, או כשהתרחיש/הבירור כבר ידע בוודאות על איזה משלוח מדובר — אין ניחוש ואין עלות AI. שלושה תרחישים שעד היום לא תיעדו דבר (בקשת פרטי משלוח, דיווח כשל מסירה, שיוך איסוף) מתעדים כעת את פעולתם.

• כפתור 'תיק המשלוח' בכותרת דף המשלוח — בתצוגה המלאה ובחלונית הצדדית כאחד
• ציר זמן מאוחד: שיחות קבוצה, בירורי בוט, התראות צוות, מחלוקות מסירה, הערות AI וניסיונות מסירה
• כל הודעה בקבוצה שמזכירה מספר משלוח נכנסת לתיק — גם כשאף תרחיש לא הופעל והבוט שתק בכוונה
• קישור דטרמיניסטי בלבד: ברקוד תקין בהודעה, ציטוט הודעה מזוהה, או בירור שכבר ידע את המשלוח — ללא הסקה וללא עלות AI
• סינון לפי סוג (שיחות / בירורי בוט / התראות / ניסיונות מסירה) עם מונים, וקיבוץ לפי יום
• הודעה שמונה כמה משלוחים (דוח מרוכז / תשובה מרוכזת של קבלן) מפוצלת — כל תיק מקבל רק את הקטע שלו, ולא את פרטי שאר הלקוחות
• סקריפט מילוי-לאחור מחיל את אותו כלל בדיוק על היסטוריית השיחות הקיימת

אותה תקלה שתוקנה אתמול בדוח עמלות הסוכן התגלתה (בסריקת-מערכת של כל שדות החיפוש) גם בדוח התשלום החודשי של השליח — טאב 'תשלומים' בכרטיס השליח. בטבלת המשלוחים, כל הקשה בשדה החיפוש ציירה מחדש את כל שורות החודש: לשליח עמוס אלפי שורות (למשל 1263 בחודש), כל אחת עם ברקוד ותגית, מה שחסם את הקלט לשניות (רינדור מלא של 1263 השורות נמדד ב-~11 שניות). עכשיו הטבלה המוטמעת המשותפת (EmbeddedDataTable) מגבילה את הרינדור ל-50 שורות עם כפתור 'הצג הכל', כך שכל הקשה מציירת חופן שורות בלבד — ההקלדה מיידית והסינון מיידי, בעוד שהמעבר בין הטאבים (מסירות/איסופים/החזרות…) והסיכומים ממשיכים לשקף את מלוא הנתונים. התיקון חל גם על שאר הטבלאות המוטמעות בכרטיס השליח (משלוחים, ביקורים אחרונים, צ'ק-ליסט), שנהנות מאותה תקרה.

המשך תוכנית ההיערכות לסקיילינג: (1) רשומות ה-audit של משלוחים — 99.5% מטבלת היומן, הרעש התפעולי של ה-webhooks — נמחקות מעתה אוטומטית אחרי 12 חודשים (במנות, בניקוי הלילי); כל שאר סוגי הרשומות (משתמשים, הרשאות, קונפיג) נשמרים לצמיתות. (2) סטטיסטיקות הגוביינא הפכו את כיוון הסינון: במקום לטעון את רשימת כל הברקודים הפעילים (שגדלה עם הטבלה) לכל טעינת מסך, נטענת רק רשימת היתומים (אנומליות בודדות שנשארות זעירות) — אומת בבדיקת שוויון מלאה מול נתוני production. (3) דוח גודל DB שבועי נכתב ללוג (סך הכול + 10 הטבלאות הגדולות), עם התראת WhatsApp לאדמין אם הגודל חוצה 20GB.

בטבלת 'פירוט לפי לקוח' שבדוח העמלות, הקלדה בשדה החיפוש השתהתה שניות והתצוגה קפצה — כל הקשה ציירה מחדש את כל הרשימות בדוח, כולל רשימת המשלוחים (אלפי שורות) ואת כל שורות הלקוחות, מה שחסם את שדה הקלט. עכשיו רשימת המשלוחים הכבדה ממוזכרת (memo) ואינה מצוירת מחדש בזמן חיפוש לקוח, וטבלת הלקוחות מגבילה את מספר השורות המצוירות ל-30 עם כפתור 'הצג הכל' — כך שכל הקשה מציירת חופן שורות בלבד. הסינון מיידי, הקלט חלק, והכולל בתחתית הטבלה ממשיך לסכם את כל התוצאות המסוננות (לא רק את המוצגות). השהיית ההקלדה ירדה מ-2–5 שניות ל-פחות מ-100 מ״ש.

סבב ראשון מתוכנית ההיערכות לסקיילינג: דף פערי ההפצה הוסב לסינון על עמודות מסונכרנות (is_roundtrip) ולשליפת נהגים מטבלת הביקורים במקום חקירת JSON על כל משלוח — אומת בבדיקת שוויון מול נתוני production (זהות מלאה בנהגים ובתאריכי מסירה); נוספה תקרת שורות לשאילתות המסך. ה-crons של ניקוי הלוגים והגלגול היומי עברו למחיקה/עדכון במנות עם תקציב זמן כך שצבר גדול לא יתקע אותם, ההתראות היזומות קיבלו תקציב זמן שמונע קטיעה באמצע שליחה, ותורת שגיאות הסנכרון תוחמה. היסטוריית משלוחי לקוח קיבלה תקרת עמודים מחייבת, ומפתח גישה שהיה כתוב בקוד הועבר למשתנה סביבה. בהמשך היום נוסף שלב הוזלת ה-webhooks: אירוע Lionwheel כפול (payload זהה בייט-בבייט) נעצר עכשיו בשער אחרי שאילתה אחת במקום להריץ את כל צינור העיבוד (15–45 פניות DB + קריאות Lionwheel), באמצעות טבלת webhook_logs הקיימת עם אילוץ ייחודיות אטומי; ושאילתות ה-secrets שרצות על כל webhook נכנס (Lionwheel / Meta / Green API) עוברות עכשיו דרך cache של דקה ב-Prisma Accelerate — חיסכון ישיר בעלות שאילתות שגדל עם התנועה. שלב שלישי באותו יום — קצבי רשתות הביטחון: חותמות הסנכרון (lastSyncAt) ומעקב בדיקות ה-POD קודמו מ-JSON לעמודות אמיתיות עם backfill מלא, כך שבחירת המועמדים לסנכרון כבר לא מפרקת את ה-JSON המלא של כל שורה; תור ההודעות המתוזמנות עבר לעיבוד מקבילי בין חברות (סדרתי בתוך חברה — שמירה על קצב ה-instance) עם תקרה של 150 להרצה במקום 50; רשתות הביטחון מול Lionwheel הוגדלו (200 לרבע שעה למשלוחים טריים, 300 כל שעתיים לפתוחים); וההתאמה הלילית של עלויות עברה ללולאה פר-חברה שמנצלת את האינדקס הייעודי. שלב רביעי — מגביל הקצב עבר מזיכרון מקומי ל-Redis: עד היום כל instance ב-Vercel ספר לעצמו, כך שמגבלות ה-API הציבורי וההגנה מפני ניסיונות התחברות כוחניים כמעט לא נאכפו תחת עומס; עכשיו המונה גלובלי (אותו Redis שמשמש את עדכוני הזמן-אמת), עם נפילה אוטומטית לזיכרון מקומי ל-30 שניות בכל תקלת Redis — בקשה לגיטימית לעולם לא תיחסם בגלל תשתית.

עד היום, נמען שכתב לבוט 'לא הזמנתי כלום' או 'טעות במספר' קיבל הפניה לבית העסק (שהוא בכלל לא מכיר) — וההתראות האוטומטיות המשיכו להישלח למספר השגוי. מעתה הבוט מזהה את המקרה כתרחיש ייעודי: עונה לנמען בחום שאין צורך בשום פעולה מצדו, שולח הודעה אוטומטית לבית העסק השולח בצ'אט העסקי (עם מספר המשלוח, שם הנמען ותוכן הטענה, ובקשה לאשר ביטול או לעדכן פרטים), משתיק את ההתראות האוטומטיות למספר ל-30 יום (גם הודעות שכבר ממתינות בתור), ומתעד הכל בהערה לצוות. אם לשולח אין צ'אט עסקי מקושר — השיחה מוסלמת לנציג עם הסבר. בנוסף תוקנה דליפת הסלמות גדולה: כשספק ה-AI המוגדר ל-tenant נכשל (מפתח נדחה, חריגת מכסה, JSON שבור) — כ-30% מכלל ההסלמות — הבוט מנסה כעת אוטומטית ספק גיבוי מערכתי לפני שהוא מוותר ומעביר לנציג.

• תרחיש 'לא הזמנתי / זה לא אני / טעות במספר' מזוהה ומטופל אוטומטית מקצה לקצה
• הודעה אוטומטית לשולח בצ'אט העסקי — עם פרטי המשלוח ובקשת הנחיה (ביטול / עדכון פרטים)
• השתקת התראות אוטומטיות למספר שדווח כשגוי ל-30 יום, כולל הודעות שממתינות בתור
• fallback לספק AI מערכתי כשספק ה-tenant נכשל — חוסך כ-30% מההסלמות שנגרמו משגיאות טכניות
• התרחיש מנוהל מדף הגדרות ← תרחישי בוט: טוגל הפעלה פר-חברה (כבוי כברירת מחדל) ותבנית הודעת-שולח ניתנת לעריכה
• המשך היום (מסקנות ניתוח 184 שיחות אמת): הבוט רואה כעת את שם בית העסק השולח, את רשומת המסירה (מתי נמסר, איך, למי — כולל חשד לסימון 'נמסר' בשעת לילה) ואת כל המשלוחים של הטלפון — כפילויות ומשלוחים מחזוריים
• הודעות הֲכָלָה בהסלמות רגישות: חריגת SLA, 'נמסר אבל לא קיבלתי' וערעור על ניסיון מסירה — הלקוח מקבל התנצלות + 'נפתח בירור' + התחייבות למועד תשובה, במקום שתיקה
• סולם טיפול חדש לערעור על 'ניסיון מסירה נכשל' (הכוונה הגדולה בהסלמות): נמסר? נבדוק · כשל איסוף? מרגיעים · כתובת חסרה? מבקשים · אחרת — בלי להתווכח, הסלמה מסודרת
• הבוט נוקב בשם השולח כשנמען שואל 'מי שלח לי את זה?' (שם בלבד, לעולם לא טלפון/כתובת) — במקום 'פנה לבית העסק' חסר-מוצא
• אימות לפני דגל ב'לא הזמנתי': טענה עמומה מקבלת שאלת אימות אחת לפני השתקה ועדכון שולח — מונע השתקת נמען אמיתי
• בקשות ביטול/עצירה ('תבטלו', 'אל תשלחו', 'כבר אספתי') מזוהות, מאושרות ללקוח ומוסלמות עם הערה מובנית — במקום להירשם בטעות כהוראת מסירה
• כשל איסוף מבית העסק לא נשלח יותר לנמען כ'ניסיון מסירה נכשל' — ההתראה המבהילה שייצרה גל פניות תמיכה הושתקה (השולח עדיין מיודע)
• יכולת 'לא לספק לפני תאריך' (hold): הבוט קולט בקשת דחייה, מאמת תאריך (עתידי, עד 14 יום), מטביע על המשלוח, מסנכרן הוראה בולטת לשליח בליונוויל — ויציאה מוקדמת להפצה מציפה התראת מנהל

דף הסוכן היה רכיב client בן ~430 שורות ששלף את GET /api/agents/[id] בטעינה מאחורי ספינר, עם פריסת שתי-עמודות עמוסה. הוא נבנה מחדש כ-Shell מרונדר-שרת קבוע (הדר זהות + שורת טאבים + רייל מאפיינים מתקפל) סביב שני טאבים מבוססי-ראוט: 'סקירה' (משתמשים מקושרים, לקוחות משויכים, פילוח לידים, הערות) ו'עמלות' (דוח עמלות חודשי + כללי עמלה + חיוב/זיכוי). הטעינה מיידית ללא ספינר, ולכל טאב יש URL משלו וניתן לקישור ישיר. ההדר צומצם לפעולת עריכה אחת; פרטי הקשר (טלפון, אימייל, חברה, עמלת ברירת מחדל, תאריך הצטרפות) עברו לרייל מתקפל בקצה — בדיוק כמו בדף הלקוח ובדף השליח/קבלן. ההרשאות נפתרות פעם אחת בשרת: טאב 'עמלות' לא מרונדר כלל למי שאין לו הרשאת צפייה-בעמלות או עריכה, וגישה ישירה ל-URL שלו מחזירה 404. סוכן שצופה בדף שלו יכול לקרוא אך לעולם לא לערוך. אותו דפוס בדיוק של העיצוב מחדש שנעשה לדף הלקוח ולדף השליח.

• רינדור-שרת במקום שליפת-client מאחורי ספינר — טעינה מיידית, URL ייעודי לכל טאב
• שני טאבים: 'סקירה' (משתמשים, לקוחות, לידים, הערות) ו'עמלות' (דוח + כללים + חיובים)
• טאב 'עמלות' מגודר בהרשאה שנפתרת בשרת — אינו מופיע ללא הרשאת עמלות/עריכה, ו-404 בגישה ישירה
• רייל מאפיינים מתקפל (סטטוס, טלפון, אימייל, עמלה, הצטרפות) — עקבי עם דף הלקוח והשליח
• ה-Shell (הדר + רייל) קבוע ואינו מרונדר מחדש במעבר בין טאבים

עובדים שכירים שעובדים בממשק הניהול יכולים מעתה להחתים כניסה/יציאה ישירות מהסרגל העליון — כפתור 'כנס למשמרת' שהופך למונה שעות חי עם סטטוס משמרת. הרכיב עצמו היה קיים במערכת אך לא הייתה דרך להפעיל אותו: נוסף שדה 'קישור לרשומת עובד (נוכחות)' בטופס עריכת משתמש שמחבר חשבון ניהול לרשומת עובד. הקישור נאכף מול ה-tenant, עובד שכבר מקושר למשתמש אחר מסומן וחסום לבחירה, ומשתמשים מקושרים ממשיכים להופיע בדף ניהול המשתמשים (עד היום הם נעלמו ממנו). השינוי נכנס לתוקף בהתחברות הבאה של המשתמש המקושר. בהמשך היום תוקנו שני באגים שמנעו מהכפתור להופיע בפועל: (1) ה-session בדפדפן לא קיבל את קישור העובד עבור משתמשי צוות — ה-callback שמשרת את הדפדפן לא העביר את השדה, בניגוד למקבילה שלו ב-middleware; (2) 'התחבר כמשתמש' (התחזות) לא אימץ את קישור העובד של משתמש היעד, וביציאה מהתחזות הקישור של המנהל עצמו נמחק עד ההתחברות הבאה. עכשיו ההתחזות משקפת נאמנה גם את זהות הנוכחות של המשתמש. תיקון שלישי ואחרון: הרשאות הנוכחות-העצמית (צפייה והחתמה) היו מוענקות רק לתפקיד 'שליח שכיר', כך שעובד מקושר בכל תפקיד אחר (אדמין, נציג שירות, מחסנאי וכו') קיבל 403 שקט והכפתור לא הוצג; ההרשאות הוענקו לכל תפקידי הצוות — הן ממילא מוגבלות לעצמי ולא פעילות ללא קישור עובד. אומת מקצה-לקצה בדפדפן: כפתור 'כנס למשמרת' מופיע בהתחזות למשתמש מקושר. ותיקון משלים: שער הכניסה למודול ניהול הנוכחות חסם כל משתמש מקושר-עובד ללא דגל גישה מפורש — גם אדמינים; מעתה הקישור לעובד לא מוריד הרשאות שהתפקיד כבר מקנה: מי שתפקידו כולל ניהול עובדים שומר על גישה מלאה למודול, והחסימה (עם דגל ה-override) חלה רק על עובדים שעתיים בתפקידים ללא הרשאת ניהול.

עד היום POST /api/v1/shipments יצר את המשלוח במערכת המקומית בלבד — לקוחה שיצרה משלוח דרך אוטומציה (Make) קיבלה רשומה עם הברקוד הפנימי שלה (1-23290) שלא הגיעה מעולם לליונוויל ולשליחים. מעתה, כשהמשלוח משויך ללקוח מקושר לליונוויל, היצירה עוברת דרך אותו pipeline משותף של יצירה ידנית/פורטל/ייבוא: ליונוויל מנפיק את ברקוד המעקב האמיתי, הברקוד ששלח הקורא נשמר כ-externalOrderId (זמין לחיפוש ב-GET ?externalOrderId=), בדיקת הכפילויות תופסת קריאה חוזרת גם לפי externalOrderId, וכשל שיגור מחזיר שגיאה ברורה במקום ליצור משלוח רפאים. כתובת מוצא נשלחת לליונוויל רק אם הקורא סיפק כתובת אמיתית (sourceName לבדו לא דורס את נקודת האיסוף של החברה). אם ה-tenant לא מחובר לליונוויל או שהלקוח לא מקושר — נשמרת ההתנהגות הישנה (יצירה מקומית בלבד). המשלוח התקוע 1-23290 שוגר בדיעבד (ברקוד חדש 26326550, כולל העתקת יעד האקספרס שהוגדר ידנית) והרשומה הישנה הועברה לסל המיחזור. תיעוד ה-API הציבורי עודכן בהתאם.

• POST /api/v1/shipments משגר לליונוויל דרך ה-pipeline המשותף כשהלקוח מקושר
• הברקוד של הקורא נשמר כ-externalOrderId; ליונוויל מנפיק את ברקוד המעקב
• בדיקת כפילויות גם לפי externalOrderId — קריאה חוזרת לא יוצרת כפילות
• fallback ליצירה מקומית בלבד כשאין ליונוויל (ההתנהגות הקודמת)
• המשלוח התקוע 1-23290 שוגר בדיעבד כ-26326550

השלמת שני הפריטים שנצפו בבדיקת הלוגים של יום ראשון. (1) מנוע סנכרון-השדות ל-Lionwheel (עריכת כתובת/טלפון/חבילות/מחיר מהמערכת, מהפורטל, מהדף הציבורי ומהבוט) עבד עד היום בקריאה יחידה עם timeout של 30 שניות ובלי retry — רגע איטי של Lionwheel איבד את העריכה, וה-webhook הבא מהם אף היה עלול לדרוס אותה מקומית בערך הישן. עכשיו: קריאות דרך ה-client המרכזי (timeout 10s), עד 3 ניסיונות עם backoff על כשלים חולפים, שליפות-האימות רצות רק כשבאמת צריך (חוסך שתי קריאות לכל סנכרון של חבילות/מחיר), וכשל-אימות כבר לא נספר ככשל סנכרון. (2) ה-cron של סנכרון סטטוסי בלדר נהרג ב-SIGKILL כשה-proxy היה איטי (התקציב הפנימי לא קוטע קריאה שבאוויר) — הורחב ל-120/90 שניות, ודחיפת הסטטוס ל-Lionwheel שבתוכו עברה ל-helper המשותף עם retry, מה שסוגר גם מקרה קצה שבו סטטוס מקומי התעדכן אך Lionwheel לא היה מקבל אותו לעולם.

בטאב התמחור של דף הלקוח הוצגה קטגוריית תעריף 'החזרה' (RETURN) — שדה שריד שאינו מחויב באף מסלול: חיוב לקוח בוחר רק מסירה/איסוף, ורגל ההחזרה של כפולה מתומחרת בתוך תוספת הכפולה. הקטגוריה הוסרה מקבוצת 'תוספות', ושורת הסיכום בדיאלוג טעינת תבנית מציגה כעת מסירה ואיסוף בלבד.

לקוח בפורטל ראה בדף "API ו-Webhooks" את כל מפתחות ה-API של הטננט — כולל מפתחות שהנפיקו לקוחות אחרים ומפתחות צוות — ולא רק את שלו. כך לקוח חדש שטרם יצר מפתח ראה שני מפתחות פעילים ששייכים לשני לקוחות אחרים, על שמם, ה-prefix, ה-scopes ומועד השימוש האחרון שלהם. הסיבה: שאילתות הרשימה והביטול סיננו לפי tenantId בלבד, בלי customerId — למרות שמסלול היצירה כבר קושר כל מפתח ללקוח המנפיק, ושכבת האימות של ה-API הציבורי כבר מכבדת את הקישור הזה. תוקן בשלושת המקומות: טעינת ה-SSR של הדף, GET /api/portal/api-keys, ו-DELETE /api/portal/api-keys/[id] — שם הצירוף tenant+customer מלווה גם את פעולת הכתיבה עצמה ולא רק את החיפוש, כך שלקוח לא יכול לבטל מפתח ייצור של לקוח אחר. בנוסף, מכסת המפתחות הפעילים (10) נספרת מעתה לפי לקוח ולא לפי טננט — קודם לכן לקוח שמילא את המכסה חסם את שאר לקוחות הטננט מהנפקת מפתחות. נוספו בדיקות רגרסיה לשתי הנתיבות. — בעקבות הממצא נסרקו כל 40 מסלולי ה-API של הפורטל וכל רכיבי השרת שלו, ונמצאו שתי תקלות נוספות מאותה משפחה: (1) POST /api/portal/ai/chat קיבל sessionId מגוף הבקשה בלי לאמת בעלות — היסטוריית השיחה נטענה לפי tenantId בלבד ומוזרקת לפרומפט, כך שלקוח יכול היה לקבל סיכום של שיחת AI של לקוח אחר (ו-AiChatSession הוא מרחב מזהים משותף שכולל גם שיחות צוות פנימיות ושיחות WhatsApp מול צד שלישי); בנוסף עדכון כותרת השיחה בוצע לפי id בלבד, בלי tenantId, כלומר חצה טננטים. נוסף אימות בעלות (tenant+customer+context) לפני השימוש, והכתיבות עברו ל-updateMany עם אותו צירוף. (2) מסלולי /api/portal/team התעלמו מ-scopedCustomerIds של המנהל עצמו — ההנחה הייתה ש"בעלים לעולם אינם מוגבלים", אך אוסף ההרשאות שמנהל פורטל רשאי להעניק הוא superset של הרשאות הבעלים, כך שמנהל יכול היה להפוך משתמש מוגבל ל"בעלים" ולתת לו גישה לרשימת המשתמשים של חשבונות מחוץ להיקפו — כולל איפוס הזמנה שמייצר קישור התחברות פעיל. נבדק מול ה-DB: 0 משתמשים חיים במצב הזה, כלומר לטנטי בלבד. בנוסף נאכף שרתית portalAiEnabled (קודם רק הוסתר הווידג'ט בצד לקוח).

• מפתחות API בפורטל — סינון לפי לקוח ולא לפי טננט, בשלוש שאילתות
• ביטול מפתח — הצירוף tenant+customer מלווה גם את הכתיבה (updateMany)
• צ'אט AI בפורטל — אימות בעלות על sessionId לפני טעינת היסטוריה
• ניהול צוות בפורטל — מנהל מוגבל נשאר מוגבל
• מכסת מפתחות פעילים נספרת לפי לקוח
• 11 בדיקות רגרסיה חדשות; 1445 בדיקות עוברות

אחרי השידור האמיתי הראשון לזיפ התגלו כמה שדות שלא נקלטו נכון, ותוקנו: (1) טלפון — נשלח בפורמט בינלאומי (+972…) שזיפ לא קולט; מומר כעת לפורמט ישראלי מקומי (0…). (2) כניסה/קומה/דירה — נדחסו בטעות לשדה מספר הבית; נשלחים כעת בשדות הייעודיים של בלדר (35/36/37), ולכן השורה גדלה מ-28 ל-37 פרמטרים (בלדר מתעלם מהעודפים אצל חברות שלא תומכות). (3) טלפונים נוספים (additionalPhones) — לבלדר אין שדה עבורם, ולכן הם משורשרים כעת להוראות המשלוח כ'טל נוסף: …' (ההוראות מגיעות לשליח). כל הטלפונים מנורמלים לפורמט מקומי.

סדרת תיקונים לחיבור השידור מול שרת בלדר של זיפ. שורש הבעיה האמיתי (שהתגלה בסוף): פרוקסי היציאה שלנו (squid) החזיר 403 בניסיון לפתוח מנהור CONNECT לפורט 58090 — squid מתיר CONNECT רק לפורט 443 כברירת מחדל, ו-undici פותח מנהור CONNECT גם ל-HTTP רגיל. התוצאה: התקשורת בכלל לא יצאה אל זיפ (ה-whitelist שלהם היה תקין כל הזמן). התיקון: שליחת בקשות בלדר דרך הפרוקסי בשיטת forwarding רגיל (absolute-form) במקום CONNECT — squid מתיר זאת לפורט 58090 (טווח Safe_ports). בדרך תוקנו גם: (1) התחברות לפי כתובת IPv4 שאנחנו פותרים בעצמנו (רשומת A בלבד) — עוקף את רשומת ה-IPv6 השבורה של זיפ (fe80::1) שגרמה להמתנה של 20 שניות; (2) חשיפת שרשרת השגיאה המלאה + כתובת היעד בלוג; (3) בבדיקת החיבור מוצגת כתובת ה-IP המדויקת שיוצאת אלינו (138.199.167.152).

שתי תשתיות שמשנות את קצב האחזקה של האפליקציה: (1) OTA — נוסף expo-updates עם runtimeVersion לפי fingerprint וערוצי EAS (preview/production). מהבנייה הזו והלאה, תיקוני JS (לא-נייטיביים) יגיעו לשליחים אוטומטית דרך 'eas update' — בלי בנייה מלאה והתקנה ידנית בכל פעם. (2) דיווח קריסות — נוסף @sentry/react-native + ErrorBoundary מותאם (מסך 'משהו השתבש' עם 'נסה שוב' במקום קריסה אדומה), עם תיוג כל אירוע ב-update-id/ערוץ כדי לאתר מאיזה bundle הקריסה. Sentry מגודר ב-EXPO_PUBLIC_SENTRY_DSN — no-op עד שמוגדר DSN, כך שה-build עובד עם או בלי חשבון Sentry. שינוי נייטיבי — נכלל ב-build v1.2.0 (versionCode 6) שיש לבנות פעם אחת; אחריו העדכונים אלחוטיים.

• OTA: תיקוני JS עתידיים מגיעים אוטומטית (eas update) בלי build והתקנה ידנית
• runtimeVersion=fingerprint — במפ גרסה חופשי, OTA נשבר רק בשינוי נייטיבי
• Sentry + ErrorBoundary: מסך שגיאה ידידותי + דיווח קריסות מתויג ל-update-id
• מגודר ב-DSN — ה-build עובד עם או בלי חשבון Sentry

חשבון שננעל אוטומטית אחרי חמישה ניסיונות כושלים הציג למשתמש את ההודעה הגנרית "אימייל או סיסמה שגויים", בלי שום רמז לכך שהחשבון נעול ושהמתנה תפתור את זה. הסיבה טכנית: כל שגיאה שנזרקת בשלב אימות הפרטים נבלעה על ידי ספריית ההתחברות והגיעה לדפדפן כמחרוזת חסרת משמעות, כך שהסיבה האמיתית אבדה בשרת. כעת השגיאות נושאות קוד שעובר ללקוח, והמסך אומר מה קרה: חשבון נעול (כולל הפניה לאיפוס סיסמה), חשבון לא פעיל, או חשבון שנפתח דרך Google ואין לו סיסמה. שגיאת סיסמה שגויה וכתובת שאינה קיימת ממשיכות להחזיר את אותה הודעה בדיוק, כדי שלא ניתן יהיה לגלות דרך מסך ההתחברות אילו כתובות רשומות במערכת.

הרחבה לכלי פתיחת המשלוח מהצ'אט: עד כה הוא ידע לפתוח מסירה רגילה בלבד. כעת הוא מזהה את סוג המשלוח מבקשת הנציג ותומך בשלושה סוגים, בדיוק כמו טופס יצירת המשלוח: מסירה, **איסוף מלקוח**, ו**כפולה** (מסירה + איסוף חזרה באותו מעמד), בתוספת **יעד שבת** (פרשה) לכל סוג. באיסוף הכיוון מתהפך — הנציג נותן את כתובת המוצא (מאיפה אוספים) והיעד נלקח אוטומטית מכתובת העסק של הלקוח, כך שהעוזר לא מבקש מהנציג את הצד שהמערכת כבר יודעת; אם ללקוח לא מוגדרת כתובת עסק, הכלי אומר זאת במפורש במקום להמציא יעד. אכיפת שדות החובה הותאמה לסוג: באיסוף נדרשים שם המקום, טלפון וכתובת האיסוף — ולא פרטי נמען. הכפולה נשלחת בסימון הנכון (is_roundtrip בלבד, בלי סוג משימה) — הכלל שאומת מול נתוני הפרודקשן בטופס. התצוגה המקדימה מציגה את סוג המשלוח ואת שני צידי הכתובת, כדי שהנציג יוכל לוודא את הכיוון לפני האישור. 28 טסטים מכסים את שלושת הסוגים.

• פתיחת איסוף מלקוח — הנציג נותן את כתובת האיסוף, היעד נלקח מכתובת העסק אוטומטית
• פתיחת כפולה (מסירה + איסוף חזרה) בסימון הנכון
• יעד שבת (פרשה) בכל סוג משלוח
• שדות החובה והתצוגה המקדימה מותאמים לסוג — באיסוף לא נדרשים פרטי נמען
• ללקוח בלי כתובת עסק — הכלי מסרב לפתוח איסוף במקום להמציא יעד

נוסף כפתור 'בדיקת חיבור' בכרטיס השידורים של נהג בלדר, שמריץ בדיקה מול השרת של הקבלן דרך אותו נתיב פרוקסי שבו משתמש השידור בפועל — קריאת GetCustomerRecords לקריאה-בלבד, בלי ליצור הזמנה. כך אפשר לוודא שכתובת השירות, קוד הלקוח, ורשימת ההיתר (whitelist) של ה-IP שלנו אצל הקבלן תקינים — לפני שמשדרים משלוח אמיתי. הבדיקה מציגה כמה משלוחים נמצאו ואת זמן התגובה, או את הודעת השגיאה המדויקת. רצה מול ההגדרות השמורות (יש לשמור לפני בדיקה).

מניתוח שיחות אמת (16/07): נציג ביקש לשלוח לשליח 'חזי דרוויש' והעוזר השיב 'לא מצאתי שליח בשם זה — תעביר לו את ההודעה ידנית'. השליח קיים ופעיל במערכת. שורש הבאג: שם השליח מפוצל לשני שדות (שם פרטי 'חזי', שם משפחה 'דרוויש'), והחיפוש חיפש את המחרוזת המלאה בכל שדה בנפרד — כך ש**שם מלא לא יכול היה להימצא לעולם**, בשום כלי (פרטי שליח, שיוך שליח, שליחה לקבוצה). כעת החיפוש מפרק את השם למילים ודורש שכל מילה תופיע באחד משדות השם, כך ש'חזי דרוויש' מאתר את השליח הנכון ואינו מתבלבל עם 'חזי גוזלן'; בנוסף מועדף שליח פעיל על פני שליח לא-פעיל בעל שם זהה. תיקון שני מאותה שיחה: הנציג ביקש במפורש לפנות לשליח מסוים 'למרות שלא עליו המשלוח' — עד כה הכלי ידע לפנות רק לשליח המשויך למשלוח; כעת ניתן לציין שליח אחר בשם או במזהה, עם אותה בדיקת חד-משמעיות (שם שמתאים לכמה שליחים מחזיר רשימה לבחירה ולא מנחש), ותוך שמירה מלאה על המדיניות שהבוט פונה לקבוצות בלבד. בנוסף: לקוח ששמו מכיל שם עיר ('מלכות ירושלים') סונן בטעות לפי העיר והוחזרו 142 משלוחים של כל הלקוחות במקום 10 של הלקוח — ההנחיות חודדו.

• שם שליח מלא ('חזי דרוויש') מאותר סוף-סוף — קודם כל חיפוש בשם מלא נכשל בהכרח
• אפשר לפנות לשליח שאינו משויך למשלוח, לפי שם או מזהה, עם בדיקת חד-משמעיות
• שליח פעיל מועדף על פני לא-פעיל בעל שם זהה
• לקוח ששמו מכיל שם עיר ('מלכות ירושלים') כבר לא מסונן כעיר

מדיניות חדשה: הבוט לעולם אינו פותח צ׳אט אישי מול שליח או קבלן, אלא פונה רק לקבוצה המשויכת (שלו, או של המנהל שלו במקרה של שליח-משנה). אם אין קבוצה מקושרת — הבוט לא שולח לשום מקום, אלא מעביר לטיפול הצוות. עד כה שלושה נתיבים נפלו חזרה לצ׳אט אישי לפי מספר הטלפון של השליח: מנגנון פתרון הקבוצה המשותף (שמשרת את תרחישי הצפי, טענת אי-מסירה, יידוע שיבוץ איסוף ותזכורות הצ׳קליסט), תרחיש תיאום מועד מחדש, וכלי ה-AI לשליחת הודעה לשליח. קבוצה היא מרחב משותף שבו הצוות רואה מה נאמר ויכול להתערב; צ׳אט אישי אינו כזה. בנוסף, תרחיש תיאום המועד עבר להשתמש במנגנון המשותף, כך שגם שליח-משנה מקבל את הפנייה בקבוצת המנהל שלו במקום להיות מפוספס. לצד זה חודדה הגדרת תרחיש הצפי כך שבקשה לשנות סכום גוביינא, דיווח על נזק, בקשת ביטול או שאלת חיוב לא ייקראו בטעות כשאלת צפי מסירה. בנוסף — יידוע שיבוץ איסוף מדלג כעת על שליח מושבת: קבלן שהופסקה עבודתו קיבל הודעה על שיבוץ והשיב שזו טעות, ולכן הבדיקה הורחבה מ"אינו שכיר" גם ל"פעיל".

שני תיקונים לזיהוי המשלוח שהשליח מדבר עליו. (1) כששליח שאל על משימה שמשובצת עליו, הבוט חיפש רק ביקורי מסירה — ולכן משימת איסוף הייתה בלתי-נראית לו לגמרי: שאלה עם מספר קיבלה "לא משויך אליך", ושאלה בלי מספר גרמה לבוט לנחש משלוח מסירה אחר ולהקריא את פרטיו (השליח שאל "מאיפה האיסוף הזה" וקיבל כתובת של משלוח אחר). כעת גם ביקורי איסוף בתמונה, וכששתי משימות פתוחות — הבוט שותק במקום לנחש. (2) בתרחיש השידור, ציטוט שיושב על הודעה סמוכה ברצף (השליח מגיב "מחר בבוקר" על הודעת השיבוץ ואז כותב "תשים עלי" בהודעה נפרדת) לא נקרא, והבוט ביקש מספר משלוח שהוצג לו זה עתה. כעת נסרקים הציטוטים בכל הרצף.

ברשימת הצ'אטים, הכפתור שנחשף במעבר עכבר על שורה היה 'העבר לארכיון' — ונציגות דיווחו שהן לוחצות עליו בטעות ומעבירות לקוחות פעילים לארכיון. הכפתור הזה הוחלף בטוגל 'סמן כנקרא' / 'סמן כלא נקרא' (לפי מצב הצ'אט), פעולה הפיכה שלא גורמת נזק בלחיצה מקרית. ההעברה לארכיון והשחזור ממנו נשארו זמינים בתפריט הקליק-ימני על השורה ובכותרת הצ'אט הפתוח. בנוסף — סימון הצ'אט הפתוח כ'לא נקרא' סוגר אותו עכשיו, כמו בוואטסאפ; קודם הסימון לא היה נראה כלל כי מחוון ה'לא נקרא' מוסתר על השורה הפעילה, והצ'אט היה מסומן כנקרא שוב בהודעה הבאה.

לקוחות ביקשו לא שנמשוך הזמנות אוטומטית אלא שהם ישדרו באופן סלקטיבי, כמו כפתור 'שדר הזמנה' שהכירו מליונוויל. בתיאום עם הצוות הטכני של אישופ מומש בדיוק זה, בלי שאישופ נדרשו לפתח דבר: בעל החנות מעביר הזמנה לסטטוס ייעודי (למשל 'שדר לשיפנסט') — וזה מה שמפעיל אצלם webhook שדוחף אלינו את ההזמנה מיד. שיפנסט יוצרת את המשלוח ומשדרת לליונוויל, ואז מעדכנת את ההזמנה בחזרה בחנות: בהצלחה — סטטוס 'שודר בהצלחה' עם מספר המשלוח; בכישלון — סטטוס 'כישלון בשידור' עם הסיבה בהערות מנהל. כך בעל החנות רואה את התוצאה בממשק שלו, בלי להיכנס לשיפנסט. נוסף מסך הגדרות לבחירת שלושת הסטטוסים (מפעיל / הצלחה / כישלון) מתוך הרשימה האמיתית של החנות, כפתור 'רשום Webhook' שמבצע את הרישום מול אישופ, ומתג לכיבוי המשיכה האוטומטית — כך שבמצב שידור יזום לא נשרפת מכסת ה-API של החנות ולא נמשכות הזמנות ישנות. האימות נעשה בטוקן סודי אקראי שנוצר בכל רישום ונשמר מוצפן (אישופ עדיין לא תומכים ב-headers מותאמים, ולכן הטוקן עובר ב-query string) ונבדק בהשוואה עמידת-תזמון, fail-closed.

• שידור יזום: העברת הזמנה לסטטוס ייעודי דוחפת אותה לשיפנסט מיד — במקום משיכה אוטומטית עיוורת
• דיווח חזרה להזמנה: הצלחה עם מספר משלוח, או כישלון עם הסיבה בהערות מנהל
• בחירת שלושת הסטטוסים (מפעיל/הצלחה/כישלון) מתוך רשימת הסטטוסים האמיתית של החנות
• כפתור 'רשום Webhook' — רישום אוטומטי מול אישופ עם הסטטוס שנבחר
• מתג לכיבוי המשיכה האוטומטית — חוסך את מכסת ה-API של החנות
• אימות fail-closed בטוקן אקראי מוצפן, בהשוואה עמידת-תזמון
• כישלון שידור לעולם לא מוחזר כשגיאה לאישופ — כדי שלא ייווצר ניסיון חוזר וכפילות
• תיקון המשך: מניעת שורות כפולות משני webhooks מקבילים — אירוע זהה שנצפה פעמיים אינו נרשם שוב, ושתי שורות "יצירה" שנוצרו במרוץ מתאחות לאחת

יומן הפעולות של משלוח היה עמוס וחלקית שגוי. שיבוץ שליח שהגיע מסנכרון ליונוויל לא נרשם כלל — driverId יושב על הביקור בעוד שבלוק ההשוואה בדק רק עמודות של המשלוח — ולכן השאלה 'מי שיבץ את השליח הזה' לא הייתה ניתנת למענה בלי לחפור בלוגים של Vercel. במקביל, כל מעבר סטטוס נרשם פעמיים משני מפיקים שונים: אחד בערכים קנוניים ואחד במחרוזות עברית, כשהאחרון היה גם המקום היחיד במערכת ששמר טקסט תצוגה לתוך oldData/newData ולכן שבר בשקט כל צרכן שמשווה מול enum, וגם השווה ערכים לא-מנורמלים כך שסטטוס מספרי מליונוויל מול ערך שמור יצר שורת סרק 'הושלם ← הושלם'. נוסף לכך, 6 שיבוצים מאפליקציית המנהלים נכתבו עם entityType באות גדולה וללא ברקוד ב-details, ולכן היו בלתי נראים בכל טיימליין במערכת.

• שיבוץ שליח מסנכרון ליונוויל נרשם כעת עם שם השליח, סוג הרגל (איסוף/מסירה/החזרה) והמקור — כולל שיבוץ שהגיע כבר ברגע יצירת המשלוח
• מפיק יחיד לסטטוס בערכים קנוניים; העברית מיוצרת בקריאה דרך STATUS_DISPLAY_MAPPING
• מיזוג אוטומטי של פרץ webhooks לשורה אחת (חלון 15 שניות, לפי מבצע זהה בלבד) — מעברי הביניים נשמרים במלואם ונפתחים בלחיצה
• ריצוד הסטטוס שליונוויל מייצרת בכל משימה שנוצרת ב-API מתקפל לשורה אחת במקום ארבע
• שורות ביקור מקושרות למשלוח לפי מזהה ולא לפי טקסט, ו-entityType מנורמל — שיבוצים מאפליקציית המנהלים מופיעים סוף-סוף
• מבצע הפעולה מוצג גם בשינויי סטטוס נגזרים משיבוץ, שקודם הופיעו ללא מבצע

רשימת המשלוחים סיננה לסוכן לפי הלקוחות המשויכים אליו, אבל הקריאה של משלוח בודד (by-barcode, row, ו-GET לפי מזהה) סיננה לפי tenant בלבד. מכיוון שהברקוד הוא מונה רץ, סוכן שהדביק מספר ברקוד בכתובת יכול היה לפתוח כל משלוח ב-tenant — כולל לקוחות שאינם משויכים לאף סוכן — ולראות טלפוני נמענים, כתובות, הערות, תמונות מסירה והערות AI. שלושת הנתיבים מחילים כעת בדיוק את אותו סינון שהרשימה מחילה (customerId של לקוחות הסוכן, או התאמת שם למשלוחים ישנים ללא customerId), כך שמשלוח שהסוכן רואה ברשימה נשאר נגיש ושום דבר מעבר לכך לא. תוקן במקביל גם GET של לקוח בודד, שהיה הנתיב היחיד בלקוחות ללא סינון סוכן. עריכה לא הייתה חשופה — היא דורשת הרשאה שאין לסוכן. מסך הסריקה במחסן הושאר ללא סינון במכוון, כדי שסורק יזהה כל חבילה פיזית שמגיעה לידיו. בהמשך לכך תוקן גם המקור עצמו: התראות הזמן-אמת (SSE) שודרו לכל משתמשי ה-tenant ללא סינון, כך שסוכן קיבל התראת 'כשל משלוח' עם הברקוד על משלוח שאינו שלו — ומשם הגיע אליו בלחיצה. הזרם מסונן כעת לפי אותו היקף לקוחות, כך שסוכן מקבל התראות רק על המשלוחים שלו וכל התראה שהוא מקבל אכן נפתחת.

המשך תיקון האיסופים: השם שהוצג בכרטיס איסוף היה איש הקשר במקום האיסוף (sourceRecipientName, למשל 'מאור') ולא בית העסק השולח. בלוח המשימות זה השם החשוב — לכן ה-name לאיסוף מציג כעת את בית העסק (sourceName, עם נפילה ל-customerName / שם הביקור, ורק כמוצא אחרון לאיש הקשר כדי שהכרטיס לא יישאר ריק). בדף המשלוח המלא מוצגים שניהם: שם בית העסק, ומתחתיו 'איש קשר: ...' (שדה contactPerson חדש בתגובת ה-API, מוסתר כשהוא זהה לשם או ריק). מחרוזות ריקות מטופלות כחסרות. הצד השרתי (הרשימה) חי מיד; שורת 'איש קשר' בדף המשלוח מגיעה עם build המובייל v1.2.0.

עושה סדר לשליח: כמה משימות איסוף מאותו שולח באותה כתובת מתקבצות כעת לעצירת-איסוף אחת ברשימת היום — כרטיס שמציג את הלקוח, הכתובת ומספר המשלוחים, במקום N משימות נפרדות (הקיבוץ לפי שולח+כתובת, זהה לדף /pickups, דרך pickupGroupKey מהשרת). לחיצה על העצירה פותחת מסך פירוט: כותרת עם ניווט לכתובת האיסוף, פס התקדמות (נאספו/סה"כ), ורשימת כל המשלוחים עם הסטטוס שלהם. סגירת העצירה נעשית בסריקה: כפתור 'סרוק לאיסוף' פותח את הסורק במצב-איסוף — כל סריקה של ברקוד אוספת משלוח אחד מהקבוצה (מאמת שהוא שייך לעצירה), מציגה התקדמות (3/10), ונשארת פתוחה לחבילה הבאה. מסירות אינן מתקבצות. בנוסף, נוספה בחירה מרובה: לחיצה ארוכה על משימה ובחירת 'בחירה' נכנסת למצב בחירה עם צ'קבוקסים על הכרטיסים; אפשר לסמן כמה משימות (או עצירת-איסוף שלמה בבת אחת) ולבצע פעולה על כולן — הוספה או הסרה מהמסלול — דרך endpoint bulk יחיד. נכלל ב-build המובייל v1.2.0 (versionCode 6).

• כמה איסופים מאותו שולח+כתובת = עצירת-איסוף אחת (במקום N משימות)
• מסך עצירה: ניווט, פס התקדמות נאספו/סה"כ, ורשימת המשלוחים
• סגירה בסריקה — כל ברקוד אוסף משלוח, עם התקדמות (3/10)
• בחירה מרובה: סימון כמה משימות והוספה/הסרה מהמסלול בבת אחת

תשתית לשני פיצ'רים חדשים באפליקציה (ה-UI יגיע ב-build הבא): (1) ה-API של 'היום' מחזיר כעת pickupGroupKey לכל משימת איסוף — מפתח קיבוץ לפי שולח+כתובת, זהה לזה של דף /pickups — כדי שהאפליקציה תקבץ מספר איסופים מאותו לקוח באותה כתובת לעצירה אחת. (2) נוסף endpoint לבחירה מרובה במסלול (route/stops/bulk) המקבל רשימת visitIds ופעולה add/remove, לביצוע פעולה על כמה משימות בבת אחת. שניהם מגובים באימות בעלות (רק ביקורים של הנהג).

המשך לתיקון האיסופים: מאחר שמשלוח עבר geocoding ליעד בלבד, משימת איסוף באפליקציה נותרה ללא קואורדינטות מקור — ולכן הוצג 'אין קואורדינטות' במקום מפה, ולא חושב מרחק מהשליח. נוספו עמודות source_latitude/source_longitude ופונקציית geocoding לכתובת המקור (geocodeShipmentSource: קואורדינטות ביקור-האיסוף → רחוב המקור → מרכז יישוב המקור). ה-API מחזיר כעת לאיסוף את קואורדינטות המקור (ביקור → מקור, לעולם לא היעד), כך שהמפה, המרחק והניווט מצביעים על נקודת האיסוף. כמו כן, שם הלקוח בכרטיס איסוף שהיה יכול להיות ריק (כשכל שדות המקור ריקים) נופל כעת ל-customerName. הקואורדינטות מגובות אחורנית למשלוחי האיסוף הרלוונטיים (סקריפט backfill, ממוקד באיסופים פתוחים המשובצים לנהג — מה שמופיע בפועל בפיד היומי, לא בכל ההיסטוריה) ומחושבות אוטומטית למשלוחים חדשים עם רגל איסוף.

דלי האחסון של המערכת משותף לכל סוגי הקבצים והיה ציבורי, כלומר כל קישור שדלף נשאר תקף לצמיתות. שני צעדים ראשונים לקראת סגירתו: (1) בבירור מסירה, תמונת ההוכחה של השליח הועברה ללקוח העסקי דרך קישור ציבורי ששרתי Green API משכו בעצמם — עכשיו הבתים נשלחים אליהם ישירות. זו הייתה התלות החיצונית היחידה בכך שהדלי יישאר ציבורי. קישור חתום לא היה תחליף בטוח כאן, שכן תשובת 200 מ-Green משמעה "בתור" ולא "נשלח", והמשיכה עלולה להגיע אחרי שהקישור פג. (2) מסמכי עובדים — ת"ז, רישיונות וחוזי העסקה — הוצגו עד היום דרך קישור ציבורי קבוע שנשמר במסד הנתונים והוחזר ללקוח. כעת הם נמשכים דרך מסלול מאומת שבודק הרשאה, מסנן לפי הטננט (ובמסך העובד — גם לפי העובד עצמו מה-session), ומפנה לקישור חתום שתקף לשעה. נתיב האחסון והקישור הציבורי כבר לא מוחזרים באף תשובת API. בשני המקרים ההתנהגות למשתמש זהה, ותנאי הסינון של הבוט לא שונו.

אותו עיצוב מחדש שיושם על דף הלקוח, עכשיו על דף השליח/קבלן. הדף היה מונוליט של 2,357 שורות בקובץ אחד, עם הדר של 8 כפתורים שטוחים וטור כרטיסים שנמתח הרבה מתחת לקיפול. הוא מפורק עכשיו למסגרת קבועה — זהות, פעולות, שורת טאבים ורייל מאפיינים — סביב חמישה טאבים שהם ראוטים אמיתיים: סקירה (KPI, מפת מסלול, heatmap, ערים, כשלונות), משלוחים (פעילים/כשלים, צ'קליסט, ביקורים אחרונים, גוביינא), תשלומים (רווחים, מחירון, התאמות ומשמרות לעובדים), תת-שליחים (למנהלים בלבד), והגדרות (שידור לקבלנים חיצוניים, קבוצת וואטסאפ, חשבונות). סט הטאבים משתנה לפי סוג השליח — מנהל רואה תת-שליחים, עובד מקבל משמרות והתאמות בתשלומים, קבלן חיצוני מקבל את כרטיס השידור — וכל ראוט מותנה מוגן בשרת. בניגוד לטאב 'כספים' בלקוח, טאב 'תשלומים' נשאר פתוח ללא גייטינג — דף השליח מעולם לא הסתיר רווחים ומחירון מהצוות, וסדרנים משתמשים בהם. ההדר ירד משמונה כפתורים לשניים: 'שבץ משלוחים' קודם לפעולה הראשית (הסיבה הכי נפוצה שפותחים שליח — לתת לו עבודה; קודם היה קבור בתוך טבלת המשלוחים), 'עריכה' יורד למשני, ופעולות הסטטוס והחשבונות עוברות ל-⋮. חייג ו-WhatsApp עוברים לרייל. בנוסף: המגירה שנפתחת מכל שם שליח הפכה לתצוגה מקדימה מהירה במקום עותק שני של הדף, עם endpoint רזה (/preview, ארבע שאילתות במקום עשרים) שגם סוגר פער הרשאות — הוא דורש עכשיו DRIVERS_VIEW.

• חמישה טאבים אמיתיים (ראוטים) במקום מונוליט של 2,357 שורות — כל טאב טוען רק את מה שהוא מרנדר
• סט הטאבים משתנה לפי סוג השליח (מנהל / עובד / קבלן חיצוני), עם guard בשרת לכל ראוט מותנה
• ההדר ירד מ-8 כפתורים לשניים; 'שבץ משלוחים' קודם לפעולה הראשית
• רייל מאפיינים קבוע — 6 שדות מקודמים ו'הצג הכל'; חייג ו-WhatsApp עברו לרייל
• טאב תשלומים נשאר פתוח (בלי גייטינג) — בשונה מטאב הכספים בלקוח
• המגירה הפכה לתצוגה מקדימה מהירה; ה-endpoint שמזין אותה ירד ל-4 שאילתות ודורש DRIVERS_VIEW

מפת התצוגה בטופס יצירת המשלוח הראתה עד היום את מרכז היישוב בלבד ("מרכז הישוב, לא ברמת רחוב") — כך שטעות ברחוב או במספר לא הופיעה על המפה. כעת, ברגע שמוזן רחוב, המפה נפתרת ברמת רחוב (MapTiler, מנוצל מהמנוי בתשלום) ומראה את נקודת המסירה האמיתית, כך שאפשר לתפוס כתובת שגויה לפני שמירה — הפרש טיפוסי בין מרכז-עיר לכתובת מדויקת הוא מאות מטרים עד קילומטרים. התווית מציינת "כתובת מדויקת" (ירוק) כשההתאמה ברמת רחוב, או "מרכז הישוב" כשיש רק עיר. תוקן תוך כדי גם באג בפורטל: מפת התצוגה בטופס הפורטל קראה ל-/api/geocode של הצוות ולכן קיבלה 401 והמפה לא הופיעה כלל — נוסף /api/portal/geocode עם אימות פורטל. הלוגיקה המשותפת (resolveAddressPreview) חיה במקום אחד ומשמשת את שני המסלולים.

תחקור עומק של כל התהליכים האוטומטיים במערכת (webhooks, crons, שליחות WhatsApp, סנכרוני חנויות) חשף שורה של מרוצי-מקביליות ונקודות אובדן — כולן טופלו בסבב אחד. הצינור של Lionwheel קיבל הגנת עדכון-מקבילי (OCC) כך ששני webhooks על אותו משלוח לא דורסים זה את זה, ומגן רגרסיה שמונע מאירוע ישן שמגיע באיחור 'לפתוח מחדש' משלוח שכבר נמסר; דחיפות סטטוס ל-Lionwheel ושליחות מתוזמנות קיבלו retry אוטומטי ו-claim אטומי שמונע הודעה כפולה ללקוח; אישור מסירה ב-WhatsApp כבר לא יכול להירשם פעמיים או להיתקע במצב ביניים; webhooks יוצאים ללקוחות API לא יישלחו שוב על-ידי ריצות חופפות; שמירת נהג עוטפה בטרנזקציה (כשל חלקי כבר לא מוחק אזורי שיבוץ); ותוקנו שתי הפרות FK פעילות (יומן מחירון לקוח, audit מהפורטל). בנוסף: סנכרון הזמנה פגומה מחנות כבר לא תוקע את כל החנות, מסכי סטטיסטיקות כבדים רוסנו מול ה-connection pool, וטקסט עם אימוג'י חתוך כבר לא מפיל את עדכון שיחות ה-WhatsApp.

• הגנת מקביליות + מגן רגרסיית-סטטוס על צינור ה-webhook של Lionwheel
• retry אוטומטי לדחיפות סטטוס ל-Lionwheel ולשליחות WhatsApp מתוזמנות
• claim אטומי בהודעות מתוזמנות וב-webhooks יוצאים — סוף לשליחות כפולות
• אישור מסירה: תפיסה אטומית + שחזור אוטומטי ממצב ביניים תקוע
• שמירת נהג בטרנזקציה — כשל חלקי לא מוחק יותר אזורי שיבוץ
• תוקנו שתי הפרות FK פעילות ומגן מספר-דמה לפני שליחת WhatsApp
• סבב המשך: retry בטוח לכל שליחות ה-WhatsApp המיידיות (כשל רשת/429/כשלי gateway — בלי סיכון כפילות על timeout)
• עבודת רקע (התראות קבוצה, סנכרון שותפים, טריגרים) מעוגנת ל-after() — לא נקטעת יותר עם החזרת ה-response
• חלון TTL של 2 דקות לסנכרון תזרים המזומנים — דפדוף בין חודשים כבר לא מפעיל חישוב מלא כל פעם (הכפתור הידני עוקף)
• לוחות ה-crons פוזרו על דקות שונות — סוף לפרץ המסונכרן של 10 ריצות בו-זמנית כל 5 דקות
• שידור SNL/בלדר דוחף סטטוס ל-Lionwheel דרך ה-helper המשותף (כולל retry) במקום קוד קשיח

ניצול המנוי בתשלום של MapTiler (Flex Pro) בשני מקומות עם ערך אמיתי. (1) דף המעקב הציבורי הציג עד היום iframe גנרי של OpenStreetMap עם תוויות באנגלית ומראה בסיסי. הוחלף בתמונת Static Map של MapTiler — תוויות עברית, marker על נקודת המסירה, מודעת theme (בהיר/כהה), ועטופה בקישור "פתח במפות" שפותח את המיקום ב-Google Maps / אפליקציית המפות של הנמען. אם התמונה נכשלת (תקלת MapTiler) יש נפילה חזרה ל-iframe של OSM, כך שהמפה אף פעם לא נעלמת. (2) גיבוי דיוק: בזמן שחשבון MapTiler היה מושהה על חריגת מכסה, ~1,100 משלוחים מהחודש האחרון קיבלו קואורדינטות בדיוק נמוך (fallback ל-Nominatim, מרכז-יישוב, או ללא) — כעת שהחשבון בתשלום, הם עברו re-geocoding ברמת רחוב דרך MapTiler. שיעור הדיוק הגבוה עלה מ-86% ל-90%.

השלמת חבילת יישור-החיוב לליונוויל: (1) מסך הגדרות ← העדפות קיבל סקציית 'בסיס ייחוס חיוב' — בחירה בין ייחוס לפי תאריך האיסוף בפועל (ברירת מחדל) לבין תאריך האיסוף המתוכנן (תואם לדוח החיוב של ליונוויל); ההגדרה נשמרת פר-טננט וכל מנועי החיוב מכבדים אותה. (2) מדיניות הכפולה נאכפת אוטומטית: בכל שמירת מחירון של לקוח ללא סוכן, תוספת הכפולה נצמדת למחיר הבסיס האפקטיבי (רגל שנייה במחיר מלא) — כך ששינוי מחיר בסיס עתידי לא ישאיר תוספת כפולה ישנה; לקוחות של סוכנים (₪5) לא נדרסים. (3) שדה 'החזרה' — שריד שאינו מחויב באף מסלול — הוסר מדיאלוג המחירון ומרשימת סוגי הכללים.

• מתג 'בסיס ייחוס חיוב' בהעדפות — בפועל / מתוכנן (תואם ליונוויל)
• כפולה=מחיר בסיס נאכף אוטומטית בכל שמירת מחירון (לקוחות ללא סוכן)
• שדה 'החזרה' הוסר מהמחירון — לא חויב מעולם באף מסלול

כל המפות במערכת הציגו אריחי "Invalid key" אחרי שחשבון MapTiler הושהה זמנית על חריגה מהמכסה החודשית (100 אלף אריחים בתוכנית החינמית). השורש: הקוד הניח שמפתח מוגדר הוא מפתח עובד — getTileConfig בחר ב-MapTiler בכל פעם שהמשתנה קיים, וחמש תצוגות הווקטור (useVector) עשו את אותה הנחה. מפתח חסר תמיד נפל ל-OSM/Carto ועבד; מפתח שנדחה היה גרוע מזה — מפות שבורות על המסך. כעת שכבת בסיס משותפת אחת (BaseTileLayer) משרתת את כל 10 תצוגות ה-raster: כשאריח נכשל, בדיקה יחידה מול MapTiler קובעת אם המפתח באמת נדחה (401/403/429) — ורק אז MapTiler מנוטרל לכל המפות בסשן, כולל החלפת תצוגות הווקטור ל-raster, והכל עובר ל-OSM/Carto אוטומטית. תקלת רשת רגעית לא מנטרלת (אריח בודד שנכשל אינו פסק דין). רענון דף מנסה את MapTiler מחדש, כך שהתאוששות (איפוס מכסה / שדרוג תוכנית) לא דורשת deploy. ה-geocoding לא נפגע מהתקלה — היה לו כבר fallback ל-Nominatim. 10 בדיקות מכסות את התרחיש.

עורך תעריפים מהיר (QuickRateEditor) בדיאלוגי המחירון של הלקוחות והשליחים: כל התעריפים שיכולים לשאת כלל מוצגים בגריד אחד, ומילוי תא הופך אותו לכלל רגיל — עם תוקף, מצב (החלפה/תוספת), תווית והערה — במקום לפתוח דיאלוג נפרד לכל תעריף. בנוסף תוקן באג בעמודת "מחיר נוכחי": כשהיו כמה כללי REPLACE חופפים, החישוב בצד הלקוח שבר את השוויון לפי validFrom — בעוד שמנוע החיוב עצמו שובר אותו לפי createdAt (האחרון שנוצר מנצח). כלומר העמודה יכלה להציג מחיר שהלקוח בפועל לעולם לא חויב בו. שני הצדדים משתמשים עכשיו באותו קריטריון, וכלל חדש שטרם נשמר נחשב לחדש ביותר — כפי שהוא. חולצו גם עוזרי תמחור משותפים (parse-rate-input, money) עם 12 בדיקות.

• עורך תעריפים מהיר — כל התעריפים בגריד אחד במקום דיאלוג לכל תעריף
• "מחיר נוכחי" הציג מחיר שגוי כשהיו כללי REPLACE חופפים — תוקן ליישר עם מנוע החיוב
• עוזרי תמחור משותפים לדיאלוג הלקוחות והשליחים, עם 12 בדיקות

דף הלקוח נבנה בשלבים, וכל פיצ'ר הוסיף עוד כרטיסייה — עד שהוא הגיע ל-1,954 שורות בקובץ אחד, הדר עם 13 פעולות, וטור שמאלי של 10 כרטיסים שנמתח הרבה מתחת לקיפול. הכל נטען בכל כניסה, כולל ההגדרות שנוגעים בהן פעם בחיי הלקוח. הדף מפורק עכשיו למסגרת קבועה — זהות, פעולות, שורת טאבים ורייל מאפיינים — סביב חמישה טאבים שהם ראוטים אמיתיים: סקירה (KPI, מפה, משלוחים אחרונים, יומן פעילות), משלוחים (הטבלה המלאה, שהייתה דיאלוג), כספים (רווחיות, חיובים, גוביינא, סאמיט) מחירון (עורך התעריפים, שהיה דיאלוג של 1,400 שורות) והגדרות (כל שמונה ההגדרות הפר-לקוחיות). כרטסת וזיכויים שומרים על הכתובות שלהן ונקראים כ"כספים". כל טאב הוא קובץ נפרד עם שליפה משלו, אז הוא טוען רק את מה שהוא מרנדר; ומכיוון ש-Next לא מרנדר layout מחדש בניווט בין ילדיו, שאילתת הזהות של המסגרת רצה פעם אחת ושורדת כל החלפת טאב. ההדר ירד לשתי פקדים: ארבע מהפעולות (משלוחים, מחירון, כרטסת, זיכויים) היו ניווט שהתחזה לפעולה והפכו לטאבים, והשאר הן פעולות מחזור-חיים שיושבות מאחורי ⋮. "בטל השעיה" הופיע פעמיים כשלקוח מושעה (באנר + סרגל) ומופיע עכשיו פעם אחת. פרטי הקשר עברו לרייל במקום להיות משוכפלים בכותרת. טאב "כספים" מוגן בשרת ומוסתר משורת הטאבים למי שאין לו הרשאת FINANCE_VIEW — ההרשאות נפתרות פעם אחת בשרת מתפקיד הדייר, ולא מהצד הלקוח (שקורא את תפקיד הפלטפורמה; השניים יכולים לא להסכים, ואז נוצר טאב שמוביל ל-404). בנוסף: המגירה שנפתחת מכל שם לקוח באפליקציה הפכה לתצוגה מקדימה במקום עותק שני של הדף, ו-endpoint שמזין אותה ירד משליפה של כל ספריית הלקוחות ויתרת הקבוצה לשלוש שאילתות.

• חמישה טאבים אמיתיים (ראוטים) במקום דף אחד עמוס — כל טאב טוען רק את מה שהוא מרנדר
• כפתור "משלוח חדש" בראש הדף — הפעולה הראשית, נפתח עם הלקוח כבר מסומן
• המחירון הפך מדיאלוג של 1,400 שורות לטאב עם URL — והדיאלוג נשאר דק לשאר הקוראים
• ההדר ירד מ-13 פעולות לשתיים; ניווט שהתחזה לפעולות הפך לטאבים
• רייל מאפיינים קבוע — 6 שדות מקודמים ו"הצג הכל"; מצב הקיפול נשמר בין טאבים
• כל ההגדרות הפר-לקוחיות עברו לטאב ייעודי במקום להיטען בכל כניסה
• המגירה הפכה לתצוגה מקדימה מהירה עם קישור לכרטיס המלא
• "בטל השעיה" הופיע פעמיים כשלקוח מושעה — תוקן
• טאב כספים מוגן בשרת, לא רק מוסתר

הערך "אגורות" במילון המונחים תיאר פרט מימוש פנימי (המערכת שומרת כסף כמספרים שלמים באגורות) וקבע "חשוב לזכור בעבודה מול ה-API" — בדיוק ההפך ממה שתיעוד ה-API אומר: "סכומי כסף ב-API נשלחים בשקלים (decimal) — המערכת ממירה אגורות פנימית, כך שלא צריך לדאוג לכך מצדכם". הקוד מאשר: הקלט מוכפל ב-100 והפלט מחולק ב-100, כך שה-API כולו בשקלים ולקוח לעולם לא נתקל באגורות. הערך גם סתר את הגדרת המילון עצמו ("כל המונחים שתפגשו ב-Shipnest"). הוסר; אין קישורים נכנסים אליו, והסבר הכסף נשאר בתיעוד ה-API במקום הרלוונטי.

שגיאה חוזרת בפרודקשן: [ai-delivery-cron] Session processing failed — "Unexpected non-whitespace character after JSON at position 290". השורש: הניקוי של תשובת המודל חילץ את ה-{...} רק אם הטקסט *לא* התחיל ב-{. gemini מחזיר בדרך כלל JSON נקי, אבל לעיתים מוסיף שורת סיום אחרי הסוגר — ואז הטקסט כן מתחיל ב-{, השומר דילג על הניקוי, ו-JSON.parse נחנק על הזבל שאחרי. התוצאה: ה-session כולו נכשל ונשלחה התראת וואטסאפ למנהל, למרות שהסיווג עצמו היה תקין. הוחלף בחילוץ שרץ תמיד, עם סריקת סוגריים מאוזנת מודעת-מחרוזות שעוצרת בסוגר הסוגר של האובייקט הראשון — עמיד לזבל לפני ואחרי, ל-code fences, לשני אובייקטים (מקרה שחיתוך פשוט מהסוגר הראשון לאחרון היה נכשל בו), ולסוגריים בתוך טקסט עברי. פלט קטוע מחזיר null מסודר עם הודעה ברורה במקום להיחנק. נבדק ש-4 מסלולי ה-AI האחרים אינם חולים בבאג. 11 בדיקות רגרסיה.

שני באגים ותיקון נוסח, שדווחו אחרי סבב הליטוש. (1) תוכן העניינים בעמוד ("בעמוד הזה") לא התעדכן בניווט בין עמודים — הוא סרק את הכותרות ב-useEffect עם תלויות ריקות, והוא יושב ב-layout שלא מתרנדר מחדש בניווט צד-לקוח. התוצאה: מעבר מעמוד ללא כותרות השאיר אותו נעלם, ומעבר מעמוד עם כותרות השאיר על המסך את רשימת הכותרות של העמוד הקודם — עד רענון. הסריקה נקשרה כעת ל-pathname, וגם ה-observer של הסעיף הפעיל מתאפס בכל מעבר. (2) התגלה תוך כדי: תוכן העניינים השמיט בשקט את כל הסעיפים הראשיים. רכיב H2 שם את ה-id על ה-div העוטף ולא על ה-h2 עצמו, בעוד שהסריקה מחפשת h2[id] — כך שהוצגו רק תת-סעיפים (H3). בעמודים שכל כותרותיהם H2, כמו מילון המונחים, תוכן העניינים פשוט לא הופיע כלל. ה-id הועבר ל-h2 (אותו ערך, כך שכל קישורי העוגן הקיימים ממשיכים לעבוד) — בעמוד ה-API מוצגים כעת 26 סעיפים במקום 16. (3) קישור העוגן (#) שליד כל כותרת נכנס לטקסט בעת העתקה — הוא שקוף ומופיע רק בריחוף, אבל העתקת כותרת גררה אותו. נוסף select-none ו-aria-hidden. (4) נוסח: המונח "פיוס" הוסר מהתיעוד לטובת "הזדכות" בכל המופעים (מילון מונחים, עמוד הגוביינא, עמוד הבית והניווט).

הסבב השני בליטוש התיעוד, שסוגר את שני הפריטים שנשארו. (1) הדגשת תחביר: בלוקי הקוד היו טקסט אפור אחיד. נוספה הדגשה מלאה (Shiki, ערכות github-light/github-dark) — אבל בצד השרת בלבד: הדפדפן מקבל HTML מוכן ו-Shiki לא נכנס ל-bundle של הלקוח כלל, וזו בדיוק הסיבה שנמנענו מזה עד היום. הגבול נאכף ב-import server-only, כך שדליפה עתידית לצד לקוח תישבר בזמן build ולא בשקט. ההדגשה עוקבת אחרי מתג ה-theme דרך משתני CSS כפולים — בלי JS ובלי הבהוב. חשוב: 19 מתוך 37 הבלוקים מתויגים text — אלה דיאגרמות זרימה בעברית ולא קוד, והם נשארים רגילים במכוון. תוך כדי התגלה שדפי התיעוד אינם סטטיים (ה-layout הראשי קורא cookies()+auth(), מה שמכריח רינדור דינמי לכל הדפים), כך שההדגשה הייתה רצה מחדש בכל צפייה; נוסף cache שממפה קוד+שפה ל-HTML, ומכיוון שבלוקי הקוד הם ליטרלים סטטיים כל בלוק מחושב פעם אחת לכל תהליך שרת. כפתור ההעתקה ממשיך להעתיק את המקור הגולמי, לא את ה-HTML המודגש. (2) תוכן עניינים במובייל: פס ה"בעמוד הזה" היה זמין רק ב-lg ומעלה, כך שבמובייל ובטאבלט לא הייתה שום דרך לנווט בתוך עמוד ארוך. נוסף אקורדיון מתקפל בראש התוכן שנסגר אוטומטית בבחירת סעיף; לוגיקת סריקת הכותרות חולצה ל-hook משותף כדי שהפס והאקורדיון לא ייפרדו.

• הדגשת תחביר בבלוקי קוד (Shiki) — בצד השרת בלבד, אפס תוספת ל-bundle של הלקוח
• ההדגשה עוקבת אחרי ה-theme דרך משתני CSS כפולים — בלי JS ובלי הבהוב
• דיאגרמות הזרימה בעברית (lang=text) נשארות ללא הדגשה במכוון
• cache להדגשה — הדפים דינמיים, אז בלי זה כל צפייה הייתה מחשבת מחדש
• תוכן עניינים מתקפל במובייל/טאבלט (עד היום היה זמין רק בדסקטופ)

חקירת הפערים מול דוחות ליונוויל הוכיחה שדוח החיוב שלהם מסנן לפי תאריך האיסוף המתוכנן (עמודת 'איסוף'), בעוד שאצלנו הייחוס היה לפי האיסוף בפועל — ומכאן פערי גבול-חודש (משלוח ערב סוף-חודש שמבוצע אחרי חצות). נוספה עמודה pickupScheduledAt שלוכדת את התאריך המתוכנן מה-webhook (מתעדכנת בכל שינוי שיבוץ עד הביצוע, ואז קופאת — ליונוויל דורסים את השדה בזמן הביצוע), והגדרה חדשה פר-טננט (tenant.settings.billingAttributionBasis) שבוחרת את בסיס הייחוס: 'איסוף בפועל' (ברירת מחדל, המצב הקיים) או 'איסוף מתוכנן' (תואם ליונוויל). כל מנועי החיוב — דוח פירוט חיובים, טבלת חיוב לקוחות, עמלות סוכן ו-P&L — עוברים דרך helper משותף אחד כך שכולם תמיד באותו בסיס. ההיסטוריה אותחלה מתאריך הביצוע (125,744 משלוחים); התאריכים המתוכננים האמיתיים נצברים מרגע הפריסה.

• pickupScheduledAt — לכידת תאריך האיסוף המתוכנן לפני שליונוויל דורסים אותו בביצוע
• הגדרה פר-טננט: ייחוס לפי איסוף בפועל (ברירת מחדל) או מתוכנן (תואם ליונוויל)
• helper משותף (lib/billing-attribution) — דוח לקוח, טבלת חיוב, עמלות סוכן ו-P&L תמיד על אותו בסיס (חיווט מנוע העמלות הושלם ב-17.7)
• אותחלו 125,744 משלוחים היסטוריים; דיוק מלא נצבר מהפריסה והלאה

הכנה לעיצוב מחדש של דף הלקוח. getCustomerDetailData היה שולף אחד ענק שכל טעינה שילמה עליו במלואו: פרטי הלקוח, ספירות, 5 משלוחים אחרונים, כל לקוחות הדייר, שאילתת SQL גולמית של עד 500 יעדים עם LATERAL join, מעבר geocoding, ויתרת סאמיט. פוצל לשולפים ממוקדים — getCustomerIdentity (הרשומה עצמה, ממוסמנת ב-React.cache כך שכמה רכיבי שרת באותה בקשה חולקים שאילתה אחת), getCustomerOverview (ספירות, אחרונים, יתרה), getCustomerDestinations (מפה) ו-getTenantCustomers (ספריית הלקוחות, לדיאלוגים בלבד) — כך שכל טאב בעיצוב החדש ישלם רק על מה שהוא מרנדר. getCustomerDetailData נשאר כ-shim שמרכיב את כולם, אז אף קורא לא השתנה וההתנהגות זהה; הוא ייעלם כשהדף יעבור לטאבים. בנוסף: הופרדו בוני ה-WHERE לפונקציות טהורות וכוסו בבדיקה שמקבעת את ההשוואה הקריטית — שספירת המשלוחים שנמסרו לא יכולה לדלוף ולהפוך לכלל-דיירית (אומת במוטציה: הזרקת הרגרסיה מכשילה את הבדיקה). ההערה שהזהירה מפני התנגשות OR עודכנה — היא תיארה מימוש שקדם למיגרציית עמודת ה-status.

אותה דליפה שתוקנה בדף הלקוח, גם בדף השליח: כותרת הטאב (generateMetadata) שלפה את שם השליח לפי מזהה בלבד, ללא סינון לפי דייר — בעוד שגוף אותו עמוד סינן נכון והחזיר 404. משתמש מחובר של דייר אחד יכול היה לקבל שם פרטי ומשפחה של שליח מדייר אחר בכותרת. הסינון עכשיו לפי ה-tenantId שב-session.

שלושה תיקונים בדף הלקוח, כהכנה לעיצוב מחדש של הדף. (1) בידוד דיירים: כותרת הטאב (generateMetadata) שלפה את שם הלקוח ישירות לפי מזהה, ללא סינון לפי דייר — בעוד שגוף אותו עמוד סינן נכון והחזיר 404. כלומר משתמש מחובר של דייר אחד יכול היה לקבל שם לקוח של דייר אחר בכותרת. הסינון עכשיו לפי ה-tenantId שב-session, בדיוק כמו הקריאה הקנונית ב-getCustomerDetailData. (2) כרטיס "גוביינא" הציג כותרת עם גוף ריק לחלוטין כשטעינת הנתונים נכשלה — ללא הודעת שגיאה וללא דרך לנסות שוב; הודעת "אין נתוני גוביינא" הייתה מקוננת בתוך ענף ההצלחה ולכן לא נורתה אף פעם בכשל. נוסף מצב שגיאה עם כפתור "נסה שוב", בדפוס של כרטיס סאמיט הסמוך, וגם תשובת 200 עם success:false נחשבת כעת ככשל. (3) בכרטיס "תיאום איסוף יומי", שם קבוצת הוואטסאפ נשלח בשמירה אך לא נכלל בזיהוי השינויים — ולכן שינוי שם של קבוצה קיימת (אותו מזהה, שם חדש) לא הפעיל את כפתור השמירה, והשם המעודכן לא ניתן היה לשמירה כלל.

סבב ליטוש בתיעוד הציבורי (/docs) שמקרב אותו לסטנדרט של תיעוד מוצר מקצועי. (1) שורת הכותרת בדסקטופ הייתה לא מאוזנת — תיבת החיפוש נתקעה בצד עם רווח מת גדול עד הניווט; כעת החיפוש ממלא את המרכז הגמיש (ממורכז, רחב יותר) וה-theme toggle מעגן את הקצה. (2) נוסף ניווט הקודם/הבא בתחתית כל עמוד תיעוד — פיצ׳ר סטנדרטי שהיה חסר, שמאפשר לקרוא את התיעוד ברצף במקום לחזור לסיידבר בכל פעם. (3) נוספו פירורי לחם בראש כל עמוד (תיעוד ← סקציה ← עמוד). שניהם נגזרים מרצף עמודים חדש שנבנה אוטומטית מסדר הסיידבר (DOCS_PAGE_SEQUENCE), כך שהם לא יכולים להיפרד ממנו — עוגנים בתוך-עמוד מתקפלים לעמוד שלהם, ועמודי stub ולינקים משפטיים מסוננים. (4) תוקן פורמט התאריך: "Updated: 13 2026 ביולי" נרנדר הפוך בגלל dir=ltr על תאריך עברי — כעת "עודכן: 13 ביולי 2026". (5) סבב עקביות ריווח לפי רשת 8px: הריווח האנכי בין בלוקי תוכן היה מעורב (12/16/20 פיקסלים לפי סוג הבלוק) ואוחד ל-16px אחיד; ריווח פריטי ניווט, TOK ווידג׳ט מה-חדש יושרו לרשת. אומת ויזואלית בדסקטופ/טאבלט/מובייל, וכן נמדד ב-CDP ברוחב 390px שאין גלישה אופקית.

• ניווט הקודם/הבא בתחתית כל עמוד תיעוד — נגזר אוטומטית מסדר הסיידבר
• פירורי לחם בראש כל עמוד (תיעוד ← סקציה ← עמוד)
• שורת הכותרת אוזנה — חיפוש ממורכז ורחב יותר, בלי רווח מת
• תאריך העדכון נרנדר הפוך (dir=ltr על תאריך עברי) — תוקן
• ריווח אנכי אחיד בין בלוקי תוכן (16px) לפי רשת 8px

הגדרה חדשה בכרטיס הלקוח: "אישור גורף להשארה ליד הדלת". כשהיא פעילה, ושליח מדווח "אין מענה" על משלוח של אותו לקוח — הבוט משיב לו מיד להניח ליד הדלת ולצלם תיעוד, במקום לפתוח בירור מול השולח ולהמתין לתשובה שידועה מראש. חוסך לשליח המתנה ולנציגות סבב פניות. גם אישור של הנמען עצמו (שנקלט אוטומטית מהשיחה איתו — "תשאירו ליד הדלת") מקצר את התהליך באותה דרך. שני חריגים שהאישור לעולם אינו גובר עליהם, כי אי אפשר להשלים אותם מול דלת סגורה: משלוח גוביינא (יש לגבות תשלום) ומשלוח כפולה (יש איסוף חזרה) — במקרים אלה הבוט מיידע את השליח מיד מדוע אי אפשר להניח, ופונה ללקוח כרגיל. משימות איסוף אינן רלוונטיות ומדולגות.

• מתג בכרטיס הלקוח (כבוי כברירת מחדל) — כשהוא פעיל הבוט עונה לשליח מיד ולא מפריע ללקוח
• גם "תשאירו ליד הדלת" של הנמען עצמו מקצר את התהליך
• גוביינא וכפולה — חריגים קשיחים שהאישור אינו גובר עליהם; השליח מקבל הסבר מיידי למה, כדי שלא יניח בכל זאת
• שני אותות בלתי-תלויים לזיהוי גוביינא (additionalData + CodTracking) — אומת על 30 יום: 176 משלוחי גוביינא, אפס פערים
• חידוד לאחר ביקורת אדוורסרית: המענה האוטומטי יורה רק על דיווח של אי-מענה טהור (דיווח מורכב כמו "אמ ולא מוצא את הכתובת" חוזר לשאלה לשולח, אחרת בעיית הכתובת הייתה נעלמת); לא יורה כשהמשלוח נוחש ולא זוהה במפורש; לא חוזר על עצמו בדיווח נוסף; וכשלא ניתן לאמת את פרטי המשלוח — נסוג לשאלה לשולח במקום להניח שבטוח.

בשיבוץ נהג בלדר מדף המשלוח, הטוסט הציג 'השליח עודכן בהצלחה' גם כשהשידור לקבלן נכשל בפועל — כי ה-route החזיר הצלחה על עדכון הביקור בלי לשקף את תוצאת השידור. מעכשיו ה-route מחזיר את תוצאת השידור (broadcastFailed), וה-UI מבטל את השיבוץ האופטימי ומציג את סיבת הכשל האמיתית ('השידור לקבלן נכשל — המשלוח לא שובץ' או הודעת השגיאה מבלדר). חל גם על נהגי SNL. משלים את ביטול-השיבוץ בצד השרת שכבר קיים.

כשמשבצים נהג בלדר, השיבוץ נכתב מקומית לפני השידור בפועל. עד היום, אם השידור נכשל (למשל 'fetch failed' מול שרת הקבלן), המשלוח נשאר משובץ על נהג הבלדר גם אחרי רענון — למרות ששום דבר לא הגיע לקבלן, ובניגוד ל-SNL גם לא נדחף נהג לליונוויל. זה הטעה את הסדרנים. מעכשיו, כל כשל שידור לבלדר (כשל רשת, דחיית פרמטרים, ספק לא מוגדר, או חוסר כתובת מחסן) מבטל אוטומטית את שיבוץ נהג הבלדר על ביקור המסירה/האיסוף — כך שהמשלוח חוזר להיות 'לא משובץ' ואפשר לנסות שוב או לבחור שליח אחר. הביטול מרוכז בפונקציית השידור, כך שהוא חל בכל מסלולי השיבוץ (דף המשלוח, שיוך מרובה, סריקה, פעולת AI ובוט קבוצתי), ובטוח: הוא נוגע רק בביקור שעדיין משובץ על נהג בלדר ושלא שודר בהצלחה (יש הגנה מפני מחיקת שיבוץ של שידור שכן הצליח). בשיוך מרובה הטבלה מתרעננת אוטומטית בסיום השידור כדי לשקף את הביטול.

שידור הניסיון הראשון לזיפ נכשל עם 'fetch failed' — השרתים שלנו ב-Vercel לא הצליחו לפתוח חיבור לשרת של זיפ (http://zip.king2k.com:58090), למרות שהכתובת תקינה והגיבה בבדיקה מקומית. הסיבה: שרתי בלדר הם מכונות on-prem ישראליות מאחורי חומת אש שמתירה רק כתובות IP מוכרות, ו-Vercel יוצא ממאגר כתובות ענן מתחלף (בנוסף, זיפ פרסמו רשומת DNS פגומה מסוג IPv6 — fe80::1 — שמפילה את happy-eyeballs של Node). הפתרון: כל קריאות בלדר (שידור ובדיקת סטטוסים) עוברות מעכשיו דרך פרוקסי היציאה הקבוע שכבר משמש את אינטגרציית אישופ (EGRESS_PROXY_URL), שמספק כתובת IP אחת יציבה שחברת השליחים יכולה להתיר, וגם פותר את רשומת ה-DNS הפגומה כיוון שהוא מבצע resolve נכון ל-IPv4. אין השפעה כשהפרוקסי לא מוגדר (נפילה חזרה ל-fetch רגיל).

עד היום מודל 'הוספת משלוחים' בעמוד יעד אקספרס ידע לקבל רק רשימת מספרי משלוח מודבקת — מי שרצה לסמן את המשלוחים של לקוח מסוים היה צריך קודם לאסוף את המספרים שלו ממקום אחר. כעת יש במודל שני מצבים: 'לפי מספרי משלוח' (הקיים) ו'לפי לקוח' — מצב חדש שפותח רשימה של כל הלקוחות הפעילים עם חיפוש (שם, טלפון או כתובת), וליד כל לקוח כפתור 'משלוחים' שפותח את כל המשלוחים שלו. משם מסמנים את המשלוחים הרצויים ובוחרים תאריך יעד אקספרס מסרגל הפעולות — בדיוק כמו הזרימה המוכרת מהצ'ק ליסט של יעד שבת. עם סגירת חלון המשלוחים טבלת האקספרס מתרעננת אוטומטית.

• מצב חדש 'לפי לקוח' במודל הוספת המשלוחים, לצד המצב הקיים של הדבקת מספרים
• רשימת כל הלקוחות הפעילים עם חיפוש לפי שם, טלפון או כתובת
• כפתור 'משלוחים' לכל לקוח — פותח את כל משלוחיו וסימון יעד אקספרס מסרגל הפעולות
• אותה זרימה מוכרת מהצ'ק ליסט של יעד שבת; טבלת האקספרס מתרעננת עם הסגירה

שני תיקונים לקריאת ההקשר בקבוצות: (1) כשלקוח עונה על שאלת הבוט (למשל מוסר מספר טלפון), האישור "קיבלנו, העברנו לשליח שמטפל ✅" הוצמד לשאלה של הבוט עצמו במקום לתשובת הלקוח — נראה כאילו הבוט עונה לעצמו, ובקבוצה עמוסה האישור התנתק מההודעה שאליה התייחס. כעת הוא מצטט את התשובה. (2) בתרחיש השידור, כששליח מבקש "תשימו עליי" בתגובה להודעה שכבר מכילה את מספר המשלוח (לרוב הודעת השיבוץ שלנו עצמה) — הבוט ביקש ממנו את המספר שהוא בדיוק מצטט. כעת הוא מחלץ את המספר מההודעה המצוטטת, כמוצא אחרון בלבד (בלי לדרוס מספרים שכבר זוהו בהודעות עצמן).

לבקשת נחמה מהשיחות ('אתה יכול לפתוח משלוח חדש?... כדאי שתלמד לעשות זאת') — העוזר הפנימי יודע כעת לפתוח משלוח חדש, דרך אותה צנרת קליטה של טופס יצירת המשלוח (ברקוד ליונוויל אמיתי). הדרישה המרכזית — שהעוזר יוודא שיש לו פרטים מלאים מהנציג — נאכפת **בתוך הכלי עצמו ולא בהנחיות בלבד**, בהמשך ללקח שהנחיות לחוד ומעשים לחוד: כל עוד חסר ולו שדה חובה אחד (הלקוח השולח, שם הנמען, טלפון, עיר, רחוב, מספר בית) הכלי מסרב ליצור ומחזיר במפורש אילו שדות חסרים, כדי שהעוזר יבקש אותם מהנציג ולא ישלים אותם בעצמו. בנוסף: שם לקוח שמתאים לכמה לקוחות מחזיר רשימת מועמדים במקום ניחוש; טלפון לא תקין נדחה; ולפני היצירה בפועל הכלי מחזיר תצוגה מקדימה של כל הפרטים ומחייב אישור מפורש של הנציג — בלי האישור לא נוצר דבר. יצירה כפולה נחסמת (idempotency), הפעולה מוגנת בהרשאת יצירת משלוחים, סוכן יכול לפתוח רק ללקוחות שלו, והמשלוח נרשם על שם מי שפתח אותו. 19 טסטים מאמתים שאף מסלול לא יוצר משלוח בלי פרטים מלאים ואישור.

• העוזר פותח משלוח חדש מהצ'אט — ברקוד ליונוויל אמיתי, דרך צנרת הקליטה הקיימת
• הכלי מסרב ליצור כל עוד חסר שדה חובה, ומפרט לנציג בדיוק מה חסר — בלי השלמות מהדמיון
• תצוגה מקדימה + אישור מפורש של הנציג לפני היצירה בפועל
• שם לקוח מעורפל מחזיר מועמדים לבחירה; טלפון לא תקין נדחה; יצירה כפולה נחסמת
• מוגן בהרשאת יצירת משלוחים; סוכן מוגבל ללקוחותיו; המשלוח נרשם על שם הפותח

נבנה תרחיש בוט חדש (ניתן להפעלה ב-/settings/bot-scenarios, כבוי כברירת מחדל): כשלקוח מדווח בקבוצתו שהנמען טוען שלא קיבל משלוח שמסומן כנמסר — הבוט לעולם אינו עונה 'המשלוח כבר נמסר' (תשובה מבטלת ושגויה), אלא פותח בירור פעיל מול שלושת הצדדים: שולח לנמען בקשת אישור קבלה בתבנית Meta מאושרת, מבקש מהשליח לברר דחוף, ומאשר לשולח. תשובת השליח מועברת לשולח בניסוח מדוד ולא כציטוט — בתרחיש רגיש כזה העברת טקסט גולמית עלולה להעביר האשמות. הנמען הוא המכריע: אישר שקיבל — הפניה נסגרת אוטומטית מול השולח והשליח; הכחיש — הבירור מול השליח נמשך. תמונת הוכחת מסירה שהשליח שולח מועברת לשולח, ולנמען אם הצ'אט איתו פעיל. הזיהוי דטרמיניסטי ונבנה מ-12 דוגמאות חיות שהצוות תייג דרך כפתור 'שייך לתרחיש' (12/12 זיהוי, 0 שגיאות-שווא). להפעלה נדרשת תבנית Meta מאושרת המסומנת 'תבנית בדיקת מסירה' בהגדרות → הודעות → תבניות.

• תרחיש רשום עם toggle, כבוי כברירת מחדל (opt-in per-tenant)
• זיהוי דטרמיניסטי שנבנה מ-12 דוגמאות חיות מתויגות — 12/12 recall, 0 false-positives; תלונת-איחור בגוף ראשון/שני ('אמרתי שלא הגיע') וייחוס עם 'עדיין' מנותבים לצפי ולא לטענת אי-מסירה
• לעולם לא עונה 'כבר נמסר' — הנמען מוכרע ישירות מול עצמו בתבנית Meta מאושרת
• תשובת השליח מועברת לשולח בניסוח מדוד ומסונן (לא ציטוט) — ללא האשמות וללא מידע פנימי
• אישור הנמען סוגר את הפניה אוטומטית מול השולח והשליח; הכחשה ממשיכה את הבירור
• העברת הוכחת מסירה חוצת-ספקים: לשולח תמיד, ולנמען אם הוא בתוך חלון 24 השעות של Meta
• תמונה מועברת ללקוח רק כשהיא משויכת חד-משמעית למשלוח (ציטוט השאלה או ברקוד בכיתוב) — בקבוצת שליח יש תמונות של לקוחות אחרים, והעברה שגויה הייתה חושפת משלוח של לקוח אחר
• כשאין צ'אט לשליח (קבלן חיצוני) או תבנית מאושרת — שאר הרגליים עדיין רצות והצוות מקבל פתק מפורש

בשיחת אמת (15/07) נשאל העוזר 'מי הלקוח הכי רווחי שלנו?' וענה 'בוודאות' על סמך דגימה של 10 לקוחות שרירותיים (מתוך 423) — והכריז על לקוח שהרווח האמיתי ממנו נמוך פי 13 מהלקוח הרווחי באמת. נוסף כלי getCustomerProfitability: דירוג מצרפי אחד (GROUP BY) של כל הלקוחות לפי רווח מוערך / הכנסה / כמות משלוחים, עם סינון תאריכים ו-top-N, באותה סמנטיקה פיננסית של הסיכום הקיים (הכנסה על כל המשלוחים לפי קליטה; רווח על שהושלמו ותומחרו בלבד). ההנחיות אוסרות במפורש דירוג ע"י דגימת לקוחות בודדים, ונוספה תזכורת להשוות תאריך אירוע לתאריך הנוכחי לפני תיוג 'היום'/'אתמול' (מסירה מהבוקר תויגה 'אתמול'). מוגן בהרשאת פיננסים. אומת מול נתוני הפרודקשן.

• כלי חדש getCustomerProfitability — 'מי הלקוח הכי רווחי' נענה מדירוג כל הלקוחות, לא ממדגם
• מיון לפי רווח / הכנסה / כמות משלוחים + סינון תאריכים + top-N
• איסור מפורש על דירוג באמצעות דגימת לקוחות בודדים
• תיוג 'היום'/'אתמול' מושווה לתאריך הנוכחי לפני שנכתב

בנוסף לכפתור 'דיווח על כשל בוט', נוסף בתיבת ההודעות כפתור 'שייך לתרחיש' על כל הודעה. הצוות מתייג הודעה כדוגמה של תרחיש — קיים או 'מוצע' (כזה שעדיין לא נבנה) — וכך נצבר דאטהסט מתויג של מקרים אמיתיים. זה נחוץ לתרחישים 'רכים' שאי-אפשר לזהות במילות-מפתח (למשל 'טוען שלא הגיע למרות שמסומן הושלם'): צוברים דוגמאות חיות ומאפיינים על בסיסן. התיוגים נאספים בלבד — הם אינם משנים את התנהגות הבוט אוטומטית. הסקירה, ניהול קטלוג התרחישים המוצעים, וייצוא הדאטהסט מתבצעים בקונסולת הפלטפורמה (/admin/דוגמאות תרחישים), פלטפורמה-רחב כמו דיווחי-הכשל. תפריט הלחיצה-הארוכה על הודעה שופר למובייל: לחיצה ארוכה כבר לא מסמנת את טקסט ההודעה (חסימת בחירה/callout במובייל בלבד), והתפריט לא נחתך כשההודעה נמוכה בצ'אט (collisionPadding — נדחף למעלה במקום להיחתך).

• כפתור 'שייך לתרחיש' פר-הודעה בתיבה, עם קטלוג מחופש (תרחישים קיימים + מוצעים) והערה חופשית
• קטלוג תרחישים מוצעים מנוהל בקונסולה (שם + מזהה + תיאור), בלי לגעת בקוד
• מסך סקירה פלטפורמה-רחב עם ספירת דוגמאות לכל תרחיש, אישור/דחייה, וייצוא JSON של הדאטהסט
• התיוגים נצברים בלבד — אין שינוי התנהגות אוטומטי של הבוט

בקבוצת טאצ' הבוט שאל את הלקוח על כתובת נכונה, והלקוח ענה בציטוט "@מזכירה בדיקה מחר בבקשה" (האצלה, לא כתובת) — והבוט העביר את זה לקבלן כ"כתובת מתוקנת" והשיב "קיבלנו, מטפלים". השורש: תשובה בציטוט (swipe-reply) זיהתה נכון את הגישור אך עקפה את שער הרלוונטיות, ולכן כל טקסט הועבר מילולית. מעכשיו תשובה מצוטטת לגישור שממתין ללקוח (אין-מענה/טלפון/כתובת) עוברת גם את שער הרלוונטיות; אישור-מספר-טלפון דטרמיניסטי ב-wrong_phone עדיין מדלג, וכשאין תקציב LLM נשמרת ההתנהגות החינמית הישנה. תוקן גם ה-ack המטעה (נדחה לפני העברת ההודעה).

בדף הסריקה, במצב קליטה במחסן בדסקטופ (סורק USB), כל סריקה פותחת חלון תצוגה גדול עם ברקוד המשלוח, שם הלקוח והכתובת, אזור ההפצה באותיות ענק ותג סיווג היעד (רגיל/חריג לפי סיווג הישובים כולל התאמות פר-חברה). החלון לא עוצר את רצף הסריקות — הקלט נשאר בסורק, וכל סריקה חדשה מחליפה את התוכן. סריקה שנכשלה מציגה את השגיאה בגדול באותו חלון. סגירה ב-Esc, בכפתור או בקליק מחוץ לחלון. במובייל (סריקת מצלמה) ההתנהגות ללא שינוי. בנוסף, גזירת אזור ההפצה בכל דף הסריקה (קליטה, שיבוץ ופעולות מרובות) יושרה למנגנון של התראות טעויות המיון: זיהוי ישוב מודע ל-aliases (resolveSettlement), קריאת האזור מהשדה החי שנערך ב-UI (ולא מטבלת מיפוי שלא מתעדכנת), region_str מליונוויל כ-fallback לישוב לא ממופה, ובדיקת טעות מיון בסריקת שיבוץ עם אותו כלל החלטה בדיוק (evaluateDriverZoneAllowance) — כך שסריקה, אזהרת שיבוץ מקדימה והתראות חיות מסכימים תמיד. כמו כן, סריקה במצב 'חיפוש משלוח' מזהה עכשיו גם מזהה חיצוני ומזהה משוגר (מספרי משימה של קבלן/שותף) — כמו בחיפוש הגלובלי: דף המשלוח פותר קוד שלא נמצא כברקוד גם מול הסיומת של חבילה וגם מול המזהים החיצוניים.

בקבוצת יצחק הפצה השליח כתב "26157230 לא זמין", אך 26157230 אינו משלוח שלו — ולכן הבוט זיהה את המשלוח הפתוח הבודד שלו (26133284) בניחוש. התשובה הייתה נכונה, אבל הודעת ההעברה-חזרה לשליח ("לגבי משלוח 26133284, הלקוחה מאשרת להשאיר מחוץ לבית") ציטטה את הודעת ה-"26157230" — שנוקבת במספר אחר ומבלבלת. מעכשיו הציטוט של דיווח-המקור מושמט כשהמשלוח זוהה בניחוש (הדיווח נקב במספר שונה מזה שנפתר); דיווח ללא מספר או עם מספר תואם עדיין מצטט כרגיל. חל על אין-מענה וטלפון-שגוי (צפי דורש ברקוד מפורש, לא מושפע).

בעקבות השוואה ברמת הברקוד מול דוחות חיוב אמיתיים של ליונוויל, שיטת החישוב של דוח עמלות הסוכן ושל רווחיות הלקוח (P&L) יושרה לשיטה של ליונוויל בשלושה מישורים: (1) הספירה היא חבילות ולא משימות — משלוח דו-חבילתי נספר פעמיים בעמודת 'כמות חבילות', והעמלה הקבועה/מרווח מוכפלת במספר החבילות; (2) משלוחים שבוטלו או נכשלו (ולא נמסרו) אינם מחויבים ואינם מזכים בעמלה — כמו בליונוויל; (3) הייחוס לחודש הוא לפי תאריך האיסוף בפועל שליונוויל מדווח (delivered_at של ביקור האיסוף) במקום זמן עיבוד ה-webhook — משלוח שנאסף ב-30 בחודש בערב וה-webhook שלו התעבד אחרי חצות מיוחס לחודש הנכון. בוצע backfill היסטורי: 393 חותמות יושרו לתאריך האיסוף, ו-66,764 משלוחים ותיקים שנעדרו לגמרי מהדוחות (חסרה להם חותמת commissionableAt מלפני שהעמודה נוספה) קיבלו חותמת מתאריך המסירה. הכרת ההכנסה ב-P&L עברה מ'תאריך קליטה' (delayClockStartedAt) לאותו בסיס איסוף — כך הכנסה, עמלת סוכן וחיוב ליונוויל נופלים כולם באותו חודש.

• 'כמות חבילות' בדוח הסוכן = Σ חבילות, זהה ל'מספר חבילות' בדוח ליונוויל
• עמלה לחבילה כפשוטה: משלוח דו-חבילתי מזכה בעמלה כפולה
• משלוחים שבוטלו/נכשלו ולא נמסרו — לא מחויבים ולא מזכים בעמלה
• ייחוס לחודש לפי תאריך האיסוף של ליונוויל — נפתרו פערי חצות בגבול חודש
• backfill: 393 תיקוני ייחוס + 66,764 משלוחים היסטוריים שחזרו לדוחות
• P&L רווחיות לקוח מוכר הכנסה לפי אותו בסיס — עקביות מלאה מול ליונוויל
• תוקן: התוספות האוטומטיות (יעד חריג / גוביינא) מתעלמות מכללי המחירון — תיקון תעריף שהוגדר ככלל מתאריך (למשל יעד חריג ₪35→₪3) לא הגיע לתוספת המוחתמת והמשלוח חויב בתעריף הישן; מעכשיו התעריף נפתר דרך הכללים לפי תאריך האיסוף, ו-30 משלוחים ב-5 לקוחות תוקנו רטרואקטיבית
• חדש: כרטיס 'פירוט חיובים' בדף הלקוח — שורה לכל משלוח מחויב בחודש (תאריך איסוף, נמען, יעד, חבילות, מחיר עם פירוק תוספות) וסיכום עם מע"מ; הורדה כ-Excel ושליחה ללקוח במייל ממותג עם הקובץ מצורף — אותה שיטת ספירה של דוח ליונוויל, מאחורי הרשאת פיננסים
• חדש: טאב 'חיוב לקוחות' בפיננסים — טבלה חודשית עם שורה לכל לקוח (משלוחים, חבילות, לפני מע"מ, מע"מ, סה"כ), פירוט נפתח לכל לקוח, הורדת אקסל ושליחת המייל ישירות מהשורה, שורת סיכום, חיפוש, והתראה על לקוחות עם משלוחים ללא פרופיל מחירון שהחיוב שלהם אינו מוכר
• זיכויים בדוחות החיוב: תעודות זיכוי מאושרות (לפי חודש החיוב שלהן) מופיעות כשורות שליליות בדוח הפר-לקוח (כרטיס, אקסל ומייל) ובעמודת 'זיכויים' בטבלת חיוב הלקוחות — הסיכום הוא חיובים − זיכויים לפני מע"מ; זיכוי גדול מהחיוב מציג סכום שלילי, ולקוח עם זיכוי בלבד מקבל שורה גם ללא משלוחים

בכל טבלאות המשלוחים במערכת נוספה עמודת "סוג יעד" שמציגה לכל משלוח האם עיר היעד היא יעד רגיל (עד 3 ימי הפצה, תג ירוק) או יעד חריג (עד 7 ימי הפצה, תג כתום) — לפי אותו סיווג ישובים שמשמש את בודק היעדים ואת תמחור תוספת יעד חריג, כולל התאמות פר-חברה. לצידה נוסף ציר סינון "סוג יעד" (יעד רגיל / יעד חריג) שרץ בצד השרת וחל על כל התוצאות והייצוא לאקסל. הפריסה: פורטל הלקוחות (עמודה + בורר בסרגל), טבלת המשלוחים הראשית (עמודה ליד עיר היעד + קטגוריה בפילטרים, כולל התאמת ספירות ה-facets והכנסת שורות חיות מ-SSE), יעד שבת ויעד אקספרס (אותה טבלה משותפת + סינון מקומי + עמודה בייצוא לאקסל), ודוח עמלות הסוכן (תג ליד כל משלוח בכרטיס העמלות — גם בתצוגת האדמין וגם בדשבורד הסוכן — ועמודה בגיליון המשלוחים של ייצוא האקסל). עיר שלא זוהתה ברשימת הישובים מוצגת עם "—" ואינה נכללת באף אחד מהסינונים.

• תג ירוק "רגיל" (עד 3 ימי הפצה) / כתום "חריג" (עד 7) בכל טבלאות המשלוחים
• סינון שרת לפי סוג יעד — חל על עימוד, ספירות ותוצאות הייצוא
• פרוס בפורטל הלקוחות, בטבלה הראשית, ביעד שבת, ביעד אקספרס ובדוח עמלות הסוכן
• עיר לא מזוהה מוצגת "—" ולא נכללת באף סינון — בלי ניחושים

ייבוא ההזמנות מחנויות אישופ שוכתב מהיסוד כך שהוא עובד כמו האינטגרציה של WooCommerce. שתי בעיות תוקנו: (1) הפרטים אבדו — מבנה התשובה האמיתי של getorder עוטף כל סקציה במערך ({Order:[..], ShippingAddress:[..], BillingAddress:[..], Products:[..]}), והקוד קרא רק את כותרת ההזמנה. כעת הקליינט מנרמל את המבנה נכון, וה-mapper מחלץ שם נמען, טלפון (עם נפילה חכמה לכתובת החיוב כשכתובת המשלוח ריקה), כתובת מלאה, מייל ופריטים — כולל ניקוי HTML משמות מוצרים וסינון שורות הנחה/משלוח. (2) לא היה שידור לליונוויל — ההזמנות נשמרו כשורות מקומיות מתות עם ברקוד מזויף. כעת הייבוא עובר דרך אותו צינור משותף של יצירת משלוח (createShipmentForTenant): שידור אמיתי לליונוויל, ברקוד אמיתי, פריטים עם מחירים, ודדופ אטומי כמו ב-WooCommerce. בנוסף נוסף בורר סטטוסים ידידותי: במקום להקליד קודים מספריים, המשתמש טוען את רשימת הסטטוסים האמיתית של החנות (עם השמות בעברית ומספר ההזמנות בכל סטטוס) ומסמן בצ'קבוקסים אילו ייובאו — רק הזמנות בסטטוסים שנבחרו יישלחו לליונוויל. הסינון נעשה בצד שיפנסט (קריאת API אחת ללא תלות במספר הסטטוסים) כדי לחסוך במכסת ה-API של החנות. גם סטטוס 'נמסר' לעדכון חזרה נבחר כעת מרשימה במקום קוד.

• getorder מנורמל נכון — נמען, טלפון, כתובת, מייל ופריטים נחלצים סוף-סוף
• טלפון נופל אוטומטית לכתובת החיוב כשכתובת המשלוח ריקה
• ניקוי HTML משמות מוצרים + סינון שורות הנחה (מחיר שלילי)
• שידור אמיתי לליונוויל דרך createShipmentForTenant — ברקוד אמיתי + פריטים, כמו WooCommerce
• דדופ אטומי (claim row) מונע יצירת שתי משימות ליונוויל לאותה הזמנה
• בורר סטטוסים בצ'קבוקסים עם השמות בעברית ומספרי ההזמנות — במקום קודים
• סינון סטטוסים בצד שיפנסט — קריאת API אחת בלבד, חוסך במכסת החנות

הדיווח המפורט שנוסף אתמול חשף את הצורה האמיתית של תשובות אישופ: רשימת ההזמנות לא מגיעה כמערך אלא עטופה באובייקט מעטפת ({"Order":[...]}). הקליינט פותח כעת את המעטפת בכל נקודות הקצה (רשימת הזמנות, הזמנה בודדת, רשימת סטטוסים) — גם בצורות המקבילות האפשריות — וייבוא ההזמנות מחנויות אישופ יוצא סוף-סוף לדרך. בהמשך התגלה שהייבוא עדיין חלקי (חסרים פרטי נמען/כתובת/פריטים ואין שידור לליונוויל) — נוסף route אבחון פנימי (platform-only, קריאה בלבד) לשליפת המבנה הגולמי האמיתי של getorder כדי לתקן את המיפוי נכון, וחיבור אישופ של חנות 'שליח' הוקפא זמנית עד שהייבוא יותאם למודל של WooCommerce.

עד היום חיבור חנות (WooCommerce, קונימבו, אישופ וכו') נקשר אוטומטית וללא בחירה ללקוח-הבית של המשתמש שיצר אותו — בקבוצת לקוחות מקושרים (לקוח-אב עם לקוחות-בנים) לא הייתה שום דרך לקבוע שההזמנות ייכנסו ללקוח אחר בקבוצה, וכל ההזמנות זרמו ללקוח-האב. כעת, כשלמשתמש יש גישה ליותר מלקוח אחד: דיאלוג חיבור חנות חדשה כולל בורר "ההזמנות ישויכו ללקוח" (ברירת מחדל: הלקוח הנוכחי), עריכת חיבור קיים מאפשרת להעביר אותו ללקוח אחר בקבוצה (משפיע על הזמנות חדשות בלבד — משלוחים קיימים נשארים אצל הלקוח הקודם), כרטיס כל חנות מציג תג עם שם הלקוח שאליו היא משויכת, ורשימת החנויות מציגה את כל חיבורי הקבוצה שהמשתמש מורשה להם — לא רק את של לקוח-הבית שלו. הבחירה נאכפת גם בשרת: שיוך מותר רק ללקוח בתוך הקבוצה המקושרת של המשתמש ובכפוף להגבלות הצפייה שלו (scopedCustomerIds), וכל פעולות החנות (עריכה, מחיקה, בדיקת חיבור, רישום webhook, גילוי שיטות משלוח) כובדו את אותה הרשאה קבוצתית.

• בורר לקוח בחיבור חנות חדשה — ההזמנות נכנסות ללקוח שנבחר, לא אוטומטית ללקוח-האב
• עריכת חיבור מאפשרת להעביר חנות ללקוח אחר בקבוצה (הזמנות חדשות בלבד)
• תג שם הלקוח על כל כרטיס חנות כשיש יותר מלקוח אחד בקבוצה
• רשימת החנויות כוללת את כל חיבורי הקבוצה שהמשתמש מורשה להם
• אכיפה בשרת: שיוך רק בתוך הקבוצה המקושרת ובכפוף ל-scopedCustomerIds

אחרי שאישופ הסירו את חסימת ה-Cloudflare (הלבנת ה-IP הושלמה מולם ב-14.7), הסנכרון האוטומטי הגיע לראשונה לתשובות אמיתיות מה-API שלהם — ונפל על צורת המענה: השרת שלהם (ASP קלאסי) עשוי להחזיר JSON עטוף בתוך מחרוזת (קידוד כפול), והקוד ציפה למערך ישירות ('t.map is not a function'). מעכשיו הקליינט פותח עטיפת קידוד-כפול אוטומטית, ורשימות (getorderlist / getstatuslist) שמגיעות בצורה לא-צפויה מדווחות שגיאה עם קטע מהתוכן האמיתי שחזר — כך שהלוג הבא יגיד בדיוק מה השרת שלח במקום שגיאת JavaScript אטומה.

תרחיש "כתובת שגויה" מעדכן כתובת ומסנכרן לליונוויל — ולכן ניחוש שגוי משחית משלוח אמיתי. באירוע (אלעזר צדוק) השליח דיווח על כתובת שגויה בלי לנקוב במספר משלוח, המדבקה נשלחה 18 דקות קודם (מעבר לחלון השחזור), והבוט ניחש את המשלוח הפתוח הבודד של השליח (26051512) במקום זה שעליו דיבר (26164296). מעכשיו התרחיש לעולם לא מנחש: כשהדיווח אינו נוקב במשלוח מזוהה, הבוט שואל את השליח "לגבי איזה משלוח מדובר? שלחו מספר", וכשהשליח עונה בברקוד — הבוט מזהה אותו (מוודא שהוא של השליח) וממשיך לשאול את הלקוח על הכתובת. אם נוקב בברקוד סגור/לא-שלו — נשאר שקט כמו קודם. שאר התרחישים (אין מענה/טלפון/צפי) ללא שינוי. עבר ביקורת אדוורסרית (הוסר מסלול דטרמיניסטי שחשף את broadcast לשידור-שווא; חוזק שער הרלוונטיות להבחין בין מספר-משלוח-כתשובה לבין דיווח סטטוס).

עמוד 'תיאום איסופים' נפתח כעת גם לסוכני לקוחות, מסונן אוטומטית ללקוחות המשויכים אליהם בלבד (כמו בטבלת הלקוחות). לסוכן זו תצוגה בלבד — כפתורי שליחת שאלת הבוקר (לכולם ולשורה בודדת) והגדרות התזמון מוסתרים ממנו. בנוסף, כרטיסי הסיכום בראש הדף הפכו לפילטר סטטוס: לחיצה על כרטיס מסננת את הטבלה לאותו סטטוס (לחיצה חוזרת או 'הכל' מבטלת). הפילטר מאותחל אוטומטית ל'יש איסוף' — הסטטוס שהכי רלוונטי בבוקר. בנוסף עוצב הדף מחדש למובייל כך שהטבלה תופסת את מרבית גובה המסך: הוסרו הכותרת והתיאור, כרטיסי הסיכום הפכו לצ'יפים דקים בשורה אחת (גלילה אופקית), הכפתורים צומצמו לשורה אחת (הגדרות כאייקון בלבד), ובורר התאריך הפך לסגמנט מחובר 'אתמול | היום | מחר' (מאותחל להיום) עם אייקון לוח-שנה מחובר לבחירת תאריך אחר, בסגנון בוררי התאריכים במערכת. תוקן גם שהדף הופיע לסוכן בסיידבר אך לא נפתח — ה-middleware חסם את הנתיב (לא היה ברשימת ההרשאות של תפקיד הסוכן); כעת הנתיב מורשה, בעוד פעולות השליחה נשארות חסומות ברמת ה-API.

קבלן ענה בבוקר "צפוי היום" בציטוט לשאלת צפי מהערב הקודם — והלקוח לא עודכן, כי גישור הצפי פג אחרי 6 שעות. שני תיקונים: פקיעת גישור צפי הוארכה ל-24 שעות (כמו כל אחיו), וציטוט מפורש של שאלה מחייה גם גישור שכבר פג (עד 3 ימים; רק EXPIRED — לעולם לא כפל-העברה). בנוסף תוקנה שחיתות דאטה: מנגנון ההשלמה של הודעות יוצאות חתם מזהי-ספק על הערות פנימיות (שלעולם לא נשלחות) — ולכן תשובת הקבלן הוצגה ב-inbox כמצטטת הערה פנימית על משלוח אחר. הסינון תוקן (הערות פנימיות מוחרגות + חלון-טריות של 15 דקות), ו-15 הערות שכבר נפגעו נוקו.

בהמשך לתיקון הכותרת: בחלק גדול מהצ'אטים ההודעות היוצאות (הירוקות) גלשו מהמסך או נחתכו במובייל. השורש — רכיב הגלילה של Radix עוטף את התוכן ב-div עם display:table שנמתח לפי רוחב התוכן: תמונה אחת (למשל צילום מדבקה) ברוחבה הטבעי הרחיבה את כל קנבס הצ'אט מעבר למסך, וההודעות היוצאות — המיושרות לקצה הנגדי — נדחפו החוצה, בעוד הודעות הלקוח נראו תקינות. הוחל אותו תיקון שכבר קיים ברשימת הצ'אטים (block במקום table) גם על אזור ההודעות.

בעקבות מקרה אמיתי: התכונה הופעלה ל-108 לקוחות בלי לבחור קבוצת תשובות — השאלות נשלחו והלקוחות ענו, אבל התשובות הגיעו רק לטבלת תיאום האיסופים ואף אחת מהן לא הופיעה בוואטסאפ, מה שנראה כאילו 'לא נשלחו הודעות'. דיאלוג ההפעלה המרובה מציג כעת אזהרה כתומה בולטת כשלא נבחרה קבוצה ולחלק מהלקוחות שנבחרו אין קבוצת תשובות קיימת, עם הסבר מפורש שהתשובות יגיעו רק לטבלה. בנוסף תוקן דף תיאום האיסופים: הטבלה לא הייתה נגללת — התוכן נחתך בגובה המסך בלי אפשרות לראות את שאר הלקוחות; כעת הכותרת וכרטיסי הסיכום קבועים והטבלה גוללת בפנים, עם בר עמודים תחתון סטנדרטי כמו בשאר הטבלאות. בנוסף, בתיבת ההודעות של לקוחות הקצה, שאלת הבוקר שיצאה בתבנית Meta הופיעה עד היום כטקסט טכני ('[תבנית Meta: …]') במקום תוכן השאלה — מעכשיו מוצג טקסט השאלה האמיתי (עם שם הלקוח), וכפתורי ה'כן'/'לא' מוצגים כצ'יפים ויזואליים מתחת להודעה (לתצוגה בלבד, ללא אפשרות לחיצה).

בקבוצת בזק, "26134634 לשדר" לא שודר ונדרשה התערבות אנושית: חלון ה-burst של השידור איחד את ההודעה עם "בבקשה להחזיר אלינו" ששלח משתתף אחר רגע קודם, ושומר-הדחייה (שנוסף אתמול כדי שהודעות החזרה לא יפעילו שידור) פסל את הטקסט המאוחד כולו. מעכשיו שער השידור שופט כל הודעה בנפרד: דחייה של שולח אחד לא מבטלת בקשה לגיטימית של אחר, הודעה שמכילה בעצמה מילת-שידור לצד ביטול ("אמרתם לבטל שידור") עדיין מושתקת, ומספר מתוך הודעת-החזרה לעולם לא משודר (איסוף המטרות היה פר-הודעה עוד קודם). מכוסה בטסטים עם טקסטי האירוע.

סבב תיקונים בעקבות ניתוח 4 שיחות אמת (07-13/07) שחשפו כשל אמינות חמור: העוזר 'אישר' פעולות שלא ביצע ("✅ ההודעה נשלחה" בלי שום קריאת כלי), הציג טבלת פרטים מומצאת למשלוח, ומיחזר נתוני משלוח קודם על פני חמישה תורות בטענה שקרא מהמערכת. שבעה תיקונים: (1) שומר אמינות דטרמיניסטי בלולאת הסוכן — תשובה שמדווחת ביצוע (✅/נשלח/עודכן) בלי שכלי פעולה רץ באותו תור, או שמציגה נתוני משלוח בלי שום קריאת כלי, נדחית אוטומטית ומוחזרת למודל לתיקון (עם ניקוי הטקסט שכבר הוזרם למסך); כולל סוללת טסטים על ההודעות האמיתיות מהשיחה. (2) סינון חדש לפי נהג איסוף (pickupDriverName) — עד כה driverName תפס רק נהגי מסירה, ולכן על נהג שרק אוסף העוזר ענה בטעות "לא עבד אתמול" ודיווח 10 איסופים כשבפועל היו 88. (3) סינון חדש לפי שם לקוח עסקי (customerName) — חיפוש לקוח דרך query (שמחפש נמענים) החזיר אפסים שגויים. (4) איתור משלוח לפי מזהה-ספק מגלה זאת כעת במפורש (identifierNote) — מספר ספק שהחזיר משלוח עם ברקוד אחר גרם לבלבול קשה בשיחה. (5) רזולוציית מזהים ב-getShipmentDetails/getShipmentCost עברה לעדיפות-ברקוד (מיגור החזרת משלוח שרירותי בהתנגשות ברקוד/מזהה-ספק). (6) הוספת הערת AI למשלוח לפי ברקוד תוקנה (נכשלה בעבר על ברקוד תקין). (7) getCostSummary מחזיר גם עלות ממוצעת לחבילה, ומצהיר במפורש כשהסיכום מכסה את כל התקופה — נגד המצאת "טווח ברירת מחדל". הנחיות עודכנו בהתאם (נהג איסוף/לקוח עסקי, איסור המצאת מדיניות חברה).

• שומר אמינות אוטומטי: דיווח ביצוע ללא פעולה אמיתית או הצגת נתונים ללא קריאת כלי — נדחים ומתוקנים אוטומטית
• סינון נהג איסוף (pickupDriverName) — "מה אסף נהג X אתמול" עובד סוף-סוף (88 איסופים שדווחו כ-10)
• סינון לקוח עסקי ישיר (customerName) — בלי לעבור דרך חיפוש נמענים
• מספר ספק שמאתר משלוח מזוהה ומוצהר (identifierNote) — סוף לבלבול בין מזהה ספק לברקוד
• עלות ממוצעת לחבילה ב-getCostSummary + הצהרה מפורשת של הטווח המכוסה

שיפור פריסת התיעוד (/docs) במסכי דסקטופ. עד כה כל מאמר היה כלוא ב-max-w-68ch (~550px) — כך שגם בתוך עמודת התוכן נותר שטח מבוזבז רב, והטבלאות נחנקו ל-550px ואז נחתכו (במיוחד טבלאות פרמטרים עם שם ארוך כמו destinationFloor / destinationApartment / ...). שלושה תיקונים: (1) ה-container הראשי של התיעוד הורחב מ-1400px ל-1600px, מה שמצמצם את השוליים המתים בקצוות ומרחיב את עמודת התוכן. (2) המאמר כבר לא כלוא ב-68ch — הוא ממלא את עמודת התוכן, כך שטבלאות, בלוקי קוד וכרטיסי endpoint מקבלים את מלוא הרוחב; פסקאות הטקסט עצמן נשארות ברוחב קריא (74ch) דרך רכיב ה-Prose. (3) בטבלאות: בוטל ה-white-space:nowrap על שם הפרמטר (שם ארוך עובר שורה במקום להרחיב את העמודה ולחתוך את התיאור), ונוספה גלילה אופקית פנימית בתוך מסגרת הטבלה כרשת ביטחון לטבלאות רחבות במיוחד.

המשך לתיקון של היום (עלות מסירה ₪0 בסאב-שליחים אחרי תיוג היסטורי). נסקרו כל המסלולים שכותבים את שליח-החיוב של ביקור: מסלולי השיבוץ (שיבוץ מרוכז, סריקה, מובייל, AI, broadcast) נוגעים רק בביקורים פתוחים ולכן תקינים, אבל שחזור שליח המסירה מ-POD של ליונוויל — שרץ דווקא על ביקורים שכבר הושלמו — מילא את השליח בלי לחשב את עלות המשלוח מחדש, והמשלוח נשאר בלי עלות לתמיד. תוקן. בנוסף נוספה רשת ביטחון: cron לילי (02:45) שסורק 45 יום אחורה ומאתר כל סנאפשוט עלות שלא תואם את שליח-החיוב של הביקור (או חסר לגמרי) ומחשב אותו מחדש — כך שגם אם מסלול עתידי ישכח לחשב מחדש, המערכת תרפא את עצמה תוך יממה במקום לשקר בדוחות הרווחיות.

עד היום, שינוי מחיר ללקוח או לשליח שכבר יש לו מחירון חייב לעבור דרך מודל נפרד לכל שדה: בחירת סוג פעולה, הקלדת סכום, הקלדת שם כלל (חובה), ובחירת שני תאריכים — ואז שוב מהתחלה לשדה הבא. שינוי של מסירה + איסוף + גוביינא עלה שלושה מודלים, שלושה שמות ושישה בוררי תאריך. נוסף עורך מהיר בראש סקציית "מחיר נוכחי" בשני הדיאלוגים: טבלה אחת עם כל התעריפים, תאריך תחולה אחד לכל השינויים, ושם שינוי שנוצר אוטומטית מהתאריך (וניתן לעריכה). ממלאים רק את התעריפים שהשתנו ולוחצים "החל שינויים". תא בודד מכסה את כל סוגי הפעולה: 25 = תעריף חדש, ‎+2 = תוספת, ‎-1.5 = הפחתה, ‎+5% = העלאה באחוזים — עם תצוגה מקדימה חיה של המחיר המתקבל. המודל הישן, הכללים לפי לקוח/אזור, מטריצת האזורים, התבניות והייבוא מ-Excel נשארו כפי שהם.

• כל התעריפים בטבלה אחת — במקום מודל נפרד לכל שדה
• תאריך תחולה אחד לכל השינויים, ושם כלל שנוצר אוטומטית
• תא אחד לכל סוגי הפעולה: 25 / ‎+2 / ‎-1.5 / ‎+5%, עם תצוגה מקדימה חיה
• "החל על הכל" — עדכון רוחבי של כל התעריפים בבת אחת (למשל ‎+5%)
• מצב "תיקון בסיס" לתיקון תעריף שהוקלד בטעות — עד היום היה אפשר רק לכסות עליו בכלל
• תיקון: עמודת המחיר הנוכחי שברה שוויון בין כללים חופפים אחרת מהחיוב בפועל, ויכלה להציג מחיר שאינו מחויב

בכל קטעי הקוד בתיעוד (/docs) כפתור "העתק" הצף בפינה העליונה חפף את תחילת השורה הראשונה של הקוד. הסיבה: הדף RTL בעוד שהקוד עצמו dir=ltr, כך שהכפתור (ממוקם לוגית ב-end) נפל בצד שמאל — בדיוק היכן שהקוד מתחיל — וה-<pre> לא שמר מספיק מרווח עליון. נוסף gutter עליון קבוע (pt-9) שמבטיח שהשורה הראשונה תמיד מתחת לכפתור ולתווית השפה, ללא תלות באורך השורה או בכיוון הטקסט.

משלוחים שבוצעו בפועל בידי סאב-שליח הציגו בדוח הרווחיות עלות מסירה ₪0 (או עלות לפי המחירון הישן של הסאב) למרות שהמנהל שלו מתומחר כראוי. הסיבה: כפתור 'תיוג היסטורי' בדף מנהל-השליחים שייך למנהל ביקורים ישנים של הסאבים שלו, אבל לא חישב מחדש את סנאפשוט עלות המשלוח — הסנאפשוט נשאר כפי שנשמר ברגע המסירה, כלומר לפי מחירון הסאב (ולסאב לרוב אין מחירון בכלל → ₪0). דוח המנהל החודשי, שמחושב חי מהביקורים, כבר הציג את הסכום הנכון — ולכן שני המספרים סתרו זה את זה. מעכשיו התיוג ההיסטורי מחשב מחדש את העלויות של כל היום/שליח המושפעים, בדיוק כפי שכבר עושה מסלול הניתוק. בנוסף הורצה תיקון נתונים חד-פעמי: 2,017 ביקורים שכבר תויגו בעבר תומחרו מחדש לפי מחירון המנהל הנכון.

המשך לחשיפת קישורי המעקב ב-API. עד כה השליפה הבודדת GET /api/v1/shipments/{barcode} — ה-endpoint הטבעי ל"תן לי את הלינק לפי מספר המשלוח" — לא החזירה את קישור המעקב (רק שליפת הרשימה עשתה זאת). כעת גם היא מחזירה publicId, trackingUrl ו-validationUrl. בנוסף נכתב מדריך מהיר בתיעוד הציבורי (/docs/api) שמראה בשלושה צעדים איך לשלוף את trackingUrl של משלוח לפי הברקוד ולשלוח ללקוח הקצה, עם אזהרה מפורשת לא להרכיב את הקישור מהברקוד ידנית (קישור-ברקוד מצומצם בכוונה). בפורטל, בעמוד הגדרות ה-API, נוסף כרטיס הבלטה שמקשר ישירות למדריך, וקישור אינליין על שורת ה-endpoint הרלוונטי.

• GET /api/v1/shipments/{barcode} מחזיר עכשיו גם publicId/trackingUrl/validationUrl
• מדריך מהיר ב-/docs/api: קישור מעקב לפי מספר משלוח
• קישור למדריך בעמוד הגדרות ה-API בפורטל

סגירת פער הרשאות שהתגלה בבדיקת החשיפה החדשה של קישורי המעקב ב-API. משתמש פורטל יכול להיות מוגבל ל-subset מהקבוצה המקושרת (CustomerUser.scopedCustomerIds) — למשל לראות רק שניים מתוך חמישה סאב-לקוחות. עד כה, כשמשתמש כזה יצר מפתח API, המפתח קיבל גישה ל*כל* הקבוצה המקושרת, כי authenticateApiKey בנה את היקף המפתח מ-getAllowedCustomerIds עם scope ריק והתעלם מההגבלה של המשתמש. כלומר משתמש מוגבל יכול היה להרחיב את ההרשאה של עצמו דרך ה-API (בתוך אותו tenant — לא דליפה חוצה-לקוחות, אבל עקיפה של הגבלה מכוונת). כעת ה-scope של היוצר מוקפא על המפתח בזמן היצירה (עמודה חדשה api_keys.scoped_customer_ids), ו-authenticateApiKey מצליב אותו מול הקבוצה המקושרת החיה — כך שהמפתח רואה לכל היותר את מה שיוצרו יכול, ומצטמצם עוד אם לקוח עוזב את הקבוצה. מפתחות קיימים וכן מפתחות של הצוות/tenant נשארים עם scope ריק = גישה מלאה לקבוצה, בדיוק כמו קודם. אומת מקצה לקצה מול קבוצה מקושרת אמיתית: מפתח מלא ראה את כל 4 הלקוחות, מפתח מוגבל ראה רק את הלקוח היחיד שהוגדר לו.

• עמודה חדשה api_keys.scoped_customer_ids — צילום ה-scope של יוצר המפתח
• authenticateApiKey מצליב את ה-scope מול הקבוצה המקושרת החיה — מצמצם, לעולם לא מרחיב
• משתמש פורטל מוגבל כבר לא יכול לייצר מפתח רחב ממנו
• מפתחות קיימים + מפתחות צוות/tenant ללא שינוי (scope ריק = גישה מלאה)

במובייל, שורת הכותרת של צ'אט פתוח הכילה חמישה צ'יפים בשורה אחת ללא עטיפה (סטטוס טיפול, דף לקוח, ארכיון, "קבוצה", ישויות מקושרות) — הרוחב המינימלי שלהם עלה על רוחב המסך וכל הפאנל נדחף החוצה. מעכשיו במובייל נשארת שורה אחת נקייה בסגנון WhatsApp: חזרה, אווטאר, שם, סטטוס טיפול ותפריט ⋮ שמרכז את הפעולות המשניות (דף לקוח, ארכיון, קישור קבוצה); השליח והלקוח המקושרים עברו לשורת-המשנה מתחת לשם (לחיצה פותחת את דיאלוג הקישור). בדסקטופ הפריסה ללא שינוי. בנוסף נוספה שבירת-מילים לבאנר ההצעות כך שטקסט ארוך ללא רווחים לא ירחיב את הפאנל.

עריכת מחירון של שליח נכשלה בשגיאה 'תאריך ישן מהמותר (45 ימים אחורה)' גם כשהתאריך שנבחר היה לפני ימים ספורים בלבד. הסיבה: בשמירה נשלחים כל כללי המחירון של השליח, והשרת אכף את מגבלת הרטרואקטיביות על כולם — כולל כללים ותיקים ששמורים במערכת ושלא נגעו בהם. ברגע שכלל קיים 'הזדקן' מעבר לחלון של 45 יום, המחירון של אותו שליח הפך לבלתי-ניתן-לשמירה. מעכשיו המגבלה נאכפת רק על כלל חדש או על כלל שתאריך התחולה שלו שונה בפועל — בדיוק כפי שכבר עובד במחירון הלקוחות.

מספר הגרסה של ה-Graph API של Meta (v21.0) היה כתוב בקשיחות בשמונה קבצים נפרדים — בשליחת ההודעות, בהורדת מדיה, בתמלול הקלטות, בניהול התבניות, בבדיקת התקינות ובבדיקת החיבור — ותחת שני שמות שונים לאותו קבוע. Meta מוציאה כל גרסת Graph משימוש כשנתיים לאחר יציאתה, כך שביום שבו נצטרך לעלות גרסה היה צריך לרדוף אחרי שמונה מקומות, ומספיק לפספס אחד כדי ששליחות או הורדת מדיה ייפלו בשקט. הכל רוכז ל-lib/messaging/meta-graph.ts שמחזיק את הקבוע היחיד ופונקציית metaGraphUrl לבניית הכתובת; כל אחת מ-11 הקריאות ל-Meta עוברת דרכו. שינוי פנימי בלבד — הכתובות שנשלחות בפועל זהות לחלוטין לקודמות, ואין שינוי בהתנהגות המערכת.

המשך ישיר לקישור המעקב לפי ברקוד שנכנס אתמול. בבדיקה התברר שהסיבה שלקוחות ביקשו לינק מבוסס-ברקוד לא הייתה שהם רוצים תצוגה מצומצמת — אלא שהברקוד הוא פשוט המזהה היחיד שהיה להם ביד: התשובה של /api/v1/shipments לא החזירה את מזהה המעקב האישי בכלל, ולכן אי אפשר היה לבנות ממנה את הקישור המלא. כעת כל משלוח בתשובת ה-API מחזיר publicId, trackingUrl ו-validationUrl מוכנים לשימוש; אירוע ה-webhook shipment.created מחזיר trackingUrl; ובטבלת המשלוחים נוספה עמודת "לינק מעקב" (מוסתרת כברירת מחדל, מופעלת מתפריט העמודות) שנכללת גם בייצוא לאקסל. כך אפשר לשלוח ללקוח הקצה במייל או ב-SMS את הקישור האישי המלא — עם הכתובת, המפה ואפשרות עדכון פרטי המסירה — במקום להסתפק בקישור הברקוד המצומצם. במקביל, לוגיקת בניית הקישורים (איזה מזהה פותח איזה עמוד) רוכזה ל-lib/shipments/public-links.ts אחרי שהתגלה שהיא שוכפלה בשלושה מקומות שכבר הספיקו להיפרד זה מזה — אחד מהם בנה קישור עדכון-פרטים מהברקוד, קישור שהמערכת לא יכולה לפתוח. התיעוד הציבורי עודכן בהתאם.

• GET /api/v1/shipments מחזיר publicId, trackingUrl ו-validationUrl לכל משלוח
• webhook shipment.created מחזיר trackingUrl — לשליחה ישירה במייל "ההזמנה נשלחה"
• עמודת "לינק מעקב" בטבלת המשלוחים, נכללת בייצוא לאקסל (למיזוג-דואר)
• לוגיקת הקישורים רוכזה למקום אחד — היא הייתה משוכפלת בשלושה מקומות ונפרדה
• תיעוד /docs/api ו-/docs/shipments עודכנו

חלון העברת ההודעה עוצב מחדש בסגנון וואטסאפ: לחיצה על צ'אט ברשימה מסמנת אותו (במקום להעביר מיד), אפשר לבחור כמה צ'אטים ואז ללחוץ 'העברה' פעם אחת לכולם; הרשימה מציגה עכשיו תמונת פרופיל, שם ומספר טלפון (או 'קבוצה') לכל צ'אט, והצ'אטים שנבחרו מוצגים בתחתית החלון. בנוסף, העברה של הודעה מצוטטת (תשובת swipe) כבר לא גוררת איתה את הציטוט המקורי — עד היום הנמען ראה ציטוט של הודעה מצ'אט אחר שלחיצה עליו לא הובילה לשום מקום; מעכשיו התוכן נשלח נקי, בלי הציטוט. והנמען רואה עכשיו סימון '↪️ הודעה שהועברה' בראש כל הודעה שהועברה אליו — כמו תווית ההעברה של וואטסאפ, שמנגנון ההעברה של ספק ה-WhatsApp לא מציג בפועל; הודעות קוליות ומדבקות, שלא יכולות לשאת כיתוב, מועברות כפי שהן.

בדיקת היתכנות לקריאה-בלבד מול שרת הבלדר של זיפ (הקבלן הראשון שמחובר) חשפה שלושה פערים בין התיעוד למציאות, ותוקנו לפני שידור ראשון: (1) הפונקציה GetCustomerRecords דורשת פרמטר בשם pCustomer ולא pParam — אומת ישירות מהשרת (SaveData ו-GetDeliveryDetails כן משתמשים ב-pParam כמתועד). (2) התשובות החיות כוללות שדה StatusName עם שם הסטטוס בעברית של חברת השליחים — נקלט ומשמש גם כתווית תצוגה וגם כמיפוי-גיבוי לקודי סטטוס שלא מופיעים בתיעוד (אצל זיפ: קוד 22 = 'נכשל', שממופה כעת לכשל מסירה כולל סימון הביקור בציר הזמן ועדכון ליונוויל), עם הגנת שלילה ('לא בוצע' לעולם לא ימופה כהצלחה). (3) השרת של זיפ לא תומך ב-HTTPS על פורט 58090 — הכתובת הנכונה לשידור היא http. בנוסף — מניעת כפל שידור: לזיפ יש אינטגרציית בלדר גם בצד של ליונוויל, כך שעדכון הנהג בליונוויל היה גורם לה לשדר שוב את אותו משלוח. מעכשיו שיבוץ נהג בלדר לא דוחף את הנהג לליונוויל (כל שאר הסנכרון — סטטוס, כתובת, הערות — ממשיך כרגיל), בכל מסלולי השיבוץ: טבלת משלוחים, דף משלוח, סריקה, אפליקציית מנהלים, פעולת AI ובוט קבוצתי. במקביל, סנכרון נכנס מליונוויל (שמעתה לעולם לא מכיר את נהג הבלדר) לא דורס את השיבוץ המקומי.

נציגות דיווחו שכשמשימת איסוף שכבר הייתה משובצת לשליח הועברה לשליח אחר — לא נשלחה הודעת 'שיבצתי עליך איסוף' לקבוצת הקבלן החדש. הסיבה: התרחיש הופעל רק במעבר הסטטוס מ'משלוח חדש' ל'שובץ לשליח איסוף', ובהחלפה הסטטוס כבר 'שובץ' ולא משתנה. מעכשיו, החלפת שליח איסוף שמבוצעת מתוך המערכת (דף משלוח, שיבוץ איסופים, שיבוץ מרובה, אפליקציית מנהלים, פעולת AI) שולחת את ההודעה לקבוצת הקבלן החדש — בתנאי שהשליח באמת הוחלף (שמירה חוזרת של אותו שליח לא שולחת דבר) ושהשליח החדש אינו שכיר. החלפה שמבוצעת בליונוויל עצמה במכוון לא שולחת הודעה.

יתרת הפתיחה בתזרים המשולב נצברה מכל ההיסטוריה — חודשים ישנים (מלפני תזרים ההכנסות) מכילים רק הוצאות, ולכן הוצג 'חוב' ענק חסר משמעות. מעכשיו הצבירה מתחילה רק מעוגן שנקבע ידנית: כל עוד לא נקבעה יתרת פתיחה — היתרה מתחילה מ-0 ומוצג באנר עם כפתור לקביעתה; אחרי קביעת עוגן, היתרה מתגלגלת ממנו קדימה בלבד (פתיחת חודש = סגירת החודש הקודם). העריכה הפכה בולטת: כפתור 'עריכה' על כרטיס יתרת הפתיחה, אייקון עריכה גם על שורת הפתיחה בטבלה, תגית 'ידנית' על חודש מעוגן, וכפתור 'איפוס' שמוחק את העוגן של החודש.

שני כשלים מהקבוצות. (1) בקבוצת בזק קבלן ענה 'תחזירו אליי בבקשה זה לא שלכם' (דחיית משלוח), והבוט הפעיל את תרחיש השידור ושאל למזהה משלוח. השורש: הטננט הוסיף ביטוי-שידור מותאם רחב מדי — 'שלכם' — שנמצא כתת-מחרוזת ב'זה לא שלכם'. שער הביטול של תרחיש השידור הורחב לזהות גם דחייה/החזרה ('תחזירו', 'להחזיר', 'לא שלי/שלכם/שלנו', 'לא שייך') — כך שהודעת דחייה משתיקה את הבוט, בעוד השימוש המכוון ('המשלוח שלכם, תשדרו', בלי 'לא') ממשיך לשדר. (2) בקבוצת יצחק הפצה הבוט שאל צפי מסירה, השליח ענה 'היום', ושער הרלוונטיות דחה זאת ולא העביר ללקוח — למרות ש'מחר'/'עד הערב' כן עברו. חוזק ה-prompt: יום או שעה בודדים ('היום', 'מחר', 'בערב', 'עד הערב', שעה) הם תשובת צפי תקינה מלאה. תחום לשאלות צפי בלבד — 'היום' לשאלת טלפון/כתובת עדיין נדחה. שני התיקונים אומתו חי; #1 מכוסה בטסט. (3) המשך של (1): שאלת 'אצטרך את מזהה המשלוח' של הבוט פתחה גישור שחי 6 שעות ותפס כל ברקוד ערום שנשלח בקבוצה — כך שברקוד שקבלן שלח 3 שעות אחר כך (בהקשר של דיווח על איסוף) שודר בטעות. קוצר ל-15 דקות: תשובת ברקוד אמיתית מגיעה תוך רגעים. (4) המשך עומק של (1+3): כשקבלן מדווח על תקלה (מס'לא תקין, אין מענה) והברקוד יושב בהודעה הקודמת — צילום מדבקה (OCR) או מספר ערום שנשלח רגע לפני — הבוט לא זיהה את המשלוח והדיווח לא הגיע ללקוח. נוסף שחזור ברקוד מההודעה שמיד-לפני, תחת כללים קשיחים כדי שלעולם לא ייצמד דיווח למשלוח לא-נכון: רק תרחישי תקלה, רק אותו שולח, רק ההודעה היחידה שמיד-לפני (בהפרש קטן מדקה, ללא סריקה אחורה — זיהוי הטריגר לפי מזהה ההודעה, חסין-כפילויות), ורק אם הברקוד נפתר למשלוח פעיל המשויך לאותו שליח. אומת מול נתוני הפרודקשן של האירוע ועבר ביקורת אדוורסרית. (5) סבב שני של היום — שבעה שורשים מ-9 דיווחי כשל נוספים: תשובת טלפון ללקוח (מספר ערום או אישור שהמספר נכון) מגיעה עכשיו לקבלן — מסלול דטרמיניסטי כשגישור-לקוח יחיד פתוח + יישור ה-handler לאחיו כך שכל תשובה מאושרת מועברת; הנחיית לקוח (החזרה/ביטול) על משימת איסוף כבר לא נשלחת לקבלן (אין מה להחזיר) אלא נפתחת כפתק פנימי לצוות; מניעת שאלה כפולה ללקוח — יצירת הגישור הפכה לתפיסה אטומית (אינדקס ייחודי חלקי ב-DB) ונוצרת לפני השליחה בכל ארבעת התרחישים; תשובת לקוח שמדווחת שהעניין כבר הסתדר ('לקוח קיבל את המשלוח') מקבלת 'תודה על העדכון' במקום 'העברנו לשליח שמטפל'; נעץ מיקום ב-WhatsApp כבר לא נעלם — מומר לקישור Google Maps, נשמר ומועבר בגישורים; אוצר-מילים של מספר-חסר ('אין טלפון') סווג עד היום כ'אין מענה' — נוסף לביטויי טלפון-שגוי; ותוקן template פגום של טננט ששכפל את מספר המשלוח ומחק את השאלה מהודעת הבירור. (6) שאלת צפי על משימת איסוף — שאלה כמו "מתי צפי לאספקה?" על משלוח-איסוף היא דו-משמעית (האספקה = ההחזרה אל הלקוח; ייתכן שהכוונה למועד האיסוף), והפתק הפנימי אף טען בטעות "שטרם שובץ לשליח" כששליח האיסוף דווקא משובץ (חבד/26035468 — החיפוש בדק רק את ביקור המסירה). מעכשיו נכתב פתק פנימי מדויק לצוות שמציין שמדובר באיסוף, נוקב בשם שליח האיסוף המשובץ, ומבקש לברר מול הלקוח למה התכוון; משימות מסירה — התנהגות זהה לחלוטין. (7) שאלת-לקוח של הבוט נשלחה לצ'אט הפרטי של בעל העסק במקום לקבוצת הלקוח (משכן שילה): המשלוח ישב על רשומת לקוח-אב בלי קבוצה, בעוד קבוצת ה-WhatsApp האמיתית רשומה על לקוח-בן — וה-fallback נפל לטלפון. מעכשיו, לפני נפילה ל-1:1, הבוט מזהה את קבוצת-המשפחה — ורק כשיש בדיוק קבוצה אחת בין האב וכל ילדיו (שתי קבוצות שונות = שני תתי-עסקים, לא מנחשים). (8) לקוח שחולק על מסירה שנרשמה ("מופיע שסופק והמשלוח לא סופק", "קיבלו חבילה 1 מתוך 2") כבר לא מקבל את התשובה המבטלת "המשלוח כבר נמסר" — הבוט שותק, ופתק פנימי ייעודי נפתח לצוות ("לקוח חולק על מסירה שנרשמה — נדרש בירור") עם ההודעה המקורית; שאלת צפי רגילה על משלוח שנמסר ממשיכה לקבל את התשובה הישירה. (9) הודעת "אין מענה" ללקוח — תוקנה הסתירה שבה סיכום דיווח השליח ביקש "מס' דירה וקומה" בעוד פירוט המשלוח שמעליו כבר מציג אותם: המסכם מקבל עכשיו את רשימת השדות שכבר מוצגים ומתבקש לציין רק פרטים שבאמת חסרים (כמו קוד כניסה); בנוסף קוצרה תבנית ההודעה לטננט — הוסר בלוק 4 הדוגמאות, נשמרה שאלה קצרה אחת כדי ששיוך התשובות ימשיך לעבוד.

כשה-API של אישופ חוסם את הבקשה ברמת Cloudflare (challenge לפני שהבקשה מגיעה בכלל לשרת), כפתור 'בדיקת חיבור' הציג עד היום 'e-shop דחה את הטוקן (403)' — הודעה מטעה ששלחה את המשתמש לבדוק טוקן תקין לחלוטין. כעת הבדיקה מזהה את חתימת ה-challenge של Cloudflare ומציגה הודעה נכונה: החסימה היא ברמת IP/WAF בצד אישופ ולא בעיית טוקן, כולל מזהה ה-CF-RAY של הבקשה — המספר שצוות אישופ צריך כדי לאתר את החסימה ב-Security Events של Cloudflare שלהם ולהגדיר חריגה. בנוסף, כל הקריאות ל-API של אישופ נשלחות כעת עם User-Agent מזהה (Shipnest-Integration/1.0) במקום זהות אנונימית — לבקשת הצוות הטכני של אישופ וכנוהג מקובל מול WAF.

בדף הסוכן היה אזור צדדי שהציג את רשימת הלקוחות ולידם את העמלה, אבל בפועל הוא היה חסר ערך: אצל רוב הלקוחות הוא הראה את המילה "ברירת מחדל" במקום סכום, ולא הייתה בו שום דרך לראות כמה חבילות נשלחו או כמה הסוכן מרוויח מכל לקוח בחודש. את התמונה האמיתית הרכיבו ידנית באקסל חיצוני. במקום אותו אזור נכנסה עכשיו טבלת "פירוט לפי לקוח" בתוך דוח העמלות החודשי, בדיוק במבנה של אותו אקסל: לקוח, מחיר גבייה, עמלה לחבילה, כמות חבילות וסה"כ עמלה לחודש — שורה לכל לקוח של הסוכן, ממוינת מהמכניס ביותר, עם שורת סיכום. מחיר הגבייה נלקח מפרופיל התמחור של הלקוח, כך שהוא מוצג כמספר נקי כמו באקסל; כשהחיוב בפועל גבוה ממנו בגלל תוספות (חבילה נוספת וכו') הממוצע האמיתי נחשף ב-tooltip במקום לזהם את העמודה. לקוח בלי משלוחים החודש עדיין מופיע — עם מחיר הגבייה והעמלה לחבילה שלו — כי גם באקסל הוא נספר. לקוח שאין לו פרופיל תמחור מסומן בבירור בכתום במקום להציג ₪0 שקרי, וכך התגלה שלעשרות לקוחות פעילים חסר מחירון במערכת. עריכת העמלה הקבועה לחבילה עברה לתוך הטבלה עצמה, והטבלה גם נוספה כגיליון נפרד בייצוא לאקסל ומופיעה גם בפורטל הסוכן עצמו. בהמשך היום נוסף גם פילוח החבילות: הכותרת הישנה הכריזה "עמלה על 4299 מתוך 4299 משלוחים" — משפט חסר משמעות, כי גם לקוח בתעריף ₪0 נספר כ"מזכה בעמלה". במקומו נכנס פילוח אמיתי לשלושה מספרים — חבילות שעברו דרך הסוכן, חבילות שהניבו לו עמלה בפועל, וחבילות שלא הניבו כלום (תעריף ₪0, ללא מודל עמלה, או עמלה שלילית). הפילוח מופיע גם פר-לקוח בטבלה וגם בייצוא לאקסל. אצל הסוכן הראשון שנבדק זה חשף שמתוך 4,299 חבילות ביוני, 1,040 לא הניבו לו שקל — כולן מארבעה לקוחות בתעריף ₪0, כשלקוח אחד לבדו אחראי ל-830 מהן.

• טבלת פירוט לפי לקוח בפורמט הדוח הידני: לקוח | מחיר גבייה | עמלה לחבילה | כמות חבילות | סה"כ לחודש
• מחיר הגבייה מוצג נקי מהמחירון; חיוב ממוצע בפועל (עם תוספות) נחשף ב-tooltip
• לקוח ללא משלוחים בחודש עדיין מופיע עם התעריף והעמלה שלו
• לקוח ללא פרופיל תמחור מסומן בכתום במקום להציג ₪0 שקרי
• עריכת העמלה לחבילה עברה לתוך הטבלה; האזור הצדדי הישן הוסר
• הטבלה נוספה כגיליון "לפי לקוח" בייצוא לאקסל, ומוצגת גם בפורטל הסוכן
• פילוח חבילות בראש הדוח: עברו דרכו / הניבו עמלה / ללא עמלה — במקום "4299 מתוך 4299"
• לקוחות בתעריף ₪0 מופיעים בדוח עם כמות החבילות שלהם ועם ₪0 — לא נעלמים
• הפילוח יורד גם לרמת הלקוח (tooltip על כמות החבילות) וגם לגיליון האקסל
• רשימת הלקוחות בטור הצדדי גוללת בתוך עצמה — היא כבר לא נמתחת הרחק מעבר לסוף הדף
• טבלת הפירוט ממוינת אלפביתית A→Z (לטינית ואז עברית) במקום לפי גובה העמלה
• בורר הלקוח בכללי עמלה הוחלף ב-combobox עם חיפוש — במקום רשימה שנפתחה מהתקרה עד הרצפה
• דף הסוכן רץ מקצה לקצה כמו שאר דפי הפירוט — הוסרה הגבלת הרוחב שהייתה ייחודית לו
• שורת חיפוש לקוח בכותרת טבלת הפירוט; שורת הסיכום מסכמת את התוצאות המסוננות
• עמודת "מחירון" בטבלה — "ערוך מחירון" / "הוסף מחירון", פותחת את אותו dialog של טבלת הלקוחות הראשית
• פריסת דף הסוכן יושרה לדף הלקוח: אין כפתור "חזרה" (הניווט דרך ה-breadcrumb), כפתור העריכה עבר לתוך הבאנר, וכל המרווחים — גם הפנימיים — על רשת 8 פיקסלים

עד היום דף המעקב הציבורי ודף עדכון פרטי המסירה נפתחו שניהם רק לפי מזהה פנימי (public_id) — מפתח אקראי שמגיע מליונוויל. לקוחות ביקשו שהקישור יסתיים בברקוד של המשלוח, כדי שיוכלו להרכיב אותו בעצמם במיזוג-דואר (למשל במייל ללקוח הקצה) מתוך מספר ההזמנה שכבר יש להם. הבקשה מולאה — אבל רק על אחד משני הדפים, וזה מכוון: הברקוד הוא מספר רץ, כך שמי שמחזיק ברקוד אחד יכול לנחש ברקודים סמוכים. לכן דף המעקב נפתח כעת גם לפי ברקוד, אך במצב מצומצם — מצב המשלוח, עיר היעד וצפי ההגעה בלבד, בלי שם הנמען, בלי הכתובת המלאה, בלי המפה, בלי המזהה האישי (שהיה בעצמו מדליף את הגישה לדף העדכון), ובלי סיבת הכשל — טקסט חופשי שהשליח מקליד, שנמצא בפועל מכיל קוד דלת או הפניה לשכן. דף עדכון פרטי המסירה — שכותב את הכתובת ומסנכרן אותה חזרה לליונוויל — ממשיך להיפתח אך ורק לפי המזהה האישי, כך שאיש לא יוכל לרוץ על ברקודים ולשנות הוראות מסירה של חבילות של אחרים. בכרטיס המשלוח ובפורטל הלקוחות נוסף פריט חדש בתפריט הקישורים: לינק מעקב לפי ברקוד. במהלך העבודה התגלה גם פער שקט — כל נתיב יצירת משלוח שאינו עובר דרך ליונוויל (WooCommerce, קוניבו, אישופ, CashCow, nopCommerce, ייבוא מחסן, שידור בין שותפים וה-API הציבורי) יצר משלוחים ללא מזהה ציבורי כלל, כלומר בלי שום קישור מעקב או עדכון שעובד. כעת כל נתיב יצירה מנפיק מזהה משלו (10 תווים אקראיים, אותה צורה שליונוויל מנפיק), 75 המשלוחים הקיימים שחסרו מזהה מולאו רטרואקטיבית, והעמודה קיבלה אילוץ ייחודיות בבסיס הנתונים. בנוסף, דף המעקב קיבל הגבלת קצב שלא הייתה לו קודם, ומשתנה התבנית validation_url הפסיק ליפול חזרה לברקוד — נפילה שייצרה עד היום קישור שבור.

• דף המעקב נפתח גם לפי ברקוד — לינק גנרי שאפשר להרכיב לבד במיזוג-דואר
• גישה לפי ברקוד מציגה מצב, עיר וצפי בלבד — בלי שם נמען, כתובת, מפה, סיבת כשל או המזהה האישי
• דף עדכון פרטי המסירה נשאר נעול למזהה האישי בלבד — ברקוד לא פותח אותו
• פריט חדש בתפריט הקישורים: לינק מעקב לפי ברקוד — בכרטיס המשלוח ובפורטל הלקוחות
• תוקן: משלוחים מחנויות, ממחסן, משידור-שותפים ומה-API נוצרו ללא מזהה ציבורי — ולכן בלי קישור מעקב שעובד
• 75 משלוחים קיימים מולאו רטרואקטיבית; העמודה קיבלה אילוץ ייחודיות
• הגבלת קצב על דף המעקב הציבורי; משתנה validation_url לא נופל יותר לברקוד (קישור שבור)

דף התזרים חולק לשלוש תצוגות. תזרים הוצאות — הטבלה הקיימת (תשלומים לשליחים/קבלנים וספקים), בתוספת ניהול הוצאות קבועות: מודל ייעודי (כפתור 'הוצאות קבועות') לעריכת רשימת ההוצאות החוזרות של החודש — שכירות, ביטוח, תוכנות וכו' — והרשימה מועתקת אוטומטית לכל חודש חדש מהחודש האחרון שנערך, כל עוד לא שונתה. תזרים הכנסות — שורה נעולה לכל לקוח עם צפי התקבול מהדוח החודשי של חודש העבודה הקודם (שילוח + מחסן − זיכויים, כולל מע"מ), בתאריך יעד לפי יום התשלום של הלקוח (ברירת מחדל: 3 לחודש; ניתן לקבוע יום קבוע פר לקוח מתוך הטבלה). תזרים משולב — טבלה לפי תאריכים: לכל יום סך הכנסות, סך הוצאות ויתרה רצה (יתרת אתמול + הכנסות − הוצאות); יתרת הפתיחה של חודש נגזרת אוטומטית מיתרת הסגירה של החודש הקודם, וניתן לקבוע אותה ידנית כעוגן (למשל יתרת עו"ש בפועל). בנוסף: העמודות המחושבות (יתרה לתשלום, ללא מע"מ, סטטוס תשלום) הפכו לתצוגה בלבד — סטטוס מוצג כתגית צבעונית, ויתרה שעבר תאריך היעד שלה מודגשת באדום.

• שלוש תצוגות בדף התזרים: הוצאות, הכנסות ומשולב — מעבר מהיר ביניהן
• הוצאות קבועות עוברות אוטומטית מחודש לחודש וניתנות לעריכה במודל ייעודי
• צפי תקבולים אוטומטי פר לקוח מהדוח החודשי, לפי יום התשלום של הלקוח (ברירת מחדל 3 לחודש)
• תזרים משולב עם יתרה רצה יומית ויתרת פתיחה שנגזרת מסגירת החודש הקודם (או נקבעת ידנית)
• סטטוס תשלום כתגית צבעונית ויתרות בפיגור מודגשות באדום

לקוחות הפורטל ביקשו לראות במעקב המשלוח יותר ממה שהוצג עד היום. ציר הזמן הציג רק את רשומות הביקור (איסוף מהשולח / מסירה לנמען), כך שבין האיסוף למסירה המשלוח 'נעלם' מהתצוגה לימים שלמים — כל השלב במחסן לא הופיע כלל. כעת הציר מאחד את רשומות הביקור עם חותמות מחזור-החיים שכבר קיימות על המשלוח (in_inventory_at / in_transfer_at / out_inventory_at / canceled_at — נקבעות במעבר הראשון לכל סטטוס ואינן מתאפסות) ומציג את כולן ממוינות כרונולוגית: המשלוח נוצר → איסוף מהשולח → נקלט במרכז המיון → הועבר בין מרכזי מיון → יצא להפצה → מסירה לנמען / כשל / ביטול. כשל מסירה מציג גם את סיבת הכשל, ואירוע שטרם קרה מוצג כ'מתוכנן' בתחתית הציר. בנוסף נוסף כרטיס 'מסרונים שנשלחו לנמען' — הלקוח רואה אילו הודעות נשלחו בפועל לנמען שלו (סוג הטריגר, מועד, טלפון היעד, תוכן ההודעה, והאם נשלחה או נכשלה). האיחוד של שלושת מקורות ההודעות (יומן ביקורת, הודעות מתוזמנות, ועמודות ה-legacy על המשלוח) חולץ ל-lib/shipment-messages ומשמש גם את כרטיס המסרונים בצד הניהול, כדי ששני המשטחים לא ייפרדו. הפרויקציה לפורטל חושפת ללקוח רק את מה ששייך לו: ללא ספק ההודעות (Green API / Meta), ללא שגיאת הספק הגולמית, וללא הודעות מתוזמנות שטרם נשלחו. הגישה מוגבלת להרשאת 'צפייה במשלוחים' ולסט הלקוחות המקושרים של המשתמש, כמו יתר דף המשלוח.

• ציר הזמן במעקב המשלוח כולל כעת גם קליטה במחסן, העברה בין מרכזי מיון ויציאה להפצה — עם מועד לכל שלב
• כשל מסירה מוצג עם מועד הכשל וסיבת הכשל; ביטול מוצג כאירוע בפני עצמו
• כרטיס חדש 'מסרונים שנשלחו לנמען' — כל ההודעות שנשלחו ללקוח הקצה, עם מועד, תוכן וסטטוס שליחה
• לוגיקת איחוד ההודעות שותפה בין הפורטל לצד הניהול (lib/shipment-messages) כדי למנוע פער בין המשטחים

אצווה של שיפורי חוויה באפליקציית השליחים, מיועדת לשחרור בנייה יחיד (אין OTA). כפתורים מתים: 'שכחתי סיסמה' פותח כעת את דף איפוס הסיסמה (shipnest.io/forgot-password, אותה טבלת משתמשים); כפתור 'שלח קבלה ללקוח' שלא היה מחובר — הוסר; ההצעה 'חפש בכל המשלוחים' בסורק (שהובילה להודעת 'בקרוב') הוחלפה בהודעה ישירה. מסך ההזדכות: כשל טעינת רשת כבר לא מוצג כמצב הצלחה 'אין חובות פתוחות' — מוצג מצב שגיאה עם כפתור 'נסה שוב'. מודעות לאיסוף: מסך הביקור מנסח 'איסוף' במקום 'מסירה' לאורך הזרימה (סטטוס, כותרת כתובת, הוכחה, CTA 'סמן כנאסף', דיאלוג אישור, toast) כשהמשימה היא PICKUP — משלים את תיקוני השרת. סיכום משלוח שהושלם: ניתן כעת לצרף תמונת הוכחה גם אחרי הסימון (תרחיש 'שכחתי לצלם'), והתווית הקשיחה 'היום' הוחלפה בתאריך אמיתי ('היום'/'אתמול'/תאריך מלא). WhatsApp: נפתח עם הודעת 'אני בדרך אליך' מוכנה + fallback ל-wa.me כשאינו מותקן; ניווט Google עבר מנעיצת-פין (q=) להכוונת-נסיעה (dir/). שקיפות רווחים: כל שורת משלוח בפירוט מציגה כעת את התעריף שממנו חושבה — תעריף בסיס, האזור שקבע אותו, ותוספת חבילות (הנתונים כבר הגיעו מהשרת ולא הוצגו); שורה שתומחרה ל-₪0 כבר לא נעלמת (סכום מוצג תמיד כשיש מחירון, כדי שהפירוט יסתכם לסך); 'התאמות ידניות' ו'ניכויי זיכוי' נפתחות עכשיו לפירוט (סוג/כמות להתאמות; סיבה/לקוח/מספר-זיכוי לניכויים, מוצגים כשליליים); נוסף רענון-במשיכה, ומעבר בין תקופות שומר על הנתונים הקודמים במקום להבהב. מיקום חי: 'המרחק ממני', מיון 'הקרוב ראשון' ו'התחל מהמיקום שלי' רצו על דגימת GPS חד-פעמית שלא התעדכנה — עכשיו הם משתמשים ב-watchPositionAsync ומתעדכנים תוך כדי תנועה. אמינות: מפתח ה-Idempotency בקריאות הוכחת-מסירה/גוביינא/חתימה הפך לפרמטר חובה (הגנת קומפילציה מפני קורא עתידי שישמיט אותו ויכפיל שורות/אחסון בניסיון חוזר). נראות רשימת היום: נוסף חיפוש חופשי (שם/רחוב/עיר/ברקוד) וכל כרטיס מציג כעת את הברקוד — כדי למצוא משלוח מסוים מבין עשרות; תווית התאריך הפכה ל'חזרה להיום' בלחיצה כשלא צופים בהיום; והטאב כבר לא קופץ מתחת ליד המשתמש כשמסלול נהיה פעיל ברקע (ברירת-המחדל החכמה חלה פעם אחת ליום, לא בכל poll).

• כפתורים מתים תוקנו/הוסרו: 'שכחתי סיסמה', 'שלח קבלה', וסטאב חיפוש הסריקה
• שגיאת רשת בהזדכות כבר לא נראית כ'הכל הוזדכה'
• ניסוח 'איסוף' לאורך מסך הביקור למשימות PICKUP
• צירוף הוכחת מסירה אחרי הסימון + תאריך אמיתי בסיכום
• WhatsApp עם הודעה מוכנה + fallback ל-wa.me; ניווט Google בהכוונה
• שקיפות רווחים: תעריף/אזור/תוספת לכל שורה, פירוט התאמות וניכויים, רענון-במשיכה
• מיקום חי (watchPositionAsync) למרחקים/מיון/נקודת-התחלה
• חיפוש + ברקוד ברשימת היום, 'חזרה להיום', ותיקון קפיצת הטאבים

סבב תיקוני שרת לאפליקציית השליחים (עצמאי מהאפליקציה — חלקם מתקנים גם את הגרסה המותקנת בשטח, ללא שחרור). קשיחות התחברות: (1) ה-hash הדמה שנועד למנוע timing-attack היה פגום — 61 תווים, bcrypt לא-תקין — וגרם ל-bcrypt.compare להתקצר ל-0ms, מה שיצר timing-oracle לזיהוי קיום כתובות אימייל; הוחלף ב-hash תקין בן 60 תווים. (2) נתיב התחברות הלקוח (CustomerUser) במובייל לא נעל חשבון אחרי ניסיונות כושלים — נוספה נעילה זהה למדיניות הצוות (5 ניסיונות → נעילה ל-15 דק', איפוס בהצלחה) מעל העמודות הקיימות, ללא migration. (3) נוסף rate-limit לכל שלושת נתיבי ההתחברות (login/refresh/google) כבלם משני מעל הנעילה הפר-חשבונית. (4) השוואת ה-hash של ה-refresh token עברה מ-'!==' ל-timingSafeEqual. תיקון איסופים (PICKUP): (5) עד כה משימת איסוף באפליקציה ניווטה את השליח לכתובת הנמען במקום לנקודת האיסוף (הקואורדינטות והכתובת נבנו מהיעד בלבד); כעת ה-API מזהה kind=PICKUP ומחזיר את הקואורדינטות/כתובת/איש-קשר של המקור (source*), עם נפילה ל-null במקום ליעד כשאין קואורדינטות מדויקות — כך שהניווט נעשה לפי כתובת המקור ולא לנקודה שגויה. מסירות נותרו זהות לחלוטין. (6) סימון איסוף כ'הושלם' הפסיק לירות webhook כוזב 'shipment.delivered' ואת התראות ה'delivered' לחנויות (Woo/Konimbo/CashCow/Shopify/NopCommerce) — הזמנה שרק נאספה כבר לא תדווח כנמסרה. הלוגיקה חולצה ל-lib/mobile-visit-fields עם כיסוי טסטים. ניקוי משטח תקיפה: (7) הוסרו שלושה endpoints יתומים ולא-בשימוש מה-API המובייל — /inbox (שהחזיר בקריאה אחת ביקורים, טלפונים וסכומי גוביינא מכל ה-tenants שאליהם ה-Person מקושר, משטח דליפה חוצה-tenant ללא שום צרכן באפליקציה), personal-stops (CRUD מלא לא-מחובר), ו-location/ping (הוחלף מזמן ב-location/batch). git-reversible אם ה-UI התואם ייבנה בעתיד. קשיחות נוספת: (8) פינגי המיקום (location/batch) קיבלו recordedAt מהלקוח ללא בדיקה — ping עתידי היה גורם לשליח להיראות 'במשמרת' ללא הגבלה (הדשבורד מסיק זאת מפינגים בשעה האחרונה); ה-timestamp נחסם כעת ל-'עכשיו' (pings ישנים מה-offline queue נותרים לגיטימיים). (9) גביית גוביינא (COD) חדלה להוסיף רשומת היסטוריה כפולה כשהרשומה כבר WITH_DRIVER — הגנת-עומק ל-retry ללא Idempotency-Key.

כשל שדווח בקבוצת פיל ביי אבי: היה גישור 'אין מענה' פתוח על משלוח 25885959 (ממתין לתשובת הלקוח). בקבוצת זיפ נציג שאל 'למה נכשל 25917396?', והקבלן ענה בתשובת swipe (ציטוט) 'זה נמסר, נשלח עם כפולה, הכפולה צריכה לחזור'. הבוט זיהה במילה 'נמסר' עדכון-פתרון של קבלן, ומכיוון שההודעה לא נקבה בברקוד בטקסט עצמו (הברקוד היה בהודעה המצוטטת), הוא שייך אותה לגישור היחיד הפתוח — 25885959 — והעביר ללקוח הלא-נכון (feel by abby) עדכון על משלוח שכלל לא שלו. השורש: רגל ה-source-resolution לא קיבלה בכלל את מזהה ההודעה המצוטטת, וזיהתה משלוח רק לפי ברקוד בטקסט. התיקון: הרגל מקבלת עכשיו את הציטוט, מזהה ממנו את המשלוח האמיתי, ואם הוא שונה מהמשלוח של הגישור הפתוח (או שההודעה נוקבת בטקסט בברקוד של משלוח אחר) — היא לא מגשרת. עדכון-פתרון סתמי בלי ברקוד ('הסתדר', 'סופק') ממשיך להתנהג כרגיל. אומת מקצה לקצה על האירוע.

כשל שדווח בקבוצת טאצ': לקוח עדכן מספר טלפון (053-2347485) בתגובה לשאלת 'טלפון שגוי', והבוט זרק אותו — נדרשה התערבות אנושית, ומאוחר יותר הבוט העביר לשליח הודעה בלתי קשורה כאילו הייתה המספר. אובחנו שלושה באגים. (1) isPureGreeting — הסינון הזול שמזהה ברכות לפני שער ה-LLM — סיווג מספר טלפון ערום כ'ברכה טהורה', כי אחרי הסרת אותיות לא נשאר בו כלום. מעכשיו הודעה שמכילה ספרה אינה ברכה, ומגיעה לשער כרגיל. (2) extractIsraeliPhone קרא תיוג @mention של איש צוות (@972556686876) כמספר טלפון, ולכן הבוט עדכן במשלוח מספר של איש צוות והעביר אותו כ'טלפון מעודכן'. מעכשיו תיוגי @ מוסרים לפני חילוץ הטלפון, כך שרק מספר שהוקלד בפועל נלקח. (3) הגישור נשאר פתוח אחרי שאיש צוות פתר ידנית ('שולח לנהג'), ולכן הבוט המשיך להחזיק אותו ותפס אליו הודעה זרה. מעכשיו הודעת צוות ברורה של טיפול/העברה-לנהג בקבוצת הלקוח סוגרת את הגישור — שמרנית: רק כשגישור אחד פתוח (לא דו-משמעי) ורק על ניסוח טיפול חד-משמעי, לא על פטפוט. שלושת התיקונים מכוסים בטסטים. תיקון (1) לבדו סוגר את האירוע — הטלפון האמיתי היה מגושר מיד והגישור היה נסגר לפני ההודעה השנייה.

הבוט השיחתי בצ׳אט 1:1 של ה-business-inbox ענה מיוזמתו לכל לקוח מוכר (התאמה לפי מספר טלפון) — כולל הצפת לקוחות אמיתיים בשיחה חופשית בקו הפרטי שלהם, ואפילו איש צוות שמספרו רשום גם כלקוח. מעכשיו סוכן הלקוח ה-1:1 הוא opt-in פר-טננט וכבוי כברירת מחדל: כשמכובה, הודעות נכנסות עדיין נשמרות ל-inbox לטיפול ידני אך הבוט אינו עונה מעצמו. נוסף מתג ייעודי בהגדרות > ספק AI > 'סוכן פורטל לקוחות' ('מענה אוטומטי בצ׳אט 1:1 של לקוחות'). חשוב: התרחישים המשימתיים של מנוע הקבוצות (העברת צפי, טעויות מיון, תיאום איסופים, לידים, גישור) נשלטים בנפרד דרך botScenarios ואינם מושפעים — הם ממשיכים לפעול כרגיל בקבוצות/בזרימות המקושרות.

• סוכן הלקוח ב-1:1 כבוי כברירת מחדל (opt-in פר-טננט) — סוף להצפת לקוחות בקו הפרטי
• הודעות נכנסות עדיין נשמרות ל-inbox גם כשהבוט מכובה
• מתג הפעלה חדש: הגדרות > ספק AI > סוכן פורטל לקוחות
• תרחישי הקבוצות (צפי / טעויות מיון / תיאום איסופים / לידים) לא מושפעים ונשארים פעילים

קבלן כתב 'שודר אלי פעמיים ואמרתם לי לבטל שידור אחד', והבוט קרא את מילת 'שידור' וענה 'כדי לשדר אליך אצטרך את מזהה המשלוח' — כאילו זו בקשת שידור חדשה. שער זיהוי בקשת השידור (isBroadcastRequest) הוא דטרמיניסטי לפי מילות מפתח, ולא הבחין בין בקשה לשדר לבין ביטול/דיווח. נוסף שער ביטול: הודעה שמזכירה שידור אך נושאת כוונת ביטול ('לבטל שידור', 'בטל', 'תבטלו', 'ביטול'), סירוב ('אל תשדרו', 'לא לשדר'), או דיווח שכבר שודר ('שודר אלי', 'כבר משודר') — הבוט שותק במקום לבקש מזהה משלוח. בקשות שידור אמיתיות ('לשדר את X', 'שדרו לי', 'שימו עלי') ממשיכות לפעול כרגיל. מכוסה בטסט.

שני הפילטרים בראש רשימת הצ'אטים קיבלו אייקונים קבועים שמתאימים למהותם: 'סוג' (לפי מי הצ'אט — לקוח/שליח/קבלן/צוות) מציג כעת אייקון אנשים, ו'מצב' (מצב הטיפול — לא נקראו/ממתינות/בטיפול/טופל) מציג את אייקון תיבת הדואר. קודם ה-trigger של כל פילטר הציג את אייקון הבחירה הנוכחית, מה שלא ייצג היטב את מהות הפילטר.

נוספה אינטגרציית שידור מלאה למערכת בלדר (Baldar) — התוכנה שמפעילות חברות שליחים רבות בישראל — במתכונת זהה לשידורי SNL. ההגדרה בכרטיס הנהג תחת 'שידורים': בוחרים 'בלדר', מזינים את כתובת השירות (service.asmx) ואת קוד הלקוח שקיבלתם מחברת השליחים, וכתובת מחסן (מוצא למסירות ונקודת החזרה לאיסופים). מרגע החיבור, שיוך משלוחים לנהג בלדר משדר אוטומטית: משיוך מרובה בטבלת המשלוחים (עם עדכון התקדמות חי), מדף הסריקה (שידור אוטומטי עם כל סריקה), משיוך בודד בדף המשלוח, מפעולת AI ומבקשת שידור בקבוצת וואטסאפ. השידור בונה את רצף 28 הפרמטרים של SaveData לפי מסמך התיעוד הרשמי — כולל ניקוי תווים שוברי-פורמט, המרת גוביינא מאגורות לשקלים, קידוד קומה/דירה/כניסה בשדה מספר הבית, ואבטחת כתובת: בשידור איסוף הקבלן רואה את נקודת האיסוף והמחסן בלבד, לעולם לא את כתובת לקוח הקצה. מספר המשלוח שמחזירה בלדר נשמר כמזהה היוצא של המשלוח (כולל קישור למדבקה), עם הגנת אידמפוטנטיות מפני שידור כפול — וזיהוי תשובת 'שידור כפול' של בלדר משחזר את מספר המשלוח הקיים במקום להיכשל. סטטוסים חוזרים בשני מסלולים: cron שדוגם את GetCustomerRecords כל רבע שעה וממפה את טבלת הסטטוסים של בלדר לסטטוסים שלנו (עם הגנה מפני נסיגה מסטטוס סופי), ו-webhook נכנס מוכן ב-/api/webhooks/baldar שממתין רק לאישור של בלדר — הוכן מסמך בקשה מסודר לשליחה אליהם (docs/baldar-webhook-request.md) עם מפרט ה-payload ושאלות הבהרה על התיעוד.

• שידור לבלדר מכל נקודות השיבוץ: טבלה מרובה, דף סריקה, דף משלוח, AI ובוט קבוצתי
• הגדרה פשוטה בכרטיס הנהג: כתובת שירות + קוד לקוח + כתובת מחסן — בלי טוקנים
• בניית SaveData מדויקת: 28 פרמטרים, גוביינא בשקלים, ניקוי תווים שוברי-פורמט
• הגנת כפילויות דו-שכבתית: אידמפוטנטיות אצלנו + זיהוי תשובת duplicate של בלדר
• סנכרון סטטוסים אוטומטי כל 15 דקות + webhook נכנס מוכן ומאובטח
• מסמך בקשה מוכן לשליחה לבלדר לקבלת עדכוני סטטוס בדחיפה

שני דיווחי כשל מהקבוצות. (1) כביסכל: הבוט שאל את הלקוח על טלפון שגוי, והלקוח ענה 'הלקוחה לא עונה גם במיילים, תחזירו את המשלוח אלינו' — הנחיה תפעולית ברורה. שער הרלוונטיות דחה אותה בצדק ('זו לא תשובה לשאלה מה הטלפון'), ולכן היא נזרקה והשולח נשאר בלי מענה. מעכשיו, כשלקוח עונה לשאלת טלפון/כתובת בהנחיה אחרת (החזרה / ביטול / שינוי יעד), הבוט מזהה זאת דרך שער חדש (isCustomerDirective, מדויק ובטמפרטורה 0, מחזיר שלילה בכל ספק ובכל שלילה כמו 'אל תחזירו'), מעביר את דברי השולח כלשונם לשליח, פותח פתק פנימי לצוות לוודא שההחזרה/הביטול בוצע, וסוגר את הגישור. נבדק חי: 9/9 — תופס החזרה/ביטול/שינוי-יעד, ודוחה טלפון, פטפוט, שאלות, שלילה ותודה. (2) זיפ: בקשת שידור מהירה '26033294 לשדר' נבלעה בשקט כי אישור השידור של המשלוח הקודם ('✅ שידרתי אליך') נחת מיליסקונדות אחרי הבקשה החדשה, וחלון ה-burst שנחתך 'אחרי ההודעה היוצאת האחרונה' השמיט את הבקשה עצמה — burst ריק → 'אין מילת מפתח' → שתיקה. תוקן: החלון נחתך לפי ההודעה היוצאת שקדמה לבקשה המפעילה, כך שהבקשה תמיד נכללת. שידורים מהירים ברצף כבר לא נבלעים. (3) עדי אקווה: הבוט בצ׳אט 1:1 ב-business-inbox הציף איש צוות בתשובות אוטומטיות — מספרו קיים גם כרשומת לקוח וגם כמשתמש צוות (TenantUser), וסוכן הלקוח זיהה אותו כלקוח לפי הטלפון בלי לבדוק שהמספר שייך לצוות שלנו. תוקן: בצ׳אט 1:1 שהמספר שלו נמצא במפת אנשי הצוות של הטננט — ההודעה נשמרת ל-inbox אך הבוט אינו עונה.

נציגה דיווחה שבמשימת איסוף הבוט הציג ללקוח את כתובת וטלפון היעד (בני ברק) במקום את המוצא (בית שמש), וכתב 'אין מענה מהנמען לבקשת המסירה' במקום איסוף. אומת בנתונים: משלוח 26119762 הוא taskType=pickup עם מוצא ויעד נפרדים, והבלוק שנשלח הראה את היעד. השורש: כל זרימת התרחישים הייתה מכוונת-מסירה בלבד. התיקון חוצה את כל התרחישים (אין מענה, כתובת שגויה, טלפון שגוי, צפי מסירה, תיאום מחדש, כשל מסירה): (1) בלוק הפרטים ושורת הכתובת מציגים כעת את שדות המוצא במשימת איסוף, עם תווית '📦 איסוף', והכתובת/טלפון של נקודת האיסוף. (2) הסיכום שנשלח ללקוח מנוסח כקושי באיסוף ('אין מענה מאיש הקשר לאיסוף') ולא כמסירה. (3) באג נסתר שנחשף ותוקן: מענה של הלקוח עם טלפון חדש עדכן את שדה טלפון היעד — כך שבמשימת איסוף הוא היה דורס את טלפון הנמען בטלפון של איש הקשר לאיסוף. מעכשיו במשימת איסוף לא נכתב שדה יעד כלל, אך התשובה עדיין מועברת לשליח. הפנייה עצמה תמיד לשולח (הלקוח המשלם), ללא שינוי. מיפוי: משלוחי 'delivery'/'transfer'/ללא-סוג נשארים מכוונים-יעד ללא שינוי.

נוסף תרחיש בוט מסוג חדש בדף 'תרחישי הבוט': כשמשלוח עובר מ'משלוח חדש' ל'שובץ לשליח איסוף' והשליח המשובץ על משימת האיסוף הוא קבלן (פנימי או חיצוני — לא שליח שכיר), הבוט שולח לקבוצת הוואטסאפ של הקבלן הודעה עם פרטי המוצא של האיסוף (שם, כתובת וטלפון של נקודת האיסוף — לא היעד) ומבקש לאשר שזה אזור ההפצה שלו. לקבלן פנימי הנוסח 'שיבצתי עליך איסוף... בבקשה תאשר שזה אזור הפצה שלך', ולקבלן חיצוני 'שידרתי לך איסוף... בבקשה תאשרו שזה אזור הפצה שלכם'. היידוע חד-כיווני — הבוט לא ממתין לאישור. התרחיש נתפס בכל דרכי השיבוץ: דף המשלוח, דף שיבוץ האיסופים, שיבוץ מרובה, אפליקציית המנהלים, פעולת AI, וגם שיבוץ שבוצע בליונוויל והגיע בוובהוק. זהו התרחיש הראשון שמופעל על ידי אירוע מערכת (שינוי סטטוס) ולא לפי הודעה בקבוצה — דף ההגדרות מציג עבורו תג 'אירוע מערכת' ומסתיר את עורך ביטויי ההפעלה. כמו כל תרחיש, כבוי כברירת מחדל ונוסחי ההודעות ניתנים לעריכה.

• הודעה אוטומטית לקבוצת הקבלן ברגע שיבוץ שליח איסוף — עם פרטי המוצא, לא היעד
• נוסח נפרד לקבלן פנימי ('שיבצתי עליך... תאשר') ולקבלן חיצוני ('שידרתי לך... תאשרו')
• שליח שכיר לא מקבל הודעה — התרחיש מיועד לקבלנים בלבד
• נתפס גם בשיבוץ מתוך המערכת וגם בשיבוץ שבוצע בליונוויל (וובהוק)
• תרחיש מונע-אירוע ראשון בדף תרחישי הבוט — מופעל משינוי סטטוס, לא מהודעה בקבוצה

שני שיפורים לתיאום האיסוף היומי. (1) שדה 'טלפון לבירור איסוף' כבר לא חובה: כל עוד לא הוגדר טלפון ייעודי, שאלת הבוקר נשלחת לטלפון העסקי של הלקוח. השדה בדף הלקוח מציג את הטלפון העסקי כברירת מחדל, וטבלת תיאום האיסופים מציגה את המספר שישמש בפועל. אזהרה מוצגת רק כשאין גם טלפון עסקי. (2) הפעלה מרובה: בטבלת הלקוחות הראשית, בבחירה מרובה של לקוחות נוספה פעולת 'תיאום איסוף יומי' — דיאלוג שמפעיל (או מכבה) את התכונה לכל הלקוחות שנבחרו בבת אחת, כולל אפשרות לקבוע לכולם קבוצת וואטסאפ משותפת לקבלת התשובות. אם לא נבחרת קבוצה, הקבוצה הקיימת של כל לקוח נשארת ללא שינוי, והדיאלוג מתריע כמה מהלקוחות שנבחרו חסרי טלפון עסקי. (3) בורר קבוצות הוואטסאפ המשותף (בכל המערכת) מציג כעת את שם הקבוצה שנבחרה על הכפתור עצמו, במקום הטקסט הקבוע 'בחר קבוצה'. (4) תוקן באג ותיק בייבוא לקוחות מליונוויל שהשאיר מאות לקוחות בלי טלפון עסקי: ליונוויל מחזירה את שדה הטלפון הראשי כ-null, והקוד שרץ מה-webhook פירש זאת כ'יש ערך' ודילג על הטלפון האמיתי שיושב בכתובת האיסוף הרשומה (location.default_phone). כל מסלולי הסנכרון תוקנו (כולל fallback לנייד/משרד), טלפון קיים לא נדרס יותר ב-null, ו-phoneNormalized מתעדכן יחד עם הטלפון. בוצע מילוי חד-פעמי מהנתונים שכבר היו שמורים — 295 לקוחות קיבלו טלפון עסקי רטרואקטיבית. (5) תוקן כשל שהתגלה בלוגי הפרודקשן: בוט הצ'אט העסקי (1:1) הפסיק לענות בכל שיחה שנציג ענה בה מה-inbox — תשובת נציג נשמרת בתפקיד 'staff' וההיסטוריה שנשלחה למודל לא סיננה אותה, מה שהפיל את הקריאה ל-AI (שגיאת 400). מעכשיו תשובות נציג נכללות בהקשר של הבוט כצד-העסק (שלא יענה שוב על מה שכבר נענה), ופתקים פנימיים לעולם לא נשלחים למודל. (6) דיאלוג ההפעלה המרובה מציג כעת את רשימת הלקוחות חסרי הטלפון עם שדה השלמה ליד כל אחד: המספר נשמר בלקוח כטלפון לבירור איסוף, ואם שאלת הבוקר של המחזור הנוכחי כבר יצאה — היא נשלחת אליהם מיד עם השמירה. (7) ימי שליחה פר-לקוח: בכרטיס תיאום האיסוף בדף הלקוח נוספו צ'יפים לבחירת ימים ספציפיים (למשל לקוח שאוספים ממנו רק ב' ו-ה') — כשלא נבחרו ימים, השאלה נשלחת לפי ימי השליחה של החברה; טבלת תיאום האיסופים מציגה עמודת 'ימי שליחה', ושליחה ידנית מכוונת ללקוח בודד עוקפת את ההגבלה.

המשך השדרוג המשפטי של מודול ההסכמים. (1) חתימת המוביל: עד היום ההסכם נחתם רק בצד הלקוח, ושדה 'חתימת המוביל' נשאר קו ריק גם במסמך הסופי. בדף הגדרות חדש — 'הסכמים וחתימה' (מופיע רק לחברות שמודול ההסכמים פעיל אצלן) — מציירים או מעלים את חתימת העסק ומזינים את שם החותם. מרגע ההגדרה, כל הסכם שנשלח לחתימה יוצא כשהוא כבר חתום בצד המוביל: החתימה מוטבעת אוטומטית בדף החתימה הציבורי וב-PDF (טיוטה וסופי) עם שם החותם ומועד החתימה, ומועד חתימת המוביל נשמר על ההסכם. ההסכם הסופי חתום דו-צדדית. (2) נספח ג' נוסח מחדש: הנוסח הקודם ('הלקוח מצטרף לכיסוי ביטוחי...') עלול היה להתפרש כשיווק ביטוח — פעילות הטעונה רישיון לפי חוק הפיקוח על שירותים פיננסיים (ביטוח). הנספח נקרא כעת 'אחריות מורחבת לחבילות' ומנוסח כהתחייבות שיפוי חוזית של המוביל עצמו, כולל הבהרה מפורשת שאין מדובר בפוליסת ביטוח. הניסוח החדש חל על הסכמים חדשים בלבד — הסכמים קיימים שומרים את הנוסח שנחתם בהם. אגב כך אוחדו נוסחי ברירת המחדל של נספחי הערבות והאחריות למקור אחד, כך שדף החתימה וה-PDF מציגים תמיד נוסח זהה (עד עכשיו הסכם ללא נוסח מותאם הציג את ברירת המחדל ב-PDF אך כלום בדף החתימה).

• דף הגדרות חדש 'הסכמים וחתימה': ציור/העלאת חתימת המוביל + שם החותם
• כל הסכם יוצא חתום בצד המוביל — בדף החתימה הציבורי וב-PDF, עם מועד חתימה
• נספח ג' הפך ל'אחריות מורחבת לחבילות' — התחייבות שיפוי חוזית, לא 'ביטוח' (חשיפת רישוי)
• נוסחי ברירת המחדל של הנספחים מאוחדים — מה שמוצג על המסך זהה למה שנחתם ב-PDF

סקירת עומק של תהליך הצעות המחיר והחוזים הולידה שדרוג רוחבי בשלושה צירים. (1) חוקיות ודין: אוחדו שני דפי החתימה הציבוריים לדף קנוני אחד שמציג את מסמך ההסכם המלא — עד היום לקוח שהגיע מקישור תזכורת ראה גרסה מקוצרת בלי הצדדים, הפתיח ונספחי הערבות והביטוח, וחתם על מה שלא ראה. ערבים (נספח ב') חותמים כעת דיגיטלית בשדה נפרד לכל ערב — חתימת ההסכם נחסמת עד שכל הערבים חתמו, כי ערבות ללא חתימת הערב אינה אכיפה; הסכמים ישנים עם ערבים שלא חתמו נחסמים בהמרה עם אפשרות אישור מודע שמתועד ביומן. נוספה הוכחת שלמות ראייתית — טביעת SHA-256 של ה-PDF החתום ושל נוסח התנאים + נוסח ההסכמה המדויק (עם גרסה) נשמרים באירוע החתימה. לכידת ה-IP תוקנה כך שלא ניתן לזייף אותה מצד הלקוח, וה-PDF החתום ותמונות החתימה מוגשים כעת בקישורים מאובטחים קצובי-זמן במקום URL ציבורי קבוע (המסמכים מכילים ת"ז). (2) תהליך מול לקוח: הלקוח מאשר או דוחה הצעת מחיר ישירות מהעמוד הציבורי (בדחייה — עם סיבה), ויוצר ההצעה מקבל התראת מייל מיידית; בחתימת הסכם נשלחת התראת מייל לסוכן ששלח (בנוסף לאישור ללקוח); הצעות והסכמים נשלחים גם ב-WhatsApp דרך חיבור ה-Green API של העסק; נוספו שכפול הצעה (הדרך לתקן הצעה שנשלחה/פגה), משיכת הצעה, ביטול הסכם שנשלח (מכבה את קישור החתימה מיידית) וסיום הסכם פעיל; וקרון יומי מפקיע אוטומטית הצעות שתוקפן עבר והסכמים שתקופתם הסתיימה — סטטוסים שעד היום לא היו ניתנים להשגה כלל. (3) נוחות: תוקן כפתור 'PDF חתום' שהיה שבור לגמרי בדף ההסכם; איש הקשר בהסכם לא נמחק יותר בעריכת טיוטה; המרת הסכם שמקושר ללקוח קיים מעדכנת את הכרטיס במקום ליצור לקוח כפול; שליחה מרשימת ההסכמים עוברת דרך דיאלוג השליחה המלא במקום לדלג על כל ההגדרות; מיון העמודות ברשימות עובד כעת מול השרת; מוני הסטטוסים בפילטרים מציגים ספירה אמיתית; לוגו העסק מוטמע ב-PDF ההסכם; גיליון הליד מציג את ההצעות וההסכמים המקושרים אליו; ותוקנו רספונסיביות במובייל, מצב כהה, נגישות ו-RTL בכל מסכי המודול.

• הלקוח מאשר או דוחה הצעת מחיר אונליין מהעמוד הציבורי — עם התראה מיידית לצוות
• ערבים חותמים דיגיטלית — ההסכם לא נחתם עד שכל הערבים חתמו על נספח הערבות
• שליחת הצעות והסכמים גם ב-WhatsApp דרך חיבור העסק
• דף חתימה קנוני אחד עם מסמך ההסכם המלא + טביעת SHA-256 ונוסח הסכמה מתועד לחיזוק ראייתי
• ביטול/סיום/משיכה + פקיעה אוטומטית של הצעות והסכמים + שכפול הצעה
• PDF חתום מוגש בקישור מאובטח קצוב-זמן (לא URL ציבורי קבוע), וכפתור ההורדה בדף ההסכם תוקן

עד היום משלוח אקספרס שלא נמסר ביום היעד שלו פשוט נשאר תקוע על התאריך שעבר, וצריך היה להזיז אותו ידנית. מעכשיו קרון לילי (00:00 שעון ישראל) בודק את כל משלוחי האקספרס: כל משלוח שיום היעד שלו כבר חלף ועדיין לא נמסר — מקודם אוטומטית ליום הנוכחי, וצובר יום פיגור. בטבלת המשלוחים (וגם בדף 'אקספרס') מופיעה לצד הסטטוס תווית אדומה 'פיגור N ימים' שמראה כמה ימים המשלוח מתעכב מעבר ליעד המקורי. מתגלגלים כל המשלוחים שלא נמסרו — כולל כאלה שנכשלה בהם מסירה (ינוסו שוב) — פרט למשלוחים שנמסרו, בוטלו, או בכשל סופי, שנשארים במקומם. הגדרה ידנית מחדש של יעד אקספרס (בדף המשלוח, בפעולה קבוצתית או ב'הוספת משלוחים') מאפסת את מונה הפיגור, כי מדובר ביעד טרי. החישוב מתבצע לפי שעון ישראל וחוצה מעברי שעון קיץ/חורף בבטחה.

• קרון לילי מגלגל אוטומטית ליום הבא כל משלוח אקספרס שלא נמסר ביום היעד שלו
• תווית אדומה 'פיגור N ימים' לצד הסטטוס, גלויה גם בטבלת המשלוחים וגם בדף אקספרס
• מתגלגלים כל מי שלא נמסר (כולל כשלים שינוסו שוב); נמסר/בוטל/כשל-סופי נשארים במקום
• הגדרה ידנית מחדש של יעד אקספרס מאפסת את מונה הפיגור

סריקה של 4,000 החלטות בוט מפרודקשן. (1) שלושת המסווגים שמפעילים את הבוט רצו ב-temperature של ברירת מחדל (1.0), בעוד שכל שאר המסווגים במערכת מקבעים 0. המשמעות: החלטות גבול הוכרעו בהטלת מטבע. מדידה על תשובת קבלן אמיתית — 'לצערי לא אספיק היום כנראה להוציא אז בראשון' — נתנה 'לא תשובה' פעמיים ו'תשובה' חמש פעמים מתוך שבע. כלומר האם הנחיה של לקוח תגיע לשליח היה תלוי בדגימה אקראית. תוקן לשלושת המסווגים ולמחלץ הכתובת. אחרי התיקון: 7 מתוך 7 זהות. (2) כשלקוח שאל על צפי מסירה של משלוח אמיתי שלו שטרם שובץ לשליח, או נקב במספר שאינו שלו, הבוט שתק ואיש לא ידע — 34 מקרים בארבעה ימים. ארבעת תרחישי השליחים כבר מעלים פתק פנימי לצוות במקרה כזה; תרחיש הצפי לא. מעכשיו נפתח פתק פנימי בשרשור של אותו לקוח (לא נשלח דבר ללקוח). (3) גישורים שפג תוקפם מעולם לא סומנו כפגי-תוקף — הפונקציה קיימת בקוד ואיש לא קרא לה, ו-152 מתוך 160 הגישורים ה'ממתינים' היו למעשה מתים (104 בני שבוע ומעלה). חוברה לקרון הקיים. (4) הצלחה של העברת תשובה לא נרשמה כלל ביומן ההחלטות, רק כישלון — מה שגרם לקריאה שגויה של היומן. נוסף תיעוד סימטרי. (5) הודעת 'המשלוח כבר נמסר' נשלחה שלוש פעמים באותה שיחה: זהו הענף היחיד שלא פותח גישור, ולכן שום דבר לא מנע ממנו לירות שוב בכל פעם שה-burst המצטבר — שעדיין נשא את מספר המשלוח — סווג מחדש. גם שאלת הלקוח, גם תשובת הנציגה וגם 'תודה' הפעילו אותו. נוספה הגנת אידמפוטנטיות של 24 שעות לכל שילוב של צ'אט ומספר משלוח. הסימון נשמר ביומן ההחלטות ולא בהודעות הצ'אט, כי ההד של Green API על הודעות הבוט מאחר בצורה בלתי צפויה — נמדד 83, 86 ו-84 דקות על שלוש ההודעות הכפולות, לעומת אפס דקות על הודעה אחרת באותו יום. (6) הודעות הבוט נשלחות כציטוט של ההודעה שהן עונות לה, וכך הן נראות ב-WhatsApp בטלפון — אבל בממשק ה-inbox הן הופיעו כבועה חשופה בלי הקשר. הנתיב ששומר הודעות יוצאות דרך ה-API היה היחיד שלא קרא את מזהה ההודעה המצוטטת. תוקן, באותה צורה שנתיב הטלפון כבר עשה.

תכונה חדשה שמחליפה את סבב הבוקר הידני בקבוצות השירות ('בוקר טוב, יש איסוף היום?'). בדף הלקוח נוסף כרטיס 'תיאום איסוף יומי': מתג הפעלה, טלפון ייעודי לבירור האיסוף ובורר קבוצת וואטסאפ לקבלת התשובות. כל בוקר ב-08:00 נשלחת ללקוחות שהתכונה פעילה אצלם שאלת תיאום בוואטסאפ — תבנית Meta מאושרת עם כפתורי 'כן'/'לא' (נשלח דרך ה-API הרשמי של Meta, שתומך בכפתורים ואינו תלוי בחלון 24 השעות). כשהלקוח עונה: 'כן' — נשלחת לקבוצת הוואטסאפ שנבחרה (דרך Green API) הודעה 'ללקוח X יש איסוף היום'; 'לא' — 'ללקוח X אין איסוף היום'; תשובה מורכבת יותר (למשל 'לא לאסוף לפני 16:00' או 'אין איסופים בשבועיים הקרובים') מועברת לקבוצה כלשונה — 'הלקוח X כתב: …'. הלקוח מקבל אישור קצר ונעים על כל תשובה, ותשובת המשך באותו יום (למשל 'כן' ואז 'רק אחרי 16:00') מגיעה גם היא לקבוצה. נוסף עמוד 'תיאום איסופים' בתפריט המשלוחים: כרטיסי סיכום (יש איסוף / אין / תשובה אחרת / ממתינים / נכשל / לא נשלח) וטבלה עם תשובת כל לקוח, שעות שליחה ומענה וסטטוס ההעברה לקבוצה. הטבלה מתאפסת כל בוקר ב-08:00 (תשובה שמגיעה ב-07:30 עדיין משויכת לשאלה של אתמול), וניתן לדפדף לימים קודמים. אפשר גם לשלוח את שאלת הבוקר ידנית לכולם או ללקוח בודד ('שלח שאלה מחדש' על שורה שנכשלה). בעמוד תבניות Meta נוסף סימון 'תבנית תיאום איסוף יומי' (תבנית אחת בלבד), עם תמיכה במשתנה {{customer_name}} לפנייה אישית. השאלה לא נשלחת בשבת ומכבדת את חלון שעות השליחה של החברה.

• כרטיס חדש בדף הלקוח: מתג הפעלה, טלפון ייעודי לבירור ובורר קבוצת וואטסאפ לתשובות
• שאלת בוקר אוטומטית ב-08:00 בתבנית Meta עם כפתורי כן/לא — ללא תלות בחלון 24 השעות
• תשובת הלקוח מועברת אוטומטית לקבוצה: יש/אין איסוף, ותשובה מורכבת עוברת כלשונה
• עמוד 'תיאום איסופים' חדש עם כרטיסי סיכום וטבלה שמתאפסת כל בוקר, כולל דפדוף להיסטוריה
• שליחה ידנית לכולם או ללקוח בודד, וסימון תבנית ייעודית בעמוד תבניות Meta
• הגדרות תזמון בדף תיאום האיסופים: בחירת ימי שליחה ושעת שליחה (06:00–11:30) פר-חברה — שעת השליחה קובעת גם את רגע איפוס הטבלה

המשך הניתוח המשותף של דיווחי כשלי הבוט, הפעם עם מדידה על נתוני פרודקשן לפני כל שינוי — ושתי מדידות הפריכו את התיקון שתכננו. (1) תרחיש חדש: שליח שכותב בקבוצתו 'כתובת?' / 'מי הלקוח?' / 'טלפון של הנמען' מקבל את פרטי המשלוח מהמערכת, באותו בלוק שכבר נשלח היום לקבוצות. עונה רק על משלוחים המשויכים לאותו שליח או לשליחי המשנה שלו; אם לא ברור על איזה משלוח מדובר — שותק. כבוי כברירת מחדל. (2) לקוח שעונה לשאלת הבוט קיבל עד היום שתיקה; מעכשיו, אחרי שההנחיה שלו מועברת בפועל לשליח, נשלח לו 'קיבלנו, העברנו לשליח שמטפל ✅'. האישור נשלח פעם אחת בלבד גם כשהודעה אחת עונה על כמה משלוחים, ולעולם לא נשלח אם ההעברה לשליח נכשלה. (3) תיקון בטיחות: השער שהוסף אתמול ('לא עולה לי בחיפוש מספר משלוח X') קרא גם את שורת ה-OCR שהמערכת עצמה מזריקה מצילום מדבקה. מדידה: מתוך 354 קריאות OCR, 88 אינן מספר משלוח כלל (טלפון, משקל, מחיר) — ו-14 הודעות אמיתיות היו גורמות לבוט להכריז בקבוצה שמשלוח לא קיים, על מספר שאיש לא הקליד. השער קורא מעתה רק את מה שבני אדם כתבו. (4) סגירת וקטור פרטיות: קבלן שנקב בברקוד של קבלן אחר גרם לבוט לפנות ללקוח של אותו משלוח ולהחזיר את תשובתו — לרוב כתובת או טלפון של נמען זר — לקבוצת הקבלן ששאל. מעתה מספר משלוח מפורש חייב להיות משויך לשואל, לשליחי המשנה שלו, או לאיש. מספר ששייך לקבלן אחר נחשב רעש (רוב המקרים הם שגיאות OCR של המדבקה של השואל עצמו) ולא מבטל את הדיווח.

• תרחיש חדש "בקשת פרטי משלוח" — כבוי כברירת מחדל, מוגבל לקבוצות שליחים, ועונה רק על משלוחים המשויכים לשואל
• אישור אוטומטי ללקוח לאחר שההנחיה שלו הועברה לשליח — פעם אחת להודעה, ורק אם ההעברה הצליחה
• הבוט לא יכריז יותר שמשלוח לא קיים על סמך מספר שה-OCR קרא מצילום מדבקה
• ברקוד מפורש חייב להיות של השואל — נסגר וקטור שבו פרטי נמען של לקוח אחד הוחזרו לקבוצת קבלן זר

בדף יעד שבת הטבלה הייתה מתאפסת כל כמה שניות: למשך כשנייה וחצי הוצג 'לא נמצאו משלוחים' ואז המידע חזר. הסיבה: הדף מרענן את עצמו ברקע בכל אירוע עדכון משלוח (SSE), וביום עמוס לפני שבת אירועי הסטטוס מגיעים כמה פעמים בשנייה — מה שחרג ממגבלת הקצב של /api/shipments (60 בקשות לדקה) והחזיר 429. הרענון הברקעי החליף אז את שורות הטבלה במערך ריק. תוקן בשניים: (1) רענון ברקע שנכשל (כולל 429) כבר לא דורס את השורות המוצגות — הנתונים נשמרים עד שהרענון מצליח; (2) רענוני ה-SSE מקובצים ומוגבלים לאחד לכל 4 שניות לכל היותר, כדי לא לחרוג ממגבלת הקצב מלכתחילה.

בכרטיסיית 'זיהוי וסטטוס' שבדף המשלוח, אייקון העתקת הברקוד (שהיה מיותר) הוחלף בכפתור 'שכפל משלוח'. לחיצה עליו פותחת דיאלוג אישור שמסביר שייווצר משלוח חדש עם אותם הפרטים וברקוד חדש. לאחר האישור מוצג טוסט מתמשך (שנשאר עד שסוגרים אותו) עם שתי פעולות: הדפסת מדבקה של המשלוח החדש, או מעבר לדף המשלוח החדש. במקום אייקון ההעתקה — כעת לחיצה על הברקוד עצמו מעתיקה אותו ללוח. הפעולה מוצגת רק למי שיש לו הרשאת יצירת משלוחים, ומשתמשת ב-endpoint השכפול הקיים. בנוסף, בשורת הליקוט שבכרטיסיית התפעול נוסף אייקון פריטים (כמו בטבלת הליקוט /picking) — בריחוף עליו נפתח פירוט מלא של הפריטים לליקוט: שם הפריט, כמות ותכונות-שורה (meta). מוצג בכל משלוח שיש לו פריטים, גם למי שאין לו הרשאת עריכה (עורך הפרשות של עלוני-שבת נשאר כפי שהיה). תיקונים בשכפול: (1) השכפול מעתיק כעת גם את הפריטים לליקוט למשלוח החדש (קודם המשלוח המשוכפל נוצר בלי פריטים); (2) בהיסטוריית הפעולות של משלוח המקור נרשמת כעת פעולת 'שכפול' עם ברקוד המשלוח החדש — כך אפשר לאתר מהמקור את העותק. (במשלוח החדש כבר הופיע 'נוצר כשכפול ממשלוח X'.)

לטבלת תזרים המזומנים (/finance/cash-flow) נוספה עמודה 'לתשלום (מחושב)' — נעולה לעריכה — שמציגה את הסכום היוצא בחודש עבור כל שליח או קבלן. התזרים מחושב לפי *מה שיוצא בחודש*: תזרים יולי, למשל, הוא בעיקר התשלומים עבור עבודת יוני (ולשליח בשוטף+35 — עבור מאי), נגזר מתנאי התשלום של כל שליח. בכל טעינת עמוד מתבצע סנכרון אוטומטי (לפי מחירון/עמלות + התאמות, מע"מ לפי אופן התשלום). שכירים על משכורת (ללא מחירון) אינם נכללים. הסנכרון idempotent — לא מרנדר מחדש כשאין שינוי — ומואץ ע"י סינון-מוקדם של שליחים פעילים והרצה מקבילית מבוקרת.

• עמודה נעולה 'לתשלום (מחושב)' — הסכום לתשלום לכל שליח/קבלן, לא ניתן לעריכה ידנית
• סנכרון אוטומטי בכל טעינת עמוד (כמו טבלת טעויות המיון) — שורה פר-שליח נוצרת/מתעדכנת לפי העבודה בחודש
• כרטיס סיכום חדש 'לתשלום (מחושב)' לצד שאר סיכומי התזרים
• יעיל: סינון-מוקדם של שליחים פעילים בחודש + חישוב מקבילי מבוקר (מ-~77ש' ל-~10ש')
• כפתור 'סנכרון' ידני בבר הכלים (עם אנימציית טעינה) בנוסף לסנכרון האוטומטי בטעינת הדף
• הטבלה תופסת את מלוא גובה הדף (כמו שאר הטבלאות) במקום גובה קבוע
• מעבר בין חודשים מרענן את תוכן הטבלה, והסכומים המחושבים מוצגים מיד עם סיום הסנכרון
• הגדרות שליח/קבלן: 'יום תשלום בחודש' הוחלף ב'תנאי תשלום — שוטף + N' (ערכים קיימים נשמרו: 15 = שוטף+15). תאריך היעד בתזרים מחושב כסוף חודש העבודה + N
• הגדרות שליח/קבלן: שדה 'אופן תשלום' חדש (חשבונית מס / קבלה / תלוש שכר / מזומן) — הוא שקובע אם מתווסף 18% מע"מ בתזרים (במקום להיגזר מסוג השליח). לשליחים ללא הגדרה נשמרת ההתנהגות הקודמת
• ייחוס חודשים מתוקן: התזרים של חודש מייצג את התשלומים היוצאים בו — כלומר עבודה מחודשים קודמים לפי תנאי השוטף של כל שליח (יולי = יוני בד"כ, שוטף+35 = מאי)
• מצב טעינה יפה בזמן סנכרון, ומצב 'אין נתונים' ידידותי (עם הוספת שורה ידנית) לחודש ריק — במקום טבלה ריקה ומתוחה
• תיקון כפילות: סאב-שליח לא מקבל עוד שורה נפרדת בתזרים — התשלום שלו כבר כלול בסכום של המנהל (שמשלם לו). שורות סאב שגויות שנוצרו נמחקות בסנכרון
• הטבלה ממוינת כברירת מחדל לפי תאריך היעד לתשלום (הקרוב ביותר ראשון)
• כפתור מילוי אוטומטי בכותרת 'סכום כולל מע"מ' — ממלא את התאים הריקים מעמודת הסכום המחושב בלחיצה אחת

לקוח שאל 'מה הצפי למשלוח 25880144?' והבוט שתק, כי המספר לא קיים במערכת באף מזהה. מעכשיו, בכל התרחישים, כשמישהו נוקב במספר משלוח שלא נמצא — הבוט משיב 'לא עולה לי בחיפוש מספר משלוח X'. הדגש הוא על דיוק: הבוט לעולם לא יגיב כך על מספר טלפון, סכום כסף, ת.ז. או מזהה שידור. שער חדש (isConfidentShipmentNumber) דורש שלושה תנאים במצטבר: (1) צורת ברקוד אמיתית — בדיוק 8 ספרות שמתחילות ב-1 או 2, כפי שנמדד על 195,935 מתוך 195,942 הברקודים החיים (אף ברקוד לא נראה כמו טלפון ישראלי); (2) המספר הוא רצף ספרות עצמאי ולא תת-מחרוזת של מספר ארוך יותר — קריטי, כי טלפון קווי כמו 021234567 מכיל את 21234567 שהיא צורת ברקוד תקינה לחלוטין; (3) אין מילת כסף או אחוז צמודה למספר. בכל ספק — הבוט שותק כמו קודם. השער מכוסה בטסטים (טלפונים ניידים וקוויים, ת.ז., סכומים, שנים, מזהי שידור), ובקשות שידור ממשיכות להשתמש בתשובת 'לא נמצא' העשירה שלהן.

המשך ניתוח דיווחי הכשל. (1) האישור ('🔎 בודק מול השליח…') הוחזק עד שה-webhook של Green API מאשר שהשאלה נמסרה. מדידה על 111 גישורים אמיתיים: 80% מתפרסמים תוך שתי דקות, אבל 17 באיחור של 10+ דקות ו-8 מעל שעה — ואף גישור לא נשאר בלי אישור בסופו של דבר. כלומר ההחזקה מעולם לא מנעה אישור, רק איחרה אותו. שתי תוצאות רעות: קבלן שדיווח 'אין מענה' חשב שהבוט מתעלם ממנו (26 דק' שתיקה), ובמקרה אחר האישור נחת 72 דקות אחרי שהתשובה כבר הועברה — ונקרא כאילו הבוט בודק שוב מהתחלה. התיקון: אישור לעולם לא מתפרסם על גישור שכבר נענה, וקרון חדש (כל שתי דקות) מפרסם אישור שממתין מעל 90 שניות גם בלי אישור מסירה. סטטוס 'failed' עדיין חוסם אותו. (2) לקוחות כמעט לא כותבים 'מתי'; הם כותבים 'מה עם 25983110?' או 'הלקוח לא קיבל, מה קורה???'. אלה סווגו כ-none והבוט שתק אף שהמשלוח היה מזוהה. נוספו ביטויי טריגר: 'מה עם', 'מה קורה עם', 'לא קיבל', 'עדיין לא הגיע', 'לא הגיע', 'איפה המשלוח', 'איפה החבילה'. בטוח: תרחיש הצפי דורש ברקוד מפורש שמאומת שהוא באמת בטקסט, ומחפש רק בין משלוחי אותו לקוח — ביטוי לבדו לא יכול לגרום לניחוש משלוח.

נוסף לכל שליח שדה 'יום תשלום בחודש' (1–31) בטופס ההוספה/עריכה — למשל שליחים שמקבלים ב-10, ב-15 או ב-25 לחודש. הערך נשמר על רשומת השליח, מוצג בכרטיס פרטי השליח, ומהווה בסיס לחישובי תזרים המזומנים.

מניתוח דיווחי הכשל: (1) הבוט העביר לקבלן 'עדכון מהשולח: זה' — מילה חסרת משמעות. הסיבה: שער הרלוונטיות (Haiku) החזיר 'unknown' (או טעה), והמנוע נפל אחורה והעביר בכל זאת; ההגנה היחידה בצד ה-handler הייתה 'אורך ≥ 2 תווים'. מעכשיו רק verdict 'yes' ודאי מעביר — 'unknown' משאיר את הגישור פתוח ושותק (נרשם בלוג ההחלטות). כמו כן חודד הפרומפט של השער: מילת מילוי/כינוי רומז ('זה', 'אוקיי', 'בסדר'), או תשובה שלא ניתן להבין ממנה מה לעשות בלי לקרוא את השאלה — נדחות. (2) הבוט שאל את הלקוח שתי שאלות כן/לא בהודעה אחת ('יש טלפון נוסף?' + 'יש אישור להשאיר ליד הדלת?'), הלקוח ענה 'כן', והבוט העביר לשליח 'עדכון מהשולח: כן' — שליח אחד הבין 'להחזיר למחסן'. התבנית שוכתבה לשאלה פתוחה אחת ('מה ההנחיה שלכם למסירה?') עם דוגמאות ניסוח, כך שכל תשובה עומדת בפני עצמה גם אחרי שהיא מועברת כלשונה. שני התיקונים משלימים: 'כן' כבר לא עונה על שאלה פתוחה, ולכן השער ידחה אותו וישתוק.

דף הסטטיסטיקות של הצ׳אט העסקי אורגן מחדש ל-4 טאבים והורחב משמעותית. סקירה: כרטיסי KPI עם השוואה לתקופה קודמת (▲/▼), הגרף היומי ופילוח המשתמשים. AI: שיעור הכלה (שיחות לקוח שנסגרו ללא נציג), עלות אוטומציית ה-AI בש״ח (ממדידת AiUsageEvent), מסלול פעולות שהבוט הציע (בוצע/נדחה/ממתין), מסלול גישורים (Relay), ופעילות מפורטת לפי תרחיש (מתוך registry התרחישים). עומס: מפת חום שעה×יום, פילוח לפי קהל (קבוצות לקוחות מול קבוצות שליחים מול צ׳אטים אישיים — לפי קישור chatId ל-Customer/Driver), וזמן תגובה כ-SLA (עד 5 דק׳/30/60/מעל שעה). איכות: התיישנות ההודעות הממתינות (עד שעה/1-4/4-24/מעל יממה), שיעור כשלי AI ל-1000 הודעות עם דיווחים פתוחים אחרונים, וצ׳אטים עמוסים. נוספו טווח תאריכים מותאם, ייצוא לאקסל (RTL, רב-גיליונות), ו-deep-link מכשלים/צ׳אטים ישירות לשיחה בתיבה.

• 4 טאבים: סקירה / AI / עומס / איכות
• ROI של ה-AI: שיעור הכלה, עלות אוטומציה בש״ח, מסלולי פעולות וגישורים, ופילוח לפי תרחיש
• עומס: מפת חום שעה×יום, פילוח קבוצות לקוחות מול שליחים, וזמן תגובה כ-SLA
• איכות: התיישנות ממתינות למענה, שיעור כשלים ל-1000 הודעות, וצ׳אטים עמוסים
• השוואה לתקופה קודמת (▲/▼) על כרטיסי ה-KPI
• טווח תאריכים מותאם, ייצוא לאקסל (רב-גיליונות, RTL), ו-deep-link לשיחה בתיבה (?chat=)

דיווחי הכשל של הבוט הם מעכשיו 'כתיבה בלבד' מצד הטננט: הצוות מדווח מתיבת העסק (קליק ימני על הודעה → 'דווח על כשל בוט'), אבל הרשימה כבר לא מוצגת בטננט. הסקירה והתיקון מרוכזים בקונטרול פאנל של הפלטפורמה — /admin/bot-failures ('כשלי בוט' בסיידבר) — עם רשימה חוצת-טננטים, תג של שם הטננט לכל דיווח, סינון לפי סטטוס וספירות, וסימון נסקר/טופל/נדחה. לחיצה על 'פתח בצ׳אט' לא מנווטת יותר לדף הצ'אטים (שממילא לא אפשרי חוצה-טננט), אלא פותחת מודל עם תמליל השיחה — 25 הודעות לפני ואחרי — גלול אוטומטית להודעה המדווחת, שמסומנת בהדגשה. כל נקודות הקצה של האדמין מוגנות ב-requirePlatformRole.

• רשימת כשלי הבוט מכל הטננטים במקום אחד: /admin/bot-failures
• 'פתח בצ׳אט' פותח מודל עם תמליל השיחה, גלול להודעה המדווחת ומסומן עליה
• תג טננט לכל דיווח + סינון לפי סטטוס וספירות, וסימון נסקר / טופל / נדחה
• בטננט נשאר רק הדיווח עצמו (כתיבה בלבד) — דף הסקירה הוסר משם

שלושה המשכים לתקלת תור השליחה. (1) אישור ההתראה הלא-נכונה: ה-webhook חיפש את ההודעה שעליה הגיבו לפי messageId, וכשלא מצא — נפל ל'ההתראה הלא-מאושרת האחרונה בצ'אט'. מכיוון שה-cron מחליף את messageId בכל חזרה, 👍 שהגיע אחרי חזרה לא התאים לכלום ואישר התראה אקראית: שגיאת מיון לא-קשורה סומנה RESOLVED, בעוד זו שהנציג באמת טיפל בה המשיכה לנדנד. מעכשיו כל התראה שומרת messageIds[] — כל מזהי ההודעות שתחתיהם נשלחה (נזרע ביצירה, מתווסף בכל חזרה, ומולא רטרואקטיבית ל-498 הרשומות הקיימות); ה-webhook מתאים מול הרשימה, ונפילת-הניחוש-לפי-צ'אט הוסרה. (2) 👍 שנציג מסמן מטלפון העסק לא אישר כלום — ענף התגובות יושב מתחת לבדיקת incomingMessageReceived, כך שתגובות יוצאות נזרקו; עכשיו הנתיב היוצא מריץ את אותו אישור, וגם סקר ה-getChatHistory של ה-cron בודק את כל העותקים ולא רק את האחרון. (3) לא היה שום ניטור על עומק תור השליחה — green-api-health בדק רק את מצב ה-instance, ולכן ההצפה לא זוהתה במשך ימים; עכשיו הוא מתעד את עומק התור בכל ריצה ומתריע למנהל מעל סף, עם throttle של פעם בשעה לטננט (ההתראה עצמה היא הודעת וואטסאפ שממתינה בתור שעליו היא מדווחת).

שני מסכי ההתחברות הציגו את קוד השגיאה הפנימי של NextAuth כמות שהוא. מכיוון ש-authorize() זורק שגיאה, @auth/core עוטף אותה ב-CallbackRouteError שאינו client-safe וממיר אותה למחרוזת 'Configuration' — כך שכל התחברות שנכשלת (סיסמה שגויה, חשבון לא פעיל, או משתמש פורטל שמנסה להיכנס למערכת הניהול) הציגה למשתמש 'Configuration' באנגלית, וההודעות העבריות ב-authorize מעולם לא הגיעו אליו. נוסף helper משותף שממפה את קודי NextAuth לעברית, והקוד הגולמי נרשם לקונסולה בלבד. בנוסף, בדף ההתחברות של הצוות נוסף קישור 'לקוח? כניסה לפורטל הלקוחות' — לקוחות הגיעו לדף הלא נכון ונתקעו בלי רמז.

כשנציגה השיבה בקבוצה על הודעה מסוימת (swipe-to-reply) מהטלפון שלה, ההודעה הופיעה בתיבה כבועה בודדת בלי בלוק הציטוט — כלומר בלי ההקשר של מה היא ענתה עליו. הסיבה: Green API שולח את התשובה כ-webhook יוצא מסוג quotedMessage עם quotedMessage.stanzaId של ההודעה המצוטטת, אבל handleOutgoingPhoneMessage שמר רק את הטקסט והתעלם מה-stanzaId. הנתיב הנכנס כבר עשה זאת נכון — ומכאן חוסר הסימטריה: בפרודקשן נמצאו 1,070 הודעות נכנסות עם ציטוט שנפתר כראוי, מול 1,238 הודעות נציג מהטלפון שמתוכן 0 נשאו ציטוט אי-פעם. התיקון: הנתיב היוצא מפענח עכשיו את ה-stanzaId מול ה-externalId של ההודעות שלנו באותה שיחה ומקשר replyToId, בדיוק כמו הנתיב הנכנס. אם ההודעה המצוטטת אינה מאוחסנת אצלנו (קדמה לנו) — ההודעה פשוט מוצגת בלי ציטוט, ללא שגיאה. התיקון חל קדימה בלבד; הודעות היסטוריות לא ניתנות לשחזור כי ה-stanzaId שלהן מעולם לא נשמר.

תגובות (reactions) של משתתפי הצ'אט כבר הוצגו נכון בתיבה — צ'יפ לכל אימוג'י מתחת לבועה, עם מונה ורשימת המגיבים בריחוף (547 הודעות נושאות תגובות בפרודקשן). אבל תגובה שנציג שלנו מסמן מ*טלפון העסק* דלפה: היא מגיעה כ-webhook יוצא מסוג reactionMessage, ו-handleOutgoingPhoneMessage לא סינן את הסוג הזה — extractOutgoingText קורא את אותו שדה (extendedTextMessageData.text) שבתגובה מכיל את האימוג'י עצמו, ולכן נשמרה בועת הודעה בודדת של '👍' במקום צ'יפ תגובה על ההודעה המקורית. בפרודקשן נמצאו 36 בועות '👍' ו-2 של '🙏' מסוג source=phone ב-30 הימים האחרונים. התיקון: הנתיב היוצא מזהה reactionMessage ומצמיד את האימוג'י להודעת היעד (לפי stanzaId ↔ externalId) בדיוק כמו בנתיב הנכנס; אימוג'י ריק = הסרת התגובה.

כשליונוויל מחזירה שגיאה ביצירת משלוח, הלוג רשם רק את הסטטוס ו-500 התווים הראשונים של התשובה — שהם דף שגיאת HTML של Rails, כלומר CSS בלבד. את המטען ששלחנו לא רשמנו כלל, ולכן כשל שתלוי במטען ספציפי (נמען אחד נכשל שוב ושוב בעוד כל שאר המשלוחים באותה דקה עוברים) לא היה ניתן לאבחון מהלוגים. מעכשיו נרשם המטען המלא שנשלח ל-/tasks/create, ודף ה-HTML מסוכם לכותרת ולהודעת השגיאה במקום להיחתך באמצע ה-CSS. תגובות JSON נשארות כפי שהן.

נציגים דיווחו שהודעות שנשלחו מתיבת העסק הגיעו ליעד רק אחרי חצי שעה ויותר (ונשארו עם ✓ בודד), בעוד שהודעות נכנסות הגיעו מיד. הסיבה: Green API מחזיר 200 ברגע שההודעה נכנסת ל*תור היוצא* שלו (לא כששלח בפועל) — ולכן ✓ בודד פירושו 'ממתינה בתור'. את התור הציף ה-cron של התראות שגיאת-מיון: התזמון ב-vercel.json הוא כל 5 דקות, אך תנאי החזרה בקוד היה 4 דקות בלבד — כך שכל התראה שלא אושרה נשלחה מחדש בכל ריצה, ללא תקרת חזרות, עד ~96 פעמים לאורך חלון 8 השעות. בפרודקשן נמצאו 145 התראות לא-מאושרות (עד 96 חזרות כל אחת, בגיל של עד 10 ימים), כולן לאותה קבוצה — כ-180 הודעות בשעה שחסמו את התור המשותף, וההודעות האינטראקטיביות של הנציגים המתינו מאחוריהן. התיקון: backoff מדורג בין חזרות (10 → 20 → 40 → 60 → 120 דקות) ותקרה קשיחה של 5 חזרות, כך שהתראה שלא אושרה עולה לכל היותר 6 הודעות (במקום 97) ופרושה על ~4 שעות. בנוסף, בדיקת האישור היקרה (getChatHistory לכל התראה) רצה מעכשיו רק על התראות שבאמת מגיע להן לחזור. הלולאות הפעילות נעצרו ידנית בפרודקשן.

עד היום איפוס סיסמה לפורטל הלקוחות היה זמין רק ביוזמת הלקוח עצמו ורק דרך מייל, והטוקן מעולם לא נחשף לצד הטננט. כשהמייל לא הגיע — או שהלקוח הקליד כתובת שגויה, והמסך מציג 'נשלח' גם כשלא נמצא משתמש כדי למנוע חשיפת כתובות — לא הייתה לצוות שום דרך לעזור: הכפתורים הקיימים הוגבלו למשתמש 'ממתין' (קישור הזמנה) או לחשבון בעלים בלבד (איפוס חשבון). מעכשיו לכל משתמש פורטל פעיל יש בכרטיס הלקוח כפתור 'צור קישור איפוס סיסמה' — נוצר קישור, מוצג להעתקה ידנית (לשליחה בוואטסאפ), וגם נשלח במייל. הפעולה אינה הרסנית: הסיסמה הקיימת ממשיכה לעבוד עד שהקישור ינוצל.

• כפתור 'צור קישור איפוס סיסמה' על כל משתמש פורטל בסטטוס פעיל, בסקציית 'משתמשי פורטל הלקוח'
• הקישור מוצג להעתקה בדיאלוג וגם נשלח במקביל למייל — עובד גם כשהמייל לא מגיע
• תוקף 24 שעות (לעומת 60 דקות באיפוס העצמי), כי הקישור מועבר ידנית; טקסט המייל מציג את התוקף הנכון
• פעולה לא הרסנית — הסיסמה הקיימת תקפה עד לניצול הקישור; ניצול הקישור גם משחרר חשבון נעול
• route חדש מאובטח בהרשאת CUSTOMERS_EDIT, מוגבל למשתמשי הטננט הנוכחי בלבד

נוסף דף סטטיסטיקות ייעודי לצ׳אט הלקוחות העסקיים (מסרונים ← לקוחות עסקיים ← סטטיסטיקות עסקי). במרכזו גרף עמודות יומי — כל עמודה היא כמות ההודעות שנשלחו באותו יום, מפולחת לפי שולח: הבוט, לקוחות/משתמשי וואטסאפ, ומשתמשי המערכת (הצוות) — עם פילוח פנימי פר-משתמש. אפשר לעבור בין תצוגת כמות לתצוגת אחוזים (עמודות מנורמלות ל-100%) ובין טווח שבוע (ברירת מחדל), חודש או 3 חודשים. הסיווג מדויק ומשקף את לוגיקת התיבה עצמה: הודעות assistant=בוט, staff=מערכת, ו-user מפולח לצוות מול לקוח חיצוני לפי התאמת מספר הטלפון למשתמשי הטננט; הודעות פנימיות אינן נספרות כ׳נשלחו׳. בנוסף מוצגים: אחוז מענה אוטומטי, שיחות הממתינות למענה כרגע, דיווחי כשל של הבוט בתקופה, פילוח משתמשי המערכת, זמן תגובה חציוני/ממוצע להודעה נכנסת, תמונת החלטות הבוט (פעל/זיהה-ללא-פעולה/שתק) וסטטוס הטיפול הנוכחי.

• גרף עמודות יומי מוערם לפי שולח (AI / לקוחות וואטסאפ / צוות), עם tooltip הכולל ספירה, אחוזים ופילוח צוות יומי
• מעבר בין תצוגת כמות לאחוזים (100%) ובין טווח שבוע/חודש/3 חודשים
• פילוח הודעות פר-משתמש מערכת — מאחד נציג ששולח מהמערכת ומוואטסאפ תחת אותו משתמש
• כרטיסי KPI: סה"כ הודעות, אחוז מענה אוטומטי, ממתינות למענה, ודיווחי כשל של ה-AI
• מדדי בונוס: זמן תגובה חציוני/ממוצע, החלטות ה-AI וסטטוס טיפול נוכחי
• API חדש GET /api/ai/business-chat/stats מגודר בהרשאת messages:view
• תיקון סיווג ה-AI: הודעות תרחישי הבוט האוטומטיות נשמרות כ-role=staff/source=trigger (לא assistant) ולכן נספרו קודם כ׳צוות׳ — כעת קטגוריית ה-AI = assistant + trigger, והקטגוריה שונתה מ׳בוט׳ ל׳AI׳

עד כה דוח העמלות החודשי של הסוכן היה גלוי רק למנהלים בדף הסוכן. כעת הטננט יכול לפתוח זאת פר-סוכן: מתג חדש בטופס הסוכן ('צפייה בדוח העמלות שלו', כבוי כברירת מחדל) חושף לסוכן את דוח העמלות החודשי שלו ישירות בדשבורד הסוכן — כולל ניווט בין חודשים, פירוט לפי רכיב (מרווח, קבוע למשלוח, אחוז מהדוח, בונוס, עלויות, התאמות) וייצוא לאקסל. הגישה מוגבלת אך ורק לנתוני הסוכן עצמו — ה-agentId נגזר מה-session ולעולם לא מפרמטרים של הלקוח — ומצב המתג נקרא טרי בכל בקשה, כך שכיבויו מבטל את הגישה מיד. מנוע החישוב וייצוא ה-Excel משותפים עם המסלול הניהולי הקיים.

• מתג 'צפייה בדוח העמלות שלו' בטופס הסוכן — פר-סוכן, כבוי כברירת מחדל, נראה רק למנהלים
• כרטיס 'דוח העמלות שלי' בדשבורד הסוכן: ניווט חודשים, פירוט מלא וייצוא לאקסל
• מסלול עצמי מוגן /api/agent/earnings (+/export) — agentId מה-session בלבד ומותנה ב-selfEarningsVisible
• מנוע הדוח וייצוא ה-Excel חולצו ל-lib משותף (agent-earnings-export) בשימוש שני המסלולים
• תיקון גלילה בדשבורד הסוכן — הדף לא גלל (root ללא overflow-y-auto), כך שדוח העמלות נחתך בתחתית; הוגדר אזור גלילה תקין
• צמצום רווח הקצוות בדשבורד הסוכן ל-8px (p-6→p-2) ורווח בין הסקציות ל-16px — פחות מרווח מבוזבז

דף 'היסטוריה' תחת מסרונים — טבלת כל ההודעות שנשלחו למשלוחים — הוסר כיוון שהיה מיותר. הכניסה מהתפריט הצידי הוסרה, וקישור השורש /messages מפנה כעת לתיבת הנכנסות (/messages/inbox). נמחקו גם ה-API route הייעודי (/api/messages), פעולת השליחה-מחדש והרכיבים שהיו בשימוש בלעדי של הדף. שאר תתי-הדפים של מסרונים (נכנסות, לקוחות עסקיים, תבניות Meta, טריגרים, העדפות שליחה, עלויות) נותרו ללא שינוי.

כל מחיקת משלוח (העברה לסל מיחזור) מציגה באישור צ'קבוקס חדש 'בטל את המשלוחים גם בליונוויל' (כבוי כברירת מחדל). בסימון — המשימות המשויכות עוברות לסטטוס 'מבוטל' בליונוויל (PUT status=4; לליונוויל אין endpoint למחיקה מוחלטת) כחלק מאותה פעולה. משלוחים שכבר נמסרו/הושלמו לא מושפעים לעולם — לא מבטלים משלוח שנמסר. הביטול best-effort עם הגבלת קונקרנטיות: כשל מול ליונוויל לא מונע את המחיקה אצלנו. מומש דרך שירות משותף (cancelLionwheelTasksForShipments) ודגל cancelLionwheel יחיד ב-endpoint המחיקה, ומחובר בכל מסכי המחיקה הראשיים.

• צ'קבוקס 'בטל בליונוויל' בכל אישורי המחיקה: טבלת המשלוחים (מרובה + שורה), עמוד המשלוח, ואיסופים (שורה + קבוצה)
• ביטול = PUT /tasks/{id}/update עם status=4; משלוחים שהושלמו/נמסרו מדולגים (לא מבטלים משלוח שנמסר)
• best-effort — כשל מול ליונוויל לא מבטל את המחיקה עצמה; קונקרנטיות מוגבלת (rate limit)
• שירות משותף + דגל יחיד ב-bulk-delete = נקודת מעבר אחת לכל מסכי המחיקה

סטטוס on-hold ב-WooCommerce פירושו 'ממתין לתשלום' (שיטות תשלום offline, או שער תשלום שמשאיר את ההזמנה פתוחה כשהקונה לא השלים תשלום). המערכת ייבאה ושיגרה אותן אוטומטית כאילו שולמו — כך נשלחו חבילות אמיתיות ללקוחות שרק ביקרו/עשו צ'קאאוט בלי לשלם. מעכשיו הזמנת on-hold מיובאת רק אם WooCommerce רשמה תשלום בפועל (date_paid) — מה שמכסה גם שער תשלום שמחזיק זמנית הזמנה ששולמה. processing/completed ממשיכים כרגיל (כולל הזמנות ₪0 חינם ללא date_paid). נוסף predicate טהור isOrderImportable עם בדיקות יחידה, ותוקן טקסט מטעה בעמוד חיבור החנות שהציג on-hold כ'התקבל תשלום'.

עד כה בייבוא הזמנות מווקומרס נשמרו רק שם הפריט, הכמות והמחיר — ומאפייני השורה שווקומרס מציג מתחת לפריט (כמו 'חוברת לנשים', 'חוברת לגברים', 'סה"כ חוברות') נזרקו במיפוי. כעת המאפיינים נקלטים מ-line_item meta_data של ההזמנה ומוצגים כשורת פירוט אפורה מתחת לשם הפריט ב'פריטי המשלוח' — בדיוק כפי שהם מופיעים במסך ההזמנה בווקומרס. מסוננים מאפייני meta פנימיים של ווקומרס (מפתחות שמתחילים ב-_) ומנוקה HTML מהערכים. נוסף גם סקריפט backfill שמושך מחדש הזמנות קיימות (שליפה מרוכזת דרך include=) ומשלים את הפירוט על משלוחים שכבר נכנסו.

• קליטת מאפייני שורה (meta_data) מהזמנות ווקומרס והצגתם מתחת לשם הפריט ב'פריטי המשלוח'
• עמודת meta חדשה ב-OrderItem — נשמרת בייבוא ונשמרת גם בעריכת פריטים ידנית
• סקריפט backfill למשלוחים קיימים, עם שליפה מרוכזת דרך include= (עוקף 401 בנתיב /orders/{id})
• endpoint אדמין מוגן להרצת ה-backfill בפרודקשן (שם ENCRYPTION_KEY זמין) — dry כברירת מחדל, ?run=1 להרצה בפועל
• הפירוט מוצג גם בעמודת הפריטים בטבלת הליקוט ובחלון משלוחי הלקוח — צ'יפ עם מונה פריטים שנפתח בריחוף לכרטיסיית פירוט (חוברות לנשים/לגברים/סה"כ)
• בדיקות יחידה לחילוץ המאפיינים (סינון meta פנימי, העדפת display_key/value, ניקוי HTML)

נוסף כפתור 'הוספת משלוחים' לסרגל הכלים של דף יעד אקספרס, שפותח חלון להגדרת יעד אקספרס לרשימת משלוחים לפי מספרי משלוח — בדיוק כמו שקיים בדף יעד שבת. מדביקים רשימת מספרים (כפילויות מוסרות אוטומטית), בוחרים תאריך יעד (צ'יפים מהירים להיום/מחר/הימים הקרובים או בורר תאריך חופשי), והמשלוחים מסומנים כאקספרס גם אם אינם מוצגים בטבלה כרגע. בסיום מוצג פירוט של מה עודכן ומה לא נמצא.

• כפתור 'הוספת משלוחים' + חלון ייעודי בדף יעד אקספרס
• הדבקת רשימת מספרי משלוח עם הסרת כפילויות אוטומטית
• בחירת תאריך יעד עם צ'יפים מהירים (היום/מחר/הימים הקרובים) ובורר תאריך
• עדכון מרוכז דרך endpoint חדש set-target-express-by-barcodes עם פירוט תוצאות

בחלון 'לינק הגדרת סיסמה' (כפתור לינק כניסה בדף השליח) מחרוזת ה-token הארוכה הרחיבה את תוכן החלון הרבה מעבר לרוחבו ומעבר לרוחב המסך — כך שגם קופסת הקישור וגם כפתור 'העתק קישור' נחתכו. ה-truncate הקיים לא נכנס לפעולה: DialogContent הוא display:grid, וה-div העוטף הוא grid-item עם min-width: auto — כלומר רוחב מינימלי לפי min-content, שהוא עצום בגלל ה-token ב-white-space: nowrap. נוסף min-w-0 לעוטף (וגם ל-flex-row ול-span שמציג את הקישור), כך שהתוכן מתכווץ והקישור מקוצר עם '...' בתוך גבולות החלון. אומת ברוחבי מסך 390px ו-900px.

הקו המערכתי שהוצג בתוך הצ'אטים ('חיבור ה-WhatsApp נותק ב-... · חזר ב-...') הוסר. הוא הופיע בכל שיחה בכל פעם שחיבור ה-Green API נותק וחזר — לרוב לרגעים בודדים — והוסיף רעש ויזואלי מיותר לתוך שרשור ההודעות. הוסר לחלוטין מהתצוגה (הקוד, ה-state והבאת הנתונים הנלווים נוקו).

תיוג רשמי של וואטסאפ בתוך הודעה (@מספר) הוצג עד עכשיו כמספר גולמי. מעכשיו הוא מזוהה ומוצג יפה: אם המספר שייך לאיש צוות מוכר — מוצג שמו במערכת לצד האווטר שלו (צ'יפ ירוק); אם זה משתתף קבוצה שהמערכת מכירה מהודעות שהוא שולח — מוצג שמו בדיוק כפי שהוא מוצג מעל ההודעות שלו (בצבע הדובר); ואם המספר לא מזוהה כלל — נשאר כ-@מספר פשוט. הזיהוי נעשה מהטקסט הגולמי של ההודעה (שכבר מכיל את @מספר) בשילוב מפת טלפוני הצוות ושמות המשתתפים של אותה שיחה — בלי שאילתות DB נוספות. חל על תיוגים רשמיים של וואטסאפ בלבד (לא על התיוג הפנימי שלנו בהערות צוות).

שורת הצ'יפים השטוחה הוחלפה בשני פילטרים נפתחים (pill-dropdown), שניהם מאותחלים על 'הכל': (1) 'סוג' — הכל / לקוחות / שליחים / קבלנים / אנשי צוות / לא משוייכים. (2) 'מצב' — חדש: הכל / לא נקראו / ממתינות לתשובה / בטיפול / טופל. 'ממתינות לתשובה' = ההודעה האחרונה בצ'אט היא מהצד השני ומחכים שנגיב — הפילטר התפעולי הכי שימושי. 'בטיפול'/'טופל' לפי סטטוס הטיפול המשותף של הצוות. צ'יפ 'תיוגים שלי' (אזכורים) נשאר כפי שהיה. שני הפילטרים פועלים בצד השרת, כך שכל התוצאות מוחזרות במלואן ומתדפדפות חלק (במקום 'לזחול' פנימה תוך כדי טעינת עמודים — לא-נקראו לבד הגיע ל-37 צ'אטים). כן בוטלה טבעת הפוקוס האגרסיבית שהופיעה על הפילטרים.

• שני פילטרים נפתחים ('סוג' + 'מצב') במקום שורת צ'יפים — נקי ומתרחב
• פילטר 'מצב' חדש: לא נקראו / ממתינות לתשובה / בטיפול / טופל
• 'ממתינות לתשובה' — צ'אטים שבהם הצד השני כתב אחרון ומחכים שנגיב
• 'בטיפול'/'טופל' לפי סטטוס הטיפול המשותף של הצוות
• הסינון בצד השרת — כל התוצאות במלואן, ללא 'קפיצות' של תוצאות שנוספות תוך כדי גלילה
• בוטלה טבעת הפוקוס על הפילטרים; צ'יפ 'תיוגים שלי' נשמר

כשלקוח שלח רשימת מספרי משלוח לבירור (למשל '25570283 25570285 25570287…'), הם זוהו בטעות כמספרי טלפון: הזיהוי 'תפס' ספרת 0 שנמצאת באמצע ברקוד (…2557‹0›283…) ובלע ספרות נוספות מעבר לרווחים שבין הברקודים, כך שנוצרו 'מספרים' מומצאים עם קידומות/סיומות לא-קשורות, ולחיצה עליהם פתחה צ'אט דמיוני עם מספר שלא יכול להיות טלפון. תוקן בשניים: (1) זיהוי טלפון עכשיו דורש פורמט ישראלי תקין ומלא כטוקן עצמאי — קידומת (0 או +972), 'ראש' אמיתי (נייד 5X / VoIP 7X / קידומת קו-נייח 2,3,4,8,9), ואז מספר הספרות המדויק, עם גבולות שמונעים התחלה באמצע רצף ספרות של ברקוד. (2) ברקודים מזוהים עכשיו כברקוד ולחיצים: השרת סורק את ההודעות אחר טוקנים ברקוד-דמויי ומחזיר רק את אלה שהם משלוחים אמיתיים בטננט (אימות מול DB, בלי ניחוש פורמט ובלי דליפה בין-טננטית) — וכל ברקוד כזה מוצג כצ'יפ עם העתקה/פתיחה שפותח דראוור תצוגה-מהירה של המשלוח, בדיוק כמו ב-/messages/inbox.

צ'אט 1:1 עם מספר טלפון ששייך למשתמש מערכת (איש צוות) הציג עד עכשיו רק את המספר. מעכשיו הוא מציג את שם איש הצוות בדיוק כפי שהוא רשום במערכת (וגם את תמונת הפרופיל שלו כ-fallback), ברשימת השיחות ובכותרת הצ'אט. בנוסף, הקלדת שם איש הצוות בחיפוש מחזירה את הצ'אט שלו בתוצאות — הזיהוי לפי מפת טלפוני הצוות של הטננט (getTenantStaffPhoneMap), עם בניית מזהה השיחה הדטרמיניסטי (972<מספר>@c.us) לצד ההתאמה. חל רק על צ'אטים אישיים שאינם משויכים ללקוח עסקי; קבוצות וצ'אטים של לקוחות לא מושפעים. בנוסף נוסף צ'יפ סינון 'אנשי צוות' לצד 'הכל'/'לקוחות'/'שליחים'/'קבלנים'/'לא משויכים', שמציג רק את השיחות האישיות עם אנשי צוות; שיחות אלה גם הוצאו מקטגוריית 'לא משויכים' (כי כעת יש להן קטגוריה משלהן).

עד היום, כשנכנסת לשיחה בתיבת צ'אט הלקוחות העסקיים שהצטברו בה הודעות חדשות, לא היה שום סימן ויזואלי איפה נגמר מה שכבר קראת ואיפה מתחילות ההודעות החדשות — והצ'אט תמיד נפתח בתחתית, כך שהיית צריך לגלול למעלה ולנחש. מעכשיו, כמו בוואטסאפ האמיתי: לפני ההודעה הראשונה שלא נקראה מוצג קו מפריד ברור ('N הודעות שלא נקראו'), והצ'אט נפתח אוטומטית ממוקם בדיוק על הקו הזה — עם מעט הקשר מעליו — גם אם אחריו יש עשרות או מאות הודעות. מספר ההודעות שלא נקראו נלקח ממצב הקריאה האמיתי של השיחה (נתפס ברגע הפתיחה, לפני סימון-כנקרא), וההודעה הראשונה שלא נקראה מזוהה כ-N ההודעות הנכנסות האחרונות. הקו נשאר במקומו כל עוד השיחה פתוחה (הודעות חדשות שמגיעות לא מזיזות אותו) ומתאפס במעבר לשיחה אחרת. משתלב עם כפתור הגלילה-לתחתית ומונה ההודעות החדשות שנוספו קודם.

• קו מפריד 'N הודעות שלא נקראו' לפני ההודעה הראשונה שטרם נקראה (עיצוב ירוק, כמו וואטסאפ)
• פתיחת הצ'אט נוחתת אוטומטית על הקו — לא בתחתית — גם כשיש אחריו הרבה הודעות
• מבוסס על מצב הקריאה האמיתי של השיחה (unreadCount) שנתפס לפני סימון-כנקרא
• הקו יציב: הודעות חדשות שמגיעות תוך כדי לא מזיזות אותו; מתאפס במעבר שיחה
• פתיחה מחיפוש/דיפ-לינק להודעה ספציפית עדיין קופצת להודעה המבוקשת (גובר על הקו)

במקום לחפש ידנית כשלים של הבוט בקבוצות ולנתח כל אחד בנפרד — לולאת משוב מובנית. על כל הודעה בתיבת העסק (קליק ימני/לחיצה ארוכה) נוסף 'דווח על כשל בוט': הצוות מסמן תשובה לא ראויה של הבוט או הודעה שהבוט התעלם ממנה, ובחלונית מתאר למה זה נראה ככשל ומה הוא ממליץ לתקן. הדיווח נשמר עם snapshot של ההקשר (השיחה, ההודעה המסומנת, מי דיווח ומתי). כל כמה ימים עוברים על הדיווחים שהצטברו בדף ייעודי בהגדרות (AI → 'דיווחי כשל'): כל דיווח מציג את ההודעה, התיאור וההמלצה, ומאפשר לפתוח את השיחה עצמה בדיוק בהודעה המדווחת (עם ההודעות שלפני ואחרי) לצורך ניתוח, ולסמן סטטוס (נסקר/טופל/נדחה).

• כפתור 'דווח על כשל בוט' על כל הודעה בתיבת העסק — עובד גם על תשובה שגויה של הבוט וגם על הודעה שהבוט התעלם ממנה
• טופס קצר: 'למה נראה שכשל' + 'מה להמליץ לתקן' (רשות); נשמר עם הקשר מלא של השיחה וההודעה
• דף סקירה בהגדרות (AI → דיווחי כשל) עם סינון לפי סטטוס וספירות, לניתוח תקופתי מרוכז
• 'פתח בצ׳אט' בכל דיווח מקפיץ ישירות לשיחה ולהודעה המדווחת, עם ההקשר שלפני ואחרי
• סימון סטטוס לכל דיווח: נסקר / טופל / נדחה / החזרה לפתוח

עד היום החיפוש בתיבת צ'אט הלקוחות העסקיים החזיר רק את השיחה (לפי שם/טלפון), ואם ההתאמה הייתה בתוך גוף הודעה — השיחה נפתחה בתחתית, בלי לראות איפה בכלל נמצאה המילה. מעכשיו החיפוש עובד כמו בוואטסאפ האמיתי: התוצאות מחולקות לשתי סקציות — 'צ'אטים' (התאמות לפי שם/טלפון/כותרת) ו'הודעות' (התאמות בתוך תוכן ההודעות). כל הודעה תואמת מוצגת בשורה נפרדת עם קטע-טקסט (snippet) ממוקד סביב המילה, כשהמילה שחיפשת מודגשת, לצד שם הצ'אט וזמן ההודעה. לחיצה על תוצאה פותחת את הצ'אט וגוללת ישירות אל ההודעה עצמה — נחיתה מיידית סמוך אליה ואז גלילה חלקה וקצרה שעוצרת עליה, עם הבהוב הדגשה כדי שקל לאתר אותה. מבוסס על אינדקס pg_trgm הקיים על תוכן ההודעות.

• תוצאות חיפוש בשתי סקציות: 'צ'אטים' (שם/טלפון/כותרת) ו'הודעות' (תוכן) — כמו בוואטסאפ
• כל הודעה תואמת = שורה נפרדת עם snippet ממוקד והמילה המחופשת מודגשת
• לחיצה על תוצאת הודעה פותחת את הצ'אט וקופצת ישירות אל ההודעה, עם גלילה חלקה קצרה והבהוב הדגשה
• החיפוש בתוכן גלובלי על פני כל השיחות בתצוגה הנוכחית (תיבה/ארכיון); מוצגות עד 50 תוצאות הודעה
• endpoint חדש /api/ai/business-chat/messages/search; חיפוש ה'צ'אטים' צומצם לשם/טלפון/כותרת (התאמות תוכן עברו לסקציית ההודעות)

כשקבלן ביקש 'תשדרו' על משלוח שכבר היה משודר — הבוט השיב 'כבר היה משודר אליך' והפסיק, גם כשהמשלוח היה בכלל משובץ לקבלן אחר. התוצאה: הבוט 'שיקר' (זה לא היה משודר אליו), לא עשה כלום, ובן אדם נאלץ לשבץ ידנית (אירוע פרודקשן 07-07, קבוצת 'שלום דוד', משלוח 25548227 — הקבלנים אף לעגו לבוט). הסיבה: הבדיקה 'כבר משודר' הסתפקה בקיום מזהה שידור כלשהו, בלי לבדוק למי המשלוח משובץ. התיקון: 'כבר משודר אליך' חל מעכשיו רק כשהמשלוח באמת משובץ לקבלן המבקש (או לתת-שליח שלו). כשהוא משובץ לקבלן אחר ויש משימת מסירה פעילה — בקשת שידור מפורשת מפעילה שיבוץ-מחדש: הבוט מעביר את המשלוח לקבלן המבקש, משדר מחדש, ומשיב 'הועבר אליך ושודר ✅' עם מספר השידור החדש. אם המשלוח כבר נמסר/הושלם (אין משימה פעילה) — לא נוגעים בו, כמו קודם.

• 'כבר משודר אליך' חל רק כשהמשלוח באמת משובץ לקבלן המבקש — לא עוד הודעה שגויה כשהוא משובץ לאחר
• בקשת שידור על משלוח של קבלן אחר (שעדיין לא נמסר) מעבירה אותו אוטומטית למבקש ומשדרת מחדש — 'הועבר אליך ושודר ✅'
• מזהה השידור בתשובה נקרא טרי מהספק (לא מציג את מזהה הקבלן הקודם); אם עדיין לא התעדכן — מוצג בלי מזהה במקום מזהה שגוי
• לא נוגעים במשלוח שכבר נמסר/הושלם; שיבוץ-מחדש מכבד גם תת-שליחים של אותו קבלן
• ניתן לעריכה בהגדרות → תרחישי בוט (תבניות 'הועבר מקבלן אחר אליך')
• גישור 'אין מענה': דיווח קבלן על ברקוד ספציפי במצב 'נכשל' (FAILED — 'עדיין אפשר לטפל') כבר לא נחסם, כי זה בדיוק המצב שבו הקבלן ממשיך לנסות וזקוק לטלפון/הנחיה מהלקוח (החמצה שאותרה בקבוצת 'זיפ', משלוח 25885959). 'נכשל סופית'/נמסר/בוטל עדיין חסומים

שיפור חווית גלילה בפורטל השליחים: הפורטל עבר למבנה גובה-קבוע (flex column על מלוא גובה המסך) כך שכל החלק העליון — סרגל הברכה, מתגי הטאבים (הדוח שלי/צ'קליסט/מעוכבים/יעד שבת), וכן הבקרות הפנימיות של כל טאב (סינון, צ'יפים לאזורים, פס ההתקדמות של הצ'קליסט, כותרת הפרשה, בורר התקופה בדוח) — נשאר קבוע וסטיקי, ורק רשימות המשלוחים גוללות (overflow-y-auto פנימי). קודם כל העמוד גלל יחד עם הבקרות. חל על כל ארבעת הטאבים. בנוסף נוספה שורת הסבר קצרה (עם אייקון) בראש כל טאב שמסבירה לשליח מה משמעות הטאב וכיצד להשתמש בו. וכן עוצב מחדש כרטיס המשלוח בטאב 'יעד שבת': שם השולח (מקור) מוצג בגדול במקום שם הנמען, מזהה המשלוח הוגדל ועלה למעלה (מוצמד לימין, שם השולח לשמאל באותה שורה), אזור ההפצה מוצג כצ'יפ קטן ופחות דומיננטי לצד צ'יפ הסטטוס (סטטוס מימין, אזור משמאל), ופרטי הנמען עם כתובת מלאה עברו לשורת פרטים תחתונה עם אייקונים. אותם עקרונות הוחלו גם על כרטיסי הצ'קליסט והמעוכבים דרך רכיב כרטיס משותף (PortalCard): בצ'קליסט האזור מוצג כצ'יפ קטן לצד תג הדחיפות; במעוכבים תג ימי-העיכוב נשאר הדומיננטי למעלה והאזור עבר לשורת הפרטים התחתונה. כמו כן נוספה בדף השליח בממשק הניהול טבלת 'צ'קליסט' מלאה (באותו סגנון כשאר טבלאות המשלוחים בדף) המציגה למנהל את המשלוחים שהשליח מחוייב לנקות מהמחסן, כולל עמודת דחיפות — נטענת מ-/api/drivers/[id]/checklist.

טאב חדש 'צ'קליסט' בפורטל השליחים, לצד 'מעוכבים' ו'יעד שבת'. הרשימה מרכזת את המשלוחים שהשליח חייב 'לנקות' (להוציא להפצה) מהמחסן ביום ההפצה הבא כדי לא לחרוג מימי ההתחייבות — בדיוק אותו חישוב של טאב 'יום אחרון להפצה' בדף פערי ההפצה (שעון תאריך-גורם + ימי עסקים + חגים), אך צופה קדימה ליום ההפצה הבא של השליח. הרשימה 'מתגלגלת' בשעת איפוס אישית פר-שליח (ברירת מחדל 18:00 שעון ישראל) ולא בחצות, כוללת רק משלוחים בסטטוס 'נקלט במחסן' (יורדים מיד כשעוברים ל'יצא להפצה'), משויכת לפי אזורי האחריות של השליח, ובימי רביעי–שישי מצרפת גם משלוחי 'יעד שבת' לקו. הדף מתעדכן אונליין (polling) כך שהשליח רואה את הרשימה מצטמצמת עד שהיא נקייה. נוספו שני טריגרי וואטסאפ נערכים (ב-/messages/triggers) שנשלחים לקבוצת השליח: תזכורת יומית בשעת האיפוס, ותזכורת 'התחיל ולא סיים'. תג הצ'קליסט וסטטוס העיכוב מוצגים גם בדף המשלוח הפנימי.

• חישוב זהה ל'יום אחרון להפצה', צופה קדימה ליום ההפצה הבא; גלגול בשעת איפוס אישית פר-שליח (בר"מ 18:00) במקום חצות
• רק סטטוס 'נקלט במחסן', שיוך לפי אזורי אחריות, צ'יפים לניווט בין אזורים, ובימי ד'–ו' צירוף משלוחי יעד שבת
• פס התקדמות 'נוקו X מתוך Y' (מבוסס snapshot יומי), תגי דחיפות ('יום אחרון!' / 'חרג ב-N'), ומיון לפי דחיפות
• סנכרון אונליין — הרשימה מצטמצמת בזמן אמת ככל שמשלוחים יוצאים להפצה; אפשרות לרשום הערה 'למה לא יצא'
• שני טריגרי וואטסאפ נערכים לקבוצת השליח: תזכורת יומית ותזכורת 'התחיל ולא סיים' (15 דק' מהניקוי האחרון)
• פאנל צ'קליסט/עיכוב בדף המשלוח הפנימי; ותיקון: מעבר סטטוס ידני מציב כעת גם 'תאריך גורם' ו'תאריך יציאה' (sticky)

המשתנים {{current_time}} ו-{{current_date}} בתבניות ההודעה (טריגרים אוטומטיים, תיבת דואר, סוכן AI, resend) חושבו בשעון השרת של Vercel שהוא UTC — כלומר 3 שעות אחורה משעון ישראל בקיץ. לקוח שקיבל הודעה ב-08:40 ('ניסינו להשיג אותך') ראה 'מועד הניסיון 05:40'. הפורמטרים ב-template-renderer היו היחידים במערכת שלא ציינו timeZone (בשונה מ-employee-triggers, lead-triggers, sorting-error-utils שכבר נעולים ל-Asia/Jerusalem). נוסף timeZone: 'Asia/Jerusalem' לשני הפורמטרים — מודע לשעון קיץ/חורף.

סבב שיפורים לרשימת המשימות ולמסך המשלוח בעקבות משוב שליחים: (1) הכתובת והעיר לא הופיעו בכרטיסי המשלוח — ה-API בנה את הכתובת רק משדות ה-Visit, שריקים במשלוחי Lionwheel (הכתובת חיה על המשלוח). כעת ה-API (רשימת היום + פרטי משלוח) נופל לכתובת מהמשלוח כשה-Visit ריק — כך רחוב, מספר ועיר מוצגים תמיד. תיקון צד-שרת, חל מיד גם על בניות קיימות. (2) נוספה תווית 'X חבילות' לכרטיס משלוח עם יותר מחבילה אחת (לצד התוויות הקיימות: גוביינא, דחוף, אקספרס, שבת). (3) הוסרה שורת שלושת הכפתורים (התקשר/וואטסאפ/נווט) מהכרטיס המודגש של העצירה הבאה — היא לא פעלה והייתה מיותרת, שכן לחיצה ארוכה על כל משלוח פותחת ממילא גיליון פעולות מעוצב עם אותן פעולות. (4) כפתור 'שתף פרטי משלוח' במסך המשלוח מפיק כעת טקסט זהה בדיוק לכפתור 'העתק פרטי יעד' בכרטיס יעד המשלוח בממשק הניהול (משלוח / שם / רחוב / דירה / קומה / עיר / טלפון עם אימוג'ים). בנוסף, לקראת פרסום מקביל ב-App Store של Apple — נוסף דגל תאימות הצפנה (ITSAppUsesNonExemptEncryption=false) ל-Info.plist, כדי לחסוך את שאלת תאימות-הייצוא בכל הגשה ל-App Store (האפליקציה משתמשת רק ב-HTTPS סטנדרטי, פטור מייצוא).

• כתובת ועיר מוצגות תמיד בכרטיסי המשלוח (fallback לכתובת מהמשלוח כשה-Visit ריק) — חל מיד גם על גרסאות מותקנות
• תווית 'X חבילות' למשלוח מרובה-חבילות בכרטיס הרשימה
• הוסרה שורת הכפתורים הלא-פעילה מהכרטיס המודגש — הפעולות זמינות בלחיצה ארוכה
• שיתוף פרטי משלוח בפורמט זהה להעתקה בממשק הניהול

כששלחו תבנית Meta מאושרת מהצ'אט ב-messages/inbox, בועת ההודעה בצ'אט של Shipnest הציגה את גוף התבנית הגולמי עם שמות המשתנים ({{destination_name}}, {{barcode}}, {{source_name}}) במקום הערכים שמולאו. הלקוח עצמו קיבל את ההודעה המלאה והנכונה — Meta מבצעת את ההחלפה בצד שלה — אבל בתצוגה הפנימית נשמר ה-preview הגולמי (tpl.body) ולא הטקסט המוחלף, מה שיצר רושם מטעה שההודעה נשלחה עם שמות המשתנים. כעת נתיב השליחה מחליף את ערכי הפרמטרים (לפי metaParamMap: variable→position) לתוך גוף התבנית לפני שמירת הבועה, כך שהצ'אט מציג בדיוק את מה שהלקוח קיבל.

כשלקוח בצ'אט 1:1 ביקש 'שלח לי לינק', סוכן הלקוח החזיר placeholder מהוזה ('[קישור למעקב דמיוני]') — כי לא היה לו שום כלי שמפיק URL אמיתי, וה-prompt לא הזכיר קישורים כלל. נוסף כלי getShipmentLinks שמחזיר את אותם קישורי מעקב ('/tracking/{public_id}') ועדכון פרטי מסירה ('/validate/{public_id}') המופיעים תחת 'קישורים להעתקה' בדף המשלוח. אם לא סופק ברקוד — הכלי בוחר אוטומטית את המשלוח הפעיל היחיד, ואם יש כמה פעילים הוא מחזיר needBarcode והבוט מבקש מספר משלוח. ה-prompt חוזק באיסור מוחלט להמציא קישור.

הסרת סאב-שליח מצוות של קבלן-מנהל דורשת כעת בחירת 'תאריך ניתוק', והניתוק חל מאותו תאריך ואילך — גם רטרואקטיבית. עד היום ההסרה נחסמה כל עוד היו לסאב משלוחים פעילים תחת המנהל; במקום החסימה, כל ביקור שהסאב ביצע תחת המנהל מתאריך הניתוק והלאה (הושלם או פעיל) מנותק מהמנהל: התיוג managedByDriverId מנוקה, כך שגם חשבון הלקוח→מנהל וגם התשלום מנהל→סאב מפסיקים לכלול אותו, והעבודה חוזרת להיות עצמאית של הסאב. משלוחים שלפני התאריך נשארים משויכים למנהל. עלויות המשלוחים המושפעים וימי-המנהל שאיבדו משלוח (לפיצול business-pickup מחדש) מחושבים מחדש אוטומטית. בורר התאריך מוגבל בין מועד יצירת הקישור להיום (ללא עתיד), והפעולה נרשמת ל-audit עם התאריך ומספר הביקורים שנותקו.

• דיאלוג ההסרה כולל DatePicker לתאריך ניתוק — ברירת מחדל היום, ניתן לבחור תאריך רטרואקטיבי
• החסימה הישנה על 'משלוחים פעילים תחת המנהל' הוסרה — הניתוק מבוסס-תאריך מטפל גם בפעילים
• ניקוי managedByDriverId מהביקורים מהתאריך ואילך + recompute עלויות אוטומטי לצד הסאב ולימי-המנהל

ליטוש עיצובי למדריכי חיבור החנות (WooCommerce/Konimbo/Shopify): (1) סמני השלבים ברשימות הוחלפו מחץ אחיד למספר השלב בפועל, כולל מספור רציף בסקציית מפתחות ה-API של WooCommerce גם כשצעד 'הוסף מפתח' מוסתר (קישור עמוק קיים) — קודם היה נוצר דילוג 1,3,4,5. (2) חצי ה'ערך' בטבלאות השדות הופכו לכיוון שמאל (←) התואם RTL, עם רווח גדול יותר אחרי החץ ורווח קטן יותר לפניו.

המשך לתיקון הברקוד המהוזה: כששליח מדווח בעיה בלי לכתוב ברקוד אבל *מגיב-בציטוט* להודעה שמזהה משלוח, הבוט מזהה כעת את המשלוח מההודעה המצוטטת — דטרמיניסטית — במקום להישען על חילוץ הברקוד של המסווג. שני נתיבים: (א) השליח ציטט את שאלת ה-relay של הבוט → AiScenarioRelay.questionMessageId → המשלוח המדויק; (ב) השליח ציטט הודעה אחרת (למשל שורת OCR של מדבקה) → מחלצים מספר ומאמתים שהוא ברקוד אמיתי של ה-tenant. הקדימות: ברקוד שמופיע בטקסט גובר; הציטוט ממלא רק כשאין ברקוד בטקסט — additive, בלי לשבור קיים. אומת מול נתוני פרודקשן: ציטוט שאלת-relay פותר למשלוח הנכון, וציטוט מדבקה פותר ל-25618278 הנכון.

כשל שנתפס בשטח: שליח דיווח "גיבתון לא עונה" (בלי ברקוד), והבוט פתח relay ועדכן את הלקוח לגבי משלוח 23950704 — משלוח אחר לגמרי (תקוע חודשים אצל לקוח אחר). השורש: המסווג (LLM) שמתבקש לחלץ ברקוד מההודעה *המציא* ברקוד שאינו קיים בטקסט, ו-resolveDriverShipment פתח relay על המשלוח השגוי ושלח ללקוח שלו. תוקן: סומכים על הברקוד של המסווג רק אם ספרותיו מופיעות מילולית בהודעה (barcodeIfMentioned); אחרת מתעלמים ממנו — הבוט נופל לזיהוי לפי משלוח פעיל של השליח, ובעמימות (ריבוי משלוחים פעילים) נשאר שקט במקום לשדר על משלוח שגוי. נוספו טסטים כולל מקרה השטח.

סבב שיפורים לעוזר הפנימי בעקבות ניתוח 5 שיחות אמת שבהן העוזר התקשה בשאלות פיננסיות ובאיתור משלוחים חסרים מדוח. שישה תיקונים: (1) getShipmentDetails החזיר ביקורים בלי תאריכים — העוזר 'המציא' תאריכי מסירה וקליטה (למשל 'נמסר 29/6' כשבפועל 1/7). כעת מוחזרים תאריכים מתויגים: תאריך איסוף (pickupScanAt), תאריך מסירה בפועל (deliveredAt), ותאריך ניסיון שנכשל — והעוזר מונחה לקרוא אך ורק מהשדות ולעולם לא לנחש. (2) getCostSummary — 'הכנסה' הובנה הפוך: העוזר טען שוב ושוב שההכנסה היא 'רק ממשלוחים שהושלמו' וחילק במונה שגוי, ואף 'המציא' שמבוטלים לא נכללים. תוקן: ההכנסה מכסה את כל המשלוחים לפי תאריך קליטה, נוספו ממוצעים מוכנים (הכנסה למשלוח, הכנסה לחבילה) וספירת חבילות, וההערה מבהירה שמבוטלים/חדשים כלולים אלא אם מסננים אותם. (3) כלי חדש getShipmentCost — עלות המסירה/איסוף של משלוח בודד (רשומה בפועל, או הערכה למשלוח שטרם הושלם); קודם העוזר נכנע ('אין מחירון לשליח') למרות שלמשלוח שנמסר יש עלות רשומה. (4) סינון חדש לפי 'תאריך איסוף מלקוח' (pickupFrom/pickupTo) — בדיוק ציר התאריך שבו משתמשת דיווחה על משלוחים חסרים; מבוסס על האיסוף שהושלם בפועל (לא על תאריך מתגלגל), כך שמשלוח שטרם נאסף כראוי לא ייכלל. (5) העברת שם לקוח או ברקוד בטעות כמזהה לקוח (customerId) החזירה 0 תוצאות בשקט — כעת נזרקת שגיאה ברורה שמנחה לאתר את הלקוח קודם. (6) הנחיות: שלושת צירי התאריך (קליטה/מסירה/איסוף), סמנטיקת ההכנסה, ומניעת לולאת ניחושים באבחון 'משלוח חסר מדוח'. הכל אומת מול נתוני הפרודקשן, כולל בדיקה יריבה שאיתרה ותיקנה שלושה באגים לפני העלייה.

• כלי חדש getShipmentCost — עלות מסירה/איסוף של משלוח בודד (רשומה או הערכה), מוגן בהרשאת פיננסים
• סינון חדש לפי תאריך איסוף מלקוח (pickupFrom/pickupTo) — ציר תאריך שלישי לצד קליטה ומסירה
• getCostSummary: ממוצע הכנסה למשלוח ולחבילה + ספירת חבילות; תוקן שההכנסה מכסה את כל המשלוחים ולא רק שהושלמו
• תיקון הזיות תאריכים — getShipmentDetails מחזיר כעת תאריך איסוף, מסירה וכישלון מפורשים
• מזהה לקוח שגוי (שם/ברקוד) זורק שגיאה ברורה במקום להחזיר 0 תוצאות בשקט

כשקבלן מדווח בעיית מסירה (אין מענה / כתובת שגויה / טלפון שגוי / כשל) והבוט מזהה את התרחיש — אבל ללקוח העסקי אין יעד WhatsApp מקושר — הדיווח היה מת בשקט (matched_no_action). סריקת DB מצאה 67 דיווחים כאלה שנעלמו לאורך הצי. כעת, במקום שקט, הבוט מוסיף הערה פנימית לצוות בתוך שרשור-הקבלן ב-inbox ("הקבלן דיווח X על משלוח Y — הלקוח Z אינו נגיש, יש לטפל ידנית") ומסמן את השיחה כלא-נקראה. ההערה פנימית בלבד (role=staff, internal) ולעולם לא נשלחת ל-WhatsApp — אפס סיכון שליחה אוטונומית. עם דדופ של 24ש' למניעת הצפה מ-burst חוזר.

המשך תיקון: שלד הטעינה עדיין כיסה רק חלק מגובה הטבלה. שתי סיבות תוקנו — (1) באג תזמון: ה-effect שמדד את גובה אזור-הגלילה היה תלוי במשתנים שלא משתנים כשה-ref מתמונט (רק אחרי טעינת ההעדפות), כך שהמדידה מעולם לא רצה והמספר נשאר על ברירת המחדל; נוסף prefsLoaded לתלויות. (2) הערכת-יתר של גובה שורת השלד — כויל לגובה אמיתי (~33px) עם באפר שמבטיח מילוי. בנוסף, מבנה אזור-הגלילה יושר לזה של טבלת הניהול (flex flex-col), ומצב 'אין משלוחים'/'לא נמצאו תוצאות' עבר ל-flex-1 כך שהוא ממורכז וממלא את כל שטח הטבלה.

קבלן עמוס עונה על הרבה משלוחים בהודעה אחת ("…25682330 סופק 25730095 היום…"). שער-הרלוונטיות ההוליסטי דחה batch כזה כ"לא תשובה", וה-relays של אותם משלוחים מתו בלי מענה — הלקוח שבצד השני לא קיבל את הסטטוס שהקבלן בעצם מסר. נוסף שלב threading דטרמיניסטי: כשברקוד של relay פתוח מופיע מילולית בהודעה עם קטע-סטטוס אחריו, הבוט משדר ללקוח *רק את הקטע של המשלוח שלו* ופותר את ה-relay. השינוי additive בלבד (רץ רק כשלא נמצאה התאמת quoted-id, ורק על ברקוד מדויק + מילת-סטטוס — אחרת נופל בדיוק להתנהגות הקיימת), וגם מקשיח פרטיות: משדר קטע-משלוח בודד במקום כל ה-batch. אומת בבקטסט על נתוני היסטוריה אמיתיים: אפס mis-fire.

בתרחישי ה-relay של הבוט ("אין מענה" / "נכשל במסירה"), כשהקלט מקבוצת השליח לא היה דיווח אמיתי על קושי במסירה (למשל מספר משלוח בלבד), המודל היה מדקלם בעברית את הוראת ה"אין מה לומר" ("מחרוזת ריקה לחלוטין…") — והטקסט הזה נשלח כהודעה ללקוח (לקוח אחד אף השיב "מה זה מחרוזת ריקה?"). שלושה תיקונים משלימים: (1) הוחלף סימן ה"אין מידע" בפרומפט מ"מחרוזת ריקה" למילת־בקרה NONE שאי־אפשר לבלבל עם תקציר אמיתי; (2) הוקשח שומר־הסף (asCustomerSafeHebrew) לפסול גם הד־הוראה/מטא־טקסט בעברית, לא רק באנגלית; (3) נוסף guard דטרמיניסטי שלא פותח relay של "אין מענה" כשה-burst אינו נושא טקסט דיווח (מספר/אזכור בלבד). נוספו טסטים למקרה העברי ולמילת ה-NONE.

סבב שני של שדרוגים לטבלת המשלוחים בפורטל: (A) שורת 'מסננים פעילים' (בדסקטופ) מעל הטבלה — כל מסנן פעיל (סטטוס/תווית/סוג/סינון-עמודה) מוצג כצ'יפ הניתן להסרה בקליק, עם כפתור 'נקה הכל'. (B) מוני משלוחים ליד כל אפשרות בפילטר הסטטוס — כמה משלוחים בכל סטטוס בהינתן שאר המסננים (facet יעיל על עמודת הסטטוס האינדקסית). (C) תוקן באג: משתמש חדש בפורטל ראה את כל העמודות (כולל המוסתרות כברירת מחדל) עד שפתח את תפריט העמודות — כעת ברירת המחדל של העמודות מכובדת מיד בטעינה. (D) עמודת הברקוד ננעצת לימין כברירת מחדל כך שנשארת גלויה בגלילה אופקית (למשתמשים חדשים; בחירת משתמש קיים גוברת). (E) שורות שלד (skeleton) בזמן טעינה במקום ספינר בודד — מספר השורות מחושב לפי גובה הטבלה כך שהשלד ממלא את כל האזור; גם מצב 'אין משלוחים'/'לא נמצאו תוצאות' ממורכז וממלא את כל שטח הטבלה במקום פס קצר בראשה. (F) עמודת התאריך מציגה 'היום'/'אתמול' למשלוחים טריים, עם התאריך המלא ב-tooltip.

• שורת 'מסננים פעילים' (דסקטופ) עם צ'יפים להסרה + 'נקה הכל'
• מוני משלוחים לכל סטטוס בפילטר הסטטוס
• תיקון: משתמש חדש כבר לא רואה את כל העמודות בבת אחת (כיבוד ברירת מחדל)
• עמודת ברקוד נעוצה כברירת מחדל (נשארת גלויה בגלילה)
• שורות שלד בזמן טעינה + תאריך יחסי 'היום'/'אתמול'

סבב שיפורי עיצוב ותצוגה לטבלת המשלוחים בפורטל הלקוח: (1) איחוד עמודות 'שולח' ו'חשבון' לעמודה אחת 'יוזר' (שם החשבון המקושר), שמוצגת רק בלקוחות עם יותר מחשבון מקושר אחד. (2) עיצוב גופן אחיד לכל תאי הטבלה — הוסרו הבדלי גודל/צבע/גופן פר-עמודה (text-xs, טקסט מעומעם, מונוספייס) כך שכל הטקסטים והמספרים מוצגים באותו עיצוב; ה-badges של סטטוס/דחיפות, תגית הברקוד וה-chips של התוויות נשמרו כאלמנטים ייעודיים. (3) תוקן צבע הרקע של כותרת עמודת הפעולות שבלט משאר הכותרות (הותאם ל-bg-card). (4) נוספה עמודה 'נוצר ע״י' לבקשת לקוחות: משלוח שנוצר ע״י משתמש פורטל מציג את שם המשתמש, ומשלוח שנוצר ע״י צוות הטננט מציג את שם הטננט (החברה) בלבד — ללא שם היוצר.

• עמודות 'שולח' + 'חשבון' → עמודה אחת 'יוזר' (מוצגת רק בחשבונות מקושרים)
• עיצוב גופן אחיד לכל העמודות — טקסטים ומספרים באותו גודל/צבע/גופן
• כותרת עמודת הפעולות כבר לא בולטת בצבע שונה משאר הכותרות
• עמודה חדשה 'נוצר ע״י': שם משתמש הפורטל, או שם הטננט למשלוחים שנוצרו ע״י הצוות
• היררכיית אייקון עמודת הפעולות תוקנה: אייקון התפריט בכותרת בולט יותר ואייקוני השורות עדינים יותר (במקום הפוך)

מנהלי משתמשים בפורטל (בעלים / manage_users) יכולים כעת להגביל אילו מבין משתמשי הצוות שלהם רואים את עלות/מחיר המשלוח. נוספה הרשאה חדשה 'צפייה בעלות המשלוח' לדף ניהול הצוות (הגדרות → צוות) וגם למסך ניהול משתמשי הפורטל בצד הטננט. ברירת המחדל: כבויה לכל המשתמשים הרגילים (קיימים וחדשים) — כך שהעלות מוסתרת עד שמנהל מעניק את ההרשאה במפורש; מנהלי המשתמשים רואים את העלות תמיד ואי אפשר לחסום אותם. ההסתרה נאכפת בצד השרת בכל שלושת מסלולי הנתונים של הפורטל (רשימת המשלוחים, פרטי המשלוח, ותצוגת ה-Drawer) — הערך פשוט לא מגיע לדפדפן — כך שהיא חלה על עמודת 'מחיר' בטבלה, על כרטיס 'עלות המשלוח' בפרטים, על החיפוש בטקסט ועל ייצוא האקסל. למשתמש מוגבל עמודת 'מחיר' אף אינה מוצעת בבורר העמודות.

• הרשאה חדשה 'צפייה בעלות המשלוח' — ניתנת להענקה/שלילה פר-משתמש בהגדרות → צוות (וגם בניהול משתמשי הפורטל בצד הטננט)
• כבויה כברירת מחדל לכל המשתמשים (קיימים וחדשים); מנהלי המשתמשים — בעלים / manage_users — רואים תמיד ואי אפשר לחסום אותם
• האכיפה בצד השרת: העלות מנוטרלת בכל מסלולי הפורטל (רשימה, פרטים, drawer) כך שאינה דולפת דרך ה-API, החיפוש או ייצוא האקסל
• למשתמש מוגבל עמודת 'מחיר' אינה מוצעת כלל בבורר העמודות (במקום להציג עמודה ריקה)

בדף פערי ההפצה, בתצוגת משלוחים המשובצים לשליח, נוסף כפתור 'העתקה לקבלן' לצד כפתור ההעתקה הרגיל (שנשאר ללא שינוי). ההעתקה לקבלן מוסיפה לכל משלוח שורה שלישית: 'יצא ב- DD/MM/YYYY - N ימים אצלכם' — התאריך הוא מועד שיבוץ השליח ו-N הוא מספר ימי העסקים מאז. כאשר המשלוח נמצא 3 ימי עסקים ומעלה אצל הקבלן מתווסף סימן קריאה בסוף השורה, אחרת ללא. הרשימה המועתקת ממוינת מהחמור לקל לפי מספר הימים אצל הקבלן (הגבוה ביותר ראשון). הכפתור מוצג רק בתצוגת 'משובץ' (שם קיים קבלן).

עד עכשיו גישור 'אין מענה' היה נסיעה חד-כיוונית וחד-פעמית: הקבלן מדווח שאין מענה → הבוט שואל את הלקוח אם יש טלפון/הנחיה → כשהלקוח עונה, הבוט מעביר לקבלן וסוגר. אבל אם הקבלן עצמו הודיע בקבוצתו 'סופק' / 'הסתדר' / 'נמסר' (לפני או אחרי שהלקוח ענה) — שום דבר לא הועבר ללקוח, והלקוח נשאר תלוי על שאלה שכבר לא רלוונטית. נוספה 'רגל שלישית' לגישור: כשמגיעה הודעה בקבוצת הקבלן בזמן שהבירור עדיין פתוח, והיא מדווחת שהמשלוח סופק/הסתדר, הבוט מעביר את הבשורה ללקוח (כתגובה מצוטטת לשאלת 'אין מענה' המקורית) וסוגר את הבירור. הזיהוי מדויק וזול: קודם מסנן מילות-מפתח חינמי (סופק/נמסר/הסתדר/בוצע...), ורק אם קיים בירור פתוח ומילת-מפתח תואמת — שער LLM אחד (Haiku) מאשר שזה באמת דיווח מסירה חיובי ולא שלילה ('לא נמסר') או כשל. הודעות צוות בקבוצה מדולגות. בנוסף תוקן באג תצוגה: תשובת-ציטוט (swipe-to-reply) של לקוח שגם פתרה גישור נשמרה בלי הפניית-הציטוט, ולכן הופיעה בתיבת העסק בלי בלוק הציטוט הוויזואלי — עכשיו הציטוט נשמר ומוצג גם במסלול זה. ותיקון דיוק חשוב: כשקבלן מדווח 'אין מענה' (או כתובת/טלפון שגויים) בלי לציין מספר משלוח, הבוט היה מנחש את המשלוח הפתוח האחרון שלו — ובקבוצת קבלן עם עשרות משלוחים פעילים זה פגע במשלוח ובלקוח לא-קשורים (למשל פנייה מיותרת ללקוח 'כביסכל' על משלוח 23165589, בזמן ש'אין מענה' הייתה בכלל תשובה לשאלת צוות על משלוח אחר שכבר נכשל). מעכשיו, כשאין ברקוד בדיווח ולקבלן יותר ממשלוח פתוח פעיל אחד — הבוט שותק במקום לנחש.

• רגל שלישית לגישור 'אין מענה': דיווח 'סופק/הסתדר' מהקבלן מועבר ללקוח וסוגר את הבירור, במקום להשאיר אותו תלוי
• העדכון ללקוח נשלח כתגובה מצוטטת לשאלת 'אין מענה' המקורית — כדי שהוא יבין להֵקשר
• זיהוי חסכוני: מסנן מילות-מפתח חינמי ואז שער LLM יחיד שמאשר מסירה חיובית ודוחה שלילה/כשל; הודעות צוות מדולגות
• ניתן לעריכה בהגדרות → תרחישי בוט (תבנית 'יידוע הלקוח כשהשליח מדווח שהמשלוח סופק/הסתדר')
• תיקון תצוגה: תשובת-ציטוט של לקוח שפתרה גישור מציגה כעת את בלוק הציטוט בתיבת העסק (קודם נשמט)
• תיקון דיוק: דיווח שליח→לקוח ללא ברקוד מפסיק לנחש משלוח — הבוט פועל רק כשיש לקבלן משלוח פתוח פעיל יחיד (מונע פנייה ללקוח הלא-נכון)

המשך לטיפול בנקרא/לא-נקרא: נציגות התלוננו שגם כשאיש צוות מהחברה שמשתתף בקבוצה הגיב, הצ'אט נשאר מסומן כלא-נקרא. הסיבה: כשאיש צוות כותב בקבוצה ממספר שאינו החשבון המחובר ל-Green API (מספר אישי, או מספר עסקי שהוא רק משתתף בקבוצה), Green API שולח את זה כהודעה נכנסת (role=user) ולא כהודעה יוצאת — ולכן התיקון הקודם (שקידם את סימון הנקרא רק על הודעות יוצאות) לא זיהה אותה, וההודעה אף הגדילה את מונה הלא-נקראו. התיקון: זיהוי השולח מול מפת טלפוני הצוות של הטננט (resolveGroupSender) — הודעת צוות בקבוצה מקדמת עכשיו את lastReadAt ומנקה סימון-לא-נקרא ידני, בדיוק כמו תגובה מהחשבון המחובר. תלוי בכך שהטלפון של איש הצוות (ראשי או משני) רשום במערכת.

השליח יכול כעת לרשום בדף המשלוח באפליקציה 'הערת שליח' — להתמצאות בכתובת או לעדכון התפעול על כשלים. ההערה פרטית: גלויה לשליח ולצוות התפעול בדשבורד הווב בלבד, לעולם לא לנמען ולא לשולח (לא בפורטל, לא ב-WhatsApp, לא ב-API הציבורי, ולא מסתנכרנת לליונוויל). בנוסף, השליח יכול לתקן ישירות מהאפליקציה את פרטי הכתובת — קומה, כניסה, דירה וקוד כניסה — והתיקון מתעדכן בכל המערכת: הוא נכתב על הביקור וגם ממופה לשדות הכתובת הקנוניים של המשלוח, כך שהדיספצ'ר בווב ופורטל השולח רואים את הכתובת המעודכנת (וישרת גם מסירה חוזרת או העברה לשליח אחר). מבחינה טכנית: נוספה עמודת courier_note ל-Shipment ועמודות entrance/entranceCode ל-Visit; נקודת הקצה של הביקור במובייל מחזירה את השדות ותומכת ב-PATCH לשמירתם (עם בדיקת בעלות מלאה — השליח יכול לערוך רק ביקור שמשויך אליו); בדשבורד הווב הערת השליח מוצגת בכרטיס יעד המשלוח לצוות התפעול. עריכה זמינה גם על ביקור שהסתיים (כשל) — כדי שאפשר יהיה לעדכן על כשל בדיעבד.

• הערת שליח פרטית בדף המשלוח — להתמצאות בכתובת או עדכון תפעול על כשלים
• פרטיות מלאה: גלוי לשליח ולתפעול בלבד — לא לנמען, לא לשולח (פורטל/WhatsApp/API ציבורי), ולא לליונוויל
• עריכת קומה/כניסה/דירה/קוד כניסה ישירות מהאפליקציה, עם תיקון שמתעדכן בכל המערכת (דיספצ'ר + פורטל השולח)
• צוות התפעול רואה את הערת השליח בכרטיס יעד המשלוח בדשבורד הווב
• עריכה מותרת גם על ביקור שנכשל — לעדכון תפעול בדיעבד; עם בדיקת בעלות (השליח עורך רק ביקור שלו)

הבר העליון של 'תמונת מחסן' אוחד לאותה מערכת רכיבים של דף /shipments: PageToolbar עם ToolbarSearch (שדה חיפוש עם כפתור X לניקוי מיידי — שהיה חסר לגמרי) וכפתורי ToolbarButton אחידים ל'רענון' ו'הדפסה', במקום Input גולמי וכפתורי אייקון ghost. שאר תוכן הכותרת — הכותרת עצמה, תג מספר המשלוחים, חותמת 'עודכן ב', ותג 'N תואמות' — נשמר בתוך הבר.

בדף 'תמונת מחסן', חיפוש (ברקוד / שם לקוח / עיר / קוד אזור) רק הקיף במסגרת את המשבצות התואמות ועמעם את השאר ל-30% שקיפות — לא מספיק בולט. כעת החיפוש מסנן ממש: מוצגות רק המשבצות שמכילות תוצאה תואמת, והשאר נעלמות. נוסף תג 'N תואמות' בכותרת, מצב 'לא נמצאו תוצאות' עם כפתור ניקוי חיפוש, וגרירה לסידור-מחדש מושבתת בזמן חיפוש (כדי שדריפה על תת-קבוצה לא תיצור סדר חלקי שגוי). לוגיקת ההתאמה אוחדה למקור-אמת יחיד המשמש גם לסינון וגם להדגשת המשבצת בתוך הכרטיס.

בדף הליקוט, בטאבים 'נלקטו היום' ו'סה"כ נלקטו', המערכת המשיכה לחשב 'ימי המתנה' כ-(היום − תאריך ההוספה) ולצבוע שורות באדום/כתום לפי הוותק — מדד חסר-תועלת עבור משלוח שכבר לוקט (הוא כבר לא 'ממתין', והמספר גדל לנצח). כעת צביעת הדחיפות (אדום/כתום) חלה רק על משלוחים שעדיין ממתינים לליקוט; ובמשלוח שלוקט עמודת 'ימי המתנה' מציגה את זמן הטיפול הקבוע — מרגע ההוספה ועד הליקוט (נגזר מ-pickedAt) — בתג ניטרלי, עובדה היסטורית שאינה משתנה במקום מונה מתגלגל. אותה נוסחה מוחלת גם על המיון לפי 'ימי המתנה' ועל ייצוא ה-Excel. ה-API של הליקוט מחזיר כעת את pickedAt.

בדף פרטי הסוכן, כשלסוכן היו הרבה משלוחים מזכים (למשל 313), רשימת המשלוחים ב'דוח עמלות חודשי' נפרשׂה במלוא גובהה וכיסתה את הכרטיסיות 'כללי עמלה' ו'חיוב/זיכוי חד-פעמי' שמתחתיה. הסיבה: רכיב ScrollArea של Radix עם max-height בלבד (בלי גובה מוגדר) — ה-Viewport הפנימי (size-full) לא קיבל גובה אמיתי לחשב מולו, גדל לגובה התוכן המלא, וגלש. הוחלף ב-div רגיל עם overflow-y-auto, שם max-height עובד נכון עם גלילה native. אותו דפוס תוקן גם בדיאלוג הוספה לליקוט (רשימת הפרשות), שהיה חשוף לאותה גלישה מעל כפתורי הדיאלוג.

מקבץ תיקונים מקיף לאפליקציית השליחים אחרי סקירת קוד רב-ממדית. תוקנו חמש תקלות קריטיות: (1) סורק המחסן במובייל (קליטה/שיוך) קרא ל-endpoint של הווב שמאומת בעוגיות דפדפן ולכן כל סריקה נכשלה — לוגיקת הסריקה חולצה ל-scan-core משותף, נבנה endpoint מובייל ייעודי מאומת-טוקן (/api/v1/mobile/admin/scan) עם בדיקת תפקיד, וההתנהגות (קליטה, שיוך, סנכרון ליונוויל, יומן ביקורת) זהה לחלוטין לסורק הווב. (2) מעקב מיקום ברקע ב-iOS לא יכול היה לעבוד כלל כי חסר UIBackgroundModes — נוסף isIosBackgroundLocationEnabled ל-app.json. (3) עבודת ליקוט אופליין על אצווה לא-משויכת (OPEN) נדחתה כולה בסנכרון ואבדה — נוסף claim אטומי ומוגן-מרוץ שתופס אצווה פנויה לעובד שהוריד אותה. (4) מסך ההכנסות והבורר-תאריך במסך הבית הציגו את היום/החודש הקודם עקב המרת תאריך ב-UTC — התאריכים נגזרים כעת מהיום המקומי, והשרת מפרש טווחי-יום כגבולות שעון ישראל. (5) timeout גורף של 10 שניות חנק העלאות תמונה ברשת סלולרית חלשה — הועלה ל-120 שניות עבור בקשות עם תמונה. בנוסף הוקשח תור הסנכרון אופליין: retry עם backoff מעריכי (התור כבר לא נתקע בשקט כשהוא 'מקוון' אבל הבקשות נכשלות), תקרת ניסיונות שמעבירה פריט 'רעיל' ל-failed במקום לחסום את כל התור, סיווג 403 וקובץ-חסר כשגיאה סופית, תיוג פעולות לפי משתמש (מכשיר משותף לא מסנכרן עבודת נהג אחד תחת טוקן של אחר), ותמונות כשל/צ'ק מועתקות כעת ל-documentDirectory כמו POD כדי שהמערכת לא תמחק אותן לפני ההעלאה. רענון הטוקן מבחין כעת בין כשל רשת רגעי (משאיר את הסשן) לבין דחייה אמיתית (מנתק), כך ששליח לא מנותק באמצע משמרת על תקלת רשת חולפת; ומעקב ה-GPS נעצר ביציאה מהמערכת (פרטיות + סוללה). אכיפת גביית COD שבה לפעול במצב אופליין (סטטוס הגבייה מוזרם מנקודת /today). בצד הדיספצ'ר: נוסף שומר-תפקיד לקבוצת מסכי האדמין, תור הביקורים הלא-משויכים כולל כעת גם צבר של עד שבוע אחורה (במקום להיעלם בחצות), שיוך ממובייל מריץ את קידום סטטוס המשלוח וסנכרון ליונוויל כמו בווב ואינו מאפשר לשייך מחדש ביקור שהושלם, והקשה על התראת פוש מנווטת נכון גם כשהאפליקציה סגורה (cold-start). בהמשך הוקשחה זרימת ההזדכות (COD settlement): תמונות ההוכחה נדחסות כעת בצד הלקוח (resize 1600 + איכות 0.8) לפני ההעלאה — קודם 5 תמונות לא-דחוסות חרגו ממגבלת גוף-הבקשה של Vercel (4.5MB) והפילו את ההזדכות ב-413; ויצירת ההזדכות בשרת הפכה לאטומית — יצירת הרשומה ותפיסת רשומות ה-COD רצות בטרנזקציה אחת עם updateMany מותנה (settlementId עדיין null), כך שבקשה מקבילה או ניסיון-חוזר לא יכולים להזדכות פעמיים על אותו כסף (אי-התאמה בספירה מגלגלת את כל הטרנזקציה אחורה ומחזירה 409). לבסוף, התראות פוש נשלחות כעת גם מזרימות השיוך בווב: שיוך בודד מדשבורד הווב שולח לשליח 'משלוח חדש'/'הועבר אליך' (ולשליח הקודם 'הועבר ממך'), ושיוך מרובה (לאסו במפה) שולח התראה מקובצת אחת — 'שויכו אליך N משלוחים' — במקום N התראות. קבלנים חיצוניים (ספקי broadcast) מוחרגים; שליח בלי טוקן פוש הוא no-op. עד כה פוש נשלח רק משיוך במובייל, כך שהשליחים פיצו על כך ב-polling.

• סורק המחסן במובייל תוקן — endpoint ייעודי מאומת-טוקן שמשתף את אותה לוגיקה בדיוק כמו סורק הווב (קליטה/שיוך/סנכרון ליונוויל/ביקורת)
• מעקב מיקום ברקע ב-iOS מופעל (UIBackgroundModes) — קודם לא עבד כלל אחרי נעילת מסך
• ליקוט אופליין על אצווה לא-משויכת כבר לא אובד — claim אטומי מוגן-מרוץ תופס את האצווה לעובד
• מסך ההכנסות וניווט התאריכים הציגו יום/חודש קודם (באג UTC) — תוקן לגבולות יום בשעון ישראל
• העלאות תמונה (POD/גוביינא/כשל) כבר לא נחנקות ב-timeout של 10ש' ברשת חלשה — 120ש' לבקשות עם תמונה
• תור הסנכרון אופליין הוקשח: backoff מעריכי, תקרת ניסיונות לפריט תקוע, תמונות נשמרות ב-documentDirectory, ותיוג פעולות לפי משתמש
• רענון טוקן לא מנתק שליח על כשל רשת רגעי; מעקב GPS נעצר ביציאה מהמערכת
• אכיפת גביית COD שבה לפעול גם אופליין, ושומר-תפקיד נוסף לקבוצת מסכי הדיספצ'ר
• שיוך ממובייל מקדם סטטוס ומסנכרן ליונוויל כמו הווב, חוסם שיוך-מחדש של ביקור שהושלם, ותור הלא-משויכים כולל צבר שבוע אחורה
• הזדכות COD: דחיסת תמונות הוכחה בצד הלקוח (תיקון 413), ויצירה אטומית בשרת (טרנזקציה + claim מותנה) שמונעת הזדכות כפולה על אותו כסף
• התראות פוש נשלחות כעת גם משיוך בווב — שיוך בודד ('משלוח חדש'/'הועבר') ושיוך מרובה עם התראה מקובצת אחת; קודם פוש נשלח רק מהמובייל

שיפורי העתקה ואינטראקציה ב-business-inbox בעקבות משוב מנציגות שירות: (1) העתקת הודעה דרך תפריט-ההקשר העתיקה תמיד את כל ההודעה, גם כשסומן רק קטע — עכשיו 'העתק' מכבד את הבחירה ומעתיק רק את מה שסומן (כשהבחירה נמצאת בתוך אותה הודעה). (2) מספרי טלפון, כתובות אימייל וקישורים בתוך הודעות הפכו לאינטראקטיביים: לחיצה על מספר פותחת את השיחה של אותו מספר בתוך התיבה עצמה — ואם אין היסטוריית התכתבות, נפתחת שיחה חדשה מוכנה לשליחה; לחיצה על אימייל פותחת חלון כתיבת מייל; וקישור נפתח בכרטיסייה חדשה. לחיצה ימנית (או לחיצה ארוכה במובייל) פותחת תפריט — פתיחת שיחה / חיוג / העתקת מספר עבור טלפון, שליחת מייל / העתקת כתובת עבור אימייל. זיהוי הטלפונים דורש 0 או +972 מוביל כדי לא לזהות ברקודים/מחירים בטעות. (3) כפתור העתקה קטן מופיע ליד מספר הטלפון של הלקוח ב-header של הצ'אט, בסגנון ההעתקה הקיים בשאר המערכת.

נוסף מנגנון שיתוף פעולה פנימי ב-business-inbox: אפשר להוסיף 'הערה פנימית' לשיחה — פתק שנשמר בשיחה אך לעולם לא נשלח ללקוח בוואטסאפ — ובתוכה לתייג חבר צוות עם @. חבר הצוות שתויג מקבל סימון בתוך המערכת (מונה 'תיוגים שלי' עם מסנן שקופץ ישר לשיחות הרלוונטיות), וההערה מודגשת לו עם תווית 'תויגת'. הרקע: וואטסאפ/Green API לא מאפשרים תיוג נייטיב אמיתי דרך ה-API (אין mentionedJid ב-SendMessage), ולכן התיוג מומש כיכולת פנימית מלאה בתוך Shipnest, מבודדת לחלוטין מהלקוח.

• מצב 'הערה פנימית' נפרד בתיבת הכתיבה (כפתור פתק) — הערה בצבע ענבר שלא נשלחת ללקוח
• תיוג חברי צוות עם @ והשלמה אוטומטית של שמות הצוות
• מונה 'תיוגים שלי' + מסנן לשיחות שבהן תויגת, והדגשת 'תויגת' על ההערה
• התיוג נראה רק לצוות — הלקוח לעולם לא רואה הערות או תיוגים

יבוא של 54 משלוחים ללקוח שמוגדר 'דורש ליקוט' הכניס לרשימת הליקוט רק 25 מהם, באופן אקראי. הסיבה השורשית: ההרשמה האוטומטית לליקוט (לפי הגדרת הלקוח requiresPicking) רצה רק כשה-webhook של ליונוויל ראה את המשלוח כ'נוצר' (created). אבל היבוא יוצר בעצמו את שורת המשלוח המקומית (upsertShipment), ובמקביל ליונוויל שולח webhook task_created לאותה משימה — מי שמנצח את המירוץ מקבל את פעולת ה-created, והמפסיד רואה 'updated'. סבב ה-/tasks/show הנוסף של היבוא הופך את זה למירוץ אמיתי שיכול ליפול לכל צד בכל שורה; כשהיבוא ניצח, ה-webhook ראה 'updated' ודילג על ההרשמה — והמשלוח נשמט בשקט מהליקוט. התיקון: ההרשמה רצה עכשיו גם על 'updated' (כל עוד לא 'skipped'), עם שמירה על ה-guard הקיים (מתעדכן רק כשגם pickingStatus וגם pickingType עדיין null) — כך שהיא idempotent, לא דורסת סוג-ליקוט שנבחר ביבוא, ולא מחזירה לחיים משלוח שהוסר ידנית (הסרה מנקה pickingStatus אך משמרת pickingType). בנוסף: תיקון נתונים רטרואקטיבי שהכניס לרשימה את 29 המשלוחים שנשמטו, וסקריפט תחזוקה backfill-stranded-picking (dry-run כברירת מחדל, ממוקד רק למשלוחים פתוחים שנוצרו לאחרונה). ולבסוף — הוסרה סתירת ה-UX שהזמינה את הבלבול מלכתחילה: כשבוחרים ביבוא לקוח שמוגדר 'דורש ליקוט', שדה הליקוט מקבל עכשיו כברירת מחדל את סוג הליקוט של הלקוח (עלוני שבת / מוצרים) במקום 'ללא ליקוט'. זה גם גורם ליבוא לקבוע את סטטוס הליקוט ישירות ומיידית, בלי תלות במירוץ ה-webhook.

כשחלק מהנציגים עובדים ב-business-inbox וחלק בוואטסאפ הרגיל, נוצר בלגן: צ'אטים נשארו 'לא נקראו' בממשק גם אחרי שקולגה טיפלה בהם בוואטסאפ, ולא היה שום סימן משותף מה טופל ומה לא. הסיבה השורשית — Green API אף פעם לא מדווח על קריאת צ'אט במכשיר אחר, ולכן אי אפשר לסנכרן את סימוני ה'נקרא' של וואטסאפ בין הממשק למכשירים המקושרים. הפתרון עוקף את המגבלה בשתי דרכים: (1) כשקולגה עונה ללקוח מהטלפון/וואטסאפ הרגיל — האות היחיד ש-Green API כן שולח (outgoingMessageReceived) — הצ'אט מסומן אוטומטית כנקרא גם בממשק, ומפסיק להיות מודגש כלא-מטופל; (2) סטטוס טיפול משותף חדש (חדש / בטיפול / טופל) + 'מי מטפל', שנשמר אצלנו ומשותף לכל הנציגים בממשק — מקור אמת אחד ל'מה טופל', בלתי תלוי בסימוני הוואטסאפ.

• סימון-נקרא אוטומטי: קולגה שעונה מהוואטסאפ הרגיל מסירה את סימון הלא-נקרא בממשק
• סטטוס טיפול משותף — חדש / בטיפול / טופל — עם שם הנציג שמטפל, גלוי לכל הצוות
• שליטה מהירה: מה-header של הצ'אט, מתפריט-ההקשר ברשימה, וצ'יפ סטטוס בכל שורה

קבלן/מנהל צוות ראה בדוח פורטל השליחים פחות ביקורים וחבילות נוספות ממה שביצע בפועל (למשל 26 ביקורים / 29 חבילות נוספות במקום 27 / 36). הסיבה: כשליונוויל שולח webhook של השלמת מסירה בלי driver_id — נפוץ במשימות קבלן/partner — ה-DELIVERY visit נשמר עם driverId=null, ואז נופל לגמרי מדוח השכר (computeManagerTenantEarnings משייך רק לפי driverId/managedByDriverId), ולוקח איתו גם את תוספת החבילות הנוספות. /tasks/show של ליונוויל כן מחזיק את הנהג גם כשה-webhook השמיט אותו, וסנכרון ה-POD ממילא מושך את ה-payload הזה — ולכן נוסף forward-guard חינמי (אפס קריאות ליונוויל נוספות) שמשלים את הנהג החסר במסירה באופן לא-הרסני (רק כשהנהג null, לעולם לא דורס שיבוץ קיים; managedByDriverId דרך הפותר הקנוני). בנוסף: תיקון נתונים חד-פעמי למסירות יתומות שנמצאו, וסקריפט תחזוקה backfill-completed-orphan-drivers לשחזור היסטורי (dry-run כברירת מחדל). רוב המסירות ה'יתומות' הן דווקא מסירות שבוצעו ע"י ספק חיצוני ואין להן נהג גם בליונוויל — אלו נכון שיישארו ללא שיוך ומחוץ לדוחות השכר.

כשקבלן דיווח 'אין מענה' והבוט שאל את הלקוח בקבוצה, תשובת הלקוח לא הועברה חזרה לקבלן. הסיבה: הלקוח ענה בציטוט השאלה (swipe-to-reply) — ו-Green API שולח הודעה כזו עם typeMessage='quotedMessage', שה-webhook לא זיהה כהודעת טקסט. ההודעה נשמטה בשקט לפני שהגיעה למנוע הרלייז (tryHandleScenarioRelayReply). אירוני, כי תשובה בציטוט היא דווקא האות החזק ביותר — היא מאפשרת שיוך דטרמיניסטי של התשובה ל-relay לפי ה-stanzaId המצוטט. התיקון: הוספת quotedMessage לענף הטקסט ב-webhook, כך שתשובות מצוטטות מנותבות כרגיל (הטקסט כבר יושב ב-extendedTextMessageData.text וה-stanzaId כבר חולץ).

בדף פרטי המשלוח באפליקציית השליח, הבלוק שכותרתו 'הערות לקוח' הציג את גוף הודעת הוואטסאפ שנשלחת ללקוח בעת הקמת המשלוח (שדה message) — טקסט תבנית ארוך ולא רלוונטי לשליח. הבלוק היה ממופה בטעות ל-shipment.message. הוראות המסירה/האיסוף האמיתיות ממילא כבר מוצגות בכרטיס הכתובת (address.notes), והערות השולח בבלוק 'הערות שולח' (shipmentNote/orgNote), כך שלבלוק לא היה תוכן לגיטימי להציג. התיקון: הסרת הבלוק לגמרי.

שליח ששיבץ על עצמו משימת איסוף בשיפנסט (דרך מסך השיבוץ במובייל, או עמוד האיסופים כשאין לו lionwheelId) גילה שהאיסוף נעלם מהאפליקציה. הסיבה: השיבוץ הזה לא נדחף לליונוויל, ולכן הסנכרון הבא של המשלוח החזיר את ה-PICKUP visit ללא נהג (driver_id = null) — וקוד ה-upsert דרס את השליח המקומי ל-null. ההגנה שמונעת דריסה כזו הייתה קיימת עד כה ל-DELIVERY בלבד (data-service.ts). התיקון: מרחיב את ההגנה גם ל-PICKUP — driver ריק נכנס על איסוף פירושו תמיד 'ליונוויל לא הכיר את השליח' ולא ביטול שיבוץ לגיטימי, ולכן שומרים תמיד על השיבוץ המקומי. שיבוץ מסירה לא הושפע.

לקוחות פורטל דיווחו שאינם רואים את 'הערת היעד' בדף פרטי המשלוח. ההערה למעשה כן הוצגה — אך ללא תווית, כטקסט אפור-מעומעם קטן עם אייקון גנרי בתחתית כרטיס היעד, כך שלא ניתן היה לזהות אותה כ'הערת יעד'. בצד הצוות, וגם בבלוק 'הערות למשלוח' שממש מתחתיו בפורטל, יש תווית ברורה. התיקון: הוספת תווית 'הערת יעד' מפורשת והצגת ההערה בצבע טקסט רגיל (לא מעומעם), בעקביות עם 'הערות למשלוח'. התיקון חל גם על מגירת התצוגה-המהירה ברשימת המשלוחים, שמשתמשת באותו רכיב.

תיקון ושדרוג של העוזר הפנימי בעקבות שיחה אמיתית שבה נתן תשובת מחיר שגויה: על 'מה עלות המסירה הממוצעת לצפת' הוא ענה ₪18 במקום ₪22. שתי סיבות שורש תוקנו. (1) הוא סינן לפי עיר המוצא (מאיפה המשלוח נאסף) במקום עיר היעד — נוסף סינון destinationCity נפרד לכל כלי החיפוש/הספירה/העלות, וההנחיות מבהירות ש'נשלח/נמסר ל-X' = יעד ואילו 'נאסף ב-X' = מוצא. ההבדל דרמטי: לצפת 2093 משלוחים לפי יעד מול 60 בלבד לפי מוצא. (2) לא היה לעוזר כלי מחירון — נוסף getDriverPricing שמציג את התעריף המוגדר של שליח/חברת שליחויות: תעריפי בסיס (מסירה, איסוף, איסוף עסקי, חבילה נוספת, החזרה) וחריגות תעריף פר-אזור/קו חלוקה. למשל זיפ: בסיס מסירה ₪18 אך אזור 12 (שכולל את צפת) = ₪22. ההנחיות מדגישות שערים שייכות לאזורי חלוקה, ושהמחירון המוגדר (getDriverPricing) שונה מעלות ממוצעת שנמדדה בפועל (getCostSummary, המושפעת מ-outliers ומהמדגם). בנוסף: getZoneDistributionDays יודע כעת לספור כמה משלוחים בקו חרגו מסף ימי-עסקים נתון (minBusinessDays → exceededCount/exceededPct). הכלי החדש מוגן בהרשאת פיננסים.

• כלי מחירון שליח חדש (getDriverPricing) — תעריפי בסיס + חריגות פר-אזור, מוגן בהרשאת פיננסים
• הבחנה בין עיר יעד (destinationCity) לעיר מוצא (sourceCity) — 'מסירה לצפת' כבר לא מסונן לפי עיר האיסוף
• getZoneDistributionDays סופר חריגות מסף ימי-עסקים (minBusinessDays) — 'כמה בקו X חרגו מ-3 ימים'
• שורש התקלה אומת בפרודקשן: זיפ בסיס ₪18, אזור 12 = ₪22; תשובת ₪18 לצפת הייתה שגויה

בטופס יצירת משלוח, בחירה בישובים מסוימים (למשל 'קרית אתא', 'הרצליה', 'קרית גת', 'קרית מוצקין') לא הציגה שום רחוב — רק ההודעה 'אין רחובות לישוב זה'. הסיבה: מאגר הישובים הפנימי שומר את השם עם דיגרף כפול ('קריית אתא'), בעוד מאגר הרחובות של data.gov.il שומר אותו בכתיב יחיד ('קרית אתא'). החיפוש ה-full-text מול data.gov.il אינו מגשר על הפרש ה-יי/וו, ולכן שאילתה עם השם הקנוני החזירה אפס רשומות. התיקון: שולחים שתי שאילתות — גם עם הכתיב הקנוני וגם עם גרסת הדיגרף המכווצת (יי→י, וו→ו) — וממזגים את התוצאות, וכן מכווצים את אותם דיגרפים בסינון הצד-שרת כך ששני הכתיבים משתווים. מיזוג (ולא החלפה) חיוני: 'פתח תקווה' דווקא נמצא רק בכתיב הכפול במאגר data.gov.il. אומת מול ה-API החי — קרית אתא: 0→352 רחובות, הרצליה: 0→775, קרית גת: 0→437.

במצב כהה תיבת הכתיבה של העוזר הפנימי הציגה שתי מסגרות מקוננות — האינפוט הפנימי (ה-textarea) קיבל רקע כהה משלו (dark:bg-input/30 של רכיב ה-Textarea הבסיסי) שלא הוטמע ברקע של המכל החיצוני, מה שיצר מראה של 'אינפוט בתוך אינפוט' עם טבעת כפולה. במצב בהיר לא הייתה בעיה כי אין וריאנט רקע כהה. תוקן בהוספת dark:bg-transparent! ל-textarea כך שהוא מתמזג ברקע המכל בשני המצבים, עם טבעת פוקוס יחידה על המכל בלבד — בדיוק כמו שכבר תוקן בשתי תיבות הכתיבה של האינבוקס.

נוסף כפתור צף לגלילה מהירה לתחתית הצ'אט (להודעה האחרונה) באינבוקס העסקי (business-inbox, Green API), בדיוק כמו שכבר קיים באינבוקס ההודעות (/messages/inbox). הכפתור מופיע רק כשהנציג גלל למעלה והתרחק מהתחתית (מעל ~200px), ולחיצה עליו גוללת בצורה חלקה להודעה האחרונה. ממוקם בפינה השמאלית-תחתונה מעל תיבת הכתיבה, בעיצוב זהה לכפתור באינבוקס השני. בנוסף: כשמגיעות הודעות חדשות מהלקוח בזמן שהנציג גלל למעלה, הכפתור מציג מונה של מספר ההודעות החדשות שטרם נראו (נספרות רק הודעות נכנסות — הודעות שהנציג עצמו שולח לא נספרות), והמונה מתאפס עם ההגעה לתחתית או בלחיצה על הכפתור.

שני שיפורים בהצגת הודעות באינבוקס ההודעות (Meta): (1) הופיע לעיתים 'קובץ מצורף' שלא ניתן לפתוח או להציג. הסיבה: כשלקוח שולח תוכן ש-WhatsApp Cloud API אינו מסוגל להעביר — מדיה לצפייה חד-פעמית (view once), סקר, או סוג הודעה לא-נתמך — מטא מוסרת את ההודעה עם type='unsupported' וללא שום מדיה (אין mediaId ואין קובץ להביא). ה-UI נפל ל-branch הגנרי והציג תיבת 'קובץ מצורף' מטעה, כאילו יש קובץ שנכשל להיפתח. כעת מוצגת הודעה ברורה: 'הודעה שאינה נתמכת בוואטסאפ — ייתכן שנשלחה מדיה לצפייה חד-פעמית או סוג הודעה שוואטסאפ אינו מעביר. לא ניתן להציג את התוכן.' שורש התקלה אומת בלוגי הפרודקשן (הודעת type='unsupported' שהגיעה מיד אחרי תמונה תקינה באותה שיחה). (2) עיצוב מחדש של כרטיס איש קשר משותף: במקום שורת טקסט אחת של 'שם · טלפון', מוצג כעת כרטיס עם ראשי-תיבות של השם, שם איש הקשר, וכל מספר טלפון בשורה נפרדת עם כפתורי פעולה — התקשרות (tel:), פתיחה בוואטסאפ (wa.me), והעתקת המספר ללוח. תומך בכמה אנשי קשר ובכמה מספרים לכל איש קשר, ומנרמל מספרים ישראליים לפורמט בינלאומי עבור wa.me.

שיפור המודל שנפתח בלחיצה על עגלה בתמונת המחסן. שני שינויים ברשימות המשלוחים (גם ב'כרגע במחסן' וגם בהיסטוריה השבועית): (1) מוצג כעת שם השולח (פרטי האיסוף) במקום שם הנמען — מתאים יותר לזרימת העבודה במחסן שבה מזהים משלוח לפי מקור; (2) ברקוד המשלוח הפך ללחיץ ופותח את דראוור פרטי המשלוח (BarcodeDisplay המשותף), בדיוק כמו בכל שאר האפליקציה — כולל העתקת מזהה ופתיחת דף המשלוח. נוסף השדה sourceName ל-API של היסטוריית המחסן.

השלמת ניתוח כל 54 שיחות העוזר הפנימי (24 השיחות הישנות שנותרו) חשפה שורת יכולות שהמשתמשים ביקשו שוב ושוב והעוזר סירב להן — למרות שהנתונים קיימים במערכת. בהמשך נוספו שתי יכולות דומיין: (א) getZoneDistributionDays — ממוצע וחציון ימי הפצה (ימי עסקים בפועל מהאיסוף עד המסירה, ללא שישי/שבת, חגים וערבי חגים, ולא כולל יום האיסוף) לפי קו/אזור הפצה, בשונה מ-getDeliveryTimeStats שסופר ימים קלנדריים לפי עיר; (ב) זיהוי 'כפולה' (משלוח הלוך-חזור: מסירה + איסוף חזרה) — getShipmentDetails מחזיר כעת isRoundtrip, כך ש'זה כפולה?' נענה. בנוסף תוקן סינון הקו להיות עמיד לרווחים ('11ב' = '11 ב', מה שהחזיר 0 קודם וכעת 5,160). נוספו שבע היכולות הקודמות, כל אחת אומתה מול נתוני פרודקשן: (1) שיבוץ שליח למשלוח (assignDriverToShipment) — היכולת המבוקשת ביותר, נדחתה 4+ פעמים ('תשבץ', 'אתה יכול ללמוד?'); מבצע שיוך ביקור, סנכרון לליונוויל וקידום סטטוס, מאחורי הרשאת עריכת משלוחים ואישור מהמשתמש. (2) סיכום עלויות ורווח (getCostSummary) — 'כמה עלות המסירה של לקוח X בחודש קודם' נדחה קודם כ'אין גישה לפיננסים', למרות שעמודות העלות מלאות על ~81 אלף משלוחים; מסכם עלות מסירה/איסוף, מחיר ליונוויל ורווח מוערך, מאחורי הרשאת פיננסים. (3) סינון לפי תאריך מסירה בפועל (deliveredFrom/deliveredTo) — 'נמסרו בחודש X' לא היה ניתן לסינון (רק לפי תאריך קליטה). (4) סינון לפי אזור/קו הפצה (zone/regionCode) — 'משלוחים בקו 11ב'. (5) סינון לפי שם שליח (driverName) — 'דוח משלוחים של נהג X'. (6) שליחה לקבוצת WhatsApp לפי שם ('שלח לקבוצת מישל') — קודם נדרש מזהה מספרי; כעת מתאים לפי שם הקבוצה/השליח, וגם חיפוש שליח לפי שם מזהה שם קבוצה. (7) getShipmentDetails מחזיר כעת את שליח האיסוף ואת כתובת המוצא — 'מי נהג האיסוף' / 'שנה יעד לכתובת המוצא' עובדים. במקביל תוקנו דפוסי כשל שחזרו בשיחות: העוזר סירב ליכולות שכבר היו לו (סימון נמסר, הערה פנימית, פנייה למחסן, חיפוש שליח בשם) — נוסף כלל מפורש 'אל תסרב ליכולת שיש לך'; הצגת קודי PENDING/SUCCESS כסטטוס מסירה (SUCCESS הוא סטטוס שליחת הודעה, לא מסירה) נאסרה; שאלות זהות והרשאה ('איך קוראים לי', 'יש לי גישה לפיננסים') נענות מההנחיות במקום 'אין לי גישה'; וסיבת כשל נרשמת בדיוק כפי שהמשתמש כתב, בלי ברירת מחדל ('אין מענה' ≠ 'תא קולי'). חילוץ helper משותף לפילטרים של כלי החיפוש מונע מהם להיפרד (באג drift שנתפס קודם).

• כלי חדש: שיבוץ שליח למשלוח מהצ'אט (מסירה/איסוף) — כולל סנכרון לליונוויל וקידום סטטוס, מאחורי הרשאה ואישור
• כלי חדש: סיכום עלויות ורווח ללקוח/טווח (מאחורי הרשאת פיננסים) — שאלה שנדחתה קודם למרות שהנתונים קיימים
• סינונים חדשים: תאריך מסירה בפועל, אזור/קו הפצה, ושם שליח — בחיפוש, בספירה ובדוח האקסל
• שליחה לקבוצת WhatsApp לפי שם ('שלח לקבוצת מישל') במקום מזהה מספרי; חיפוש שליח לפי שם מזהה גם שם קבוצה
• פרטי המשלוח כוללים כעת את שליח האיסוף וכתובת המוצא — 'מי נהג האיסוף' ו'החזרה לכתובת מוצא' עובדים
• כלל 'אל תסרב ליכולת שיש לך' — סימון נמסר, הערה פנימית, פנייה למחסן וחיפוש שליח לא נדחים יותר
• בלי הצגת PENDING/SUCCESS כסטטוס מסירה; שאלות זהות/הרשאה נענות מההנחיות; סיבת כשל בדיוק כפי שנכתב
• כל השבע אומתו מול נתוני פרודקשן (למשל עלות מסירה של לקוח בננה ליוני: 652 משלוחים, ₪10,930)
• ביקורת אדוורסרית לפני הדחיפה תפסה 6 באגים ותוקנו: שיבוץ שליח לפי שם עמום היה יכול לשבץ ולחייב את השליח הלא-נכון (כעת שגיאת ריבוי-התאמות), חישוב רווח מנופח, וסתירות בפרומפט
• כלי חדש: ימי הפצה בפועל (ימי עסקים מאיסוף עד מסירה) לפי קו/אזור הפצה; זיהוי 'כפולה' בפרטי המשלוח; סינון קו עמיד לרווחים
• ביקורת נוספת תפסה התאמת-קו רחבה מדי (קו '1' משך את 10–19) — עוגן לקוד מדויק או תת-קו, ואוחד בין שני מסלולי הסינון

המשך שיפור העוזר הפנימי על בסיס ניתוח מקיף של 29 שיחות אמיתיות מהחודש האחרון. סבב ראשון — שיחת 'לקוח בירושלים': העוזר ענה עם נמען במקום לקוח עסקי, הבטיח לזכור הוראה בלי לשמור אותה, לא היה לו כלי לחפש לקוחות לפי עיר, ו'התוודה' בשקר על המצאת תשובה שהייתה נכונה. תוקן: (1) כלי חדש לחיפוש וספירת לקוחות עסקיים לפי שם/אימייל/טלפון/עיר; (2) מילון ישויות: 'לקוח' תמיד = הלקוח העסקי, שדה שם-הנמען שונה שמו; (3) כלל עמידה מאחורי נתונים ואיסור דוגמאות בדיוניות; (4) הוראות מתמשכות נשמרות כתובנה לפני המענה; (5) פירוש שגיאות הקלדה לפי הקשר. סבב שני — ניתוח רוחבי של כלל השיחות חשף שני באגי תשתית שגרמו ללולאות 'עדכנתי ✅ / לא עדכנת' מתסכלות: מטמון הפעולות (idempotency) שמר גם כישלונות, כך ש'נסה שוב' החזיר את הכישלון השמור בלי להריץ מחדש — תוקן כך שכישלון לא נשמר; וכלי הכתיבה (עדכון סטטוס/כתובת/פנייה) איתרו משלוח רק לפי ברקוד מדויק או מזהה פנימי, בעוד שכלי הקריאה מאתרים גם לפי מזהי partner — אוחד האיתור כך שמה שנמצא בקריאה נמצא גם בעדכון, כולל זיהוי ברקוד שהועבר בטעות כמזהה. נוספו: כלי סטטיסטיקת זמני מסירה (ממוצע וחציון ימים מקליטה עד מסירה, לפי עיר או השוואת ערים — שאלה שחזרה שוב ושוב וגרמה לקריסת השיחה); סינון לפי עיר מוצא ('משלוחים שנאספו בירושלים'); העלאת תקרת סבבי הכלים מ-5 ל-8 והחלפת הודעת 'לא הצלחתי לעבד את הבקשה' הסתמית בהסבר כן עם הצעה לפצל; וכללי כנות דיווח: הצלחה מדווחת רק מתוצאת הכלי של אותו סבב, אסור למחזר מזהי רשומה מפעולות קודמות, ו'לא עדכנת' מפעיל אימות מחדש במקום חזרה על הודעת ההצלחה. זרימות שהצוות לימד בשטח שוב ושוב קובעו כברירת מחדל: ברקוד + סיבת כשל → סימון נכשל + הודעה לשולח (לא לשליח); עדכון פרטים → הצעת עדכון לשליח בכל סטטוס; הודעות לשליחים בלי 'שלום' ו'תודה' ותמיד עם מספר המשלוח. סבב הביקורת האדוורסרי על השינויים תפס וסגר שלושה באגים לפני הדחיפה: עדכון כתובת שכתב למזהה הגולמי במקום למזהה שנפתר (נתיב הברקוד קרס וגם חסר סינון tenant); קריסת overflow כשברקוד בן 10–12 ספרות הועבר כמזהה מספרי (INT4); ואיתור לא-דטרמיניסטי כשאותו מספר הוא ברקוד של משלוח אחד ומזהה-partner של אחר — נפתר עם קדימות לברקוד (אומת מול 3 התנגשויות חיות בפרודקשן). בנוסף נוקו 21 רשומות כישלון שכבר היו במטמון.

• תוקנו שני באגי תשתית שגרמו ללולאות 'עדכנתי ✅ / לא עדכנת': מטמון פעולות ששמר כישלונות, ואיתור משלוח שונה בין קריאה לכתיבה
• כלי חדש: סטטיסטיקת זמני מסירה — ממוצע וחציון מקליטה עד מסירה, לפי עיר או השוואת ערים בקריאה אחת
• כלי חדש: חיפוש וספירת לקוחות עסקיים לפי שם / אימייל / טלפון / עיר
• כנות דיווח: הצלחה מדווחת רק מתוצאת הכלי בפועל; 'לא עדכנת' מפעיל אימות מחדש במקום חזרה על אותה הודעה
• זרימות שהצוות לימד קובעו כברירת מחדל: דיווח כשל → הודעה לשולח; עדכון פרטים → עדכון לשליח בכל סטטוס; הודעות בלי נימוסים מיותרים
• סינון חדש לפי עיר מוצא ('נאסף בירושלים'), תקרת שלבי עיבוד הועלתה, והודעת הכישלון הסתמית הוחלפה בהסבר שימושי
• 'לקוח' תמיד = הלקוח העסקי; הוראות מתמשכות נשמרות כתובנה לפני המענה; בלי דוגמאות בדיוניות
• ביקורת אדוורסרית לפני הדחיפה תפסה 3 באגים: כתיבה למזהה הלא-נכון, קריסת INT4 על ברקוד ארוך, ואיתור לא-דטרמיניסטי בהתנגשות ברקוד/מזהה-partner (אומת מול פרודקשן)

שדרוג מקיף לעוזר ה-AI הפנימי, בעקבות ניתוח שיחה אמיתית שבה משתמשת ביקשה 'דוח של כל המשלוחים שנאספו בחודש קודם' והעוזר נתקע: הוא לא ידע מה התאריך הנוכחי (ניחש 'נובמבר 2024'), לא היה לו סינון לפי תאריכים, הוא הוגבל ל-50 שורות בלי יכולת ייצוא, והוא חזר על אותן שאלות הבהרה פעמיים. מה שתוקן: (1) הזרקת התאריך הנוכחי (שעון ישראל) להנחיות העוזר, כולל חישוב מפורש של 'חודש קודם' — ביטויי זמן יחסיים מחושבים מעכשיו לבד ואסור לו לשאול עליהם; (2) כלי חדש exportShipmentsReport — העוזר מפיק דוח אקסל מלא (עד 20,000 שורות, כל עמודות המשלוח, RTL) ומחזיר קישור הורדה בצ'אט; ההורדה עוברת דרך מסלול מאובטח שגוזר את ה-tenant מה-session ודורש הרשאת צפייה במשלוחים; (3) סינון תאריכים חדש (dateFrom/dateTo, שעון ישראל) וסינון החרגת-סטטוסים (excludeDeliveryStatuses) בכלי הספירה, החיפוש והדוח — 'לא כולל חדשים ומבוטלים' עובד עכשיו באמת; (4) כללי התנהגות חדשים: סבב הבהרה אחד לכל היותר עם ברירת מחדל מומלצת, איסור לחזור על שאלה אחרי תשובה כללית ('הכל'), איסור להציג למשתמש קודי סטטוס פנימיים או שמות כלים/מגבלות API, והעדפת ניסוח ניטרלי מגדרית; (5) תצפיתיות: קריאות הכלים ומספר הטוקנים של כל תשובת עוזר נשמרות עכשיו על ההודעה — מסך מעקב שיחות ה-AI של מנהלי הפלטפורמה מציג מעתה מה העוזר באמת עשה מאחורי הקלעים.

• העוזר יודע מה התאריך היום (שעון ישראל) ומחשב לבד 'חודש קודם' / 'אתמול' / 'השבוע'
• כלי חדש: הפקת דוח אקסל מלא מהצ'אט — עד 20,000 שורות עם כל פרטי המשלוח וקישור הורדה מאובטח
• הדוח מכבד הרשאות: נדרשת הרשאת 'ייצוא משלוחים', ועמודת המחיר מוצגת רק לבעלי הרשאת פיננסים
• סינון לפי טווח תאריכים והחרגת סטטוסים בכל כלי השליפה של העוזר
• סבב הבהרה אחד לכל היותר — תשובה כללית ('הכל') מפעילה ברירת מחדל במקום שאלה חוזרת
• בלי מונחים פנימיים מול המשתמש — סטטוסים בעברית בלבד, בלי שמות כלים ומגבלות API
• מעקב שיחות AI מציג כעת את קריאות הכלים והטוקנים של כל תשובה
• השינויים עברו ביקורת רב-סוכנית אדוורסרית לפני הדחיפה — 18 ממצאים אומתו ותוקנו (כולל דיוק תאריכים בימי מעבר שעון קיץ)

סבב אופטימיזציה מקיף שמכסה את כל שכבות המערכת, על בסיס אודיט אוטומטי של עשרה ממדי ביצועים שכל ממצא בו אומת פרטנית מול הקוד ומול בסיס-הנתונים החי לפני היישום — 43 שיפורים בסך הכול, כולם ללא שינוי התנהגות. בסיס נתונים: נוספו 8 אינדקסים חדשים בפרודקשן — הבולט שבהם על מזהה המעקב הציבורי של משלוח (public_id): עד היום כל לחיצה של נמען על קישור מעקב ב-WhatsApp סרקה את טבלת המשלוחים כולה (453MB); כעת זו שליפה נקודתית. אינדקסים נוספים: רשימת המשלוחים בפורטל הלקוחות לפי לקוח+תאריך, פריטי הזמנה לפי משלוח (רץ בכל webhook של ליונוויל), זיהוי שיחה בכל הודעת WhatsApp נכנסת/יוצאת, זיהוי לקוח מקבוצת WhatsApp בבוט, ציר 'תאריך מסירה' בטבלת המשלוחים, לולאת האישורים של תרחישי הבוט, ורשימת הגוביינא. שרת: שאילתות בלתי-תלויות שרצו ברצף הוסבו לריצה מקבילה בכל המסלולים החמים (משלוחים, איסופים, ליקוט, גוביינא, אנליטיקות שליחים, אינבוקס עסקי, שכר); הוסרו שליפות של ה-JSON הכבד של ליונוויל במקומות שקוראים רק סטטוס (פורטל, הודעות, לקוחות); חושב-שכר ומסך-לקוח שרצו שאילתה-פר-שורה אוחדו לשאילתות מקובצות; גזירת מפתח ההצפנה (PBKDF2, ‏100 אלף איטרציות, ~14ms של CPU חסום) נשמרת כעת בזיכרון במקום להיגזר מחדש בכל פענוח סוד — מורגש בכל webhook ובכל קריאת API לליונוויל; ה-webhook של Meta עונה 200 מיידית ומעבד את האירועים (תמלול, סיווג AI, הורדת מדיה) אחרי התשובה — כמו אחיו של ליונוויל ו-Green API; אימות ההרשאות (auth) עבר memoization פר-בקשה; cron סנכרון-המשלוחים-האחרונים שוכתב — 3 קריאות ליונוויל במקביל במקום טורית עם השהיות, וחלון הסריקה מתקדם לפי סנכרון-אחרון במקום לחזור על אותם 50 הישנים. דפדפן: מסך פרטי-המשלוח (533KB) נטען עד היום בכל עמוד ועמוד דרך רכיבי ה-layout — כעת הוא נטען רק בפתיחה ראשונה, מה שמקטין את ה-JS ההתחלתי של כל 121 עמודי המערכת; מעבד ה-Markdown של הצ'אטים (142KB) ויצוא האקסל של הרווחיות (430KB) נטענים רק בשימוש; עמוד יומן-העדכונים הפסיק לארוז את כל קובץ היומן (955KB) לדפדפן; החיפוש הגלובלי הפסיק לגרור את שכבת ה-API לתוך ה-bundle של כל עמוד; כל מנגנוני ה-polling (אינבוקס עסקי, נוכחות, התראות, באנרים) מושהים כשהטאב מוסתר; חיפוש במבט-המחסן ממומש כעת עם memoization במקום למיין מחדש את כל האזורים בכל הקשה. אפליקציית שליחים: ציור פוליגון במפה הפסיק לרנדר מחדש את כל המרקרים בכל תזוזת אצבע (memoization מלא של שכבות המפה); ריקון תור הפעולות באופליין מרענן את רשימת היום פעם אחת בסוף במקום פעם לכל פעולה. נסגר גם דוח הביקורת: סריקת code-review רב-זוויתית על כל השינויים לפני הדחיפה, עם תיקוני המשך (מטמון רכיבים שנטענו, איחוד helper של 'היום הישראלי', ביטול סריקת regex חוזרת בהודעות סטרימינג). בהמשך היום נכנס הסבב השני — פריטי ה-backlog שדרשו שינוי התנהגות מבוקר: שיבוץ שליח המוני עונה כעת מיידית (העדכון המקומי, יומן הפעולות ורשומת-השחזור נשמרים לפני העבודה האיטית; סנכרון ליונוויל, שידורים וקידום סטטוס רצים ברקע אחרי התשובה — סוף להמתנה של דקות על לאסו של מאות משלוחים); רשימת המשלוחים בפורטל הלקוחות והחיפוש הגלובלי קוראים את עמודת הסטטוס הממופתחת במקום ה-JSON הכבד; אישורי ליונוויל ו-Summit נשמרים במטמון ל-5 דקות עם פינוי מיידי בשמירת הגדרות; אישור התחשבנות מעדכן את כל הגוביינות בפעולה אחת במקום עד 100; ה-webhook של ליונוויל חוסך משיכות /tasks/show כפולות ומדלג על שכתוב פריטי הזמנה שלא השתנו; מנוע העלויות מדלג על כתיבות זהות במקום לשכתב את כל יום-הנהג בכל אירוע; מילון היישובים לאוטו-השלמה במטמון משותף (גם לפורטל); ובאפליקציית השליחים — polling נעצר במסכים שאינם בפוקוס, הטוקן נשמר בזיכרון במקום קריאת keychain בכל בקשה, נקודות GPS נשלחות ב-batch אחד, וספינר הרענון מופיע רק במשיכה ידנית. חולצו גם שני hooks משותפים (polling מודע-נראוּת שחונה את הטיימר בטאב מוסתר, ו-lazy-loading של רכיבים) שהחליפו ~12 עותקים ידניים. גם סבב זה עבר code-review רב-זוויתי לפני הדחיפה, כולל תיקון רגרסיה שנתפסה בביקורת (תגי סינון 'מצב משלוח' בגוביינא הראו 0 במצב ברירת-מחדל — הוחזר). לסיום נסגר גם הפריט הכבד האחרון: אימות ההרשאות רץ עד היום כמעט בכל בקשה (2 שאילתות DB טוריות לכל קריאת auth של משתמש צוות, ואחת לכל קריאה של משתמש פורטל) כי מנגנון ההשהיה של פעם-בדקה לא נשמר בפועל; כעת מטמון בזיכרון אוכף את הקצב המתוכנן — בדיקה אחת לכל היותר בדקה פר משתמש — עם שמירה מלאה על הסמנטיקה האבטחתית (משתמש מושבת לעולם לא נשמר במטמון, ושינוי הרשאות פורטל מפנה את המטמון מיידית). השינוי עבר סקירת אבטחה אדוורסרית ייעודית (נעילת משתמש מושבת, דליפת תפקידים בין טננטים, התחזות, החלפת טננט) — ואושר. הסבב הרביעי סגר את השאריות: האינבוקס העסקי עבר בידוד רינדור — תיבת הכתיבה הופרדה לרכיב עם state מקומי, כך שהקלדה מרנדרת רק אותה ולא את כל רשימת השיחות וציר ההודעות (שגם קיבלו memo ובניית ציר ממוזכרת) — ההקלדה בצ'אט חלקה גם בשיחות ארוכות; רשימת ההודעות הפסיקה לשלוף את ה-JSON הכבד (אומת שאף צרכן חי לא קורא ממנו); ארבע לולאות הסנכרון הידניות מול ליונוויל אוחדו ל-helper אחד עם knob קצב יחיד; ובונוס אבטחה — משתמש פורטל שהושבת מנותק כעת מיידית (במקום להמשיך עד תפוגת ה-token), וביטול הרשאה תופס בבקשה הבאה — באפס עלות, על גב שאילתה שכבר רצה בכל בקשה.

• 8 אינדקסים חדשים בפרודקשן — עמוד המעקב הציבורי ירד מסריקת 453MB לשליפה נקודתית בכל קליק על קישור מעקב
• 533KB ירדו מה-JS ההתחלתי של כל 121 עמודי המערכת — מסך פרטי-המשלוח נטען רק בפתיחה בפועל
• גזירת מפתח הצפנה נשמרת בזיכרון — חוסך ~14ms של CPU חסום בכל webhook וכל קריאת ליונוויל
• שאילתות מקביליות בכל המסלולים החמים — משלוחים, איסופים, ליקוט, גוביינא, אנליטיקות, אינבוקס, שכר
• ה-webhook של Meta עונה מיידית ומעבד ברקע — סוף ל-retries של Meta על תשובות איטיות
• כל ה-polling מושהה בטאבים מוסתרים — פחות עומס על השרת ועל הסוללה
• אפליקציית שליחים: ציור אזור במפה חלק (בלי רינדור כל המרקרים בכל תזוזה), וסנכרון אופליין מרענן פעם אחת במקום N פעמים
• cron הסנכרון מתקדם בחלון במקום לחזור על אותם 50 משלוחים, עם 3 קריאות ליונוויל במקביל

לפורטל השליחים נוסף טאב שלישי — 'יעד שבת' — שמציג לשליח את משלוחי יעד-השבת של הפרשה הקרובה שטרם נמסרו. הפרשה הקרובה נגזרת ממקור האמת היחיד במערכת (getUpcomingShabbat מ-@workspace/shared, שעון ישראל), וכותרת הטאב מציגה את שם הפרשה. כלל הנראות זהה לטאב המשלוחים המעוכבים: (1) משלוח המשובץ על השליח או על שליחי המשנה שלו — בכל אזור; (2) משלוח שאינו משובץ על אף שליח — רק אם הוא באחד מאזורי האחריות שלו; (3) משלוח המשובץ על שליח אחר — לא מוצג. מוצגים רק משלוחים פתוחים (שטרם נמסרו). כל שורה לחיצה ופותחת מגירת פרטים עם ניווט (Waze / Google Maps) והתקשרות, בדיוק כמו בטאב המעוכבים, וקיימים אותם סינון-קטגוריה (הכל / משובצים עליי / באזורי האחריות) וסינון-אזור. אגב כך חולצה תשתית תצוגת-הרשימה המשותפת (PortalShipmentList) המשמשת כעת גם את המעוכבים וגם את יעד השבת.

• טאב 'יעד שבת' בפורטל, עם שם הפרשה הקרובה ומונה משלוחים
• אותו כלל נראות של המעוכבים: משובץ עליי/צוות (כל אזור) או לא-משובץ באזורי האחריות; משובץ על אחר מוסתר
• רק משלוחים פתוחים (שטרם נמסרו) של הפרשה הקרובה
• לחיצה על משלוח → פרטים + ניווט Waze/Google Maps + התקשרות, וסינון לפי אזור

עד היום עלות איסוף/מסירה פר-משלוח חושבה אך ורק ממחירון השליח, ולשליח שכיר (שעתי) בלי מחירון נרשמה עלות 0 — כך שהמשלוחים שהוא ביצע נראו ברווחיות כאילו לא עלו כלום, בעוד השכר שלו חי רק בדוח השכר. מעכשיו, שליח מסוג 'שכיר' עם רשומת עובד מקושרת ותעריף שעתי — וללא מחירון — מקבל תמחור אוטומטי לפי שכר: עלות היום מחושבת מהמשמרות שהחתים בנוכחות (שעות נטו × תעריף שעתי, כולל שעות נוספות 125%/150% לפי כללי העבודה של הארגון ונסיעות יומיות), ומתחלקת שווה-בשווה בין נקודות האיסוף והמסירה שהשלים באותו יום. דוגמה: שכר יום של 500 ₪ על 25 נקודות = 20 ₪ לנקודה. החלוקה נשמרת כ-snapshot על כל משלוח (עלות איסוף/מסירה) ומזינה את כל תחשיבי הרווחיות בדיוק כמו עלות מבוססת-מחירון. העלות מתעדכנת אוטומטית בסיום משמרת (החתמת יציאה), בעריכת/מחיקת/אישור/דחיית משמרת ובהוספת משמרת רטרואקטיבית — ברקע, בלי להאט את ההחתמה — וריצת איזון לילית מתקנת את שלושת הימים האחרונים ליתר ביטחון. בריחוף על עלות בכרטיסיית התמחור של משלוח מוצג הפירוק המלא: שכר היום, שעות נטו, תעריף, ומספר המשימות שהשכר חולק ביניהן. מחירון מוגדר תמיד גובר (גם לשכיר), שכיר במשכורת חודשית גלובלית אינו מחולק (אין פילוח יומי משמעותי), ושליח-מנהל עם סאב-שליחים מוחרג — חיוב מנהל מחייב מחירון. אגב העבודה אוחד גם חישוב 'היום הישראלי' (עוגן אזור-זמן Asia/Jerusalem) ל-helper משותף אחד בין מנוע הרווחים למנוע ה-snapshots, ומשלוחים שנמחקו (סל מיחזור) הוחרגו מחלוקת השכר כדי שחלק מהעלות לא ייעלם מהדוחות. בהמשך תוקנה תקלה שהתגלתה בשטח מיד אחרי ההמרה של שליח קיים לשכיר: עריכת שליח ששמרה שדה 'מזהה ליונוויל' ריק ניתקה את השליח מליונוויל, וה-webhook הבא יצר אוטומטית שליח כפול — וכל המשלוחים החדשים שובצו לכפיל במקום לשכיר. שלושה תיקונים: (1) סנכרון הנהגים מזהה כעת מזהה ליונוויל לא-מוכר ששייך לשליח קיים (התאמת טלפון מנורמלת) ומקשר אותו מחדש במקום ליצור כפיל; (2) בעדכון שליח, שדה מזהה ליונוויל שלא נשלח כלל שומר על הערך הקיים (רק ריקון מפורש מנתק); (3) הוולידציה מקבלת כעת גם מזהה מספרי — כפתור הפעיל/לא-פעיל בדף השליח שלח מספר ונפל על ולידציה. הנתונים בפרודקשן תוקנו ידנית: הכפיל אוחד חזרה לשליח המקורי (29 ביקורים הוחזרו, המזהה שוחזר). בהמשך היום תוקן באג בטבלת המשלוחים: ספירות הפילטרים בחלונית הסינון (למשל 'שובץ לשליח איסוף — 78') לא תאמו את מספר השורות שהוצגו בפועל אחרי בחירת הפילטר. הספירות חושבו תמיד לפי תאריך יצירת המשלוח, בעוד הטבלה כיבדה את בורר שדה-התאריך (תאריך מסירה / איסוף / קליטה במחסן) — כך שבכל בחירה של שדה תאריך שאינו ברירת המחדל המספרים בפילטר לא שיקפו את התוצאות. כעת הספירות מסוננות לפי אותו שדה תאריך בדיוק כמו הטבלה, ובנוסף הן מביאות בחשבון גם את מסנן סטטוס התפעול ואת מסנני השדות המותאמים-אישית, שעד כה הוחלו על הטבלה בלבד. אגב התיקון אוחדה התנהגות מסנן השדות המותאמים-אישית לחיפוש שאינו רגיש לאותיות גדולות/קטנות בכל המסלולים, ועדכוני שורות חיים (SSE) מכבדים כעת גם את מסנני סוג-המשימה וסטטוס-התפעול — משלוח חדש שלא תואם את הפילטר הפעיל לא יתווסף יותר לטבלה המסוננת בזמן אמת. בנוסף (התראות מערכת): חוזק ערוץ ההתראות למנהל נגד הצפה — מפתח מניעת-הכפילויות מנורמל כך ש-request-id ומספרים דינמיים בהודעת השגיאה לא עוקפים עוד את חלון ההשתקה של שעה, ונוספה תקרת פרץ (עד 4 התראות ב-5 דקות) כך שתקרית תשתית רוחבית, כמו מיצוי connection pool, לא מציפה את המנהל במטח הודעות. בהמשך נוספו שני שיפורים שצפו מחקירת 'השליח הנעלם': (א) רמז חיפוש חוצה-טאבים בטבלת השליחים — כשחיפוש לא מוצא תוצאות בטאב הנוכחי אך קיימות התאמות בטאבים אחרים (פעילים / לא פעילים / קבלנים חיצוניים), מוצג באנר עם צ'יפים לחיצים שמעבירים ישירות לטאב הרלוונטי עם מונה התאמות — כך שליח לא 'נעלם' רק כי הוא מסווג בטאב אחר. (ב) הקשחת multi-tenancy בקריאת משלוחים: מסלול שליפת משלוח לפי ברקוד לא סינן לפי ארגון — משתמש מחובר של ארגון אחר יכול היה לקרוא משלוח זר לפי ברקוד (הברקוד ייחודי כלל-מערכתית); נוסף סינון tenant מחייב. בנוסף, בכל מסלולי הקריאה של משלוח/ביקור, נהג שמשויך לביקור אך שייך לארגון אחר (driverId פגום/היסטורי) מוסתר מהתשובה במקום להדליף שם וטלפון של שליח זר — הביקור מוצג כלא-משובץ. בהמשך טופלה מן היסוד גם האיטיות של סינון בטבלת המשלוחים ובדף שיבוץ האיסופים (סימון סטטוס בפילטרים 'חשב' שניות ארוכות, ובעומס אף הפיל בקשות אחרות): כל שאילתות הסטטוס חילצו את הסטטוס מתוך ה-JSON הגולמי הכבד של ליונוויל בכל שורה מועמדת (כ-5KB לשורה על פני מאות אלפי שורות), במקום להשתמש בעמודת הסטטוס הממופתחת שקיימת בבסיס הנתונים מאז יוני ומסונכרנת אוטומטית. שש נקודות קצה (רשימת משלוחים, ספירות פילטרים, מפה — וכן שלישיית שיבוץ האיסופים) הוסבו לעמודה הממופתחת: ספירת הסטטוסים ירדה מ-16 שניות לשנייה אחת, וסינון סטטוס מ-4.4 שניות ל-0.2 שניות — פי 20 ומעלה, עם תוצאות זהות (אומת מול נתוני הפרודקשן). נוסף אינדקס חדש לסינון לפי 'תאריך קליטה במחסן' (1.6 שניות → 0.5), ושאילתות ספירת הפילטרים פוצלו לשתי קבוצות כך שבקשה בודדת לא תתפוס עוד את כל מאגר חיבורי בסיס-הנתונים — הגורם לתקלות העומס החוזרות של החודש האחרון. תוקן גם החיפוש הגלובלי: הדבקת מספר ארוך (טלפון ללא מקפים, מזהה שותף) הפילה את כל החיפוש בשגיאת שרת במקום להחזיר תוצאות — כעת ערך מספרי שגדול מדי בשביל להיות מזהה משלוח פנימי פשוט מדולג, והחיפוש הטקסטואלי (ברקוד/טלפון/מזהי שותף) ממשיך לעבוד כרגיל. שופר גם ייצוא האקסל של טבלת המשלוחים, שסבל מאותה איטיות ביתר שאת (ייצוא מסונן ארך יותר מ-10 דקות): מלבד האצת השאילתות עצמן, מנגנון הדפדוף של הייצוא הפסיק להריץ מחדש את שאילתת ספירת-הכול הכבדה על כל עמוד ועמוד (היא רצה כעת פעם אחת בלבד בתחילת הייצוא), נוסף טיפול חינני במגבלת קצב הבקשות — ייצוא גדול ממתין ומנסה שוב במקום להיכשל באמצע — והטוסט מציג התקדמות חיה: 'מייצא X מתוך Y שורות'. בנוסף (אפליקציית שליחים — תשתית בנייה): יושרו ממצאי expo-doctor לקראת הבנייה הבאה לחנות — הוסר מפתח supportsRtl לא-חוקי מ-app.json (תבנית ה-manifest של Expo כבר כוללת אותו כברירת מחדל, ה-RTL נשמר), תצורת Metro משמרת את תיקיות המעקב של ברירת המחדל, וחמש חבילות Expo יושרו לגרסאות ה-SDK — 18/18 בדיקות עוברות. בנוסף (נוכחות — עובדים מזדמנים): לכל כניסת משמרת נוסף שדה חובה 'סוג עבודה' — ליקוט / עבודת מחסן / שירות לקוחות / אחר. בבחירת ליקוט נפתחת בחירת לקוח חובה מתוך קומבובוקס עם חיפוש שמציג רק לקוחות עם ליקוט פעיל (נגיש גם לתפקיד מנהל עובדים, בלי לחשוף את מודול הלקוחות המלא), ולכל משמרת ניתן לצרף הערה חופשית — למשל פירוט כשנבחר 'אחר'. סוג העבודה ולקוח הליקוט מוצגים בטבלת הכניסות, בהיסטוריה החודשית ובכרטיסי המובייל, והחיפוש בטבלה מאתר כניסות גם לפי שם לקוח הליקוט. בנוסף (סנכרון חנויות — בריאות חיבורים): נבנה מנגנון בריאות לחיבורי חנויות (קונימבו, אישופ, WooCommerce, nopCommerce, CashCow) — חיבור שנכשל שוב ושוב (טוקן שבוטל בחנות, חסימת Cloudflare) נכנס ל-backoff מדורג של עד שעה במקום לירות את אותה שגיאה כל 5 דקות ולהציף את יומן הפרודקשן ואת ערוץ ההתראות למנהל (התראה אחת בתחילת רצף כשל; החזרות יורדות לרמת אזהרה). השגיאה מסווגת להודעה קצרה וברורה בעברית — למשל 'חסימת Cloudflare — ה-IP עדיין לא ברשימה הלבנה' במקום עמוד HTML שלם — נשמרת על החיבור ומוצגת בפורטל הלקוח על כרטיס החנות. סנכרון מוצלח, עדכון פרטי חיבור, בדיקת חיבור מוצלחת או הפעלה מחדש של החיבור מאפסים את המנגנון מיידית כך שברגע שהתקלה נפתרת (אצלנו או אצל הספק) הסנכרון חוזר תוך דקות. בנוסף (ביצועים — השלמת מיגרציית עמודת הסטטוס): כל שאילתות הסטטוס שנותרו על ה-JSON הכבד של ליונוויל הוסבו לעמודת הסטטוס הממופתחת — 17 קבצים נוספים: מבט מחסן (+debug), פערי הפצה, אנליטיקות שליחים (כללי ופר-שליח), משלוחים מעוכבים בפורטל השליחים, טעויות מיון (+מפה), משלוחי כרטיס לקוח, ניקוי היסטורי, סנכרון משלוחים פתוחים, משיכת תמונות מסירה, דף הליקוט (+סטטיסטיקות) וכלי ה-AI (מנהל ולקוח) — נסגר סופית שורש תקלות מיצוי מאגר החיבורים של החודש האחרון. אגב כך תוקן באג שבו חיפוש בדף הליקוט דרס בשקט את פילטר הקטגוריה (שוטף/מזדמן) — שני הפילטרים חיים כעת יחד. כמו כן אובחן מקור מטח שגיאות ה-401 של קונימבו ביומן — חיבור בדיקה ישן עם טוקן מת שכבר הושבת; ואומת שחסימת ה-Cloudflare של אישופ עדיין פעילה מצד הספק (ממתינים לרישום ה-IP הקבוע שלנו ברשימה הלבנה).

• שליח שכיר שעתי ללא מחירון: עלות המשלוחים נגזרת מהשכר בפועל — שכר היום מהמשמרות מחולק שווה-בשווה בין המשימות שביצע
• החישוב זהה למנוע השכר: שעות נטו אחרי הפסקות, שעות נוספות 125%/150% לפי הגדרות הארגון, נסיעות יומיות
• עדכון אוטומטי בהחתמת יציאה ובכל שינוי משמרת (עריכה/מחיקה/אישור/דחייה/רטרו) — ברקע, בלי להאט את ההחתמה
• ריצת איזון לילית (cron) מתקנת את 3 הימים האחרונים — עמידות לעריכות בדיעבד
• tooltip פירוק מלא בכרטיסיית התמחור: שכר יום, שעות, תעריף שעתי ומספר המשימות בחלוקה
• מחירון מוגדר תמיד גובר; משכורת חודשית גלובלית ושליח-מנהל מוחרגים במכוון
• משלוחים בסל המיחזור מוחרגים מהחלוקה — העלות לא נעלמת מהדוחות
• רמז חיפוש חוצה-טאבים בטבלת השליחים — באנר עם קפיצה ישירה לטאב שבו נמצאו ההתאמות
• אבטחה: שליפת משלוח לפי ברקוד מסוננת כעת לפי ארגון, ונהג זר (cross-tenant) לעולם לא מוצג על ביקור
• עובדים מזדמנים: שדה חובה 'סוג עבודה' לכל משמרת (ליקוט / עבודת מחסן / שירות לקוחות / אחר), בחירת לקוח ליקוט חובה בקומבובוקס עם חיפוש, והערה חופשית אופציונלית
• סנכרון חנויות: חיבור כושל נכנס ל-backoff מדורג עם שגיאה מסווגת שמוצגת בפורטל — סוף להצפת יומן והתראות כל 5 דקות; מתאפס אוטומטית ברגע שהתקלה נפתרת
• הושלמה מיגרציית עמודת הסטטוס ב-17 הקבצים שנותרו (מחסן, פערים, אנליטיקות, ליקוט, AI, סנכרונים) — סגירה סופית של שורש תקלות מיצוי מאגר החיבורים

עד היום פתיחת חשבון לשליח חייבה שליחת מייל הפעלה שבו השליח קובע סיסמה בעצמו — חסם תפעולי משמעותי בקליטת שליחים. נוסף כפתור 'חשבון אפליקציה' בדף השליח: המנהל מזין אימייל וסיסמה התחלתית (או מייצר סיסמה אקראית בלחיצה), מוסר לשליח את פרטי הכניסה — והשליח נכנס לאפליקציה מיידית. השליח יכול להחליף סיסמה בכל שלב דרך 'שכחתי סיסמה'. בנוסף תוקן פער קריטי: חשבונות שנוצרו דרך זרימת הפורטל נוצרו ללא שיוך ארגון (TenantUser) ולכן לא יכלו להתחבר לאפליקציית השליחים כלל — מעכשיו כל יצירת חשבון (בשתי הזרימות) יוצרת את השיוך, ועדכון סיסמה ע"י מנהל מתקן אוטומטית חשבונות ותיקים חסרי שיוך. בהמשך היום תוקנה קריסת אפליקציה בפתיחת פרטי משלוח: ביקורים אמיתיים ללא שם איש-קשר (Visit.name ריק) הפילו את מסך הפרטים בחישוב ראשי-תיבות — ה-API מחזיר כעת נפילה לשם הלקוח מהמשלוח, והמסכים (פרטי משלוח, גוביינא) הוקשחו מול שם/טלפון ריקים כולל נטרול כפתורי חיוג/וואטסאפ כשאין טלפון. תוקנו גם ייבואים שבורים של TODAY_QUERY_KEY (רענון נתונים אחרי מסירה/כשל/גבייה לא עבד), נוסף גוון primary-400 חסר לפלטה, ותוקנו שגיאות טיפוסים — typecheck של אפליקציית המובייל נקי לחלוטין. בהמשך היום תוקנו שני ליקויים בדף פרטי השליח: (1) כרטיסיית 'פרטים אישיים' לא הציגה כתובת אימייל לשליחים שאינם שכירים — האימייל נשמר רק על רשומת העובד שקיימת לשכירים בלבד; כעת, כשאין רשומת עובד, מוצג האימייל של חשבון המשתמש המקושר (פורטל/אפליקציה). (2) כפתור 'עריכה' בדף השליח ניווט לטבלת השליחים הראשית ופתח שם את דיאלוג העריכה — כעת הדיאלוג נפתח ישירות בדף השליח, בלי לצאת ממנו. בנוסף (הודעות — צ'אט עסקי): כל הודעה יוצאת בצ'אט העסקי (business-inbox) מציגה כעת מי כתב אותה — אווטר ושם של הנציג ששלח מתוך המערכת (כמו בצ'אט הלקוחות), תג AI סגול להודעות שהבוט חיבר, חיווי ייעודי להודעות שהוקלדו ידנית בטלפון של העסק, וחיווי 'הודעה אוטומטית' להודעות טריגר/בוט שנשלחו דרך ה-API. גם ציטוט של הודעת נציג מציג כעת את שם הנציג במקום 'צוות' גנרי. הודעות ישנות (שקדמו לשינוי) ממשיכות להיות מוצגות עם אייקון צוות כללי. בהמשך היום תוקן כשל בהמרת שליח קיים לשליח שכיר: כאשר כבר הייתה רשומת עובד עם אותה תעודת זהות במודול העובדים, השמירה קרסה עם שגיאת מערכת גולמית באנגלית. כעת ההמרה מזהה את העובד הקיים ומקשרת אליו את השליח (תוך שמירה על פרטי ההתחברות של העובד), ואם הת"ז שייכת לעובד שכבר מקושר לשליח אחר — מוצגת הודעת שגיאה ברורה בעברית על שדה הת"ז. בנוסף, כל שגיאת כפילות נתונים במערכת (unique constraint) מוצגת מעתה כהודעה ידידותית בעברית במקום טקסט שגיאה טכני באנגלית. סבב תיקונים נוסף מבדיקות שטח של אפליקציית השליחים: (1) תור הסנכרון הלא-מקוון לא הופעל אחרי ביצוע פעולה — מסירה/גוביינא/הוכחת-מסירה המתינו עד מעבר רקע-חזית של האפליקציה; נוסף טריגר שמסנכרן מיידית עם כל פעולה, והתור ממשיך לעבד עד ריקון. זה היה גם השורש לכך שכפתור 'דווח על כשל' נשאר פעיל אחרי מסירה ושכפתורי הוכחת-המסירה ננעלו אחרי שמירה. (2) העלאת הוכחת מסירה פוצלה לבקשה-נפרדת-לכל-תמונה — בקשה מרובת תמונות (base64) חצתה את מגבלת גוף-הבקשה של Vercel (4.5MB) וה-413 שהוחזר תקע את התור כולו; 413 מסווג כעת ככשל קבוע שאינו חוסם את התור. (3) ציור פוליגון במפה היה בלתי-נראה (אך הבחירה עבדה) — טעינת סגנון MapTiler אחרי עליית המפה מחקה את שכבות הציור; המפה עולה כעת רק אחרי שהסגנון נטען, והחלפת סגנון גוררת רינדור נקי מחדש. (4) יכולת חדשה: שליח יכול להוסיף ולהסיר משלוח מהמסלול הפעיל — בלחיצה ארוכה על משלוח ברשימה או מתפריט מסך המשלוח (endpoint חדש /api/v1/mobile/route/stops). (5) לחיצה ארוכה על משלוח פותחת כעת גיליון פעולות מעוצב (התקשר / וואטסאפ / נווט / הוספה-הסרה מהמסלול) במקום דיאלוג נייטיבי שלא ניתן היה לסגור, וכפתור שלוש-הנקודות במסך המשלוח — שלא עשה דבר — מחווט לתפריט פעולות מלא כולל שיתוף פרטי משלוח. (6) כפתור הניווט פותח כעת Waze ישירות — canOpenURL מחזיר false באנדרואיד 11+ ולכן תמיד נפתחה Google Maps.

• כפתור 'חשבון אפליקציה' בדף השליח — יצירת חשבון עם אימייל + סיסמה התחלתית, ללא תלות במייל הפעלה
• מחולל סיסמאות אקראיות + כפתור 'העתק פרטי התחברות' למסירה מהירה לשליח בוואטסאפ
• מנהל יכול לאפס סיסמה לשליח קיים בכל שלב; השליח יכול להחליף אותה בעצמו אחר כך
• תוקן: חשבונות שליח שנוצרו דרך הפורטל לא יכלו להתחבר לאפליקציה (חסר שיוך ארגון) — נוצר אוטומטית בכל הזרימות
• תוקן: קריסת אפליקציית השליחים בפתיחת משלוח ללא שם איש-קשר + הקשחת מסכי פרטים/גוביינא מול נתונים חסרים
• תוקן: אימייל לא הוצג בפרטים אישיים לשליח קבלן (נופל כעת לאימייל חשבון המשתמש) + כפתור 'עריכה' פותח את הדיאלוג בדף השליח במקום לנווט לטבלה
• צ'אט עסקי: חיווי 'מי כתב מה' על כל הודעה יוצאת — אווטר + שם הנציג ששלח מהמערכת, תג AI לבוט, וחיווי נפרד להודעות מהטלפון של העסק ולהודעות אוטומטיות
• תוקן: המרת שליח לשכיר קרסה כשכבר קיים עובד עם אותה ת"ז — כעת השליח מקושר לרשומת העובד הקיימת, ושגיאות כפילות מוצגות בעברית
• אפליקציית שליחים: סנכרון מיידי של מסירות/גוביינא/הוכחות-מסירה (התור נתקע עד מעבר רקע-חזית) + העלאת תמונות מפוצלת שלא נתקעת במגבלת Vercel
• אפליקציית שליחים: שליח מוסיף/מסיר משלוח מהמסלול הפעיל, גיליון פעולות מעוצב בלחיצה ארוכה ובכפתור שלוש-הנקודות, ניווט נפתח ישירות ב-Waze, וציור אזור במפה נראה שוב

שיפורים לתצוגת 'משלוחים מעוכבים': (1) נוסף סינון לפי אזור הפצה — שורת צ'יפים אופקית מעל הרשימה, שמציגה את האזורים הקיימים בקטגוריה הנוכחית עם מונה לכל אזור. (2) לחיצה על שורת משלוח פותחת מגירה תחתונה עם פרטי המשלוח המלאים (כתובת מלאה, אזור, ברקוד, חבילות, טלפון, שיוך), וכפתורי פעולה: 'ניווט ב‑Waze', 'Google Maps' ו'התקשר ללקוח'. ה‑API של המעוכבים מחזיר כעת גם רחוב, מספר וטלפון לצורך הניווט וההתקשרות. בנוסף (סנכרון חנויות): ה‑cron של סנכרון הזמנות אישופ רושם כעת אזהרה מפורשת ביומן כאשר EGRESS_PROXY_URL אינו מוגדר — כדי שכשל תצורה בניתוב דרך ה‑proxy הקבוע לא ייראה בטעות כחסימה מצד אישופ. בנוסף (התראות מערכת): שוקם ערוץ התראות השגיאה למנהל — השליחה עוברת כעת על ה‑credentials של tenant ייעודי (SYSTEM_ALERT_TENANT_ID), מספר המנהל עבר ל‑ADMIN_ALERT_PHONE (עם תאימות לאחור ל‑TEST_PHONE) ומאומת לפני שליחה, נוסף מנגנון מניעת‑הצפה עמיד (התראה אחת לשעה לכל שגיאה, גם בין instances ב‑serverless), והוסרה האפשרות ללולאת התראות על כשל בערוץ ההתראות עצמו. בנוסף (הרשאות — סריקת מחסן): נוספה הרשאה ייעודית 'סריקת מחסן — קליטה ושיבוץ שליחים' (shipments:scan). עמוד הסריקה דורש כעת אותה במקום 'עריכת משלוחים', והיא הוענקה לכל התפקידים שיכלו לסרוק עד כה וגם למחסנאי (WAREHOUSE_WORKER) — כך שעובד מחסן יכול לבצע קליטת מחסן ושיבוץ שליחים בסריקה. בורר הנהגים במצב שיבוץ עבר ל-endpoint רזה חדש (/api/drivers/scan-options) שמחזיר שמות נהגים בלבד — פותר גם תקלה קיימת שבה מנהל מחסן ונציג שירות לא יכלו לטעון את רשימת הנהגים לשיבוץ, ובלי לחשוף למחסנאי את רשימת השליחים המלאה (טלפונים, ת"ז, משמרות). בנוסף (API ציבורי + תיעוד): לקראת אינטגרציית Datalogics, עמוד התיעוד /docs/api וקובץ openapi.yaml יושרו מול ההתנהגות בפועל לאחר ביקורת עומק — תוקנו כ-38 אי-דיוקים, בהם: שדות POST /api/v1/webhooks הנכונים (name חובה; הוסרו description/isActive ו-wildcard ["*"] שאינם נתמכים), סמנטיקת ביטול משלוח (canceledAt, idempotency, newStatus 'canceled'), ברקוד ייחודי כלל-מערכתי (לא פר-Tenant), price = מחיר משלוח (לא גוביינא), פירוט מקורות פליטה לכל אירוע webhook, ומגבלת קצב 10/דקה ל-test endpoint. יושרו גם התנהגויות קוד לחוזה המתועד: DELETE /api/v1/webhooks/{id} הפך ל-idempotent, תגובת endpoint הבדיקה עברה למעטפת הסטנדרטית ({success, data}), תאריך לא תקין ב-GET /shipments מחזיר 400 במקום 500, ה-User-Agent של webhooks יוצאים שונה ל-Shipnest-Webhooks/1.0, אירוע cod.collected נפלט כעת גם מגביית גוביינא באפליקציית הנהג (עד כה רק מסימון בממשק), ותגובות ה-customers מחזירות צורה אחידה בכל ארבעת ה-endpoints. בהמשך היום נוספו שני endpoints חדשים ל-API הציבורי עבור אינטגרציות צד-חנות (Datalogics): GET /api/v1/shipments?externalOrderId=… לאיתור משלוח לפי מזהה הזמנה במערכת המקור, ו-GET /api/v1/shipments/{barcode}/label להורדת מדבקת ה-PDF — אותה מדבקה כמו בממשק (ברקוד, אזור, גוביינא, לוגו לקוח), scope shipments:read, מוגבל 30/דקה, מכבד בידוד מפתחות פר-לקוח, וכל הורדה נרשמת ביומן הפעולות.

(1) המיני-מפה בתצוגת פרטי המשלוח השתמשה במפות Google (react-native-maps + PROVIDER_GOOGLE) ודרשה מפתח Google Maps API שלא הוגדר — כך שבבנייה לפרודקשן המפה הייתה מוצגת ריקה. הוחלפה למנוע MapLibre + MapTiler בסגנון העברית, בדיוק כמו מסך המפה הראשי; בוטלה התלות ב-Google Maps SDK, וחבילת react-native-maps והגדרת android.config.googleMaps הוסרו. (2) משתני הסביבה (EXPO_PUBLIC_API_BASE_URL, EXPO_PUBLIC_MAPTILER_KEY) חוברו ל-eas.json ל-profiles preview+production, כדי שבניית ה-AAB בענן לא תצא בלי כתובת השרת/מפתח המפה. (3) כפתור 'המשך עם Google' במסך הכניסה הפך למותנה — מוצג רק כשמוגדר EXPO_PUBLIC_GOOGLE_WEB_CLIENT_ID, כך שבודקים לא נתקלים בכפתור לא-פעיל עד שה-Google Sign-In יחווט במלואו. (4) versionCode קודם ל-2.

באזור האישי של השליחים נוסף מתג עליון 'הדוח שלי / משלוחים מעוכבים' (עם מונה אדום). התצוגה החדשה מציגה לשליח את המשלוחים המעוכבים הרלוונטיים אליו, לפי אותה הגדרת 'עיכוב' כמו דף פערי ההפצה של המשרד (סטטוס מסירה פתוח + חלפו ≥ סף ימי-עסקים של הטננט). כלל הנראות: (1) כל משלוח מעוכב שמשובץ עליו או על שליחי המשנה שלו — בכל אזור; (2) משלוח מעוכב שאינו משובץ על אף שליח — רק אם הוא באחד מ'אזורי האחריות' שלו; (3) משלוח המשובץ על שליח אחר — לא מוצג. לכל משלוח מוצג סטטוס: 'משובץ עליך' / 'במחסן' / 'בכשל' (או תרגום הסטטוס), מספר ימי העיכוב, העיר, האזור והברקוד. נוסף גם סינון פנימי: הכל / משובצים עליי / באזורי האחריות. לצורך כך נוסף שדה חדש בכרטיס השליח — 'אזורי אחריות' (מקביל ל'אזורים מורשים', בפורמט אזורי ליונוויל).

• מתג עליון בפורטל: 'הדוח שלי' / 'משלוחים מעוכבים' עם מונה אדום חי
• שדה חדש בכרטיס השליח: 'אזורי אחריות' — אזורי הפצה שהשליח מחוייב עליהם (נפרד מ'אזורים מורשים')
• משלוח מעוכב לא-משובץ מופיע לשליח רק אם הוא באזורי האחריות שלו; משלוח שמשובץ על שליח אחר לא מופיע
• משלוחים המשובצים על השליח או על שליחי המשנה שלו מופיעים בכל אזור
• סטטוס לכל משלוח: 'משובץ עליך' / 'במחסן' / 'בכשל', עם מספר ימי עיכוב וסינון לפי קטגוריה

בעמודות הכספיות של טבלת המשלוחים (מחיר בסיס, סה"כ לחיוב, עלות ליונוויל, עלות איסוף, עלות מסירה, סה"כ עלות, רווח) — הדרופדאון שנפתח בלחיצה על כותרת העמודה מציג כעת את סכום כל הערכים בעמודה. הסכום מחושב על *כל* המשלוחים התואמים לסינון הפעיל (כל העמודים, לא רק העמוד המוצג), ומכבד גם סינון-בכותרת-עמודה. כדי לא לעכב את טעינת הטבלה, הנתונים המלאים נשלפים באופן עצל רק בפתיחת הדרופדאון הראשון של עמודה כספית (עם אינדיקציית טעינה), ואז נשמרים ב-cache לשאר העמודות עד לשינוי סינון. הסכום כולל גם עלויות משוערות (projected) בדיוק כמו התצוגה, ומסומן ב-'~' ובהערה 'כולל אומדנים' כשיש בו ערכים משוערים.

• לחיצה על כותרת עמודת מחיר/עלות/רווח → סכום כל העמודה בראש הדרופדאון
• הסכום מחושב על כל המשלוחים המסוננים (כל העמודים), לא רק העמוד המוצג
• מכבד סינון-בכותרת-עמודה; כולל עלויות משוערות עם סימון '~'
• שליפה עצלה + cache — אפס עלות על טעינת הטבלה עד שפותחים סכום

(1) ייצוא ל-Excel: עמודות העלות (עלות איסוף, עלות מסירה, סה"כ עלות) והרווח ייצאו ריק כשהמשלוח עדיין לא סיים ביקור והעלות הייתה 'עלות משוערת' בלבד (projected) — למרות שהערך מוצג בבירור בטבלה. הייצוא קרא רק את העלות הבפועל והתעלם מהצפי. כעת הייצוא נופל חזרה לעלות המשוערת בדיוק כמו הטבלה, כולל סימון '~' לפני ערך שהוא צפי. (2) הטולטיפ של עלות משוערת ('צפי — מבוסס על מחירון השליח/אזור') נתקע פתוח: ריחוף מהיר על תאים רצופים פתח ערימת טולטיפים שלא נסגרו. הסיבה — ה-Tooltip נטען לא-מבוקר (defaultOpen) רק אחרי שהעכבר כבר נכנס לתא, כך ש-Radix פספס את אירוע הכניסה ולא סגר ביציאה. כעת ה-Tooltip מבוקר (open/onOpenChange) ונסגר ודאית ביציאת העכבר. (3) עמודת 'עלות ליונוויל' שונתה ל'מחיר ליונוויל' (זהו המחיר שהתקבל מליונוויל, לא עלות ביצוע).

שני תיקונים במנוע חישוב השכר (/attendance/payroll): (1) עובד עם 'שכר חודשי' (monthlyRate) קיבל עד כה ₪0 — החישוב הכפיל תמיד שעות×תעריף-שעתי והתעלם לחלוטין מה-monthlyRate. כעת עובד עם שכר חודשי מקבל את הסכום החודשי הקבוע ללא תלות במספר השעות שעבד (השעות עדיין נרשמות לתצוגה), בתוספת בונוסים וקצובת נסיעות. (2) כשלא הוגדר תעריף לאף עובד, 'חישוב שכר' דילג על כולם בשקט והחזיר '0 עובדים' בלי הסבר — מה שנראה כאילו הדף שבור. כעת המערכת מחזירה ומציגה בדיוק אילו עובדים דולגו ומדוע (לא הוגדר תעריף שעתי או שכר חודשי), כך שברור שצריך להשלים תעריף בכרטיס העובד.

בורר העיר והרחוב (עם החיפוש-לפי-שם-חלופי, רמז 'נקרא גם', וטעינת כל רחובות הישוב מ-data.gov.il) היה עד כה משוכפל inline רק בטופס יצירת המשלוח. חילצנו אותו לקומפוננטה משותפת <CityCombobox>/<StreetCombobox> (components/shared/CityStreetPicker.tsx) — מבוקרת לחלוטין (value/onChange) ותומכת בהחלפת endpoint כדי לשרת גם את ה-API של הצוות וגם את ה-API של הפורטל. טופס יצירת המשלוח עבר להשתמש בקומפוננטה המשותפת (הוסרו ~150 שורות state+JSX כפולות, ללא שינוי התנהגות), והבורר נוסף לשני מקומות שבהם עד כה הוזנו עיר ורחוב כטקסט חופשי: (1) טופס טיול מזדמן — כתובת יעד וגם כתובת מוצא; (2) עמוד הכתובות השמורות בפורטל הלקוחות. בכל המקומות הרחוב ננעל עד לבחירת עיר, ובחירת עיר מנקה רחוב שנבחר קודם.

• קומפוננטה משותפת <CityCombobox>/<StreetCombobox> — מקור אמת אחד, בלי דריפט בין טפסים
• טופס טיול מזדמן: עיר+רחוב עם השלמה אוטומטית ביעד ובמוצא (במקום טקסט חופשי)
• כתובות שמורות בפורטל: עיר+רחוב עם השלמה אוטומטית
• טופס יצירת המשלוח עבר לקומפוננטה המשותפת ללא שינוי התנהגות

בעקבות תקלה שבה סינון בתוך כותרת עמודה בדף 'פערי הפצה' צמצם תצוגתית ל-~20 שורות, אך 'בחר הכל' סימן את כל ~120 המשלוחים שברשימה ושינוי הסטטוס ל'הושלם' חל על כולם. שלושה תיקונים: (1) ב'פערי הפצה', 'בחר הכל' בוחר כעת רק את השורות הגלויות בפועל אחרי הסינון-בכותרת (getFilteredRowModel) במקום את כל הרשימה המסוננת-בשרת — כך שלא יסומנו שורות שהמשתמש לא רואה. (2) שינוי סטטוס מרובה דורש כעת אישור בדיאלוג עם ספירה מדויקת ('הפעולה תשנה את הסטטוס של N משלוחים ל...'), כפי שכבר קיים במחיקה. (3) שינוי סטטוס מרובה נרשם כעת כפעולת מאסה (BulkOperation, action=SET_STATUS) עם snapshot של הסטטוסים הקודמים — ולכן מופיע ב-/management/bulk-history וניתן לשחזור בלחיצת כפתור; השחזור מחזיר את additionalData.status לכל משלוח ודוחף את הסטטוס המשוחזר חזרה לליונוויל (מקבילות חסומה, best-effort).

• 'בחר הכל' בפערי הפצה מכבד את הסינון בכותרת העמודה — לא בוחר עוד שורות מוסתרות
• אישור חובה עם ספירה לפני שינוי סטטוס מרובה
• שינוי סטטוס מרובה ניתן כעת לשחזור מ-/management/bulk-history (כולל דחיפה חזרה לליונוויל)

באג איבוד-נתונים: שיבוץ שליח מסירה שבוצע בסריקת מחסן נמחק אצלנו אך נשאר בליונוויל. השיבוץ נשמר על ה-Visit (visit.driverId) ונדחף לליונוויל; אך כשהמשלוח משובץ לקבלן, ליונוויל מנהל אותו כמשימת partner נפרדת, ולכן ה-DELIVERY visit חוזר בסנכרון (webhook ו-cron sync-recent-shipments) ללא driver_id שניתן לפענח. נתיב ה-upsert ב-data-service דרס את visit.driverId המקומי ל-null על כל סנכרון — כך שבליונוויל הופיע הקבלן כשליח מסירה, ואצלנו 'אין שליח משובץ'. ה-cron מרענן מחזורית את כל המשלוחים האחרונים, ולכן הבאג פגע בהרבה משלוחים. התיקון: הסנכרון הנכנס כבר לא מאפס שליח מסירה מקומי קיים כאשר המשלוח נמצא בסטטוס 'יצא למסירה' (OUT_INVENTORY/IN_TRANSFER) גם לפני הסנכרון וגם אחריו וה-visit הנכנס בלי נהג ממופה — הוא רק קובע/מעדכן נהג כשיש נהג ודאי. מעבר ל'נקלט במחסן' עם שדה שליח ריק (החזרה למחסן) ממשיך לאפס שליח כרגיל, כי זה ביטול שיבוץ לגיטימי. נוסף סקריפט שחזור (backfill-wiped-delivery-drivers, dry-run כברירת מחדל) שמשחזר שיבוצים שכבר נמחקו, מתוך ה-audit log של הסריקות (driverId המקומי + זמן השיבוץ האמיתי).

בכרטיסיית 'תמחור ורווחיות' של דף המשלוח, עלות מסירה/איסוף לביקור שטרם הושלם מוצגת כ'צפי' (לפי מחירון השליח שהוקצה, או אומדן אזורי כשאין שליח/מחירון) — אך בטבלת המשלוחים עצמה אותן עמודות (עלות איסוף/מסירה/סה"כ עלות/רווח) קראו רק את ה-snapshot השמור ב-DB, שעדיין NULL/0 עד השלמת הביקור. התוצאה: משלוח שבדף שלו מוצגת עלות ~20 ₪ הראה בטבלה עלות 0 ורווח מנופח (הכנסה פחות 0). כעת ה-API של רשימת המשלוחים מחשב את הצפי בצורה מקובצת (projectPendingCostsForList — טוען ביקורים, מחירוני שליחי-החיוב ואת השליחים המורשים-לאזור פעם אחת לכל העמוד, במקום לולאה פר-משלוח) ומצרף projectedPickupCost/projectedDeliveryCost. הטבלה מציגה עלות אפקטיבית = snapshot ?? צפי, מסומנת ב-~ עם הסבר בריחוף, והרווח נגזר ממנה — כך שהטבלה והכרטיס תואמים. הצפי מחושב רק כשהעלות השמורה NULL, ורק תחת הרשאת FINANCE_VIEW. שיפור ביצועים (המשך): חישוב החיוב (computeShipmentListBilling) ואומדן הצפי (projectPendingCostsForList) רצים כעת במקביל (Promise.all) במקום בטור על הנתיב החם של רשימת המשלוחים — אחרי שחרור הפיצ'ר העמוד הואט, כי שתי סדרות ה-round-trips מול Accelerate נצברו זו אחר זו על כל טעינה אצל משתמשי פיננסים. בנוסף, העבודה הכבדה (חיוב + אומדן) רצה כעת רק כשעמודת תמחור/עלות/רווח גלויה בפועל — כשאף עמודה כזו אינה מוצגת הטבלה שולחת withPricing=0 וה-API מדלג על החישוב לגמרי (ברירת המחדל היא לחשב, כך ששאר צרכני ה-API לא הושפעו). ובצד-הלקוח: הטבלה אינה virtualized, וכל תא-אומדן עטף את הערך ב-Tooltip של Radix — מה שיצר עד אלפי אינסטנסים בו-זמנית בעמוד עמוס והאט מאוד את הרינדור; כעת ה-Tooltip נטען בעצלתיים, רק כשמרחפים מעל התא בפועל, כך שאפס עלות mount עד אז.

כרטיסיית הרווחיות (P&L) בדף הלקוח הייתה איטית מאוד ו'תקעה' את המסך בעת חישוב, גם בניווט מחודש לחודש. הסיבה: אומדן העלות למשלוחים הפתוחים (projectedCostForCustomer) הריץ את projectPendingCostsForShipment בלולאה סדרתית — עד 150 משלוחים, כל אחד בכמה שאילתות DB דרך Accelerate — כלומר מאות round-trips ברצף. כעת האומדן רץ במקביל ב-batches חסומים (concurrency=12), כך שזמן הקיר יורד מסכום-כל-הקריאות למקסימום-batch. בנוסף, רכיב הכרטיסייה הציג ספינר רק בטעינה הראשונה; בניווט חודש הוא הציג את הנתון הישן בלי שום חיווי ולכן נראה תקוע. כעת מוצג ספינר בכל שליפה (כולל מעבר חודש), עם עמעום עדין של הנתון הקודם — כך שתמיד יש משוב למשתמש. הרחבה (לשונית 'רווחיות' ב-פיננסים): הטבלה של כל-הלקוחות נכשלה לעיתים בשגיאת 500 כי שליפת כל משלוחי החודש בבת אחת חרגה ממגבלת התגובה של Accelerate (5MB) — והקליינט בלע את השגיאה ונשאר על נתון ישן ('תקוע'). כעת השליפה מחולקת ל-batches לפי cursor (כל תגובה קטנה מהמגבלה); חיפושי אזור-לפי-עיר (~30 ברצף) וחישובי עמלות-הסוכן רצים במקביל עם תקרת מקביליות ונשמרים במטמון; ובלשונית עצמה נוסף חיווי טעינה בכל שליפה ומצב-שגיאה גלוי, במקום מסך שנראה תקוע.

נוספה לשונית ייעודית 'רווחיות' תחת פיננסים (לצד תזרים ומאזן), המרכזת את דוח הרווח-וההפסד החודשי של כל הלקוחות בטבלה אחת — כל שורה היא סיכום ה-P&L של לקוח (הכנסת שילוח + מחסן מול עלות נהגים/קבלנים + עמלת סוכן + זיכויים, רווח נטו), בדיוק כמו בכרטיס הרווחיות שבעמוד הלקוח, עם שורת פירוט נפתחת. מעל הטבלה שורת סיכום (סך הכנסה / עלות / רווח נטו) שמתעדכנת לפי הפילטרים הפעילים. ארבעה פילטרים, כולם ברמת הלקוח: לפי עיר בית-העסק, לפי אזור חלוקה (נגזר מעיר העסק דרך טבלת הישובים), לפי סוכן, ולפי רווח/הפסד. בשורת הסיכום ניתן להוסיף 'תוספות מזדמנות' — שורות עלות או הכנסה חד-פעמיות (למשל שכירות, פיצוי נקודתי) שאינן נשמרות אלא משוקללות בסיכום ובייצוא בלבד. כפתור 'ייצוא לאקסל' מפיק קובץ xlsx של השורות המסוננות + התוספות המזדמנות + שורת הסיכום. העיר נגזרת מנתוני הספק (lionwheelData) עם נפילה לכתובת החופשית; לקוחות ללא עיר ידועה מקובצים תחת 'ללא עיר/אזור'. הכל מאחורי הרשאת FINANCE_VIEW. תצוגת 'רווחיות לפי לקוח' המקוצרת תחת אנליטיקס→לקוחות נשמרה כפי שהיא.

• לשונית 'רווחיות' חדשה תחת פיננסים — טבלת P&L חודשי לכל הלקוחות, עם שורת פירוט נפתחת
• שורת סיכום (הכנסה/עלות/רווח נטו) שמתעדכנת לפי הפילטרים
• פילטרים ברמת-לקוח: עיר בית-העסק, אזור חלוקה, סוכן, רווח/הפסד
• תוספות מזדמנות חד-פעמיות (עלות/הכנסה) בשורת הסיכום — לסיכום ולייצוא בלבד
• ייצוא לאקסל (xlsx) של השורות המסוננות + המזדמנות + הסיכום
• עיר/אזור נגזרים מכתובת בית-העסק; הכל מאחורי FINANCE_VIEW
• נוספה עמודת 'חבילות' (סך packages ?? 1 לכל משלוח) לצד עמודת 'משלוחים', בטבלה, בשורת הסיכום ובייצוא — כמו בשאר טבלאות המערכת
• הפילטרים אוחדו לפאנל אחד (FiltersPopover) עם בחירה-מרובה, חיפוש וספירות פר-אפשרות, במקום ארבעה תפריטים נפרדים
• חישוב העלות/הרווח כולל כעת אומדן עלות למשלוחים פתוחים (טרם תומחרו סופית) — לפי השליח המשובץ, או לפי שליחי האזור כשאין — בדיוק כמו בכרטיס הלקוח ובטבלת המשלוחים. שורות שכוללות אומדן מסומנות ב-'~' עם פירוט בריחוף, ולייצוא נוספה עמודת 'מזה אומדן'. האומדן מחושב מקובץ (projectPendingCostsForList) בצ'אנקים כדי לא להאט את הדוח
• תג 'חלקי' בעמודת המשלוחים מוצג כעת רק כשלמשלוח אין עלות כלל — לא סופית ולא אומדן (אין שליח משובץ ואין שליח-אזור מתומחר); משלוח פתוח שקיבל אומדן נחשב מכוסה ומסומן ב-'~' בלבד, כך שהתג לא מופיע כפול ומיותר לצד ה-'~'
• נוספה עמודת 'מסירה/חבילה' — עלות מסירה ממוצעת לחבילה (עלות מסירה כולל אומדן חלקי מספר החבילות, לא למשלוח). מסומנת ב-'~' כשכוללת אומדן, ונוספה גם לייצוא לאקסל כולל ממוצע משוקלל בשורת הסיכום
• תיקון: משלוחים מבוטלים (סטטוס 'בוטל') הוחרגו מכל תחשיב הרווחיות — הכנסה, עלות, ספירת משלוחים/חבילות ואומדן — כי הלקוח אינו מחויב עליהם (גם כשקיים מחיר בסיס). חל על טבלת הרווחיות בפיננסים, על תצוגת האנליטיקס ועל כרטיס הרווחיות בעמוד הלקוח
• תיקון קריטי: בטבלת הרווחיות הטננטית האומדן לא נכנס בפועל לחלק מהלקוחות (עמודת עלות הראתה ₪0 אף שבטבלת המשלוחים היה אומדן) — מסנן המועמדים לאומדן היה רחב מדי (כל משלוח מסירה-בלבד נושא pickupCost=null לצמיתות ולכן נספר), ~18K מועמדים חצו את תקרת ההגנה, ומשלוחים פתוחים אמיתיים נחתכו. כעת המועמדים נשלפים מה-DB עם סינון לרגל-פתוחה בלבד (visits.some(isDone:false)), והתקרה הועלתה — כך שכל משלוח פתוח מקבל את האומדן שלו
• שינוי מדיניות: ההכנסה בתחשיב הרווחיות נגזרת אך ורק מהמחירון שהוגדר ללקוח — בסיס (כולל כללי REPLACE/ADD) × מכפיל דחיפות + תוספות (יעד חריג, גוביינא, כפולה) + חבילות נוספות עם הנחת חבילה שנייה/שלישית; זיכויים מנוכים בצד העלות. לקוח **ללא מחירון** מוצג כעת עם הכנסה 0 (במקום נפילה למחיר הספק השמור), כדי שלא תיווצר הכנסה שאינה נגזרת מהתמחור שלנו — וכך בולט שצריך להגדיר לו מחירון. זהה למנוע החיוב של computeShipmentListBilling
• נוספו עמודות 'עלות איסוף' ו'עלות מסירה' (עלות אפקטיבית = סופית + אומדן, מסומנות ב-'~' כשכוללות אומדן) לצד עמודת 'עלות' הכוללת, וכן לייצוא לאקסל — כך שרואים את פירוק עלות הנהגים/קבלנים לפי רגל, בדומה לטבלת המשלוחים
• שיוך משלוח לחודש בתחשיב הרווחיות עבר להתבסס על **תאריך הקליטה** (delayClockStartedAt) — התאריך הגורם שממנו מתחיל מניין ימי ההפצה, זהה לבסיס בדף פערי-ההפצה — במקום commissionableAt. משלוח שטרם נקלט או שורה ישנה ללא השדה נופלים ל-createdAt כדי לא ליפול בין החודשים (כך שחודשים היסטוריים נשמרים). חל על הכנסת השילוח ועלות הנהג; עמלת סוכן/מחסן/זיכויים נשארים על בסיס ההכרה שלהם
• בהירות מונחים בטבלת המשלוחים ובפילטר התאריך: עמודת 'מועד האיסוף' (delayClockStartedAt) שונתה ל'תאריך קליטה מלקוח', ו'תאריך קליטה במחסן' (inInventoryAt) שונתה ל'תאריך כניסה למחסן' — כדי להבחין ברור בין קליטת המשלוח מהלקוח (שממנה נגזרת הרווחיות וימי ההפצה) לבין כניסתו הפיזית למחסן

שני באגים שמנעו עדכון מחירון ללקוח שכבר בוצע לו 'ייבוא מחירון' עם תאריך תחולה היסטורי. (1) שמירה חסומה: בעת שמירת המחירון נשלחים לשרת כל הכללים הקיימים, כולל הכלל שנוצר מהייבוא עם validFrom היסטורי (למשל 30/04/2026). הגנת ה-45-יום בשרת בדקה כל כלל בבקשה, ולכן דחתה את כל השמירה בשגיאה 'מנסה לחול מתאריך ישן מהמותר' — גם כשהשינוי החדש תוארך להיום. כעת הגנת הרטרואקטיביות חלה רק על כללים חדשים או כללים שתאריך התחולה שלהם שונה — כלל קיים שתאריכו לא נגע בו לא חוסם עוד עריכה לא-קשורה. (2) שדה 'שם הכלל': הצעות ההשלמה רונדרו ב-Popover של Radix שגזל את הפוקוס מתיבת הקלט ברגע שנפתח, כך שלא ניתן היה להקליד טקסט חופשי. הוחלף ברשימת הצעות פשוטה שאינה גוזלת פוקוס, מסוננת לפי מה שהוקלד (אם אין התאמה — אין הצעות), ובחירת הצעה מתבצעת ב-onMouseDown כדי לא להתבטל מול ה-blur. בנוסף, אזהרת 'חל על תאריך בעבר' לא תוצג עוד כשנבחר היום (השוואה מול תחילת היום במקום מול הרגע הנוכחי).

עלות המסירה/איסוף הפר-משלוח (כרטיסיית תמחור ורווחיות) תומחרה לפי מבצע הביקור בפועל. כשהמבצע היה סאב-שליח ללא מחירון משלו, העלות יצאה 0 — למרות שה-tenant משלם בפועל למנהל שמעליו (managedByDriverId), שיש לו מחירון. כעת העלות מתומחרת לפי 'שליח החיוב' = managedByDriverId ?? driverId, בדיוק כמו דו"ח התשלום החודשי tenant→manager (computeManagerTenantEarnings) — כך שה-snapshot הפר-משלוח שווה למה שה-tenant באמת משלם. תוקנו כל מסלולי החישוב: recomputeCostsForDriverDay (קיבוץ ותמחור לפי המנהל + טעינת ביקורי הסאבים שלו באותו OR של הדו"ח החודשי), recomputeCostsForShipment (קיבוץ לפי managedByDriverId ?? driverId), recomputeCostsForDriver (עריכת מחירון מנהל מרעננת גם את המשלוחים שהסאבים שלו מסרו), והצפי (projectAssignedLeg מתמחר אף הוא לפי המנהל). בוצע באקפיל לחודשיים אחורה: 7,222 משלוחים שנמסרו ע"י סאבים בחלון עודכנו לעלות הנכונה (0 נותרו שגויים).

עד היום מסך הרווחיות (בכרטיס הלקוח ובטבלת האנליטיקס) הציג רק 'שולי שילוח' — הכנסת השילוח פחות עלות הנהג — על פני טווח תאריכים חופשי. זו הייתה תמונה חלקית: היא התעלמה מהכנסות מחסן/לוגיסטיקה, מעמלות הסוכן ומזיכויים שניתנו ללקוח, ולכן הרווח שהוצג היה מנופח כלפי מעלה. כעת המסך מציג דוח רווח-והפסד מלא ברמת הלקוח, פר חודש קלנדרי: ההכנסה מצרפת את הכנסת השילוח (מנוע התמחור הקיים) עם חיובי המחסן/3PL (WhBillingEvent — אחסון/ליקוט/קליטה); העלות מצרפת את עלות הנהגים/קבלנים (snapshot של תשלום השליח — קבלן מוגדר כשליח עם מחירון), עמלת הסוכן המיוחסת ללקוח (ממנוע computeAgentEarnings), ותעודות זיכוי מאושרות שיוחסו לחודש (שבר/אובדן/איחור/פיצוי). הרווח הנטו נגזר ביניהם. בסיס התאריך הוא חודש קלנדרי בזמן ישראל, וההכרה בהכנסת השילוח עברה ל-commissionableAt (תאריך החיוב) כדי להתיישר בדיוק עם אופן ההכרה בעמלת הסוכן — כך שכל שורות ה-P&L מתייחסות לאותה תקופה. בכרטיס הלקוח נוסף ניווט חודשי (חיצים) ופירוט מלא של שורות ההכנסה והעלות, ולמשלוחים פתוחים שטרם תומחרו סופית מוצג אומדן עלות (כדי שהרווח לא ינופח באפס עלות). בטבלת 'רווחיות לפי לקוח' באנליטיקס נוסף טור 'רווח נטו', שורת פירוט נפתחת לכל לקוח (שילוח/מחסן מול נהגים/סוכן/זיכויים), ובורר חודש עצמאי. עלויות סוכן שאינן ניתנות לייחוס ללקוח בודד (בונוס חודשי כללי, התאמות חד-פעמיות) מושמטות מה-P&L הפר-לקוח ונשארות עלות ברמת הטננט. כל המסך נותר מאחורי הרשאת FINANCE_VIEW.

• מעבר מ'שולי שילוח' ל-P&L מלא: הכנסת שילוח + מחסן/3PL מול עלות נהגים/קבלנים + עמלת סוכן + זיכויים מאושרים
• בסיס חודש קלנדרי (זמן ישראל); הכרה בהכנסה לפי commissionableAt — מיושר עם דוח עמלות הסוכן
• כרטיס הלקוח: ניווט חודשי + פירוט מלא של ההכנסות והעלויות, כולל אומדן עלות למשלוחים פתוחים
• טבלת 'רווחיות לפי לקוח': טור 'רווח נטו' + שורת פירוט נפתחת לכל לקוח, עם בורר חודש עצמאי
• עלויות סוכן שאינן ניתנות לייחוס ללקוח (בונוס/התאמה כללית) מושמטות מה-P&L הפר-לקוח
• הכל מאחורי הרשאת FINANCE_VIEW

עד היום עלות האיסוף/מסירה בכרטיסיית 'תמחור ורווחיות' חושבה ונשמרה רק לאחר שהביקור סומן כ'בוצע' — כך שמשלוח שכבר הוקצה לקבלן עם מחירון, אך טרם נמסר, הציג עלות מסירה 0 ורווח חסר, למרות שהעלות ידועה מראש. כעת, כשביקור איסוף/מסירה משויך לשליח בעל מחירון אך עדיין לא הושלם, המערכת מחשבת 'עלות צפויה' באמצעות אותו מנוע חישוב בדיוק (computeEarningsLines) שמייצר את העלות הסופית — כך שהצפי זהה למה שייקבע בפועל עם השלמת המסירה. השורה מסומנת בתג 'צפי', וגם סך העלות, הרווח ושולי הרווח מחושבים לפי הצפי ומסומנים בהתאם. הצפי מוצג רק כשיש מחירון לשליח; ביקור שטרם שויך, או שליח ללא מחירון, ממשיכים להציג '—'. בנוסף, כשעדיין לא שובץ אף שליח למסירה — המערכת נותנת 'צפי משוער' לעלות המסירה לפי השליחים המורשים לאזור ההפצה (DriverAllowedZone): לוקחת את כל השליחים הפעילים עם מחירון שמורשים מפורשות לאזור (התאמה מדויקת או לפי מספר-אזור-בסיס), ומציגה לחומרא את המחיר הגבוה מביניהם. ברגע ששובץ שליח בפועל (גם הזול מבין המורשים) — הצפי מתעדכן מיד לערך המדויק שלו, והצפי-המשוער-לפי-אזור נדחה. הצפי המשוער מסומן בתג 'צפי משוער' (להבדיל מ'צפי' המדויק) עם הסבר ב-tooltip על מספר השליחים המורשים והאזור. גם כששובץ שליח שאין לו מחירון כלל — במקום להציג '—', המערכת נופלת לצפי המשוער לפי האזור, ומציינת ב-tooltip ובשורה ששם השליח המשובץ ללא מחירון (כך שגם רואים את הצפי וגם מקבלים חיווי לתקן את מחירון השליח).

• עלות מסירה/איסוף צפויה מוצגת מרגע שיוך השליח, לא רק אחרי השלמת הביקור
• הצפי מחושב במנוע התשלומים הקיים → זהה לעלות הסופית (למעט קיבוץ איסוף-עסקי שמתגבש על פני יום שלם)
• כשאין שליח משובץ — צפי משוער לעלות המסירה לפי השליחים המורשים לאזור (לחומרא: המחיר הגבוה), שמתעדכן לערך מדויק ברגע השיבוץ
• תג 'צפי' (מדויק, שליח משובץ) מול 'צפי משוער' (לפי אזור) — על שורת העלות, סך העלות והרווח
• שובץ שליח ללא מחירון? נופלים לצפי המשוער לפי האזור (במקום '—') + חיווי שלשליח אין מחירון
• אין שליח מורשה לאזור עם מחירון — לא מוצג צפי שגוי (נשאר '—')

בהורדה לאקסל מטבלת מעקב המשלוחים הראשית, עמודת הסטטוס יוצאה בערך הגולמי באנגלית (COMPLETED, FAILED וכו') במקום בתווית העברית שמוצגת בטבלה. כעת הערך מתורגם לעברית ("הושלם", "נכשל", "יצא להפצה"…) דרך getStatusDisplayText — אותו מיפוי שמזין את תגי הסטטוס במסך — כך שהקובץ תואם למוצג. תיקון זה גם מיישר את פילטר-הטקסט של עמודת הסטטוס: חיפוש לפי טקסט עברי בעמודה תואם כעת לערך המוצג. בנוסף נוספה עמודה חדשה "סטטוס תפעולי" (מוסתרת כברירת מחדל, ניתנת להפעלה מתפריט העמודות) — הסטטוס המשני המוגדר פר-חברה שמוצג כתגית נוספת לצד הסטטוס הראשי בטבלה, וכעת זמין גם בייצוא ובפילטר-הטקסט, כשהוא מתורגם משם-המפתח לתווית העברית המוגדרת.

בטופס יצירת משלוח חדש (גם בממשק הצוות וגם בפורטל הלקוחות) רשימת הרחובות הופיעה ריקה עבור ערים ששמן ב-data.gov.il שונה במעט מהשם אצלנו — בעיקר תל אביב, שאצלנו "תל אביב יפו" ובמאגר הממשלתי "תל אביב - יפו" (עם מקף). הסינון הקודם דרש התאמה מדויקת של שם הישוב ולכן החזיר 0 רחובות. כעת החיפוש מבוצע כ-full-text ממוקד-שדה על שם הישוב (שמגשר על הבדלי מקף/רווחים), והתוצאות מסוננות לפי השוואה מנורמלת של שם הישוב — כך שעיר עם שם-על כמו "גן יבנה" לא נכנסת בטעות לחיפוש על "יבנה". בנוסף, שם העיר נפתר תחילה דרך resolveSettlement (אותו מנגנון שמות חלופיים של ייבוא האקסל) לשם הקנוני — כך שעיר שנשמרה כשם חלופי ("נצרת עילית" → "נוף הגליל", "ת\"א" וכו'), בין אם מילוי-אוטומטי מכתובת לקוח/כתובת שמורה ובין אם ממשלוח ישן, עדיין מוצאת את רחובותיה. הוסר גם תקרת ה-3000 שחתכה ערים גדולות (ירושלים — ~4,400 רחובות). הלוגיקה רוכזה ב-lib/streets/gov-streets.ts המשותף לשני ה-endpoints. בנוסף, בבורר העיר — כשהחיפוש תואם שם חלופי ולא את השם הרשמי — מוצגת מתחת לשם תווית קטנה ומעומעמת "נקרא גם \"…\"", כך שמשתמש שמחפש "נצרת עילית" מבין מיד שעליו לבחור ב"נוף הגליל".

תוקן באג שגרם לאובדן שקט של שינוי מספר חבילות: עריכת פרטי משלוח דרך פורטל הלקוחות (מספר חבילות, משקל, כתובת) לא סונכרנה כלל לליונוויל, ובמקביל כל webhook סטטוס מליונוויל דרס את הערך המקומי בערך המקורי שלו — כך שלקוח ששינה 1→2 והדפיס מדבקות ראה את המשלוח חוזר ל-1, בעוד הקבלן קיבל שתי מדבקות. כעת: (1) עריכה בפורטל מסתנכרנת לליונוויל מיד, כמו במסך העריכה של הצוות; (2) webhook מעדכן מספר חבילות מקומית רק כשליונוויל באמת שינה אותו מול ה-snapshot הקודם — כך שעריכה מקומית שטרם הסתנכרנה אינה נדרסת, אך שינוי אמיתי שבוצע בליונוויל עדיין מסתנכרן אלינו ב-webhook הקרוב; (3) עריכות והדפסות מדבקה מהפורטל נרשמות כעת כראוי ביומן הפעולות — תוקנה הפרת מפתח-זר (FK) שבלעה בשקט את רישום ההדפסה (מזהה משתמש-פורטל נכתב לעמודה שמצביעה על טבלת משתמשי הצוות).

כל משלוח חדש מתעד מעתה מי יצר אותו: משתמש פורטל הלקוחות (לפי שם) או משתמש צוות. עד כה משלוחים שנוצרו דרך פורטל הלקוחות יוחסו ב-audit ל-"Lionwheel" (כי רישום היצירה הגיע מה-webhook של הסנכרון), והיוצר האמיתי לא נשמר בשום מקום. כעת היוצר נשמר על שורת המשלוח ומוצג בשני מקומות: בהיסטוריית הפעולות בדף המשלוח (צד צוות) — שורת "יצירה" מציגה "פורטל לקוחות · <שם המשתמש>" במקום Lionwheel; ובפורטל הלקוחות עצמו — שורת "נוצר ע״י" בכותרת פרטי המשלוח. נוסף actorType חדש 'customer' למערכת ה-audit, המדורג מעל ה-webhook כדי שסנכרון ליונוויל המאוחר לא ידרוס את ייחוס היוצר.

• שדות חדשים על המשלוח: created_by_user_id / created_by_name / created_by_type
• היסטוריית הפעולות בדף המשלוח מציגה את משתמש הפורטל שיצר ("פורטל לקוחות · <שם>") במקום Lionwheel
• פורטל הלקוחות מציג "נוצר ע״י <שם>" בכותרת פרטי המשלוח ובמגירת התצוגה המהירה
• actorType='customer' חדש ב-audit, מדורג מעל webhook כדי שהסנכרון לא ידרוס את היוצר
• הייחוס נשמר גם למשלוחי צוות (createdByType='user'); משלוחים ישנים / ייבוא מחנות נשארים ללא ייחוס

חנות WooCommerce שמציעה כמה שיטות משלוח (למשל משלוח רגיל שיוצא איתנו, אקספרס שיוצא עם מוביל אחר, ונקודות איסוף) — ניתן כעת להגדיר אילו שיטות בלבד ייובאו לשיפנסט. רשימת-היתר נשמרת לכל חיבור חנות; הזמנה ששיטת המשלוח שלה אינה ברשימה לא נמשכת ולא משוגרת ל-Lionwheel. הסינון חל גם על ה-webhook בזמן אמת וגם על סנכרון ה-cron כל 5 דקות. בטופס חיבור החנות בפורטל נוסף בורר שטוען את שיטות המשלוח ישירות מהחנות (מאזורי המשלוח + הזמנות אחרונות) ופאנל אימות שמראה מה נשלף מהזמנות אמיתיות — כדי לוודא שהשיטה אכן נמצאת בשדה התקני (shipping_lines) ולא מוסתרת ב-meta של תוסף צד-שלישי כמו Datalogics. בנוסף נוסף בורר 'מתי לייבא הזמנה' לכל חיבור: אוטומטי (מיד עם התשלום) או 'רק כשמסומנת הושלמה' — מצב ידני לחנויות שמכינות את המוצר לפני המשלוח (חריטה/אריזה), כך שהמשלוח נוצר ונשלח רק כשהצוות מסמן את ההזמנה Completed.

• רשימת-היתר של שיטות משלוח לכל חיבור חנות — ברירת מחדל: ייבוא כל השיטות (תאימות לאחור)
• בורר שיטות שטוען אוטומטית מהחנות (Shipping Zones + הזמנות אחרונות)
• פאנל אימות PII-safe: shipping_lines + שמות מפתחות meta של הזמנות אחרונות (ערכים לא נחשפים)
• fail-safe: הזמנה עם רשימת-היתר מוגדרת אך ללא שיטת משלוח כלל — לא מיובאת
• הסינון חל בצומת המשותף לשני המסלולים (webhook בזמן אמת + cron כל 5 דקות)
• בורר 'מתי לייבא הזמנה': אוטומטי (processing/on-hold) או ידני — רק כשההזמנה מסומנת 'הושלמה' (completed), לחנויות שמכינות את המוצר לפני המשלוח

האזור האישי של השליחים (פורטל מנהלי השליחים) עוצב מחדש כדשבורד עשיר. נוסף מתג יום / שבוע / חודש בראש המסך, עם ניווט מתאים לכל מצב (יום ספציפי, טווח שבוע, או חודש) — קודם לכן היה דוח חודשי בלבד. כל הנתונים נשלפים מטווח התאריכים החופשי שכבר נתמך ב-API, ללא שינוי לוגיקת חישוב או DB. הקיבוץ היומי מחושב בצד הלקוח לפי שעון ישראל, בהתאמה למתמטיקת השרת.

• מתג יום / שבוע / חודש עם ניווט מתאים וכפתור 'הבא' שמושבת בתקופה הנוכחית
• גרף עמודות של הכנסה יומית (בתצוגת שבוע/חודש) — לחיצה על יום מציגה את הסכום ומספר הביקורים שלו
• תג השוואה לתקופה הקודמת (▲/▼ אחוז) על כרטיס 'סה״כ לתשלום'
• ממוצע הכנסה ליום פעיל, היום החזק ביותר, ומספר ימי העבודה בתקופה
• סך כל החבילות שטופלו מוצג לצד מספר הביקורים
• תיקון: בכרטיס השליחים מוצג שם השליח (כולל המנהל עצמו ושליחים שקישורם הפך ללא-פעיל) במקום מזהה מספרי; שורת המנהל מסומנת '(אני)'
• פס הפקדים (יום/שבוע/חודש + ניווט תאריך) הפך דביק בראש המסך — אפשר להחליף תקופה ולדפדף בין תאריכים מכל מיקום גלילה בלי לחזור למעלה
• תיקון פריסת דסקטופ: התוכן ממורכז במרכז המסך (קודם נצמד לימין), והבורדר העליון רוכך לקו עדין עם רקע מטושטש

בתפריט הלחיצה-ימנית על שיחה נוספו 'הצמד' / 'בטל הצמדה'. שיחות מוצמדות צפות לראש רשימת השיחות (המוצמדת-אחרונה ראשונה), מעל שאר השיחות הממוינות לפי פעילות, ומסומנות באייקון נעץ קטן. עובד גם בחיפוש וגם בגלילה האינסופית (המוצמדות נשלפות בנפרד בעמוד הראשון כדי שתמיד יישבו למעלה, ללא תלות בזמן הפעילות).

שני תיקונים משלימים לגישור-הצפי, בעקבות תקרית 25640198. (1) אם המשלוח כבר נמסר ברגע שהלקוח שואל — הבוט עונה ישירות 'המשלוח כבר נמסר ✓' מנתוני המסירה שלנו, במקום לשאול את השליח לחינם (סטטוס סופי אחר כמו נכשל/בוטל → שתיקה, נציג מטפל). (2) אם המשלוח נמסר *תוך כדי* שהבוט ממתין לתשובת השליח: במקרה 25640198 המשלוח נמסר כ-12 דקות אחרי שקקאו שאלו צפי — ליונוויל עדכן COMPLETED, ואז cron הנדנוד ביטל את הגישור בשקט, כך שקקאו לא קיבלו כל תשובה (וגם תשובת הקבלן זיפ בציטוט 'זה כבר בוצע' נפלה על גישור מבוטל). כעת כשהנדנוד סוגר גישור-צפי בגלל מסירה בפועל, הוא מודיע ללקוח 'נמסר ✓' (תבנית delivered_to_customer הניתנת לעריכה) — סוגר את הלולאה גם בלי תשובת השליח.

בתפריט הלחיצה-ימנית על שיחה ברשימה נוספו 'סמן כנקרא' ו'סמן כלא נקרא' (בנוסף ל'העבר לארכיון' הקיים). 'סמן כנקרא' מנקה את תג הלא-נקראו ושולח ✓✓ כחול ללקוח (ReadChat). 'סמן כלא נקרא' מסמן ידנית בסגנון וואטסאפ — האינדיקטור נשאר דלוק גם בלי הודעות נכנסות חדשות, ומוצג כנקודה ירוקה כשאין מונה. שני הסימונים מתנקים אוטומטית כשפותחים את השיחה.

תיקון לפיצ'ר ה'בודק': עד כה הבוט רשם 'מברר מול הלקוח... אעדכן בהקדם' ברגע ש-Green API החזיר 200 על השאלה שנשלחה ללקוח/שליח. אבל 200 אומר רק שהבקשה התקבלה לתור — לא שההודעה נמסרה. במקרה אמיתי (משלוח 25739886) השאלה ללקוח 'כביסכל' נשמטה בשקט (Green API החזיר מזהה אך לא הגיע webhook מסירה כלל, ההודעה לא נרשמה ב-inbox של הלקוח, וה-relay נשאר PENDING) — אך הבוט כבר הבטיח 'מברר', ובן-אדם נאלץ להתערב ידנית. כעת ה-ack נשמר כ'ממתין' על ה-relay ונשלח לקבוצת המקור רק כשמסירת השאלה מאומתת דרך webhook סטטוס המסירה (sent/delivered/read); אם המסירה נכשלת (notInGroup/noAccount/failed) או שלא מגיע סטטוס כלל — ה'מברר' לא נשלח בכלל. כך ההודעה 'מברר/בודק' מופיעה אך ורק כשהבוט באמת פנה לצד השני בהצלחה.

המשך הבאת ה-Business Inbox לפריטי וואטסאפ. (1) קריאה: פתיחת צ'אט מסמנת אותו כנקרא ושולחת ✓✓ כחול ללקוח (Green API ReadChat), ותג מונה 'לא נקראו' ירוק מופיע ברשימת השיחות, עם הדגשת שיחות שיש בהן הודעות נכנסות חדשות. (2) פעולות על הודעה (תפריט בלחיצה-ימנית בדסקטופ / לחיצה-ארוכה במובייל): העברה לצ'אט אחר (ForwardMessages, עם בורר צ'אט מחופש), מחיקה לכולם (DeleteMessage — מוצגת כ'ההודעה נמחקה'), עריכת טקסט שנשלח (EditMessage — מקבל תג 'נערך'), והעתקה. (3) ריאקציות נכנסות מוצגות כצ'יפים על הבועה (שמות המגיבים ב-hover). (4) חיווי 'מקליד…' ללקוח בזמן שהנציג כותב (sendTyping, מווסת לכ-פעם ב-3.5 שניות). הכל נשען על תשתית ה-externalId שכבר נשמרת לכל הודעה. מגבלת ספק: שליחת ריאקציה מאיתנו אינה נתמכת ב-Green API — לכן רק הצגת ריאקציות נכנסות.

• קריאה: סימון נקרא בפתיחה + ✓✓ כחול ללקוח, ותג 'לא נקראו' ברשימה
• העברת הודעה לצ'אט אחר (בורר צ'אט עם חיפוש)
• מחיקה לכולם → מוצגת כ'ההודעה נמחקה'
• עריכת הודעה שנשלחה → תג 'נערך' (בכפוף לחלון הזמן של וואטסאפ)
• העתקת תוכן הודעה מהתפריט
• ריאקציות נכנסות מוצגות כצ'יפים (שמות המגיבים ב-hover)
• חיווי 'מקליד…' ללקוח בזמן הקלדה
• מגבלה: שליחת ריאקציה מאיתנו אינה נתמכת ב-Green API (רק הצגה)

נציגי השירות יכולים כעת להשיב מתוך ה-Business Inbox תוך ציטוט הודעה ספציפית — בדיוק כמו בוואטסאפ. במובייל מחליקים (סווייפ) על ההודעה, ובדסקטופ לוחצים על אייקון ↩ שמופיע בריחוף; נפתח סרגל 'משיב ל...' מעל תיבת הכתיבה (ביטול ב-X או ב-Esc), וההודעה נשלחת כ-quoted reply אמיתי דרך Green API — אותו מנגנון שהבוט כבר משתמש בו בתרחישים. בלוק הציטוט מוצג בראש הבועה, ולחיצה עליו קופצת להודעה המקורית ומדגישה אותה לרגע. דו-כיווני: גם כשלקוח/קבלן מצטט הודעה בוואטסאפ, הציטוט מוצג עכשיו באינבוקס (זוהה מ-quotedMessage.stanzaId וקושר להודעה אצלנו לפי externalId). נשען על התשתית הקיימת: כל הודעה כבר שומרת את ה-idMessage של Green API, ולכן לא נדרש backfill.

• סווייפ על הודעה במובייל / אייקון ↩ בריחוף בדסקטופ → מענה מצוטט
• סרגל 'משיב ל...' מעל ההקלדה, עם ביטול מהיר (X או Esc)
• בלוק ציטוט בראש הבועה; לחיצה קופצת להודעה המקורית ומדגישה אותה
• דו-כיווני — גם ציטוטים נכנסים מלקוח/קבלן מוצגים באינבוקס (טקסט ומדיה)
• נשלח כ-quoted reply אמיתי דרך Green API

שני שיפורים בעקבות תקרית 25691571. (1) כשהבוט קולט הודעה כתשובה לתרחיש גישור פתוח (relay) ומעביר אותה חזרה — ההודעה הנקלטת נשמרת כעת ב-inbox כך שהצוות רואה אותה. עד כה הנתיב הזה היה מחזיר לפני השמירה, ולכן ההודעה שעליה הבוט הגיב (למשל תמונת הקבלן 'הלקוח לא מעוניין לקבל') לא הופיעה בשיחה כלל — מה שיצר מצב הזוי שבו הבוט 'רואה' הודעה שהנציגים לא רואים. (2) אם תשובת הגישור מזכירה במפורש מספר משלוח אמיתי *אחר* מזה של ה-relay הפתוח — הבוט כבר לא משייך אותה אוטומטית, אלא משאיר את ה-relay פתוח ושותק (במקום לגשר תשובה על משלוח שגוי). חריג: תשובה שמצטטת ישירות את שאלת הבוט (quoted reply) ממשיכה כרגיל, כי הציטוט הוא איתות כוונה חד-משמעי.

כעת אפשר להגדיר למשתמש 'טלפונים נוספים' (מכשיר שני) בטופס עריכת המשתמש, והמערכת תזהה הודעות שהוא כותב בקבוצות הוואטסאפ כצוות — גם כשהן נשלחות מהמספר המשני. רקע: איש צוות ענה בקבוצת לקוח מהטלפון השני שלו 'הלקוח לא מעוניין לקבל', והבוט לא זיהה אותו כצוות (מפת הצוות הכירה רק טלפון יחיד לכל משתמש) — לכן קלט את ההודעה כתשובת-הלקוח לתרחיש 'אין מענה' פתוח, וגישר אותה בטעות חזרה לקבוצה אחרת על משלוח שגוי. כעת getTenantStaffPhoneMap ממפה את הטלפון הראשי ואת כל הטלפונים הנוספים לאותו משתמש, כך שמחסום 'תשובת צוות אינה תשובת הלקוח' תופס משני המספרים. נוסף שדה additionalPhones ל-User (גלובלי), נתמך ביצירה/עריכה דרך /api/users.

שיפור חיווי הסטטוס של הודעות יוצאות בתיבת השיחות (business-inbox), כדי שהודעה שנמצאת בתור המסירה של Green API לא תיראה כאילו 'לא נשלחה'. עד כה הודעה בזמן שליחה (אופטימית) הוצגה ללא שום אייקון — bubble ריק שנקרא כ'נכשל', והאייקון ✓ הבודד ('נשלח') לא הובהר. כעת לכל הודעה יוצאת יש מצב ברור עם tooltip: 'שולח…' (ספינר בזמן שהבקשה בדרך), '✓ נשלח · ממתין למסירה' (Green API קיבל, ממתין בתור), '✓✓ נמסר', '✓✓ נקרא' (כחול), ו'⚠ נכשל — ההודעה לא נמסרה'. ההודעה האופטימית מתחילה כעת כ'שולח…' במקום bubble חסר-חיווי. רקע: שליחה ידנית לקבוצה שאינה מקושרת ללקוח נראתה למשתמש כ'לא נשלחה' למרות שבפועל הצליחה ונקראה — העיכוב היה בתור המסירה של Green API, לא אצלנו.

תוקנו שלוש בעיות במודל 'שיוך שליח' שנפתח מסרגל הפעולות של בחירה מרובה בדף המשלוחים: (1) הלייבל הציג 'נהג' במקום 'שליח' — אוחדה הטרמינולוגיה ל'שליח' בכל המודל (כותרת, לייבל, הודעות). (2) רשימת השליחים לא נתנה לגלול — הרשימה רונדרה כ-dropdown מרחף (portal) שנחת מחוץ ל-scroll-lock של הדיאלוג ולכן אירועי גלילה נחסמו; הוחלפה ברשימה inline נגללת בתוך גוף הדיאלוג. (3) החיפוש לא היה יעיל — מכיוון שרוב השליחים נושאים את שם החברה (למשל 'שליח מישל') בשם התצוגה, חיפוש 'מישל' הציף עשרות שמות והקבר את השליח ששמו מישל; נוסף דירוג רלוונטיות שמקדים התאמה מדויקת → מילה ראשונה → מילה שלמה → תחילית, כך שהשליח המבוקש מופיע ראשון. בנוסף בוצעה סריקה של כל האפליקציה לאיתור אותו באג (dropdown נגלל-נייטיב שמרונדר ב-portal בתוך חלון נועל-גלילה) ותוקנו כל המופעים החיים: בחירת שליח בכרטיס המשימות (TasksCard) כשהוא נפתח במגירת פרטי-המשלוח, ובוררי אזורים/תבניות מבוססי Command בתוך טפסים מודאליים (טופס נהג, טופס יישוב, ובורר תבניות WhatsApp). תיקון עיצובי קטן: נוסף ריווח אופקי לאזור התוכן הגולל במודל 'שיוך שליח' כדי שטבעת הפוקוס סביב שדה החיפוש לא תיחתך בקצוות (overflow-y-auto חותך את ציר ה-X). בעקבות כך בוצעה סריקה נוספת בכל האפליקציה לאיתור אותה בעיית-חיתוך-טבעת, ותוקנו כל המודלים שבהם שדה-קלט/בחירה ברוחב-מלא יושב באזור גולל ללא ריווח אופקי: דיאלוגי האינטגרציות (חיבור כללי, חברת משלוחים, הנהלת חשבונות), תמחור מרובה (לקוחות + נהגים), ייבוא לידים, החלת-מנהל-רטרו לנהג, יצירת מפתח API בפורטל וניהול תוויות. עוטף-התוכן בקונבנציית-הדיאלוג ב-CLAUDE.md עודכן לכלול px-1 כדי שדיאלוגים עתידיים לא יחזירו את הבאג (ב-FormDialog המשותף זה כבר היה מובנה דרך px-6).

תוקן באג שבו בקשת שידור (למשל צילום מדבקה + 'לשדר') בקבוצה שמקושרת כשליח אך לא כלקוח (כמו קבוצת 'זיפ') לא שודרה — לסירוגין. נתיב השידור רץ ברקע עם debounce של 8 שניות ועטוף ב-after() כדי שוורסל ישאיר את הפונקציה חיה, אבל ה-after() עקב רק אחרי נתיב סוכן-הלקוח. בקבוצה שאינה מקושרת ללקוח, סוכן הלקוח יוצא מיד ('שולח לא מזוהה') ללא ה-debounce — ולכן הפונקציה הוקפאה באמצע ה-sleep של השידור והשידור נשמט בשקט (נרשם רק סיווג 'silent', אף פעם לא החלטת broadcast_request). זה היה לסירוגין כי תעבורה מקבילה לעיתים השאירה את האינסטנס חם מספיק. כעת routeInboundUserMessage ממתין גם לנתיב הקבוצה/שידור (במקביל, ללא תוספת latency), כך שהבטחת ה-after() מכסה אותו והשידור תמיד מסתיים. משפיע על שני המסלולים — טקסט ומדיה.

הועברה חבילת המשוב מסורק הווב לסורק המחסן באפליקציה (קליטה/מיון): רכיב ScanFeedbackOverlay חדש מציג ברגע זיהוי הברקוד טוסט אפור-ניטרלי עם ספינר ('ממתין לשרת…'), שמתמרמר עם תשובת השרת לטוסט ירוק (הצלחה) / אדום (כישלון) / כתום (טעות מיון) עם הודעה מתאימה — 'נקלט בהצלחה' (כולל 'בוטל שיוך ל…' כשהשיוך נוקה), 'שובץ לשליח X', טקסט השגיאה, או הסבר טעות המיון (איזה אזור אינו באזורי הנהג). הטוסטים נערמים ונעלמים אוטומטית, ניתנים לסגירה ידנית, ובמקביל מהבהבת מסגרת צבעונית סביב המצלמה ומופעל רטט (קליק קל בזיהוי, ורטט הצלחה/אזעקה/שגיאה בתוצאה דרך expo-haptics). רשימת ההיסטוריה תחת המצלמה עודכנה לזהות גם טעות מיון (כתום). מימוש pure-JS (Animated + expo-haptics קיים) — ללא תלות נייטיב חדשה, כך שזה מתפרסם כעדכון OTA ללא בנייה מחדש. צליל לא נוסף (דורש expo-av = בנייה נייטיב).

הזמנה של GL Glow עם כתובת 'רקפת 10' שנשמרה ב-WooCommerce כ-'10, רקפת' (מספר הבית ראשון) לא שודרה לליונוויל אלא נקלטה כ'ממתין' עם ברקוד סינתטי — ונאלצנו להמתין שליונוויל תקים אותה דרך האינטגרציה שלה. שתי סיבות תוקנו: (1) ה-parser של הכתובת זיהה מספר בית רק בסוף ('הרצל 10') ולא בהתחלה ('10, רקפת'), ולכן נשאר ללא מספר בית; (2) ה-validation של יצירת-המשלוח דרש מספר בית גם בייבוא, בעוד שליונוויל מקבלת כתובת מלאה ללא מספר נפרד. כעת ה-parser מזהה מספר בית בשני הצדדים (כולל פסיק), ובמסלול הייבוא מספר בית חסר כבר לא חוסם שידור. הזמנות חדשות כאלה ישודרו ישירות עם ברקוד אמיתי של ליונוויל.

שני ייעולים שמקטינים עומס מיותר על השרת. (1) הסטרים של 'מי מחובר' (presence, /api/users/online/stream) נסגר קודם כל 25 שניות וגרם לכל דפדפן מחובר להתחבר מחדש בערך כל 26 שניות — סופת חיבורים-מחדש ושאילתות DB מיותרות. כעת הוא נשאר פתוח ~4.5 דקות (כמו סטרימי ההתראות/משלוחים/ליקוט), מה שמקטין את כמות החיבורים-מחדש פי ~10. (2) נתיב התראות השגיאה ל-WhatsApp של המנהל ניסה לשלוח הודעה על כל שגיאה גם כשלא הוגדר מספר טלפון מנהל (TEST_PHONE ריק), ונכשל ב-validation עם 'Failed to send error notification: Invalid phone number format' — רעש שקפץ על כל כשל cron חיצוני (konimbo/eshop/woocommerce). כעת אם אין מספר מנהל תקין, ההתראה מדולגת בשקט ללא ניסיון שליחה מבוזבז.

כשמשלוח שמשובץ לשליח או משודר לקבלן עובר סריקת 'קליטה במחסן' (כלומר חזר למחסן), המערכת מנקה כעת אוטומטית את השיוך: הנהג מוסר מביקור המסירה (driverId/managedByDriverId/driverAssignedAt מאופסים) ומסומני השידור היוצא (targetPartnerTaskId + snl_broadcast_at/snl_barcode/snl_task_type) נמחקים — כך שהמשלוח חוזר למצב 'נקלט במחסן' נקי וניתן לשדרו/לשבצו מחדש (קודם הגנת ה-idempotency הייתה חוסמת שידור חוזר). במקביל מתעדכן ליונוויל ברקע (after()): הסטטוס נדחף ל'נקלט במחסן', והנהג מוסר מהביקור (driver_id: null) כשיש מזהה ביקור. הסורק מציג בטוסט הקליטה גם את ביטול השיוך (למשל 'בוטל שיוך למשה כהן'). הערה: ההזמנה אצל הקבלן (SNL) עצמה אינה מבוטלת אוטומטית — רק השיוך המקומי וליונוויל מתעדכנים.

תוקן באג שבו עובד שדיווח משמרת רטרואקטיבית קיבל בטעות 'קיימת משמרת חופפת בתאריך זה' למרות שלא הייתה חפיפה אמיתית. הסיבה: השעות שהוזנו פורשו לפי אזור הזמן של השרת (UTC ב-Vercel) ולא לפי שעון ישראל, כך שדיווח על 09:30–10:30 נשמר בפועל כ-12:30–13:30 והתנגש במשמרת שנרשמה בזמן אמת. כעת התאריך והשעה מתפרשים כשעון ישראל (מודע לשעון קיץ/חורף) דרך helper חדש israelLocalToUtc. בנוסף תוקנה לוגיקת בדיקת החפיפה עצמה לבדיקת-טווחים תקנית אחת (חפיפה אמיתית בלבד, כולל הכלה דו-כיוונית; משמרות צמודות גב-אל-גב כבר לא נחשבות חופפות).

דף הסריקה (shipments/scan) הורחב משני מצבים לארבעה. נוסף מצב 'חיפוש משלוח': סריקת ברקוד (סורק USB, הקלדה + Enter, או מצלמת הנייד) פותחת מיד את דף המשלוח של הברקוד שנסרק — ללא עדכון סטטוס וללא פעולת שרת. בנוסף נוסף מצב 'פעולות מרובות': סורקים קבוצת משלוחים לרשימה ואז מחילים עליהם פעולה מרובה אחת — שיבוץ שליח, הדפסת מדבקות, העברה לסל מיחזור, הוספה לליקוט, שינוי סטטוס, וכן יעד שבת/אקספרס, שכפול, העתקה וסנכרון מליונוויל. הרשימה נבנית תוך כדי סריקה (כל ברקוד נשלף ומוצג עם נמען, כתובת וסטטוס, עם אפשרות להסרה פרטנית), ומופעל בה אותו סרגל הפעולות המרובות של דף המשלוחים — כך שכל הפעולות והאישורים זהים בדיוק. סיומת חבילה בברקוד (למשל '1234-2') מקוצצת אוטומטית לברקוד-האב בשני המצבים, כמו בשאר פעולות הסריקה. נוסף endpoint קליל (scan-lookup) לשליפת משלוח בודד לפי ברקוד לצורך בניית הרשימה. שיפורים נוספים למצב 'פעולות מרובות' למניעת טעויות: כל משלוח שכבר נמסר/בוטל/נכשל-סופית מסומן בכתום עם אזהרה כשהוא נכנס לרשימה (כדי לא לפעול עליו בטעות); שורת פילוח מעל הרשימה מציגה סה"כ משלוחים+חבילות, מספר המשלוחים בסטטוס סופי, ופיזור לפי אזורי חלוקה (לתפיסת טעויות מיון לפני שיבוץ שליח); הרשימה הסרוקה נשמרת ב-sessionStorage ושורדת רענון דף באמצע באצ'; סריקה חוזרת של משלוח שכבר ברשימה מקבלת חיווי מובחן (צליל דו-טוני + טוסט כתום); לחיצה על שורה סרוקה פותחת את דף המשלוח; ונוסף משוב רטט (haptics) במובייל לכל סריקה. ה-dedup של מצב הפעולות הופרד לחלוטין מזה של קליטה/שיבוץ. נוסף גם **דוח סריקות יומי** (shipments/scan-report, נגיש מכפתור 'דוח יומי' בסורק): מציג את כל היסטוריית הסריקות של היום הנבחר — הצלחות, שגיאות וטעויות מיון — עם בורר תאריך, כרטיסי סיכום לחיצים (סה"כ/הצלחות/שגיאות/טעויות מיון) המשמשים גם כמסננים, סינון לפי סוג (קליטה/שיבוץ), וייצוא ל-Excel/CSV והדפסה. כדי שגם השגיאות יתועדו, סריקות שנכשלו (משלוח לא נמצא, אין ביקור מסירה פתוח, נהג לא נמצא, חסר מזהה נהג) נרשמות כעת ל-audit trail תחת פעולה נפרדת 'scan_failed', וטעויות מיון מסומנות ברשומת ה-scan — כך שהדוח מציג תמונה מלאה. הדוח אינו משנה את לוג הסריקות הפר-משלוחי הקיים.

• מצב 'חיפוש משלוח' — סריקה פותחת מיד את דף המשלוח, ללא פעולת שרת
• מצב 'פעולות מרובות' — סריקת קבוצת משלוחים והחלת פעולה מרובה על כולם
• פעולות נתמכות: שיבוץ שליח, הדפסת מדבקות, סל מיחזור, ליקוט, שינוי סטטוס ועוד (שימוש חוזר בסרגל הפעולות של דף המשלוחים)
• מניעת טעויות: אזהרה כתומה על משלוח שכבר נמסר/בוטל, ופילוח קבוצה לפי אזור לפני שיבוץ
• שמירת הרשימה הסרוקה ברענון דף, חיווי לסריקה כפולה, פתיחת משלוח בלחיצה, ורטט במובייל
• דוח סריקות יומי — כל היסטוריית הסריקות (הצלחות + שגיאות + טעויות מיון) עם סיכום, סינון וייצוא ל-Excel/CSV
• עובד בסורק USB, בהקלדה ידנית ובמצלמת הנייד; קיצוץ אוטומטי של סיומת חבילה לברקוד-האב

מאחר שהסורק קולט את הברקוד מיידית בעוד תגובת השרת לוקחת זמן, שונתה לוגיקת החיווי: ברגע זיהוי הברקוד קופץ מיד טוסט אפור-ניטרלי עם מספר הברקוד וספינר ('ממתין לשרת…'), וכשהתשובה חוזרת הוא מתמרמר במקום (morph) לירוק/אדום/כתום עם טקסט התוצאה המלא — והטיימר של 3 שניות, מסגרת המסך והצליל מופעלים רק ברגע ה-morph. הטוסטים נערמים, כך שניתן לעקוב במקביל אחרי מספר ברקודים שעדיין ממתינים. החיווי הגנרי 'מעבד…' בתחתית הוסר (מיותר). נוסף gate ברמת המצלמה שמונע פתיחת טוסט-ממתין חוזר לברקוד שכבר טופל ונשאר מול המצלמה. נוסף timeout ל-fetch של הסריקה והשידור (15/20 שניות) כך שבקשה תקועה תיפתר לשגיאה ולא תשאיר ספינר תקוע — והשרת idempotent ולכן ניסיון חוזר אחרי timeout לא יוצר כפילות. בנוסף שונתה תצוגת הטוסטים לפי משוב: טוסטים של הצלחה/המתנה נערמים כעת כקלפים שמבצבצים חלקית זה מאחורי זה (כדי לא לתפוס גובה מעל אזור הסריקה), בעוד טוסטים של שגיאה/טעות-מיון 'יוצאים החוצה' ומוצגים במלואם (חיווי קריטי שמותר לו להסתיר את התצוגה). שופר גם המשוב על כשלים: כשל שידור מציג כעת את סיבת הכשל האמיתית שהשרת החזיר (במקום 'השידור נכשל' גנרי), וטעות מיון מציגה הסבר מפורש — איזה אזור אינו באזורי החלוקה של הנהג, ושבמקרה של קבלן החבילה לא שודרה. תוקן רגרסיה: כפתור הפנס שנעלם לגמרי (בעקבות gate שהסתיר אותו כשלא זוהתה תמיכה) — הכפתור מוצג שוב תמיד, וההפעלה מנסה את ה-constraint ישירות (חלק ממכשירי אנדרואיד לא מדווחים תמיכה אך כן מפעילים); אם באמת לא נתמך (iOS Safari) מוצגת הודעה קצרה 'הפנס אינו נתמך'. נוסף משוב רטט (Vibration API): רטט קצר ברגע זיהוי הברקוד (כדי שהמשתמש ידע מיד שנקלט ויעבור לחבילה הבאה), ורטט כפול מובחן בכשל/טעות מיון. נתמך בדפדפני אנדרואיד; ב-iOS Safari אין Vibration API ולכן זה no-op שם.

שיפורים לסורק הברקודים בדפדפן הנייד בדף קליטת/הוצאת מחסן (shipments/scan). תוקן הפנס: כעת מזוהה תמיכת torch ברגע שהמצלמה עולה — הכפתור מוצג רק במכשירים שבהם הוא באמת עובד (ב-iOS Safari אין גישת פנס דרך הדפדפן, ולכן הכפתור הוסתר במקום להישאר כפתור מת), וההפעלה עוטפה ב-try/catch שמקרין כשל. תוקן באג שבו מקלדת הטלפון נפתחה באמצע סריקה — שדה הקלט הנסתר קיבל inputMode=none (קולט סורק USB ללא העלאת מקלדת רכה), ולוגיקת ה-focus האוטומטי הושבתה במכשירי מגע. נוסף חיווי תוצאה בתוך מסך המצלמה: לכל סריקה מוצג טוסט נערם בראש המסך (כדי לא להסתיר את אזור הסריקה) עם מספר הברקוד, אזור ההפצה והעיר, וכותרת לפי הפעולה — 'נקלט בהצלחה' בקליטה, 'שובץ לשליח X' בשיבוץ, 'שודר בהצלחה ל-X' בשידור לקבלן, או טקסט הכישלון בכישלון. טוסט הצלחה ירוק, כישלון אדום, וטעות מיון בכתום; כל טוסט נעלם אחרי 3 שניות ויש כפתור X להסתרה מיידית. במקביל מוארת מסגרת צבעונית סביב המסך לחצי שנייה ומושמע צליל הצלחה/כישלון/אזעקה. צלילי הביפ/אזעקה בצד העמוד מושתקים כשהמצלמה פתוחה כדי למנוע כפילות. תוקנה בעיה קריטית של שידור כפול לקבלן (= חיוב כפול): כשתגובת השרת איטית והמשתמש המתין על אותו ברקוד, ה-debounce (1.5 שניות) פג והסריקה נשלחה שוב — וכל שליחה יצרה הזמנה נפרדת אצל הקבלן. נוספה הגנה דו-שכבתית: (1) בצד הלקוח — דה-דופ פר-סשן שלא שולח את אותו הברקוד פעמיים לאחר שנשלח/הצליח (כישלון מאפשר ניסיון חוזר; 'נקה סשן' מאפס); (2) בצד השרת — broadcastShipmentsToSnl הפך ל-idempotent: אם המשלוח כבר שודר לאותו רגל (targetPartnerTaskId/pickupOutboundTaskId קיים) הקריאה ל-API מדולגת ומוחזר 'כבר שודר', כך שאף מסלול שידור (סורק, שידור מרוכז, שיוך נהגים, סוכן AI) לא יכול ליצור הזמנה כפולה. נוסף גם חיווי 'מעבד…' מיידי בסורק כדי שהמשתמש יידע שהסריקה נקלטה ולא יסרוק שוב. בנוסף הואצה תגובת הסריקה: סנכרון הסטטוס ל-Lionwheel (שה-API שלו איטי, ~1-2 שניות) הוצא מנתיב הבקשה הקריטי — הסטטוס נשמר מקומית והתגובה חוזרת מיד, והדחיפה ל-Lionwheel מתבצעת ברקע דרך after() של Next. חל גם על קליטה (IN_INVENTORY) וגם על שיוך (סנכרון הנהג לביקור ב-Lionwheel).

בעקבות הבחירה באייקון 'חנות' (Store) ללקוח בטופס הקמת המשלוח, אוחד אייקון הלקוח בכל המערכת — בכל מקום שמייצג לקוח. הוחל ב: ניווט הצד (קבוצת 'לקוחות' + הקישור למצבת), דף הלקוחות (כולל מצב ריק), טופס הוספת/עריכת לקוח, אווטאר/עמודת הלקוח בטבלה, בוררי הלקוח בהצעות מחיר ובהסכמים, קיבוץ לפי לקוח באיסופים, סינון לפי לקוח בליקוט, כרטיסי ה-KPI של לקוחות (אנליטיקס, דשבורד סוכן, דף סוכן, דף טננט באדמין), הגדרות לקוחות בטריגרים, ובורר סקופ הלקוח במחסן. הוחלפו Building2/Users/User באייקון Store בהקשרי לקוח בלבד — לא נגעו אייקוני עיר/טננט/צוות/משתמשים. הוחרגו במכוון: פילטר 'לקוחות' בתיבת השיחות (מייצג משתתפי צ'אט) וסקופ 'הכל (טננט + לקוחות)' במחסן.

חישוב ההכנסה למשלוח לקח בחשבון רק חבילה אחת — מחיר הבסיס לא הוכפל במספר החבילות. ההכפלה הסתמכה כל כולה על תוספת 'חבילה נוספת' שנשמרה מראש ב-priceSurcharges, וכאשר היא חסרה (משלוח ישן, ללא מחירון בעת היצירה, או שינוי מספר חבילות לאחר ההקמה) ההכנסה ירדה למחיר חבילה בודדת והוצג הפסד מדומה (למשל משלוח של 4 חבילות שחושב כ-25 ₪ במקום 100 ₪). כעת תוספת החבילות הנוספות מחושבת חיה ישירות ממספר החבילות ומהמחירון בכל חישוב הכנסה — כך שהתיקון חל רטרואקטיבית על כל המשלוחים לפי המחירון שלהם, ללא צורך בעדכון נתונים. החישוב מכבד את הנחת החבילה הנוספת (כללית ופר-אינדקס), ותוספת ה-extra_package השמורה מנוכה כדי שלא תיספר פעמיים. בנוסף תוקן שורש עמוק יותר: תוספת החבילות חושבה לפי שדה התעריף הגולמי בפרופיל (deliveryRate/pickupRate), אך אצל לקוחות שהתעריף שלהם מוגדר דרך כללי REPLACE השדות האלה הם 0 — ולכן התוספת התאפסה לחלוטין. כעת היא מחושבת מתעריף הבסיס המחושב (resolveCustomerBaseRate, כולל כללים), בדיוק כמו חבילה ראשונה. חל על פאנל התמחור הפר-משלוח, עמודת ההכנסה/רווח בטבלת המשלוחים, סיכום הרווחיות הפר-לקוח (כרטיס הלקוח + אנליטיקס) ובסיס חישוב עמלות הסוכנים.

בורר הלקוח (משלח) בטופס הקמת המשלוח היה קבור בתחתית הטופס (אחרי המוצא, הנמען, היעד והמפה), כך שהזרימה הייתה הפוכה — מילוי כתובות ידני ורק בסוף בחירת לקוח שדורסת אותן — ורבים כלל לא הבחינו בו. כעת בורר הלקוח הוא השדה הראשון והבולט בראש הטופס, בעיצוב זהה לזה שבדף ייבוא המשלוחים. בחירת לקוח ממלאת אוטומטית את צד 'בית העסק' לפי סוג המשלוח ונועלת אותו לעריכה: ב'מסירה' כתובת המוצא ננעלת; ב'איסוף' פרטי הנמען וכתובת היעד ננעלים; רק ב'חופשי' שתי הכתובות פתוחות. הנעילה משתמשת ב-readOnly כך שהערכים שמולאו אוטומטית עדיין נשלחים. השינוי חל על אותו רכיב טופס בכל ההקשרים — ממשק הניהול, ממשק הסוכנים ופורטל הלקוחות.

• בורר הלקוח (משלח) הועבר לראש טופס ההקמה כשדה ראשון ובולט, בעיצוב התואם את בורר הלקוח בדף ייבוא המשלוחים
• בחירת לקוח ממלאת אוטומטית את צד בית העסק: במסירה — כתובת המוצא; באיסוף — שם/טלפון הנמען וכתובת היעד
• הצד שמולא אוטומטית ננעל לעריכה (readOnly — הערכים עדיין נשלחים בתקין); רק במצב 'חופשי' שתי הכתובות פתוחות לעריכה חופשית
• כפתורי 'כתובות מועדפות' מוסתרים בצד הנעול, וטקסטי העזרה וכותרות הסקציות עודכנו לשקף נעילה
• חל על ממשק הניהול, ממשק הסוכנים ופורטל הלקוחות (אותו רכיב ShipmentForm). סוכן בוחר רק לקוחות המשויכים אליו; משתמש פורטל — רק מהלקוחות המקושרים אליו
• הטופס הורחב בדסקטופ (sm→2xl, lg→4xl, xl→5xl) כדי שלא יהיה דחוס מהצדדים ולתת מקום לפריסה רחבה. תוקן באג רוחב: ה-className הקודם (max-w-2xl ללא prefix) הפסיד ל-sm:max-w-lg של רכיב הדיאלוג הבסיסי ולכן הטופס היה בפועל ~512px בלבד בדסקטופ. רשת כתובת המוצא עברה ל-3 עמודות בדסקטופ
• בורר סוג המשלוח: כל אפשרות היא כפתור נפרד עם גבול משלו ורווח בין הכפתורים (הפרדה ברורה בין האפשרויות במקום רצף מבולבל), עם הדמיית-כיוון בכל כפתור (אייקון בית-העסק בצד המעוגן, אייקון מיקום בצד הלקוח, חץ מימין-לשמאל; חץ כפול ל'כפולה'). ההסבר המלא של הסוג שנבחר עבר לשורת הלייבל בפורמט '(הסוג שנבחר - מסירה - משלוח מבית העסק עד בית הלקוח)'. נוסף סוג רביעי 'כפולה' (משלוח דו-כיווני) שמתנהג כמסירה לעניין מילוי/נעילת המוצא ונשלח עם is_roundtrip. השדה חובה; במובייל מוצג כ-Select
• נוספו לסקציית 'כתובת יעד' שני שדות: קוד כניסה לבניין (door_code — מתקפל אוטומטית להערת היעד בליונוויל) ומיקוד יעד (destination_zip_code — נשלח לליונוויל/מדבקה). שדה 'הערות' זוהה כהערת-יעד (מה שהשליח רואה בכתובת המסירה, Lionwheel destination_notes), הועבר לסקציית 'כתובת יעד', הוקטן ל-2 שורות ותויג מחדש כ'הערת יעד'
• כל שדות כתובת היעד (עיר, רחוב, מספר, דירה, קומה, כניסה, קוד כניסה, מיקוד) אוחדו לגריד אחיד אחד — רוחב שווה לכל שדה (רבע בדסקטופ, חצי במובייל), במקום שעיר/רחוב/קוד-כניסה/מיקוד יהיו רחבים פי-שניים משאר השדות
• ליטושים: 'הערת יעד' צומצמה לשורה אחת (לכל הרוחב) במקום 2 שורות; שדות טלפון (נמען/מוצא/נוספים) ומיקוד מיושרים לימין כשאר הטופס (הוסר dir=ltr שגרם ליישור-שמאל); שדה 'ברקוד' הוסר כליל — הברקוד נוצר אוטומטית בליונוויל
• גוביינא מוסתרת מאחורי טוגל ('גוביינא (COD)' עם הסבר 'גביית כסף מהנמען בעת מסירת המשלוח') כדי לחסוך מקום — כבוי כברירת מחדל. רק בהפעלתו מופיעים השדות 'סכום גבייה' ו'סוג תשלום' (מזומן/שיק); כיבוי הטוגל מאפס את הסכום
• אחידות אייקוני שדות: לכל שדה אייקון, וללא כפילות בין מושגים שונים. תוקן ש'לקוח' ו'עיר' חלקו אותו אייקון (לקוח→חנות, עיר→Building). שדות זהים במוצא/יעד חולקים אייקון (עיר/רחוב/מספר/שם/טלפון); נוספו אייקונים לשדות שחסרו (דירה/קומה/כניסה/קוד-כניסה/מיקוד/מספר-מוצא); גוביינא קיבלה אייקונים מובחנים (סכום=שטר, סוג תשלום=ארנק)
• הצד הנעול של הכתובת (מוצא במסירה/כפולה, יעד באיסוף) מוצג כעת ככרטיס-טקסט קריא — 'כתובת ברירת המחדל של בית העסק' עם הפרטים + רמז 'להזנת כתובת שונה בחר סוג משלוח חופשי' — במקום שדות אפורים ונעולים שיצרו בלבול. הערכים עדיין נשלחים (inputs מוסתרים רשומים, ללא סיכון submit)
• שדה הרחוב הוסב ל-Combobox אמיתי: טוען פעם אחת את כל רחובות העיר ממאגר data.gov.il (ממוטמן פר-עיר) ומסנן מקומית — נפתח מיידית בלחיצה עם רשימה מלאה, הפוקוס נכנס ישר לשדה החיפוש, והשדה עצמו אינו ניתן לכתיבה (הערך נקבע רק מבחירה ברשימה). נוספה אפשרות 'רחוב שלא מופיע ברשימה' (מופיעה תוך כדי הקלדה) שבבחירתה מוצגת אזהרה לוודא שהרחוב קיים כדי למנוע טעויות שליחים. אינדיקציית הטעינה מוצגת בתוך הרשימה ולא חוסמת טקסט. שני ה-endpoints (ניהול + פורטל) עודכנו לתמוך בטעינת כל רחובות העיר

בדף המשלוח בפורטל הלקוחות כפתור 'לינק מעקב' בנה את הכתובת לפי הברקוד (/tracking/<barcode>), בעוד שדף המעקב הציבורי מחפש לפי public_id — כך שהקישור הוביל תמיד ל'משלוח לא נמצא / הקישור אינו תקף'. הכפתור תוקן ובמקומו נכנס דרופדאון עם שתי האפשרויות הזהות לאלו שבממשק הניהול: 'לינק מעקב ללקוח' (/tracking/<public_id>) ו'לינק לעדכון פרטים' (/validate/<public_id>) — שתיהן בנויות נכון לפי public_id ומועתקות ללוח בלחיצה. כשאין public_id למשלוח האפשרויות מושבתות.

עד כה כפתור 'משלוח חדש' בדף המשלוחים היה מוסתר לסוכנים, כך שסוכן יכול היה רק לצפות במשלוחים (וליבא בכמות דרך דף הייבוא) — אך לא להקים משלוח בודד מהממשק. כעת לסוכן יש גישה מלאה לטופס הקמת המשלוח הרגיל (כל השדות, כמו לצוות), עם הגבלה אחת: רשימת הלקוחות בטופס מצומצמת אך ורק ללקוחות המשויכים לסוכן (Customer.agentId). הסינון נאכף בצד שרת ב-/api/customers/for-shipment-form, ובנוסף נקודת היצירה /api/shipments/create מאמתת מחדש שהלקוח שנבחר באמת משויך לסוכן ודוחה בקשה מזויפת (403) — אותו דפוס הגנה שכבר קיים בייבוא הכמותי. סוכן ללא לקוחות משויכים מקבל רשימה ריקה.

עד כה WooCommerce דרשה מהלקוח להגדיר Webhook ידנית (יצירת webhook ב-WooCommerce + הדבקת Secret תואם), ובניגוד לקונימבו/CashCow/e-shop/nopCommerce — לא הייתה לה משיכה אוטומטית כגיבוי. התוצאה: לקוח שחיבר חנות, לחץ 'בדיקת חיבור' (שבודקת רק את ה-REST API) וקיבל 'החיבור הצליח' — אך לא השלים את הגדרת ה-Webhook או הגדיר Secret שלא תאם — לא ראה אף הזמנה, בלי שום אינדיקציה לתקלה. כעת בחיבור חנות WooCommerce שיפנסט **רושמת את ה-Webhook אוטומטית** דרך ה-API של החנות (יוצרת order.created + order.updated עם Secret שאנחנו מייצרים), כך שהזמנות חדשות מגיעות **מיד בזמן אמת ללא שום הגדרה ידנית**. בנוסף נוסף cron גיבוי שמושך הזמנות processing/on-hold כל 5 דקות, עם דה-דופ משותף עם ה-Webhook כך שאין כפילויות. כפתור 'סנכרן Webhook' מאפשר לרשום מחדש בלחיצה לחיבורים קיימים.

• הזמנה מיובאת משודרת אוטומטית לליונוויל (דרך אותה ליבת יצירת-משלוח כמו יצירה ידנית) — מקבלת ברקוד אמיתי של ליונוויל וסטטוס אמיתי, במקום שורה מקומית עם ברקוד סינתטי. נעילה אטומית (claim על הברקוד הדטרמיניסטי) מונעת שידור כפול מ-order.created+order.updated/cron; אם השידור נכשל המשלוח נשמר כ'ממתין' ולא אובד. חל על שני המסלולים (webhook + cron)
• רישום Webhook אוטומטי מול WooCommerce ברגע החיבור (order.created + order.updated, Secret מנוהל-מערכת) — זמן אמת ללא הגדרה ידנית; דורש מפתח Read/Write, ואחרת נופל בחן למסלול הידני
• כפתור 'סנכרן Webhook' בכרטיס החנות + endpoint register-webhook לרישום מחדש לחיבורים קיימים (כמו חנויות שחוברו לפני הפיצ'ר)
• Cron גיבוי sync-woocommerce-orders כל 5 דקות, מושך לפי modified_after (תופס גם הזמנות שעברו ל-processing אחרי תשלום); דה-דופ משותף עם ה-Webhook לפי (tenant, customer, connection, externalOrderId) + barcode זהה
• מדריך החיבור בפורטל עודכן (תיבת 'איך הסנכרון עובד', הבהרת ה-Secret), וכשל-חיבור לחנות נרשם כ-warning ולא כשגיאת-מערכת כדי לא להפעיל התראת admin בכל מחזור
• סנכרון ה-Webhook מוחק כעת hooks ישנים לפי נתיב מזהה-החיבור (לא URL מדויק), כך שכפילויות בכתובת מעט שונה (www מול apex) מוסרות ולא יוצרות 401 ומסירה כפולה
• תוקן: סטטוס ההזמנה של WooCommerce (processing/on-hold) דלף ל-additionalData.status ונראה ללקוח כסטטוס משלוח שגוי + הסתיר את המשלוח מדפי השיבוץ. המיפוי שומר אותו כעת תחת wooStatus, והמשלוח המיובא נקלט כ'משלוח חדש' (UNASSIGNED) וניתן לשיבוץ/דחיפה לליונוויל
• סנכרון סטטוס חזרה ל-WooCommerce על כל מעבר סטטוס (לא רק 'נמסר'): נמסר/הושלם→completed, בוטל→cancelled, נכשל→failed; 'נקלט במחסן' ו'יצא להפצה' מתועדים כהערה בציר-הזמן של ההזמנה (אין להם סטטוס מובנה ב-WooCommerce). פועל גם על מעברים מליונוויל (upsertShipment, AI-lock-aware) וגם על שינוי סטטוס ידני ב-Shipnest, fire-and-forget
• פריטי הזמנה כוללים כעת תמונת מוצר ומחיר: קולטים את image.src מ-line_items של WooCommerce ושומרים בעמודה image_url חדשה ב-order_item; כרטיס פריטי המשלוח מציג thumbnail לכל פריט (placeholder לפריטים ללא תמונה). גם המחיר נשמר כעת בשידור (עבר דרך ליבת יצירת-המשלוח, קודם ירד)

משתמשים רבים ביקשו דרך מהירה לטפל בקבצי יבוא גדולים עם שורות שגויות: במקום לתקן עשרות שורות אחת-אחת בתוך הטבלה, אפשר כעת להוריד את השורות השגויות בלבד כקובץ אקסל, לתקן אותן בנוחות באקסל, ולהעלות מחדש רק אותן. בשלב התצוגה המקדימה (טאב 'שגויות') נוסף כפתור 'הורד שגויות' לצד כפתור ה-AI; הוא מייצא את אותן שורות חוסמות (שדות חובה חסרים, טלפון לא תקין, מזהה כפול וכד') בדיוק בפורמט תבנית היבוא הסטנדרטי — כך שהקובץ נטען בחזרה ללא מיפוי מחדש — עם עמודת 'סיבת שגיאה' ראשונה המפרטת לכל שורה מה צריך לתקן. עמודת הסיבה אינה ממופה ביבוא ולכן מתעלמים ממנה אוטומטית בהעלאה החוזרת. הפיצ'ר זמין גם בפורטל הלקוחות (אותו רכיב יבוא).

נציגות השירות ביקשו לדעת מתי הבוט כבר טיפל בפנייה, כדי לא לטפל בה כפול. עד כה כשהבוט גישר (למשל: לקוח שואל צפי → הבוט שואל את השליח בקבוצת השליח), קבוצת המקור — שם הלקוח והנציגות צופות — נשארה שקטה עד שחזרה התשובה, ולא היה ניתן לדעת שהבוט תפס את הפנייה. כעת, מיד כשהבוט פותח גישור בפועל, הוא רושם הודעת יידוע קצרה בקבוצת המקור (כציטוט של ההודעה המקורית): 'בודק מול השליח את צפי המסירה של משלוח X, אעדכן בהקדם 🔎' / 'מברר מול הלקוח...'. ההודעה נשלחת אך ורק כשהבוט באמת פעל ופתח גישור — לא כשהוא שותק או מתעלם — ופעם אחת בלבד (גארד hasOpenRelay), לא על כל הודעה חוזרת. הנוסח ניתן לעריכה פר-תרחיש בהגדרות → תרחישי הבוט (תבנית 'יידוע שהבוט מטפל'). חל על חמשת תרחישי הגישור: צפי, תיאום/שינוי מועד, אין מענה, כתובת שגויה וטלפון שגוי. תרחישי השידור ואימות הקבלה כבר עונים באותה קבוצת מקור, ולכן אינם כלולים.

ציטוט הודעות (Green API quotedMessageId) אפשרי רק באותו צ'אט. הודעות הבוט שהן חוצות-צ'אט (שאלת צפי לשליח, בקשת טלפון/כתובת ללקוח) לא יכולות להיות מצוטטות כי הטריגר נמצא בקבוצה אחרת — וזה החלק שנראה הכי הרבה. תשובות השידור, לעומת זאת, נשלחות באותה קבוצה של הקבלן — ושם עכשיו הוספנו ציטוט: '✅ שודר אליך', 'כדי לשדר אצטרך מספר', 'לא נמצא' וכו' נשלחות כתשובה מצוטטת על הודעת הבקשה של הקבלן, כך שברור ויזואלית למה הן מתייחסות. (relay-back ונדנודים כבר מצטטים מאז קודם; נדנודים עדיין כבויים כברירת מחדל.)

אנשי המחסן דיווחו שהדף מציג חבילות שכבר עזבו את המחסן (נמסרו או יצאו להפצה) כאילו הן עדיין תקועות בעגלה. הסיבה: התצוגה סיננה לפי additionalData.status='IN_INVENTORY', וסטטוס זה נשאר 'תקוע' כשעדכון הסטטוס מליונוויל מתעכב או מתפספס. עד כה השאילתה הסתירה רק משלוח 'בדרך כרגע' (שליח משובץ), אך לא משלוח שכבר נמסר — כך שמשלוח נמסר עם סטטוס תקוע 'קפץ' חזרה לעגלה. כעת התצוגה סומכת על ביקור המסירה ועל חותמת היציאה מהמחסן יותר מאשר על שדה הסטטוס: מוסתרים משלוחים שביקור המסירה שלהם הושלם (isDone / deliveredAt) או שיצאו להפצה (out_inventory_at אחרי הקליטה) — תוך שמירה על משלוחים שנכשלו וחזרו פיזית למחסן. אומת מול נתוני פרודקשן: 15 משלוחים שגויים הוסרו (כולל אחד שנמסר במרץ), ללא פגיעה ב-2,102 המשלוחים שבאמת ממתינים. בנוסף: טופל מצב שבו כשל זמני בטעינת ה-API הציג 'המחסן ריק' מטעה (כעת מוצג באנר שגיאה והנתונים הקיימים נשמרים על המסך), והעגלות ממוינות כעת מספרית (1,2,3…10,11) במקום לקסיקוגרפית (1,10,11…2,20).

עד כה הודעות הבוט פירטו את המשלוח בסוגריים עם מידע דל (למשל '(מורן 5, פרדס חנה)'). כעת בכל תרחישי הגישור — צפי, אין מענה, טלפון שגוי, כתובת שגויה, תיאום מחדש וכשל מסירה — פרטי המשלוח מופיעים בדיוק באותו פורמט שהנציגות מעתיקות מכרטיסיית פרטי היעד בדף המשלוח — בלוק מסודר עם אימוג'ים: מספר משלוח, שם הנמען, רחוב ומספר, דירה וקומה (כשקיימים), עיר וטלפון. הוסף placeholder חדש {details} לתבניות הניתנות לעריכה (לצד {barcode}/{address} שעדיין נתמכים). בתרחישי בקשת שידור הפורמט נשאר תמציתי כפי שביקשת.

בדיווח שליח (אין מענה / נייד לא תקין / אין זיהוי) הבוט שייך את הדיווח למשלוח לפי הברקוד (מהטקסט או מצילום המדבקה), או — כשאין ברקוד — ל'משלוח הפעיל האחרון של השליח'. שני המסלולים לא בדקו את סטטוס המסירה: מסלול הברקוד התאים כל משלוח לפי המספר ללא סינון, ומסלול ה-fallback סינן בטעות לפי sendStatus (סטטוס שליחת הודעת הוואטסאפ ללקוח) במקום סטטוס המסירה. כך משלוח שכבר נמסר במרץ — אך הודעת הלקוח שלו מעולם לא סומנה כנשלחה (sendStatus=PENDING) — שוּיֵּך לדיווח, והבוט טרטר את הלקוח הלא-נכון שוב ושוב ('השליח מדווח שמספר הטלפון שגוי במשלוח 22834782...'). כעת שני המסלולים מתבססים על סטטוס המסירה הקנוני (status) ומחריגים משלוחים שנמסרו/נכשלו/בוטלו; ואם הברקוד בדיווח מצביע על משלוח שכבר נמסר — הבוט שותק ולא נופל אחורה למשלוח אחר.

נוספו לטבלת המשלוחים עמודות פרטי המוצא (האיסוף), במקביל מלא לעמודות היעד: עיר מוצא, אזור חלוקה מוצא, כתובת מוצא ומועד האיסוף. במקביל, עמודות היעד הקיימות תויגו מחדש כדי שיהיה ברור לאיזה צד הן שייכות: 'עיר' → 'עיר יעד', 'אזור' → 'אזור חלוקה יעד', 'כתובת' → 'כתובת יעד', ו'תאריך מסירה' → 'מועד מסירה'. 'כתובת מוצא' מציגה רחוב+מספר (בדומה ל'כתובת יעד'), ו'עיר מוצא' היא עמודה נפרדת. השדה pickupZoneCode נוסף ל-API של רשימת המשלוחים — גם בנתיב ה-Prisma וגם בנתיב ה-SQL הגולמי (המופעל בסינון לפי סטטוס/שליח), יחד עם delay_clock_started_at — כך שהעמודות החדשות מתאכלסות בכל שילוב פילטרים. כל עמודות המוצא מוסתרות כברירת מחדל ומופעלות מתפריט העמודות.

• ארבע עמודות מוצא חדשות: עיר מוצא, אזור חלוקה מוצא, כתובת מוצא, מועד האיסוף — מקבילות לעמודות היעד
• עמודות היעד תויגו מחדש לבהירות: עיר → עיר יעד, אזור → אזור חלוקה יעד, כתובת → כתובת יעד, תאריך מסירה → מועד מסירה
• pickupZoneCode + delay_clock_started_at נוספו לנתיב ה-SQL הגולמי (סינון סטטוס/שליח) כך שהעמודות מתאכלסות בכל שילובי הסינון
• כל עמודות המוצא מוסתרות כברירת מחדל — הפעלה מתפריט העמודות

במודל 'דיווח משמרת רטרואקטיבי' (וכל בורר שעות אחר שנפתח בתוך דיאלוג), העמודות הנגללות של שעה/דקה לא נגללו במגע בטלפון — הן היו 'תקועות'. הסיבה: פאנל הבורר עבר portal אל גוף המסמך, מחוץ ל-DialogContent, ולכן נעילת הגלילה של הדיאלוג (react-remove-scroll) חסמה אירועי מגע שמקורם מחוץ לאזור הנעול. התיקון ממקם את פאנל הבורר בתוך הדיאלוג הקרוב (portal container), כך שהוא נכלל באזור המותר לגלילה והמגע עובד. במקביל, מרכוז הערך הנבחר בעת הפתיחה מתבצע מעתה על העמודה בלבד (scrollTop ידני) במקום scrollIntoView, כדי שלא יזיז את גלילת הדיאלוג עצמו.

טבלת המשלוחים חושפת מעתה את אותם נתוני תמחור ורווחיות שהיו זמינים רק באקורדיון 'תמחור ורווחיות' שבדף המשלוח הבודד: מחיר בסיס, עלות ליונוויל, עלות איסוף, עלות מסירה, סה"כ עלות ורווח. כל העמודות נחשפות רק למשתמשים עם הרשאת finance:view ומוסתרות כברירת מחדל — המשתמש מפעיל אותן מתפריט העמודות. 'מחיר בסיס' הוא תעריף הבסיס במחירון הלקוח (ריק כשאין מחירון). הרווח חושב עד כה נאיבית כ'מחיר פחות עלויות'; מעתה הוא מחושב כמו בפאנל הפר-משלוח — סה"כ לחיוב ללקוח (בסיס × מכפיל דחיפות + תוספות) פחות עלות הביצוע, עם נפילה למחיר ליונוויל כשאין מחירון, ומוצג רק לאחר שחושבו עלויות האיסוף/מסירה. baseRate וההכנסה מחושבים פר-עמוד בשרת דרך helper מקובץ (שתי שאילתות בלבד). בנוסף, העמודה 'מחיר' (מחיר ליונוויל) שונתה ל'עלות ליונוויל' והוגנה אף היא מאחורי finance:view, עקבי עם שאר העמודות הפיננסיות.

• שש עמודות פיננסיות בטבלת המשלוחים — מחיר בסיס, עלות ליונוויל, עלות איסוף, עלות מסירה, סה"כ עלות, רווח — מקבילות לאקורדיון 'תמחור ורווחיות' בדף המשלוח
• מוצגות רק למשתמשים עם הרשאת finance:view, מוסתרות כברירת מחדל (הפעלה מתפריט העמודות)
• הרווח מחושב לפי מחירון הלקוח (בסיס × מכפיל דחיפות + תוספות) פחות עלות הביצוע, ומוצג רק לאחר שחושבו עלויות האיסוף/מסירה
• חישוב baseRate + הכנסה מקובץ פר-עמוד בשרת (שתי שאילתות), עם נפילה למחיר ליונוויל כשאין מחירון ללקוח
• העמודה 'מחיר' שונתה ל'עלות ליונוויל' והוגנה מאחורי finance:view
• נוספה עמודת 'סה"כ לחיוב' (החיוב המלא ללקוח: בסיס × מכפיל + תוספות, או מחיר ליונוויל כשאין מחירון) — משלימה את התמונה: רווח = סה"כ לחיוב − סה"כ עלות
• ייצוא ה-Excel של הטבלה מכבד מעתה את התצוגה ברגע הלחיצה — רק העמודות הגלויות (בסדרן) ורק השורות שעוברות את הפילטרים הפעילים (כולל העמודות הפיננסיות והשדות המותאמים). קודם יוצאה רשימת עמודות קבועה שהתעלמה מהבחירה
• הייצוא מוריד מעתה את כל השורות התואמות לסינון (כל העמודים), לא רק את הדף שעל המסך — שליפה מהשרת בלולאת עמודים עד מיצוי התוצאות, עם חיווי טעינה וספירת שורות
• הוסרה העמודה 'השליח קרוב נשלח' (חותמת הזמן של התראת 'השליח קרוב') מטבלת המשלוחים — שם מבלבל ולא נחוץ

דף /settings/ai-insights הציג עד כה 'זיכרון על ישויות' (תצפיות על לקוח/שליח/משלוח ספציפי) — מה שנראה כטריוויה חסרת-משמעות. במקביל, התובנות שה-AI אוסף על עצמו (פעולות שלא ידע לבצע, טעויות חוזרות, שאלות שלא ידע לענות — רמת 'system') היו חבויות בלוח המפתחים בלבד ולא נחשפו לבעל המערכת. הדף נבנה מחדש כתצוגת שיפור-עצמי: הוא מציג כעת את תובנות-המערכת של הטננט עצמו, עם הרחבת המקור (השיחה/הקבוצה ממנה נלמדה), סימון 'טופל'/'נדחה' ומחיקה. תובנות על ישות (לקוח/שליח/משלוח) ירדו מהדף ומוצגות מעתה בכרטיס הייעודי שבדף של אותה ישות — שם הן הקשריות — וממשיכות להיות מוזרקות לפרומפט כרגיל. נוסף endpoint ייעודי לטננט (/api/ai/insights/system) המקודד-קשיח ל-entityType=system ולטננט של המבקש, כך שבידוד ה-multi-tenancy נשמר במלואו (הבידוד הקודם בנתיבי-הישות לא רוכך). תג 'תובנות' בסיידבר סופר מעתה תובנות-מערכת ממתינות בלבד.

• הדף מציג את תובנות-המערכת של הטננט: מה שהבוט לא ידע לבצע, טעה בו או לא הבין — לזיהוי מה לשפר
• תובנות לקוח/שליח/משלוח ירדו מהדף ומוצגות בכרטיס שבדף של אותה ישות (עדיין מוזרקות לפרומפט)
• endpoint ייעודי /api/ai/insights/system (+ [id] ל-triage/מחיקה) — scoped קשיח ל-system + tenantId; בידוד multi-tenancy נשמר
• תג 'תובנות' בסיידבר משקף מעתה את מה שהדף מציג — תובנות-מערכת ממתינות בלבד
• תיעוד /docs/ai עודכן לפיצול בין תובנות-ישות (בכרטיס הישות) לתובנות-מערכת (בדף ההגדרות)
• הרחבת 'מקור' מציגה כל הודעה בשורה נפרדת עם תאריך/שעה מקוצר ושם הכותב — תובנות חדשות נשמרות הודעה-הודעה (חילוץ מובנה דרך ה-webhook, אדיטיבי ללא שינוי בסיווג), הישנות מפוצלות לתצוגה; רכיב מקור משותף לדף ההגדרות וללוח המפתחים

לקוחות קצה קיבלו הודעות וואטסאפ בלילה כשנפתח משלוח בשעות מאוחרות. הסיבה: טריגר שמוגדר 'מיידי' (וזו גם ברירת המחדל) שלח ישירות דרך sendWhatsApp שבדק רק שבת — ולא את שעות הפעילות שהוגדרו לטננט (ברירת מחדל 08:00–21:00). כעת גם הנתיב המיידי בודק את חלון השליחה (isWithinMessagingWindow): אם המשלוח נוצר מחוץ לשעות הפעילות (או בחג חסום), ההודעה נכנסת לתור ההודעות המתוזמנות ומשתחררת אוטומטית ברגע שהחלון נפתח — בדיוק כמו מנגנון הצבירה שכבר היה קיים, דרך קרון scheduled-messages שרץ כל 5 דקות ומדלג על הודעות מחוץ-לחלון בלי לבזבז ניסיון. חסימת שבת ממשיכה כמקודם (תור עד מוצ"ש). בנוסף — בטופסי הטריגרים, מתחת לאפשרות 'מיידי', נוספה הבהרה שהשליחה מוגבלת לשעות הפעילות וההודעה תיצבר ותישלח כשייפתחו. ובדף שעות הפעילות (/messages/preferences) נוספה ולידציה שמונעת שמירת טווח לא תקין — שעת הסיום חייבת להיות מאוחרת משעת ההתחלה; טווח שעובר חצות (למשל 21:00–08:00) אינו נתמך וחוסם את כפתור השמירה.

בקבוצת שליח/קבלן הבוט שלח לעיתים 'כדי לשדר אליך — אצטרך את מזהה המשלוח' בלי שאיש ביקש לשדר, מנותק לגמרי מההקשר. שני גורמים תוקנו: (1) חלון זמן — איסוף מספרי המשלוח כבר היה מוגבל ל-20 דקות, אבל שער-הזיהוי (האם זו בכלל בקשת שידור?) בדק את כל ה'מטח' מאז התגובה היוצאת האחרונה (עד 30 הודעות), כך שמילת-שידור ישנה מלפני שעות עדיין הדליקה אותו; כעת גם השער מוגבל לאותן 20 דקות אחרונות. (2) הפרדת צוות מקבלן — שער-הזיהוי בדק את כל הטקסט כולל שורות שכתב חבר צוות שלנו ([צוות: ...]), כך שמילת-שידור שצוות כתב הדליקה את הבוט; כעת השער קורא אך ורק את תוכן הקבלן (לא-צוות), עקבי עם איסוף-היעדים שכבר דילג על הודעות צוות. בקשת שידור חייבת להגיע מהקבלן, לא מאיתנו.

נוסף נדנוד אוטומטי: כשהבוט שואל שליח/קבלן שאלה (למשל צפי מסירה) ולא מתקבלת תשובה, הוא שולח תזכורת בקבוצת השליח — בציטוט השאלה המקורית — כל מספר שעות שמוגדר, וממשיך לנדנד בהדרגה (תזכורת 1, 2, ...) עד שמתקבלת תשובה (עד 10 תזכורות). הנדנוד נשלח אך ורק בשעות הפעילות של העסק (ברירת מחדל 08:00–21:00, מודע לשבת/חגים — אותו מנגנון של ההודעות המתוזמנות), כך שלא נשלחות הודעות בלילה; הוא מתחדש למחרת בבוקר עם נוסח 'בוקר טוב' רך, ומגוון את הניסוח כדי שלא יהיה רובוטי. הנדנוד חל אך ורק על תרחישים שממתינים לשליח/קבלן (צפי, תיאום מחדש) — לעולם לא ללקוחות. בעריכת התרחיש (/settings/bot-scenarios) נוסף מתג 'נדנוד אוטומטי' + הגדרת מרווח השעות; כבוי כברירת מחדל.

• מתג נדנוד + מרווח שעות לכל תרחיש בר-נדנוד (כבוי כברירת מחדל)
• תזכורות בציטוט השאלה המקורית, מוגבלות לשעות פעילות (מודע לשבת/חגים), המשך בבוקר עם גיוון
• רק לשליחים/קבלנים (relay שממתין לשליח), לעולם לא ללקוחות
• מנוע: cron כל 15 דק' (/api/cron/scenario-nudges) + מעקב nudge_count/last_nudge_at על ה-relay
• מפסיק לנדנד אוטומטית כשהמשלוח כבר טופל (נמסר/נכשל/בוטל) — אין תזכורת מיותרת על משלוח סגור
• גיוון נוסח מורחב, במיוחד בפתיחים של תזכורות הבוקר; המונה מתאפס בכל בוקר (לא נצבר מיום ליום)
• נדנוד גם לשאלות צוות: כששואלים שליח על משלוח בקבוצה (עם מספר) והוא לא עונה — הבוט מזכיר לו; נתפס מרגע ההפעלה והלאה, נעצר כשהשליח עונה או כשהמשלוח טופל. מתג ייעודי בהגדרות (כבוי כברירת מחדל)

כשהבוט מחזיר תשובת גישור לקבוצה (למשל אחרי שהשליח עונה על שאלת צפי — 'לגבי X: נמסר אתמול', או כשהלקוח עונה על 'אין מענה'), ההודעה הופיעה כהודעה עצמאית שנראתה 'מנותקת מהקשר'. כעת הבוט שולח אותה כ**תשובה מצוטטת** ישירות על ההודעה המקורית שפתחה את הגישור (שאלת הצפי של הלקוח / דיווח השליח), כך שברור מיד למה היא מתייחסת. מומש דרך השדה quotedMessageId של Green API (ציטוט אפשרי רק לאותו צ'אט). הוספנו לכידה ושמירה של מזהה הודעת-הטריגר הנכנסת (עמודה trigger_message_id ב-relay), והעברנו אותו עד לשליחת התשובה. חל על כל תרחישי הגישור (צפי, אין מענה, כתובת שגויה, טלפון שגוי, תיאום מחדש). שאלת-הביניים לשליח אינה מצוטטת (צ'אט אחר — Green API לא מצטט בין צ'אטים).

• תשובת הבוט מופיעה כשרשור (reply) על ההודעה המקורית — סוף ל'הודעה שצצה משום מקום'
• נשמר מזהה הודעת-הטריגר הנכנסת (trigger_message_id) לכל relay
• תמיכה ב-quotedMessageId לאורך ה-adapter והשולח; חל על 5 תרחישי גישור

באנר ה-DisconnectSeparator שמופיע כרונולוגית בתוך צ'אט ב-business-inbox רוכך: הצ'יפ הוקטן (ריפוד וגופן קטנים יותר, אייקון h-2.5) ועבר מצבע ענבר בולט לצבע ניטרלי עדין (bg-muted/40, text-muted-foreground/70, ring-border/30). נוסח הטקסט והקווים האופקיים משני הצדדים נשמרו כמות שהם.

עד כה במסך 'תרחישי הבוט' חלק מהביטויים שמפעילים תרחיש היו מובנים (קבועים, לא ניתנים להסרה) וחלק תוספות של הטננט. כעת כל הרשימה ניתנת לעריכה: אפשר להסיר כל ביטוי, להוסיף ביטויים משלך, ולשחזר לברירת מחדל — כל טננט מגדיר לעצמו בדיוק מה מפעיל כל תרחיש. בתרחיש השידור (דטרמיניסטי) ההסרה אמיתית לחלוטין: הסרת מילת מפתח באמת מפסיקה להפעיל אותה, תוך שמירה על הכוונון מול false-positives (כמו ש'שדרות' לא נחשב 'שדר') לביטויים שנשארו. בתרחישי ה-AI כל ביטויי הטריגר הועברו מהקוד הקשיח אל הרשימה הניתנת לעריכה, והמסווג מופעל כעת אך ורק לפי הרשימה (תיאור התרחיש נשאר רק כהקשר ולמניעת התאמות שגויות — לא כטריגר): רשימה ריקה משביתה את התרחיש, והסרת ביטוי מסירה אותו כמקור טריגר (ניסוח או שגיאת-כתיב ברורה של ביטוי שנשאר עדיין תזוהה). הרשימות מאותחלות בברירת מחדל חזקה ומקיפה, וטננט שלא נוגע בהגדרות מקבל התנהגות זהה כמעט לחלוטין לקודמת.

• כל ביטוי טריגר ניתן להסרה — לא עוד ביטויים 'נעולים'
• כפתור 'החזר ברירת מחדל' לשחזור הביטויים המובנים
• שידור: רפקטור למשפחות מילות-מפתח (תווית + תבנית מכוונת) — הסרה אמיתית בלי לאבד הגנה מ-false-positives
• תרחישי AI: ביטויי הטריגר הוצאו מהקוד הקשיח — המסווג מופעל אך ורק לפי הרשימה הניתנת לעריכה (רשימה ריקה = תרחיש כבוי)
• אחסון בפורמט חדש (רשימה מלאה) עם תאימות-לאחור מלאה לנתונים קיימים

התיעוד הציבורי ב-shipnest.io/docs הורחב כך שיכסה את כל מודולי המערכת, ולא רק את ליבת הלקוח/תפעול. נוספו 9 דפים חדשים: מחסן ו-3PL, עובדים ונוכחות ושכר, פיננסים, AI ובוט, אנליטיקה, אזורי הפצה וישובים, תפעול (ליקוט ובירורים), סוכנים, והגדרות וניהול. בנוסף הורחבו שלושה דפים קיימים: משלוחים (תצוגות מתקדמות — איסופים, מפה, יעד שבת/אקספרס, פערי הפצה, תמונת מחסן, סל מחזור), נהגים (ניתוח, התראות geofence, ושליחים מזדמנים), והודעות (תיבות נכנסות, היסטוריה ועלויות). הניווט בסיידבר אורגן מחדש לקבוצות (לקוחות ומכירות; שליחים, עובדים ומחסן; פיננסים ואנליטיקה; מערכת), ודף הבית של ה-docs עודכן עם כרטיסי המודולים החדשים. כל התוכן נגזר מקריאה ישירה בקוד, עם הבחנה כנה בין ששוחרר למה שעדיין בפיתוח.

• 9 דפים חדשים: מחסן/3PL, עובדים, פיננסים, AI/בוט, אנליטיקה, אזורי הפצה, תפעול, סוכנים, הגדרות
• הרחבת דפי משלוחים (תצוגות מתקדמות), נהגים (ניתוח/התראות/מזדמנים) והודעות (תיבות נכנסות/עלויות)
• ארגון מחדש של ניווט ה-docs ל-9 קבוצות, ועדכון כרטיסי דף הבית
• כיסוי מלא: כעת לכל מודול בסיידבר של האפליקציה יש דף תיעוד תואם

בשליחת תבנית Meta מאושרת לנמען מתוך תיבת הדואר הנכנס (/messages/inbox), השדות של הפרמטרים ({{destination_name}}, {{barcode}}, {{source_name}} וכו') כבר אינם ריקים — הם מתמלאים אוטומטית מהמשלוח האחרון של אותו נמען לפי שם המשתנה (destination_name → שם הלקוח, barcode → ברקוד, source_name → שם השולח, וכן שדות כתובת/יעד נוספים). כל שדה נשאר ניתן לעריכה, יש חיווי 'מולא אוטומטית מהמשלוח האחרון' וכפתור 'מלא מהמשלוח האחרון' למילוי חוזר. צד שרת: ה-API של ההודעות מחזיר כעת מפת variable→value שנבנית מהמשלוח התואם האחרון דרך buildVariables המשותף.

תחילת אינטגרציה מול חלוקת last-mile של DHL דרך חילופי קבצי TXT ב-SFTP (פורמט Exp/Arr/Del מופרד ב-pipe). נבנתה שכבת הפורמט הטהורה תחת lib/integrations/dhl/: כתיבת קובץ Exp (17 עמודות), פירוק קבצי Arr/Del כיומן אירועים (מיון לפי זמן והכרעת הסטטוס האחרון לכל שטר מטען), מיפוי סטטוסי הספק (OK/BA/NH/WC) לסטטוסים הקנוניים, ועזרי תאריך/טלפון/שם-קובץ — מאומת ב-12 בדיקות vitest מול קבצי הדוגמה האמיתיים. קוד תוסף בלבד שעדיין לא מחובר לזרימה; שלבי ההמשך (תעבורת SFTP, cron, קונפיג, חיבור לשיגור) ממתינים לתשובות הספק. בהמשך היום נבנתה גם שכבת התעבורה: לקוח SFTP (ssh2-sftp-client), קידוד Windows-1255/UTF-8, טעינת קונפיג מוצפן פר-tenant מ-TenantProviderConfig, אורקסטרציית סריקת inbox במצב dryRun בלבד (דיווח ללא שינוי סטטוסים), ושלד cron (טרם רשום ב-vercel.json). סה"כ 18 בדיקות vitest עוברות, אפס שגיאות טיפוסים.

נוסף hook משותף ומטומן (useDrivers) לשליפת רשימת הנהגים, שממזג קריאות מקבילות לבקשת רשת אחת ומגיש את הרשימה מהמטמון בחזרה לדף. בדף פרטי המשלוח, רשימת הנהגים נשלפת כעת במקביל לטעינת המשלוח (במקום להמתין לו) ולא מחדש בכל כניסה — פתיחת משלוח מהירה יותר. שאר הצרכנים של הרשימה יומרו ל-hook המשותף בהמשך.

בעריכת תצוגת היבוא, הקלדה בתא בודד גרמה לרינדור מחדש של כל השורות הנראות (עד 200) ולחישוב מיקום כל שורה ב-findIndex (O(n) לכל שורה → O(n²) לכל תו), מה שהפך את ההקלדה ביבוא גדול לתקועה. כעת: (1) שורת היבוא עטופה ב-React.memo כך שרק השורה שנערכה מתרנדרת מחדש (השאר נשארות יציבות מבחינת reference); (2) מיקום השורה מחושב מראש פעם אחת ל-Map (O(1) לכל שורה). אין שינוי בהתנהגות או בנתונים — רק הקלדה חלקה.

כל ניווט בפורטל הלקוח הריץ פעמיים את אותה שרשרת שאילתות (ה-layout וה-page כל אחד שלף בנפרד את היקף ההרשאות ואת קבוצת הלקוחות המקושרת). העטיפה ב-React cache() ממזגת אותן לקריאה אחת לכל בקשה — חיסוך של ~3 round-trips בכל ניווט בפורטל. במקביל, ב-layout של ממשק הצוות, שלושת בדיקות ה-feature-flags (מחסן, הצעות מחיר, חוזים) שלפו כל אחת בנפרד את הגדרות ה-tenant; כעת הן חולקות שליפה אחת ממוזגת (cache) — שלוש שאילתות לאחת. אין שינוי התנהגות — רק פחות round-trips ל-DB וטעינה מהירה יותר.

שני תיקונים בבוט התרחישים בקבוצות הוואטסאפ. (1) שידור רשימה: כשקבלן שולח בקבוצה רשימה של כמה משלוחים לשידור, הבוט שידר את הקיימים אך השמיט בשקט מהתשובה כל מספר שלא נמצא במערכת או שלא ניתן לשדר — כך שהקבלן לא ידע שמשלוח מסוים נכשל (למשל רשימה של 24508067 + 25644764 שהחזירה 'שודרו אליך 1 משלוחים' בלי לציין ש-24508067 לא נמצא). כעת התשובה המאוחדת מפרטת כל מספר שנשלח עם הסטטוס שלו (שודר / כבר משויך / כבר נמסר-הושלם / לא נמצא ❌ / לא ניתן לשדר), וכשאף משלוח לא נמצא מוצגת הודעה שמפרטת את כל המספרים; כפילות של אותו מספר עדיין מקובצת לשידור אחד. (2) דליפת טקסט-מטא ללקוח: בעדכוני 'אין מענה'/'כשל מסירה' התקציר של דיווח השליח נוצר ע"י מודל, וכשהקלט לא היה דיווח שליח בודד אלא רשימת מספרים, המודל החזיר לעיתים טקסט-מטא באנגלית ('I need the actual courier reports...') שדלף כמו-שהוא להודעה שנשלחה ללקוח. נוסף שומר שמוודא שהתקציר הוא עברית קצרה בלבד — אחרת חוזרים לנוסח גנרי ('אין מענה מהנמען') ושום טקסט פנימי/מטא לא מגיע ללקוח. (3) שידור שנכשל בשקט: כשקבלן ביקש לשדר משלוח שכבר נמסר/הושלם (אין לו משימת מסירה פעילה), או כשהשידור נכשל מסיבה אחרת — הבוט שתק לגמרי והקבלן לא ידע אם נשדר. כעת מוחזרת הודעה ברורה: 'אין משימת מסירה פעילה (ייתכן שכבר נמסר/הושלם/הוחזר)' או הודעת תקלה גנרית, לפי סיבת הכשל. (4) זיהוי 'לשים עלי': בקשת שידור בנוסח 'אפשר לשים עלי' (וכן 'שים עלי' / 'תשים עלי') לא זוהתה — אוצר המילים הכיר רק 'שימו עלי'/'לשבץ עלי' — כך שצילום מדבקה עם הכיתוב הזה לא שודר, ואף דולג כשנשלחה בקשה נוספת. הורחב הזיהוי לכל משפחת 'שים/לשים/תשים/לשום + עלי' ו-'שבץ/תשבץ/לשבץ + עלי', כולל צורות אות סופית. (5) חלון זמן ל-burst של קבוצת לקוח: ה'מטח' שהבוט סיווג נבנה מ'ההודעות מאז התגובה היוצאת האחרונה', אך הצוות שעונה מהטלפון האישי נספר כצד-הלקוח (לא כתגובה יוצאת), כך שללא הגבלת זמן שאלה ישנה נשארה ב'מטח' למשך ימים והפעילה את הבוט מחדש בכל הודעה חדשה לא-קשורה (שאלת צפי בת-4-ימים שוחררה לפתע ערב אחד). נוספה הגבלת חלון של 6 שעות — מטח אמיתי באותה שיחה ממשיך לעבוד, אך תוכן ישן כבר לא מפעיל את הבוט.

התיעוד הציבורי ב-shipnest.io/docs הושלם: כל הדפים שהיו מסומנים 'בקרוב' נכתבו במלואם, בעומק ובסגנון של דפי ה-API וה-CRM הקיימים. נוספו שני דפי התחלה (תחילת עבודה — חמשת הצעדים הראשונים מהתחברות ועד המשלוח הראשון; ומילון מונחים שמרכז את כל המושגים המרכזיים), חמישה דפי ליבה תפעולית (משלוחים, מעקב COD/גוביינא, לקוחות, נהגים ושיוך, ותבניות והודעות אוטומטיות), ושלושה דפי אינטגרציות (Lionwheel, Summit, WhatsApp Business). כל דף מבוסס על קריאה ישירה בקוד כדי לשקף את ההתנהגות בפועל — כולל הבחנה כנה בין יכולות ששוחררו לבין כאלה שעדיין בכתיבה (למשל אוטומציית מסמכים ב-Summit, אכיפת שעות פעילות בהודעות). בנוסף הוסרו סימוני 'בקרוב' מהסיידבר ומדף הבית, ותוקן ה-blurb של דף הלקוחות שהבטיח ייבוא ומיזוג כפילויות שאינם קיימים.

• התחלה: תחילת עבודה (5 צעדים) + מילון מונחים
• ליבה תפעולית: משלוחים, מעקב COD, לקוחות, נהגים ושיוך, תבניות והודעות אוטומטיות
• אינטגרציות: Lionwheel, Summit, WhatsApp Business (Meta Cloud API)
• התוכן נגזר מהקוד בפועל, עם הבחנה בין יכולות ששוחררו לבין כאלה בכתיבה; הוסרו סימוני 'בקרוב' מהניווט

בטבלת האיסופים (/pickups) נוסף ציר סינון חדש 'סוכן' בחלונית הפילטרים — לצד לקוח, עיר, אזור ושליח. הסוכן נגזר מהלקוח של המשלוח (customer → agent), כולל אפשרות 'ללא סוכן' למשלוחים שללקוח שלהם לא משויך סוכן. הספירות מתעדכנות חיה (faceted) ומשתלבות עם שאר הפילטרים הפעילים, בדיוק כמו שאר הצירים.

עד כה יצירת לקוח ב-Shipnest נשמרה רק מקומית, והקישור לליונוויל דרש ליצור את החברה ידנית בליונוויל ולהדביק את המזהה. כעת בטופס הלקוח החדש נוסף מתג 'צור גם בליונוויל' (דלוק כברירת מחדל): כשהוא פעיל, נוצרת חברה תואמת בליונוויל עם השם, הטלפון, האימייל והכתובת של הלקוח, ומזהה החברה (lionwheelId) נשמר אוטומטית על הלקוח — כך שמשלוחים שלו ייקשרו מיד לחברה הנכונה. אם כבר הוזן מזהה ליונוויל ידני, המתג מושבת והלקוח פשוט מקושר לחברה הקיימת. בנוסף, עריכת שם/טלפון/כתובת/אימייל של לקוח שכבר מקושר לליונוויל דוחפת אוטומטית עדכון (PATCH) לחברה בליונוויל. כל הקריאות לליונוויל הן best-effort — כשל לא חוסם את השמירה המקומית, מוצגת התראה רכה והלקוח נשמר כרגיל.

• מתג 'צור גם בליונוויל' בטופס לקוח חדש, דלוק כברירת מחדל; מושבת כשהוזן מזהה ליונוויל קיים
• POST /companies יוצר את החברה בליונוויל ושומר את ה-lionwheelId על הלקוח אוטומטית
• עריכת שם/טלפון/כתובת/אימייל של לקוח מקושר מסנכרנת חזרה ב-PATCH /companies, תוך מיקוד ה-location הקיים כדי לא לכפול כתובות
• best-effort ולא-חוסם: כשל בליונוויל לא מונע שמירה מקומית; קוראים שאינם ה-UI (API ציבורי/ייבוא) לא מפעילים יצירה אלא אם ביקשו במפורש

במחירון השליח נוסף מתג 'תשלום על כל איסוף בנפרד'. עד כה כל איסוף עם 2+ משלוחים מאותו לקוח באותו יום קובץ אוטומטית ל'איסוף עסקי' — תשלום סמלי אחד שמתחלק בין המשלוחים. כעת, לשליחים שמקבלים על איסוף כמו על מסירה, אפשר להפעיל את המתג כך שכל איסוף משולם בנפרד לפי תעריף 'איסוף רגיל' (פר חבילה, כולל תוספת חבילה נוספת), גם כשנאספו כמה משלוחים מאותו לקוח באותו יום — בלי קיבוץ. הדגל נשמר פר-שליח, וכל עלויות האיסוף ההיסטוריות שלו מחושבות מחדש ברקע עם השמירה. ברירת המחדל ללא שינוי (קיבוץ לאיסוף עסקי).

• מתג פר-שליח בדיאלוג המחירון — מבטל את קיבוץ ה'איסוף עסקי' עבורו
• במצב פעיל כל איסוף משולם לפי pickupRate + תוספת חבילה נוספת (פר חבילה), כמו איסוף רגיל
• עקבי לאורך כל מנועי החישוב — דוח חודשי, סנפשוט עלות איסוף ופירוט סאב-שליחים
• חישוב מחדש רטרואקטיבי של עלויות האיסוף עם שמירת המחירון

סדרת שיפורי מהירות כירורגיים בנקודות נבחרות, בלי שינוי התנהגות: (1) בורר האימוג'ים (emoji-picker-react, מאגר נתונים גדול) ב-inbox וב-business-inbox נטען כעת lazy — רק כשפותחים את הבורר — במקום להיכלל ב-JS של הטעינה הראשונית של המסכים הנפתחים ביותר. (2) גרף לוח-הבקרה בפורטל (recharts) נטען lazy אחרי כרטיסי ה-KPI, כך שדף הבית של הלקוח מגיב מהר יותר. (3) ברשימת המשלוחים, כפתור הרענון שמועבר לשורות הפך ל-callback יציב — סימון שורה או עדכון real-time כבר לא מרנדר מחדש את כל הרשימה אלא רק את השורה שהשתנתה. (4) הופעל optimizePackageImports (lucide-react, date-fns, recharts, react-day-picker) ל-tree-shaking טוב יותר של אייקונים בכל route. נבדק: typecheck נקי, build תקין, 1029 בדיקות יחידה עוברות.

מפתח API שמונפק דרך פורטל הלקוח (/portal/settings/api) היה מוגבל עד כה ל-Tenant בלבד — כך שלקוח אחד יכול היה לקרוא ולערוך משלוחים, לקוחות ומנויי webhook של כל שאר לקוחות ה-Tenant דרך ה-REST API הציבורי. מעתה כל מפתח כזה נכבל אוטומטית ללקוח שהנפיק אותו (ולסאב-לקוחות המקושרים שלו בלבד): כל endpoints ה-v1 מסננים את הקריאה והכתיבה לקבוצת הלקוחות המורשית בלבד, יצירת לקוח דרך POST /customers נוצרת כסאב-לקוח של אותו לקוח, ומנויי webhook מקבלים אך ורק events שהמשלוח/לקוח שמאחוריהם שייך לאותה קבוצה (סינון פר-לקוח ב-emit, fail-closed). מפתחות ברמת ה-Tenant שמונפקים על ידי הצוות ממשיכים לראות את כל נתוני ה-Tenant ללא שינוי.

• ApiKey ו-WebhookSubscription נושאים customerId — מפתח/מנוי של פורטל מצומצם ללקוח שלו + הסאב-לקוחות המקושרים
• GET/PATCH/cancel למשלוחים ולקוחות מסוננים ל-allowedCustomerIds; ניסיון לגעת בלקוח מחוץ לקבוצה מחזיר 404/403
• POST /customers ממפתח פורטל יוצר סאב-לקוח (parentCustomerId), POST /shipments מחויב customerId בתוך הקבוצה
• מסירת webhook מסוננת פר-לקוח — events של לקוחות אחרים לא נמסרים למנוי של לקוח (fail-closed כשלא ניתן לשייך)
• מפתחות ברמת Tenant (צוות) ללא שינוי — גישה מלאה כבעבר

תרחיש 'בקשת שידור' מבין כעת רצף של תמונות מדבקה כבקשה אחת: כשהקבלן שולח כמה תמונות וכותב מילת שידור (לשדר/שדר/תשדרו...) על אחת מהן או בהודעה נפרדת — לפני הרצף, אחריו או בתוכו — הבוט משדר את כל המשלוחים שזוהו ומשיב בהודעה אחת מאוחדת ('שודרו אליך N משלוחים ✅' עם רשימת מספרי השידור). תמונה בתוך הרצף שכתוב עליה משהו אחר (למשל 'אין מענה') לא תשודר — רק היא יוצאת מהכלל; ומספר משלוח שצוין לצד מילת השידור (בטקסט) משודר גם הוא. כדי לזהות רצף, נתיב קבוצות-השליח עבר לאיחוד-מטח (debounce 8 שניות) עם חלון 20 דקות שמונע שידור בטעות של תמונות ישנות שהצטברו. ארכיטקטונית, השידור הופרד לנתיב דטרמיניסטי נפרד — תרחישי הגישור (אין מענה/כתובת/טלפון) נשארו פר-הודעה כך שדיווחים על כמה משלוחים שונים ברצף אחד לא נדרסים. מספרי טלפון מסוננים כך שלא יזוהו כמספרי משלוח.

• מילת שידור במקום כלשהו ברצף (כיתוב על תמונה או הודעה נפרדת) חלה על כל התמונות ברצף
• תשובה אחת מאוחדת — תבנית חדשה success_multi ('שודרו אליך {count} משלוחים ✅' + רשימה), ניתנת לעריכה בהגדרות
• תמונה עם טקסט אחר משלה (הוראה שונה) מוחרגת מהשידור — שאר התמונות משודרות
• השידור הופרד לנתיב דטרמיניסטי נפרד; תרחישי הגישור נשארו פר-הודעה ולא נדרסים ברצף רב-משלוחי
• סינון מספרי טלפון (לא יזוהו כמשלוח) + תקרה של 8 משלוחים בבת אחת + חלון 20 דקות

בדף 'תרחישי הבוט', דיאלוג 'ערוך נוסח' של כל תרחיש קיבל סקציה חדשה — 'ביטויים שמפעילים את התרחיש'. עד כה אוצר מילות-המפתח שמפעיל כל תרחיש היה קבוע בקוד; כעת מוצגים הביטויים המובנים (לקריאה בלבד) ואפשר להוסיף ביטויים משלך לכל תרחיש — בלי קוד. הביטויים שמוסיפים מוזנים למסווג ה-AI (לכל התרחישים), ובתרחיש 'בקשת שידור' גם לשער הדטרמיניסטי שמאשר את הזיהוי. כך, למשל, אפשר לחדד את תרחיש 'טלפון שגוי' בעצמך ('מספר לא פעיל', 'יש 11 ספרות' וכו') או להוסיף ניסוחי שידור מקומיים של קבלן מסוים. הביטויים נשמרים פר-חברה, מנוקים (trim/כפילויות, עד 40), ואינם כופלים את הביטויים המובנים.

• סקציית 'ביטויים שמפעילים את התרחיש' בדיאלוג עריכת הנוסח — צ'יפים מובנים לקריאה + הוספה/הסרה של ביטויים משלך
• הביטויים מוזנים למסווג ה-AI לכל התרחישים, ולשער הדטרמיניסטי של 'בקשת שידור'
• נשמר פר-חברה ב-botScenarios.triggerPhrases (מנוקה, עד 40, ללא כפילות של ביטוי מובנה)
• מאפשר לחדד תרחישים (למשל 'טלפון שגוי' עם 'מספר לא פעיל') ללא שינוי קוד

בוט בדיקות-המסירה (cron ai-delivery-sessions) שמטפל בשיחות WhatsApp מול הנמען היה כותב לשדה 'הערת יעד' (destinationNotes — שמודפס על המדבקה ומסונכרן לליונוויל) גם תובנות תפעוליות פנימיות שאינן נוגעות לשליח — כמו 'המשלוח יצא להפצה והיום הוא יום ההפצה האחרון לפי ההתחייבות' — וגם דרס את ההערה הקיימת בכל סבב שיחה במקום לשמרה. הסיבה: פעולת update_notes הוגדרה ב-prompt כטקסט חופשי ללא גבולות, והקוד החיל אותה כדריסה מלאה (destinationNotes = value). כעת ה-prompt מגדיר את ההערה כהנחיית מסירה לשליח בלבד: מותר רק פרטי גישה/טיפול/העדפת זמן שמסייעים בפועל למסירה (קוד כניסה, להשאיר עם שכן, עדיפות בוקר, חוסר זמינות + בקשת תיאום), ואסור במפורש סטטוס משלוח, ימי-הפצה/SLA, מועד התחייבות או נימוקים פנימיים. בנוסף הבוט מונחה לשמר את ההערה הקיימת ולהוסיף רק פרט חדש (מיזוג, לא החלפה), ולא לפלוט update_notes כלל אם אין פרט חדש רלוונטי לשליח. נוסף שומר בקוד שמונע מחיקת הערה קיימת ע"י ערך ריק.

תרחיש 'בקשת שידור' של בוט הקבוצות עבר לדרישת מילת שידור מפורשת בכל מקרה. מספר משלוח בודד או צילום מדבקה בודד כבר לא מפעילים שידור בעצמם — רק מילה כמו 'לשדר', 'שדר', 'שדרו', 'שימו עלי', 'לא משודר', 'לא נסרק' וכו' (אפשר לצרף לצידה מספר או צילום). זה תיקן תקלות שדווחו בקבוצות שבהן קבלן הדביק מספר משלוח לצורך אחר (הפניה, דיווח על טלפון שגוי) והבוט ענה בטעות 'המשלוח כבר משויך אליך' או 'לא מצאתי משלוח'. רשימת מילות-המפתח כבר מחוזקת בגבולות-מילה עבריים כך ש'שדרות'/'משודרג' אינם נחשבים.

בדף שיבוץ האיסופים, בחירת שליח איסוף מתוך הפילטר רוקנה את הטבלה לגמרי ('אין משימות איסוף פתוחות') למרות שליד שם השליח הופיע מונה נכון (למשל 'דוד בהר — 24'). הסיבה: שם השליח שמוצג במונה נבנה בביטוי SQL אחד (TRIM לכל חלק + רווח בודד, עם נפילה ל'ליונוויל #<id>'), אבל כשלוחצים על השם, ה-WHERE שמסנן את הטבלה שיחזר את השם בביטוי שונה (TRIM(CONCAT(...))) — כך ששליח עם רווח מיותר ב-firstName (למשל 'דוד ' + 'בהר' → המונה מציג 'דוד בהר' אבל הסינון יצר 'דוד בהר' עם רווח כפול) או שליח עם שם ליונוויל-בלבד מעולם לא הותאם, והטבלה התרוקנה. כעת שני הצדדים — בניית התצוגה והתאמת הסינון — משתמשים באותו ביטוי SQL יחיד (driverDisplayNameSql) בכל שלושת ה-endpoints (טבלה, מפה, מוני הפילטר), כך שהתאמה מובטחת. אומת מול נתוני פרודקשן: לפני התיקון הסינון החזיר 0 שליחים לטוקן 'דוד בהר'; אחריו הוא מתאים את השליח ואת 30 משימות האיסוף הפתוחות שלו. בנוסף: כפתור ה-X להסרת השליח המשובץ בתיבת השיבוץ הופיע רק אצל שליחים שנמצאים ברשימת השליחים הפעילים — שליח משובץ שסונן מהרשימה (לא-פעיל / ליונוויל-בלבד) הציג את שמו אך ללא כפתור הסרה. כעת הכפתור מותנה בקיום שיבוץ בלבד ולכן מופיע אצל כל שליח משובץ. כמו כן, אייקון החיפוש שמוצג בתיבת השיבוץ כשאין שליח משובץ הוצג עם רקע אפור (bg-muted) שבלט מול הדף — הוסר הרקע כך שהאייקון נטמע בעיצוב (נשאר רק המסגרת, בדומה לכפתור ה-X). התיקון הוחל על כל מופעי תיבת שיבוץ השליח במערכת — לא רק בדף שיבוץ האיסופים אלא גם בכרטיסי המשימות של עמוד המשלוח (TasksCard ו-ShipmentTasks) ובדיאלוג השיבוץ הקבוצתי, וגם על אייקון בורר התאריך הצמוד באותן שורות כדי לשמור על אחידות.

כל הקלסיפיירים וה-extractors של ה-AI (סיווג הודעות שליח, אישור מסירה, OCR ברקוד, חילוץ הנחיות מסירה, תיקון ומיפוי יבוא, וכריית תובנות) רצו עד כה ב-temperature ברירת-מחדל (~1.0) — כלומר אותה הודעה יכלה להתקבל אחרת בהרצות שונות. כעת הם רצים ב-temperature=0: לכל קלט המודל מחזיר את התשובה הכי-סבירה, באופן עקבי ומדויק יותר. אפס שינוי בעלות (אותם טוקנים) וללא נגיעה בלוגיקת הבוט. שיפור אפקטיביות ישיר — פחות סיווגים אקראיים שגויים.

עד כה חיפוש המשלוחים של עוזר ה-AI הכיר רק את הברקוד הראשי (וכן שם, עיר, רחוב, public_id), ולא ידע לאתר משלוח לפי מזהי ה-partner — מזהה נכנס (originPartnerTaskId), מזהה יוצא לאיסוף (pickupOutboundTaskId) ומזהה יוצא למסירה (targetPartnerTaskId) — כך שמשלוחים שהגיעו מספק מקור או שודרו לקבלן חיצוני לא נמצאו לפי המזהה שהמשתמש מכיר. כעת שלושת המזהים נוספו גם לחיפוש הטקסט החופשי (searchShipments/countShipments) וגם לשליפת פרטי משלוח בודד (getShipmentDetails): כל מזהה שהמשתמש מקליד נפתר מול כל עמודות המזהה. שינוי additive בלבד — חיפוש לפי ברקוד נשאר זהה.

סטטוס המסירה הקנוני של משלוח, שהיה כלוא בשדה JSON (additionalData.status) ונדרש סינון עם OR על מספר ייצוגים ללא אינדקס, קודם לעמודת 'status' מאונדקסת. העמודה מתעדכנת אוטומטית ע"י trigger ב-DB מתוך additionalData.status (שנשאר מקור-האמת), כך שאף נתיב כתיבה באפליקציה לא משתנה. בוצע backfill ל-185,756 השורות הקיימות (0 אי-התאמות), נוצר אינדקס (tenantId, status, createdAt), ומשלוח חסר-סטטוס (יבוא מחסן/API ציבורי) מנורמל כעת ל-UNASSIGNED — מה שמסיר באג ידוע שבו סטטוס NULL הסתיר משלוחים מסינונים. כשלב המשך, שאילתות הסטטוס בפורטל הלקוחות (רשימת המשלוחים, לוח הבקרה וכרטיס הלקוח) עברו כעת לקרוא מהעמודה המאונדקסת במקום מה-JSON — סינון מהיר ומאונדקס. שאר נתיבי הקריאה (אנליטיקה, ליקוט, סנכרון) יעברו בהדרגה.

ה-AI האוטונומי שרץ על מפתח ה-AI החינמי של Shipnest (בוט הקבוצות: סיווג תרחישים, שער רלוונטיות, חילוץ תובנות, OCR לתמונות, וסוכן הלקוח ב-1:1) מוגבל כעת ל-1$ ביום פר-טננט. כשהמכסה נגמרת, ה-AI האוטונומי משתתק לשארית היום (התנהגות ברירת-המחדל הבטוחה של הבוט) ומופיע באנר קבוע בראש האפליקציה שמסביר שעברת את המכסה היומית החינמית ומפנה ל'הגדרות ← ספק AI' לחיבור מפתח משלך. טננט שמחבר מפתח משלו אינו מוגבל כלל, והבאנר נעלם מיידית. צ'אט ה-AI האינטראקטיבי שומר על מכסת ההודעות החינמית הנפרדת שלו ללא שינוי. תמלול (Whisper) משתמש תמיד במפתח של הטננט ולכן אינו מושפע.

• תקרת עלות 1$/יום פר-טננט על מפתח המערכת, מבוססת על ai_usage_event הקיים (בלי טבלה/אינדקס חדשים)
• אכיפה בנקודות שיודעות keySource: מנוע התרחישים (classifier/relay/insight), OCR, וסוכן הלקוח 1:1 — רק כשהמפתח הוא של המערכת
• חסימה = שתיקה (לא שבירה): הודעות עדיין נשמרות, רק התשובה/הסיווג האוטומטי מדולגים; הבדיקה fail-open על תקלת DB
• באנר קבוע בראש האפליקציה עם קישור ל-/settings/ai-provider; נעלם ברגע שמוגדר מפתח עצמי
• איפוס יומי בחצות UTC (~02:00–03:00 שעון ישראל), עקבי עם מכסת הצ'אט הקיימת

המשך פיצ'ר הלוגו לכל סאב-לקוח. (1) ירושת לוגו: חשבון מקושר ללא לוגו משלו מדפיס כעת אוטומטית את הלוגו של החשבון הראשי (האב), כך שלקוח-אב שמגדיר לוגו אחד מקבל מיתוג אחיד לכל הקבוצה — וניתן עדיין להגדיר לוגו ייעודי לכל סאב-לקוח שמבטל את הירושה. (2) זהות מלאה בין מסלולי המדבקה: הלוגו שהלקוח מעלה בפורטל משמש כעת בכל מסלולי ההדפסה של הטננט (הצוות) — מדבקה בודדת, הדפסה מרובה/ליקוט ולינק שיתוף — דרך הלפר מרכזי משותף. (3) תוקן פער שבו לינק שיתוף של מדבקה בודדת לא כלל כלל את לוגו הלקוח. (4) בעמוד הגדרות הלוגו בפורטל מוצג כעת הלוגו המורש (בעמעום קל עם הסבר) לחשבונות ללא לוגו משלהם. (5) הלוגו מוצג כעת גם בצד הצוות — בטבלת הלקוחות (אווטאר השם) ובכותרת דף הלקוח — וניתן לערוך אותו ישירות מדף הלקוח (כפתור 'לוגו': העלאה/החלפה/הסרה) דרך endpoint חדש מאובטח בהרשאת עריכת לקוחות.

• ירושת לוגו: סאב-לקוח ללא לוגו משלו מדפיס את הלוגו של החשבון הראשי (האב); הגדרת לוגו ייעודי מבטלת את הירושה
• הלוגו שהלקוח מעלה משמש בכל מסלולי המדבקה של הטננט/צוות — בודד, מרובה (ליקוט / share-bulk) ולינק שיתוף
• תיקון: לינק שיתוף של מדבקה בודדת לא הציג את לוגו הלקוח — כעת מוצג (כולל ירושה)
• ריכוז הלוגיקה בהלפר משותף (effectiveLabelLogoUrl + select אחיד) על פני כל מסלולי המדבקה
• עמוד הגדרות הלוגו בפורטל מציג לוגו מורש בעמעום עם הסבר 'יורש את הלוגו מהחשבון הראשי'
• צד הצוות: לוגו הלקוח מוצג בטבלת הלקוחות (אווטאר עמודת השם) ובכותרת דף הלקוח, עם נפילה חזרה לאייקון כשאין לוגו
• צד הצוות: עריכת לוגו לקוח ישירות מדף הלקוח (כפתור 'לוגו') — העלאה/החלפה/הסרה דרך endpoint חדש /api/customers/[id]/logo, מאובטח בהרשאת עריכת לקוחות (CUSTOMERS_EDIT) ומתועד ב-audit log

סקציית 'שעות פעילות' בהגדרות ה-AI עוצבה מחדש. בורר השעה הנייטיבי של הדפדפן (input type=time) — שאייקון השעון המובנה שלו חפף לטקסט השעה ולא ניתן לעיצוב — הוחלף ב-TimePicker משותף חדש: Popover עם עמודות שעה/דקה נגללות, בסגנון ה-DatePicker הקיים. הטבלה הגנרית עם ה-checkbox הגולמי הוחלפה ברשימת ימים נקייה עם מתג צ'ק מעוצב לכל יום, ימים סגורים מסומנים בבירור, וכפתור 'החל על כל הימים' להעתקת שעות יום אחד לכל הימים הפתוחים. בהמשך, אותו TimePicker הוטמע בכל שאר מקומות בחירת השעה במערכת במקום בורר השעה הנייטיבי: דיווח משמרת רטרואקטיבי (עובד), הוספת משמרת, רישום עובדים מזדמנים, ובוחר התאריך+שעה של משימות אדמין. אין שינוי בנתונים הנשמרים או ב-API.

ה-prefix הקבוע של סוכני ה-AI (הוראות המערכת + הגדרות 23 הכלים) נשלח מחדש בכל סבב כלי ובכל תור בשיחה, וחויב במחיר מלא. כעת הוא נשמר ב-cache (cache_control ephemeral), כך שבקריאות חוזרות בתוך החלון הוא מחויב ב-~0.1× במקום מחיר מלא — הוזלה ניכרת בעלות הקלט, ללא כל שינוי בפלט או בהתנהגות המודל. מודל ברירת המחדל נשאר Haiku, כך שאף לקוח לא משלם יותר. במקביל נוספה תשתית adaptive thinking שמופעלת אך ורק עבור לקוחות שבחרו ידנית מודל חזק (Sonnet/Opus) — היא הופכת את המודל שכבר בחרו לחכם יותר, בלי להעלות את עלות ברירת המחדל לאף אחד. כל הספקים שאינם Anthropic (Google/OpenAI-תואם) ולקוחות עם מודל נעול — ללא שינוי כלל. בנוסף, מסווג שירות-הלקוחות ב-WhatsApp — ה-prompt הסטטי הגדול ביותר ובנפח הקריאות הגבוה ביותר — עבר אף הוא ל-prompt caching (הוזלת קלט של ~85-90% בקריאות חוזרות). שלוש קריאות AI שלא נמדדו עד כה (המסווג, חילוץ כתובת מתשובת לקוח, ודייג התובנות השעתי) חוברו למטרינג כך שעלותן נראית בלוח הבקרה — עם שיוך מדויק של 'מפתח הלקוח מול מפתח המערכת'. תקרת הטוקנים של המסווג הוקטנה מ-8192 ל-4096 (הגנת runaway עם מרווח בטוח לתשובה ארוכה), וקובץ AI מת (ai-delivery-parser) הוסר. בנוסף, בנתיב קבוצות-השליחים (הנפח הגבוה ביותר) בוטל סיווג-Haiku כפול ללמידה: הודעות ללא אוצר-מילים של דיווח-מסירה — או דיווח 'אין מענה' חד-משמעי — מטופלות כעת דטרמיניסטית ומדלגות על קריאת הסיווג, ללא כל נגיעה בלוגיקת הבוט (התרחישים והפעולות נשארו זהים). נוספו שני בלמי-עלות נוספים: תמלול קולי (Whisper, חיוב לדקה) חוסם כעת קבצים גדולים חריגים (מעל 10MB — הרבה מעבר להודעה קולית רגילה), וכריית התובנות (גם בזמן-אמת וגם ב-digest השעתי) נעצרת ל-tenant שצבר ערימה גדולה של תובנות-pending שלא נסקרו — ומתחדשת אוטומטית כשהתור מתפנה. אף אחד מהשינויים אינו משפיע על tenant חדש או על מי שמשתמש בפיצ'ר בפועל.

ה-API של משלוח בודד (צפייה, עריכה, שינוי סטטוס וסטטוס-תפעול, סטטוס החזרה והלוך-חזור, חילוץ AI ועדכון ביקור) חוזק כך שכל גישה למשלוח מוגבלת במפורש לארגון של המשתמש המחובר; בקשה למזהה שאינו שייך לארגון מחזירה כעת 'לא נמצא' (404) במקום לטעון נתונים. בנוסף, משתמש צוות שהושבת או שתפקידו שונה מאבד כעת את ההרשאות באופן כמעט-מיידי (עד דקה) במקום להמתין לפקיעת ההתחברות. כמו כן, כתובות URL של webhooks יוצאים ושל ספקי AI מאומתות כעת כך שלא ניתן להפנותן לכתובת רשת פנימית/שמורה (הגנת SSRF), ובקשות יוצאות כאלה נחסמות גם בזמן השליחה. אין שינוי בחוויית המשתמש עבור גישה לגיטימית — רק חיזוק הבידוד בין ארגונים, ההרשאות, והבקשות היוצאות.

שידור אצווה ל-ש.נ.ל עיבד עד כה את המשלוחים אחד-אחרי-השני, כך ששידור של עשרות משלוחים נמשך דקות — וקריאת API איטית או שנתקעת עד ה-timeout (15 שניות) חסמה את כל שאר המשלוחים בתור. כעת המשלוחים מעובדים במקביל ב-pool תחום (5 בו-זמנית), מה שמקצר משמעותית את זמן השידור ומונע ממשלוח בודד תקוע לעכב את כל האצווה. בנוסף, כשל בעיבוד משלוח יחיד (למשל תקלת DB אחרי שה-API הצליח) מבודד כעת לאותו משלוח בלבד במקום להפיל את כל האצווה. סדר התוצאות המוזרמות ל-UI נשמר עקבי, והתקרה נשמרת נמוכה כדי לא לחרוג ממגבלות הקצב של ש.נ.ל ו-Lionwheel.

מחיר החבילות הנוספות עבר ממודל 'מחיר נפרד' למודל 'הנחה': חבילה מהשנייה והלאה מתומחרת כמחיר הבסיס פחות הנחה. ההנחה מוגדרת כסכום ב-₪: הנחה כללית לכל חבילה נוספת, ובנוסף עוקפים ייעודיים פר-אינדקס (חבילה שנייה, שלישית, …) שנוספים בלחיצת '+'. אינדקס ללא עוקף מקבל את ההנחה הכללית; ברירת המחדל (ללא הנחה) היא מחיר בסיס מלא. במקביל תוקן פער מהותי: מנגנון הטירים הקודם כלל לא היה מחובר לחיוב המשלוח בפועל (הפונקציה getPackagePrice מעולם לא נקראה, והחיוב נשען על שדה ישן שאף מסך לא הגדיר) — כעת ההנחות מוטמעות ב-computeAutoSurcharges ומשפיעות על תוספת 'חבילה נוספת' בכל משלוח. ⚠️ שינוי התנהגות: מרגע ההטמעה, חבילות נוספות מתומחרות (מחיר בסיס פחות הנחה) במקום שלא להוסיף דבר כפי שהיה בפועל — יש לוודא שמחירוני הלקוחות מעודכנים. ההגדרה זמינה בדיאלוג המחירון (סקציית 'חבילות נוספות (הנחה)') וב-3 עמודות חדשות בקובץ יבוא האקסל.

• מודל הנחה: חבילה נוספת = מחיר בסיס − הנחה (₪). הנחה כללית + עוקפים פר-אינדקס; אינדקס ללא עוקף → הכללי; ברירת מחדל = מחיר בסיס מלא
• תיקון פער: ההנחות מחוברות עכשיו לחיוב המשלוח בפועל (computeAutoSurcharges); קודם מנגנון הטירים היה תצוגתי בלבד (הצעות מחיר/PDF)
• ⚠️ שינוי חיוב: חבילות נוספות יתחילו להיות מתומחרות מרגע ההטמעה (פחות הנחות שתגדיר); בעבר הן בפועל לא הוסיפו למחיר
• דיאלוג המחירון: סקציית 'חבילות נוספות (הנחה)' — שדה כללי + '+' להוספת הנחה לחבילה ספציפית
• יבוא אקסל: שלוש עמודות חדשות — 'הנחת חבילה נוספת', 'הנחת חבילה שניה', 'הנחת חבילה שלישית' (במקום עמודות מחיר החבילה); התבנית להורדה עודכנה בהתאם
• ההנחה מוגבלת ל-[0, מחיר בסיס] (חבילה לא יורדת מתחת ל-0); חל על מסירה ואיסוף יחד; שינויים מתועדים ב-audit של המחירון
• כיסוי טסטים: ללא הנחה, הנחה כללית, עוקף פר-אינדקס, הנחה גדולה מהבסיס, וחבילה בודדת

חוזק תרחיש 'בקשת שידור' של בוט הקבוצות נגד זיהויי-שגוי, אחרי שני מקרים בפרודקשן: (1) צילום של מדבקת משלוח שצורף לדיון תפעולי אחר (היכן נמסר) זוהה כבקשת שידור והוליד 'לא מצאתי משלוח עם המספר שצוין'; (2) ההודעה '25595110 יש 11 ספרות' (דיווח של קבלן על מספר טלפון שגוי) זוהתה כבקשת שידור, כי מספר משלוח בודד נחשב טריגר. כעת הזיהוי דטרמיניסטי: בקשת שידור = מילת שידור מפורשת (לשדר/שדר/שדרו/תשדרו/לא משודר/לא נסרק/שימו עלי/לא מופיע לי...) או מספר משלוח בודד לחלוטין (ללא טקסט נוסף). מספר שמלווה בכל הערה/שאלה/דיווח אחר → שתיקה. צילום מדבקה נחשב בקשת שידור אך ורק אם מלווה במילת שידור מפורשת — צילום ללא מילת מפתח (גם אם נשלח לבדו) אינו בקשת שידור. רשימת מילות המפתח חוזקה עם גבולות-מילה עבריים, כך שמילים לא-קשורות שמכילות שורש 'שדר' (שדרות, משודרג, שדרוג) לא מזוהות בטעות. במקביל שופרה הנחיית תרחיש 'טלפון שגוי' (כבוי כרגע) כך שיזהה דיווח על מספר ספרות שגוי כמו 'יש 11 ספרות' — מוכן ליום שיופעל. מחרוזת ה-OCR אוחדה לקבוע משותף.

נוסף מנגנון מכפיל דחיפות למחירון הלקוח: לכל לקוח ניתן להגדיר 'מכפיל דחוף' (EXPRESS) ו'מכפיל בהול' (URGENT) — מספר עשרוני כמו 1.8, 2 או 3 — שמוכפל על מחיר הבסיס האפקטיבי של משלוחים בדחיפות המתאימה. עד כה שדה הדחיפות במשלוח (REGULAR/EXPRESS/URGENT) היה קיים אך לא השפיע על המחיר כלל. המכפיל חל על מחיר הבסיס בלבד (התוספות — גוביינא, יעד חריג, חבילות — נשארות שטוחות), והוא מוטמע בכל מסלולי החישוב: סיכום החיוב הפר-משלוח, פאנל התמחור (שמציג כעת שורת 'מכפיל דחוף/בהול ×N' עם תוספת המחיר), וסיכום הרווחיות המצטבר ללקוח. ברירת המחדל היא 1 (ללא שינוי). אפשר להגדיר את המכפילים בדיאלוג המחירון של הלקוח, וגם דרך שתי עמודות חדשות בקובץ יבוא מחירוני האקסל ('מכפיל דחוף', 'מכפיל בהול').

• שני שדות חדשים בפרופיל המחירון: expressMultiplier (דחוף) ו-urgentMultiplier (בהול), Decimal עם ברירת מחדל 1.0
• המכפיל חל על מחיר הבסיס האפקטיבי לפי shipment.urgency; התוספות נשארות שטוחות
• מוטמע בכל החישובים: computeCustomerBillingSummary, פאנל התמחור (שורת 'מכפיל דחוף/בהול ×N'), וחישוב הרווחיות המצטבר
• ניתן להגדרה בדיאלוג המחירון של הלקוח (סקציית 'מכפילי דחיפות')
• שתי עמודות חדשות בקובץ יבוא מחירוני האקסל — 'מכפיל דחוף' ו'מכפיל בהול' (מספר עשרוני, לא ₪), כולל בתבנית להורדה, בתצוגה המקדימה ובוולידציה (1–20)
• תיעוד מלא ב-audit: שינוי מכפיל נרשם בהיסטוריית המחירון של הלקוח

נוסף סיכום רווחיות מצטבר ברמת הלקוח: כמה הלקוח חויב, כמה עלו האיסופים, כמה עלו המסירות, והרווח/הפסד שנגזר ביניהם — על פני טווח תאריכים נבחר. ההכנסה למשלוח מחושבת בדיוק כמו בלשונית התמחור הפר-משלוח (תעריף בסיס מהמחירון לפי סוג המשימה + תוספות, או מחיר ליונוויל השמור כשאין מחירון), והעלות מבוססת על ה-snapshot של עלות האיסוף/מסירה ששמור על המשלוח. הסיכום מופיע בשני מקומות: כרטיס 'רווחיות' בדף הלקוח (עם בורר טווח תאריכים) וטבלת 'רווחיות לפי לקוח' באנליטיקס (לשונית לקוחות), שניהם מאחורי הרשאת FINANCE_VIEW. בנוסף, דף המשלוח המלא (/shipments/[barcode]) קיבל כרטיס 'תמחור ורווחיות' שעוטף בדיוק את אותו פאנל של לשונית התמחור במגירת המשלוח — כך ששני המסכים מציגים מידע פיננסי זהה ואין יותר חוסר אחידות בין כניסה למשלוח מהרשימה לבין כניסה ישירה לפי ברקוד.

• כרטיס 'רווחיות' בדף הלקוח: סך חיוב ללקוח, עלות איסופים, עלות מסירות ורווח/הפסד — עם בורר טווח תאריכים (ברירת מחדל: החודש הנוכחי)
• טבלת 'רווחיות לפי לקוח' באנליטיקס: שורה לכל לקוח (הכנסה, עלות, רווח/הפסד) ממוינת לפי רווח, עם סיכום כללי וייצוא CSV
• חישוב הכנסה זהה ללשונית התמחור הפר-משלוח; חישוב יעיל — פרופיל המחירון נשלף פעם אחת ללקוח והרווחיות נצברת בזיכרון
• סימון כיסוי חלקי: כשעלות זמינה רק לחלק מהמשלוחים (איסוף/מסירה שטרם הושלמו) — מוצגת הבהרה שהרווח משקף את צד העלות הריאלי בלבד
• דף המשלוח המלא מציג כעת את אותו פאנל תמחור (מחיר בסיס, תוספות, סה"כ לחיוב, עלות איסוף/מסירה ורווח) כמו מגירת המשלוח — איחוד מלא של התצוגה הפיננסית
• כל הנתונים הפיננסיים (עלות ורווח) מאחורי הרשאת FINANCE_VIEW; ללא ההרשאה מוצגים רק מחיר בסיס ותוספות
• עיצוב מחדש של פאנל התמחור: שורת KPI עליונה (לחיוב · עלות · רווח + שולי רווח %), שני כרטיסי פירוט פרוסים זה לצד זה (חיוב מול עלות/רווח), בורדרים רכים ופריסה רחבה במקום קונטיינר צר מוצמד

כעת, לפני כל שיבוץ נהג (איסוף או מסירה), המערכת בודקת בזמן אמת אם הנהג מורשה לאזור של המשלוח — באותה שיטה בדיוק שבה עובד טריגר 'טעות מיון' הקיים (checkDriverZoneAllowance: בדיקת האזורים המורשים של הנהג מול אזור המשלוח, עם סובלנות למספר אזור בסיסי כמו '1- מרכז' ≈ '1- צפון'). אם מזוהה טעות מיון, מוצגת אזהרה חמורה ומעוצבת (לא נייטיב) שמפרטת בדיוק את הטעות — שם השליח, האזורים המורשים שלו, ורשימת המשלוחים מחוץ לאזור מקובצת לפי אזור — והפעולה מתבצעת רק אם המשתמש מאשר אותה במפורש ('אני בטוח — שבץ בכל זאת'). הבדיקה היא קריאה-בלבד: היא אינה יוצרת רשומת טעות מיון ואינה משדרת התראות וואטסאפ/סירנה (זה ממשיך לקרות כרגיל בסנכרון מ-Lionwheel). האזהרה חלה על כל מסלולי שיבוץ הנהג במערכת.

• בדיקה בזמן-אמת לפני שיבוץ — אותו כלל בדיוק כמו טריגר טעות המיון הקיים (לוגיקת ההרשאה חולצה לפונקציה משותפת evaluateDriverZoneAllowance)
• אזהרה חמורה מעוצבת עם פירוט מלא: שם השליח, אזוריו המורשים, ורשימת המשלוחים החריגים מקובצת לפי אזור
• הפעולה מתבצעת רק לאחר אישור מפורש; ביטול עוצר את כל השיבוץ
• חל על כל המסלולים: טבלת איסופים (שורה בודדת / סרגל קבוצתי / קבוצה מקובצת), לאסו במפת האיסופים והמשלוחים, דיאלוג שיבוץ קבוצתי, שיבוץ מהיר בכרטיס השליח, ושיבוץ פר-משימה בעמוד המשלוח
• כיסוי לאיסוף ולמסירה כאחד; הסרת שליח (ניקוי) אינה דורשת אישור
• בדיקה קריאה-בלבד — ללא יצירת רשומת טעות מיון וללא שידור התראות; fail-open אם הבדיקה נכשלת כדי לא לחסום עבודה

נוסף חלון אישור מעוצב (לא נייטיב) לפני כל שיבוץ קבוצתי של משימות איסוף לשליח, כדי למנוע שיבוץ בטעות של עשרות איסופים לקבלן/שליח שגוי בלחיצה אחת. ההודעה מפרטת כמה איסופים, מאיזו עיר/עירוֹת מקור, ולאיזה שליח עומדים לשבץ — לדוגמה: 'שים לב — הנך עומד לשבץ 28 איסופים מירושלים על השליח אל איי שליחויות. האם הנך בטוח?'. האישור חל על שלושת מסלולי השיבוץ בלחיצה אחת בעמוד האיסופים: סימון אזור במפה (לאסו), סרגל הפעולות הקבוצתי, ושיבוץ קבוצה מקובצת. הסרת שליח מקבוצה (ניקוי) אינה דורשת אישור.

שיפורי תשתית בסקריפטי ה-backfill התפעוליים (לא חשוף ללקוח). backfill-pickup-zone-codes: נוסף מנגנון retry עם backoff סביב קריאות Prisma Accelerate, כך ש-'fetch failed' חולף (P5010) לא מפיל ריצה על אלפי שורות — שורה שנכשלת באופן עקבי מדולגת ונספרת (הרצה חוזרת מנסה אותה שוב). backfill-shipment-costs: תוקנה טעינת ה-.env מ-root הריפו לפני שרשרת ה-lib (db.ts בונה את ה-Prisma client בזמן import), כך שהסקריפט רץ נכון מ-root עם pnpm --filter web exec tsx. בנוסף נוסף .mcp.json עם הגדרת שרת ה-MCP של Vercel.

בעל החשבון (או משתמש עם הרשאת 'ניהול משתמשים') יכול כעת לנהל את צוות הפורטל לבד, בלי לפנות לחברת המשלוחים בכל פעם. עמוד 'צוות וגישה' בפורטל הורחב ל-CRUD מלא: הזמנת משתמש חדש (אימייל, שם, הרשאות → נשלח קישור הזמנה במייל להגדרת סיסמה), קביעת הרשאות וגישת חשבונות לכל חבר צוות, איפוס סיסמה/שליחת הזמנה מחדש (מחזיר קישור להעתקה), ומחיקת משתמש. גבולות הבטיחות נאכפים בשרת: מנהל יכול להעניק כל הרשאה חוץ מ'ניהול משתמשים' (שנשארת בידי חברת המשלוחים בלבד), ואינו יכול לערוך/למחוק/לאפס את עצמו או משתמש אחר שהוא 'מנהל משתמשים'. נלווה לתיקון של היום שמנע שמירת הרשאות מוגבלות (ההשלמה-האוטומטית לבעלים הוסרה).

• הזמנת משתמש חדש מתוך הפורטל — אימייל הזמנה להגדרת סיסמה (או קישור להעתקה אם המייל לא נשלח)
• קביעת הרשאות וגישת חשבונות לכל חבר צוות, איפוס סיסמה/הזמנה מחדש, ומחיקה
• גבול: 'ניהול משתמשים' לעולם אינו ניתן להענקה מהפורטל — נשאר בידי הטננט
• מניעת הסלמה/נעילה: אי אפשר לפעול על עצמך או על מנהל-משתמשים אחר
• כל הגבולות נאכפים בשרת (canManagePortalUsers + בדיקות יעד), לא רק ב-UI

שיפור מדבקת המשלוח לפי משוב מהשטח. (1) נוסף בלוק 'הערת מיקום' בולט מתחת לכתובת, שמרכז את פרטי המיקום המדויקים — קומה, דירה, כניסה וקוד כניסה — יחד עם הערת היעד החופשית. עד כה פרטי המיקום המובנים לא הופיעו על המדבקה כלל, והערת היעד הייתה ממוזגת לשורת 'הערות' כללית בתחתית המדבקה ולכן נחתכה לעיתים במדבקות מלאות. (2) הוגדל הפונט בבלוק פרטי היעד — גם התווית (מפתח) וגם הערך — כי לקוחות התלוננו שטקסט הכתובת קטן מדי וקשה לקריאה לשליח. (3) תוקנה תצוגת סכום הגוביינא: הסכום מאוחסן באגורות והוצג ללא המרה — כך שגוביינא של 250 ₪ הופיעה כ-25000 ₪. כעת הסכום מומר נכון לשקלים, מוצג עם מפרידי אלפים (1,250 ש״ח) ומציין את אמצעי התשלום (במזומן / בשיק) לפי codType, במקום הטקסט הקבוע 'במזומן'. השינוי חל על שני מנועי הרינדור (PDF להדפסה ו-HTML לתצוגה מקדימה וללינק שיתוף) ועל כל מסלולי המדבקה — משלוח בודד, מרובה, לינק שיתוף ציבורי ופורטל לקוחות.

• בלוק 'הערת מיקום' חדש ובולט מתחת לכתובת — קומה · דירה · כניסה · קוד כניסה
• הערת היעד הוצאה לבלוק המיקום הייעודי במקום שורת 'הערות' הכללית — כך אינה נחתכת במדבקות מלאות
• הגדלת הפונט של התווית והערך בבלוק פרטי היעד (עיר, כתובת, שם מקבל, טלפון, גוביינא) לשיפור הקריאות
• תיקון סכום הגוביינא: הוצג פי 100 (250 ₪ נראו כ-25000) — כעת מומר נכון מאגורות לשקלים, עם מפרידי אלפים
• סכום הגוביינא מציין את אמצעי התשלום — במזומן / בשיק לפי codType — במקום 'במזומן' קבוע
• פרטי המיקום המובנים מוצגים תמיד; הערת היעד החופשית כפופה למתג 'הערות' הקיים
• חל על PDF ו-HTML ועל כל מסלולי ההדפסה — בודד, מרובה, לינק שיתוף ופורטל לקוחות
• פורטל לקוחות: לוגו נפרד לכל חשבון מקושר — לקוח-אב מקושר יכול כעת להגדיר לוגו שונה לכל סאב-לקוח בקבוצה (במקום לוגו יחיד), והלוגו מופיע על מדבקות המשלוחים של אותו חשבון. עד כה ניתן היה להגדיר רק לוגו אחד (על חשבון המשתמש), ועל משלוחים של סאב-לקוחות לא הופיע לוגו כלל
• ניווט: 'שיבוץ איסופים' הועברה מקבוצת-אב נפרדת לתת-לשונית תחת קבוצת 'משלוחים'
• שיבוץ איסופים: סדר עמודות ברירת מחדל חדש — שליח איסוף ותאריך איסוף מיד אחרי הלקוח, ואז אזור, עיר וכתובת
• שיבוץ איסופים: עמודת האזור מציגה את הקוד בלבד (13) במקום 'אזור 13'
• שיבוץ איסופים: עמודות חדשות — 'סוכן' (הסוכן המשויך ללקוח) ו'תאריך יצירה' של המשלוח
• שיבוץ איסופים: הוצרו עמודות 'שליח איסוף' ו'תאריך איסוף' שהיו רחבות מדי
• שיבוץ איסופים: מסנן התקופה עובד כעת לפי תאריך יצירת המשלוח (במקום תאריך האיסוף, שגולגל קדימה כל לילה ע"י קרון וניפח את 'השבוע' ל-37,000)
• שיבוץ איסופים: הדף מציג כעת אך ורק משלוחים שטרם נאספו — בסטטוס 'משלוח חדש' או 'שובץ לשליח איסוף' (וכן משלוחים חדשים ללא סטטוס עדיין); סונכרן בטבלה, בפילטרים ובמפה
• תצוגת סטטוס: תוקן סטטוס גולמי 'new' — ליונוויל מסמן משימה חדשה במחרוזת 'new' (במקום קוד מספרי), שנשמרה כפי שהיא והוצגה גולמית במקום 'משלוח חדש', לא הופיעה בדף שיבוץ האיסופים, ואף נספרה בטעות כמזכה-עמלה. כעת מנורמלת ל-UNASSIGNED בכתיבה (chokepoint יחיד) ובתצוגה, עם backfill לשורות הקיימות
• שיבוץ איסופים: הושמטו מהדף משלוחים המיועדים לליקוט פנימי של הטננט (שמופיעים בדף הליקוט) — מה שמיועד לליקוט אינו מיועד לאיסוף
• שיבוץ איסופים: שם שליח האיסוף המשובץ מוצג כעת בצבע מלא וברור (במקום בגוון פלייסהולדר עמום)
• שיבוץ איסופים: כפתור הניקוי (X) בתיבת תאריך האיסוף עוצב כתיבה תחומה זהה לזו שבבורר השליח
• שיבוץ איסופים: עמודת הברקוד עברה לרכיב הברקוד הקנוני של המערכת (כמו בדף המשלוחים) — כולל העתקה מהירה ופתיחת המשלוח
• שיבוץ איסופים: תאריך היצירה מוצג כעת באותו עובי/צבע כשאר תאי הטבלה (לא בגוון עמום)
• שיבוץ איסופים: קיבוץ משימות להאצת השיבוץ — קיבוץ לפי לקוח+כתובת (ברירת מחדל), לפי אזור איסוף או לפי עיר (וכן 'ללא קיבוץ'), עם כפתור החלפה בסרגל. כל קבוצה מוצגת כשורה מכווצת ('משימות מקובצות' + מונה), נפתחת בלחיצה למסגרת עוטפת, וניתן לשבץ שליח/תאריך לכל הקבוצה בפעולה אחת או לבחור חלק מהמשימות
• שיבוץ איסופים: העתקת משימות לשליחים/קבלנים — אייקון העתקה בכל משימה משובצת, בכל כותרת קבוצה (מעתיק את כל הקבוצה), וכפתור 'העתקה' בסרגל הבחירה המרובה. הטקסט כולל ברקוד, לקוח, כתובת ועיר
• שיבוץ איסופים: כפתור 'סמן לליקוט' בסרגל הבחירה המרובה (זהה לדף המשלוחים) — מסמן את הנבחרים לליקוט פנימי
• שיבוץ איסופים: אייקון '⋯' בסוף כל שורה (במקום אייקון פתיחת המשלוח) עם תפריט פעולות — סמן לליקוט, פתח בליונוויל, העתקת פרטים, שכפל משלוח, העברה לסל מחזור
• שיבוץ איסופים: לחיצה על הברקוד פותחת מגירת תצוגה מהירה של דף המשלוח (זהה לדף המשלוחים)
• תיבת שיבוץ שליח: רוחב מינימלי תואם לעמודת תאריך האיסוף, והוסר קיצור ראשי התיבות (אווטאר) מרשימת השליחים — בכל מקום בפרויקט
• שיבוץ איסופים: שורת הקבוצה עוצבה מחדש לתאים מלאים בכל עמודה (זהה לשורה רגילה) — בכל עמודה מוצג הערך האחיד או 'לא אחיד'. עמודות שליח ותאריך הן בקרות קבוצתיות שמשבצות שליח/תאריך לכל הקבוצה בפעולה אחת; הסטטוס ותאריך היצירה מציגים ערך אחיד או 'לא אחיד'
• שיבוץ איסופים: רק כפתור 'משימות מקובצות' (עם החץ בתוכו) פותח/סוגר את האקורדיון; שאר התא אינו לחיץ
• שיבוץ איסופים: כפתור הקיבוץ בסרגל עוצב כשאר כפתורי הסרגל (תאריך/פילטרים/מפה), והתפריט הנפתח קיבל אייקונים, תיאורים וסימון לאופציה הפעילה
• שיבוץ איסופים: מתג מהיר בסרגל למעבר בין 'הכל / לא משובץ / משובץ' עם מונים חיים לכל מצב, קיצורי מקלדת 1/2/3, ושמירת הבחירה. ברירת מחדל: 'לא משובץ'. הסינון חל על הטבלה ועל המפה
• שיבוץ איסופים: תיקון תצוגה מבלבלת — איסוף המשובץ על שליח לא-פעיל (שמסונן מרשימת השליחים) הוצג כתיבה ריקה כאילו אינו משובץ, מה שגרם לקבוצה להיראות 'מעורב' ללא סיבה גלויה. כעת מוצג שם השליח המשובץ גם אם אינו פעיל, וגם בזמן טעינת רשימת השליחים
• שיבוץ איסופים: מתג 'הכל / לא משובץ / משובץ' עוצב מחדש לסגנון הלשוניות (tabs) הזהה לדפים אחרים כמו 'פערי חלוקה' — מסילה רכה ולשונית פעילה מורמת — במקום סגרל מקטעים תחום בקו
• שיבוץ איסופים: תיקון — הסרת שליח מקבוצה (לחיצה על ה-X) נכשלה כי נקודת הקצה הקבוצתית לא קיבלה ערך ריק; כעת ההסרה עובדת ומסנכרנת גם לליונוויל
• שיבוץ איסופים: קביעת תאריך איסוף לקבוצה/לבחירה מרובה משמרת את שעת הביקור (מהפריט הראשון) במקום לאפס ל-09:00
• שיבוץ איסופים: מיון ברירת מחדל לפי תאריך יצירה — המשלוחים החדשים ביותר ראשונים, כדי לראות מיד 'מה נכנס עכשיו'
• שיבוץ איסופים: כשהקיבוץ חורג מ-500 משימות — נוסף כפתור 'הצג הכל ברשימה' שמעביר לתצוגה רגילה מעומדת על אותו סינון
• שיבוץ איסופים: תפריט הקיבוץ מציג כמה קבוצות ייווצרו בכל מצב (אזור/עיר/לקוח+כתובת) כדי לבחור בלי ניסוי וטעייה
• שיבוץ איסופים: בעמודות 'שליח איסוף' ו'תאריך איסוף' הוסר סינון הטקסט (שחיפש בערך השמור ולא בבורר החי); המיון נשמר
• שיבוץ איסופים: כפתור 'ביטול' (Undo) ל-10 שניות בהודעות של העברה לסל מחזור וסימון לליקוט — בשורה, בקבוצה ובבחירה מרובה — להחזרה מיידית של פעולה שגויה
• שיבוץ איסופים: ייעול ביצועים — בחירת שורה כבר לא מרנדרת מחדש את כל הטבלה (ייצוב ה-handlers וה-refresh), חשוב במיוחד בקיבוץ עם מאות שורות
• שיבוץ איסופים: נגישות — מתג 'הכל / לא משובץ / משובץ' סומן כקבוצת בחירה (radiogroup) עם תוויות ARIA
• שיבוץ איסופים: מגירת פרטי המשלוח (בלחיצה על ברקוד) נטענת בעצלתיים (lazy) רק בפתיחה הראשונה — מקטין את משקל הטעינה של דף האיסופים
• שיבוץ איסופים: איחוד פונקציות עזר לתאריך למודול משותף אחד (ניקיון קוד, ללא שינוי התנהגות)
• אזורי חלוקה: לישובים שליונוויל מפצלת לכמה אזורים לפי פוליגון (כיום ירושלים), המערכת קוראת כעת את אזור החלוקה המלא (כולל מרכז/צפון/דרום) ישירות מליונוויל — גם באיסוף וגם בחלוקה — ונופלת לאזור-הישוב היחיד ('1') רק כשליונוויל לא החזירה אזור. שאר הישובים ממשיכים להישען על המיפוי הידני לפי שם ישוב
• אזורי חלוקה: תיקון — בסנכרון (webhook/סנכרון ידני) האזור המדויק של ירושלים שנקבע ביצירה (מרכז/צפון/דרום) נדרס בכל פעם באזור-הישוב הגנרי, כי נתיב הסנכרון לא משך מ-API את ה-region_str המדויק (שלא נשמר ב-payload). כעת לישובים רב-אזוריים הסנכרון מושך את האזור המדויק מליונוויל — כך האזור נשאר מדויק ואף ממלא אזורים ריקים. שאר הישובים ללא שינוי (ללא קריאת API)
• תאריך איסוף: תיקון אזור-זמן בדחיפה לליונוויל — בעת קביעה/שינוי של תאריך איסוף מהמערכת, הפירמוט לליונוויל נעשה לפי UTC במקום שעון ישראל, מה שהזיז את השעה ב-3 שעות (ולעיתים את היום סביב חצות) וגרם לתאריך 'לקפוץ'. כעת הפירמוט תמיד בשעון ישראל. תוקן בכל שלושת נקודות הדחיפה: עדכון ביקור בודד, קביעת תאריך מרובה, ותאריך האיסוף בעת יצירת משלוח חדש (שברירת המחדל שלו 'היום' חושבה ב-UTC)
• שיבוץ איסופים: כפתור 'סנכרן מליונוויל' בסרגל הבחירה המרובה — מושך נתונים טריים (כולל תאריך האיסוף המעודכן) מליונוויל למשלוחים שנבחרו. נחוץ כי ליונוויל לא שולחת webhook כששינוי הוא רק תאריך הביקור, ולכן תאריך שעודכן בממשק של ליונוויל נשאר ישן אצלנו עד סנכרון ידני או webhook הבא

כשמנהל ערך משתמש פורטל בעמוד הלקוח והוריד לו הרשאות (למשל כרטסת או API), השינוי נשמר אך 'חזר' בטעינה הבאה — וכל המשתמשים נראו כבעלים עם גישה מלאה. הסיבה: הפונקציה שמזריעה את משתמש הפורטל הראשון מהאימייל של הלקוח רצה בכל טעינה של עמוד הלקוח, ובתוכה 'השלמת הרשאות בעלים' שהוסיפה מחדש את כל הרשאות הבעלים לכל משתמש שהיו לו יותר מהרשאת הצפייה הבסיסית בלבד. כך כל הורדת הרשאה (שלא הורידה עד לצפייה-בלבד) שוחזרה אוטומטית. ההשלמה האוטומטית הזו הוסרה — מעתה כל צירוף הרשאות שמגדירים נשמר ונשאר. הערה: משתמשים שכבר 'הועלו' לבעלים צריך לערוך מחדש פעם אחת אחרי העדכון.

נוספה הרשאת לקוח חדשה — 'ניהול משתמשי פורטל' — הדרגה הגבוהה ביותר, שאותה רק הטננט יכול להעניק (מתוך עמוד הלקוח, ככל שאר ההרשאות). משתמש פורטל שקיבל אותה (וכן בעל החשבון) יכול כעת לנהל בעצמו, מתוך עמוד 'צוות וגישה' בפורטל, את כל משתמשי הפורטל של הלקוח (וחשבונות מקושרים) — לקבוע לכל אחד את ההרשאות שלו (צפייה/יצירת משלוחים, כרטסת, מפתחות API) ואת החשבונות שהוא רואה. גבולות הבטיחות: מנהל משתמשים בפורטל אינו יכול להעניק או לשלול את הרשאת 'ניהול משתמשים' עצמה (נשארת בלעדית לטננט), לא יכול לערוך בעלים ולא את עצמו — כך שהטננט שומר על השליטה בדרגה העליונה ואין הסלמת הרשאות. האכיפה בשרת (ה-API מגודר), לא רק ב-UI. הרחבה של עמוד 'צוות וגישה' שנוסף קודם.

• הרשאת 'ניהול משתמשי פורטל' — הדרגה העליונה, ניתנת על ידי הטננט בלבד (מופיעה אוטומטית ברשימת ההרשאות בעמוד הלקוח)
• מנהל משתמשים (או בעלים) קובע מתוך הפורטל את ההרשאות ואת גישת החשבונות של כל חבר צוות
• מנהל בפורטל יכול להעניק כל הרשאה חוץ מ'ניהול משתמשים' עצמה — נשארת בידי הטננט
• מניעת הסלמת הרשאות: אי אפשר לערוך בעלים, אי אפשר לערוך את עצמך, וה-MANAGE_USERS של היעד נשמר תמיד
• אכיפה בשרת (ה-API מגודר ב-canManagePortalUsers), לא רק הסתרת UI
• ללא מיגרציה — בעלים קיימים ממשיכים לנהל את הצוות כרגיל

נוסף דף חדש 'שיבוץ איסופים' (/pickups) כפריט ניווט עליון. הדף מרכז את כל המשלוחים שיש בהם משימת איסוף שטרם בוצעה ומאפשר לנציגות לשבץ שליח, לקבוע תאריך איסוף ולעדכן סטטוס — אינליין בכל שורה, או בבחירה מרובה בפעולה אחת. הדף בנוי במתכונת דף המשלוחים: בורר טווח תאריכים (היום/אתמול/השבוע/שבוע שעבר/החודש/חודש קודם/טווח מותאם — מסונן לפי תאריך האיסוף), פילטרים מבוססי-ספירה לפי לקוח, עיר איסוף, אזור איסוף, שליח איסוף וסטטוס, חיפוש חופשי, שליטה בעמודות (הצגה/הסתרה/הצמדה/מיון/סינון בתוך העמודה), ייצוא לאקסל, סקלטון, רספונסיביות, מצב כהה/בהיר ופאגינציית שרת. כל שורה כוללת ברקוד, סטטוס, שם לקוח, כתובת האיסוף, עיר ואזור האיסוף, שליח האיסוף ותאריך האיסוף. בנוסף נוספה תצוגת מפה לצד הטבלה (split-view) עם סימון אזור (lasso) לשיבוץ שליח איסוף לקבוצת משלוחים. כדי לתמוך בעמודה ובפילטר 'אזור איסוף' נוסף שדה pickupZoneCode למשלוח, הנגזר מעיר האיסוף, מתעדכן גם בסנכרון, ועבר backfill לכל הקיים. במסגרת זו תוקנה גם מכונת-המצבים של האיסוף בכל המערכת: שיבוץ שליח לאיסוף מעדכן כעת ל'שובץ לשליח איסוף' ולא ל'נאסף', ומעבר לסטטוס שאחרי האיסוף (נאסף/נקלט במחסן/יצא להפצה/בהעברה/הושלם/נמסר) מסמן אוטומטית את משימת האיסוף כבוצעה.

• דף חדש /pickups עם פריט ניווט עליון 'שיבוץ איסופים' — כל המשלוחים עם משימת איסוף פתוחה
• עריכה אינליין של שלושה שדות בכל שורה: שליח איסוף (אותה קומפוננטת שיבוץ עם השלמה אוטומטית ו-X להסרה כמו בדף המשלוח), תאריך איסוף, וסטטוס המשלוח
• בחירה מרובה + טולבר לשיבוץ שליח / קביעת תאריך / שינוי סטטוס לכל הנבחרים בפעולה אחת
• פילטרים מבוססי-ספירה (לקוח, עיר איסוף, אזור איסוף, שליח איסוף, סטטוס), בורר טווח תאריכים לפי תאריך האיסוף, חיפוש, שליטה בעמודות, ייצוא לאקסל ותצוגת מפה עם lasso
• עמודת 'אזור איסוף' חדשה (pickupZoneCode) שנגזרת מעיר האיסוף, מתעדכנת בסנכרון ועברה backfill
• תיקון גלובלי: שיבוץ שליח איסוף → 'שובץ לשליח איסוף' (לא 'נאסף'); מעבר לסטטוס שאחרי האיסוף מסמן אוטומטית את משימת האיסוף כבוצעה
• פיצול ה'מזהה היוצא' לשתי רגליים: 'מזהה יוצא (איסוף)' (שדה חדש pickupOutboundTaskId) ו'מזהה יוצא (מסירה)' — כדי לתמוך באיסוף ומסירה אצל קבלנים שונים. שיבוץ שליח קבלן לאיסוף שומר כעת את מזהה הקבלן בעמודת האיסוף, ותוקן באג ששידר שיבוץ של ביקור בודד תמיד כמסירה

בעל חשבון בפורטל יכול כעת להגביל כל חבר צוות לתת-קבוצה של החשבונות המקושרים — למשל עובד שאחראי רק על 'פרשה' יראה אך ורק את המשלוחים של 'פרשה', ולא של שאר החשבונות בקבוצה. עד כה כל משתמש פורטל קיבל אוטומטית גישה לכל הקבוצה המקושרת (הורה + כל הילדים). נוסף עמוד 'צוות וגישה' בפורטל (גלוי לבעלים בלבד) שבו מגדירים פר-חבר-צוות לאילו חשבונות יש לו גישה (ברירת מחדל: כל החשבונות; בעלים תמיד עם גישה מלאה ואי אפשר להגביל אותם). ההגבלה נאכפת בשרת בכל נקודות הסינון של נתוני משלוחים, ייבוא, תוויות וכרטסת — מזהה ה-scope הוא פרמטר חובה בפונקציית ההרשאה, כך שהקומפיילר מוודא שאף מסלול לא נשכח (אין דליפת מידע משקט). בורר החשבונות בעמוד המשלוחים מציג למשתמש מוגבל רק את החשבונות שלו.

• עמוד 'צוות וגישה' בפורטל (לבעלים בלבד) — הגדרת גישה פר-חבר-צוות לחשבונות מקושרים נבחרים
• scope נשמר על משתמש הפורטל (scoped_customer_ids); ריק = גישה מלאה (תאימות לאחור — אף משתמש קיים לא מושפע)
• אכיפה בשרת בכל ~20 נקודות הסינון: scope הוא פרמטר חובה, ה-TypeScript מכריח לעדכן כל מסלול
• החיתוך תמיד מול הקבוצה המקושרת — מזהה זר/ישן לעולם לא מרחיב גישה (fail-closed)
• בורר 'חשבונות מקושרים' ועמודי הפורטל מציגים למשתמש מוגבל רק את החשבונות המורשים לו
• בעלים אינם ניתנים להגבלה — תמיד גישה מלאה (מניעת נעילה-עצמית)

עד כה, כשמופע ה-WhatsApp (Green API) התנתק, איש לא ידע — הודעות נעלמו בלי עקבות ונציגי השירות לא הבינו לאן. נוסף ניטור מצב מלא: המערכת מתעדת כעת כל מעבר חיבור/ניתוק של המופע (notAuthorized / sleepMode / blocked / yellowCard ↔ authorized) משני מקורות — webhook מיידי (stateInstanceChanged) ו-cron גיבוי כל 5 דקות שמתשאל את getStateInstance (תופס גם ניתוקים שה-webhook לא נמסר עליהם). נשמרים רק מעברים (טבלת provider_state_events), כך שאין הצפת רשומות. שתי נקודות תצוגה: (1) באנר ענבר גלובלי בראש האפליקציה כל עוד המופע מנותק, עם שעת הניתוק והסיבה; (2) קו-מפריד מערכתי בתוך כל צ'אט ב-business-inbox שמראה בדיוק מתי החיבור נותק ומתי חזר — ממוקם כרונולוגית בין ההודעות, כך שכל נציג שנכנס לכל צ'אט מבין את הפער.

• באנר גלובלי באפליקציה כל עוד ה-WhatsApp מנותק — עם שעת הניתוק והסיבה
• חיווי 'נותק ב-HH:MM · חזר ב-HH:MM' בתוך כל צ'אט ב-business-inbox, ממוקם כרונולוגית בין ההודעות
• זיהוי כפול: webhook מיידי (stateInstanceChanged) + cron גיבוי כל 5 דק' (getStateInstance) שתופס גם ניתוקים שלא נמסר עליהם webhook
• תיעוד מעברים בלבד (provider_state_events) — בלי הצפת רשומות מה-poll
• סקריפט חד-פעמי להפעלת stateWebhook על המופע (הזיהוי המיידי); ה-cron עובד גם בלעדיו
• מדריך הגדרה מובנה בדיאלוג אינטגרציית Green API — כתובת ה-webhook להעתקה + צ'קליסט מלא של ה-toggles וההגדרות שצריך בקונסולה כדי שכל היכולות יעבדו

דיאלוג 'חיבור לקוח לסאמיט' נתקע על ספינר בלי להציג התאמות או הצעות. הסיבה: לאחר המעבר של אינטגרציית סאמיט להגדרה פר-טננט (TenantProviderConfig), חמש הפונקציות ב-actions/customers.ts (שליפת לקוחות סאמיט, פרטי לקוח, חוב, קישור לכרטסת, וחיבור לקוח) נשארו על ה-config הגלובלי הישן מה-env — שלא מוגדר בפרודקשן כי כל טננט מגדיר את סאמיט שלו בעצמו. כתוצאה getSumitCredentials החזיר null, ה-API החזיר רשימה ריקה (עם שגיאה 'Summit API not configured' בלוג), והדיאלוג נשאר במצב טעינה לנצח. תוקן: כל חמש הפונקציות עברו ל-getTenantSummitConfig(tenantId) — אותו דפוס פר-טננט שכבר בשימוש ב-summit-accounting.ts. בנוסף, הדיאלוג כבר לא נתקע על ספינר כשהרשימה ריקה (תקלה או טננט שלא הגדיר סאמיט) אלא עובר למצב חיפוש ידני.

לקוחות הפורטל יכולים כעת להעלות את הלוגו שלהם, והוא מודפס על כל מדבקת משלוח. ההעלאה נעשית מתוך הגדרות → מדבקה בפורטל (כרטיס 'לוגו על המדבקה', PNG/JPG עד 2MB); הלוגו נשמר ברמת הלקוח/חברה ומשותף לכל משתמשי הפורטל של אותו חשבון. במדבקה הלוגו מצויר בתחתית במקום סמל ברירת המחדל, מגודר בהגדרת 'הצג לוגו'. הלוגו נפתר פר-משלוח לפי החברה שלו — כך שבהדפסה קבוצתית של מספר חשבונות מקושרים כל מדבקה מקבלת את הלוגו הנכון; הוא מופיע גם כשמדפיסים מצד הצוות או דרך קישור שיתוף. מימוש נשען על תשתית הלוגו והאחסון הקיימת (Supabase) ועל אותו דפוס שמסמכי ה-CRM כבר משתמשים בו לציור לוגו ב-PDF (הטמעת data-URI, רק PNG/JPG שנתמכים ב-react-pdf).

• העלאת לוגו פר-לקוח מתוך הגדרות → מדבקה בפורטל (כרטיס חדש), עם תצוגה מקדימה והסרה
• הלוגו נשמר על הלקוח (logo_url) ומופיע על מדבקות שמדפיס כל משתמש של אותו חשבון
• פתרון פר-משלוח: בהדפסה קבוצתית של חשבונות מקושרים כל מדבקה מקבלת את הלוגו של החברה שלה
• מופיע בכל מסלולי ההדפסה — פורטל בודד/קבוצתי, צד צוות, וקישור שיתוף
• גודל הלוגו ב-footer מתואם לגובה הסמל הקיים כדי לא לדחוף את שאר פרטי המדבקה; העלאה מוגבלת ל-PNG/JPG (נתמך ב-react-pdf)
• הרשאה: רק חבר עם 'יצירת משלוחים' יכול לשנות את הלוגו; צפייה פתוחה לכל משתמש

שלושה סוגי טריגרים שניתן היה להגדיר בטופס הטריגרים ("יצא להפצה"/out_inventory, "נקלט במחסן"/in_inventory, "נאסף"/pickup_completed) מעולם לא נשלחו בפועל — מנוע הטריגרים החזיק רשימה מקוצרת משלו שלא כללה אותם, כך שהטריגר היה מוגדר ופעיל בממשק אך יצא מהפונקציה עוד לפני שליפת ההגדרה מה-DB. נוסף לכך, גם מעבר ל"יצא להפצה" שמקורו פנימי (שיבוץ שליח מסירה בסריקה/בלאסו, או שינוי סטטוס ידני בממשק) כלל לא הגיע לצינור הטריגרים — רק webhook מליונוויל הפעיל אותו. תוקנו שני הפערים: (1) מנוע הטריגרים גוזר כעת את סוגי הטריגרים ואת טבלת מיפוי-הסטטוס ישירות מ-status-mappings.ts (מקור אמת יחיד, בלי דריפט עתידי); (2) שינויי סטטוס פנימיים (applyAssignmentStatus המשמש סריקה+שיבוץ-מרובה, וה-PATCH הידני של סטטוס) מפעילים כעת את אותו צינור טריגרים שה-webhook מפעיל. שליחה כפולה נמנעת על ידי שמירת המשמרת הקיימת (statusChanged): ה-echo של ליונוויל אחרי הדחיפה רואה שהסטטוס המקומי כבר עודכן ואינו שולח שוב.

• out_inventory / in_inventory / pickup_completed — טריגרים שהיו מוגדרים בממשק אך מתים — נשלחים סוף-סוף
• מקור אמת יחיד: המנוע נגזר מ-status-mappings.ts במקום רשימה כפולה שנטתה לדריפט
• שינוי סטטוס פנימי (שיבוץ שליח / שינוי ידני) מפעיל טריגר בדיוק כמו webhook מליונוויל
• הרחבה: שינוי סטטוס ידני בממשק מפעיל כעת גם טריגרי מחזור-חיים (למשל סימון 'נמסר' ידנית שולח את הודעת delivery_completed)
• מניעת כפילות מובנית — ה-echo של ליונוויל לא שולח שוב (statusChanged=false)

עד כה חלק גדול מהפעולות שמשנות משלוח שמרו חותמת זמן בלבד (למשל 'נלקט') בלי לתעד מי ביצע אותן, ולכן הן לא הופיעו ביומן הפעולות של המשלוח. הסיבה: היומן מוזן מטבלת ה-AuditLog, ונקודות כתיבה רבות פשוט לא קראו ל-logAudit. הושלם הפער: כל פעולה משמעותית שנוגעת במשלוח רושמת כעת רשומת audit פר-משלוח עם ייחוס מלא (משתמש / API / מערכת), כולל דיף 'לפני ← אחרי' לכל שדה שהשתנה. כוסו: כל מסלולי הליקוט (סימון נלקט / ביטול ליקוט / הוספה / הסרה / שינוי קטגוריה / הערת ליקוט), פעולות תפעול (תוספות תשלום, הערת מעקב פער, ביטול פעולת מאסה), פעולות שליח מהאפליקציה (סימון הושלם / נכשל — משויך לשם השליח), שינויים מ-API ציבורי, מפורטל הלקוח ומעמוד המעקב הציבורי (מתויגים כמקור חיצוני), וגם מעברים אוטומטיים — הוספה אוטומטית לליקוט, סימון-נלקט אוטומטי לפי סטטוס, ומעברי סטטוס שמגיעים מהספק ב-webhook (מתויגים 'סנכרון ספק' / 'אוטומטי', ונרשמים רק על מעבר אמיתי). במקביל הורחבה טבלת תוויות השדות של היומן כך ששבת יעד, תאריך אקספרס, הערת ליקוט, הערת מעקב פער וסך תוספות התשלום מוצגים בעברית עם פורמט ₪ / תאריך תקין.

• סימון 'נלקט' / 'בוטל ליקוט' מציג סוף-סוף מי לקט את המשלוח — התלונה שהובילה לשינוי
• כל מסלולי הליקוט נרשמים פר-משלוח עם דיף לפני/אחרי (סטטוס, קטגוריה, סוג, הערה, שבת יעד)
• פעולות שליח מהאפליקציה (הושלם / נכשל) משויכות לשם השליח שביצע אותן
• שינויים מ-API ציבורי, פורטל לקוח ועמוד מעקב — נרשמים ומתויגים לפי מקור (שם מפתח ה-API / פורטל / עמוד מעקב)
• מעברי סטטוס אוטומטיים מהספק (webhook) וסימון-נלקט אוטומטי — נרשמים ומתויגים 'סנכרון ספק' / 'אוטומטי', רק על מעבר אמיתי
• תוספות תשלום, אקספרס, הערות ושבת יעד — קיבלו תוויות עבריות ופורמט ₪ / תאריך ביומן
• הודעות WhatsApp לא מופיעות ביומן הפעולות — הן נשארות באקורדיון 'מסרונים' הייעודי בלבד (סינון פעולות send_whatsapp ושדות הודעה)

כרטיסי המדדים בטאב 'סקירה כללית' (אנליטיקה) עוצבו מחדש בשפה מרוסנת: הוסרו ארבעת צבעי הגרדיאנט השונים, אפקטי ה-glow, ה-blob המטושטש, ה-sparkle וה-shine sweep — והוחלפו במשטח ניטרלי אחיד שבו הצבע נושא משמעות בלבד (ירוק/אדום לכיוון השינוי). המספרים הוגדלו עם tabular-nums והיררכיה טיפוגרפית חדה, נוסף sparkline אמיתי מסדרת המשלוחים היומית לכרטיס 'סה"כ משלוחים', ופס התקדמות אמיתי לכרטיס 'אחוז הצלחה'. אפקט ה-hover עבר מהרמה + זוהר ניאון לעומק צל פיזי בלבד. במקביל נוסף סולם elevation (טוקני --elevation-1/2/3 + utility classes) ל-globals.css כבסיס לשפת העיצוב החדשה.

לקוחות בפורטל קיבלו שגיאה כשניסו להדפיס מדבקות לבחירה גדולה (מעל 250 משלוחים) — הבקשה נדחתה והם נאלצו לפצל ידנית. הוסר חסם ה-250: מחולל ה-PDF מרנדר כעת אצוות גדולות במקטעים מוגבלים (כדי לא להעמיס את הזיכרון של הפונקציה) וממזג אותם לקובץ PDF אחד עם pdf-lib, כך שניתן להדפיס עד 1000 מדבקות בקובץ אחד. במקביל שופר ה-UI בפורטל: חיווי טעינה בזמן ההכנה ופתיחת הטאב מראש כדי לא להיחסם ע"י חוסם החלונות הקופצים בהדפסות ארוכות. בנוסף תוקנו שני באגים: (1) בהדפסה מרובה משלוח עם כמה חבילות הדפיס מדבקה אחת בלבד במקום מדבקה לכל חבילה — כעת ההדפסה הקבוצתית מרחיבה משלוח רב-חבילתי ל-N מדבקות בדיוק כמו הדפסה מדף המשלוח (תוקן גם במסלול הפורטל וגם במסלול השיתוף לצוות). (2) בבורר 'חשבונות מקושרים' בעמוד המשלוחים בפורטל לא ניתן היה לבטל את הבחירה 'הכל' — צ'קבוקס 'הכל' היה תקוע מסומן; כעת לחיצה עליו מבטלת ומתמקדת בחשבון של המשתמש עצמו, וניתן להוסיף משם חשבונות נוספים. בנוסף שופרה תבנית המדבקה עצמה: (א) מספר החבילה (חבילה 1/2, 2/2 וכו') מוצג כעת בבירור על מדבקת משלוח רב-חבילתי — קודם הוא חושב פנימית אך מעולם לא צויר ב-PDF; (ב) הפונט של פרטי המשלוח (עיר, כתובת, שם מקבל, טלפון, גוביינא, הערות) הוגדל לקריאוּת טובה יותר, עם ריווחים שהודקו כדי שהכול ימשיך להיכנס במדבקת 100×100; (ג) המדבקה נחתכת כעת בגבול הפיזי (overflow hidden) במקום לגלוש לעמוד שני מיותר בהדפסה קבוצתית. הערות המשלוח והערת היעד/מיקום ממשיכות להופיע (כברירת מחדל) וכעת בפונט גדול יותר.

תוקנה תקלה שבה בוט הקבוצות (מנוע התרחישים) העביר הודעות זבל לא-קשורות בחזרה ללקוח/שליח. כששאלת צפי (eta_relay) של לקוח נשלחה לקבוצת שליח עמוסה, כל פטפוט שהגיע שם ('בוקר טוב', צילום מדבקה של משלוח אחר, רשימת כתובות) הוחזר ללקוח עם הקידומת 'לגבי משלוח X:'. שני שורשים: (1) ה-leg של תשובת ה-relay קיבל כל טקסט כ'תשובה' (heuristic טריוויאלי בלבד), בעוד שצד הטריגר מוגן במסווג LLM זהיר — נוסף כעת שער רלוונטיות LLM זול שמעביר רק הודעה שבאמת עונה על מה שנשאל, ומדלג על הודעות שכתב נציג שלנו בצד היעד; בכל ספק — שתיקה וה-relay נשאר פתוח לתשובה אמיתית. (2) ה-burst בקבוצת הלקוח לא התאפס, כך שכל הודעה חדשה הפעילה מחדש את אותו תרחיש ויצרה relay כפול ופנייה חוזרת לשליח — נוסף guard שמונע פתיחת relay כפול כשכבר קיים אחד פתוח לאותו משלוח. בנוסף בוטל relay תקוע שנותר פתוח, כמיטיגציה מיידית.

נוסף כפתור X בתיבת החיפוש בעמוד השיחות העסקיות (business-inbox) לניקוי מהיר של השדה, בדיוק כפי שקיים כבר בתיבת החיפוש של תיבת הדואר הרגילה. הכפתור מופיע רק כשיש טקסט בשדה.

הושלמו שתי לולאות משוב שהיו פתוחות. (1) 'שאלות ממתינות' → תובנה: עד כה כשמשתמש ענה כן/לא על שאלה שעוזר ה-AI שאל (פאנל 'שאלות ממתינות'), התשובה רק נשמרה ב-DB ונעלמה — ה-AI לא קיבל אותה בחזרה. כעת תשובת כן/לא הופכת אוטומטית לתובנה מאושרת על הישות הקשורה (שליח/משלוח/חברה), כך שהידע נכנס לזיכרון ה-AI ומשפיע על תשובות עתידיות; קריאת Haiku קצרה מנסחת את התשובה כעובדה הצהרתית, והמשתמש מקבל הודעת 'נשמר כתובנה'. דחייה אינה מלמדת דבר. (2) למידת תרחישים לבוט הקבוצות (Phase 2): נוסף עמוד 'החלטות הבוט' (הגדרות → AI → החלטות הבוט) שמציג את ההחלטות האחרונות של הבוט בקבוצות — ובמיוחד היכן שתק. נציג יכול ללמד 'זה היה אמור להיות תרחיש X', והתיקון מוזרק כדוגמה למסווג של אותו טננט ומשטח (קבוצת שליח/לקוח) — כך הדיוק עולה עם הזמן בלי שינוי קוד. ניתן להסיר דוגמה שגויה (ואז ההחלטה חוזרת לרשימת הטיפול). תרחיש מושבת לעולם אינו מסווג גם אם נלמד.

• תשובת כן/לא בפאנל השאלות הממתינות → תובנה מאושרת שנכנסת לזיכרון ה-AI (כולל קידום תובנה שכבר הומתנה)
• עמוד 'החלטות הבוט' — סקירת החלטות הבוט בקבוצות ולימוד 'זה היה תרחיש X' לשיפור המסווג
• דוגמאות שנלמדו מוזרקות למסווג לפי טננט ומשטח; הסרת דוגמה שגויה מחזירה את ההחלטה לטיפול
• תיקון: סוגי אירועי התרחישים מבודדים מ-digest הלמידה (לא יוצרים תובנות שווא); אינדקס + ניקוי טלמטריה לבונד גודל הטבלה
• תיוג מקור-מפתח (tenant/system) מדויק בחיוב, ומדידת עלות לכל קריאות החילוץ

שדרוג מקיף להיסטוריית הפעולות של המשלוח. (1) פעולות שמבצע עוזר ה-AI שעד כה לא תועדו כלל — שינוי כתובת/טלפון יעד (updateShipmentAddress) ושינוי סטטוס תפעולי (updateShipmentOperationalStatus) — נרשמות כעת ב-audit log, מיוחסות למשתמש שביקש מה-AI (קישור FK רק כשהוא משתמש אמיתי) ועם diff מלא של השדות שהשתנו. (2) כל פעולת AI (סטטוס, כתובת, תפעול) מסומנת כעת בתג 'AI' ענברי + נקודת ניצוץ, וכוללת קישור 'צפה בשיחה' שפותח את ה-widget של העוזר ישירות על הצ'אט שגרם לפעולה — סוף-סוף ניתן לעקוב מההיסטוריה איך ולמה ה-AI פעל. הקישור ממומש דרך עמודת session_id חדשה ב-audit_logs שנלכדת בכל פעולת AI. (3) סוגי פעולה שהוצגו עד כה כ'פעולה' גנרית עם שעון אפור — סטטוס תפעול וסטטוס החזרה — קיבלו אייקון, תווית עברית וצ'יפ-סינון ייעודיים. (4) שינויי גוביינא (COD) שהופיעו בהיסטוריה מחופשים לשינוי/עדכון/מחיקה ברמת המשלוח (כולל פח אדום מטעה על מחיקת גוביינא) קיבלו זהות 'גוביינא' נפרדת עם אייקון מטבעות. הכול תוך שמירה על תאימות: הנתונים נשמרים, ותג ה-AI/כפתור הביטול הקיימים ממשיכים לעבוד. (5) בקרת גישה לקישור 'צפה בשיחה': צפייה בשיחה של משתמש אחר מותרת רק לבעלי הרשאת AUDIT_LOGS_VIEW (בעלים/אדמין) — נציג רגיל רואה ופותח רק את השיחות שהוא עצמו יצר. נאכף בשרת ב-/api/ai/chat (לא רק הסתרת הקישור ב-UI): טעינת שיחה בודדת בודקת בעלות, והקישור עצמו מוצג רק כשהצופה רשאי לפתוח. סוגר פער קודם שבו טעינת שיחה לפי id הייתה מסוננת לפי tenant בלבד.

• שינויי כתובת/טלפון וסטטוס תפעולי של ה-AI נרשמים כעת בהיסטוריה (קודם נעלמו לגמרי), מיוחסים למשתמש שביקש
• כל פעולת AI מסומנת בתג 'AI' + קישור 'צפה בשיחה' שפותח את הצ'אט שגרם לה
• סטטוס תפעול וסטטוס החזרה קיבלו אייקון/תווית/צ'יפ-סינון ייעודיים במקום 'פעולה' גנרית
• שינויי גוביינא קיבלו זהות נפרדת — כבר לא מתחזים לשינוי/מחיקה ברמת המשלוח (פח אדום מטעה הוסר)
• עמודת session_id חדשה ב-audit_logs מקשרת כל פעולת AI לשיחה שיצרה אותה
• בקרת גישה: צפייה בשיחה של משתמש אחר רק לבעלים/אדמין (AUDIT_LOGS_VIEW), נאכף בשרת — נציג רואה רק את שלו

נוסף תרחיש בוט שביעי: 'אימות קבלה מול הנמען'. כשקבלן/שליח טוען בקבוצתו שהנמען כבר קיבל את המשלוח ('נמסר', 'הלקוח קיבל', 'כבר אצלו') אך אצלנו הוא לא מסומן כנמסר, הבוט פונה אוטומטית לנמען בצ'אט לקוחות הקצה (תבנית ה-Meta המסומנת 'בדיקת מסירה') ושואל אם קיבל; אם מאשר — המשלוח מסומן DELIVERED אוטומטית, אם מכחיש — מסומן לטיפול. הבוט מאשר לקבלן שהבדיקה יצאה. התרחיש משתמש מחדש בתשתית בדיקת המסירה הקיימת (sendDeliveryConfirmationViaTemplate + ה-webhook של Meta) ומוסיף שני שומרים: דילוג אם המשלוח כבר מסומן כנמסר, ודילוג אם כבר יש בקשת אישור פתוחה למשלוח (לא להציק לנמען פעמיים). כבוי כברירת מחדל, רמת סיכון 'פעולה'. בנוסף — שני שדרוגי אמינות ל-webhook של Meta: (1) תקתוק על כפתור תשובה מהירה ('כן'/'לא') ממופה ישירות ל-CONFIRMED/DENIED בלי קריאת LLM (חד-משמעי וזול יותר; טקסט חופשי עדיין עובר לסיווג); (2) תפוגת זמן — בקשת אישור ממתינה תיחשב רק אם נוצרה ב-14 הימים האחרונים, כדי שתקתוק מאוחר על כפתור לא ישייך תשובה לבקשה ישנה/לא קשורה. בנוסף — תיעוד מלא בהיסטוריית הפעולות של המשלוח: באישור הנמען נכתבת רשומת 'שינוי סטטוס' עם הנימוק שבוצעה בדיקת מסירה חיובית (כולל אם זה היה בלחיצת כפתור או בהודעה), ובהכחשה נכתבת רשומת 'בדיקת מסירה' שהנמען הכחיש קבלה. תיקון חשוב שהתגלה תוך כדי: בדיקת המסירה הקודמת עדכנה רק את sendStatus (שמתאר אם הודעת ההתראה נשלחה — לא אם המשלוח נמסר), כך שלמעשה היא לא סגרה את המשלוח כנמסר בפועל; כעת היא מעדכנת את הסטטוס האמיתי (additionalData.status → COMPLETED), כך שהמשלוח באמת מסומן כהושלם. גם השומר 'כבר נמסר' בתרחיש תוקן לבדוק את שדה הסטטוס הנכון.

• תרחיש 'אימות קבלה מול הנמען' — קבלן טוען שנמסר → בדיקה אוטומטית מול הנמען → סימון נמסר באישור
• שומרים: דילוג אם כבר נמסר, ודילוג אם כבר יש בקשת אישור פתוחה
• מיפוי דטרמיניסטי של תקתוק כפתור (כן/לא) בלי LLM
• TTL של 14 יום על בקשות אישור ממתינות
• תיעוד בהיסטוריית המשלוח: אישור → 'שינוי סטטוס' עם נימוק בדיקת מסירה חיובית; הכחשה → רשומת 'בדיקת מסירה'
• תיקון: בדיקת מסירה חיובית סוגרת עכשיו את הסטטוס האמיתי (additionalData.status=COMPLETED), לא רק sendStatus

הרחבה מקיפה של מנגנון התובנות כך שהעוזר הופך ל'מכונה לומדת' עם פיקוח אנושי. תובנות נשמרות ברמה המדויקת שלהן ונשלפות רק כשהן רלוונטיות, במקום להיכנס עיוורת לכל פרומפט: משלוח, לקוח, שליח, חברה (קיימים) + שתי רמות חדשות — 'משתמש' (תובנות על אופן העבודה המועדף של משתמש ספציפי, מוזרקות לפרומפט רק כשאותו משתמש מדבר) ו'מערכת' (משוב על העוזר עצמו: פעולות שלא הצליח לבצע, טעויות חוזרות, שאלות שלא ידע לענות — נשמר למפתחים בלבד ולעולם לא מוזרק לשום פרומפט). כל תובנה נשמרת כעת עם 'הקשר מקור' (sourceContext) שנלכד ברגע היצירה — באיזו קבוצה/שיחה נוצרה, מי אמר (צוות/שליח/לקוח), מתי, והטקסט המקורי המדויק. נוסף חילוץ תובנות בזמן אמת מקבוצות WhatsApp: כשמנוע התרחישים מזהה אירוע תפעולי ודאי (חריג), קריאת Haiku זולה וfire-and-forget מחלצת תובנה ארוכת-טווח אם יש כזו, עם dedup ושמירה כ'ממתינה'. בדף 'תובנות AI' נוסף כפתור 'חדד' שפותח drawer עם מיני-צ'אט: המשתמש יכול לחקור את העוזר כיצד הגיע לתובנה, לראות את הטקסט המקורי, ולדון בנכונותה — ובסוף לאשר, לדחות, או לשמור ניסוח מחודד שהעוזר מציע. תובנות מערכת מוצגות בלוח הבקרה (Control Plane → תובנות מערכת) בלבד, חוצות-טננט, מאחורי הרשאת פלטפורמה, כדי שהמפתחים ידעו מה לשפר. בנוסף, פריטים 'ממתינים' שלא טופלו 60 יום נמחקים בשקט כדי לשמור על מיקוד דף הסקירה.

• שתי רמות תובנה חדשות: 'משתמש' (מוזרקת רק לאותו משתמש) ו'מערכת' (משוב למפתחים, לעולם לא בפרומפט)
• הקשר מקור מלא לכל תובנה — קבוצה/שיחה, דובר, תאריך וטקסט מקורי
• חילוץ תובנות בזמן אמת מקבוצות WhatsApp בעת אירוע תפעולי ודאי (fire-and-forget, dedup)
• כפתור 'חדד' — מיני-צ'אט לבחינת התובנה וקבלת ניסוח מחודד, לצד אישור/דחייה
• לוח בקרה לתובנות מערכת חוצה-טננט (הרשאת פלטפורמה) + ניקוי שקט של ממתינות אחרי 60 יום
• בידוד תובנות מערכת נאכף בשרת (לא רק ב-UI) — אינן דולפות או ניתנות לעריכה דרך נתיבי הטננט

בונה תבניות ה-Meta (Messages → Templates → שליחה לאישור Meta) תמך עד היום רק בכפתורי לינק (URL) — אימות פרטי מסירה ומעקב משלוח. נוסף תמיכה בכפתורי תשובה מהירה (Quick Reply): הנמען לוחץ על כפתור והטקסט חוזר אלינו כהודעה נכנסת. בדיאלוג השליחה אפשר כעת להוסיף עד 3 כפתורי תשובה מהירה (עד 25 תווים כל אחד), כולל כפתור 'מילוי מהיר' שמגדיר אוטומטית 'כן, קיבלתי' ו'לא, עדיין לא קיבלתי' — בדיוק לתבנית בדיקת מסירה. ה-payload ל-Meta בונה רכיב BUTTONS משולב (QUICK_REPLY ואז URL), והכפתורים נשמרים בתבנית המקומית. כך לבדיקת המסירה האוטומטית מול הנמען יהיו כפתורים חד-משמעיים במקום להסתמך על סיווג טקסט חופשי. בנוסף תוקן באג: הדגל isDeliveryConfirmation (וגם buttons) נשמטו ב-round-trip של GET/PUT כי לא היו בסכמת ה-Zod של /api/messages/templates (Zod מסנן מפתחות לא מוכרים) — כעת הם נשמרים כראוי, וגם מועברים בחזרה ל-state אחרי שליחה ל-Meta כדי שלא יימחקו בשמירה הבאה.

• כפתורי Quick Reply בבונה התבניות (עד 3, עם מילוי מהיר כן/לא לבדיקת מסירה)
• רכיב BUTTONS משולב ל-Meta (QUICK_REPLY + URL)
• תיקון: isDeliveryConfirmation ו-buttons נשמרים כראוי (היו נשמטים בסכמת ה-Zod)
• סינון אוטומטי של אמוג'י/שורות חדשות בשדות הכפתורים (Meta דוחה תבנית עם אמוג'י בכפתור)

בצ'אט הלקוחות העסקיים (/messages/business-inbox), לחיצה על כפתור/מחוות 'אחורה' של הטלפון בתוך שיחה פתוחה הוציאה את המשתמש לגמרי מהדף, בניגוד לצ'אט לקוחות הקצה (/messages/inbox) ששם 'אחורה' חוזר לרשימת הצ'אטים. נוסף ל-business-inbox אותו יירוט מבוסס-היסטוריה (pushState בפתיחת שיחה + מאזין popstate): כעת 'אחורה' סוגר את השיחה הפתוחה וחוזר לרשימה, וזהה בשני הצ'אטים.

התגלה שתמונות הוכחת המסירה (POD) שצולמו בליונוויל כמעט ולא הופיעו אצלנו — רק חלק זעיר מהמשלוחים שהושלמו הציגו תמונה. שורש הבעיה: ליונוויל מצרף את התמונה ברגע המסירה או מיד אחריה, כשהמשלוח כבר במצב 'הושלם' (טרמינלי), וה-payload של ה-webhook הרגיל לרוב לא כולל את מערך התמונות — התמונה זמינה באופן אמין רק דרך /tasks/show. בנוסף, ה-cron שמסנכרן משלוחים פתוחים מדלג על משלוחים טרמינליים, כך שמשלוח שהושלם לא נמשך שוב ולכן התמונה שלו לא נשלפה. כמו כן הסנכרון הקודם היה הרסני — מחק תמונות קיימות בכל עדכון וייצר אותן מחדש רק אם ה-payload הנוכחי כלל תמונות, כך שכל webhook מאוחר בלי תמונות מחק תמונה שכבר נשמרה. התיקון: (1) הסנכרון הפך ללא-הרסני — לא מוחק תמונות קיימות כשאין תמונות ב-payload; (2) טיפול ייעודי ב-webhook של 'צירוף תמונה' (is_photo_attached) — כשמתקבל סיגנל שצורפה תמונה אך ה-payload לא נשא אותה, התמונה נמשכת מ-/tasks/show; (3) cron התאמה חדש (sync-completed-pod-images) שרץ כל 30 דקות, מאתר משלוחים שהושלמו לאחרונה וחסרי תמונה, ומושך את ה-POD מליונוויל — עם חלון זמן מוגבל וניסיונות חוזרים תחומים כדי לכבד את ה-rate limit. התיקון פועל קדימה (משלוחים חדשים); לא בוצע backfill היסטורי המוני.

• סנכרון תמונות POD לא-הרסני — webhook בלי תמונות לא מוחק יותר תמונה שכבר נשמרה
• משיכת התמונה מ-/tasks/show כשליונוויל מסמן is_photo_attached אך ה-webhook לא נשא את ה-URL
• cron התאמה חדש שתופס תמונות שמצורפות אחרי השלמת המשלוח (כל 30 דק', חלון מוגבל)

הפלייסהולדר של תיבת כתיבת ההודעה בשני הצ'אטים (/messages/inbox ו-/messages/business-inbox) מציין כעת גם איך יורדים שורה: 'כתוב הודעה... (Enter לשליחה, Shift+Enter לשורה חדשה)'. במובייל (ב-/messages/inbox) נשאר 'כתוב הודעה...' בלבד כי שם Enter ממילא יורד שורה. בנוסף — לארבעת כפתורי ה-header של חלון עוזר ה-AI (שאלות ממתינות, היסטוריית שיחות, שיחה חדשה, סגור) נוספו Tooltip תקניים בהתאם לקונבנציית shadcn/ui. כמו כן תוקנה אי-עקביות במקלדת: ב-business-inbox במובייל Enter שלח את ההודעה (במקום לרדת שורה) בניגוד ל-/messages/inbox — נוסף זיהוי מכשיר-מגע גם ל-business-inbox, כך שכעת בשני הצ'אטים זהה: במובייל Enter יורד שורה (השליחה בכפתור) ובדסקטופ Enter שולח ו-Shift+Enter יורד שורה.

נוספה תחת הלשונית הראשית AI (לצד 'ספקים', 'תרחישים', 'תובנות') לשונית 'עלויות' המציגה לכל לקוח כמה עלה לו השימוש ב-AI — בעיצוב זהה לדף עלויות המסרונים. מכיוון שכל לקוח מחבר ספק AI משלו (ואנחנו לא מספקים שירות AI), העלות נמדדת בשיטת מדידה-עצמית: בכל קריאת AI נרשם אירוע שימוש פר-לקוח (טבלת ai_usage_event) עם ספירת הטוקנים בפועל, והעלות מחושבת ונשמרת באותו רגע מול מחירון. כך השיטה אחידה לכל הספקים (Anthropic/Google/OpenAI), והכי חשוב — היא מייחסת ללקוח גם שימוש שרץ על מפתח-הגיבוי של המערכת (key_source = system), כך שאפשר להציג ולחייב עליו בנפרד (הדף מפצל 'מפתח שלך' מול 'מפתח מערכת'). המספר הוא הערכה: ספירת הטוקנים מדויקת, התמחור לפי מחירון ציבורי. הדף מציג כרטיס עלות כוללת (₪/$ עם שער חי), מדדי טוקנים, וטבלאות פירוט לפי מודל ולפי יום, וכן אזהרה על מודלים ללא מחיר מוגדר. אינסטרומנטציה: מנוע התרחישים (classify + סיכומי דיווח שליח) וסוכני הצ'אט (עובדים + פורטל לקוחות) — דרך wrapper מדידה guarded שלעולם לא שובר קריאת AI. בנוסף, נוסף דף ניהול 'מחירי מודלים' (למנהלי פלטפורמה בלבד) לתחזוקת המחירון לאורך זמן: ברירות מחדל בקוד + override ב-DB הניתן לעריכה ידנית, וכפתור 'בדוק מחירים' שמריץ חיפוש אינטרנט (Claude + web_search) מול דפי התמחור הרשמיים ומציג diff לאישור — מסמן שינויים חריגים, ולעולם לא מחיל אוטומטית בלי אישור אנושי. עלויות היסטוריות אינן משתנות בעדכון מחיר (snapshot בזמן הרישום).

• לשונית 'עלויות' פר-לקוח תחת AI — הערכת עלות לפי ספירת טוקנים ומחירון, אחידה לכל הספקים
• מדידה עצמית מייחסת גם שימוש על מפתח-הגיבוי של המערכת ללקוח (פיצול 'מפתח שלך' מול 'מפתח מערכת') — בסיס לחיוב עתידי
• דף 'מחירי מודלים' למנהלי פלטפורמה: מחירון בקוד + override, וכפתור 'בדוק מחירים' (web search → diff לאישור, ללא החלה אוטומטית)
• עלויות היסטוריות יציבות — המחיר מצולם בזמן הרישום ואינו משתנה בעדכון מחירון

עד כה תרחיש 'אין מענה' שלח ללקוח העסקי תבנית קבועה שדיברה רק על אי-מענה, וסיננה פרטים נוספים שהשליח ציין באותה הודעה. כעת הבוט מחלץ מהדיווח של השליח תקציר נאמן של כל הפרטים התפעוליים שעשויים לעזור במסירה — למשל 'אין מענה מהנמען, והשליח גם אינו מצליח לאתר את הכתובת' — ומשבץ אותו בהודעה ללקוח דרך placeholder חדש {driverReport}. כך הלקוח מקבל תמונה מלאה (אם השליח לא מצא את הכתובת הוא לא יכול היה אפילו לדפוק בדלת או להניח ליד הדלת אם זה מאושר) ויכול לתת הנחיה מועילה. זה אינו תרחיש 'כתובת שגויה' — שם הכתובת עצמה שגויה וצריך לתקנה; כאן הכתובת תקינה והשליח פשוט אינו מאתר אותה, והפרט מועבר ללקוח במסגרת האין-מענה. בנוסף — אותו חילוץ הוחל גם על תרחיש 'דיווח כשל מסירה', שעד כה העביר ללקוח את הטקסט הגולמי של השליח (סיכון לחשיפת מידע פנימי). חשוב מכך, מנגנון החילוץ מסנן כעת מידע פנימי/תפעולי שהלקוח לא אמור להיחשף אליו ללא בקרה: עיכובים אצלנו/במחסן, בעיות שידור/שיבוץ, החבילה הגיעה לשליח באיחור מצדנו, פספוס יום איסוף, נזק/אשמה, מחירים, שמות עובדים, מספרי משלוח ותיוגי צוות. הכלל: כל פרט שעוזר למסירה (מצד הנמען/הכתובת) מועבר לשולח; כל פרט פנימי — מסונן, ובספק מושמט; אם לא נשאר פרט בטוח לחשיפה — נשלח משפט גנרי. החילוץ נעשה בקריאת Haiku קצרה שמפענחת גם קיצורים (אמ=אין מענה). בנוסף, גם תשובת השליח בתרחיש 'בקשת תיאום/שינוי מועד' עוברת ניקוי לפני שהיא מועברת ללקוח — שומר על התשובה המהותית (מתי/האם/אילוצי מסירה) ומסיר מידע פנימי; אם לא נשאר תוכן בטוח, התשובה כלל לא מועברת.

כותרות ארוכות ברשימת השיחות בדף /admin/ai-sessions גלשו ודחקו את חותמת הזמן מהשורה. התיקון בשני שלבים: (1) נוסף min-w-0 לשדה הכותרת כך ש-truncate ייכנס לפועל ב-flex child; (2) הרשימה הוחזרה משימוש ב-Radix ScrollArea ל-div עם overflow-y-auto רגיל (כמו ב-/messages/inbox) — ה-Viewport של Radix עוטף את התוכן ב-wrapper עם display:table שמתרחב לרוחב הכותרת הארוכה ביותר ולכן ביטל את ה-truncate לחלוטין. הכותרת נעטפה גם ברכיב ה-Tooltip המשותף (בהתאם לקונבנציה שאוסרת title נייטיבי) שמציג את הכותרת המלאה במעבר עכבר. בנוסף — פעולות שינוי-סטטוס שמבצע עוזר ה-AI (כולל ביטול משלוח) מתעדות כעת מי ביקש אותן: ה-audit log מקשר את המשתמש המבקש (כשהוא משתמש אמיתי) ומוסיף '(לבקשת <שם>)' לתיאור, כך שבהיסטוריית הפעולות של המשלוח רואים את שם המבקש והאווטאר שלו עם חותמת הזמן — במקום 'מערכת' בלבד. תג ה-AI וכפתור הביטול נשמרים. עד כה לא היה ניתן לדעת מההיסטוריה מי הורה ל-AI לבצע את הפעולה. בנוסף — ניקיון רעש בהיסטוריית הפעולות של המשלוח: רשומות עדכון-ביקור הציגו 'עודכנו השדות: שליח (משלוח 12345)' — גם מספר המשלוח (מיותר בדף המשלוח עצמו) וגם שם השדה (שכבר מוצג בטבלת השינויים מתחת) — וכעת שורת התיאור מנוקה ונשען על תג 'עדכון ביקור' + טבלת השינויים בלבד; ושליחות WhatsApp/תבנית Meta (send_whatsapp) הוסרו מהטיימליין כיוון שכבר מוצגות בפירוט באקורדיון 'מסרונים' הייעודי — שניהם שינויי תצוגה בלבד, הנתונים נשמרים ב-DB.

מנוע התרחישים בקבוצות שייך עד כה משלוחים לפי רשומת הלקוח/השליח המדויקת בלבד, ולכן פספס שתי היררכיות נפוצות שכבר קיימות במערכת: (1) לקוח-אב עם תת-לקוחות (parentCustomerId) — למשל 'חבד ישראל' שיש לו קבוצה ו-8 תת-לקוחות (חיינו, פרוייקטים, עלון פרשה...) עם אלפי משלוחים, אך ללא קבוצה משלהם; (2) שליח-מנהל עם סאב-שליחים (DriverManagerLink) — למשל 'מישל ראשון לציון' שיש לו קבוצה ו-12 סאב-שליחים ללא קבוצה. כתוצאה מכך משלוחים של תת-הלקוחות/הסאב-שליחים לא טופלו ע"י הבוט. כעת השיוך מודע-היררכיה: בכל תרחישי הגישור (אין-מענה, צפי מסירה, כתובת שגויה, טלפון שגוי, כשל מסירה) — איתור המשלוח מקבוצת שליח-מנהל מכסה את כל הסאב-שליחים (visit.driverId בין המנהל לסאבים), שליחת הודעה ללקוח נופלת חזרה לקבוצת לקוח-האב כשלתת-לקוח אין קבוצה, איתור משלוח מקבוצת לקוח-אב מכסה את כל תת-הלקוחות, ושאלה לשליח נופלת חזרה לקבוצת המנהל כשלסאב-שליח אין קבוצה. מומש מרכזית ב-lib/ai/scenarios/shared.ts (getDriverAndSubIds, getCustomerAndChildrenIds, customerChatTarget מודע-אב, resolveDriverGroupChat מודע-מנהל) כך שכל ה-handlers נהנים מהתיקון.

• קבוצת לקוח-אב (חבד ישראל) מכסה כעת את משלוחי כל תת-הלקוחות שלה
• קבוצת שליח-מנהל (מישל) מכסה כעת את משלוחי כל הסאב-שליחים שלו
• fallback אוטומטי לקבוצת האב/המנהל כשלישות-הבן אין קבוצה — בכל 5 תרחישי הגישור

דף תרחישי הבוט (AI → תרחישים) עוצב מחדש מרשימת סקשנים ארוכה וטקסטואלית לגריד כרטיסי יכולת קומפקטי. כל תרחיש מוצג ככרטיס עם אייקון בוט, כותרת, תגיות סיכון (קריאה/גישור/פעולה) וסוג קבוצה, צ'יפ זרימה ויזואלי שממחיש את כיוון הגישור (שליח ← בוט ← לקוח), ומתג הפעלה/כיבוי כפעולה הראשית. ההפעלה/כיבוי נשמרים מיידית (אופטימי, עם חזרה לאחור בכשל) במקום כפתור שמירה גלובלי. עריכת נוסח התגובות עברה למגירה צדדית ממוקדת לפי קונבנציית ה-Drawer של המערכת (כותרת קבועה, אזור גלילה, וכפתורי שמירה/ביטול קבועים). כרטיס מופעל מקבל הדגשה סגולה עדינה, וכרטיס עם נוסח מותאם מסומן 'מותאם'. שמירת נוסח שומרת רק overrides שנבדלים מברירת המחדל, כך ששינויי נוסח עתידיים בברירת המחדל עדיין מגיעים לטננטים שלא התאימו.

• גריד כרטיסי יכולת במקום רשימת סקשנים ארוכה
• צ'יפ זרימה ויזואלי לכיוון הגישור (שליח ← בוט ← לקוח)
• מתג הפעלה/כיבוי עם שמירה מיידית (אופטימי)
• עריכת נוסח התגובות במגירה צדדית ממוקדת
• שמירת overrides בלבד — שינויי ברירת מחדל עתידיים עדיין מתפשטים לטננטים

משלוחי 'איסוף' (סחורה שנאספת מלקוח קצה וחוזרת לבית העסק) זוהו עד היום רק כשליונוויל תייג task_type='pickup', אבל פריסת השדה אצל ליונוויל אינה עקבית — חלק מהאיסופים הגיעו ללא תיוג ולכן נחשבו (וגם תומחרו) כמסירה רגילה. חוזק מנגנון הזיהוי האוטומטי שגוזר 'pickup' כשהנמען הוא העסק עצמו: עיגון לפי טלפון או כתובת החנות (מרשומת הלקוח), עם תנאי-בטיחות ששם הנמען תואם לשם העסק — כך שמסירה רגילה לעולם לא תסומן בטעות (חשוב כי task_type מזין תמחור ועמלות סוכן). הכלל מחליף את ה-fallback הישן שהתאים רק כתובת מדויקת (פספס סניף שני, כתיב רחוב שונה, או לקוח ללא כתובת ברשומה). בנוסף בוצע backfill חד-פעמי שתייג 298 משלוחי איסוף שהיו ללא תיוג. הזיהוי המחוזק רץ מעתה אוטומטית בכל סנכרון. בנוסף, משלוחי האיסוף הוצאו מטאבי פערי המסירה (מסירה / קריטיים / יום אחרון) כדי שלא יתערבבו עם מסירות רגילות, וטאב 'כפולות' הורחב ל'החזרות וכפולות' — מציג כעת גם את כל האיסופים הפתוחים (סחורה שנאספה מלקוח וטרם חזרה לעסק) לצד הכפולות. נוספה עמודת 'סוג' (כפולה / החזרה), מניין הימים לאיסוף נספר מרגע האיסוף בפועל מהלקוח, ועמודת השליח מציגה את מי שמביא חזרה לעסק (שליח ההחזרה לכפולה, שליח המסירה-חזרה-לעסק לאיסוף).

מנוע התרחישים של בוט הקבוצות (Green API) הורחב בחמישה תרחישים חדשים שניתן להפעיל ולערוך פר-טננט בהגדרות → תרחישי הבוט. (1) 'כתובת שגויה/חסרה' — שליח מדווח בקבוצתו שהכתובת שגויה או שאינו מוצא אותה, הבוט שואל את הלקוח העסקי לכתובת הנכונה, מחלץ את השדות (עיר/רחוב/מספר/קומה/דירה) בקריאת Haiku קצרה, מעדכן את המשלוח ומסנכרן לליונוויל, ומעביר את הכתובת המעודכנת לשליח. (2) 'טלפון שגוי' — שליח מדווח שמספר הנמען לא תקין, הבוט מבקש מהלקוח מספר נכון, מעדכן את המשלוח ומעביר לשליח. (3) 'בקשת תיאום/שינוי מועד' — לקוח מבקש בקבוצתו לתאם או לשנות מועד מסירה, הבוט מעביר את הבקשה לשליח המשובץ ושואל אם אפשרי, ומעביר את התשובה חזרה ללקוח (אם המשלוח לא משובץ — שותק). (4) 'דיווח כשל מסירה' — שליח מדווח על כשל סופי, הבוט מיידע את הלקוח העסקי על הכשל והסיבה (יידוע חד-כיווני ללא גישור). (5) 'בקשת שידור' — קבלן/שליח מדווח בקבוצתו שמשלוח לא משודר אליו ומבקש לשדר (מילים כמו 'לשדר', 'לא משודר', 'לא נסרק', 'שימו עלי', 'לא מופיע לי באפליקציה'), או שולח צילום של מדבקת המשלוח. הבוט מזהה את המשלוח לפי המספר — מטקסט או מתוך התמונה ב-OCR (Claude vision) — משבץ את הקבלן ומשדר אליו בצורה גנרית (ליונוויל / SNL / שותף Shipnest), ממתין מספר שניות וקורא את מזהה השידור החיצוני (target_partner_task_id המאוחד), ומחזיר את מספר השידור לקבוצה. אם הקבלן טועה והמשלוח כבר משודר — הבוט מחזיר את מספר השידור הקיים במקום לשדר שוב. אם לא צוין מספר — הבוט מבקש אותו (ופותח relay לתשובה). כל חמשת התרחישים כבויים כברירת מחדל — הם אינם משנים את התנהגות הבוט של אף טננט עד שהוא בוחר להפעיל אותם — בהתאם לעקרון 'בספק → שתיקה'. התרחישים שמעדכנים נתונים או משבצים/משדרים (כתובת/טלפון/שידור) מסומנים ברמת סיכון 'פעולה'. ה-OCR לתמונות מוגבל לקבוצות שליח מקושרות שבהן תרחיש השידור מופעל בלבד (בקרת עלות). הקלסיפייר מקבל רמזי טריגר עם הבחנות מפורשות בין התרחישים (למשל 'אין מענה' מול 'טלפון שגוי' מול 'כשל מסירה' מול 'בקשת שידור') כדי למנוע בלבול.

• תרחיש כתובת שגויה — חילוץ כתובת ב-Haiku, עדכון משלוח וסנכרון ליונוויל
• תרחיש טלפון שגוי — בקשת מספר נכון מהלקוח, עדכון והעברה לשליח
• תרחיש בקשת תיאום/שינוי מועד — גישור לקוח↔שליח
• תרחיש דיווח כשל מסירה — יידוע חד-כיווני ללקוח העסקי
• תרחיש בקשת שידור — שיבוץ ושידור אוטומטי לקבלן (ליונוויל/SNL/שותף), כולל OCR לזיהוי מספר המשלוח מצילום מדבקה והחזרת מספר השידור
• זיהוי קיצור השליחים 'אמ'/'א.מ' (=אין מענה) בתרחיש 'אין מענה', והעברת הודעות קצרות עם מספר משלוח או קיצור מוכר את מסנן ה-substantive (כדי שדיווחים תמציתיים כמו '25510238 אמ' ייתפסו)
• כל התרחישים החדשים כבויים כברירת מחדל (opt-in פר-טננט)

שלוש הלשוניות הקשורות ל-AI שהיו מקוננות תחת 'הגדרות' (ספקי AI, תרחישי הבוט, תובנות AI) קובצו ללשונית ראשית חדשה בשם 'AI' בסיידבר, הממוקמת מתחת ל'מסרונים'. תג ההתראה על תובנות AI ממתינות (pendingInsights) עבר יחד איתן ומוצג כעת על הקבוצה החדשה. נתיבי הדפים עצמם לא השתנו (/settings/ai-provider, /settings/bot-scenarios, /settings/ai-insights), כך שמועדפים שמורים וקישורים קיימים ממשיכים לעבוד. הקבוצה החדשה ממוקמת לפני 'הגדרות' במערך כדי שה-path prefixes הספציפיים שלה יזוהו לפני ה-prefix הרחב /settings. בנוסף קוצרו שמות הלשוניות בתוך הקבוצה (ספקים / תרחישים / תובנות) — הקידומת 'AI'/'הבוט' מיותרת כשהקבוצה עצמה נקראת 'AI'. כמו כן, מאחר שיש כבר הרבה לשוניות ראשיות, כל הקבוצות בסיידבר נפתחות כעת סגורות כברירת מחדל — בוטלה הפתיחה האוטומטית של 'משלוחים' ושל הקבוצה התואמת לעמוד הנוכחי — והבחירה של המשתמש אילו קבוצות לפתוח נשמרת ב-localStorage ומשוחזרת בין ניווטים וטעינות. כותרת הקבוצה הפעילה נשארת מודגשת ויזואלית גם כשהיא סגורה, כך שעדיין רואים היכן נמצאים, והתנהגות ה-accordion (פתיחת קבוצה סוגרת את האחרות) נשמרה.

דף /admin/ai-sessions לניטור שיחות ה-AI בכל הטננטים קיבל ארבע יכולות חדשות: (1) חיפוש העומק עכשיו סורק גם את תוכן ההודעות עצמן (מעבר לכותרת ושם הטננט) — מנוצל אינדקס ה-pg_trgm שכבר קיים על עמודת ה-content; (2) פילטר טווח תאריכים דרך רכיב DateRangeFilter המשותף, מסנן לפי פעילות אחרונה (updatedAt); (3) בורר מיון — פעילות אחרונה / פעילות ישנה / הכי הרבה הודעות / תאריך יצירה; (4) רינדור הודעות עשיר בצד הפירוט: תצוגת מדיה inline (תמונה/סטיקר/אודיו/וידאו/קובץ עם fallback כש-URL פג), סטטוס מסירה (נשלח/נמסר/נקרא/נכשל), ייחוס שולח בהודעות קבוצה (senderName/senderPhone עם צבע דטרמיניסטי), אבחנה ויזואלית בין assistant לבין staff, ועיצוב נקי של קריאות לכלים (tool calls) במקום JSON גולמי. בנוסף, הדף עוצב מחדש בשפת העיצוב של צ'אט לקוחות הקצה (/messages/inbox): רשימת שיחות עם שורות rounded-xl ואווטרים עגולים ממופי-צבע (ראשי תיבות הטננט) עם טבעת active, חיפוש בשדה מעוגל (rounded-full) עם כפתור ניקוי, פילטר ההקשר הומר לשורת צ'יפים בסגנון ה-inbox, וכותרת הפירוט ובועות ההודעות (בועות שקופות מעוגלות עם פינה אסימטרית, border ו-shadow) תואמות עכשיו את מראה הצ'אט.

• חיפוש עומק בתוך תוכן ההודעות (pg_trgm)
• פילטר טווח תאריכים + ארבע אפשרויות מיון
• תצוגת מדיה inline, סטטוס מסירה וייחוס שולח בהודעות קבוצה
• רינדור מסודר של קריאות לכלים במקום JSON גולמי
• עיצוב מחדש בשפת ה-inbox — אווטרים עגולים, צ'יפים, בועות שקופות ושורות rounded-xl