OpenClaw チェンジログ更新

OpenClaw チェンジログ更新 は何をしますか？

チェンジログの書き換えや GitHub リリースノートのソーステキストに使用します。通常のベータ版/安定版では、可能な限り最終ソースの認定前に完全なノートを準備してください。その場合、コード SHA がリリース SHA になることもあります。編集作業はコード検証と重複する場合があります。検証復旧のバックポートごとに再実行しないでください。バックポートがコード SHA を置き換える場合、最終的なコード SHA がグリーンになった後に一度だけ再実行します。これは、既存の成果物再利用ポリシー（タイミング）に基づく、正真正銘の 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 のみの子孫として後からコミットすることもできます。
• 標準 main 参照: 検証前にフェッチされた現在の origin/main。リリースノートは、同じ作業がバックポートによって運ばれる場合、元のマージされた main PR を引用します。バックポートが現在の main にフォワードポートとして存在しない場合にのみ、リリースブランチ 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 関連付けを解決する。既存のリバート除外を保持する。
   • リリース中に main が移動した場合は、--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 を省略します。共有ライターを使用して、正確なバージョンセクションを Highlights、Changes、Fixes の順で開始します。デルタマニフェストを生成し、その範囲の散文のみを記述します。以降の実行では、キャプチャした npm ベースラインタグを明示的に使用します（分岐範囲のマージベース SHA だけではありません）。公開後は npm に再度問い合わせたり、累積安定版エントリを上書きしたりしないでください。安定版準備時に累積安定版ノートを再生成します。

   リリースコミットが来歴メタデータを伝達できない場合は、繰り返し可能な --release-provenance '<40sha> -> #PR[, #PR]' 入力を追加します。これらは、コミット本文マーカーと同じ正確なマーカー文法と現在の main 検証を使用します。

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

   • マニフェストは書き換えに必要な入力であり、事後監査ではありません。参照されたすべての PR、適格な貢献者クレジット、インライン Issue コンテキスト、すべての直接コミット、および PR と直接コミットの編集適格性分類が含まれます。
   • スキーマバージョン 3 は必須の一時的なマニフェスト契約です。古いマニフェストを再生成します。バージョン 2 はサポートされているダウンストリームリーダー境界ではありません。
   • 過去のバックフィルの場合は、--seed-ref <pre-backfill-ref> を 1 回追加して、以前のチェンジログからの貢献記録が、古いマージコミットが PR 番号を省略した場合でも保持されるようにします。検証機能は、ベースタグ後にリバートされた作業（安定版リリース前にリバートされたベータ作業を含む）の記録を除外します。
   • 生成された来歴レポートは、範囲内の PR を保持されたシードのみの PR とは別に報告し、一意の行の総数を示します。両方のインベントリに存在する PR は範囲内としてカウントされます。シードを含む総数を現在のリリース範囲でマージされた作業として説明しないでください。
   • 到達可能な main クローズアウトが出荷されたタグまたは後のフォワードポートコミットがすでにリリースされた PR を再関連付ける場合と異なるときは、繰り返し可能な --shipped-ref <prior-shipped-tag> を追加します。各タグは累積出荷境界です。検証機能は、番号付きリリースセクションの完全な貢献記録から明示的な PR 行を結合し、重複する PR のみを除外し、Unreleased を無視します。この境界をベース SHA、ターゲット散文、またはターゲットレコードから推測しないでください。マニフェストと生成された来歴は、決定論的な候補検証のために、各タグと除外された正確な PR インベントリとカウントを保持します。
   • ソース PR 検出は、GitHub コミット関連付けを選択されたターゲット履歴、または標準キャリアの場合は凍結された main 履歴に制限します。文脈上のソース参照は、マージされたコミットがターゲット履歴内で到達可能であり、マージ時間がターゲット内にある場合にのみ貢献になります。すべての参照を解決可能に保ちますが、リリース準備中にマージされたという理由だけで無関係な 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、元の共著者、リンクされた報告者の証拠から再構築します。シードはメンバーシップと参照を保持しますが、未検証の古い感謝の言葉は保持しません。再生成は記録とグループ化された散文の古い生成されたクレジットを置き換えます。検証は、不足しているクレジットとサポートされていないクレジットの両方を拒否します。
   • キーワード

(以下略)