re0-release

このリポジトリの出荷・リリースチェックリストを保留中の変更に適用し、確認後にタグを付けて公開します。

目標

毎回出荷・リリースチェックリストを手作業で作り直す代わりに、「リリースを準備して出荷する」を明確な1つのコマンドにします。インストールされている場合は sip を実行し、コミットエコノミーを直接適用します。また、ユーザーが呼び出した別のスキルを自動的に起動することはありません。「コミット」と「タグ付け＋プッシュ」を、それぞれ別個の重要なタイミングとして扱います。コミットはローカルにとどまり、元に戻せます。公開されるのはタグ付け＋プッシュの手順だけです。

ワークフロー

1. 保留中の差分を基に、リリース可能な状態か確認します。AGENTS.md の Shipping チェックリストのうち、バージョン更新と sip の実行（ここでは手順 2 と 3）を除く、該当するすべての項目を確認してください。
   • 新規または変更された SKILL.md の形式が正しいこと（フロントマターに name と description があること、ユーザー起動の場合に限り disable-model-invocation を設定すること、本文に Goal／Workflow／Rules／Verification の各セクションがあること）。
   • README と docs/readme/ 配下のすべてのローカライズ版に、正しい起動列とロスター内の論理的な順序で、正確に記載されていること。plugin.json、scripts/catalog.cjs、re0-upgrade のカタログでも同じ順序を保ち、reorder と足並みを揃えてください。README の Problem の削除対象リストと Fixes の説明に含めるのは、その主張の要となる場合に限ります（大半のスキルはどちらにも該当しません。どちらも精選された内容です）。
   • plugin.json にそのパスが登録されていること。
   • 名前を変更した場合は、re0-upgrade の非推奨化チェックリストに、古い名前 → 新しい名前の行をリリース順に追加すること。
   • スキル間で共有するルール（edit-safety、negatives-as-corpus、commit-economy）を、それらが含まれるすべてのコピーで一貫させること。 不備があれば報告し、推測で先に進まず中止してください。
2. バージョン更新の種類を分類します。新しいスキルはマイナー、修正またはドキュメントのみの変更はパッチ、代替手段のないスキルの削除はメジャーです。既存スキルの拡張という境界ケースでは、規模ではなく変更の性質で判断してください。そのスキルの以前の仕様と比べて、従来の動作が誤っていたのか（修正なのでパッチ。修正のみを目的とする新しい仕組みもパッチ）、それとも正しいが範囲が狭かった／要素が不足していたのか（ユーザーが新たに利用する機能なのでマイナー）を判断します。バージョン番号だけでなく、その判断を明示してください。
3. sip がインストールされている場合は実行し、検出事項を適用します。インストールされていない場合は、チェックを順に直接実行して、検出事項を適用してください。cold-read（shower）、主張または評価がある場合に限り真偽チェック（factchk／mandela）、一貫性チェック（まず ssotize 監査を行い、統合は承認後にのみ実施）、最後に整理（re0）です。
4. 手順 2 の分類に従って、package.json のバージョンを更新します。
5. commit-economy に従ってコミットメッセージを作成します。実質的で持続性のある変更ごとに 1 つの箇条書きを設け、関連する編集はそこにまとめます。差分またはバージョンからすでに明らかな内容は含めず、共同作成者タグも付けません。ローカルログの書式に合わせてください。書式がない場合は、件名と、変更ごとに 1 つの - 箇条書きを、折り返しのない 1 行に収めます。最初の草案から作成し、編集のたびに追記していく方法は避けてください。コミットがすでに存在し、整理が必要な場合は、人間に re0-git の実行を依頼してください。自動で実行してはいけません。
6. 明示的な確認を求めてから、コミットします。
7. .re0/release/RELEASE_NOTES.local.md を作成します。このファイルは Git の追跡対象外で、リリースには同梱されないローカル用の作業ファイルですが、署名付きタグのメッセージとして使います。次のプロジェクト内の書式に従ってください。バージョンではなくリリースの持続性のある主旨を示す ## 見出しを 1 つ、現在の状態を表す短い現在形の段落を 1 つ記載します。リリースに該当するセクションのみを含めます（### New、### Also、ロスターの再マッピングが必要な場合に限る ### The catalog (N skills)、常に最後に置くインデント付きブロックの ### Install）。外部からの貢献は、それぞれ PR 番号と作者のハンドルを本文中に記載します（(#123, @handle)）。スキル名とパスはバッククォートで囲みます。タグやバージョンからすでに明らかな内容は含めません。
8. タグ付けとプッシュについては、これとは別に 2 回目の確認を求めます。公開されるのはこの手順だけです。その後、次を実行します。git tag -s vX.Y.Z -F .re0/release/RELEASE_NOTES.local.md --cleanup=verbatim を実行し、git tag -v vX.Y.Z で有効な署名が報告されることを確認してから、main をプッシュし、タグをプッシュします。
9. 起動したリリースワークフローの完了まで監視し、成功または実際の失敗を報告します。公開されたと決めつけてはいけません。失敗した場合は原因を修正して再実行してください。作成者が誤った内容で切ったタグ（メッセージ、署名、対象が誤っている場合）は、バージョンを上げずに削除して同じバージョンで切り直します。公開成果物に誤りがある場合に限り、バージョンを進めます。ワークフローの作業を手動で完了させてはいけません。
10. 成功を確認したら、リリースに含まれた外部からの貢献をそれぞれクローズします。クローズ前に、その貢献をレビューした人が PR を承認します。リリースに向けてコミットをまとめるか再構築した貢献はマージせずにクローズし、承認を記録することで、拒否ではなく受け入れられたことを示します。クローズ時のコメントには、リリースノートに記載した謝辞を含めます。レビュー権限を持つ共同作業者またはメンテナーであれば誰でも対応でき、特定のレビュアーに限定されません。
11. その後、リリース済みのサイクルを終了します。.re0/iteration/<version>-<workname>/ フォルダーを名前を変更せずに .re0/iteration/completed/<version>-<workname>/ へ移動します。.re0/ は Git の追跡対象外なので、通常のファイルシステム移動（mv）を使い、git mv は使わないでください。追跡対象外のパスでは git mv が失敗します。このサイクルで re0-plan を使って計画しておらず、対応するイテレーションフォルダーもない場合に限り、この手順を省略します。

