InvestIQ — Local Engine Pilot Specification

מפרט פיילוט נגזר מארכיטקטורת היעד ומתוכנית המעבר המאושרות

Local Engine Pilot Specification

גרסה: v0.31תאריך: 9 בספטמבר 2026סטטוס: Candidate for Approval

מפרט לתכנון ואישור — ללא הרשאת קוד, הרצה או שינוי במערכת. v0.31 נגזר מ-Target Architecture v0.2, Migration Plan v0.2 ו-Planning-to-Pilot Work Order v1.0. אישור v0.31 אינו אישור להתחיל קוד — הפעולה הבאה היא כתיבת Canonical Event Schema v0.1.

1. מטרת המסמך

מסמך זה מגדיר את גבולות הפיילוט של InvestIQ Local Engine ואת דרישותיו ברמת המפרט. v0.3 נגזר מ-Target Architecture v0.2, Migration Plan v0.2 ומסמך Planning-to-Pilot Work Order v1.0.

מטרת הפיילוט אינה להעביר את מערכת המסחר כולה למחשב המשתמש. מטרתו להוכיח באופן מבוקר שה-Local Engine יכול לשמש User Runtime אמין לעבודה תכופה, תוך שמירת Base44 כ-Control Plane וכ-System of Record בשלב זה.

2. Out-of-Scope — גבולות שאסור לחרוג מהם

סעיף זה מחייב. כל הרחבה מעבר לו היא Scope Change ודורשת אישור מפורש לפני ביצוע.

• אין שינוי ב-Risk Gate authority.
• אין שינוי ב-Decision/CIO authority.
• אין שינוי ב-Live Execution authority.
• אין Broker integration בשלבי M1-M3.
• אין AI/LLM integration בשלבי M1-M3. Direct AI ייכנס רק ב-M4 ולאחר PASS/Gate מתאים.
• אין multi-user rollout בפיילוט הראשוני.
• אין החלפה או מחיקה של Base44 workflows; Strangler Pattern מחייב ריצה מקבילה/Shadow לפני cutover.
• אין שינוי System of Record; Base44 נשאר המקור הקנוני.
• אין Hosted Engine/VPS production במסגרת הפיילוט הראשוני.
• אין hardcoded operational thresholds במקום שבו הוגדר Policy/Configuration.

3. מסמכי מקור וסמכות

מסמך	סטטוס	סמכות לפיילוט
Target Architecture v0.2	מאושר	Control Plane / Local Engine / AI Adapter / Events / Health / Operability / Cost Governance
Migration Plan v0.2	מאושר	M0-M9, Shadow, PASS/FAIL, rollback, sequencing ו-authority boundaries
Planning-to-Pilot Work Order v1.0	מאושר לתיעוד	סדר המסמכים, Gates, Out-of-Scope, Pre-M0 preservation

4. מטרות הפיילוט

• להוכיח Local Engine יציב על מחשב משתמש כפלטפורמת User Runtime.
• להוכיח תקשורת קנונית, versioned ו-idempotent בין Local Engine ל-Base44.
• להוכיח Heartbeat/Freshness כך ש-Base44 אינו מציג stale data כ-live.
• להוכיח local cache/queue/retry/logging והתאוששות מ-restart/ניתוק.
• להכין תשתית ל-M2/M3: Market Data monitoring ו-Trigger Engine, ללא העברת סמכות מסחרית.
• למדוד reliability, latency, event integrity ו-operability לפני הכנסת AI.
• לשמור מסלול rollback וללא תלות בלתי הפיכה ב-Local Engine.

5. סביבת הפיילוט

רכיב	דרישת פיילוט
Operating System	Windows 10/11 לפיילוט. התלות ב-Windows מוגבלת ל-Service Hosting בלבד; שכבות הליבה — events, queue, configuration, schema, metrics ו-business-neutral runtime — הן platform-agnostic.
Runtime Form	Windows Service — רץ גם ללא Login פעיל
User Interface	Base44 דרך דפדפן כגון Chrome/Edge; אין UI מסחרי נפרד ל-Local Engine
Local Storage	SQLite או equivalent מקומי בהתאם למפרט M1
Central Control	Base44
System of Record	Base44
Network	Outbound-only secure communication; אין inbound network ports. health מקומי, אם יידרש, יבוצע ללא פתיחת port חיצוני ויפורט במפרט המתאים.
Pilot Users	משתמש יחיד בשלב הראשוני

6. ארכיטקטורת הפיילוט

