Renovate + sharedWorkspaceLockfile:false: catalog 更新で per-package lockfile が drift する（再発防止の方式検討）

[sousuke0422]

事象

pnpm workspace が sharedWorkspaceLockfile: false（各 apps/*・packages/* が独立 lockfile を持つ）構成のため、Renovate が catalog / overrides を更新すると、ルート pnpm-lock.yaml だけ再生成し、配下（apps/cli / apps/frontend / packages/*）の per-package lockfile を放置する。結果、workspace の pnpm install --frozen-lockfile が

[ERR_PNPM_LOCKFILE_CONFIG_MISMATCH] Cannot proceed with the frozen installation.
The current "overrides" configuration doesn't match the value found in the lockfile

で失敗し、main が壊れる。

実例（今回の発生）

• トリガー: chore(deps): update vite-plus to v0.2.5 #404（chore(deps): update vite-plus to v0.2.5）。catalog vite → @voidzero-dev/vite-plus-core を 0.2.4→0.2.5 に更新したが、変更ファイルは pnpm-lock.yaml と pnpm-workspace.yaml の2つのみ（配下 lockfile 未更新）。参考: 前回の chore(deps): update vite-plus #248 は配下 lockfile も全て更新していた。
• 検知: PR ci: align e2e workflow action pins with other frontend workflows #427 の e2e Install frontend dependencies が上記エラーで失敗（packages/oxlint-plugin-api-path-params で検出）。
• 暫定修正: 配下3 lockfile を catalog 0.2.5 へ同期する commit 6971f15c を、緊急対応として main へ直接着地（PR 非経由）。frozen install 全4 workspace PASS を実証済み。

根本原因

1. upstream バグ: renovatebot/renovate#37485「Catalog version not applying to all packages in pnpm workspace when shared-workspace-lockfile = false」（OPEN・priority-4-low）。当分の upstream 修正は見込めない。関連: discussion #42185。
2. ホスティング制約: 本 repo は Mend クラウド Renovate App（renovate[bot]）を利用。クラウド App はセキュリティ上 postUpgradeTasks（任意コマンド実行）を封じているため、更新後に pnpm install を走らせて全 lockfile を再生成する正攻法が使えない。
3. 検知が遅れた理由: frozen install を検証する WF（cli-test / frontend-* / e2e）は全て path-gated。chore(deps): update vite-plus to v0.2.5 #404 のような root-only（pnpm-workspace.yaml + ルート lock のみ）の変更ではどの WF も発火せず、drift が無検証のまま main へマージされた。

制約（再発防止策が満たすべき要件）

1. Renovate の PR に介入しない（bot が Renovate 枝へ commit-back する方式は、Renovate の rebase と衝突して運用が面倒）
2. main を瞬間たりとも壊さない（main が赤くなると、他の Renovate PR の auto-merge が連鎖的に停止する）
3. sharedWorkspaceLockfile: false を維持（独立配布・単一バイナリ構想のため、当分 true 回帰は不可）
4. hands-off（人手介入なしで Renovate が一貫した PR を仕上げる）

候補案

#	案	評価
1	self-hosted Renovate ＋ postUpgradeTasks で pnpm install --lockfile-only を実行（fileFilters: ["**/pnpm-lock.yaml"]・executionMode: "branch"）。self-host 側 allowedCommands で当該コマンドを許可	✅ 全制約充足・documented fix。Renovate 自身が自分の PR 生成の一部として lockfile を再生成 → PR が最初から一貫 → rebase 時も再実行され保たれる → main 無破損・auto-merge 無傷。コスト = Mend クラウド → self-hosted（GitHub Actions）移行 ＋ RENOVATE_TOKEN（専用 GitHub App 推奨）。【推奨】
2	main-side reconciler（マージ後に drift 検知→自動修正 PR/commit）	❌ catalog マージ〜修正完了まで main が瞬間的に赤 → auto-merge 連鎖崩壊。制約2に反する
3	Renovate lockFileMaintenance（定期 lockfile refresh）	△ 同じ #37485 バグを踏み per-package を再生成しない恐れ（未実証）＋定期実行ゆえ窓が大きい
4	commit-back helper Action（Renovate 枝で lockfile 再生成→push back）	❌ Renovate の rebase と衝突（制約1に反する）
5	catalog / overrides 撤廃	❌ overrides: vite: 'catalog:' は vitest の transitive vite を vite-plus-core へ強制するアーキ上必須。撤廃不可

副次策（どの案でも併用検討可）

• frozen install 整合性を path-filter 無しで検証する軽量 gate を新設し、root-only 変更が無検証で main へ抜ける穴（chore(deps): update vite-plus to v0.2.5 #404 が通った経路）を塞ぐ。ただし Renovate PR を赤くして auto-merge を止める副作用があるため、適用範囲は要検討。

暫定運用（恒久策決定まで）

• catalog（vite-plus 等）更新で drift が発生した場合、都度緊急 lockfile 同期を main へ直接着地させる（今回の 6971f15c が実例）。

決めること

• 恒久策として 案1（self-hosted + postUpgradeTasks） を採るか。採る場合、Renovate 用 GitHub App / トークン発行と Mend クラウド App の停止段取りを別途調整する。

Assisted-by: multi-agent-shogun-aki-tweak