adopt-releaselisted

# Adopt release A release can carry hundreds of changes, and only a few touch this project. Find those few, prove each one against a file, and count the rest. ## Step 1: Pin the range The target is the version in $ARGUMENTS, else the latest stable release upstream publishes. The start is the version this project was last adapted to. Read it from the project's pin: lockfile, manifest constraint, `.tool-versions`, `.nvmrc`, `engines`, Docker base image, CI matrix. A tool the user runs outside the project (an agent host, a CLI) often has no pin, and its installed version is already the new one: ask the user once for the start version or a date, and take every release after it. Done when both ends are exact versions. ## Step 2: Map the surface The **surface** is every point where this project touches the tool. Build it before you read any release notes: it is the filter for Step 4. - **Pin sites**: every file that names the version, including type packages such as `@types/node` and docs that state a minimum. - **Config**: the tool's config files and every key the project sets. For a tool the user runs, include its user-level directories (`~/.claude/`; `~/.codex/` and `~/.agents/skills/` for Codex) and everything the project ships to it: skills and their frontmatter, hooks, plugin manifests, `AGENTS.md`, MCP config. - **API**: imported modules and symbols, CLI commands and flags in scripts and CI, env vars, file formats the project reads or writes. - **Workarounds**: code