fix: release.yml sends its payload from a file and refuses notes over 60000 bytes; 8.0.0 entry condensed (#183)

The 8.0.0 release job failed with "curl: Argument list too long": the
payload was one argument over Linux's 128 KiB limit, and Gitea on MySQL
stores at most 65535 bytes of release note anyway. The payload now goes
through --data-binary @file, the notes step refuses over 60000 bytes
before anything is built or tagged, and workflow_dispatch lets a failed
release be retried on main. The CHANGES.md entry for 8.0.0 drops from
129 KB to 22 KB: one paragraph per larger change, the rest stays as a
bullet in the bump list. DEVELOPMENT.md step 6 names the limit and the
retry path.

Files changed:
- .gitea/workflows/release.yml
- CHANGES.md
- DEVELOPMENT.md

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

.gitea/workflows/release.yml

@@ -25,6 +25,11 @@ on:
     branches: [main]
     paths:
       - VERSION
+  # A release whose job failed after VERSION had already moved cannot be
+  # retried by a push - the version is not raised again - and a re-run uses the
+  # workflow file of the failed commit. Dispatching on main runs the current
+  # file; the "already exists" check below still refuses a second release.
+  workflow_dispatch:
 
 jobs:
   release:
@@ -132,6 +137,17 @@ jobs:
           EOF
           cat /tmp/release-notes.md
 
+          # Gitea keeps a release note in a TEXT column, which on this instance's
+          # MySQL holds 65535 bytes. A longer note fails the API call after the
+          # tarball is built; refusing here keeps the margin visible and the tag
+          # uncreated. The fix is a shorter CHANGES.md entry, not a cut note.
+          size="$(wc -c < /tmp/release-notes.md)"
+          if [ "$size" -gt 60000 ]; then
+            echo "Release notes are ${size} bytes; Gitea stores at most 65535 on MySQL."
+            echo "Shorten this version's CHANGES.md entry, then dispatch this workflow on main."
+            exit 1
+          fi
+
       - name: Build the distribution tarball
         id: build
         if: steps.version.outputs.skip != 'true'
@@ -191,18 +207,21 @@ jobs:
         run: |
           set -eu
           # Creating the release creates the tag, pinned to this commit.
-          payload="$(jq -n \
+          # The payload goes through a file: as one argument it is bounded by
+          # Linux's 128 KiB per-argument limit, which the 8.0.0 notes exceeded
+          # ("curl: Argument list too long").
+          jq -n \
             --arg tag "$TAG" \
             --arg target "$GITHUB_SHA" \
             --arg name "$TAG" \
             --rawfile body /tmp/release-notes.md \
             '{tag_name: $tag, target_commitish: $target, name: $name, body: $body,
-              draft: false, prerelease: false}')"
+              draft: false, prerelease: false}' > /tmp/release-payload.json
 
           release="$(curl -sS -f -X POST "${API}/releases" \
             -H "Authorization: token ${TOKEN}" \
             -H "Content-Type: application/json" \
-            -d "$payload")"
+            --data-binary @/tmp/release-payload.json)"
           id="$(printf '%s' "$release" | jq -r '.id')"
           echo "Created release ${TAG} (id ${id})."
 

DEVELOPMENT.md

@@ -135,6 +135,13 @@ eine Sitzung ihn tatsächlich durchläuft:
    `setup-instance.md` und `preflight.md`, auf die der Installationssatz in `INSTALL.md` zeigt.
    **CI setzt den Tag, nie eine Sitzung** - das hält Invariante 5 intakt.
 
+   Die Release-Notiz ist der `CHANGES.md`-Eintrag; Gitea speichert auf MySQL höchstens 65535
+   Bytes, und der Job verweigert ab 60000, bevor er einen Tag anlegt. Scheitert der Job, nachdem
+   `VERSION` schon auf `main` steht, hilft weder ein Push (die Version steigt nicht noch einmal)
+   noch ein Re-run (er nimmt die Workflow-Datei des gescheiterten Commits): Ursache beheben,
+   publishen und `release.yml` per `workflow_dispatch` auf `main` starten. Die Prüfung auf ein
+   schon vorhandenes Release verhindert ein zweites.
+
 Die drei Verify-Befehle stehen oben in Schritt 3; was jeder von ihnen prüft, steht in
 [tools/CONTRACT.md](tools/CONTRACT.md) und wird dort von `docs verify` gegen die tatsächliche
 CLI gehalten. Hier steht es bewusst **nicht** noch einmal: eine zweite Beschreibung derselben