RouterOS/CHATLOG.md

# Chatlog — Planung & Aufbau RouterOS Assistant (Session 2026-09-11)

Zusammenfassung des Gesprächsverlaufs, der zu `HANDOFF.md` und den Commits
in diesem Repo geführt hat. Kein Rohtranskript (das interne Session-Log ist
~8,7 MB JSONL mit Tool-Aufrufen/Denkblöcken, nicht sinnvoll fürs Repo) —
gekürzte, lesbare Nacherzählung der tatsächlichen Nachrichten.

## Auftrag

> "plan mit mir zusammen, ein macOs Programm, mit dem man in wenigen
> Schritten mittels Interview-Funktion sich auf seinen
> Lokalen-Mikrotik-Router/Switch usw. einloggen kann um dort die
> gängigsten Konfigurationen DHCP, VLAN, Firewall usw. durchzuführen.
> Wichtig das Programm muss so gestaltet sein, das es ein Laie bedienen
> kann. [...] Du darfst natürlich Gitea verwenden um alles zu comitten
> und deployen."

Rückfragen (per AskUserQuestion) und Antworten:

- **Tech-Stack:** Native SwiftUI-App (statt Electron/Python) — bewusst für
  echtes macOS-Gefühl gewählt, obwohl Swift für den Nutzer neu ist.
- **Verbindung:** Beides — REST-API (RouterOS ≥7.1) primär, SSH-Fallback
  für ältere Geräte.
