Betriebsmodi und Reifegrade

Ausfuehrliches Betriebsmodell fuer Teams, die neue und grosse Architekturen schrittweise sicher bedienen wollen, bevor vollwertige GUIs stehen.

1. Warum Reifegrade?

Neue Architekturen werden beherrschbar, wenn der Betrieb nicht sofort maximal komplex gestartet wird. Stattdessen nutzt ihr feste Modi mit klaren Regeln: Starter, Teambetrieb, Produktionsmodus.

Vertical Climbing fail-closed Story + Role + TX HITL bei Risiko

2. Drei Betriebsmodi im Überblick

Starter (minimal sicher)

Ein Team, wenige aktive Stories, klare private Defaults.
Fokus: Bedienbarkeit lernen, nicht Features ausreizen.
Nur noetige Skriptpfade und Basis-Validierung.

Teambetrieb (koordiniert)

Rollenpakete aktiv (Owner, Delivery, Reviewer, Legal).
Mehrere parallele Projekte und regelmaessige Reviews.
Gates aktiv, dokumentierte Eskalationswege.

Produktionsmodus (voll auditierbar)

Regelmaessige Full-Stack-Audits und Release-Gates.
Striktes Evidence-Management und Incident-Learning.
Klare Freigabelinien fuer Public/Client-facing Aenderungen.

3. Modus-Matrix: Was ist Pflicht?

Bereich	Starter	Teambetrieb	Produktionsmodus
Story/Plan Pflicht	Basis	Verbindlich fuer alle Work Items	Verbindlich + Release-Bezug
Rollenpakete	Minimal (Owner + Delivery)	Vollstaendig aktiv	Vollstaendig + Vertretungsregeln
Review Gates	Nur bei Risiko	Standard gemaess RG-Katalog	Strikt + TTL-Überwachung
Transaction-Disziplin	Kernänderungen	Alle State-Änderungen	Alle Änderungen inkl. Betriebsrunden
Audit-Frequenz	ad hoc	woechentlich	pro Release + regelmaessig
Public-Freigabe	selten, manuell	kontrolliert	nur nach GO/NO-GO Gate

4. Typische Betriebsablaeufe je Modus

Starter: Tagesroutine

1. Stack starten + Status pruefen

2. 1-3 aktive Stories priorisieren

3. private Default fuer neue Objekte einhalten

4. Tagesabschluss mit TX + kurzer Notiz

Teambetrieb: Sprint-/Wochenroutine

1. Rollenpakete und Verantwortliche pro Story fixieren

2. Review-Slots und Gate-Faelle frueh markieren

3. Projektfortschritt nur ueber evidenzbasierte State-Wechsel

4. Wochenreview: Drift, Risiken, offene Escalations

Produktionsmodus: Release-Routine

1. Full Stack Audit ausfuehren

2. Reviewer + Owner pruefen Evidence

3. HITL GO/NO-GO (RG-004)

4. Release nur bei GO, danach Incident-Watch

5. Post-Release Learning klassifizieren

5. Checklisten pro Modus

Starter Checkliste

Sind alle neuen Kunden/Projekte als private gestartet?
Gibt es fuer jedes aktive Work Item Story + Owner?
Wurden State-Aenderungen als TX geloggt?
Sind offene Risiken klar benannt?

Teambetrieb Checkliste

Sind Rollenpakete pro Story dokumentiert?
Ist Reviewer ungleich Author?
Sind RG-Faelle im Voraus sichtbar?
Ist der Wochen-Review terminiert?

Produktionsmodus Checkliste

Audit-Evidence aktuell und vollständig?
GO/NO-GO Entscheidung dokumentiert?
Rollback-/Recovery-Pfad getestet?
Post-Release Monitoring und Incident-Oncall aktiv?

6. Transition-Regeln zwischen Modi

Von	Nach	Mindestvoraussetzung	BLOCK wenn
Starter	Teambetrieb	Rollenpakete aktiv + stabile TX-Disziplin + klarer Review-Prozess	Unklare Ownership oder fehlender Reviewer
Teambetrieb	Produktionsmodus	Wiederholbar grüne Audits + funktionierende GO/NO-GO Praxis	Gate-Bypass oder unvollständige Evidence
Produktionsmodus	Teambetrieb (Downgrade)	Geplanter Risk-Downshift mit Dokumentation	Ungeplante Deaktivierung von Sicherheitskontrollen

Keine Transition ohne Team-Entscheid Kein Upgrade ohne reproduzierbare Evidence Kleine Schritte mit Checkpoints

7. Betriebskommandos (praxisnah)

# Starter
bash specs/scripts/start-dev-web-stack.sh 8000 /home/zolo/space
bash specs/scripts/status-single-webserver.sh 8000

# Teambetrieb
bash iio/specs/scripts/validate-workspace-root-cleanliness.sh /home/zolo/space/iio strict
bash iio/specs/scripts/validate-capability-profiles.sh /home/zolo/space/iio strict

# Produktionsmodus
bash iio/specs/scripts/run-full-stack-audit.sh /home/zolo/space /home/zolo/space/iio /home/zolo/space/intelego
bash iio/specs/scripts/run-foundation-semantic-crosscheck.sh /home/zolo/space /home/zolo/space/iio /home/zolo/space/intelego