הפיילוט מפריד בין שלוש אחריויות: Base44 מנהל ומציג; Local Engine מנטר ומעבד עבודה תכופה; ספקים חיצוניים יחוברו דרך Adapters בשלבים המתאימים.

• Base44 → configuration/policy מאושרים ופקודות בקרה.
• Local Engine → heartbeat, health, scan summaries, warnings ו-events קנוניים.
• Local Engine → local cache, queue, retry, idempotency ו-logs.
• Market Data Adapter → ייכנס ב-M2 לאחר PASS M1.
• Trigger Engine → ייכנס ב-M3 לאחר Canonical Event Schema מאושר.
• AI Adapter → אינו חלק מ-M1-M3; ייכנס רק ב-M4.
• Broker Adapter → אינו חלק מ-M1-M3; Read-Only/Paper מתוכנן ל-M7.

7. רכיבי M1 — Local Engine Skeleton

רכיב	דרישה	תוצאת מינימום
Windows Service	install/start/stop/restart/auto-start	חזרה תקינה לאחר reboot
Engine Identity	engine_id + user_id + engine_version	זיהוי חד-משמעי ב-Base44
Configuration	versioned config/policy loader	שינוי config ללא שינוי קוד במקום שהוגדר configurable
Event Client	שליחה לפי Canonical Event Schema	schema validation + idempotency
Heartbeat	דיווח מחזורי	LIVE/STALE/DEGRADED/OFFLINE/RECOVERING ניתנים להצגה
Local Store	SQLite/cache	state תפעולי מקומי ללא שינוי System of Record
Queue/Retry	buffer בעת תקלה	אין אובדן/כפילות side effects
Logging	structured logs	diagnostics ללא secrets
Versioning	build/version reporting	גרסה נראית ב-Control Plane
Update/Rollback	מנגנון בסיסי מבוקר	יכולת חזרה לגרסה קודמת
Metrics/Telemetry	counters + timers: events sent, retries, queue depth, heartbeat latency, failures	מדידה כמותית ל-Acceptance Plan
Cost/Credit Counter	count של events/sync calls וצריכת Base44 שניתנת לייחוס ל-Engine	baseline ועלות M1 ניתנים למדידה
Credential Store	Engine Identity credentials באחסון OS-secure; ללא plaintext config/logs	auth פעיל ללא חשיפת secret

8. Canonical Event Contract — תלות מוקדמת

הפיילוט אינו רשאי להמציא payloads נקודתיים. Canonical Event Schema v0.1 ייכתב ויאושר מיד לאחר v0.3 ולפני Trigger Engine ו-Heartbeat/Freshness specifications.

שדות הליבה הצפויים, בכפוף למסמך הסכמה המאושר:

event_id, event_type, schema_version, user_id, engine_id, source, occurred_at, sent_at, correlation_id, idempotency_key, severity, payload, source_data_age, engine_version, status.

source_data_age הוא freshness של מקור הנתון לאירוע; engine freshness הוא מצב מערכתי נפרד ומוגדר ב-Heartbeat/Freshness Policy.

Event types מינימליים צפויים: health, scan_summary, warning, config_synced, metrics_snapshot. event types נוספים יתווספו רק במסמך הסכמה.

9. Heartbeat/Freshness — גבולות הפיילוט

Heartbeat/Freshness Policy v0.1 יגדיר את ההתנהגות המדויקת. v0.3 נועל רק את העקרונות:

• Base44 חייב לדעת מתי Local Engine חי ומתי המידע stale.
• מצבים: LIVE / STALE / DEGRADED / OFFLINE / RECOVERING. DEGRADED מציין Engine פעיל אך לא כשיר במלואו עקב state/data/provider/local-resource problem; הוא אינו sub-state של RECOVERING.
• 15/60 דקות הם Policy Defaults מוצעים בלבד, configurable ולא hardcoded.
• חזרה מניתוק מחייבת health/re-sync לפני הצגת LIVE.
• אין להציג נתון ישן כאילו הוא נתון חי.

10. Trigger Engine — גבולות הפיילוט

Trigger Engine יוגדר במפרט נפרד לאחר אישור Canonical Event Schema. כל trigger יפיק event קנוני ולא Decision/Trade.

• סוגים: market, news, state/risk, operational — לפי scope המאושר בכל milestone.
• priority, debounce, cooldown, dedup ו-rate limit.
• כל threshold הוא configuration/policy versioned ולא hardcoded.
• trigger_id, reason, source, timestamp, policy_version ו-idempotency key.
• Trigger Fired אינו שווה Candidate/Decision/Trade אלא אם milestone מאוחר יותר מגדיר זאת במפורש.

