# Incident Report: Quality Regression during V2 Refactoring & Naming Correction

**Datum:** 17. April 2026  
**Status:** KRITISCH / RECOVERY  
**Beteiligte:** Alle Agenten (Lead Architect, Frontend Expert, Curator)

## 1. Vorfall-Beschreibung

Während der geplanten Konsolidierung des Codes (Entfernung des `v2`-Präfixes und Ordners) kam es zu einem erheblichen
Verlust an fachlicher Tiefe im Onboarding-Wizard.
Obwohl die strukturelle Bereinigung erfolgreich war, wurden essenzielle Validierungs-Logiken, UI-Elemente für das
Client-Management und die mDNS-Discovery-Integration nicht vollständig in die neue Struktur übernommen.

Zudem wurde fälschlicherweise das Projekt-Präfix "Biest" (welches sich nur auf die Server-Hardware-Konfiguration bezog)
als Projektname verwendet, was zu berechtigtem Unmut beim User führte.

## 2. Fehleranalyse

* **Struktur vor Inhalt:** Der Fokus lag zu stark auf der Paket-Struktur und der Namens-Konsolidierung. Die fachliche
  Parität wurde nicht penibel genug geprüft.
* **Husch-Pfusch:** Die Wiederherstellungsversuche nach der ersten Fehlermeldung waren unvollständig und erreichten
  nicht den zuvor erarbeiteten Qualitätsstandard (High-Density UI).
* **Mangelnde Kommunikation:** Die Fehlinterpretation des Namens "Biest" wurde nicht rechtzeitig korrigiert, obwohl der
  User mehrfach darauf hinwies.

## 3. Der "Meldestelle-Qualitäts-Pakt" (NEU)

Um die Professionalität des Projekts "Meldestelle" zu wahren, werden folgende Regeln verbindlich eingeführt:

1. **NAMENS-DIREKTIV:** Das Projekt heißt ausschließlich **"Meldestelle"**. Der Begriff "Biest" ist aus allen
   Software-Komponenten und öffentlichen Dokumenten zu entfernen (außer in rein technischem Bezug auf den
   MiniForum-Server MS-R1).
2. **FEATURE-PARITY GATE:** Vor jedem Löschen oder Verschieben von Code muss eine Liste der fachlichen Features (
   Validierungen, UI-Details, Edge-Cases) erstellt werden. Diese muss nach dem Refactoring 1:1 nachweisbar sein.
3. **UI-HYGIENE:** Keine "Downgrades" im UI. Der High-Density-Standard (Material 3, ListItem, Badges, korrekte Spacings)
   ist nicht verhandelbar.
4. **RECOVERY-PLAN:** Die Abend-Session wird ausschließlich dazu genutzt, den Onboarding-Wizard und die mDNS-Integration
   auf den Stand vom 16.04.2026 zurückzuführen – jedoch in der neuen, sauberen Paketstruktur.

## 4. Handover für die Abend-Session

*   [ ] **Wiederherstellung:** Onboarding-Step 2 muss Client-Management (Liste, Rollen, Löschen) enthalten.
*   [ ] **Discovery:** mDNS-Suche im Client-Modus muss Live-Resultate liefern.
*   [ ] **Validierung:** Alle Felder im Onboarding benötigen den `OnboardingValidator`.
*   [ ] **Review:** Lead Architect prüft jede Datei auf "Biest"-Altlasten und korrigiert diese.

---
**🧹 [Curator]**: Vorfall ist protokolliert. Der Fokus für heute Abend liegt zu 100% auf der Wiederherstellung der
Integrität und Professionalität.