mita/wow20
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
390d31c70e3ce81d91fdf19ac2e8efadf151d3ea
wow20/BUILD-VS-ADOPT-DECISION-REPORT-2026-08-24.md
T
mita 390d31c70e .
2026-08-25 10:42:53 +02:00

96 KiB
Raw Blame History

Wiki of Wikis (WoW20): Build-vs-Adopt-vs-Extend-vs-Fork Audit

Decision Report · Stand 24. August 2026 · Research only

Executive Recommendation

Empfehlung: ADOPT. Die heutige WiWoW-Compilerarchitektur sollte nicht weiterentwickelt werden. Der nächste Schritt ist ein strikt zeitbegrenzter, vergleichender Proof of Concept mit LangChain OpenWiki als bevorzugter Knowledge Engine. Bei Bestehen der Exit Criteria wird OpenWiki auf einem fixierten Upstream-Commit übernommen; WiWoW wird nicht als eigener Compiler fortgeführt.

Die empfohlene Zieloption ist Option F: OpenWiki unverändert bzw. upstream-nah einsetzen und ausschließlich nachgewiesene Lücken als getrennte, kleine Policy-/Validator-/Federation-Komponenten ergänzen. Vor dem PoC wird nichts davon gebaut. Ein Fork ist nicht der Ausgangspunkt, sondern nur ein letzter Ausweg, falls ein zwingendes Hard-Gate nicht über Konfiguration, externes CI oder einen akzeptierten Upstream-Hook erreichbar ist.

Diese Empfehlung ist nicht knapp: OpenWiki deckt auf dem untersuchten main-Stand bereits die für WiWoW teuersten Commodity-Bausteine ab — Git- und Markdown-Wiki, OKF 0.2, strukturierte Claims mit versionierter Repository-Evidenz, Change Detection, inkrementelle Updates, deterministische Finalizer, Providerabstraktion, CLI/CI und Agentenintegration. llm_wiki ist bei Ingestion, Chunking, Cache, Source-Watching, Retrieval, Vector Search und Graphanalyse sogar funktional breiter. Der noch plausible WiWoW-Rest ist keine eigene Knowledge Engine, sondern höchstens ein dünner, engine-neutraler Policy- und Federation-Layer.

Der unmittelbare Entscheidungsrahmen lautet daher:

  1. Aktuelle WiWoW-Roadmap einfrieren: keine Umsetzung von Epic 4 oder 5 in der jetzigen Architektur.
  2. OpenWiki-PoC durchführen: mit demselben WiWoW-Quellensatz, lokalem OpenAI-kompatiblem/vLLM-Endpunkt und den in diesem Report definierten Ausfallkriterien.
  3. Nur gemessene Lücken ergänzen: zuerst externes CI/Adapter; Upstream-Beitrag vor Fork; kein Retrieval-, Ingestion- oder Graph-Neubau.
  4. llm_wiki als zweite PoC-Referenz verwenden: besonders für Dokumentingestion und Retrieval, nicht als derzeit bevorzugte Basis für OKF/Claims/Git.

Stop / Go Decision

ADOPT — OpenWiki als Knowledge Engine; aktuelle WiWoW-Eigenentwicklung stoppen.

Das ADOPT ist an einen technischen Abnahme-PoC gebunden, nicht an eine weitere Architekturphase. Scheitert OpenWiki an einem zwingenden Kriterium, folgt nicht automatisch ein Rückfall auf WiWoW. Zuerst wird geprüft, ob llm_wiki oder eine kleine externe Ergänzung die Lücke schließt. Eigenentwicklung wird nur wieder geöffnet, wenn beide Standardlösungen an derselben zwingenden, messbaren Anforderung scheitern und die Lücke nicht mit einem kleinen, engine-neutralen Baustein geschlossen werden kann.

1. Audit Scope, Evidenz und Statusbegriffe

1.1 Untersuchte Stände

System Untersuchte Revision Bedeutung
WiWoW Workspace main, HEAD 0d79421 PRD, SPEC, Architecture Spine/ADRs, Epics/Stories, Epic-Kontexte, implementierte Verträge, Adapter, Wiki, Tests/Harnesses, Deferred Work und Retrospektiven Epic 1–3
OpenWiki main @ 6ffa7b6, 24.08.2026 Aktueller Default-Branch, nicht nur README. Wichtige Fähigkeiten sind neuer als Release v0.3.3.
llm_wiki main/Release v0.6.10 @ 889789c, 21.08.2026 Aktueller veröffentlichter Stand und Code, nicht Roadmap/Marketing
OKF kanonisches Repository GoogleCloudPlatform/open-knowledge-format Das frühere knowledge-catalog/okf ist eingefroren; maßgeblich ist weiterhin OKF 0.2 im neuen Repository.

OpenWiki enthält auf main bereits OKF 0.2, Claims und Coding-Agent-Integrationen, liegt damit aber 36 Commits und rund 34.700 hinzugefügte Zeilen vor dem Tag v0.3.3. Offene Changesets kennzeichnen diese Funktionen als noch nicht veröffentlicht: OKF 0.2, Grounded Claims und Agent-Integration. Der PoC muss deshalb genau den untersuchten Commit bauen oder auf einen entsprechenden Release warten. npm install -g openwiki@0.3.3 wäre kein Test aller hier bewerteten Fähigkeiten.

1.2 Evidenzhierarchie

Bewertet wurde in dieser Reihenfolge:

  1. ausgeführter Code und persistiertes Datenmodell;
  2. Tests und CI;
  3. tatsächlich vorhandene Konfiguration/CLI/API;
  4. Dokumentation, soweit sie zum Code passt;
  5. Issues, Pläne und Roadmaps nur als Zukunftshinweis, nie als Capability.

Die Statusbegriffe für Referenzprodukte bedeuten:

Status Bedeutung
IMPLEMENTED Auf dem untersuchten Default-Branch im ausführbaren Code vorhanden.
EXPERIMENTAL Code vorhanden, aber deutlich begrenzt, nicht produktionsbelegt oder ausdrücklich experimentell.
PLANNED Konkreter Plan/Roadmap, aber keine nutzbare Implementierung; zählt nicht als Coverage.
DOCUMENTED ONLY Nur in Text/Beispiel behauptet; zählt nicht als Coverage.
MISSING Weder nutzbare Implementierung noch belastbare Produktfähigkeit gefunden.

Für die Competitive Capability Matrix gelten andere, an Requirements gebundene Begriffe:

Wert Bedeutung
BETTER Erfüllt die tatsächliche Anforderung belastbar und geht in nützlicher Weise darüber hinaus.
EQUIVALENT Erfüllt die Anforderung ausreichend.
PARTIAL Ein relevanter Teil ist vorhanden, eine notwendige Eigenschaft fehlt oder ist unbewiesen.
MISSING Zwingender Teil fehlt.
NOT REQUIRED Die Fähigkeit ist für das WiWoW-Problem kein Muss und wird nicht als Vorteil gezählt.

1.3 Grenzen des Audits

  • Für WiWoW wurde der vollständige lokale Dokument-, Code- und Testbestand analysiert; vorhandene Retrospektiven wurden als Gegenbelege zu formalen done-Markierungen behandelt.
  • Für llm_wiki liefen 130 Testdateien mit 1.865 Tests sowie 22 MCP-Tests erfolgreich. Die Rust-Suite konnte lokal wegen eines Toolchain-/Lockfile-Konflikts nicht gestartet werden; die CI baut Rust, führt aber keine Unit-Test-Suite aus.
  • Für OpenWiki wurde die umfangreiche Test- und CI-Struktur codebasiert untersucht, aber in diesem Audit keine vollständige Live-LLM- oder lokale Gesamtsuite ausgeführt. Knowledge Quality und vLLM-Kompatibilität bleiben daher PoC-Gegenstände.
  • Stars, Forks und Aktivität sind zeitabhängige Risikosignale, keine Qualitätsbeweise.
  • Lizenzbewertung ist technisch-strategisch, keine Rechtsberatung.

2. Current WiWoW Assessment

2.1 Rekonstruiertes Problem Statement

WiWoW soll verhindern, dass wachsende, heterogene Rohquellen bei jeder Agentenanfrage erneut vollständig gesucht, gelesen und synthetisiert werden. Neue Sources sollen gegen bereits destilliertes Wissen verarbeitet werden, sodass ein langfristig nutzbares, source-grounded Wiki entsteht und Wissen „akkumuliert“, statt dass Kontextkosten linear mit dem Quellenbestand wachsen.

Das gewünschte Produkt ist ausdrücklich ein Knowledge Compiler, nicht primär ein Retrieval-System: Das kanonische Ergebnis ist ein lesbares, Git-versioniertes Markdown-/OKF-Bundle ohne obligatorischen Server, proprietäre Datenbank oder WiWoW-Runtime. Evidenz: PRD Z. 14–51 und SPEC Z. 14–16.

2.2 Product Goals

Die tatsächlich ableitbaren Produktziele sind:

  • lokale Sources aufnehmen, von kuratiertem Wissen trennen und nachvollziehbar referenzieren;
  • vorhandene Concepts aktualisieren oder neue Concepts erstellen, statt jede Source isoliert zusammenzufassen;
  • mehrere Sources synthetisieren sowie Korrekturen und Widersprüche sichtbar behandeln;
  • ein portables OKF-0.2-/Markdown-Bundle mit normalen Links und progressiven Indizes erzeugen;
  • Änderungen inkrementell verarbeiten, No-op erkennen und unnötige LLM-Arbeit vermeiden;
  • menschliche Kuratierung bewahren;
  • Änderungen über Git nachvollziehbar halten, fachliche Provenienz aber nicht mit Git-History verwechseln;
  • das Wissen ohne Producer-Runtime über Dateioperationen, CLI und Agenten langfristig konsumierbar machen;
  • Cloud-Abhängigkeit vermeiden und lokale/OpenAI-kompatible Modelle ermöglichen.

Die PRD-Erfolgssignale — Compounding, Transformation statt Kopie, Provenienz, Consumer-Unabhängigkeit und „zero mandatory infrastructure“ — besitzen bislang keine quantitativen Qualitätsschwellen. Der adversariale PRD-Review beanstandete bereits, dass „Synthese statt Kopie“ nicht operationalisiert oder messbar ist: PRD Review Z. 13–17.

2.3 Architectural Goals und ADRs

Die ADRs sind als AD-1 bis AD-17 in den Architecture Spine eingebettet; separate ADR-Dateien existieren nicht.

Ziel Architekturentscheidung Muss oder Mittel?
Portables Wissen OKF-0.2-Markdown ist kanonisch; Graphen/Embeddings nur abgeleitet Muss
Source-Integrität raw/ und wiki/ getrennt; Rohquellen nicht still überschreiben Muss, konkrete Unveränderlichkeitsregel ist verhandelbar
Provenienz claim-granulare Source-Grounding; Wiki-Seite nicht alleinige Evidenz Muss
Incrementality neuen Source-Bestand gegen vorhandenes Wissen verarbeiten Muss
Kontrollierter Write Reason/Plan/Mutate/Validate logisch trennen Ziel ist sinnvoll; konkrete Prompt-Abbildung ist ein Mittel
Identität/Navigation Pfad als Concept-ID, normale Markdown-Links, Indizes Muss für Portabilität; Pfad-ID ist austauschbar
Producer-Unabhängigkeit Agentenunabhängiger Vertrag, keine eigene LLM-Runtime Muss auf Bundleebene; nicht zwingend im Authoring-Stack
Acquisition/Retrieval Acquisition außerhalb, Retrieval consumerseitig sinnvolle Grenze, aber kein Verbot interner Suche
Trust/Lifecycle Human/Machine-Ereignisse, Status, Staleness Muss, sofern langfristige Pflege zentral bleibt
Konflikte NEW/CONFIRMING/CORRECTING/CONTRADICTING/REDUNDANT gewünschte Semantik, noch nicht implementiert
Concurrency Root-Lease, Dirty-Tree-Regeln, Byte-Determinismus Implementierungsentscheidung, kein Produktmuss

Entscheidungsrelevant ist Architecture D-3 selbst: Ein Standalone- oder anderer Compiler soll erneut erwogen werden, wenn der Promptansatz nicht deterministisch, testbar oder portabel genug wird. Nach Epic 3 ist genau diese Revisionsbedingung erfüllt.

2.4 Implementierungsrealität nach Epic 3

