Lange Cursor-Sessions: Eine Spezifikation, Handoff-Dateien und Regeln statt Hoffnung

Viele kennen Cursor als Editor mit KI-Autocomplete — Tab drücken, nächste Zeile Code. Seit Agent Mode und Composer geht es einen Schritt weiter: Das Tool plant, editiert Dateien, startet Shell-Befehle und arbeitet Minuten oder Stunden an einer Aufgabe, während du zusiehst oder parallel etwas anderes machst. Man spricht dann von Coding-Agents (oder agentischer Entwicklung): nicht «eine Antwort im Chat», sondern eine laufende Session mit Repo-Zugriff.

Dieser Beitrag richtet sich an zwei Gruppen gleichzeitig:

• Einsteiger: Du nutzt Cursor vielleicht schon, hast aber noch kein System für lange Aufgaben — hier erkläre ich Begriffe, typische Fehler und ein Minimal-Setup zum Kopieren.
• Praktiker: Du kennst Git, CI und Multi-Repo-Arbeit — im zweiten Teil bleiben die konkreten Muster (ACTIVE, Checkpoint, Hooks, Rules), nur mit mehr Kontext, warum sie nötig sind.

Stand Oktober 2026 arbeite ich in mehreren Repos — Backend, Admin-Oberfläche, Docker-Orchestrierung, Themes — und setze Agents für echte Refactorings, Regressionen und Produktfixes ein. Der Engpass war selten «schreibt das Modell schlechten Code?». Viel häufiger:

• Kontextverlust nach Kompression oder neuem Chat
• vorzeitiges Stoppen nach einem grünen Teilresultat
• Plan-Sprawl (viele Markdown-Pläne, die sich widersprechen)
• Schnellfixes an Testdaten statt an der eigentlichen Pipeline
• Live-Tests gegen alte Builds ohne Rebuild

Die Antwort war keine «bessere Prompt», sondern ein kleines Betriebssystem für Agents im Repository. Dieser Text ist keine offizielle Cursor-Dokumentation, sondern ein Erfahrungsbericht — du kannst die Ideen auch in anderen IDEs oder mit anderen Modellen anwenden, solange du Dateien und Regeln im Repo pflegst.

Kurzfassung

1. Der Chat ist kein Projektplan. Alles Wichtige gehört in versionierte Dateien (Spezifikation + kurzer Checkpoint).
2. Hooks und Rules erinnern den Agent an Session-Start und vor Kontext-Kompression — wie ein Übergabeblatt in der Schicht.
3. Klare Gates (Tests, Deploy, Regression) und klare Stop-Regeln verhindern, dass «fast fertig» als fertig verkauft wird.

Wenn du nur fünf Minuten hast: lies Kurzfassung, Glossar und «Minimal-Set für dein Repo» am Ende. Wenn du einrichten willst: der Mittelteil ist die Schritt-für-Schritt-Logik.

Was ist Cursor hier — und was ein Agent?

Begriff	In einem Satz
Cursor	Code-Editor (VS-Code-Familie) mit eingebauter KI und Agent-Modus.
Agent / Composer	Modus, in dem die KI mehrere Schritte ausführt (Dateien, Terminal), nicht nur Text antwortet.
Kontextfenster	Begrenzter «Arbeitsspeicher» der Session — irgendwann wird zusammengefasst (Compaction).
Rules	Projektregeln in .cursor/rules/, die das Modell bei jeder Anfrage mitlesen soll.
Hooks	Kleine Skripte, die Cursor bei Events (z. B. Session-Start) ausführt und Text in den Kontext injiziert.
Gate	Ein definierter Prüfpunkt (Tests, Deploy, Regression), der grün sein muss, bevor man «fertig» sagt.
Handoff	Übergabe an den nächsten Chat, die nächste Session oder den Menschen — ohne Gedächtnis im Chat allein.

Analogie: Ein Agent ist eher Praktikant mit Tastatur als Orakel. Er arbeitet schnell, vergisst aber, was ihr morgens besprochen habt, wenn ihr kein Logbuch auf dem Schreibtisch (Checkpoint) und keinen Projektauftrag in der Schublade (ACTIVE) habt.

