stocktakelisted

# stocktake A stocktake records what the project actually uses before changing what it orders. Dependency work starts from manifests, resolved versions, runtime pins, generated clients, and CI configuration. The requested version is only one line in that inventory. ## Modes - **AUDIT** reports outdated, unsupported, vulnerable, duplicated, or unused dependencies without changing the repository. - **UPDATE** applies a requested version change or an accepted audit finding. - **MIGRATE** handles a major version, runtime, package manager, or toolchain boundary with required source and configuration changes. If the user asks only for an audit, stop after the backlog. Do not turn discovery into a lockfile rewrite. ## 1. Define the boundary Pin the scope before running an updater: - named package, runtime, toolchain, or manifest - requested target version or allowed version range - applications and libraries affected - compatibility floors that must remain supported - whether security remediation changes the priority Split unrelated major upgrades. A runtime migration, framework major, and package-manager change are separate compatibility boundaries even when one command can update all three. ## 2. Inventory resolved state Read every source that can select or constrain a version: - package manifests and workspace roots - lockfiles, checksums, and vendored dependency records - runtime and toolchain pins - CI actions, build images, containers, and deployment configuration -