feat: Versionskandidat statt Bump-pro-Release - VERSION traegt -beta.N, version release fixiert (4.4.0, #42)

Files changed:
- .gitea/workflows/release.yml
- AGENTS.md
- CHANGES.md
- DEVELOPMENT.md
- README.md
- VERSION
- docs/version-model.md
- instructions/dev/version-parts.md
- tools/CONTRACT.md
- tools/chemenu/commands/dist_cmd.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/doctor.py
- tools/chemenu/commands/migrate_cmd.py
- tools/chemenu/commands/version_cmd.py
- tools/chemenu/kb_state.py
- tools/chemenu/tests/test_dist_cmd.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_doctor.py
- tools/chemenu/tests/test_migrate_cmd.py
- tools/chemenu/tests/test_version_cmd.py
- tools/chemenu/version.py

instructions/dev/version-parts.md

@@ -20,6 +20,36 @@ Two questions decide a version bump, and they are **not the same question**:
 Getting these backwards is how a genuinely breaking change ships as a MINOR. It happened once
 already (see the case study at the end), which is why this file exists.
 
+## The candidate model
+
+Between two releases the stack carries **one running candidate**, not a fresh version per
+`bump`. Five bumps with no release in between used to mean five numbers, four of which nothing
+ever consumed - the release-granularity CI's version gate wants (`VERSION` must move on every
+stack-touching push) was being paid at bump granularity instead. A candidate closes that gap
+without touching the gate: `VERSION` still moves on every bump, it just escalates the *same*
+number instead of handing out a new one.
+
+- **State lives in `VERSION` itself**, as an optional `-beta.N` suffix (`4.4.0-beta.3`). No
+  second state file: the last release is read back out of `CHANGES.md` (the newest entry with no
+  suffix), and the escalation stage is the difference between the candidate's base and that
+  release - derived, not stored.
+- **`--major`/`--minor`/`--patch` is max-wins escalation**, not a step you can undo. A `--patch`
+  bump on a candidate already at MINOR only advances its bump count (`N`); nothing ever steps a
+  candidate back down. Declaring the part is still your judgment call, made the same way section
+  below describes - `escalate()` only ever raises it further.
+- **A candidate is never released.** Pre-release is a dev-checkout state; `release.yml` only acts
+  on a suffix-free `VERSION`, so a distributed instance never sees a `-beta.` version at all, and
+  its parser never has to know the suffix exists.
+- **One `CHANGES.md` entry per candidate**, not per bump. The first bump of a candidate opens it
+  (heading, date, author, and a machine-managed `<!-- wikitool:bumps -->` list seeded with that
+  bump's `--title`); every later bump of the *same* candidate updates that entry in place -
+  heading, date and the bumps list all move, but the entry's own prose (written below the
+  skeleton, by hand) is left alone. `version notes` therefore still prints exactly one entry per
+  release, whatever a candidate's history of bumps looked like.
+- **`version bump` opens or continues a candidate; `version release` fixes one.** Only `release`
+  strips the suffix and turns the entry into a real, closed release - see its own row in
+  `tools/CONTRACT.md`. Nothing else does, and nothing auto-fixes a candidate on its own.
+
 ## When to run
 
 Before every `tools/wikitool version bump` - the `stack-dev` skill's step 3 sends you here.
@@ -63,9 +93,11 @@ the three-line test below is usually enough.
    | Fix, no interface change | `--patch` |
    | New capability, drop-in in both directions | `--minor` |
 
-4. **Stop and talk to the user before a boundary-crossing bump.** It is expensive in a way the
-   other two parts are not: every existing instance pays for it, once, by hand. Put in front of
-   them, in this order:
+4. **Stop and talk to the user before the bump that first escalates a candidate past the
+   boundary.** It is expensive in a way the other two parts are not: every existing instance pays
+   for it, once, by hand. That escalation happens exactly once per candidate - a later bump that
+   keeps the candidate at the same stage (another `--major` on one already there, say) does not
+   re-cross anything and needs no second conversation. Put in front of the user, in this order:
 
    - **What breaks**, concretely - which file, which name, which call site.
    - **What each existing instance must do**, as the steps they would actually run.
@@ -81,8 +113,9 @@ the three-line test below is usually enough.
 
    Then wait for an explicit go-ahead. Do not bump across the boundary on your own initiative.
 
-5. **Record the break in the bump itself.** A boundary-crossing bump requires
-   `--breaking "<what breaks>"`, which writes a `**Breaking Change:**` line into the entry:
+5. **Record the break in the escalation bump itself.** The bump that first crosses the boundary
+   requires `--breaking "<what breaks>"`, which writes a `**Breaking Change:**` line into the
+   entry:
 
    ```bash
    tools/wikitool version bump --major \
@@ -91,22 +124,33 @@ the three-line test below is usually enough.
      --no-migration "<why no page has to change>"     # only if that is true
    ```
 
-   `--breaking` is refused on a bump that crosses nothing, and required on one that does;
-   `docs verify` checks the newest boundary-crossing entry still carries the line. Write it for
-   the operator of an instance that has not read this repository: what stops working, and what
-   they do about it.
+   The line, once written, stays in the entry across every later bump of the same candidate -
+   a follow-up `--major` does not need to repeat `--breaking`, because the entry it would repeat
+   it into is the same one. `--breaking` is refused on a bump that crosses nothing, and required
+   on the one that does. `docs verify` checks the newest boundary-crossing entry still carries
+   the line. Write it for the operator of an instance that has not read this repository: what
+   stops working, and what they do about it.
 
 6. **Then answer the migration question separately.** Boundary-crossing and
    content-migrating are independent:
 
    - Content must change → write the migration document under `instructions/migrations/` per
-     [migrate-corpus.md](../migrate-corpus.md). `bump` finds it by its `migrates_to:` field.
+     [migrate-corpus.md](../migrate-corpus.md). The escalation bump finds it by the document's
+     `migrates_to:` field, matched against the candidate's **base** - a document targets the
+     release the candidate will become, never a `-beta.N` form of it.
    - Content need not change → `--no-migration "<reason>"`, which records that in the entry.
 
    Both are also needed by `docs verify`, for the same reason: an instance that learns it must
-   migrate, with nothing telling it how, is a dead end.
+   migrate, with nothing telling it how, is a dead end. Like `--breaking`, both persist across
+   later bumps of the same candidate without being repeated.
 
-7. **Write the entry's body.** `bump` leaves it empty on purpose. A boundary-crossing entry
+7. **Fix the candidate once it is ready to ship.** `version bump` only ever opens or escalates
+   one; nothing turns it into a release except `tools/wikitool version release`, which strips the
+   `-beta.N` suffix and closes the entry - see its row in `tools/CONTRACT.md`. That is also the
+   point to pass a summarising `--title` if the candidate collected several bump titles along the
+   way; without one, the heading simply keeps whichever bump last set it.
+
+8. **Write the entry's body.** `bump` leaves it empty on purpose. A boundary-crossing entry
    earns a paragraph that says *why this is breaking* - it is the one thing a future reader
    cannot reconstruct from the diff, and it is what the next session in this position will read
    instead of guessing.