Warum ein Assistent im Chat allein scheitert

Komplexität ist verteilt

Stell dir vor, ein Test in einer großen Suite schlägt fehl — rot, ein FAIL. Für einen Menschen mit Erfahrung ist das der Beginn der Diagnose. Für einen Agent im Chat ist es oft das Ende der Aufmerksamkeit, wenn niemand vorgibt, was als Nächstes zählt.

Ein roter Test kann Ursachen haben in Routing, Datenaufbereitung, Autorisierung, Caching, Prompting, Ranking, Timeouts — und in der Reihenfolge, in der Prüfungen laufen. Der Agent sieht im Chat oft nur «1 FAIL». Ohne Trace, ohne verbindliche Gate-Hierarchie und ohne Verbot, nach dem ersten Patch zu stoppen, endet die Session mit «hier ist ein Vorschlag» statt mit grünem Gate oder benannter Restschuld.

Im Alltag: Du gibst dem Agent «mach die Regression grün». Er fixt einen Test, meldet Erfolg, und schweigt. Du öffnest am nächsten Tag einen neuen Chat — und keiner weiß mehr, dass noch elf FAILs in Cluster B offen sind.

Kontext ist teuer und flüchtig

Lange Sessions füllen das Kontextfenster. Cursor kompimiert (Compaction): ältere Teile der Unterhaltung werden zusammengefasst oder fallen weg. Das ist nötig, damit das Modell weiterarbeiten kann — fühlt sich aber an wie plötzliches Gedächtnisverlust.

Danach «erinnert» sich der Agent an Details aus Stunde 1 nicht mehr — es sei denn, kritische Entscheidungen stehen in Dateien, die bei Session-Start wieder eingespielt werden. Genau dafür sind Checkpoint und Hooks gedacht (siehe unten).

«Grün» ist mehrdeutig

Metrik	Was sie bedeutet	Was sie nicht bedeutet
pytest einer Datei	Ein Modul-Verhalten	Das Gesamt-Track-Ziel ist erledigt
Eine Suite voll grün	Diese Stichprobe	Die volle Regression mit allen Schaltern
Ein Smoke-Test OK	Ein Pfad funktioniert	End-to-End inkl. teurer Schritte
Commit auf Branch	Code existiert	Deployed auf der Umgebung, die du testest

Ohne explizite Gate-Hierarchie verkaufen Agents «fast fertig» als Erfolg — während die operative Spezifikation noch offene Kriterien und eine Delete-Liste enthält.

Merksatz: Ein grüner Teilschritt ist ein Zwischenstand, kein Abschluss — es sei denn, die Spezifikation sagt ausdrücklich, dass nur dieser Schritt zählt.

Das Problem mit zehn Plänen im Repo

Viele Teams (und viele Agents) erzeugen unter Druck neue Markdown-Dateien: plan-v2.md, TODO-phase-3.md, notes-from-chat.md. Jede klingt vernünftig. Zusammen sind sie widersprüchlich: Plan A sagt «nur Refactor», Plan B «schnell Feature», der Chat sagt «wir sind fertig».

Kernidee: Es gibt genau eine aktive Spezifikation für Agent-Arbeit am Produkt — bei uns heißt die Datei ACTIVE.md unter docs/ (der Name ist egal; WORKING.md geht auch). Alte *plan*-Markdowns, veraltete Branch-Notizen und Chat-Zusammenfassungen sind Archiv, nicht Arbeitsauftrag.

Plans are cheap; operational specs are expensive. Teams und Agents brauchen einen Ort für «was ist jetzt wahr?», explizite Verbote und einen nächsten Schritt — nicht verstreute Bullet-Listen im Chat.

Die Datei darf lang sein. Das ist Absicht: Agents sollen nicht raten. Menschen können mit der Tabelle «Status-Log» und dem Abschnitt «Nächster Schritt» einsteigen.

