openclaw-changelog-update

OpenClaw 変更履歴更新（Changelog Update）

変更履歴の書き換えおよび GitHub リリースノートのソーステキストに使用します。通常のベータ版/安定版リリースでは、最終ソースの認定が可能な場合は、可能な限り完全なノートを作成してください。その場合、コード SHA がリリース SHA になることもあります。編集作業はコードの検証と重複しても構いません。検証回復のためのバックポートごとに再実行しないでください。バックポートによってコード SHA が置き換えられた場合、最終的なコード SHA がグリーンになった後に 1 回だけ再実行します。これは、既存のプロダクトエビデンス再利用ポリシーの下での、正当な CHANGELOG のみの子孫となります（タイミングを参照）。拡張安定版リリースの場合は、最終的な正確な HEAD 検証とタグ付けの前に実行します。ツールの再試行、公開の再開、プロモーションのために再実行しないでください。 release-openclaw-maintainer と組み合わせて使用します。このスキルは、変更履歴の内容、順序、グループ化、帰属の規律を担当します。

目標

対象の CHANGELOG/<version>.md リリースセクションを、古いドラフトノートではなく、完全で生成された履歴マニフェストから再構築します。関連するすべての Issue/PR 参照と、検証済みの人間による Thanks @... 帰属を保持しながら、ユーザーの関心順にグループ化された、ユーザー向けのリリースノートを作成します。

