כל הגרסאות המפורטות

02 / 03

Qz

איוש מחושב: תחזית, תכנון וסימולציה למוקד פניות.

Creative Labs · UI/UXMVPדמו פרטיאפיון מוצרבנייה בעזרת AI

סקירה כללית ב-Qz במצב כהה: ארבעה מדדים, תמהיל התורים וגרף מגמות, בסביבת הדגמה עם נתונים בדויים.

אפליקציית Windows מקומית שלומדת מההיסטוריה כמה פניות יגיעו בכל שעה, מציעה איוש לשבוע ומאפשרת לשחק ב"מה אם" לפני שמחליטים — ובמשמרת אומרת מי לקרוא ומי לשחרר. כל הצעה נבדקת בסימולציה, והנתונים נשארים במחשב.

הערה כל השמות והמספרים במסכים ובשתי התצוגות האינטראקטיביות בדויים: המסכים הם סביבת ההדגמה של האפליקציה עם שמות תורים בדויים, והתוצאות באינטראקטיבי חושבו במנוע של Qz על ביקוש בדוי. לא מופיע כאן נתון אמיתי של מוקד, ארגון או מערכת. ההצגה כתובה לצוותי הפיתוח, מערכות המידע וההנהלה: קודם המוצר ומה נדרש להפעיל אותו.

החלק שלי בפרויקט
אפיון, עיצוב הממשק והמיתוג, וניהול הבנייה בעזרת Claude Code.
תחום
Creative Labs · UI/UX
מצב המוצר
MVP · דמו פרטי

01

איפה זה עומד

Qz היא מוצר שלם שעובד מקצה לקצה: ייבוא, למידה, תחזית, הצעת איוש, סימולציה ומשמרת חיה. נתוני אמת חוברו אליה מקומית וצינור הייבוא נבדק מולם. מה שעוד לא הוכח הוא הדיוק של התחזית וההצעות מול מה שקורה בפועל — וזה בדיוק מה שהניסוי המבוקר נועד למדוד.

  1. רעיון
  2. אפיון
  3. עובד מקצה לקצה
  4. נתוני אמת מחוברים (מקומית)
  5. ניסוי מבוקר
  6. בשימוש שוטף

היום: מוצר שלם; הייבוא נבדק על נתוני אמת במחשב אחד. הצעד הבא: ניסוי מבוקר של ארבעה שבועות לצד התהליך הקיים — ואדם מחליט תמיד.

עובד ונבדק היום

  • ייבוא מודרך של פניות, דוחות לפי שעה, פריון שבועי ומשמרות

    זיהוי עמודות מהכותרות, תצוגה מקדימה, כתיבה אטומית, ביטול ייבוא, ודוח על שורות שנדחו ולמה.

  • תחזית ביקוש שעה אחר שעה, עם בחירה אוטומטית של שיטה לכל תור

    מגמות, חגים וימים חריגים, טווחים, ויומן שמשווה כל תחזית שנשמרה למה שקרה.

  • הצעת איוש שבודקת כל חלופה בסימולציה של הפניות הצפויות

    כמה חלופות לבחירה, ו"לא נמצא" כשלא נמצא — בלי להבטיח מינימום.

  • סימולציה של יום שלם: גרירת רופאים לתורים וראיית התוצאה בכל שעה

    ביקוש ידני, מהתחזית או מיום אמיתי מההיסטוריה.

  • משמרת חיה: תמונת מצב שמוקלדת, צפי קדימה, ומי לקרוא כתגבור ומי לשחרר

  • ייצוא כמויות להרשמה לאפליקציית המשמרות, בפורמט שנלמד מקובץ דוגמה

  • מקומי לגמרי, ללא אינטרנט וללא שירות AI

    הנתונים והחישוב נשארים במחשב. סביבת ההדגמה נפרדת ומסומנת בכל מסך.

  • מאות בדיקות מנוע, בדיקות ממשק, ובדיקות קצה־לקצה שמפעילות את האפליקציה האמיתית מול המנוע האמיתי

