From 2448ae5c7a63a1e1f14cf6cd3771ac6b22c574a6 Mon Sep 17 00:00:00 2001 From: Sucukdeluxe Date: Sat, 30 May 2026 22:54:50 +0200 Subject: [PATCH] =?UTF-8?q?Docs:=20lessons.md=20=E2=80=94=20Release-Verifi?= =?UTF-8?q?kation=20+=20Gitea-UNIQUE-Recovery=20+=20curl-F-Leerzeichen?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 --- tasks/lessons.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) 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,