openclaw-changelog-update

OpenClaw 変更履歴の更新

変更履歴の書き換えと GitHub リリースノートのソーステキストには、これを使用します。通常のベータ版／安定版では、可能であれば最終ソースの適格性確認の前に完全なノートを準備してください。その後、Code SHA が Release SHA になる場合もあります。編集作業は Code の検証と並行して行えます。検証リカバリーのバックポートごとに再実行しないでください。バックポートによって Code SHA が置き換わる場合は、最終的な Code SHA がグリーンになった後に一度だけ再実行してください。これは、既存の製品エビデンス再利用ポリシーに基づく、正当な CHANGELOG のみの子孫コミットです（タイミング）。extended-stable では、最終的な厳密な 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 を使うのは、それが対象からも到達可能な場合に限ります。
• 対象参照：記録対象となる、製品として完全な履歴です。その貢献記録の対象は最終リリース対象の祖先である必要がありますが、まだ作成されていない変更履歴コミットを指定する必要はありません。ノートを確定する前に、後続の修正をすべて含めてください。最終ノートは、適格性確認の前にコミットすることも、グリーンの Code SHA の子孫として CHANGELOG のみを変更して後からコミットすることもできます。
• 正規の main 参照：検証前に取得した現在の origin/main です。同じ変更がバックポートで取り込まれている場合、リリースノートでは元の main にマージされた PR を参照します。現在の main にフォワードポートがない場合に限り、リリースブランチの PR を使用します。

ワークフロー

1. リリースブランチと正確な履歴対象を確認します：

   • git fetch --tags origin
   • git status -sb がクリーンであることを確認します
   • git rev-parse HEAD を履歴対象として記録します
   • すでに適格性確認が行われている場合は、Full Release Validation の実行 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> \
     --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 を含む正確なバージョンのセクションを作成します。差分マニフェストを生成し、その範囲についてのみ説明を書きます。以降の実行では、分岐した範囲のマージベースの SHA だけでなく、記録済みの npm ベースラインタグを明示的に使用します。公開後に npm を再照会したり、累積安定版エントリーを上書きしたりしないでください。安定版の準備時に、累積安定版ノートを再生成します。

   リリースコミットに来歴メタデータを付けられない場合は、繰り返し指定できる --release-provenance '<40sha> -> #PR[, #PR]' 入力を追加します。これらには、コミット本文マーカーと同じ厳密なマーカー文法および現在の main に対する検証が適用されます。 検証ツールは、worktree の git メタデータ配下にある、ベース SHA とターゲット 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> を一度追加してください。これにより、古いマージコミットで PR 番号が省略されていても、以前の変更履歴にあるコントリビューション記録が保持されます。検証ツールは、ベースタグ以降に取り消された記録を除外します。これには、安定版リリース前に取り消されたベータ版の変更も含まれます
   • 生成される来歴レポートでは、対象範囲内の PR と保持されたシードのみの PR を別々に報告した後、一意な行の合計数を示します。両方の一覧に含まれる PR は対象範囲内として数えます。シードを含む合計を、現在のリリース範囲内でマージされた変更として記述してはいけません
   • 到達可能な main のクローズアウトがリリース済みタグと異なる場合、または後続のフォワードポートコミットによってすでにリリース済みの PR が再関連付けされる場合は、繰り返し指定可能な --shipped-ref <prior-shipped-tag> を追加します。各タグは累積的なリリース済み境界です。検証ツールは、番号付きリリースセクションにある完全なコントリビューション記録から明示的な PR 行を統合し、重複する PR のみを除外し、Unreleased は無視します。この境界をベース SHA、ターゲットの本文、ターゲットの記録から推測してはいけません。決定論的な候補検証のため、マニフェストと生成される来歴には、各タグと、正確な除外 PR 一覧および件数が保持されます
   • ソース PR の検出では、GitHub のコミット関連付けを、選択したターゲット履歴、または正規キャリアの場合は固定された main 履歴に限定します。コンテキスト内のソース参照がコントリビューションとなるのは、そのマージコミットがターゲット履歴に到達可能で、マージ時刻がターゲットの範囲内にある場合に限られます。すべての参照を解決可能な状態に保ちますが、リリース準備中にマージされたという理由だけで、無関係な PR を昇格させてはいけません。明示的なシードは過去の所属を保持し、対象範囲内であると個別に証明されない限り、シードのみとして扱います。関連付けのすべてのページを解決してください。既存の正規化、チェリーピック、来歴に関する契約は引き続き優先されます。
   • 複数コミットを明示的に取り消すには、revert の件名と、単独の行に記載された Reverts <full SHA> and <full SHA>. 宣言が必要です（カンマ区切りの一覧で、最後に and を置く形式も使用できます）。末尾が正確に to restore the previous behavior. である場合も受け入れられます。重複、短縮、文中への埋め込み、繰り返しの宣言では取り消しを立証できません。指定された各コミットは単一親の祖先でなければならず、指定されたすべてのパッチを逆適用した結果、完全な revert ツリーが再現される必要があります。宣言が認識されても、この証明に失敗した場合は検証を停止します。証明には、フックや外部 diff を使わず、非公開の Git インデックス／オブジェクトストレージを使用します。正規の単一 revert と revert の再取り消しに関する計上は維持されます。
   • バックポートは、main 上で元になったマージ済み PR に正規化します。明示的なチェリーピック元を優先し、それがない場合は、作者が同じで変更されたパスが重複することを条件に、正規化した件名が一意に一致する必要があります。対応する main の PR が現在の origin/main に存在する場合は、リリース／バックポート PR を除外します。変更が先にリリースブランチに取り込まれ、まだ main にフォワードポートされていない場合に限り、リリースブランチの PR を保持します
   • ### Highlights、### Changes、### Fixes を編集する前にマニフェストを確認してください。再監査せずに、以前のグループ化された文章をそのまま引き継いではいけません
   • 判断が難しいコミットについては、リンク先の PR／issue または diff を確認してください。直接コミットは編集のための入力であり、公開台帳の行ではありません。件名、本文、変更されたファイル、テスト、前後のコミットから、ユーザーにとって重要な結果を推定します

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つのユーザーストーリーを表している場合は、細かなコミットごとに箇条書きを分けないでください。
   • ### Complete contribution record：まとめた説明の後に、PRを主軸とした生成済みの記録を置きます。これは網羅的な記録用であり、リリース概要を繰り返すものではありません。

