Roadmap

Non rappresenta un piano di rilascio, non definisce date e non promette la disponibilita' delle funzionalita' citate. Le fasi possono cambiare in funzione delle esigenze del progetto, delle priorita' operative e della maturazione dell'architettura.

L'obiettivo e' mantenere una crescita coerente con l'architettura descritta nella documentazione Developer, in particolare con:

• Ecosystem;
• Domain Model;
• Resource Ownership Model;
• Account System;
• Identity Model;
• Membership Model;
• Account Provisioning;
• Invitation Service;
• Feature Flags;
• DSC+ Overview;
• Partner Integration.

La roadmap non deve essere letta come un elenco di feature isolate. Descrive invece un percorso di evoluzione architetturale: ogni fase prepara la successiva, mantenendo Drone Sky Check utilizzabile anche senza autenticazione e preservando la separazione tra nucleo pubblico, Core Account System, Pilot Workspace, Feature Flags, DSC+ e servizi collegabili.

Direzione Attuale

La prossima attivita' di sviluppo resta l'integrazione del Tool Authorization con il contesto locale gia' gestito dal Core Account System.

Questa integrazione appartiene ancora a Drone Sky Check Free: usera' il modello locale gia' introdotto, in cui il Pilot Workspace rappresenta il pilota singolo, l'UAS Operator personale coincide operativamente con il pilota, i droni appartengono a quell'operatore personale e i dati sono salvati nel browser.

Il Tool Authorization sara' il primo consumer dell'Operational Context composto dal Core Account System. Il Pilot Workspace non e' la ragione per cui Authorization esiste e Authorization non e' la ragione per cui il Workspace esiste. Il tool dovra' leggere profilo, workspace, operatore, attestati e droni dal Core Account System, mantenendo nel proprio flusso solo dati della singola pratica autorizzativa: periodo, attivita', area operativa, marca da bollo, destinatari e altri dati temporanei.

Questa scelta prepara la direzione piu' ampia: tutti i futuri strumenti, come Mission Planning, Future Planning, USEPPO, Logbook, Report, API e servizi DSC+, dovranno usare lo stesso Operational Context invece di creare archivi paralleli.

Principi Guida

La crescita di Drone Sky Check deve rispettare alcuni principi stabili:

Principio	Implicazione
Account opzionale	Il login abilita servizi aggiuntivi, ma non deve diventare requisito generale per usare la piattaforma pubblica.
Core Account System	Il Core Account System e' il centro architetturale dei domini personali e operativi: Workspace, Pilot Profile, UAS Operator, Membership, Feature Flags e domini futuri.
Evoluzione modulare	Ogni servizio deve poter crescere senza imporre dipendenze rigide agli altri moduli.
Feature Flags	Le funzionalita' avanzate nei moduli applicativi devono essere abilitate tramite flag specifiche prodotte dalla Membership, non tramite controlli generici su piani.
Pilot Workspace	Lo spazio personale del pilota e' un dominio del Core e il principale punto di accesso personale al contesto operativo, senza sostituire Pilot Profile o UAS Operator.
Operational Context	I moduli devono consumare una composizione temporanea di domini del Core, formata da Pilot Workspace, Pilot Profile, UAS Operator, droni, missione corrente, pratica corrente, membership e feature abilitate.
DSC+ come ecosistema	DSC+ deve rappresentare l'insieme dei servizi avanzati e della continuita' operativa del pilota, non un semplice abbonamento o un blocco artificiale di singole azioni.
Continuita' operativa	Le funzionalita' pubbliche e locali permettono di consultare e utilizzare Drone Sky Check. DSC+ abilita persistenza, sincronizzazione e servizi evoluti del Pilot Workspace, evitando limitazioni artificiali su singole funzioni.
Partner collegabili	Academy, Useppo e futuri partner devono restare servizi integrabili, non dipendenze strutturali del nucleo.
Valorizzazione open source	Quando esiste un progetto open source solido e specializzato, Drone Sky Check deve integrarlo tramite confini chiari invece di duplicarne le funzionalita'.

Gerarchia implementativa del Core Account System:

Identity
  -> Membership
  -> Feature Flags
  -> Repository

L'Identity stabilisce chi e' l'utente. FREE non richiede Identity Firebase: e' uso anonimo locale. La Membership determina se un account Cloud provisionato usa l'ecosistema DSC+. Le Feature Flags espongono le capacita' abilitate dalla Membership. Il Repository Manager sceglie il repository attivo partendo dalla Membership e dalla feature workspaceSync, non da controlli sparsi nei service applicativi.

DSC+ non deve essere trattato come un semplice paywall. Il suo valore non deriva dal blocco isolato di esportazioni, PDF o singole azioni, ma dalla continuita' dei dati e dei workflow del pilota tra sessioni, dispositivi e servizi. Eventuali PDF, report, autorizzazioni o output strutturati possono far parte dell'ecosistema, ma non rappresentano da soli la proposta di valore di DSC+.

Visione D'Insieme