WiWoW ist heute keine ausführbare Knowledge Engine:

  • schema/compiler.md Z. 9–13 beschreibt ausdrücklich eine textuelle Agenteninstruktion, keinen Compiler-Code. Die Datei umfasst etwa 31.000 Wörter bzw. 293 KB.
  • schema/validator.md ist ebenfalls eine textuelle Prüfinstruktion, kein deterministischer Validator.
  • schema/wiki-compiler.md ist ein Markdown-Vertrag.
  • adapters/claude/README.md Z. 1–5 ist ein Platzhalter. Codex-, OpenAI-compatible- oder vLLM-Adapter existieren nicht.
  • Die produktnahen ausführbaren Artefakte sind 13 Shell-Harnesses mit zusammen rund 9.853 Zeilen bzw. 1,05 MB; sie testen überwiegend Prompt-/Git-/Byte-Verträge.
  • Der eigentliche Nicht-Log-Wikibestand umfasst nur vier demonstrative Concepts, rund 1.744 Wörter bzw. 17 KB. wiki/log.md umfasst dagegen rund 17.294 Wörter bzw. 179 KB und besteht weitgehend aus Build-, Review- und Storyhistorie.

Der letzte Punkt widerspricht dem eigenen Compilervertrag: Build-, Review-, Story- und Sandboxhistorie soll außerhalb des Knowledge Bundles liegen (schema/compiler.md, Z. 426–439), dominiert aber aktuell wiki/log.md. Prozessmetadaten sind mehr als zehnmal größer als das fachliche Wissen.

2.5 Ergebnisse Epic 1–3

Epic Tatsächliches Ergebnis Bewertung
Epic 1 Workspace, OKF-Profil, Compiler-/Validatorinstruktionen accepted-with-open-items; Formatvertrag, aber keine Engine
Epic 2 Vier Concepts, Links/Index und Provenienzkonvention accepted-with-open-items; vier Selbsttestlücken bleiben nach Epic 3 offen
Epic 3 Git-Leasing, Receipts, No-op-/Update-Verträge und Sandbox-Gates formal done, aber unabhängiger echter LLM-Re-Run rot; CREATE/Synthese aus echtem A/B-Gate entfernt

Der externe RADIUM-/PDF-Dry-Run berichtet 28 Seiten Source, 11 Root-Concepts und 18 strukturell erfolgreiche Bundledateien (Dry-Run-Bericht, Z. 21–38). Source und Ausgabe liegen jedoch außerhalb dieses Repositories und waren nicht unabhängig prüfbar. Gemessen wurden Form, Dateizahl und Source-Hash, nicht fachliche Richtigkeit, Synthesequalität, Retrieval, Tokenverbrauch oder Langzeitwartung.

2.6 Warum der Stand nach Epic 3 nicht zufriedenstellend ist

Implementierungsfehler

  • Im unabhängigen Live-Re-Run meldete Agent A RUN_DONE, führte aber keine Mutation aus; Agent B aktualisierte korrekt. Die Ursache ist unbekannt, weil Transkripte gelöscht wurden: Epic-3-Retro Z. 105–109 und 132–143.
  • Der Helper commit_worktree behandelt einen leeren Stage zunächst als „kein Commit erforderlich“ (sandbox-3-13/run-sandbox.sh, Z. 614–624); das Gesamtgate verwirft den No-op anschließend in E.5 fail-closed (Z. 680–691). Das Gate hat die Agentenunzuverlässigkeit damit korrekt sichtbar gemacht, nicht verdeckt.
  • Die Tagesüberschrift in log.md ist nicht gepinnt und widerspricht Byte-Determinismus über Tagesgrenzen.
  • Drei Lease-/Stalenessmodelle und mehrere Normalisierungsregeln koexistieren.
  • Story 3.13 verlangt macOS-/Linux-Portabilität, das Gate setzt tatsächlich cygpath, GNU timeout, sha256sum und die Claude CLI voraus.

Architekturprobleme

  • Nichtdeterministische Synthese, Planung, Transaktionen, Routing und Validierung sind in einen 293-KB-Prompt verlagert.
  • Freie, „eigenständig formulierte“ LLM-Prosa soll zugleich byteidentisch sein. Das ist kein realistischer Determinismusvertrag.
  • CREATE/Synthese erzeugte 24 von 26 nicht nur zeitstempelbedingte Divergenzen. Der grüne Gatepfad ersetzte diesen Kernfall daraufhin durch ein agentenloses, festes Shell-Surrogat (Epic-3-Retro, Z. 93–97; Harness Z. 476–487).
  • Root-Scope-Leasing serialisiert das gesamte Wiki, schützt aber keine unabhängigen Clones ohne zusätzliches externes Protokoll.
  • Source-Immutability ist zu einer fehlenden Replacement-/Revocation-Semantik geworden: geänderte oder gelöschte Sources werden eher abgewehrt als fachlich verarbeitet.
  • Retrieval wird dogmatisch aus dem Compiler ausgeschlossen, obwohl der Compiler relevantes Bestandswissen finden muss.

LLM-/Prompt-Probleme

  • „Bedeutungstragende Terme“ sollen durch das Modell gewählt werden und zugleich „kein freies Urteil“ sein — keine operationalisierbare Regel.
  • Reale Gate-Läufe dauerten circa 30 bis über 35 Minuten je Agent; vollständige Gatezeiten lagen bei etwa 2,5–3,5 Stunden. Der Harness erlaubt 2.700 Sekunden und mindestens 32k Output-Tokens je Lauf.
  • Die kanonische Termregistry ist trotz bestehender Concepts leer.
  • Kein Eval misst Factuality, Coverage, Entailment, nützliche Synthese oder Antwortqualität; Bytegleichheit fungiert als falscher Qualitätsproxy.

Fehlende Features

  • Contradiction Handling, Human Curation und operationales Trust/Lifecycle: erst Epic 4.
  • echte Provideradapter, Consumer-Nachweis und Agentenunabhängigkeit: erst Epic 5.
  • Source-Revocation/-Replacement und automatische Stale-Verarbeitung.
  • produktfähige CLI/API/MCP-Schnittstelle.
  • OpenAI-compatible-/vLLM-/On-Prem-Ausführung.
  • Chunking-, Context-Window- und Skalierungsstrategie.
  • semantische Qualitäts- und Wartungsevaluation.
  • Federation mehrerer Wikis.

Unnötige Komplexität

  • 293 KB Compilerprompt, 1,05 MB Shell-Harnesses und 179 KB Prozesslog stehen 17 KB Fachwissen gegenüber.
  • Epic 3 brauchte 44 Commits, mindestens sechs Gate-Reruns und zwei Review-Loops.
  • Dreizehn Stories investierten in Leases, Receipts, Zeitstempel, Normalisierung und Bytegleichheit, bevor Knowledge Quality nachgewiesen war.

Falsche Abstraktionen

  • Ein „Claim“ ist Prosa mit Inline-Pfadkonvention, kein strukturiertes Claimobjekt.
  • „Trust“ ist überwiegend ein Actor-Präfix, keine Evidenz-, Unsicherheits- oder Reviewpolicy.
  • „Lifecycle“ ist optionales Frontmatter ohne ausführbare Stale-/Deprecation-Logik.
  • „Validator“ und „Compiler“ sind Promptrollen, keine deterministischen Programme.
  • Das Fachlog und die Buildhistorie teilen sich dasselbe wiki/log.md.

Problem des Produktkonzepts

Der Kern — persistentes, source-grounded, inkrementell gepflegtes Markdown-Wissen — bleibt sinnvoll. Nicht belegt ist die These, dass dafür ein eigener Compiler erforderlich ist oder bessere Wissensqualität erzeugt. Der aktuelle Korpus ist selbstreferenziell: Sources sind eigenes PRD, Epics und Architecture; die vier Concepts paraphrasieren diese Planungsartefakte. Es gibt keinen Nachweis für langjährige Pflege, reale Multi-Domain-Synthese oder bessere Agentenantworten.

2.7 Nachweisbare WiWoW-Differentiatoren

Kandidat Tatsächlicher Status Strategische Tragfähigkeit
Portables Git-/Markdown-/OKF-Bundle im Ausgabeformat nachweisbar wichtig, aber inzwischen Standard-/OpenWiki-Capability
Striktes OKF-0.2-Profil als detaillierter Vertrag vorhanden nützlich als separater Validator; kein Grund für eigene Engine
Claim-granulare Provenienz konzeptionell detailliert, in Pages demonstriert ohne ausführbaren Entailment-/Fragmentcheck nur PARTIAL
Byte-Determinismus Shell-Surrogate mechanisch belegt kein fachlicher Mehrwert; kollidiert mit Synthese
Agentenunabhängigkeit Bundle ist unabhängig Producer/Gate ist aktuell Claude-spezifisch
Contradictions/Human Trust/Lifecycle geplant kein aktueller Differentiator
Federation / „Wiki of Wikis“ weder Requirement noch Code/Test kein Differentiator

Ein allgemeines project-context.md existiert nicht; vorhanden sind nur Epic-1/2/3-Kontexte. Auch Sprintstatus, Retrospektive und done-Markierungen sind teilweise widersprüchlich. Dieser Befund ist relevant, weil das System langfristige Nachvollziehbarkeit verspricht, sie aber schon im eigenen Entwicklungsbestand nicht konsistent erreicht.

3. Referenzprodukt: LangChain OpenWiki

3.1 Architektur und Kurzurteil

OpenWiki ist auf dem untersuchten main eine Node-22-/TypeScript-CLI/TUI/CI-Anwendung. Der native Pfad ist:

CLI / TUI / CI
  → runOpenWikiAgent
  → Provider- und Modellauflösung
  → DeepAgent + geschütztes Repository-Dateisystem
       → Claims-Tools
       → optionale Source-Connectoren
       → Read-only Review-Subagents
  → Markdown + Claims-Sidecars
  → deterministische Finalizer
       → OKF-Frontmatter / generated / verified
       → Links / Indizes / Mermaid / Sources
  → Git-Diff bzw. automatisierter Pull Request

Der vollständige Run-Boundary einschließlich No-op, Claim-Preflight, transaktionalem Init und Rollback ist implementiert in runOpenWikiAgent; der Agentgraph in src/agent/index.ts. Schreibzugriffe bleiben unter openwiki/, Claims-Sidecars sind vor generischen Agenttools verborgen und .openwikiignore begrenzt Lesezugriffe (Backend-Grenzen).

Kurzurteil: OpenWiki ist keine bloße README-Idee mehr, sondern eine reale, sehr junge Knowledge Engine für Git-Repositories. Für code- und repositorybasierte Sources überschneidet sie sich stark mit WiWoW. Ihre Hauptlücken sind externe claim-granulare Provenienz, harte vollständige OKF-Bundlevalidierung, operationales Human-Trust/Lifecycle, Retrieval-Index und Federation.

3.2 Codebasierte Capability-Prüfung