נדרש כדי שיהיה fully functional

  • אימות הדיוק מול המציאות: תחזית, הצעות איוש וכללי "חלקי" על נתוני אמתפיתוח

    היום הם נבדקו על נתונים מומצאים. צינור הייבוא אומת על נתוני אמת — התוצאות לא.

  • ניסוי מבוקר של ארבעה שבועות, לצד התהליך הקייםהנהלה

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

  • חתימת קוד, בדיקת התקנה על מחשב נקי, והצפנת קובצי הפרויקטמערכות מידע

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

  • החלטה על משתמשים והרשאותמערכות מידע

    היום: מחשב אחד ומשתמש אחד. אם יהיו כמה אנשים — הרשאות, גיבוי ושיתוף הם עניין אחר לגמרי.

  • משמרת חיה אמיתית: ייבוא תמונת מצב במקום הקלדהפיתוח

    השכבה שמתחת מוכנה; אשף הייבוא עצמו עדיין לא נבנה.

  • עמדה כתובה על תחזוקה בעזרת עוזר AIמערכות מידע

    היום נתוני אמת נשארים מחוץ לשיחה ומחוץ לגיט, ורק מספרים מצטברים נקראים. מי שיתחזק את המוצר יצטרך הסדר כתוב.

מה שהבדיקות לא מכסות: בדיקה בעין אנושית בקנה מידה של 125% ו-150%, עכבר מול מגע וקורא מסך; ביצועים בנפח של מאות אלפי פניות בחודש; והתקנה על מחשב נקי.

02

מכאב אל מוצר

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

  1. הכאב

    כמה אנשים, באיזה שילוב, באילו שעות — ומה עושים באמצע המשמרת

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

  2. האפיון

    קודם כותבים מה נחשב נכון

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

  3. המנוע

    חישוב בלי ממשק, ממשק בלי חישוב

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

  4. הלמידה

    שיטות שמתחרות כל שבוע, ולא שיטה אחת שנקבעה מראש

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

  5. האיוש

    הצעה שנבדקה, לא נוסחה

    הצעת האיוש היא חיפוש מוגבל בתקציב; כל חלופה עוברת סימולציה מלאה. ממנה נולד דף הסימולציה — "גררו רופאים לתורים וראו מה קורה" — ואחריו המשמרת החיה.

  6. העיצוב

    עיצוב רק אחרי שהמנוע מחזיק

    הממשק עוצב מחדש אחרי שהמנוע עבד: מצב כהה כברירת מחדל, טוקנים בקובץ אחד, ולוגו וספלאש של סטיב. כל החלטת עיצוב נכתבה עם הסיבה, ונבדקה בסקריפט ניגודיות.

  7. היום

    ניסוי מבוקר לצד התהליך הקיים

    התהליך הקיים נשאר הראשי ו-Qz רצה לצידו: היא מציעה, אדם מחליט, ומודדים כמה היא צדקה. קריטריוני המוכנות כתובים לכל שלב — ראו בהמשך.

03

איך המערכת עובדת

ארבעה חלקים שחולקים אותו מנוע: מלמדים אותו מההיסטוריה, מתכננים את השבוע, בודקים "מה אם", ובמשמרת שואלים מה לעשות עכשיו. התוצאה היוצאת היא קובץ כמויות לאפליקציית המשמרות — לא פעולה שהמערכת עושה בעצמה.

  1. כניסה

    דוחות מהמערכות הקיימות

    פניות (עם זמני בקשה, טיפול ונטישה), דוחות לפי שעה, פריון שבועי וקובץ משמרות.

  2. שלב

    בדיקה וייבוא

    מיפוי עמודות מודרך, בדיקות איכות, ושורות שנדחו עם סיבה. ייבוא חוזר לא מכפיל.

  3. שלב

    למידה

    לכל תור: שיטת תחזית שנבחרת בשחזור שבועי, מגמות, זמן טיפול נלמד כהצעה לאישור, ומהירות לכל איש צוות.

  4. שלב

    תכנון השבוע

    לוח עם גרירה, והצעות איוש שנבדקות בסימולציה. אפשר להחיל חלופה על הלוח, וגם לבטל.

  5. שלב

    סימולציה

    יום שלם: מי עובד באילו תורים, כמה פניות מגיעות בכל שעה, ומה קורה לתור. שני מקורות ביקוש: תחזית או יום אמיתי.

  6. שלב

    משמרת חיה

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

  7. תוצאה

    קובץ כמויות ודוח להנהלה

    כמה מקומות לפתוח להרשמה בכל שעה ולכל סוג רופא, ללא שמות, בפורמט שנלמד מקובץ דוגמה. ודוח HTML שאפשר להדפיס.

04

