============================================================ ALGO - DOCUMENT HEADER ------------------------------------------------------------ Doc ID : B10 Title : EA Canonical Examples Filename : B10 - EA Canonical Examples - V02.txt Version : V09 Updated : 2026-04-25 16:35 (Europe/Rome) Status : ACTIVE (CANONICAL / EXAMPLES) Scope : WORKED EXAMPLES FOR HUMAN AND EXTERNAL AI DEV Changelog : - V09: aggiunto esempio canonico occurrence-based su doppio swing per chiarire anchor selezionati, provenance e collegamento ai trade. - V08: aggiunto l'esempio canonico di evento logico con `runtime_anchor_dt` distinto dalla certificazione logica e `logical_bar_start_dt` per dataset `BAR_START`. - V07: aggiunto l'esempio canonico della tabella riassuntiva pre-registrazione e la regola pratica Markdown + `.txt` human-readable quando la tabella e' troppo densa. - V06: aggiunto anti-esempio esplicito di mapping logical->EXEC basato su exact-match dell'anchor, vietato dalle canonical e rifiutabile dal CORE. - V05: aggiunto il principio che il prompt universale di B9 fa parte del corpus canonico e non deve restare in istruzioni esterne o temporanee. - V04: aggiunto esempio canonico della struttura obbligatoria di AI_DESCRIPTION con tabelle parametri e ChartTrade Semantics. - V03: aggiunti esempi espliciti su MRE vs EXEC, pattern_symbol runtime-aware, params runtime current-shape e force-exit a fine dati. - V02: aggiunto esempio esplicito di risposta corretta vs risposta sbagliata di una AI DEV esterna. ============================================================ B10 - EA Canonical Examples Versione: V09 Status : ACTIVE (CANONICAL / EXAMPLES) ============================================================ 1) SCOPO ============================================================ Questo documento contiene esempi canonici da imitare. Non sostituisce B2-B9, ma mostra come trasformare una idea discrezionale in un draft tecnico ALGO-compatible. ============================================================ 2) ESEMPIO A - STRATEGIA DAILY SEMPLICE ============================================================ Idea umana: - Compra il close del lunedi' se: - oggi e' lunedi' - close di oggi < close di ieri - close di ieri < close di due barre fa - Esci quando close > high[1] Traduzione corretta: - Pattern: - P1 = Monday two-step selloff reversal - Conditions: - P1C1 = oggi e' lunedi' (tf D) - P1C2 = close < close[1] (tf D) - P1C3 = close[1] < close[2] (tf D) - Entry: - P1E1 = enter long on close (tf EXEC) - Exit: - P1X1 = close > high[1] (tf EXEC come fill, logica daily) - Pattern TF: - D - MRE: - D Note corrette: - il pattern vive su D - il fill puo' vivere su EXEC - MRE = D non obbliga EXEC = D; H1/M15 possono essere leciti se il fill e' ancorato correttamente alla giornata daily - non bisogna inventare D1 - non bisogna trasformare la regola in un indicatore non auditabile ============================================================ 3) ESEMPIO B - COSA NON FARE ============================================================ Errore: - "Se EXEC_TF e' H1 allora ricostruisco io il daily dal dataset H1" Perche' e' sbagliato: - viola DB wins - viola dataset != timeframe - introduce inference implicita - rompe il contratto pattern_contexts Corretto: - il runtime deve passare all'EA il contesto Pattern con il dataset D gia' risolto ============================================================ 3-bis) ESEMPIO B2 - COSA NON FARE SU MRE ============================================================ Errore: - "La strategia ha pattern_tf = D e MRE = D, quindi faccio `if timeframe != 'D': raise ValueError(...)`" Perche' e' sbagliato: - MRE significa minimo EXEC richiesto - non significa che EXEC debba essere identico al tf logico - impedisce inutilmente l'uso di EXEC piu' fini compatibili col runtime Corretto: - accettare EXEC uguale o piu' fine - usare il dataset D del Pattern per la logica - ancorare il fill all'ultimo EXEC bar compatibile con la barra logica del segnale ============================================================ 3-ter) ESEMPIO B3 - COSA NON FARE SUL MAPPING LOGICAL -> EXEC ============================================================ Errore: - `exec_row = exec_by_anchor.get(logical_close_anchor)` - oppure descrivere il fill come "barra EXEC il cui close anchor corrisponde esattamente al logical close anchor" Perche' e' sbagliato: - rompe su EXEC intraday dove il logical close anchor non coincide con nessun close intraday esatto - rompe su sessioni holiday / overnight / close-anchored - e' una semantica fragile che il CORE puo' rifiutare in create/update/run Corretto: - usare il latest EXEC close anchor `<= logical close anchor` - se il logical close anchor cade prima del primo EXEC close disponibile, saltare il segnale come bootstrap/range truncation ============================================================ 4) ESEMPIO C - SEMANTICA VISIVA CHARTTRADE ============================================================ Caso corretto: - Condition strutturale visibile solo se aggiunge valore auditabile - Pattern visibile se aiuta a capire perche' si e' entrati - Entry ed Exit visibili - start_dt/cert_dt distinti solo se il fenomeno lo richiede davvero Caso scorretto: - emettere condizioni di puro calcolo solo per riempire il pane logic - plottare marker su punti non corrispondenti al fenomeno reale ============================================================ 5) ESEMPIO D - AI_DESCRIPTION PROPOSTA ============================================================ Forma buona: - spiega idea strategica - spiega Pattern - spiega Conditions principali - include Detailed Condition Semantics con una scheda per ogni condition_id canonico - spiega entry/exit - spiega eventuale contesto multi-market - include tabella Variables - include tabella Constants - include ChartTrade Semantics con motivazioni - non contiene marketing o testo vago Forma cattiva: - testo generico - assenza di tf logici - assenza di logica entry/exit - assenza di tabella parametri - assenza di semantica ChartTrade - linguaggio non auditabile ============================================================ 5-bis) ESEMPIO E - SHAPE CORRETTA DI AI_DESCRIPTION ============================================================ Forma corretta minima: - `Strategy Overview` - `Pattern Logic` - `Detailed Condition Semantics` - `Variables` - `Constants` - `ChartTrade Semantics` - `Operational Notes` Esempio corretto di tabella Variables: | Variable | Meaning | Effect on strategy | |---|---|---| | ibs_threshold | Maximum allowed IBS for setup readiness. | Lower values make entries rarer and more selective. | Esempio corretto di tabella Constants: | Constant | Meaning | Effect on execution / PnL | |---|---|---| | point_value | Monetary value of one point. | Scales gross PnL and MAE/MFE currency values. | Esempio corretto di ChartTrade Semantics: - Visible events: `P1`, `P1E1`, `P1X1` - Non-visible events: `P1C1`, `P1C2` - Why visible: pattern explains setup; entry/exit explain execution - Anchor: pattern on logical/EXEC mapping agreed in design; fills on EXEC - start/cert: start is the first valid onset, cert is the canonical confirmation ============================================================ 5-ter) ESEMPIO E2 - TABELLA RIASSUNTIVA PRE-REGISTRAZIONE ============================================================ Forma corretta minima della tabella: - deve stare nella scheda principale in Markdown - deve essere leggibile e confrontabile a colpo d'occhio - se il Markdown e' troppo largo o denso, deve esistere anche una copia `.txt` monospaziata per lettura umana Colonne minime consigliate: - `Entita'` - `Categoria` - `Significato operativo` - `TF logico reale` - `TF payload runtime attuale` - `Motivo della differenza` - `Preset` Esempio corretto: | Entita' | Categoria | Significato operativo | TF logico reale | TF payload runtime attuale | Motivo della differenza | Preset | | --- | --- | --- | --- | --- | --- | --- | | `P1C1` | CONDITION | setup filter true | `D` | `EXEC` | event anchored to mapped EXEC close for current runtime compatibility | `until_entry` | | `P1` | PATTERN | setup completo | `D` | `EXEC` | pattern event aligned with executable fill chronology | `until_entry` | | `P1E1` | ENTRY | fill LONG effettivo | `EXEC` | `EXEC` | no difference: real execution event | `event_only` | Forma sbagliata: - scheda lunga e verbosa senza una tabella riassuntiva finale - tabella che non distingue `TF logico reale` da `TF payload runtime` - tabella presente solo in Markdown ma illeggibile e senza versione `.txt` alternativa quando serve ============================================================ 5-quater) ESEMPIO E3 - EVENTO LOGICO CON RUNTIME ANCHOR DISTINTO ============================================================ Caso corretto: - una `CONDITION` daily mantiene: - `tf = D` - `cert_tf = D` - `cert_dt = logical daily close anchor` - `cert_price = close della barra daily logica` - ma l'evento espone anche in `meta`: - `runtime_anchor_dt` - `runtime_anchor_price` - `logical_bar_start_dt` se il dataset logico e' `BAR_START` Perche' e' corretto: - mantiene pulita la semantica logica dell'evento - evita di falsare il tf dell'evento solo per esigenze runtime - permette a validator/runtime/UI di sapere anche dove l'evento si ancora operativamente Forma sbagliata: - cambiare `tf` da `D` a `EXEC` solo per far passare la cronologia, perdendo la semantica logica, quando la piattaforma supporta gia' anchor runtime distinti ============================================================ 5-quinquies) ESEMPIO E4 - OCCURRENCE-BASED AUDIT SU DOPPIO SWING ============================================================ Caso corretto: - una strategia tipo bullish divergence su due swing low puo' esporre: - `logic_state` per mostrare stati booleani densi come `POSITION` o `SETUP ACTIVE` - `logic_occurrences` per mostrare le occorrenze discrete realmente usate - esempio concettuale: - `occ_sl1_00017` - `entity_id = P1C1` - `entity_type = CONDITION` - `logic_label_short = SL1` - `semantic_role = anchor` - `status = selected` - `occ_sl2_00044` - `entity_id = P1C2` - `entity_type = CONDITION` - `logic_label_short = SL2` - `semantic_role = anchor` - `status = certified` - `depends_on_occurrence_ids = ["occ_sl1_00017"]` - `occ_div_00045` - `entity_id = P1C3` - `entity_type = CONDITION` - `logic_label_short = RSI DIV` - `semantic_role = confirmation` - `depends_on_occurrence_ids = ["occ_sl1_00017", "occ_sl2_00044"]` - `occ_p1_00009` - `entity_id = P1` - `entity_type = PATTERN` - `logic_label_short = PATTERN` - `semantic_role = pattern_complete` - `used_by_trade_ids = [138]` Perche' e' corretto: - distingue l'entita' astratta dalla sua occorrenza concreta - rende auditabile quale swing low sia stato davvero usato dal trade - evita che la UI debba indovinare da soli puntini fractal o da segmenti legacy del Logic Indicator Forma sbagliata: - esporre solo marker prezzo uguali fra loro e pretendere che il consumer capisca quale sia l'anchor selezionato - usare solo `logic_state` per un problema che richiede di distinguere piu' occorrenze della stessa `CONDITION` - lasciare la numerazione del trade come ordinamento locale UI invece di allinearla a un `trade_seq` persistito quando disponibile ============================================================ 6) ESEMPIO E - STATUS DEL TASK ============================================================ Nuovo EA: - usare nome descrittivo provvisorio - non assegnare strategy_code ufficiale - non assumere strategy_version ufficiale Nuova versione di EA esistente: - usare strategy_code gia' assegnato da ALGO - proporre la strategy_version solo dentro quel contesto ============================================================ 7) ESEMPIO F - RISPOSTA CORRETTA DI UNA AI DEV ============================================================ Dato input: - strategia dichiarata daily - entry at close - exit at close - nessuna richiesta di percent-of-equity - nessuna assegnazione ALGO di strategy_code Risposta corretta: - usa D diretto - usa close della barra segnale - mantiene `position_size = 1` come default ALGO - usa nome descrittivo provvisorio - non inventa `EA-XXX-VYY` - dichiara le assunzioni e produce il draft ============================================================ 8) ESEMPIO G - RISPOSTA SBAGLIATA DI UNA AI DEV ============================================================ Risposta sbagliata: - apre una lista di opzioni come "D diretto o M1 aggregato?" - chiede "close corrente o open barra successiva?" quando il brief dice gia' at close - propone un strategy_code ufficiale sequenziale inventato - apre discussioni su roadmap future prima del draft base - cita template/versioni non coerenti con il bundle ricevuto - hardcoda `pattern_symbol` come alias di mercato invece di renderlo runtime-aware - dimentica la force-exit quando il trade puo' restare aperto a fine dati - accetta solo params nested e poi si rompe nel runtime reale di ALGO - AI_DESCRIPTION di due righe senza tabella Variables/Constants - ChartTrade Semantics lasciata implicita o fuori dal campo AI_DESCRIPTION Perche' e' sbagliata: - non applica i default canonici - scarica sull'utente decisioni che il pacchetto canonico dovrebbe gia' risolvere - viola la governance dell'identita' ufficiale ALGO ============================================================ 9) CHECK RAPIDO PER AI ESTERNA ============================================================ Se non riesci a rispondere chiaramente a tutte queste domande, il draft non e' ancora pronto: - qual e' il Pattern? - quali sono le Conditions? - qual e' il tf di ogni Condition? - qual e' il Pattern TF? - qual e' l'MRE? - cosa compare in charttrade? - cosa resta invisibile? - entry ed exit sono completamente definite? - il task e' draft o ufficiale? - il strategy_code esiste gia' oppure no? - il draft accetta il formato params runtime attuale? - `pattern_symbol` e' runtime-aware? - se MRE e' piu' grosso di EXEC, il mapping fill EXEC -> barra logica e' dichiarato? - se il trade puo' restare aperto, esiste una force-exit? ============================================================ 10) PROMPT UNIVERSALE: PRINCIPIO CANONICO ============================================================ Il prompt universale definito in B9 e' parte del corpus canonico. Questo significa: - non deve vivere solo in chat o in istruzioni temporanee - deve poter essere consegnato insieme alle specs come handoff autosufficiente - e' corretto specializzarlo sul singolo brief, ma non svuotarlo dei suoi vincoli - se il prompt specializzato confligge con B2-B10, prevalgono sempre B2-B10 ============================================================ FINE B10 ============================================================