כרך 3 — מעבר ממנוע Shadow למערכת תפעולית
מסמך יסוד מאושר: היקף מחייב, שערי מעבר והחלטות נדרשות
v1.0 Locked & Approved · 12.8.2026
מסמך
InvestIQ_V3
גרסה
1.0 — גרסה רשמית ומאושרת
תאריך
12.8.2026
סטטוס
Locked & Approved — בסיס מחייב לכרך 3
נקודת מוצא
כרך 2 סגור ומעודכן
מצב נוכחי
Shadow Active · Paper בלבד
גבול המסמך: כרך 3 מתחיל לאחר סגירת כרך 2. אין לפתוח מחדש את 8 פרקי כרך 2, את 50 משימותיו או את החלטות הסמכות. מסמך זה ננעל כבסיס המחייב למטרת הכרך, למבנה שמונת הפרקים ולשערי המעבר; החלטות יישום שסומנו OPEN יינעלו בפרק האחראי להן.
תקציר מנהלים
כרך 2 בנה והפעיל ב-Shadow את מנוע ההחלטה המרובה-סוכנים: Candidate, חבילת ניתוח, Evidence Fusion, כיול, CIO ומנגנוני קבלה. כרך 3 אינו מיועד לבנות שוב את המנוע, אלא להוכיח אותו לאורך זמן, להעבירו בהדרגה מ-Shadow ל-Enforced, להכין חיבור מבוקר לברוקר אמיתי, ולהפעיל Live Canary קטן, מדיד והפיך.
עקרון-העל נשאר ללא שינוי: שמירת ההון קודמת לרווח; המשתמש שולט במדיניות; CIO מפיק Decision אך אינו בעל וטו; Risk Gate הדטרמיניסטי הוא בעל סמכות הווטו הסיכונית; וכשל ברכיב חדש אינו מפיל את המערכת הקיימת.
1. נקודת המוצא — כרכים 1 ו-2
| בסיס | מצב נעול | משמעות לכרך 3 |
|---|---|---|
| כרך 1 | 244/244 PASS; חוזי Decision, Risk ו-Execution נעולים | אין שינוי ללא ADR וגרסה חדשה |
| כרך 2 | 8/8 פרקים; 50/50 משימות ובדיקות; Shadow Active | מקור הבסיס למעבר, לא נושא לכתיבה מחדש |
| בדיקות | 294 בדיקות בכל שגרה: V1 244 + V2 50 | V3 מוסיף בדיקות נפרדות ואינו חוסם V1/V2 |
| ביצוע | Paper בלבד; ברוקר אמיתי חסום | אין Live לפני שערי מוכנות ו-Canary |
| סמכות | CIO מחליט; Risk Gate מטיל וטו | אין וטו לסוכן, Candidate או CIO |
2. מטרת כרך 3
מטרת-העל: להפוך תשתית החלטה תקינה ב-Shadow ליכולת תפעולית אמינה, מבוקרת והפיכה — תחילה Enforced ללא כסף אמיתי, לאחר מכן Broker Sandbox/Paper, ולבסוף Live Canary מוגבל.
- להוכיח איכות החלטה לאורך 50 מחזורי Shadow לפחות, בהתאם לתנאי המעבר שננעלו.
- לאכלס ולאמת reliability_profile לכל סוכן ולהשלים אישור Evidence Fusion.
- להגדיר Enforced כשלב סמכותי מבוקר, בלי לעקוף Risk Gate, Approval או TTL.
- להכין אינטגרציית ברוקר, התאמות, partial fills, recovery ו-reconciliation לפני Live.
- להגדיר Live Canary בכסף אמיתי עם גבולות הון, נכסים, שעות, פקודות ויכולת rollback.
- לייצר ממשל הפעלה, אירועים, תחקור, ניטור וחתימת מוכנות לייצור.
2.1 הגדרה מחייבת של מחזור Shadow וחלון T+7
מחזור Shadow כשיר הוא הערכה אחת של Candidate שהושלמה מקצה לקצה: קליטת חבילת הניתוח, Evidence Fusion, הפקת Decision ב-CIO, השוואה לנתיב הבסיס, סיווג mismatch וכתיבת Audit מלאה. סריקת שוק שלא הפיקה Candidate כשיר אינה מחזור; יום מסחר יכול להכיל כמה מחזורים.
- מכסת 50 המחזורים תיאסף לאורך 7 ימי מסחר לפחות; אין לרכז את המכסה בסריקות צפופות כדי לקצר את חלון ההוכחה.
- המדגם יכסה תנאי שוק מגוונים. תנאי שלא הופיע בחלון החי ייבדק ב-replay מאושר ומתועד, אך לא יחליף את מינימום 7 ימי המסחר החיים.
- לפי מסגרת הכיול של V2-CH6, תוצאת reliability למחזור מבשילה רק לאחר T+7. לכן G1 אינו נסגר עם המחזור ה-50: יש להמתין להבשלת חלון T+7 של כל מחזור שנכלל בחתימת reliability_profile.
כלל ספירה: G1 דורש גם 50 מחזורים כשירים וגם השלמת כל חלונות T+7. מחזור חסר נתונים, Audit, סיווג mismatch או תוצאת T+7 נשאר PENDING ואינו נספר כראיית יציאה.
3. מה אינו חלק מכרך 3
- כתיבה מחדש של Candidate, Evidence Fusion, CIO, כיול או חוזה AnalysisOutput.
- שינוי חוזה Decision, מכונת המצבים או כללי Risk Gate של כרך 1 ללא תהליך שינוי רשמי.
- הרחבת שווקים, Crypto, EU/ASIA, Bond או סוכנים שנדחו בכרך 2, אלא אם תנאי היסוד השתנה.
- חיבור ישיר של חשבון בנק למנוע ההחלטה. חשבון הבנק הוא מקור מימון לברוקר בלבד ואינו רכיב מסחר.
- מעבר ישיר מ-Shadow למסחר מלא. כל שלב מחייב שער כניסה, ראיות יציאה ואישור מפורש.
4. שערי המעבר של כרך 3
| שער | מצב כניסה | ראיות יציאה | המצב הבא |
|---|---|---|---|
| G0 — Baseline | V2 Shadow Active | גרסאות נעולות, 294 PASS, תמונת מצב ו-rollback | Shadow Validation |
| G1 — Shadow Proven | 50 מחזורים כשירים; ≥7 ימי מסחר | כל T+7 הושלמו; 0 mismatch מהותי; reliability ו-Fusion מאושרים | Enforced Paper |
| G2 — Enforced Stable | Decision של V2 משפיע ב-Paper בלבד | יציבות, Audit מלא, Risk/Approval/TTL תקינים | Broker Readiness |
| G3 — Broker Ready | חיבור Sandbox/Paper לברוקר | פקודות, fills, cancel, reconciliation ו-recovery PASS | Live Canary |
| G4 — Canary Proven | הון קטן ומגבלות קשיחות | תקופת Canary ללא חריגה מהותית ואישור אנושי | Controlled Live |
| G5 — Production Signed | Controlled Live יציב | SLO/SLA, Incident, DR, אבטחה וחתימה | Production |
אין מעבר אוטומטי: עמידה מספרית בשער אינה מפעילה את השלב הבא מעצמה. כל מעבר דורש דוח ראיות, החלטה מפורשת ויכולת חזרה מיידית לשלב הקודם.
4.1 הגדרה מחייבת של Mismatch מהותי
ב-50 מחזורי ה-Shadow לא די לספור פערים. כל mismatch יסווג, ינומק ויקושר ל-Candidate, ל-Decision ולגרסאות הקלט. פער מהותי הוא פער שהיה משנה פעולה, חשיפה, סיכון או חוק תפעולי; פער זניח הוא פער שאינו חוצה מדיניות ואינו משנה את הפעולה.
| סוג | Mismatch מהותי | פער לא-מהותי |
|---|---|---|
| כיוון פעולה | BUY מול SELL; הגדלת חשיפה מול REDUCE/EXIT; פעולה מול HOLD שנדרש מטעמי סיכון | אותו כיוון פעולה עם הבדל ניסוח בלבד |
| סיכון | חציית Risk Rule, מגבלת הון/פוזיציה/הפסד או סיווג מותר מול אסור | פער confidence שאינו משנה Risk Gate או Approval |
| מחיר או כמות | פער החוצה את סף ה-Trade Validity הפעיל או מגבלת Canary | פער בתוך הספים, עם אותה פעולה ואותה רמת סיכון |
| מצב ותוקף | Decision/Approval/TTL/Market State שונים באופן שהיה מאפשר או חוסם ביצוע | פער timestamp בתוך חלון freshness מאושר |
| ראיות ונתונים | נתון חסר/ישן/שגוי ששינה מסקנה או סיכון | הבדל timing מתועד שלא שינה מסקנה |
| תפעול | duplicate, idempotency failure, trace חסר או state לא מזוהה | הבדל latency בלבד בתוך SLO |
כלל G1 נדרש: 0 mismatch מהותי, 0 mismatch לא-מסווג ו-100% תיעוד גם לפערים הלא-מהותיים. פער חוזר שאינו מהותי נבדק כמגמת drift ואינו נמחק מהדוח.
5. מבנה מאושר ומחייב לכרך 3
החלוקה הבאה ננעלה כמבנה הרשמי של כרך 3. שמונת הפרקים, תחומי האחריות ותוצרי הסיום מחייבים; פירוט המשימות בכל פרק ייקבע במפרט הפרק בלי לשנות את גבולות המבנה ללא תהליך שינוי רשמי.
| פרק | נושא | תוצר סיום | קישור |
|---|---|---|---|
| V3-CH1 | מסירת מקל מכרך 2 ונעילת Baseline | מפת גרסאות, ראיות, חסמים ו-rollback מאושר | פתח → |
| V3-CH2 | אימות Shadow ודיוק החלטה | 50 מחזורים, mismatch, reliability ו-Fusion Sign-off | פתח → |
| V3-CH3 | Enforced במצב Paper | ניתוב CIO ל-Risk Gate וחיתוך נקי ללא כסף אמיתי | פתח → |
| V3-CH4 | חיבור Adapter קיים לברוקר | השלמת Sandbox/Paper end-to-end + reconciliation | פתח → |
| V3-CH5 | Live Canary ושמירת הון | מסחר אמיתי מוגבל, מדיד והפיך | פתח → |
| V3-CH6 | הרחבת התפעול של כרך 1 | SLO ו-AlertRules ל-Live/Canary על בסיס CH8 הקיים | פתח → |
| V3-CH7 | כיול Production ושינוי מבוקר | מדיניות drift, tuning, version promotion ו-rollback | פתח → |
| V3-CH8 | קבלה, חתימה ומעבר לייצור | דוח Cross-Volume וחתימת Production Readiness | פתח → |
6. V3-CH1 — מסירת מקל ונעילת Baseline
פרק הפתיחה יהיה קצר ומעשי: הוא אינו בונה מערכת חדשה אלא מוכיח מה בדיוק קיים בתחילת כרך 3.
- נעילת רשימת גרסאות לכל רכיבי V1/V2, כולל Prompt, Model, AgentProfile, Schema ו-Feature Flags.
- אימות 244/244 של כרך 1 ו-50/50 של כרך 2 באותה נקודת זמן.
- רשימת חסמים שנותרו למעבר: 50 מחזורים, mismatch, reliability_profile ואישור Fusion.
- תיעוד נתיב rollback מ-Enforced ל-Shadow ומ-Shadow להשבתת V2 בלבד.
- קביעת בעלים, סמכויות אישור, חלונות שינוי ותבנית דוח לכל שער.
6.1 כלל מנהלי מחייב לרכיבי Legacy
Legacy Review Date: בעת פתיחת כל משימת יישום הנוגעת לרכיב המסומן legacy: true חובה לקבוע legacy_review_date. משימה לא תעבור ל-IN_PROGRESS ללא תאריך בחינה, בעלים ותוצאת בחינה צפויה.
שדות חובה
legacy_review_date, legacy_owner, review_scope ו-evidence_refהחלטה במועד הבחינה
RETAIN, REPLACE, ISOLATE או RETIREדחיית תאריך מחייבת נימוק, מאשר, תאריך חלופי ו-AuditEvent; אין דחייה אוטומטית. רכיב Legacy ללא תאריך בחינה תקף מסומן כ-Governance Violation ואינו מקודם לשער הבא.
7. מעבר Shadow ל-Enforced
| נושא | Shadow | Enforced Paper | כלל מחייב |
|---|---|---|---|
| Decision | נוצר ומושווה בלבד | מניע את נתיב Paper | אותו חוזה Decision נעול |
| Risk Gate | פעיל וקובע | פעיל וקובע | אין עקיפה או soft bypass |
| Approval | לפי מצב המערכת | חובה לפי המדיניות | TTL ו-validity נשמרים |
| Execution | הנתיב הקיים/Paper | Paper בלבד | אין Broker Live |
| Rollback | השבתת V2 | חזרה ל-Shadow | פעולה אחת, מתועדת ונבדקת |
| Audit | השוואות ו-mismatch | Decision-to-execution מלא | אין אירוע ללא trace_id |
תרגיל Rollback מחייב: לפני מעבר שער G2 יבוצע תרגיל רטוב ומבוקר של חזרה אוטומטית מ-Enforced Paper ל-Shadow Active. תחילת rollback: עד 30 שניות מזיהוי/החלטה; חזרה מלאה ומאומתת ל-Shadow Active: עד 5 דקות. כשל בסף חוסם את G2.
7.1 מנגנון Enforced Paper וחיתוך נקי
V3-CH3 יגדיר מתג קנוני יחיד v3_cio_enforcement_mode מסוג enum: DISABLED, SHADOW או ENFORCED_PAPER. אין להשתמש בצירוף flags עצמאי שעלול ליצור שני נתיבי ביצוע פעילים.
| מצב | Decision סמכותי ל-Risk Gate | נתיב הסוכן היחיד | ביצוע |
|---|---|---|---|
| DISABLED | הנתיב הקיים | פעיל | Paper לפי המצב הקיים |
| SHADOW | הנתיב הקיים | פעיל וסמכותי | runCioShadow משווה בלבד; ללא executeTrade |
| ENFORCED_PAPER | Decision של CIO מ-evidenceFusion + cioAlgorithm | רץ כ-comparator לא-בר-ביצוע | CIO → Risk Gate → Approval → Paper בלבד |
- המעבר נחתך לפי enforced_cutover_at: Candidate חדש מהמועד ואילך משתמש ב-CIO כמקור Decision יחיד לביצוע.
- עסקת Paper פתוחה שנוצרה לפני החיתוך נשארת בבעלות הנתיב המקורי עד מצב סופי; אין הסבה, re-parenting או יצירת פקודת יציאה כפולה.
- לכל Decision ו-Trade יירשם decision_source. פלט ההשוואה מהנתיב שאינו סמכותי יסומן NON_EXECUTABLE_SHADOW ולא יוכל להגיע ל-executeTrade.
תנאי סגירת V3-CH3: אין סגירת הפרק ללא בדיקת cutover עם עסקאות Paper פתוחות, הוכחת מקור סמכות יחיד, אפס duplicate orders ותרגיל rollback שעומד בספי 30 שניות/5 דקות.
8. חיבור ברוקר וחשבון בנק
שימוש חוזר מחייב: תשתית הברוקר אינה נבנית מחדש. V3-CH4 מתחבר ל-Adapter הקיים (brokerAdapter.ts) ומשלים Sandbox/Paper end-to-end; אין כתיבת adapter חלופי.
סדר נכון: ראשית בוחרים ומחברים ברוקר ב-Sandbox/Paper; לאחר שהאינטגרציה, ההתאמות וה-Canary מאושרים, מחברים חשבון בנק לצורכי הפקדה ומשיכה בלבד. חשבון הבנק אינו מתחבר ל-CIO, ל-Risk Gate או ל-executeTrade.
Air Gap מחייב: בין InvestIQ לבין רשת הבנק יישמר בידוד לוגי ורשתי מלא. CIO, Execution וכל שירות מערכת לא יחזיקו הרשאות, API keys, tokens, cookies או credentials של חשבון הבנק. העברת כספים תבוצע מחוץ למנוע ורק אל חשבון הברוקר המאושר; למערכת מותר לקרוא יתרות ותנועות מהברוקר בלבד.
| שלב | ברוקר | חשבון בנק | מותר |
|---|---|---|---|
| 1 — הכנה | בחירה, API, הרשאות, Sandbox | לא נדרש | קריאות, נתוני חשבון ו-Paper orders |
| 2 — אימות | Paper/Sandbox end-to-end | לא נדרש | fills, cancel, partial, reconciliation |
| 3 — פתיחת Live | חשבון מסחר Live חסום לפקודות | חיבור מימון מוגבל | הפקדה קטנה ובדיקות יתרה בלבד |
| 4 — Canary | Live עם מגבלות קשיחות | מימון מוגבל ומאושר | מספר קטן של פקודות/נכסים |
| 5 — Controlled Live | הרחבה מדורגת | לפי מדיניות הון | רק לאחר חתימת שער G4 |
9. עקרונות Live Canary
- Global Freeze חוסם קניות חדשות; מכירות, הקטנות ויציאות הגנה נשארות זמינות.
- תקרות הון, פוזיציה, הפסד יומי, מספר עסקאות ונכסים מאושרים הן דטרמיניסטיות.
- אין שינוי אוטומטי במגבלות בעקבות ביצועים טובים; הרחבה דורשת החלטה נפרדת.
- פקודה כפולה, מצב לא מזוהה, reconciliation חסר או mismatch מהותי מחזירים ל-Paper/Shadow.
- כל fill חלקי, cancel, reject ו-timeout מקבלים AuditEvent וקישור Decision-to-Order-to-Fill.
- החלטה מאומצת: ה-Canary מתחיל במצב hard_semi — אישור אנושי פרטני לכל Decision שעבר Risk Gate.
מסמך יסוד · v1.0 Locked & Approved · 12.8.2026 · בסיס מחייב לכרך 3
חזרה למפרטים ומסמכים