fable-release

Fable リリース

ユーザーが受け取る正確なコミットと成果物がリリース可能な状態であることを証明し、その準備状況と実際の配布を区別します。

ミッション

リリースとは、外部の状態遷移です。ソースのテストに問題がなくても、パッケージにファイルが含まれていなかったり、タグが別のコミットを指していたり、レジストリで古いバージョンが引き続き配信されていたり、公開された成果物がクリーンな環境で起動できなかったりする可能性があります。

このスキルでは、リリースに関する主張を、正確なバージョン、コミット、成果物、ワークフロー、タグ、レジストリの証拠に結び付けることで、この隔たりを埋めます。

次の場合に有効化

• ブランチをマージする準備、またはバージョンをリリースする準備をするとき。
• バージョンタグを作成／プッシュするとき。
• npm／パッケージ／プラグインの成果物を公開するとき。
• GitHub Release を最終確定するとき。
• 配布チャネルで意図したバージョンが実際に配信されていることを検証するとき。
• 直前の変更後もリリースの証拠が最新かどうかを評価するとき。

次の場合は有効化しない

• 実装がまだ変更中であるとき（fable-execute／fable-tdd）。
• 機能検証が完了していないとき（fable-verify）。
• 対応が必要なレビュー／セキュリティ上の指摘が残っているとき。
• ユーザーが取り消し不能な公開操作を承認していないとき。準備状況の確認は実施できますが、公開には該当する承認が必要です。

リリースの分類

リリースの種類	追加で考慮する事項
マージのみ	ブランチ／ベースの最新性、必須 CI、レビュー
パッケージレジストリ	パッケージの内容、クリーンインストール、レジストリでの検証
Git タグ／GitHub Release	タグと SHA の紐付け、リリースノート／アセット、ドラフト／プレリリースの状態
プラグイン／マーケットプレイス	マニフェスト／バージョンの整合性、提出／承認の状態
移行を伴うリリース	展開順序、後方互換性、ロールバック
セキュリティ上重要なリリース	アドバイザリ／シークレット／依存関係のゲート、開示上の制約

プロトコル

ステージ 1 — 候補を固定する

正確な候補を特定します。

• バージョン。
• コミット SHA。
• 対象ブランチ／タグ。
• 配布チャネル。
• 必須の CI／レビュー／セキュリティの証拠。

この時点以降にソース／設定／パッケージを変更すると、関連するリリースの証拠は無効になり、新しい候補が作成されます。

ステージ 2 — バージョンの意味を検証する

以下を確認します。

• 対象レジストリ／タグの名前空間に、そのバージョンがまだ存在しないこと。
• SemVer が実際の互換性への影響に合致していること。
• 正式なすべてのバージョン記載箇所／マニフェストの内容が一致していること。
• 変更履歴／リリースノートが、ユーザーに見える変更を正確に説明していること。
• プレリリースの状態が意図したものであること。

都合だけを理由にパッチ／マイナー／メジャーを選ばないでください。

ステージ 3 — 最新の品質ゲートを再確認する

必要な機能／ビルド／レビュー／セキュリティの証拠が、候補の SHA／変更世代に対応していることを検証します。候補の変更前に証拠が作成されていた場合は、再実行します。

• 利用可能な場合は、ブランチのプッシュを no-mistakes プロキシ（git push no-mistakes または no-mistakes axi run）経由で行い、リモートへのマージ前にリベース、自動レビュー、テスト、lint、ドキュメントの各チェックを通過させます。

ステージ 4 — 成果物の境界を調べる

正確な成果物をビルド／ドライランし、そのマニフェスト／内容を確認します。

以下を確認します。

• 必須のエントリーポイント／アセット／マニフェストが存在し、空でないこと。
• シークレット、一時ファイル、テスト／フィクスチャ／内部用の保留ファイルが、意図的に公開する場合を除き、除外されていること。
• 生成ファイルが最新であること。
• 実行権限／エクスポート／bin パスが正しいこと。
• 依存関係／ランタイムの制約が正確であること。

ステージ 5 — クリーンな環境でスモークテストする

可能な場合は、ソースのチェックアウト外で生成した成果物をインストールして使用します。

少なくとも以下を証明します。

• インストールが成功すること。
• 主な実行ファイル／インポートが解決されること。
• バージョン／ヘルプ／基本的なスモークテストが動作すること。
• ドキュメントに記載されたクイックスタート手順が、リポジトリ内のファイルに誤って依存していないこと。

ステージ 6 — リポジトリのリリース状態を検証する

公開前に、以下を確認します。

• 候補コミットがプッシュされていること。
• 候補に対する必須 CI が成功していること。
• タグが存在しないか、存在する場合は意図した SHA を正確に指していること。
• リリースノート／アセットが同じタグ／SHA を対象にしていること。
• ブランチがベースブランチに対して既知の不具合を抱えていないこと。

ステージ 7 — 認可された安全な経路のみで公開する

長期間有効なトークンを導入するのではなく、設定済みの信頼できる公開方式／OIDC／ホスト側の自動化を優先してください。

リリースを通すために、認証情報を表示・保存したり、セキュリティを弱めたりしないでください。

認可または認証がない場合は、残っている作業を正確に示して READY_NOT_PUBLISHED の状態で停止してください。

ステージ 8 — 配布状況を独立して確認する

公開後、公開コマンドを信頼するのではなく、外部の配布先に問い合わせてください。

