diff --git a/tasks/lessons.md b/tasks/lessons.md index 25a2a31..0e9758b 100644 --- a/tasks/lessons.md +++ b/tasks/lessons.md @@ -1,5 +1,30 @@ # Lessons +## 2026-05-30 — Release verifizieren BEVOR "fertig" gesagt wird; curl -F mit Leerzeichen im Pfad + +**Muster A (Edit ins Leere + trotzdem released):** Ein Edit schlug fehl ("String not +found"), ich habe es übersehen, committet und v1.7.165 released — die Datei enthielt +das Feature NICHT. Erst der nächste Blick zeigte es. +**Regel:** Nach jedem Feature-Edit VOR dem Release `git show HEAD:datei | grep ` +— bestätigen dass der Code wirklich im Release-Commit ist, nicht nur dass `git commit` +durchlief. + +**Muster B (Gitea UNIQUE constraint):** `npm run release:gitea` pusht erst den Tag, +dann erstellt es den Release. Gitea legt beim Tag-Push automatisch einen Tag-Release- +Eintrag an (name=null). `fetchExistingRelease` im Script matcht den nicht → POST create +→ `UNIQUE constraint failed: release.repo_id, release.tag_name`. Commit + Tag sind dann +schon gepusht, nur der Release+Assets fehlen. +**Recovery:** `GET /api/v1/repos/.../releases/tags/` → id holen → `PATCH releases/` +mit name/body/draft:false → Assets per `POST releases//assets?name=` hochladen. + +**Muster C (curl -F Datei mit Leerzeichen):** `curl -F "attachment=@release/Datei mit +Leerzeichen.exe.blockmap"` lädt FALSCHEN Inhalt hoch (Server-Size != lokale Size). +**Regel:** Datei mit Leerzeichen im Namen erst nach `/tmp/leerzeichenfrei` kopieren, +DAS hochladen, Asset-Name über `?name=` setzen. Danach Server-Size gegen +lokale Size prüfen. + + + ## 2026-05-30 — Nicht in chaotische Parallel-Tool-Batches verfallen (User-Korrektur: "bist du in nem endless loop") **Muster:** Bei einem großen Multi-File-Edit habe ich Dutzende Tool-Calls (Bash-Probes,