flowchart TB
  Core["Core Account System\nFoundation e Core Context"]

  Core --> Workspace["Pilot Workspace\npunto di accesso personale"]
  Core --> Profile["Pilot Profile\npersona"]
  Core --> Operator["UAS Operator\nasset e responsabilita'"]
  Core --> Membership["Membership\nDSC+ e programmi"]
  Core --> Flags["Feature Flags\ncapacita' abilitate"]

  Workspace --> Context["Operational Context\ncomposizione temporanea"]
  Profile --> Context
  Operator --> Context
  Membership --> Context
  Flags --> Context

  Context --> Authorization["Authorization\nprimo consumer"]
  Context --> MissionPlanning["Mission Planning"]
  Context --> Logbook["Logbook"]
  Context --> Reports["Report"]
  Context --> Api["API"]
  Context --> DscPlus["Servizi DSC+"]

  Core --> OperationalDomain["Dominio Operativo\nDroni, missioni,\nflotte, operatori"]
  OperationalDomain --> MissionPlanning
  MissionPlanning --> FuturePlanning["Future Planning"]
  DscPlus --> Academy["Academy"]
  DscPlus --> DscDrones["Droni DSC+\nFleet e Flight Log"]
  DscPlus --> PartnerPlatform["Partner Platform\nUSEPPO e integrazioni"]
  PartnerPlatform --> Platform["Ecosistema Piattaforma\nRealtime, cloud, dispositivi"]

Le fasi non devono essere interpretate come una catena in cui Authorization segue o sostituisce il Pilot Workspace. Il Core Account System fornisce domini separati; l'Operational Context li compone; Authorization e' solo il primo consumer concreto di quel contesto.

Stato Della Foundation

La Foundation del Core Account System e' ormai completata come base tecnica locale e architetturale.

Lo stato implementato include:

• Context Manager con getContext(), setContext(), updateContext(), resetContext() e cancellazione esplicita del contesto persistito;
• Repository Pattern per caricare, salvare e cancellare il Core Context senza esporre il repository concreto ai service;
• LocalStorage Repository attivo, con chiave stabile dsc.core.context, payload versionato e migrazione v1 -> v2;
• Firestore Repository implementato come repository cloud DSC+ compatibile con lo stesso contratto del repository locale;
• Membership Service collegato a Firestore tramite collezione memberships/{uid};
• nessuna Cloud Function generica attiva su creazione utente Auth per creare Membership FREE;
• Feature Flags derivate dalla Membership caricata;
• Repository Manager centralizzato, usato dal Core per selezionare un solo repository attivo tra LocalStorage e Firestore in base alla Membership;
• Firebase Authentication collegata al Core Account System per login email/password, login Google, registrazione beta, logout, recupero password, verifica email, refresh dello stato account e ascolto onAuthStateChanged;
• Account Cloud DSC+ provisionato tramite inviti amministrativi: Provisioning Service, Invitation Service, Cloud Functions callable, audit e Control Center sono implementati come prima slice;
• Control Center operativo per overview, monitoraggio provisioning, inviti, Membership e audit;
• bootstrap first-run del primo amministratore tramite Cloud Function one-shot, protetta da utente autenticato, secret backend e lock Firestore;
• Notification Service backend condiviso per email transazionali, con Brevo come provider e template separati dalla logica account;
• Domain Models dedicati per Operational Place, Pilot Profile e UAS Operator personale locale;
• service applicativi per Pilot Workspace, Pilot Profile e UAS Operator, indipendenti dal meccanismo di persistenza;
• canale eventi minimo del Core per notificare cambiamenti di Context, account, membership, Feature Flags, repository, Pilot Profile, Operatore e Workspace;
• Self Test del Core Account System per verificare contratti, normalizzazione e comportamento dei modelli principali;
• separazione tra UI, Domain Model, service applicativi, Context Manager e repository.

L'autenticazione e' ora disponibile come livello di identita' per account Cloud provisionati. Dopo il login, il Core carica la Membership e da questa deriva le Feature Flags e la scelta del repository attivo. Il login non abilita automaticamente DSC+, sincronizzazione cloud o funzionalita' premium.

Fase 1: Foundation

Questa e' la fase di consolidamento architetturale iniziale.

Lo scopo non e' rilasciare subito servizi avanzati, ma preparare il terreno per introdurli in modo coerente, reversibile e mantenibile.

Obiettivi:

Area	Obiettivo
Account opzionale	Definire il modello di accesso senza rendere obbligatoria l'autenticazione per l'uso pubblico.
Identity	Separare l'identita' dell'utente dai dati operativi, dalla membership e dalle feature abilitate.
Domain Model	Stabilire la relazione tra Persona, Pilot Profile, Pilot Workspace, UAS Operator e Active Operator prima di introdurre nuovi oggetti operativi.
Resource Ownership Model	Definire owner, editor, consumer e visibility delle risorse prima di implementare droni, missioni, operatori e collaborazione.
Identity Model	Mantenere distinti persona, account personale, Pilot Profile, UAS Operator, organizzazioni e ruoli.
Pilot Workspace	Definire lo spazio personale del pilota come contenitore evolutivo per dati e servizi futuri.
Pilot Profile	Mantenere il profilo focalizzato sulle informazioni che descrivono il pilota.
Membership Model	Separare Membership DSC+, Subscription, piano commerciale, entitlements, Feature Flags, ruoli operatore e collaborazione.
Feature Flags	Stabilire il modello di abilitazione delle funzionalita' avanzate.
DSC+	Descrivere DSC+ come ecosistema di servizi avanzati, non come semplice piano commerciale.
Architettura pronta	Rendere chiari confini, responsabilita' e dipendenze prima dell'implementazione.

