CM – CASS Memory System
Prozedurales Gedächtnis für KI-Coding-Agenten. Verwandelt verstreute Sitzungen in persistentes, agentenübergreifendes Gedächtnis. Nutzt eine dreischichtige kognitive Architektur, die die menschliche Expertise-Entwicklung nachbildet.
Warum es das gibt
KI-Coding-Agenten sammeln wertvolles Wissen, aber es ist:
- In Sitzungen gefangen – Kontext geht verloren, wenn die Sitzung endet
- Agentenspezifisch – Claude weiß nicht, was Cursor gelernt hat
- Unstrukturiert – Rohe Protokolle sind keine handlungsleitenden Anweisungen
- Kollapsgefährdet – Naive Zusammenfassung verliert kritische Details
Sie haben diesen Monat dreimal Auth-Bugs in verschiedenen Agenten gelöst. Jedes Mal von vorne angefangen.
CM löst dies mit agentenübergreifendem Lernen: Ein in Cursor entdecktes Muster steht Claude Code sofort in der nächsten Sitzung zur Verfügung.
Dreischichtige Kognitive Architektur
┌─────────────────────────────────────────────────────────────────────┐
│ EPISODISCHES GEDÄCHTNIS (cass) │
│ Rohe Sitzungsprotokolle aller Agenten – die „Grundwahrheit" │
│ Claude Code │ Codex │ Cursor │ Aider │ PI │ Gemini │ ChatGPT │ ...│
└───────────────────────────┬─────────────────────────────────────────┘
│ cass search
▼
┌─────────────────────────────────────────────────────────────────────┐
│ ARBEITSGEDÄCHTNIS (Diary) │
│ Strukturierte Sitzungszusammenfassungen: Erfolge, Entscheidungen │
└───────────────────────────┬─────────────────────────────────────────┘
│ reflect + kuratieren (automatisiert)
▼
┌─────────────────────────────────────────────────────────────────────┐
│ PROZEDURALES GEDÄCHTNIS (Playbook) │
│ Destillierte Regeln mit Vertrauensverfolgung und -abnahme │
└─────────────────────────────────────────────────────────────────────┘
Die Sitzungen jedes Agenten speisen das gemeinsame Gedächtnis. Ein in Cursor entdecktes Muster hilft automatisch Claude Code in der nächsten Sitzung.
Der Eine Befehl, Den Sie Brauchen
cm context "<Ihre Aufgabe>" --json
Führen Sie dies aus, bevor Sie eine nicht-triviale Aufgabe beginnen. Gibt zurück:
- relevantBullets – Regeln aus dem Playbook, bewertet nach Aufgabenrelevanz
- antiPatterns – Dinge, die Probleme verursacht haben
- historySnippets – Frühere Sitzungen (Ihre und die anderer Agenten)
- suggestedCassQueries – Suchvorschläge für tiefere Untersuchungen
Filtern der Historie nach Quelle
historySnippets[].origin.kind ist "local" oder "remote". Remote-Treffer enthalten origin.host:
{
"historySnippets": [
{
"source_path": "~/.claude/sessions/session-001.jsonl",
"origin": { "kind": "local" }
},
{
"source_path": "/home/user/.codex/sessions/session.jsonl",
"origin": { "kind": "remote", "host": "workstation" }
}
]
}
Vertrauensabnahme-System
Regeln sind nicht unsterblich. Das Vertrauen nimmt ohne erneute Bestätigung ab:
| Mechanismus | Effekt |
|---|---|
| 90-Tage-Halbwertszeit | Vertrauen halbiert sich alle 90 Tage ohne Feedback |
| 4x Schadensmultiplikator | Ein Fehler zählt 4× so viel wie ein Erfolg |
| Reifegrad-Progression | candidate → established → proven |
Visualisierung der Score-Abnahme
Anfangswert: 10,0 (10 hilfreiche Markierungen heute)
Nach 90 Tagen (Halbwertszeit): 5,0
Nach 180 Tagen: 2,5
Nach 270 Tagen: 1,25
Nach 365 Tagen: 0,78
Formel für den Effektiven Score
effectiveScore = decayedHelpful - (4 × decayedHarmful)
// Wobei decay factor = 0.5 ^ (daysSinceFeedback / 90)
Reifegrad-Zustandsautomat
┌──────────┐ ┌─────────────┐ ┌────────┐
│ candidate│──────▶│ established │───▶│ proven │
└──────────┘ └─────────────┘ └────────┘
│ │ │
│ │ (harmful >25%) │
│ ▼ │
│ ┌─────────────┐ │
└────────────▶│ deprecated │◀─────────┘
└─────────────┘
Übergangsregeln:
| Übergang | Kriterien |
|---|---|
candidate → established | 3+ hilfreich, Schadensquote <25% |
established → proven | 10+ hilfreich, Schadensquote <10% |
any → deprecated | Schadensquote >25% ODER explizite Ablehnung |
Anti-Pattern-Lernen
Schlechte Regeln werden nicht einfach gelöscht. Sie werden zu Warnungen:
"Cache-Auth-Tokens für Performance"
↓ (3 schädliche Markierungen)
"FALLE: Cache keine Auth-Tokens ohne Ablauf-Validierung"
Wenn eine Regel mehrfach als schädlich markiert wird (>50% Schadensquote bei 3+ Markierungen), wird sie automatisch in ein Anti-Pattern umgewandelt.
ACE-Pipeline (Wie Regeln Erstellt Werden)
Generator → Reflector → Validator → Curator
| Stufe | Rolle | LLM? |
|---|---|---|
| Generator | Kontextanreicherung vor der Aufgabe (cm context) | Nein |
| Reflector | Muster aus Sitzungen extrahieren (cm reflect) | Ja |
| Validator | Evidenzprüfung gegen cass-Historie | Ja |
| Curator | Deterministischer Delta-Merge | Nein |
Kritisch: Curator hat KEIN LLM, um Kontextkollaps durch iterative Drift zu verhindern. LLMs schlagen Muster vor; deterministische Logik verwaltet sie.
Wissenschaftliche Validierung
Bevor eine Regel in Ihr Playbook aufgenommen wird, wird sie gegen die cass-Historie validiert:
Vorgeschlagene Regel: "Überprüfe vor Auth-Debugging immer den Token-Ablauf"
↓
Evidenzprüfung: Suche cass nach Sitzungen, in denen dies zutraf
↓
Ergebnis: 5 Sitzungen gefunden, 4 erfolgreiche Ergebnisse → ANGENOMMEN
Regeln ohne historische Evidenz werden als Kandidaten markiert, bis sie bewiesen sind.
Befehlsreferenz
Kontextabruf (Haupt-Workflow)
# DER HAUPTBEFEHL - vor nicht-trivialen Aufgaben ausführen
cm context "Benutzerauthentifizierung implementieren" --json
# Ergebnisse für das Token-Budget begrenzen
cm context "Bug beheben" --json --limit 5 --no-history
# Mit Workspace-Filter
cm context "Refactoring" --json --workspace /pfad/zum/projekt
# Selbstdokumentierende Erklärung
cm quickstart --json
# Systemzustand
cm doctor --json
cm doctor --fix # Probleme automatisch beheben
# Ähnliche Regeln finden
cm similar "Fehlerbehandlungs-Best Practices"
Playbook-Verwaltung
cm playbook list # Alle Regeln
cm playbook get b-8f3a2c # Regel-Details
cm playbook add "Führe immer zuerst Tests aus" # Regel hinzufügen
cm playbook add --file rules.json # Batch-Hinzufügen aus Datei
cm playbook add --file rules.json --session /pfad/session.jsonl # Quelle verfolgen
cm playbook remove b-xyz --reason "Veraltet" # Entfernen
cm playbook export > backup.yaml # Exportieren
cm playbook import shared.yaml # Importieren
cm playbook bootstrap react # Starter auf bestehendes anwenden
cm top 10 # Effektivste Regeln
cm stale --days 60 # Regeln ohne aktuelles Feedback
cm why b-8f3a2c # Regel-Herkunft
cm stats --json # Playbook-Zustandsmetriken
Lernen & Feedback
# Manuelles Feedback
cm mark b-8f3a2c --helpful
cm mark b-xyz789 --harmful --reason "Verursachte Regression"
m undo b-xyz789 # Feedback rückgängig machen
# Sitzungsergebnisse (positional: status, rules)
cm outcome success b-8f3a2c,b-def456
cm outcome failure b-x7k9p1 --summary "Auth-Ansatz fehlgeschlagen"
cm outcome-apply # Auf Playbook anwenden
# Reflexion (normalerweise automatisiert)
cm reflect --days 7 --json
cm reflect --session /pfad/zu/session.jsonl # Einzelne Sitzung
cm reflect --workspace /pfad/zum/projekt # Projektspezifisch
# Validierung
cm validate "Überprüfe vor Dereferenzierung immer auf null"
# Sitzungen gegen Regeln prüfen
cm audit --days 30
# Dauerhaft ablegen
cm forget b-xyz789 --reason "Durch besseres Muster ersetzt"
Onboarding (Agenten-Nativ)
Kostenloser Playbook-Aufbau mit Ihrem bestehenden Agenten:
cm onboard status # Fortschritt prüfen
cm onboard gaps # Kategorielücken
cm onboard sample --fill-gaps # Priorisierte Sitzungen
cm onboard sample --agent claude --days 14 # Nach Agent/Zeit filtern
cm onboard sample --workspace /pfad/projekt # Nach Workspace filtern
cm onboard sample --include-processed # Sitzungen erneut analysieren
cm onboard read /pfad/session.jsonl --template # Reichhaltiger Kontext
cm onboard mark-done /pfad/session.jsonl # Als verarbeitet markieren
cm onboard reset # Neu starten
Trauma Guard (Sicherheitssystem)
cm trauma list # Aktive Muster
cm trauma add "DROP TABLE" --description "Massenlöschung" --severity critical
cm trauma heal t-abc --reason "Geplante Migration"
cm trauma remove t-abc
cm trauma scan --days 30 # Nach Traumata scannen
cm trauma import shared-traumas.yaml
cm guard --install # Claude Code Hook
cm guard --git # Git Pre-Commit Hook
cm guard --install --git # Beide
cm guard --status # Installation prüfen
Systembefehle
cm init # Initialisieren
cm init --starter typescript # Mit Vorlage
cm init --force # Neu initialisieren (erstellt Backup)
cm starters # Vorlagen auflisten
cm serve --port 3001 # MCP-Server
cm usage # LLM-Kostenstatistiken
cm privacy status # Datenschutzeinstellungen
cm privacy enable # Agentenübergreifende Anreicherung aktivieren
cm privacy disable # Anreicherung deaktivieren
cm project --format agents.md # Für AGENTS.md exportieren
Starter-Playbooks
Mit einem leeren Playbook zu beginnen, ist entmutigend. Starter bieten kuratierte Best Practices:
cm starters # Verfügbare auflisten
cm init --starter typescript # Mit Starter initialisieren
cm playbook bootstrap react # Auf bestehendes Playbook anwenden
Integrierte Starter
| Starter | Fokus | Regeln |
|---|---|---|
| general | Universelle Best Practices | 5 |
| typescript | TypeScript/Node.js-Muster | 4 |
| react | React/Next.js-Entwicklung | 4 |
| python | Python/FastAPI/Django | 4 |
| node | Node.js/Express-Dienste | 4 |
| rust | Rust-Dienstmuster | 4 |
Benutzerdefinierte Starter
Erstellen Sie YAML-Dateien in ~/.cass-memory/starters/:
# ~/.cass-memory/starters/django.yaml
name: django
beschreibung: Django Web Framework Best Practices
bullets:
- content: "Verwende immer Djangos ORM für Datenbankoperationen"
category: database
maturity: established
tags: [django, orm]
Inline-Feedback (Während der Arbeit)
Hinterlassen Sie Feedback in Code-Kommentaren. Wird während der Reflexion geparst:
// [cass: helpful b-8f3a2c] - Diese Regel hat mich vor einem Kaninchenbau bewahrt
// [cass: harmful b-x7k9p1] - Dieser Ratschlag war falsch für unseren Anwendungsfall
Agentenprotokoll
1. START: cm context "<Aufgabe>" --json
2. ARBEITEN: Regel-IDs referenzieren, wenn Sie sie befolgen (z. B. "Folge b-8f3a2c...")
3. FEEDBACK: Inline-Kommentare hinterlassen, wenn Regeln helfen/schaden
4. ENDE: Einfach beenden. Lernen geschieht automatisch.
Sie MÜSSEN NICHT:
cm reflectausführen (die Automatisierung erledigt das)cm markmanuell ausführen (Inline-Kommentare verwenden)- Manuell Regeln zum Playbook hinzufügen
Lückenanalyse-Kategorien
| Kategorie | Schlüsselwörter |
|---|---|
debugging | error, fix, bug, trace, stack |
testing | test, mock, assert, expect, jest |
architecture | design, pattern, module, abstraction |
workflow | task, CI/CD, deployment |
documentation | comment, README, API doc |
integration | API, HTTP, JSON, endpoint |
collaboration | review, PR, team |
git | branch, merge, commit |
security | auth, token, encrypt, permission |
performance | optimize, cache, profile |
Kategoriestatus-Schwellenwerte:
| Status | Regelanzahl | Priorität |
|---|---|---|
critical | 0 Regeln | Hoch |
underrepresented | 1-2 Regeln | Mittel |
adequate | 3-10 Regeln | Niedrig |
well-covered | 11+ Regeln | Keine |
Trauma Guard: Sicherheitssystem
Das „heiße Ofen"-Prinzip – aus früheren Vorfällen lernen und Wiederholungen verhindern.
Wie es funktioniert
Sitzungshistorie Trauma-Register Laufzeit-Guard
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ rm -rf /* (oops)│ ──────▶ │ Muster: rm -rf │ ──────▶ │ BLOCKIERT: │
│ „Entschuldigung,│ scannen │ Schwere: FATAL │ hook │ Dieser Befehl │
│ ich habe einen │ │ Sitzung: abc123 │ │ entspricht │
│ Fehler gemacht