root 92645521b2 fix(fuenfvoacht): UNIQUE constraint bug + Einplanen für zukünftige Tage

- 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

2026-02-28 22:46:55 +07:00

7.8 KiB

Raw Blame History

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

Dieser Artikel erscheint zusammen mit einem öffentlichen GitHub-Repository: cursor-memory-system — alles was du brauchst um das System nachzubauen.

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:

## 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:

# 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:

# 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

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:

Repo klonen oder Template kopieren
.cursorrules in deinen Workspace-Root
Routing-Tabelle auf deine Projekte anpassen
Eine STATE.md für dein erstes Projekt anlegen
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
→ Nächster Artikel: ESP32-Heizungsprojekt Teil 2 — Die Hardware

Grafik-Ideen für diesen Artikel

Animiertes Flussdiagramm: Infrastruktur → homelab-brain → KI — mit leuchtenden Datenpfeilen (SVG, wie Fließschaltbild)
Kontextfenster-Vergleich: Balkendiagramm "ohne System" (voll, rot) vs. "mit Routing" (schlank, grün)
Screenshot: Cursor öffnet sich, KI antwortet sofort mit korrekten IPs/Befehlen ohne Nachfragen
Repo-Struktur: Dateibaum als schöne Grafik (dark theme)

7.8 KiB Raw Blame History