TRIP MAKER · טריפ מייקר 🧭

מתכנן טיולים בעברית — בונים מסלול יום-אחר-יום, מקבלים קוד שיתוף בן 6 ספרות, ושולחים לחברים.

מה יש בפנים

• עמוד בית עם חיפוש יעדים / קוד טיול, רצועה מצומצמת של יעדים פופולריים מתחת לחיפוש — יעד בודד או שילוב של כמה מדינות ("הטיול הגדול במזרח", "דרום אמריקה"), שלחיצה עליו פותחת את האשף עם היעדים כבר בפנים (public/js/popular.js, רשימה אחת לדף הבית ולאשף) — וקרוסלת טיולים מומלצים
• עמוד טיול עם מסלול יומי, קישורי גוגל מפות לכל תחנה, מפת הטיול (Leaflet על אריחים חינמיים — רחובות, כהה, לוויין; פינים ממוספרים לפי סדר ההליכה, הדרך ביניהם מ-OSRM, רצועת תחנות, מסך מלא ו"המיקום שלי") וכרטיס שיתוף בסגנון כרטיס עלייה למטוס
• תכנון — טיול שנוצר עם AI נפתח על שיחה, לא על מסלול מוכן: ה-AI שואל את שאלות ההבהרה בצ'אט, מציע לבנות בבת אחת (מסך טעינה ואז הטיול) או שלב אחרי שלב (מומלץ): קובעים יחד את האזורים, מבינים את הטיסות ויוצרים להן תחנות נסיעה, ואז 1–2 עוגנים ליום — וכל השאר מושלם אוטומטית בלחיצה. טיול בכמה מדינות לא מקבל את ההצעה "בבת אחת" בכלל: הוא מתחיל ישר שלב אחרי שלב, מדינה אחת בכל פעם, כדי לא להעמיס כמה מדינות על תור אחד של המודל (וגם build_now של המודל נזרק בקוד). ה-AI בונה ועורך את התחנות בעצמו דרך אותם ops, אותו אימות מקומות ואותו כותב של השינוי החכם, ומעבר לתחנות — מלונות, מסגרת התקציב ותאריך היציאה (lib/plan-actions.js, עם היפוך מדויק לכל פעולה). כל שינוי הוא כרטיס אחד, וה-AI מחליט בעצמו בכל תור אם הוא מבצע מיד (עם ביטול) — שינוי שהתבקש במילים, או עובדה שנמסרה: כרטיס, הזמנה, תקציב — או מציע לאישור — יוזמה שלו, מחיקה או החלפה של מה שהמטיילים בחרו. (היה כאן מתג ידני/אוטומטי; הנתונים הראו אותו נלחץ הלוך ושוב.) ליד שורת ההקלדה + לצירוף כרטיס טיסה, אישור מלון או צילום מסך: הקובץ נקרא במכשיר (שכבת הטקסט של PDF, OCR של הדפדפן או tesseract — אותו סולם כמו במסמכים, doc-text.js), ולשרת נשלח הטקסט ולא הקובץ; רק תמונה שהמכשיר לא הצליח לקרוא נשלחת כעותק מוקטן (עד 1024px, JPEG) שהמודל קורא ברמת low — עלות קבועה וזעירה. עד 3 קבצים ביום למשתמש (lib/attachments.js, מונה files), וה-AI פותח את התשובה במה שהבין מהקובץ ("ראיתי שהעליתם כרטיסי טיסה עם קונקשן בציריך") ואז ממלא: טיסה למסלול, מלון לרשימת המלונות, תאריך לטיול. כל קובץ שמצורף נשמר ברקע גם במסמכים של הטיול (TripDocs.stash), מתויג לפי הטקסט שכבר נקרא — בלי OCR שני ובלי הודעה; התג על טאב המסמכים הוא כל ההכרזה. חלוקת האזורים שה-AI מציע מצוירת על לוח שנה בתוך הצ'אט, וצובעים ימים כדי לשנות. כשהטיול נראה מגובש ה-AI מציע פעם אחת להזמין חברים לתכנון (וואטסאפ / קישור). כל תור על המודל החזק — צ'אט הוא קול אחד, ושני מודלים נשמעו כשניים. השיחה וזיכרון התכנון (trips.plan_state: שלב, עובדות שהוסכמו, חלוקת האזורים) נשמרים בשרת (trip_plan_messages), כך שהמודל לא "שוכח" החלטה מלפני עשרים הודעות. מרגע השמירה הטאב הופך להמלצות. routes/plan.js; 20 הודעות ליום למשתמש
• המלצות — למי שרשאי לערוך, בקשה מפורשת ("תוסיף / תוריד / תזיז", "הזמנו את המלון…", או קובץ שצורף ב-+) חוזרת כהצעה לאישור — תחנות, מלונות, תקציב ותאריכים, אותו כרטיס כמו בתכנון; כל שאלה אחרת היא המלצה כרגיל. אין מתג: המודל מבדיל בין שאלה לבקשה לפי המילים. צ׳אט עם ה-AI על האזור, שעונה בכרטיסי המלצה (תמונה, קטגוריה, משך, עלות) עם ➕ שמכניס אותם למסלול דרך בוחר-יום בתצוגת חודש, או "תבחרו בשבילי". POST /api/trips/code/:code/recs: המודל החזק עונה, כל מקום מאומת מול Photon/Google ומה שלא אומת נזרק, תמונות מוויקיפדיה (חינם, בלי מפתח), 30 שאלות ליום למשתמש
• המלצות ליום פנוי — יום בלי תחנות לא מציג טקסט ריק ולא רצועת מלונות, אלא שלוש המלצות של ה-AI לאותו יום (בוקר, צהריים, ערב) בשורות רחבות ונמוכות, עם ➕ שמכניס ישר ליום וכפתור "המלצות אחרות" שמחליף לשלוש אחרות. ההמלצות נשמרות ב-DB (trip_day_recs) כך שכל המשתתפים רואים אותן, ונטענות לפי הסדר הכרונולוגי ובבקשות קטנות: קודם נקבעת חלוקת הימים לאזורים — החלוקה שהמטיילים קבעו בצ'אט התכנון אם יש כזו, אחרת זו שהתחנות כבר מכתיבות, ורק כשאין אף אחת מהן בקשה נפרדת ל-AI (trip_rec_areas, נשמרת ונשאלת מחדש אחרי כל שינוי; היא פנימית בלבד ולא משנה את המסלול) — ואז בקשה אחת לכל אזור, עד שישה ימים בכל בקשה, עם הימים הקבועים שבטווח כ-context. כל יום נכתב ברגע שהוא מוכן, כך שטיול של 30 יום מתמלא מיום 1 והלאה מול המשתמש במקום להמתין לסוף; הטעינה מתחילה כבר במסך הטעינה של הדף ושל הבנייה. אחרי כל שינוי במסלול — מהצ'אטים או ידני — נשלחת בקשה נוספת, שמשחזרת רק ימים שה-context שלהם השתנה (האזור והתחנות משני צדדיו), כך שתחנה שנוספה ביום 3 לא מייצרת 30 קריאות מודל. routes/day-recs.js, public/js/trip-dayrecs.js; בדיקת המבנה בלי מודל: node tools/day-recs-plan-check.js; הכפתור מוגבל ל-40 רענונים ליום למשתמש
• שעות פתיחה — המסלול מאומת גם בזמן, לא רק במרחב. לכל תחנה יש תאריך אמיתי ושעה, ולכל מקום יש שעות פתיחה — ותחנה ששולחת אתכם לדלת סגורה מקבלת סימון על הכרטיס (🚪 סגור, עם התגית שממנה זה נקבע). המקור החינמי קודם: התגית opening_hours של OSM דרך ה-endpoint של האלמנט (בלי מפתח, בלי מכסה), וגוגל רק למה ש-OSM לא ידע. אף פעם לא מנחשים: תגית שהפרסר לא מבין במלואה מקבלת unknown ולא "סגור", כי סימון שגוי גורם למטייל לוותר על מקום פתוח. הסימון הוא הצעה בלבד — שום דבר לא זז ולא נמחק מהמסלול. lib/opening-hours.js, routes/hours.js; בדיקה בלי רשת: node tools/opening-hours-check.js; בדיקת נגישות המקורות מהשרת: node tools/opening-hours-probe.js; מדידת הבסיס על טיולים אמיתיים: node tools/opening-hours-audit.js
• התאמת שעות בבנייה — המודל כותב שעה לכל תחנה בלי שמץ של מושג מתי הדלת נפתחת. אחרי אימות המקומות, בנייה של טיול עם תאריכים בודקת את שעות הפתיחה ומזיזה תחנה לשעה שעובדת — בתוך היום שלה בלבד, רק קדימה, ולעולם לא מעבר לתחנה הבאה (מוזיאון ב-09:00 שנפתח ב-10:00 → 10:00; ארוחת בוקר במקום שפתוח 17:00–22:00 → 17:00). מקום שסגור כל היום מדווח ולא מוזז — באיזה יום להציב אותו זו שאלה על כל המסלול. מאמץ מיטבי עם תקציב זמן: בנייה לא ממתינה לגאוקודר (lib/hours-fit.js). המלצות ליום פנוי פשוט לא מציעות מקום שסגור באותו יום. הדיווח נשאר בכל מקרה — תחנה שנוספה ידנית או שעה ששונתה ביד לא עוברות כאן כלל
• הדרך בין התחנות — המסלול מאומת גם בתנועה, לא רק במרחב ובזמן. זמני הנסיעה בין תחנות עוקבות (OSRM, בלי מפתח) מצוירים מתחת לכרטיסים — ברשימה וגם בתצוגת היום של לוח השנה — ותחנה שהשעה שלה מגיעה לפני שאפשר להיות בה מקבלת סימון (⏱ לא מספיקים; לעורך הסימון הוא התיקון: לחיצה אחת מזיזה אותה לשעה הראשונה שאפשר להגיע בה). הכלל אחד, משותף לבנייה ולדף (public/js/travel-rules.js): לכל קטגוריה רצפת שהייה (ארוחה 45 דק׳, מוזיאון שעה…) — לא הערכה, מינימום — ותחנה נחשבת מחוץ להישג רק כשגם המינימום ועוד הדרך לא נכנסים בפער. קטע של מעל 120 ק״מ לא נשפט (רכבת? מטוס?), וגם קטע אל תחנת נסיעה או ממנה — היא עצמה הנסיעה. בבנייה (lib/travel-fit.js, לפני בדיקת השעות) תחנה כזו זזה קדימה, בתוך היום שלה, ולעולם לא מעבר לתחנה הבאה — אחרת מדווחת ולא זזה. תשובות OSRM נשמרות ב-api_cache, ורוּטר שלא עונה לא משנה כלום. בדיקה בלי רשת: node tools/travel-fit-check.js
• מסמכים — כרטיסי טיסה, דרכון, הזמנות וביטוח לכל טיול, מתויגים לתיקיות אוטומטית: מיד לפי שם הקובץ, ואז לפי התוכן — שכבת הטקסט של PDF (pdf.js), קבצי טקסט/HTML/EML/DOCX, ו-OCR לתמונות ולסריקות (ה-TextDetector של הדפדפן כשיש, אחרת tesseract.js ב-WASM — רק במכשיר שנראה מסוגל, על עותק מוקטן ובתקציב זמן; טלפון חלש או חיבור חסכוני נשארים עם התיוג לפי השם, או "אחר", והבחירה הידנית תמיד נשארת). הכול רץ בדפדפן: הקבצים והטקסט לא עולים לשרת — רק מנועי הזיהוי נטענים מ-jsDelivr בפעם הראשונה. נשמרים רק במכשיר (IndexedDB, לפי משתמש+טיול). הכללים ב-public/js/doc-classify.js, ובדיקתם: node tools/docs-classify-check.js
• צ'קליסט לטיול — מעל המסלול יושב ווידג'ט עם שלושת הדברים שחייבים לפני היציאה: eSIM (קישור ל-Airalo, לדף המדינה כשיש אחת), ביטוח נסיעות (PassportCard), והדבר השלישי שה-AI בוחר ליעד הזה (Visit Japan Web ליפן, ESTA לארה״ב, תעודת חיסון כשנדרשת) — נשאל פעם אחת לטיול ונשמר. פתיחת הצ'קליסט המלא (הכפתור בסרגל, או השורה הראשונה ב"עוד" בטלפון) בונה בפעם הראשונה את כל הרשימה בסעיפים לפי המסלול: אישורי כניסה, הזמנות מראש לתחנות שבאמת נגמרות, אריזה לפי העונה, ביום הטיסה. שלושה טאבים: משותף (סימון אחד לכולם, עם מי סימן), אישי (אותה תבנית, סימון לכל משתתף; פריט שמוסיפים כאן פרטי), ופרו — תגיות צבעוניות (🛒 לקנות, 🔎 למצוא אונליין, 📅 להזמין מראש, 🖨️ להדפיס, 🎒 לארוז, ❓ לברר, 🔥 דחוף), ⏳ "להמשך" שמוציא פריט למגש בתחתית, מועד שנספר אחורה מהיציאה (באיחור באדום), אחראי לכל פריט משותף, תצוגות לפי סעיף / מועד / רשימת קניות / אחראי, סינון, סימון סעיף שלם, העתקה ושיתוף בוואטסאפ. המודל לא מחזיר כתובות אינטרנט — רק מילות חיפוש, והדף פותח חיפוש ("למצוא אונליין"); הקישורים היחידים ברשימה הם השניים שלנו. הבנייה הראשונה לטיול לא נספרת במכסה; "רענון מה-AI" מוגבל ל-10 ביום. routes/checklist.js, public/js/trip-checklist.js, המילון המשותף ב-public/js/checklist-tags.js; טבלאות trip_checklists, trip_checklist_items, trip_checklist_ticks
• מכסות ה-AI (lib/quota.js) — מונה יומי אחד לכל פיצ'ר (בניות, שינויים חכמים, שאלות המלצות, הודעות תכנון), נשמר ב-DB (ai_usage) ולא בזיכרון, כי השרת החינמי מתאתחל בכל deploy ונרדם אחרי רבע שעה. מנהלים לא מוגבלים. כשהמכסה נגמרת הצ'אט לא מציג שגיאה אלא כרטיס: אפשר להמשיך ידנית ומחר יש מכסה חדשה — ומי שמשתף את האפליקציה בוואטסאפ ושלושה חברים נרשמים דרך הקישור שלו (/?ref=CODE, GET /api/me/referral) מקבל מכסה כפולה לכל המונים, לתמיד
• אשף תכנון בשלושה צעדים — יוצר טיוטה ריקה ונוחת בטאב התכנון (/trip/CODE#plan)
• חשבונות משתמשים (JWT + bcrypt) ועמוד "הטיולים שלי" — ובלי חשבון מתכננים כרגיל: מי שיוצר טיול בלי להירשם מקבל חשבון אורח (lib/guest.js: שורת users בלי אימייל, JWT עם guest: true), והאשף, צ'אט התכנון, הבנייה והעריכה עובדים לו כמו לכל אחד. החומה עומדת איפה שהטיול הופך לאמיתי לאנשים אחרים — שמירת הטיול (חשיפת קוד השיתוף) והצטרפות לטיול של מישהו אחר — ושם ההרשמה שומרת הכול: הרשמה הופכת את שורת האורח עצמה לחשבון (אותו id), והתחברות לחשבון קיים מעבירה אליו את הטיולים, ההצטרפויות וההצבעות ומוחקת את האורח (גם דרך Google, עם ?guest= על הקישור). "הטיולים שלי" אומר לאורח שהטיולים שמורים בדפדפן הזה בלבד. טביעת אורחים מוגבלת ל-10 לרבע שעה לכתובת, כמו הרשמה — כל אורח הוא מכסות AI טריות
• WebMCP — כלים בשם לסוכני AI, במקום ניחושים על ה-DOM (ראו למטה)

סטאק

• Node.js + Express על Vercel (פונקציה אחת, api/index.js), PostgreSQL (Neon, דרך Vercel)
• Frontend: HTML/CSS/JS ללא פריימוורק, RTL מלא, עיצוב זכוכית
• APIs חינמיים ללא מפתח: Open-Meteo (חיזוי מזג אוויר + Geocoding לאוטוקומפליט יעדים בעברית), OSM Overpass (מלונות באזור, עם קאש בצד השרת), Google Maps Embed

WebMCP — ממשק לסוכני AI

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

הכלים נרשמים לכל מארח שהדפדפן חושף, לפי הסדר: document.modelContext (הטיוטה של W3C), navigator.modelContext (Edge 147 / ה-origin trial של Chrome 149), ובכל מקרה גם window.tripmakerTools — גשר משלנו. הגשר הוא זה שעובד היום בפועל: תמיכה נייטיבית עדיין דקה, ורוב הסוכנים שמגיעים לאתר עושים זאת דרך דפדפן headless שבו הערוץ היחיד הוא הרצת JS.

window.tripmakerTools.host              // 'document' | 'navigator' | null
window.tripmakerTools.list()            // כל הכלים: שם, תיאור, inputSchema, annotations
await window.tripmakerTools.call(name, input)

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

בכל דף (webmcp-tools.js): tripmaker_whoami · tripmaker_search_trips · tripmaker_list_suggested_trips · tripmaker_get_trip · tripmaker_list_my_trips · tripmaker_search_destinations · tripmaker_create_trip · tripmaker_open

רק כשטיול פתוח (נרשמים מ-trip.js): tripmaker_current_trip · tripmaker_add_stop · tripmaker_update_stop · tripmaker_delete_stop

כלי התחנות עוברים דרך addItem/saveItem/deleteItem של הדף עצמו, לא ישר ל-API — כך עריכה של סוכן מתרנדרת בשתי התצוגות בדיוק כמו עריכה של אדם, במקום להשאיר על המסך מסלול שכבר לא קיים.

הערות אבטחה: כלי קריאה מסומנים readOnlyHint, וכל כלי שמחזיר תוכן שנוצר על ידי משתמשים אחרים מסומן גם untrustedContentHint. הרשאות לא נעקפות — הכלים רוכבים על אותו JWT ואותן בדיקות הרשאה של ה-API, וסוכן לא מתחבר בשם המשתמש. /admin לא טוען את הכלים בכוונה.

הרצת מיגרציות

node db/migrate.js — עמודת destinations (ריבוי יעדים + קואורדינטות), אידמפוטנטי.

הרצה מקומית

npm install
# צרו קובץ .env עם:
# DATABASE_URL=postgresql://...
node db/setup.js   # פעם אחת: סכימה + טיולים מומלצים
npm start          # http://localhost:3000
npm test           # כל הבדיקות שלא צריכות רשת, מפתח או DB: תחביר של כל קובץ + ארבעת סקריפטי ה-check

משתני סביבה

משתנה	תיאור
DATABASE_URL	כתובת חיבור ל-PostgreSQL. הסכימה, המיגרציות והטיולים המומלצים נוצרים לבד בעלייה (lib/db-bootstrap.js) — מסד נתונים חדש לא צריך שום צעד ידני
IMPORT_FROM_DATABASE_URL	חד-פעמי: כתובת מסד הנתונים הישן (חי). בעלייה הבאה השרת מעתיק ממנו את כל הטבלאות (משתמשים, טיולים, תחנות…) עם אותם מזהים — רק לתוך מסד שאין בו עדיין משתמשים, אחרת מדלג. מסירים אחרי הריצה
DB_BACKUP_KEY	סוד לפענוח גיבוי ה-escrow החודשי. כשהוא מוגדר, מסד ריק (או שיש בו רק טיולי הדגמה) משוחזר אוטומטית בעלייה מהגיבוי המוצפן ב-GitHub (lib/db-restore.js). בלעדיו אין שחזור — רק seed
RESTORE_FROM_ESCROW	1 = לכפות שחזור מה-escrow גם על טיולי הדגמה שכבר קיימים (התאוששות חד-פעמית). מוחק ומשחזר; מסירים אחרי הריצה. בלי זה השחזור רץ רק על מסד ריק/דגמה
RESTORE_SOURCE_URL	אופציונלי — כתובת קובץ ה-escrow. ברירת מחדל: ה-raw של ofir6868/tripi בענף db-rotation-backups
JWT_SECRET	סוד לחתימת טוקנים
PORT	פורט (ברירת מחדל 3000). רלוונטי רק כשמריצים את server.js ישירות — על Vercel אין פורט להאזין עליו
CRON_SECRET	הטוקן שהמתזמן של Vercel חותם איתו את /api/cron/tick — התזכורות, גיבוי ה-escrow וטאטוא המטמון, שעל מארח תמיד-דלוק רצים כטיימרים בתוך התהליך. בלעדיו הנתיב מסרב לכולם, וזו התשובה הנכונה לנתיב שאחרת היה נותן לזר לשרוף לנו את מכסת ה-push
OSRM_URL	אופציונלי — שרת הניתוב לזמני הנסיעה בין תחנות בבנייה (lib/travel-fit.js). ברירת מחדל: השרת הציבורי https://router.project-osrm.org, בלי מפתח. הדפדפן פונה אליו ישירות ולא דרך המשתנה הזה
CANONICAL_ORIGIN	אופציונלי — המקור היחיד שמותר להיכנס לאינדקס. ברירת מחדל https://tripmaker.co.il (מתוך SITE ב-lib/seo.js). כל בקשת GET לדף שמגיעה למארח או לסכימה אחרים מקבלת 301 לכאן
GOOGLE_PLACES_API_KEY	מפתח Google Places (New) — אוטוקומפליט של יעדים, וגם תמונות המקומות בכרטיסי ההמלצות. בלעדיו התמונות נופלות חזרה לוויקיפדיה
AI_MODEL_PLAN	אופציונלי — המודל של צ'אט התכנון. ברירת מחדל: , כי התורות שלו מכניסות מקומות אמיתיים ישר למסלול

התחברות עם Google

ב-Google Cloud → OAuth client (Web application):

• Authorized JavaScript origins: https://tripmaker.co.il (ו־http://localhost:3000 לפיתוח)
• Authorized redirect URIs: https://tripmaker.co.il/api/auth/google/callback (ו־http://localhost:3000/api/auth/google/callback)

אחרי הגדרת המשתנים, הריצו node db/migrate.js פעם אחת (עמודת google_sub + סיסמה אופציונלית).

בדיקת הספק הפעיל: node tools/hotel-content-probe.js (או node tools/hotel-content-probe.js liteapi).