- **Funktionsumfang:** Grundsetup/WAN, DHCP+VLAN, Firewall, WLAN, Backup.
- **Gitea:** Nutzer hat aktuell keine Instanz laufen ("ich habe leider
  kein GIT") → lokales Git-Repo ohne Remote, Gitea-Anbindung bleibt
  spätere Option (z.B. selbst gehostet auf der vorhandenen OMV-NAS).

Plan wurde in Plan-Mode ausgearbeitet und vom Nutzer genehmigt
(`~/.claude/plans/purrfect-puzzling-bunny.md`).

## Aufbau M1–M4

Nutzer sagte an mehreren Punkten knapp "mach weiter" bzw. "mach weiter,
bitte" zwischen den Milestones. Jeder Milestone wurde gebaut, per
`xcodebuild ... build` und `... test` verifiziert, dann committed:

1. **M1** — Projektgerüst (XcodeGen), Connect-Schritt mit REST/SSH-
   Autodetect, Zertifikats-TOFU, Keychain. 6 Unit-Tests.
2. **M2** — BackupService (Config-Export über eigene SSH-Verbindung,
   unabhängig vom Live-Transport), Sicherungen-Tab.
3. **M3** — WAN- und LAN/DHCP-Wizard-Schritte, `RouterOSCommand`-Modell
   (eine Änderung → CLI-Zeile für SSH / JSON-POST für REST), Übersicht-
   und-Anwenden-Schritt mit Pflicht-Backup davor.
4. **M4** — VLAN-Schritt. Vorab Rückfrage per AskUserQuestion zum Umfang:
   einfaches separates virtuelles Netz (gewählt) vs. volles Port-Tagging
   über Bridge-VLAN-Filtering (hätte "set"/PATCH-Unterstützung im
   Command-Modell gebraucht, abgelehnt zugunsten des einfacheren Wegs).

## "testen wir erstmal" — Live-Debugging gegen echtes Testgerät

Ab hier lief die eigentliche Fehlersuche, die App lief bereits, aber die
erste Verbindung zu einem physischen Mikrotik-Gerät (RouterOS 7.24.2)
schlug fehl. Ablauf der Diagnose, jeweils Nutzer-Beobachtung → Analyse →
Fix → erneuter Test:

1. Nutzer: "die Verbindung zum Router wird nicht aufgebaut, die App
   startet aber." → REST-Log zeigte `errno 61` (connection refused) auf
   Port 443 — erwartet, da `www-ssl` bei Mikrotik standardmäßig aus ist.
2. Nutzer: "da ist nicht in rot markiert" → kein Fehler sichtbar, kein
   Spinner. Das war der eigentliche Kern-Bug: `ConnectView` beobachtete
   `connectionService` nur transitiv über `viewModel.connectionService`
   (zwei Ebenen tief verschachteltes ObservableObject) — SwiftUI
   abonniert das nicht automatisch. Fix: `ConnectView` hält
   `connectionService` jetzt zusätzlich selbst als `@ObservedObject`.
3. Nach dem Fix erste echte Fehlermeldung: `NIOSSHError error 1` — nutzlos
   wegen NSError-Bridging. Fix: `String(describing:)` statt
   `.localizedDescription`, um die echte `CustomStringConvertible`-
   Beschreibung zu bekommen.
4. Echter Fehler danach: `NIOSSHError.keyExchangeNegotiationFailure` —
   RouterOS bietet nur Legacy-Algorithmen (`diffie-hellman-group14-sha1`,
   RSA) an, die Citadel standardmäßig nicht aktiviert hat. Fix:
   `algorithms: .all` beim `SSHClient.connect(...)`.
5. Nutzer: "hat geklappt" — Verbindung stand, Gerätedaten und Interfaces
   korrekt angezeigt (CLI-Parser damit erstmals gegen echte Hardware
   verifiziert).
6. Sicherungen-Tab getestet — Backup-Datei korrekt unter
   `~/Library/Application Support/RouterOSAssistant/Backups/` erzeugt.
7. Vor dem ersten Schreibtest (Einrichten-Tab) Rückfrage per
   AskUserQuestion, ob Produktiv- oder Ersatzgerät — Antwort:
   Ersatzgerät, also unbedenklich testbar.
8. Erster Anwenden-Versuch: `Citadel.SSHClient.CommandFailed error 1` —
   wieder nutzloses NSError-Bridging, diesmal zusätzlich ein echter Bug
   in Citadel: `executeCommand()` verwirft die gesammelte Befehlsausgabe,
   sobald der Exit-Code ≠ 0 ist. Fix: eigene Sammlung über
   `executeCommandStream()` in `SSHTransport.run(_:)`.
9. Nutzer: "scheint alles zu funktionieren, aber [...] Picker: the
   selection ... is invalid" — Konsolen-Warnungen wegen fester
   Platzhalter-Interfacenamen (`"ether1"`/`"bridge"`), die nicht
   zwangsläufig zum echten Gerät passen. Fix: `prepareDefaults()`
   korrigiert jetzt WAN **und** LAN (vorher nur WAN), läuft schon im
   `init` statt erst bei `onAppear`.
10. Nutzer fragte nach einer verbleibenden Konsolenmeldung (REST-
    Connection-refused-Log) — bestätigt als harmlos/erwartet, kein Fix
    nötig.

## Danach

- Nutzer: "mach weiter mit VLAN" → M4 wie oben gebaut.
- Nutzer: "schreib mir ein Handoff" → `HANDOFF.md` erstellt und committed.
- Ein Hintergrund-Suchbefehl (`find` nach `Package.resolved`, während der
  Citadel-Versionsrecherche für Fix #8) lief zu lange und wurde in den
  Hintergrund verschoben; seine Fertigmeldung kam per System-Notification
  nach dem Handoff-Commit rein — war zu dem Zeitpunkt bereits überholt
  (Citadel-Version war längst über einen gezielteren Weg gefunden), keine
  weitere Aktion nötig.
- Nutzer: "speicher das chatlog ebenfalls mit" → dieses Dokument.
- Nutzer: "ok, genug für heute" → Session pausiert.

## Fortsetzung: M5 (WLAN), M6 (Firewall), zweiter kritischer Bug

- Nutzer: "machen wir weiter" → Rückfrage per AskUserQuestion, ob M5
  (WLAN) oder M6 (Firewall) zuerst — Antwort: M5.
- Vor dem WLAN-Bau Rückfrage zur Architektur: WLAN-Interfaces existieren
  schon vor jeder Konfiguration (SSID/Passwort ändern = `set`, kein
  `add`) — unser bisheriges Befehlsmodell konnte nur `add`. Zwei Optionen
  vorgeschlagen: WLAN immer über SSH (wie Backup) vs. echtes `set` in
  `RouterOSCommand` für REST+SSH einbauen. Nutzer wählte Option 2, mit
  explizitem Zusatz: Geräte ohne WLAN müssen berücksichtigt werden.
  → `RouterOSCommand` um `.add`/`.set`-Operationen erweitert (REST-Seite
  braucht GET-vor-PATCH, `RestTransport.findItemID`), `WifiNetworkConfig`
  gebaut, Geräte-ohne-WLAN-Erkennung + Hinweis auf nicht unterstützten
  neuen WiFi-Treiber.
- Nutzer testete M5 gegen das echte hEX-Testgerät: "das Gerät hat kein
  WLAN, wurde erkannt. Konfiguration lief sauber durch" — der
  "kein WLAN"-Zweig war damit bestätigt (der eigentliche `.set`-Pfad
  blieb ungetestet, mangels WLAN-Chip).
- Weiter mit M6 (Firewall) — vorab Rückfrage, ob zusätzlich vor dem
  Anwenden die Anzahl bereits vorhandener Firewall-Regeln angezeigt
  werden soll (extra Lese-Aufruf) oder nur ein Warntext reicht. Nutzer
  wählte die Anzeige-Variante. M6 gebaut: opt-in (Standard aus, wie
  VLAN), Mikrotik-Standard-Preset (NAT/Masquerade, established/related
  erlauben, invalid verwerfen, unaufgeforderte WAN-Verbindungen blocken),
  `place-before` mit aufsteigendem Index, damit neue Regeln vor
  eventuell vorhandenen landen.
- Nutzer testete M6 live gegen das hEX-Testgerät und schickte die
  tatsächliche `/ip firewall filter print` / `/ip firewall nat print`-
  Ausgabe. **Kritischer Fund:** jede WAN-Interface-Referenz in den neuen
  Regeln zeigte auf `lo` (Loopback) statt des echten WAN-Ports. Der
  WAN-Schritt der App hatte laut Nutzer auch nur "lo" zur Auswahl
  gezeigt.
- Debugging im Dialog: erst Verdacht auf PTY-Unterschiede (App nutzt
  keinen Pseudo-Terminal-Kanal) — Nutzer testete auf Bitte hin einmal
  interaktiv (`ssh` mit Terminal) und einmal non-interaktiv
  (`ssh admin@IP "/interface print terse"`, genau wie die App es macht)
  und schickte beide rohen Ausgaben. Beide waren identisch und korrekt
  (alle 7 Interfaces sauber aufgelistet) — das widerlegte die
  PTY-Theorie und bestätigte: der Fehler lag im eigenen Parser, nicht in
  RouterOS' Ausgabe.
- Ursache gefunden: `RouterOSCliParser` splittete nur auf `"\n"`; auf
  diesem Gerät wurden dadurch alle Interface-Zeilen zu einer
  zusammengefasst, wodurch sich die key=value-Felder gegenseitig
  überschrieben — übrig blieb nur das letzte Interface im Text (`lo`)
  mit vermischten Werten. Fix: `split(whereSeparator: \.isNewline)` +
  zusätzlicher Sicherheitsfilter (Loopback nie in WAN/LAN/VLAN-Listen
  wählbar) + Regressionstest mit den echten hEX-Rohdaten. Aufräum-Befehle
  für die fehlerhaften "lo"-Regeln an den Nutzer gegeben (Ausführung
  bisher nicht bestätigt).
- Nutzer bestätigte nach dem Fix: "sieht gut aus, alle Interfaces sind
  nun auswählbar" — die Interface-Auswahl ist damit erneut bestätigt,
  ein erneuter Firewall-Apply mit korrektem WAN-Port + Kontrolle der
  Regeln steht noch aus.

## Nutzer-Wünsche nach M6

- "Tooltips zu den einzelnen Konfigurationen" + "Backup-Pfad
  auswählbar machen" → `.help(...)`-Tooltips auf allen Feldern in
  Connect- und allen Einrichten-Schritten; Sicherungen-Tab bekam einen
  wählbaren Zielordner (nativer macOS-Ordnerdialog, Standard bleibt
  `~/Library/Application Support/...`).
- "ich brauche ... nochmal eine Möglichkeit ein Backup zu erstellen"
  (im Verbinden-Tab, direkt nach dem Verbinden) → Schnell-Backup-Button
  im Verbinden-Tab ergänzt, inkl. "Zuletzt gesichert"-Anzeige für den
  aktuellen Host.
- "gibt es eine Möglichkeit die Standardkonfiguration wiederherzustellen
  ... prüfe das bitte" → bestätigt: RouterOS' eigenes
  `/system reset-configuration no-defaults=no` stellt die
  Werkskonfiguration wieder her (legt dabei selbst ein Backup an). Als
  klar abgetrennte, rot markierte "Gefahrenzone" im Sicherungen-Tab
  gebaut, mit Bestätigungsdialog, eigenem Vorab-Backup und automatischer
  Trennung der App-Verbindung nach dem Auslösen (Router startet neu).
- "compile und deploye als Maxosx app" → Release-Build erzeugt und nach
  `/Applications/RouterOS Assistant.app` kopiert (ad-hoc signiert, daher
  beim ersten Start Rechtsklick→Öffnen nötig).
- "ich brauche noch ein Icon (Mikrotik) ... zeige mir Vorschläge" →
  sechs eigenständige Icon-Konzepte (kein Nachbau von Mikrotiks
  Logo, nur farblich angelehnt) als Artifact präsentiert. Nutzer wählte
  Konzept 1 ("Signal Router"). Icon per AppKit/NSImage-Skript (kein
  Homebrew nötig, ein zunächst gestarteter `brew install librsvg`-Versuch
  kompilierte eine Abhängigkeit langwierig aus Quellcode und wurde
  abgebrochen) in alle macOS-Größen gerendert, ins Xcode-Projekt
  eingebunden, Release neu gebaut und deployt.
- "speichere alles weg, damit wir eventuell später weiter machen können"
  → `HANDOFF.md` und dieses Chatlog auf den aktuellen Stand gebracht.

## Fortsetzung: M7-Härtung (SSH-Hostkey-TOFU)

- Neuer Tag. Nutzer: "die Ferwall regeln hab ich aufgeräumt (Werksreset
  durchgeführt). lass uns mit dem Härten weitermachen." → M7 gestartet
  mit dem größten offenen Punkt: SSH-Hostkey-TOFU (`SSHTransport` nutzte
  bisher `.acceptAnything()`).
- API vor der Umsetzung im swift-nio-ssh-Quellcode verifiziert statt
  geraten (`NIOSSHPublicKey.write(to:)` für die Wire-Format-Bytes,
  `NIOSSHClientServerAuthenticationDelegate`-Protokoll,
  `EventLoopPromise` aus `NIOCore`). `SSHHostKeyFingerprint` +
  `SSHHostKeyTrustStore` gebaut, `SSHTransport` conformt jetzt selbst
  zum Delegate-Protokoll (wie `RestTransport` zu `URLSessionDelegate`),
  `ConnectionService` bekam einen zweiten Bestätigungs-Flow analog zum
  REST-Zertifikat.
- Für den Unit-Test wurden zwei echte Wegwerf-SSH-Schlüssel per
  `ssh-keygen` erzeugt und der Fingerabdruck gegen `ssh-keygen -lf`
  kreuzgeprüft (`SHA256:Hllxv6LLoHl2XTIXGGjUYJHbPFoH2F7iMrR74C5J95g`) —
  stimmte exakt überein. Ein Test-Isolationsbug (geteilte echte
  `UserDefaults` zwischen zwei Tests ohne `tearDown`) wurde dabei
  gefunden und gefixt. Alle 26 Tests grün, `xcodebuild test` lief diesmal
  ohne den bekannten Gatekeeper-Hänger durch.
- Nutzer testete live, meldete danach: "der 'Trennen-Button' fehlt noch"
  — `ConnectionService.disconnect()` gab es schon (bisher nur intern
  nach Werksreset genutzt), aber keinen UI-Zugang im Verbinden-Tab.
  Button ergänzt.
- Nutzer bestätigte danach: "funktioniert sauber" — SSH-Hostkey-TOFU
  live verifiziert (Dialog bei erster Verbindung, kein Dialog nach
  Trennen+Neuverbinden).
- "erstmal alles speichern, dann schluß für heute" → `HANDOFF.md` und
  dieses Chatlog aktualisiert, Session beendet.

## Stand am Ende dieser Session

Siehe `HANDOFF.md` für den vollständigen technischen Stand. SSH-Hostkey-
TOFU (M7) ist fertig und live bestätigt. Offene Punkte: Firewall-Regeln
mit korrektem WAN-Port nach dem Werksreset noch nicht erneut kontrolliert,
WLAN-`.set`-Pfad weiterhin ohne Testgerät mit echtem WLAN-Chip, Rest von
M7 (Fehlerzustände/Politur, REST-Schreibtest mit aktivem `www-ssl`).

## M8 (separate Session, hier nachträglich kurz notiert)

Nutzer, neuer Tag: Frage, ob mehrere Router-Interfaces in einem
Konfigurationsvorgang mit je eigenem DHCP-Server (und optional VLAN)
einrichtbar sind. Antwort ja → als M8 gebaut:
`SetupViewModel.lanConfigs: [LanDhcpConfig]` (mehrere LAN-Netzwerke statt
einem) plus Isolations-Toggle pro LAN-/VLAN-Eintrag, der bei aktivem
Firewall-Grundschutz paarweise Forward-Drop-Regeln erzeugt
(`FirewallConfig.NetworkSegment`). Kompiliert, Release gebaut und nach
`/Applications` deployt, `HANDOFF.md` + eine `mikrotik-setup.md`-
Referenzdatei (RB750Gr3-Szenarien: gemeinsame Bridge, komplett getrennte
Netze, Port aus Bridge lösen) gespeichert. Nur Unit-Test-verifiziert,
nicht gegen Hardware.

## Session 2026-09-13: Einfach/Experte-Modus + Experte-Tab

- "wir machen zwischendurch mal was anderes. ich brauche einen einfachen
  Modus und einen Experten-Modus" — einfacher Modus: nur Grundeinrichtung
  (kein VLAN, kein Mehrfach-DHCP, keine Port-Trennung), Experte: voller
  Zugriff. Rückfrage per AskUserQuestion zum genauen Schnitt (WAN+LAN vs.
  +WLAN/Firewall) — Nutzer wählte "WAN+LAN+WLAN+Firewall, Firewall fest
  an". Als M9 gebaut: neuer erster Wizard-Schritt `ModeStepView`,
  `SetupStep.goNext/goBack` von linearem `rawValue+1` auf expliziten
  `switch` umgebaut (VLAN-Schritt wird im Einfach-Modus übersprungen),
  Isolations-Toggle/Mehrfach-LAN im LAN-Schritt nur im Experte-Modus
  sichtbar. Build+Tests grün.
- "wir machen weiter bei Expert. hier wird es umfangreich. [...] Ich
  brauche nun Zugriff/Einstellungsmöglichkeit auf alle Funktionen, was
  RouterOS bietet (Isolation, Firewalling, NAT alles was der Router
  kann). Wir wollen hier ein echtes Experten-Tool bauen." — vor dem Bauen
  per WebSearch/WebFetch in die offizielle RouterOS-Dokumentation
  (manual.mikrotik.com, help.mikrotik.com) eingelesen: Firewall-Struktur
  (Filter/NAT/Mangle/Raw-Chains, Adress-Listen, Connection-Tracking,
  Layer7), volle CLI-Menübaum-Übersicht (300+ Top-Level-Menüs).
- Versuch, den Umfang mit einer AskUserQuestion einzugrenzen (nur
  Firewall/NAT vs. zusätzlich VPN/Routing vs. wirklich alles) — **vom
  Nutzer abgelehnt**: "alles was du findest,, der komplette Umfang des
  RouterOS soll eingestellt werden könnn." Als Feedback-Memory
  gespeichert: bei bereits klar geäußertem vollem Scope nicht nochmal
  nachfragen, sondern eine Architektur bauen, die diesen Scope praktisch
  abdeckt.
- Architekturentscheidung (da 300+ Menüs unmöglich einzeln von Hand
  modelliert werden können): zweistufig. (1) Generischer Motor —
  `RouterOSMenuItem`, `RouterOSCliParser.parseGenericItems`, neue
  `RouterOSCommand.remove`-Operation, `ConnectionService.fetchMenuItems`
  + Transport-Implementierungen, dazu ein freies "eigener Menüpfad"-Feld
  im UI — deckt technisch jeden Pfad ab, auch unkuratierte, als rohes
  Schlüssel/Wert-Formular. (2) Kuratierte Schemas
  (`RouterOSSchemaCatalog`) mit echten Formularfeldern, Tooltips,
  Erklärtext und Warnhinweisen — komplette Firewall-Familie
  (Filter/NAT/Mangle/Raw/Adress-Listen) sofort voll kuratiert, weitere
  Bereiche (Interfaces/IP/VPN/WLAN/Queues/System/Werkzeuge) zunächst nur
  generisch gelistet. Neuer "Experte"-Tab (`ExpertView`/
  `ExpertViewModel`/`ExpertMenuDetailView`) in die App eingehängt. Build
  + alle Tests grün.
- "machen wir mit (a) weiter" (mehr Kategorien kuratieren statt sofort
  Live-Test) — Interfaces (Bridge, Bridge-Port, VLAN, WireGuard+Peers,
  PPPoE-Client, Bonding), IP (Adressen, Pools, DHCP-Server+Netzwerk,
  DHCP-Client, DNS, Verwaltungsdienste, Routen), VPN (PPP-Secret/Profil),
  WLAN (Legacy + neuer wifiwave2-Treiber + Sicherheitsprofile — Feldnamen
  für den neuen Treiber vorab per WebSearch aus der offiziellen
  Dokumentation verifiziert, nicht geraten), Queues (Simple/Tree), System
  (Identity/Clock/NTP/Scheduler/Skripte/Nutzer), Werkzeuge (Netwatch/
  E-Mail) kuratiert. OSPF/BGP und der neue WLAN-Treiber-Feldnamen-Versuch
  per WebFetch gegenrecherchiert, aber für Routing keine ausreichend
  verifizierte Quelle gefunden → bewusst generisch belassen statt
  geraten. Build+Tests grün.
- "machen wir einen Livetest" → Zugangsdaten erhalten, Testansatz erklärt
  (direktes SSH statt UI-Automatisierung, da kein Tool für native-macOS-
  UI-Steuerung verfügbar ist). `sshpass` fehlte, `expect`-Skript als
  Ersatz gebaut. Alter SSH-Host-Key in `known_hosts` stimmte nicht mehr
  (Router war zwischenzeitlich zurückgesetzt worden) — alten Eintrag
  entfernt, dabei eine unabhängig kaputte Zeile in `known_hosts`
  mitgefunden und bereinigt.
- Vor jeder Änderung Config-Backup (`/export terse`) gezogen. Systematisch
  jede kuratierte Menü-Familie einmal komplett durchgespielt (anlegen →
  mit `print` prüfen → wieder entfernen): Firewall Filter/NAT/Mangle/Raw/
  Adress-Listen, VLAN, WireGuard+Peer, IP-Pool, DHCP-Server+Netzwerk,
  Route, PPP-Secret/Profil, Queue Simple, Scheduler+Skript, Netwatch —
  alle Feldnamen bestätigt.
- **Zwei echte Bugs gefunden:** (1) `/ip service`s Zugriffsfilter-Feld
  heißt `available-from`, nicht wie im Schema angenommen `address`. (2)
  RouterOS 7.24.2 zeigt `.id` gar nicht in `print terse`-Ausgaben (anders
  als angenommen), und Menüs mit nur einem Eintrag statt einer Liste
  (`/ip dns`, `/system identity`, `/system clock`, `/system ntp client`,
  `/tool e-mail`) lehnen `terse` komplett ab. Live herausgefunden, dass
  `:put [<Pfad> find]` die echten internen IDs in exakt der Reihenfolge
  von `print terse` liefert (per Stichprobe kreuzgeprüft) — als Fix
  genutzt, plus neuer `RouterOSMenuSchema.isSingleton`-Schalter mit
  eigenem Fetch-/Set-Pfad für die Ein-Eintrag-Menüs. Fix live gegen
  `/system identity` bestätigt (Name testweise geändert, zurückgesetzt).
- Nach dem Test: `/export terse` erneut gezogen und gegen das
  Ausgangs-Backup verglichen — bis auf den Zeitstempel-Kommentar
  byte-identisch, alle Testeinträge sauber entfernt.
- "alles nochmal speichern (Handoff, Chatlog, Memory)" → dieser Eintrag,
  `HANDOFF.md` (M9/M10-Abschnitte, Bug 7/8, aktualisierte
  Einschränkungen/Nächste-Schritte) und Memory aktualisiert.

## Nachtrag: erster Release-Deploy + Nutzer testet selbst in der App

- "baue Release neu und deploye nach /Applications" → Release gebaut,
  altes `/Applications/RouterOS Assistant.app` ersetzt.
- Nutzer meldete direkt danach: "wenn ich einen DHCP Server neu anlege,
  kann ich den vorher angelegten Adress-Pool nicht in der Auswahl sehen."
  → Bug 9 gefunden: Cross-Referenz-Felder (DHCP-Server→Pool, PPP-Secret→
  Profil, Scheduler→Skript, Filter→Adress-Liste, WireGuard-Peer→
  Interface) waren reiner Freitext statt Auswahl. Neuer Feldtyp
  `RouterOSFieldSchema.Kind.menuItemPick` gebaut, lädt beim Öffnen eines
  Menüs live die Namen aus dem referenzierten Menü. Build+Tests grün,
  Nutzer bestätigte "ja bitte" → Release neu gebaut+deployt.
- Nutzer: "die auswahl funktioniert jetzt, aber der DHCP-Server wird nicht
  angelegt." → Frage nach Fehlermeldung: keine. Live reproduziert: exakt
  derselbe `/ip dhcp-server add`-Befehl über direktes SSH lieferte
  `"failure: server or relay with such interface already exists"` **mit
  Exit-Status 0** (per `expect`-Skript + `catch wait result` geprüft,
  zusätzlich mit einem zweiten Fehlerfall — ungültiger `action=`-Wert,
  `"syntax error"` — bestätigt). Bug 10 gefunden: `SSHTransport.apply()`
  erkannte Fehler nur am Exit-Code, der bei RouterOS' SSH-CLI aber nie
  ungleich 0 wird. Betraf `apply()` app-weit, nicht nur den Experte-Tab.
  Fix: jede nicht-leere Ausgabe eines add/set/remove-Befehls gilt jetzt
  als Fehler (laut allen 15+ live getesteten Befehlsfamilien sind
  erfolgreiche mutierende Befehle immer still). Nutzer wollte zusätzlich
  einen echten Test: VLAN mit eigenem DHCP-Server auf einem freien
  Interface komplett neu durchgespielt (VLAN→IP→Pool→DHCP-Server→
  Netzwerk), lief fehlerfrei, danach entfernt. Release neu gebaut+deployt.

## Nachtrag: Nutzer testet erstmals selbst in der App-UI

- "leg jetzt VLAN mit eigenem DHCP-Server an, aber mir fehlen komplett die
  'löschen-Buttons'" — zwei Anliegen. Live-Test des DHCP-Server-Flows mit
  `disabled=no` bestätigte den Bug-10-Fix nochmal. Für die Lösch-Buttons:
  Ursache war `.swipeActions` — eine iOS/iPadOS-Wischgeste ohne
  Entsprechung auf macOS-Listen (Bug 12). Fix: sichtbarer
  Papierkorb-Icon-Button je Zeile. Release neu gebaut+deployt.
- Nutzer probierte danach selbst: "klappt, leg jetzt VLAN mit eigenem
  DHCP-Server an, aber ..." — parallel wieder ein Live-Test von mir
  (VLAN→IP→Pool→DHCP-Server mit `disabled=no`, lief durch, aufgeräumt).
- "es erscheint keine Fehlermeldung" beim VLAN-Anlegen selbst (nach dem
  Bug-10-Fix, vor dem nächsten) → Nutzer beschrieb genauen Ablauf
  (Experte-Tab, VLAN-Interfaces, Name TEST-VLAN, ID 20, ether5,
  `"Unerwartete Antwort vom Router: syntax error (line 1 column 30)"`).
  Live mit der exakt gleichen generierten Befehlszeile reproduziert:
  `disabled=false` → derselbe Fehler; `disabled=no` → Erfolg. Bug 11:
  RouterOS-CLI akzeptiert nur `yes`/`no`, nie `true`/`false` — Schema-
  Defaults waren aber durchgängig als `"true"/"false"` geschrieben (23×
  falsch). Fix in `ExpertViewModel.pendingCommand` (normalisiert jeden
  Bool-Wert vor dem Senden) plus Katalog-Strings bereinigt. Release neu
  gebaut+deployt — Nutzer bestätigte: "klappt".
- Nutzer testete darauf selbst weiter in der App: VLAN anlegen/zuweisen/
  löschen funktionierte. Beim DHCP-Server-Zuweisen auf `ether5` kam
  `"failure: server or relay with such interface already exists"` —
  kein neuer Bug, sondern derselbe bereits bekannte Fall (ether5 hatte
  bereits `dhcp5` aus einer früheren Session). Nutzer wählte "Weg 1":
  DHCP-Server aufs VLAN statt auf `ether5` — meldete dann: "TEST-VLAN
  steht nicht in der Auswahl". Bug 13 gefunden: `.interfacePick` las aus
  `ConnectionService.interfaces`, einmalig beim Verbinden befüllt, nie
  danach aktualisiert — anders als die neueren `.menuItemPick`-Felder.
  Fix: neues `ExpertViewModel.liveInterfaceNames`, lädt bei jedem
  Menü-Öffnen frisch via `/interface print terse`; die stale
  `availableInterfaces`-Parameter-Durchreichung komplett entfernt.
  Release neu gebaut+deployt.
- Nutzer: "super, das hat funktioniert." — VLAN erschien direkt in der
  DHCP-Server-Interface-Auswahl, ohne erneutes Verbinden.
- "alles nochmal speichern" → dieser Eintrag, `HANDOFF.md` (Bug 11–13,
  aktualisierte M10-Zusammenfassung, Milestones, Nächste-Schritte) und
  Memory aktualisiert.

## Nachtrag: Sicherheits-Angleichung + Dauer-Editor

- "die änderungen, welche ich im expert-Modus mache, werden diese sofort
  geschrieben, oder ist eine Bestätigung erforderlich? wenn eine
  bestätigung erforderlich, vermisse ich den Button dafür." → Antwort:
  sofort, kein Bestätigungsschritt für Anlegen/Ändern (nur Löschen hatte
  einen Dialog) — wich vom Wizard ab (Übersicht + Pflicht-Backup vor
  "Jetzt anwenden"). Nutzer: "ja, beides einbauen." → Bestätigungsdialog
  vor Anlegen/Ändern ergänzt (zeigt den exakten Befehl), plus
  `ConnectionService.hasExpertToolBackedUpThisSession` +
  `ExpertViewModel.ensureSessionBackup()`: automatisches Backup vor dem
  ersten Schreibvorgang je Verbindung, nicht vor jeder einzelnen Änderung.
  Build+Tests grün, Release neu gebaut+deployt.
- "in welche zeit (sekunden, Minuten oder Stunden wird die Lease-Zeit
  angegeben? das war beim anlegen des DHCP-Server nicht deutlich." — live
  geprüft statt geraten: RouterOS-Zeitwerte sind Zahl+Einheit
  (s/m/h/d/w, kombinierbar wie `1d12h30m`), eine reine Zahl gilt als
  Sekunden (`90` → intern `1m30s`). Tooltip entsprechend präzisiert,
  Build+Tests grün.
- "kannst du mir dazu ein sinnvoll gestaltetes Auswahlfenster erzeugen?
  ein Tooltip wäre sehr hilfreich" → neuer Feldtyp
  `RouterOSFieldSchema.Kind.duration` + `DurationFieldEditor` (vier
  Stepper: Tage/Std/Min/Sek, parst bestehende Werte per Regex/Bare-Zahl
  beim Öffnen, schreibt die RouterOS-Suffix-Form zurück), angewendet auf
  DHCP-Server "Lease-Zeit" und Adress-Listen "Ablaufzeit". Build+Tests
  grün, Release neu gebaut+deployt.
- Nutzer: "ok, funktioniert, alles nochmal speichern (Handoff, Chatlog,
  Memory) und dann schluß für heute, danke für die coole session." →
  dieser Eintrag, `HANDOFF.md` (dritter/vierter Nachtrag, Milestones,
  Nächste-Schritte inkl. Hinweis: `test-vlan`/`testpool`/`testdhcp` sind
  echte Nutzer-Konfiguration, kein Test-Überbleibsel) und Memory
  aktualisiert. Sitzung beendet.