6. クレジットを保持します。

   • #issue、(#PR)、Fixes #...、Thanks @...をそのまま残します。
   • ユーザー向けの項目に含まれる、人間が作成したマージ済みPRにはすべてPR参照とThanks @authorを付けます。PRに関連付けられたissueがない場合も同様です。
   • ユーザー向けの項目に含まれる、Fixes #...または参照先のバグissueの人間による報告者には、同じ箇条書きですでにそのユーザー名に謝辞を述べている場合を除き、Thanks @reporterを付けます。
   • ユーザー向けの作業に含まれる、人間のCo-authored-by貢献者には、GitHub上でユーザー名が判明している場合、Thanks @handleを付けます。
   • 1つの箇条書きに複数のPRやissueをまとめる場合は、関連するPR／issue参照と人間の貢献者全員のユーザー名を、その箇条書きに含めます。
   • 1つの箇条書きに複数のThanks @...が含まれるのは問題ありません。変更メモをまとめたことを理由に、貢献者への謝辞を削除したり省略したりしないでください。
   • 1つの箇条書きが直接コミットとPRの両方を扱う場合は、すべてのPR参照と謝辞に加え、直接コミットのissue参照と人間の貢献者への謝辞もすべて保持します。
   • issueは通常のインラインの#NNN参照として残します。リンク済みissueの一覧を別途追加しないでください。生成されたPR記録では、元となるissueを、そのissueを含むPRにRelated #NNNとしてインラインで記載します。
   • 以前のリンク済みissue一覧を補完する場合は、GitHubで確認済みの、クローズPRと関連付けられたissueすべてについて、報告者への謝辞をインラインで保持します。一般的な相互参照イベントからPRとの関係を推測したり、単独の報告に無関係なPRリンクを作ったり、廃止された一覧を再作成したりしないでください。
   • 完全な貢献記録には、検証済みの対象期間内のすべてのPRと、明示的に保持されたシードのみのPRを、**PR #NNN**としてそれぞれ1回だけ記載します。検出時には正規の履歴とcherry-pickの来歴を保持し、文脈上の参照には凍結済み履歴への所属を必須とします。インラインの文脈だけを根拠に貢献記録の行を追加することはできません。作成者／共同作成者への謝辞と、元のタイトルに含まれるissue参照を保持します。
   • 来歴の計算結果と一意の合計数は、出力されたPRの行数と一致させます。候補の検証では、不正形式または改ざんされた件数を拒否します。
   • 直接コミットは、GitHubで解決された作成者、共同作成者、issue、編集対象の適格性に関するデータとともにマニフェストに保持します。直接コミットはまとめた説明には反映しますが、公開用の#### Direct commits一覧として出力してはいけません。直接コミットへの謝辞をまとめた箇条書きに加えるのは、明示的なクローズissue参照、または少なくとも2つの特徴的な件名用語を共有する場合に限ります。
   • 検証ツールは、通常のdocs、test、refactor、ci、build、chore、styleのPRをHighlights、Changes、Fixesで拒否します。Conventional Commitsの!マーカーが明示されていれば、どのタイプでも編集対象にできます。その検証済みのユーザー向け破壊的変更と移行ガイダンスを、元のPR参照と謝辞とともに記載します。その他の内部向け貢献は完全なPR記録にのみ残します。
   • Conventional Commits形式のタイトルは、説明文に偶然含まれるdocやbuildなどの語ではなく、宣言されたタイプとスコープに基づいて分類します。タイプが明示されていないタイトルでは、QA、test、docs、refactor、lint、CIなど、内部作業を示す語句を保持します。適格性の判定が、ユーザーに見える成果を確定するためのソース監査の代わりになることはありません。
   • 明示的な依頼がない限り、変更履歴やGitHubリリースノートの文面にGHSA参照、アドバイザリID、セキュリティアドバイザリのスラッグを追加しないでください。
   • 初回のリリース生成では、既存の謝辞ポリシーを適用します。ボット、@claude、@codex、@openclaw、@clawsweeper、@steipeteには謝辞を述べないでください。承認済みの、ドキュメント公開後のGitHub本文では、謝辞の対象となる@steipeteを含む、検証済みの人間の貢献者全員を記載します。
   • GitHubのリリース貢献者数を正としないでください。変更履歴自体に、人間の貢献者への謝辞を漏れなく記載する必要があります。

