סקירת פרק 7 — הרשאות, אישורים ומעורבות אנושית

Review Version 0.2 — משולב לאחר הערות חוסמות · 11 באוגוסט 2026

Version 1.0 — Approved Architecture Baseline for T7.1 ✅

אושר ב-11 באוגוסט 2026 על-ידי BAROUCH SHALIT. כל 6 ההערות החוסמות + 5 הערות נוספות טופלו ואומתו במסמך המקורי (v0.21 → v1.0). פסקת חוזה הספים (8.5/9.5) נוספה ל-§7.7. §7.16, §7.18, נספח ב׳ ו-נספח ג׳ — מלאים ומפורטים. 7/7 עקרונות מאושרים כבסיס ל-T7.1. מעבר ל-T7.1 מאושר.

חלק א׳ — 6 הערות חוסמות + תיקונים

מעמד המסמך מוקדם מדי — Version 1.0 נכתב מוקדם

חוסם

הבעיה: בתחילת המסמך נכתב Version 1.0, בסעיף 7.17 נכתב "החלטות נעולות ומאושרות", וב-DoD נכתב שהמסמך כבר ננעל ואושר — אף שטרם נבדק מול המערכת בפועל (T7.1 טרם התבצע).

תיקון מוצע:

גרסה: Review Version 0.2 — משולב לאחר הערות.
סטטוס: טיוטה משולבת לבדיקת As-Is מול המערכת — אינה נעולה.
§7.17 ינוסח מחדש: "החלטות מוצעות לנעילה — בכפוף לאימות T7.1".
DoD ינוסח מחדש: "המסמך מוכן למעבר ל-T7.1; אינו נעול עד סיום בדיקת As-Is והכרעת פערים".
רק לאחר T7.1–T7.4 והכרעת כל הפערים — מעבר ל-Version 1.0.

סטטוס: תוקן ב-Review v0.2

שמונה תפקידים לעומת עשרה רכיבים — §7.6 חסר פירוט

חוסם

הבעיה: בסעיף 7.6 נכתב ש-PermissionMatrix מחזיק עשרה רכיבים לוגיים, אך מפורטים רק שמונה. בנוסף, בפתיח מופיע תפקיד Approver, אך ברשימה אין תפקיד כזה בנפרד — צריך להחליט אם הוא חלק מ-Operator/User או תפקיד לוגי עצמאי.

תיקון מוצע:

לפרט את כל 10 הרכיבים הלוגיים (מתוך PermissionMatrix בקוד): Scanner, Agent, CIO Shadow, Risk Gate, Execution, Broker, System Admin, Security Admin, Operator, Auditor.
להוסיף טבלת רכיב × תפקיד × הרשאות קריאה/כתיבה × איסורים × Break-Glass.
להכריע ב-Approver: תפקיד לוגי עצמאי או חלק מ-Operator. המלצה: Approver הוא תפקיד לוגי השייך ל-Operator (אותו משתמש יכול לאשר הצעות שהוא עצמו לא יזם). יש לתעד זאת מפורשות ב-§7.6.
לסמן: "רכיבי PermissionMatrix — נטען שקיים, לאימות ב-T7.1".

סטטוס: תוקן ב-Review v0.2 — ראה חלק ד׳

סתירה בדרישת Re-authentication — §7.7 מול §7.12

חוסם

הבעיה: בסעיף 7.7 נקבע: מעבר ל-full_auto דורש אימות מחדש; מעבר בין manual ל-semi_auto דורש Audit בלבד. אבל בסעיף 7.12 נכתב שכל שינוי במצב העבודה או בסטטוס Freeze דורש אימות מחדש. שתי ההוראות אינן יכולות להישאר יחד.

תיקון מוצע:

כלל מאוחד (מחליף את §7.7 ו-§7.12): אימות מחדש (re-auth) נדרש בשלושה מקרים בלבד:
א) מעבר ל-full_auto (סיכון קריטי — ביצוע אוטומטי ללא אישור פרטני).
ב) ביטול Global Freeze (סיכון קריטי — שחרור עמדות לקנייה).
ג) שינוי הרשאות מהותי (הענקת/שלילת Break-Glass, שינוי PermissionMatrix).
הפעלת Global Freeze — מיידית, ללא אימות מחדש (פעולת הגנה P0 אינה ממתינה).
מעבר manual ↔ semi_auto — Audit בלבד, ללא אימות מחדש (שינוי תפעולי שגרתי, שערי ההגנה זהים).

