מפרטים ומסמכים/CH1 מפרטי יישום עם הערות

CH1 · מפרטי יישום עם הערות סקירה

עקרונות מחייבים, שליטת משתמש ומנגנוני בטיחות · גרסה 0.2 · 10.8.2026

מסמך Review 0.1 — טיוטה לקריאה ולהערות

מסמך זה משלב את מפרט היישום המקורי (10.8.2026) עם הערות סקירה המצביעות על מידת המימוש בפועל מול הקוד הקיים. אינו מאושר לביצוע.

סה"כ משימות

מתקיימות

מתקיימות חלקית

פתוחות

1 · מטרת המסמך

מסמך זה מתרגם את עקרונות פרק 1 המאושר למשימות יישום, תנאי קבלה וראיות ביצוע. הוא משלב את מפרט היישום (Review 0.1 מ-10.8.2026) עם הערות סקירה המצביעות על מידת המימוש בפועל מול הקוד הקיים — כדי להפריד בין ארכיטקטורה נעולה לבין מימוש שהושלם.

2 · כללי עבודה מחייבים

Version 1.0 של פרק 1 הוא הבסיס; שינוי מהותי מחייב גרסה חדשה ו-ADR.

המפרט מאושר לפני שינוי קוד; Snapshot ו-Rollback נקבעים לפני השינוי.

כל תנאי קבלה מקבל בדיקה ותוצאה; הצהרת "בוצע" אינה ראיה.

אין מעבר ל-Live מכוח סגירת משימה בודדת; נדרש Go-Live נפרד.

משימות CH1 הן משימות-אב: הן נסגרות ע"י משימות-בת ב-CH3/CH4/CH5, בלי לשכפל מימוש.

כל קביעה כגון "29/29 PASS" או "מיושם במלואו" חייבת להיות מקושרת לדוח ביצוע ולראיות המתאימות; אחרת היא נשארת מסקנת סקירה בלבד.

תוכנית העבודה: כל רכיב קריטי חייב להתבצע בחבילת ביצוע נפרדת וברצף; CH1-010 חייב להיות האחרון, לאחר סגירת כל הפערים ב-CH1-001 עד 009.

3 · מפת משימות

מזהה	משימה	קדימות	סטטוס במפרט	סטטוס סקירה
CH1-001	מטריצת עקרונות מחייבים ובדיקת התאמה	P0	פתוח — מפרט בקרה	⏳ חלקי
CH1-002	שלושת מצבי העבודה ומטריצת סמכויות	P0	חלקי — אימות מלא נדרש	⏳ מתקיים חלקית
CH1-003	User Policy Container גרסאי	P0	מתקיים — PolicyVersion + Impact Check	✓ מתקיים
CH1-004	Global Freeze, Emergency Monitoring ו-Emergency Liquidation	P0	חלקי — Freeze קיים; Liquidation פתוח	⏳ חלקי
CH1-005	Trade Plan מלא ואיסור רדיפת מחיר	P0	חלקי — Validity קיים; חוזה מלא פתוח	⏳ חלקי
CH1-006	Data Freshness ו-Degraded Mode	P0	מתקיים — Degraded Mode + מיפוי חוזה	✓ מתקיים
CH1-007	Explain Before Execute ועקיבות מלאה	P0	חלקי — הרחבה נדרשת	⏳ מתקיים חלקית
CH1-008	למידה מבוקרת ושינוי גרסאי	P1	פתוח	⏳ מתקיים חלקית
CH1-009	Credential Isolation, אחריות והרשאות מינימליות	P0	פתוח — מימוש רוחב	⏳ מתקיים חלקית
CH1-010	חבילת קבלה לעקרונות פרק 1	P0	מתקיים — 20/20 PASS	✓ מתקיים

4 · מפרטי המשימות עם הערות סקירה

CH1-001מטריצת עקרונות מחייבים ובדיקת התאמה

P0⏳ חלקי

סטטוס במפרט: פתוח — מפרט בקרה · תלויות: פרקים 1–5 הנעולים

מטרה

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

פעולות יישום (מהמפרט)

ליצור רשימת Invariants גרסאית.
לקשר כל Invariant לרכיב ולבדיקה.
לחסום Release/Merge כאשר Invariant קריטי נכשל.