Was in einer ACTIVE-Datei stehen sollte

1. Gesamtziel — wann «fertig» wirklich fertig ist (nicht «wenn der Agent aufhört»).
2. Parallele Tracks — z. B. UI-Fix vs. Backend-Cleanup vs. Refactor ohne Verhaltensänderung. Verhindert, dass ein Agent im Refactor-Branch versehentlich Produktlogik anfasst.
3. Eingefrorener Scope — klare Grenze: «diesen Modulblock jetzt nicht anfassen».
4. Agent-Sessions (verbindlich) — Stop-/Weiter-Regeln (eigener Abschnitt unten).
5. Erlaubte Dateien pro Phase — Diff außerhalb → Stop und Mensch fragen.
6. Gate-Reihenfolge — Unit → breitere Regression → Deploy → Smoke → optional teurer Full-Lauf.
7. Status-Log (Tabelle) — chronologisch: was gebaut, welche Tests, welcher Live-Lauf, Restschuld in einem Satz.

Beispiel «Nächster Schritt» (gut): «FAIL-Cluster login-timeout: Trace für Case 7 lesen, dann Pool-Timeout in service/auth.py anpassen, erneut Suite B.»

Beispiel (schlecht): «Weiter debuggen wenn Zeit.»

Commit- und PR-Vertrag (Beispiel)

• Titel-Schema, damit Historie lesbar bleibt
• Diff nur gegen erlaubte Dateien
• Bei rotem Gate: Restschuld ins Status-Log, nicht heuristisch überall patchen
• Korrektur-Reihenfolge bei Fehlklassen dokumentiert (z. B. Konfiguration → Daten → Pipeline, nicht der schnellste Copy-Paste aus einem anderen Modus)
• Kurz bestätigen, dass Engineering-Regeln (Layout, keine Shims) geprüft wurden

Handoff ohne Gedächtnis: die Checkpoint-Datei

Stell dir vor, du gehst Feierabend — oder der Chat wird komprimiert — und ein neuer Agent übernimmt. Was braucht er in den ersten drei Minuten?

Nicht zwanzig Seiten Prosa, sondern ein Dashboard: Branch, letzter Testlauf, was offen ist, eine nächste Aktion.

Dafür pflegen wir SESSION_CHECKPOINT.md — oft eine Tabelle, aktualisiert bei größeren Zwischenständen und vor Turn-Ende, wenn noch Restschuld da ist.

Feld	Zweck	Beispiel (illustrativ)
branch	Wo wird gearbeitet?	fix/regression-cluster-b
updated	Zeitstempel	2026-10-18 14:00
deploy	Was läuft in der Test-Umgebung?	LocalDev, BuildCodeOnly nach Commit abc
uncommitted	Grober Diff-Hinweis	3 files auth + tests
last_gate	Letztes messbares Ergebnis	Suite B: 38/40
gate_target	Aktuelles Ziel	Suite B: 40/40, dann Full Smoke
baseline	Vergleichslauf	gestern 35/40
fail_clusters	Gruppierung offener FAILs	timeout (2), flaky-api (0 fixed)
next_action	Eine klare Aktion	Case 12 Trace → Timeout 30s
in_progress	Hintergrund-Shell	regression.sh läuft, PID …

	ACTIVE	SESSION_CHECKPOINT
Tiefe	Spezifikation, Historie, Phasen	Momentaufnahme
Änderung	Bei echtem Fortschritt / Phasenwechsel	Oft pro Session / vor Compact
Leser	Warum	Was jetzt

Checkpoint ersetzt nicht die Spezifikation — er verweist darauf. Wenn du nur eine Datei anlegst: nimm zuerst den Checkpoint. Wenn du skalierst: ACTIVE dazu.

Cursor Hooks: Kontext bei Start und vor Kompression

Hooks sind für viele Leser das Unbekannteste. Kurz: Cursor kann beim Start einer Session und bevor der Kontext komprimiert wird ein Skript auf deinem Rechner ausführen. Das Skript liest Dateien aus dem Repo und gibt strukturierten Text zurück — der landet im Agent-Kontext, fast wie eine zusätzliche Regel.