Capability Status Tatsächlich implementierter Umfang und Grenze
Knowledge Representation IMPLEMENTED Markdown, YAML-Frontmatter, normale Markdown-Links, Verzeichnishierarchie; im Repositorymodus zusätzlich JSON-Claims-Sidecars.
OKF IMPLEMENTED, auf main noch unreleased Tatsächlich OKF 0.2; Root-Index schreibt deterministisch okf_version: "0.2" (Index Sync).
Vollständige OKF-0.2-Validierung MISSING Basisfrontmatter und optionale Felder werden geprüft/repariert, aber kein harter vollständiger Bundle-Validator für alle OKF-Familien, Actor-Konventionen, Credibility Signals, Attested Computation, Log und Referenzintegrität.
Concepts IMPLEMENTED Jede nicht reservierte Markdown-Datei ist ein Concept; type ist frei, nicht zentral ontologisiert (Promptvertrag).
Claims IMPLEMENTED, repository-only, auf main noch unreleased Stabile page-owned ID, atomare Aussage, mindestens eine Evidence; add, confirm, update, retract; striktes Sidecar und atomische Persistenz (Typen, Mutationen). Keine deterministische Entailment-Prüfung, typisierte Prädikate, Claim-Relationen oder globale IDs.
Repository-Provenance IMPLEMENTED repo://path#Lx-Ly, SHA-256-Version, sichere Pfadauflösung und Relokation von Evidenzbereichen (Resolver, Relokation).
Externe Provenance MISSING als Claims-Modell Connector-Fakten werden nicht in dasselbe Claim-/Evidence-Modell aufgenommen. Personal-Wiki-Provenienz bleibt überwiegend prompt-/seitenbasiert.
Page-Provenance IMPLEMENTED Body-Hash-gesteuertes generated: {by, at}; unveränderte Bodies behalten das alte Ereignis (Generated Provenance).
Trust / verified IMPLEMENTED, eng Machine-Event nach erfolgreicher Claim-Reconciliation und finalem Evidenzcheck; Human-/Process-Events werden erhalten (Eligibility). Das beweist Evidenzauflösung, nicht semantische Wahrheit, Vollständigkeit oder Human Review.
Trust Score / Source Credibility MISSING Keine Authority-, Corroboration-, Confidence- oder Trust-Propagation-Policy.
Lifecycle Metadata IMPLEMENTED Formprüfung für draft, stable, deprecated, stale_after (Frontmatter Validator).
Lifecycle Engine MISSING stale_after wird nicht als Zeitregel ausgeführt; keine automatische Review Queue, Transition oder Deprecation Policy.
Ingestion Pipeline IMPLEMENTED Repositorymodus: agentische Analyse des Repos. Personal Mode: deterministischer Connector-Pull, Raw JSON, danach Agent-Update je Source (Pipeline, Source Run).
Source Handling IMPLEMENTED Custom MCP, Git Repo, Gmail, Hacker News, LangSmith, Notion, Slack, Web Search und X sind registriert (Registry). Kein allgemeiner PDF-/Dokumentparser oder eigener Chunking-Layer.
Incremental Update IMPLEMENTED .last-update.json, Git HEAD/Worktree, git diff --name-only; echter No-op ohne Modell (Change Detection). Git-Diff-zu-Page-Plan bleibt agentisch.
Claim Change Detection IMPLEMENTED Preflight löst Evidence neu auf und klassifiziert stale/unresolved (Preflight); Debt wird absichtlich lazy beim Lesen einer Seite eingeblendet.
Connector Cache IMPLEMENTED, begrenzt Raw JSON und State/Run-Summaries; kein content-addressed Chunk-/Embedding-/Semantic Cache.
Validation PARTIAL Frontmatter-Middleware, Link-Validator und Finalizer vorhanden. Fehlerhafte Writes können Warnungen statt Hard-Fail erzeugen; Linkfehler werden markiert und ungültiges Mermaid zu Text degradiert.
Contradiction Handling MISSING als Fachmodell Claims können geändert/retrahiert werden, aber kein CONTESTED-/Contradiction-Modell oder unabhängige Gegenclaim-Beziehung.
Human Curation PARTIAL Fremde Verifikationsereignisse bleiben erhalten; Review-Subagents existieren. Kein expliziter Merge-/Protection-Vertrag für manuell korrigierte Prosa.
Retrieval IMPLEMENTED, agentisch/lexikalisch Wiki-first über Index, ls, glob, grep, read_file; kein eigenständiger Query-/Retrieval-Service.
Vector Search MISSING auf main Kein Embedding-/Vector-Modul im Default-Branch; konditionale Eval-Doku oder fremde Branches zählen nicht.
Knowledge Graph IMPLEMENTED als Linkgraph Nodes sind Markdown-Seiten, Edges aufgelöste Links (Graphmodell); kein typisierter semantischer KG.
Community Detection MISSING Keine Cluster-/Communityanalyse.
Knowledge-Gap Detection EXPERIMENTAL Init-only LLM Question Finder plus Wiki-only Answer Verifier (QA-Subagents); keine kontinuierliche Gap Engine.
Agent Integration IMPLEMENTED, auf main teils unreleased Interner DeepAgent sowie externe Codex-/Claude-Code-Integration. Review-Subagents dürfen nur lesen/suchen.
MCP IMPLEMENTED, Lifecycle-Schnittstelle begin, inspect_claims, resolve_claims, finish (Protokoll); keine Query-/Search-Tools.
HTTP/REST API MISSING Kein Server-API; lokales MCP nutzt stdio.
Model Provider IMPLEMENTED 13 Provider, einschließlich generischem OpenAI-Compatible (Providerliste).
OpenAI-compatible IMPLEMENTED beliebige HTTP(S)-Base-URL; Chat Completions standardmäßig, Responses und Streaming optional (Konfiguration, Modelbau).
On-Prem / lokale LLMs IMPLEMENTED über generischen Endpoint Ollama/LM Studio dokumentiert; keine notwendige Cloud. Tool-Calling-Qualität des lokalen Modells bleibt Betriebsanforderung.
vLLM EXPERIMENTAL durch Protokollkompatibilität Kein vllm-Code, Test oder Beispiel. OpenAI-kompatibler Betrieb ist plausibel, aber nicht E2E nachgewiesen; im PoC zwingend zu testen.
Git Integration IMPLEMENTED Wiki, Sidecars und Metadaten im Repo; Git-History/-Diff steuert Updates; GitHub-, GitLab- und Bitbucket-Automation. Beispiel: GitHub Workflow.
Scaling EXPERIMENTAL / begrenzt Bis zu neun Authoring-Subagents plus Critic/QA und History-Offload; kein Retrievalindex, keine verteilte Verarbeitung.
Erweiterbarkeit PARTIAL Generischer MCP-Sourceadapter und OpenAI-Compatible sind gute Erweiterungspunkte. Neue Connector-ID, Claimresolver oder Finalizer-Hook erfordert Code; keine deklarierte stabile Library-exports-API.
Federation MISSING Keine Wiki-Registry, Cross-Wiki-Suche, Entity Resolution, Trust Aggregation oder Ontologie. Mehrere getrennte Repos/Instanzen sind möglich.
Ontologie MISSING freie type-Werte, untypisierte Links, page-lokale/randomisierte Claim-IDs.

3.3 Tests, Aktivität, Community, Lizenz und Abhängigkeiten

  • Tests: 216 benannte Testdateien repo-weit, davon 180 unter test/; grob 46,9k Testzeilen gegenüber 49,6k Sourcezeilen. CI führt Format, Lint, Typecheck, Build, CLI-Smoke, vollständige Tests auf Node 22/24, Windows-Portabilität und Trivy aus. Eine Coverage-Schwelle wurde nicht gefunden. LEDGER-/DeepSWE-Eval-Harnesses sind implementiert, aber ohne eingecheckte Live-Ergebnisberichte nur EXPERIMENTAL.
  • Aktivität: Zum Auditzeitpunkt 308 Commits, davon 119 in 30 Tagen und 30 in sieben Tagen; 17 Tags. Öffentliche Kennzahlen lagen bei ungefähr 15,6k Stars und 1,1k Forks. Das ist hohe Aktivität, aber das Projekt ist erst seit Juni 2026 öffentlich und daher mit hohem Änderungs-/Schema-Risiko verbunden.
  • Lizenz: MIT (LICENSE).
  • Technologie: Node 22, TypeScript/ESM, LangChain, DeepAgents 1.12, LangGraph SQLite Checkpointing, MCP, Ink/React, Zod/YAML und mehrere Provider-SDKs. Speicher-/Format-Lock-in ist niedrig; Runtime-/Framework-Lock-in an LangChain/DeepAgents ist mittel bis hoch.
  • Risikobild: große sichtbare Community und starke Dynamik, aber unreleaste Kernfunktionen und ein sehr junges Projekt. Deshalb Revision pinnen, Upgrade-Tests schreiben und keine internen Imports als stabile API voraussetzen.

4. Referenzprodukt: nashsu/llm_wiki

4.1 Architektur und Kurzurteil

llm_wiki ist eine lokale Desktop-Knowledge-Engine:

Tauri-v2-Desktop-App + React 19 / Vite / Milkdown
  → Source Import / Parser / Watcher / persistente Queue
  → Analyse-LLM → Generations-LLM → optional Review/Repair/Merge
  → Markdown-Wiki + YAML-Frontmatter + Wikilinks
  → lokale Embeddings in LanceDB
  → Link-/Source-overlap-Graph + Louvain
  → Hybrid Search / Agent Chat / lokale HTTP API
  → Node-MCP-Bridge

Kurzurteil: llm_wiki implementiert einen großen Teil allgemein verfügbarer Knowledge-Engine-Infrastruktur: Multi-Format-Ingestion, Two-Step-Pipeline, Chunking, Hash-Cache, Source-Watcher, Page-Merge/Delete, Retrieval, Vectorindex, Linkgraph, Review UI, API/MCP und lokale Provider. Es besitzt aber weder OKF noch First-class Claims oder ein claim-granulares Provenance-/Evidence-System; vorhanden sind nur Page-Level-sources[] und eine optionale interne File-History. Echte Git-Integration und Federation fehlen ebenfalls. Für die aktuellen WiWoW-Must-haves ist es deshalb die zweite, nicht die erste Basisoption.

4.2 Codebasierte Capability-Prüfung

Capability Status Tatsächlich implementierter Umfang und Grenze
Knowledge Representation IMPLEMENTED lokale Schichten raw/sources → Markdown-Wiki → schema.md; YAML-Frontmatter und Obsidian-[[wikilinks]] (Struktur, Dateiformat). Das generische Frontmattermodell kennt nur string | string[].
OKF MISSING Kein Code-/Doku-Treffer für OKF; unterstützte OKF-Version: keine. schema.md steuert nur Type→Directory-Routing (Schema Parser).
Concepts IMPLEMENTED Page Types source, entity, concept, comparison, query, synthesis, thesis, methodology, finding (Typen).
Claims MISSING als First-class-Modell „Claims“ sind Prompt-/Markdownprosa; weder Claimtyp noch Evidence-Objekt. finding ist kein durchsetzbares Claimmodell.
Provenance PARTIAL sources[] auf Page-Level wird bei Merges vereinigt und geschützt (Source Merge, Persistenz). Keine Claim-Spans, Locator/Hash-Bindung, Entailment- oder Transformationskette.
Trust MISSING als generisches Modell confidence, status, replicated existieren nur in einzelnen Templateprompts, nicht als erzwungener Vertrag (Research Template).
Lifecycle PARTIAL starkes Source-/File-Lifecycle und Review-HITL; kein strukturierter Claim-/OKF-Lifecycle. Optionale File-History ist standardmäßig aus und kein Git.
Ingestion / Two-Step IMPLEMENTED separate Analyse- und Generationscalls (Ingest); optionaler dritter Reviewcall (Review) plus mögliche Repair-/Mergecalls. „Two-Step“ bedeutet zwei Hauptphasen, nicht garantiert zwei LLM-Aufrufe.
Source Handling IMPLEMENTED lokale Sources bleiben unter raw/sources; Parser, Watcher, persistente Queue, Move-/Delete-Behandlung und optionale Dokumentparser sind ausführbar. Sourcebindung bleibt allerdings überwiegend page-granular.
Chunking IMPLEMENTED deterministisch, Markdown-aware, Heading-Kontext, Overlap, Fence-/Tabellenschutz (Chunker); Checkpoints und Konsolidierung für lange Sources.
Cache IMPLEMENTED SHA-256-Skip plus Prüfung, ob erwartete Outputs weiter existieren (Ingest Cache, Cache Logic).
Incremental Processing IMPLEMENTED, source-/page-granular geänderte Source wird vollständig neu analysiert; bestehende Page vereinigt Sources/Tags/Related deterministisch und Body agentisch, mit Locked Fields und 70%-Shrink-Guard (Page Merge). Kein Claim-Diff.
Change Detection IMPLEMENTED persistenter Watcher mit Snapshot/Hash/Queue/Retry; unveränderte Moves über Hash, Create/Modify ingestieren, Delete kaskadiert (File Sync).
Validation PARTIAL Frontmatter parse/repair, Type-/Pfadrouting, Struktur-Lint, LLM-Semantiklint für Widerspruch/Stale/Missing und Ingest-Sicherheitschecks. Kein strikter OKF-/Claim-/Bundlevalidator. Ein historischer Codekommentar berichtet für Entity Pages vor Einführung der Reparatur von ungefähr 45 % unparsebarem modellgeneriertem Frontmatter; dieser Wert wurde im Audit nicht reproduziert.
Human Review IMPLEMENTED, produktintern persistente Review-Items mit stabilen IDs und Typen contradiction, duplicate, missing-page, confirm, suggestion (Review Store). Keine portable OKF-Human-Verification-Semantik.
Source-grounded Retrieval IMPLEMENTED in UI/API, PARTIAL über MCP Faithful erzwingt Raw-Source-Suche, entfernt generierten Wiki-/Graph-/Web-Kontext und verlangt Sourcepfade pro Fakt (Modes, Runtime). MCP Chat exponiert den Modus nicht direkt.
Hybrid Retrieval IMPLEMENTED Keyword + LanceDB-Vector via RRF und 15–30 % Graph-Expansion; Scanlimit 10.000 Wiki-Markdowndateien (Search).
Vector Search IMPLEMENTED lokales chunk-level LanceDB v2; replace-by-page; frei konfigurierbarer OpenAI-kompatibler Embedding-Endpunkt (Vector Store).
Knowledge Graph IMPLEMENTED, heuristisch aus Markdown-Wikilinks und Source-Overlap; Relevanz aus direct link, Source-Overlap, Adamic-Adar und Type Affinity (Graph Relevance). Kein RDF-/Ontologie-/Claimgraph.
Community Detection IMPLEMENTED reale Graphology-Louvain-Ausführung (Analyse).
Knowledge-Gap Detection IMPLEMENTED, heuristisch degree ≤ 1, Community Cohesion < 0,15 und Bridges über ≥ 3 Communities (Insights). Das erkennt Graphlücken, keine semantisch fehlenden Claims.
Agent Integration IMPLEMENTED integrierter Chat/Agent, lokale API und MCP; zusätzlich lokale Claude-/Codex-CLI-Provider.
HTTP API IMPLEMENTED, desktopgebunden tokenisierte, projektbezogene Endpunkte für Files, Reviews, Search, Graph, Rescan, Embed und Chat (API Routes).
MCP IMPLEMENTED, desktopgebunden Status, Projects, Set Project, Files, Read, Reviews, Search, Chat, Graph, Rescan, Embed (MCP Tools). Desktop-App muss laufen; kein headless Daemon.
Model Provider IMPLEMENTED OpenAI, Anthropic, Google, Azure, Ollama, Custom, MiniMax und lokale CLI-Provider (Store).
OpenAI-compatible / On-Prem IMPLEMENTED private HTTP-Endpunkte, Custom Headers, /chat/completions, Ollama und frei konfigurierbare Embeddings.
vLLM IMPLEMENTED BY PROTOCOL, E2E unbewiesen vLLM wird im Custom-Providercode explizit als kompatibler lokaler Server behandelt (Provider); dieser Audit führte keinen echten vLLM-Lauf aus.
Git Integration DOCUMENTED ONLY / praktisch MISSING „wiki is just a git repo“ steht nur in einer ausdrücklich abstrakten Ideendatei (Idee). Kein Init/Commit/Branch/Pull/Push/Merge/Conflict-Code; Markdown ist lediglich extern Git-fähig.
Scaling PARTIAL, lokale Einzelinstanz LanceDB und Parallelität lokal; 10k-Datei-Suchlimit, gewichteter Graph/Community-Schwelle bei 3.000 Nodes (Graph Limit); kein Cluster/Multi-Tenant/Distributed Ingest.
Erweiterbarkeit PARTIAL konfigurierbare Schemas, Templates, Provider und API; großer Tauri-/Rust-/React-Stack und GPL erschweren eine schlanke eingebettete Library.
Federation MISSING mehrere isolierte Projekte sind möglich, aber API ist project-scoped; MCP bindet eine Session an genau ein Projekt und blockiert Cross-Project Override (Binding).

