showdar-upgradelisted

# Showdar Upgrade ## Purpose - Make upgrades controlled engineering changes rather than version-number edits. - Identify compatibility across runtime, framework, peers, native toolchains, build plugins, and deployment environment. - Search repository usage for breaking/deprecated APIs before modifying versions. - Keep rollback boundaries explicit. - Read `references/compatibility.md`, `references/breaking-changes.md`, and `references/migration-strategy.md` for nontrivial upgrades. ## When to use - Dependency, framework, runtime, SDK, build plugin, iOS/Android platform, or language upgrade. - Migration across deprecated APIs or project template/toolchain changes. - Resolving peer/toolchain compatibility before installing a new version. - Planning staged upgrades across multiple coupled packages. ## When not to use - Installing a new small dependency with no version migration or compatibility question. - Debugging an unknown build failure without evidence that version compatibility is causal. - Production deploy belongs to showdar-ship after the upgrade is verified. - Do not blindly “upgrade everything to latest” unless explicitly requested. ## Inputs and assumptions - Current and target versions (or target policy such as latest supported). - Current runtime/toolchain/native platform versions. - Lockfile/package manager ownership. - Official release/migration information should be checked when freshness matters. - `scripts/inspect-dependencies.mjs` can collect current d