92645521b2
- DB-Migration: UNIQUE(date) → UNIQUE(date, post_time) — alte DBs werden automatisch beim Start migriert (database.py init_db) - api_save: gibt article_id zurück für nachgelagerte Operationen - confirmPlan(): speichert auf selectedDate, verschiebt dann ggf. per reschedule auf Zieldatum — fixes "Kein Artikel für diesen Tag vorhanden" - Alle Source-Dateien (app.py, database.py, templates, ...) hinzugefügt - arakava-news: cursor-memory-system Artikel + SVG-Diagramm hinzugefügt Made-with: Cursor
201 lines
7.8 KiB
Markdown
201 lines
7.8 KiB
Markdown
# Wie ich meiner KI ein Gedächtnis gebaut habe — und warum das alles verändert
|
|
|
|
**Kategorie:** Technik / KI / Homelab
|
|
**Tags:** Cursor, Claude, AI Memory, Homelab, Git, Automatisierung, Prompt Engineering
|
|
**Lesezeit:** ca. 8 Minuten
|
|
|
|
---
|
|
|
|
<p><strong>Dieser Artikel erscheint zusammen mit einem öffentlichen GitHub-Repository: <a href="https://github.com/Orbitalo/cursor-memory-system">cursor-memory-system</a> — alles was du brauchst um das System nachzubauen.</strong></p>
|
|
|
|
---
|
|
|
|
## Das Problem: Die KI weiß nach jedem Gespräch nichts mehr
|
|
|
|
Ich nutze Cursor mit Claude täglich für mein Homelab. Server einrichten, Code schreiben, Automatisierungen bauen. Das funktioniert gut — bis die Session endet.
|
|
|
|
Beim nächsten Tag fängt die KI wieder bei null an. Ich erkläre zum dritten Mal welche Container laufen, welche IP mein WordPress hat, was das Projekt eigentlich soll. Wertvolle Minuten, manchmal eine halbe Stunde, nur um den Kontext wiederherzustellen.
|
|
|
|
**Das ist kein Bug. Das ist wie diese KI-Systeme funktionieren.** Jedes Gespräch ist eine leere Seite.
|
|
|
|
Ich wollte das ändern.
|
|
|
|
---
|
|
|
|
## Die Idee: Ein Git-Repository als Gehirn
|
|
|
|
Die Lösung kam aus einer simplen Beobachtung: Die KI kann Dateien lesen. Also gebe ich ihr die richtigen Dateien — mit allem was sie über mein System wissen muss.
|
|
|
|
Kein Plugin. Kein teurer API-Wrapper. Nur ein Git-Repository mit Markdown-Dateien.
|
|
|
|
Ich nenne es **homelab-brain**.
|
|
|
|
*[Grafik: Animiertes Flussdiagramm — Live-Infrastruktur links, homelab-brain Repo mitte, Cursor/KI rechts, Datenpfeile fließen von links nach rechts]*
|
|
|
|
---
|
|
|
|
## Wie es funktioniert
|
|
|
|
### 1. Die Routing-Tabelle
|
|
|
|
Die wichtigste Datei ist `.cursorrules` im Workspace-Root. Sie ist die **Telefonzentrale** des Systems:
|
|
|
|
```markdown
|
|
## Routing-Tabelle
|
|
| Aufgabe betrifft... | Lade diese Datei |
|
|
|-----------------------------|-------------------------------|
|
|
| WordPress / RSS | arakava-news/STATE.md |
|
|
| KI-Redakteur | redax-wp/STATE.md |
|
|
| Smart Home / ioBroker | smart-home/STATE.md |
|
|
| ESP32 / Display / Heizung | esp32/PLAN.md |
|
|
| Server / Container / Proxmox| infrastructure/STATE.md |
|
|
```
|
|
|
|
Wenn ich eine neue Cursor-Session öffne und sage "richte mir einen neuen Container ein", liest die KI zuerst `.cursorrules` und weiß: *Infrastruktur → lade `infrastructure/STATE.md`*. Nur diese eine Datei. Das Kontextfenster bleibt sauber.
|
|
|
|
### 2. Die STATE.md Dateien
|
|
|
|
Für jedes Projekt gibt es eine `STATE.md`. Sie enthält alles was die KI wissen muss:
|
|
|
|
```markdown
|
|
# STATE: Redax-WP
|
|
**Stand: 28.02.2026**
|
|
|
|
## Zugang
|
|
| Was | URL |
|
|
|-----|-----|
|
|
| Dashboard | https://redax.orbitalo.net |
|
|
| Login | admin / astral66 |
|
|
|
|
## Stack
|
|
redax-web Flask Dashboard (:8080)
|
|
redax-wordpress WordPress intern (:80)
|
|
redax-db MySQL 8
|
|
|
|
## Letzter Stand
|
|
- Multi-Publish zu 2 WordPress-Instanzen aktiv
|
|
- Drag & Drop im Redaktionsplan
|
|
- ESP32-Serie Teil 2 als Entwurf (Post 1340)
|
|
```
|
|
|
|
IPs, Passwörter, Container-Nummern, letzter Entwicklungsstand — alles drin. Die KI fragt nicht nach.
|
|
|
|
### 3. Das Auto-Sync-Script
|
|
|
|
Das Geniale: Die STATE.md-Dateien für laufende Services werden **automatisch aktualisiert**. Ein Cron-Job auf dem Server läuft alle 15 Minuten:
|
|
|
|
```bash
|
|
# Läuft auf pve-hetzner, alle 15 Min
|
|
*/15 * * * * /opt/homelab-brain/scripts/sync-state.sh
|
|
```
|
|
|
|
Das Script fragt live die Container ab — ist der RSS-Manager aktiv? Wie viel OpenRouter-Guthaben ist noch da? Wie voll ist die Festplatte? — und schreibt die Ergebnisse in die STATE.md. Dann committed und pushed es auf Forgejo (mein internes Git).
|
|
|
|
*[Screenshot: STATE.md mit Live-Daten — Timestamp, Service-Status grün, OpenRouter-Guthaben]*
|
|
|
|
Wenn ich morgens Cursor öffne, hat die KI den **Stand von heute Nacht** — nicht von vor drei Wochen.
|
|
|
|
---
|
|
|
|
## Was sich verändert hat
|
|
|
|
**Vorher:**
|
|
> Ich: "Richte mir auf CT 113 den Redakteur ein."
|
|
> KI: "Was ist CT 113? Auf welchem Server? Welches OS? Was soll der Redakteur tun?"
|
|
|
|
**Nachher:**
|
|
> Ich: "Richte mir auf CT 113 den Redakteur ein."
|
|
> KI: *liest infrastructure/STATE.md* → weiß: CT 113 ist auf pve-hetzner, Debian 12, IP 10.10.10.113, Docker läuft, Tailscale aktiv. Schreibt direkt den Deployment-Befehl.
|
|
|
|
Der Unterschied ist nicht nur Zeit. Es ist **Qualität**. Die KI macht keine Annahmen mehr über meine Infrastruktur — sie kennt sie.
|
|
|
|
---
|
|
|
|
## Das Ergebnis in Zahlen
|
|
|
|
Ich betreibe damit:
|
|
- **7 aktive Projekte** (WordPress-Blog, KI-Redakteur, Edelmetall-Bot, Flugpreisscanner, Smart-Home, ESP32-Heizung, FünfVorAcht-Telegram-Bot)
|
|
- **12 Container** auf 2 Proxmox-Servern
|
|
- **Auto-Sync alle 15 Minuten** für 4 Live-Services
|
|
|
|
Und ich muss der KI **nie wieder erklären** was mein System ist.
|
|
|
|
---
|
|
|
|
## Der Trick mit dem Kontextfenster
|
|
|
|
Ein häufiger Fehler: alles in eine riesige Datei packen und immer komplett laden. Das funktioniert nicht — Kontextfenster sind begrenzt, und je mehr irrelevanter Kontext drin ist, desto schlechter werden die Antworten.
|
|
|
|
Meine Lösung: **Routing + Lazy Loading**.
|
|
|
|
```
|
|
.cursorrules ← wird IMMER geladen (klein, ~30 Zeilen)
|
|
└── Routing-Tabelle
|
|
├── Aufgabe A → lade STATE-A.md
|
|
├── Aufgabe B → lade STATE-B.md
|
|
└── Aufgabe C → lade STATE-C.md
|
|
```
|
|
|
|
Die KI lädt nur was gerade relevant ist. Bei 7 Projekten mit je 100-200 Zeilen STATE.md würde alles auf einmal ~1500 Zeilen Kontext fressen. Mit Routing sind es ~30 Zeilen Basis + ~150 Zeilen pro Session.
|
|
|
|
*[Grafik: Vergleich Kontextfenster — ohne Routing (voll, rot) vs. mit Routing (schmal, grün)]*
|
|
|
|
---
|
|
|
|
## Wie du es nachbaust
|
|
|
|
Ich habe das komplette System als Template auf GitHub veröffentlicht:
|
|
|
|
**→ [github.com/Orbitalo/cursor-memory-system](https://github.com/Orbitalo/cursor-memory-system)**
|
|
|
|
Das Repository enthält:
|
|
- `.cursorrules` Vorlage mit Routing-Tabelle
|
|
- `STATE-template.md` zum Anpassen
|
|
- `sync-state.sh` Auto-Sync-Script (für Linux-Server)
|
|
- `SETUP.md` — Schritt-für-Schritt Anleitung
|
|
|
|
**Minimale Version in 10 Minuten:**
|
|
|
|
1. Repo klonen oder Template kopieren
|
|
2. `.cursorrules` in deinen Workspace-Root
|
|
3. Routing-Tabelle auf deine Projekte anpassen
|
|
4. Eine `STATE.md` für dein erstes Projekt anlegen
|
|
5. Cursor neu starten
|
|
|
|
Das Auto-Sync ist optional — auch eine manuell gepflegte STATE.md ist 10x besser als keine.
|
|
|
|
---
|
|
|
|
## Was kommt als nächstes
|
|
|
|
Das System wächst mit dem Homelab. Geplant:
|
|
|
|
- **ESP32-Integration**: Sobald die Heizungssteuerung läuft, werden Echtzeit-Temperaturen direkt in `smart-home/STATE.md` geschrieben — die KI sieht live ob der Pufferspeicher warm genug ist
|
|
- **Alert-System**: Wenn ein Service ausfällt, schreibt der Watchdog ein `⚠️ ALERT` in die STATE.md — die KI sieht es beim nächsten Öffnen sofort
|
|
- **Mehrsprachig**: README und Templates auf Englisch für die internationale Community
|
|
|
|
---
|
|
|
|
## Fazit
|
|
|
|
Das Konzept ist simpel bis zur Peinlichkeit: **Gib der KI die richtigen Dateien, und sie wird klüger.**
|
|
|
|
Kein Plugin, kein Abo, keine schwarze Magie. Ein Git-Repository, ein paar Markdown-Dateien, optional ein Cron-Job. Das war's.
|
|
|
|
Die KI hat kein schlechtes Gedächtnis. Sie hat nur kein Gedächtnis bekommen.
|
|
|
|
---
|
|
|
|
*Dieser Artikel beschreibt mein persönliches Homelab-Setup. Das GitHub-Repository ist ein Template — anpassen erwünscht.*
|
|
|
|
*→ GitHub: [cursor-memory-system](https://github.com/Orbitalo/cursor-memory-system)*
|
|
*→ Nächster Artikel: [ESP32-Heizungsprojekt Teil 2 — Die Hardware](/...)*
|
|
|
|
---
|
|
|
|
### Grafik-Ideen für diesen Artikel
|
|
|
|
1. **Animiertes Flussdiagramm**: Infrastruktur → homelab-brain → KI — mit leuchtenden Datenpfeilen (SVG, wie Fließschaltbild)
|
|
2. **Kontextfenster-Vergleich**: Balkendiagramm "ohne System" (voll, rot) vs. "mit Routing" (schlank, grün)
|
|
3. **Screenshot**: Cursor öffnet sich, KI antwortet sofort mit korrekten IPs/Befehlen ohne Nachfragen
|
|
4. **Repo-Struktur**: Dateibaum als schöne Grafik (dark theme)
|