סטטוס: תוקן ב-Review v0.2 — ראה חלק ה׳

נקודת בדיקת market_open אינה תואמת את הממצא האחרון

חוסם

הבעיה: המסמך קובע שהבדיקה נעשית "אך ורק" בתוך executeTrade. בדוח האחרון שלנו נקבע שהבדיקה מופעלת גם ב-refreshPortfolioPrices לפני הביצוע. אין לנעול נקודת אכיפה יחידה עד לאימות מול הקוד.

תיקון מוצע:

ניסוח נכון ל-§7.2 (לפני אימות T7.1):
"בדיקת market_open נאכפת בנתיב הביצוע הסופי. נקודת האכיפה המדויקת (executeTrade ו/או refreshPortfolioPrices) תאומת מול הקוד במסגרת T7.1."
להסיר את המילה "אך ורק" מכל מקום בו מופיעה ייחוס לנקודת אכיפה טרם אימות.

סטטוס: תוקן ב-Review v0.2 — ראה חלק ו׳

הספים 8.5 ו-9.5 אינם מוסברים — חוזה חד-משמעי חסר

חוסם

הבעיה: ב-full_auto מופיע סף confidence >= 8.5, וב-semi_auto נכתב שמתחת ל-9.5 מופעל semi_hard. זה יוצר אי-בהירות: האם 8.5 הוא סף ביצוע אוטומטי? מה בדיוק תפקיד 9.5? מדוע semi_hard מופעל כאשר הציון נמוך מ-9.5? האם semi_hard הוא מצב עבודה, פרופיל משנה או מנגנון אישור?

תיקון מוצע:

חוזה ספים מאוחד (לאימות מול CH1/CH4 והקוד ב-T7.1):
סף 8.5 (auto_execute_threshold ב-SystemSettings): סף ביצוע אוטומטי. ב-full_auto, Decision עם confidence >= 8.5 מבוצע אוטומטית (בכפוף לכל שערי ההגנה). מתחת ל-8.5 — הצעה נשמרת לאישור או נדחית.
סף 9.5: סף "רמת ביטחון גבוהה" במצב semi_auto. Decision עם confidence >= 9.5 מוצע לביצוע מיידי (pending אישור). מתחת ל-9.5 — מופעל hard_semi (פרופיל משנה של semi).
hard_semi (semi_hard): אינו מצב עבודה נפרד ואינו מנגנון אישור. זהו פרופיל משנה של semi_auto — כאשר confidence < 9.5, ההצעה נכנסת להמתנה ארוכה יותר (קירור) ודורשת אישור מפורש גם ב-semi_auto. שערי ההגנה זהים; רק זמן ההמתנה ודרישת האישור מחמירים.
לאמת את שני הספים מול SystemSettings.auto_execute_threshold והקוד ב-T7.1.

סטטוס: תוקן ב-Review v0.2 — ראה חלק ז׳

T7.4 אינו מפרט מלא — חסרים פעולות, קריטריונים, ראיות ו-Rollback

חוסם

הבעיה: ל-T7.1–T7.3 יש פעולות, קריטריוני קבלה וראיות. ל-T7.4 מופיעה רק המטרה. חסרים: תרחישי הבדיקה, קריטריוני PASS/FAIL, בדיקות רגרסיה, ראיות חובה, Rollback ותנאי סגירת CH7.

תיקון מוצע:

T7.4 יורחב למפרט מלא התואם את מבנה T7.1–T7.3 (ראה חלק ח׳).
יכלול: מטרה, תלויות, פעולות, קריטריוני קבלה, בדיקות נדרשות, תרחישי כשל, Rollback, ראיות ותנאי סגירה.

סטטוס: תוקן ב-Review v0.2 — ראה חלק ח׳

חלק ב׳ — הערות נוספות (נדרשות לתיקון)

שמות קבצים מוצגים כעובדות קיימות — לסמן כ"נטען שקיים"