Risultato atteso della fase:

• documentazione architetturale consolidata;
• separazione chiara tra account personale, Pilot Workspace, Pilot Profile, UAS Operator, membership, ruoli, ownership delle risorse e Feature Flags;
• base concettuale pronta per progettare implementazioni future senza accoppiamenti prematuri.

Stato attuale:

• la Foundation e' stata completata come base frontend del Core Account System;
• il Core Context contiene identita', Pilot Profile, Operatore UAS personale locale, Pilot Workspace, membership e Feature Flags come concetti separati;
• sono stati formalizzati Domain Model, Identity Model, Membership Model e Resource Ownership Model per guidare operatori, ruoli, collaborazione e DSC+ futuri;
• i servizi applicativi lavorano sul Core Context e non conoscono direttamente il meccanismo di persistenza;
• Firebase Authentication e' stata attivata come identita' account opzionale, con stato pubblicato tramite Context ed eventi del Core;
• la Membership viene letta da Firestore dopo il login e pubblicata nel Core Context;
• un account Firebase senza Membership valida e' uno stato anomalo/non provisionato e non diventa FREE;
• il Firestore Repository e' disponibile come repository cloud, ma viene abilitato solo da Membership DSC_PLUS attiva con feature workspaceSync;
• il provisioning Admin reale e' implementato come prima slice tramite inviti e Control Center;
• non sono stati introdotti sincronizzazione cloud continua con merge automatico, snapshot versionati, Stripe, pagamenti, assegnazione automatica di DSC+ o DSC+ commerciale automatico.

Fase 2: Pilot Workspace

Questa fase introduce il concetto operativo di spazio personale del pilota.

Il Pilot Workspace non deve trasformare Drone Sky Check in un'applicazione chiusa. Deve aggiungere continuita' e sincronizzazione per chi sceglie di usare servizi personali.

Il Pilot Workspace deve poter esistere anche in una modalita' locale o non sincronizzata. Persistenza remota e sincronizzazione tra dispositivi sono abilitate oggi dalla feature DSC+ workspaceSync. Backup versionati, storico, notifiche, gestione delle scadenze e servizi evoluti potranno essere abilitati attraverso feature dedicate quando avranno un dominio tecnico reale, senza rendere obbligatoria autenticazione o abbonamento per usare il nucleo pubblico di Drone Sky Check.

Possibili aree di evoluzione:

Area	Descrizione architetturale
Operational Places	Primo oggetto del Pilot Workspace: luoghi operativi significativi per il pilota.
Missioni sincronizzate	Salvataggio e recupero di missioni associate al Pilot Workspace.
Droni	Elenco o configurazione di asset operativi associati al pilota.
Report	Archivio personale di report o documenti generati da servizi avanzati.
Impostazioni	Preferenze sincronizzate tra dispositivi o sessioni.

Questi elementi sono esempi di evoluzione. Non rappresentano funzionalita' gia' disponibili.

Stato attuale raggiunto:

• e' stata implementata la prima versione locale del Pilot Workspace con persistenza nel browser;
• Operational Places rappresenta il primo oggetto di dominio del Pilot Workspace;
• e' stato introdotto il pattern Domain Model, che separa la logica degli oggetti dal Workspace Service;
• il Pilot Profile dispone di Domain Model, service dedicato e UI di riepilogo/editor, restando separato dal Pilot Workspace e dall'Operatore UAS;
• il Pilot Profile e' stato riallineato alla Persona: contiene dati personali, recapiti, fotografia/avatar locale, attestati, qualifiche, competenze e preferenze, senza codice operatore o assicurazione;
• UAS Operator e' ora un'entita' separata nel Core Context: nella modalita' locale esiste un solo Operatore personale, con codice operatore UAS EASA personale e assicurazione;
• e' stata introdotta la migrazione LocalStorage v1 -> v2, che sposta codice operatore e assicurazione dal vecchio Pilot Profile al nuovo Operatore personale quando sono presenti dati significativi;
• l'avatar della topbar usa prima la fotografia del Pilot Profile, poi le iniziali, poi il fallback persona;
• e' stato introdotto il concetto architetturale di Active Operator, necessario per determinare asset e workflow disponibili durante una missione;
• il primo livello tecnico degli Operational Places include self-test del Core, ID locale del Workspace, campi type e status, archiviazione, ripristino ed eliminazione;
• il Pilot Workspace dispone ora di una propria interfaccia utente, aperta dal pulsante utente nella topbar;
• gli Operational Places dispongono ora di UI per creazione, modifica, navigazione sulla mappa, archiviazione, visualizzazione degli archiviati, ripristino ed eliminazione definitiva;
• il Core Context viene caricato automaticamente all'avvio e salvato automaticamente a ogni modifica tramite Repository Pattern;
• il repository attivo viene selezionato dal Repository Manager del Core;
• utenti anonimi e account non provisionati continuano a usare LocalStorage con chiave stabile dsc.core.context e payload version: 2;
• utenti autenticati con Membership DSC_PLUS attiva e feature workspaceSync usano il Firestore Repository come repository attivo;
• la migrazione iniziale del Workspace locale verso cloud e' predisposta come operazione esplicita una tantum, senza merge automatico e senza sincronizzazione bidirezionale;
• dopo la migrazione il LocalStorage non viene cancellato e resta come copia locale non sincronizzata;
• il Context Manager espone una cancellazione esplicita dei dati persistiti locali, separata dal normale reset del Context;
• il termine "Preferiti" potra' restare una scelta di interfaccia, ma l'architettura usa luoghi operativi e non semplici segnalibri;
• il Workspace non viene piu' creato manualmente dall'utente: viene creato automaticamente alla prima operazione che richiede un contesto operativo personale;
• la sezione Account Cloud del Pilot Workspace usa Firebase Authentication per accesso email/password, accesso Google, logout, recupero password, verifica email e refresh dello stato account;
• la registrazione pubblica e' temporaneamente bloccata: il form di creazione account e' disponibile solo aprendo l'app con ?dscplus=beta, mentre senza parametro resta visibile solo la schermata informativa DSC+;
• la UI Account Cloud identifica l'ecosistema DSC+ con badge e testo informativo, ma non mostra piani, abbonamenti o appartenenza DSC+ non verificata;
• lo stato del Pilot Workspace indica dinamicamente il repository realmente attivo;
• se un utente DSC+ non ha ancora un contesto cloud ma possiede un Workspace locale, il Pilot Workspace propone esplicitamente Trasferisci oppure Inizia da zero;
• non sono state introdotte sincronizzazione cloud continua, merge automatici, risoluzione conflitti, chiamate REST account, Stripe, pagamenti o assegnazione automatica commerciale di piani;
• la Fase 2 non e' da considerarsi completata.

Obiettivi immediatamente successivi:

• integrare il Tool Authorization con l'Operational Context locale del Core Account System come primo consumer del nuovo contesto operativo;
• eliminare progressivamente la duplicazione dei dati permanenti oggi presenti nel flusso Authorization, mantenendo nel tool solo i dati della singola pratica;
• proseguire la Fase 3 con domini operativi separati, senza introdurre ancora Mission Domain, Fleet Management o collaborazione;
• mantenere la separazione gia' implementata tra Pilot Profile, Pilot Workspace, UAS Operator personale locale e asset operativi;
• progettare i futuri Domain Model Mission e Fleet rispettando Domain Model, Identity Model, Membership Model e Resource Ownership Model, quindi distinguendo dati personali locali, dati dell'operatore, ownership, ruoli e dati collaborativi sincronizzati;
• definire in una fase futura il flusso commerciale che abilita le feature Cloud DSC+, oggi workspaceSync, senza confonderlo con il semplice login Firebase.

Consolidamento Del Core

Prima di introdurre nuovi oggetti operativi, la Fase 2 deve consolidare il Core Account System gia' implementato.

Le aree di consolidamento sono:

Area	Direzione architetturale
Riduzione dell'accoppiamento	Mantenere UI, Domain Model, service applicativi, Context Manager e repository su livelli separati.
Eventi del Core	Canale minimo introdotto per context:changed, account:changed, membership:changed, features:changed, repository:changed, pilotProfile:changed, operator:changed e workspace:changed; eventuali estensioni restano future.
Repository intercambiabili	Repository Manager centralizzato introdotto per scegliere un solo repository attivo tra LocalStorage e Firestore in base alla Membership, senza modificare i service.
Self Test	Ampliato per coprire Operatore UAS, migrazione v1 -> v2, fotografia profilo, protezione delle copie, caricamento Membership, account non provisionati, selezione repository tramite Membership, migrazione cloud esplicita, mantenimento LocalStorage e login Google.
Separazione dei confini	Evitare che Pilot Profile, Pilot Workspace, repository e UI assumano responsabilita' reciproche.

Questo consolidamento non introduce nuove funzionalita' utente. Serve a rendere stabile la base tecnica prima di aggiungere Droni, Missioni, Flotte, Operatori e collaborazione.

Prima di introdurre Droni, Missioni, Organizzazioni e Collaborazione, il modello Persona <-> Operatore deve restare stabile: una Persona possiede un account personale e un Pilot Profile personale, mentre l'UAS Operator possiede gli asset operativi. L'Active Operator definisce il contesto effettivo di una missione.

Roadmap Account E Provisioning

