dep-upgrade

依存関係を安全にアップグレードする

破損を一切発生させずに、依存関係を体系的にアップグレードします。プロジェクトのエコシステムを検出し、古いパッケージや脆弱性のあるパッケージを監査して、優先順位を付けた計画を提示し、承認後にアップグレードを1つずつ実行します。各アップグレード後にテストを検証します。

基本原則： アップグレードは1つずつ行います。毎回テストします。失敗したらロールバックします。自動コミットは行いません。

前提条件の確認

パッケージマネージャーのファイルをスキャンして、プロジェクトのエコシステムを検出します。

ls go.mod package.json pyproject.toml Cargo.toml *.csproj 2>/dev/null

パッケージマネージャーのファイルが見つからない場合は、ユーザーに報告して停止します。複合プロジェクト（例：Go バックエンド + Node フロントエンド）もサポートされています。各エコシステムを個別に監査してアップグレードします。

ステップ1：依存関係を監査する

古いパッケージを一覧表示し、検出された各エコシステムの脆弱性スキャナーを実行します。

Go：

go list -u -m all 2>/dev/null | grep '\['
govulncheck ./... 2>/dev/null

Node.js：

npm outdated 2>/dev/null
npm audit 2>/dev/null

Python：

pip list --outdated 2>/dev/null
pip-audit 2>/dev/null

Rust：

cargo outdated 2>/dev/null
cargo audit 2>/dev/null

.NET：

dotnet list package --outdated 2>/dev/null
dotnet list package --vulnerable 2>/dev/null

エコシステムごとの詳細なコマンドについては、references/upgrade-commands.md を参照してください。

脆弱性スキャナーがインストールされていない場合は、レポートに記載したうえで、古いパッケージの一覧表示は続行します。

ステップ2：分類して優先順位を付ける

古いパッケージごとに、次の優先度を割り当てます。

• CRITICAL — 既知の CVE またはセキュリティアドバイザリがある
• HIGH — メジャーバージョンが遅れている、または依存関係が EOL になっている
• MEDIUM — マイナーバージョンが遅れている
• LOW — パッチバージョンのみが遅れている

優先度の判断基準と破壊的変更の評価については、references/priority-matrix.md を参照してください。

ステップ3：アップグレード計画を提示する

アップグレードを行う前に、優先順位を付けた一覧をユーザーに提示します。references/report-template.md の計画フォーマットを使用します。

Dependency Upgrade Plan

Ecosystem: Go
Outdated: 5 packages
Vulnerable: 1 package

| # | Package           | Current | Target | Priority |
|---|-------------------|---------|--------|----------|
| 1 | example/vuln-pkg  | v1.2.0  | v1.2.5 | CRITICAL |
| 2 | example/old-pkg   | v2.0.0  | v4.1.0 | HIGH     |
| 3 | example/minor-pkg | v3.1.0  | v3.4.0 | MEDIUM   |

Proceed with upgrades?

続行する前に、ユーザーの承認を待ってください。 ユーザーはすべてをアップグレードするか、特定のパッケージを選択するか、スキップするかを選べます。

ステップ4：1つずつアップグレードする

承認されたパッケージごとに、優先順位の高い順に次を行います。

1. 調査 — 破壊的変更について、変更履歴またはリリースノートを確認します。メジャーバージョンをまたぐ場合は、移行ガイドを読みます。
2. アップグレード — エコシステム固有のアップグレードコマンドを実行します
3. ロックファイルを更新 — go mod tidy、npm install などを実行します
4. テストを実行 — プロジェクトのテストスイートを実行します
5. テストに合格した場合 — 次のパッケージに進みます
6. テストに失敗した場合 — このアップグレードを直ちにロールバックします。

# Rollback: restore dependency files from git
git checkout -- <dependency-file> <lockfile>

失敗（パッケージ、対象バージョン、テストエラー）を報告し、残りのパッケージの処理を続けます。

エコシステム固有のアップグレードおよびロールバックコマンドについては、references/upgrade-commands.md を参照してください。

ステップ5：ロックファイルを検証する

すべてのアップグレードが完了したら、ロックファイルの整合性を検証します。

# Go
go mod verify

# Node
npm ci --dry-run

# Rust
cargo build --dry-run

ロックファイルが更新され、依存関係マニフェストとの整合性が取れていることを確認します。

ステップ6：概要を提示する

references/report-template.md のテンプレートを使って、アップグレードの結果を提示します。次の内容を含めます。

1. アップグレードに成功 — パッケージ、変更前のバージョン、変更後のバージョン、テストの状態
2. 失敗してロールバック — パッケージ、対象バージョン、失敗の理由
3. スキップ — パッケージ、理由（ユーザーがスキップを選択、または破壊的変更に手動での移行が必要）
4. 残存する脆弱性 — 解消されていない CVE
5. ロックファイルの状態 — エコシステムごとの更新および検証状況

変更をコミットしないでください。いつ、どのようにコミットするかはユーザーが決定します。コミットメッセージを提案します。

deps: upgrade X packages (Y security fixes)

重要な制約

• 自動コミットは絶対に行わない — パッケージをアップグレードするとファイルが変更されますが、コミットするかどうかはユーザーが決定します
• ブランチは作成しない — Git 操作はユーザーに任せます
• 1つずつ行う — 複数のパッケージを同時にアップグレードすると、どのアップグレードがテストを破損させたのか特定できません
• 失敗したら直ちにロールバックする — 依存関係が壊れた状態で続行しないでください
• すべて報告する — ユーザーがパッケージのスキップを選択した場合も、理由とともに概要に含めます