docs: Migrationsdokument haelt das Vorher fest und verweist auf die .template-Form, Rest-Abschnitt aus types/source.md entfernt (#107)

Files changed:
- CHANGES.md
- VERSION
- instructions/migrate-corpus.md
- instructions/migrations/6.0.0-type-guidance-split.md
- types/source.md

instructions/migrate-corpus.md

@@ -120,6 +120,16 @@ Write it for a reader who has the new machinery and the old content, and who is
 changed, which pages are affected, how to tell a migrated page from an unmigrated one, and what
 `migrate verify` should report when it is done.
 
+**A verification step names its own baseline, and does it in an earlier step.** Where the
+document asks that something "read the same as before" - a composed `types describe` answer, a
+rendered index, any command's output - it says what to capture, where to put it, and at which
+point, so the check is a `diff` rather than a memory. Step 4's `migrate verify` needs none of
+that: its baseline is the last commit, which git holds whether or not anyone thought to keep it.
+A migration that changes machinery rather than `kb/` pages has no such baseline, and that is
+exactly where the unfalsifiable version has already slipped through - the 6.0.0 type-guidance
+split asked for output that "must read the same", named nothing to compare it against, and a
+stray section in the middle of one type-spec survived a check made in good faith.
+
 **Baseline: 1.0.0.** Migrations that predate it - the type-system move, the `confidence_base`
 backfill, the German section headings, the translation itself - have no documents and will not
 get any. An instance older than that is re-exported, not migrated.

instructions/migrations/6.0.0-type-guidance-split.md

@@ -56,7 +56,7 @@ upgrade(s) available"; taking it is not gated on anything else being current.
    shipped default.** Compare the type-spec's current prose (everything outside `## Frontmatter`
    and `## Template`) against the corresponding `types/<name>.guidance.md`:
 
-   - **Unchanged, or changed only in ways this instance is happy to lose:** proceed to step 3
+   - **Unchanged, or changed only in ways this instance is happy to lose:** proceed to step 4
      directly - the new guidance file already carries the improved version.
    - **Locally edited in a way worth keeping** (a house style note, an extra rule specific to
      this corpus): that edit has to move somewhere before the old prose is dropped. Either fold
@@ -65,28 +65,69 @@ upgrade(s) available"; taking it is not gated on anything else being current.
      instead of adding `guidance:` at all - both are legitimate; declining the stack default for
      one type is not an error.
 
-3. **Add `guidance: types/<name>.guidance.md` to the type-spec's frontmatter** - by hand, the same
+3. **Write down what `types describe` answers today, before changing anything.** Step 6 checks
+   that the composed answer still reads the same, and that is only a check if the "before" was
+   recorded somewhere other than your memory:
+
+   ```bash
+   tools/wikitool types describe <name> > /tmp/<name>-before.txt
+   ```
+
+   The whole output, per type-spec you are about to touch. Reading it through `head` or `tail`
+   instead is how a difference in the middle of a 150-line answer survives the check - and a
+   stray section in the middle of one type-spec is exactly what this step exists to catch.
+
+4. **Add `guidance: types/<name>.guidance.md` to the type-spec's frontmatter** - by hand, the same
    way any other type-spec frontmatter field is written (a type-spec is machinery, not a `kb/`
    page, so this is not a `wikitool touch` call). Do not remove `## Frontmatter` or `## Template`;
    only the generic prose around them is what the guidance file now carries.
 
-4. **Delete the now-duplicated prose from the type-spec**, keeping the H1, a short pointer to the
-   guidance file (`types/entity.md`'s own current text is the worked example), `## Frontmatter`
-   and `## Template`. Where step 2 found a local edit worth keeping and it lives in the
-   type-spec's own body rather than a private guidance file, leave that part exactly where it is.
+5. **Delete the now-duplicated prose from the type-spec**, keeping the H1, a short pointer to the
+   guidance file, `## Frontmatter` and `## Template`. Where step 2 found a local edit worth
+   keeping and it lives in the type-spec's own body rather than a private guidance file, leave
+   that part exactly where it is.
 
-5. **Verify:**
+   **The worked example is `types/<name>.md.template`, not `types/<name>.md`.** The latter is the
+   copy this instance adopted at setup - it is the file you are editing, so it still shows the
+   before-state. The `.template` beside it ships verbatim with every release and already carries
+   the after-state: H1, pointer paragraph, and `guidance:` in the frontmatter. Read it for the
+   shape; do not copy it wholesale, because its `## Frontmatter` and `## Template` are the
+   stack's defaults and yours are yours.
+
+   **The pointer paragraph is written in English**, like the H1 above it. It is authoring prose
+   addressed to an agent, so it belongs to the control plane whether or not this instance owns
+   the file it sits in - and so does any prose you keep beside it. A local note written in this
+   instance's KB language before that rule existed is therefore translated, not relabelled:
+   an English heading over a body in another language is the half-done version of this step.
+   [types/type-spec.md](../../types/type-spec.md#who-owns-a-type-spec) has the part-by-part
+   table; `## Frontmatter` and `## Template` are untouched by this migration either way.
+
+   **Do not head a kept note `## Authoring guidance`.** `types describe` sets that heading itself
+   and inlines the guidance file beneath it, which brings its own - so a third one out of the
+   type-spec's body reads as a duplicated section in the composed answer. Give a local note a
+   name of its own.
+
+6. **Verify against the file from step 3:**
 
    ```bash
-   tools/wikitool types describe <name>
+   tools/wikitool types describe <name> > /tmp/<name>-after.txt
+   diff /tmp/<name>-before.txt /tmp/<name>-after.txt
    ```
 
-   The output must read the same as it did before this migration - the guidance prose composed
-   ahead of the type-spec's own body, in one answer. A diff against the pre-migration output of
-   the same command, restricted to wording, is expected only where step 2 found something to
-   drop or fold in; the structure (frontmatter fields, template block) must be byte-identical.
+   The two must read the same - the guidance prose composed ahead of the type-spec's own body,
+   in one answer. Wording differences are expected only where step 2 found something to drop or
+   fold in; the structure (frontmatter fields, template block) must be byte-identical, and a
+   heading that stands in the "after" but not in the "before" means prose was renamed where it
+   should have been removed. One number catches the most likely version of that:
 
-6. **Record it:**
+   ```bash
+   grep -c '^## Authoring guidance' /tmp/<name>-after.txt
+   ```
+
+   Two is correct - the one `types describe` sets, and the one the guidance file brings. Three
+   means the type-spec's own body still carries a section of that name (step 5).
+
+7. **Record it:**
 
    ```bash
    tools/wikitool migrate done 6.0.0 --pages 0