4.3 Tests, Aktivität, Community, Lizenz und Abhängigkeiten

  • Lokal ausgeführt: npm run test:mocks — 130 Testdateien, 1.865 Tests bestanden; MCP — 22/22 bestanden. Typecheck bestand. Im Rust-Code liegen rund 400 Testattribute in 31 Dateien. cargo test --locked --no-run scheiterte unter Rust 1.89 vor dem Teststart, weil eingecheckte Lance-/LanceDB-Abhängigkeiten Rust 1.91 und roaring Rust 1.90 verlangen. Der im Manifest deklarierte Floor 1.88 passt damit nicht zum Lockfile; die README-Angabe 1.70+ ist zusätzlich veraltet.
  • CI: baut Frontend, MCP und Rust auf macOS/Linux/Windows, führt aber keine Unit-Tests, keinen tsc und keine Coverage-Schwelle aus (CI). Testbestand ist stark, Merge-Gate schwächer.
  • Aktivität/Community: öffentlich rund 848 Commits, 16,7k Stars, 2,0k Forks, 155 Issues und 72 Pull Requests; Releases v0.6.9 am 14.08. und v0.6.10 am 21.08.2026 (Releases). Der lokale Clone war shallow; Contributorverteilung/Bus-Faktor wurde daher nicht belastbar bestimmt.
  • Lizenz: GPL v3 laut Root-Lizenz und README (LICENSE); die genaue SPDX-Variante ist nicht eindeutig deklariert. Das MCP-Unterpaket deklariert MIT (package.json), ohne klar erkennbare separate Lizenzdatei. Vor Fork oder Codeübernahme sind SPDX-Variante und MCP-Abgrenzung rechtlich zu klären.
  • Technologie: Tauri v2/Rust, React 19, TypeScript/Vite, Milkdown, Graphology/Sigma/Louvain, AnyDoc, notify, lokale LanceDB, Node-MCP. Der Root-Dependency-Audit meldete 16 npm-Vulnerabilities, der MCP-Baum fünf; das ist ein Wartungssignal, kein unmittelbarer Exploitnachweis.
  • Operatives Risiko: Desktop-Prozess muss für API/MCP laufen. Für langfristige unbeaufsichtigte Automation ist das schwächer als eine reine CLI/CI-Engine.

5. Prüfung der zwingenden Betriebsconstraints

Constraint WiWoW heute OpenWiki @ 6ffa7b6 llm_wiki @ 889789c Urteil
On-Premise LLM Claude-only Live-Gate; kein Adapter generischer lokaler OpenAI-Endpunkt lokale/custom Provider real OpenWiki im PoC validieren; llm_wiki am klarsten implementiert
OpenAI-compatible API MISSING IMPLEMENTED IMPLEMENTED Eigenbau nicht gerechtfertigt
vLLM MISSING protokollseitig plausibel, ungetestet im Providercode explizit vorgesehen, E2E ungetestet für beide PoC-Hard-Gate
Kein Cloud-Zwang aktueller Gatepfad faktisch Claude CLI ja, bei lokalem Endpoint ja, optionale Cloudparser sind nicht nötig beide Referenzen grundsätzlich geeignet
Git-versioniertes Wissen Format/Gates vorhanden tief integriert, Update-/PR-Workflow nur extern möglich OpenWiki klar bevorzugt
Langfristig lesbares Markdown EQUIVALENT EQUIVALENT, normale Links/OKF EQUIVALENT, aber Obsidian-Wikilinks und kein OKF OpenWiki näher am Muss
geringe Vendor-Abhängigkeit Output gering, Producer aktuell Claude Output gering; Runtime bindet an LangChain/DeepAgents Output lesbar; Runtime bindet an Tauri/LanceDB, GPL OpenWiki akzeptabel mit pinning; kein interner API-Coupling
Agent-/CLI-Nutzung Prompt manuell/Claude-Harness native CLI plus Codex/Claude MCP API/MCP/Agent, aber Desktop nötig OpenWiki operativ einfacher
Langzeitautomation sehr langsame Bash-Gates GitHub/GitLab/Bitbucket CI Watcher/Queue, aber laufende App OpenWiki passt besser
Lesen ohne Runtime ja ja ja für Markdown; Suche/Graph brauchen App alle beim Basiskonsum passend

Cloud-only Connectoren oder Hosted-Evals wurden nicht als Ersatz für lokale Anforderungen gewertet. OpenWikis On-Prem-Fit hängt praktisch davon ab, dass das lokale Modell zuverlässiges Tool Calling und ausreichend große Kontexte bietet. Diese Unsicherheit ist ein PoC-Gegenstand, kein Grund, vorab wieder eine eigene Engine zu bauen.

6. Competitive Capability Matrix

Die Matrix bewertet Requirement Fit, nicht die Anzahl vorhandener Features. Ein BETTER für Retrieval kompensiert daher kein MISSING bei zwingender Provenienz. WiWoW wird nach seiner aktuellen ausführbaren Realität bewertet, nicht nach Epic-4+-Absicht.

Capability WiWoW OpenWiki llm_wiki Requirement Verbleibender Gap
Portables Markdown + OKF 0.2 + normale Links PARTIAL EQUIVALENT PARTIAL MUST OpenWiki: vollständiges Hard-Gate; llm_wiki: OKF-Export und Linknormalisierung
Raw-/Knowledge-Trennung EQUIVALENT EQUIVALENT EQUIVALENT MUST klare Retention-/Revocation-Policy
Concepts und Cross-Source-Synthese PARTIAL EQUIVALENT EQUIVALENT MUST Qualität und Wiederholbarkeit im PoC messen
Strukturierte First-class Claims PARTIAL PARTIAL MISSING MUST für starke Provenienz OpenWiki nur Repository-Sources; semantische Entailment überall offen
Claim-Provenance für Repository-Sources PARTIAL BETTER MISSING MUST OpenWiki-Evidence semantisch prüfen; sichtbare Range-Projektion optional
Claim-Provenance für externe Dokumente PARTIAL MISSING MISSING MUST, falls Nicht-Code-Sources zentral kleiner externer Resolver/Adapter oder Enginegrenze erforderlich
Page-Provenance EQUIVALENT BETTER PARTIAL MUST llm_wiki nur sources[]; OpenWiki Connector-Pfad schwächer
Trust / Human Review MISSING PARTIAL PARTIAL MUST für Langzeitpflege portable Human-Review-Ereignisse und Policy
Lifecycle / Freshness / Deprecation PARTIAL PARTIAL PARTIAL MUST Zeitregeln, portable Reviewpolicy und Claim-/Source-Revocation fehlen; llm_wiki besitzt nur eine produktinterne Review Queue
Harte Schema-/Bundlevalidierung PARTIAL PARTIAL PARTIAL MUST eigenständiger deterministischer Validator ist plausibel
Inkrementeller No-op PARTIAL EQUIVALENT PARTIAL MUST llm_wiki skippt unveränderten Text, kann aber multimodale Extraktion/Summary/Embedding weiter ausführen; OpenWiki plant Änderungen agentisch
Source Change / Move / Delete MISSING PARTIAL BETTER MUST für jahrelange Pflege Claim-aware Replacement/Retraction bleibt offen
Menschliche Textkorrekturen bewahren MISSING PARTIAL MISSING MUST llm_wiki ersetzt bei Sole-Source-Updates den Body; Multi-Source-Merge ist ohne Human-Markierung unbewiesen; PoC-Hard-Gate
Widersprüche als Wissen erhalten MISSING MISSING PARTIAL MUST, sofern konflikthafte Sources real sind portable contested-claim-/decision-Semantik
Git-Diff, No-op, PR-/Commit-Automation PARTIAL BETTER MISSING MUST llm_wiki braucht externen Git-Wrapper/CI samt Ignore-/Secret-Policy; WiWoW-Leasekomplexität entfällt
OpenAI-compatible / lokal / vLLM MISSING PARTIAL PARTIAL MUST lokale OpenAI-wire-Endpunkte sind implementiert; echter vLLM-E2E-Lauf bleibt für beide Kandidaten Pflicht
Agent-/CLI-/CI-Nutzung PARTIAL BETTER PARTIAL MUST llm_wiki braucht laufende Desktop-App
Lesen ohne Producer-Runtime EQUIVALENT EQUIVALENT EQUIVALENT MUST keine wesentliche Lücke
Source-grounded Retrieval MISSING PARTIAL BETTER SHOULD, kann consumerseitig sein OpenWiki braucht externen Retriever nur bei gemessenem Bedarf
Vector Search NOT REQUIRED NOT REQUIRED BETTER OPTIONAL kein Entscheidungs-Gap; nicht nachbauen ohne Skalenbeleg
Knowledge Graph / Communities / Gap Heuristik NOT REQUIRED NOT REQUIRED BETTER OPTIONAL keine Ontologie daraus ableiten; kein Feature-Count-Bonus
MCP-/HTTP-Query-API MISSING PARTIAL BETTER SHOULD für Agenten OpenWiki-Lifecycle-MCP ist kein Retrieval-MCP
Skalierung auf langfristig wachsenden Korpus MISSING PARTIAL PARTIAL MUST, Zielgröße noch unquantifiziert Korpusgröße/SLO definieren und im PoC messen
Federation mehrerer Wikis MISSING MISSING; mehrere Instanzen als Enabler MISSING; mehrere Projects/API als Enabler NEUES SHOULD, kein bisheriges WiWoW-Requirement dünner Registry-/Router-PoC erst bei ≥3 realen Wikis
geringe Format-/Vendorbindung PARTIAL EQUIVALENT PARTIAL MUST OpenWiki-Upgrades pinnen; keine internen DeepAgents-APIs koppeln
Semantische Quality Evals MISSING PARTIAL MISSING MUST vor Produktentscheidung gemeinsames Golden Set und Update-Szenarien; vorhandene Integrationstests sind kein Knowledge-Quality-Eval
Operative Einfachheit MISSING EQUIVALENT PARTIAL MUST OpenWiki-main-Build zunächst reproduzierbar verpacken