11. Market Data ב-M2

לא נבחר ספק Market Data במסמך זה. הבחירה תיעשה לפי איכות, freshness, רישוי, כיסוי שווקים, יציבות ועלות.

• Local Engine יקבל data דרך Adapter ולא דרך לוגיקה קשיחה לספק.
• נדרשת בדיקת freshness ו-source timestamp.
• ניטור Watchlist ו-deterministic checks יבוצעו ב-Shadow.
• אין Candidate production או שינוי החלטות ב-M2.
• השוואה מול מקור ייחוס מוגדר מראש תתועד. בפיילוט, מקור הייחוס הוא הנתון הקנוני הקיים ב-Base44/מקור הנתונים המאושר שמזין אותו; ספק חיצוני חלופי אינו הופך למקור ייחוס ללא החלטה מפורשת.

12. AI — תיחום ברור

AI אינו חלק משלבי M1-M3 ולכן אינו חלק מביצוע הפיילוט הראשוני. עם זאת, ה-Local Engine מתוכנן כך ש-AI Adapter יוכל להתווסף ב-M4 ללא שינוי ארכיטקטורת הליבה.

• אין InvokeLLM replacement ב-M1-M3.
• אין OpenAI/Gemini/Anthropic integration ב-M1-M3.
• אין local model requirement.
• M4 ידרוש Structured Output, Quality Gate, fallback/HOLD ו-cost metering.
• יעד ≥80% ירידה ב-Base44 InvokeLLM הוא יעד M4/Scaling בלבד ובכפוף לשמירת איכות.

13. Broker — תיחום ברור

אין Broker integration ב-M1-M3. IBKR Read-Only/Paper + Reconciliation הוא milestone מאוחר יותר (M7). אין ב-v0.3 הרשאה לשלוח order, לשנות Trade state או להניח broker acknowledgement.

14. Reliability & Recovery

• Service restart לאחר crash/reboot.
• Queue נשמרת לפי עקרון zero unexplained event loss. כל bounded-loss exception, אם יידרש, יוגדר מספרית רק ב-Acceptance Test Plan.
• Disk-full / storage exhaustion מזוהה ומוביל ל-DEGRADED/HOLD, עם event/alert מתאים; אין המשך שקט.
• Clock synchronization נדרש. המנוע יבדוק clock skew מול מקור זמן אמין; סף הקבלה המספרי יינעל ב-Acceptance Test Plan (יעד תכנון ראשוני: עד 5 שניות).
• Retry מוגבל עם backoff; אין infinite retry storm.
• Idempotency מונעת side effects כפולים.
• Clock/timestamp handling עקבי.
• Corrupt local state מזוהה ומוביל ל-DEGRADED/HOLD, לא להמשך שקט.
• Recovery מתועד ב-log וב-health event.

15. Security

• Secrets מחוץ לקוד ומחוץ ל-logs.
• Engine Identity credentials ב-M1 יישמרו במנגנון מאובטח של מערכת ההפעלה (למשל Windows Credential Manager או equivalent מאושר), ולא בקובץ configuration גלוי.
• engine identity מאומתת.
• per-user isolation כבר בפיילוט גם אם יש משתמש אחד.
• least privilege.
• TLS לתקשורת חיצונית.
• אין credentials ב-event payload.
• יכולת revoke/rotate credentials תוגדר לפני הרחבת משתמשים.

16. Operability

• התקנה והסרה מסודרות.
• Auto-start.
• version/build visibility.
• diagnostics bundle או export לוגים.
• update/rollback מבוקר.
• health check לאחר update.
• תיעוד סביבת OS ו-dependencies.
• הפיילוט אינו דורש מהמשתמש לנהל ידנית תהליך קבוע בכל הפעלה.

17. PASS/FAIL — עקרונות v0.3

המספרים הסופיים יינעלו ב-Pilot Acceptance Test Plan לאחר אישור שלושת המפרטים הנגזרים. v0.3 קובע את קטגוריות הקבלה:

קטגוריה	PASS עקרוני
Service Reliability	עולה לאחר reboot ומתאושש מתקלות מבוקרות
Event Integrity	schema valid; אין duplicate side effects
Heartbeat/Freshness	stale/offline מזוהים ומוצגים נכון
Queue/Retry	אין אובדן בלתי מוסבר; retry נשלט
Security	אין secrets בקוד/logs/events
Versioning	engine/config/schema versions ניתנים למעקב
Rollback	ניתן לחזור לגרסה/מצב קודם ללא פגיעה ב-System of Record
Authority Boundary	אפס שינוי ב-Risk/Decision/Execution authority, מאומת באמצעות code/config diff + audit evidence שאין route חדש לביצוע או שינוי סמכות.

