# Wissens-Lint statt Datenfriedhof URL: https://www.mikebild.dev/de/blog/wissens-lint-statt-datenfriedhof/ Ein Wiki kann jeden Monat wachsen und gleichzeitig unbrauchbarer werden. Neue Seiten kommen hinzu, alte Aussagen bleiben stehen, Beziehungen zeigen ins Leere und offene Vorschläge warten so lange, dass niemand mehr ihren Anlass kennt. Die Zahl der Dokumente steigt; das Vertrauen sinkt. Eine bessere Suche löst dieses Problem nicht, denn sie kann auch veraltete und widersprüchliche Aussagen finden, ohne ihren Zustand zu bewerten. Was fehlt, sind überprüfbare Qualitätsregeln für Claims, Belege und Beziehungen. WikiKit behandelt Wissensqualität deshalb ähnlich wie Codequalität. Der Lint-Lauf untersucht den sichtbaren Stand und weist unter anderem Widersprüche, fehlende Belege, beschädigte Beziehungen, veraltete Claims und verwaiste Konzepte aus. Der Lauf braucht kein Sprachmodell. Er ist eine deterministische Diagnose: Bei gleichem sichtbarem Stand, gleicher Konfiguration und gleicher Regelversion müssen dieselben Regeln zu denselben Befunden führen. Was aus einem Befund folgt, entscheidet der Lauf nicht – das bleibt Sache des menschlichen Reviews. ## Lint prüft Invarianten, keine Schreibästhetik Ein Linter kann feststellen, ob ein sichtbarer Claim keinen Beleg besitzt, eine Beziehung beschädigt ist oder sichtbare Claims einander widersprechen. Er kann nicht allgemeingültig entscheiden, ob eine Erklärung elegant oder eine Architekturentscheidung klug ist. Der Regelsatz ist Stand August 2026 breiter als die Beispiele in diesem Text; die folgenden Befunde stehen stellvertretend für die Art der Prüfung, nicht für ihren vollständigen Umfang. Vereinfachtes, illustratives Beispiel einer Ausgabe – die Feldnamen sind hier kein vollständiger API-Vertrag: ```json { "findings": [ { "rule": "missing-citations", "severity": "error", "concept_slug": "refund-policy", "message": "A visible claim has no citation." }, { "rule": "orphan-concepts", "severity": "warn", "concept_slug": "legacy-import", "message": "The concept appears to be isolated." } ], "counts": { "error": 1, "warn": 1, "info": 0 } } ``` Solche Befunde lassen sich durch Menschen prüfen und durch Workflows auswerten. Ein Workflow kann bei Fehlern scheitern, Warnungen sammeln und Hinweise nur protokollieren. Eine prüfende Person öffnet anschließend die betroffenen Konzepte und Quellen. Der Lint-Lauf selbst ändert weder Claims noch Konzepte – er weist Befunde aus, damit sie trotz wachsendem Bestand bearbeitet werden können. ```mermaid flowchart LR K["freigegebener Wissensstand"] --> L["LLM-freier Lint-Lauf"] L --> B["Befunde zu Belegen,
Konsistenz und Pflege"] B --> E{"fachliche Einordnung:
Änderungsbedarf?"} E -->|ja| P["Änderungsvorschlag"] E -->|nein| D["Befund dokumentieren"] P --> R["menschliches Review"] ``` ## Fehlende Belege sind Fehler Ein sichtbarer Claim ohne Citation bricht WikiKits Herkunftsversprechen. Das ist keine kosmetische Warnung. Der Claim muss mit einer echten Quelle belegt oder stillgelegt werden. Ein automatischer Fix wäre falsch. Der Linter besitzt keine Quelle, die er ergänzen dürfte. Er meldet die Lücke. Ein Mensch oder ein unterstützender Agent sucht danach einen vorhandenen Beleg oder reicht eine neue Quelle als Vorschlag ein. Die Diagnose zeigt, wo die Invariante verletzt ist; die Reparatur läuft über den Vorschlags- und Reviewweg. Für CI kann ein fehlender Beleg deshalb als harter Fehler behandelt werden, damit unbelegte Claims nicht unbemerkt in eine Veröffentlichung eingehen. ## Widersprüche bleiben sichtbar WikiKit prüft den sichtbaren Wissensbestand auf Widersprüche. Ein solcher Befund entscheidet noch nicht, welche Aussage gilt. Im Review muss geklärt werden, ob die Claims tatsächlich denselben Geltungsbereich und denselben Zeitraum betreffen oder nur ähnlich formuliert sind. Beispielbefund: ```json { "rule": "contradictions", "severity": "error", "concept_slug": "service-runtime", "message": "Two visible claims may contradict each other." } ``` Der Fehler bedeutet nicht, dass der jüngere Claim automatisch gewinnen soll. Das Review prüft Geltungsbereich, Zeitpunkt und Quellen. Vielleicht werden die Subjekte enger gefasst. Vielleicht löst eine neue Entscheidung die alte ab. Vielleicht bleibt der Konflikt offen. Ein Widerspruch muss geprüft werden und bleibt sichtbar, bis eine freigegebene Änderung ihn auflöst. Lint verhindert, dass dieser Zustand in einem großen Bestand vergessen wird. ## Beziehungen können beschädigt oder verwaist sein Beziehungen verbinden Konzepte im sichtbaren Wissensbestand. Kann eine solche Verbindung nicht mehr aufgelöst werden, ist die Beziehung beschädigt. Exporte, Imports oder Migrationen dürfen diesen Zustand nicht unbemerkt hinterlassen. WikiKit weist außerdem verwaiste Konzepte aus. Ein solcher Befund ist nicht automatisch ein Fehler. Ein neuer eigenständiger Begriff kann bewusst ohne weitere fachliche Einbindung stehen. In einem großen Bestand ist der Hinweis trotzdem nützlich: Vielleicht wurde das Konzept nie mit seinem fachlichen Zusammenhang verbunden. In einer entsprechend konfigurierten CI kann eine beschädigte Beziehung eine Veröffentlichung blockieren, weil Leser oder Werkzeuge sonst einem nicht auflösbaren Verweis folgen. Bei einem verwaisten Konzept ist dagegen menschliches Urteil nötig. Es kann verknüpft, zusammengeführt, stillgelegt oder bewusst als eigenständig bestätigt werden. ## Staleness ist eine Pflegefrage Ein Claim kann formal korrekt belegt und trotzdem veraltet sein. Preise, Zuständigkeiten und Anbieterlimits ändern sich schnell. Architekturprinzipien oder mathematische Definitionen können lange stabil bleiben. Lint weist veraltete Claims aus, ändert ihren Status aber nicht selbstständig. Alter ist ein Signal für erneute Prüfung, kein Gegenbeweis. Beispielbefund: ```json { "rule": "stale-claims", "severity": "warn", "concept_slug": "provider-limits", "message": "The claim should be reviewed again." } ``` Der nächste Schritt kann eine aktuelle offizielle Quelle sein. Bestätigt sie die Aussage, kann eine neue Revision mit aktuellem Beleg entstehen. Widerspricht sie, wird der Claim als Konflikt im Review geprüft. ## Offene Vorschläge sind ein anderer Zustand Eine große Zahl wartender Änderungsvorschläge ist kein Fehler im sichtbaren Wissen. Sie zeigt einen Arbeitsrückstand. Lint-Befunde und Review-Rückstand müssen deshalb getrennt betrachtet werden. Für den Gesamtblick gibt es den Health-Read: Er verbindet Lint, Review-Rückstand und Ingest-Warteschlange in einer LLM-freien Sicht. So lässt sich unterscheiden, ob in einem Space Lint-Befunde vorliegen, Arbeit im Review liegen bleibt oder neues Material noch auf Verarbeitung wartet. Diese Trennung schützt vor falschen Schlussfolgerungen. Kein offener Vorschlag kann bedeuten, dass ein Bestand gut gepflegt ist. Es kann ebenso bedeuten, dass er nicht mehr bearbeitet wird. Umgekehrt können offene Vorschläge auf eine laufende, sinnvolle Aktualisierung hinweisen. Ein Betriebsbericht sollte solche Zustände getrennt ausweisen, statt sie zu einer einzigen Qualitätszahl zu verdichten. ## Drei Zugänge, eine Diagnose Cockpit, REST und MCP sind Zugänge zur gleichen Diagnose. Das WikiKit-Cockpit stellt Lint und Health als menschliche Betriebsoberflächen über die Produkt-APIs bereit. Skripte können die Diagnose über REST abrufen, Agenten über MCP. Diese Anordnung trennt Darstellung und Qualitätsregeln. Das Cockpit visualisiert die Befunde, während CI oder Agenten sie für ihren jeweiligen Ablauf verwenden. Keine dieser Oberflächen soll eigene Regeln erfinden oder einen Befund selbstständig reparieren. ## Lint in CI und in geplanten Workflows Ein Repository kann vor einer Veröffentlichung einen Lint-Lauf ausführen. Ein geplanter Workflow kann die Diagnose regelmäßig abrufen und ihre Entwicklung in einer Betriebsübersicht zeigen. Beispiel ohne Festlegung auf einen konkreten Endpoint oder ein vollständiges Antwortschema: ```bash result=$(curl -s "$WK_LINT_URL" \ -H "Authorization: Bearer $WK_READ_KEY") errors=$(printf '%s' "$result" | jq '.counts.error') test "$errors" -eq 0 ``` Für CI ist ein harter Fehler bei fehlenden Citations oder beschädigten Beziehungen sinnvoll. Eine Veröffentlichung würde sonst unbelegte Claims oder nicht auflösbare Verweise sichtbar machen. Warnungen zu Alter oder fachlicher Einbindung können zunächst sichtbar bleiben, ohne jeden Build zu blockieren. Diese Entscheidung gehört in eine dokumentierte, projektspezifische CI-Policy. ## Eine Regel braucht einen klaren Fehlerpfad Eine Lint-Regel ist nur hilfreich, wenn ein Fund zu einer verständlichen Handlung führt. Ein Befund zu fehlenden Citations sollte den betroffenen Claim identifizieren. Bei einer beschädigten Beziehung müssen die beteiligten Konzepte auffindbar sein. Ein Hinweis auf einen veralteten Claim braucht genug Kontext für die erneute Prüfung. Beispiel für einen solchen Vertrag: ```ts type LintFinding = { rule: string; severity: "error" | "warn" | "info"; conceptSlug?: string; claimId?: string; message: string; }; ``` Eine Regel mit einer allgemeinen Meldung wie `bad-knowledge` wäre wertlos. Sie verrät weder die verletzte Invariante noch den nächsten Schritt. Eine gute Lint-Regel sollte eine einzelne Invariante prüfen und mit einem minimalen Wissenszustand testbar sein. Fehlalarme verdienen dieselbe Aufmerksamkeit wie übersehene Fehler. Ein absichtlich eigenständiges Konzept kann als verwaist erscheinen. Dann sollte nicht der ganze Linter deaktiviert werden. Zuerst ist zu prüfen, ob eine dokumentierte Ausnahme oder eine fachlich passende Beziehung den Fall klarer beschreibt. Häufen sich solche Ausnahmen, ist die Regel wahrscheinlich zu breit. Auch Änderungen an Schweregraden brauchen einen nachvollziehbaren Übergang. Wenn ein Befund heute nur gewarnt und morgen als Fehler behandelt wird, muss die CI-Policy darauf vorbereitet sein. Andernfalls scheitern Läufe nicht wegen eines geänderten Wissensbestands, sondern wegen eines unangekündigt geänderten Messverfahrens. ## Von einem Fund zum Änderungsvorschlag Lint schreibt den Wissensbestand nicht selbst um. Ein Workflow kann aus einem Fund eine Aufgabe oder einen vorbereiteten Vorschlag erzeugen, aber auch dieser braucht Quellen und Review. Der Lauf stellt die Verletzung einer Regel fest; das Review entscheidet über die Änderung. Bei einer beschädigten Beziehung kann der technische Fix eindeutig sein, wenn eine überprüfbare Historie die Umbenennung des Ziels belegt. Bei einem veralteten Claim ist die Lage offen: aktuelle Quelle suchen, Aussage bestätigen, bestreiten oder stilllegen. ```mermaid flowchart TD F["Lint-Fund"] --> T{"technische oder
fachliche Ursache?"} T -->|technisch| X["Fix mit Test und Referenz"] T -->|fachlich| S["aktuelle Quelle suchen"] X --> P["Änderungsvorschlag"] S --> P P --> R["menschliche Prüfung"] ``` Ein Agent darf dabei helfen, betroffene Stellen und mögliche Quellen zu finden. Er soll den Fund nicht durch einen erfundenen Beleg zum Verschwinden bringen. Der nächste Lint-Lauf bestätigt erst nach der Freigabe, ob die Invariante wieder erfüllt ist. Für wiederkehrende technische Funde lohnt ein Regressionstest. Hat ein Import einmal beschädigte Beziehungen erzeugt, gehört ein minimaler Zustand mit genau diesem Fehler in die Testsuite. ## Ein Verlauf erklärt mehr als eine Zahl Ein einzelner Lint-Lauf zeigt den aktuellen Stand. Eine Verdichtung über mehrere Läufe kann unterscheiden, ob der Bestand stabiler oder nur größer wird. Hypothetischer Verlauf mit frei gewählten Beispieldaten: ```text week 1: errors=4 warnings=12 concepts=180 week 2: errors=2 warnings=11 concepts=187 week 3: errors=0 warnings=9 concepts=191 ``` Diese Zahlen beweisen keine bessere inhaltliche Qualität. Sie zeigen lediglich, dass die als Fehler behandelten Invarianten wieder erfüllt sind und die Zahl der Warnungen trotz wachsendem Bestand sinkt. Ein belastbarer Report nennt deshalb auch die verwendete Regelversion. Ein sprunghafter Rückgang kann durch eine deaktivierte oder geänderte Regel entstehen. Deshalb gehört die Lint-Version oder der Produktrelease in das Reportmanifest. Veränderungen am Messverfahren müssen von Veränderungen am Wissensbestand unterscheidbar bleiben. Für diesen Anwendungsfall genügt eine stündliche oder tägliche Verdichtung. Fehlende Belege und fachliche Widersprüche verlangen sorgfältige Korrekturen, keinen Alarm außerhalb des vereinbarten Reviewprozesses. ## Lint-Regeln sollten getestet werden Ein sinnvoller Testaufbau beginnt mit minimalen Wissenszuständen für jede Regel. Ein Test erzeugt genau einen fehlenden Beleg, eine beschädigte Beziehung oder einen Widerspruch und prüft den erwarteten Befund. Weitere Tests prüfen das Zusammenspiel mit sichtbaren und noch nicht freigegebenen Änderungen. Beispiel für eine solche Erwartung: ```ts expect(findings).toContainEqual(expect.objectContaining({ rule: "missing-citations", severity: "error", conceptSlug: "refund-policy" })); ``` Ebenso wichtig ist der Negativtest: Ein noch nicht freigegebener Claim darf die Diagnose des sichtbaren Bestands nicht verändern. Bei einer Ablehnung bleiben die vorgeschlagenen Änderungen für den Audit erhalten, werden aber nicht als sichtbare Revisionen oder aktive Beziehungen freigegeben. Solche Tests begrenzen die Determinismusbehauptung auf einen definierten Zustand, eine bekannte Konfiguration und eine feste Regelversion. ## Abgrenzung zur Observability [Observability mit OpenTelemetry](https://www.mikebild.dev/de/blog/observability-mit-opentelemetry/) beschreibt Logs, Traces und Metriken als unterschiedliche Signale für laufende Software. Gemeinsam machen sie Betriebszustände untersuchbar. Beim Wissens-Lint ist der Gegenstand ein anderer: Fehlende Belege, offene Widersprüche und beschädigte Beziehungen müssen regelmäßig ausgewiesen werden. Hier geht es nicht um Latenz oder Fehlerrate, sondern um den prüfbaren Zustand von Claims, Quellen und fachlichen Verbindungen. Die Detailoberfläche ist eine fachliche Produkt-API, keine Prometheus-Metrik. [Wissen, das die Session überlebt](https://www.mikebild.dev/de/blog/wissen-das-die-session-ueberlebt/) warnt vor Wissensdateien, aus denen nie etwas entfernt wird. Lint macht dieses Pflegeproblem messbar, ohne einem Modell die Entscheidung über Löschen oder Gültigkeit zu überlassen. ## Mit wenigen Regeln beginnen Für einen ersten Lauf in einem Bestand reichen wenige Regeln: keine sichtbaren Claims ohne Beleg, keine beschädigten Beziehungen und keine übersehenen Widersprüche. Hinweise auf veraltete oder verwaiste Inhalte können hinzukommen, wenn für sie ein klarer Reviewweg existiert. Review-Rückstand und Ingest-Warteschlange bleiben davon getrennte Zustände im Health-Read. Dauerhaft ignorierte Befunde machen eine Regel wirkungslos. Jeder Fund braucht einen möglichen nächsten Schritt. Regeln, deren Meldungen keine Entscheidung auslösen, müssen präzisiert oder bewusst entfernt werden. So bleibt die Wissensbasis prüfbar. Alterung, Konflikte und Lücken werden sichtbar, bevor sie sich hinter immer mehr Seiten verstecken. Fachliche Änderungen bleiben bis zur menschlichen Prüfung Vorschläge. ## Weiterführende Quellen - [WikiKit README, Stand 3da2c47](https://github.com/MikeBild/wikikit/blob/3da2c47f482ff843f849f504257467282a7d9363/README.md) - [WikiKit Produktdokumentation, Stand 3da2c47](https://github.com/MikeBild/wikikit/blob/3da2c47f482ff843f849f504257467282a7d9363/docs/llms-full.txt) - [WikiKit Cockpit, Stand 3da2c47](https://github.com/MikeBild/wikikit/blob/3da2c47f482ff843f849f504257467282a7d9363/docs/COCKPIT.md) - [Observability mit OpenTelemetry](https://www.mikebild.dev/de/blog/observability-mit-opentelemetry/) - [Wissen, das die Session überlebt](https://www.mikebild.dev/de/blog/wissen-das-die-session-ueberlebt/)