yasrt — der Tag bestätigt, er kündigt nicht an.

Warum

semantic-release trifft die Entscheidungen richtig und die Mechanik falsch für CI: Es taggt, bevor irgendetwas gebaut ist. Es löst zur Laufzeit hunderte ungepinnte Pakete auf. Und es beurteilt „hat sich etwas Shippbares geändert?“ gegen die Push-Range statt gegen das letzte Release, so dass ein echter Fix, der mit einer CI-Änderung gebündelt ankommt, nie shippt.

yasrt behält die Entscheidungen (dieselben Commit-Konventionen, dieselbe Versionsarithmetik, dieselbe Changelog-Form) und repariert die Mechanik. Der Tag bestätigt ein Artefakt, das schon existiert, statt eines anzukündigen, das es vielleicht geben wird. In meinem Estate hat genau das ~30 Repositories mit Tags ohne Image hinterlassen, an einem einzigen Abend; seitdem taggt hier nichts mehr vor dem Build.

Drei Kommandos

yasrt next --output .release.env   # entscheiden; schreibt nichts ins Repository
yasrt check                        # Konfiguration prüfen, Umgebung sondieren
yasrt release                      # veröffentlichen; idempotent, gefahrlos wiederholbar

next legt seine Entscheidung in einer dotenv-Datei ab: RELEASE_STATUS ist release, no-bump, not-deliverable oder already-released, daneben RELEASE_VERSION, RELEASE_TAG, RELEASE_PREVIOUS, RELEASE_BUMP, RELEASE_REASON und RELEASE_COMMIT. Dein Build liest sie; release liest sie zurück und weigert sich, etwas anderes zu taggen als den analysierten Commit. Die Schlüssel und die Exit-Codes sind eine öffentliche Schnittstelle.