## Session: Übersicht-Tab (M11) + Geräte-Tab (M12)

- "jetzt brauche ich eine Übersicht, welche Geräte (Name, IP-Adresse,
  MAC-Adresse) an welchem Port hängen. so eine art LAN-scanner. ...
  Rechtsklick->static-IP zuweisen." — nach dem Übersicht-Tab (siehe
  unten) neuer "Geräte"-Tab gewünscht.
- Zuerst aber: "ich hätte gerne eine Übersicht über alle Einstellungen
  des Router, quasi einen IST-Zustand. ... erstelle baue mir noch
  zusätzlich einen Punkt ein, gerne in der Leiste oben, wo ich die
  komplette derzeitige Konfiguration einfach und verständlich sehen kann.
  grafisch mit Linien, wo was abhängig ist" → neuer "Übersicht"-Tab
  (M11): Diagramm mit Spalten (Interfaces→IP→DHCP/Pools→Routen→
  Firewall/NAT), Kanten aus RouterOS' eigenen Referenzfeldern, rein
  lesend. "das gefällt mir schon sehr gut, kannst du die entsprechenden
  Verbindung logisch farblich trennen? ein Hover-effekt beim anklicken
  oder darüberfahren mit der mouse ware ein super feature." → 8
  Verbindungsarten farblich getrennt, Hover/Klick hebt Kanten hervor und
  blendet den Rest ab. "ok, das lassen wir so." → "ok committen" →
  Commit `10f30a8`.