הבעיה: שמות כגון leastPrivilege.ts, emergencyLiquidation.ts, tradeExecution.ts, explainBeforeExecute.ts, BreakGlassEvent ו-hash chain מוצגים כעובדות קיימות. לפני אימות מול המערכת יש לסמן אותם כ"נטען שקיים — לאימות ב-T7.1".

תיקון מוצע:

כל אזכור של שם קובץ/ישות/מודול ילווה בתגית: "נטען שקיים — לאימות ב-T7.1". רק לאחר T7.1 יוסר התג.

סטטוס: לתיקון ב-Review v0.3

איחוד שדות גרסאות ותפוגה — אי-בהירות

הבעיה: יש לאחד/להבהיר את השדות version_cas, decision_version, expires_at, proposal_expires_at ו-approval_expires_at. כרגע לא ברור אם אלה שדות שונים או שמות חלופיים.

תיקון מוצע:

טבלת הבהרת שדות (לאימות ב-T7.1):
• version_cas — מונה אופטימי להחלפה אטומית של Decision (CAS).
• decision_version — מספר גרסה של Decision בתוך משפחה (decision_family_id).
• expires_at — תוקף החלטה (Decision TTL, מתוך SystemSettings.decision_ttl_hours).
• proposal_expires_at — תוקף Proposal ל-Trade במצב pending (SystemSettings.proposal_ttl_hours).
• approval_expires_at — תוקף אישור ל-Trade במצב approved/wait (SystemSettings.approval_ttl_hours).
אלה 5 שדות נפרדים על 2 ישויות (Decision + Trade), אינם שמות חלופיים. יש לתעד מפורשות ב-§7.9.

סטטוס: תוקן ב-Review v0.2 — ראה חלק ט׳

נתון 47/50 התאמות — דרוש הסבר ל-3 הרשומות הנותרות

הבעיה: נתון 47/50 התאמות, 0 סתירות דורש הסבר לשלוש הרשומות הנותרות ומקור ראיה.

תיקון מוצע:

ה-3 הרשומות הן missingTrade: Decisions של CIO Shadow שלא הולידו Trade. במצב manual/semi_auto זה צפוי — המשתמש לא אישר את ההצעה, ולכן לא נוצרה עסקה. אין מדובר בסתירה. מקור ראיה: runCioShadow (10.8.2026, 47 matched / 0 mismatched / 3 missingTrade). יש לתעד זאת מפורשות ב-§7.14.

סטטוס: תוקן ב-Review v0.2

#10

רשימת תדירויות 15/30/60/720 — עלולה להטעות

הבעיה: רשימת התדירויות 15, 30, 60, 720 עלולה להשתמע כשייכת לחמשת הסוכנים הפעילים. 720 שייך ל-Financial Reports המושהה.

תיקון מוצע:

להציג תדירות לכל רכיב בנפרד (כפי שנעשה ב-CH6 Registry): Scanner 15 דק׳, News 30 דק׳, Technical 60 דק׳, Portfolio Risk 30 דק׳ (נפרד), Financial Reports 720 דק׳ (Paused — אין Scheduler פעיל). לא לכתוב רשימה מצטברת.

סטטוס: תוקן ב-Review v0.2

#11

סעיף 7.18 חסר — מספור קופץ מ-7.17 ל-7.19

הבעיה: המספור עובר מ-7.17 (החלטות מוצעות לנעילה) ל-7.19 (DoD). סעיף 7.18 חסר.

תיקון מוצע:

להוסיף §7.18: "שאלות Review פתוחות" — 6 שאלות שדורשות הכרעה לפני נעילה (ראה חלק י׳).
להזיז את ה-DoD מ-7.19 ל-7.20 אם יש צורך, או למלא את 7.18 ולהשאיר את 7.19 כ-DoD.
המלצה: §7.18 = 6 שאלות Review; §7.19 = DoD; §7.20 = מעבר לפרק 8.

סטטוס: תוקן ב-Review v0.2 — ראה חלק י׳

חלק ג׳ — תיקוני ניסוח ועימוד

תיקוני ניסוח:

"שאינם ניתנות" → "שאינם ניתנים"
"אינה ממתווה" → "אינה ממתינה"
"קול קריאה" → "קריאה"
"Mערכת" → "מערכת"

בעיות עימוד (לתיקון ב-DOCX):

