Dokumentations-Verifikation

Dokumentierte Aussagen gegen den Code prüfen, nie den Code gegen das Dokument

Ein Semantic Contract: Vokabular, das dein Projekt selbst mitliefert — zum Einsetzen in deine CLAUDE.md / AGENTS.md.

Dokumentation gegen den Code verifizieren, in beide Richtungen.

Fragen, was die Implementierung zutage gefördert hat, das die Dokumente noch nicht sagen
Für jede strukturelle Aussage in Architektur- und Spezifikationsdokumenten bestätigen, dass sie heute noch stimmt: Modulnamen, Klassennamen, Dateipfade, Tabellen- und Spaltennamen, Enum-Werte, Invarianten, Startbefehle und Aussagen der Form „die einzige Stelle, an der X passiert“
Jede Aussage auflisten, die nicht mehr stimmt, mit Fundstelle im Dokument und im Code
Nie den Code an das Dokument anpassen. Das Dokument beschreibt eine Absicht, der Code die Wirklichkeit. Das Dokument korrigieren oder ein Issue anlegen, wo der Code falsch ist
Berichten, wie viele Aussagen geprüft wurden und wie viele abgedriftet sind
Strukturelle Aussagen mechanisch prüfbar machen, wo das Projekt es zulässt: Tabellennamen, Spaltennamen, Modulpfade, Enum-Werte. Traceability-Werkzeuge, die nur vorwärts laufen (jede Regel hat einen Test), bemerken nie eine dokumentierte Spalte, die es im Schema nicht gibt
Eine strukturelle Aussage, die kein Test prüfen kann, gehört nicht in die Dokumentation. Entweder prüfbar machen oder löschen
Nach dem Bug-Fix-Loop erneut verifizieren, vor dem Release: Fixes ändern Verhalten, und geändertes Verhalten macht aus einer korrekten Aussage eine veraltete

Verwandte Anker