Die neuen Modelle arbeiten deine komplette Roadmap stundenlang, sogar tagelang ab, ohne den Faden zu verlieren. Genau deshalb wiegt Zustandsabweichung schwerer, nicht leichter: Je mehr ein Agent zwischen deinen Checkpoints erledigt, desto eher hört sein protokollierter Zustand still und leise auf, mit git übereinzustimmen. casp check ist das deterministische Gate, das den Push blockiert, sobald das passiert — heute mit Claude Code, und mit jedem Modell, das als Nächstes kommt.
Du kommst nach einer Woche zu einem Projekt zurück — oder jonglierst fünf gleichzeitig. Der Agent liest eine Zustandsdatei, die nicht mehr der Realität entspricht, beginnt selbstbewusst Arbeit, die längst ausgeliefert ist, und du verbrennst einen Nachmittag damit, das wieder rückgängig zu machen.
Boards, Karten und Tabellen retten dich nicht: Den Kontext zu rekonstruieren ist Handarbeit, und der Agent kann nichts davon lesen. Der Zustand muss maschinenlesbar sein, git-nativ — und nachweislich wahr.
CASP gibt jedem Projekt einen Faden, der über Sitzungen hinweg fortbesteht — und nicht still abweichen kann.{
"phase": "13 — camera streaming",
"next_prompt": "phases/14-camera.md",
// shipped in v13.4
"last_commit": "a1f3c9",
// not in git history
"migrations": ["0001"…"0007"],
// git stops at 0006
}
Der angrenzende Bereich — Mem0, Letta, Zep, die neuen git-nativen „memory“-Projekte — alle speichern, was passiert ist. Fast keines prüft, ob der gespeicherte Zustand noch der git-Realität entspricht. Diese Prüfung ist casp check — und sie ist vor jedem Push verpflichtend.
Dein next_prompt zeigt auf eine Datei, die bereits ausgeliefert ist — oder nicht existiert. CASP weigert sich, die falsche Sitzung zu starten.
last_commit nicht in der Historie, Migrationsliste nicht synchron, nicht committeter Zustand — geprüft gegen git selbst, nicht geraten.
Keine unscharfen Ähnlichkeitswerte. Ein hartes, wiederholbares Bestanden/Durchgefallen-Gate, das den Push stoppt, solange der Zustand lügt.
CASP ersetzt nichts in deinem Workflow. Es füllt die eine Lücke, die nichts anderes abdeckt — die validierte Gegenwart eines Projekts, in einer Form, die dein Agent lesen und auf die er handeln kann.
Keine Datenbank. Kein Service. Kein Vektorspeicher. Drei einfache Dateien, die ein Agent in der ersten Zeile jeder Sitzung lesen kann.
Maschinenlesbar, pro Projekt: aktuelle Phase, nächste Phase, der exakte auszuführende next-prompt, ausgelieferte Phasen, angewandte Migrationen, letzter Commit, letzte Session-ID.
Das „wo stehe ich gerade“ auf einem Bildschirm. Öffne es, hol dir den Faden in fünf Sekunden zurück — keine Archäologie.
Die Next-3 zum Ausliefern plus eine Phasen-Anzeigetafel. Der Agent kennt immer die Reihenfolge der Arbeit.
session-prompt-, session-log- und audit-brief-Templates sorgen dafür, dass jede Sitzung — Mensch oder Agent — gleich geformte Artefakte erzeugt. Struktur wird erzwungen, nicht vorgeschlagen.Ein echtes Produkt ist nicht ein Feature. Es sind Dutzende Phasen über API, Web-Client und Mobile, über Wochen ausgeliefert von rotierenden Sitzungen und Agenten. CASP hält eine einzige validierte Reihenfolge über das Ganze — sodass jeder Agent weiß, welche Phase als Nächstes kommt, und nie eine ausgelieferte erneut ausliefert.
Und die Schleife schließt sich selbst: Am Ende jeder Sitzung schreibt der Agent den Prompt der nächsten Sitzung für dich — du feilst an einer Zeile, du verfasst nicht von Grund auf — hängt ein Sitzungsprotokoll an und aktualisiert den Zustand. Öffne die nächste Sitzung, und sie macht genau dort weiter, wo die letzte aufgehört hat. Die Roadmap führt sich aus; du überwachst.
Jede Zahl unten wird direkt aus der state.json jedes Projekts gelesen — dieselbe Datei, die der Agent liest, beim letzten Push gegen git validiert. Keine Marketing-Rechnerei.
Ein kundenseitiges Flottenmanagement-ERP für ein Transportunternehmen in der Côte d'Ivoire — Web + Mobile, multi-modul, multi-rolle: Fahrer, Fahrzeuge, Compliance, Kasse, Werkstatt, Rechtsstreitigkeiten, Buchhaltung.
Jedes Modul ist eine validierte Phase. Der Agent liest das Cockpit, führt die nächste Phase aus next_prompt aus und hat nie ein ausgeliefertes Modul erneut ausgeliefert — selbst an einem Tag mit sechs Sitzungen.
Die interne Ops- & Launch-Orchestrierungsplattform für ZeroSuite — eine mehrmonatige Roadmap, bearbeitet von einem echten Team, mit Launch-Modus-Gating und einem verfolgten Post-Launch-Backlog.
Ein validierter Faden über 40+ Phasen und drei Personen — plus 58 Elemente, explizit auf nach dem Launch verschoben, keines davon verloren. Das ist der „große Mehrbenutzer-Projekt“-Fall, für den CASP gebaut wurde.
Dasselbe Protokoll, zwei sehr unterschiedliche Produkte. Das Cockpit ist das Einzige, was sie teilen.
Gedächtnis-Tools merken sich, wer du bist. CASP verfolgt, wo dein Projekt steht — und beweist es. Anderes Artefakt, andere Operation, anderes Versagen, das es verhindert.
Eine Silbe, keine Homographen, dieselben in Englisch, Französisch oder Spanisch.
state.next_prompt.CASP liefert Claude-Code-Slash-Befehle, sodass der Zustand dort lebt, wo du bereits arbeitest.
Nur-Lese-Status — der Agent liest den aktuellen Faden, bevor er eine einzige Zeile schreibt.
Startet die nächste Sitzung automatisch direkt aus state.next_prompt. Kein Copy-Paste, kein Raten.
Funktioniert mit Claude Code · Cursor · Aider · Continue — allem, was Dateien liest.
Ein Agent, der das Falsche tut, kostet einen Nachmittag. Hundert Agenten, die es über hundert Repos tun, kosten ein Quartal. CASP ist die deterministische Leitplanke, die du in die Automatisierungsschleife einsetzt — dieselbe Form in jedem Projekt.
casp check sitzt im selben Slot wie Lint und Tests. Ein Zustand, der lügt, kann nicht gemerged werden — Drift wird auf Org-Ebene blockiert, nicht der Disziplin Einzelner überlassen.
Autonome Agenten vervielfachen Fehler. CASP gibt jedem von ihnen denselben validierten Faden zum Lesen und dasselbe harte Gate, bevor er pusht. Automatisierung ohne die Doppelarbeitssteuer.
Jeder Zustandsübergang ist ein git-Commit. Eine vollständige, diff-bare, rücksetzbare Aufzeichnung, wie jedes Projekt sich bewegt hat — git log ist dein Compliance-Trail.
Rein lokal, keine Telemetrie, keine Cloud, kein Account. Nichts zu prüfen, nichts zu exfiltrieren. Der Security-Review ist eine Zeile: Es verlässt nie die Maschine.
jobs: state-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: { fetch-depth: 0 } # casp checks against full git history - run: npx @justethales/casp check # ✗ fails the build the moment state drifts
Ein Protokoll, jedes Repo. Dieselbe validierte Form, org-weit.
Ein Protokoll verdient sich Adoption dadurch, dass es vorhersehbar ist. Diese geben nicht nach.
CASP prüft, was dein Repo ist, nie, was du vorhattest. Fakten gegen git, jedes Mal.
Kanonische Artefakte werden erzwungen, nicht vorgeschlagen. Jede Sitzung kommt in derselben Form heraus.
Der Validator ist nicht optional. Ein lügender Zustand erreicht nie dein Remote.
Deterministisch, git-nativ, rein lokal. Keine Telemetrie. Keine Cloud, kein Account, keine Rechnung.
Installieren, init, und dein Agent liest die Wahrheit in seiner ersten Zeile.
$ npm i -g @justethales/casp $ casp init # scaffold the layer $ casp status # where am I right now $ casp check # prove the state is true