18. Pre-M0 Baseline Preservation

לפני תחילת M0, ולא כחלק מפיתוח Local Engine, יש לוודא שנתוני 10 ימי המסחר ההיסטוריים המשמשים Quality Baseline עדיין קיימים ולהקפיא snapshot בלתי משתנה.

• אימות נגישות לנתוני המקור.
• תיעוד טווח תאריכים ו-schema.
• ייצוא snapshot/archive read-only.
• זיהוי version/hash/filename/date.
• אין תיקון או השלמת נתונים חסרים בהשערה.
• Missing Evidence מתועד במפורש. נתון חסר/פגום אינו מושלם בהשערה ואינו חוסם אוטומטית את הפיילוט; השפעת החוסר על Quality Baseline ועל PASS/FAIL תסומן ותאושר.

19. Derivation Trace

דרישה ב-v0.3	מקור מסמיך
Base44 = Control Plane/System of Record	Target Architecture v0.2
Local Engine = User Runtime	Target Architecture v0.2
Windows Service + operability	Target Architecture v0.2 §Local Engine Operability; Migration M1
Canonical Event Schema	Target Architecture v0.2 §Canonical Event Schema; Migration M1
Heartbeat/Freshness	Target Architecture v0.2 §Heartbeat; Migration M1
Trigger Engine configurable	Target Architecture v0.2 §Trigger Engine; Migration M3
No AI in M1-M3	Migration Plan v0.2 M1-M3 / M4 boundary
Direct AI only after Gate	Migration Plan v0.2 M4 + M4→M5 Decision Gate
No Broker in M1-M3	Migration Plan v0.2; Broker Read-Only/Paper at M7
No authority transfer	Target Architecture v0.2 + Migration Plan v0.2
Shadow/Strangler	Migration Plan v0.2
Pre-M0 baseline preservation	Planning-to-Pilot Work Order v1.0

20. מסמכים נגזרים מ-v0.3

הסדר הוא סדרתי ומחייב: לאחר Event Schema מאושר נכתב Trigger Engine, ורק לאחריו Heartbeat/Freshness. בכך v0.31 מחדד את ה-Work Order; אין מקביליות בין שני המפרטים במסגרת חבילת העבודה הנוכחית.

סדר	מסמך	כלל תלות
1	Canonical Event Schema v0.1	נכתב ראשון ומאושר ראשון
2	Trigger Engine Specification v0.1	רק לאחר Event Schema מאושר
3	Heartbeat/Freshness Policy v0.1	רק לאחר Event Schema מאושר
4	Pilot Acceptance Test Plan v0.1	רק לאחר אישור שלושת המפרטים לעיל

21. שאלות לאישור הצוות

האם Scope ו-Out-of-Scope של v0.3 תואמים במלואם לשני מסמכי היסוד?
האם רכיבי M1 המוגדרים כאן מספיקים לשלד Local Engine, ללא החדרת יכולות מוקדמת?
האם יש dependency טכני קיים ב-Base44 שחייב להיכלל ב-M1?
האם Windows Service הוא runtime נכון לפיילוט על Windows 10/11?
האם Event types המינימליים health/scan_summary/warning מספיקים לפתיחת Canonical Event Schema?
האם חסר failure mode מהותי ב-Reliability/Recovery?
האם יש secret/session dependency שחייב להיכלל כבר ב-M1?
האם יש התנגדות לכך ש-AI ו-Broker נשארים מחוץ ל-M1-M3?
האם Derivation Trace משקף נכון את שרשרת הסמכות?
האם יש blocker לפני כתיבת Canonical Event Schema v0.1?

22. Gate

אישור v0.31 אינו אישור להתחיל קוד.

לאחר אישור v0.3, הפעולה הבאה היא כתיבת Canonical Event Schema v0.1. רק לאחר השלמת ואישור חבילת חמשת המסמכים ו-Gates שנקבעו, מתחילה העבודה המעשית בהתאם ל-Work Order.

23. החלטה מוצעת

לאשר את InvestIQ Local Engine Pilot Specification v0.31 כמפרט הפיילוט המחייב שממנו ייגזרו שלושת המפרטים הטכניים ותוכנית הקבלה.

InvestIQ Local Engine Pilot Specification v0.31 | Candidate for Approval | 9 September 2026