הסכום המרבי לסיכון הוא $200 (2% מ-10,000$). במחיר של $185.35 למניה, ניתן לרכוש מניה אחת בלבד (1 מניה = $185.35). המערכת מעגלת תמיד למטה למספר שלם של מניות, ולעולם לא תקנה יותר ממה שתקציב הסיכון מאפשר — גם אם ה-AI ימליץ על פוזיציה גדולה יותר, הקוד הקשיח יחתוך את הכמות למספר המניות המקסימלי שמתאים לתקציב הסיכון.

המערכת לא תשלח פקודה נוספת על אותו הסמל כל עוד הפקודה הראשונה במצב PENDING/SENT/WORKING. הכסף לפקודה הראשונה כבר "מוקצה" (reserved_cash_usd), ולכן שליחת פקודה נוספת תיחסם כדי למנוע "בזבוז כפול" של אותו תקציב. המערכת תמתין לקבלת סטטוס סופי (אושרה / נכשלה / פגה), ורק אז תבצע הערכה מחדש. אם הפקודה הראשונה תאושר — אין צורך בפקודה נוספת. אם תיכשל או תפוג — המערכת תבחן מחדש את האיתות החדש ותחליט.

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

המערכת לא תנסה שוב ושוב בלופ אינסופי. היא תנסה פעם אחת נוספת (מקסימום ניסיון חוזר = 1), ואם גם היא נכשלת — היא תעבוד מול מסד הנתונים הפנימי של Base44 שמכיל את הנתונים העדכניים ביותר שנשמרו. חשוב: אם הכשל חל על נכס עם הגנות פעילות (סטופ-לוס או טייק-פרופיט), המערכת לא תתעלם ממנו בשתיקה — היא תפעיל התראת חירום קריטית ("אובדן מעקב זמן אמת") שתדווח למשתמש באפליקציה ובאימייל שהמעקב על הסטופ-לוס/טייק-פרופיט הופסק זמנית, ותבקש בדיקה ידנית של העמדה. קניות חדשות נחסמות על בסיס נתונים לא עדכניים, אך מכירות ידניות וסטופ-לוס שנשלחו מראש לברוקר נשארים פעילים אצל הברוקר באופן עצמאי, ללא תלות במערכת שלנו.

הנתונים נשלפים ממסד הנתונים של Base44 (הישויות Portfolio ו-SystemSettings), ולא מהזיכרון הפנימי של ה-AI. ה-AI אינו שומר "זיכרון שיחה" של יתרות או פוזיציות — הוא מקבל תמונת מצב עדכנית ממסד הנתונים בכל סבב ניתוח. מסד הנתונים מתעדכן על ידי תהליכי רקע (רענון מחירים, עדכון יתרות אחרי ביצוע עסקה). במצב Paper (הנוכחי) אין קריאת API חיה לברוקר בזמן ההחלטה — הנתונים מגיעים ממסד הנתונים המקומי שמתוזמן לעדכון.

יש קוד קשיח. מודל ה-AI אינו יכול לעקוף את מגבלות הסיכון. ברגע שהעסקה מגיעה לשלב הביצוע (executeViaBroker), המערכת בודקת: (1) האם יש מספיק מזומן במאגר הרלוונטי — אם לא, הפקודה נדחית אוטומטית עם הודעת שגיאה. (2) האם המערכת בהקפאה גלובלית — אם כן, קניות נחסמות. (3) האם עבר שער הסיכון (Risk Gate) — אם לא, הביצוע נחסם. אף אחת מהבדיקות האלה אינה תלויה בשיקול דעת של ה-AI — הן קוד תכנותי קשיח שרץ לפני כל ביצוע.

המערכת מגבילה ניסיונות חוזרים למקסימום אחד (max_retries = 1). אין לופ אינסופי של ניסיונות. טווחי הזמן מוגדרים: טיימאאוט שליחה = 20 שניות, טיימאאוט מילוי Market = 90 שניות, טיימאאוט ביטול = 20 שניות. אם הניסיון השני נכשל, הפקודה מסומנת כ-FAILED ונרשמת ביומן האירועים לבירור ידני. כל ניסיון משתמש במפתח Idempotency ייחודי כדי למנוע כפילות — גם אם התגובה מגיעה באיחור, לא תיווצר פקודה כפולה.

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

במצב Paper (הנוכחי) ההשהיה מינימלית — שניות ספורות, כי הביצוע דטרמיניסטי (לא עובר דרך רשת חיצונית). במצב Live עתידי, ההשהיה תושפע מ: זמן עיבוד ה-AI (מודל מהיר/זול = שניות, מודל יקר = עשרות שניות), וזמן תגובת API של הברוקר (בדרך כלל מילישניות עד שניות). סך הכל: מספר שניות עד חצי דקה במצב Live. המערכת אינה מתיימרת להיות מערכת HFT (מסחר בתדירות גבוהה) — היא מערכת ניתוח והחלטה.

