Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki:
raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht
tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren
Grenzen in Code durchgesetzt sind statt im Prompt.
Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige
Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses
Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44
Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist.
Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den
Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er
dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs.
Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte.
Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet -
siehe NOTICE.
Sonnet-Analyse, die AGENTS.md und wikitool mit Farzas Gist und awesome-llm-wiki vergleicht und die Codex-Analyse um konkrete Empfehlungen zu Qualitätsschwellen, Stilrichtlinie, Auditrhythmus und Skalierung ergänzt
Diese Quelle dokumentiert eine Analyse des Sonnet LLM, die das aktuelle AGENTS.md-Schema und die wikitool-Implementierung des LLM-Wiki-Repositoriums gegen externe Referenzen vergleicht: Farza's Gist (https://gist.github.com/farzaa/c35ac0cfbeb957788650e36aabea836d) und das awesome-llm-wiki-Repository. Die Analyse dient als Ergänzung zur Codex-Analyse und bietet spezifischere und umsetzbarere Empfehlungen.
Die Sonnet-Analyse kommt zu dem Ergebnis, dass das aktuelle Repository bereits konzeptionell den meisten öffentlichen LLM-Wiki-Implementierungen voraus ist, insbesondere in Bezug auf Nachverfolgung der Herkunft/Zitierung, deterministische CLI-Durchsetzung über wikitool und Konfidenzscoring mit Verfall. Sie identifiziert jedoch sieben konkrete Verbesserungslücken mit realem Nutzen: Seitenlänge/Qualitätsschwellen, Stil-/Tonfibel, Anti-Cramming-Heuristik, Checkpoint-/Audit-Rhythmus, Index-Skalierungsschwellen, Massenpublizierungs-Bestätigungsgate und obligatorisches Sitzungs-Orientierungsprotokoll.
Die Analyse bewertet auch einen Community-Kommentar von „pascalandy" in Farza's Gist, der ein separates „Wiki Schema (Global)" mit einer eigenen Tag-Taxonomie enthält. Während einige Ideen aus diesem Schema nützlich sind, empfiehlt die Analyse, seine vollständige Taxonomie nicht zu übernehmen, da dies mit dem bestehenden entity_type/concept_type/tags-Modell in Konflikt geraten würde.
Kernaussagen
Aktuelle Stärken: Das Herkunfts- und Zitierungssystem (raw_files:, provenance:-Marker, Inline-Zitate, provenance.md-Umkehrindex) ist reifer als jede Referenzimplementierung. Die deterministische CLI (wikitool) führt alle mechanischen Operationen präzise aus. Konfidenzscoring mit Verfallformal existiert und funktioniert.
Qualitätsschwellenlücke: Keine Überprüfung auf Seitenlänge/Qualität - Farza definiert Stub-Minimum (≥3 Sätze / 15 Zeilen), Teilungsschwelle (>120-150 Zeilen) und Zeilenzählziele pro Typ. Pascalandy's Schema schlägt 200 Zeilen als Ziel vor.
Stilfibel-Lücke: Keine expliziten Ton-/Formulierungsregeln - Farza definiert „Wikipedia, kein AI-Ton" mit spezifischen Verboten (Gedankenstrichstriche, Füllwörter wie „bahnbrechend", Phrasen wie „es ist zu beachten", maximal 2 Zitate/Seite).
Anti-Cramming-Lücke: Keine Heuristik für den Zeitpunkt, wann eine neue Seite erstellt oder zu einer bestehenden hinzugefügt werden soll - Farza's Regel: „Wenn du den 3. Absatz zu einem Unterthema auf einer bestehenden Seite hinzufügst, verdient dieses Unterthema seine eigene Seite."
Audit-Rhythmus-Lücke: Keine reguläre Qualitäts-Audit-Kadenz - Farza: Index+Backlinks alle 15 Einträge neu erstellen, auf 0 neue Artikel prüfen (Cramming-Alarm), 3 meistgeänderte Artikel neu lesen.
Index-Skalierungs-Lücke: Keine Schwellen für die Aufteilung von index.md - Pascalandy: Tabellensektionen bei >50 Einträgen aufteilen, _meta/topic-map.md bei >200 Gesamtseiten erstellen.
Sicherheitslücke: Kein Bestätigungsgate für Massenpublizierungen - Farza: anhalten und bestätigen, wenn eine Operation ≥10 Seiten ändert.
Sitzungsprotokoll-Lücke: Keine explizite Vorflight-Prüfung - Farza: Schema + Index + letzte N Log-Einträge vor jeder Operation lesen, um Drift zu erkennen.
Zu vermeidende Anti-Patterns: Personenzentrierte Taxonomien, aggressive Always-Rewrite-Schleifen, vorzeitige Multi-Agent-Orchestrierung und die alternative Tag-Achsen-Taxonomie aus pascalandy's Schema (area/kind/topic/status/pty), da sie mit bestehenden Typen in Konflikt gerät.
Aufgaben
Content Quality & Style-Sektion zu AGENTS.md mit Seitenlängenschwellen und Stilfibel-Regeln hinzufügen
lint.py mit mechanischen Überprüfungen für Zeilenzähler-Ausreißer und Index-Sektionsgröße erweitern
Anti-Cramming-Heuristik als dokumentierte Regel im CREATE vs UPDATE-Workflow implementieren
Checkpoint-/Audit-Rhythmus zum Wartungsplan mit spezifischen Triggern und Aktionen hinzufügen
Index-Skalierungsschwellen definieren (Tabelle bei >50 Einträgen aufteilen, Topic-Map bei >200 Seiten)
Massenpublizierungs-Bestätigungsgate (≥10 Seiten) als Sicherheitsprüfung im Publish-Workflow hinzufügen
Sitzungs-Orientierung als obligatorischer erster Schritt für alle Workflows hinzufügen (AGENTS.md + index.md + aktuelle Log-Einträge lesen)
Entity-Seite mit pascalandy-Schema erstellen, um das ausgewertete externe Schema zu dokumentieren
torben
18ae28f918