ln-32-dependency-upgrader

依存関係のアップグレード

目標： 依存関係を、変更元を特定できる小さな単位でアップグレードします。マニフェスト、ロックファイル、ランタイムのサポート、製品の動作を維持します。互換性、セキュリティ、保守に関する根拠がない限り、新しいバージョンに価値があるとは見なしません。

実行規約： 順序付きチェックボックスが完了の定義です。各項目を内部で PENDING、具体的な証拠がある PROVEN、条件が存在しない証拠がある CLEARED、または不足がある UNPROVEN として追跡します。読み取り、委任、ツールの失敗は証明になりません。各セクションの後に項目を照合します。返答の前に、すべての PENDING を解消し、PROVEN と CLEARED のみを数えます。すべての未解決事項に対して、スキルの判定ルールと承認ルールを適用します。 ユーザーの意図、スコープ、既存の承認を維持します。承認済みの作業は続行し、重大な選択肢が未解決の場合、または外部承認が必要な場合に限り確認します。重大なリスクに応じて調査の深さを調整し、確認を暗黙に省略しません。依存関係と安全性に関する順序を維持し、それ以外では各義務に適した検証方法を選択します。

ツールの使い分け

必要な作業	優先ツール	使用する状況	代替手段
パッケージマネージャーの検出	マニフェスト、ロックファイル、ワークスペースファイル、ランタイムファイル、リポジトリの指示	コマンドやアップデートのスコープを選ぶ前に必ず実施	ビルドおよび CI の設定
古いパッケージや脆弱なパッケージの検出	パッケージマネージャー標準の古いパッケージ確認および監査コマンド	パッケージマネージャーとレジストリが利用可能な場合	公式レジストリ、ベンダーのアドバイザリ、ロックファイルの調査
破壊的変更とサポート状況の確認	公式リリースノート、移行ガイド、変更履歴、アドバイザリ、ランタイムのサポート表	影響のあるマイナー、メジャー、置き換え、セキュリティアップデートのすべて	一次情報であるリポジトリのリリース。それ以外は UNVERIFIED とする
使用状況と影響範囲の確認	言語サーバーまたはホスト標準のコードインテリジェンス	更新する API、型、プラグイン、ビルドツール、ランタイムが利用側に影響する可能性がある場合	インポート、シンボル、設定、スクリプトを対象に絞って検索
安全なバージョン変更	パッケージマネージャー標準のコマンド	マニフェストと生成されるロック状態の更新	ロックファイルを手編集したり、パッケージ解決を模倣したりしない
検証	リポジトリで定義されたインストール、復元、ビルド、リント、型、テスト、移行、スモークテストの各コマンド	変更前および各バッチの後	CI とスクリプトを調査し、未検証であることを明記
差分とロールバック	Git のステータス、差分、分離したコミットまたはワークツリー	ユーザーの変更を保護し、失敗したバッチだけを元に戻す場合	バッチを安全に分離できない場合は中止

パッケージの公開、認証情報のローテーション、デプロイ、監査および検証のゲートを弱める操作は行いません。通常の環境保護策なしに、信頼できないパッケージソースからライフサイクルスクリプトを実行しないでください。

証拠のルール

• マニフェストには制約が宣言され、ロックファイルには解決済みのバージョンが記録されます。アクティブな環境がそれと異なる場合は、インストールメタデータがその環境を証明します。レジストリの「latest」は、ランタイムや互換性の制約に優先しません。
• 脆弱性の指摘には、影響を受けるバージョン、アドバイザリ、到達可能性または露出の状況、信頼できる修正方法が必要です。
• 破壊的変更の主張には、正確なバージョン間の変更に対応するリリースまたは移行の証拠が必要です。
• 生成されたロックファイルの変更は、選択したパッケージマネージャー標準の方法で生成され、リポジトリのバージョンと合致する場合に限り保持します。
• アップグレードの成功には、インストールまたは復元の成功だけでなく、リポジトリの検証が必要です。

チェックリスト

1. 対象範囲を特定し、作業領域を保護する

