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

.gitea/scripts/publish.py

@@ -9,7 +9,7 @@ import distribution as dist
 import release
 
 tag, evidence_revision = os.environ['TB_TAG'], os.environ['TB_EVIDENCE_REVISION']
-dist.require(re.fullmatch(r'v[0-9]+\.[0-9]+\.[0-9]+(?:-[A-Za-z0-9.-]+)?', tag), 'Ungültiger Tag')
+release.release_version(tag)
 dist.require(re.fullmatch('[0-9a-f]{40}', evidence_revision), 'Ungültige Nachweisrevision')
 revision = subprocess.check_output(['git', 'rev-parse', '--verify', tag + '^{commit}'], text=True).strip()
 api = release.Gitea()

.gitea/scripts/release.py

@@ -44,13 +44,19 @@ class Gitea:
             return response.read()
 
 
+def release_version(tag):
+    dist.require(re.fullmatch(r'v(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)', tag),
+                 'Release-Tag muss vX.Y.Z entsprechen')
+    return tag[1:]
+
+
 def expected(version):
     return [n for t in dist.TARGETS for n in (dist.name(version, t), dist.name(version, t) + '.sha256')] + ['acceptance.json']
 
 
 def stage(api, directory, tag, revision):
-    version = tag.removeprefix('v')
+    version = release_version(tag)
-    dist.require(tag == 'v' + version and re.fullmatch('[0-9a-f]{40}', revision), 'Tag/Revision ungültig')
+    dist.require(re.fullmatch('[0-9a-f]{40}', revision), 'Tag/Revision ungültig')
     dist.require(api.request('GET', '/tags/' + quote(tag, safe=''))['commit']['sha'] == revision, 'Tag zeigt auf andere Revision')
     names = expected(version)
     for target in dist.TARGETS:
@@ -92,8 +98,7 @@ def verify_uploads(api, release_id, directory, names):
 
 
 def publish(api, directory, evidence, tag, revision):
-    version = tag.removeprefix('v')
+    version = release_version(tag)
-    dist.require(tag == 'v' + version, 'Versionstag erforderlich')
     dist.require(api.request('GET', '/tags/' + quote(tag, safe=''))['commit']['sha'] == revision, 'Tag zeigt auf andere Revision')
     dist.gate(directory, evidence, revision, version)
     release = api.request('GET', '/releases/tags/' + quote(tag, safe=''))
@@ -118,7 +123,7 @@ def main():
     else:
         args.packages.mkdir(parents=True)  # Nie lokale Kandidaten überschreiben.
         release = api.request('GET', '/releases/tags/' + quote(args.tag, safe=''))
-        names = expected(args.tag.removeprefix('v'))
+        names = expected(release_version(args.tag))
         dist.require(release['draft'], 'Nur bestehende Entwürfe freigeben')
         assets = release.get('assets', [])
         dist.require(len(assets) == len(names) and {a['name'] for a in assets} == set(names), 'Pflichtassets fehlen')

.gitea/scripts/test_distribution.py

@@ -18,7 +18,7 @@ class DistributionTests(unittest.TestCase):
         self.packages = self.root / 'packages'; self.packages.mkdir()
         self.evidence = self.root / 'evidence'; self.evidence.mkdir()
         self.revision = 'a' * 40
-        self.version = '0.1.0'
+        self.version = '1.0.0'
         self.manifests = {}
         for target in d.TARGETS:
             path = self.packages / d.name(self.version, target)
@@ -42,6 +42,13 @@ class DistributionTests(unittest.TestCase):
         self.mock_verify = patch.object(d, 'verify', side_effect=lambda archive, target, *args: self.manifests[target])
         self.mock_verify.start(); self.addCleanup(self.mock_verify.stop)
 
+    def test_release_tags_are_exact_numeric_versions(self):
+        for tag in ('v1.0.0', 'v0.0.0', 'v12.34.56'):
+            self.assertEqual(r.release_version(tag), tag[1:])
+        for tag in ('main', '1.0.0', 'v1.0', 'v1.0.0-rc1', 'v1.0.0+build',
+                    'v1.0.0/extra', 'v01.0.0', 'v1x.0.0', 'v1.0.0\n'):
+            with self.assertRaises(ValueError, msg=tag): r.release_version(tag)
+
     def gate(self):
         return d.gate(self.packages, self.evidence, self.revision, self.version)
 

.gitea/workflows/build.yml

@@ -1,15 +1,11 @@
-name: Vierziel-Build und Pflichtabnahme
+name: Release-Build und Pflichtabnahme
 on:
   push:
-    branches: ['main', 'ci/**']
+    tags: ['v[0-9]*.[0-9]*.[0-9]*']
-    tags: ['v*']
-  pull_request:
-  workflow_dispatch:
 permissions:
   contents: read
 jobs:
   checks:
-    if: gitea.event_name != 'pull_request' || gitea.event.pull_request.head.repo.full_name == gitea.repository
     runs-on: linux-arm64
     container: ghcr.io/rust-cross/cargo-zigbuild@sha256:82af75c41958c2af2787e8bedd912da7678a9438937e223e9d83d006d747b38b
     timeout-minutes: 60
@@ -30,6 +26,18 @@ jobs:
       - uses: https://gitea.com/actions/checkout@11d5960a326750d5838078e36cf38b85af677262
         with:
           persist-credentials: false
+      - name: Release-Tag und Workspace-Version prüfen
+        env:
+          TB_TAG: ${{ gitea.ref_name }}
+          PYTHONPATH: .gitea/scripts
+        run: |
+          python3 - <<'PYTHON'
+          import os, tomllib
+          import distribution as dist
+          from release import release_version
+          version = tomllib.loads((dist.ROOT / 'Cargo.toml').read_text())['workspace']['package']['version']
+          dist.require(release_version(os.environ['TB_TAG']) == version, 'Tag und Workspace-Version weichen ab')
+          PYTHON
       - name: Gepinnte Werkzeuge
         run: sh .gitea/scripts/bootstrap.sh
       - name: Fixierten Fremdbestand bereitstellen
@@ -50,7 +58,7 @@ jobs:
           path: acceptance/
           if-no-files-found: error
   build:
-    if: gitea.event_name != 'pull_request' || gitea.event.pull_request.head.repo.full_name == gitea.repository
+    needs: checks
     runs-on: linux-arm64
     timeout-minutes: 90
     strategy:
@@ -116,7 +124,7 @@ jobs:
         env:
           GITEA_SERVER_URL: ${{ gitea.server_url }}
           GITEA_REPOSITORY: ${{ gitea.repository }}
-          TB_RELEASE_TOKEN: ${{ secrets.TB_RELEASE_TOKEN }}
+          TB_RELEASE_TOKEN: ${{ secrets.TB_RELEASE_TOKEN || gitea.token }}
           TB_TAG: ${{ gitea.ref_name }}
           TB_REVISION: ${{ gitea.sha }}
         run: |

.gitea/workflows/publish.yml

@@ -3,7 +3,7 @@ on:
   workflow_dispatch:
     inputs:
       tag:
-        description: 'Vorhandener Versionstag, z.B. v0.1.0'
+        description: 'Vorhandener Versionstag, z.B. v1.0.0'
         required: true
       evidence_commit:
         description: '40-stellige Origin-Revision mit release-evidence/<tag>/'
@@ -34,7 +34,7 @@ jobs:
         env:
           GITEA_SERVER_URL: ${{ gitea.server_url }}
           GITEA_REPOSITORY: ${{ gitea.repository }}
-          TB_RELEASE_TOKEN: ${{ secrets.TB_RELEASE_TOKEN }}
+          TB_RELEASE_TOKEN: ${{ secrets.TB_RELEASE_TOKEN || gitea.token }}
           TB_TAG: ${{ inputs.tag }}
           TB_EVIDENCE_REVISION: ${{ inputs.evidence_commit }}
         run: python3 .gitea/scripts/publish.py

Cargo.lock