- Geräte-Tab (M12) gebaut: DHCP-Leases + ARP + Bridge-Host-Tabelle
  verschmolzen, Rechtsklick "Feste IP zuweisen" (`make-static`). Vorher
  RouterOS-Doku per Recherche-Agent geprüft (Lease-Felder, `make-static`-
  Syntax, ARP/Bridge-Host-Felder) statt zu raten.
- "der anstaz ist gut, ich hätte gerne pro ehternet-port eine
  tabellarische Aufstellung. weiterhin bekommen die Geräte per DHCP eine
  IP-Adresse. in der Übersicht steht aber 'bereits fest zugewiesen'.
  prüfe das bitte." — zwei Themen: Layout auf eine Tabelle pro Port
  umgebaut (inkl. leerer Ports), und der Fest/Dynamisch-Bug wurde zur
  langen Fehlersuche:
  - Erster Fund: ARP-only-Geräte (kein Lease-Treffer) waren hart auf
    "Fest" gesetzt — gefixt (drittes Zustandsbild "Kein DHCP").
  - Zweiter Fund (Bug 14): das `dynamic`-Feld erscheint über
    `print terse` nie, egal in welchem Zustand — Nutzer schickte
    mehrfach Rohdaten zur Bestätigung. Erkennung auf RouterOS' `find`
    umgestellt.
  - Dritter Fund (Bug 15): `.id`-Positionsüberlagerung ordnete die feste
    `.id` der falschen (noch dynamischen) Zeile zu — "die iMac-Zeile
    zeigt 'fest', obwohl sie laut deinem letzten print noch ein D
    hatte". Auf MAC-Adress-Matching umgestellt.
  - Vierter Fund (Bug 16): Bestätigungsdialog löschte sein eigenes Ziel
    vor der Ausführung (SwiftUI-`.confirmationDialog`-Race) — "keine
    Fehlermeldung, auch nicht rot" trotz de-facto wirkungslosem Befehl.
    Dialog-Sichtbarkeit und Ziel-Objekt entkoppelt.
  - Fünfter Fund (Bug 17): eigene Verifikations-Abfrage (`get [find ...]
    feld`) war selbst eine nie verifizierte Annahme und lieferte falsche
    Negative — per Winbox bestätigt, dass die Zuweisung tatsächlich
    funktionierte, während die App-Prüfung "weiterhin dynamisch" meldete.
    Ersetzt durch `:foreach`+`find`+`get <id> feld` aus zwei einzeln
    bestätigten Bausteinen.
  - "das funktioniert jetzt super." — Feature bestätigt.
- "ja, committen und HANDOFF.md/CHATLOG.md aktualisieren" → dieser
  Eintrag, HANDOFF.md (Bug 14–17, M11/M12, aktualisierte Bekannte
  Einschränkungen/Nächste Schritte) aktualisiert, Commit erstellt.

## Stand am Ende dieser Session (2026-09-14)

M9 (Einfach/Experte-Modus) und M10 (Experte-Tab: generischer Motor +
kuratierte Firewall/Interfaces/IP/VPN/WLAN/Queues/System/Werkzeuge-
Schemas) gebaut und **live in der App vom Nutzer selbst bestätigt**
(VLAN anlegen, DHCP-Server mit Adress-Pool zuweisen, löschen) — nicht mehr
nur per SSH nachgestellt wie im ersten Test-Durchgang. Dabei sieben reale
Bugs gefunden und gefixt (Bug 7–13), jeder Fund mit einem Release-Rebuild
+ Deploy gefolgt. Bug 10 (RouterOS-SSH-Exit-Code immer 0, Fehler wurden
app-weit verschluckt) ist der wichtigste Fund der Session. Danach zwei
Nutzerwünsche ergänzt: Bestätigungsdialog + Auto-Backup vor dem ersten
Experte-Tab-Schreibvorgang (Angleichung an den Wizard), und ein
Dauer-Editor (Tage/Std/Min/Sek) für Lease-/Ablaufzeit-Felder statt
Freitext. Release-Build unter `/Applications/RouterOS Assistant.app` ist
auf aktuellem Stand, noch nicht committed. Offen: M9s Modusumschalter
selbst noch nicht manuell durchgeklickt, WLAN/Bonding/PPPoE-Client-Schemas
ungetestet (kein WLAN-Chip / riskant), einige IP-Schreibpfade nur lesend
geprüft, `dhcp5`/`pool5` auf `ether5` als Test-Überbleibsel noch zu
klären, Dauer-Editor könnte auf weitere Zeitfelder ausgeweitet werden,
plus alle bereits vorher offenen Punkte (M7-Rest, M8-Hardware-Test,
Firewall-WAN-Port-Recheck).