Il modello account e' stato riallineato: FREE indica uso anonimo locale, mentre un account Firebase rappresenta un account Cloud provisionato o uno stato anomalo se manca una Membership valida. Non deve esistere una registrazione pubblica che crei utenti FREE e non deve esistere una funzione generica Auth che assegni automaticamente Membership FREE.

Fase	Stato	Obiettivo
Consolidamento client	Implementato	Login Firebase per account provisionati, lettura Membership, Feature Flags derivate, selezione repository tramite Membership e fallback locale per stati non validi.
Provisioning Service	Implementato, prima slice	Punto server-side per validare diritto, duplicati, piano, ruolo, feature, entitlements, sorgente e durata, creando richieste idempotenti senza attivare direttamente utenti.
Invitation Service	Implementato, prima slice	Generazione inviti con token hashato, email Brevo tramite Notification Service, validita' temporale, revoca, reinvio con rotazione token, accettazione account e completamento del provisioning.
First Admin Bootstrap	Implementato	Cloud Function first-run one-shot per inizializzare il primo amministratore senza credenziali Admin SDK locali.
Admin Provisioning	Implementato, prima slice	Control Center e API protette per creare richieste, monitorare provisioning, listare inviti, reinviare, revocare e consultare audit senza fidarsi del browser.
Membership Admin	Implementato, prima slice	Control Center e API protette per listare Membership, aggiornare stato, ruolo e feature workspaceSync, con audit server-side.
Stripe Test Mode	Futuro	Checkout e webhook verificati che richiedono provisioning e invito, senza creare direttamente utenti o duplicare la logica commerciale.
Business E Partner	Futuro	Provisioning massivo, ruoli, licenze e programmi collegati, mantenendo separati piano, ruolo, entitlements e feature.

Flusso previsto:

flowchart TB
  Sources["Admin / Stripe / Gift / Coupon / Business / Partner"]
  Provisioning["Provisioning Service\nserver-side"]
  ControlCenter["Control Center\nAdmin UI"]
  Invitation["Invitation Service\ninvito e attivazione"]
  Notifications["Notification Service\nBrevo email"]
  Auth["Firebase Authentication"]
  Membership["memberships/{uid}"]
  Features["Feature Flags"]
  Repository["Repository Manager"]

  Sources --> ControlCenter
  ControlCenter --> Provisioning
  Provisioning --> Invitation
  Invitation --> Notifications
  Invitation --> Auth
  Invitation --> Membership
  Membership --> Features
  Features --> Repository

Consolidamento Del Modello Di Dominio

La fase di progettazione del dominio si considera consolidata quando i modelli Developer principali sono allineati:

• Domain Model;
• Identity Model;
• Membership Model;
• Resource Ownership Model.

Da questo punto in avanti le modifiche dovrebbero concentrarsi sull'implementazione progressiva della roadmap, usando il modello consolidato come riferimento e non ridefinendo i confini concettuali a ogni nuovo modulo.

flowchart TB
  Foundation["Foundation"] --> CoreAccount["Core Account System"]
  CoreAccount --> PilotWorkspace["Pilot Workspace"]
  CoreAccount --> DomainModel["Domain Model"]
  DomainModel --> IdentityModel["Identity Model"]
  IdentityModel --> MembershipModel["Membership Model"]
  MembershipModel --> OwnershipModel["Resource Ownership Model"]
  OwnershipModel --> Consolidated["=== MODELLO DEL DOMINIO CONSOLIDATO ==="]

  Consolidated --> Drones["Implementazione Droni"]
  Drones --> Missions["Implementazione Missioni"]
  Missions --> Operators["Operatori"]
  Operators --> Collaboration["Collaborazione"]
  Collaboration --> CloudSync["Sincronizzazione Cloud"]

Fase 3: Dominio Operativo

Questa fase traduce il modello concettuale consolidato in Domain Model operativi.

L'obiettivo non e' ancora costruire workflow avanzati, ma definire oggetti, responsabilita' e confini applicativi per le risorse che formeranno il lavoro quotidiano del pilota e dell'operatore.

Possibili aree di evoluzione:

Area	Descrizione architetturale
Drone Domain	Modello dedicato agli asset UAS, separando dati personali, dati operatore, ownership, stato e configurazioni.
Mission Domain	Modello dedicato alla missione come risorsa operativa collegata ad Active Operator, piloti assegnati, luoghi, droni e report.
Fleet Domain	Modello dedicato a flotte, raggruppamenti di droni, manutenzioni, documentazione e assegnazioni.
Droni DSC+ / Fleet Registry	Servizio avanzato separato dalla scheda Droni Free, con importazione Flight Log, componenti, registro voli e statistiche.
Organization Domain	Modello dedicato a UAS Operator, organizzazioni, ruoli, membership approvate e collaborazione futura.
Active Operator	Risoluzione del contesto operativo corrente, cioe' quale operatore determina asset, workflow, visibilita' e responsabilita' durante il lavoro.

