Encelado/Encelado/docs/STATE.md

Stato del lavoro

Aggiornato: 2026-09-23 (sessione 5.0, Fasi 6-9 concluse: il piano 5.0 è completo).

Fase in corso

Piano 5.0 concluso (docs/PIANO_5.0.md): tutte le fasi 0-9 sono fatte. Il bot è Encelado.Server (Kestrel + motore + interfaccia web incorporata) e gira nel container (ADR-0007, ADR-0008); la finestra WPF non esiste più (D-28). Versione di sviluppo 5.0.0 in Directory.Build.props; il rilascio 5.0.0 non è ancora stato fatto (tag, immagine sul registro di Gitea, release): lo decide l'utente con dotnet msbuild build/Release.proj -t:Rilascia -p:Versione=5.0.0 dopo il push del ramo.

Fatto nell'ultima sessione (2026-09-23, Fasi 6-9)

• Fase 6 — Engine + Server: src/Encelado.Bot → src/Encelado.Engine (libreria, senza UI); src/Encelado.Server (Sdk.Web, nessun NuGet) con WebHost (token in cookie HttpOnly o Bearer, senza token solo localhost), API JSON scritta a mano, SSE /api/stream a uno snapshot al secondo, LogBuffer, HistoryService; chiavi da variabili o file cifrato etoro.keys.enc (AES-256-GCM, ENCELADO_KEY_PASSPHRASE) al posto di DPAPI; AppPaths con /config e /data; HeadlessRunner ridotto a console (stato, comandi, bonifica); --sample, --health, --no-autostart, ENCELADO_AUTOSTART, ENCELADO_CONFIRM_LIVE.
• Fase 7 — interfaccia web Material 3 (Web/wwwroot, vanilla): navigation rail 80/256 px (drawer sotto 600 px), barra con orologi UTC e fuso, selettore della valuta (USD, EUR, GBP, CHF, JPY, AUD, CAD, NZD con tasso dalle quotazioni e tooltip in USD), AVVIA/FERMA, KILL-SWITCH con «chiudi anche le esterne»; dashboard con sei KPI (incluso il margine), tabella dei basket (cards da telefono), card evento/eToro/Telegram, attività, banner; Storico ordini (ordini, posizioni classificate, profitti per periodo con curva SVG, CSV); Log con filtri; Impostazioni con configurazione validata, chiavi eToro, ripristino in cinque passi, Ricerca, Diagnostica (con bonifica), Informazioni (versione, build, commit da AssemblyMetadata); temi scuro/chiaro. HistoryBuilder nel Core; SnapshotJson, SampleSnapshot, SettingsService nell'Engine; comando learn nello strumento (Learn.cs); ui.displayCurrency/theme/navExpanded e coppie di conversione nel polling.
• Fase 8 — Docker e Unraid: Dockerfile multi-stage (build, test, publish, runtime aspnet:10.0 + gosu + tzdata), deploy/docker/entrypoint.sh (TZ, PUID/PGID), docker-compose.yml, .dockerignore, HEALTHCHECK --health; deploy/unraid/encelado.xml (Container v2, icona assets/encelado.png raw da Gitea, D-29) e README; build/Release.proj senza Inno Setup: Pubblica framework-dependent, Docker, Pacchetto (zip + template + tag), Rilascia (push dell'immagine sul registro di Gitea + release); VS Code con F5 sul server (Encelado (server), Encelado (campione), backtest) e attività Docker. Immagine 192.168.30.23:3000/alby96/encelado:5.0.0 (346 MB) costruita dalla catena (-t:Docker -p:Versione=5.0.0, senza tag) con 210 test verdi nello stadio Linux e provata: avvio, semina di /config, permessi 99:100, /api/health, token, sonda --health, nessun avviso di Kestrel o di useradd. Il primo arresto con docker stop non era pulito (SIGKILL dopo la grazia): corretto con PosixSignalRegistration per SIGTERM in Program.cs e verificato: docker stop chiude in 1 s con «SIGTERM: arresto» ed exit 0.
• Avvio in locale (richiesta dell'utente): sandbox deploy/local/ (config/ = /config, data/ = /data, ignorata da git) usata da F5 (Encelado (server), ENCELADO_CONFIG_DIR + ENCELADO_DATA_DIR, che ora vale anche fuori dal container), dagli script scripts/run-dev.ps1|.sh, run-docker.ps1|.sh (compose, token sviluppo), screenshots.ps1|.sh e dalle attività di VS Code (avvia in locale (script), avvia in docker, ferma docker, screenshot); provati tutti e tre i modi e lo script degli screenshot. /api/health in --sample non finge più un motore acceso.
• Fase 9 — documenti e pulizia: ADR-0007, ADR-0008, docs/DOCKER.md, docs/UI_GUIDELINES.md, README.md con gli screenshot (docs/img/), CLAUDE.md, ARCHITECTURE, RUNBOOK, KNOWN_ISSUES, GLOSSARY, DATA_SOURCES, ML_AND_LEARNING, QUESTIONS (D-28, D-29, D-36, D-37 risposte), POSTMORTEM (gli «accrediti» erano crediti demo per ogni ordine ridotto), skill aggiornate, build/README.md. Codice morto rimosso: progetto WPF, DPAPI, test WPF, UiRenderTests, ~45 membri mai usati (statistiche di ricerca, Psi, EmptyContextProvider, EnvironmentKeyStore, display helper dello snapshot, INotifyPropertyChanged in SettingField, …). Test nuovi: EmbeddedUiTests, WebHostTests, HistoryBuilderTests, KeyStoreTests; suite a 210 verdi.

Prossimi passi

1. Rilascio 5.0.0 (utente): push del ramo, -t:Rilascia -p:Versione=5.0.0 (richiede Docker acceso, build/gitea.json con permesso package, registro 192.168.30.23:3000 dichiarato insecure-registry), poi installazione su Unraid dal template.
2. Riaccendere il Demo nel container per 24 ore di verifica: contatore «orfane» a 0, orders.jsonl senza Unknown irrisolti, sizing_bound = margin sui primi ingressi; kill-switch a mano con verifica di piattezza; fermare il container un'ora con un basket aperto per vedere il recupero; messaggi Telegram reali.
3. Revisione visiva dell'interfaccia con l'utente (gli screenshot sono dal campione --sample); eventuali ritocchi ai testi e ai tooltip.
4. Avviso Telegram sui feed fermi da più di un'ora (resta in KNOWN_ISSUES).
5. Rifare il backtest (backtest baskets) con i limiti di margine e aggiornare §3 di docs/STRATEGY.md.

Problemi aperti

• Il disco C: del PC di sviluppo si era riempito (0 byte) a metà sessione; ora ha 12 GB liberi. Le immagini e la cache di build di Docker pesano: docker system prune ogni tanto.
• Backtest negativo: la strategia non regge i costi (docs/STRATEGY.md).
• Il conto reale vale 224,90 USD: il Live non è praticabile.
• Google News blocca le ricerche RSS; RBA 403 a intermittenza; Fed 404 a tratti.
• Il server non ha TLS e il registro di Gitea è in HTTP (rete locale).
• Modifiche.txt nella radice è un appunto dell'utente, modificato e non committato: decidere se tenerlo nel repository.