Upgrade Dependencies

Essential Principles

1. One dependency, one commit. Every package upgrade gets its own atomic commit. No batching, no grouping "low-risk" patches together. This enables git bisect, clean reverts, and clear failure attribution.

2. Research with real sources. Use the web-search skill (see ../web-search/SKILL.md) to fetch current changelogs and migration guides. NEVER rely on training data for version-specific details — it may be stale or wrong.

3. Verify after every single upgrade. Run the full verification suite after each individual package upgrade. Stop on first failure — fix before proceeding.

Verification suite (run in order):

1. Type check: tsc --noEmit (skip if no tsconfig.json)
2. Tests: project's test runner
3. Build: project's build command
4. In monorepos: run across ALL affected workspaces

4. Detect, don't assume. Auto-detect package manager, monorepo structure, test runner, and build tool from the project before starting.

5. Match the project's commit convention. Scan git log --oneline -50 and any commitlint.config.* for prior dependency commits. If none is obvious, default to build(deps): ... — build is a Conventional Commits type and (deps) is the scope Dependabot and Renovate use. Workflow commit steps show default formats; substitute the detected convention when it differs. If history is mixed, pick the most recent form; ask if still unclear.