flightplanner/TODO.md

TODO — flightplanner

État d'avancement entre sessions. Cocher au fur et à mesure.

Étape 1 — Workspace Cargo ✅ (en cours de validation)

• Workspace Cargo.toml (members core + cli, deps partagées)
• Crate flightplanner-core (lib) : error, model, stubs navdata/db/routing/perf/export
• Crate flightplanner-cli (bin flightplanner) : clap, sous-commandes import-navdata / route (stub)
• Profils avions data/aircraft/{a320,b738}.json
• README, TODO, .gitignore, rust-toolchain
• cargo build + cargo test verts, clippy -D warnings propre, fmt --check OK
• Point d'arrêt : validation utilisateur

Étape 2 — Parsing navdata + import SQLite ✅ (en cours de validation)

• Format figé depuis les vrais fichiers (fix 1101, nav 1150, awy 1100 + coords CIFP)
• Parsers streaming ligne-à-ligne (navdata/{fix,nav,airway,airport}.rs)
• Schéma SQLite : airports, waypoints, navaids, airways, airway_segments
• Import bulk transactionnel (db::import_navdata)
• Aéroports dérivés des seuils de piste CIFP (centroïde = point de référence)
• Fixtures faites main + tests unitaires parsing + test intégration end-to-end
• Câbler import-navdata dans le CLI
• Import réel vérifié : 250 762 wpt / 7 923 navaids / 121 884 segments awy
• Point d'arrêt : validation utilisateur

Note : n'ont été extraits du CIFP que LFPG.dat/EGLL.dat (→ 2 aéroports). Pour tous les aéroports, extraire tout le dossier CIFP/ de l'archive.

Étape 3 — Routing ✅ (en cours de validation)

• Construction graphe petgraph depuis SQLite (routing/graph.rs)
• A* airways (heuristique great-circle) + connexion dep/dest aux points proches (DCT)
• Fallback direct great-circle si pas de chemin
• Test bout-en-bout LFPG→EGLL sur fixtures + gestion aéroport inconnu
• Câbler route dans le CLI
• Vérifié sur vraies données : LFPG DCT PON UT300 … MID UM185 MODMI DCT EGLL (12 legs, 236 nm)
• FL-aware : filtrage des airways par bande base/top selon le FL de croisière (build(conn, Some(fl))) → routes cohérentes qui passent le pré-check IFPS
• Point d'arrêt : validation utilisateur
• (idée) collapse des legs consécutifs d'un même airway à l'affichage

Étape 4 — Performance / carburant ✅ (en cours de validation)

• Struct AircraftProfile (serde) + chargement data/aircraft/<icao>.json
• Modèle 3 phases (montée/croisière/descente) réparti sur la distance
• Temps/carburant par segment + cumul + réserves (taxi/contingence/finale/alternate)
• route --aircraft A320 [--alternate] [--cruise-fl] dans le CLI
• Tests (couverture distance, block>trip, vol court sans croisière, chargement profil)
• Point d'arrêt : validation utilisateur

Étape 5 — Export ✅ (MVP bouclé)

• .pln (MSFS/P3D, AceXML) avec ATCWaypoint + ATCAirway
• .fms (X-Plane 11, v1100) avec ADEP/ADES/NUMENR
• OFP texte (route, table legs dist/ETE/fuel/cumul, réserves, block)
• Câblé au CLI : route … --pln f.pln --fms f.fms --ofp
• Test end-to-end export (pln/fms/ofp)

Étape 6 — Moteur de perf physique OpenAP 🔧 (en cours — cap : remplaçant PFPX)

Objectif : sortir du fuel_flow_kgph fixe et calculer la conso par la physique (atmosphère ISA + polaire de traînée + TSFC), comme BADA/OpenAP.

• perf/openap.rs : atmosphère ISA, polaire CD = CD0 + k·CL², débit = TSFC·traînée
• Coefficients réels OpenAP embarqués (A320/CFM56-5B4, B738/CFM56-7B26) dans les JSON avion (openap{})
• Débit fonction de la masse et du FL ; câblé dans compute_fuel_plan (non-cassant, fallback si pas d'openap)
• Tests : ISA vs valeurs connues, croisière A320 réaliste (~2000 kg/h @FL350), + lourd = + conso, + haut = - conso, plancher idle en descente
• Vérifié sur route réelle : courbe d'altitude optimale (min conso ~FL360, remonte à FL390)
• Masse réelle : --payload au CLI, ZFW/TOW/LDW calculés, itération point-fixe du block-fuel (masse ← OEW+payload+carburant), alertes MTOW/MLW ; masses au print + OFP. Vérifié : trip fuel monte avec la charge (LFPG→EGLL : 1736→1959 kg de 8t à 20t)
• Profil de montée/descente intégré par tranches d'altitude (au lieu d'une altitude médiane)
• Traînée de compressibilité (wave drag) près du Mach de croisière
• TSFC calibrée par phase (idle/approche/climb depuis les points ICAO du moteur)
• (option) brancher les datasets BADA 4 derrière la même interface PerfModel si licence EUROCONTROL obtenue

Étape 7 — GUI desktop (Tauri + React + Fluent UI) 🖥️ (en cours)

Fenêtre native (WebView2, PAS un navigateur). Règle : aucun CSS/style écrit à la main — on utilise le design system Fluent UI (Microsoft, look Windows 11). gui/ = frontend React/TypeScript (Vite) ; gui/src-tauri/ = backend Rust (flightplanner-gui, membre du workspace). Lancer : cd gui ; npm run tauri dev.

• Scaffold Tauri v2 (react-ts) intégré au workspace, WebView2 présent
• Fluent UI (@fluentui/react-components) : FluentProvider suit le thème clair/sombre de l'OS ; composants standards (Field/Input/Select/Card/Table/Badge/MessageBar) → zéro style maison, juste de la mise en page via les tokens
• Commande plan : pont vers core (route + fuel plan) via DTO sérialisables
• Formulaire : dep/dest, avion, cruise FL, payload, alternate, sources data (DB/profils)
• Résultats : route string, cartes (trip/block/réserves), bandeau masses (payload/ZFW/TOW/LDW + alertes MTOW/MLW), table des legs (dist/ETE/fuel/cum)
• cargo check propre sur flightplanner-gui, frontend npm run build (tsc) OK
• Carte (MapLibre) avec tracé de la route + waypoints
• Sélecteurs d'aéroport avec autocomplétion depuis la DB (Combobox Fluent)
• Boutons export (.pln/.fms/OFP) + copier route
• Écran réglages (chemin DB, cycle AIRAC, unités kg/lb)
• Bundler une DB navdata + packaging installeur (tauri build)

Plus tard (hors MVP)

• UI web locale (Axum) → remplacé par GUI Tauri (étape 7)
• Météo, cycles AIRAC automatiques
• Check IFPS :
  • Pré-validateur offline (core::ifps) : point existe / sur airway, sens, bande FL, DCT, continuité + CLI ifps-check et route --check-ifps
  • Validateur autoritatif online Autorouter (le vrai « fiable ») — voir IDEAS.md
• Vision produit complète (briefing type SkyNexus/SimBrief) → voir IDEAS.md