# Drone Mission Control (DMC) — Architektur- und Design-Dokumentation

> Zusammenfassung aller bisher in diesem Projekt getroffenen Architektur- und Design-Entscheidungen: vom HTML/JS-Demonstrator ("Drone Mission Command.html") bis zur geplanten Flutter-Zielarchitektur.

---

## 1. Projektüberblick

**Ziel:** Mobile App zur Missionsplanung und Flugsteuerung für einen Fixed-Wing-Drohnen-Aufbau (Heewing T1 Ranger, iNAV-Firmware), mit Fokus auf Wegpunkt-Missionen, Live-Fly-Modus und Point-and-Fly (PnF)-Einzelziel-Anflug.

**Zwei Entwicklungsstränge:**
1. **HTML/JS-Demonstrator** (`Drone Mission Command.html`, vormals `taf_mission_planner_osm_v13.html`) — iteratives Rapid-Prototyping zur Validierung von Workflow und Feature-Umfang, lauffähig im Browser.
2. **Flutter-Zielarchitektur** — die für die produktive App geplante Struktur, die den Demonstrator ablösen soll.

**Sprachregelung:** Konversation und Dokumentation auf Deutsch, Code und UI-Texte auf Englisch.

---

## 2. Systemarchitektur (Flutter-Zielarchitektur)

Fünf-Schichten-Architektur, gemeinsam festgelegt:

```
┌─────────────────────────────────────────────┐
│  UI Layer (Screens: Plan / Fly / Settings /  │
│  Library)                                    │
├─────────────────────────────────────────────┤
│  App-Mode State Machine                      │
│  (Plan → Connect → Upload → Fly)             │
├─────────────────────────────────────────────┤
│  Mission Domain Layer                        │
│  (Strategy Pattern: TrackMission,             │
│  SurveyAreaMission*, SearchAreaMission*)      │
├─────────────────────────────────────────────┤
│  Mission-Sync Service  │  Telemetry Service   │
├─────────────────────────────────────────────┤
│  Transport / Protokoll-Layer                 │
│  (FlightControllerLink-Abstraktion)          │
└─────────────────────────────────────────────┘
```
\* geplant, noch nicht implementiert

### 2.1 Kernprinzip: Protokoll-Abstraktion
Ein einheitliches Interface `FlightControllerLink` kapselt die Kommunikation mit dem Flightcontroller, unabhängig davon, ob iNAV (via MSP) oder ArduPilot (via MAVLink) angesprochen wird. Die Mission-Domain-Schicht kennt nur eine protokollneutrale `FlatWaypointList`; die Divergenz zu MSP bzw. MAVLink findet ausschließlich im letzten Schritt (Encoder) statt.

### 2.2 App-Mode State Machine
Explizite Zustandsfolge: **Plan → Connect → Upload → Fly**, inkl. definiertem "Ready-to-Fly"-Gate:
> Mission hochgeladen **und** verifiziert **und** Drohne noch disarmed.

Grund: iNAV (und MAVLink bei iNAV) akzeptiert `MSP_SET_WP`-Uploads grundsätzlich nur im **unarmed**-Zustand. Der Handover-Prozess (Connect → Verify → Upload → Ready-to-Fly) muss dieses Gate technisch erzwingen, nicht nur als UI-Konvention behandeln.

---

## 3. Komponenten

### 3.1 `FlightControllerLink` (Interface)
Zentrale Abstraktion für alle FC-Interaktionen.

**Methoden/Properties:**
- `connect()`, `disconnect()`
- `capabilities` → `FcCapabilities`-Struct (Feature-Flags: `supportsMultiMission`, `supportsInFlightUpload`, `maxWaypoints`, …)
- `uploadMission(FlatWaypointList)`
- `setFlightMode(mode)` — abstrakte Modus-Konstanten: `MISSION_RUN`, `GUIDED_POINT`, `RETURN_HOME`, `HOLD`
- `arm()`
- `subscribeTelemetry()`
- `readActiveWaypointIndex()`

