Prozess & Zuständigkeiten (RACI)

Diese Seite beschreibt den verbindlichen Ablauf für Fehler (Bugs), Verbesserungen (Features) und Support-Fragen — inklusive einer RACI-Matrix, die festhält, wer entscheidet, wer ausführt und wer nur informiert wird.

Die vier Kanäle

Fehler (Bug)

Etwas funktioniert nicht. Wird zum Ticket FB-#### vom Typ bug.

Verbesserung (Feature)

Ein Wunsch oder eine Idee. Wird zum Ticket FB-#### vom Typ feature.

Support-Frage

Verständnis- oder Hilfefrage, kein Fehler. Läuft als Chat mit eigener Nummer SUP-####.

Kummerkasten

Familieninterne Meldung eines Kindes. Bleibt streng in der Familie — erreicht nie den Betreiber oder GitHub. Eigener Prozess, eigene Tabellen.

Grundregeln

Diese acht Regeln gelten für jedes Ticket:

1. Status zuerst, dann Code. Erst übernehmen und die Felder pflegen, dann bauen — nie umgekehrt.
2. Nie direkt schließen. Nach dem Bauen geht das Ticket auf test (mit Versionsnummer); der Melder nimmt ab. Ein Datenbank-Guard erzwingt das.
3. Rückfragen nur über das System (feedback_ask), nicht per Chat oder Mail — der Melder sieht sie dann als „Der Betreiber hat eine Frage“.
4. Jeder Fix wird dokumentiert: architecture (Ursache, Komponenten, Lösungsskizze) und test (Reproduktion, Regressionstest, CI-Gates).
5. Freigabe-Gate. Verbesserungen normaler Nutzer brauchen die Freigabe des Betreibers. Ausnahmen: von der KI erkannte echte Fehler sowie Meldungen von Konten mit feedback_direct_ok.
6. GitHub-Export automatisch. Bug → bestätigt bzw. Feature → angenommen legt ein Issue an. Fragen, Duplikate und abgelehnte Meldungen niemals. Screenshots bleiben privat.
7. Migrationen immer als Datei unter app/supabase/migrations/ — sie sind die Quelle für CI und frische Deployments.
8. Nach jedem Deploy: Version hochzählen, Changelog-Eintrag, CI grün prüfen. Zusammengehörige Fixes bündeln (weniger Releases spart CI-Minuten).

Statusketten

Fehler (Bug)

neu→triage→bestätigt→analyse→umsetzung→test→erledigt

Seitenwege: abgelehnt, duplikat. bestätigt löst den GitHub-Export aus. Lehnt der Melder ab („Doch nicht behoben“, mit Pflicht-Begründung), geht das Ticket zurück auf umsetzung.

Verbesserung (Feature)

idee→prüfung→angenommen→geplant→umsetzung→test→ausgeliefert

Zusätzlicher Freigabe-Zweig: vorgeschlagen — die KI hat Analyse und Lösungsvorschlag erstellt, das Ticket wartet auf die Freigabe des Betreibers (→ umsetzung) oder wird abgelehnt. angenommen löst den GitHub-Export aus.

Support-Fragen

offen→in Bearbeitung→erledigt

Support-Fragen sind kein Ticket, sondern ein Chat zwischen Melder und Betreiber. Jede Frage bekommt eine eigene Nummer SUP-#### und einen sichtbaren Status — im Support-Modul der Betreiber-Konsole und in „Meine Fragen“ beim Melder. Wird aus einer Frage ein Fehler oder ein Wunsch, legt der Betreiber daraus ein FB-####-Ticket an.

Pflicht-Dokumentation je Fix

Feld	Inhalt
architecture	cause (Ursache), components (Dateien), tables (Tabellen/Edge), sketch (Lösungsskizze)
test	repro, regression (Test geschrieben?), regressionLink (Testpfad), gates (vitest, pgtap, deno, e2e), note

Jeder Fix bekommt einen Test

Sicherheits- und RLS-Arbeit wird zuerst per pgTAP abgesichert, danach umgesetzt.

