Define reversible beta rollout model

docs/roadmap.md

@@ -21,6 +21,73 @@ Incident-Protokollen.
 - Datenminimierung: zentrale Speicherung nur von verdichteten Ereignissen und
   Incident-Kontext, nicht von vollstaendigen Dateilisten.
 
+## Beta- und Rollback-Modell
+
+Jede neue Erkennung, Datenart und UI-Aenderung durchlaeuft denselben
+reversiblen Lieferweg. Eine Funktion wird nie erstmals auf dem gesamten Bestand
+aktiv geschaltet.
+
+### Stufe 0: Spezifikation und lokale Tests
+
+- Zweck, Datenfelder, Bewertung und erwartete Last werden vor dem Coding
+  dokumentiert.
+- Beispielereignisse decken Normalfall, Hinweis, Warnung, kritisch und Fehler
+  ab.
+- Der Client muss bei fehlender neuer Konfiguration das bisherige Verhalten
+  unveraendert beibehalten.
+
+### Stufe 1: Interne Beta
+
+- Das Paket wird als separater Beta-Release veroeffentlicht; `stable` bleibt
+  unveraendert.
+- Eine neue Funktion ist per Feature-Schalter standardmaessig deaktiviert.
+- Die Beta wird nur auf Testgeraeten bzw. einer internen Organisation verteilt.
+- Zentrale Auswertung prueft Laufzeit, Upload-Volumen, Fehler und Datenformate.
+
+### Stufe 2: Passiver Kunden-Pilot
+
+- Ausgewaehlte Geraete erhalten die Beta mit aktivierter Funktion im
+  Beobachtungsmodus.
+- Signale erscheinen in Protokoll und Dashboard, loesen aber keine NinjaOne-
+  Alarmbedingung aus.
+- Der Pilot laeuft mindestens eine realistische Arbeitswoche, bei Fileservern
+  inklusive der normalen Spitzenzeiten.
+
+### Stufe 3: Kontrollierte Alarmierung
+
+- Erst nach Auswertung werden Warnungen fuer eine kleine, benannte Pilotgruppe
+  an NinjaOne uebergeben.
+- Hinweise bleiben weiterhin rein informativ.
+- Schwellenwerte, Ausnahmen und Empfaenger werden pro Pilot dokumentiert.
+
+### Stufe 4: Stable-Rollout
+
+- Rollout zuerst je Organisation oder Richtlinie, nicht an alle Kunden zugleich.
+- Der Stable-Kanal wird erst nach erfolgreichem Pilot, Review der Datenqualitaet
+  und Freigabe der Alarmbedingungen aktualisiert.
+- Die vorherige Stable-Version bleibt als signiertes Release verfuegbar.
+
+### Rueckfall
+
+- Sofort: Feature-Schalter in der Richtlinie deaktivieren. Der Client bleibt
+  installiert, sammelt fuer diese Funktion aber nichts mehr.
+- Kurzfristig: Pilotgeraete ueber NinjaOne auf die vorherige Stable-Version
+  zuruecksetzen.
+- Zentral: Die Auswertung kann das neue Feld ignorieren; neue JSON-Felder sind
+  immer optional und muessen abwaertskompatibel bleiben.
+- Datenbankaenderungen werden nur additiv eingefuehrt. Loeschende oder nicht
+  rueckgaengig zu machende Migrationen gehoeren nicht in eine Beta.
+
+### Abbruchkriterien
+
+Ein Pilot wird pausiert und zurueckgesetzt, wenn eines dieser Kriterien eintritt:
+
+- spuerbare Last oder Beeintraechtigung auf einem Kundenserver,
+- unkontrolliertes Upload- oder Queue-Wachstum,
+- fehlerhafte Organisationszuordnung oder unerwartete personenbezogene Daten,
+- mehr als ein unbegruendeter NinjaOne-Alarm im Pilot ohne klare Korrektur,
+- fehlende oder nicht nachvollziehbare Incident-Protokolle.
+
 ## Ausgangslage: geliefert
 
 - Endpoint-Client mit signiertem Upload und lokaler NinjaOne-Feldaktualisierung.
@@ -31,6 +98,18 @@ Incident-Protokollen.
   Einzelne Tippfehler erzeugen keinen Alarm; Anmelde-Bursts und Password
   Spraying werden als Warnung oder kritisch bewertet.
 
+## Voraussetzung: 1.4.1 Beta-Auslieferung
+
+- Eigener Beta-Manifest-Pfad neben `release/stable/version.json`.
+- Eigene NinjaOne-Aufgabe fuer Pilotgeraete, die ausschliesslich den
+  Beta-Manifest-Pfad verwendet.
+- Stable-Aufgabe bleibt unveraendert und ist zugleich der schnelle Rollback auf
+  die letzte freigegebene Version.
+- Beta-Releases werden in Gitea als Vorabversion markiert und erhalten dieselbe
+  Paket-Hash-Pruefung wie Stable-Releases.
+- Jeder Pilot dokumentiert Geraete, Organisation, aktivierte Feature-Schalter,
+  Startzeitpunkt und verantwortliche Person.
+
 ## Naechster Schwerpunkt: 1.5 Ransomware-Frueherkennung
 
 ### 1.5.0: Leichtgewichtiger Fileserver-Sensor
@@ -73,6 +152,8 @@ Incident-Protokollen.
 - Nachweis, dass normale Dateiaktivitaet von vielen Benutzern keinen Alert
   erzeugt und ein simuliertes Mehrsignal-Szenario korrekt eskaliert.
 - Offline-Pufferung, Deduplizierung und Retry des Incident-Protokolls getestet.
+- Start als interne Beta gemaess dem Beta- und Rollback-Modell; der Sensor wird
+  erst nach dem passiven Fileserver-Pilot als NinjaOne-Alarm aktiviert.
 
 ### 1.5.1: Tuning und kontrollierter Rollout