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

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

Stand 07.09.2026. Basis: `796564795a6607651c366c6b0de74560af55e71a`
mit dem dokumentierten Change-06-Diff. Change 05 wurde zuvor synchronisiert,
auf Benutzeranweisung archiviert und dieser Commit auf Origin bestätigt.

## Ergebnis

| Dimension | Stand |
|---|---|
| Vollständigkeit | 5/11 Aufgaben abgeschlossen; sechs Aufgaben mit echten Origin-/Ziel-/Rechtenachweisen offen |
| Korrektheit | Vier echte Cross-/Native-Builds auf Linux arm64; native Paketprüfungen auf Linux arm64 und macOS arm64 bestanden; lokale Pflichtabnahme und negative Paket-/Releaseprüfungen bestanden |
| 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**. Vier lokal orchestrierte Container-
builds auf dem Gitea-Host sind keine vier erfolgreichen Actions-Jobs.

## 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.

## 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 gebauten Testpakete tragen den uncommitteten Diffstand im Manifest und
sind absichtlich nicht releasefähig. Lokale Belege werden unter `evidence/`
aufbewahrt; Paketprüfsummen und tatsächliche Hostdaten stehen in den Berichten.

## Offene externe Befunde

- **1.1/1.3/2.1/3.4:** Gitea 1.25.4, Actions am Repository aktiviert,
  registrierter Runner `gitea-arm64-01`, Label `linux-arm64` bestätigt.
  Der Runner ist in einer Neustartschleife: `rootlesskit ... /proc/self/exe:
  operation not permitted`. Eine Entscheidung zur Reparatur des gemeinsamen
  Runners wurde angefragt. Keine Docker-/AppArmor-Konfiguration verändert.
  Ein echter erfolgreicher Actions-Matrixlauf und dessen Rechteverhalten fehlen.
- **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.

Diese Befunde lassen sich nicht durch Änderungen an Paketcode oder durch
Abhaken von Aufgaben schließen. Nach Runner-Reparatur den Origin-Lauf ausführen,
zugehörige Paket-/Zielnachweise ergänzen und kontrollierte Entwurfs-/Rechte-
prüfung durchführen. Bis dahin keine Freigabe und keine Behauptung „0 Befunde“.

## Origin-Anbindung

Implementierungscommit `32d3838002baa7e90e66e710f56ea985413d7ec5` wurde auf
`origin/ci/phase-6-06` gepusht. Gitea hat daraufhin
[Actions-Lauf 1](https://git.rfc1437.de/hugo/TerminalBasic/actions/runs/1)
(API-ID 542) erzeugt; beim Nachlesen Status `queued`. Damit sind Workflow-
Erkennung und Push-Anbindung belegt, keine ausgeführten Jobs oder Zielergebnisse.
`origin/main` bleibt beim abgeschlossenen Change 05 (`7965647`).
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.