**Implementierungen:**
- `MspFlightControllerLink` — für iNAV, eigenständiger MSP-Adapter (kein fertiges Dart-Paket verfügbar, komplett selbst implementiert)
- `MavlinkFlightControllerLink` — für ArduPilot (perspektivisch, nicht MVP)
- `MockFlightControllerLink` — synthetische Telemetrie für Tests ohne Hardware/SITL

### 3.2 Mission Domain Layer
Strategy-Pattern für erweiterbare Missionstypen:
- `TrackMission` — aktuell implementiert (Wegpunkt-Strecke)
- `SurveyAreaMission` — geplant (Flächenabflug)
- `SearchAreaMission` — geplant (Suchmuster)

Gemeinsame Datenstruktur: `FlatWaypointList` (protokollunabhängig), am Ende protokollspezifisch codiert durch:
- `MspWaypointEncoder` (iNAV)
- `MavlinkMissionEncoder` (ArduPilot)

### 3.3 Mission-Sync Service
Orchestriert den Ablauf Connect → Verify → Upload → Ready-to-Fly. Erzwingt das Ready-to-Fly-Gate.

### 3.4 Telemetry Service
Abonniert Live-Telemetrie vom FC, liefert normalisierte `TelemetryFrame`-Objekte an die UI. Läuft in einem eigenen **Isolate**, um Kartenrendering nicht zu blockieren.

### 3.5 Drohnen-Profil (Settings)
Enthält u. a.:
- **FC-Typ** — bewusst als explizites Setting im Drohnen-Profil verankert, **nicht** aus dem Transportkanal abgeleitet (siehe Abschnitt 4.3)
- Flugleistungsdaten: min/max Speed, min. Kurvenradius, max. Steig-/Sinkrate, max. Reichweite, max. Flugdauer, Cruise Speed
- Standardprofil: **T1 Ranger** (Heewing)
- Liste mehrerer Profile, aufrufbar über Tap, Teil des Vollbild-Menüs (gemeinsam mit Missionsübersicht, per Tabs umschaltbar)

### 3.6 Waypoint-Liste (UI-Komponente)
- Spalten: **Execute** (Dropdown: —/Loiter/Landing) und **Action**
- Swipe-adjustierbare Wertechips für Alt/Speed/Catch-Radius (vertikal ±10, horizontal ±1, 14px/Step, Achsen-Lock bei 8px)
- Zeilen-Edit-Modus bewusst **entkoppelt** vom Karten-Edit-Modus (siehe Abschnitt 4.4)
- Zeile antippen → Karte zentriert auf diesen Wegpunkt, Liste schließt sich
- Liste zeigt englische Spaltenüberschriften, ausreichend Randabstand zu den Drehrädern
- Automatisches Beenden des Zeilen-Edit-Modus beim Schließen der Liste (Sicherung gegen inkonsistenten Zustand)

### 3.7 Flugpfad-Darstellung
- Kein einfacher Spline durch alle Punkte, sondern physikalisch fundierte Geometrie: **Geradenstücke + tangentiale Kreisbögen (Fillets)** pro Kursänderung, abgeleitet aus Geschwindigkeit + max. Schräglage (25°)
- Machbarkeitsprüfung kombiniert Tangentenlänge der Kurve mit dem Fangradius (60 m): überschreitet die Tangentenlänge den Fangradius, wird der Turn rot markiert
- Höhenprofil-Anzeige in der unteren Leiste

### 3.8 Wind-System
- `buildCombinedWindLevels()` — vereint Druckflächendaten und feste Nabenhöhen (10/80/120/180 m AGL, in ASL umgerechnet) als Stützpunkte für Interpolation
- `windUrlsFor()` — baut zwei getrennte, fokussierte Open-Meteo-Requests
- Alle drei Konsumenten (Header, Waypoints, Validierungspanel) nutzen denselben Mechanismus
- Böen (`wind_gusts_10m`) nur im Validierungspanel, nicht in der Wegpunktanzeige

