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

## Aktueller Stand 11.09.2026: direkte Tagveröffentlichung

Die frühere Freigabearchitektur in den folgenden historischen Abschnitten
ist durch die Benutzerentscheidung ersetzt: Tag → Versionsvorprüfung → vier
Builds/Pakete → Upload → automatische Veröffentlichung im selben Job.
`publish.yml`, `publish.py`, das Nachweis-Gate und alle Release-Asset-Downloads
sind entfernt. Die Pflichtabnahme läuft nicht mehr im Release-Workflow;
lokale Testwerkzeuge bleiben verfügbar. Acht Pflichtassets (vier Archive
und vier SHA-256-Dateien) genügen. Während des Uploads schützt ein temporärer
Entwurf vor Teilveröffentlichung. Lokale Integritätsprüfungen und die
API-Kontrolle von Dateiliste und Größen bleiben erhalten.

Die vorherigen offenen Secret-/Download-/Nachweisbedingungen des
Releasepfads entfallen. Aufgabe 3.4 bleibt nur für einen tatsächlichen
Taglauf der neuen direkten Veröffentlichung offen. Der vorhandene Tag
v1.0.0 und sein historischer Lauf 7 enthalten noch den alten Workflow.
Historische Nachweise werden dadurch nicht als neue Läufe ausgegeben.

Lokale Verifizierung der Umstellung: fünf Python-Regressionstests bestanden
(direkte Freigabe ohne Nachweise/Downloads, fehlgeschlagener Upload mit
Wiederholung, Schutz veröffentlichter Releases, fehlende/falsche Größen,
lokal beschädigte/falsche Pakete und Tagformat). Workflow-YAML geprüft:
ausschließlich Tag-Push, Versionsvorprüfung vor vier Builds, Releasejob
abhängig von allen Builds. Die tatsächliche eingebettete Versionsvorprüfung
akzeptiert v1.0.0 und lehnt unpassende/ungültige Tags ab. Beide betroffenen
Changes und alle 30 Hauptspecs validiert; `git diff --check` bestanden.
Keine Produktcodeänderungen oder neuen Builds erforderlich für diese
Workflow-/Releasepfadänderung; kein Tag oder Release wurde verändert.

# Verifizierung: phase-6-06-gitea-actions-und-releases

Stand 07.09.2026. In Actions geprüfter Implementierungsstand:
`dec067dfec0c97918f92f00d0b2729238f494c6a` (Lauf auf `ci/phase-6-06`).
Change 05 wurde zuvor synchronisiert, auf Benutzeranweisung archiviert und
mit `7965647` auf origin/main bestätigt.

## Ergebnis vor der Tag-Umstellung (07.09.2026)

| Dimension | Stand |
|---|---|
| Vollständigkeit | 7/11 Aufgaben abgeschlossen; vier Aufgaben mit noch fehlenden Ziel-/Rechtenachweisen offen |
| Korrektheit | Actions-Lauf 5 mit Pflichtabnahme und vier Paketjobs grün; Originalpakete auf Linux arm64 und macOS arm64 erfolgreich ausgeführt; Paket-/Release-Regressionen grün |
| Kohärenz | Bestehende Exportvalidierung, Vorlagenpfade, TBL-/Native-/PTY-Prüfungen wiederverwendet; keine neue Produktabhängigkeit |

Keine aktuell bekannte unbehobene lokale Codeabweichung. Der Change ist
wegen der unten benannten fehlenden externen Nachweise **nicht vollständig
verifiziert oder archivierungsbereit**. Der tatsächliche Actions-Build ist
jetzt nachgewiesen; fehlende echte Zielabnahmen bleiben davon getrennt.

## Umsetzung und Szenarioabdeckung

- `.gitea/workflows/build.yml`: Push/interner PR, vier Targets auf
  `linux-arm64`, gepinnte Images/Action-Commits, getrennte Grundabnahme und
  Paketartefakte. Fremde PRs laufen nicht auf dem persönlichen Runner.