• 要求された更新範囲内で、パッケージマネージャー、マニフェスト、ロックファイル、レジストリ、ランタイム／ツールの固定設定、生成された状態、依存関係でつながるワークスペースを検出します。範囲を広げるのは、互換性上の依存関係が確認された場合に限ります。
• 各成果物をアプリケーション、ライブラリ、プラグイン、CLI、コンテナー、ビルドツールに分類し、バージョン範囲、ロックファイル、ピア制約、サポート対象ランタイムの保証を正しく解釈します。
• リポジトリの指示を読み、サポート対象のパッケージマネージャーのバージョン、更新コマンド、ロックファイルの方針、CI の要件を確認します。
• Git の状態を調べ、既存のユーザー変更が上書きされたり、アップグレードの出力と誤認されたりしないよう、作業を分離します。
• 作成した絶対パス、ワークツリー、プロセス ID、キャッシュ、レポート、一時成果物をすべて記録する、この実行専用のリソース台帳を作成します。既存のリソースをクリーンアップ対象として登録してはいけません。
• セキュリティのみ、定期的なパッチまたはマイナー更新、選択したパッケージ、メジャー更新、ランタイム移行、全体更新のいずれかを確認し、要求された範囲を確定します。
• 編集前に、インストールまたは復元、ビルド、リント、型チェック、テスト、スモークテスト、セキュリティ監査のベースラインを記録します。
• 既存の失敗、アドバイザリ、非推奨事項、ピア依存関係の競合、サポート対象外のランタイムの組み合わせを記録します。

2. 調査し、バッチを計画する

• ネイティブの更新確認コマンドと監査コマンドを使い、ファイルを変更せずに、直接依存関係と関連する間接依存関係の更新候補を一覧にします。
• 削除、セキュリティ修正、通常の更新、メジャー更新、ビルドツールの変更、ランタイムまたはエコシステムの移行を分けます。
• API の変更、設定の変更、デフォルト、ピア制約、ランタイムのサポート、削除された動作について、公式のリリースノートと移行ガイドを確認します。
• 環境マーカー、追加機能、オプション／開発用グループ、ピア依存関係、ターゲットフレームワーク、プラットフォーム固有のパッケージを確認します。プロジェクトがより広い環境マトリックスを保証している場合、現在のマシンでのみ依存関係グラフが解決できても十分ではありません。
• 影響を受けるバージョン範囲、悪用条件、修正版、回避策、このプロジェクトで依存関係が実際に使用可能かどうかについて、公式アドバイザリを確認します。
• 重要な依存関係ごとに、実際のインポート、シンボル、プラグイン、スクリプト、設定、生成コード、ランタイム読み込みを検索します。
• 未使用、重複、保守終了、置き換え済み、またはプラットフォーム上で冗長な依存関係を、個別の削除候補として特定します。ランタイムと動的読み込みの証拠を確認し、要求された更新範囲外で削除する場合は、ユーザーの明示的な承認を得ます。
• 実際の互換性グラフに基づいてバッチの順序を決めます。パッケージマネージャー／ランタイム、ツール、基盤ライブラリ、フレームワーク、統合機能、末端の依存関係という分類は調査の手引きであり、固定の順序ではありません。相互に依存する移行はまとめます。
• 失敗の原因を特定できるよう、通常のバッチは小さく保ちます。互換性マトリックス上必要な場合に限り、フレームワーク群、アナライザー、生成クライアント、または制約の厳しいピア依存関係をまとめます。
• バージョン戦略、ランタイムのサポート、ライセンス、レジストリの方針、移行範囲が相互に両立せず、製品の意図に影響する場合は、ユーザーの指示を仰ぐため作業を止めます。

3. 各バッチを安全に適用する

• リポジトリで想定されているバージョンとフラグを使用し、ネイティブのパッケージマネージャーでマニフェストとロックファイルを更新します。
• 依頼の範囲が狭い場合は、パッケージマネージャーがロックグラフを安全に維持できない場合を除き、広範な再解決を避けます。避けられない変更がある場合は説明します。
• セキュリティリスクに応じて、インストールスクリプト、レジストリの配信元、チェックサム、パッケージの来歴、予期しない新しい推移的パッケージを確認します。
• ドキュメントに記載された破壊的変更に必要な、インポート、API、型、設定、ビルドスクリプト、プラグイン、生成済みクライアント、アプリケーションコードを更新します。
• 仕様、前提条件、設定、コマンドに変更がある場合に限り、ユーザー向けまたは運用者向けドキュメントを更新します。
• 無関係なフォーマット変更、制約の削除、レジストリの逸脱、改行コードの変更、生成物、意図しないダウングレードがないか、差分をすぐに確認します。
• 解決済みの依存関係グラフを確認し、新たに重複したメジャーバージョン、満たされていない、または黙って無視されたピア依存関係、変更されたオプション機能、実行時の動作を変える推移的依存関係の置き換えがないか調べます。
• 根拠なく警告を抑制したり、監査を無効化したり、必須チェックを省略したり、互換性のないピア依存関係を強制的に固定したり、互換性ハックを追加したりしないでください。

4. 検証して維持または取り消す

