docs toc/verify: die .template-Form einer Referenzdatei steht im Dateisatz, Version 6.0.1 freigegeben (schliesst #106)

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/doc-pull-through.md
- kb/CONVENTIONS.md.template
- tools/CONTRACT.md
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/tests/test_docs_verify.py
- tools/chemenu/tests/test_toc.py
- tools/chemenu/toc.py

CHANGES.md

@@ -59,6 +59,53 @@ concern - readable here, never shipped as something to parse.
 
 ---
 
+## 6.0.1 - 2026-09-16 - docs toc/verify erreichen die .template-Form einer Referenzdatei
+
+**Author:** Torben Nehmer
+
+<!-- wikitool:bumps -->
+**High impact**
+- docs toc/verify erreichen die .template-Form einer Referenzdatei
+<!-- /wikitool:bumps -->
+
+### docs toc/verify erreichen die .template-Form einer Referenzdatei
+
+`kb/CONVENTIONS.md.template` war 105 Zeilen lang und trug keine TOC-Region. `toc.target_files()`
+berechnete den Dateisatz ueber die *adoptierten* Namen, und eine Datei auf `.md.template` faellt
+aus jedem dieser Walks heraus - also hat `docs toc --apply` das Template nie angefasst und
+`docs verify` es nie gelesen. Eine Instanz, die es nach `instructions/setup-instance.md`
+adoptiert, bekam damit eine `kb/CONVENTIONS.md` ohne Region und fiel am `docs verify` in
+Schritt 13 derselben Anleitung um - dem Befehl, mit dem das Setup endet. Ausgeliefert war das in
+`6.0.0`.
+
+Eine in Scope stehende Datei nimmt ihr `<name>.template` jetzt mit hinein: das Template ist
+dasselbe Dokument einen Schritt frueher in seinem Leben, und wer es auslaesst, laesst die
+adoptierte Kopie den Fehler erben. `docs verify` prueft im Ursprungs-Repo damit 57 statt 56
+Referenzdateien, in einer frisch exportierten Instanz 59.
+
+Ausgeloest hat es ein Wachstum um sechs Zeilen: `f350999` hat das Template von 99 auf 105 Zeilen
+gebracht und damit ueber die Schwelle von 100. Seither war `ci.yml` auf jedem Push rot (Laeufe
+279 bis 289) - was als Flackern gelesen wurde, weil jeder Push zusaetzlich einen gruenen
+`release.yml`-Lauf erzeugt und die Paare wie Lauf und Wiederholung aussehen. Sie sind zwei
+verschiedene Workflows.
+
+Grenzuebertritt-Frage geprueft und verneint, gegen den dokumentierten Update-Weg: das Template ist
+stack-eigen (`ownership.is_stack_owned` - jede `.template` unter einer Content-Stage), steht nicht
+in `UPGRADE_PRESERVED_PATHS`, und `dist upgrade` schreibt es damit mit. Eine Instanz bekommt das
+reparierte Template also durch den Upgrade selbst, ohne Handarbeit; der Rueckweg funktioniert
+ebenso, weil die alte Maschinerie das Template gar nicht erst prueft. Handarbeit faellt nur an, wo
+eine Instanz ihr stack-eigenes Template lokal veraendert hat - `dist upgrade` meldet genau das als
+`blocked` und verlangt `--keep-local`.
+
+Verifiziert: `docs verify`/`instructions verify` gruen, 1275 Tests gruen (3 neu: das Template einer
+in Scope stehenden Datei steht im Dateisatz, ein `.template` ohne solche Datei daneben nicht
+(`USER.md.template`), und ein Template ueber der Schwelle ohne Region ist ein Befund - der letzte
+waere am heutigen Stand rot gewesen). Dazu der vollstaendige `setup-instance.md`-Replay gegen einen
+frischen `dist export`: `doctor`, `docs verify`, `instructions verify` und `lint` laufen in der
+frischen Instanz durch.
+
+---
+
 ## 6.0.0 - 2026-09-15 - search: Pfad und Titel vollstaendig, Trunkierung sichtbar
 
 **Author:** Torben Nehmer