▸כותרת האנגלית בעמוד הראשון נשברת בצורה לא טבעית והסוגריים מתהפכים — לתקן את כיוון הסוגריים (RTL) ולמנוע שבירת שורה.
▸בטבלת 7.8, בעמוד 7, נשארה שורת המשך שבה שלושה תאים ריקים ורק התא האחרון מכיל טקסט — למנוע שורות המשך ריקות בטבלאות (page-break-inside: avoid).
▸העמוד האחרון כמעט ריק — לצמצם את המסמך לאחר תיקון שבירות עמודים.

חלק ד׳ — תיקון §7.6: 10 רכיבי PermissionMatrix המלאים

#	רכיב	תפקיד	קריאה	כתיבה	איסורים
1	Scanner	סריקת שווקים	MarketData, AssetMaster	AnalysisOutput (scanner)	executeTrade, modify_risk_rule
2	Agent	ניתוח (News/Technical/Financials)	MarketData, AnalysisOutput	AnalysisOutput	executeTrade, change_global_freeze
3	CIO Shadow	איחוד המלצות (Shadow בלבד)	AnalysisOutput, Decision	Decision (shadow)	executeTrade, modify Trade
4	Risk Gate	בדיקת סיכונים	Trade, Portfolio, SystemSettings	RiskVerdict	executeTrade, change_automation_mode
5	Execution	ביצוע עסקה	Trade, Decision, SystemSettings	Trade (execution_state), Portfolio, TaxReport	create Decision, change_risk_rule
6	Broker	מתאם ברוקר (Adapter)	Trade (execution_state)	Fill, BrokerEvent	create Trade, create Decision
7	System Admin	ניהול תצורה	SystemSettings, AgentConfig	SystemSettings, AgentConfig	executeTrade, change PermissionMatrix
8	Security Admin	ניהול אבטחה	PermissionMatrix, AuditEvent, BreakGlassEvent	PermissionMatrix	executeTrade, change automation_mode (דורש re-auth)
9	Operator	תפעול יומי (כולל Approver)	Trade, Decision, Portfolio, Alerts	Trade (approve/reject), Alert	change PermissionMatrix, change_risk_rule
10	Auditor	ביקורת (קריאה בלבד)	AuditEvent, all entities (read-only)	—	כל פעולת כתיבה

Approver: תפקיד לוגי השייך ל-Operator (אותו משתמש יכול לאשר הצעות שלא יזם). אינו תפקיד נפרד ב-Paper.

הערה: כל הרכיבים מסומנים "נטען שקיים — לאימות ב-T7.1".

חלק ה׳ — תיקון §7.7/§7.12: כלל Re-auth מאוחד

פעולה	דרישה	סיבה
מעבר ל-full_auto	אימות מחדש (re-auth)	סיכון קריטי — ביצוע אוטומטי ללא אישור פרטני
ביטול Global Freeze	אימות מחדש (re-auth)	סיכון קריטי — שחרור עמדות לקנייה
שינוי הרשאות מהותי (Break-Glass, PermissionMatrix)	אימות מחדש (re-auth)	סיכון אבטחה — שינוי מפת סמכויות
הפעלת Global Freeze	מיידי, ללא אימות	פעולת הגנה P0 אינה ממתינה
מעבר manual ↔ semi_auto	Audit בלבד	שינוי תפעולי שגרתי, שערי הגנה זהים
מעבר מ-full_auto ל-semi_auto/manual	Audit בלבד	הקטנת סיכון — אינה מעלה סיכון

כלל זה מחליף את הסתירה בין §7.7 ו-§7.12 במסמך המקורי.

חלק ו׳ — תיקון §7.2: ניסוח market_open

בדיקת market_open נאכפת בנתיב הביצוע הסופי. נקודת האכיפה המדויקת (executeTrade ו/או refreshPortfolioPrices) תאומת מול הקוד במסגרת T7.1. עד לאימות, אין לנעול נקודת אכיפה יחידה.

חלק ז׳ — חוזה ספים 8.5 ו-9.5