7. 並べ替えの優先順位：

   • セキュリティ／データ損失とコンテンツ境界に関する修正
   • トランスクリプト／リプレイ／返信の配信の正確性
   • チャネルとモバイル連携
   • プロバイダー／Codex／ローカルモデルの信頼性
   • インストール／更新／リリース経路の信頼性
   • パフォーマンスと可観測性
   • ドキュメントと貢献者向け／内部向けの詳細は最後に置くか、省略します。

8. 既存ファイルのスタイル上必要な場合を除き、箇条書きは1行で記述します。ユーザーのインストールや更新の安全性に影響しない限り、内部のリリースプロセスに関するノイズは避けてください。

9. リリースノートに関する追加条件を確認します。

   • src/plugins/compat/registry.tsを調査します。
   • src/commands/doctor/shared/deprecation-compat.tsを調査します。
   • 非推奨の互換性レコードがremoveAfterに達している場合、安全性を確認できたら削除するか、ブロッカーを記録してremoval-pendingに移動します。期限を過ぎたremoval-pendingレコードは、文書化された条件が満たされるまでのみ保持します。

10. 検証してリリースします。

• マニフェスト駆動の書き換え後、コミットする前に、完全なコントリビューション記録を再生成して検証してください。

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

• このコマンドは、リリース履歴またはレンダリングされたリリースセクション内の #NNN 参照を解決できない場合、取り消された作業がリリース済みとして示されている場合、ソース PR がコントリビューション記録にない場合、直接コミットが公開記録のダンプとしてレンダリングされている場合、編集以外の PR がグループ化された本文に含まれている場合、または対象となる PR 作成者や既知の共同作成者が、その PR の Thanks @... クレジットに含まれていない場合に失敗します。また、履歴の収集前に、--base が --target の祖先でない場合（マージベースへの正規化とリリース済み記録の差し引きを行うベータリリースタグを除く）、### Highlights が選択された安定版（5～8）またはベータ版（0～8）のトップレベル箇条書き数の上限に違反している場合、既存の本文または記録にソース範囲外の PR が記載されている場合にも失敗します。過去の PR 一覧を追加できるのは、明示的な --seed-ref のみです。明示的に繰り返し指定できる --shipped-ref を使うと、以前のリリース済みタグに存在することが証明された PR を差し引けます。
• グループ化された本文に PR を記載する場合、その同じ箇条書きに、生成された PR 記録内のすべての貢献者と、リンク付きレポーターのクレジットを残してください。
• 修飾子のない #NNN 参照は openclaw/openclaw を参照します。openclaw/imsg#141 のような別リポジトリへの参照は文字列のままにし、ローカルのイシューリンクに書き換えないでください。
• GitHub のリリースまたはプレリリースを公開した後、該当するすべてのリリースページを、同じソースセクションと照合して検証してください。

  node --import tsx .agents/skills/openclaw-changelog-update/scripts/verify-release-notes.mjs \
    --base <base-tag> \
    --target <target-ref> \
    --version <YYYY.M.PATCH> \
    --release-tag v<YYYY.M.PATCH> \
    --check-github
  

