TL;DR: Verify upgrades against the consumers, not just the package: run your own repo's test suite (the downstream code that actually uses the bumped package) as the merge gate, plus the package's own tests as a sanity check. The package's tests prove the package works in isolation; your tests prove the upgrade works in your system. Gate the merge on both.

```text
agent verified the upgrade by running only the package's own test suite  -  30 downstream tests broke after merge
```

1. Reproduce the gap: check out the merged upgrade and run your repo's full test suite (or the affected subset) against it.
   Expected: the 30 downstream failures appear, confirming the verification gap.
2. Change the agent's verification plan: the merge gate is your repo's test suite run against the bumped dependency, not the package's own suite.
   Expected: future upgrades cannot merge without downstream tests passing.
3. Keep the package's own test suite as a secondary check (it catches packaging and environment issues), but never as the sole gate.
   Expected: two green suites required, each catching different failure classes.
4. For widely-used packages, add a consumer smoke test: a small script exercising your actual call paths against the new version, run before the full suite.
   Expected: the most common breakage surfaces in seconds, not after the full run.
5. Verify on the next bump: confirm both suites ran in CI and the merge was blocked until both were green.
   Expected: no more "green merge, red downstream" surprises.

## Use this when
- an upgrade passed its own tests but broke your code after merge
- the agent tests the package in isolation only
- downstream breakage shows up post-merge repeatedly
- the merge gate does not include consumer tests

## Not for this skill when
- your repo has no tests covering the dependency's usage (write those first; the gate needs something to run)
- the breakage is in the package's own behavior that its tests should have caught (report it upstream)
- the downstream failures are flaky and unrelated to the bump (fix the flakes, not the gate)

## Variant phrasings
- "upgrade passed package tests broke downstream"
- "agent only ran the package's own test suite"
- "how to verify dependency upgrade against consumers"
- "green merge then 30 tests broke"
- "downstream tests not run on dependabot PR"

## Why it happens
Running the package's own tests feels thorough: it is the test suite the authors wrote, and it passes. But those tests pin the package's behavior in the author's environment, not yours. Your code depends on the package's public behavior as you use it, which is a different (usually smaller, sometimes quirky) surface. Only your tests exercise that surface, so only your tests can catch when an upgrade changes it.

## Edge cases
- Your test suite may not cover every usage of the package; the consumer smoke test covers the gap for critical paths.
- Running the full downstream suite per candidate version is expensive; combine with the tiered-verification skill (affected subset per candidate, full suite on the finalist).
- If the package's own tests fail in your environment for unrelated reasons (missing optional deps), do not let that block the upgrade; gate on your suite.
- Monorepo consumers: run the affected workspace's tests, not every workspace, unless the package is shared infra.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_89Nr9OONDHnQ6oIWWz_kow