יש מנגנון הגנה. המערכת בודקת סטיית מחיר (Price Drift): במצב אוטומטי הסף הוא 3%, במצב חצי-אוטומטי/ידני הסף הוא 5%. אם המחיר זז מעבר לסף בין רגע ההחלטה לרגע הביצוע, הפקודה פגה אוטומטית (PRICE_DEVIATION_EXCEEDED). בנוסף, ניתן להגדיר פקודות Buy Limit שמגבילות את מחיר הכניסה המקסימלי — העסקה לא תבוצע מעל המחיר שהוגדר. המערכת לא תקנה "בכל מחיר".

פקודות Stop-Loss ו-Take-Profit אינן נשלחות על ידי המערכת בזמן אמת כשהמחיר מתקרב — הן נשלחות מראש לברוקר (כפקודות DAY או GTC) ברגע שהפוזיציה נפתחת. הברוקר אחראי לבצע אותן באופן עצמאי, ללא תלות במערכת שלנו או בעומס על השרתים שלה. כך, גם אם המערכת שלנו תקועת או איטית בזמן עומס, ה-Stop-Loss עדיין פעיל אצל הברוקר.

המערכת בודקת סטיית מחיר ברגע האישור בשני ספים: סף אישור מחדש (2% ברירת מחדל) וסף תפוגה (5% למצב חצי-אוטומטי). פער של 4% חורג מסף האישור המחדש — ולכן האישור הקודם מבוטל אוטומטית, והעסקה עוברת לסטטוס "דרוש אישור מחדש". המשתמש מקבל הודעה: "המחיר השתנה ב-4% מאז ההמלצה (מ-$X ל-$Y). האישור הקודם בוטל. אשר מחדש אם ברצונך לבצע במחיר החדש." רק לאחר שהמשתמש לוחץ אישור נוסף, העסקה מבוצעת. אם הפער היה מעל 5%, הפקודה הייתה פגה לחלוטין (PRICE_DEVIATION_EXCEEDED) והמשתמש היה צריך לקבל המלצה חדשה. הסיבה: יחס הסיכון/סיכוי המקורי (שעליו התבססו הסטופ-לוס והטייק-פרופיט) משתנה כשמחיר הכניסה זז משמעותית — והמערכת לא תבצע עסקה במחיר שונה משמעותית ללא הסכמה מפורשת מחודשת.

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

כרגע המערכת משתמשת בנוסחה קבועה: אחוז מקסימלי לעסקה (ברירת מחדל 10% מסך התיק), כאשר גם גודל הפוזיציה וגם המחיר מוגבלים בתקציב הסיכון. המערכת לא מתאימה אוטומטית את גודל הפוזיציה לתנודתיות (ATR/Beta) של המניה הספציפית — זוהי יכולת עתידית מתוכננת. כיום, התאמה לתנודתיות נעשית ידנית על ידי המשתמש דרך הגדרת ה-Stop-Loss וה-Take-Profit, והמערכת מכבדת את הגבולות שהוגדרו.

ה-Stop-Loss נשלח מראש לברוקר כפקודה עצמאית. כאשר המניה נעצרת (Halt), הברוקר לא יכול לבצע את ה-Stop-Loss. כשהמסחר מתחדש והמחיר נפתח בפער מתחת ל-Stop-Loss, הפקודה תופעל אוטומטית — אבל במחיר הפתיחה החדש (שעשוי להיות נמוך משמעותית ממחיר ה-Stop-Loss). זוהי סכנת שוק אמיתית שאי אפשר למנוע לחלוטין. המערכת תתעד את האירוע ותדווח על ההפסד שנוצר. זה בדיוק הסיבה שהמערכת מגבילה את גודל הפוזיציה — כדי שפער כזה לא ימחק חלק משמעותי מהתיק.

כן. קיים מפסק פקק אוטומטי (Circuit Breaker) שרץ בכל מחזור רענון מחירים. המערכת מחשבת את ההפסד היומי המצטבר = רווח/הפסד לא-ממומש של כל הפוזיציות הפתוחות + רווח/הפסד ממומש מעסקאות שבוצעו היום. כאשר ההפסד הכולל חורג ממגבלת ההפסד היומית (daily_loss_limit_pct, ברירת מחדל 5% מההון ההתחלתי), המערכת מפעילה אוטומטית הקפאה גלובלית (global_freeze = true) שחוסמת פתיחת פוזיציות חדשות למשך שארית היום. מכירות וצמצום עמדות עדיין מתאפשרים — כדי שהמשתמש יוכל לצאת מפוזיציות. המערכת שולחת הודעה קריטית ואימייל מיידי עם הפעלת המפסק. החישוב רץ בכל מחזור רענון (כל מספר דקות), לא רק פעם ביום — כך שהמערכת מגיבה מהר ככל שהמחירים מתעדכנים.