### 3.9 Terrain-System
- Distanzbasierte Sampling-Strategie: alle 30 m (`TERRAIN_SAMPLE_SPACING`), min. 10 / max. 2000 Samples (`TERRAIN_MAX_SAMPLES`)
- Einzelpunkt-Höhenabfrage (`fetchElevationAt`) für Point-and-Fly-Kollisionsprüfung
- Datenquelle: AWS Terrarium Tiles

### 3.10 Point-and-Fly (PnF) Modus
- Zentrales Fadenkreuz (amber) auf dem Bildschirm
- Setzt transienten Einzel-Wegpunkt (Loiter-Aktion) mit aktuellen Radwerten für Alt/Speed
- Terrain-Kollisionsprüfung: mind. 60 m Bodenabstand, referenziert gegen Home-Wegpunkt-Höhe
- Zielpunkt übernimmt beim Setzen die zu diesem Zeitpunkt gültigen Radwerte dauerhaft (ändert sich nicht rückwirkend)
- Zielpunkt verschwindet beim Moduswechsel oder Verlassen des Fly-Modus
- Zentrale Sichtbarkeitslogik über ein gemeinsames Prädikat (Räder, Fadenkreuz, Readouts konsistent)

### 3.11 Fly-Modus allgemein
- `setFlightMode()` zentralisiert
- Eintritt in Fly-Modus setzt immer auf Standardmodus **Waypoint** zurück
- Verlassen des Fly-Modus klappt Dropdown automatisch ein
- Readouts: drei Zeilen (Titel, SET in Blau, LIVE in Grün)

### 3.12 Branding/Logo
- M-/D-/C-Monogramm-Konstruktion (Drone Mission Command)
- Finale Lösung: vertikal gespiegeltes "C" mit kurzem vertikalem Schließstrich statt verjüngtem "D" — mathematisch als Sonderfall derselben Tangentenkonstruktion bestätigt (Stammlänge 75,2 Einheiten, 92,4 % bilaterale Symmetrie)

---

## 4. Getroffene Design-Entscheidungen inkl. Begründung