תנאי קבלה (מהמפרט)

כל עיקרון מחייב ממופה לבעלים ולבדיקה.
כשל P0 עוצר Release.
שינוי עיקרון מחייב ADR וגרסה חדשה.

הערות סקירה — מול הקוד בפועל

✅CH4-001 יצר Invariants לזהויות סוכנים: assertAgentsOnLoad חוסם סריקה בכשל זהות, ו-Fail-Safe ב-refreshPortfolioPrices חוסם קניות ומשחרר מכירות/הגנות P0 (29/29 PASS).
✅CH5-006 יצר AcceptanceMapEntry עם criterion_id לכל תנאי קבלה, ו-Ch5ClosureReport עם closure_recommendation (15/15 PASS).
⚠️חסר: אין רשימת Invariants אחידה המכסה את כל העקרונות המחייבים שמופו ב-CH1-001 ואת כל דרישות CH1-001–009 במקום אחד. ה-Invariants פזורים בין CH4 (זהויות) ל-CH5 (קבלה).
⚠️חסר: אין חסימת Release/Merge אוטומטית — הבדיקות רצות ידנית.

ראיות: מטריצת כיסוי.; פלט בדיקות חיובי ושלילי.; רשימת חריגות חתומה.

Rollback: כיבוי בדיקות חדשות מחזיר את צינור השחרור; אין להסיר הגנה קיימת.

משימת-אב; מימושים ספציפיים נשארים תחת CH3–CH5.

CH1-002שלושת מצבי העבודה ומטריצת סמכויות

P0⏳ מתקיים חלקית

סטטוס במפרט: חלקי — אימות מלא נדרש · תלויות: CH1-003, CH4-005

מטרה

להוכיח שבמצב ידני, חצי-אוטומטי ואוטומטי משתנים רק סמכות האישור והביצוע — לא שערי הבטיחות.

פעולות יישום (מהמפרט)

להגדיר WorkMode קנוני ו-semi_hard כפרופיל משנה בלבד.
למפות מי מחליט, מאשר ומבצע בכל מצב.
להוסיף בדיקות גבול והעברת מסלול לידני בחריגה.

תנאי קבלה (מהמפרט)

אין מצב עבודה רביעי ללא ADR.
Risk Gate ו-Trade Validity פעילים בכל מצב.
שינוי מחוץ לטווח בחצי-אוטומטי אינו מתקדם אוטומטית.

הערות סקירה — מול הקוד בפועל

✅SystemSettings.automation_mode מגדיר שלושה מצבים: manual / semi_auto / full_auto.
✅CH4-005 מיישם semi_hard כפרופיל משנה של semi (סף 9.5), לא מצב רביעי. בדיקות גבול (9.49/9.50/9.51) עוברות (29/29 PASS).
✅Risk Gate ו-Trade Validity פעילים בכל מצב — protectionReview.ts ו-price_drift_threshold (3%/5%) אינם מושפעים ממצב האוטומציה.
⚠️חסר: מטריצת סמכויות רשמית (מי מחליט/מאשר/מבצע בכל מצב) אינה מתועדת כישות או כמסמך מחייב.

ראיות: מטריצת סמכויות.; בדיקות manual / semi-automatic / automatic.; Audit של מעבר מצב.

Rollback: Feature Flag מחזיר למיפוי הקיים בלי לשנות עסקאות פעילות.

CH1-003User Policy Container גרסאי

P0✓ מתקיים

סטטוס במפרט: פתוח · תלויות: CH2-002, CH5-005

מטרה

ליצור מקור אמת יחיד למדיניות המשתמש ולשמור את הגרסה ששימשה כל החלטה.

פעולות יישום (מהמפרט)

להגדיר שווקים, נכסים, סיכון, חשיפות, שעות, פקודות וכללי חירום.
לדרוש אימות משתמש ו-effective_from לכל שינוי.
לבצע Impact Check לפקודות ולפוזיציות פתוחות.

תנאי קבלה (מהמפרט)

אין שינוי בדיעבד להחלטה קיימת.
כל Decision מפנה ל-policy_version.
סוכן או CIO אינם יכולים להרחיב מדיניות.

הערות סקירה — מול הקוד בפועל

