maintaining-dependencieslisted

# Maintaining Dependencies `/app:upgrade` is the procedure; this is the reasoning it leans on. Read it before the first lane, and come back to the signature table the moment a dependency PR goes red. ## Core principle: three files, one truth A pnpm workspace states its dependencies in three places, and they disagree silently: | File | What it is | Who may be lying | | --------------------- | ------------------------- | ------------------------------------------ | | every `package.json` | a **claim** about a range | any spec an override rewrites | | root `pnpm.overrides` | a **rewrite** of claims | any entry whose reason is gone | | `pnpm-lock.yaml` | the **truth** — what runs | never, but it only tells you what, not why | Plus the ledger, `contributing/dependency-overrides.md`, which is where the _why_ lives because `package.json` is strict JSON and cannot carry a comment. Every change keeps all four consistent **in one commit**. A bump that moves a spec but not the override that masks it changed nothing and now lies. An override that moves without its ledger entry outlives its reason. The override-masking check — for every touched override, every workspace spec naming that package is at or below its floor — is not optional, it is the difference between a bump and a claim. ## Direct or transitive — the first question for any advisory ```bash pnpm why <package>