איך נבחרת שיטת התחזית

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

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

נתונים בדויים · שחזור אמיתי של Qz · תוצאות שחושבו מראש

מירוץ השיטות

שלושה תורים בדויים, כל אחד עם היסטוריה של 15 שבועות. Qz מחזירה כל שיטה אל שבועות העבר, מריצה אותה כאילו אינה יודעת מה קרה אחר כך, ומודדת אותה מול המציאות. בחרו תור, הדליקו שיטות על הגרף, וראו למה הוחלט מה שהוחלט.

טוען את התוצאות המחושבות…

05

סימולציה — נסו בעצמכם

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

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

נתונים בדויים · המנוע האמיתי של Qz · תוצאות שחושבו מראש

מעבדת סימולציה

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

טוען את התוצאות המחושבות…

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

06

הסקירה, התחזית והלמידה

צילומי מסך של האפליקציה בסביבת ההדגמה. שמות התורים בדויים. לחצו על מסך כדי לגלול בתוכו.

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

07

תכנון, סימולציה ומשמרת חיה

הלוח השבועי והצעת האיוש, דף הסימולציה במלואו, המשמרת החיה, מאגר העובדים והחיבור לאפליקציית המשמרות.

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

08

מה נחשב "מוכן"

העלייה לאוויר היא החלטה לפי שלב, לא הכול או כלום. לכל שלב נקבע מה רץ לצד התהליך הקיים, ומתי הוא נחשב מוכן. כל מספר נקרא יחד עם רצפת הרעש האקראי.

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

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

09

פיצוחים ופתרונות

החלטות שנבעו מטעויות אפשריות — חלקן נתפסו בבדיקה, חלקן נחשבו מראש. כל אחת מתועדת בהחלטות המוצר.

  • הבעיה

    שעה בלי פניות יכולה להיות שעה שקטה — או שעה שחסרים בה נתונים.

    הפתרון

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

  • הבעיה

    בדיקת תחזית על העבר יכולה להציץ לעתיד בלי כוונה.

    הפתרון

    ההיסטוריה נחתכת בפועל לפני שהשיטה נקראת, ובדיקה עם "שיטה מרגלת" מוכיחה שהיא אף פעם לא ראתה שעה מהעתיד.

  • הבעיה

    רעש אקראי יכול להכתיר "שיטה מנצחת" חדשה כל שבוע.

    הפתרון

    מחליפים שיטה רק בהפרש ברור, בניצחון ברוב השבועות, ובבחירת הפשוטה מבין הכשירות. הרישום שומר את המספרים, לא רק את הבחירה.

  • הבעיה

    שיטה מדויקת לא פחות יכולה להיות נמוכה בעקביות — ואיוש שנשען עליה חסר כל שבוע.

    הפתרון

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

  • הבעיה

    נוסחה אחת לכל התורים מתעלמת מכך שרופא אחד יכול לשרת כמה תורים.

    הפתרון

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

  • הבעיה

    מי לוקח את הפנייה הבאה כשרופא פנוי יכול לענות לכמה תורים?

    הפתרון

    התורים עונים לסירוגין, והראשון הוא התור שהפונה הראשון בו מחכה הכי הרבה. ומבין הרופאים הפנויים נבחר הפחות גמיש — כך נשמרים רופאי הילדים לתור שרק הם יכולים לענות לו.

  • הבעיה

    שתי הפעלות של אותה סימולציה יכולות להניב תוצאות שונות.

    הפתרון

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

  • הבעיה

    אותו אדם כתוב אחרת בקבצים שונים — סדר שמות, גרש.

    הפתרון

    שם זהה מתחבר לבד; שם דומה מוצע עם הסיבה וממתין לאישור, ומה שאושר נזכר. מה שאין לו דומה נשאר "חדש" ולא מנחשים.

  • הבעיה

    אפליקציית המשמרות תוחלף יום אחד, והקובץ שלה ישתנה.

    הפתרון

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

  • הבעיה

    נתוני תפעול אמיתיים הם רגישים.

    הפתרון

    הכול נשאר במחשב המקומי. סביבת ההדגמה נפרדת ומסומנת בכל מסך. וכלי הפיתוח לא פותח קבצי אמת: הוא קורא רק מספרים מצטברים שהאפליקציה עצמה מחשבת.

10

מיתוג, ספלאש ותנועה

