Release-Tags nach Paketbuild direkt veröffentlichen

docs/distribution.md

@@ -2,7 +2,7 @@
 
 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
+Build, Paketierung und Veröffentlichung 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.
@@ -19,7 +19,7 @@ Kein Cross-Build ist ein Windows-/macOS-/Linux-Emulatornachweis.
 Rust 1.97.1 ist in `rust-toolchain.toml` fixiert. Die Images stehen mit Digest
 in `.gitea/workflows/build.yml`; SDK/Clang/Zig stammen aus diesen Images.
 7-Zip 25.01 wird mit fester SHA-256 in `bootstrap.sh` bereitgestellt.
-Vor dem Checkout installieren beide Workflows Node.js 22.22.0 mit fester
+Vor dem Checkout installieren die Jobs Node.js 22.22.0 mit fester
 SHA-256: Die Cross-Images enthalten keine Laufzeit für JavaScript-Actions.
 Zusätzlich prüft der Windows-Build einen festen Hash aller SDK-/CRT-Dateien
 und Symlinks. Änderungen unter derselben Microsoft-Versionsbezeichnung
@@ -51,10 +51,6 @@ Repository-Workflows ändern keine globale Docker-/AppArmor-Konfiguration.
 
 Erforderliche Konfiguration:
 
-- Variable `TB_VBDOS_REPOSITORY`: erreichbarer Git-Bestand des in
-  `foreign.rs` fixierten Referenzprojekts. Der Checkout muss exakt
-  `1cdd2b32b829fe1721d0b6aecc433abc47a96fb6` liefern. Fehlende Konfiguration
-  lässt den Pflichtjob scheitern; Fremdprogramme werden nicht übersprungen.
 - Releasezugriff: standardmäßig der eingebaute repositorygebundene
   `gitea.token`, optional ein explizites Secret `TB_RELEASE_TOKEN`.
   Nur Upload/Freigabe verwenden ihn für Releasezugriffe; der Checkout
@@ -62,14 +58,22 @@ Erforderliche Konfiguration:
   im Taglauf geprüft. Gitea 1.25 ignoriert die deklarativen `permissions`-
   Angaben; diese allein sind kein Nachweis getrennter Jobrechte.
   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.