Questa fase deve rispettare Domain Model, Identity Model, Membership Model e Resource Ownership Model. Droni, missioni, flotte, assicurazioni e report non devono essere assorbiti dal Pilot Profile. Quando appartengono a un operatore, devono essere modellati come risorse dell'UAS Operator.

Il risultato atteso e' una base di dominio pronta per Mission Planning, collaborazione, sincronizzazione e servizi DSC+ futuri.

Stato attuale:

• Fase 3 avviata ufficialmente con il Drone Domain;
• il Drone Domain e' implementato come entita' UAS generica, non legata a un modello o produttore specifico;
• i droni appartengono all'UAS Operator personale locale tramite operator.drones;
• la classe C0-C6/Legacy/Privately Built/Unmarked e' una proprieta' tecnica/regolamentare dell'UAS, mentre Open, Specific e Certified restano categorie operative future da determinare nel Mission Domain o nell'analisi operativa;
• il Pilot Profile non possiede droni;
• le collezioni legacy del Workspace non vengono usate per il nuovo Drone Domain;
• non sono stati introdotti Mission Domain, Fleet Management, sincronizzazione cloud continua, collaborazione, merge cloud, risoluzione conflitti o DSC+ operativo.

Servizio DJI Su Hetzner

La direzione aggiornata non prevede piu' l'uso di Open DroneLog come componente di riferimento.

Drone Sky Check dispone gia' di un servizio su Hetzner per la lettura dei log DJI. Questo servizio deve essere trattato come adapter tecnico iniziale per il formato DJI: riceve il file, produce un payload preliminare e rimane separato dal modello di dominio.

Il servizio Droni DSC+ dovra' invece essere il livello prodotto: riconciliazione della flotta, associazione a drone esistente, componenti, record di volo, statistiche e collegamento al contesto operativo Drone Sky Check. Il parser non deve diventare il Fleet Manager.

Flight Log Import E Fleet Registry

La sezione Droni Free dovra' restare una gestione manuale essenziale degli asset. Il servizio Droni DSC+ dovra' evolvere in modo progressivo verso registro tecnico della flotta, registro operativo del pilota e Fleet Manager integrato. La funzione Importa Flight Log oggi collocata nella sezione Droni e' sperimentale e non definisce la collocazione UX finale.

La roadmap specifica per importazione Flight Log e flotta e':

Fase	Obiettivo	Dettagli
Fase 1 - Fondamenta	Preparare il modello senza nuova UI complessa.	Modello normalizzato di importazione, rimozione futura del secret dal client, servizio server-side protetto, identificativo univoco del log, validazione payload.
Fase 2 - Importazione e associazione	Collegare il log al drone corretto.	Importazione generale, creazione drone da log, associazione a drone esistente, riconciliazione conflitti, prevenzione duplicati, risultato visibile all'utente.
Fase 3 - Componenti	Trattare componenti come entita'.	Batterie, radiocomandi e camere riconosciuti per seriale, statistiche di base e storico utilizzo.
Fase 4 - Registro voli	Rendere persistente lo storico operativo.	Record di volo, lista voli, dettaglio volo, statistiche drone e statistiche flotta.
Fase 5 - Contesto operativo	Collegare i voli all'ecosistema Drone Sky Check.	Luoghi, missioni, spazio aereo, NOTAM, AIP/ENR, meteo, autorizzazioni e documentazione operativa, distinguendo dati al momento del volo da dati ricostruiti o attuali.
Fase 6 - Altri formati	Aprire l'architettura oltre DJI.	Adapter indipendenti dal produttore, nuovi formati di log, importazioni multiple, eventuali API o sincronizzazioni esterne.

Menu DSC+

La UX futura dovra' prevedere un menu dedicato ai servizi DSC+. Questo menu non deve essere una copia del Pilot Workspace Free: deve raccogliere servizi avanzati con workflow propri, Feature Flags dedicate e dati persistenti.

Il primo candidato concreto e' Droni DSC+, distinto dalla sezione Droni Free. La scheda manuale Free resta valida e puo' diventare la base da arricchire; il servizio DSC+ aggiunge invece importazione Flight Log, riconciliazione, componenti, storico voli e statistiche.

Vincoli della fase attuale:

• non implementare ancora il modello completo;
• non creare collezioni Firestore definitive;
• non spostare il pulsante sperimentale;
• non modificare comportamento FREE o DSC+;
• non introdurre dati fittizi;
• non presentare come disponibile cio' che e' solo pianificato.

I documenti tecnici di riferimento sono Flight Log Import, Flight Log Analysis e Fleet Registry.

Fase 4: Mission Planning

Questa fase rappresenta il possibile cuore operativo di DSC+.

L'obiettivo e' portare la pianificazione oltre l'analisi del momento corrente, mantenendo coerenza con dati aeronautici, vincoli temporali e servizi avanzati.

La pianificazione futura dovra' distinguere chiaramente tra verifica dello scenario attuale e preparazione di una missione che avverra' in un momento successivo. Drone Sky Check potra' usare solo dati disponibili al momento della pianificazione: ENR e finestre temporali gia' pubblicate, SUP, NOTAM disponibili, meteo o altre sorgenti accessibili. Non dovra' mai presentare come certe informazioni non ancora pubblicate.

