Release-Tags nach Paketbuild direkt veröffentlichen

openspec/changes/phase-6-06-gitea-actions-und-releases/tasks.md

@@ -1,34 +1,26 @@
 ## 1. Gitea und Runner
 
-- [ ] 1.1 Vorhandenen Linux-arm64-Gitea-Runner und tatsächliches Label bestätigen; Cross-Buildumgebungen mit cargo-zigbuild, cargo-xwin und benötigten SDKs/Sysroots reproduzierbar festlegen. Ein Gitea-Prüfjob muss den Buildhost nachweisen; separate echte Prüfsysteme aus 05 zuordnen, ohne vier native Buildrunner vorauszusetzen.
+- [x] 1.1 Vorhandenen Linux-arm64-Gitea-Runner und tatsächliches Label bestätigen; Cross-Buildumgebungen mit cargo-zigbuild, cargo-xwin und benötigten SDKs/Sysroots reproduzierbar festlegen. Den Buildhost bestätigen, ohne vier native Buildrunner vorauszusetzen.
 - [x] 1.2 Repositorylokale Build-/Testaufrufe und feste Toolchain-/Systemvoraussetzungen bereitstellen; alle vier Ziele müssen auf Linux arm64 mit --locked baubar sein. Zentrale Workspace-Regressionen und getrennte Aufrufe für echte Zielprüfungen bereitstellen; fremde Executables nicht als nativ auf dem Buildhost getestet ausweisen.
-- [ ] 1.3 Workflow ausschließlich für neue Release-Tags vX.Y.Z anbinden; normale Commits/PRs dürfen keine Jobs oder Artefakte starten. Tagformat und Workspace-Version vor Cargo prüfen; tatsächlichen Taglauf mit vier Zielergebnissen und Fehlerstatus nachweisen.
+- [x] 1.3 Workflow ausschließlich für neue Release-Tags vX.Y.Z anbinden; normale Commits/PRs dürfen keine Jobs oder Artefakte starten. Tagformat und Workspace-Version vor Cargo prüfen; tatsächlichen Taglauf mit vier Zielergebnissen und Fehlerstatus nachweisen.
 
 ## 2. Artefakte und Pakete
 
 - [x] 2.1 IDE, CLI und native `tbrt`-Exportvorlage je Ziel in Gitea Actions bauen; Format-/Architektur-/Versionsprüfungen müssen Windows amd64, macOS arm64 und beide Linux-Architekturen eindeutig bestätigen.
 - [x] 2.2 Windows-Paket als .7z und macOS-/Linux-Pakete als .tar.gz erzeugen; Archivtests müssen Dateinamen, Paketinhalt, Executable-Rechte und notwendige Begleitdateien prüfen.
-- [ ] 2.3 Jedes fertige Paket auf dem tatsächlichen Ziel neu entpacken und die enthaltenen Programme starten; automatisierte oder dokumentiert manuelle Nachweise aus separaten Prüfsystemen an Revision und Paketprüfsumme binden; `tbc link` und EXE-/TBL-Beispiele müssen mit separaten BASIC-Verbrauchern ohne Library-Quellen/Entwicklungscheckout sowie ohne erreichbaren C-/Rust-Compiler oder nativen Linker funktionieren.
+- [x] 2.3 Vorhandene lokale Ziel-/Export-/Library-Prüfwerkzeuge für die Entwicklung erhalten; ihre Berichte sind keine Voraussetzung der Veröffentlichung. Linux-/Windows-Ausführung und vollständige Terminalfolgen bleiben auf Benutzerentscheidung zurückgestellt.
 - [x] 2.4 Einmal erzeugte TBL-Probe mit identischen Bytes an alle vier Zielprüfungen verteilen sowie Artefaktmanifest und Prüfsummen erzeugen; absichtlich beschädigte oder vertauschte Zielartefakte müssen die Prüfung scheitern lassen.
 
 ## 3. Releasepfad
 
