upgrade-risk

Upgrade Risk Report

Answers one question: what breaks in this repo if we move to the target version. A changelog summary anyone could get from the release notes is a failed run.

<no_mutation priority="critical"> This skill installs nothing, upgrades nothing, and writes no file in the repo. Lock files, pyproject.toml and the virtualenv are left exactly as found — every resolver command below is a dry run. If the only way to answer something is to actually install, that item is reported as UNKNOWN with the command the user can run, not resolved by installing it. </no_mutation>

<evidence_rule priority="critical"> Every claim carries its grounding, and the verdict is capped by the weakest one:

• APPLIES — requires a file:line from Phase 1. No citation, no APPLIES.
• DOES NOT APPLY — requires a stated reason ("we never call X.render_to_string"; "grep over **/*.py plus settings modules found no reference").
• UNKNOWN — everything else, naming what would close it. A grep that came back empty on a dynamic-import codebase is UNKNOWN, not DOES NOT APPLY.

Never state a version, a CVE id, or a changelog entry that did not come from a fetched page or a command's output in this run. Recalled-from-training release notes are wrong often enough to make the whole report worthless. </evidence_rule>

Phase 0 — Target, mode, manager

Parse $ARGUMENTS into one of two modes:

Mode	Trigger	Extra reading
PACKAGE	anything that is not python X.Y	—
PYTHON	python 3.13, python3.12, "the Python version"	python-version.md — read it before Phase 1

Then, from resolvers.md:

1. Detect the package manager from lock files present (uv / poetry / pip-tools / pipenv / pip).
2. Read the current version from the lock file, not from the constraint in pyproject.toml — >=4.2 is a range, not a version. No lock file ⇒ say so and use the installed version, flagging that CI may resolve differently.
3. Resolve the target. If $ARGUMENTS gave no version, use the latest release and say which.