Release-Kette: Packaging-Skript und Workflow

[GodModeAI2025]

Release-Kette fuer das erste Release

Das Konto hat ueber 56 Repos hinweg kein einziges Release. Dieser Branch legt die Kette, die daraus eines macht: ein Skript, das das Artefakt baut, ein Workflow, der es an ein Tag haengt, eine Versionsquelle, eine Doku, die zum Artefakt passt, und ein CI-Schritt, der das alles bei jedem Push nachprueft. Getaggt und veroeffentlicht wird nichts, das macht der Owner.

Was das Artefakt ist

Nicht die ZIP, die nightshift/scripts/build_zip.py und 24x7/scripts/build_zip.py erzeugen. Die bauen ein Setup fuer ein konkretes Projekt eines Nutzers. Das Release liefert den Skill selbst aus, also das, was jemand nach ~/.claude/skills/ legt.

Zwei Artefakte, nightshift.skill und 24x7.skill, je ein ZIP mit SKILL.md, scripts/build_zip.py, der Lizenz und der Version. Zwei und nicht eins, weil die Skills einzeln installiert werden, die Landingpage zwei getrennte Quickstarts hat und es vier getrennte Guides gibt.

Die Namen sind nicht frei gewaehlt. main nennt in der README und auf der Landingpage schon heute releases/latest/download/nightshift.skill und releases/latest/download/24x7.skill und den Befehl unzip nightshift.skill -d ~/.claude/skills/. Diese Links liefern 404. Mit dem ersten Tag treffen sie das Artefakt, ohne dass dieser PR gemergt sein muss.

Die sechs Commits

1. Packaging-Skript (scripts/build_release.py). Laeuft lokal, ohne Netz, ohne git, ohne GitHub, nur Standardbibliothek, Python 3.9. Bewusst ein Skript und keine Shell-Logik im Workflow: was im Workflow steht, laesst sich erst nach dem Tag pruefen, ein Skript jederzeit. Die Dateiliste ist eine Allowlist, kein Filter, damit gar nichts hineingeraten kann, was nicht namentlich dasteht. Zwei Laeufe ergeben byteweise dasselbe Archiv (fester Zeitstempel, feste Rechte, create_system=3, sortierte Eintraege).
2. Release-Workflow (.github/workflows/release.yml). push: tags: v*, permissions: contents: write, ruft das Skript auf und haengt das Ergebnis mit softprops/action-gh-release@v2 an. Keine Packaging-Logik im Workflow. Vorher ein Vergleich von Tag und VERSION, der abbricht, wenn beides auseinanderlaeuft. fail_on_unmatched_files: true, damit ein fehlendes Artefakt den Lauf scheitern laesst statt ein leeres Release zu veroeffentlichen.
3. Versionsquelle. VERSION im Wurzelverzeichnis, dazu ein CHANGELOG.md. Das Skript liest sie, der Release-Workflow prueft das Tag dagegen, die CI prueft CHANGELOG und Fuss der Landingpage dagegen. 1.0.0, weil die Landingpage vor Welle 2 oeffentlich v1.0 behauptet hat und die Reparaturen aus Welle 2 und die CI aus Welle 3 diese Behauptung inzwischen decken. Eine Nummer darunter waere eine Aussage ueber den Reifegrad, keine ueber den Stand.
4. Doku. Welle 2 hatte die Download-URLs entfernt, weil sie 404 lieferten. Jetzt stehen sie wieder da, mit genau den Namen, die das Skript baut, in README, den vier Guides und der Landingpage. Der Klon-Weg und der Rohdatei-Download aus main bleiben als Rueckfall stehen, samt Hinweis, woran man erkennt, dass noch kein Tag existiert. Solange nicht getaggt ist, ist damit keine Zeile falsch.
5. CI-Pruefschritt (tests/test_paket.py). Baut bei jedem Push dieselben Archive, die der Release-Workflow spaeter anhaengt, und schaut hinein: existieren, nicht leer, genau die erwarteten Dateien, kein .git, kein .github, kein index.html, keine .pyc. Dazu drei Pruefungen, die es vorher nicht gab: zwei Laeufe muessen byteweise dasselbe ergeben, jeder Eintrag muss den festen Zeitstempel tragen, und jede in README, Guides oder Landingpage dokumentierte releases-URL muss auf einen Dateinamen zeigen, den das Skript wirklich baut. Damit faellt ein kaputtes Paket vor dem Tag auf, nicht danach.
6. Korrektur im CHANGELOG. Ein Eintrag nannte Python 3.10 und beide Generatoren. Nachgesehen in c7d7e78: betroffen war nur der Nightshift-Generator, Ursache war ein Backslash im Ausdruck eines f-Strings, den erst 3.12 erlaubt.

Nachgefahren

Alle vier Schritte aus ci.yml laufen lokal unter Python 3.9.6, derselben Version wie auf dem Runner: py_compile ok, 7 Generator-Tests ok, 4 Hook-Tests ok, 11 Paket-Tests ok. Beide Workflow-Dateien parsen. Die Tag-Wache lokal mit v1.0.0 (exit 0), v1.0 und v2.0.0 (beide exit 1) durchgespielt.

Drei Gegenproben in einer Wegwerfkopie, damit die neue Pruefung nicht nur gruen aussieht: ein falscher Dateiname in der README, ein eingeschmuggeltes index.html im Artefakt und eine auseinanderlaufende Version faellt jeweils mit einer benannten Fehlermeldung durch.

index.html ist nur inhaltlich geaendert, nicht verschoben.

Was der Owner danach tun muss

Nach dem Merge das Tag setzen, genau v1.0.0:

git tag v1.0.0
git push origin v1.0.0

Der Workflow baut die Artefakte und haengt sie an. Ein Release ueber die Oberflaeche mit demselben Tag geht ebenso, die Dateien kommen in beiden Faellen dazu. v1.0 lehnt die Wache ab.

Danach zur Kontrolle:

curl -fLO https://github.com/GodModeAI2025/NightShift/releases/latest/download/nightshift.skill
curl -fLO https://github.com/GodModeAI2025/NightShift/releases/latest/download/24x7.skill

Wenn der Tag nicht heute landet: das Datum im CHANGELOG-Abschnitt ## [1.0.0] - 2026-09-04 anpassen.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BL7UoPomBp2Luhg89R6fYk

---

Gestapelt. Dieser PR sitzt auf ci/welle-3. GitHub haengt ihn automatisch auf main um, sobald der darunterliegende PR gemergt ist. Vorher zeigt der Diff nur die Welle-3-Aenderungen, das ist so gewollt.

Teil von Welle 4 des Haerteplans: Release und Packaging. Jede Aenderung wurde von einem zweiten Durchgang abgenommen, der das Artefakt selbst gebaut, entpackt und den Installationsweg durchgegangen ist.