InvestIQ — Technical Review

תגובת צוות על מסמך Migration Plan v0.2

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

תאריך: 3 בספטמבר 2026גרסת מסמך: v0.2 (Candidate for Approval)סטטוס: מאושר — מצורף לתיק שינוי

מסמך מאושר ומצורף לתיק שינוי. כל 5 ההמלצות מהסקירה הקודמת שולבו ב-v0.2 (סעיף 21א מפורש): Quality Baseline ב-M0, יעד ≥80% ירידה ב-InvokeLLM ב-M4, Decision Gate M4→M5, מיפוי M6 ל-Quality Rehabilitation Map, ו-Automatic Rollback Policy ב-M8. השלב הבא — הכנת מסמכי M1–M3 ו-Pilot Acceptance Test Plan.

1. הערכה כללית

המסמך מצוין. זוהי אחת מתוכניות המעבר הזהירות והמקצועיות ביותר שנכתבו למערכת. ההקפדה על Strangler Pattern, Shadow First, One Capability at a Time, ו-Gates מספריים משקפת בשלות תכנונית גבוהה. החלוקה ל-10 שלבים (M0–M9) עם תנאי PASS/FAIL מפורשים לכל שלב היא בדיוק הגישה הנכונה למערכת פיננסית.

סיכום ההמלצה: המסמך ראוי לאישור ללא תנאים. גרסה v0.2 שילבה את כל 5 ההמלצות מהסקירה הקודמת (3 הערות מהותיות + 2 המלצות תכנוניות) ותיעדה אותן בסעיף 21א מפורש. תנאי ה-PASS/FAIL כעת ברי-מדידה מלאים.

2. נקודות חוזק מרכזיות

✓
Strangler Pattern כעקרון מוביל — הרכיב החדש נבנה לצד הקיים ומחליף אותו רק לאחר Shadow והוכחה. זהו הפתרון הנכון למערכת פיננסית שלא יכולה להרשות לעצמה קטיעה.
✓
הפרדת Execution Authority מהפיילוט — M0–M8 אינם נוגעים ב-Execution/Risk authority. זהו עקרון קריטי: המנוע המקומי יכול להיכשל בלי שאף עסקה תבוצע שלא כראוי.
✓
Trigger Engine עם policy versioning — כל threshold configurable ומנוהל גרסאות, לא hardcoded. זה פותר את הבעיה שזוהתה ב-Target Architecture v0.2 (סעיף 8) ומבטיח שינוי ספים לא דורש deployment.
✓
Rollback Ready לכל cutover — Base44 workflow הקודם אינו נמחק, רק מושבת הפיך. זה מבטיח שכשל במנוע המקומי לא גורם להשבתת המערכת.
✓
Shadow Plan עם מדדים מספריים — Coverage, Timeliness, Quality, Outcome, Reliability, Cost, Explainability. זהו מערך מדידה מקצועי שמאפשר החלטה מבוססת נתונים.
✓
M6 — Scanner/CIO Quality Restoration — זהו השלב החשוב ביותר מבחינת ערך עסקי. הוא מטפל ישירות ב-4 נקודות הפגיעה שזוהו ב-Quality Rehabilitation Map (Pre-Filter עיוורון, CIO dedup, Agent intervals, Protection evaluation).

3. הערות מהותיות להוספה/הבהרה

3.1M0 Baseline — הוסף "Quality Baseline" לצד Credit Baseline

שולב ב-v0.2

המסמך v0.1 הגדיר baseline ל-LLM calls, credits, scan coverage וכו'. אך אינו הגדיר baseline איכותי — כלומר, מהי רמת האיכות של המערכת הנוכחית (לאחר אופטימיזציה) שיש להשוות אליה. ללא baseline איכותי, PASS M6 ("איכות ≥ baseline המקורי") אינו בר-מדידה. המלצה: להוסיף ל-M0 מדידת baseline של: זמן גילוי נכסים חדשים, שיעור false positives, כיסוי intraday, ותדירות ניתוח protection — על בסיס 10 ימי מסחר זמינים.

✓ תוצאה ב-v0.2: סעיף 21א: "M0: Quality Baseline מדיד נוסף לצד Credit/Operational Baseline." — Quality Baseline הפך לחלק רשמי מ-M0.

