Docs: lessons.md — Release-Verifikation + Gitea-UNIQUE-Recovery + curl-F-Leerzeichen

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

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 <marker>`
+— 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/<tag>` → id holen → `PATCH releases/<id>`
+mit name/body/draft:false → Assets per `POST releases/<id>/assets?name=<url-encoded>` 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=<url-encoded>` 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,