ביקורת ארכיטקטורה — InvestIQ

InvestIQ — ביקורת ארכיטקטורה מול המערכת הקיימת

מסמך מקור: InvestIQ Architecture Book, כרך 1 — יסודות הארכיטקטורה, פרק 1 (Version 1.0) תאריך ביקורת: 2026-08-05 היקף: השוואה בין עקרונות הפרק למצב המערכת הממומש בפועל

1. עקרונות שכבר ממומשו במערכת

| עיקרון במסמך | מקור במסמך | מצב במערכת | |---|---|---| | Capital-Aware System (§1.15) | הפעלה מותנית בהון פנוי | ממומש — הפעלה לפי יתרות מאגרי המזומן (auto / semi / manual) | | Audit & State Traceability (§1.15) | רישום רשומות נפרדות | ממומש חלקית — ישות Message כעקבות צבעועיות מרכזית | | Separation of Responsibility (§1.15) | סוכן אחד = תחום אחד | ממומש — סוכנים נפרדים: scanner / news / financials / technical / portfolio | | שלושת מצבי העבודה (§1.11) | ידני / חצי-אוטומטי / אוטומטי מלא | ממומש במבנה הנתונים — שדה management_mode בישויות Trade ו-Portfolio | | Documentation First (§1.15) | תיעוד לפני שינוי קוד | מתקיים בתהליך הנוכחי (מסמך זה) | | Variable Scan Intervals | אופטימיזציית קרדיטים | ממומש — 15–30 דקות ל-scanner/news, 60 דקות ל-technical, 720 דקות ל-financials |

2. פערים מרכזיים מול המפרט

2.1 היעדר סמכות החלטה יחידה (CIO)

  • מקור במסמך: §1.12 — "ה-CIO הוא הסמכות היחידה לגיבוש החלטת המערכת: BUY, SELL או WAIT."
  • מצב במערכת: הסוכנים פועלים בנפרד ומייצרים המלצות עצמאיות ללא שלב מיזוג פורמלי שמכריע BUY/SELL/WAIT.
  • השלכה: אין נקודת החלטה אחת שאחראית לתוצאה ולהסבר שלה.

2.2 היעדר שני שערי סיכון נפרדים

  • מקור במסמך: §1.12 — Pre-Risk Check (מוקדם) ו-Final Risk Gate (סופי, דטרמיניסטי, בעל זכות וטו).
  • מצב במערכת: יש בדיקות סיכון, אך לא מופרדות כשני שערים דטרמיניסטיים עם אחריות וסמכויות מובחנות.
  • השלכה: Final Risk Gate אמור להיות בלתי עקיף — כיום אין רכיב כזה.

2.3 היעדר TTL להחלטות CIO

  • מקור במסמך: §1.13.1, ADR-016 — כל החלטת CIO כוללת expires_at ו-TTL לפי סוג עסקה.
  • מצב במערכת: ישות Trade אינה כוללת שדה תפוגה / גרסת נתונים / תנאי ניתוח-מחדש.
  • השלכה: עסקה שאושרה לפני זמן רב עלולה להישלח לברוקר על בסיס נתונים מיושנים ללא בדיקת תפוגה.

2.4 היעדר Trade Validity לפני ביצוע

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

2.5 היעדר Data Freshness ו-Degraded Mode

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

2.6 היעדר Canonical Market Data Layer

  • מקור במסמך: §1.15, §1.16.1, ADR-017 — שכבת נרמול אחידה לסימולים, מטבעות, אזורי זמן, חותמות זמן, גיל נתון, איכות ומקור; Snapshot עקבי לכל הסוכנים.
  • מצב במערכת: אין שכבת נרמול אחידה — סוכנים ורכיבי בקרה ניזונים ממקורות נפרדים.
  • השלכה: החלטות עלולות להתבסס על ציטוטים סותרים בין סוכנים.

2.7 היעדר מנגנוני חירום

  • מקור במסמך: §1.12.1, §1.17.3, UC-9 — Global Freeze (עצירת עסקאות חדשות), Emergency Liquidation, הפרדה בין עצירה לחיסול, החלטת משתמש לאחר Freeze.
  • מצב במערכת: אין מנגנון Global Freeze או Emergency Liquidation כלל.
  • השלכה: אין למשתמש כפתור עצירת חירום נפרד מחיסול פוזיציות.

