technical-changeloglisted

Produce a **one-page technical report** of what changed for a release, stored in `docs/technical-changelog/<base>-<next>.md`. The report must be grounded in the **real diff** — added/modified/removed code, route/flag/dep/channel deltas — **not** commit messages or the requirements docs. In this repo especially, `docs/**` describes the *end state* and the *whole* feature history (see `docs/ai/requirements-summary.md`), so it routinely credits the range with work that predates it, or describes posture that was already true. Every claim is a verified delta between the base tag and HEAD. ## The two facts that make this skill necessary 1. **HEAD is the next, unreleased version.** `package.json` still holds the *last* released version, so the release number can't be read from the repo — **you must ask the user** what the next planned version is. 2. **The base is always the most recent production release tag** (e.g. `v0.9.0`), and the range is `<base>..HEAD`. Pre-release tags (`-beta`, `-rc`) are never the base. Note this repo's `package.json` version can be far ahead of the newest `vX.Y.Z` tag — the script picks the newest **tag**, which is correct; it warns if that isn't what you expect. ## Steps 1. **Ask for the next release number first.** Use `AskUserQuestion` (or ask in prose): *"What's the next planned release version for this changelog?"* Do not guess and do not read it from `package.json` (that's the previous release). Accept e.g. `1.2.0` / `v1.2.0`