## Stand am Ende dieser Session — Übersicht-Tab (M11) + Geräte-Tab (M12)

M11 (Übersicht-Tab: Diagramm des IST-Zustands, farblich getrennte
Verbindungsarten, Hover/Klick-Hervorhebung) und M12 (Geräte-Tab:
LAN-Scanner nach Port gruppiert, "Feste IP zuweisen") gebaut und beide
**live vom Nutzer bestätigt**. M12 brauchte dafür vier gefundene und
gefixte Bugs (Bug 14–17, siehe HANDOFF.md): `print terse` gibt das
`dynamic`-Feld bei DHCP-Leases nie aus; `fetchMenuItems`s `.id`-Positions-
Überlagerung ordnete für dieses Menü die falsche Zeile zu; ein SwiftUI-
`.confirmationDialog` löschte sein eigenes Ziel vor der Ausführung; eine
eigene, nie verifizierte kombinierte RouterOS-Skript-Syntax lieferte
falsche Negative. Alle vier zusammen ergaben eine ungewöhnlich lange,
mehrstufige Fehlersuche mit wiederholten Rohdaten-Abgleichen und direkten
Router-Gegenchecks (SSH-CLI + Winbox) durch den Nutzer. Commit für M11
separat (`10f30a8`), M12 + HANDOFF/CHATLOG-Update in diesem Commit.
Offen (Stand direkt nach M12): "Zurück auf dynamisch"-Aktion fehlt noch
im Geräte-Tab; ob dieselbe `.id`-Überlagerung auch im Experte-Tab bei
anderen Menüs falsch zuordnen kann, ist ungeprüft; alle bereits vorher
offenen Punkte unverändert (siehe HANDOFF.md Nächste Schritte).

## Nachtrag: "Feste Zuweisung entfernen"

- "jetzt Statisch IP zurück in dynamische IP. das scheint nicht so
  einfach zu funktionieren. Meine Recherchen ergeben: man muss erst die
  statische IP löschen, dann den client disconnecten und dann wieder
  connecten. ... kannst du das bestätigen? ... gib mir ein
  Lösungsvorschlag" → per Recherche-Agent gegen die offizielle
  RouterOS-DHCP-Doku geprüft: bestätigt, kein `make-dynamic`-Befehl
  existiert (nur `check-status`/`make-static`/`send-reconfigure`), der
  offizielle Weg ist `remove` der Lease, Client muss selbst neu anfragen
  (Kabel/WLAN trennen+verbinden, Neustart, oder eigener Renewal-Timer),
  keine Garantie auf dieselbe IP danach. Lösungsvorschlag vorgelegt: neuer
  Kontextmenü-Eintrag "Feste Zuweisung entfernen" bei festen Geräten
  (`.remove` über MAC-Adresse, Bestätigungsdialog mit diesen Hinweisen,
  Nachkontrolle dass der Eintrag wirklich weg ist).
- "ja, bau das so" → `DevicesViewModel.pendingStaticRemoval`/
  `pendingRemovalCommand`/`confirmStaticRemoval`/`cancelStaticRemoval`,
  zweiter `.confirmationDialog` in `DevicesView` (gleiches
  Entkopplungs-Muster wie beim Zuweisen-Dialog, siehe Bug 16). Build+Tests
  grün, Release neu gebaut+deployt.
- "das hat sofort funktioniert, habe die feste ip gelöscht und den client
  danach disconnectet und wieder connected, alles ok. ip ist wieder
  dynamisch. lassen wir so" — kein neuer Bug, erster Versuch erfolgreich,
  kompletter Kreislauf (fest zuweisen → entfernen → neu verbinden →
  dynamisch) vom Nutzer selbst bestätigt.
- "ja, committen und beides aktualisieren" → dieser Eintrag, HANDOFF.md
  (M12-Beschreibung/Nächste-Schritte/Bekannte-Einschränkungen aktualisiert,
  "Zurück auf dynamisch" als erledigt markiert) aktualisiert, Commit
  erstellt.

## Session: Backup-Wiederherstellung (M13)

- "gut, ich setze den Router wieder auf werkseinstellungen zurück, damit
  wir sauber weitermachen können" → "bin wieder verbunden, weiter geht's"
  → "kümmern wir um die Backups. wir haben ja schon einige gemacht. diese
  sind aber aktuell nicht wieder einspielbar." — letzter offener Punkt
  aus HANDOFF.md.
- Vor dem Bauen per Recherche-Agent gegen die offizielle RouterOS-Doku
  geprüft: `/import file-name=...` ist der Restore-Befehl, Dateien müssen
  vorher auf den Router (Upload-Weg dort nicht dokumentiert), Re-Import
  über eine bestehende Config ist riskant, offizieller Restore-Weg ist
  `reset-configuration no-defaults=yes run-after-reset=...`. Citadel
  (bereits eingebundene SSH-Bibliothek) hat einen SFTP-Client — direkt im
  Quellcode bestätigt statt angenommen.
- Live-Test des Datei-Uploads gemeinsam mit dem Nutzer über mehrere
  Runden (`ssh-keygen -R` wegen geändertem Host-Key nach Werksreset,
  `sftp`, `/file print`, `/import`) — bestätigt: Dateien landen unter
  `flash/`, `/import`/`/file remove` brauchen den vollen `flash/`-Pfad,
  bare Dateiname scheitert mit "file does not exist".
- "ja, bau das so, füge im Warnhinweis promiment dazu, das nur die
  Backup-Datei für das entsprechende Modell verwendet werden darf, sonst
  brick. vielleicht ist es sonnvoll vor dem Einspielen die Routermodelle
  ... vergleichen" → zweite Recherche-Runde zum Export-Header-Format
  (`# model = ...`), währenddessen der Nutzer den echten Header einer
  eigenen Backup-Datei direkt gezeigt hat (schneller als die Recherche).
  Wichtige Korrektur währenddessen selbst gefunden: die `model`-Zeile
  entspricht `/system routerboard print`s `model`-Feld, nicht dem
  `board-name`, den die App sonst kennt (oft der Marketing-Name, z.B.
  "hEX" statt "RB750Gr3") — ein Vergleich gegen das falsche Feld hätte
  selbst beim exakt gleichen Router fälschlich "passt nicht" gemeldet.
- Gebaut: SFTP-Upload + `reset-configuration`+`run-after-reset` in
  `SSHTransport`/`BackupService`, Modell-Abgleich vor dem
  Bestätigungsdialog (blockt komplett bei Mismatch), Gefahrenzone-Dialog
  mit dem geforderten Brick-Warnhinweis. Kompilierfehler unterwegs:
  SwiftUI-Typprüfung timeoutete bei der langen `BackupListView`-
  Modifier-Kette (Bug 19) — Restore-Dialoge in eine eigene
  `@ViewBuilder`-Property ausgelagert.
- "ok, das Backup an sich scheint zu funktionieren, eine verbindung zum
  wiederhergestellten Router funktioniert nicht: Flascher Username oder
  Passwort. Nur ein Hard-Reset hilft dann noch" — ernster Bug (18):
  RouterOS-Exporte enthalten nie Passwörter, `no-defaults=yes` löscht
  zusätzlich den Werks-Admin-Account, nach dem Restore also kein Login
  mehr vorhanden, nur per Hardware-Reset behebbar. Fix: aktuelles
  App-Login wird jetzt vorne ins Restore-Skript eingefügt (vor dem
  eigentlichen Sicherungsinhalt, da RouterOS den Import beim ersten
  Fehler abbricht), inkl. zwei Tests für die Escaping-Logik.
- "alles gut, ist ja ein Testgerät :)" — Nutzer gelassen trotz
  Aussperrung. "gut, das hat funktioniert." — Restore inkl. Login-Erhalt
  danach bestätigt.
- "ja, committen und beides aktualisieren" → dieser Eintrag, HANDOFF.md
  (Bug 18+19, M13, aktualisierte Bekannte Einschränkungen/Nächste
  Schritte inkl. Hinweis auf den zweiten Werksreset/Hardware-Reset
  während der Session) aktualisiert, Commit erstellt.

## Stand am Ende dieser Session — Backup-Wiederherstellung (M13)

M13 gebaut und live bestätigt — der letzte seit langem offene Punkt aus
HANDOFF.md ("Backup-Wiederherstellung fehlt komplett") ist erledigt. Der
Weg dahin war der bisher risikoreichste dieser App: ein echter, live
reproduzierter Aussperr-Vorfall (Bug 18), der den Nutzer zu einem
Hardware-Reset zwang, bevor der Fix (Login-Erhalt vorangestellt im
Restore-Skript) das behoben hat. Modell-Abgleich vor dem Restore
(RB750Gr3 vs. "hEX" — wichtige Feld-Verwechslung selbst noch vor dem
Bauen gefunden und vermieden) und der geforderte Brick-Warnhinweis sind
mit drin. Router wurde im Lauf der Session zweimal komplett
zurückgesetzt (einmal gewollt für einen sauberen Stand, einmal
ungewollt durch Bug 18) — alle älteren Hinweise auf spezifische
Test-Konfiguration (`test-vlan`, `dhcp5` etc.) aus früheren Sessions
sind dadurch hinfällig, siehe HANDOFF.md Nächste Schritte. Offen bleibt
weiterhin die `.id`-Positionsüberlagerungs-Frage für den Experte-Tab
(Bug 15) und alle länger schon offenen Punkte (M7-Rest, M8-Hardware-
Test, WLAN/Bonding/PPPoE-Live-Tests).

## Session: Update-Check (M14) + Design-Durchgang