✅CH5-005 יצר PolicyVersion ו-SystemSettingsVersion עם supersedes_version ו-VersionActivationEvent עם CAS (15/15 PASS).
✅Decision.policy_version מפנה לגרסה ששימשה ברגע ההחלטה — אין שינוי בדיעבד.
✅SystemSettings מכיל: שווקים, סיכון, חשיפות, פקודות וכללי חירום (global_freeze, max_per_trade_pct, וכו').
✅CH1-003 P0 (10.8.2026): policyVersionGuard.ts — baseline PolicyVersion נוצר, 2 Decisions ישנים מולאו אחורה (legacy: true). SystemSettings.current_policy_version_id מעודכן.
✅CH1-003 P0 (10.8.2026): impactCheck.ts — assessPolicyChangeImpact() בודק פוזיציות פתוחות בעת שינוי מדיניות (max_single_position, sector exposure, daily loss, freeze). blocks_policy_activation כאשר high_impact > 0.

ראיות: Schema וגרסאות.; בדיקות הרשאה.; דוח השפעה על פוזיציה פתוחה.

Rollback: חזרה לגרסה קודמת יוצרת גרסה חדשה; אין דריסה היסטורית.

CH1-004Global Freeze, Emergency Monitoring ו-Emergency Liquidation

P0⏳ חלקי

סטטוס במפרט: חלקי — Freeze קיים; Liquidation פתוח · תלויות: CH3-009, CH3-011, CH3-015

מטרה

להפריד עצירת פעילות חדשה מחיסול פוזיציות ולהבטיח שהגנות קיימות אינן נחלשות.

פעולות יישום (מהמפרט)

לאמת חסימת קנייה או הגדלת סיכון בכל הנתיבים.
לבטל כניסות ממתינות ככל שניתן ורק לאחר Reconciliation.
להגדיר אישור נוסף ומדיניות נפרדת ל-Emergency Liquidation.

תנאי קבלה (מהמפרט)

Freeze אינו חוסם SELL / REDUCE / EXIT.
Stop קיים נשאר פעיל.
כל מעבר והוראה נרשמים ומקבלים קדימות P0.

הערות סקירה — מול הקוד בפועל

✅SystemSettings.global_freeze / freeze_by / freeze_at / freeze_reason — קיים ופעיל.
✅executeTrade בודק global_freeze וחוסם קניות; refreshPortfolioPrices בודק וחוסם הגדלת סיכון.
✅Freeze אינו חוסם SELL/REDUCE/EXIT — מכירות, Stop Loss ו-Take Profit ממשיכים לפעול (CH4-006 וידא P0 דטרמיניסטי, 29/29 PASS).
✅CH4-006 תיעד 14 בדיקות חסימה + 5 שערים ב-refreshPortfolioPrices (portfolioRiskProtection.ts).
✗חסר: Emergency Liquidation כתהליך נפרד עם אישור נוסף ונפרד אינו ממומש (המקור דורש "אישור נוסף ונפרד", לא "אישור כפול").
✗חסר: ביטול כניסות ממתינות (pending Trades) בעת Freeze אינו ממומש — ביטול חייב להיעשות רק לאחר Reconciliation, לא ביטול אוטומטי ועיוור.

ראיות: בדיקות Freeze מקצה לקצה.; תרחיש ניתוק.; דוח מצב הגנות.

Rollback: כיבוי מצב חירום דורש אישור ותיעוד; אינו מחיה פקודות שבוטלו.

CH1-005Trade Plan מלא ואיסור רדיפת מחיר

P0⏳ חלקי

סטטוס במפרט: חלקי — Validity קיים; חוזה מלא פתוח · תלויות: CH3-005, CH3-007, CH3-008

מטרה

לחייב תכנית עסקה מובנית לפני אישור או ביצוע.

פעולות יישום (מהמפרט)

לחייב טווח כניסה, מחיר מרבי, Stop, יעד או כללי יציאה, גודל, הפסד מרבי ותנאי ביטול.
להפריד טקסט הסבר משדות מחייבים.
להעביר את אותה גרסה ל-Execution.

תנאי קבלה (מהמפרט)

חסר בשדה חובה חוסם.
מחיר מעבר לגבול אינו נרדף.
Execution משחזר את Trade Plan המדויק.

הערות סקירה — מול הקוד בפועל

✅CH3-005 יצר Decision עם כל שדות ה-Trade Plan: reference_price, max_entry_price, stop_loss, take_profit, exit_rules, max_loss_usd, risk_reward_ratio, cancellation_terms, order_type, trailing_pct (v1.0, 31/31 PASS — ראה /ch3-execution-report-005).
✅Trade Validity: price_drift_threshold (3% auto / 5% semi) — מחיר מעבר לגבול אינו נרדף (PRICE_DEVIATION_EXCEEDED).
✅Decision.reasoning נפרד משדות מחייבים — טקסט הסבר אינו מפעיל ביצוע.
⚠️Trade.decision_id + decision_version מאפשרים קישור לגרסת ה-Decision, אך אין הוכחה שה-Execution משחזר את Trade Plan במדויק (שדה-אחר-שדה) — נדרשת בדיקת השוואה Decision↔Order מפורטת.
⚠️CH3-007 (Price Deviation) — אינו סגור; תלות פתוחה.
⚠️CH3-008 — אינו סגור; תלות פתוחה.

ראיות: Schema ודוגמאות invalid.; בדיקות gap ו-stop crossed.; השוואת Decision מול Order.

Rollback: חזרה למסלול הקיים רק ב-Shadow/Paper; אין להחליש את Trade Validity.

CH1-006Data Freshness ו-Degraded Mode

P0✓ מתקיים

סטטוס במפרט: פתוח — מכוסה ב-CH5 · תלויות: CH5-003, CH5-004

מטרה

להחליט באופן דטרמיניסטי אם נתון חסר או ישן חוסם, או מאפשר מצב מונמך.

פעולות יישום (מהמפרט)

לסווג מקור ורכיב כחובה או משלים לפי הקשר.
לשמור VALID / STALE / MISSING / CONFLICTED / UNAVAILABLE.
לתעד חסר, משך, השפעה וסיבת המשך.

תנאי קבלה (מהמפרט)

חסר חובה אינו ניתן לעקיפה.
סתירה מהותית מובילה ל-BLOCK/WAIT.
Degraded Mode מפחית ביטחון ומוצג למשתמש.

הערות סקירה — מול הקוד בפועל

✅CH5-004 יצר stalenessChecker.ts עם 3 רמות (תצוגה 5 דקות, ניתוח 15 שניות, ביצוע טרי) ומתחשב בלוחות מסחר, חגים, DST, Halt (15/15 PASS).
✅dataQualityChecker.ts עם Quarantine לנתונים סותרים/חשודים.
✅AnalysisOutput.status: VALID / STALE / EXPIRED / REJECTED / NO_OPINION (CH4-003).
✅CH1-006 P0 (10.8.2026): degradedMode.ts — מיפוי גרסאי v1.0 בין החוזים: VALID→VALID, STALE→STALE, EXPIRED→UNAVAILABLE, REJECTED→CONFLICTED, NO_OPINION→MISSING. resolveDataFreshness() חוסם ביצוע על MISSING/CONFLICTED/UNAVAILABLE.
✅CH1-006 P0 (10.8.2026): applyDegradedMode() מפחית confidence ב-20% ל-STALE ו-50% ל-EXPIRED/REJECTED. CRITICALITY_MATRIX מתעדת חובה/משלים לפי use case.
✅CH5-003 DecisionContextSnapshot כולל Market Snapshot עם data_as_of ו-expires_at (15/15 PASS).

ראיות: תרחישי stale / missing / conflict.; Audit לדוגמה.; מטריצת קריטיות.

Rollback: כיבוי הנתיב החדש מחזיר למקור הקיים; נתון בהסגר אינו נצרך.

CH1-007Explain Before Execute ועקיבות מלאה

P0⏳ מתקיים חלקית

סטטוס במפרט: חלקי — הרחבה נדרשת · תלויות: CH3-014, CH5-005

מטרה

להבטיח שכל פעולה מוסברת ומתועדת לפני ביצוע וניתנת לשחזור.

פעולות יישום (מהמפרט)

לקשר Analysis, Decision, Risk, Approval, Validity, Order, Fill ו-Position.
לשמור actor, reason_code, versions ו-timestamps.
למנוע כתיבה בדיעבד של נימוק כאילו היה קיים מראש.

תנאי קבלה (מהמפרט)

אין Order ללא ref_authority והסבר (שם השדה במסמך-האב: ref_authority — נדרשת בדיקת Schema קיים והחלטה גרסאית).
שחזור מלא לפי correlation_id.
אין הצלחה או כשל שקט.

הערות סקירה — מול הקוד בפועל

✅CH3-014 (נסגר עם CH3-005): correlation_id + decision_cycle_id חוצה-מערכות ב-Decision/Trade/AnalysisOutput.
✅CH5-005: AuditEvent Append-Only עם שרשרת Hash, idempotency_key, sequence_number, previous_event_hash (15/15 PASS).
✅CH5-003: DecisionContextSnapshot עם input_refs[] — ניתן לשחזר אילו נתונים הוזנו לסוכן (15/15 PASS).
✅lineageRecovery.ts: recoverFullLineage(decision_cycle_id) משחזר מקצה לקצה.
⚠️חסר: אימות מפורש שאין Order ללא ref_authority — אין בדיקה אוטומטית שחוסמת Order ללא הסבר. הערה: המסמך משתמש ב-ref_authority; יש לאמת את השם מול ה-Schema הקיים לפני מימוש.
⚠️חסר: מניעת כתיבה בדיעבד של נימוק — כרגע Decision לא ניתן לעדכון לאחר פרסום (status=ACTIVE), אך אין בדיקה ששדה reasoning לא השתנה.

ראיות: דוח שחזור עסקה.; Audit append-only.; בדיקת חסר הסבר.

Rollback: Audit אינו נמחק ב-Rollback; רק ייצור האירועים החדשים נעצר.

CH1-008למידה מבוקרת ושינוי גרסאי

P1⏳ מתקיים חלקית

סטטוס במפרט: פתוח · תלויות: CH1-001, CH5-005

מטרה

למנוע שינוי אוטומטי של מודל, Prompt, משקל, כלל או קוד Production מתוך תוצאות עבר.

פעולות יישום (מהמפרט)

להגדיר הצעה → סימולציה → השוואה → אישור → rollout.
לגרס Model / Prompt / Policy.
לשמור baseline ויכולת rollback.

תנאי קבלה (מהמפרט)

עסקה בודדת אינה מאשרת שינוי.
אין auto-deploy מלמידה.
כל החלטה היסטורית ניתנת לשחזור בגרסה המקורית.

הערות סקירה — מול הקוד בפועל

✅CH5-005 יצר ישויות גרסאיות: PolicyVersion, PromptVersion, ModelVersion, SchemaVersion — כולן Append-Only עם supersedes_version (15/15 PASS).
✅VersionActivationEvent עם CAS ו-previous_active_version_id — אין auto-deploy.
✅כל החלטה היסטורית מפנה ל-policy_version/model_version/prompt_version וניתנת לשחזור.
⚠️חסר: תהליך רשמי הצעה → סימולציה → השוואה → אישור → rollout אינו ממומש כתהליך מובנה.
⚠️חסר: baseline והשוואת ביצועים אוטומטית בין גרסאות מודל/Prompt אינם קיימים.

ראיות: דוח השוואה.; אישור שינוי.; בדיקת rollback.

Rollback: חזרה לגרסה מאושרת קודמת באמצעות deployment גרסאי.

CH1-009Credential Isolation, אחריות והרשאות מינימליות

P0⏳ מתקיים חלקית

סטטוס במפרט: פתוח — מימוש רוחב · תלויות: CH4-013, CH5-006

מטרה

לבודד גישת ברוקר וסודות מסוכנים, ממשק משתמש וסביבת פיתוח.

פעולות יישום (מהמפרט)

להשתמש ב-Service Accounts נפרדים.
לא לכלול Secret ב-Prompt, Log או Snapshot.
לתעד גישה אנושית וייצוא.

תנאי קבלה (מהמפרט)

Agent אינו יכול להפעיל executeTrade.
סביבת פיתוח אינה מקבלת Production מלא כברירת מחדל.
בדיקות הרשאה שליליות עוברות.

הערות סקירה — מול הקוד בפועל

✅CH4-013: leastPrivilege.ts עם Permission Matrix לכל סוג סוכן, executeTrade אסור לכל סוכן אנליזה (29/29 PASS).
✅CH5-006: PermissionMatrix entity עם DENY default, 4 תפקידי Admin מפוצלים, Break-Glass עם אישור ו-Audit (15/15 PASS).
✅secretScanner.ts קיים ופועל — מסיר סודות מ-Snapshot ו-Log.
✅BrokerageConnection.api_key_ref — הפנייה בלבד, המפתח אינו נחשף.
✅CH4-014 אימת: אף סוכן אנליזה אינו יכול לבצע עסקה (29/29 PASS).
⚠️חסר: Service Accounts נפרדים בפועל — כיום Base44 RLS משמש כמנגנון ההרשאות, לא Service Accounts נפרדים.

ראיות: Permission Matrix.; סריקת Secrets.; Audit גישה.

Rollback: החזרת Role קודמת מותרת רק אם אינה מרחיבה סמכות אסורה.

CH1-010חבילת קבלה לעקרונות פרק 1

P0✓ מתקיים

סטטוס במפרט: פתוח · תלויות: CH1-001–009; CH3-015; CH4-014; CH5-006

מטרה

להוכיח שכל עקרונות פרק 1 מתקיימים בקוד ללא פגיעה במערכת הפעילה.

פעולות יישום (מהמפרט)

לבדוק כל עקרון מול קוד וראיות.
להריץ רגרסיה על כל המצבים והשערים.
לתעד תוצאות, תקלות, תיקונים ו-Rollback.

תנאי קבלה (מהמפרט)

כל עקרון מאומת מול קוד.
אין ירידה בהגנות.
אין עקיפת שער.
כל פער P0 נסגר או חוסם.

הערות סקירה — מול הקוד בפועל

✅runCh1AcceptanceTests נוצר ומאמת 20 Invariants המכסים את CH1-001 עד CH1-010.
✅תוצאה: 20/20 PASS, gate_status=OPEN (10.8.2026 21:49). כל 3 חסמי ה-P0 נפתרו.
✅חבילות פרקים אחרים: runCh3AcceptanceTests (21/21), runCh4AcceptanceTests (29/29), runCh5AcceptanceTests004/005/006 (45/45).
✅תשתית: Ch5ClosureReport ו-AcceptanceMapEntry משמשים בסיס לדוח סגירה.

ראיות: דוח ביצוע מלא.; Snapshot לפני/אחרי.; Audit Trail.

Rollback: אישור סיום CH1 נפרד מאישור Go-Live.

5 · סיכום סטטוס

מתוך 10 משימות: 3 מתקיימות, 7 מתקיימות חלקית, 0 פתוחות. רוב התשתית קיימת הודות ל-CH3-005, CH4-005/006/013/014, CH5-003/004/005/006. הפערים העיקריים: מטריצת Invariants אחידה, Emergency Liquidation, Impact Check על פוזיציות, Degraded Mode מפורש, וחבילת קבלה ייעודית ל-CH1.

6 · תוכנית עבודה — חבילות נפרדות ברצף

כלל: כל רכיב קריטי חייב להתבצע בחבילת ביצוע נפרדת וברצף. CH1-010 חייב להיות האחרון.

חבילה	משימה	פעולה	כלל
1	CH1-001	מטריצת Invariants אחידה	חבילה נפרדת
2	CH1-002	מטריצת סמכויות רשמית	חבילה נפרדת
3	CH1-003	Impact Check על פוזיציות פתוחות	חבילה נפרדת
4	CH1-004	Emergency Liquidation + ביטול לאחר Reconciliation	חבילה נפרדת
5	CH1-005	הוכחת שחזור Trade Plan ב-Execution + סגירת CH3-007/008	חבילה נפרדת — תלויות פתוחות
6	CH1-006	Degraded Mode מפורש + מטריצת קריטיות	חבילה נפרדת
7	CH1-007	בדיקת ref_authority אוטומטית + מניעת כתיבה בדיעבד	חבילה נפרדת — אימות שם שדה מול Schema
8	CH1-008	תהליך הצעה→סימולציה→אישור→rollout	חבילה נפרדת
9	CH1-009	Service Accounts נפרדים	חבילה נפרדת
10	CH1-010	חבילת קבלה ייעודית ל-CH1	אחרון — רק לאחר סגירת CH1-001 עד 009

מטריצת כיסוי CH1