fix: types/type-spec.schema.yaml enforced against real type-spec frontmatter, doc-pull-through.md docs/-page count corrected (closes #105)

Files changed:
- CHANGES.md
- VERSION
- instructions/dev/doc-pull-through.md
- tools/CONTRACT.md
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/tests/test_docs_verify.py
- types/type-spec.md
- types/type-spec.schema.yaml

CHANGES.md

@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
 
 ---
 
-## 6.0.0-beta.6 - 2026-09-15 - types/: Seiten-Type-Spec-Anleitungsprosa in stackeigene guidance-Datei ausgelagert
+## 6.0.0-beta.7 - 2026-09-15 - types/type-spec.schema.yaml enforced against real type-spec frontmatter
 
 **Author:** Torben Nehmer
 
@@ -79,6 +79,7 @@ concern - readable here, never shipped as something to parse.
 **Medium impact**
 - docs verify: ein nur als .template ausgeliefertes Linkziel gilt als aufgeloest
 - Control-Plane-Sprache universell: Achse ist das Publikum, kein Instanz-Schalter
+- types/type-spec.schema.yaml enforced against real type-spec frontmatter
 
 **Low impact**
 - gates.md/session-setup.md: die Budget-Ausnahme von version regrade haengt an der Aufrufform
@@ -307,6 +308,40 @@ ein `dist upgrade` schreibt verbesserte Guidance-Prosa in eine adoptierte Instan
 Type-Spec selbst nie im Stamp stand, `types describe` komponiert beide Haelften in JSON und
 Textausgabe getrennt nachweisbar).
 
+### types/type-spec.schema.yaml enforced against real type-spec frontmatter
+
+Bei der Vorbereitung der Aenderung oben fiel auf: `types/type-spec.schema.yaml` traegt
+`additionalProperties: false`, kannte aber `root:` und `capture_fields:` nicht, obwohl
+`types/instruction.md` bzw. `types/source.md` beide Felder tragen und `type_resolver.get_root()`/
+`get_capture_fields()` sie lesen. Gegen das Schema validiert waeren beide Type-Specs ungueltig
+gewesen. Dass es niemandem auffiel, war der eigentliche Befund: Type-Spec-Frontmatter wurde
+nirgends gegen sein eigenes Schema validiert - `resolver.validate_frontmatter()` lief nur ueber
+`kb/`-Seiten, neu erzeugte Seiten und Instruktionsdateien, nie ueber die Type-Specs selbst.
+`TypeResolver._validate_type_spec()`, der einzige Weg, den der Selbstbezug `type: types/type-spec.md`
+nimmt, prueft ausschliesslich, ob `type`/`name`/`description` vorhanden sind.
+
+Beide fehlenden Felder ergaenzt (`root:` als Enum `kb`/`repo`, `capture_fields:` als Liste wie
+`page_ref_fields:`), dazu `guidance:` (seit der Aenderung oben real benutzt, aber noch nie im
+Schema). `docs verify` bekommt eine neue Pruefung: jede Datei unter `types/` mit
+`type: types/type-spec.md` validiert jetzt gegen `types/type-spec.schema.yaml`
+(`check_type_spec_frontmatter()`, wiederverwendet `resolver.list_type_specs()` statt eines zweiten
+Parse-Durchlaufs). `types/type-spec.md` § Validation Contract und die beiden `docs verify`-Zeilen
+in `tools/CONTRACT.md` nennen das jetzt.
+
+Daneben ein zweiter, unabhaengiger Befund derselben Aufraeumrunde behoben:
+`instructions/dev/doc-pull-through.md` verwies fuer `docs/`-Seiten weiter auf "AGENTS.md § File
+naming lists all four" - der Zaehler in AGENTS.md selbst war beim vorigen Bump schon auf fuenf
+(plus eine sechste, nur von `CLAUDE.md` aus verlinkte) korrigiert worden, diese eine verbliebene
+Stelle nicht.
+
+Grenzuebertritt-Frage geprueft und verneint: additiv in beide Richtungen - eine bestehende Instanz
+validiert bereits (0 Befunde gegen den realen Baum), und ein Type-Spec ohne die drei neuen Felder
+bleibt unveraendert gueltig. `--patch`, kein `--breaking`, keine neue Migration noetig.
+
+Verifiziert: `tools/wikitool docs verify`/`instructions verify` gruen, 1263 Tests gruen (2 neu:
+alle Type-Specs dieses Repos validieren gegen ihr eigenes Schema; ein Type-Spec mit einem dem
+Schema unbekannten Feld wird gemeldet, mit Dateiname und Feldname in der Meldung).
+
 ## 5.1.0 - 2026-09-12 - changelog: Kandidaten-Eintrag nach Impact gruppiert, version regrade zur Nachkorrektur, version release verlangt eine Zusammenfassung
 
 **Author:** Torben Nehmer