Possibili aree di evoluzione:

Area	Descrizione architetturale
Future Planning	Pianificazione di missioni in date e orari futuri, quando i dati disponibili lo consentono.
Timeline missione	Rappresentazione temporale delle fasi operative della missione.
ENR future	Uso di regole temporali e dati aeronautici per valutazioni future, se supportate dai dataset.
Pianificazione	Strumenti avanzati per costruire, salvare e rivedere scenari operativi.
Report PDF	Produzione di documenti strutturati collegati alla missione, quando previsti.

Questa fase dovra' dipendere in modo chiaro da Feature Flags specifiche, evitando controlli generici su DSC+ o membership.

Fase 5: Academy

Questa fase riguarda la possibile area formativa dell'ecosistema.

Academy deve essere considerata un servizio collegabile al Core Account System, al Pilot Workspace e a eventuali programmi o membership, non una dipendenza del nucleo pubblico.

Possibili aree di evoluzione:

Area	Descrizione architetturale
Contenuti	Materiali formativi collegati all'uso consapevole della piattaforma o a temi operativi.
Video	Contenuti video accessibili tramite Feature Flags dedicate.
Webinar	Eventi formativi o sessioni guidate, se previsti.
Percorsi	Organizzazione dei contenuti in sequenze o programmi formativi.

Academy deve restare modulare: puo' essere parte di DSC+, di programmi specifici o di future collaborazioni, senza modificare il nucleo di Drone Sky Check.

Fase 6: Partner Platform

Questa fase riguarda l'apertura controllata dell'ecosistema a servizi esterni.

L'obiettivo e' permettere a partner e integrazioni di aggiungere capacita' senza creare dipendenze dirette nei moduli principali.

Possibili aree di evoluzione:

Area	Descrizione architetturale
Useppo	Esempio di integrazione partner collegabile tramite contratti logici e Feature Flags.
Altri partner	Servizi esterni futuri, aggiungibili o rimovibili senza modificare il nucleo pubblico.
API	Interfacce controllate per esporre o consumare capacita' della piattaforma.
Integrazioni	Collegamenti tra Core Account System, Pilot Workspace, servizi partner e funzionalita' abilitate.

I partner devono essere progettati come servizi collegabili. La piattaforma deve poter disabilitare, sostituire o rimuovere un'integrazione mantenendo stabile l'esperienza pubblica.

Fase 7: Ecosistema Della Piattaforma

Questa fase descrive l'evoluzione finale verso un ecosistema di piattaforma piu' ampio.

L'obiettivo e' collegare dati, dispositivi, servizi realtime, cloud e integrazioni mantenendo separati nucleo pubblico, Core Account System, Pilot Workspace, UAS Operator, Feature Flags e servizi esterni.

Possibili aree di evoluzione:

Area	Descrizione architetturale
Mini Tracker	Possibile dispositivo o servizio collegato al Pilot Workspace e ai flussi operativi.
AirSense	Possibile componente dell'ecosistema per consapevolezza operativa o dati specializzati.
API	Interfacce controllate per esporre o consumare capacita' della piattaforma da client, partner o servizi autorizzati.
Integrazioni esterne	Collegamenti con partner o servizi verticali senza dipendenze dirette nel nucleo pubblico.
Servizi realtime	Capacita' dinamiche collegate a stato, posizione, notifiche o monitoraggio.
Cloud	Persistenza remota, sincronizzazione e continuita' multi-dispositivo dove abilitati da DSC+. Backup versionati e ripristino restano capacita' future dedicate.
Team	Possibile gestione di piu' utenti o ruoli collegati a uno scenario operativo.
Collaborazione	Condivisione controllata di missioni, report, dispositivi o workflow.

Questa fase richiede che le basi precedenti siano solide: Core Account System, identita', Pilot Workspace, Active Operator, ownership delle risorse, Feature Flags, Partner Integration e confini tra servizi devono essere gia' chiari.

Relazione Tra Le Fasi

flowchart TB
  Core["Core Account System"]

  Core --> Workspace["Pilot Workspace"]
  Core --> Profile["Pilot Profile"]
  Core --> Operator["UAS Operator"]
  Core --> Membership["Membership"]
  Core --> Flags["Feature Flags"]
  Core --> FutureDomains["Domini futuri"]

  Workspace --> Context["Operational Context\ncomposizione temporanea"]
  Profile --> Context
  Operator --> Context
  Membership --> Context
  Flags --> Context
  FutureDomains --> Context

  Context --> AuthorizationConsumer["Authorization\nprimo consumer"]
  Context --> MissionPlanning["Mission Planning"]
  Context --> Logbook["Logbook"]
  Context --> Reports["Report"]
  Context --> Api["API"]
  Context --> PartnerPlatform["Partner Platform\nUSEPPO"]
  Context --> DscPlusServices["Servizi DSC+"]

  Operator --> OperationalDomain["Dominio Operativo\nDroni, missioni, flotte"]
  OperationalDomain --> MissionPlanning
  MissionPlanning --> FuturePlanning["Future Planning"]
  DscPlusServices --> Academy["Academy"]
  DscPlusServices --> DscDrones["Droni DSC+\nFleet e Flight Log"]
  PartnerPlatform --> PlatformEcosystem["Ecosistema Piattaforma"]