CHANGELOG.md は、生成されたリリースインデックスです。共有の所有者 scripts/lib/release-changelog.mjs は、ワーキングツリーまたは固定された Git 参照（モノリスをまだ含む過去の参照を含む）から、リリースセクションとコントリビューションレコードを解決します。セクションを取得するには node scripts/release-changelog.mjs read --version <version> [--ref <sha-or-tag>] を使用し、コントリビューションレコードを取得するには --record を追加します。分割されたアーティファクトが見つからない場合、ルートインデックスにフォールバックしてはいけません。レコードのない過去のリリースには、捏造された来歴を付与してはいけません。生成された CHANGELOG/** ファイルは、正確に移行またはミラーリングされたバイトを保持し、ルート変更履歴と同様に、一般的なフォーマットから除外されます。所有者を通じて pnpm changelog:check で検証します。

現在の書き込みは分割レイアウトを使用します。完全な初期セクションを保存するには、node scripts/release-changelog.mjs write --version <version> --file <section.md> を使用します。これにより、リリースエントリが更新され、CHANGELOG/records/<version>.md が存在する場合はそれと一致し、インデックスも一緒に更新されます。初期生成では、以下のセクション形式を保持します。公開ドキュメントのミラーは、このスキルの最後にある別のリリース後ルートに従います。初期生成は決してそれらを上書きしてはいけません。

入力

• ターゲットバージョン：ベータ版デルタの場合は正確な YYYY.M.PATCH-beta.N、累積安定版ノートの場合は YYYY.M.PATCH。ベータ版エントリとレコードは独立した凍結アーティファクトであり、安定版ベースセクションのコピーではありません。
• ベータ版ベースタグ：公開前に、公開 npm openclaw@beta によって現在選択されているバージョンをキャプチャします。最後の GitHub プレリリースや最も高いベータサフィックスバージョンではありません。セレクタは latest によっても選択される安定版バージョンを指定する場合があります。正確なベータバージョンで --base を省略するか（または --base npm-beta を使用して）一度解決します。生成されたマニフェストから解決されたタグを保持し、編集、検証、復旧のためにその明示的な --base を再利用します。npm がすでに候補または新しいバージョンを選択している場合、生成は過去のセレクタ状態を推測することを拒否します。以前にキャプチャしたタグを指定してください。そのタグが祖先でない場合（たとえば、安定版クローズアウトフォワードポート）、検証ツールは到達可能なマージベースを使用し、--shipped-ref セマンティクスを通じて、キャプチャされた出荷タグの累積 PR レコードを差し引きます。マニフェストとレコードは両方の境界を保持します。キャプチャされたタグで再生して同じ範囲を解決し、古い GitHub ベータを代わりに選択しないでください。
• 安定版ベースタグ：最後に到達可能な出荷済み安定版リリースタグ。ターゲットの祖先である必要があります。新しいが分岐したタグは有効な履歴境界ではありません。明示的な出荷済み/メインクローズアウト SHA は、それがターゲットからも到達可能な場合にのみ使用します。
• ターゲット参照：文書化されている正確な製品完全履歴。そのコントリビューションレコードターゲットは、最終リリースターゲットの祖先である必要があります。まだ作成されていない変更履歴コミットを指定する必要はありません。最終決定前に後続の修正を含めます。最終ノートは認定前にコミットするか、グリーンなコード SHA の CHANGELOG のみの子孫として後でコミットします。
• 正規のメイン参照：検証前にフェッチされた、現在の origin/main。リリースノートは、同じ作業がバックポートによって運ばれる場合、元のマージされたメイン PR を引用します。現在のメインにフォワードポートが存在しない場合にのみ、リリースブランチ PR を使用します。

ワークフロー

1. リリースブランチと正確な履歴ターゲットを確認します：

   • git fetch --tags origin
   • クリーンな git status -sb を確認
   • git rev-parse HEAD を履歴ターゲットとして記録
   • 認定が既に存在する場合、完全リリース検証の実行 ID と試行を記録
   • 最終ソースを凍結する前に、保留中のプロダクト/バージョン/バックポートの変更を完了します。実際の変更のためにインベントリを更新します

2. 直接コミットを含む履歴を監査します：

   • git log --topo-order --date=iso-strict --pretty=format:'%h%x09%ad%x09%s' <base-tag>..<target-ref>
   • git log --topo-order --grep='(#' --date=short --pretty=format:'%h%x09%ad%x09%s' <base-tag>..<target-ref>
   • マージされたサイドブランチを含む、ベースからは到達できないがターゲットからは到達可能なすべてのコミットを含めます。重複を排除し、出荷済みレコードを差し引く前に PR の関連付けを解決します。既存のリバート除外を保持します。
   • メインがリリース中に移動した場合は、--since='24 hours ago' も検査します。

3. グループ化された散文を書く前に、完全なコントリビューションレコードと編集マニフェストを生成します：

   node --import tsx .agents/skills/openclaw-changelog-update/scripts/verify-release-notes.mjs \
     --base <base-tag> \
     --target <target-ref> \
     --release-branch <canonical-release-branch> \
     --main-ref origin/main \
     --version <YYYY.M.PATCH> \
     --manifest /tmp/openclaw-release-<YYYY.M.PATCH>.json \
     --write-ledger
   

   ベータ版生成の場合、--version YYYY.M.PATCH-beta.N を使用し、最初のインベントリ実行では --base を省略します。共有ライターを使用して、ハイライト、変更点、修正点を含む正確なバージョンセクションを開始します。デルタマニフェストを生成し、その範囲の散文のみを記述します。後続の実行では、キャプチャされた npm ベースラインタグを明示的に使用します（分岐範囲のマージベース SHA のみではありません）。公開後は npm に再度問い合わせたり、累積安定版エントリを上書きしたりしないでください。安定版準備時に累積安定版ノートを再生成します。

   リリースコミットが来歴メタデータを伝達できない場合、反復可能な --release-provenance '<40sha> -> #PR[, #PR]' 入力を追加します。これらはコミット本文マーカーと同じ正確なマーカー文法とソース検証を使用します。マージされたリリースブランチオリジナルは、対応する現在のメインフォワードポートが存在しない場合にのみ有効です。その GitHub マージコミットが元のソースを固定します。

   検証ツールは、ワークツリーの git メタデータの下での正確なベース/ターゲット SHA スナップショットからの公開 GitHub GraphQL 応答を自動的に再利用します。同じターゲットでの反復的な書き換えは、ネットワークの再探索を回避します。API データが疑わしい場合は --refresh-github-snapshot、明示的なアーティファクトの場合は --github-snapshot <path>、ライブのみの監査の場合は --no-github-snapshot を使用します。GitHub リリース本文は常にライブで読み取られます。 アクティブソース内の明示的な CI #、CI run #、Actions run #、workflow run # 参照は、Issue/PR 解決が失敗し、ライブの同一リポジトリ Actions ルックアップが正確な実行 ID を確認した場合にのみ、個別に分類されます。アクティブソース、ノート、またはコントリビューションレコード内のその番号の通常の出現は、厳格な Issue/PR 要件のままです。確認された実行は、検証出力とマニフェストでは workflowRuns として表示され、PR の関連付けやコントリビューターのクレジットとしては表示されません。 コンテキスト上のコミット本文テキストに限定され、件名、クロージング参照、来歴、ノート/レコードに存在せず、解決された最高の番号未満である GitHub NOT_FOUND 参照のみが、クレジットなしで省略され、マニフェスト unavailableReferences として報告される場合があります。

   • マニフェストは書き換えに必要な入力であり、事後監査ではありません。参照されるすべての PR、対象となるコントリビュータークレジット、インライン Issue コンテキスト、すべての直接コミット、および PR と直接コミットの編集適格性分類が含まれます。
   • スキーマバージョン 3 は、必要な一時的なマニフェスト契約です。古いマニフェストを再生成します。バージョン 2 はサポートされるダウンストリームリーダー境界ではありません。
   • 過去のバックフィルの場合、--seed-ref <pre-backfill-ref> を 1 回追加して、古いマージされたコミットが PR 番号を省略した場合でも、以前の変更履歴からのコントリビューションレコードが保持されるようにします。検証ツールは、ベースタグ以降にリバートされた作業（安定版リリース前にリバートされたベータ作業を含む）のレコードを除外します。
   • 生成された来歴レポートは、範囲内の PR を保持されたシードのみの PR と個別に表示し、一意の行の総数を示します。両方のインベントリに存在する PR は範囲内としてカウントされます。シードを含む総数を現在のリリース範囲でマージされた作業として説明しないでください。
   • 到達可能なメインクローズアウトが出荷タグまたは後のフォワードポートコミットがすでにリリースされた PR を再関連付ける場合、反復可能な --shipped-ref <prior-shipped-tag> を追加します。各タグは累積的な出荷境界です。検証ツールは、番号付きリリースセクションの完全なコントリビューションレコードからの明示的な PR 行を結合し、重複する PR のみを除外し、Unreleased は無視します。この境界をベース SHA、ターゲット散文、またはターゲットレコードから推測しないでください。マニフェストと生成された来歴は、決定論的な候補検証のために、各タグと除外された正確な PR インベントリとカウントを保持します。
   • ソース PR 発見は、GitHub コミットの関連付けを選択されたターゲット履歴、または正規のキャリアの場合は凍結されたメイン履歴にバインドします。コンテキスト上のソース参照は、マージされたコミットがターゲット履歴内で到達可能であり、マージ時間がターゲット内にある場合にのみ、コントリビューションになります。すべての参照を解決可能に保ちますが、リリース準備が続行されている間にマージされるという理由だけで、無関係な PR を昇格させないでください。明示的なシードは、その歴史的なメンバーシップを保持し、独立して範囲内であることが証明されない限り、シードのみのままです。関連付けのすべてのページを解決します。既存の正規、チェリーピック、来歴契約は引き続き信頼できます。
   • 明示的なマルチコミットリバートには、リバート件名と 1 つのスタンドアロン Reverts <full SHA> and <full SHA>. 宣言が必要です（カンマ区切りのリストと最後の and も機能します）。正確な末尾 to restore the previous behavior. は受け入れられます。重複、省略、埋め込み、繰り返しの宣言はリバートを確立しません。名前付きの各コミットは単一の親祖先である必要があり、名前付きのすべてのパッチを逆適用すると、完全なリバートツリーが再現される必要があります。この証明に失敗した認識された宣言は、検証を停止します。証明は、フックや外部差分なしでプライベートな Git インデックス/オブジェクトストレージを使用します。正規の単一リバートおよびリバート・オブ・リバートの会計はそのまま維持されます。
   • バックポートを main 上の元のマージされた PR に正規化します。明示的なチェリーピック元が優先され、次に一意の正規化されたサブジェクト一致には同じ著者と重複する変更パスが必要です。対応する main PR が現在の origin/main に存在する場合は常に、リリース/バックポート PR を抑制します。変更が最初にリリースブランチにランディングし、まだ main にフォワードポートされていない場合にのみ、リリースブランチ PR を保持します。
   • ### Highlights、### Changes、### Fixes を編集する前にマニフェストを読み取ります。再監査せずに古いグループ化された散文を前方に引き継がないでください。
   • あいまいなコミットについては、リンクされた PR/Issue または差分を検査します。直接コミットは編集入力であり、公開元帳の行ではありません。件名、本文、タッチされたファイル、テスト、近隣のコミットから、実質的なユーザー成果を推測します。

4. 選択した 1 つのリリースセクションのみを書き換えます：

   • ベータ版：## YYYY.M.PATCH-beta.N。キャプチャされた npm ベータベースライン以降の変更のみを含めます。
   • 安定版：## YYYY.M.PATCH。以前の安定版ベースライン以降の累積。
   • ターゲットリリースの上に古い ## Unreleased セクションを残さないでください。
   • Unreleased にリリース対象のノートが含まれている場合は、削除せずにターゲットセクションにマージします。

5. セクションの構成：

   • ### Highlights：安定版の場合は 5〜8 個の箇条書き、ベータデルタの場合は 0〜8 個。小さなホットフィックスベータ版のためにハイライトを捏造しないでください。
     • 明確なユーザーに表示可能な機能またはワークフローの解放、実質的な信頼性/安全性の修正、広範なクロスサーフェスの改善、またはリリースを定義する統合/互換性のマイルストーンのみを含めます。
     • すべてのハイライトは、1 文でユーザーにとって何が変わったかを述べる必要があります。箇条書きごとに 1 つのユーザーストーリーを使用し、サポート PR をグループ化します。
     • テスト、CI、リファクタリング、ドキュメント、カタログの変動、実装の詳細は、結果が実質的なインストール/更新、データ安全、または広く見えるユーザー改善でない限り除外します。
   • ### Changes：新しい機能と動作の変更。
   • ### Fixes：ユーザー向けの修正を最初に、影響とサーフェスでグループ化します。
   • 関連する変更/修正は、サーフェスとユーザーへの影響でグループ化します。複数のコミットが 1 つのユーザー向けストーリーを構成する場合、小さなコミットごとに 1 つの箇条書きを避けます。
   • ### Complete contribution record：グループ化された散文の後に、生成された PR 優先のレコード。これは、網羅的な会計面であり、2 番目のリリース概要ではありません。

6. 検証済みの帰属を保持します：

   • PR の著者は、正規の GitHub PR から取得され、リリースコミットの作成者、コミッター、またはバックポートオペレーターからは決して取得されません。コーサーはその PR の元のマージコミットから解決します。リリースキャリアのトレーラーやコンテキスト上の言及は、別の PR でのクレジットを確立しません。
   • PR、元のコーサー、リンクされたレポーターの証拠から、生成された感謝を再構築します。シードは、メンバーシップと参照を保持しますが、検証されていない古いデータは保持しません。