Hitonabi
b8162753a9
Commander-Entscheid 24.07.: nur noch EIN Branch. Der stable-Zwischenbranch war vestigial — die VM deployt ohnehin aus main (git pull), das Gruen-Gate hat den Live-Deploy nie real gegated. - ci.yml: Beförderungs-Schritt (push -> stable) entfernt; die Ampel prueft nur noch (Ruff/pytest/Vite-Build), Rot heisst weiterhin: nicht deployen. - deploy.sh: klont/resettet auf main statt stable. - AGENTS §C, README (Entwicklung), DESIGN-2.0-Briefing: auf main-only umgeschrieben. Design-2.0-Briefing als ERLEDIGT markiert. - SAVEPOINT v3.6. Branches stable / design-2.0 / kernumbau-2026-07-23 werden nach diesem Push geloescht (Inhalte vollstaendig in main). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
3.2 KiB
AGENTS.md — Arbeits-Konventionen für Rippy
Grundregeln
1. Plan vor Code. Vor jeder Etappe: Klare Akzeptanzkriterien schreiben, dann bauen. 2. Kleine Schritte. Max. eine Feature pro Commit. Commit-Nachrichten beschreiben WAS und WARUM. 3. Beweisen statt behaupten. Testen, was gebaut wurde. Keine "es sollte funktionieren"-Commits. 4. Deutsch-Nicht-Entwickler. Der Commander liest alles — Variablennamen auf Englisch, aber Kommentare und Docs auf Deutsch.
⛔ HARTE Regeln (mechanisch geprüft — seit 22.07.2026)
A. Die CI-Ampel muss GRÜN sein, bevor irgendetwas „fertig" heißt.
.gitea/workflows/ci.yml läuft bei jedem Push auf dem Gitea-Runner (NICHT löschen, NICHT
abschwächen). Keine Tests = rot = nicht fertig. Der Commander liest die Ampel, nicht den Code.
B. Abweichung vom KONZEPT = STOPP + fragen. Anderes Werkzeug, andere Bibliothek, gestrichenes Muss-Feature → erst den Commander fragen, NIE still ersetzen. (Vorgefallen: Muss-Feature „MakeMKV lossless" wurde still durch lossy HandBrake ersetzt.)
C. Single Source of Truth ist main — es gibt nur diesen einen Branch
(seit 24.07.2026; der stable-Zwischenbranch ist abgeschafft). Die CI-Ampel
läuft bei jedem Push und PRÜFT nur (Ruff/pytest/Vite-Build) — sie befördert
nichts mehr. Deployt wird direkt aus main: auf der VM git pull bzw.
./deploy.sh (verifiziere vorher, dass die Ampel für den Commit GRÜN ist —
rot heißt: nicht deployen). Nie freihändig per SSH auf der VM bauen.
(Vorgefallen: Doppel-Anlage Rippy + rippy auf der VM durch Freihand-Deploys.)
D. Externe Schnittstellen NIE aus dem Kopf. Vor Nutzung fremder CLI-Flags oder
Bibliotheks-APIs: --help/Doku prüfen und die Fundstelle im Commit nennen.
(Vorgefallen: erfundene Celery-Methode self.send_task, erfundene abcde-Flags.)
Workflow
- Read: KONZEPT.md + ROADMAP.md lesen. Verstehen, welche Etappe dran ist.
- Plan: Was genau soll diese Sitzung bauen? Eine Zeile.
- Build: Code schreiben, testen, committen.
- Verify:
docker compose up— funktioniert das Ganze? - Savepoint: SAVEPOINT.md aktualisieren. Nächster Chat beginnt nicht von Null.
Modelle je Aufgabe
- Planung: Heavy-Modell (Reasoning) für Architektur-Entscheidungen.
- Bauen: schnelles Coding-Modell.
- Review: Heavy nochmal für Code-Review vor Merge.
Docker-Praxis
- Alles läuft in Containern:
docker compose up -d - Keine System-Pakete auf dem Host — alles im Container.
- Dockerfile immer multi-stage, kleinste Images.
Was NICHT gebaut wird
- Kein Code direkt im Host-OS.
- Kein Proxmox-LXC-Nesting-Workaround — das Projekt lebt bewusst in normalem Docker.
- Kein ARM-Fork — Rippy ist ein Eigenbau von Grund auf.
Aktueller Stand (24.07.2026)
- ✅ E2E bewiesen (v3.1): BD-50 komplett durch die Kette (43 GB → 4,8 GB)
- ✅ Etappe 13 (v3.2): Universal-Komfort-Runde — Media-Server-Integration, echte Benachrichtigungen, SMB-Klartext-Fehler, UHD-Arbeitsverzeichnis, MakeMKV-Key via UI, Job-Detail-Popup, Toast-Feedback, Ampel-Blocker behoben
- 📝 Details immer in SAVEPOINT.md — diese Sektion nennt nur die Etappe