Matrixurteil

  • OpenWiki gewinnt nicht durch Featuremenge, sondern weil es die zwingende Schnittmenge aus Markdown/OKF, Claims, repositorygebundener Provenienz, Git, Incrementality, lokalen Providern und Agent-/CI-Betrieb am weitesten operationalisiert.
  • llm_wiki gewinnt bei Commodity Infrastructure, verliert aber bei genau den fachlichen Eigenschaften, die WiWoW als langfristiges Wissensartefakt definieren: OKF, Claims, claim-granulare Provenienz, Git und Runtime-Unabhängigkeit der erweiterten Funktionen.
  • WiWoW besitzt gegenwärtig keinen ausführbaren Bereich mit eindeutiger Gesamtführerschaft. Sein strengerer Vertragsentwurf kann als Policy-/Validatorquelle dienen, nicht als Beleg für eine bessere Engine.

7. Besonders kritischer Vergleich: WiWoW vs. OpenWiki

7.1 OKF

OpenWiki unterstützt auf dem untersuchten main tatsächlich OKF 0.2. Es erzeugt ein portables Markdownbundle, reservierte Indizes, normale Links und standardisierte sources-, generated-, verified-, status- und stale_after-Felder. WiWoWs eigene OKF-Erzeugung ist daher nicht mehr als eigenständige Knowledge Engine notwendig.

WiWoW beschreibt ein engeres Profil und mehr Validierungsregeln. Dieser Vorteil ist heute textuell, nicht operativ: Der Validator ist ein Prompt. Die wirtschaftlich und architektonisch richtige Form des verbleibenden Werts ist ein kleiner deterministischer OKF-/Policy-Validator, der ein OpenWiki-Bundle nach dem Lauf prüft. Das kann zunächst als externes CI-Gate geschehen. Nur wenn eine atomare Vor-Commit-Prüfung zwingend ist und OpenWiki keinen Hook akzeptiert, wäre eine sehr kleine Upstream-Erweiterung zu rechtfertigen.

Antwort: Nein, eine eigene WiWoW-OKF-Verarbeitungskette ist nicht gerechtfertigt. Ja, einzelne strengere Regeln können als unabhängiger Validator weiterleben.

7.2 Claims

Aspekt WiWoW heute OpenWiki main
Repräsentation Proseaussage im Markdown mit Inline-Sourcekonvention strukturiertes page-owned Claimobjekt im Sidecar
Identität primär Page/Pfad, kein eigenständiger Claim-Lifecycle stabile Claim-ID innerhalb der Seite
Evidence Sourcepfad/Fragment konventionell repo://path#Lx-Ly plus Inhaltsversion
Mutationen promptgesteuerte Pageänderung add, confirm, update, retract, atomisch persistiert
Change Detection keine belastbare Claim-Neuauflösung stale/unresolved durch erneuten Resolverlauf
Entailment nicht deterministisch geprüft ebenfalls nicht deterministisch geprüft
Contradiction geplant, nicht implementiert nicht als Claimrelation implementiert
Cross-Wiki nicht vorhanden nicht vorhanden

OpenWikis Claimsemantik ist enger als eine Ontologie, aber deutlich ausführbarer. verified bedeutet, dass ein erfolgreicher Reconciliation-Lauf mindestens einen persistierten Claim ohne offene Evidence-Issue hinterließ und die Evidence beim finalen Check unverändert war. Es bedeutet nicht, dass ein Satz logisch bewiesen, vollständig, unabhängig bestätigt oder menschlich geprüft wurde.

WiWoW ist damit semantisch nicht „stärker“, sondern ambitionierter beschrieben und schwächer operationalisiert. Ein echter Mehrwert bliebe erst bei strukturierter Contradiction-, Cross-Source- oder Human-Decision-Semantik.

7.3 Provenance

Für Repository-Sources ist OpenWiki praktisch stärker:

  • exakter Pfad und optionaler Zeilenbereich;
  • Content Hash als Evidence-Version;
  • sichere Resolvergrenze;
  • Relokation unveränderter Evidenz nach Sourceänderung;
  • automatische stale-/unresolved-Erkennung;
  • Body-Hash-basierte Producerprovenienz;
  • Git-History für Bundleänderungen.

Die Grenzen sind wichtig: Im sichtbaren OKF-Frontmatter werden Claims auf Whole-File-Sources projiziert; präzise Ranges bleiben im Sidecar. Connector-Fakten besitzen nicht dasselbe Evidence-Modell. Weder OpenWiki noch WiWoW prüft deterministisch, ob die zitierte Passage die Behauptung semantisch trägt.

Urteil: OpenWiki-Provenienz ist nicht bloß „anders“, sondern für Code-/Textdateien operational stärker. WiWoW hat nur für externe Sources einen konzeptionellen Vorsprung, der noch implementiert werden müsste. Diese Lücke rechtfertigt einen Resolver/Adapter, nicht den Neuaufbau der Engine.

7.4 Trust und Lifecycle

OpenWiki bewahrt vorhandene Human-/Process-Verification-Events und projiziert Machine Verification. Es validiert Lifecyclefelder formal, führt stale_after aber nicht als Zeitregel aus. WiWoW beschreibt Human-vs-Machine-Actors und ein Lifecycleprofil, besitzt nach Epic 3 jedoch ebenfalls keinen Reviewworkflow oder Lifecyclemotor.

Urteil: WiWoW hat hier keinen aktuellen Produktvorteil. Ein Differentiator entstünde erst durch einen realen, portablen Workflow für Human Review, Evidence Quality, Expiry, Deprecation und contested Claims. Ob dieser nötig ist, muss der PoC mit realen Pflegefällen zeigen.

7.5 Validation

OpenWikis ausführbare Validierung ist mechanisch stärker als WiWoWs textueller Validator, aber inhaltlich weniger strikt als WiWoWs Vertrag:

  • fehlerhafte optionale OKF-Felder können bei ansonsten parsebarem type bestehen bleiben;
  • Agent-Write-Validierung liefert teils Warnungen statt Hard-Fail;
  • Linkfehler werden markiert statt den Build abzubrechen;
  • Mermaidfehler werden zu Text degradiert;
  • kein vollständiger abschließender Bundlecheck.

Das ist der sauberste Kandidat für eine externe WiWoW-derived Policy Library. Sie sollte ausschließlich deterministische Form-/Referenzregeln enthalten; keine LLM-Wahrheitsprüfung und keine Git-Leases.

7.6 Agent Architecture

OpenWikis Ansatz ist insgesamt einfacher und robuster als WiWoWs Pipeline, weil er deterministische Verantwortlichkeiten in Code zieht:

  • Path Confinement, Sidecarpersistenz, Claimresolver, No-op, Git-Diff und Finalizer sind Code;
  • das Modell entscheidet weiterhin semantische Struktur und Formulierung;
  • Review-Subagents sind read-only;
  • externe Coding Agents nutzen ein kleines Lifecycle-MCP statt eines 293-KB-Monolithprompts.

OpenWiki ist nicht deterministisch im Sinn identischer freier Prosa. Es versucht das aber auch nicht als falsches Qualitätsziel. Risiken bleiben Overdocumentation bei Init, hohe Tokenkosten, Modell-/Tool-Calling-Abhängigkeit und agentische Diff→Page-Planung. Diese Risiken sind durch Evals und Budgetgrenzen zu kontrollieren, nicht durch Bytegleichheit.

7.7 Update Model und Change Detection

Schritt WiWoW OpenWiki
No-op Prompt-/Harnessvertrag; echter Agent kann fälschlich nichts tun Git-HEAD-/Worktree-Prüfung ohne Modell
Sourceänderung bestehende Raw-Änderung tendiert zum Hard-Fail Git-Diff liefert geänderte Pfade
Page Impact agentisch, ohne ausführbaren Dependencygraph ebenfalls agentisch; kein vollständiger Source→Page-Graph
Claim Impact nicht ausführbar Evidence Preflight → stale/unresolved
Updatepersistenz Agent schreibt Markdown; komplexe Lease-/Receipt-Regeln transaktionales Init, Claims-Batch, Finalizer, Git-Diff/PR
Löschung/Revocation nicht fachlich gelöst Evidence wird unresolved; vollständige Wissensrevocation bleibt unvollständig

OpenWiki ist damit klar besser für kontinuierliche Repositorypflege. Für jahrelange Knowledge Maintenance fehlen beiden eine robuste Source-Revocation-Policy, ausführbare Zeitstaleness und messbarer Schutz menschlicher Korrekturen. Diese drei Szenarien gehören in den PoC.

7.8 Extend oder Fork?

Prioritätsreihenfolge:

  1. Konfiguration und Prompt-/Skillanpassung;
  2. externer Validator bzw. Retrieval-/Federation-Service über Dateien und öffentliche Schnittstellen;
  3. kleiner Upstream-Beitrag mit stabiler Hook;
  4. erst dann Fork.

Ein Fork ist nur vertretbar, wenn ein zwingendes Exit Criterion ohne Änderung im transaktionalen finish-Pfad nicht erreichbar ist, der Upstream einen Hook ablehnt und die Abweichung dauerhaft klein sowie automatisch rebase-testbar bleibt. Retrieval, Vektorsuche oder Federation sind kein Grund, die Knowledge Engine zu forken; sie gehören darüber.

8. Besonders kritischer Vergleich: WiWoW vs. llm_wiki

Bereich llm_wiki-Befund Hat WiWoW heute einen echten Vorteil? Konsequenz
Ingestion Multi-Format-Pipeline, Parser, Queue, Watcher, Delete/Move Nein; WiWoW lagert Acquisition aus und hat keine Engine nicht neu bauen
Two-Step Analysis/Generation getrennte Hauptcalls, optional Review/Repair/Merge Nein; WiWoW besitzt nur Promptphasen als Commodity übernehmen/evaluieren
Chunking deterministisch, Markdown-aware, Long-source Checkpoints Nein nicht neu bauen
Incremental Processing SHA-Skip, Page-Merge, Source Lifecycle nur bei gewünschter claim-granularer Semantik konzeptionell Engine nutzen, Claims separat beurteilen
Caching Content Hash + Outputexistenz + Checkpoints Nein Commodity
Source-grounded Retrieval Faithful Mode mit Raw-Source-Snippets/Pfaden WiWoW hat strengere Provenienzabsicht, aber keine Retrievalimplementierung llm_wiki funktional besser, Provenienz semantisch schwächer
Vector Retrieval lokales LanceDB, Hybrid-RRF Nein, außerdem kein heutiges MUST nicht nachbauen; nur nutzen, wenn Eval Mehrwert zeigt
Knowledge Graph Links/Source-Overlap/Adamic-Adar/Type-Affinity kein heutiger WiWoW-Vorteil; beide ohne Ontologie abgeleiteter Index, nie kanonisches Wissen
Community Detection Louvain real implementiert Nein Commodity/optional
Knowledge-Gap Detection graphheuristisch, nicht semantisch WiWoW hat auch keine Engine nicht mit echter Wissenslückenanalyse verwechseln
Review UX persistente HITL-Items WiWoW hat nur Backlogsemantik produktiver Vorsprung llm_wiki
OKF fehlt vollständig Ja, im Formatvertrag bei llm_wiki erheblicher Adaptergap
Claims/Provenance nur page-level sources[] Ja, konzeptionell; nicht ausführbar überlegen zentraler Grund gegen unverändertes llm_wiki
Git nur extern möglich Ja, WiWoW-Format/Gitabsicht; OpenWiki aber stärker spricht für OpenWiki, nicht für Eigenbau
Agent-/API-Betrieb starke API/MCP, aber Desktop muss laufen kein WiWoW-Vorteil Headless-SLO im PoC prüfen

Gesamturteil: Bei Ingestion, Chunking, Cache, Incrementality, Retrieval, Vectorindex und Graph würde WiWoW Commodity Infrastructure erneut entwickeln. Ein eigener Compiler ist dadurch nicht gerechtfertigt. llm_wiki bleibt dennoch nur Option D bzw. PoC-Referenz, weil ein nachträglicher OKF-/Claims-/Provenance-/Git-Layer voraussichtlich größer und invasiver wäre als die verbleibenden Ergänzungen über OpenWiki. Hinzu kommen GPL-Copyleft und Desktop-Runtime als Integrationsrisiken.

9. Federation / „Wiki of Wikis“

9.1 Ist Federation heute vorhanden?