סף	שדה/קוד	היקף	משמעות	סוג	אימות מול
8.5	SystemSettings.auto_execute_threshold	full_auto	סף ביצוע אוטומטי. Decision עם confidence >= 8.5 מבוצע אוטומטית (בכפוף לכל שערי ההגנה). מתחת ל-8.5 — הצעה נשמרת לאישור או נדחית.	סף ביצוע	SystemSettings + executeTrade
9.5	קוד: management_mode = hard_semi כאשר confidence < 9.5	semi_auto	סף "רמת ביטחון גבוהה". Decision עם confidence >= 9.5 מוצע לביצוע מיידי (pending אישור). מתחת ל-9.5 — מופעל hard_semi.	סף אישור	decisionObject.ts + management_mode
hard_semi	Trade.management_mode = "hard_semi"	semi_auto (תת-פרופיל)	פרופיל משנה של semi_auto. אינו מצב עבודה נפרד ואינו מנגנון אישור. כאשר confidence < 9.5 ב-semi_auto, ההצעה נכנסת להמתנה ארוכה יותר (קירור) ודורשת אישור מפורש גם ב-semi_auto. שערי ההגנה זהים; רק זמן ההמתנה ודרישת האישור מחמירים.	פרופיל משנה	Trade.management_mode + CH4 Review

חלק ח׳ — T7.4 מורחב: מפרט מלא

מטרה

להריץ חבילת בדיקות אחת המוכיחה שהרשאות, אישורים, Override, Freeze, חירום ומעורבות אנושית פועלים יחד ב-Paper וב-Shadow, ללא רגרסיה ב-CH1–CH6 וללא טענה שגויה למוכנות Live.

תלויות

T7.1–T7.3 סגורים עם דוחות ביניים; סביבת Paper תקינה; Shadow CIO פעיל ללא סמכות; CH1–CH6 סגורים (105/105 PASS).

פעולות (10)

1.להריץ Regression מלא ל-CH1–CH6 ולתעד כל חריגה.
2.להריץ מטריצת Override: legacy:true (מותר — Decision Gate בלבד), עקיפת Risk Gate (חסום), עקיפת TTL (חסום), עקיפת Validity (חסום), עקיפת Audit (חסום).
3.להריץ מטריצת Freeze: BUY חסום, SELL/Reduction/Exit מתאפשר, Stop Loss/Take Profit פעילים, הפעלה מיידית, ביטול דורש re-auth + סיבה.
4.להריץ מטריצת חירום: Emergency Liquidation עם BreakGlassEvent, אישור נפרד, Audit מלא.
5.להריץ מטריצת Re-auth: מעבר ל-full_auto (דורש), ביטול Freeze (דורש), הפעלת Freeze (מיידי), מעבר manual↔semi (Audit בלבד).
6.להריץ מטריצת ספים: confidence >= 8.5 (auto-exec), confidence >= 9.5 (semi מיידי), confidence < 9.5 (hard_semi קירור).
7.להריץ מטריצת אישורים: pending→approved→executed, pending→rejected, pending→expired, approved→expired (אין הארכה אוטומטית).
8.להשוות CIO Shadow לתוצאה הפעילה בלי לשנות Trade.
9.להפיק דוח ביצוע מסכם: גרסאות, קבצים ששונו, תוצאות, חריגות, Rollback והמלצת סגירה.
10.לסמן במפורש ש-Live-Go נשאר חסום עד אישור Go-Live נפרד ואימות ברוקר אמיתי.

קריטריוני קבלה (10)

כל בדיקות T7.1–T7.3 עברו; אין P0/P1 פתוח של CH7.
אין עקיפת Risk Gate, TTL, Validity או Audit בשום מסלול (כולל legacy:true).
Global Freeze חוסם BUY חדש ואינו חוסם SELL/Reduction/Exit/Protection.
Emergency Liquidation דורש BreakGlassEvent עם אישור ו-Audit נפרד.
Re-auth נדרש רק ב-3 מקרים: מעבר ל-full_auto, ביטול Freeze, שינוי הרשאות מהותי.
ספי 8.5 ו-9.5 מאומתים מול SystemSettings והקוד; hard_semi מוגדר כפרופיל משנה.
אין רגרסיה ב-CH1 20/20, CH3 31/31, CH4 29/29, CH5 45/45, CH6 105/105.
Audit מאפשר שחזור של מחזור מלא ללא חיפוש ידני.
Rollback נבדק בפועל ב-Paper.
דוח הסגירה אינו ממליץ על Live-Go; מציין חסמים נפרדים.