- "ok, sieht gut aus. weiter mit der Update-Überprüfung." — mehrdeutig
  (RouterOS-Software vs. Routerboard-Firmware), per `AskUserQuestion`
  geklärt: "Beides". Vorher per Recherche-Agent geprüft: `/system
  package update` (Felder channel/installed-version/latest-version/
  status, check-for-updates dann install, install reboot automatisch)
  und `/system routerboard upgrade` (braucht in Winbox normalerweise
  y/n-Bestätigung, kein automatischer Reboot danach).
- Gebaut: Routerboard-Vollinfo + Software-Update-Sektion im
  Verbinden-Tab, "Firmware aktualisieren" mit Warnhinweis zur unsicheren
  Interaktivitäts-Frage.
- "davon sehe ih nichts, CMD+Q wurde ausgeführt und app neugestartet" →
  "nur die neue 'Routerboard'-Sektion fehlt" → gemeinsam per SSH
  verifiziert (`/system routerboard print terse` → "bad parameter
  terse"), dann über den Experte-Tab denselben generischen Lesepfad
  getestet ("Unerwsrtete Antwort vom Router: bad commandname add" beim
  Anlegen-Versuch, Liste vorher leer) — Bug 20 gefunden: der bestehende
  Singleton-Fallback (Bug 8) reagiert nur auf eine geworfene Exception,
  aber RouterOS liefert "bad parameter terse" für dieses Menü mit
  Exit-Code 0 zurück, landet also als normaler leerer Output. Fix:
  zusätzlich den Output-Text selbst prüfen. "ok, sieht gut aus" danach.
- "sieht gut aus, der Button 'Firmware aktualisieren' funktioniert
  auch?" — ehrlich beantwortet: kann ich nicht bestätigen ohne Live-Test.
  Nutzer testete, Konsolen-Ausgabe geteilt ("Firmware upgraded
  successfully, please reboot for changes to take effect!") — die
  interaktive Bestätigung blockierte den SSH-Weg nicht, wie gehofft.
  "ja, bau das" → "Jetzt neu starten"-Button ergänzt, ebenfalls sofort
  funktionierend gemeldet.
- "ok, jetzt zum Design. ich hätte gerne die einzelnen Sektionen
  sauberer getrennt - Trennstriche oder Rahmen um die Sektionen." — per
  `AskUserQuestion` Umfang ("ganze App") und Stil ("Karten mit Rahmen")
  geklärt. Geprüft: Wizard-Schritte und Experte-Tab nutzten schon
  `.formStyle(.grouped)` (nativer macOS-Karten-Look), nur Verbinden-
  Detailseite/Sicherungen/Geräte liefen auf nackter `List` — auf
  `Form`+`.formStyle(.grouped)` umgestellt statt eine eigene
  Karten-Komponente zu bauen.
- "wie sieht es mit einem Darkmode aus?" — Code geprüft (keine
  `.preferredColorScheme`-Überschreibung, kein
  `NSRequiresAquaSystemAppearance`, nur adaptive System-Farben) und
  bestätigt: funktioniert schon ohne Codeänderung. Nutzer bestätigte
  nach eigenem Test ("passt super und funktioniert").
- "ja, committen und beides aktualisieren" → dieser Eintrag, HANDOFF.md
  (M14, Bug 20, Design-Durchgang, Dark-Mode-Bestätigung) aktualisiert,
  Commit erstellt.

## Session: M8-Hardware-Test begonnen (nicht abgeschlossen)

- "was steht als nächstes auf dem Plan?" → HANDOFF-Liste zusammengefasst.
  "fangen wir bei 4 an" (M8 Netzwerk-Isolation) → per `AskUserQuestion`
  geklärt: voller Wizard-Durchlauf statt nur gezieltem Firewall-Test,
  kombiniert damit Punkt 1 (kompletter Wizard-Durchlauf) mit.
- Unterwegs zwei praktische RouterOS-Fragen beantwortet: ether5 aus der
  Bridge entfernen (`/interface bridge port remove [find
  interface=ether5]` bzw. Experte-Tab), dann "Unerwartete Antwort vom
  Router: failure: dhcp-client on that interface already exists" beim
  WAN-Schritt — Ursache: Wizard nutzt immer `.add`, aber auf dem
  Interface existierte aus der zurückgespielten Sicherung schon ein
  DHCP-Client. "fixe es gleich" → Bug 21, `SetupViewModel.
  applyIdempotently` (Fallback auf `.set` bei `.add`-Fehlschlag auf
  DHCP-Client/PPPoE), deployt.
- "ok, alles speichern, genug für heute" → dieser Eintrag, HANDOFF.md
  (Bug 21, Nächste-Schritte Punkt 1 als "in Arbeit" markiert — der
  eigentliche M8-Isolationstest ist noch nicht zu Ende geführt, nächste
  Session dort fortsetzen) aktualisiert, Commit erstellt. Sitzung beendet.

## Session: M8 komplett live verifiziert (manuell + über die App)

- "wo waren wir stehen geblieben?" → Stand zusammengefasst, "weiter bei
  M8" (M5 kann mangels Hardware nicht getestet werden).
- Nutzerfrage: Port 5 komplett isolieren, eigener DHCP-Server, trotzdem
  Internet — `mikrotik-setup.md` Szenario C traf exakt zu, Befehle
  gegeben. Danach mehrere Diagnoserunden am echten Router (SSH), jede
  ein eigener Konfigurationsfehler statt App-Bug: Adresse zuerst als
  `/32`, dann versehentlich als `.0`-Netzadresse statt `.1`-Host-Adresse
  eingetragen (Route fehlte); danach DNS-Anfragen an den Router liefen
  in Timeout, obwohl Lease+Route+Internet gingen — Ursache: `ether5`
  fehlte in der defconf-Interface-Liste "LAN", RouterOS' Werks-Firewall
  blockt Input von allem, was nicht in dieser Liste steht. Isolation
  danach per `/interface list`-basierter Forward-Drop-Regel gesetzt und
  beidseitig bestätigt (iMac ↔ Laptop erreichen sich nicht, Internet
  bleibt für beide).
- "testen wir das nochmal über die App" → derselbe Test über den
  Wizard (Experte-Modus, `ether4`) wiederholt, um die eigentliche
  M8-Abnahmebedingung zu erfüllen. Dabei vorab zwei App-Bugs erkannt und
  gefixt, bevor überhaupt angewendet wurde: **Bug 22** (LAN/VLAN-Schritt
  fügt neues Interface nie der "LAN"-Liste hinzu — derselbe DNS-Bug wie
  eben, jetzt als App-Bug bestätigt) und **Bug 23** (voller
  Wizard-Durchlauf gegen bereits konfigurierten Router bricht am
  zweiten, nicht-idempotenten Befehl ab — Nutzer wählte "Idempotenz
  jetzt erweitern" statt nur Befehle zu verifizieren).
- Nach Apply zeigte `/ip firewall filter print` zwei mit `I` (INVALID)
  markierte Isolationsregeln: `ether4` war noch Bridge-Slave (Werks-
  Bridging), RouterOS verwirft Interface-Matcher auf Slave-Ports selbst.
  **Bug 24** gefunden — Nutzer entfernte `ether4` manuell aus der
  Bridge, danach wurden die Regeln automatisch gültig; Fix (automatisches
  Lösen aus der Bridge vor Zuweisung) direkt im Wizard-Code ergänzt und
  getestet.
- Alle Live-Tests am Ende erfolgreich (Lease, Gateway-Ping, DNS,
  Internet, Isolation gegen iMac/Laptop), 52 Unit-Tests grün. M8 als
  erster Milestone sowohl manuell als auch über die App selbst
  verifiziert. Nebenbei zwei veraltete Doku-Stellen korrigiert (Gitea-
  Remote existiert längst, war noch als "nicht vorhanden" dokumentiert).
  HANDOFF.md/README.md aktualisiert, Commit + Push.

## Session: Experte-Tab-Politur + M15 (Übersicht-Tab)

- "machen wir weiter bei den Tooltips im Experte-Tab" → alle
  `RouterOSFieldSchema.help`-Texte überarbeitet (konkrete Adress-
  Beispiele wie "192.168.88.1/24"), plus auf Nachfrage fette
  Sektions-Überschrift und hellblaue Hervorhebung des aktiven
  Listeneintrags ergänzt (`.listRowBackground` funktionierte im
  Sidebar-Stil nicht, Hintergrund stattdessen am Zeileninhalt gesetzt).
  Commit + Push.
- "lass uns den Übersicht-Tab nochmal anschauen... Größe... Hover-Infos
  auf Verbindungslinien" → mehrere Iterationsrunden: Auto-Fit-Versuch
  (GeometryReader) brach das Scroll-Verhalten, wieder zurückgezogen;
  echter Geometrie-Bug gefunden (gleiche-Spalte-/Rückwärts-Kanten
  schossen mit falschen Kontrollpunkten über den Canvas hinaus, links
  abgeschnitten) und gefixt; Hover-Flackern durch Trägheit + Beschränkung
  auf die hervorgehobenen Kanten behoben; Klick-vs-Hover-Priorität
  vertauscht (Klick gewinnt jetzt), da Hover über fremde Karten beim
  Nachfahren einer Linie die Auswahl verdrängte; Linien-Klick zeigt jetzt
  volle Erklärung im rechten Panel statt nur Hover-Tooltip.
- "neuer Milestone: ... direkt bearbeiten? und rückwirken ... (wie im
  Experte-Tab)" → M15: `OverviewNode.EditTarget` (Menüpfad/REST-Pfad/
  RouterOS-`.id`) für IP-Adressen, Pools, DHCP-Server/-Netzwerke/
  -Clients, Routen, Firewall-Filter-/NAT-Regeln, WireGuard-Peers.
  "Bearbeiten"-Button öffnet dieselbe `ExpertItemEditView`-Sheet wie der
  Experte-Tab (dafür `private` entfernt), eigene `ExpertViewModel`-
  Instanz, kein Code dupliziert. Nutzer bestätigte live: Kommentar an
  einer Firewall-Regel geändert, "funktioniert". 59 Unit-Tests grün,
  HANDOFF.md/README.md aktualisiert (u.a. M11s veraltete "rein lesend"-
  Aussage korrigiert), Commit + Push.
- "nachdem entfernen des Kommentars... bleibt dieser bestehen. ...Route
  ... Fehler: bad parameter immediate-gw" → zwei Bugs in
  `ExpertViewModel.pendingCommand` gefunden (betreffen Experte-Tab UND
  Übersicht-Tab): geleerte Felder wurden aus den Argumenten gefiltert
  statt explizit als "" gesendet (RouterOS' `set` ändert nur übergebene
  Parameter); unkuratierte "Weitere Parameter" wurden bei jedem Speichern
  blind mitgeschickt, auch nur-lesbare/berechnete Felder wie einer
  Route's `immediate-gw` — RouterOS lehnte das ab und brach die ganze
  Änderung ab. Bug 25/26, beide gefixt (Feld bleibt bei vorherigem Wert
  erhalten zum expliziten Leeren + SSH-Rendering zeigt leeren Wert jetzt
  als `""`; unkuratiertes Feld nur noch gesendet wenn tatsächlich
  geändert). 54 Unit-Tests grün (neue `ExpertViewModelTests` +
  `RouterOSCommandBuilderTests`-Ergänzung), HANDOFF.md aktualisiert,
  Commit + Push.
- "ein fehler beim kommentar schreiben in der Route... value of distance
  out of range" → Bug 27: dieselbe Ursache wie Bug 26, aber bei einem
  kuratierten Feld — eine dynamische Route hat `distance=0`, unverändert
  zurückgesendet lehnt RouterOS das ab. Fix generalisiert: "nur bei
  Änderung senden" gilt jetzt für kuratierte UND unkuratierte Felder,
  Bug-25-Sonderfall dadurch überflüssig geworden und entfernt. Dabei
  entdeckt: `ExpertViewModelTests.swift` lief die ganze Zeit gar nicht
  mit, weil nach dem Anlegen der Datei kein `xcodegen generate` lief —
  Merksatz für künftige neue Dateien notiert. Nach `xcodegen generate`
  58 Unit-Tests grün (inkl. `ExpertViewModelTests` jetzt tatsächlich
  ausgeführt). HANDOFF.md aktualisiert, Commit + Push.
- "neuer fehler: no such item (4)... /ip/route/set" → Nutzer bestätigte
  auf Nachfrage per `/ip route print detail`: Route ist dynamisch
  (`D`-Flag, `distance=0`, automatisch durch die Bridge-IP angelegt).
  Bug 28: dynamische Routen bieten jetzt gar kein "Bearbeiten" mehr an
  (`distance=0` als verlässliches Signal, da RouterOS' "dynamic"-Flag
  nicht in `print terse` steht). 59 Unit-Tests grün, HANDOFF.md
  aktualisiert, Commit + Push.
- "funktioniert, der Übersicht-Tab aktualisiert sich nicht selbst..." →
  Bug 29: `.task` lief nur einmal pro View-Lebenszeit, SwiftUI zerstört
  Tab-Inhalte auf macOS beim Wechsel aber nicht. Fix: `.onAppear` statt
  `.task`, feuert bei jedem Tab-Besuch neu. 59 Unit-Tests grün, HANDOFF.md
  aktualisiert, Commit + Push.
- "was sind die nächsten Milestones?" → offene Punkte aus HANDOFF.md
  zusammengefasst, Nutzer wählte "6" (M15 auf Interfaces/Adress-Listen
  erweitern). Interfaces umgesetzt: VLAN-Interfaces über kuratiertes
  `/interface vlan`, alle anderen Typen generisch über `/interface`.
  Live gefunden: Nutzer wollte `ether5`→`ether51` umbenennen, hat aber
  `default-name` (Werksname, nie änderbar) statt `name` erwischt, da
  beide unbeschriftet in "Weitere Parameter" nebeneinander standen —
  "bad parameter default-name". Fix: `/interface` jetzt kuratiert
  (Name/Kommentar/Deaktiviert), Tooltip warnt explizit vor der
  Verwechslung. Live bestätigt ("funktioniert"). Adress-Listen bewusst
  weiter zurückgestellt (andere UI-Form nötig). 60 Unit-Tests grün,
  Manual.md/HANDOFF.md aktualisiert, Commit + Push.
- "jetzt machen wir das ganze zweisprachig..." → M16 gestartet, Nutzer
  wählte "Schrittweise, Tab für Tab" als Vorgehen. Erster Versuch: Apple
  String Catalog (`Localizable.xcstrings`) + `.environment(\.locale, ...)`
  auf `WindowGroup`-Ebene, Tab-Namen/Kategorien/Experte-Tab-Chrome mit
  passenden deutschen Keys befüllt. Live: "wenn ich von DE auf EN
  wechsele passiert nicht im experte-Tab" → Root Cause vermutet: Swifts
  `Text`/`.help`/etc. wandeln nur String-*Literale* automatisch in
  `LocalizedStringKey` um, nicht String-*Variablen* (`field.label` etc.)
  — jede Stelle explizit mit `LocalizedStringKey(...)` umschlossen, 60
  Tests grün. Live erneut: "bleibt auf deutsch" — Fix wirkungslos.
  Tatsächliche Ursache gefunden: `.environment(\.locale)` steuert nicht,
  welche Sprachtabelle `Text(LocalizedStringKey)` zur Laufzeit auflöst
  (nur Calendar/DateFormatter-artige APIs) — die String-Catalog-Bindung
  scheint an der Bundle-internen Locale-Verhandlung beim App-Start
  festzuhängen und reagiert nicht auf einen Laufzeit-Override. Fix:
  `Localizable.xcstrings` entfernt, neuer eigener Helfer
  `Core/Localization/L10n.swift` (`L10n.t(german, appLanguage) -> String`,
  simples Dictionary, deutscher Text als Schlüssel), jede betroffene View
  liest `@AppStorage("appLanguage")` selbst und ruft `L10n.t(...)` direkt
  auf statt über die Environment/Catalog-Kette zu gehen. Umgesetzt für
  alle 6 Tab-Namen, alle 13 Menü-Kategorien, komplette Chrome von
  `ExpertView.swift`/`ExpertMenuDetailView.swift` (Buttons, Dialoge,
  Feld-Labels/-Hilfetexte) — Firewall-Familie darin bereits vollständig
  übersetzt aus dem ersten Versuch. 60 Tests grün, live bestätigt ("das
  sieht gut aus"). HANDOFF.md/README.md/Manual.md aktualisiert, Commit +
  Push. Rest von `RouterOSSchemaCatalog.swift` sowie die übrigen Tabs
  bleiben offen für Folgesessions (Tab für Tab, wie vereinbart).
- "was schlägst du als nächsten schritt vor?" → Empfehlung: restliche
  Katalog-Familien übersetzen (geringes Risiko, baut auf verifiziertem
  Mechanismus auf). Nutzer: "mach deine Empfehlung". Alle 9 Menü-
  Familien aus `RouterOSSchemaCatalog.swift`
  (Firewall/Interfaces/IP/Routing/VPN/WLAN/Queues/System/Werkzeuge)
  durchgelesen und in `L10n.swift`s `translations`-Dictionary übersetzt
  (376 Einträge gesamt). Dabei zwei Dictionary-Key-Kollisionen gefunden
  und behoben ("Deaktiviert", "Nur zur eigenen Wiedererkennung." kamen
  in zwei Familien mit identischem deutschen Text vor — Swift-
  Dictionary-Literale mit doppelten Schlüsseln crashen erst zur
  Laufzeit, nicht beim Compilieren, per Python-Skript systematisch auf
  Duplikate geprüft). 60 Tests grün, live bestätigt ("funktioniert").
  Damit ist der komplette Experte-Tab zweisprachig. HANDOFF.md/
  README.md/Manual.md aktualisiert, Commit + Push.
- "mach den Verbinden-Tab zweisprachig" → `ConnectView.swift`
  durchgearbeitet: Verbindungsformular, Verbindungsstatus, Geräte-/
  Routerboard-Infos, Software-/Firmware-Update-Bereich samt aller
  Bestätigungsdialoge, Zertifikats-/SSH-Hostkey-Warnungen. Mehrere
  Nachrichten mit eingebetteten Laufzeitwerten (Fingerabdruck, Version,
  Datum) in übersetzte statische Textteile + unverändert eingefügten
  Wert zerlegt, statt einen Dictionary-Key mit Platzhalter zu bauen. Die
  vier `View`-Extension-Hilfsfunktionen für die Dialoge bekamen dafür
  einen zusätzlichen `appLanguage`-Parameter (liegen außerhalb der
  View-Struct, kein direkter `@AppStorage`-Zugriff). Dabei eine Lücke im
  bereits als "komplett" gemeldeten Experte-Tab-Katalog gefunden und
  geschlossen: Feld-Label "Passwort" (in fünf Schemas verwendet) hatte
  keinen eigenen Übersetzungseintrag. `L10n.swift` jetzt 444 Einträge,
  keine Duplikate (Python-Skript-Check). 60 Tests grün, live bestätigt
  ("sieht gut aus" / "sieht gut aus"). Bewusst nicht übersetzt:
  Backend-/Laufzeit-Text von RouterOS oder app-eigenen Fehlerpfaden
  (technische/englische Ausgaben, keine kuratierten UI-Strings).
  HANDOFF.md/README.md/Manual.md aktualisiert, Commit + Push.
- "nochmal zum Tab Übersicht, nur eine Idee: wenn ich einen Interface-
  Button klicke, möchte ich ALLE Linien sehen..." → `OverviewGraph.
  highlightedNodeIDs(startingAt:)` ergänzt: für Interface-Knoten eine
  BFS über alle Kanten (beide Richtungen), für jeden anderen Knotentyp
  unverändert nur 1-Hop. "teste die Interface-Verbindung im Übersicht-
  Tab" → da die laufende GUI nicht selbst klickbar ist, die BFS-Logik in
  `OverviewGraphTests.swift` isoliert getestet (Interface→Adresse→DHCP-
  Netzwerk und Interface→DHCP-Server→Pool, inkl. Sanity-Check, dass Pool/
  DHCP-Netzwerk wirklich zwei Hops entfernt liegen). 61 Tests grün.
  "ich räume den Router mal auf - werksreset" / "ist durch, funktioniert"
  → HANDOFF.md aktualisiert: Router am 2026-09-15 erneut auf
  Werkseinstellungen, alle alten Config-Stände hinfällig. "alles
  speichern bitte" → HANDOFF.md/CHATLOG.md aktualisiert, Commit + Push —
  visuelle Live-Prüfung des Diagramms selbst steht noch aus (nur die
  Logik ist getestet), auf ausdrücklichen Nutzerwunsch trotzdem
  gespeichert.
- "beim Einrichten unter Einrichten/Experte, wenn man ein neues LAN
  anlegt, mache vorher eine prüfung, ob der entsprechende port frei
  ist..." → LAN-Port-Konflikt-Prüfung gebaut: `PortConflict`-Modell,
  `ConnectionService.checkPortConflict(interfaceName:)` (liest Bridge-
  Mitgliedschaft/IP-Adresse/DHCP-Client/PPPoE-Client parallel per
  `async let`), `LanStepView`s neue Warnbox mit zwei aufeinanderfolgenden
  Bestätigungsdialogen. "bitte nach erfolgreichen Einrichten einen
  'Fertig'-Button" → `SetupViewModel.finish()` setzt den Assistenten
  nach erfolgreichem Anwenden zurück. Beides nur Build+Unit-Test-
  verifiziert, noch nicht live getestet.
- "ich würde gerne mehrere Logins hinterlegen können, quasi eine Liste
  bekannter Router..." → M17: `SavedRouter`/`SavedRoutersStore`
  (JSON in UserDefaults), Anzeigename defaultet auf `RouterDeviceInfo.
  boardName` beim ersten Connect, bleibt danach unverändert außer bei
  explizitem Umbenennen. "ich sehe 'Bekannte Router' nicht" → Liste
  füllt sich nur bei einer neuen Verbindung nach dem Rebuild, nicht
  rückwirkend. "das umbenennen funktioniert nicht" → TextField steckte
  in einem `.disabled(isRenaming)`-Button, der auch das TextField
  deaktivierte — Fix: kein umschließender Button mehr, `.onTapGesture`
  für Zeilen-Auswahl. "ein Standort... müssten noch als Freitextfelder"
  → `SavedRouter.location` ergänzt, Menü "Umbenennen"→"Bearbeiten"
  (Name+Standort zusammen), rückwärtskompatibles Decoding. "wenn die
  Liste länger als 4 bekannte Router wird, mach einen Scrollbalken" →
  eigene `ScrollView` mit Höhen-Cap statt das Formular wachsen zu
  lassen. Alle live bestätigt außer dem Scroll-Cap (kein explizites
  Feedback, kein Einwand).
- "kannst du die Punkt vor der Interfaces-Bezeichnung einfärben oder
  sogar animieren (grün), wenn sie aktuell in Verwendung sind und Daten
  übertragen?" → M18: neue `InterfaceTraffic`/`InterfaceTrafficMonitor`
  (eigene dedizierte SSH-Verbindung, `/interface monitor-traffic` hat
  kein REST-Äquivalent), 3s-Polling. "alle buttons sind grau, keine
  Animation" → Nutzer bot direkten Router-Zugriff an; da ich keine
  Zugangsdaten habe und ungern ein Passwort im Chat sehen wollte, um
  zwei Diagnose-Befehle gebeten (`/interface print without-paging
  terse`, `/interface monitor-traffic ... once`) statt zu raten. Zwei
  reale Bugs gefunden: (1) `running=`/`disabled=` existieren in echtem
  Terse-Output gar nicht — RouterOS codiert das als Buchstaben-Flags vor
  dem ersten Feld (R/X/S), ein vorbestehender, nie zuvor aufgefallener
  Parser-Bug; (2) `monitor-traffic` liefert `"50.7kbps"` statt einer
  reinen Zahl, `Int(...)` scheiterte lautlos zu 0. Beide gefixt, 82
  Tests grün (inkl. 2 Tests mit dem exakten Nutzer-Output). Live
  bestätigt ("sehr gut").
- "im Übersicht-tab... die Linien auch animiert haben, mit einer
  animierten Flußrichtung" → M19a: `EdgesCanvas` in `TimelineView(.
  animation)` gewickelt, `dashPhase` wandert über die Zeit in Richtung
  "von→nach". "kann man die einzelnen Kästchen verschiebbar machen? ...
  ein Button für den Reset" → M19b: `nodeOffsets`-State +
  `@GestureState` fürs laufende Draggen, `effectivePositions` kombiniert
  beides für Knoten-Karten UND `EdgesCanvas`. "der Button ... fehlt" →
  `Label` (Icon+Text) vermutlich in Toolbar-Overflow verschwunden, Fix
  auf Icon-only. "verwirrend, ähnlich wie Refresh" → auf reinen
  Text-Button "Zurücksetzen" umgestellt (wie der bereits funktionierende
  "100%"-Button). Alle drei Teile live bestätigt. "commit+push, bitte
  die Readme.md nicht vergessen" → HANDOFF.md/README.md/Manual.md/
  CHATLOG.md aktualisiert, Commit + Push (inkl. der noch nicht live
  getesteten Port-Konflikt-Prüfung + Fertig-Button, auf ausdrücklichen
  Nutzerwunsch mitgespeichert).
- "ergänze die Mermaid-Grafik um die neuen Features" → README.md-
  Architekturdiagramm um `InterfaceTrafficMonitor`s eigene SSH-Verbindung
  und den lokalen `SavedRoutersStore`→`UserDefaults`-Pfad ergänzt. Commit
  + Push.
- "der Tab 'Geräte' muss umbenannt werden in Lan-Scanner ... zusätzlich
  einen Button 'neu scannen'" → M20 gestartet: Tab umbenannt, "Aktuali-
  sieren"-Button zu "Neu scannen" (identische Aktion, nur klarerer
  Name). "sieht gut aus" → bestätigt.
- "den Lan-scanner bohren wir noch ein wenig auf... Netzwerk-Tools
  liste... nslookup, ping etc." → `NetworkToolsService` (eigene SSH-
  Verbindung, `/ping`/`/tool traceroute`/`/resolve`), Rohausgabe im
  Sheet statt geparst (Format nicht live verifiziert). Sicherheits-
  maßnahme: Zeichen-Validierung gegen Command-Injection über einen
  böswilligen DHCP-Hostnamen (RouterOS-Konsole trennt Befehle mit ";").
  Live bestätigt.
- "die Warnung zum zuweisen einer festen IP-Adresse... muss erweitert
  werden. der Hinweis, wie die Adresse wieder in dynamisch gemacht
  werden kann" → Warnhinweis um Rückweg-Erklärung ergänzt (Rechtsklick
  → "Feste Zuweisung entfernen", Gerät danach kurz trennen/neu
  verbinden). Live bestätigt.
- "der refresh-button muss prominenter werden" → `.buttonStyle(.
  borderedProminent)` auf "Neu scannen". Live bestätigt.
- "ersetze DE und EN mit den jeweiligen Landesflaggen" → 🇬🇧/🇩🇪 statt
  Text, zeigt weiter die Sprache, zu der ein Klick wechselt. Live
  bestätigt.
- "macht es sinn andere Sprachen per Plugin zu importieren?" (nur Frage,
  keine Umsetzung) → Empfehlung: für 1-2 feste Sprachen reicht das
  bestehende `L10n.swift`-Muster, ein echtes Plugin-System wäre Overkill
  ohne konkrete Nachfrage. "lass uns bei DE/EN bleiben" → bestätigt.
  "eventuell kommt spanisch indisch noch dazu... MikroTik-Router günstig,
  daher oft in ärmeren Ländern wie Brasilien" → als Claude-Memory
  (`future-language-support.md`) für Folgesessions festgehalten, keine
  Code-Änderung.
- "können wir die Netzwerk-tools noch erweitern? ein Portscanner...
  (Offene Ports rot, geschlossene grün, nicht erreichbare grau)" →
  `PortScanner` (Network.framework, TCP-Connect direkt von diesem Mac,
  NICHT über den Router — RouterOS hat kein eingebautes Portscan-Tool).
  Live-Bug beim ersten Testlauf-Versuch bereits im eigenen Unit-Test
  gefunden: `NWConnection` meldet eine verweigerte Verbindung über
  `.waiting`, nicht `.failed` — der ursprüngliche Code prüfte nur
  `.failed` und wartete den vollen Timeout aus statt sofort "geschlossen"
  zu melden. Gefixt, Test bestätigt es gegen einen echten (aber
  garantiert freien) Loopback-Port. 92 Tests grün. "sieht gut aus und
  funktioniert, alles speichern committen und pushen, denk an die
  Mermaid-Grafik" → README.md/HANDOFF.md/Manual.md/CHATLOG.md
  aktualisiert (inkl. Mermaid-Diagramm um `NetworkToolsService`-SSH-
  Verbindung und `PortScanner`s direkten Mac→Gerät-Pfad ergänzt),
  Commit + Push.