Nein — in keinem der drei Systeme.

  • WiWoWs PRD, SPEC, Architecture, Epics, Code und Tests definieren genau ein wiki/-Bundle. Es gibt keine Wiki-Registry, Cross-Wiki-Abfrage, Routing-, Entity-Resolution-, Trust-Aggregation- oder Ontologiesemantik. Der Name „Wiki of Wikis“ ist kein implementiertes Requirement.
  • OpenWiki verwaltet im Repositorymodus ein Wiki unter openwiki/ je Git-Root und im Personal Mode ein lokales Wiki. Mehrere getrennte Repositories/Instanzen sind möglich, aber nicht gemeinsam abfragbar.
  • llm_wiki verwaltet mehrere isolierte Projects. API-Aufrufe sind project-scoped; die MCP-Session wird explizit an genau ein Project gebunden. Es existiert kein Cross-Project Search oder gemergter Graph.

Die WiWoW-PRD definiert das Knowledge Bundle als Gesamtheit eines verwalteten OKF-Wikis; die Architektur genau eine Bundleroot wiki/. Es gibt auch keine Story ab Epic 4, die Federation einführt. Federation ist daher eine neue Produkthypothese, kein Sunk-Cost-geschützter Differentiator.

9.2 Reichen mehrere Instanzen und ein Router?

Für die genannten Beispiele — Spring, Flowable, BMAD, Architecture — ist die wahrscheinlich kleinste hinreichende Architektur:

flowchart TD
    A["Agent / CLI / IDE"] --> R["Thin Wiki Registry + Router"]
    R --> S["Spring Wiki\nOpenWiki repo/instance"]
    R --> F["Flowable Wiki\nOpenWiki repo/instance"]
    R --> B["BMAD Wiki\nOpenWiki repo/instance"]
    R --> W["Architecture Wiki\nOpenWiki repo/instance"]
    S --> K["Optional derived retrieval indexes"]
    F --> K
    B --> K
    W --> K
    P["External OKF / Policy validator"] -. validates .-> S
    P -. validates .-> F
    P -. validates .-> B
    P -. validates .-> W

Der Router braucht in einer ersten Version nur:

  • Registry: Wiki-ID, Domainbeschreibung, Pfad/Repo, Version, Zugriffsart;
  • Kandidatenauswahl: expliziter Wiki-Scope, lexikalische/semantische Routingbeschreibung;
  • parallele Query an ein oder mehrere Wikis bzw. direktes Lesen ihrer Markdown-Indizes;
  • Antwortzusammenführung mit Wiki- und Source-Namespace;
  • keine Schreibkoordination über Wikis hinweg.

Das ist kein Knowledge Compiler. Es ist eine kleine Library oder ein MCP-/CLI-Adapter. Mehrere unabhängige Wikis sind operativ sogar vorteilhaft: getrennte Ownership, Releasezyklen, Trust Policies und Repositories bleiben erhalten.

9.3 Braucht Federation eine gemeinsame Ontologie?

Nicht zunächst. Eine Ontologie kann später abgeleitet über vorhandenen Wikis liegen:

  • Namespaced Concept IDs statt globaler Umbenennung;
  • Alias-/Same-as-Mappings in einem separaten Registry-Bundle;
  • Cross-Wiki-Relations als eigener abgeleiteter Index;
  • keine Mutation der kanonischen Wiki-Markdowndateien durch den Router.

Eine globale Ontologie vor realen Cross-Wiki-Queries wäre YAGNI. Sie wird erst gerechtfertigt, wenn gemessene Entity-Kollisionen, Cross-Domain-Claims oder Routingfehler mit einfachen Namespaces nicht lösbar sind.

9.4 Entscheidung zur Kernfrage

Ja: „Wiki of Wikis“ ist nach heutiger Evidenz wahrscheinlich nur ein dünner Federation Layer über existierenden Wiki-Systemen.

Er sollte erst gebaut werden, wenn mindestens drei reale Fachwikis existieren, ein Golden Set Cross-Wiki-Fragen enthält und Single-Wiki-Routing nachweisbar nicht reicht. Bis dahin genügen mehrere Instanzen und expliziter Scope im Agent/CLI.

10. Strategische Optionen

Option A — WiWoW weiterentwickeln

Bestehende Prompt-/Lease-/Receipt-/Validatorarchitektur fortführen und Epic 4/5 implementieren.

Urteil: verwerfen. Diese Option verlängert eine unbewiesene Engine, deren Kern-Gate nach Epic 3 rot ist, und baut Provider, Change Detection, Claims, Ingestion-/Retrieval-nahe Infrastruktur sowie Wartungslogik erneut. Der Großteil des Aufwands dient der eigenen Architektur, nicht Knowledge Quality.

Option B — WiWoW vereinfachen

Promptmonolith, Byte-Determinismus, Root-Leases und Commodity-Bestand reduzieren; eigenen kleinen Compiler für OKF/Provenienz/Trust behalten.

Urteil: nur Rückfalloption. Beseitigt erhebliche Fehlkomplexität, behält aber das höchste semantische Risiko — eine eigene agentische Knowledge Engine — und muss Claims, Provider, Changes, Updates und Evals weiterhin selbst tragen.

Option C — OpenWiki einsetzen und intern erweitern

OpenWiki als Engine; Validator, externe Claimresolver, Human Review und ggf. Federation als OpenWiki-Codeänderungen oder Fork ergänzen.

Urteil: gut, aber nicht optimal. Hoher Fit und deutlich weniger Eigenbau. Direkte Erweiterung koppelt jedoch an ein sehr junges, schnell wechselndes internes API und erzeugt unnötig früh Fork-/Rebase-Risiko.

Option D — llm_wiki einsetzen und erweitern

llm_wiki als Engine; OKF-Export, Claims/Provenance/Trust, Git und Federation ergänzen.

Urteil: nur bei dokument-/retrievalzentrierter Priorität. Ingestion und Retrieval sind stark, aber die Ergänzungen schneiden quer durch Datenmodell, Updatepfad, API und Persistenz. GPL und Desktop-Runtime erhöhen das Risiko. Gegenwärtig schlechterer Kernfit als OpenWiki.

Option E — Eigenentwicklung einstellen, Standardprodukt unverändert verwenden

OpenWiki ohne eigene Produktkomponenten einsetzen; nur Konfiguration, Skills und Betriebsautomation.

Urteil: besser als WiWoW-Build und bei geringerem Provenienz-/Federationsbedarf völlig plausibel. Es fehlen jedoch noch harte Bundlevalidierung, externe Claim-Provenienz und ein nachgewiesener Human-Protection-/vLLM-Pfad. Deshalb nicht die primäre Empfehlung unter den derzeit formulierten Must-haves.

Option F — OpenWiki upstream-nah + getrennte, PoC-getriebene Companion-Komponenten

OpenWiki auf fixierter Revision als Knowledge Engine; keine interne Enginekopie. Nur kleine engine-neutrale Komponenten außerhalb des Authoring-Kerns:

  • deterministischer OKF-/Policy-Validator als CI-Gate;
  • optionaler externer Evidence Resolver für nicht-repositorybasierte Sources;
  • optionaler Registry-/Retrieval-/Federation-Layer;
  • Human-Curation-Akzeptanztests und gegebenenfalls kleine Schutzpolicy.

Urteil: empfohlen. Diese Option maximiert Standardnutzung und Reversibilität, hält kanonisches Wissen als Markdown/OKF, vermeidet einen Fork und isoliert die echten Differentiatoren. „Optional“ bedeutet: erst nach einem fehlgeschlagenen PoC-Kriterium bauen.

11. Gewichtete Build-vs-Adopt Decision Matrix

11.1 Scoring

Skala 1–5; 5 ist am besten. Bei Implementation Effort bedeutet 5 wenig Restaufwand, bei Vendor/Project Risk bedeutet 5 geringes Risiko. Scores bewerten die erwartete Zieloption, nicht bereits investierte Arbeit.

Criterion Weight A: weiter B: vereinfachen C: OpenWiki intern erweitern D: llm_wiki erweitern E: OpenWiki unverändert F: OpenWiki + externer Minimal-Layer
Functional Fit 20 % 3 3 5 3 4 5
Knowledge Quality 15 % 2 3 4 3 4 4
Provenance / Trust 10 % 3 4 5 2 4 5
On-Premise Compatibility 10 % 2 4 4 4 4 4
Maintainability 10 % 1 3 4 3 5 5
Implementation Effort 10 % 1 2 4 2 5 4
LLM/Token Efficiency 5 % 1 3 4 3 4 4
Extensibility 5 % 2 4 4 3 3 4
Federation Potential 10 % 1 3 3 3 2 4
Vendor/Project Risk 5 % 2 3 4 3 4 4
Gewichteter Score / 5 100 % 1,95 3,15 4,20 2,90 3,95 4,40

Formel: Σ(score × weight) / 100. Ein Abstand von 0,2 ist wegen PoC-Unsicherheit nicht absolut; der Abstand von A zu C/E/F ist jedoch entscheidungsfest.

11.2 Evidenz für die Einzelbewertungen

Criterion A — WiWoW weiter B — vereinfachtes WiWoW C — OpenWiki-Extend D — llm_wiki-Extend E — OpenWiki unchanged F — OpenWiki + Companion
Functional Fit Vertrag breit, Implementierung nach Epic 3 unvollständig und Gate rot Kernrequirements bleiben, Commodity wird reduziert OKF/Claims/Git/CLI passen; Gaps erweiterbar starke Ingestion, aber OKF/Claims/Git fehlen hoher Baseline-Fit, Hard-Gaps bleiben gleicher Fit plus isolierbare Hard-Gaps
Knowledge Quality nur vier selbstreferenzielle Concepts; keine semantischen Evals bessere Fokussierung, aber Engine unbewiesen Claims/Review/Finalizer real; Livequalität noch PoC Two-Step/Review/Retrieval sind Mechanismen, aber kein Ergebnis-Eval; Provenienz schwach gleiches OpenWiki-Authoring ohne Schutzergänzung Quality bleibt Engineleistung; Companion verhindert formale/kuratierte Regression
Provenance / Trust strenger Entwurf, kein ausführbares Claimmodell/Humanworkflow könnte fokussiert implementiert werden repositorygenaue Evidence + Erweiterungspunkt nur page-level sources[]; großer Umbau repositoryseitig gut, extern/Human partial externes Policy-/Resolvermodul ergänzt gezielt
On-Premise aktuell Claude-CLI-only Provider muss neu gebaut werden OpenAI-compatible real, vLLM zu testen lokale/OpenAI-wire-Endpunkte explizit; vLLM-E2E und Desktopbetrieb offen wie C wie C; lokaler Betrieb bleibt Hard-Gate
Maintainability 293-KB-Prompt, 1,05-MB-Harness, drei Lease-Modelle weniger, aber eigener Compiler bleibt Upstreambasis; direkte Patches koppeln intern großer Desktop-/Rust-/React-Stack plus GPL minimal eigener Code minimaler eigener Code mit klarer Grenze
Implementation Effort Epic 4/5 plus Grundlagen/Evals fehlen erheblicher Umbau und Restengine kleiner als Eigenbau, aber Integrationshooks OKF/Claims/Git quer durch Stack nur Konfiguration/PoC kleiner externer Validator/Router nur bei Bedarf
LLM/Token Efficiency 31k-Wort-Instruktion, 32k Output, lange Gates Prompt kann schrumpfen, Caches fehlen Git-No-op ohne Modell, DeepAgent weiterhin teuer SHA-Cache hilft, Two-Step plus Review/Repair/Merge kann Calls erhöhen; ungemessen OpenWiki-No-op; Initrisiko wie E plus messbare Budgets
Extensibility Textvertrag flexibel, ausführbarer Extensionvertrag fehlt kleiner Kern könnte modular werden Connector/Provider gut; interne Hooks jung API/Schema/Templates gut, Embedded-Library schwach Konfiguration gut, tiefe Gaps nicht Engine-neutraler Companion maximiert Austauschbarkeit
Federation nichts implementiert könnte gebaut werden, aber vermischt mit Engine mehrere Instanzen; eigener Cross-Wiki-Code nötig mehrere Projects; Router möglich nur manuelle Instanzwahl Registry/Router ist explizit separierbar
Vendor/Project Risk eigenes Bus-Faktor-/Wartungsrisiko, Claude-Bindung reduziert, aber allein getragen MIT, aktive Community; junger/churnender Upstream GPL, Desktop, Lizenzinkonsistenz MCP, große Dependencyfläche kein Fork; Upstreamchurn bleibt kein Fork, Revision pinning und Austauschgrenze reduzieren Risiko

11.3 Sensitivitätsanalyse: geringere Bedeutung von Federation

Die Ausgangsgewichtung gibt Federation 10 %. Zwei Varianten wurden gerechnet; die übrigen Gewichte werden proportional neu skaliert.