3.2M4 Direct AI Adapter — הוסף יעד חיסכון קרדיטים מספרי

שולב ב-v0.2

המסמך v0.1 הגדיר cost ceiling ו-cost metering (סעיף 9), ובסעיף 19 כתב "Cost: ירידה מהותית" — אך אינו הגדיר יעד חיסכון מספרי. נתוני ה-DB מראים שהמערכת כיום צורכת ~15 קרדיט/יום (~450/חודש) — הרבה מתחת למכסת Builder. השאלה הקריטית: האם M4 יחליף קריאות InvokeLLM של Base44 בקריאות ישירות ל-Gemini/OpenAI? המלצה: להוסיף יעד: ≥80% ירידה ב-InvokeLLM (מ-28/יום ל-≤6/יום) כתנאי PASS M4. בלעדיו, הפיילוט עשוי "להצליח" מבחינה תפעולית אך לא לחסוך קרדיטים — שזו התכלית העסקית.

✓ תוצאה ב-v0.2: סעיף 9 הורחב: "Scaling/Cost Target: יעד של ≥80% ירידה ב-Base44 InvokeLLM, מה-baseline של כ-28 קריאות/יום ל-≤6 קריאות/יום, תוך שמירת Quality Gate." + "מיצוב M4: הכנה לסקיילינג רב-משתמשים, לא 'הצלת המערכת' במצבה הנוכחי." PASS M4 כעת דורש גם Quality Gate וגם יעד ≥80%. חריגה מיעד העלות אינה מאפשרת לעקוף את Quality Gate.

3.3M8 Cutover — הגדר "Rollback Trigger" אוטומטי

שולב ב-v0.2

המסמך v0.1 אמר "Rollback switch מוגדר מראש" ו-"24–72 שעות observation" — אך אינו הגדיר מתי מופעל rollback אוטומטי. במערכת פיננסית, המתנה של 24–72 שעות ל-rollback ידני עלולה להיות מסוכנת אם המנוע המקומי מייצר נתונים שגויים שמזינים החלטות. המלצה: להוסיף rollback triggers אוטומטיים: (א) heartbeat STALE > 30 דק' → חזרה אוטומטית ל-Base44 workflow; (ב) mismatch rate > 5% → התראה + השהיית cutover; (ג) cost ceiling נחרג → כיבוי AI adapter.

✓ תוצאה ב-v0.2: סעיף 21א: "M8: Automatic Rollback Policy עם STALE/mismatch/cost triggers configurable ובדיקת כשירות fallback." — rollback אוטומטי הפך לחלק רשמי מ-M8, עם שלושת הטריגרים שהוצעו.

4. המלצות תכנוניות

4.1 — מפה את M6 ל-Quality Rehabilitation Map

שולב ב-v0.2

M6 (Scanner/CIO Quality Restoration) מטפל בדיוק ב-4 נקודות הפגיעה שזוהו ב-Quality Rehabilitation Map. מומלץ לקשר את תנאי PASS M6 ישירות למדדים שם: זמן גילוי intraday, כיסוי שוק שקט, תדירות ניתוח protection. זה יבטיח שהפיילוט לא רק "עובד" אלא משקם את האיכות שאבדה באופטימיזציה.

✓ תוצאה ב-v0.2: סעיף 21א: "M6 ממופה ישירות למדדי Quality Rehabilitation Map." — הקישור בוצע כהמלצה.

4.2 — הוסף "Decision Gate" בין M4 ל-M5

שולב ב-v0.2

המעבר מ-M4 (AI Adapter) ל-M5 (News Intelligence) הוא קפיצה משמעותית: M4 מוכיח ש-AI ישיר עובד, M5 מפעיל אותו על נפח אירועים גבוה. מומלץ להוסיף Decision Gate מפורש ביניהם: האם איכות ה-AI הישיר ≥ baseline? האם עלות לקריאה נמוכה מ-InvokeLLM? האם fallback/HOLD עובד בפועל? רק אם כל התשובות חיוביות — לעבור ל-M5.