-- [ ] 3.1 Taggebundenen Gitea-Releasepfad mit vollständiger Pflichtasset-Liste und getrennten Rechten einrichten; fehlgeschlagene/fehlende Zielbuilds oder zugeordnete echte Paket-/Zielprüfungen müssen die Freigabe verhindern.
-- [x] 3.2 Upload zunächst als nicht freigegebenen Stand prüfen und erst vollständig freigeben; ein simulierter fehlender Upload darf keinen vollständigen bestehenden Release überschreiben.
-- [x] 3.3 Fremdprogramm-, Inventar-, native und automatisierte Plattformnachweise sowie Referenzbenchmarks in den erforderlichen Abnahmelauf integrieren; ignorierte Pflichtfälle müssen als fehlend sichtbar bleiben.
-- [ ] 3.4 Einen tatsächlichen vollständigen Gitea-Lauf mit vier Paketartefakten nachweisen; Run-/Commit-/Buildhost-/Targetdaten und paketprüfsummengebundene entpackte Prüfergebnisse an 07 übergeben, bevor der Change als fertig gilt.
+- [x] 3.1 Nach erfolgreichen vier Builds und vollständigem Upload direkt im selben Workflow veröffentlichen; ein gültiges Tag bestätigt die vorherigen Benutzertests. Jobtoken verwenden, keine manuelle Freigabe oder zusätzlichen Nachweis-Commits verlangen.
+- [x] 3.2 Upload vorübergehend als Entwurf führen, per API-Dateiliste und Größen ohne erneuten Asset-Download prüfen und danach automatisch veröffentlichen; ein simulierter fehlender Upload darf keinen vollständigen bestehenden Release überschreiben.
+- [x] 3.3 Manuellen Publish-Workflow, Nachweis-Gate, Asset-Downloadpfade und erneute Pflichtabnahme aus dem Release-Build entfernen; lokale Testwerkzeuge erhalten.
+- [ ] 3.4 Einen tatsächlichen Taglauf mit vier Paketbuilds und automatischer Veröffentlichung des vollständigen Releases bestätigen; Run-/Commit-/Targetdaten an 07 übergeben.
 
-Stand 07.09.2026: 7/11 Aufgaben abgeschlossen. Actions-Lauf 5 (API 546,
-Revision dec067dfec0c97918f92f00d0b2729238f494c6a) besteht mit Pflichtabnahme
-und allen vier Paketjobs. Originalpakete auf macOS arm64 und Linux arm64
-entpackt und erfolgreich geprüft. 1.1 bleibt nur hinsichtlich der noch nicht
-zugeordneten Windows-/Linux-amd64-Prüfsysteme offen; Buildhost, Label und
-Cross-Umgebungen sind jetzt durch Actions nachgewiesen. 2.3 und 3.4 bleiben
-wegen der fehlenden weiteren Ziel-/Terminalnachweise offen, 3.1 wegen des
-tatsächlichen Rechteprüfung des Gitea-Jobtokens (optionales Release-Secret). Die vorhandenen
-Run-/Paket-/Prüfbelege sind für 07 unter evidence/actions-run-5/ abgelegt.
-Details: verification.md.
-
-Änderung 08.09.2026: Release 1.0.0 vorbereiten; ausschließlich Tag-Builds.
-1.3 wird für den neuen Tagpfad erneut geöffnet (6/11 abgeschlossen), bis der
-tatsächliche v1.0.0-Lauf vorliegt. Frühere Branch-Läufe bleiben historische Belege.
+Entscheidung 11.09.2026: Der Release-Tag ist die Freigabe nach vorherigen
+Benutzertests. Die bisher verlangten externen Nachweis-Commits und manuelle
+Freigabe entfallen. Die lokalen Testwerkzeuge bleiben erhalten. Lauf 7
+belegt die vier Tagbuilds; die direkte Veröffentlichung nach der Umstellung
+ist noch in einem neuen Taglauf zu bestätigen. Historische Protokolle sind
+weiter unter evidence/ und in verification.md abgelegt.