- `.gitea/scripts/build.py`, `bootstrap.sh`, `rust-toolchain.toml`: feste
  Toolchain, SDK-/CRT-Versionen und Inhaltsprüfung, statische Windows-CRT,
  glibc-Buildbaseline 2.28, macOS-Deployment 11.0. Das sind Buildvorgaben,
  keine nachgewiesenen minimalen OS-Versionen.
- `distribution.py`: richtige `.7z`-/`.tar.gz`-Formate, vollständige Inhalte,
  0755 für Unix-Executables, Dateiprüfsummen, Versions-/Target-/Revision-
  Manifest. Entpacken lehnt fremde Pfade, Links und unvollständige Archive ab.
  `tb-template --inspect` verwendet den vorhandenen nativen Formatparser.
- `target-check`: Programme aus frisch entpackten Paketen starten; EXE-Export
  ohne expliziten Vorlagenpfad, native Parität, identische portable.tbl,
  quellfreie Verbraucher, leerer PATH ohne Compiler/Linker, Unix-PTY; Windows
  verlangt zusätzlich das explizite Konsolentestexecutable. Manuelle
  Emulatorfolgen bleiben getrennt und revisions-/paketgebunden.
- `release.py`, `publish.py`, `publish.yml`: Tag-/Commitbindung, vollständige
  Pflichtassets, Entwurfsstatus, Zurücklesen mit Bytevergleich, keine Ersetzung
  existierender abweichender Assets oder veröffentlichter Releases. Fehlende,
  falsche oder unvollständige Ziel-/Terminal-/Grundnachweise verhindern den
  letzten `draft=false`-Aufruf. Nachweise stammen aus einem Origin-Commit.
- `acceptance.py`: bestehende Fremdprogramm-/Inventar-/Workspace-/Clippy-/
  Format-/Compile-/VM-Prüfung sowie explizite native IDE-Abnahme. Fehlende
  Konfiguration, ignorierte Pflichtläufe und Fehler werden nicht grün.
- `docs/distribution.md`, `INSTALL.txt`: Aufrufe, Paketlayout, Rechte,
  Systemgrenzen, manuelle Nachweisform und Freigabefolge.

## Gefundene und behobene Befunde

1. Die neuen Paketprüfungen verwendeten zunächst `tbc --help`, obwohl die
   CLI diesen Aufruf nicht unterstützt. Prüfung/Installation verwenden jetzt
   echte Compiler-/Exportbefehle; keine zusätzliche CLI-Funktion nötig.
2. Ein flaches tbrt neben tb/tbc erfüllte die bestehenden automatischen
   Suchpfade nicht. Archive enthalten nun `runtimes/<Target>/tbrt[.exe]`
   samt Metadaten. Der ausdrückliche Test ohne `--template` besteht.
3. Alte Abnahmeskripte setzten das Entwicklerwerkzeug tb-template voraus.
   Sie verwenden vorhandene Paketmetadaten; der bisherige Entwicklerpfad
   bleibt für nicht paketierte Builds verfügbar.
4. Die native IDE-Pflichtprobe erhielt zunächst den falschen Runtime-Basispfad.
   `acceptance.py` legt die Vorlage im geforderten Target-Unterverzeichnis ab;
   der vollständige Abnahmelauf besteht nach der Korrektur.
5. Der vorhandene cargo-xwin-Stand akzeptiert den VS-Kanal nur numerisch;
   CRT-Auswahl benutzt die Manifest-ID `14.44.17.14`, nicht die Dateiversion.
   Mit Kanal 17 und den tatsächlichen IDs bestehen Build und .7z-Prüfung.
   Zusätzlich verhindert der SDK-Inhaltspin eine stille Änderung unter
   unveränderten Versionsbezeichnungen.