@@ -604,7 +604,7 @@ dependencies = [
 
 [[package]]
 name = "tb-cli"
-version = "0.1.0"
+version = "1.0.0"
 dependencies = [
  "anyhow",
  "crossterm",
@@ -622,7 +622,7 @@ dependencies = [
 
 [[package]]
 name = "tb-export"
-version = "0.1.0"
+version = "1.0.0"
 dependencies = [
  "anyhow",
  "tb-vm",
@@ -630,7 +630,7 @@ dependencies = [
 
 [[package]]
 name = "tb-frontend"
-version = "0.1.0"
+version = "1.0.0"
 dependencies = [
  "log",
  "thiserror",
@@ -638,7 +638,7 @@ dependencies = [
 
 [[package]]
 name = "tb-ide"
-version = "0.1.0"
+version = "1.0.0"
 dependencies = [
  "anyhow",
  "crossterm",
@@ -654,7 +654,7 @@ dependencies = [
 
 [[package]]
 name = "tb-runner"
-version = "0.1.0"
+version = "1.0.0"
 dependencies = [
  "tb-export",
  "tb-runtime",
@@ -664,7 +664,7 @@ dependencies = [
 
 [[package]]
 name = "tb-runtime"
-version = "0.1.0"
+version = "1.0.0"
 dependencies = [
  "jiff",
  "log",
@@ -675,7 +675,7 @@ dependencies = [
 
 [[package]]
 name = "tb-ui"
-version = "0.1.0"
+version = "1.0.0"
 dependencies = [
  "anyhow",
  "crossterm",
@@ -690,7 +690,7 @@ dependencies = [
 
 [[package]]
 name = "tb-vm"
-version = "0.1.0"
+version = "1.0.0"
 dependencies = [
  "log",
  "tb-frontend",

Cargo.toml

@@ -12,7 +12,7 @@ members = [
 ]
 
 [workspace.package]
-version = "0.1.0"
+version = "1.0.0"
 edition = "2021"
 license = "MIT"
 repository = ""

PLAN.md

@@ -492,7 +492,8 @@ sind bestanden. Die vollständige Terminal-/OS-Matrix bleibt Phase 6.
 
 Verbindliche Build- und Release-Ziele (Terminalanwendungen): Windows amd64,
 macOS arm64 sowie Linux amd64 und arm64. Gitea Actions am bestehenden
-Origin erstellt die Artefakte für alle vier Ziele auf dem vorhandenen
+Origin erstellt ausschließlich beim Push neuer Release-Tags im Format
+`vX.Y.Z` die Artefakte für alle vier Ziele auf dem vorhandenen
 Linux-arm64-Runner: Linux arm64 nativ beziehungsweise mit festgelegter
 Zielbaseline, Linux amd64 und macOS arm64 über cargo-zigbuild, Windows amd64
 über cargo-xwin. Cross-Toolchains einschließlich SDK/Sysroot werden in Change
@@ -518,7 +519,15 @@ in 05 weitergeführt und bleiben Voraussetzung der Phasenabnahme.
 RGB-/Fensterflächenkorrektur vom Benutzer bestätigt, automatisierte macOS-
 Prüfungen bestanden. Acht unvollständige Matrixaufgaben bleiben als
 Nachweisbedarf bei 06/07; Windows-Ausführung ist vorerst zurückgestellt.
-Nächster Umsetzungschange ist 06 (Gitea Actions und Releases).
+Aktiver Change ist 06 (Gitea Actions und Releases). Die Vierziel-Matrix
+und Pflichtabnahme sind in Actions belegt. Ab 08.09.2026 laufen Build, Tests
+und Artefaktuploads ausschließlich für neue Release-Tags, erstmals `v1.0.0`
+mit Workspace-Version `1.0.0`. Es gibt keine CI für normale Commits oder PRs
+und keinen manuellen Paketbuild. Tagformat und Versionsgleichheit werden vor
+dem Bau geprüft. Arbeit und Pushes erfolgen direkt auf `main`; Release-Tags
+werden zusätzlich erstellt und gepusht. Lokale Tests bleiben verfügbar.
+Eine manuelle Freigabe kann vorhandene Releasepakete nach deren Zielabnahme
+veröffentlichen, baut sie aber nicht erneut.
 
 Release-Pakete: Windows als `.7z`, macOS und beide Linux-Architekturen
 als `.tar.gz`, jeweils mit `tb`, `tbc` und der passenden `tbrt`-Vorlage
@@ -569,8 +578,9 @@ Gesamtproposal und Abhängigkeiten:
       werden geprüft. Die Runtime ist nativer Code in `tbrt` und wird nicht
       in jede TBL kopiert. Erzeugung und Backend-Anbindung erfolgen in Phase 6.
 - [ ] Dokumentation: Sprachreferenz, Migrationshinweise, Beispielprogramme
-- [ ] CI (Gitea Actions am bestehenden Origin: Build + Tests auf allen vier
+- [ ] Release-Automatisierung (Gitea Actions am bestehenden Origin: Build +
-      System-/Architektur-Zielen), Releases über Gitea
+      Tests und Pakete ausschließlich für neue Tags `vX.Y.Z` auf allen vier
+      System-/Architektur-Zielen), Releases über Gitea; keine Commit-/PR-CI
 - [ ] **Abnahme der Leitplanke „Vollständigkeit ist das Soll"**:
       docs/inventar.md steht auf **0 offen** — jeder der 285 Einträge ist
       entweder implementiert oder als Non-Feature in der Sprachreferenz

README.md

@@ -1,5 +1,10 @@
 # Terminal Basic
 
+Version **1.0.0**. Release-Pakete werden ausschließlich durch neue Tags
+`vX.Y.Z` in Gitea Actions gebaut: Windows amd64 als `.7z`, macOS arm64 und
+Linux amd64/arm64 als `.tar.gz`. Normale Commits und PRs starten keine CI.
+Details zu Paketen und Freigabe: [Distribution](docs/distribution.md).
+
 Eine plattformübergreifende **Re-Imagination** des letzten großen BASIC-Dialekts
 für DOS (1992) — Sprache, Laufzeitbibliothek, Forms-Engine und IDE — in Rust,
 mit [Ratatui](https://ratatui.rs) als Terminal-UI-Schicht.

crates/tb-export/src/tests.rs

@@ -68,7 +68,10 @@ fn targets_versions_integrity_and_payload_bounds_are_enforced() {
         let meta = manifest(&b, t);
         for wrong in [
             meta.replace("runtime=1", "runtime=2"),
-            meta.replace("package=0.1.0", "package=9"),
+            meta.replace(
+                &format!("package={}", env!("CARGO_PKG_VERSION")),
+                "package=9",
+            ),
             meta.replace("tbc=4", "tbc=99"),
             meta.replace("checksum=", "checksum=0"),
         ] {

docs/distribution.md

@@ -2,6 +2,10 @@
 
 Change 06 baut ausschließlich am Origin `git.rfc1437.de/hugo/TerminalBasic`.
 Die Actions verwenden das bestätigte Label `linux-arm64` und vier Zieltriple.
+Build, Pflichtabnahme und Artefaktuploads starten ausschließlich bei neuen
+Release-Tags `vX.Y.Z`, erstmals `v1.0.0`. Normale Commits und PRs starten
+keine CI. Tagformat und Übereinstimmung mit der Workspace-Version werden
+vor dem Cargo-Build geprüft; ein manueller Paketbuild ist nicht vorgesehen.
 Kein Cross-Build ist ein Windows-/macOS-/Linux-Emulatornachweis.
 
 ## Buildumgebung
@@ -51,13 +55,15 @@ Erforderliche Konfiguration:
   `foreign.rs` fixierten Referenzprojekts. Der Checkout muss exakt
   `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6` liefern. Fehlende Konfiguration
   lässt den Pflichtjob scheitern; Fremdprogramme werden nicht übersprungen.
-- Secret `TB_RELEASE_TOKEN`: Gitea-Zugang nur für dieses Repository und die
+- Releasezugriff: standardmäßig der eingebaute repositorygebundene
-  Releaseverwaltung. Nur der Tag-Entwurfsjob und der manuelle Freigabeworkflow
+  `gitea.token`, optional ein explizites Secret `TB_RELEASE_TOKEN`.
-  referenzieren es. Es wird weder im Checkout gespeichert noch geloggt.
+  Nur Upload/Freigabe verwenden ihn für Releasezugriffe; der Checkout
-- PRs aus fremden Repositories führen keinen unkontrollierten Code auf dem
+  speichert keine Credentials. Die tatsächliche Uploadberechtigung wird
-  gemeinsamen persönlichen Runner aus. Interne PRs/Pushes erhalten keine
+  im Taglauf geprüft. Gitea 1.25 ignoriert die deklarativen `permissions`-
-  Veröffentlichungsschritte. Die tatsächliche Gitea-/Runner-Kompatibilität
+  Angaben; diese allein sind kein Nachweis getrennter Jobrechte.
-  einschließlich Jobrechten muss der erste Origin-Lauf bestätigen.
+  Siehe [Gitea-1.25-Kompatibilität](https://docs.gitea.com/1.25/usage/actions/comparison/).
+- Keine Branch-/PR-Trigger und kein manueller Buildtrigger. Der manuelle
+  Freigabeworkflow verarbeitet nur vorhandene taggebundene Originalpakete.
 
 Die Actions-URLs sind explizite Gitea-URLs mit festen Commit-IDs.
 [Absolute Action-URLs](https://docs.gitea.com/usage/actions/comparison/)
@@ -77,7 +83,7 @@ Auf dem passenden Prüfsystem das unveränderte Paket herunterladen und ausführ
 
 ```sh
 python3 .gitea/scripts/distribution.py target-check \
-  --archive /pakete/terminalbasic-0.1.0-macos-arm64.tar.gz \
+  --archive /pakete/terminalbasic-1.0.0-macos-arm64.tar.gz \
   --target aarch64-apple-darwin --output /nachweise/aarch64-apple-darwin
 ```
 
@@ -122,7 +128,7 @@ keine Durchführung. Herkunft wird über den geprüften Origin-Commit gebunden.
 
 ## Entwurf und Veröffentlichung
 
-Ein Push des passenden Tags `v<version>` baut/testet alle vier Ziele und lädt
+Ein Push eines neuen passenden Tags `vX.Y.Z` (beispielsweise `v1.0.0`) baut/testet alle vier Ziele und lädt
 erst danach neun Assets in einen Gitea-Entwurf: vier Pakete, vier SHA-Dateien,
 `acceptance.json`. Dessen Referenzlauf enthält Fremdprogramme, Inventar,
 Workspace/Clippy/Format, Compile-/VM-Benchmarks und die ausdrücklich gestartete

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.