מי לקח את המקרן? בונים עם Lovable מערכת להזמנת ציוד, מבקשה ועד החזרה

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

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

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

2שלב 1: מגדירים את מסלול ההשאלה לפני הבנייה

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

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

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

3שלב 2: מאפיינים ציוד, הזמנות ונתוני דמה

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

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

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

4שלב 3: מתכננים תפקידים והרשאות

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

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

5שלב 4: מנסחים פרומפט בנייה מוגדר

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

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

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

6שלב 5: בונים מסך זמינות עם כלל חפיפה מפורש

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

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

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

7שלב 6: מוסיפים הגשת בקשה ואישור

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

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

8שלב 7: משלימים מסירה, ביטול והחזרה

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

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

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

9שלב 8: מריצים תרחישי בדיקה עם נתוני דמה

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

• חפיפה: אשרו מקרן לשעות 09:00–11:00 ונסו להזמין אותו ל-10:00–12:00. צפויה חסימה; אותו טווח לפריט אחר לא אמור להיחסם.
• גבול טווח: נסו להזמין את אותו מקרן מ-11:00. לפי מדיניות ההדגמה, אין חפיפה.
• בקשות ממתינות: צרו בקשות חופפות, אשרו אחת ונסו לאשר את האחרת. צפויה הודעת התנגשות.
• ביטול: בטלו הזמנה מאושרת שטרם נמסרה. התקופה אמורה להשתחרר, והבקשה להישאר בהיסטוריה.
• איחור: פריט שנמסר ומועד החזרתו עבר צריך להיחסם להזמנות חדשות ולהופיע לטיפול האחראי.
• החזרה עם תקלה: תעדו החזרה וסמנו שהפריט אינו כשיר. ההשאלה תסתיים, אך הפריט לא יהיה זמין.
• תפקידים: ודאו שעובד דמה אינו רואה פרטי בקשות של עובדים אחרים או פעולות אישור בממשק.
• שמירה ושליחה חוזרת: רעננו את המסך ובדקו התנהגות בהתאם לשיטת השמירה; לחיצה חוזרת על שליחה לא אמורה ליצור בקשה כפולה.

10שלב 9: מתקנים טעויות נפוצות ומכינים הדגמה

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

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

11כאן עוצרים: מה עוד נדרש לפני שימוש ארגוני

המדריך נעצר לפני אבטחה, חיבורים מורכבים והיערכות לעומס. לפני עבודה עם משתמשים ונתונים אמיתיים נדרשות בחינה מקצועית של הזדהות ואכיפת הרשאות, שמירת נתונים, מניעת התנגשויות בו־זמניות ופרטיות. אפשר להיעזר ב[מדריכים נוספים](/guides/) להמשך למידה, או לפנות ל-Operator AI ל[ייעוץ AI](/services/ai-consulting/) לבחינת התהליך. לתרגול מונחה של האפיון, הפרומפטים והבדיקות, ניתן לתאם [סדנת AI לצוות](/services/ai-training-workshops/).