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