Zwei Texte je Fix — und sie haben verschiedene Leser

Zu jedem ausgelieferten Fix entstehen zwei Texte. Sie werden leicht verwechselt — dann landet die Ursachenanalyse aus dem Ticket in den Release-Notes und klingt dort wie ein privates Gespräch mit dem Melder, obwohl sie jede Familie liest.

	Ticket-Kommentar	Release-Notes
Leser	der eine Melder	alle Nutzer (Hilfe › Versionshistorie, Neuigkeiten, Versionshistorie)
Zweck	Der Melder soll abnehmen können	Alle sollen wissen, was jetzt anders ist
Inhalt	Ursache · was gebaut wurde · Prüf-Kette	Das Ergebnis, in ein bis zwei Sätzen
Ton	persönlich, antwortend	sachlich, allgemein

Die Ursache gehört ins Ticket, das Ergebnis in die Release-Notes

In den Release-Notes haben nichts zu suchen: Ursachen-Herleitung, Selbstkritik, „bitte prüfen“-Ansprache, Datei-, Tabellen- oder Bibliotheksnamen, interne Projekt-Stufen und persönliche Beispiele. Alle drei Anzeigen speisen sich aus einer Quelle (app/src/changelog.ts) — eine geglättete Doku-Fassung gibt es nicht.

Zuständigkeiten — RACI

Rollen: Melder (die meldende Person) · Betreiber (Owner/Operator) · KI (ausführende Assistenz im Namen des Betreibers) · System (Guards, Auto-Export, CI, Deploy, Benachrichtigungen).

R führt ausA verantwortlich / entscheidetC wird konsultiertI wird informiert

Aktivität	Melder	Betreiber	KI	System
Meldung / Frage erstellen	A·R	I	I	I
Sichten & Triagieren	I	A	R	—
Analyse / Ursache	I	A	R	—
Vorschlag erstellen (Analyse + Lösung)	I	C	R	—
Freigabe erteilen	I	A·R	C	I
Umsetzen (Code + Test)	I	A	R	—
Test- & CI-Gate	I	A	R	R
Deploy	I	A	R	R
Auf „test“ setzen + Melder benachrichtigen	I	A	R	R
Ticket-Kommentar an den Melder (Ursache · Prüf-Kette)	C	A	R	—
Release-Notes formulieren (für alle Nutzer)	I	A	R	—
Abnahme („Passt ✓“ / „Doch nicht behoben“)	A·R	I	I	I
Endgültig schließen	C	A	R	R
GitHub-Issue anlegen / synchronisieren	I	A	I	R
Support-Frage beantworten	C	A	R	I
Changelog / Version / Ticketfelder	I	A	R	—

Kurz gemerkt: Der Melder besitzt Erstellen und Abnehmen. Der Betreiber ist überall dort verantwortlich, wo entschieden oder freigegeben wird. Die KI ist der ausführende Part — Triage, Analyse, Bauen, Testen, Deployen, Dokumentieren — im Namen des Betreibers. Das System erzwingt die Regeln (Abnahme-Guard, Auto-Export) und übernimmt die Automatik.

Ausnahme bei Vorschlägen

Die KI erstellt Analyse und Lösungsvorschlag. Bei Verbesserungen normaler Nutzer entscheidet der Betreiber die Freigabe. Von der KI erkannte echte Fehler und Meldungen von Konten mit feedback_direct_ok dürfen direkt in die Umsetzung gehen.

Merksatz für die tägliche Arbeit

Tipp

Übernehmen → Felder, Architektur und Test dokumentieren → Melder antworten → bauen (mit Test) → auf „test“ + Version → Melder nimmt ab.

Nie erst Code, dann Ticket. Nie direkt schließen. Rückfragen nur über das System.

Quellen

Die kanonische, maschinenlesbare Definition der Statusketten und Regeln lebt in der Datenbank (RPC mcp_feedback_guide) und im Arbeits-Skill feedback-workflow. Diese Seite ist die lesbare Fassung inklusive Zuständigkeiten. Bei Prozessänderungen werden alle drei nachgezogen.