✓ תוצאה ב-v0.2: נוסף "DECISION GATE M4→M5" מפורש בסעיף 9 עם 4 תנאים מדויקים: (1) איכות Direct AI ≥ baseline; (2) עלות בפועל נמדדה ומתאימה ליעד הסקיילינג; (3) fallback/HOLD הוכח בפועל; (4) Structured Output יציב.

5. ניתוח סיכונים נוספים

סיכון	חומרה	הגבלה במסמך	הערה
Windows Service נכשל ב-reboot	בינוני	PASS M1 דורש עלייה אחרי reboot	מכוסה
AI ישיר מייצר החלטות שגויות	גבוה	Fallback/HOLD — לעולם לא Decision מומצא	מכוסה
Cost ceiling נחרג ב-AI ישיר	בינוני	Cost ceiling יומי/חודשי + warning + כיבוי אוטומטי (v0.2)	מכוסה
Cutover ללא rollback אוטומטי	גבוה	Automatic Rollback Policy עם STALE/mismatch/cost triggers (v0.2)	מכוסה
Reconciliation mismatch לא מזוהה	גבוה	M7: mismatch detection + unresolved state	מכוסה
Secrets נשארים ב-local logs	גבוה	סעיף 16: local logs אינם כוללים credentials	מכוסה

6. תשובות לשאלות העולות מהמסמך

Baseline קרדיטים נוכחי: ~15/יום, ~450/חודש (לאחר De-LLM-ification). נתון מאומת מ-DB. המסמך מציין "10 ימי מסחר זמינים אם כבר קיימים" — נתונים אלה זמינים.

אילו נקודות איכות לשקם (M6): 4 נקודות שזוהו ב-Quality Rehabilitation Map — Pre-Filter עיוורון בשוק שקט, CIO_SCAN daily dedup, Agent intervals 90/240 דק', evaluateProtectionStatus פעם/יום. M6 מטפל בכולן.

יעד חיסכון קרדיטים: ≥80% ירידה ב-InvokeLLM (מ-28/יום ל-≤6/יום). חייב להיות תנאי PASS M4 מפורש.

עלות חלופית של AI ישיר: ב-Gemini 1.5 Flash, ~28 קריאות/יום × ~3,000 טוקנים = ~$0.15/יום = ~$4.5/חודש. זול משמעותית מכל מכסת Base44.

Windows Service vs Tray: Windows Service — אמין יותר, רץ גם כשהמשתמש לא מחובר. המסמך בחר נכון.

תדירות Heartbeat: 15 דק' = STALE, 60 דק' = offline. סביר לפיילוט. מומלץ להפוך ל-configurable policy (כמו שהמסמך עצמו דורש ל-trigger thresholds).

7. מסקנה והמלצה

המלצה: לאשר את תוכנית המעבר v0.2 ללא תנאים.

גרסה v0.2 שילבה את כל 5 ההמלצות מהסקירה הקודמת ותיעדה אותן בסעיף 21א מפורש. שלוש ההערות (Quality Baseline ב-M0, יעד חיסכון ≥80% ב-M4, rollback triggers אוטומטיים ב-M8) ושתי ההמלצות התכנוניות (מיפוי M6 ל-Quality Rehabilitation Map, Decision Gate M4→M5) כולן שולבו. תנאי ה-PASS/FAIL כעת ברי-מדידה מלאים, בהתאם לעיקרון Evidence Based שהמסמך עצמו מבקש לאכוף.

התוכנית ממוקמת נכון: אינה דחופה להישרדות (450 קרדיט/חודש כיום), אך אסטרטגית לסקיילינג ל-25+ משתמשים. M6 הוא השלב בעל הערך העסקי הגבוה ביותר — שיקום האיכות שאבדה באופטימיזציה. סעיף 23 החדש ("Gate להמשך") מבטיח שלאחר אישור v0.2 לא מתחילים מיד בשינוי Base44, אלא בהכנת מסמכי M1–M3 ו-Pilot Acceptance Test Plan.

סקירה זו מבוססת על ניתוח מעמיק של קוד המערכת הקיים, נתוני צריכת קרדיטים מאומתים מה-DB, ה-Quality Rehabilitation Map, ו-Target Architecture v0.2 המאושר. מיועד לדיון צוותי פנימי.

InvestIQ Technical Review — Migration Plan v0.2 | ספטמבר 2026