GUI Transition Backlog

Bruecke vom heutigen Betrieb ohne GUI zu einer klar priorisierten GUI-Einfuehrung. Fokus: sichere Bedienbarkeit, Rollen-Transparenz und fail-closed Gates statt kosmetischer Oberflaechen.

1. Zielbild fuer die erste GUI

Die erste GUI ist kein neues Prozessmodell, sondern eine sichtbare Schicht auf bestehenden Story-, Role-, Boundary- und Transaction-Rails. Alles, was heute per SOP und Skript passiert, muss in der GUI gleich oder sicherer sein.

GUI als Rail-Adapter No hidden state Role-aware actions TX-first Kein Gate-Bypass

2. Priorisierung: MVP, P1, P2

Tier	Scope	Nutzen	Nicht enthalten
MVP	Objekte/Kunden/Projekte anlegen, Story-Start, State-Wechsel, TX-Protokoll, Gate-Status	Teams koennen alltaeglichen Betrieb ohne CLI-Bottleneck fahren	Komplexe Analytics, freie Dashboard-Baukaesten
P1	Review-Arbeitsplaetze, Incident-Board, Audit-Evidence Viewer, Rollenpaket-Wizard	Review- und Produktionsbetrieb werden reproduzierbarer	Cross-space Federation Cockpit
P2	Federation-Views, semantische Diff-Assistenz, Workflow-Automation Templates	Skalierung ueber Teams/Spaces hinweg	Ad-hoc Experimente ohne Governance

3. MVP Screens und Kern-Flows

Screen A: Operations Home

Heute aktive Stories, offene BLOCKs, naechste Gates.
Quick Actions: Kunde anlegen, Projekt starten, Review starten.
Health/Validation Snapshot statt roher Terminal-Logs.

Screen B: Kunden- und Objektverwaltung

Default = private, expliziter Review fuer public.
Objektbaum mit Boundary-Markierungen.
Owner, Reviewer, Legal-Verantwortung sichtbar.

Screen C: Projekt-Workspace

Story -> Plan -> Work -> Artifact -> State in einer Sicht.
State-Transition nur mit Pflichtfeldern und TX-Entwurf.
Evidence-Anhaenge direkt am State-Wechsel.

Screen D: Gate and Release Panel

RG-Status mit Gruenden, TTL und Verantwortlichen.
GO/NO-GO als gefuehrter Entscheidungsdialog.
Fail-closed wenn Pflicht-Evidence fehlt.

Screen E: Transaction Logbook

Chronologischer TX-Feed mit Filter nach Scope und Rolle.
Diff-Ansicht: alter State vs neuer State.
Export fuer Review und Forensik.

Screen F: Runbook Runner

Vordefinierte Runs: Tagesstart, Onboarding, Release, Incident.
Schrittstatus mit Checklisten-Haken.
Automatische Erzeugung der zugehoerigen TX-Eintraege.

4. Top 8 User Flows fuer den Start

Flow 1: Neuen Kunden anlegen (safe default)

1. Kunde erfassen, Modus automatisch auf private setzen

2. Owner zuweisen, Reviewer optional vorschlagen

3. Erstes Projekt mit Story-Template erzeugen

4. TX-Eintrag erzeugen und bestaetigen

Flow 2: Projekt starten

1. Story und Zielzustand definieren

2. Rollenpaket zuordnen

3. Plan-Checkpoint erstellen

4. State = active setzen mit TX

Flow 3: Public-Freigabe beantragen

1. Boundary-Wechsel private -> public anstossen

2. Legal/IP und Reviewer-Pruefung verpflichtend

3. Gate-Entscheid RG-004 dokumentieren

4. Bei GO: State-Wechsel plus Evidence

Flow 4: Review-Run fuer release-ready

1. Reviewer oeffnet Gate Panel mit offenen Risiken

2. Evidence pruefen, fehlende Nachweise markieren

3. GO/NO-GO dokumentieren mit Begruendung

4. TX fuer Entscheidung und Auflagen schreiben

Flow 5: Incident erfassen und stabilisieren

1. Incident mit Scope, Impact, Boundary erfassen

2. Sofortmassnahme und Verantwortliche festlegen

3. Recovery-Status laufend dokumentieren

4. Root Cause und Learning-Klasse abschliessen

Flow 6: Tagesstart als gefuehrter Run

1. Health Snapshot und offene BLOCKs laden

2. Pflicht-Checks abhaken (Root, Profile, Audit-Status)

3. Prioritaeten fuer aktive Stories setzen

4. Ergebnis als Tagesstart-TX persistieren

Flow 7: State-Transition mit Pflichtbegruendung

1. Nutzer waehlt Zielstatus (z. B. review-ready)

2. GUI prueft Pflichtfelder, Rollenrecht und Gate-Status

3. Evidence und Kommentar werden angehaengt

4. Transition wird mit TX finalisiert

Flow 8: Audit-Export fuer Operator Review

1. Scope (Projekt, Zeitraum, Boundary) auswaehlen

2. Sequenziellen TX-Feed erzeugen

3. Gate-Entscheide und Evidence referenzieren

4. Export mit Hash/Version fuer Review bereitstellen

5. GUI Backlog als konkrete Stories (ausfuehrlich)

