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

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

@@ -1,6 +1,6 @@
 ## Context
 
-Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versionsabfrage liefert Gitea 1.25.4. Im Repository existieren noch keine Actions-Workflows. Der bestehende Runner wurde am 2026-09-07 per read-only SSH als Linux aarch64 mit laufendem Gitea-Runner-Container bestätigt. Andere Projekte am Origin verwenden bereits `linux-arm64` mit cargo-zigbuild und cargo-xwin. Das tatsächliche Label, Toolchain-/SDK-Versionen und der Release-Zugang werden bei der Anbindung dieses Projekts geprüft; eine erfolgreiche TerminalBasic-Cross-Matrix wurde noch nicht nachgewiesen. Der Benutzer verlangt ausschließlich Gitea Actions am Origin und vier native Terminalziele.
+Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versionsabfrage liefert Gitea 1.25.4. Die vorhandenen Actions-Workflows werden auf Release-Tags beschränkt. Der bestehende Runner wurde am 2026-09-07 per read-only SSH als Linux aarch64 mit laufendem Gitea-Runner-Container bestätigt. Andere Projekte am Origin verwenden bereits `linux-arm64` mit cargo-zigbuild und cargo-xwin. Das tatsächliche Label, Toolchain-/SDK-Versionen und der Release-Zugang werden bei der Anbindung dieses Projekts geprüft; Lauf 5 hat die vollständige TerminalBasic-Cross-Matrix nachgewiesen. Der Benutzer verlangt ausschließlich Gitea Actions am Origin und vier native Terminalziele.
 
 ## Goals / Non-Goals
 
@@ -15,7 +15,7 @@ Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versio
 3. Matrixprodukte: `terminalbasic-<version>-windows-amd64.7z`, `terminalbasic-<version>-macos-arm64.tar.gz`, `terminalbasic-<version>-linux-amd64.tar.gz`, `terminalbasic-<version>-linux-arm64.tar.gz`. Windows enthält `tb.exe`/`tbc.exe`/`tbrt.exe`, übrige `tb`/`tbc`/`tbrt`; tbrt ist die native Exportvorlage unter `runtimes/<Target-Triple>/`, dazu deren Metadaten, Lizenz, Kurzinstallation. Das vorhandene CLI-/IDE-Suchschema bleibt erhalten. Archive dürfen keine Buildverzeichnis-/Quellbaumabhängigkeiten haben. Exportierte Anwenderprogramme bleiben normale native Einzelartefakte; die Archivformate betreffen die Distribution.
 4. Der Linux-Buildhost erzeugt/prüft Windows-Archive mit 7-Zip und Unix-Archive mit tar+gzip unter Erhalt der Executable-Bits. Inhalts-/Formatprüfungen laufen dort; tatsächliche Start-/Exportprüfungen verwenden neu entpackte Pakete auf passenden Zielsystemen aus 05, automatisiert oder dokumentiert manuell. Externe Nachweise müssen an Revision und exakte Paketprüfsumme gebunden und vor Freigabe geprüft sein. Ein gemeinsames TBL-Testartefakt wird einmal erzeugt und mit nachgewiesen identischen Bytes auf allen vier Zielsystemen verwendet. Separate BASIC-Verbraucher werden mit den entpackten TB-Tools verknüpft, als TBC ausgeführt und mit tbrt als EXE exportiert. Library-Quellen sind dabei nicht verfügbar. Erzeugung/Linken werden in einer Umgebung ohne erreichbaren C-/Rust-Compiler oder nativen Linker geprüft; Systemhilfen zur EXE-Finalisierung dürfen verfügbar bleiben. Fertige EXEs laufen anschließend ohne externe TBL/TBC oder TB-Installation.
 5. `cargo test --locked --workspace`, Clippy und Formatprüfung zentral auf dem Linux-arm64-Host; zielabhängige Rust-Testprogramme bei Bedarf cross-kompilieren und auf passenden Prüfsystemen ausführen. Native Tests aus 02/03/04 und automatisierbare Plattformtests aus 05 auf ihren tatsächlichen Zielen ausführen. Buildstatus und Ausführungsnachweise getrennt ausweisen; macOS-EXE-Finalisierung mit codesign erfolgt auf macOS. Den fixierten Fremdprogrammbestand ausdrücklich im erforderlichen Abnahmelauf bereitstellen. Compile-/VM-Messungen auf dokumentiertem Referenzrunner statt instabiler Debug-Zeitlimits in allen Jobs.
