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

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.
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.
Alte Abnahmeskripte setzten das Entwicklerwerkzeug tb-template voraus. Sie verwenden vorhandene Paketmetadaten; der bisherige Entwicklerpfad bleibt für nicht paketierte Builds verfügbar.
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.
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.
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.
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 (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 (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.

14 KiB Raw Blame History Unescape Escape