| # | Entscheidung | Begründung |
|---|---|---|
| 4.1 | **MVP-Scope: nur Android, nur iNAV via MSP, nur WiFi/TCP** | Reduziert Komplexität für ersten Release; MAVLink, USB-Seriell und iOS werden bewusst zurückgestellt |
| 4.2 | **MSP für iNAV, MAVLink für ArduPilot**, beide hinter `FlightControllerLink` | Jedes Protokoll spricht die native Sprache seines FC; einheitliche Domain-Schicht bleibt protokollunabhängig |
| 4.3 | **FC-Typ als explizites Setting im Drohnen-Profil**, nicht aus Transport abgeleitet | Zukunftssicher: falls iNAV später testweise über MAVLink läuft, bleibt Zuordnung eindeutig steuerbar |
| 4.4 | **Zeilen-Edit-Modus der Wegpunktliste von Karten-Edit-Modus entkoppelt** | Nutzer-Feedback: gekoppeltes Verhalten war unerwartet/unerwünscht — Bearbeiten in der Liste soll nicht automatisch den Karten-Modus verändern |
| 4.5 | **"Ready-to-Fly"-Gate = Upload + Verifiziert + Disarmed** | iNAV/MAVLink erlauben grundsätzlich keinen Missions-Upload im armed-Zustand; das Gate muss dies technisch erzwingen |
| 4.6 | **Physikalisch fundierter Flugpfad (Geraden + Kreisbögen) statt Spline** | Ehrlichere Darstellung dessen, was ein realer Autopilot (ArduPlane/iNAV) tatsächlich fliegt; verhindert falsches Sicherheitsgefühl bei engen Kurven |
| 4.7 | **Tangentenkonstruktion statt frei gezogener Linien beim Logo** | Vermeidet sichtbaren Knick zwischen Gerade und Bogen; mathematisch konsistent mit der ursprünglichen D-Form |
| 4.8 | **Gespiegeltes C statt verjüngtem D als Logo-Grundform** | Wirkt symmetrischer, ist aber dieselbe Konstruktion nur gespiegelt und geschlossen |
| 4.9 | **Böen nur im Validierungspanel, nicht in der Wegpunktanzeige** | 10-m-Böendaten sind auf Flughöhe nicht aussagekräftig |
| 4.10 | **Zwei getrennte Open-Meteo-Requests statt einem kombinierten** | Ein kombinierter 35-Variablen-Request verursachte Modellauswahl-Fehler; auch ein einzelner Request für die Validierung schlug fehl — zwei fokussierte Requests bestätigt als robustes Muster |
| 4.11 | **`typeof x === 'number'`-Guards überall im Wind-Code** | Open-Meteo liefert bei fehlenden Werten `null`, nicht `undefined` — ungeschützter Code führte zu drei aufeinanderfolgenden Rendering-Fehlern |
| 4.12 | **Distanzbasiertes statt festes Terrain-Sampling (30 m Spacing)** | Gleichmäßigere Auflösung unabhängig von der Missionslänge, mit sinnvollen Ober-/Untergrenzen (10–2000 Samples) |
| 4.13 | **Fester Dateiname "Drone Mission Command.html"** | Bewusst beibehalten, um `localStorage`-Daten über Updates hinweg zu erhalten |
| 4.14 | **Klettersteigungsprüfung nutzt geradlinige statt Bogen-Distanz** | Bewusste Vereinfachung; als vernachlässigbar bewertet, aber offen dokumentiert (siehe Abschnitt 6) |
| 4.15 | **Drift statt Hive für Missions-Persistenz (Flutter-Ziel)** | Indexierte Abfragen nötig (Suche nach Name, Ort, Datum); zudem kompatibel mit künftigem local-first Server-Sync-Muster (Dirty-Flags, Server-IDs) |
| 4.16 | **Bloc/Riverpod-Kombination für State-Management (Flutter-Ziel)** | Bloc passt zur expliziten App-Mode-State-Machine (erzwungene Event→State-Struktur, Debug-Tooling); Riverpod ist ergonomischer für viele kleine reaktive Zustände wie Telemetriewerte |
| 4.17 | **`flutter_map` statt `google_maps_flutter` (Flutter-Ziel)** | Freies OSM-Tile-Modell entspricht dem Leaflet-Demonstrator; anderes Lizenz-/API-Modell bei Google Maps unerwünscht; ermöglicht direkte Portierung der Tangenten-Bogen-Geometrie |
| 4.18 | **`flutter_map_tile_caching` (FMTC) für Offline-Kacheln (Flutter-Ziel)** | Automatisches Caching pro Mission, gekeyt über die Bounding-Box der Mission |
| 4.19 | **Eigener MSP-Encoder/Decoder in Dart (Flutter-Ziel)** | Kein fertiges Dart-Paket verfügbar; Struktur bereits aus MSP-Recherche bekannt |
| 4.20 | **Foreground Service (Android) für Telemetrie im Hintergrund (Flutter-Ziel)** | Ohne Foreground Service + Wake Lock würde Android die Verbindung bei App-Wechsel/Display-Sperre kappen |
| 4.21 | **Protokoll-Parsing in eigenem Isolate (Flutter-Ziel)** | Verhindert UI-Ruckeln bei hoher Telemetrie-Rate; Isolates kommunizieren nur über Message-Passing, kein Shared Memory |
| 4.22 | **Mission-Domain-Layer + Protokoll-Adapter als eigenständiges reines Dart-Package (Flutter-Ziel)** | Isoliert unit-testbar ohne Emulator; wiederverwendbar für z. B. CLI-Tools oder Backend-Simulatoren |
| 4.23 | **`go_router` für Navigation (Flutter-Ziel)** | Typisierte Übergänge, passend zum expliziten Mode-Wechsel-Trigger der State-Machine |

