BaoCut Desktop-Veröffentlichungen
Dies ist die Electron v3 App (com.baocut.app). Das ältere baocut-app Skill dient nur als Referenz und nicht als ausführbarer Workflow dieses Checkouts. Halten Sie dieses Entwickler-Skill außerhalb der skills/ des App-Craft; rufen Sie keine legacy GPUI/npm/Homebrew Releases auf.
Wählen Sie den Workflow
| Benutzerabsicht | Lesen und befolgen |
|---|---|
| Normale Release-/Veröffentlichungsanfrage; keine Methode angegeben | Tag-Release — Standard. Pushen Sie den eingefrorenen Quell-Tag; veröffentlichen Sie zuerst verifiziertes Mac arm64, dann fügen Sie Windows CPU/CUDA/Vulkan zur selben Release hinzu. |
| Explizites lokales Paket/Candidate, traditionelles oder manuelles Release, Single-Platform-Wiederherstellung/Fortsetzung | Traditionelles Release. Berücksichtigen Sie die angeforderten Plattformen und den lokalen/öffentlichen Umfang. |
| Nur Signatur-Identität, portable Backups oder GitHub-Anmeldedaten | Signatur/Backups. Erstellen Sie keinen Tag und veröffentlichen Sie nicht. |
Laden Sie nur die Referenz, die für die ausgewählte Absicht benötigt wird. Fragen Sie Benutzer nicht, zwischen den beiden Release-Methoden zu wählen, wenn sie keine angegeben haben: Verwenden Sie das Tag-Release. Fallen Sie nicht stillschweigend auf traditionelles Packaging nach einem Actions-Fehler zurück. Eine spezifische lokale oder plattformspezifische Anweisung überschreibt den standardmäßigen plattformübergreifenden Umfang; folgen Sie der expliziten Methode und den Einschränkungen des Benutzers.
Gemeinsame Release-Einschränkungen
- Überprüfen Sie den Git-Status vor Änderungen; bewahren Sie nicht zusammenhängende oder parallele Arbeit. Führen Sie aufgabenbezogene Quellcode-Änderungen durch, bevor Sie ein Release einfrieren. Befolgen Sie die Regeln für Repository-Commit, aktuelle Aufgaben-Push-Autorisierung und Worktree-Bereinigung; verwenden Sie keine Push-Autorisierung aus einer anderen Aufgabe wieder oder fordern Sie sie erneut an, wenn sie bereits hier gewährt wurde.
apps/desktop/package.jsonbesitzt die App-Version. Synchronisieren Sie die Root-Version und Lockfile über npm; erhöhen Sie keine Cargo- oder Protokoll-Versionen für ein App-Release.- Fragen Sie tatsächliche Releases/Feeds ab, bevor Sie einen Build auswählen. Builds erhöhen sich strikt; bereits veröffentlichte Tags/Dateien sind unveränderlich.
- Halten Sie den Tag und alle Plattform-Artefakte an eine volle Quell-SHA gebunden. Versenden Sie niemals Binärdateien mit schmutzigen Quellen, privates Signatur-Material oder nicht abgeschlossene Notar-Einreichungen.
- Veröffentlichen Sie das Mac-Release, seine abgeglichenen Release-Notes und verifizierten Download-Links, sobald der Mac-Candidate besteht; Windows/CUDA-Builds blockieren diese Phase nicht. Spätere Plattform-Fertigstellungen aktualisieren die Assets, Notizen und Feeds dieser Release, niemals den Git-Tag oder dessen Quell-SHA. Melden Sie ausstehende Plattformen separat; setzen Sie Latest im unten stehenden Fertigstellungsschritt voran.
- Befolgen Sie für jede neue veröffentlichte Version/jeden neuen Build die Release-Notes: Erfassen Sie den vollständigen Commit/PR-Bereich, fassen Sie große Bereiche in Batches zusammen, gleichen Sie die Abdeckung ab und veröffentlichen Sie das konsolidierte Changelog. Ein lokaler Candidate behält dieselben Notizen lokal; Plattform-Fortsetzung verwendet den bestehenden Bereich der Version.
- Überprüfen Sie nach jeder öffentlichen Veröffentlichung oder Plattform-Fortsetzung die Download-Links mithilfe von Download-Links. Die READMEs und baocut.com verlinken auf
baocut.com/download/<id>, was automatisch GitHub Releases folgt. Bearbeiten Sie die READMEs nicht und stellen Sie die Seite nicht für ein Release neu bereit; überprüfen Sie, dass baocut.com den neuen Build ausliefert. - Melden Sie tatsächliche Prüfungen und Auslassungen. Ein Tag-Push oder eine Anmeldedaten-Prüfung allein ist kein abgeschlossenes Release; eine Veröffentlichung erfordert erfolgreiche Jobs, öffentliches Auslesen, Feeds, verifizierte Release-Notes und eine bestandene baocut.com Download-Prüfung.
Vollständiges öffentliches Release
Nachdem alle ausgewählten Plattformen veröffentlicht wurden, öffentliche Assets und Feeds das Auslesen bestanden haben und die konsolidierten Release-Notes verifiziert sind, markieren Sie die neueste stabile Desktop-Release als Latest im Reiter "Releases" von GitHub:
gh release edit "$release_tag" --repo "$release_repo" --latest
gh api "repos/$release_repo/releases/latest" --jq '.tag_name'
Verwenden Sie das verifizierte Repository und den Tag für diese Aufgabe; das Auslesen muss mit diesem Tag übereinstimmen. Plattform-Publisher bewahren den vorherigen Latest, während Validierung und Uploads laufen, daher ist dieser letzte Schritt auch dann erforderlich, wenn Actions erfolgreich ist. Lokale Candidates, Drafts und Prereleases setzen Latest nicht voran. Wenn Sie eine ältere Release fortsetzen, behalten Sie eine neuere veröffentlichte Desktop-Version/einen neueren Build als Latest. Fügen Sie den verifizierten Latest-Tag in den Fertigstellungsbericht ein.
Der Desktop-Leitfaden besitzt die Verpackungsmechaniken; modus-spezifische Referenzen erklären, wann dieser geladen werden muss. Anfragen nur zur Änderung der Release-Konfiguration dürfen keinen Release-Tag erstellen oder veröffentlichen.