בדיקות נדרשות (11)

Smoke: מחזור Paper מלא מסריקה עד ביצוע.Override Matrix: legacy:true + עקיפות חסומות.Freeze Matrix: BUY/SELL/Reduction/Exit + הפעלה/ביטול.Emergency Matrix: BreakGlassEvent + אישור + Audit.Re-auth Matrix: 3 דרישות + 3 פטורים.Threshold Matrix: 8.5/9.5/hard_semi.Approval Lifecycle: pending→approved/rejected/expired.CIO Shadow comparison.Regression CH1–CH6.Audit Reconstruction לפי correlation_id.Rollback בפועל.

תרחישי כשל

P0עקיפת Risk Gate/TTL/Validity/Audit — P0; עצירה ו-Rollback.

P0BUY עובר בזמן Freeze — P0; עצירה מיידית.

P0Emergency Liquidation ללא BreakGlassEvent — P0; עצירה.

P0legacy:true עוקף Gate נוסף — P0; החזרת תיקון.

P1רגרסיה ב-CH1–CH6 — P1; עצירה והחזרה.

חסימהP0/P1 חדש — CH7 נשאר פתוח ואין המלצת סגירה.

Rollback

כיבוי כל Flags של CH7 בסדר הפוך: T7.3, T7.2, ולאחר מכן חזרה ל-Registry/Baseline של T7.1.
שחזור SystemSettings/AgentConfig/PermissionMatrix מן Snapshot המאושר.
הרצת Smoke קצר לאחר Rollback להוכחת תקינות Paper.
שמירת Audit, דוח הכשל והיסטוריית הגרסאות; אין מחיקה כדי להציג PASS.

ראיות (6)

דוח תוצאות מלא עם PASS/FAIL/NOT TESTABLE לכל בדיקה.
פלטי רגרסיה CH1–CH6.
מטריצות Override/Freeze/Emergency/Re-auth/Threshold.
דוח השוואת CIO Shadow.
לוג Rollback ו-Smoke לאחר חזרה.
המלצת סגירה מפורשת: Closed/Remain Open, ללא אישור Live-Go.

תנאי סגירת CH7 (6)

כל T7.1–T7.3 סגורים עם דוחות מאושרים.
אין P0/P1 פתוח של CH7.
רגרסיה CH1–CH6 ללא נסיגה.
כל שמות הקבצים והשדות אומתו מול הקוד (תג "נטען שקיים" הוסר).
ספי 8.5/9.5 ו-hard_semi אומתו ומתועדים.
מסמך CH7 עודכן ל-Version 1.0 רק לאחר הכרעת כל הפערים.

חלק ט׳ — טבלת הבהרת שדות גרסאות ותפוגה

שדה	ישות	תכלית	הערה
version_cas	Decision	מונה אופטימי (CAS) להחלפה אטומית של Decision (DRAFT→ACTIVE, supersede). מונע כתיבה כפולה.	נטען שקיים — לאימות ב-T7.1
decision_version	Decision	מספר גרסה של Decision בתוך משפחה (decision_family_id). כל supersede מעלה ב-1.	נטען שקיים — לאימות ב-T7.1
expires_at	Decision	תוקף החלטה (Decision TTL). מחושב מ-data_as_of + SystemSettings.decision_ttl_hours.	נטען שקיים — לאימות ב-T7.1
proposal_expires_at	Trade	תוקף Proposal ל-Trade במצב pending. מתוך SystemSettings.proposal_ttl_hours.	נטען שקיים — לאימות ב-T7.1
approval_expires_at	Trade	תוקף אישור ל-Trade במצב approved/wait. מתוך SystemSettings.approval_ttl_hours.	נטען שקיים — לאימות ב-T7.1

מסקנה: 5 שדות נפרדים על 2 ישויות (Decision + Trade). אינם שמות חלופיים.

חלק י׳ — §7.18: 6 שאלות Review פתוחות (הסעיף החסר)

האם בשלב הנוכחי נדרש להציג בממשק תפקידים נפרדים, או די ברישום תפקידים לוגיים מאחורי הקלעים?