---

## 5. Verworfene Alternativen

| Verworfene Option | Warum nicht gewählt |
|---|---|
| **Spline/Glättungskurve durch alle Wegpunkte** | Suggeriert unrealistische Kurvenradien; ersetzt durch Geraden+Kreisbögen-Modell (4.6) |
| **Freie Linienführung beim Logo (statt Tangentenkonstruktion)** | Hätte sichtbaren Knick zwischen Gerade und Bogen erzeugt |
| **Verjüngtes "D" als finale Logoform** | Wirkte weniger symmetrisch als gespiegeltes/geschlossenes "C" (Farbschwerpunkt-Analyse: −27,2 → −22,7 Einheiten Verbesserung) |
| **Kombinierter 35-Variablen-Wetter-Request** | Verursachte Modellauswahl-Fehler bei Open-Meteo |
| **Einzelner Request für das Wind-Validierungspanel** | Ebenfalls fehlgeschlagen; bestätigte die Notwendigkeit des Zwei-Request-Musters |
| **Gekoppelter Zeilen-/Karten-Edit-Modus** | Erste Implementierung koppelte beide Modi; nach Nutzer-Feedback explizit wieder entkoppelt |
| **Böen-Anzeige auch in der Wegpunktliste** | Als nicht aussagekräftig auf Flughöhe verworfen, in Validierungspanel belassen |
| **`dart_mavlink`-Community-Paket unkritisch übernehmen** | Nicht offiziell gelistet, wirkt wenig gepflegt — Alternative (eigener Generator aus MAVLink-XML) als Option offengehalten, aber noch nicht entschieden |
| **Feste Anzahl Terrain-Samples (z. B. 50)** | Ungleichmäßige Auflösung je nach Missionslänge; durch distanzbasiertes Sampling ersetzt |
| **USB-Seriell als Transportkanal (aktuell)** | Auf iOS ohne MFi-Zertifizierung praktisch nicht machbar; für aktuellen WiFi-Bridge-Plan nicht kritisch, aber als Plattformrisiko vermerkt, falls später gewünscht |
| **Auto-Erkennung des FC-Typs aus der Transportverbindung** | Weniger robust/eindeutig als explizites Profil-Setting (4.3) |
| **Hive für Missions-Persistenz (ursprünglich vorgeschlagen)** | Ausreichend für aktuellen Funktionsumfang, aber keine indexierten Abfragen — zugunsten von Drift verworfen, sobald Suche/Sync-Anforderungen klar wurden |

---

## 6. Offene Fragen / TODOs