-6. Gitea-Release erst nach allen Pflichtjobs, zugeordneten echten Zielnachweisen und Vollständigkeits-/Prüfsummenprüfung freigeben. Upload zunächst zu einem als Entwurf erkennbaren Release oder gleichwertigem nicht freigegebenen Staging; anschließend atomare Freigabe im Rahmen der verfügbaren API. PR-Jobs ohne Veröffentlichungsrechte und ohne Release-Secrets; fremder PR-Code darf nicht mit solchen Rechten auf persönlichen Runnern laufen. Zugangswerte werden als Gitea-Secrets konfiguriert, nicht committed. Tests erzeugen keine öffentlichen Testreleases.
+6. Gitea-Release erst nach allen Pflichtjobs, zugeordneten echten Zielnachweisen und Vollständigkeits-/Prüfsummenprüfung freigeben. Upload zunächst zu einem als Entwurf erkennbaren Release oder gleichwertigem nicht freigegebenen Staging; anschließend atomare Freigabe im Rahmen der verfügbaren API. Keine Commit-/PR-Jobs. Der Release-Upload nutzt den repositorygebundenen Gitea-Jobtoken; ein explizites TB_RELEASE_TOKEN-Secret kann ihn bei Bedarf ersetzen. Keine persönlichen Zugangswerte werden committed. Tests erzeugen keine öffentlichen Testreleases.
 7. README-/PLAN-/Releasehinweise nennen die tatsächlich gemessenen minimalen OS-/Systembibliotheksversionen. Developer-ID-/öffentliche Vertrauenssignatur ist kein Ersatz für lokale Ausführbarkeit; wenn entsprechende Identitäten nicht konfiguriert sind, deren Download-/Vertrauensgrenzen ehrlich dokumentieren. Mac-Artefakte müssen trotzdem lokal korrekt finalisiert und startbar sein.
 
 ## Risks / Trade-offs
@@ -27,7 +27,7 @@ Origin ist `https://git.rfc1437.de/hugo/TerminalBasic.git`; die read-only Versio
 
 ## Migration Plan
 
-Lokale Skripte zuerst lauffähig machen, dann Gitea-Runner und Workflows anbinden. PR-/Push-Lauf ohne Veröffentlichung prüfen; kontrollierter Tag-/Release-Lauf nach erfolgreicher Matrix. Bisherige lokale Cargo-Nutzung erhalten. Rollback über vorheriges vollständiges Release und Rücknahme der Workflowänderung; keine Server-/Runnerinstallation durch bloße Proposal-Erstellung.
+Lokale Skripte zuerst lauffähig machen, dann Gitea-Runner und Workflows anbinden. Nur neue Tags im Format vX.Y.Z starten Build, Pflichtabnahme und Paketupload; keine Branch-/PR- oder manuellen Buildtrigger. Der Prüfjob lehnt ungültige Tags und Abweichungen von Cargo.toml vor dem Cargo-Build ab; die Zielmatrix hängt von diesem Job ab. Bisherige lokale Cargo-Nutzung erhalten. Rollback über vorheriges vollständiges Release und Rücknahme der Workflowänderung; keine Server-/Runnerinstallation durch bloße Proposal-Erstellung.
 
 ## Konkretisierung während der Umsetzung
 
@@ -40,6 +40,8 @@ Lokale Skripte zuerst lauffähig machen, dann Gitea-Runner und Workflows anbinde
   für tb/tbc. Build und Paketprüfung laufen auf dem Host ohne fremde Programme
   auszuführen. Die Anwenderpakete benötigen tb-template nicht.
 - Taglauf erzeugt erst nach Build/Grundabnahme einen überprüften Entwurf.
+  `v1.0.0` bezeichnet die erste Releaseversion. Normale Commits/PRs erzeugen
+  keine Jobs oder Artefakte; lokale Entwicklungsprüfungen bleiben verfügbar.
   Originalpakete werden auf separaten Systemen geprüft. Ein manueller Workflow
   auf main bindet deren Nachweise aus einem Origin-Commit an Tag, Revision und
   Paket-SHA-256 und gibt erst dann denselben Entwurf frei; kein erneuter Bau.

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

@@ -1,10 +1,10 @@
 ## Why
 
-Das Repository am bestehenden Gitea-Origin enthält noch keine CI-/Release-Workflows. Für eine vollständige Phase 6 müssen die vier vereinbarten Zielartefakte in Gitea Actions gebaut, auf ihren Zielsystemen geprüft und als nutzbare Release-Pakete ausgeliefert werden.
+Die vorhandenen Workflows am Gitea-Origin werden auf ausschließliche Release-Builds umgestellt. Für eine vollständige Phase 6 müssen die vier vereinbarten Zielartefakte in Gitea Actions gebaut, auf ihren Zielsystemen geprüft und als nutzbare Release-Pakete ausgeliefert werden.
 
 ## What Changes
 