ID	Story	Tier	Aufwand	Abhaengigkeiten	Akzeptanzkriterien
GUI-001	Als Delivery Lead will ich neue Kunden mit private default anlegen.	MVP	S	-	Default private; public nur ueber Gate-Dialog.
GUI-002	Als Owner will ich ein Projekt nur mit Story+Owner starten koennen.	MVP	S	GUI-001	Ohne Story/Owner ist Start technisch blockiert.
GUI-003	Als Team will ich Rollenpakete pro Projekt setzen.	MVP	M	GUI-002	Owner/Delivery/Reviewer/Legal sind sichtbar und validiert.
GUI-004	Als Nutzer will ich State-Transitionen nur mit Pflichtdaten ausfuehren.	MVP	M	GUI-002	Transition fordert Pflichtfelder, sonst fail-closed BLOCK.
GUI-005	Als System will ich jeden State-Wechsel automatisch als TX loggen.	MVP	M	GUI-004	Ohne TX wird kein State persistiert.
GUI-006	Als Reviewer will ich offene Gates mit Evidence-Luecken sehen.	MVP	M	GUI-005	Gate-Liste zeigt Risiko, TTL, fehlende Nachweise.
GUI-007	Als Legal will ich public-Freigaben mitzeichnen koennen.	MVP	S	GUI-006	Boundary-Wechsel auf public erfordert Legal-Freigabe.
GUI-008	Als Ops will ich einen Tagesstart-Run guided ausfuehren.	MVP	M	GUI-006	Run dokumentiert Pflichtchecks und erzeugt Tages-TX.
GUI-009	Als Team will ich Objektbaum und Boundary-Zustand auf einen Blick sehen.	MVP	M	GUI-001	Objekte zeigen private/public/federated Labels.
GUI-010	Als Reviewer will ich GO/NO-GO ueber einen gefuehrten Dialog entscheiden.	MVP	M	GUI-006, GUI-007	Entscheid speichert Auflagen, Reviewer, Timestamp, TX.
GUI-011	Als Ops will ich Incident mit Impact/Scope erfassen.	P1	M	GUI-005	Incident braucht Klassifizierung und Owner.
GUI-012	Als Incident Lead will ich Recovery-Schritte als Timeline fuehren.	P1	M	GUI-011	Jeder Recovery-Schritt wird als TX erfasst.
GUI-013	Als Team will ich Root-Cause und Learning-Klasse verpflichtend abschliessen.	P1	S	GUI-011	Incident kann ohne RCA+Learning nicht auf closed.
GUI-014	Als Reviewer will ich Audit-Evidence im Kontext eines States sehen.	P1	M	GUI-006	Evidence Viewer zeigt Dateien, Zeit, Source, Hash.
GUI-015	Als Delivery Lead will ich Runbooks als wiederverwendbare Vorlagen nutzen.	P1	L	GUI-008	Vorlagen fuer Onboarding/Release/Incident vorhanden.
GUI-016	Als Manager will ich WIP-Limits und BLOCK-Aging sehen.	P1	M	GUI-006	Dashboard zeigt offene BLOCKs nach Alter und Owner.
GUI-017	Als Team will ich Federation-Sicht fuer verteilte Spaces nutzen.	P2	L	GUI-009, GUI-014	Cross-space Status ist read-only und auditierbar.
GUI-018	Als Reviewer will ich semantische Diffs fuer Status- und Artefakt-Aenderungen.	P2	L	GUI-005, GUI-014	Diff zeigt Bedeutungsebene statt nur rohe Textaenderung.
GUI-019	Als Ops will ich Workflow-Automation Templates definieren.	P2	L	GUI-015	Templates laufen nur innerhalb Rollen- und Gate-Regeln.
GUI-020	Als Betreiber will ich Release-Wellen mit Freeze- und Rollback-Knopf steuern.	P2	M	GUI-010, GUI-015	Freeze/Unfreeze und Rollback erzeugen nachvollziehbare TX-Kette.

6. Wellenplanung fuer die Umsetzung

Welle	Ziel	Stories	Exit-Kriterium
Welle 0 (Fundament)	Minimaler End-to-End Pfad ohne GUI-Bruch	GUI-001 bis GUI-005	Kunde -> Projekt -> State-Transition -> TX ist durchgaengig nutzbar
Welle 1 (Review faehig)	Gate- und Freigabebetrieb sauber in der GUI	GUI-006 bis GUI-010	GO/NO-GO laeuft ohne manuellen Side-Channel
Welle 2 (Incident und Audit)	Produktionsbetrieb mit Incident-Runs und Audit-Viewer	GUI-011 bis GUI-016	Incident-Lifecycle inkl. Learning ist vollstaendig
Welle 3 (Skalierung)	Federation, semantische Diffs, Automation	GUI-017 bis GUI-020	Skalierungsfunktionen ohne Governance-Bypass aktiv

Thin path first Jede Welle releasebar Kein Sprung ueber Wellen hinweg

7. Rollenrechte fuer die GUI

Aktion	Owner	Delivery	Reviewer	Legal
Kunde anlegen	erlaubt	erlaubt	sichtbar	sichtbar
Boundary auf public	beantragen	beantragen	pruefen	pruefen + freigeben
State release-ready	beantragen	vorbereiten	entscheiden	mitzeichnen bei Risiko
Gate override	nein	nein	nein	nein

Override nicht erlaubt Public ohne Review blockiert Least privilege

8. Test- und Abnahme-Matrix (fail-closed)

Testfall	Erwartetes Verhalten	Gate-Bezug
Projektstart ohne Story	BLOCK mit klarer Begruendung und Hinweis auf Pflichtfeld	Story/Transaction
Boundary private -> public ohne Legal	BLOCK, kein State-Wechsel, kein stilles Speichern	Boundary/Role
State-Wechsel ohne Evidence bei Risiko	BLOCK bis Evidence angehaengt	Audit/Gate
GO/NO-GO ohne Reviewer	BLOCK, Reviewer muss gesetzt sein	Actor/Role
Rollback eines Releases	Neue TX-Kette statt Retro-Edit	Transaction