- **Klettersteigungsprüfung gegen tatsächliche Bogenlänge statt Geradenverbindung berechnen** — aktuell bewusste Vereinfachung, könnte bei engen Kombinationen aus Höhenänderung und scharfer Kurve leicht zu optimistisch sein.
- **iNAV-10-Änderungen an Mission-/Wegpunktsystem** — zum Recherchezeitpunkt keine bestätigten grundlegenden Änderungen gegenüber v9 gefunden; Release-Termin (evtl. Ende 2026) und Feature-Freeze noch offen, vor App-Release erneut prüfen.
- **Experimenteller iNAV-Community-Branch für Wegpunkt-Upload im Flug (bei nicht aktivem NAV-WP-Modus)** — Status unklar, ob in einen stabilen Release gewandert; vor Release gegen aktuelle 9.x-Firmware verifizieren, nicht darauf verlassen.
- **`dart_mavlink`-Paket vs. eigener Generator aus MAVLink-XML-Dialektdateien** — Entscheidung für die MAVLink-Anbindung (nicht MVP-kritisch, aber für spätere ArduPilot-Unterstützung relevant) noch offen.
- **XR1-Empfänger-Kompatibilität mit mLRS** — XR4 ist vom mLRS-Team offiziell validiert, XR1 nur wahrscheinlich kompatibel (über generisches Firmware-Target), nicht bestätigt.
- **iOS-Hintergrundverbindung** — Konzept (Background Modes / "voip"/"location"-Capability) benannt, aber nicht MVP-relevant (MVP ist Android-only) und nicht im Detail ausgearbeitet.
- **USB-Seriell als späterer Fallback-Transportkanal** — Plattformrisiko (iOS ohne MFi quasi unmöglich) früh klären, falls dies später doch gewünscht wird.
- **Melos-Monorepo vs. Einzelpaket-Struktur** — konkreter Ordner-/Package-Vorschlag für das Flutter-Projekt wurde als nächster Schritt vorgeschlagen, aber noch nicht ausgearbeitet.
- **`SurveyAreaMission` und `SearchAreaMission`** — als Missionstypen im Strategy-Pattern vorgesehen, aber inhaltlich noch nicht spezifiziert oder implementiert.
- **Winkelannahmen der Flugpfad-Machbarkeitsprüfung (25° Schräglage, 20° Steigwinkel)** — zur Diskussion gestellt, ob diese Werte angepasst werden sollen; keine endgültige Entscheidung dokumentiert.
- **Migration vom HTML-Demonstrator zur Flutter-App** — Reihenfolge/Umfang der Portierung (z. B. wann welches Feature 1:1 übernommen wird) ist nicht Schritt-für-Schritt festgelegt.

---

## 7. Umfangreiche Feature-Liste

### 7.1 Missionsplanung
- Wegpunkt-Missionen (Track-Missionen) auf OSM-Kartenbasis (Leaflet.js im Demonstrator)
- Wegpunkt hinzufügen/verschieben/löschen direkt auf der Karte
- Wegpunktliste mit swipe-adjustierbaren Werten für Höhe, Geschwindigkeit, Fangradius (Catch-Radius)
- Execute-Aktion pro Wegpunkt: —, Loiter, Landing
- Zeilen-Edit-Modus unabhängig vom Karten-Edit-Modus
- Tippen auf Listenzeile zentriert Karte auf diesen Wegpunkt
- Automatisches Schließen des Edit-Modus beim Schließen der Liste
- Höhenprofil-Anzeige der gesamten Wegpunktliste in der unteren Leiste
- Physikalisch realistische Flugpfad-Darstellung (Geraden + Kreisbögen statt Spline)
- Farbliche Markierung nicht machbarer Kurven (Tangentenlänge > Fangradius)
- Klettersteigungs-/Sinkraten-Prüfung pro Streckenabschnitt
- JUMP-Wegpunkt-Unterstützung für Patrouillen-/Loop-Missionen (iNAV Action-Code 6, mit Wiederholzähler inkl. Endlos-Option)
- Mehrfach-Missionsverwaltung (bis zu 9 Missionen im FC speicherbar, iNAV-seitig)
- Aktiven Wegpunkt live aus FC auslesen und in der Liste hervorheben (`MSP_NAV_STATUS`/`wp_number`)
- Adressensuche/Geocoding (Nominatim)
- Terrainprofil entlang der Mission (AWS Terrarium Tiles, distanzbasiertes Sampling)

### 7.2 Flugbetrieb (Fly-Modus)
- Umschaltbare Flugmodi: Waypoint, Point-and-Fly, weitere abstrahiert über `MISSION_RUN`/`GUIDED_POINT`/`RETURN_HOME`/`HOLD`
- Standard-Rückstellung auf Waypoint-Modus beim Eintritt in Fly-Modus
- Live-Telemetrie-Anzeige (SET- vs. LIVE-Werte für Höhe/Geschwindigkeit)
- Drehräder (Wheels) zur Live-Anpassung von Soll-Höhe/-Geschwindigkeit
- Point-and-Fly: zentrales Fadenkreuz, Einzelziel setzen ohne bestehende Mission zu verändern
- Terrain-Kollisionsprüfung bei PnF (Mindestabstand 60 m über Grund)
- Persistente Zielpunkt-Beschriftung mit zum Setzzeitpunkt gültigen Werten
- Wind-Anzeige nach Höhe interpoliert (10/80/120/180 m AGL + Druckflächendaten)
- Wind-Validierungspanel mit Böen-Anzeige
- Home-Button (zentriert an der oberen Bildschirmkante)
- Maximieren-Button mit Mindestabstand zu den Drehrädern