確認例：

• レジストリで想定したバージョン／配布メタデータが報告される；
• レジストリからのクリーンインストールが成功する；
• Git タグが候補の SHA を参照している；
• GitHub Release が実際に公開されており、下書きではない；
• マーケットプレイスのステータスが申請済み／公開済みの状態を反映している。

ステージ 9 — リリース後のスモークテストと引き継ぎ

公開配布経由で、ユーザー向けのインストール／呼び出し手順を実行してください。確認されたロールバック／非推奨化／フォローアップの課題を記録してください。

リリース判定

• NOT_READY：必須の決定的な検証／レビュー／セキュリティ／成果物のゲートが失敗しています。
• READY_NOT_PUBLISHED：候補に問題はありませんが、公開が認可されていない／利用できない／要求されていません。
• PUBLISHED_UNVERIFIED：公開コマンド／ワークフローは成功を示していますが、外部配布が独立して確認されていません。
• RELEASED：正確な候補が意図したチャネルで公開され、独立して確認されています。

これらの状態を「完了」にまとめないでください。

判断ルール

• 汚れたワークツリーでも、変更がリリースと無関係であることが明確で、リリース成果物がクリーンな候補 SHA から作成されている場合は、自動的に失敗とはなりません。ただし、未コミットのリリース変更がある場合は、準備完了と判定できません。
• タグが異なる SHA に存在する → 即時停止してください。リリースタグを安易に移動／強制更新してはいけません。
• パッケージのバージョンが不変のレジストリにすでに存在する → 有効な新しいバージョンを選び、上書きしないでください。
• ドライランの内容が想定する公開範囲と異なる → タグ付け／公開の前にパッケージ設定を修正してください。
• リポジトリのリンクからのローカルなグローバルインストールは成功するが、クリーンな tarball／レジストリからのインストールが失敗する → NOT_READY。
• 古いコミットで CI が成功している → リリースの根拠としては古くなっています。
• GitHub Release が下書きである → 公開リリースの根拠にはなりません。
• 公開ワークフローは成功しているが、レジストリがまだ更新されていない → 独立して確認されるか、既知の反映ポリシーが解決されるまで PUBLISHED_UNVERIFIED としてください。
• マーケットプレイスで手動承認が必要 → 申請状況を正確に報告してください。公開済みと主張してはいけません。

不変条件

• リリースのバージョン、コミット、タグ、成果物、公開メタデータは、同一の候補を参照しています。
• 認証情報をコミットしたり、リリースの証拠としてログに記録したりしません。
• 取り消せない外部への書き込みには、適用される認可が必要です。
• 公開に関する主張は外部で確認されています。
• 直前の変更により、古くなった候補の証拠は無効になります。
• リリースノートで、最新の証拠によって裏付けられていない成熟度／機能を主張しません。

失敗の分類

成果物の欠落／混入

パッケージから実行時ファイルが欠落しているか、秘密情報／内部資料が含まれています。境界を修正し、再ビルドし、スモークテストを再実行してください。

バージョンの不一致

マニフェスト／変更履歴／CLI／タグの内容が一致していません。リリース前に整合させてください。

候補の不一致

リリースコミットの変更後も CI／証拠が古い SHA を指しています。ゲートを再実行してください。

タグの不一致

既存のタグが別の場所を指しています。停止して調査してください。強制移動してはいけません。

公開／認証の失敗

候補は READY_NOT_PUBLISHED のままにできます。認証情報を埋め込まずに、安全な認証／ワークフローの問題を診断してください。

レジストリ／リリースの不一致

公開は成功したと報告されていますが、公開チャネルで誤った／古い成果物が提供されています。PUBLISHED_UNVERIFIED のままにして調査してください。

クリーンインストールの失敗

成果物がリポジトリ内のファイル／開発時の状態に依存しています。ソースのテストが成功していても NOT_READY です。

アンチパターン

• 「テストに合格したら公開する」
• 成果物の内容を確認する前にタグを付ける
• インストールテストをソースチェックアウトだけで済ませる
• タグを強制的に移動する
• 信頼された公開を回避するため、トークンを設定やドキュメントに追加する
• ドラフトリリースを公開リリースと同一視する
• レジストリやリリースを確認せず、ワークフローの成功を信頼する
• 公開を確認する前に、利用可能であると主張するようドキュメントを更新する
• 変更後の動作を示す証拠が古いまま、成熟度が100%だと主張する

リリース証明

Version:
Candidate SHA:
Target channels:
Fresh quality gates:
Artifact manifest check:
Clean-install smoke:
Tag → SHA:
GitHub Release state:
Registry/marketplace state:
External verification:
Verdict: NOT_READY | READY_NOT_PUBLISHED | PUBLISHED_UNVERIFIED | RELEASED
Rollback/follow-up:

完了条件

要求されたリリース段階が正確に証明された時点で、Skill の作業は完了です。

• 準備状況に関する主張が、特定の候補を示す証拠に紐づいている
• 該当する場合、成果物の境界とクリーンインストールが証明されている
• タグ、リリース、レジストリの状態に一貫性がある
• RELEASED とする前に、公開配布が独立して確認されている
• 未取得の認可や外部ゲートは、推測で解消せず、明示的な状態として示されている

段階的なリソース

• 詳細ガイド：references/artifact-and-distribution-verification.md
• 既存のリリースゲート：references/release-gates.md
• 例：examples/release-readiness-audit.md