Sessions sind fluechtig — Erkenntnisse nicht. Wie man mit 20 Supabase-Tabellen, vier Claude-Code-Hooks und fuenf Industrie-Standards (Lean Canvas, ADR, RICE, Diataxis, PRD) eine vollstaendige Projekt-Persistenz fuer AI-gestuetzte Entwicklung baut. Mit automatischem Logging, Cross-Session-Awareness und DB-Triggern die sich selbst schreiben.
Wer mit Claude Code oder einem anderen AI-Agent taeglich arbeitet, kennt das Phaenomen: jede Session beginnt bei null. Du hast gestern ein Problem geloest, drei Tage zuvor eine Architektur-Entscheidung getroffen, letzte Woche ein Feature gebaut — und heute musst du es der AI nochmal erklaeren.
Das ist nicht nur unbequem. Es produziert drei systematische Fehler:
1. Rekonstruktion statt Weiterarbeit — jede Session beginnt mit "was haben wir nochmal gemacht?"
2. Datenverlust bei Session-Wechseln — Erkenntnisse in Session A verschwinden, wenn du nach Session B wechselst
3. Keine Reproduzierbarkeit — andere (oder dein zukuenftiges Ich) koennen den Entwicklungsweg nicht nachvollziehen
Die Loesung ist nicht "besser aufpassen". Die Loesung ist strukturelle Persistenz: Ein System das automatisch erfasst was passiert, das Zusammenhaenge erkennt, und das bei jeder neuen Session sofort den vollen Kontext liefert.
Das System besteht aus drei Schichten.
Was gibt es ueberhaupt in deinem Setup? Welche Tools, welche APIs, welche Skills, welche Migrations laufen?
- auto_systems — externe Services (HubSpot, Banking-API, Cloud-Provider)
- auto_skills — AI-Agent-Skills (Python-Scripts die vom Agent aufgerufen werden)
- auto_connections — wie die Systeme miteinander sprechen
- auto_mcp — Model Context Protocol Server die der Agent nutzt
- auto_migration — Status aller Migrations-Projekte
- auto_accounts — Lizenzen und Kosten
- auto_domains — DNS, Hosting, Worker-Zuordnung
Das ist der Stand deiner Infrastruktur — der Agent weiss jederzeit was er hat.
Was bauen wir, warum, in welcher Reihenfolge? Hier liegt die eigentliche Disziplin.
- auto_projects — hierarchische Projekte mit Lean Canvas (9 Bloecke nach Ash Maurya)
- auto_prds — Product Requirements Documents
- auto_adrs — Architecture Decision Records im MADR-Format
- auto_roadmap — Now/Next/Later mit RICE-Scoring
- auto_features — konkrete Funktionen mit Status-Tracking
- auto_docs — Dokumentation nach Diataxis-Framework
- auto_project_resources — was gehoert zum Projekt
- auto_open_items — Fragen, Risiken, Blocker, Assumptions
Was ist heute passiert, wer hat was gemacht, wohin fliessen Themen weiter?
- auto_sessions — jede AI-Session mit Hostname, Topic, Start/Ende, Tools, Files
- auto_handoff — Uebergaben zwischen Sessions/Tools
- auto_dev_log — automatisches Entwicklungs-Log (ueber DB-Trigger)
- auto_goals — strategische Ziele (verknuepft mit Projekten)
- auto_processing_stats — operative KPIs der Pipelines
Claude Code bietet Hook-Events — Zeitpunkte an denen eigene Scripts ausgefuehrt werden koennen. Vier davon sind entscheidend.
Beim Start jeder Session wird ein Script aufgerufen das einen Eintrag in auto_sessions erstellt — mit Session-ID, Hostname, Start-Zeitpunkt, aktuellem Arbeitsverzeichnis. Async, damit der Agent nicht blockiert.
Die Konfiguration in ~/.claude/settings.json:
"SessionStart": [{"hooks": [{"type": "command", "command": "python3 session_logger.py SessionStart", "timeout": 8, "async": true}]}]
Bei jedem Prompt passiert zweierlei:
1. Async-Logging — Message-Count, last_activity werden aktualisiert
2. Cross-Session-Awareness-Check (synchron) — Script prueft ob der Inhalt des Prompts zu einem anderen Projekt gehoert als dem aktuellen
Der Clou: das Cross-Session-Script gibt einen strukturierten Hinweis an den Agent zurueck, damit der Agent den User hoeflich fragt ob ein Handoff sinnvoll ist. Automatische Aktionen werden NICHT ausgeloest — der User behaelt die Kontrolle.
Nach jedem Tool-Aufruf werden die genutzten Tools und geaenderten Dateien getrackt. So laesst sich nachvollziehen welche Session welche Dateien angefasst hat — perfekt fuer Incident-Analyse.
Vor jedem Tool-Call laufen zwei Schutz-Scripts:
- check_destructive_ops blockiert rm -rf, DROP TABLE, git push --force
- check_volltext_truncation verhindert dass Dokumente abgeschnitten werden
Das ist Pflicht. Agenten die "aus Versehen" Dinge loeschen sind ein haeufiges Produktionsproblem.
Viele Updates muessen automatisch geloggt werden — sonst muss der User bei jeder Aenderung daran denken. Postgres-Trigger sind dafuer perfekt.
Das Grundprinzip:
CREATE OR REPLACE FUNCTION log_feature_changes()
RETURNS TRIGGER AS $$
BEGIN
IF (TG_OP = 'UPDATE' AND OLD.status IS DISTINCT FROM NEW.status) THEN
INSERT INTO auto_dev_log (entity_type, entity_name, action, description, source)
VALUES ('feature', NEW.name, 'updated',
format('Status: %s -> %s', OLD.status, NEW.status), 'auto-trigger');
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Der entscheidende Vorteil: Egal wie eine Aenderung reinkommt — ueber den Agent, ueber eine Web-UI, direkt in SQL — das Log schreibt sich selbst. Keine Disziplin noetig.
Trigger werden angelegt fuer:
- auto_features — Status-Aenderungen (todo → in_progress → done)
- auto_projects — neue Projekte, Status-Aenderungen
- auto_adrs — neue Architektur-Entscheidungen
- auto_sessions — Session-Start und -Ende
Das Ergebnis ist ein lueckenloser Audit-Trail ohne manuellen Aufwand.
Das Problem: Wenn ein User eine Session startet mit dem Topic "ERP Buchhaltung KG 2023", woher soll das System wissen dass das zum Projekt "ERP Buchhaltungs-Pruefung" gehoert?
Loesung: Eine Postgres-Funktion die Keywords matched, kombiniert mit einem Trigger der bei jeder Topic-Aenderung die project_id automatisch setzt.
Das Grundprinzip (vereinfacht):
CREATE OR REPLACE FUNCTION find_project_by_keywords(topic TEXT)
RETURNS INTEGER AS $$
DECLARE
pid INTEGER;
topic_lower TEXT;
BEGIN
topic_lower := lower(topic);
SELECT id INTO pid FROM auto_projects
| WHERE topic_lower ILIKE '%' | lower(slug) | '%' |
|---|---|---|
| OR topic_lower ILIKE '%' | lower(short_name) | '%' |
ORDER BY parent_id NULLS LAST LIMIT 1;
IF pid IS NOT NULL THEN RETURN pid; END IF;
-- Themen-Heuristiken als Fallback
IF topic_lower ~ '(erp|buchhaltung|steuer)' THEN
SELECT id INTO pid FROM auto_projects WHERE slug = 'erp-buchhaltung';
RETURN pid;
END IF;
RETURN NULL;
END;
$$ LANGUAGE plpgsql;
Ab jetzt gilt: Du nennst eine Session "XYZ", und automatisch ist sie mit dem passenden Projekt verknuepft. Im Dashboard siehst du sofort alle Sessions zu einem Projekt, alle bearbeiteten Dateien, alle getroffenen Entscheidungen.
Das ist der interessanteste Teil. Das Szenario: Du arbeitest an Projekt A und erwaehst etwas das eigentlich zu Projekt B gehoert. Ohne Erkennung ist diese Erkenntnis verloren.
Das Cross-Session-Script laeuft bei jedem UserPrompt und scored wie gut der Prompt zu jedem aktiven Projekt passt.
Das Scoring-Prinzip:
def score_project_match(prompt_lower, project):
score = 0
if project['slug'] in prompt_lower: score += 60 # Direkte Erwaehnung
if project['name'].lower() in prompt_lower: score += 50
for kw in KEYWORDS[project['slug']]:
if kw in prompt_lower: score += 15 # Keyword-Match
return min(score, 100)
Bei einem Score >= 30 UND das Projekt ist NICHT das aktuelle, bekommt der Agent einen Hinweis:
CROSS-PROJECT HINWEIS (automatisch erkannt):
Aktuelle Session: ERP Buchhaltungs-Pruefung
Moegliches anderes Projekt: "Mandantenportal" (Match: 60%)
→ Soll ein Handoff erstellt werden?
Der Agent fragt dann den User. Der User entscheidet. Keine verlorenen Erkenntnisse mehr — ohne dass der User selbst dran denken muss.
Das System ist nicht nur technisch sondern auch methodisch durchdacht. Fuenf etablierte Frameworks werden kombiniert.
Jedes Projekt bekommt 9 Felder: Problem, Kundensegmente, Unique Value Proposition, Loesung, Kanaele, Einnahmequellen, Kostenstruktur, Key Metrics, Unfair Advantage. Das zwingt zu strategischer Klarheit bevor Code geschrieben wird. Kein Projekt startet ohne ausgefuelltes Canvas.
Standard-Sektionen: TL;DR, Background, Goals, Non-Goals, User Stories, Requirements (functional + non-functional), Success Criteria, Open Questions, Out of Scope, Risks, Dependencies, Timeline. Ein PRD pro Projekt.
Jede architektonische Entscheidung wird dokumentiert: Kontext, Decision Drivers, Considered Options, Decision, Rationale, Positive/Negative/Neutrale Konsequenzen, Status. Nummeriert (ADR-001, ADR-002...) pro Projekt. Unersetzlich wenn du 3 Monate spaeter fragst "warum haben wir das eigentlich so gemacht?"
Statt Datums-Plaene (die nie stimmen) arbeiten wir mit drei Buckets:
- Now — was wird in den naechsten 1-2 Wochen gebaut
- Next — was kommt danach (kein Datum)
- Later — Backlog
Kombiniert mit RICE-Scoring: (Reach x Impact x Confidence) / Effort = Prio-Wert. Automatische Sortierung. Keine politischen Entscheidungen.
Vier Dokumentations-Typen: Tutorial (lernen durch Machen), How-To (Aufgabe erledigen), Reference (trockene Info), Explanation (Verstehen). Jeder Doc-Eintrag bekommt einen doc_type und wird entsprechend strukturiert. Nie wieder Doku die niemand findet weil sie falsch kategorisiert ist.
Dogfooding bedeutet: du nutzt dein eigenes Produkt selbst. Production-Driven Development bedeutet: Features entstehen aus echten Produktionsanforderungen, nicht aus Theorie-Roadmaps. Customer Zero bedeutet: du bist dein eigener erster Kunde.
Wenn du das kombinierst mit dem beschriebenen System:
- Jeder Prompt wird geloggt
- Jede Datei-Aenderung wird getrackt
- Jede Entscheidung wird in einem ADR dokumentiert
- Jedes Feature hat einen Status
- Jedes Problem landet in Open Items bis es geloest ist
- Jede Session wird automatisch einem Projekt zugeordnet
- Cross-Projekt-Themen werden erkannt bevor sie verloren gehen
- Das Dev-Log schreibt sich selbst ueber DB-Trigger
Nach einer Woche hast du einen vollstaendigen Entwicklungs-Timeline. Nach einem Monat kannst du jeden Schritt zurueckverfolgen. Nach einem Jahr hast du ein Produkt dessen Entwicklungsgeschichte komplett dokumentiert ist.
Der Wert ist nicht technisch, sondern kognitiv: Du musst den Stand nie mehr im Kopf behalten.
- PostgreSQL — wir nutzen Supabase (managed Postgres + REST-API + Auth)
- Claude Code oder ein anderer Agent mit Hook-Support
- Optional: Ein Web-Framework fuer das Dashboard (Cloudflare Workers reicht — unter 1.000 Zeilen JavaScript)
Die 20 Tabellen mit Indizes, Constraints und RLS-Policies. Setup-Zeit: ca. 10 Minuten mit einem fertigen SQL-Script.
In ~/.claude/settings.json die vier Hooks eintragen. Die Scripts sind jeweils 100-200 Zeilen Python.
Fuer auto_features, auto_projects, auto_adrs je eine Trigger-Funktion die bei INSERT/UPDATE in auto_dev_log schreibt.
Die Postgres-Funktion find_project_by_keywords(topic) + Trigger auf auto_sessions.topic.
Entweder ein Cloudflare Worker der direkt aus Supabase liest, oder eine React-App. Der Worker-Ansatz ist einfacher zu deployen.
Lean Canvas ausfuellen, PRD schreiben, erste 3-5 Features anlegen, erste 3-5 Roadmap-Items eintragen. Das kostet 2 Stunden und hat danach fuer Monate Wirkung.
- Supabase Free Tier reicht fuer einzelne Entwickler
- Cloudflare Workers Free reicht fuer das Dashboard (100k requests/day)
- Setup: ca. 1 Tag fuer die komplette Infrastruktur
- Laufend: ca. 5 Minuten pro Session fuer den session-end Skill
- Disziplin: null — das meiste laeuft automatisch
Die naive Nutzung von AI-Agents ist ein Chat-Fenster. Das funktioniert fuer einmalige Fragen. Es funktioniert nicht fuer echte Entwicklung.
Echte Entwicklung braucht:
- Persistenten Kontext (was wurde entschieden, warum)
- Strukturierte Entscheidungen (ADRs, PRDs, Lean Canvas)
- Verlinkbare Ressourcen (Sessions zu Projekten, Files zu Sessions)
- Verlaessliche Dokumentation (Diataxis-klassifiziert)
- Cross-Session-Awareness (Themen-Routing bevor Erkenntnisse verloren gehen)
All das laesst sich mit einer Handvoll Tabellen, ein paar Hooks und ein bisschen Disziplin bauen. Das System hier wurde in einer einzigen Session entwickelt — waehrend es gleichzeitig benutzt wurde. Dogfooding at its best.
- Lean Canvas: https://leanstack.com/lean-canvas
- MADR-Format: https://adr.github.io
- Diataxis: https://diataxis.fr
- RICE-Scoring: https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers
- Claude Code Hooks: https://docs.anthropic.com/de/docs/claude-code/hooks
Lizenz: CC BY-SA 4.0