Konfiguration in .cursor/hooks.json:

{
  "version": 1,
  "hooks": {
    "sessionStart": [
      { "command": "py .cursor/hooks/session_context.py sessionStart" }
    ],
    "preCompact": [
      { "command": "py .cursor/hooks/session_context.py preCompact" }
    ]
  }
}

Was beim sessionStart passiert

1. Du öffnest Cursor oder startest eine neue Agent-Session.
2. Das Skript läuft (Python in unserem Fall; PowerShell oder Node geht auch).
3. Es liest Checkpoint und den Anfang von ACTIVE.
4. Es schreibt JSON auf stdout mit additional_context — Cursor hängt diesen Text an die Session.

Effekt für Einsteiger: Du musst nicht mehr in jedem Chat copy-pasten «lies bitte docs/…». Das Repo begrüßt den Agent mit dem aktuellen Stand.

Was bei preCompact passiert

Kurz bevor Cursor den Chat zusammenfasst, läuft dieselbe Pipeline mit einer Erinnerung: Checkpoint jetzt aktualisieren (next_action, last_gate, in_progress). Sonst verliert die Zusammenfassung genau die Zahlen, die morgen wichtig wären.

Warum das besser ist als «lies ACTIVE am Anfang»:

• Niemand muss diszipliniert sein — das passiert automatisch.
• Nach Compaction kommt preCompact — genau dann, wenn Agents sonst «frisch» wirken und aufhören.
• Der Checkpoint hat ähnliche Priorität wie Projekt-Rules.

Grenze: Hooks ersetzen kein Deploy und keinen Regression-Lauf. Sie reduzieren Orientierungsverlust, nicht falschen Code.

Rules mit alwaysApply: Verhalten erzwingen

Rules sind Markdown-Dateien unter .cursor/rules/ (oft .mdc). Darin stehen Anweisungen wie «vor Live-Test immer deployen» oder «nicht committen ohne User».

Cursor kann Rules immer mitschicken (alwaysApply: true) oder nur, wenn bestimmte Dateien bearbeitet werden. Für lange Agent-Sessions setzen wir die wichtigsten auf alwaysApply — sonst werden sie in Stunde drei vergessen.

Bei uns typisch:

• Session-Kontinuität: Checkpoint-Checkliste, kein Stop nur wegen Notification, nach Handoff next_action ausführen
• Scope: nur erlaubte Dateien aus ACTIVE; kein Archiv-Plan; kleine Diffs ohne explizites OK
• Deploy vor Live-Test: nach App-Änderung erst Build/Stack, dann Regression gegen die richtige URL
• Engineering: Commit-Gate, SOLID, keine TODO-Commits
• Repo-Layout: kein Mixed Layout, keine Import-Shims

Lesson: Rules sind API-Verträge zwischen Mensch und Agent. Ohne alwaysApply konkurrieren sie mit dem Modell-Drang, «fertig» zu sein und den User zu entlasten — was oft heißt: zu früh stoppen.

Für Einsteiger: Fang mit einer Rule an: «Wenn next_action im Checkpoint gesetzt ist, ist die Session nicht zu Ende, bis es erledigt oder als Restschuld im Log steht.»

AGENTS.md und die Schichten

Nicht alles gehört in Rules — manches ist reine Repo-Dokumentation. AGENTS.md im Root ist die Kurzreferenz für Cursor und andere Coding-Agents: wie CI starten, welche Skripte kanonisch sind, wo die aktive Spezifikation liegt.

User Rules (Cursor-Einstellungen, z. B. Sprache, kein Push ohne Anfrage)
    ↓
AGENTS.md (Repo-Einstieg, CI-Befehle)
    ↓