ルール

• CLI コマンドやフラグを決して創作したり、推測したりしないでください。実行する手順に記載する前に、公式ドキュメントまたは実際の実行で確認してください。
• プッシュが唯一の手動手順です。 リリースワークフローが担当する手順（公開、リリースページのタイトル設定など）を手作業で実行してはいけません。失敗した実行を救済するためであっても同様です。唯一の例外は、作者自身の不備があるタグを再作成すること（手順 9）です。この場合も再度プッシュし、残りの作業は引き続きワークフローに任せます。手作業で実行すると、成果物以外にワークフローが付与する要素（署名付きの来歴証明、タイトル規約、dist-tag）が欠落します。それでもリリース自体は正常に見えるため、何も失敗せず、前回のリリースとの比較をして初めてその欠落が明らかになります。
• 未処理の差分に無関係な内容が混在している場合は、メッセージを作成する前にその点を伝え、分割を提案してください。1 つのコミットメッセージに差分の役割まで担わせてはいけません。
• ローカルのバージョンが一致する（package.json が作成予定のタグと一致する）前に、決してプッシュしてはいけません。CI チェックは最後の防衛線であり、最初の防衛線ではありません。
• negatives-as-corpus — リタイア時はイテレーションフォルダーを移動し、削除してはいけません。リリースが失敗した場合やロールバックされた場合は、実際にはリリースされていないサイクルをリタイアせず、フォルダーをそのまま残してください。

検証

完了前に、次の項目を確認してください。

1. package.json のバージョンがタグと一致している。
2. コミットメッセージが、差分を見なくても明確な引き継ぎ内容になっている。
3. リリースノートが所定のスタイルに従い、このリリースで得られる内容だけに言及している。
4. プッシュしたタグによって実行されたワークフローが正常に完了したことを、推測ではなく確認している。
5. 失敗した実行の救済を含め、ワークフローが担当する手順を手作業で実行していない。
6. リリースに含まれた各外部からの貢献について、PR がクローズされる前に承認され、クレジットコメントが付与されている。
7. リリースされたサイクルのイテレーションフォルダーを .re0/iteration/completed/ に移動したか、該当するフォルダーが存在しないため正しくスキップしている。
8. スキップした手順や未解決の問題があれば報告する。