6. Den Cross-Images fehlt Node für checkout und Artefakt-Actions. Beide
   Workflows installieren vor checkout Node 22.22.0 mit SHA-256-Prüfung.
   Checkout und Fehlerartefakt-Upload sind damit im echten Lauf erfolgreich.
7. Der Fremdprogrammtest verwendete zwei unterschiedliche temporäre Pfade.
   Linux zeigt den kurzen CURDIR$-Pfad im Titel, wodurch der vollständige
   Bildschirmvergleich fehlschlug. Beide Läufe verwenden jetzt denselben
   jeweils frisch entpackten Pfad; alle Vergleiche bleiben unverändert.
   Lokaler Test mit TMPDIR=/tmp und der echte Linux-Actions-Test bestehen.

## Nachweise

- Vier Targets auf dem tatsächlichen Linux-aarch64-Gitea-Host gebaut;
  PE/amd64/Console, Mach-O/arm64 und beide ELF-Maschinen geprüft.
- Echte entpackte Linux-arm64-Paketprüfung auf Linux 6.8.0-139/glibc 2.41.
- Das auf Linux cross-kompilierte macOS-Paket auf macOS 26.6.2/arm64 gestartet:
  Standard-Vorlagenpfad, native Fälle, TBL, IDE-Shell/Abbruch/Wiederherstellung
  bestanden. Die Programme wurden dabei nicht lokal erneut gebaut.
- Fünf automatisierte Paket-/Release-Regressionen: vollständiger Satz,
  fehlende/falsche Nachweise, Korruption, falsche Revision, schmutzige Quellen,
  Archiv-Traversierung, fehlender Upload, sichere Wiederholung, Schutz bereits
  veröffentlichter Releases. Keine öffentlichen Testreleases erzeugt.
- Zusätzlich echte negative Artefaktproben: Mach-O als Linux deklariert und
  verändertes Executable innerhalb eines Archivs werden abgelehnt.
- Lokaler vollständiger Pflichtlauf mit fixiertem Fremdbestand einschließlich
  Benchmarks und expliziter nativer IDE-Probe bestanden. Exporttests, Clippy,
  Format, YAML-Parsing und OpenSpec-Validierung bestanden.