המערכת כרגע לא סורקת ולא מבצעת עסקאות ב-Pre-Market או After-Hours. סריקות ה-AI מתוזמנות לשעות המסחר הרגילות. פקודות Stop-Loss נשלחות כפקודות GTC (Good-Till-Cancelled) שנשארות פעילות גם מחוץ לשעות הרגילות אצל ברוקרים שתומכים בכך. לברוקרים שלא תומכים — המערכת מסתמכת על כך שה-Stop-Loss יופעל בפתיחת המסחר הבאה. אירועים משמעותיים שקורים מחוץ לשעות המסחר ייתפסו בסריקת הבוקר (Morning Routine) שרצה לפני פתיחת השוק.

זה אינו הפסד אמיתי — זהו פיצול מניות טכני. כשחברה מבצעת פיצול 1:3, כל מניה הופכת ל-3 מניות והמחיר יורד לשליש. השווי הכולל לא משתנה. המערכת מזהה פיצולים אוטומטית בשלוש דרכים: (1) זיהוי רטרואקטיבי — השוואת מחיר הקנייה הממוצע למחיר הנוכחי; אם היחס תואם לפיצול מוכר (למשל 3.0), המערכת מתאימה את הכמות (×3) ואת מחיר הקנייה הממוצע (÷3). (2) זיהוי בזמן אמת — השוואת המחיר הישן השמור לציטוט החדש מהשוק. (3) זיהוי משיעור השינוי היומי של Yahoo — ביום הראשון אחרי פיצול, chartPreviousClose עדיין לא מותאם ומראה צניחה של -66.7%. ההפסד הפיקטיבי נעלם מיד לאחר ההתאמה האוטומטית — הכמות גדלה פי 3 ומחיר הקנייה יורד לשליש, כך שהרווח/הפסד חוזר לערך האמיתי. סטופ-לוס וטייק-פרופיט מותאמים אוטומטית באותו יחס. התיקון מתבצע ברענון המחירים הבא של המערכת (כל מספר דקות) — אין צורך בפעולה ידנית.

התיקון אינו תלוי בעדכון של Yahoo. המערכת משתמשת בשלושה איתותים עצמאיים. האיתות הרטרואקטיבי (השוואת מחיר קנייה למחיר נוכחי) פועל גם ימים ושבועות אחרי הפיצול, כי מחיר הקנייה הממוצע לא משתנה ברענוני מחירים. לכן גם אם Yahoo כבר עדכן את הנתונים ושיעור השינוי היומי חזר ל-0%, המערכת עדיין תזהה את הפיצול ותתקן את ההפסד הפיקטיבי ברענון הבא. התיקון אידמפוטנטי — לאחר ההתאמה, מחיר הקנייה והמחיר הנוכחי מותאמים שניהם, היחס נהיה ~1, והמערכת לא מפעילה את ההתאמה שוב. חשוב להדגיש: ירידה אמיתית במניה לא תניב יחס מדויק של 3.0 או 2.0 — פיצול מניב יחס מדויק, ולכן המערכת לא תתבלבל בין ירידה אמיתית לפיצול טכני.

לכל פקודה יש מזהה ייחודי (client_order_id) ומצב ביצוע (execution_state) שעובר דרך מכונת מצבים. כשהמערכת שולחת פקודה, היא ממתינה לאישור קליטה (עד 20 שניות). אם לא מתקבל אישור, הפקודה מסומנת כ-FAILED ונרשמת ביומן האירועים לבירור. המערכת לא מניחה שהפקודה הצליחה או נכשלה — היא מסמנת אותה כדורשת בירור (RECONCILIATION_REQUIRED). במצב כזה, המערכת בודקת מול הברוקר את הסטטוס באמצעות המזהה הייחודי, ומתקנת את המצב. פוזיציה "יתומה" (פקודה שנקלטה אצל הברוקר אך המערכת לא יודעת על כך) תתגלה בבדיקת הבירור.

במסלול הידני והחצי-אוטומטי, ההחלטה הסופית היא של המשתמש. ה-AI לא דורס את החלטת המשתמש. עם זאת, המערכת מציגה את שני הצדדים: גם האיתות הטכני החיובי וגם החדשות השליליות, עם נימוק מפורט. סוכן ה-CIO (מנוע המיזוג) שוקל את המשקל היחסי: חדשות שליליות חמורות (כמו הונאה, פשיטת רגל, תביעה משמעותית) מקבלות משקל גבוה יותר מאיתות טכני. ההמלצה שהמשתמש יראה תציין את הסתירה ותמליץ בדרך כלל על המתנה או דחייה עד להתבהרות. אבל בסופו של דבר — המשתמש לוחץ "אישור" או "דחייה".