deps-update

name	deps-update
description	cargo/npm の依存を一括更新し検証する。ユーザーが「依存更新して」「deps 更新」「/deps-update」と言ったときに使う。
disable-model-invocation	true

依存更新ワークフロー

npm と cargo の依存を安全に更新する。

ステップ 1: 現状把握

以下を並列で実行する:

npm outdated
cargo update --dry-run

ステップ 2: 更新方針の判断

• パッチ・マイナー更新: 一括で進めてよい
• メジャー更新: 1 件ずつ changelog・breaking changes を確認し、ユーザーに更新可否を確認する。波及範囲は changelog の散文でなくパッケージメタデータで実測する（npm view <pkg>@<ver> engines exports peerDependencies）。見送って issue 化する場合もこの実測結果を issue に書く（想定で書くと着手時にスコープごと覆る。#185 は「マッチャー波及」を懸念して起票したが、実際の争点は engines.node と CI のランタイム版だった）
• tauri 系（@tauri-apps/cli / @tauri-apps/api / 各プラグイン / tauri クレート）: CLI・api・プラグインの版を揃える
• rusqlite / libsqlite3-sys: tauri-plugin-sql との links 制約で上限が固定されている。src-tauri/CLAUDE.md「rusqlite と sqlx-sqlite の libsqlite3-sys 共有制約」を読み、解錠条件を満たしていない限り major bump しない
• シリアライズ・ストレージ形式に関わるクレート: 後方互換性の検証手順（src-tauri/CLAUDE.md「依存クレートの移行・更新」）に従う

ステップ 3: 更新の実行

npm update          # package.json の semver 範囲内
cargo update        # Cargo.lock の更新

範囲を超える更新（メジャー）は package.json / Cargo.toml を個別に編集する。

ステップ 4: 検証

/commit のコミット前チェックリストを全実行する。UI に波及しうる更新（React・Fluent UI・i18next・tauri 系）の場合は /e2e の手動実行を推奨する。

toolchain 更新（rustup stable の bump）時の clippy 再ゼロ化: CI（ci-build.yml）は dtolnay/rust-toolchain@stable（浮動）で clippy を -D warnings ゲートしている。cargo update とは別に stable が上がると新 lint で CI が突然赤くなりうる。rustup update で stable を上げたら、依存更新と同一 PR かは問わず cargo clippy --workspace --all-targets -- -D warnings と bench 構成（--features bench --all-targets）を再実行し、警告ゼロを回復してからコミットする。toolchain は固定していない（新 lint を早期検知する方針・#175）。順序が重要: toolchain を先に上げ、依存を変更していないツリーでベースラインを取ってから依存更新に入る。逆順だと赤が出たとき「新 lint 由来」か「新版由来」かを切り分けられない。

Node ランタイムの EOL 確認: Rust とは非対称で、CI の node-version は明示ピン（浮動でない）。放置しても赤くならず、静かに EOL のランタイムで回り続ける。依存更新のたびに node -v・ci-build.yml / release.yml の node-version・Node のリリース予定 を突き合わせる。.npmrc が無く engine-strict は既定 off のため、engines.node を満たさない依存を入れても npm ci は警告どまりで失敗しない——CI の赤は検知手段にならない（#185 で EOL 経過後の Node 20 を検出）。

ステップ 5: コミットと PR

/commit → /pr へ接続する。更新内容（何をどの版からどの版へ）を PR 本文に列挙する。