Die früheren lokal orchestrierten Testpakete tragen den uncommitteten
Diffstand im Manifest. Die vier aktuellen Actions-Pakete dagegen tragen
`dec067d` und `source_dirty=false`. Ihre Archive wurden aus dem Gitea-
Artefaktspeicher geladen und gegen die hochgeladenen SHA-Dateien geprüft.
`evidence/actions-run-5/` enthält Joblogs, Manifest-/Paketprüfsummen und
die tatsächlichen entpackten macOS-/Linux-arm64-Prüfergebnisse.
Linux arm64 läuft zusätzlich direkt auf dem Host mit glibc 2.39; macOS
auf 26.6.2/arm64. Windows-PE und Linux-amd64-ELF sind formatgeprüft,
aber auf ihren Zielen nicht ausgeführt.

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 (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.
  Für Windows und Linux amd64 sind weiterhin konkrete echte Prüfsysteme
  zuzuordnen; vier native Buildrunner sind nicht erforderlich.
- **3.4:** Der vollständige Actions-Lauf und die verfügbaren paketgebundenen
  Prüfergebnisse sind für 07 abgelegt. Die Übergabe aller vorgeschriebenen
  Zielnachweise bleibt bis zu den fehlenden Prüfungen aus 2.3 unvollständig.
- **2.3:** Windows-Ausführung bleibt entsprechend Benutzerentscheidung offen;
  Linux amd64 und die vollständigen manuellen Emulatorfolgen sind ebenfalls
  nicht belegt. Cross-Build, lokale Mocktests und gemeinsame ANSI-Technik
  ersetzen diese Prüfungen nicht.
- **3.1:** Der getrennte Releasezugang `TB_RELEASE_TOKEN` ist noch nicht
  eingerichtet/verifiziert. Es wurde kein persönlicher Git-Zugang als
  dauerhaftes Release-Secret übernommen. Die Referenzvariable für den
  vorhandenen fixierten Fremdbestand wurde am Repository eingerichtet.

Die verbleibenden Ziel-/Rechtebefunde lassen sich nicht durch Abhaken von
Aufgaben schließen. Die fehlenden Paket-/Zielnachweise ergänzen und
kontrollierte Entwurfs-/Rechte-
prüfung durchführen. Bis dahin keine Freigabe und keine Behauptung „0 Befunde“.

## Origin-Anbindung

[Actions-Lauf 5](https://git.rfc1437.de/hugo/TerminalBasic/actions/runs/5)
(API-ID 546) für `dec067dfec0c97918f92f00d0b2729238f494c6a` ist abgeschlossen
mit `success`: Prüfjob 901 sowie Paketjobs 902–905 erfolgreich. Der
Release-Schritt ist bei diesem Branch-Push erwartungsgemäß `skipped`.
Damit sind Push-Anbindung, echte Pflichtabnahme, vier Zielarchive und Upload
belegt. Der frühere fehlerhafte Lauf 3 zeigte den korrekten Fehlerstatus;
Lauf 4 führte die fehlgeschlagene Pflichtabnahme samt Protokoll-Upload aus.
Es wurde kein PR eröffnet und kein Release erzeugt; der PR-Pfad benötigt
keine Release-Secrets. Eine tatsächliche Release-Rechteprüfung fehlt weiter.
Der Implementierungsstand wird samt Bericht und Nachweisen per Fast-forward
auf `main` übernommen. Weitere Arbeit und Pushes erfolgen direkt auf `main`;
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.

## Stage-Korrektur 11.09.2026

[Taglauf 7](https://git.rfc1437.de/hugo/TerminalBasic/actions/runs/7)
(API 548, Revision `6e742d96b1dfcb3c517998eee5ae825fe748ceb0`):
Pflichtabnahme 913 und alle vier Paketjobs 914–917 erfolgreich. Stage 918
hat alle neun Pflichtassets in Draft 10 hochgeladen und ist anschließend
in `verify_uploads` → `Gitea.download` mit HTTP 404 gescheitert. Gitea 1.25.4
erteilt dem Jobtoken die Repository-Rechte in der API, aber nicht auf dem
Web-Downloadpfad des privaten Repositorys. Ein persönlicher Token konnte
alle neun Dateien lesen; die vier Archivprüfsummen und die Grundabnahme
für die Tagrevision stimmen. Kein Token wurde als Secret hinterlegt.

Benutzerentscheidung: den erneuten Download zur Uploadkontrolle entfernen.
Stage prüft weiter lokal Archive, Revision und SHA-256 vor dem Upload.
Die Uploadkontrolle und Wiederholung prüfen API-Dateiliste und Dateigrößen;
vorhandene Assets werden nicht ersetzt. Es findet dabei keine erneute
Byte-/SHA-Prüfung der serverseitigen Inhalte statt.

Verifizierung: sechs Python-Regressionstests bestanden. Der erweiterte
Wiederholungstest verbietet jeden Asset-Download, bestätigt unveränderte
vorhandene Uploads und lehnt abweichende Größen ab. Die neue Funktion
`verify_uploads` wurde zusätzlich lesend gegen Draft 10 ausgeführt: alle
neun Größen korrekt, Asset-Downloads ausdrücklich im Testaufruf gesperrt,
keine Release-Mutation. Der historische Actions-Lauf bleibt fehlgeschlagen;
sein Tag enthält noch den alten Code. Tag und Freigabestatus bleiben erhalten.

Abgrenzung: `publish.yml` lädt weiterhin die Originalpakete für `dist.gate`.
Der Jobtoken-Zugriff auf diesen separaten Download bleibt offen; die lokale
Stage-Korrektur ist kein Nachweis eines erfolgreichen manuellen Publish.