### 7.3 Drohnen-Profile
- Mehrere Drohnenprofile verwaltbar, Standardprofil T1 Ranger
- Profilliste als Tab im Vollbild-Menü (gemeinsam mit Missionsübersicht)
- Profildaten: min/max Speed, min. Kurvenradius, max. Steig-/Sinkrate, max. Reichweite, max. Flugdauer, Cruise Speed
- FC-Typ als explizites Profil-Setting (MSP/MAVLink)

### 7.4 Konnektivität (geplant/MVP)
- WiFi/TCP-Verbindung zum Flightcontroller (DroneBridge, mLRS-WiFi-Bridge)
- MSP-Protokoll nativ für iNAV
- MAVLink-Protokoll für ArduPilot (Post-MVP)
- Feature-Capability-Abfrage je FC (`FcCapabilities`: Multi-Mission, In-Flight-Upload, max. Wegpunkte)
- Ready-to-Fly-Gate mit Upload-/Verifikations-/Arm-Status

### 7.5 Persistenz & Datenhaltung
- Lokale Speicherung von Missionen, Profilen, Einstellungen
- Autosave/Mission-Drafts
- Suche nach Missionen nach Name, Ort, Datum (Flutter-Ziel, Drift)
- Vorbereitung für lokal-first Server-Sync (Dirty-Flags, Server-IDs)

### 7.6 Branding/Visuelles Design
- Eigenes Monogramm-Logo (M/D/C-Konstruktion, gespiegeltes C mit Schließstrich)
- Konsistentes Farbschema für SET/LIVE-Anzeigen (Blau/Grün)
- Einheitliche Chip-Optik für swipe-adjustierbare Werte und Execute-Dropdown

### 7.7 Nicht-funktionale Eigenschaften
- Android-Landscape-Ausrichtung (MVP)
- Offline-Kartenkachel-Caching pro Mission (Flutter-Ziel)
- Hintergrund-Telemetrie ohne Verbindungsabbruch bei App-Wechsel (Flutter-Ziel)
- Testbarkeit ohne physische Hardware via Mock-FC-Link
- Reine, UI-unabhängige Testbarkeit der Mission-Domain-Logik (separates Dart-Package, Flutter-Ziel)

---

## 8. Technologie-Stack im Überblick

| Bereich | Demonstrator (HTML/JS) | Flutter-Ziel |
|---|---|---|
| Karten | Leaflet.js + OSM-Tiles | `flutter_map` + `flutter_map_tile_caching` |
| Wind | Open-Meteo API | Open-Meteo API |
| Geocoding | Nominatim | Nominatim |
| Terrain | AWS Terrarium Tiles | AWS Terrarium Tiles |
| Persistenz | `localStorage` | Drift (SQLite) |
| State-Management | (imperativ, Vanilla JS) | Bloc + Riverpod (kombiniert) |
| MSP-Protokoll | eigene JS-Implementierung | eigene Dart-Implementierung |
| MAVLink | — (nicht MVP) | `dart_mavlink` (Risiko prüfen) oder eigener Generator |
| Hintergrundbetrieb | — | `flutter_foreground_task` (Android) |
| Navigation | — | `go_router` |
| Nebenläufigkeit | — | Dart Isolates für Protokoll-Parsing |

---

*Dieses Dokument fasst den Stand der bisherigen Projektkonversationen zusammen. Es wird empfohlen, es bei künftigen Architekturentscheidungen fortzuschreiben.*