releaselisted

# Sprint Coder Release リポジトリの `AGENTS.md` とこの手順を順守する。リリース単位でversionを一度だけ決め、署名・notarization済み成果物を検証してからGitHub Draft Releaseを更新する。 ## 原則 - release/build設定の変更は高リスクとして `codex/` 作業ブランチとPRを使う。 - 既存のユーザー変更を保持する。リリース作業の一時ファイルや成果物をcommitしない。 - 秘密鍵、証明書パスワード、token、USB tokenのPINを表示・保存・commitしない。 - ユーザーが明示しない限りtagをpushせず、Releaseを公開しない。Draftまでの権限と公開権限を分ける。 - tag、package version、対象commit、成果物内versionが一致しなければ停止する。 - 実在しないassetへのリンクをRelease本文に書かない。 - Windows成果物はWindows上、macOS成果物はmacOS上で作る。cross-buildしない。 ## 1. Versionをリリース時に一度だけ決める commitごとにversionを上げない。リリース準備を開始したときだけ、次の順で判定する。 1. `gh release list` と `gh release view` で、対象commitの祖先にある直近の公開stable releaseとtagを特定する。現在のpackage versionを基準versionにしない。 2. そのtagの次からリリース対象commitまでの全commit、merge済みPR、実差分を確認する。version bump commit自体は変更種別に数えない。 3. 各変更を下表で分類し、最も大きい変更種別をリリース全体へ一度だけ適用する。commit prefixは初期分類に使うが、実際のユーザー影響を優先する。 4. 基準versionから目標versionを計算する。package versionがすでに目標versionなら再度上げない。基準versionなら目標versionへ一度だけ更新する。その他の不一致は停止して理由を確認する。 5. version、lockfile、埋め込みclient versionを同じ目標versionへ揃える。同一リリース範囲では以後変更しない。 | 最大の変更 | 0.xでの更新 | 1.0.0以降 | 例 | | --- | --- | --- | --- | | PATCH | `0.4.0 → 0.4.1` | PATCH | bug fix、UI微調整、既存機能内のrefactor/perf、runtime依存更新 | | MINOR | `0.4.x → 0.5.0` | MINOR | 新機能、Provider、設定項目、主要UI、workflow | | BREAKING | `0.5.1 → 0.6.0` | MAJOR | 互換性を壊す変更 | 1.0.0未満ではMAJORを通常使わず、breaking changeもMINORへ上げる。1.0.0以降のbreaking changeだけ次のMAJORへ上げる。 Conventional Commitsの既定分類は次とする。 - `feat:` はMINOR。 - `fix:`、`perf:`、`refactor:` はPATCH。 - `docs:`