Release-Tags nach Paketbuild direkt veröffentlichen

2026-09-11 23:08:44 +02:00
1 parent 5a1a284505
commit ccc372778c
@@ -1,3 +1,32 @@
+## Aktueller Stand 11.09.2026: direkte Tagveröffentlichung
+
+Die frühere Freigabearchitektur in den folgenden historischen Abschnitten
+ist durch die Benutzerentscheidung ersetzt: Tag → Versionsvorprüfung → vier
+Builds/Pakete → Upload → automatische Veröffentlichung im selben Job.
+`publish.yml`, `publish.py`, das Nachweis-Gate und alle Release-Asset-Downloads
+sind entfernt. Die Pflichtabnahme läuft nicht mehr im Release-Workflow;
+lokale Testwerkzeuge bleiben verfügbar. Acht Pflichtassets (vier Archive
+und vier SHA-256-Dateien) genügen. Während des Uploads schützt ein temporärer
+Entwurf vor Teilveröffentlichung. Lokale Integritätsprüfungen und die
+API-Kontrolle von Dateiliste und Größen bleiben erhalten.
+
+Die vorherigen offenen Secret-/Download-/Nachweisbedingungen des
+Releasepfads entfallen. Aufgabe 3.4 bleibt nur für einen tatsächlichen
+Taglauf der neuen direkten Veröffentlichung offen. Der vorhandene Tag
+v1.0.0 und sein historischer Lauf 7 enthalten noch den alten Workflow.
+Historische Nachweise werden dadurch nicht als neue Läufe ausgegeben.
+
+Lokale Verifizierung der Umstellung: fünf Python-Regressionstests bestanden
+(direkte Freigabe ohne Nachweise/Downloads, fehlgeschlagener Upload mit
+Wiederholung, Schutz veröffentlichter Releases, fehlende/falsche Größen,
+lokal beschädigte/falsche Pakete und Tagformat). Workflow-YAML geprüft:
+ausschließlich Tag-Push, Versionsvorprüfung vor vier Builds, Releasejob
+abhängig von allen Builds. Die tatsächliche eingebettete Versionsvorprüfung
+akzeptiert v1.0.0 und lehnt unpassende/ungültige Tags ab. Beide betroffenen
+Changes und alle 30 Hauptspecs validiert; `git diff --check` bestanden.
+Keine Produktcodeänderungen oder neuen Builds erforderlich für diese
+Workflow-/Releasepfadänderung; kein Tag oder Release wurde verändert.
+
 # Verifizierung: phase-6-06-gitea-actions-und-releases

 Stand 07.09.2026. In Actions geprüfter Implementierungsstand:
@@ -169,3 +198,33 @@ Releaseprüfungen 6/6, YAML-Trigger und Versionsvorprüfung einschließlich
 Negativfällen, Format und OpenSpec 30/30 bestanden. Der vollständige
 Release-Pflichtlauf einschließlich der erforderlichen ignorierten Fälle
 folgt im neuen Taglauf.
+
+## Stage-Korrektur 11.09.2026
+
+[Taglauf 7](https://git.rfc1437.de/hugo/TerminalBasic/actions/runs/7)
+(API 548, Revision `6e742d96b1dfcb3c517998eee5ae825fe748ceb0`):
+Pflichtabnahme 913 und alle vier Paketjobs 914–917 erfolgreich. Stage 918
+hat alle neun Pflichtassets in Draft 10 hochgeladen und ist anschließend
+in `verify_uploads` → `Gitea.download` mit HTTP 404 gescheitert. Gitea 1.25.4
+erteilt dem Jobtoken die Repository-Rechte in der API, aber nicht auf dem
+Web-Downloadpfad des privaten Repositorys. Ein persönlicher Token konnte
+alle neun Dateien lesen; die vier Archivprüfsummen und die Grundabnahme
+für die Tagrevision stimmen. Kein Token wurde als Secret hinterlegt.
+
+Benutzerentscheidung: den erneuten Download zur Uploadkontrolle entfernen.
+Stage prüft weiter lokal Archive, Revision und SHA-256 vor dem Upload.
+Die Uploadkontrolle und Wiederholung prüfen API-Dateiliste und Dateigrößen;
+vorhandene Assets werden nicht ersetzt. Es findet dabei keine erneute
+Byte-/SHA-Prüfung der serverseitigen Inhalte statt.
+
+Verifizierung: sechs Python-Regressionstests bestanden. Der erweiterte
+Wiederholungstest verbietet jeden Asset-Download, bestätigt unveränderte
+vorhandene Uploads und lehnt abweichende Größen ab. Die neue Funktion
+`verify_uploads` wurde zusätzlich lesend gegen Draft 10 ausgeführt: alle
+neun Größen korrekt, Asset-Downloads ausdrücklich im Testaufruf gesperrt,
+keine Release-Mutation. Der historische Actions-Lauf bleibt fehlgeschlagen;
+sein Tag enthält noch den alten Code. Tag und Freigabestatus bleiben erhalten.
+
+Abgrenzung: `publish.yml` lädt weiterhin die Originalpakete für `dist.gate`.
+Der Jobtoken-Zugriff auf diesen separaten Download bleibt offen; die lokale
+Stage-Korrektur ist kein Nachweis eines erfolgreichen manuellen Publish.