תשובה: די ברישום תפקידים לוגיים מאחורי הקלעים. המערכת היא Single User — אותו אדם נושא את כל התפקידים הלוגיים. הצגת תפקידים נפרדים ב-UI תיצור עומס מיותר ללא ערך עסקי. הרישום הלוגי (AuditEvent.actor, PermissionMatrix) מספיק לביקורת ולעתיד SaaS.

המלצה: לאמץ: רישום לוגי בלבד. לדחות הצגת תפקידים ב-UI לשלב SaaS מוכח.

האם שינוי automation_mode דורש אישור מחדש/אימות נוסף בכל פעם, או רק במעבר ל-full_auto?

תשובה: רק במעבר ל-full_auto (ובביטול Freeze ושינוי הרשאות מהותי — ראה חלק ה׳). מעבר manual↔semi_auto הוא שינוי תפעולי שגרתי — Audit בלבד. מעבר מ-full_auto למצב אחר (הקטנת סיכון) — Audit בלבד.

המלצה: לאמץ את הכלל המאוחד בחלק ה׳. לא להשאיר סתירה בין §7.7 ו-§7.12.

האם ביטול Global Freeze מחייב הזנת סיבה והמתנה קצרה, או סיבה בלבד?

תשובה: סיבה + אימות מחדש (re-auth), ללא המתנה. המתנה קצרה (cooldown) תיצור עיכוב מיותר בפעולות הגנה דחופות. הסיבה נרשמת ב-Audit עם זהות וזמן. כל הצעה שנצברה עוברת Revalidation מלאה (TTL + Validity) לפני ביצוע — זהו השער האמיתי. הפעלת Freeze נשארת מיידית (ללא re-auth).

המלצה: לאמץ: סיבה + re-auth + זהות + זמן ב-Audit. ללא המתנה. Revalidation של הצעות נצברות הוא השער.

האם פעולות SELL/Reduction/Exit ב-full_auto ממשיכות לפי מדיניות ההגנה ללא אישור אנושי נוסף?

תשובה: כן. פעולות הקטנת חשיפה (SELL/Reduction/Exit/Stop) הן פעולות הגנה P0 ואינן דורשות אישור אנושי נוסף ב-full_auto. הן מבוצעות לפי מדיניות ההגנה (Stop Loss, Take Profit, Trailing) שאושרה ברמת המערכת. עיכובן באישור אנושי יסכן הון.

המלצה: לאמץ: SELL/Reduction/Exit ב-full_auto = ללא אישור אנושי נוסף. עיקרון P0.

האם נדרש Reviewer לקריאה בלבד כבר בגרסת Paper, או לדחות זאת לשלב SaaS?

תשובה: לדחות לשלב SaaS. בגרסת Paper עם Single User, תפקיד Reviewer לקריאה בלבד אינו מוסיף ערך — המשתמש היחיד הוא גם הבעלים, המפעיל והמבקר. AuditEvent עם hash chain מאפשר סקירה לאחור מלאה ללא תפקיד נפרד. Auditor נשמר כרכיב לוגי ב-PermissionMatrix, אך לא כמשתמש נפרד ב-Paper.

המלצה: לדחות ל-SaaS. לשמר Auditor כתפקיד לוגי ב-PermissionMatrix.

האם ארבע משימות היישום T7.1–T7.4 משקפות נכון את סדר העבודה הרצוי?

תשובה: כן, הסדר נכון ותואם את דפוס CH6. T7.1 (מיפוי As-Is + אימות שמות קבצים/שדות) → T7.2 (חוזה אחיד + Re-auth) → T7.3 (Override/Freeze/חירום) → T7.4 (בדיקות E2E וסגירה). כעת, לאחר הרחבת T7.4 למפרט מלא, כל המשימות עקביות ברמת הפירוט.

המלצה: לאמץ את סדר T7.1→T7.2→T7.3→T7.4. להוסיף תלות מפורשת: T7.2 חסום עד T7.1; T7.3 חסום עד T7.2; T7.4 חסום עד T7.3.

חלק י"א — 7 עקרונות מוצעים לנעילה (§7.17) — מעודכן

מודל Single User עם תפקידים לוגיים; אין RBAC מורכב ללא צורך יישומי מוכח.

מתקיים

מצב בקוד: Single User. PermissionMatrix מגדירה רכיבים לוגיים. נטען שקיים — לאימות ב-T7.1.