-- Gitea Actions am bestehenden Origin für Push-/PR-Prüfungen und taggebundene Releases einrichten.
+- Gitea Actions am bestehenden Origin ausschließlich für neue Release-Tags `vX.Y.Z` verwenden; keine Commit-/PR-CI und keine Entwicklungsartefakte.
 - Auf dem vorhandenen Linux-arm64-Gitea-Runner Terminalanwendungen für Windows amd64 (cargo-xwin), macOS arm64 und Linux amd64 (cargo-zigbuild) sowie Linux arm64 bauen; keine zusätzlichen Zielplattformen und kein Mirror.
 - Windows als `.7z`, macOS und beide Linux-Ziele als `.tar.gz` mit `tb`, `tbc` und der nativen `tbrt`-Vorlage samt Metadaten paketieren.
 - Entpackte Pakete einschließlich `tbc link`, nativer Exporte und separater BASIC-Verbraucher von `.tbl` prüfen, Prüfsummen und nachvollziehbare Buildmetadaten liefern.

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

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

@@ -2,7 +2,7 @@
 
 - [ ] 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.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.
-- [x] 1.3 Push-/PR-Workflow unter .gitea/workflows anbinden; ein tatsächlicher Origin-Lauf muss vier Zielergebnisse und Fehlerstatus liefern, ohne Release-Secrets im PR-Pfad.
+- [ ] 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
 
@@ -25,6 +25,10 @@ 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
-getrennten Releasezugangs und der tatsächlichen Rechteprüfung. Die vorhandenen
+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.

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

@@ -5,7 +5,7 @@ Stand 07.09.2026. In Actions geprüfter Implementierungsstand:
 Change 05 wurde zuvor synchronisiert, auf Benutzeranweisung archiviert und
 mit `7965647` auf origin/main bestätigt.
 
-## Ergebnis
+## Ergebnis vor der Tag-Umstellung (07.09.2026)
 
 | Dimension | Stand |
 |---|---|
@@ -107,7 +107,7 @@ Die Cross-Linker melden eine ignorierte alte Linux-Linkeroptimierung bzw.
 fehlende Microsoft-CRT-PDBs (Windows). Alle Release-Builds sind erfolgreich;
 die Meldungen bleiben in den unveränderten Rohlogs sichtbar.
 
-## Offene externe Befunde
+## Offene externe Befunde (Stand des Laufs 5)
 
 - **1.1:** Runner `gitea-arm64-01`, Label `linux-arm64`, Linux-aarch64-Host,
   fixierte Tools und SDKs sind durch den erfolgreichen Actions-Lauf belegt.
@@ -147,3 +147,25 @@ der nur für die CI-Erprobung angelegte Branch wird anschließend entfernt.
 Rohbelege werden bytegetreu aufbewahrt; `.gitattributes` nimmt ausschließlich
 Nachweisdateien von Quelltext-Whitespace-Regeln aus. Patch-Kontext und
 Tool-Ausgaben dürfen ihre ursprünglichen Leerzeichen behalten.
+
+## Anpassung 08.09.2026: Release 1.0.0 und ausschließlich Tag-Builds
+
+Benutzerentscheidung: keine Commit-/PR-CI; Artefakte nur für Releases.
+`build.yml` besitzt nur einen Tag-Push-Trigger. Vor jedem Cargo-Build prüft
+`release_version` exakt vX.Y.Z und der Prüfjob die Übereinstimmung mit der
+Workspace-Version. Die Matrix hängt vom erfolgreichen Prüfjob ab.
+Workspace und Lockfile stehen auf 1.0.0. Ein versionsabhängig fest auf 0.1.0
+kodierter Exporttest verwendet jetzt CARGO_PKG_VERSION.
+Der Upload nutzt standardmäßig den repositorygebundenen Gitea-Jobtoken;
+TB_RELEASE_TOKEN ist optional. Dessen konkrete Releaseberechtigung bleibt
+bis zum tatsächlichen Upload zu prüfen. Die fehlenden Zielabnahmen werden
+weder durch die Version 1.0.0 noch den Tag-Build als bestanden ausgegeben.
+Der historische Stand 7/11 bezieht sich auf den früheren Branch-Workflow;
+für den neuen Tagpfad ist 1.3 erneut offen (aktuell 6/11).
+
+Lokale Prüfung vor dem Tag: Workspace 638 bestanden, 0 Fehler,
+3 ausdrücklich ignorierte Sonderprüfungen; Exporttests 3/3, Python-
+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.