La fase Foundation sostiene tutte le altre attraverso il Core Account System. Il Pilot Workspace e' il principale punto di accesso personale del pilota, mentre Pilot Profile, UAS Operator, Membership e Feature Flags restano domini indipendenti. L'Operational Context compone questi domini per i moduli operativi. Il Tool Authorization consuma per primo questo contesto, ma non lo possiede e non rappresenta l'evoluzione del Workspace. DSC+ e Feature Flags permettono di abilitare servizi diversi a contesti diversi senza modificare l'architettura di base.

Confini Del Documento

Questa sezione non definisce:

• date di rilascio;
• priorita' definitive;
• funzionalita' gia' disponibili;
• condizioni commerciali;
• implementazioni tecniche;
• scelte di provider o infrastruttura;
• elenco finale dei servizi DSC+.

La roadmap definisce una direzione: far evolvere Drone Sky Check come piattaforma modulare, mantenendo il nucleo pubblico accessibile e costruendo i servizi avanzati in modo progressivo e coerente.

Principi Architetturali Permanenti

Questi principi restano validi per tutte le fasi della roadmap:

Principio	Regola
Domain Model come guida	L'implementazione deve seguire il modello di dominio consolidato, non ridefinirlo implicitamente nei singoli moduli.
Repository intercambiabili	LocalStorage, repository cloud o altri repository futuri devono rispettare contratti stabili e sostituibili.
Service indipendenti dalla persistenza	I service applicativi devono lavorare sul Core Context e non conoscere il repository concreto.
Core Account System come centro	Il Core Account System aggrega domini separati e rende possibile un Operational Context condiviso.
Pilot Profile distinto dal Workspace	Il Pilot Profile descrive la Persona; il Pilot Workspace contiene il contesto personale e operativo del pilota.
UAS Operator proprietario degli asset	Droni, flotte, assicurazioni, missioni, documentazione e report operatore appartengono all'UAS Operator, anche quando l'operatore e' personale.
Tool come consumer del contesto	Authorization, Mission Planning, Future Planning, Logbook, Report, USEPPO, API e servizi futuri devono leggere il contesto comune e non duplicare dati permanenti.
Feature Flags per le capacita'	Le capacita' avanzate devono essere abilitate tramite flag specifiche, non tramite controlli generici su membership o piani.
Nucleo pubblico accessibile	Drone Sky Check deve restare utilizzabile anche senza autenticazione obbligatoria, abbonamento o servizi cloud.
Adapter tecnici separati dal dominio	Servizi come il parser DJI su Hetzner devono restare adapter tecnici incapsulati; il dominio flotta, i voli e il contesto operativo appartengono a Drone Sky Check.

Ogni nuova implementazione deve preservare questi confini, cosi' l'evoluzione verso Droni, Missioni, Operatori, collaborazione, DSC+ e servizi di piattaforma resta progressiva e coerente.

Strategia Di Sviluppo

Una volta consolidato il modello del dominio, ogni nuova funzionalità dovrà essere implementata seguendo un processo coerente.

L'obiettivo è evitare che il codice evolva più velocemente dell'architettura o che la documentazione perda allineamento con l'implementazione.

L'ordine di sviluppo raccomandato è il seguente:

1. aggiornamento del Domain Model (solo se realmente necessario);
2. implementazione del Domain Model JavaScript;
3. implementazione del Service dedicato;
4. integrazione con il Repository (quando previsto);
5. aggiornamento ed estensione dei Self Test del Core;
6. implementazione della UI;
7. integrazione con il resto della piattaforma;
8. aggiornamento della documentazione.

Seguire sempre questo ordine permette di mantenere coerenti architettura, codice e documentazione durante tutta l'evoluzione della piattaforma.

Checklist Implementativa

Ogni nuovo modulo della piattaforma dovrebbe seguire la stessa checklist di sviluppo.

Questa lista non rappresenta un vincolo assoluto, ma una guida per mantenere uniforme l'architettura del progetto.

Nuovo Domain

• ☐ Verifica del Domain Model Developer
• ☐ Eventuale aggiornamento della documentazione architetturale
• ☐ Domain Model JavaScript
• ☐ Service dedicato
• ☐ Verifica dell'impatto sul Repository
• ☐ Self Test del Core
• ☐ Interfaccia utente
• ☐ Integrazione con Core Account System e Operational Context
• ☐ Aggiornamento della documentazione utente
• ☐ Aggiornamento della Roadmap (se necessario)

Questa checklist verrà utilizzata per tutti i futuri moduli della piattaforma, ad esempio:

• Drone Domain
• Mission Domain
• Fleet Domain
• Organization Domain
• Report Domain
• Authorization Domain