============================================================ ALGO - DOCUMENT HEADER ------------------------------------------------------------ Doc ID : B8 Title : EA Generation - Master Specs Filename : B8 - EA Generation - Master Specs - V03.txt Version : V18 Updated : 2026-04-25 16:35 (Europe/Rome) Status : ACTIVE (CANONICAL / AI-READY) Scope : SINGLE-SOURCE DOCUMENT FOR AI-DRIVEN EA GENERATION Changelog : - V18: formalizzato che i setup che dipendono da anchor/occurrences selezionate devono emettere `logic_occurrences`; chiarito il collegamento tra occurrence, trade.id e trade_seq. - V17: formalizzato che, quando un evento logico mantiene il proprio timestamp di certificazione sul tf logico ma richiede anche un anchor runtime distinto, la AI deve esporre tale anchor in `event.meta` in modo esplicito. - V16: resa obbligatoria nella scheda pre-registrazione una tabella riassuntiva canonica in Markdown; quando il Markdown non e' abbastanza leggibile, va prodotta anche una versione `.txt` monospaziata human-readable coerente con la stessa semantica. - V15: resa obbligatoria la scheda EA pre-registrazione con onset_dt/cert_dt e preset di stato visuale per Conditions/Pattern/Entry/Exit. - V14: introdotta l'istruzione alla AI di utilizzare nativamente il "Linear Pointer Engine" (O(N+M)) per il mapping logico->EXEC in tutti i nuovi EA, mantenendo la conformità semantica col Full Scan. - V13: vietato generare mapping logical->EXEC con exact-match dell'anchor; la AI deve usare latest EXEC close anchor <= logical close anchor e il CORE puo' rifiutare output/script non conformi. - V12: formalizzato che se il logical close anchor precede il primo close disponibile del dataset EXEC caricato nel run, la AI deve trattarlo come bootstrap/range truncation e saltare il segnale. - V11: chiarito esplicitamente che su dataset BAR_START la AI non puo' usare il `dt` grezzo della barra logica come close anchor per `cert_dt` o per il mapping verso EXEC. - V10: formalizzato che le strategie multi-underlying devono essere modellate con pattern_context separati per simbolo; vietato comprimere conferme esterne in colonne extra del dataframe principale. - V09: formalizzato che il PATTERN_REGISTRY deve essere staticamente consumabile dagli strumenti ALGO; ammessi riferimenti a costanti top-level staticamente risolvibili, vietata costruzione dinamica. ============================================================ B8 - EA Generation - Master Specs Versione: V18 Status : ACTIVE (CANONICAL) ... ============================================================ 9) DEFAULT CANONICI DI TRADUZIONE STRATEGICA ============================================================ Se il brief non specifica diversamente, la AI DEV deve usare questi default: ... - MRE e Performance: - MRE indica il minimo EXEC ammesso. - Per garantire scalabilita' su timeframe intraday (H4, H1, etc.), la AI deve implementare il mapping logico->EXEC utilizzando il "Linear Pointer Engine" (complessita' O(N+M)) come mostrato nel template B5. - L'uso di scansioni complete (Full Scan O(N*M)) e' sconsigliato per la produzione operativa. - Il mapping deve rispettare la regola: "latest EXEC close anchor <= logical close anchor". - La AI non deve mai usare exact-match dell'anchor logico. - Se il dataset logico e' etichettato `BAR_START`, la AI deve prima derivare il close anchor canonico. - Se il logical close anchor cade prima del primo close disponibile nel dataset EXEC, la AI deve saltare il segnale (bootstrap/truncation). - Scheda canonica pre-registrazione: - Prima di proporre la registrazione ufficiale di un nuovo EA, la AI deve produrre una scheda completa per ogni `Condition`, `Pattern`, `Entry` ed `Exit`. - Per ogni entita' la scheda deve dichiarare almeno: `significato operativo`, `onset_dt`, `cert_dt`, `onset_tf`, `cert_tf`, `preset di stato visuale logic-indicator`. - La scheda deve contenere obbligatoriamente una tabella riassuntiva canonica in Markdown che permetta di confrontare in modo rapido tutte le entita' principali. - La tabella riassuntiva deve distinguere chiaramente almeno: `entita'`, `categoria`, `significato operativo`, `tf logico reale`, `tf payload runtime corrente`, `motivo di eventuali differenze`, `riferimenti semantici salvati nei meta` se presenti, `preset di stato visuale`. - Se la tabella Markdown risulta poco leggibile per numero di colonne o lunghezza del testo, la AI deve produrre anche una copia `.txt` monospaziata, ottimizzata per l'occhio umano, semanticamente coerente con la versione Markdown. - Nel payload runtime corrente, `start_dt` equivale semanticamente a `onset_dt`. - Se `start_dt/cert_dt` restano sul tf logico ma la piattaforma richiede anche un anchor operativo distinto, la AI deve esporre quell'anchor in `event.meta` con nomi espliciti e auditabili, per esempio `runtime_anchor_dt`, `runtime_anchor_price`, `logical_bar_start_dt`. - Se la leggibilita' del setup dipende dal distinguere occorrenze concrete della stessa entita' astratta, la AI deve emettere anche il blocco `logic_occurrences`. - `logic_occurrences` deve modellare almeno: `occurrence_id`, `entity_id`, `entity_type`, label corte/lunghe, ruolo semantico, stato lifecycle, dipendenze da altre occorrenze e collegamento ai trade. - La AI non deve hardcodare il modello su nomi strategy-specific come `SL1/SL2`: deve usare un lessico generalizzabile di occurrence, anchor, confirmation, gate, selected, superseded, invalidated. - Se l'utente deve poter capire quale occorrenza ha generato il trade mostrato nella colonna `#`, la AI deve prevedere il collegamento esplicito tra occurrence e trade tramite `trade.id` nel payload e `trade_seq` quando tale identita' umana e' disponibile lato persistenza/UI. - Il preset di stato visuale deve essere scelto tra: - `event_only` - `until_cert` - `until_entry` - `until_exit` - `while_setup_active` - `while_position_open` - `sticky_historical` - `custom_rule` - Se il caso richiede `custom_rule`, la AI deve descrivere esplicitamente la regola di spegnimento (`becomes empty when ...`). ... (resto del file invariato)