2.8 היעדר הפרדת רשומות ביקורת

  • מקור במסמך: §1.15 — רשומות נפרדות: המלצת סוכן → החלטת CIO → אישור משתמש → הוראה לברוקר → סטטוס פקודה → ביצוע בפועל.
  • מצב במערכת: רוב המידע נשמר בשדות של ישות Trade האחת; ישות Message משמשת כעקבות אך לא כשרשרת רשומות נפרדות לכל שלב.
  • השלכה: קשה לשחזר שרשרת החלטה מלאה עבור עסקה אחת.

2.9 היעדר איחוד Scanner Engine (ADR-009)

  • מקור במסמך: ADR-009 — Scanner Engine אחיד עם Scanner Profiles לכל השווקים.
  • מצב במערכת: שני סוכנים נפרדים (US ו-IL) ולא profile אחיד.
  • השלכה: כפילות לוגיקה וקושי להוסיף שווקים חדשים.

2.10 פער מתועד: semi_hard לא מוזכר במסמך

  • מקור במסמך: §1.11 — מגדיר בדיוק שלושה מצבי עבודה (ידני / חצי-אוטומטי / אוטומטי מלא).
  • מצב במערכת: בישויות Trade ו-Portfolio קיים ערך רביעי semi_hard שאינו מופיע במסמך כלל.
  • השלכה: פער בין המפרט המאושר למימוש — דורש החלטה: להסיר מהמערכת או לתעד ב-ADR חדש ולעדכן את המסמך.

3. סעיפים בפרק שלא היו ברורים בחילוץ הראשון (קראנו מחדש מ-PDF)

3.1 §1.10 ערכי הליבה (7 ערכים)

אמון · שקיפות · עקביות · אחריות · משמעת · צניעות · שיפור מתמיד.

3.2 §1.14 מנגנון עקיפה מדורג (3 רמות)

  1. אזהרה רכה — ניתנת לעקיפה מתועדת.
  2. שינוי טעון אישור — מחייב CIO + Final Risk Gate + Trade Validity מחדש.
  3. חסימה מוחלטת — אינה ניתנת לעקיפה בשום מצב.

3.3 §1.22 טבלת ADR (17 רשומות)

ADR-001 עד ADR-017, כולל ADR-016 (Decision TTL) ו-ADR-017 (Market Data Truth) שלא נראו בחילוץ הטקסטואלי הראשון.

3.4 §1.23 מקרי שימוש (10 תרחישים)

UC-1 Onboarding · UC-2 מצב ידני · UC-3 חצי-אוטומטי · UC-4 אוטומטי מלא · UC-5 ניהול פוזיציה · UC-6 חסימת Risk Gate · UC-7 Override ידני · UC-8 Post-Trade Audit · UC-9 Global Freeze · UC-10 Data Degradation.

4. סיכום וסדר עדיפויות מוצע

הפערים הקריטיים ביותר לטיפול (לדעת המבקר):

| דירוג | פער | סיבה | |---|---|---| | 1 | CIO סמכות יחידה (§2.1) | לב הארכיטקטורה — בלעדיו אין החלטה מוסברת אחת | | 2 | Trade Validity לפני ביצוע (§2.4) | בטיחות הון ישירה — מונע ביצוע על נתונים מיושנים | | 3 | TTL להחלטות (§2.3) | משלים את Trade Validity — תפוגה פורמלית | | 4 | Final Risk Gate בלתי עקיף (§2.2) | וטו אחרון לפני ביצוע | | 5 | מנגנוני חירום (§2.7) | בטיחות משתמש בתקלות | | 6 | Canonical Market Data Layer (§2.6) | עקביות נתונים בין סוכנים | | 7 | הפרדת רשומות ביקורת (§2.8) | יכולת תחקור לאחר מעשה | | 8 | Data Freshness / Degraded Mode (§2.5) | טיפול בכשלים חלקיים | | 9 | איחוד Scanner Engine (§2.9) | תחזוקה והרחבה | | 10 | יישור semi_hard (§2.10) | עקביות מפרט-מימוש |

5. הערות כלליות

  • המסמך (Version 1.0) מוגדר כ"מוכן לנעילה מלאה", ולכן כל פער בינו לבין המימוש הוא בגדר חריגה שדורשת החלטה: לתעד ב-ADR חדש, או לתקן במערכת.
  • הניתוח מבוסס על סקירת קוד וסכמות הישויות הקיימות בלבד; אינו תחליף לבדיקה ידנית של כל נתיב ביצוע.
  • סעיפים מלאים במסמך (1.10, 1.14, 1.22, 1.23) נקראו מקובץ ה-PDF ואינם עוד "ריקים".

מסמך זה נועד לשיתוף פנימי בלבד ואינו מהווה המלצת השקעה או ייעוץ משפטי.