- RouterOsTimeouts: Lesen 15 s, Schreiben 30 s, Befehle (Backup/Restore/Update) 120 s,
Verbindungstest 8 s; vorher global 8 s (Fehlalarme auf schwacher Hardware, Mac v1.3/v1.6)
- BinaryRouterOsClient: Zugriffe per SemaphoreSlim serialisiert, nach !trap wird das
folgende !done mitgelesen (sonst las der naechste Befehl eine fremde Antwort)
- REST-Fehler nennen RouterOS' 'detail'
- IRouterOsClient.RunAsync liefert die Ausgabe eines Befehls (Basis fuer Ping/Traceroute)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Isolierte VLANs erreichten WebFig/SSH/API des Routers (Mac #41). Neuer Baustein
NetworkIsolation: Forward-Drop in beide Richtungen mit Kommentar, Input nur DNS/DHCP,
Connection-Tracking des isolierten Netzes leeren. DuplicateRuleGuard ignoriert den
Kommentar, damit aeltere Regeln nicht doppelt entstehen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Arbeitspakete P1-P41 mit Gitea-Issues (#37-#69, Milestone M-Mac-Abgleich-v1.11),
ohne App-Store-/Verkaufsthemen.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nutzer-Feedback: Seit dem Sidebar-Umbau gab es "Bekannte Router" doppelt —
als vollständige Bearbeitungsliste im Verbindungs-Schritt (Hauptfenster) und
als Kurzauswahl in der Sidebar. Der Verbindungs-Schritt zeigt jetzt nur noch
das Formular für ein neues, unbekanntes Gerät.
Rückfrage zur Konsequenz: Bearbeiten (Name/Standort) und Entfernen gab es
bisher nur in der jetzt entfernten Liste. Auf Nutzerwunsch zieht "Entfernen"
kompakt in die Sidebar (kleines Papierkorb-Symbol neben jedem Eintrag);
Umbenennen entfällt bewusst — der Name kommt weiterhin automatisch vom
Gerätemodell.
Aufgeräumt: UseSavedRouterCommand (kein eigenes Kommando mehr nötig, nur noch
intern von ConnectToSavedRouterAsync genutzt) und SavedRouterEntry.ToSavedRouter
(war ausschließlich für die jetzt entfernte Bearbeiten-Persistenz da) entfernt.
Core-Suite unverändert grün (138 Tests). Nicht-destruktiver Smoke-Test
bestätigt, dass die Sidebar weiterhin alle bekannten Router korrekt lädt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bisher gab es nur ein einzelnes simuliertes Testgerät (127.127.127.127,
"CHR (Simulator)"). Um Funktionen wie "Bekannte Router" oder den Sidebar-
Umbau mit mehreren, klar unterscheidbaren Einträgen ausprobieren zu können,
ohne echte zweite/dritte Hardware zu brauchen, unterstützt DemoRouterOsClient
jetzt mehrere Profile (DemoDeviceProfile): zusätzlich 127.127.127.128
("Büro-Router", hAP ac2, RouterBOARD) und 127.127.127.129 ("Keller-Switch",
CRS326-24G-2S+, RouterBOARD) — alle mit denselben Zugangsdaten (admin/admin).
Jedes Profil bekommt dynamisch eine zu sich selbst passende Demo-Backup-Datei
in "Backup verwalten" (statt nur das ursprüngliche CHR-Profil). Die simulierte
"/system/routerboard"-Antwort unterscheidet jetzt zwischen "kein RouterBOARD"
(wie beim ursprünglichen CHR-Profil, unverändertes Verhalten) und "echtes
RouterBOARD" (neue Profile, meldet Modell zusätzlich über routerboard.model).
8 neue Unit-Tests, bestehende 132 unverändert grün. Die beiden neuen Router
wurden testweise bereits verbunden und erscheinen jetzt unter "Bekannte
Router" (lokale Datei, unabhängig vom Git-Repository).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nutzer-Wunsch "Optik-Renew": Sidebar zeigt jetzt unabhängig vom aktuellen
Schritt eine Verbindungs-Karte statt nur Logo + Schritt-Liste.
- Nicht verbunden: kompakte Liste bekannter Router (Name + Host/Benutzername),
ein Klick verbindet direkt und springt bei Erfolg automatisch weiter
(ConnectionStepViewModel.ConnectToSavedRouterCommand kombiniert
UseSavedRouter+TestConnectionAsync; MainViewModel.QuickConnectCommand ruft
das auf und geht bei Erfolg per GoNextCommand weiter).
- Verbunden: grüner Punkt + Gerätename/-modell (MainViewModel.
ConnectedDeviceLabel — fällt auf den Host zurück, bis die Geräte-Erkennung
gelaufen ist) + "Wechseln"-Button (trennt Verbindung, setzt session.Device
zurück, springt zum Verbindungs-Schritt).
Manuelle Formular-Eingabe für neue Geräte bleibt bewusst auf der
Verbindungs-Schritt-Seite — passt nicht kompakt in die schmale Sidebar.
Als eigener Entwurf umgesetzt (kein Referenz-Screenshot vorgegeben), im
bestehenden WPF-UI/Fluent-Stil. WPF-Smoke-Test für ConnectedDeviceLabel-
Übergänge und den Wechseln-Ablauf; QuickConnect selbst per Code-Review
verifiziert (dünner Wrapper um bereits getestete Pfade, im Scratch-Harness
nicht end-to-end testbar wegen internem WindowsCredentialStore-Zugriffs).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nutzer-Feedback: Der letzte Schritt "RouterOS-Update" war in der Sidebar nicht
sichtbar. Ursache: die Schritt-Liste steckte in einem einfachen StackPanel
ohne ScrollViewer — mit inzwischen 13 Schritten (nach Ergänzung von "Was
möchtest du tun?" und "Backup verwalten") überschritten die unteren Einträge
bei kleineren Fensterhöhen den sichtbaren Bereich, ohne dass sich dorthin
scrollen ließ.
Logo-Kopfzeile bleibt fix (Grid-Row Auto), darunter ScrollViewer mit
VerticalScrollBarVisibility=Auto um die Schritt-Liste (Grid-Row *).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
#33 — Architektur als dritte Prüfstufe: RouterBackupService bettet zusätzlich
RouterDevice.Architecture in den Backup-Dateinamen ein (Modell_Architektur_
Seriennummer). BackupRestoreService.CheckCompatibility liefert jetzt vier
Stufen statt zwei: Match, SameModelDifferentDevice (gleiches Modell+Architektur,
bekannt andere Seriennummer — gelb markiert, nur mit ausdrücklicher "auf eigene
Gefahr"-Bestätigung wiederherstellbar), Mismatch (anderes Modell/andere
Architektur — weiterhin hart blockiert) und Unknown. Ältere Backups ohne
eingebettete Architektur/Seriennummer fallen weiterhin auf den Modell-Abgleich
zurück.
#34 — Backup-Bereich aus dem Interview gelöst: neuer Schritt "Was möchtest du
tun?" (AreaSelectionStepViewModel) direkt nach der Verbindung, setzt
WizardSession.SelectedArea (AppArea-Enum). Bei "Backup verwalten" überspringen
alle Konfigurations-/Analyse-Schritte per ShouldSkip, direkt zum neuen
BackupManagementStepViewModel — liest das Gerät eigenständig aus (unabhängig
von DeviceOverviewStepViewModel) und bündelt Auflisten/Erstellen/
Wiederherstellen. Die alte "Backup wiederherstellen"-Option in der Moduswahl
sowie WizardSession.IsRestoreBackupMode wurden entfernt (kein Parallel-
Mechanismus zur neuen Navigation) — SummaryStepViewModel ist wieder rein für
die geplanten Assistent-Änderungen zuständig. Der ShouldSkip-basierte Ansatz
deckt sich bewusst mit dem für M-Experte (#21) vorgesehenen Bedarf an
Navigation außerhalb der linearen Schritt-Kette.
17 neue/angepasste Unit-Tests (Core: 132 gesamt), WPF-Smoke-Test über die
komplette MainViewModel-Navigation (Connect → Bereich wählen → Backup
verwalten direkt erreicht, alle vier Kompatibilitäts-Stufen, Rückwärts-
Navigation) sowie Regressionscheck des normalen Assistenten-Pfads.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nutzer-Feedback: bisher gab es nur automatische Backups direkt vor dem Anwenden
bzw. vor einem Restore, aber keine Möglichkeit, unabhängig davon auf Knopfdruck
eine Sicherung anzulegen (z. B. vor eigenen Änderungen direkt in WinBox).
Neuer Button im "Backup wiederherstellen"-Bildschirm ruft denselben
RouterBackupService wie die automatischen Backups auf (inkl. Modell-/
Seriennummer-Einbettung) und lädt die Backup-Liste danach neu, damit die neue
Datei sofort erscheint. DemoRouterOsClient simuliert "/system/backup/save"
jetzt auch tatsächlich als neuen Dateieintrag, damit sich das im Demo-Zugang
end-to-end durchklicken lässt.
Neuer Unit-Test für den Demo-Client, WPF-Smoke-Test für den kompletten
Erstellen-und-sofort-in-der-Liste-sehen-Ablauf.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nutzer-Feedback: reiner Modell-Abgleich ließe ein baugleiches, aber physisch
anderes Gerät (gleiches Modell, andere Seriennummer) fälschlich als passend
durch. RouterBackupService bettet die Seriennummer jetzt zusätzlich zum Modell
in den Dateinamen ein (getrennt per "_", ein Zeichen, das die Sanitisierung nie
erzeugt und die Trennung beim Zurücklesen eindeutig hält).
BackupRestoreService.CheckCompatibility bündelt die Prüf-Priorität (Seriennummer
vor Modell vor "unbekannt") an einer Stelle, die sowohl RestoreAsync zum
Blockieren als auch die neue BackupSelectionItemViewModel zur Anzeige nutzen —
UI und tatsächliche Durchsetzung können so nicht auseinanderlaufen. Modell bleibt
Fallback für ältere Backups ohne eingebettete Seriennummer oder Geräte, die keine
liefern (z. B. virtuelle Testgeräte).
10 neue Unit-Tests, WPF-Smoke-Test für alle vier Kompatibilitäts-Zustände
(exakter Treffer, gleiches Modell/andere Seriennummer, anderes Modell, unbekannt)
sowie Regressionscheck der gesamten Core-Suite (125 Tests).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neue Option "Backup wiederherstellen" im Moduswahl-Schritt (WizardMode-Enum ersetzt
das bisherige reine IsExpertMode-bool-Radiobutton-Paar; EnumToBooleanConverter für
mehr als zwei sich ausschließende Optionen). Überspringt WAN/LAN/VLAN/WLAN/Firewall
per ShouldSkip und zeigt in der Zusammenfassung die auf dem Gerät vorhandenen
.backup-Dateien zur Auswahl statt der geplanten Änderungen.
RouterOS prüft beim Zurückspielen selbst nicht, ob ein Backup zum verbundenen Gerät
passt. Da .backup-Dateiinhalte ohne SFTP (v1.3, noch offen) nicht lesbar sind, macht
RouterBackupService das Gerätemodell stattdessen Teil des Dateinamens (eigene
Backups); BackupRestoreService parst es beim Auflisten zurück und blockiert bei
erkanntem Mismatch ohne Override-Möglichkeit. Unbekannte Backups (z. B. aus WinBox)
brauchen eine explizite Bestätigung per Checkbox. Vor dem Zurückspielen wird wie
beim normalen Anwenden zusätzlich eine Sicherung des aktuellen Zustands erstellt.
11 neue Unit-Tests, WPF-Smoke-Test für alle drei Modell-Zustände sowie
Regressionscheck des normalen (Nicht-Restore-)Modus.
Folge-Issue #32 angelegt: exaktes Verhalten von "/system/backup/load" (Dateiname-
Format, Reboot/Verbindungsabbruch, Passwort-Parameter) gegen echtes Gerät verifizieren.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nutzer-Feedback: Nach "Feste IP zuweisen" → "Rückgängig machen" wirkte die Zeile wie
kaputt (Button einfach ausgegraut, Status nur "Kein DHCP-Lease"). Technischer Hintergrund
bestätigt: RouterOS kennt kein "wieder dynamisch machen", UndoStaticAsync entfernt den
Lease-Eintrag komplett — das Gerät merkt das aber nicht sofort, sondern hält seine IP
client-seitig, bis es sich neu meldet (Renewal-Timer oder Trennen/Neuverbinden). Die Zeile
zeigt das jetzt explizit ("Feste IP entfernt" + erklärender Hinweistext/Tooltip statt
kommentarlosem Ausgrauen). Zusätzlich: immer sichtbarer "Aktualisieren"-Button, um nach
einem Trennen/Neuverbinden ohne Schritt-Wechsel neu zu scannen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Wizard-Schritt "Geräte im Netzwerk" nach der IST-Zustand-Analyse: LanScanService
(Core) führt DHCP-Leases, ARP-Tabelle und Bridge-Host-Tabelle per MAC-Adresse zusammen
und gruppiert nach physischem Anschluss (aus der Bridge-Host-Tabelle, nicht aus
ARP/Lease, da deren "interface"-Feld bei gebrückten Setups nur die Bridge zeigt).
Erlaubt, eine DHCP-Lease per Klick fest zuzuweisen (RouterOS "Make Static") oder das
wieder rückgängig zu machen. Rein informativ bis auf diese eine Aktion.
Folge-Issue #30 angelegt: ob RouterOS für "make-static" wirklich ".id" statt "numbers"
erwartet, ist bislang unverifiziert (nur gegen den Demo-Client getestet).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nach erfolgreicher Verbindung wird Host/Benutzername/Modellname lokal
gemerkt (SavedRoutersStore, JSON unter %AppData%), mit editierbarem
Namen und Standort-Feld. Das Passwort liegt separat im Windows-
Anmeldeinformationsspeicher (WindowsCredentialStore, P/Invoke auf
advapi32.dll) statt im Klartext -- bewusst in App statt Core, da Core
plattformneutral bleibt.
Da viele MikroTik-Geraete werksseitig dieselbe Standardadresse nutzen
(192.168.88.1/admin), waere Host+Benutzername allein nicht eindeutig:
RouterDevice liest jetzt zusaetzlich die Seriennummer aus
(/system/routerboard), SavedRoutersStore legt bei Host+Benutzername-
Treffer mit unterschiedlicher Seriennummer einen eigenen Eintrag an
statt den bestehenden zu ueberschreiben. Ansatz 1:1 von der parallel
entwickelten Mac-Version uebernommen (dort M26/M27), vom Nutzer live
bestaetigt.
README zusaetzlich um den auf dem mac-version-merge-Branch liegen
gebliebenen Ablaufplan/M-*-Milestone-Katalog ergaenzt, der bisher nicht
in main uebernommen war, und auf den aktuellen Stand gebracht (v1.2,
CI/CD, M-Bekannte-Router als abgeschlossen markiert).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Selbstgehosteter Windows-Runner registriert und verbunden, Workflow
erfolgreich scharf getestet (Run #26). Neuer Abschnitt erklaert den
User-Modus-Runner ohne Docker und warum kein setup-dotnet-Schritt noetig
ist (fehlende Schreibrechte nach "C:\Program Files\dotnet").
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Der selbstgehostete Runner laeuft bewusst im User-Modus (kein Admin).
actions/setup-dotnet@v4 versucht aber, eine eigene SDK-Kopie nach
"C:\Program Files\dotnet" zu installieren, wofuer die Schreibrechte
fehlen -- erster Testlauf (#25) ist deshalb dort fehlgeschlagen. Das
.NET 8 SDK ist auf dem Runner-Rechner ohnehin schon installiert, der
Schritt war nur fuer gehostete/leere Runner noetig.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Runner "danielpc-windows" (host-Modus, kein Docker) auf diesem Windows-
Rechner registriert und mit dem Repo verbunden (Issue #10). Label von
ubuntu-latest auf windows-latest umgestellt, damit der Workflow ihn
tatsaechlich trifft (Issue #11) -- passt ausserdem besser zum Windows-
exe-Build-Ziel als ein Linux-Runner.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Echte Formatpruefung (IP/CIDR/Praefix/Adressbereiche/Portbereiche) statt
reiner Nicht-leer-Pruefung in WAN, LAN, VLAN und Firewall, mit sofortiger
roter Fehlermeldung je Feld/Zeile statt stillem Blockieren von "Weiter".
Neuer NetworkValidation-Baustein in Core (24 Tests). Behebt nebenbei einen
echten Absturzpfad: LanConfigurator/VlanConfigurator riefen IPAddress.Parse
bisher ungeprueft bei jedem Tastendruck auf.
Zusaetzlich Issue #19 behoben: Firewall-/NAT-Regeln ohne eindeutiges
Identitaetsfeld duplizierten sich bei wiederholtem Wizard-Lauf gegen
dasselbe Geraet. Neuer DuplicateRuleGuard-Baustein holt den Ist-Zustand
einmal pro Wizard-Lauf (nicht pro Regel, um Selbst-Kollisionen innerhalb
desselben Laufs zu vermeiden) und ueberspringt bereits vorhandene Regeln.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Im Experten-Modus lässt sich jedes VLAN wahlweise fest einem oder
mehreren Anschlüssen zuordnen, statt nur über einen VLAN-fähigen
Switch/Access Point (getaggt) erreichbar zu sein. Aktiviert dafür
Bridge-VLAN-Filterung erst als letzten Schritt (nachdem alle PVID-
und Bridge-VLAN-Tabellen-Einträge stehen), um keine Verbindung
während der Einrichtung zu kappen, und schützt die zugeordneten
Anschlüsse per frame-types/ingress-filtering vor VLAN-Hopping.
Ein Anschluss kann nur einem Netzwerk zugeordnet sein; Konflikte
blockieren "Weiter" mit einer Fehlermeldung statt die Auswahl
stillschweigend zu ändern.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kernfunktion ist umgesetzt und vom Nutzer beim Live-Test bestaetigt.
Roadmap-Tabelle um Status-Spalte erweitert; offen bleiben optisches
Feintuning und die Route-zu-Interface-Verifizierung gegen ein echtes
Geraet. Zugehoerige Gitea-Issues #12-#16 geschlossen, neues Issue #18 fuer
das offene Feintuning angelegt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kategorien (Internet / Netzwerk-Schnittstellen / IP-Adressen / DHCP-Server
/ Firewall-Regeln) sind jetzt Spalten von links nach rechts statt Baendern
untereinander - auf Nutzer-Feedback nach dem Live-Test. Jede Spalte
stapelt ihre Knoten vertikal, sortiert nach Baum-Tiefe/Eltern-Knoten,
damit zusammengehoerige Knoten (z.B. eine Bridge und ihre Ports) nahe
beieinander stehen.
Per headless-Harness verifiziert: fuenf saubere Spalten (X=0/280/560/
840/1120), keine Ueberlappungen. Regulaerer Build/Test/Smoke-Test gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ursache gefunden per headless-Reproduktion (WPF-Layout ausserhalb des
sichtbaren Fensters angestossen, da keine Klick-Automatisierung fuer
native Fenster verfuegbar ist): TopologyBandHeaderViewModel.Location war
eine rein schreibgeschuetzte Property. Nodifys ItemContainer.Location ist
aber standardmaessig TwoWay gebunden (damit Drag&Drop den Knoten
zurueckschreiben kann) - beim ersten Layout-Durchlauf warf das eine
InvalidOperationException auf dem UI-Thread, die mangels
DispatcherUnhandledException-Handler den Prozess sofort und ohne jede
Meldung beendete.
Fix: Location bekommt einen (ungenutzten) Setter. Zusaetzlich als
Sicherheitsnetz einen globalen DispatcherUnhandledException-Handler
ergaenzt, der kuenftige unerwartete Fehler als Meldung anzeigt statt den
Prozess stumm zu beenden.
Verifiziert per Konsolen-Harness (WPF-Layout ohne sichtbares Fenster):
View-Konstruktion, Layout-Durchlauf und simulierter Knoten-Klick laufen
jetzt fehlerfrei durch. Ausserdem regulaerer Build/Test/Smoke-Test grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Aktualisiert die Beschreibung des dritten Wizard-Schritts, das Architektur-
Flowdiagramm (neue RouterOS-Endpunkte, Band-Layout, Teilbaum-Hervorhebung
statt reiner Pfad-Hervorhebung) auf den aktuellen Code-Stand.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Auf Nutzer-Feedback aus dem Live-Test:
- Klick auf einen zentralen Knoten (z.B. WAN oder eine Bridge) hob bisher
nur den Weg nach oben zum Internet-Knoten hervor. Jetzt wird der
komplette verbundene Teilbaum hervorgehoben (Vorfahren UND Nachfahren) -
ein Klick auf eine Bridge zeigt jetzt wirklich alle angeschlossenen
Geraete/Netzwerke.
- Layout war zu eng, Kasten-Inhalte abgeschnitten: Knoten verbreitert
(180->220px), mehr Zeilen-/Spaltenabstand, Label-Text umbricht jetzt
statt mit "..." abgeschnitten zu werden.
- Grafik nach Kategorien gruppiert (Internet / Netzwerk-Schnittstellen /
IP-Adressen / DHCP-Server / Firewall-Regeln) mit Beschriftung je Band,
statt eines reinen Tiefen-Layouts. Kategorie-Label sind eigene, nicht
anklickbare Eintraege im selben Nodify-Item-Raum wie die Knoten, damit
sie beim Pan/Zoom exakt mitwandern statt als Overlay zu driften.
- Neu: Firewall-/NAT-Regeln, die an eine konkrete IP gebunden sind
(Portfreigaben ueber /ip/firewall/nat, Filter-Regeln mit dst-/
src-address), werden als eigene Knoten unter der IP-Adresse eingehaengt,
deren Subnetz die gebundene Adresse enthaelt. Allgemeine, nicht
adressgebundene Basisregeln (z.B. "drop new from WAN") bleiben bewusst
aussen vor, sonst waere die Grafik von Standard-Boilerplate ueberflutet.
2 neue Core-Tests fuer die Firewall-Zuordnung (56 insgesamt, alle gruen).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Schritt-Liste um "Vorhandene Netzwerke" erweitert (jetzt 11 Schritte),
neuen Abschnitt zur Funktion ergänzt, Architektur-Diagramm um den neuen
Schritt und ein Nodify/NetworkAnalysisService-Flowdiagramm erweitert,
Nodify in "Verwendete Bibliotheken" aufgenommen und die Roadmap-Tabelle
um den neuen Milestone ergänzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Wizard-Schritt "Vorhandene Netzwerke" direkt nach der Geräte-
Erkennung. Liest per NetworkAnalysisService (Core) aus, welche Bridges,
VLANs, IP-Adressen, DHCP-Server, Routen und WLANs auf dem Gerät bereits
existieren, und stellt sie als anklickbare Grafik dar (Nodify). Klick auf
einen Knoten hebt die Eltern-Kette bis zum synthetischen "Internet"-Knoten
hervor (Hops/Pfad). Rein informativ, verändert nichts am Gerät und fließt
nicht in die vom Assistenten geplante Soll-Konfiguration ein.
Core liefert reine Fakten (Records in Analysis/), die App-Schicht baut
daraus Knoten/Kanten mit deterministischem Spalten-Layout. Jeder RouterOS-
Endpunkt ist einzeln fehlertolerant (fehlendes Paket, z.B. kein WLAN,
bricht die Analyse nicht ab). Route-zu-Interface-Zuordnung ist best-effort
(gateway-status-Format ist RouterOS-versionsabhängig) — als bekannte
Einschränkung dokumentiert.
Ursprünglich geplant war, den Schritt bei werksneuen Geräten per
ShouldSkip automatisch zu überspringen. Das erwies sich als architektonisch
nicht möglich: die Wizard-Navigation prüft ShouldSkip, bevor
OnActivatedAsync für den Zielschritt läuft, das Analyse-Ergebnis steht zu
dem Zeitpunkt also noch nicht fest. Stattdessen zeigt der Schritt bei
leerem Ergebnis einen kurzen Hinweistext statt einer leeren Grafik.
Demo-Client um Beispieldaten erweitert, damit sich der Schritt über den
Testzugang (127.127.127.127) durchklicken lässt. 9 neue Core-Tests für
NetworkAnalysisService (54 insgesamt, alle grün).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Schritt-Liste um "Modus wählen" erweitert (jetzt 10 Schritte), neuen
Abschnitt mit den Experten-Feldern je Bereich ergänzt, sowie Architektur-
und Datenstruktur-Diagramme (WizardSession.IsExpertMode, erweiterte
Settings-Records, WirelessSecurityMode) auf den aktuellen Code-Stand
gebracht.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neuer Wizard-Schritt "Modus wählen" nach der Geräte-Erkennung, mit dem
zwischen dem geführten Assistenten und einem Experten-Modus gewählt werden
kann. Im Experten-Modus zeigen die bestehenden Schritte zusätzliche,
technischere Felder (DHCP-Feinsteuerung, MTU, WPA3, Portbereiche,
IP-Sperrlisten, VLAN-Isolation u.a.), die im Laien-Modus verborgen bleiben.
Alle neuen Settings-Felder sind optional mit Defaults, die das bisherige
Verhalten unverändert lassen (45 Tests grün, 7 davon neu für die
Experten-Felder).
Zusätzlich zwei beim Live-Testen gefundene Bugs behoben: der letzte Schritt
zeigte einen dauerhaft ausgegrauten "Weiter"-Button statt eines
"Beenden"-Buttons, und die Texte im neuen Moduswahl-Schritt wurden
abgeschnitten (horizontales StackPanel gab TextBlocks unbegrenzte Breite
zum Messen, dadurch griff TextWrapping nicht — behoben durch Grid mit
fester Spaltenbreite).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Statisches Badge (kein Live-Wert, VirusTotal bietet dafür keine
Badge-API) neben dem MIT-Badge, verlinkt auf die Releases-Seite, wo bei
jedem Release der aktuelle Scan-Link in den Notizen steht.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SummaryPdfExporter.Export ist [SupportedOSPlatform("windows")], aber das
Test-Projekt zielte auf net8.0 (ohne OS-Angabe). Der Plattform-Analyzer
kannte den Windows-Kontext dadurch nicht und meldete an jeder Aufrufstelle
in SummaryPdfExporterTests.cs eine CA1416-Warnung - so in den Annotationen
des ersten GitHub-Actions-Laufs aufgefallen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
append_body kollidierte mit generate_release_notes bei einem bereits
bestehenden Release unter demselben Tag: die automatisch generierten
Notizen überschrieben unseren VirusTotal-Link vollständig. Ein evtl.
vorhandenes Release wird jetzt vor dem Erstellen entfernt, damit der
dokumentierte "body wird den Auto-Notizen vorangestellt"-Fall greift.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
update_release_body der crazy-max/ghaction-virustotal-Action griff nicht,
da sie nur reagiert, wenn der Workflow selbst durch das Event
"release: published" ausgelöst wurde - hier läuft er aber bei einem
Tag-Push, und das Release wird im selben Lauf erst danach erzeugt.
Scannt jetzt zuerst, extrahiert den Analyse-Link aus der Action-Ausgabe
und übergibt ihn als body an softprops/action-gh-release.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Der Demo-Verbindungszugang (127.127.127.127), den ein Test nutzt, ist per
#if DEBUG nur in Debug-Builds vorhanden. Mit --configuration Release lief
der Test stattdessen in einen echten (nie erfolgreichen) Verbindungsversuch
und Timeout - so im ersten GitHub-Actions-Release-Lauf aufgefallen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Hält den aktuellen Stand nach Abschluss aller 8 geplanten Phasen fest:
Entscheidungen mit Begründung, Code-Struktur, bekannte Stolperfallen
und offene Punkte — allen voran ein noch unbestätigter kompletter
Durchlauf inkl. "Jetzt einrichten" gegen ein echtes Gerät.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Eigenes, neutrales Netzwerk-Symbol (Mittelknoten mit vier Satelliten,
MikroTik-Grün) als app.ico — programmatisch erzeugt, bewusst kein
MikroTik-Logo, um keine Markenrechte zu verletzen. Als Resource statt
Content eingebunden, damit es beim Single-File-Publish mit in der exe
landet statt als separate Datei danebenzuliegen. Eingebunden als:
- ApplicationIcon (Datei-Icon in Explorer/Taskleiste/Alt-Tab)
- Window.Icon
- WPF-UI-TitleBar-Icon (Titelleiste)
- Sidebar-Branding (ersetzt den bisherigen grünen Punkt)
README.md für Gitea: was der Assistent einrichtet, Screenshot,
Hinweise für Nutzer (portabel, keine Installation) und Entwickler
(Bauen/Testen, Release-Build, interner Testzugang, Projektstruktur,
verwendete Bibliotheken).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SatelliteResourceLanguages=de;en beschränkt die mitgelieferten
Sprachpakete der .NET-Laufzeit und Abhängigkeiten (übersetzte
Systemmeldungen, nicht unsere eigenen UI-Texte — die App hat ohnehin
nur deutsche Texte) auf Deutsch/Englisch. Vorher wurden ~20 weitere
Sprachordner (ja, ru, zh-Hans, ...) ungenutzt mitgeschleppt.
Ungepackt: 170 MB -> 155 MB. Komprimierte Single-File-exe: 71,7 MB ->
67 MB. Reines Build-Einstellungs-Flag ohne Code- oder Trimming-Risiko
(im Gegensatz zu PublishTrimmed, das bei WPF-Apps wegen der starken
Reflection-Nutzung unzuverlässig sein kann und deshalb bewusst nicht
aktiviert wurde).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Kein Runner auf der Gitea-Instanz konfiguriert — build-release.ps1
kapselt den dotnet-publish-Befehl aus dem letzten Commit als
Ein-Zeiler-Aufruf (.\build-release.ps1), meldet Erfolg/Misserfolg und
zeigt Pfad + Größe der fertigen exe. Der Gitea-Actions-Workflow bleibt
bestehen, falls später doch ein Runner eingerichtet wird.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Baut bei jedem Push auf main (und manuell auslösbar) automatisch:
Tests ausführen, dann die self-contained Single-File-exe für win-x64
veröffentlichen und als Build-Artefakt bereitstellen.
runs-on: ubuntu-latest, da der vorhandene Runner Linux-basiert ist —
das self-contained Publishing für win-x64 funktioniert dank der
plattformunabhängig über NuGet beziehbaren Windows-Desktop-
Referenz-/Runtime-Pakete auch von einem Linux-Build-Host aus
(offizieller .NET-Anwendungsfall für genau solche CI-Pipelines),
auch wenn die exe dort natürlich nicht ausgeführt werden kann.
Runner-Label ist als Platzhalter zu verstehen — falls der eigene
Runner unter einem anderen Namen registriert ist, muss "runs-on"
entsprechend angepasst werden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
MikrotikInstaller.App.csproj bekommt Produkt-Metadaten (Name, Version,
Beschreibung) und Publish-Vorgaben, die greifen, sobald ein
RuntimeIdentifier angegeben wird: self-contained (keine separate
.NET-Installation beim Nutzer nötig), eine einzelne komprimierte .exe
statt eines Ordners voller DLLs, Debug-Symbole eingebettet statt als
separate .pdb-Datei daneben (MikrotikInstaller.Core.csproj ebenso).
Ausgabename umbenannt auf "MikroTik-Installer.exe".
Build/Test:
dotnet publish src/MikrotikInstaller.App/MikrotikInstaller.App.csproj -c Release -r win-x64
Ergebnis: eine einzelne ~72-MB-exe unter
src/MikrotikInstaller.App/bin/Release/net8.0-windows/win-x64/publish/
— läuft eigenständig ohne Installation, verifiziert per UI-Automation
(App startet, komplette Sidebar/Navigation funktioniert). Der
Debug-Simulator-Zugang (127.127.127.127/admin/admin) ist im
Release-Build wie vorgesehen nicht erreichbar (#if DEBUG greift).
Ein fertiger Installer (Inno Setup) bleibt bewusst eine spätere
Ausbaustufe — die portable Einzeldatei ist der MVP-Verteilweg.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ShouldSkip übersprang den WLAN-Schritt bisher nur bei Geräten ganz
ohne WLAN-Hardware. Ein Gerät mit vorhandener, aber deaktivierter
WLAN-Schnittstelle (z. B. weil es hier rein als Switch dient) hat
zu Recht "WLAN-fähig" gemeldet — der Schritt blieb aber Pflicht und
verlangte SSID/Passwort, obwohl der Nutzer gar kein WLAN einrichten
wollte.
Neue Checkbox "Kein WLAN einrichten" macht den Schritt explizit
überspringbar: aktiviert, wird "Weiter" ohne SSID/Passwort freigegeben,
die übrigen Felder werden deaktiviert, und es werden keine
WLAN-Änderungen in die Zusammenfassung/Anwendung übernommen.
Neuer InverseBooleanConverter für die IsEnabled-Bindung (die bisherige
Idee, den Visibility-Konverter dafür zu missbrauchen, wäre ein
Typfehler gewesen — Visibility lässt sich nicht in bool/double
konvertieren).
Per UI-Automation verifiziert: Checkbox aktiviert, Felder werden
deaktiviert, "Weiter" wird ohne Eingaben aktiv.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
RouterOsUpdateService nutzt RouterOS' eigene Update-Funktion
(/system/package/update/check-for-updates + /print), inklusive Polling
bis der Status nicht mehr "Checking..." ist. Schlägt die Prüfung fehl
(z. B. weil das Gerät noch keinen Internetzugang hat), wird das als
"nicht geprüft werden konnte" behandelt statt als Fehler.
Zeitlicher Ablauf wie gewünscht: Die Prüfung wird zuerst im Hintergrund
in der Geräte-Erkennung versucht (Schritt 2) — funktioniert nur, wenn
das Gerät zu diesem Zeitpunkt schon Internetzugang hat. Nach
erfolgreichem Anwenden (Schritt 8, wenn WAN eingerichtet wurde) wird
sie automatisch wiederholt. Beide Läufe blockieren die Navigation
nicht (Fire-and-forget im Hintergrund).
Neuer Schritt 9 "RouterOS-Update" zeigt das Ergebnis: nicht geprüft
werden konnte (mit "Erneut prüfen"), bereits aktuell, oder eine neuere
Version verfügbar — dann mit deutlicher Warnung vor dem automatischen
Neustart und einer Pflicht-Checkbox, bevor "Jetzt aktualisieren"
aktiv wird. Komplett optional, keine Pflicht zum Abschluss des
Assistenten.
Zusammenfassungs-Schritt lässt "Weiter" jetzt erst nach erfolgreichem
Anwenden zu (vorher automatisch gesperrt, weil er der letzte Schritt
war — das ist er jetzt nicht mehr).
Simulator-Zugang liefert jetzt eine simulierte verfügbare Version
(7.15.2 → 7.16.1), damit sich auch dieser Schritt gefahrlos
durchspielen lässt.
Per UI-Automation den kompletten Assistenten durchgeklickt: "nicht
geprüft werden konnte"-Zustand (echtes Simulator-Verhalten ohne
Update-Endpunkte) und "Update verfügbar"-Zustand beide verifiziert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ToolTip-Inhalte hängen nicht im normalen visuellen Baum der Seite,
sondern werden erst beim Anzeigen separat verbunden — eine direkte
ElementName-Bindung im ToolTip-Inhalt (wie zuvor verwendet) läuft
daher ins Leere und bleibt leer, ohne einen Fehler zu werfen.
Fix nach dem dafür vorgesehenen WPF-Muster: Der Text wird als Tag auf
das sichtbare SymbolIcon gebunden (das steht im normalen Baum, dort
funktioniert ElementName), der ToolTip-Inhalt liest ihn anschließend
über PlacementTarget.Tag zurück.
Per UI-Automation mit echter, schrittweiser Mausbewegung verifiziert:
Tooltip zeigt jetzt den vollständigen, umbrochenen Erklärtext an.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neues wiederverwendbares Steuerelement InfoHint: ein kleines
"?"-Symbol, das per Hover eine kurze, einfache Erklärung zeigt —
ohne die Formulare optisch zu überladen (nur bei tatsächlich
erklärungsbedürftigen Begriffen, nicht bei Selbstverständlichem wie
"Benutzername" oder "Passwort").
Fachbegriffe jetzt erklärt in allen Schritten:
- Verbindung: IP-Adresse/Hostname, verschlüsselte Verbindung
- Geräte-Erkennung: RouterOS, Architektur, Netzwerkschnittstellen
- Internet-Zugang: Schnittstelle, DHCP, Präfix, Gateway
- Heimnetzwerk: Bridge/interner Name, Router-Adresse, Präfix,
Adressbereich, DNS-Server
- VLANs: VLAN-ID, Router-Adresse
- WLAN: Schnittstelle, SSID
- Firewall: Portfreigabe, Protokoll, Port von außen/am Gerät
Per UI-Automation den kompletten Assistenten erneut durchgeklickt:
alle Schritte rendern weiterhin korrekt, Info-Symbole erscheinen an
den richtigen Stellen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SummaryPdfExporter (PdfSharp, MIT-lizenziert) druckt die Einrichtung
als einseitiges PDF: Internet-Zugang, Heimnetzwerk, VLANs und Firewall
mit den konkreten technischen Daten (IP-Bereiche, Anschlüsse, DNS) in
der linken Spalte, WLAN-Name und -Passwort groß hervorgehoben in der
rechten Spalte — zum Aufbewahren/Ausdrucken, nicht zum vereinfachten
Vorlesen wie die Bildschirm-Zusammenfassung.
Nice-to-have umgesetzt: WifiQrCodeGenerator (QRCoder, MIT-lizenziert)
erzeugt einen QR-Code im Standard-WIFI:-Format, den Handys direkt als
"WLAN beitreten" erkennen. QR-Erzeugung schlägt niemals das gesamte
PDF fehl — bei Problemen (z. B. Sonderzeichen) wird sie einfach
ausgelassen.
Zwei PdfSharp-6-Besonderheiten gelöst:
- Schriftauflösung: PDFsharp 6 löst Schriften nicht mehr automatisch
über GDI auf. WindowsSegoeUiFontResolver liest Segoe UI direkt aus
dem Windows-Schriftartenordner (keine Schriftdatei wird mitgeliefert
— Microsoft-Lizenz).
- Von QRCoder erzeugte PNGs wurden von PDFsharps PNG-Decoder abgelehnt;
über GDI+ (ohnehin transitive Abhängigkeit von QRCoder) nach BMP
normalisiert, das zuverlässig gelesen wird.
Neuer "Als PDF speichern"-Button im Zusammenfassungs-Schritt (vor und
nach dem Anwenden verfügbar) öffnet einen Speichern-Dialog und zeigt
Erfolg/Fehler direkt im Assistenten an.
Per UI-Automation und Sichtprüfung des erzeugten PDFs verifiziert:
korrektes einseitiges Layout, lesbarer QR-Code, alle Daten vorhanden.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die Zusammenfassung zeigte bisher jede einzelne RouterOS-Aktion als
flache Liste (z. B. "IP-Adressbereich 192.168.88.10-192.168.88.254
für Geräte in deinem Netzwerk reservieren", "DHCP-Server auf
„bridge-lan" aktivieren, ...) — für Laien kaum verständlich und rein
technisch sortiert.
Jeder Configurator (Wan/Lan/Vlan/Wireless/Firewall) bekommt jetzt
zusätzlich BuildFriendlySummary(...): 1-2 kurze, verständliche Sätze
ohne RouterOS-Fachbegriffe, getrennt von den technischen
ConfigurationAction-Beschreibungen (die weiterhin als Fortschrittstext
beim tatsächlichen Anwenden dienen).
WizardSession hält jetzt zusätzlich die rohen Einstellungsobjekte
jedes Schritts (WanSettings, LanSettings, VlanDefinitions,
WirelessSettings, FirewallSettings), damit der Zusammenfassungs-Schritt
daraus bauen kann, was tatsächlich passiert ist — nicht wie.
Die Zusammenfassung zeigt jetzt pro Themenbereich eine eigene Karte
(Internet-Zugang, Heimnetzwerk, optional VLANs, optional WLAN,
Firewall) mit Symbol, Titel und kurzen Stichpunkten; leere Bereiche
(z. B. keine VLANs eingerichtet) werden gar nicht erst angezeigt.
Unit-Tests prüfen u. a., dass die Klartext-Sätze keine RouterOS-Begriffe
wie "NAT" enthalten und dass das WLAN-Passwort nicht in der Anzeige
landet.
Per UI-Automation verifiziert: vier klar getrennte, grün akzentuierte
Karten mit verständlichen Stichpunkten statt einer technischen Liste.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
adminandClaude Opus 5.5