.cursor/rules/*.mdc (alwaysApply + dateispezifisch)
    ↓
docs/…/ACTIVE.md (domänenspezifische Spezifikation)
    ↓
SESSION_CHECKPOINT.md (operatives Now)
    ↓
Skills bei Bedarf (spezialisierte Anleitungen)

User Rules gelten global in deinem Cursor-Profil. AGENTS.md gilt pro Repository. Wenn du in drei Repos arbeitest, brauchst du drei AGENTS — oder ein Multi-Root-Workspace mit klaren Pfaden in den Rules.

Duplikation vermeiden: ACTIVE hält den aktuellen Kriegsplan; AGENTS verlinkt dorthin für lange Sessions.

Was Stoppen erlaubt ist — und was nicht

Das klingt pedantisch, ist aber der kulturelle Kern: Agents sind darauf trainiert, hilfreich abzuschließen. «Ich habe dir Bescheid gegeben» fühlt sich für das Modell wie eine gute Tat an. Für dich ist es oft Halbfertig.

Stoppen erlaubt

• Nutzer bricht ab («reicht», «nur Frage»).
• Harter Blocker mit einer klaren User-Entscheidung (Scope außerhalb erlaubter Dateien, Secrets, Architekturentscheidung).
• Track-Ziel erledigt: Gate grün oder Restschuld explizit im Status-Log + Chat.

Stoppen verboten (in echten Sessions passiert)

Anti-Stop	Was stattdessen
«Kurz informiert» nach Hintergrund-Task	Weiter: nächster FAIL-Cluster
Eine Teilsuite grün	Volles Gate oder nächster Bullet «Nächster Schritt»
«Optional wenn du zurück bist»	Ungültig als Session-Ende
Regression exit 1 nur loggen	Triage + Fix + Re-run
System-Notification «briefly inform user»	Danach wie offene Restschuld weiter
«Soll ich pushen / weitermachen?» nach klarem Auftrag	Push nur auf Wunsch; Arbeit ohne Rückfrage fortsetzen
User: «warum gestoppt?»	Erklären und weitermachen

Empfohlene User Rule (Cursor)

Bei Arbeit nach ACTIVE.md nicht nach Teilaufgaben stoppen; offene Restschuld im gleichen Auftrag weiterbearbeiten; git push nur wenn ich es sage.

Das aligniert den Agent mit dem Menschen — ergänzt Checkpoint, ersetzt ihn nicht.

Carte blanche (bewusst gegeben)

Agents dürfen kanonische Ops-Pfade nutzen (Regression-Skripte, dokumentierte CLI, Analyse-Tools im scripts/-Baum). Verboten: Ad-hoc-Skripte unter tmp/ als dauerhafte «Auswertung» — sonst findet der nächste Agent zwei widersprüchliche Wahrheiten.

Regression, Deploy und die Illusion vom grünen Einzeltest

Auch ohne Cursor kennst du das: lokal grün, auf dem Server rot — oder umgekehrt. Agents verschärfen das, weil sie schnell committen und schnell ein Skript starten, ohne zu prüfen, welche Instanz antwortet.

Typische Gate-Reihenfolge:

1. Unit — schnelle Tests, ein Modul oder eine Phase
2. Breite Regression — die Suite, die vor «wir sind fertig» Pflicht ist (nicht die kleinste Teilmenge)
3. Deploy — nach App-Änderung: Stack/Container neu bauen, bevor Live-Skripte laufen
4. Smoke — ein bis zwei repräsentative Fälle gegen die deployte Umgebung
5. Full — teurer End-to-End-Lauf (optional, aber klar getrennt)

Live-Skripte treffen oft Container-URLs (z. B. Docker auf localhost mit festem Port), nicht einen vergessenen Prozess von gestern. Wer Code ändert und sofort gegen eine alte Instanz testet, misst altes Verhalten — und interpretiert fälschlich «Fix hat nicht geholfen».

Art Test	Typisch schnell	Typisch teuer
Probe / Schnelltest	Pfade, Logs, Traces	—
Full mit generativem Schritt	—	Inhaltliche Assertions, LLM in der Schleife

Für Pipeline-Arbeit ist die schnelle innere Schleife die richtige; das volle Gate ist die Ausfahrt vor «fertig».

Artefakte gehören in feste Verzeichnisse (tmp/…/runs/, JSON-Reports) — nicht in Chat-Logs als Speicher. Der nächste Agent (oder du in drei Tagen) muss den Pfad wiederfinden.

Fallstudie (anonymisiert): Daten vs. Pipeline

Diese Geschichte ist absichtlich ohne Produktnamen — das Muster kommt in Search-, ETL- und API-Systemen vor.

Symptom: Eine kurze Nutzerfrage liefert gute Treffer. Eine lange, erklärende Frage in anderer Sprache liefert FAIL — «kein verlässlicher Treffer».

Erste Hypothese (falsch): «Die Daten fehlen» → teures Neu-Laden aller Inhalte. Agents schlagen das gern vor, weil es wie Fortschritt aussieht.

Audit (richtig): Stichproben in den gespeicherten Segmenten zeigen: der Inhalt ist da, Wörter und Abschnitte passen. Das Problem liegt in der Pipeline bei der langen Frage — z. B. falsche Query-Umschreibung, zu aggressive Filterung, mehrere Gates hintereinander, die jedes Mal Material verwerfen.

Fix (generisch): Wenn bereits ein Dokument fokussiert ist, den Kandidaten-Pool erweitern; Vertrauensregeln so setzen, dass ein klarer Top-Treffer nicht von einem zu strengen zweiten Gate weggeworfen wird — ohne Testdaten-Wörter im Produktcode zu verankern (sonst bricht Generik für andere Mandanten).

Moral für Leser ohne Backend-Tiefen: Zuerst fragen — liegen die Daten falsch oder verarbeitet das System die Frage falsch? Das spart Nächte. Audit + Trace schlägt Bauchgefühl und schlägt «alles neu indexieren».

Engineering-Disziplin für Agents

Agents produzieren schnell Schulden, wenn man sie nicht einzäunt — nicht aus Bosheit, sondern weil «lokal grün» der einfachste Weg ist.

• Commit-Gate: Diff gegen Prinzipien + Layout; CI mindestens für betroffene Repos; keine TODO-Commits als «fertig».
• Layout-CI: kein Mixed Layout (Dateien und Ordner derselben Rolle vermischt); keine Re-Export-Shims — sonst duplizieren sie Pfade und «fixen» FAILs am falschen Ort.
• Scope pro Session: ein architektonisches Thema; begrenzte Dateianzahl und Diff-Größe (Ausnahme: explizites User-OK).

Das wirkt für kleine Projekte pedantisch. Für Agent-Stunden ist es essentiell — sonst reviewst du am Ende einen Patch-Berg ohne roten Faden.

Cursor-Features, die wir nutzen

Feature	Nutzung	Für Einsteiger
Agent Mode / Composer	Mehrstufige Fixes mit Shell + Repo	Start mit kleiner, klar umrissener Aufgabe
Rules (alwaysApply)	Kontinuität, Deploy, Layout	Eine Rule zuerst
Hooks	Checkpoint + ACTIVE bei Start + preCompact	Optional, nachdem Checkpoint-Manual funktioniert
Skills	Refactor- oder Qualitäts-Skills bei Bedarf	Später
Subagents	Explore für Suche; CI-Investigator für PRs	Wenn Repo groß
Background Terminal	Lange Regression — Ergebnis lesen, weiterarbeiten	Nicht als «fertig» werten, wenn Shell endet
Multi-Root Workspace	Mehrere Repos	Pfade in Rules explizit

Nicht als Spezifikation: Ad-hoc Chat-Zusammenfassungen ohne Checkpoint; Scratch-Skripte; alte Plan-MDs im Archiv.

Checklisten

Neuer Chat / nach Compaction

1. Checkpoint lesen — zuerst next_action
2. ACTIVE → «Nächster Schritt» + neueste Status-Zeile
3. next_action ausführen (ohne «weitermachen?»)
4. Bei Codeänderung: Deploy, dann Live-Probe

Vor Turn-Ende (Agent)

• Nächster Schritt erledigt oder Restschuld benannt
• Checkpoint aktualisiert
• Kein Push ohne User
• FAIL → Triage dokumentiert (Case, Trace, Suite)

Vor «wir sind fertig» (Mensch)

• Volles Pflicht-Gate grün oder begründete Teilmenge + Restschuld im Log
• CI für betroffene Repos grün
• Status-Log-Zeile für diesen Fix

Anti-Patterns (aus echten Sessions)

1. «N−1 von N ist super» — der letzte FAIL ist noch Pflicht-Arbeit.
2. Hintergrund-Shell fertig → Kurzinfo → Stopp — Notification ist kein Done.
3. Daten neu laden, bevor Inhalt geprüft ist — maskiert Pipeline-Bugs.
4. Test-Wörter im Produktcode — bricht Multi-Mandanten-/Generik-Regeln.
5. Parallele Plan-MDs — verwässert ACTIVE; Archiv tot halten.
6. Live-Test ohne Rebuild — falsche Schlüsse, Stunden verloren.
7. Scope aus ACTIVE ignorieren — Whack-a-mole in verbotenen Modulen.

Bezug zu diesem Blog

Im Repository fabricio-technical-journal gilt ein ähnliches Prinzip für Inhalte: Markdown-Entwürfe, Import als WordPress-Entwurf, Preflight und Tests — Veröffentlichen bleibt manuell. Die Agent-Infrastruktur für Code und die für Posts teilen die Idee eine Wahrheit in Dateien, Gates vor «fertig», Mensch am letzten Schritt. Wer den Markdown-Import-Weg sucht, findet dazu einen eigenen Field Note auf diesem Blog.

Ausblick

Was gut funktioniert

• Zwei-Dokument-Handoff (Spezifikation + Checkpoint) + Hooks
• Explizite Stop-Verbote in Rules
• Schnelle innere Regressionsschleife + klares Full-Gate
• Daten-Audit als Poka-Yoke vor teuren Ops
• Phasen mit erlaubten Dateien gegen Scope-Creep

Was noch hart ist

• Subtile FAILs («falsche Stelle im Dokument, aber Quelle da») — brauchen eigene Logik, nicht mehr Unit-Tests allein
• Volles Gate: Laufzeit und Triage-Skalierung
• Agents, die trotz Rules «fertig» signalisieren — braucht Checkpoint + User Rules

Minimal-Set für dein Repo (Woche 1)

1. Eine ACTIVE– oder WORKING.md — eine Wahrheit, Status-Tabelle, nächster Schritt (auch drei Absätze reichen zum Start).
2. Eine SESSION_CHECKPOINT.md — eine Tabelle mit zehn Feldern, auch wenn viele Zeilen «—» sind.
3. Optional Woche 2: sessionStart / preCompact Hook, der (1)+(2) injiziert.
4. Eine alwaysApply-Rule: kein Stop bei offenem next_action.
5. Gate-Reihenfolge in AGENTS.md — auch nur als nummerierte Liste.

Das ist übertragbar auf jedes Long-Horizon-Agent-Projekt — Backend, Plattform oder großes Monorepo. Du musst nicht alles an Tag eins bauen; du musst eine Wahrheit haben, die der Chat nicht ist.

Fazit

Cursor und Coding-Agents sind produktiv, wenn man sie wie Junior-Entwickler mit perfektem Kurzzeitgedächtnis behandelt: klare Spezifikation, Handoff auf Festplatte, Hooks an den richtigen Lebenszyklus-Events, und Kultur («Stoppen ist verboten, bis das Gate oder die Restschuld stimmt»). Die Technik ist einfach; die Disziplin, eine ACTIVE-Datei aktuell zu halten, ist der eigentliche Preis — und billiger als jede Nacht, in der ein Agent gegen einen alten Container testet.

Wenn du aus diesem Artikel nur eine Sache mitnimmst: Schreib auf, was als Nächstes gilt — nicht in den Chat, in eine Datei, die der nächste Chat automatisch liest.