Table of contents
Entwickler
Version: 2.0.1 Gültigkeit: aktueller Entwicklungsablauf Letzter Stand: 9. Juli 2026
Die Solution basiert auf C#/.NET 8, WinUI 3, CommunityToolkit.Mvvm, Entity Framework Core und SQLite.
Inhalt
dotnet test .\Bastelhof.HomelabManager.sln -c Release
.\scripts\build.ps1 -Version 2.0.1 -Runtime win-x64
.\scripts\verify-release.ps1 -Version 2.0.1 -Runtime win-x64
.\scripts\acceptance-test.ps1 -Version 2.0.1 -Runtime win-x64
Neue Fachlogik wird über Interfaces abstrahiert und per Dependency Injection registriert. Datenmodelländerungen benötigen Migration und Tests; UI bleibt deutsch und per Automation erreichbar. Connectoren benötigen Transportvertragstests. Monitoringregeln liegen in IMonitoringService; externe Quellen werden erst im ViewModel orchestriert.
Der Release-Build veröffentlicht zuerst die selbstenthaltende App und erzeugt daraus über Inno Setup 6 eine Setup-EXE. build-installer.ps1 findet ISCC.exe über PATH oder die Windows-Registrierung. verify-installer.ps1 kontrolliert Größe, Version, Produktname und Herausgeber.
build-portable.ps1 kopiert denselben App-Payload, ergänzt Marker, Anleitung und leeren Datenordner. verify-portable.ps1 kontrolliert Version, Marker, identische EXE und das Fehlen ausgelieferter Datenbanken.
filter-locales.ps1 entfernt nach dem Publish alle erkannten Kulturordner außer de und en. verify-locales.ps1 prüft App und Portable-Ausgabe und bricht den Release bei weiteren oder fehlenden erlaubten Sprachen ab.
Der Build veröffentlicht zusätzlich das Agent-Projekt selbstenthaltend für Linux x64 nach agent/linux-x64/. Auch dieser Payload wird auf höchstens deutsche und englische Ressourcen begrenzt. Die Release-Prüfung verlangt Agent-Binärdatei und Betriebsanleitung.
Plugin-Manifeste verwenden Schema- und API-Version 1. Neue Pluginverträge benötigen Kompatibilitätsprüfung, Tests und Aktualisierungen in Plugins, API und Sicherheit. Neue Regeltypen gehören in den Service, nicht in die View. Agent-API-Erweiterungen bleiben standardmäßig lesend und benötigen Connector-Vertragstests.
UI-Änderungen sollen die gemeinsamen App-Ressourcen verwenden. Produktive Listen benötigen sichtbare Spaltenüberschriften; Detailbereiche sollen als Bastelhof-Panelkarten mit fachlichen Abschnittslabels aufgebaut werden. Neue Seiten dürfen Werte nicht nur als unbeschriftete Spalten anzeigen, sondern müssen Namen, Status, Ressourcen, Endpunkte und Laufzeiten klar über Tabellenkopf oder Detailabschnitt einordnen.
Hinweise
Code, README, docs/ und dieses separate Wiki müssen synchron bleiben. Alle Wiki-Seiten liegen direkt im Repository-Root. Architekturentscheidungen werden zusätzlich in DECISIONS.md des Hauptrepositories dokumentiert.
Der lokal erzeugte Ordner build/ ist über .gitignore ausgeschlossen. Build-Artefakte werden nicht committed oder in das Hauptrepository gepusht.