Hitonabi
1eb1c91dd8
Ampel / ampel (push) Successful in 28s
Fuenf Vorgaben, was daraus wurde:
Codebase sauber -> vier tote Routen + zwei Module weg (main.py 1726 -> 1682
Zeilen), Tests halten sie draussen
UI schnell -> /capabilities 1,010 s -> 0,003 s; Dashboard-Aufbau
1,03 s -> 0,028 s. Alle 15 Ladeendpunkte unter 10 ms
UI selbsterklaerend -> Wizard-Kasten "Was Rippy gerade sieht" mit
Handlungsanweisung je Problem, sichtbare Keys mit Pruefung
Idiotensicher -> Wizard empfiehlt nach GEMESSENER CPU statt H.265 blind;
4K-Falle ist damit zu
Externe Worker -> auf Windows gegengeprueft (Kerne/Modell korrekt, encoders
ohne HandBrake korrekt leer, SIMD ehrlich "unbekannt")
Dazu die offene 4K-Frage aus v3.14 beantwortet: Kompression ist je Disc-Typ
abwaehlbar, 4K kann verlustfrei bleiben waehrend DVD/Blu-ray weiter schrumpfen.
ARM-Vergleich drin: fast alles, was ARM automatisch macht, macht Rippy schon -
und meist gruendlicher. Zwei echte Luecken benannt und NICHT gebaut
(ISO-Sicherung fuer Datentraeger, mehrere Laufwerke gleichzeitig), weil das
Funktionen sind und keine Reparatur. Ehrlich dabei: ob Rippy parallel rippen
kann, ist unbewiesen - mit einem Laufwerk nicht testbar.
Offene Punkte stehen unter "NOCH OFFEN", darunter der VM-CPU-Typ (qemu64 statt
host - AVX2 waere ein VM-Neustart und 2-4x schneller).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
90 lines
4.7 KiB
Markdown
90 lines
4.7 KiB
Markdown
# 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
|
|
|
|
1. **Read:** KONZEPT.md + ROADMAP.md lesen. Verstehen, welche Etappe dran ist.
|
|
2. **Plan:** Was genau soll diese Sitzung bauen? Eine Zeile.
|
|
3. **Build:** Code schreiben, testen, committen.
|
|
4. **Verify:** `docker compose up` — funktioniert das Ganze?
|
|
5. **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 (25.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
|
|
- ✅ **Etappe 17 (v3.10):** 4K-UHD-Disc-Schlüssel — persistentes
|
|
MakeMKV-Datenverzeichnis + `KEYDB.cfg` im UI
|
|
- ✅ **Etappe 18 (v3.11):** 4K-UHD gelöst — `makemkvcon` holt Schlüssel
|
|
unter Linux nie, unter Windows schon; Schlüsselspeicher übernehmbar.
|
|
Akira-UHD geht auf der VM auf (`TCOUNT:5`, bewiesen)
|
|
- ✅ **Etappe 19 (v3.14):** Durchsicht Frontend/Backend — vier Placebos weg
|
|
(Fortschritt log, Auswurf tat nichts, „Alle Tracks" konnte nichts, Encoder
|
|
wurden behauptet statt gemessen), Zombie-Erkennung gebaut, Pfad-Prüfung
|
|
gehärtet, und der Platten-Schutz aus `c065967` als **unwirksam** entlarvt
|
|
- ✅ **Etappe 20 (v3.15):** Aufräum-Runde — `/capabilities` 1,010 s → 0,003 s
|
|
(Ping im Hintergrund), Kompression je Disc-Typ abwählbar (4K verlustfrei),
|
|
Wizard empfiehlt nach gemessener CPU, vier tote Routen entfernt
|
|
- 📝 **Details immer in SAVEPOINT.md** — diese Sektion nennt nur die Etappe
|
|
|
|
## Was diese Sitzungen wiederholt gekostet hat
|
|
|
|
**Nicht aus einem Zustandswert auf einen Mechanismus schließen.** Vorgefallen:
|
|
aus „kein Schlüssel da" → „Server abgeschaltet" (falsch), aus Status
|
|
`transcoding` → „Celery hat neu zugestellt" (falsch), aus `progress=99` →
|
|
„Altwert aus dem Absturz" (falsch — ein Bug), aus gleichem `st_dev` →
|
|
„`os.rename` funktioniert" (falsch — der Kernel vergleicht den Mount).
|
|
Jedes Mal hätte eine Messung von unter einer Minute gereicht.
|
|
|
|
**Und die Umkehrung gilt genauso:** gleiches `st_dev` heißt NICHT gleicher
|
|
Mount. Wo eine Eigenschaft ausprobierbar ist, probiere sie aus, statt sie
|
|
vorherzusagen.
|