• 各ベータ版ページは、正確なベータ版のバージョン、記録されたベースとターゲットを使って検証してください。安定版と拡張安定版は、それぞれ独自のソースセクションと範囲で検証してください。複数のベータ版ページを、累積された単一の安定版セクションと照合してはなりません。### Release verification の末尾部分は許可されますが、それ以外の本文の差異は失敗となります。
• scripts/render-github-release-notes.mts は、候補の検証、公開、検証で使用する、正式なリリース本文レンダラーです。選択したバージョンの完全なセクションが GitHub の 125,000 文字の上限と、レンダラーの同じ 125,000 バイトの安全上限の両方に収まる場合、本文には見出しを含むそのセクション全体をそのまま記載してください。
• ソースセクション全体がいずれかの上限を超える場合、レンダラーは ### Complete contribution record の直前の行まで、グループ化された編集上の注記をそのまま保持します。その後、この見出しを出力し、タグに固定された CHANGELOG/records/<version>.md 内の完全なコントリビューション記録への安定したリンクを記載します（過去の単一ファイル形式のタグでは、元の CHANGELOG.md 記録リンクを維持します）。箇条書きや記録の一部を切り詰めたり、別の短縮版を手作業で作成したりしないでください。
• 正式な完全版または短縮版の本文を確定した後、収まる場合にのみ ### Release verification を追加してください。収まらない場合は本文末尾を省略し、変更不可の添付リリース証跡を保持してください。任意の末尾を残すために、上限内に収まる完全なコントリビューション記録を短縮してはなりません。
• pnpm release:candidate は、ローカルの生成チェックを明示的にスキップする場合も含め、Full Release Validation を開始する前に、正確なターゲットからこの決定的なレンダリングチェックを実行します。
• git diff --check
• pnpm changelog:check は、分割されたインデックス、記録、およびマークされたドキュメントのミラーを検証します。
• ドキュメント／変更履歴のみの変更には、広範なテストは不要です。
• リリース項目、その生成済み記録、変更されたインデックスをステージし、git commit -m "docs(changelog): refresh YYYY.M.PATCH notes" でコミットしてください。
• リリースブランチを、動き続ける main にリベースせずにプッシュしてください。
• 新たな完全な適格性確認の前に、すべての修正と最終ノートがコミットされている場合は、そのコミットを Code SHA と Release SHA の両方として記録してください。両方の役割に、同じ成功した完全な親／試行と、その正確な公開バイト列を使用してください。
• Code の適格性確認後にノートを変更した場合に限り、git diff --name-only <code-sha>..<release-sha> に CHANGELOG/<version>.md と、その項目に対応する記録および CHANGELOG.md のみが含まれていることを必須とし、必要に応じて split-changelog-release-v1 を使用してください。選択した項目／記録の追加または変更は許可されますが、名前変更、削除、他のリリース、ドキュメントのソース変更は許可されません。過去のルートのみのレシートでは changelog-only-release-v1 を維持してください。分割パスでは、成功済みの Code 証明を保持したまま、新しい Release SHA のパッケージバイト列を適格性確認します。それ以外のパスが変更された場合は、製品の適格性確認を新たに実施する必要があります。

