types/type-spec.schema.yaml deklarierte additionalProperties: false, kannte aber die Felder root: und capture_fields: nicht, obwohl types/instruction.md (root: repo) und types/source.md (capture_fields: [fidelity, authority]) beide tragen und type_resolver.get_root()/get_capture_fields() sie lesen. Gegen das Schema validiert waeren
beide Type-Specs ungueltig gewesen - und niemandem fiel es auf, weil Type-Spec-Frontmatter
nirgends gegen das Schema validiert wurde.
Entscheidung
Wie im Befund empfohlen: eingeschaltet, nicht als reine Dokumentation gekennzeichnet.
Umsetzung (erledigt)
root: (Enum kb/repo) und capture_fields: (Liste wie page_ref_fields:) im Schema
ergaenzt. Dazu guidance:, das seit #104 real benutzt wird, aber ebenfalls nie im Schema stand.
docs verify bekam eine neue Pruefung (check_type_spec_frontmatter()): jede Datei unter types/ mit type: types/type-spec.md validiert jetzt gegen types/type-spec.schema.yaml,
wiederverwendet resolver.list_type_specs() statt eines zweiten Parse-Durchlaufs.
types/type-spec.md § Validation Contract und beide docs verify-Zeilen in tools/CONTRACT.md nennen die neue Pruefung.
Nebenbei behoben: instructions/dev/doc-pull-through.md verwies noch auf "AGENTS.md § File
naming lists all four" docs/-Seiten - der Zaehler in AGENTS.md selbst stand schon auf fuenf
(plus eine sechste, nur von CLAUDE.md verlinkte).
Akzeptanzkriterien
root: und capture_fields: stehen im Schema, mit den Mustern, die get_root() und get_capture_fields() tatsaechlich akzeptieren (root: nur kb oder repo).
Jede Datei unter types/ mit type: types/type-spec.md validiert gegen types/type-spec.schema.yaml - nachgewiesen durch test_this_repos_type_specs_validate_against_their_own_schema, das ueber alle Type-Specs
des Repos laeuft (nicht durch einen Einzelfall), und test_an_unknown_type_spec_field_is_reported
fuer die Gegenrichtung.
Ein Type-Spec mit einem im Schema unbekannten Frontmatterfeld wird gemeldet (eingeschaltet,
also diese Haelfte des Kriteriums).
pytest in tools/: 1263 gruen (2 neue Tests fuer diese Aenderung)
check_type_spec_frontmatter() gegen den realen Baum: 0 Befunde (alle acht bestehenden
Type-Specs validieren)
Grenzuebertritt
Additiv in beide Richtungen - eine bestehende Instanz validiert bereits (0 Befunde gegen den
realen Baum), ein Type-Spec ohne die drei neuen Felder bleibt unveraendert gueltig. --patch,
kein --breaking, keine neue Migration noetig.
Veroeffentlicht als 6.0.0-beta.7, Commit 55f65c1.
## Befund
`types/type-spec.schema.yaml` deklarierte `additionalProperties: false`, kannte aber die Felder
`root:` und `capture_fields:` nicht, obwohl `types/instruction.md` (`root: repo`) und
`types/source.md` (`capture_fields: [fidelity, authority]`) beide tragen und
`type_resolver.get_root()`/`get_capture_fields()` sie lesen. Gegen das Schema validiert waeren
beide Type-Specs ungueltig gewesen - und niemandem fiel es auf, weil Type-Spec-Frontmatter
nirgends gegen das Schema validiert wurde.
## Entscheidung
Wie im Befund empfohlen: **eingeschaltet**, nicht als reine Dokumentation gekennzeichnet.
## Umsetzung (erledigt)
- `root:` (Enum `kb`/`repo`) und `capture_fields:` (Liste wie `page_ref_fields:`) im Schema
ergaenzt. Dazu `guidance:`, das seit #104 real benutzt wird, aber ebenfalls nie im Schema stand.
- `docs verify` bekam eine neue Pruefung (`check_type_spec_frontmatter()`): jede Datei unter
`types/` mit `type: types/type-spec.md` validiert jetzt gegen `types/type-spec.schema.yaml`,
wiederverwendet `resolver.list_type_specs()` statt eines zweiten Parse-Durchlaufs.
- `types/type-spec.md` § Validation Contract und beide `docs verify`-Zeilen in
`tools/CONTRACT.md` nennen die neue Pruefung.
- Nebenbei behoben: `instructions/dev/doc-pull-through.md` verwies noch auf "AGENTS.md § File
naming lists all four" `docs/`-Seiten - der Zaehler in AGENTS.md selbst stand schon auf fuenf
(plus eine sechste, nur von CLAUDE.md verlinkte).
## Akzeptanzkriterien
- [x] `root:` und `capture_fields:` stehen im Schema, mit den Mustern, die `get_root()` und
`get_capture_fields()` tatsaechlich akzeptieren (`root`: nur `kb` oder `repo`).
- [x] Jede Datei unter `types/` mit `type: types/type-spec.md` validiert gegen
`types/type-spec.schema.yaml` - nachgewiesen durch
`test_this_repos_type_specs_validate_against_their_own_schema`, das ueber alle Type-Specs
des Repos laeuft (nicht durch einen Einzelfall), und `test_an_unknown_type_spec_field_is_reported`
fuer die Gegenrichtung.
- [x] Ein Type-Spec mit einem im Schema unbekannten Frontmatterfeld wird gemeldet (eingeschaltet,
also diese Haelfte des Kriteriums).
- [x] `docs verify`, `instructions verify` und `pytest` gruen (1263 Tests, 2 neu).
## Verifiziert
- `tools/wikitool docs verify` / `instructions verify`: gruen
- `pytest` in `tools/`: 1263 gruen (2 neue Tests fuer diese Aenderung)
- `check_type_spec_frontmatter()` gegen den realen Baum: 0 Befunde (alle acht bestehenden
Type-Specs validieren)
## Grenzuebertritt
Additiv in beide Richtungen - eine bestehende Instanz validiert bereits (0 Befunde gegen den
realen Baum), ein Type-Spec ohne die drei neuen Felder bleibt unveraendert gueltig. `--patch`,
kein `--breaking`, keine neue Migration noetig.
Veroeffentlicht als `6.0.0-beta.7`, Commit `55f65c1`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Befund
types/type-spec.schema.yamldeklarierteadditionalProperties: false, kannte aber die Felderroot:undcapture_fields:nicht, obwohltypes/instruction.md(root: repo) undtypes/source.md(capture_fields: [fidelity, authority]) beide tragen undtype_resolver.get_root()/get_capture_fields()sie lesen. Gegen das Schema validiert waerenbeide Type-Specs ungueltig gewesen - und niemandem fiel es auf, weil Type-Spec-Frontmatter
nirgends gegen das Schema validiert wurde.
Entscheidung
Wie im Befund empfohlen: eingeschaltet, nicht als reine Dokumentation gekennzeichnet.
Umsetzung (erledigt)
root:(Enumkb/repo) undcapture_fields:(Liste wiepage_ref_fields:) im Schemaergaenzt. Dazu
guidance:, das seit #104 real benutzt wird, aber ebenfalls nie im Schema stand.docs verifybekam eine neue Pruefung (check_type_spec_frontmatter()): jede Datei untertypes/mittype: types/type-spec.mdvalidiert jetzt gegentypes/type-spec.schema.yaml,wiederverwendet
resolver.list_type_specs()statt eines zweiten Parse-Durchlaufs.types/type-spec.md§ Validation Contract und beidedocs verify-Zeilen intools/CONTRACT.mdnennen die neue Pruefung.instructions/dev/doc-pull-through.mdverwies noch auf "AGENTS.md § Filenaming lists all four"
docs/-Seiten - der Zaehler in AGENTS.md selbst stand schon auf fuenf(plus eine sechste, nur von CLAUDE.md verlinkte).
Akzeptanzkriterien
root:undcapture_fields:stehen im Schema, mit den Mustern, dieget_root()undget_capture_fields()tatsaechlich akzeptieren (root: nurkboderrepo).types/mittype: types/type-spec.mdvalidiert gegentypes/type-spec.schema.yaml- nachgewiesen durchtest_this_repos_type_specs_validate_against_their_own_schema, das ueber alle Type-Specsdes Repos laeuft (nicht durch einen Einzelfall), und
test_an_unknown_type_spec_field_is_reportedfuer die Gegenrichtung.
also diese Haelfte des Kriteriums).
docs verify,instructions verifyundpytestgruen (1263 Tests, 2 neu).Verifiziert
tools/wikitool docs verify/instructions verify: gruenpytestintools/: 1263 gruen (2 neue Tests fuer diese Aenderung)check_type_spec_frontmatter()gegen den realen Baum: 0 Befunde (alle acht bestehendenType-Specs validieren)
Grenzuebertritt
Additiv in beide Richtungen - eine bestehende Instanz validiert bereits (0 Befunde gegen den
realen Baum), ein Type-Spec ohne die drei neuen Felder bleibt unveraendert gueltig.
--patch,kein
--breaking, keine neue Migration noetig.Veroeffentlicht als
6.0.0-beta.7, Commit55f65c1.root:,capture_fields:,guidance:ins Schema nachgetragen,docs verifyvalidiert jetzt jeden Type-Spec dagegen,doc-pull-through.mds veralteter "vier"-Verweis auf fuenf korrigiert.6.0.0-beta.7, Commit55f65c1.