AGENTS.md
+36 −2
https://raw.githubusercontent.com/activeing123/mcptoon/HEAD/AGENTS.md
− | Chocolatey community package | listed (0.8.3); 0.8.5 submitted, awaiting review | manual: build the nupkg, push, wait for the automated review. Advisory-only in the drift gate |− | `microsoft/winget-pkgs` | PR #443014 open (0.8.3), awaiting a community moderator | manual: needs a self-contained zip asset per version. Advisory-only in the drift gate. Say "PR submitted", never "on winget" until merged |+ ### Release notes are in English (added 2026-10-04)+ **The GitHub Release title and body are English — always.** The body is the `CHANGELOG.md`+ block for that version, verbatim; the title is `vX.Y.Z — <short English summary>`. Do not+ paste a commit subject into the title, and do not hand-write a translated body.+ Why this is a rule and not a preference: the Release is a *global* surface. The numtide+ packaging bot and its maintainers, the PyPI project page (which renders this body), the MCP+ Registry, Glama's reviewers and every upstream PR author read it. The Chinese-facing surface+ already exists and is `README.zh-CN.md`. Measured drift this rule prevents: v0.8.12 shipped+ with a Chinese title (the `release:` commit subject, pasted into `name`) and v0.8.11 with a+ fully Chinese body that was never in `CHANGELOG.md` at all — 2 of 47 releases, both fixed+ 2026-10-04. `CHANGELOG.md` itself has stayed 0.0% CJK throughout, so following it is enough+ to stay English; the failure mode is bypassing it.+ ### Batch the release, don't ship every finding (added 2026-10-02)+ **A release is the unit of a finished topic, not of a single fix.** Ship one version per+ topic once the topic is exhausted — not one version per discovery. Measured cost of the+ alternative: **six releases on 2026-10-02** (0.8.6 → 0.8.11), each one a full ritual+ (version in 5 places, 3 claim surfaces, CHANGELOG, tag, GitHub Release, 3 workflow runs,+ tap dispatch, drift gate, ledger in 2 places) — roughly an hour of mechanical work per+ version, and most of it repeated. Worse, every release resets the numtide grace window,+ so the bot that packages us stayed pinned at 0.8.7 all day and could never catch up.+ Rules that follow:+ - **Finish the attack surface before you bump.** If you are probing one module (or one+ class of defect), keep finding and fixing until the probe reports nothing, *then*+ release once. 0.8.10 and 0.8.11 were both products of the same adversarial technique on+ adjacent code and could have shipped together.+ - **Same topic, same version.** A fix and the test that pins it and the docstring it+ corrects belong to one release. Splitting them across versions is what "one finding,+ one release" looks like from the outside.+ - **Cap the cadence at one release per day** unless a shipped defect is actively+ corrupting data or blocking installs. If a second release seems necessary the same day,+ the honest question is whether the first one should have waited.+ - **Do not batch unrelated work into one version to satisfy this rule.** The rule is+ "finish the topic", not "hoard changes". A release with two unrelated themes is harder+ to reason about than two releases with one theme each.+ | Chocolatey community package | listed and **approved at 0.8.5** (2026-10-02 verified: OData `Published=2026-09-30T12:07:12Z`, package page `Approved`) | manual: build the nupkg, `PUT` it, wait for moderation. **There is no automation** — `release_sync.py` lists this one as advisory, so a new release needs a human to push the package. Advisory-only in the drift gate |+ | `microsoft/winget-pkgs` | PR #443014 open (0.8.3), awaiting a community moderator (validation pipeline already passed) | manual: needs a self-contained zip asset per version. Advisory-only in the drift gate. Say "PR submitted", never "on winget" until merged. **Decided 2026-10-02:** merge 0.8.3 first to claim the version number (version directories are immutable in winget), then file a fresh 0.8.5 manifest afterwards. Do not reopen the PR to change its version, and do not chase the moderator.
