feat: changelog entries stay compact - one paragraph per topic, a size budget in docs verify and version release, version bump names required migration documents (#184)

Files changed:
- CHANGES.md
- DEVELOPMENT.md
- VERSION
- instructions/dev/stack-build/SKILL.md
- instructions/dev/version-parts.md
- instructions/migrate-corpus.md
- tools/CONTRACT.md
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/version_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_version_cmd.py
- tools/chemenu/version.py

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

CHANGES.md

@@ -1,61 +1,37 @@
 # Changelog
 
 This file tracks changes to the **wiki stack itself** - `AGENTS.md`, the
-`instructions/` layer, `tools/wikitool`, and the contracts. It is distinct from
-`kb/log.md`, which is the audit trail of *wiki content* operations (ingests,
-queries, lints, page creates/updates) performed by the LLM against `kb/`.
+`instructions/` layer, `tools/wikitool`, and the contracts - one entry per
+release, newest first. It is distinct from `kb/log.md`, the audit trail of
+*wiki content* operations against `kb/`. Entries below `0.1.0` predate
+versioning and carry a date-only heading.
 
-Previously each of `AGENTS.md` and `README.md` carried its own "Version
-History" table. Those have been consolidated here so there is one place to
-look for "what changed in the tooling/schema, and when." From now on,
-document any change to the stack (schema, instructions, `wikitool` commands,
-contracts) as a new entry at the top of this file instead of editing inline
-version history tables.
+`wikitool version bump` opens and updates the running candidate's entry and
+`wikitool version release` closes it; the topmost entry is what
+`wikitool version notes` prints as the release notes. What an entry contains,
+who writes which part, and the size budget it is held to are defined in one
+place only: `instructions/dev/version-parts.md` § The candidate model.
 
-Since `0.1.0` an entry's heading also carries the stack version it describes
-(`## <version> - <date> - <title>`). `wikitool version bump` writes that
-heading, and `wikitool docs verify` refuses a tree whose `VERSION` and newest
-versioned entry disagree. Entries below `0.1.0` predate versioning and keep
-their date-only headings.
+---
 
-Since `4.4.0` the stack carries **one running candidate** between two
-releases rather than a fresh version per bump - see
-`instructions/dev/version-parts.md`. While a candidate is open its heading
-names it with a `-beta.N` suffix (`## 4.4.0-beta.2 - <date> - <title>`), and
-every bump of that same candidate updates this one entry in place rather than
-opening another: the heading's version/date/title move, and the bump's
-`--title` joins a machine-managed `<!-- wikitool:bumps -->` list right under
-the entry's `**Author:**`/`**Breaking Change:**`/`**Migration:**` lines -
-written and read by `wikitool version bump`, never by hand.
+## 8.1.0-beta.1 - 2026-10-06 - Changelog kompakt: ein Absatz pro Thema, Größenbudget, Migrationsverweis
 
-`**Breaking Change:**` accumulates, because one candidate can cross the
-compatibility boundary more than once and each crossing is a separate thing an
-operator has to act on: one reason stays on the marker line, a second and
-further ones move to bullets beneath a bare marker. `**Migration:**` does not -
-it answers one yes/no question about the candidate as a whole, so a later
-answer replaces the earlier one.
+**Author:** Torben Nehmer
 
-That list is graded, not a flat chronological dump: each bump carries an
-impact (`--impact high|medium|low`, default `medium`), and the list renders
-grouped under `**High/Medium/Low impact**` headings - except when every bump
-so far is `medium`, where it stays flat with no headings at all, exactly as
-it always did before grading existed. `wikitool version regrade` corrects a
-grade after the fact, against a single read of the whole list. Below the
-list comes a short summary paragraph, written once at release time, and below
-that one `### <bump title>` changeset per bump, in chronological order -
-`wikitool version release` refuses to close a candidate that collected two or
-more bumps and has no summary there (a one-bump candidate is exempt, since its
-single changeset already reads as one). This layering exists because a
-long-running candidate's bump list, left flat and ungraded, grows unreadable
-as a release announcement - the concrete case that forced it was `5.0.0`, one
-entry across roughly 1440 lines.
+<!-- wikitool:bumps -->
+- Changelog kompakt: ein Absatz pro Thema, Größenbudget, Migrationsverweis
+<!-- /wikitool:bumps -->
 
-`wikitool version release` is what closes a candidate: it strips the suffix
-and turns the entry into an ordinary, suffix-free one, leaving the bump list,
-summary and changesets as the record of what happened. A distributed instance
-never sees a `-beta.` version at all (`release.yml` only ever releases a fixed
-one), so the suffix and everything below the heading are a dev-checkout
-concern - readable here, never shipped as something to parse.
+### Changelog-Einträge mit Größenbudget und Migrationsverweis (#184)
+
+Ein Eintrag bekommt `###`-Abschnitte pro Thema statt pro Bump; eine kleinere Änderung steht nur
+als Bump-Titel in der Liste. `docs verify` und `version release` halten den obersten Eintrag bei
+höchstens 32 000 Bytes und jeden `###`-Abschnitt bei genau einem Absatz von höchstens 1 000 Bytes,
+die Überschrift nicht mitgezählt; ältere Einträge bleiben ungeprüft. Zielt ein erforderliches
+Migrationsdokument auf die Basis des Kandidaten, schreibt jeder `version bump` die Zeile
+`**Migration:** required - <pfad>` anstelle von `none required`, und `docs verify` meldet einen
+grenzüberschreitenden Eintrag, der sein Dokument nicht nennt. Die Formregeln stehen nur noch in
+`instructions/dev/version-parts.md`.
 
 ---