リリース後のドキュメントミラー

ドキュメント公開の明示的な承認後、承認済みのドキュメントソースと、機械的にフラット化した変更履歴を、同じソース PR で公開します。これは初回リリース生成とは別の作業です。リリースの準備や公開時に、編集者による書き換えを自動で実行しないでください。

大規模なリリースや複数のドキュメントページにまたがるリリースでも、順序どおりに並べたドキュメントソースを、1 つの完全な Markdown ファイルにレンダリングします。

pnpm changelog:from-docs --version YYYY.M.PATCH \
  --source docs/releases/YYYY.M.PATCH.md \
  --output CHANGELOG/YYYY.M.PATCH.md
pnpm changelog:check

複数のパートに分かれたリリースでは、承認された閲覧順に --source を繰り返します。コンバーターは表示用のラッパーを取り除き、アコーディオンのタイトルを見出しに変換し、ドキュメントリンクを展開して、ソーステキスト、クレジット、コード、表、画像を保持します。未対応のマークアップがある場合、内容を黙って削除するのではなく、処理を失敗させます。先頭行のマーカーは、順序どおりに並べたソースパスとソースの正確なダイジェストを紐付けます。チェックでは、マーカー付きのミラーだけをソースと照合します。変更されていない過去のオリジナルは、当初の形式のまま維持されます。読者向けの文章を置き換えるときは、CHANGELOG/records/YYYY.M.PATCH.md を確定済みの記録として保持してください。ドキュメントソースを変更する場合は、同じ PR でミラーを再生成します。

承認済みの公開バンドルでは、ソースのマージ、検証済みのドキュメントのデプロイ、後続の GitHub Release 本文の更新を、それぞれ記録された個別の手順として扱います。デプロイ後、既存のリリースを改めて読み込み、本文のみを更新してください。更新内容には、バージョンと統計情報、Raw 変更履歴とドキュメントへのリンク、重複を除いてアルファベット順に並べた検証済みの人間による謝辞、変更しないリリース検証セクションを含めます。検証済みの PR、直接のコミット、共同作成者、イシューに対するクレジットを含め、@steipete も記載してください。ボットは除外します。クレジットや証跡を切り詰めずに、125,000 文字と 125,000 バイトの上限をどちらも守ってください。ネイティブのアバターとアセットは GitHub が管理します。本文を読み戻して検証し、未完了の手順のみを再開してください。この本文を置き換えるために、タグの付け直し、再ビルド、アセットの再公開、初回公開の再実行をしてはいけません。初回の履歴検証ではドキュメントミラーが拒否されます。ミラーの検証には、ドキュメント公開ワークフローを使用してください。

Extended-Stable バリアント

Extended-stable では、リリースコミットは 1 つ、正規の GitHub Release 本文も 1 つです。バージョン準備と承認済みのバックポートの後、通常のマニフェストと、元のメイン PR のプロベナンスルールに従って CHANGELOG/YYYY.M.P.md を再生成します。PR で取り込み、その後、タグを付ける前に最終ブランチの先端を検証してください。リリースのクローズ処理では、親パイプラインが Latest ではないリリースページを公開する前に、タグが所有するセクションを共有ドラフトにレンダリングします。プロダクトのバックポート後は再監査してください。ツールのみの修正には変更履歴の項目は必要ありません。公開済みのタグや変更履歴を書き換えてはいけません。

クォータ／API 障害時のルール

GitHub API のクォータを使い切っても、待機したままにしないでください。GitHub API を必要としない作業を続けてください。

• ローカルでの変更履歴の書き換えとリリースノートの抽出
• ローカルでのタグ付け前チェックとパッケージ／ビルドの健全性確認
• git プロトコルを使った git push／タグのチェック
• npm レジストリに対する npm view チェック
• ワークフローのディスパッチコマンドの正確な準備

GitHub Release の作成、ワークフローのディスパッチ、実行状況のポーリング、アーティファクトのダウンロード、イシュー／PR の変更にのみ API クォータが必要です。