Release 1.0.0: Builds ausschließlich für Release-Tags

openspec/changes/phase-6-06-gitea-actions-und-releases/specs/gitea-distribution/spec.md

@@ -5,12 +5,24 @@ Liefert geprüfte Terminal-Basic-Programme und Exportvorlagen für die vier fest
 ## ADDED Requirements
 
 ### Requirement: Vier verbindliche Buildziele
-Gitea Actions am bestehenden Origin SHALL Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 aus derselben Revision auf dem vorhandenen Linux-arm64-Runner bauen und paketieren. Cross-Kompilierung SHALL für fremde Ziele verwendet werden; vier native Buildrunner MUST NOT vorausgesetzt werden. Buildprüfungen und echte Zielausführung SHALL getrennt nachvollziehbar sein. Fehlende Build- oder Ausführungsnachweise, fehlgeschlagene Tests oder fehlende Artefakte eines Pflichtziels MUST einen vollständigen erfolgreichen Release verhindern. Für normale Änderungen SHALL ein reproduzierbarer Build-/Teststatus vorliegen.
+Gitea Actions am bestehenden Origin SHALL Terminalanwendungen für Windows amd64, macOS arm64, Linux amd64 und Linux arm64 aus derselben Revision auf dem vorhandenen Linux-arm64-Runner bauen und paketieren. Cross-Kompilierung SHALL für fremde Ziele verwendet werden; vier native Buildrunner MUST NOT vorausgesetzt werden. Buildprüfungen und echte Zielausführung SHALL getrennt nachvollziehbar sein. Fehlende Build- oder Ausführungsnachweise, fehlgeschlagene Tests oder fehlende Artefakte eines Pflichtziels MUST einen vollständigen erfolgreichen Release verhindern. Build, Pflichtabnahme und Paketartefakte SHALL ausschließlich durch den Push eines neuen Release-Tags im exakten Format `vX.Y.Z` ausgelöst werden; X, Y und Z SHALL nichtnegative Dezimalzahlen ohne führende Nullen sein. Der Tag SHALL der Workspace-Version entsprechen. Normale Branch-Commits und Pull Requests MUST NOT Actions-Builds oder Paketartefakte auslösen. Lokale Entwicklungsprüfungen SHALL weiterhin verfügbar sein.
 
 #### Scenario: Ein Ziel fehlt
 - **WHEN** drei Zieljobs erfolgreich sind und der vierte fehlt oder fehlschlägt
 - **THEN** wird kein vollständiger Release veröffentlicht und das fehlende Ziel bleibt erkennbar
 
+#### Scenario: Normaler Commit oder Pull Request
+- **WHEN** ein Commit auf main oder ein Pull Request gepusht wird
+- **THEN** startet kein Actions-Build und es entstehen keine Paketartefakte
+
+#### Scenario: Neuer passender Release-Tag
+- **WHEN** v1.0.0 auf eine Revision mit Workspace-Version 1.0.0 gepusht wird
+- **THEN** laufen Pflichtabnahme und anschließend die vier Paketbuilds für diese Revision
+
+#### Scenario: Ungültiger oder unpassender Tag
+- **WHEN** ein Tag vom Format vX.Y.Z oder von der Workspace-Version abweicht
+- **THEN** beginnt kein Cargo-/Paketbuild; ein vom groben Tagfilter erfasster ungültiger Tag scheitert bereits in der Vorprüfung
+
 ### Requirement: Nutzbare Releasearchive
 Windows SHALL als `.7z` ausgeliefert werden; macOS und beide Linux-Architekturen SHALL jeweils als `.tar.gz` ausgeliefert werden. Jedes Archiv SHALL die passenden IDE-/Compiler-Executables `tb`/`tbc` und `tbrt` als native Runtime-/Exportvorlage (Windows jeweils mit `.exe`), benötigte Metadaten, Lizenz und Benutzungshinweise enthalten. Architektur, Version und Betriebssystem SHALL im Dateinamen eindeutig sein; Dateirechte und notwendige Begleitdateien SHALL erhalten bleiben.
 
@@ -26,7 +38,7 @@ Der Actions-Releasepfad SHALL tatsächliche Prüfungen der fertig gepackten und
 - **THEN** scheitert die Format-/Startprüfung vor der Veröffentlichung
 
 ### Requirement: Nachvollziehbare Veröffentlichung
-Releaseartefakte SHALL Version/Tag, Commit, Toolchain, Buildhost, Ziel, Integritätsprüfsumme und zugehörige Prüfergebnisse nachvollziehbar machen. Nur der freigegebene Tag-/Releasepfad SHALL Veröffentlichungsrechte verwenden; PR-Prüfungen MUST keine Release-Secrets benötigen. Wiederholte fehlgeschlagene Veröffentlichungen SHALL keinen bestehenden vollständigen Release stillschweigend durch unvollständige Assets ersetzen.
+Releaseartefakte SHALL Version/Tag, Commit, Toolchain, Buildhost, Ziel, Integritätsprüfsumme und zugehörige Prüfergebnisse nachvollziehbar machen. Nur der freigegebene Tag-/Releasepfad SHALL Veröffentlichungsrechte verwenden; Normale Commits und PRs SHALL keine Actions-Jobs starten. Der repositorygebundene Gitea-Jobtoken SHALL für Releasezugriffe nutzbar sein; ein getrenntes Secret SHALL optional bleiben. Wiederholte fehlgeschlagene Veröffentlichungen SHALL keinen bestehenden vollständigen Release stillschweigend durch unvollständige Assets ersetzen.
 
 #### Scenario: Paket beschädigt oder Upload unvollständig
 - **WHEN** ein Archiv nach dem Bau verändert wird oder ein Pflichtasset nicht hochgeladen werden kann