# Dependency Upgrade Verification

> Dependency-upgrade verification

- Skill: `randommonicle/dependency-upgrade-verification` (Agent Skill)
- Install (CLI): `npx skillmds@latest add randommonicle/dependency-upgrade-verification`
- Raw SKILL.md: https://api.skillmd.com/api/skills/randommonicle/dependency-upgrade-verification/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: randommonicle (https://skillmd.com/u/randommonicle)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/randommonicle/dependency-upgrade-verification

---


# Dependency-upgrade verification

A SQLite plugin jumped two majors and the question was whether existing on-device databases
would survive. Inspecting runtime data could not answer it: an idempotent initialiser makes
a fresh database indistinguishable from a correctly-upgraded one. The data could not
distinguish the hypotheses, so no amount of device testing would.

## The rule

When runtime evidence cannot distinguish "upgrade handled correctly" from "silently started
fresh" (or any two hypotheses about a major bump), move upstream to something the failure
cannot forge — the dependency's own published source:

```bash
npm pack package@old package@new
# unpack both, diff the file that decides the behaviour
```

Diff the specific file that implements the concern (the storage layer, the migration
handler, the serialisation format), offline, before hunting for a device repro. The tarballs
are free, authoritative, and available without a device.

## Why

Published tarballs are a first-class diagnostic that answers in minutes what black-box
testing cannot answer at all when the observable states are identical. Evidence: ASH
LESSONS_LEARNED 2026-07-20 (SQLite plugin 6 to 8).