Files
Encelado/Encelado/docs/KNOWN_ISSUES.md
T
Alby96andClaude Fable 5.1 c5f2b7d852 5.0 Fase 4: recupero dopo inattività, heartbeat e lock di istanza
Un riavvio, una sospensione del PC o un container fermo lasciavano i basket
aperti senza che nessuno applicasse le regole di uscita per il tempo perso.
Ora un heartbeat ogni 30 s misura l'inattività; oltre la soglia il bot blocca
le entrate, risolve gli ordini senza esito, riconcilia, riscalda le serie con le
barre perse e rivaluta ogni basket aperto come a una chiusura di barra
ordinaria (chiudi o tieni), chiude le orfane, riporta le esterne, scrive
reports/recupero_<run_id>.csv e riapre le entrate dopo il riscaldamento; a
mercato chiuso aspetta. Un lock tenuto in esclusiva impedisce due istanze
sulla stessa cartella dati. Sezione recovery in strategy.json. Test (r).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-23 11:14:06 +02:00

4.7 KiB
Raw Blame History

Problemi noti e limiti

Aggiornato: 2026-09-23. Una voce per limite, con lo stato. Quando un limite viene rimosso, la voce si sposta nel CHANGELOG.md.

Strategia

  • Il backtest è negativo. Su 7,75 anni di barre M15 nessuna configurazione della griglia è profittevole al netto dei costi assunti; il break-even è vicino a zero, cioè il segnale non ha contenuto misurabile (docs/STRATEGY.md). Il modulo resta uno strumento di forward test in Demo, non un sistema da mettere sul reale.
  • EURAUD ha tick solo per parti del 2018, 2021 e 2026: il basket EURAUD/AUDCAD è misurabile in backtest solo su quei tratti.
  • Il backtest non ha calendario né notizie: blackout e sentiment sono attivi solo dal vivo. L'effetto del blackout sui risultati non è misurato.
  • Il cancello di correlazione ρ_W ≤ 0,6 si apre di rado sulle barre M15: nelle 4 ore di Demo del 2026-09-16 31 segnali su 31 sono stati rifiutati per quel solo motivo. Non è un bug: è la soglia della specifica; va misurata sul ledger prima di proporre un valore diverso (knowledge/proposals.csv).
  • I costi del backtest sono assunzioni (spread tipici pubblicati o spread dei tick, overnight 0,3 o 0,9 pip/gamba/giorno). Il costo vero si misura solo nel ledger del Demo.

eToro

  • L'endpoint delle candele non pagina: al massimo ~10 giorni di M15. Lo storico dipende dai tick forniti dall'utente.
  • L'API demo mostra spread di mercato di 0,1-0,7 pip senza markup e un overnight di 0,91 USD/giorno per 10 000 EURUSD. Se l'esecuzione reale applica uno spread diverso, lo si vedrà dallo slippage scritto nel ledger a ogni ingresso.
  • Il campo dei costi si chiama value (non amount, come si era scritto in prima battuta): corretto il 2026-09-16 pomeriggio; le righe del ledger della mattina hanno markupA/B = 0 e overnight nullo per questo motivo.
  • Il conto reale dell'utente vale 224,90 USD (2026-09-23): con l'esposizione minima di 1000 USD per gamba il Live non è praticabile a prescindere dai cancelli.
  • Il server non registra l'x-request-id come referenceId degli ordini v2: il lookup per riferimento risponde 404 anche per ordini eseguiti. Dalla 5.0 l'esito si legge per orderId; il riferimento resta solo come ripiego (ADR-0009).
  • A margine esaurito il server riduce l'ordine a un importo fisso (2 000 USD di margine osservati il 16-21/9) invece di rifiutarlo; la regola non è documentata nell'OpenAPI. Il bot registra unita_richieste e unita_eseguite in orders.jsonl e dimensiona la gamba B sulle unità eseguite di A; i limiti di margine della Fase 2 evitano di arrivarci.

Feed

  • Google News vieta /rss/search nel robots.txt: le cinque query (EURUSD, SNB, RBNZ, RBA, forex) non vengono scaricate e restano vuote. SNB e RBNZ non hanno quindi nessuna fonte; RBA solo il feed ufficiale, che risponde 403 a intermittenza (Akamai). Il sentiment su CHF, NZD e in parte AUD è di fatto zero.
  • Il feed della Fed risponde 404 a tratti (osservato alle 15:16 UTC+2 del 2026-09-16): la cache copre i buchi.
  • Il calendario FairEconomy è settimanale: la settimana successiva compare solo da domenica.

Bot

  • Le posizioni salvate in baskets_state.json da una modalità diversa non vengono riprese (si riparte dalla riconciliazione del conto).
  • Il ledger delle sessioni Demo del 16-21/9 (le 65 righe segnale_ingresso/rifiuto del post-mortem) non è su questa macchina; l'analisi si basa sullo storico del conto letto via API (D-36).
  • La finestra WPF mostra i contatori nuovi (in attesa, orfane, esterne, P&L del conto) nei riquadri esistenti; la scheda Storico, la bonifica con pulsante e la navigazione a sinistra arrivano con la web UI (Fasi 6-7, dopo D-28). In attesa, la bonifica si lancia da headless (--bonifica).
  • Un movimento di cassa viene riconosciuto dal salto del saldo (oltre 10 USD e 0,25 %): un accredito piccolo sotto quella soglia passa per rumore; un prelievo che coincide con una chiusura viene distinto solo se lo storico del conto risponde.
  • Il ciclo settimanale gira solo mentre il bot è acceso la domenica dopo le 10 UTC (o al primo avvio dopo sette giorni).
  • La finestra e l'headless usano lo stesso log: il lock di istanza (5.0) impedisce che due motori girino sulla stessa cartella dati, ma la finestra aperta senza AVVIA scrive comunque nel log mentre gira l'headless.

Codice

  • BasketEngine è spezzato in sei file parziali dalla 5.0; il file principale resta di ~900 righe (loop, decisioni, esecuzione).
  • I test dell'interfaccia rendono le pagine in memoria (UiRenderTests, con ENCELADO_RENDER_DIR), non il comportamento della finestra vera (dialoghi, timer).
  • Il test (l) copre i blocchi nel decisore, non la simulazione completa dell'equity stop nel motore live; quella è coperta dal backtest (EquityStops in BacktestResult) e dal ledger.