diff --git a/CHANGES.md b/CHANGES.md
index 39f31a8..2773c79 100644
--- a/CHANGES.md
+++ b/CHANGES.md
@@ -35,7 +35,7 @@ dev-checkout concern - readable here, never shipped as something to parse.
 
 ---
 
-## 5.0.0-beta.5 - 2026-09-10 - Konfidenz-Mechanismus ersatzlos entfernt
+## 5.0.0-beta.6 - 2026-09-10 - version-parts.md dokumentiert den --migration-required-Ruecknahmepfad
 
 **Author:** Torben Nehmer
 
@@ -58,6 +58,7 @@ dev-checkout concern - readable here, never shipped as something to parse.
 - dist export erzeugt die TOC-Region nach dem Marker-Strip neu (CI-Fund im Export-Replay)
 - Konfidenz-Mechanismus ersatzlos entfernt
 - Konfidenz-Mechanismus ersatzlos entfernt
+- version-parts.md dokumentiert den --migration-required-Ruecknahmepfad
 <!-- /wikitool:bumps -->
 
 
@@ -985,6 +986,15 @@ ist der mechanische Strip der zwei Felder über den betroffenen Korpus,
 mitsamt der Invariante, die ein automatisierter Lauf einhalten muss (kein
 `modified:`-Bump, byte-identischer Body, unveränderte Referenzarrays).
 
+Nachgezogen in `-beta.6`: `instructions/dev/version-parts.md` Schritt 6
+beschreibt den Rücknahmepfad jetzt selbst. `tools/CONTRACT.md` führte das neue
+Flag bereits, aber die Instruction, die eine Sitzung *vor* einem Bump liest,
+kannte den Fall nicht — dieselbe Sitzung ist genau darüber gestolpert. Der
+Abschnitt nennt auch, warum ihn nichts meldet: die Zeile ist
+maschinengeschrieben, `docs verify` genügt ihr bloßes Vorhandensein, und die
+Eskalationsprüfungen laufen nur auf dem Bump, der die Grenze *zuerst*
+überschreitet.
+
 ---
 
 ## 4.7.4 - 2026-09-04 - bootstrap.md nennt den session-id-WARN nach frischem Bootstrap explizit als erwartet
diff --git a/VERSION b/VERSION
index 90a0894..39c2186 100644
--- a/VERSION
+++ b/VERSION
@@ -1 +1 @@
-5.0.0-beta.5
+5.0.0-beta.6
diff --git a/instructions/dev/version-parts.md b/instructions/dev/version-parts.md
index 19f333b..77ad639 100644
--- a/instructions/dev/version-parts.md
+++ b/instructions/dev/version-parts.md
@@ -157,6 +157,17 @@ the three-line test below is usually enough.
    migrate, with nothing telling it how, is a dead end. Like `--breaking`, both persist across
    later bumps of the same candidate without being repeated.
 
+   **A `--no-migration` answer can turn out wrong later in the same candidate**, and that is not
+   a hand-edit: a bump escalates, a second change lands under the same running number, and now
+   content does have to move after all. Write the migration document first, then retract the line
+   with `version bump --migration-required` - it removes the `**Migration:** none required` line
+   the earlier bump wrote, and refuses unless a document already targets the new base. Nothing
+   else takes that statement back: the line is machine-written (invariant 1), `docs verify` is
+   satisfied by its bare presence, and the escalation checks in this step run only on the bump
+   that *first* crosses the boundary - so a candidate that keeps a stale `none required` line is
+   never reported by anything. The 5.0.0 candidate is the case: it declared `--no-migration` for
+   a TOC-verification change, then absorbed a schema removal that migrates 152 pages.
+
 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