Szenario A B C D E F Rangfolge
Baseline: Federation 10 % 1,95 3,15 4,20 2,90 3,95 4,40 F > C > E > B > D > A
Federation 2 % 2,03 3,16 4,31 2,89 4,12 4,44 F > C > E > B > D > A
Federation 0 % 2,06 3,17 4,33 2,89 4,17 4,44 F > C > E > B > D > A

Ergebnis: Die Empfehlung ändert sich nicht. Geringere Federation-Bedeutung stärkt Adoption — insbesondere OpenWiki unverändert — statt WiWoW. Option F bleibt vorn, weil ihr Wert primär aus geringem eigenem Code und isolierter Policy kommt, nicht aus einem großen Federation-Projekt.

12. Sunk-Cost Check

Würden wir heute bei null anfangen und WiWoW hätte keine einzige Zeile Code: Würden wir es angesichts OpenWiki und llm_wiki noch selbst entwickeln?

NO.

Wir würden zuerst OpenWiki auf dem fixierten aktuellen Stand gegen die zwingenden Anforderungen evaluieren, llm_wiki als Ingestion-/Retrieval-Benchmark heranziehen und nur nachgewiesene Restlücken separat schließen. Der heutige Markt-/Codebestand rechtfertigt weder einen eigenen End-to-End-Compiler noch die bisherige Lease-/Receipt-/Byte-Determinismusarchitektur.

Das ist keine Aussage, dass jede WiWoW-Idee wertlos ist. Strikte Validierungsregeln, Human-Curation-Schutz, externe Evidenzauflösung und mögliche Federation sind wiederverwendbare Anforderungen. Sie rechtfertigen aber höchstens kleine Komponenten, nicht die Fortsetzung des Produkts in seiner heutigen Form.

13. Reinvented Commodity Infrastructure

Folgende Bereiche würde WiWoW unnötig selbst entwickeln oder bereits mit hohem Aufwand simulieren:

Commodity OpenWiki llm_wiki Entscheidung
Agentlauf / Modellprovider DeepAgent, 13 Provider, Codex/Claude-Integration viele Provider, lokale CLIs, Agent übernehmen
OpenAI-compatible / lokale Modelle generischer Endpoint Custom/Ollama/vLLM-kompatibel übernehmen und E2E testen
Git Change Detection / No-op nativ, ohne Modell Hash-/Watcher-basiert, Git extern OpenWiki übernehmen
transaktionales Init/Update implementierter Run-Boundary/Rollback persistente Queue und Page Merge übernehmen
Claim Store / Evidence Resolver strukturierte Sidecars, Hash/Range/Relocation nicht vorhanden OpenWiki übernehmen/erweitern
Source Connectors Git, MCP, SaaS-/Webquellen umfangreiche lokale Parser/Watcher nicht im WiWoW-Kern bauen
Long-document Chunking nicht allgemeingültig implementiert und checkpointed bei Bedarf Standardkomponente nutzen
Caching Git-No-op, Connector-State SHA-/Output-/Checkpoint-Cache nicht neu bauen
Markdown-/Index-Finalisierung OKF, Links, Indizes, Mermaid Schema/Index/Wikilinks OpenWiki übernehmen
Review-/Lint-Infrastruktur Review-Subagents, Link-/OKF-Finalizer persistente HITL-Reviews, Struktur-/Semantiklint konfigurieren, nicht neu erfinden
Retrieval / Vector / Graph Datei-/Linkgraph; extern ergänzbar Hybrid/LanceDB/Louvain nur als abgeleiteten Consumerdienst nutzen
API/MCP/CLI CLI/CI/Lifecycle-MCP HTTP/MCP/Desktop vorhandene Schnittstelle wählen
Multi-OS Build/Test reife CI-Strukturen in beiden drei Desktopplattformen Upstream nutzen

Die Eigenentwicklung sollte sich nicht an „Feature Parity“ versuchen. Insbesondere Vector Search, Knowledge Graph und Community Detection sind nur dann relevant, wenn ein Retrieval-Eval einen messbaren Vorteil gegenüber normaler Datei-/Indexsuche zeigt.

14. Minimal Differentiator Test

14.1 Was bleibt, wenn ausreichend gelöste Fähigkeiten entfernt werden?

Nach Abzug von Markdownauthoring, OKF-Basiserzeugung, Provider, Agentlauf, Git-Updates, No-op, Claims-Grundmodell, Ingestion, Chunking, Caching, Retrieval und Graph bleiben höchstens:

  1. WiWoW Policy Validator

    Deterministische zusätzliche OKF-/Bundle-/Referenzregeln, klare Exit Codes, keine LLM-Logik.

  2. External Evidence Adapter

    Stable Locators/Hashes für PDF, Webseiten oder andere Nicht-Repository-Sources, falls der PoC diese Sources wirklich benötigt.

  3. Human Curation / Contested Knowledge Policy

    Wenige portable Zustände und Akzeptanztests: menschliche Korrektur schützen, Gegenclaims erhalten, Reviewentscheidung nachvollziehen.

  4. Wiki Registry and Router

    Namespaces und Cross-Wiki-Abfrage über unabhängigen Wikis, erst bei belegtem Federationbedarf.

14.2 WiWoW Minimal Core

wow-registry.yaml              # optional: Wiki-ID, Domain, Repo/Pfad, Version
wow validate <wiki-path>       # deterministisches OKF-/Policy-Gate
wow query --scope ...          # optionaler dünner Cross-Wiki-Router
evidence-resolver plugins      # optional; nur für tatsächlich benötigte Sourcearten
golden-set/                    # engine-neutrale Qualitäts-/Update-Akzeptanztests

Explizit nicht Teil dieses Kerns:

  • kein eigener LLM-Orchestrator;
  • kein Compilerprompt;
  • keine Git-Lease-/Receipt-Engine;
  • kein eigener Markdownwriter oder Claim Store;
  • kein eigener Vector Store;
  • kein kanonischer Knowledge Graph;
  • keine Source-Acquisition-Suite;
  • kein Fork einer Knowledge Engine.

14.3 Produktklassifikation des Restkerns

Frage Antwort
Eigenständiges Produkt? Heute nein. Dafür fehlen belegter Nutzerbedarf, eigenständiger Workflow und ausreichend Umfang.
Library? Ja, potenziell für Validator/Registry, falls PoC-Gaps bestehen.
Adapter? Ja, insbesondere externe Evidence und Agent-/MCP-Routing.
Federation Layer? Potenziell ja, aber erst nach Nachweis mit mehreren echten Wikis.
Konfiguration/Skill-Sammlung? Wahrscheinlich die erste und kleinste Form.
Bleibt möglicherweise gar kein eigener Kern? Ja. Wenn OpenWiki-PoC und expliziter Scope pro Repo genügen, bleiben nur Konfiguration, CI und Evals.

Der Name WiWoW kann als Projekt-/Konfigurationsname weiterleben. Er bezeichnet dann kein selbst entwickeltes Wissenssystem mehr.

15. Recommended Architecture

15.1 Zielbild

flowchart LR
    subgraph Sources["Versionierte Sources"]
      MD["Markdown / Code / Text"]
      DOC["Optional: normalisierte Dokumente\nmit stabilen Locators"]
    end

    subgraph Engine["Adopted Knowledge Engine"]
      OW["OpenWiki\npinned upstream revision"]
      CL["Grounded Claims sidecars"]
      FIN["OKF 0.2 finalizers"]
    end

    subgraph Canonical["Kanonisches Artefakt"]
      W["Git-versioniertes OKF-/Markdown-Wiki"]
    end

    subgraph Optional["Nur nach PoC-Nachweis"]
      V["External deterministic policy validator"]
      R["Wiki registry + retrieval/router"]
      E["External evidence resolver"]
      X["Derived vector/graph index"]
    end

    A["Codex / Claude / local tool-calling agent\nvia OpenAI-compatible vLLM"] --> OW
    MD --> OW
    DOC --> OW
    OW --> CL --> FIN --> W
    V -. hard gate .-> W
    E -. resolver .-> CL
    W --> R --> C["Agents / CLI / IDE consumers"]
    W -. optional index .-> X --> R

15.2 Architekturregeln

  • Kanonischer Zustand bleibt Git/Markdown/OKF. Sidecars müssen offen, versioniert und ohne Dienst lesbar sein.
  • OpenWiki wird gepinnt und über Black-box-Akzeptanztests aktualisiert. Keine Kopie interner Agentlogik.
  • Source Acquisition bleibt getrennt. PDFs werden nur bei echtem Bedarf mit einem Standardparser in stabile, versionierte Text-/Locatorartefakte überführt.
  • Validator ist deterministisch. Er prüft Schema, Links, IDs, Sources, Actor-/Lifecycleform und optionale Policies; keine semantische Wahrheit per LLM.
  • Human Protection wird getestet, nicht behauptet. Verliert ein Update eine manuelle Korrektur, muss es entweder sicher mergen oder vor Commit hart stoppen.
  • Retrieval und Graph bleiben abgeleitet. Verlust des Index darf nie Verlust des Wissens bedeuten.
  • Federation ist read-first. Kein verteiltes Write-/Merge-/Trustprotokoll, solange reale Anforderungen das nicht erzwingen.
  • Kein Fork als Default. Externe Komponente oder Upstream-Hook zuerst.

15.3 Entscheidungsbaum nach dem PoC

OpenWiki erfüllt alle Hard Gates
  └─ ADOPT OpenWiki
      ├─ kein relevanter Gap → nur Config/Skills/Evals
      └─ kleiner Gap → externer Validator/Adapter (Option F)

OpenWiki scheitert an einem Hard Gate
  ├─ mit ≤5 Engineering-Tagen engine-neutral lösbar → Option F
  ├─ llm_wiki erfüllt alle Gates mit kleinem Adapter → Option D neu bewerten
  └─ beide scheitern gleichartig
       ├─ Requirement validieren/reduzieren
       └─ erst dann vereinfachten Eigenkern (Option B) neu entscheiden

16. Proof-of-Concept Plan — noch nicht implementieren

16.1 Zweck und Timebox

Der PoC ist zweistufig und besitzt einen harten Gesamtstopp nach acht Engineering-Tagen:

  1. Feasibility Gate — maximal drei Tage: reproduzierbare Installation, lokaler Provider, Cold Init, No-op und ein Update je Kandidat. Ein Kandidat mit Cloud-Zwang, nicht automatisierbarem Lauf oder frühem Datenverlust scheidet aus.
  2. Quality/Update Gate — maximal fünf weitere Tage: nur für verbleibende Kandidaten; Golden Set, Update-/Curation-Szenarien, drei Wiederholungen der kritischen Fälle und vollständige Messung.

Der PoC entscheidet die Enginewahl; er ist kein Vorwand für produktiven Adapterbau. Zulässig sind Konfiguration, wegwerfbare Messharnesses und reproduzierbare Runskripte. Produktcode, Forks, neue Ontologie und Federation-Engine sind ausgeschlossen.

16.2 Vergleichsarme und fixierte Inputs

Arm Stand
Historische Baseline aktuelles WiWoW-Ergebnis nach Epic 3; statisches Artefakt, kein gleichwertiger neuer Modelllauf
Primärkandidat OpenWiki 6ffa7b6debaed25422398c73ccc4d21ad1438795
Referenz llm_wiki 889789c3218e8c7844e8515d5429a4e53b96fc19 / v0.6.10

Sources:

  • raw/prd/prd-wow20-2026-08-14.md
  • raw/epics/epics-2026-08-14.md
  • raw/architecture-spine/architecture-spine-2026-08-14.md
  • RADIUM/MetaModel.pdf nur, wenn Originalsource und frühere Ausgabe wieder verfügbar und prüfbar sind; sonst keine erfundene Rekonstruktion.
  • Falls RADIUM fehlt, genau eine kleine lizenzklare PDF-/DOCX-Fixture mit bekanntem Golden Set, um Multi-Format-Ingestion separat zu testen. Ohne eine solche Fixture wird kein Multi-Format-Vorteil gutgeschrieben.

OpenWiki und llm_wiki erhalten denselben Source-Snapshot, dieselben Aufgaben, dasselbe lokale Modell, identische Sampling-/Budgetparameter und drei Wiederholungen je kritischem Szenario. Modell, vLLM-Version, Hardware, Prompt und Laufzeit werden protokolliert. WiWoW bleibt eine historische Artefaktbaseline: Mangels OpenAI-compatible-/vLLM-Adapter darf es nicht in quantitative Laufzeit-/Tokenvergleiche mit einem anderen Provider gemischt werden; dieser Confounder wird ausdrücklich ausgewiesen.