+- Keine Branch-/PR-Trigger und kein manueller Build- oder Freigabeworkflow.
+  Das Setzen des Release-Tags bestätigt die zuvor durchgeführten Tests.
+
+Der Release-Schritt prüft Archive, Revision und SHA-256 lokal vor dem Upload.
+Anschließend prüft er per Release-API die vollständige Dateiliste und die
+Dateigrößen, ohne die Assets erneut herunterzuladen. Wiederholungen ergänzen
+fehlende Dateien und ersetzen keine vorhandenen Assets; abweichende Größen
+führen zum Fehler. Nach vollständigem Upload veröffentlicht derselbe Job den Release direkt.
+Es werden keine Release-Assets erneut heruntergeladen und keine zusätzlichen
+Nachweise oder Secrets benötigt.
 
 Die Actions-URLs sind explizite Gitea-URLs mit festen Commit-IDs.
 [Absolute Action-URLs](https://docs.gitea.com/usage/actions/comparison/)
 und [Runnerlabels](https://docs.gitea.com/runner/) entsprechen dem Gitea-Modell.
 
-## Pakete und Zielprüfungen
+## Pakete und optionale lokale Zielprüfungen
 
 `terminalbasic-<version>-windows-amd64.7z` sowie `...-macos-arm64.tar.gz`,
 `...-linux-amd64.tar.gz`, `...-linux-arm64.tar.gz` enthalten `tb`/`tbc` im Hauptverzeichnis und
@@ -79,7 +83,7 @@ bzw. `tbrt.exe.meta`),
 Das Manifest bindet Version, Revision, Rust, Buildhost/Image, Target und
 SHA-256 jeder Datei. Jedes Paket erhält zusätzlich eine `.sha256`-Datei.
 
-Auf dem passenden Prüfsystem das unveränderte Paket herunterladen und ausführen:
+Für eine freiwillige lokale Zielprüfung das Paket auf dem passenden System prüfen:
 
 ```sh
 python3 .gitea/scripts/distribution.py target-check \
@@ -103,51 +107,26 @@ derselben Revision. Dieses Testexecutable kann der Linux-Builder mit
 Anwenderpaket. DOSBox kann diese Windows-PE-Programme nicht ausführen.
 Windows bleibt auf Benutzerentscheidung vorerst offen.
 
-Der automatisch erzeugte `report.json` lässt die manuelle Terminalabnahme
-offen. Die Bedienfolge steht in `docs/plattformmatrix.md`. Je Target sind
-zusätzlich `manual.json` und die referenzierten nichtleeren Belegdateien nötig:
+Die Bedienfolge für freiwillige Terminalprüfungen steht in
+`docs/plattformmatrix.md`. Ergebnisse dieser Werkzeuge sind Entwicklungsdaten
+und werden nicht als Releasefreigabe eingelesen. Es gibt keine Pflicht für
+manuelle JSON-Berichte oder einen zusätzlichen Nachweis-Commit.
 
-```json
-{
-  "target": "aarch64-apple-darwin",
-  "revision": "<40-stellige Revision>",
-  "package_sha256": "<SHA-256 des Originalpakets>",
-  "passed": true,
-  "tester": "<Prüfer>",
-  "terminal_versions": {"terminal.app": "<gemessene Version>"},
-  "cases": {"f1_f12": true, "modifiers": true, "mouse": true,
-    "unicode_colors": true, "resize": true, "input_break": true, "shell": true},
-  "evidence": ["terminal-protokoll.txt"]
-}
-```
+## Direkte Veröffentlichung
 
-Windows verlangt `windows-terminal`, beide Linux-Ziele jeweils `xterm` und
-`vte` mit Versionen. Nur tatsächlich bestandene Schritte auf true setzen.
-Die Felder dienen einer verantworteten manuellen Bestätigung; sie ersetzen
-keine Durchführung. Herkunft wird über den geprüften Origin-Commit gebunden.
+Das Setzen und Pushen eines neuen Tags `vX.Y.Z` ist die Freigabeentscheidung:
+Die fachlichen Tests erfolgen vorher in der Entwicklung. `build.yml` prüft
+Tag und Workspace-Version, baut alle vier Ziele und veröffentlicht dann
+acht Assets: vier Pakete und vier SHA-256-Dateien. Im Release-Build laufen
+keine erneute Pflichtabnahme und keine formale Ziel-/Terminalnachweisprüfung.
+Die vorhandenen Testwerkzeuge bleiben lokal ausführbar, beispielsweise
+`python3 tests/support/release-abnahme.py --vbdos-repo /pfad/zum/vbdos-bestand`.
 
-## Entwurf und Veröffentlichung
-
-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
-native IDE-Abnahme. Golden-Erzeugung bleibt bewusst ignoriert. Echte native
-Paket-/Terminalprüfungen sind eine zusätzliche Freigabebedingung.
-
-Nachweise auf separaten Systemen beziehen sich auf diese Originalpakete.
-Unter `release-evidence/v<version>/<target>/` werden `report.json`, Logs,
-`manual.json` und dessen Belege in einem Origin-Commit bereitgestellt.
-Der manuell auf main gestartete Workflow „Geprüften Gitea-Entwurf freigeben“
-erhält Tag und vollständige Nachweisrevision. Er lädt die ursprünglichen
-Entwurfsassets, prüft vier exakte Paketbindungen, Ziel-/Terminalresultate,
-gemeinsame TBL-Prüfsumme und die Grundabnahme aus dem ursprünglichen Taglauf.
-Er baut die Pakete dabei nicht erneut. Fehlende oder abweichende Daten sperren
-Freigabe. Der Tag muss zur Paketversion und zur geprüften Revision passen.
-
-Uploads werden zurückgelesen und bytegenau geprüft. Wiederholungen ergänzen
-nur fehlende identische Assets eines Entwurfs. Abweichende Assets oder ein
-bereits veröffentlichter Release werden nicht überschrieben. Erst der letzte
-API-Aufruf ändert `draft` auf false. Die Regressionen simulieren insbesondere
-fehlende Uploads, falsche Nachweise, korrupte Pakete und bestehende Releases;
-sie erzeugen keine öffentlichen Testreleases.
+Während des Uploads bleibt der Release kurzzeitig ein Entwurf. Erst wenn
+alle vier Builds erfolgreich sind und Dateiliste sowie Größen stimmen,
+setzt derselbe Job `draft` auf false. Kein manueller Publish-Schritt und
+kein weiterer Commit sind erforderlich. Fehlgeschlagene Builds oder Uploads
+verhindern eine unvollständige Veröffentlichung. Wiederholungen ergänzen
+fehlende Dateien; bestehende Assets und veröffentlichte Releases werden
+nicht überschrieben. Tag, Paketrevision und Prüfsummen werden lokal vor
+dem Upload geprüft; Release-Assets werden nicht zurückgeladen.

docs/plattformmatrix.md

@@ -1,5 +1,9 @@
 # Plattformabnahme – Phase 6, Change 05
 
+Diese Entwicklungsprüfungen sind unabhängig von der Releaseveröffentlichung.
+Der Release-Tag bestätigt die vorherigen Tests; Gitea verlangt dafür keine
+zusätzlichen Terminalberichte oder Nachweis-Commits.
+
 Diese Matrix prüft die tatsächliche IDE und native Exporte auf den vier
 Release-Zielen. Automatisierte Headless-/PTY-/Konsolentests und die manuelle
 Emulatorbedienung sind getrennte Nachweise. Eine grüne Compilation oder ein