Hitonabi/rippy

Fork 0

Files

T

Hitonabi 57bda55af4

CI / ui (push) Failing after 13m34s

Details

CI / api-und-worker (push) Failing after 14m28s

Details

Harte Regeln (Ampel-Pflicht, Spec-Stopp, deploy.sh-only, keine

erfundenen APIs) + idempotentes deploy.sh

Lehren aus dem Review 22.07.: stille MakeMKV->HandBrake-Abweichung,
Doppel-Anlage auf der VM, halluzinierte Celery/abcde-Schnittstellen.

2026-07-22 18:59:53 +02:00

2.8 KiB

Raw Blame History

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. Deployment NUR über ./deploy.sh. Idempotent, EIN fester Compose-Projektname (rippy), EIN Pfad (~/projects/rippy). Nie freihändig per SSH auf der VM bauen. (Vorgefallen: Doppel-Anlage Rippy + rippy auf der arcane-VM.)

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 (21.07.2026)

✅ Etappe 8 abgeschlossen: Dark Mode mit Theme-Toggle, React-UI mit TailwindCSS
✅ Git Sync: Arcane VM (192.168.178.162) mit Git Repository konfiguriert
✅ Savepoint v1.8: Separation of Concerns geplant, Dark Mode implementiert
📝 Nächste Etappe: SoC-Refactoring (Theme-Context auslagern)

2.8 KiB Raw Blame History