Pilot Acceptance Test Plan v0.11
תוכנית בדיקות קבלה לפיילוט — M0 עד M3. הופך את הדרישות שאושרו בארבעת מסמכי התכנון הקודמים לסט בדיקות קבלה מדיד, חוזר ובר-ביקורת עבור Pre-M0, M0, M1, M2 ו-M3.
1. מטרת המסמך
זהו מסמך התכנון החמישי והאחרון בחבילת Planning-to-Pilot. מטרתו להפוך את הדרישות שכבר אושרו לסט בדיקות קבלה מדיד, חוזר ובר-ביקורת עבור Pre-M0, M0, M1, M2 ו-M3.
2. בסיס מחייב
| מסמך | סטטוס | מה נבדק ממנו |
|---|---|---|
| Target Architecture v0.2 | מאושר | גבולות Control Plane/User Runtime, authority, versioning, rollback |
| Migration Plan v0.2 | מאושר | PASS M0-M3, Shadow First, Quality Baseline |
| Local Engine Pilot Specification v0.31 | מאושר | M1 components, reliability, security, operability, Pre-M0 |
| Canonical Event Schema v0.11 | מאושר | Envelope, event types, validation, ACK, 256KB, idempotency |
| Trigger Engine Specification v0.11 | מאושר | Lifecycle, evaluators, persistence, suppression, Shadow |
| Heartbeat/Freshness Policy v0.11 | מאושר | Health states, Watchdog, freshness, recovery, per-engine isolation |
אין במסמך זה להוסיף סמכות חדשה. אם בדיקה דורשת behavior שאינו נתמך במסמכים המאושרים, היא מסומנת New Requirement ומוחזרת לאישור לפני ביצוע.
3. עקרונות קבלה
- PASS מבוסס evidence, לא התרשמות.
- כל test case מתועד עם build/version, config_version, policy_version, timestamp ותוצאה.
- Critical test שנכשל חוסם Gate; אין "PASS with known critical failure".
- בדיקה שנחסמה עקב Missing Evidence מסומנת BLOCKED/MISSING EVIDENCE ולא PASS.
- אין שינוי threshold במהלך run כדי לגרום לבדיקה לעבור.
- Shadow results אינם משנים Candidate/Decision/Trade/Risk/Execution.
- Quality קודמת ל-Cost; חריגת cost נמדדת אך אינה מצדיקה ירידת quality/safety.
- כל retry/re-run מתועד; אין מחיקת run שנכשל.
4. סטטוסי Test Case
| סטטוס | משמעות |
|---|---|
| PASS | כל תנאי הקבלה התקיימו והראיות נשמרו. |
| FAIL | תנאי קבלה אחד או יותר לא התקיימו. |
| BLOCKED | לא ניתן לבצע בגלל dependency/סביבה; אינו PASS. |
| MISSING EVIDENCE | הבדיקה/השוואה דורשת evidence היסטורי שאינו זמין. |
| NOT APPLICABLE | רק אם scope מאושר אינו כולל את הבדיקה; דורש נימוק. |
5. Severity & Gate Rules
| Severity | דוגמה | Gate |
|---|---|---|
| CRITICAL | Authority breach, secret exposure, false LIVE, unexplained event loss, duplicate trading side effect | FAIL מיידי; Gate חסום |
| HIGH | Schema/idempotency/recovery/freshness failure, duplicate trigger, persistent state failure | Gate חסום עד תיקון ו-retest |
| MEDIUM | Metric/diagnostic/operability defect ללא safety impact | נדרש תיקון או waiver מפורש לפני Gate |
| LOW | תיעוד/UX לא קריטי | יכול להיסגר ב-action item אם Gate owner מאשר |
6. סביבת הפיילוט
| OS | Windows 10/11 בהתאם ל-v0.31; לפחות סביבת Pilot מאושרת אחת מכל גרסה שנבחרה לבדיקה. |
| Hosting | Windows Service |
| UI | Base44 דרך Chrome/Edge |
| Local Store | SQLite או equivalent מאושר |
| Mode | M2-M3 SHADOW בלבד |
| User scope | משתמש יחיד בפיילוט הראשוני; state מבודד per engine_id |
| AI/Broker | מחוץ ל-M1-M3 |
| Time | UTC; clock synchronization פעיל |
| Evidence | logs, event records, metrics snapshots, screenshots/exports לפי צורך |
7. ספים מספריים שננעלים ב-v0.1
| מדד | סף קבלה לפיילוט | מקור/היגיון |
|---|---|---|
| stale_after | 15 דקות | Default מאושר ב-v0.31/v0.11 Health; configurable/versioned |
| offline_after | 60 דקות | Default מאושר ב-v0.31/v0.11 Health; configurable/versioned |
| heartbeat_interval | 5 דקות | Candidate numeric lock: 3 heartbeat opportunities לפני STALE; quality-first |
| clock_skew | ≤ 5 שניות | Planning target קיים; ננעל כ-PASS threshold לפיילוט |
| serialized event size | ≤ 256KB | Canonical Event Schema v0.11 |
| M2 asset coverage | ≥ 99% | Migration Plan v0.2 PASS M2 |
| unexplained event loss | 0 | zero unexplained event loss principle |
| duplicate canonical side effect | 0 | Idempotency requirement |
| duplicate trigger fire | 0 | PASS M3 |
| authority side effects M1-M3 | 0 | גבול סמכות מחייב |
| unknown/hardcoded operational threshold | 0 | Policy governance |
| heartbeat scheduler tolerance | ≤ 1 דקה (≤20% מ-5 דקות) | New Numeric Lock; אינו דוחה stale_after/offline_after |
8. Pre-M0 — Baseline Preservation Tests
| ID | בדיקה | PASS |
|---|---|---|
| PRE-01 | איתור 10 ימי המסחר ההיסטוריים | מקור, תאריכים ו-schema מתועדים; אם חסר → MISSING EVIDENCE מפורש |
| PRE-02 | Immutable snapshot | snapshot/export נשמר ללא ניקוי/נרמול/שינוי |
| PRE-03 | Integrity record | filename/path + date + version/hash או equivalent נשמרים |
| PRE-04 | Read-back | ניתן לקרוא את snapshot ולשחזר את מבנה הנתונים |
| PRE-05 | Source preservation | המקור המקורי לא שונה במהלך השימור |
Missing Evidence אינו חוסם אוטומטית את הפיילוט, אך השפעתו על Quality Baseline חייבת להיות מתועדת ומאושרת לפני PASS M0.
9. M0 — Baseline & Freeze Acceptance
| ID | מדד/בדיקה | PASS |
|---|---|---|
| M0-01 | Freeze | אין שינוי Base44/Local Engine במהלך baseline collection ללא change approval |
| M0-02 | Credit/Call baseline | LLM calls, Base44 calls/credits ככל שניתן למדוד באופן מאומת, ותדירויות מתועדים |
| M0-03 | Discovery baseline | נמדד על 10 ימי המסחר שנשמרו ב-PRE-01. אם PRE-01=MISSING EVIDENCE, גם M0-03 יורש MISSING EVIDENCE. אין baseline על פחות מ-10 ימים ללא תיעוד השפעה ואישור. |
| M0-04 | False positive baseline | שיעור/ספירה נמדדים כאשר קיימת ground truth מוסכמת; אחרת limitation מתועדת |
| M0-05 | Intraday coverage | כיסוי חלונות intraday מתועד |
| M0-06 | Quiet-market coverage | כיסוי שוק שקט/slow trend מתועד |
| M0-07 | Protection baseline | תדירות/איכות protection analysis מתועדת |
| M0-08 | Operational baseline | latency, uptime/freshness, alerts/anomalies ידועים מתועדים |
| M0-09 | Dependencies | כל dependency שחייב להשתנות בפיילוט ממופה |
PASS M0 = נקודת ייחוס תפעולית ועלות מתועדת + Quality Baseline מדיד ככל שה-evidence מאפשר + dependencies ידועים. אין להמציא baseline במקום נתון חסר.
10. M1 — Service & Operability Tests
| ID | תרחיש | PASS |
|---|---|---|
| M1-S01 | Install + start | Service מותקן ועולה ללא פעולה ידנית חריגה |
| M1-S02 | Windows reboot | לאחר reboot השירות עולה אוטומטית ומתחיל RECOVERING |
| M1-S03 | Recovery to LIVE | LIVE רק לאחר R1-R8 הרלוונטיים ו-health samples לפי policy |
| M1-S04 | Stop/start | עצירה/הפעלה מתועדות; אין backdated heartbeat |
| M1-S05 | Version visibility | engine_version/build מוצגים ונרשמים |
| M1-S06 | Update/rollback dry run | חזרה לגרסה קודמת אפשרית ומלווה health check |
| M1-S07 | Diagnostics export | logs/metrics ניתנים לייצוא ללא secrets |
| M1-S08 | M1 no-trading-impact audit | Audit diff של Candidate/Decision/Trade/Risk/Execution לפני ואחרי הפעלת M1: 0 שינויים attributable ל-Local Engine. כל שינוי כזה = CRITICAL FAIL. |
11. M1 — Canonical Event Contract Tests
| ID | תרחיש | PASS |
|---|---|---|
| M1-E01 | Valid health event | ACCEPTED; כל required fields ו-cross-validation תקינים |
| M1-E02 | Missing required field | REJECT_SCHEMA; אינו reliable liveness evidence |
| M1-E03 | status/payload mismatch | REJECT_SCHEMA |
| M1-E04 | Unsupported major version | REJECT_VERSION |
| M1-E05 | Duplicate idempotency_key | ACK_DUPLICATE; 0 duplicate side effects |
| M1-E06 | retryable=false rejection | אותו event אינו נשלח שוב ללא שינוי; תיקון יוצר event_id חדש |
| M1-E07 | Event >256KB | REJECT_SIZE |
| M1-E08 | Secret in payload | REJECT_SECURITY; secret אינו מופיע ב-log/audit |
| M1-E09 | config_synced | versions/digest מתועדים; אין plaintext secret |
| M1-E10 | metrics_snapshot | counters עקביים לפי v0.11 |
| M1-E11 | policy_version mismatch trigger_fired | REJECT_SCHEMA |
12. M1 — Queue, Retry & Persistence
| ID | תרחיש | PASS |
|---|---|---|
| M1-Q01 | Base44 unavailable | events נשמרים durable queue; unexplained loss=0 |
| M1-Q02 | Reconnect | queued events נשלחים עם idempotency תקין; duplicates side effects=0 |
| M1-Q03 | Restart with queue | queue שורדת restart וממשיכה recovery |
| M1-Q04 | Disk full | DEGRADED/HOLD; אין silent loss; warning/audit |
| M1-Q05 | Corrupt local state | אין המשך שקט; DEGRADED/HOLD + diagnostics |
| M1-Q06 | Retry/backoff | אין busy-loop/event storm; retries נמדדים |
13. M1 — Security Tests
| ID | תרחיש | PASS |
|---|---|---|
| M1-SEC01 | Credential storage | Engine Identity secret נשמר OS-secure ולא plaintext config |
| M1-SEC02 | Log inspection | 0 secrets/tokens/passwords ב-logs/events |
| M1-SEC03 | Outbound-only | אין inbound network port חיצוני שנפתח על ידי הפיילוט |
| M1-SEC04 | TLS | Control Plane communication מוצפנת בהתאם ל-contract |
| M1-SEC05 | Engine isolation | נבדק באמצעות synthetic second engine_id / isolated test fixture ללא multi-user rollout, ובנוסף code/config inspection; state/watchdog/metrics אינם חוצים engine_id. |
14. M1 — Heartbeat / Watchdog / Health Tests
| ID | תרחיש | PASS |
|---|---|---|
| M1-H01 | Heartbeat cadence | 5 דקות עם scheduler tolerance של עד 1 דקה; אין interval/tolerance hardcoded; tolerance אינו דוחה STALE/OFFLINE. |
| M1-H02 | Fresh heartbeats | Control Plane מציג LIVE רק לאחר recovery PASS |
| M1-H03 | No heartbeat >15m | state אינו LIVE; STALE לכל המאוחר בסף policy. אינו מופעל לפני stale_after (false STALE = HIGH FAIL). |
| M1-H04 | No heartbeat >60m | OFFLINE לכל המאוחר בסף policy. אינו מופעל לפני offline_after. |
| M1-H05 | DEGRADED then crash | DEGRADED מזדקן ל-STALE/OFFLINE לפי evidence age |
| M1-H06 | Invalid heartbeat | נדחה ואינו מאפס evidence age |
| M1-H07 | Engine self-reports LIVE but stale | Watchdog state המחמיר גובר |
| M1-H08 | Return from STALE/OFFLINE | RECOVERING לפני LIVE |
| M1-H09 | Clock skew >5s | אין LIVE ל-capability time-sensitive; DEGRADED/HOLD לפי policy |
| M1-H10 | Policy change re-verification | בעת policy update ב-LIVE: re-verification לפני המשך LIVE |
Tolerance לתזמון heartbeat נועד לשונות scheduler/transport בלבד ואינו רשאי לדחות את stale_after/offline_after.
15. M1 — Metrics & Cost Measurement
PASS M1 לפי Migration Plan: service עולה אחרי reboot, heartbeat נכון, schema נבדק, queue/idempotency עובדים, ו-Base44 מציג Engine state ללא השפעה על מסחר.
16-17. M2 — Market Data, Local Monitoring & Drift
PASS M2: coverage ≥99%, freshness תקין, אין duplicate events, ואין drift לא מוסבר מול מקור הייחוס.
Drift & Reference Evidence
Drift אינו מקבל threshold שרירותי במסמך זה משום שסוגי data/provider טרם ננעלו. PASS דורש שכל mismatch יהיה מוסבר ומסווג: timestamp difference, provider convention, rounding, corporate action, market state או defect. mismatch בלתי מוסבר אחד ברכיב קריטי = FAIL עד חקירה.
De minimis handling: אין review ידני לכל הפרש זעיר. לפני run, לכל source/data type מותר להגדיר tolerance/classification rule מספרי ומאושר (למשל rounding precision) על בסיס semantics של המקור — לא על בסיס תוצאות ה-run. mismatch בתוך tolerance מסווג אוטומטית כ-EXPLAINED_BY_TOLERANCE ונמדד; mismatch מחוץ לו דורש הסבר/חקירה. אין לקבוע tolerance כללי של 0.01% במסמך זה ללא provider/data-type basis.
18-19. M3 — Trigger Engine Functional & Suppression/Storm Tests
PASS M3 לפי Migration Plan: אין trigger storm, אין ירי כפול לאותו אירוע, שינוי policy אינו דורש שינוי קוד, וכל trigger ניתן להסבר ולשחזור.
20. Quality Comparison — M2/M3 Shadow
מאחר שהמסמכים המאושרים אינם מספקים threshold מספרי אחיד ל-false-positive/false-negative או latency, המסמך אינו ממציא מספר. לפני run שבו נדרש Gate מספרי, היעד ייגזר מ-M0 Quality Baseline ויינעל מראש ב-Test Run Sheet.
21. Authority Boundary Test
זהו test קריטי וחוצה M1-M3. יש לבצע code/config diff + audit evidence ולהוכיח:
- ✗אין route חדש שיוצר/מאשר/מבצע Trade.
- ✗אין שינוי Risk Gate.
- ✗אין שינוי CIO/Decision state.
- ✗אין שינוי Candidate production ב-M2/M3.
- ✗trigger_fired נשאר observation/event בלבד.
- ✗אין Broker/AI integration ב-M1-M3.
- ✗Base44 נשאר System of Record.
22-24. Failure Injection Matrix, Evidence Package & Gate Decision Rules
Failure Injection Matrix (§22): רשימת תרחישי כשל מלאה ל-M1-M3 (Base44 unavailable, disk full, corrupt state, clock skew, secret exposure, duplicate event, trigger storm ועוד) — כפי שמשתקף ב-test cases המפורטים בסעיפים 10-14.
Evidence Package לכל Gate (§23): כל test case מתועד עם build/version, config_version, policy_version, timestamp ותוצאה. ראיות נשמרות לביקורת ולשחזור PASS/FAIL.
Gate Decision Rules (§24): Regression של Gate קודם מבטל את ההנחה שהוא עדיין PASS עד retest. אין "ירושה אוטומטית" של PASS לאחר שינוי build/config/policy מהותי.
25. Stop / Rollback Conditions בפיילוט M1-M3
- ■Authority breach או side effect מסחרי לא מאושר.
- ■Secret exposure.
- ■False LIVE שמסתיר absence-of-heartbeat מעבר לסף.
- ■Unexplained event loss.
- ■Duplicate side effect קנוני או duplicate trigger fire שאינו מוסבר.
- ■Persistent state corruption שאינה מאפשרת dedup/cooldown/recovery.
- ■Schema/version incompatibility שאינה ניתנת ל-fail-closed.
- ■כל failure שמסכן evidence integrity.
ב-M1-M3 rollback פירושו חזרה למצב הקודם/השבתת capability המקומית; אין העברת workload מסחרי. Automatic Rollback של M8 אינו מופעל בשלב זה.
26. Cost/Credit — Acceptance Scope
ב-M1-M3 העלות נמדדת אך אינה Gate של quality replacement. base44_credit_units מתקבל רק ממקור שאומת מול Dashboard/מקור חשבונאי מאושר; אחרת הוא null.base44_calls_count נשמר בכל מקרה.
יעד ≥80% הפחתת Base44 InvokeLLM שייך ל-M4 ואינו תנאי PASS של M1-M3. הכנסת היעד למסמך זה כ-PASS הייתה סותרת את ה-scope המאושר.
27. Test Run Sheet — תבנית
תבנית רשמית לתיעוד כל run: ID, build/version, config_version, policy_version, timestamp, תוצאה, ראיות, ובמקרה של FAIL/BLOCKED — סיבה ופעולה. יעדים מספריים שנגזרים מ-M0 Baseline (false-positive/false-negative, latency) ננעלים ב-Test Run Sheet לפני run — אין לקבוע tolerance לאחר ראיית התוצאה.
28. Derivation Trace
New Numeric Lock המובא לאישור ב-v0.1: heartbeat_interval = 5 דקות ו-heartbeat scheduler tolerance ≤1 דקה (≤20%). שאר הספים המספריים במסמך מגיעים ממסמכים מאושרים: STALE 15 דקות, OFFLINE 60 דקות, clock skew 5 שניות, event size 256KB, M2 coverage ≥99%, ו-zero unexplained loss/duplicates/authority side effects.
29. שאלות לצוות לפני G-TEST
- האם heartbeat_interval של 5 דקות ו-scheduler tolerance מקסימלי של 1 דקה הם האיזון הנכון לפיילוט מול stale_after=15 דקות ועלות Base44?
- האם clock skew ≤5 שניות ננעל כ-PASS threshold לפיילוט?
- האם unexplained event loss=0 ו-duplicate trigger fire=0 צריכים להישאר absolute gates כפי שמוצע?
- האם M1-H03/M1-H04 צריכים לדרוש transition בדיוק בסף או לכל המאוחר בסף + scheduler tolerance מתועד?
- האם M2 drift צריך להישאר source-specific ולהינעל לפני run, ולא לקבל מספר כללי עכשיו?
- האם false-positive/false-negative ו-latency targets נכון שייגזרו מ-M0 baseline ויינעלו ב-Test Run Sheet לפני run?
- האם כל CRITICAL/HIGH failure חוסם Gate ללא waiver?
- האם רשימת Failure Injection מלאה ל-M1-M3?
- האם Evidence Package מספיק לביקורת ולשחזור PASS/FAIL?
- האם יש blocker שמונע נעילת חבילת חמשת המסמכים לאחר תיקון/אישור v0.1?
30. Gate G-TEST והחלטה מוצעת
לאשר את InvestIQ Pilot Acceptance Test Plan v0.11 כתוכנית הקבלה המחייבת ל-Pre-M0 ול-M0-M3, בכפוף להערות הצוות ולנעילת G-TEST.
אישור G-TEST סוגר את חבילת חמשת מסמכי התכנון. הוא עדיין אינו אישור לבצע שינוי מערכת. הצעד הבא הוא Pre-M0 Baseline Preservation בהתאם ל-Work Order, ולאחריו M0 ורק לאחר PASS M0 + אישור מפורש — M1.
InvestIQ Pilot Acceptance Test Plan v0.11 | Candidate for Approval | 9 בספטמבר 2026. מסמך 5 מתוך 5 בחבילת Planning-to-Pilot.