הלוגו של סטיב: Q סגולה ו-z כמעט שחורה. במסך הפתיחה כפתור הפעלה מסתובב והופך לזנב של ה-Q, ה-z נכנס, וכותרת המשנה "איוש מחושב" נוחתת. הממשק כהה כברירת מחדל, עם מעבר לבהיר, ובעל אישיות שקטה: סגול רך כהדגשה, ומשטחים ניטרליים שכל אחד נושא קורט מהסגול.

פתיחה, כ-4 שניות, והטעינה מופיעה רק אם האפליקציה עדיין לא מוכנה
  • סגול הלוגו#592973ה-Q, והדגשה במצב בהיר
  • שחור כמעט#191913ה-z, וטקסט במצב בהיר
  • לבן קר#F7F6FAרקע במצב בהיר
  • רקע כהה#121016ברירת המחדל
  • הדגשה בכהה#BE93E0אותו גוון, בהיר יותר
  • תור 1 · 2 · 3 · 4#9AA4FFועוד #5fb4ff, #f090bd, #4fd2c9 — זהות תור, לעולם לא סטטוס

כתב

  • Heebo ארוז בתוך האפליקציה (רישיון פתוח), ללא טעינה מהרשת

כללי העיצוב

  • סטטוס לעולם לא רק בצבע: תמיד מילה או סמל לצידו.
  • מספרים ותאריכים מבודדים מכיוון הטקסט, וציר זמן תמיד משמאל לימין ומסומן במפורש.
  • גוף 15 פיקסלים, כפתורים 40 ומעלה, ניווט 44, פוקוס גלוי, ותנועה מופחתת מכובדת.
  • לכל גרף יש חלופה בטבלה, והנקודות נגישות במקלדת; הקווים ישרים כדי לא להמציא מגמה.
  • ניגודיות נבדקת בסקריפט לכל זוג צבעים בשני המראות (AA).

11

כלים ושילוב בתהליך

מנוע בפייתון, ממשק באלקטרון וריאקט, ובדיקות בשלוש שכבות. כל כלי נכנס בשלב שבו הוא חוסך הכי הרבה.

  1. 01

    אפיון

    האפיון בקלוד נעשה על בסיס מסמך אפיון: בעברית, עם פנקס החלטות וסטטוס כן.

    • Claude Codeשיחת אפיון על בסיס מסמך האפיון ותיעוד החלטות; נתוני אמת אינם נפתחים בו
    • Figmaשלדי מסך (wireframe)
  2. 02

    המנוע

    תחזית, סימולציה, חיפוש איוש ושמירה — בלי ממשק.

    • Pythonהמנוע
    • SQLiteשמירת פרויקט, גרסאות הגדרות והיסטוריה
    • openpyxl · convertdateקבצי אקסל, ולוחות שנה עבריים ואחרים לחגים
    • PyInstallerאריזת המנוע כקובץ עצמאי
  3. 03

    האפליקציה

    מעטפת מוקשחת, ערוץ אחד אל המנוע, וממשק.

    • Electronחלון, בידוד, מדיניות תוכן וערוץ יחיד עם רשימת בקשות מותרות
    • React · TypeScript · Viteהממשק
  4. 04

    עיצוב

    טוקנים, סקיצה, לוגו ואנימציית פתיחה, וצילומי מסך בשבעה רוחבים.

    • Illustratorיצירת הלוגו
    • After Effectsאנימציית הפתיחה
    • CSS tokensמקור אמת אחד לצבע, מרווח, כתב וצורה
    • Contrast scriptבדיקת AA לכל זוג צבעים בשני המראות
    • Heeboכתב ארוז
  5. 05

    בדיקה

    שלוש שכבות, ושער אחד שחייב לעבור.

    • pytestהמנוע, כולל מקרי יסוד מהאפיון
    • Vitestלוגיקת הממשק ומפת הניווט
    • Playwrightהאפליקציה האמיתית מול המנוע האמיתי, בשני המראות, ללא גלישה ושגיאות
    • PowerShellסקריפטי התקנה, אימות ובנייה

12

מה נדרש כדי שיפעל באמת

מי שצריך להחליט או לספק, ומה.

מערכות מידע

להחליט איפה הנתונים חיים ומי מתחזק.

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

פיתוח

לסגור את מה שהניסוי יחשוף.

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

הנהלה

להפעיל את הניסוי ולהכריע אחריו.

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