release

Cyrus のリリース

信頼済みパブリッシングのワークフローを使って Cyrus をリリースします。ワークスペースのパッケージを手動で公開しないでください。

必読のリファレンス

リリース作業を始める前に、apps/cli/RELEASING.md を最後まで読んでください。これを正式な作業ガイド、scripts/release-packages.mjs を正式なパッケージ一覧および依存関係の順序として扱います。

リリースワークフロー、スクリプト、インストーラー、リリースドキュメントを編集しても、このリリース手順は実行されません。skills/f1-test-drive/SKILL.md の適用ポリシー F1 と対象を絞ったチェックを使って、これらの変更を検証してください。

ワークフロー

1. origin/main をフェッチし、最新の main を起点とし、無関係なローカル変更を保持します。
2. ブランチでリリースを準備します。
   • 両方の変更履歴にある Unreleased エントリーを新しいバージョンに移します。
   • node scripts/release-packages.mjs list で出力されるすべてのマニフェストに同じバージョンを設定します。
   • pnpm install を実行し、ロックファイルに変更があればコミットします。
   • 正式な適用ポリシー F1 に従い、前回のリリース以降のペイロード全体を評価します。これには、バージョン更新 PR より前にマージされた機能変更も含めます。F1 の対象となる動作変更については、関連する F1 シナリオを実行し、必須の -release-v<version>.md サフィックスを付けてエビデンスを保存します。それ以外の場合は、apps/cli/RELEASING.md に従って、ペイロードの評価と対象を絞ったチェックを F1 以外のリリース検証として記録します。F1 レポートを捏造しないでください。
   • CHANGELOG.md にリリースするすべての package@version を記載します。
3. node scripts/release-packages.mjs validate <version> を実行し、その後、apps/cli/RELEASING.md で必須とされているすべてのチェックを実行します。続行する前に失敗を修正してください。
4. コミットしてプッシュし、リリース PR を作成して、ワークフローをディスパッチする前に main にマージします。マージされていないソースや main 以外の参照を公開しないでください。
5. dry-run モードで、main から .github/workflows/release-cli.yml をディスパッチし、完了まで監視します。
6. ユーザーがライブリリースを明示的に依頼した場合に限り、同一のバージョンを dry_run=false でディスパッチします。npm への公開、Git タグ付け、GitHub Release の作成まで監視します。
7. npm 上のバージョンを独立して検証し、公開済み CLI の --version コマンドを実行します。
8. Linear 統合を使って、該当バージョンの変更履歴セクションで参照されているすべての課題を MergedUnreleased から ReleasedMonitoring に移動します。

安全性

• npm トークンを追加しないでください。公開には GitHub Actions OIDC を使用する必要があります。
• 最初のライブワークフロー実行の前に、すべての npm パッケージで cyrusagents/cyrus と release-cli.yml が信頼されていることを確認してください。
• dry run では npm に認証せず、レジストリへの書き込みも検証できません。
• 一部の公開が完了したバージョンを、何も調べずに再実行しないでください。npm のバージョンは変更できません。どのパッケージが公開されたかを確認し、慎重に復旧してください。
• すべてのパッケージが公開されるまで、リリースタグを作成または移動しないでください。タグと GitHub Release の作成はワークフローが担当します。