16.3 Szenarien

  1. Cold Init: vollständiges Wiki aus den drei realen Sources.
  2. No-op: unveränderter Source-/Git-State.
  3. Confirming Update: neue Source bestätigt bestehende Aussage.
  4. Correction: Source ersetzt eine konkrete frühere Aussage.
  5. Contradiction: zwei Sources widersprechen sich ohne autoritative Auflösung.
  6. Cross-source Synthesis: Antwort/Concept benötigt PRD + Architecture + Epics.
  7. Human Edit: fachlich richtige manuelle Korrektur vor erneutem Update.
  8. Rename/Move: Sourcepfad ändert sich, Inhalt bleibt gleich.
  9. Delete/Revocation: einzige und geteilte Source wird entfernt bzw. als ungültig markiert.
  10. Local Provider: alle relevanten Läufe über OpenAI-compatible vLLM ohne Cloud-Egress.
  11. Agent Consumption: CLI/Agent beantwortet Golden-Set-Fragen nur aus Wiki bzw. mit offenem Source-Fallback. Bei llm_wiki wird Faithful über UI/API getestet, weil MCP Chat keinen retrieval_mode anbietet; Raw-Source-Lexical Search und Wiki-Vector Search werden getrennt bewertet.
  12. Federation Spike ohne Build: drei Wiki-Kopien mit explizitem Scope; messen, ob ein einfacher Agentrouter genügt. Kein Routerprodukt implementieren.
  13. Git Hygiene: externes Git initialisieren, kanonische Sources/Wiki/Claims von Cache, Chats, Datenbanken und Secrets trennen; No-op-, Update-, Delete-, Konflikt- und Rollback-Diffs prüfen.

16.4 Messgrößen

Bereich Messung
Knowledge Quality blindes 1–5-Rubric für factual correctness, completeness, synthesis, uncertainty, non-duplication; Golden Set mit mindestens 30 Fragen/Fakten; zwei unabhängige Rater, vorab fixierte Ankerbeispiele und Inter-Rater-Agreement, bei < 0,7 verpflichtende Adjudikation
Struktur Pageanzahl, Duplikate, orphan/broken links, Navigationszeit, nachvollziehbare Conceptgrenzen
Provenance Anteil materieller Aussagen mit auflösbarer Evidence; genaue Source/Range/Version; korrekte Behandlung geteilter Sources
Retrieval Precision/Recall bzw. Answer correctness auf direkten, Cross-source-, Negativ- und Widerspruchsfragen; Faithful-/Source-only-Modus separat
Update-Verhalten richtige Page-/Claimänderungen, unrelated churn, Human-Edit-Erhalt, Stale/Unresolved/Retraction, No-op-Diff
Tokenverbrauch Input-/Outputtokens und Callzahl inklusive Review/Repair/Merge aus gemeinsamen vLLM-/OpenAI-Gatewaylogs mit Request-IDs; Cached Tokens nur werten, wenn der Provider sie tatsächlich ausweist; appinterne Zeichenzähler gelten nicht als Tokens
Laufzeit Wall-clock je Szenario; No-op separat
Bedienbarkeit reproduzierbarer CLI-Run, klare Exit Codes/Logs, Wiederanlauf nach Fehler, keine manuelle GUI-Pflicht für Primärpfad
Wartbarkeit benötigte Konfiguration; Upgrade-/Pinning-Aufwand; Abhängigkeiten und Lizenzgrenzen. Gap-Größe nur als reviewte Designschätzung aus Interfaces, Datenfluss, betroffenen Dateien, LOC-Band und Risiken — nicht durch Vorabimplementierung.

16.5 Messbare Exit Criteria

Jeder Kandidat darf nur adoptiert werden, wenn alle gemeinsamen Hard Gates erfüllt sind. OpenWiki bleibt wegen des Codeaudits der Primärkandidat; llm_wiki ist zunächst Benchmark und muss dieselben Gates bestehen, um selbst Basisoption zu werden.

Exit Criterion Schwelle
Factuality / Coverage ≥ 85 % Golden-Set-Antworten korrekt und ausreichend; blindes Gesamturteil ≥ 4,0/5
Kritische Halluzinationen 0 kritische unsupported facts in drei Wiederholungen
OKF / Portabilität 0 Fehler gegen gepinnte OKF-0.2- und WiWoW-Profilchecks; normale Markdownlinks; reproduzierbares Bundle ohne Producer-Runtime. Für llm_wiki ist ein natives Fail zu erwarten und als konkreter Adaptergap zu schätzen.
Provenance ≥ 90 % materieller Tatsachenaussagen mit maschinell auflösbarer Evidence; 100 % der kritischen Aussagen
Cross-source Synthesis alle definierten Cross-source-Fälle enthalten die wesentlichen Fakten und Sources
Contradiction 100 % der eingebauten Widersprüche sichtbar erhalten/markiert; keine stille Ersetzung
Correction/Revocation 100 % der Testkorrekturen aktualisiert; veraltete sole-source Claims entfernt/stale/unresolved statt weiter als verifiziert
Human Curation 100 % der eingebauten menschlichen Korrekturen bleiben erhalten oder der Run stoppt vor Datenverlust mit klarer Diagnose
No-op 0 LLM-Calls, 0 Knowledge-Diff, ≤ 60 Sekunden
Incrementalität Update-Token ≤ 35 % des Cold-Init-Verbrauchs; unrelated Page Churn ≤ 10 %
Laufzeit Cold Init ≤ 60 Minuten, einfacher Update ≤ 20 Minuten auf deklarierter PoC-Hardware
Lokalbetrieb 3/3 erfolgreiche relevante Läufe über vLLM/OpenAI-compatible, kein obligatorischer Cloud-Egress
Operabilität unbeaufsichtigter CLI/CI-Lauf mit deterministischem Exit Code, Git-Diff und wiederholbarem Setup
Git Hygiene nur freigegebene Sources, Markdown, Claims und notwendige Metadaten versioniert; 0 Secrets/volatile DBs; sauberer No-op-Diff; verständliche Update-/Delete-Diffs; Konflikt und Rollback ohne Wissensverlust
Gap-Größe zwingende Ergänzung nach unabhängigem Designreview plausibel ≤ 5 Engineering-Tage und ≤ 1.000 eigene produktive LOC; kein Fork nötig

Ein Hard-Gate gilt als gescheitert, wenn derselbe kritische Fehler in mindestens zwei von drei Wiederholungen auftritt oder Daten still verloren gehen. Ein besonders guter Vector-/Graph-Score kompensiert kein Provenienz-, Human-Edit- oder On-Prem-Fail.

16.6 Auswahlregel zwischen OpenWiki und llm_wiki

  • Besteht OpenWiki alle Gates: OpenWiki adoptieren.
  • llm_wiki wird nur bevorzugt, wenn seine Retrieval-Answer-Correctness mindestens 15 % relativ höher ist, sein blindes Knowledge-Quality-Rubric höchstens 0,2 Punkte schlechter ausfällt und OKF, Claims, Git sowie Headless-Betrieb zusammen innerhalb derselben kleinen, unabhängig reviewten Gap-Schwelle erreichbar sind. Nach Codeaudit ist das unwahrscheinlich, aber der PoC bleibt ergebnisoffen.
  • Scheitern beide: Requirement und externe Ergänzung prüfen. Keine automatische Genehmigung für WiWoW-Fortsetzung.

17. Backlog Consequences für Epic 4+

Die Statuswerte beziehen sich auf die empfohlene Option F. Vor Abschluss des PoC wird keine Story umgesetzt.

Story Entscheidung Neue Bedeutung / Begründung
4.1 Information klassifizieren REPLACE OpenWiki-add/confirm/update/retract plus stale/unresolved übernehmen. Nur ein kleines contested-/Correction-Policy-Delta spezifizieren, wenn der Widerspruchstest scheitert. Kein neuer WiWoW-Klassifikationscompiler.
4.2 Disagreements in log.md SIMPLIFY Nur fachliche unresolved disagreements und menschliche Entscheidungen protokollieren. Build-/Story-/Sandboxhistorie bleibt außerhalb des Knowledge Bundles. Kein Root-Lease-gebundenes 179-KB-Auditlog.
4.3 Menschliche Kuratierung respektieren KEEP Als engine-neutrales Hard-Gate und Regressionstest behalten. Implementierung primär über OpenWiki-Verhalten/Upstream-Hook; kein eigener Authoring-Stack.
4.4 Machine vs. Human Trust/Lifecycle MODIFY OpenWiki-generated, verified, status, stale_after wiederverwenden. Nur portable Human-Review-/Expiry-Semantik ergänzen, die der PoC als fehlend belegt. Keine parallele Trustsprache.
5.1 Git-Diffs und Commit Boundary REPLACE OpenWiki-Git-Diff, No-op und CI-/PR-Workflow übernehmen. WiWoW-Lease-/Receipt-/Commitmechanik entfernen; nur Akzeptanztest für saubere Diffs behalten.
5.2 Tool-unabhängiger Zugriff KEEP Als unverhandelbare Produktinvariante/Abnahmetest behalten. OpenWiki-Markdown/OKF erfüllt sie grundsätzlich; kein eigener Implementierungs-Epic nötig.
5.3 Agent-unabhängiger Vertrag / Adapter REPLACE OpenWikis Providerabstraktion sowie Codex-/Claude-Lifecycle-MCP nutzen. vLLM als PoC-Gate. Eigene Compileradapter entfallen.

17.1 Welche Epics entfallen?

  • Epic 5 entfällt vollständig als Implementierungs-Epic. Seine gewünschten Ergebnisse werden Upstream-Fähigkeiten, Konfiguration und drei Abnahmetests: Git-Diff, plain Markdown clone/read, lokaler Agentlauf.
  • Epic 4 schrumpft von vier Engine-Stories auf einen kleinen, engine-neutralen Policy-/Acceptance-Track. Story 4.3 bleibt zwingender Test; 4.1/4.2/4.4 werden nur bei nachgewiesenem Gap umgesetzt.
  • Die vorhandenen Epics 1–3 bleiben historische Evidenz, werden aber nicht als Grundlage einer weiteren Compilerroadmap fortgeschrieben.
  • Neue Epics für Ingestion, Chunking, Vector Search, KG, Provider, API/MCP oder Git-Automation sind ausdrücklich REMOVE/NOT REQUIRED, weil Standardlösungen diese Flächen abdecken.

17.2 Reihenfolge nach menschlicher Entscheidung

  1. PoC-Epic mit Messplan und fixierten Revisionen.
  2. Adopt-/Reject-Gate anhand der Exit Criteria.
  3. OpenWiki-Betriebs-/Upgrade-Story, falls bestanden.
  4. Nur fehlgeschlagene Hard-Gates als kleine einzelne Stories.
  5. Federation-Discovery erst bei mindestens drei realen Wikis und Cross-Wiki-Golden-Set.

18. Final Decision

Executive Recommendation

WiWoW nicht wie geplant weiterentwickeln. OpenWiki als Basis adoptieren, die aktuelle Compilerarchitektur stoppen und den Umstieg mit einem kleinen vergleichenden PoC absichern. llm_wiki bleibt der starke Benchmark für Commodity-Ingestion und Retrieval sowie eine Alternative, falls diese Fähigkeiten wichtiger werden als OKF/Claims/Git.

Warum diese Entscheidung belastbar ist

  • Die Kernhypothese „persistentes Markdownwissen“ bleibt richtig; die Zusatzhypothese „dafür braucht es unseren Compiler“ ist widerlegt bzw. unbewiesen.
  • Epic 3 hat mechanische Determinismuskomplexität maximiert, aber CREATE/Synthese und Knowledge Quality nicht belastbar verifiziert.
  • OpenWiki operationalisiert bereits die engste Muss-Schnittmenge und hat eine permissive Lizenz.
  • llm_wiki zeigt, wie viel der geplanten Ingestion-/Retrievalfläche Commodity geworden ist.
  • Kein nachweisbarer WiWoW-Differentiator erfordert eine eigene End-to-End-Engine.
  • Federation ist ein dünner separierbarer Layer und bisher nicht einmal ein WiWoW-Requirement.
  • Die Empfehlung bleibt auch ohne Federationgewicht stabil.

Klare Handlungsentscheidung

ADOPT

  • Stop: aktueller WiWoW-Compiler, Lease-/Receipt-/Byte-Determinismusroadmap.
  • Adopt: OpenWiki, revision-pinned und PoC-gated.
  • Retain: Requirements/Evals für Portabilität, Provenienz, Human Curation und Lifecycle.
  • Build only if proven: externer Validator, Evidence Adapter oder dünner Federation Router.
  • Do not fork by default.

Appendix A — Untersuchte WiWoW-Artefakte

Appendix B — Reproduzierbarkeit externer Befunde

Reference in New Issue View Git Blame Copy Permalink