• ロックファイルの再現性を証明するため、十分にクリーンな状態からインストールまたは復元を実行します。
• 各バッチの適用後に、関連するビルド、リント、型、単体、統合、スモーク、パッケージング、マイグレーション、アプリケーション起動のチェックを実行します。
• 影響を受けるランタイム、ターゲットフレームワーク、OS、アーキテクチャ、機能の組み合わせを必須または任意に分類します。必須の各組み合わせについてローカルまたは信頼できる CI の証拠がある場合に限りバッチを維持し、必須のカバレッジに信頼できる代替手段がない場合は BLOCKED を返します。
• 一般的なテストではカバーされない可能性がある、変更された API、プラグイン、シリアライザー、ビルド出力、ランタイム経路を実際に試します。
• 更新した依存関係が指標に大きく影響する可能性がある場合は、バンドル、起動、成果物、パフォーマンスの指標を比較します。
• セキュリティ監査を再実行し、修正済み、未解決、新たに導入、到達不能、修正なしのアドバイザリを区別します。
• 検証に合格し、想定される動作が引き続きサポートされる場合に限り、バッチを維持します。
• バッチが失敗した場合は、ベースラインまたは環境の失敗とアップグレードの欠陥を区別します。範囲を限定したマイグレーションエラーを修正して再確認するか、ユーザーの作業に触れずにバッチ全体を元に戻します。ブロッカーを記録し、独立して安全なバッチのみ続行します。
• 次のバッチを適用する前に、維持する依存関係の状態をベースラインとして確立します。
• 計画した各バッチを、適用して検証済みの場合は KEPT、適用後に検証に失敗して完全にロールバックした場合は REVERTED、必須の判断、互換性戦略、または独立した前提条件が未解決のため意図的に適用しなかった場合は SKIPPED に分類します。

5. 最終確認と報告

• 必須のリポジトリ検証が、維持した変更全体を対象としていることを確認します。引き続き有効な結果は再利用し、不足しているチェックを実行し、後続バッチや未解決の失敗によって無効になったチェックを再実行します。
• マニフェスト、ロックファイル、ランタイムのバージョン固定、CI、コンテナー、ドキュメント、生成済みメタデータが、最終バージョンと一致していることを確認します。
• 実行で所有する台帳エントリーのみを削除します。絶対パスが承認済みの一時ルート内にあることを確認し、記録されたプロセス ID と完全に一致するプロセスを停止し、変更のある、または実行前から存在するワークツリーを保持し、意図的に報告する証拠用アーティファクトを残します。
• 意図的にスキップしたパッケージを、正確な制約、リスク、アドバイザリ、またはマイグレーション上の理由とともに列挙します。
• バッチ台帳を、最終バージョン、マイグレーションによる編集、アドバイザリ、ロックファイルの変更量、残存リスクと照合します。
• 要求された更新範囲が満たされ、検証済みの場合に限り UPDATED を使用します。安全な範囲のみを維持し、依頼された作業または任意のカバレッジが残る場合は PARTIAL、維持したバッチがなくベースラインに復元した場合は NO_CHANGE、安全に進められない、または必須の検証を実施できない場合は BLOCKED を使用します。

セルフチェック

• 返却前に照合してください。 項目ごとの根拠、要件の網羅性、矛盾、範囲、判定、該当するクリーンアップを確認します。報告または許可された成果物を修正します。有効な根拠は再利用し、リポジトリを自動的に再スキャンしたり、成功済みのコマンドを再実行したりしないでください。関連する変更、失敗、または未解決の根拠がある場合に限り、チェックを繰り返します。残る不足点を明示します。

出力契約

ユーザーの言語で、以下の順序で報告してください。5つのフィールドすべてを維持し、各事実は一度だけ述べます。結果が少ない場合はフィールドごとに1行で記載できます。空の表は省略し、リンク先の成果物をコピーしないでください。

1. 結果： スキル固有の判定と、根拠によって裏付けられた結果。
2. 範囲： レビュー／変更した範囲、除外事項、ベースライン、重要な前提。
3. 根拠： 以下のスキル固有の項目。事実、推論、未検証の主張を区別します。成果物にリンクし、必要に応じて表を使用します。
4. 検証： チェックと結果、入手できない根拠、該当するクリーンアップ／外部状態。
5. 完了： Checklist: X/Y complete、Incomplete: None、または各 UNPROVEN 項目の理由、結果への影響、具体的な次のアクションを記載します。残存リスクと必要な判断も示します。

スキル固有の根拠： マネージャー、ワークスペース、ランタイム、要求された更新ポリシー、既存の失敗／注意事項。バッチごとに、パッケージ、バージョン、移行、KEPT / REVERTED / SKIPPED、検証結果を記載します。修正済み／残存／新規の注意事項、ピア／ランタイム／レジストリの制約、ロックファイルの変更状況、スキップしたパッケージの理由、複合状態のチェック、実行によって所有されたマニフェスト／ロックファイル／差分、およびロールバック／クリーンアップの根拠も含めます。