superstack-depslisted

# superstack-deps The platform moves under every project. An upgrade is ordinary work with one distinguishing risk: the breaking change you didn't read about — so the method is inventory, batches, and a checkpoint per batch. ## The method 1. **See green first, then inventory — printed.** Run the project's named verify command *before* any bump: a post-bump red you can't attribute is two hours of bisecting a failure that predated you (scope's rule, applied here). Then the inventory: what's depended on, current vs latest, EOL/advisory flags, and which dependencies are load-bearing vs incidental. When the work spans sessions, the inventory lives at the top of the task file (`.superstack/tasks/<slug>.md`) — dated, so the next session diffs against it instead of re-deriving it. 2. **Batch by risk, not alphabet.** Patch-safe bumps travel together; each major travels **alone**, with its breaking-change digest read from the actual changelog — opened, not guessed (R1: the changelog is a file you haven't opened yet). 3. **Each batch ends at a checkpoint:** the project's named verify command green, then a commit — so any batch is a legal stopping point and execution moves verified-state to verified-state (the plan shape). Rollback per batch is the commit revert — which stays true only if batches are pure: **no drive-by refactors inside an upgrade commit.** 4. **A big migration is a campaign.** Framework major, runtime jump, anything spanning sessions: open a plan file and run superst