wow20/BUILD-VS-ADOPT-DECISION-REPORT-2026-08-24.md

# 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`](https://github.com/langchain-ai/openwiki/commit/6ffa7b6debaed25422398c73ccc4d21ad1438795), 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`](https://github.com/nashsu/llm_wiki/commit/889789c3218e8c7844e8515d5429a4e53b96fc19), 21.08.2026 | Aktueller veröffentlichter Stand und Code, nicht Roadmap/Marketing |
| OKF | kanonisches Repository [`GoogleCloudPlatform/open-knowledge-format`](https://github.com/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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/.changeset/adopt-okf-v0-2.md#L1-L5), [Grounded Claims](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/.changeset/free-pens-win.md#L1-L5) und [Agent-Integration](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/.changeset/bright-hosts-connect.md#L1-L5). 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](./_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/prd.md) Z. 14–51 und [SPEC](./_bmad-output/specs/spec-wow20/SPEC.md) 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](./_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/review-adversarial.md) Z. 13–17.

### 2.3 Architectural Goals und ADRs

Die ADRs sind als AD-1 bis AD-17 in den [Architecture Spine](./_bmad-output/planning-artifacts/architecture/architecture-wow20-2026-08-14/ARCHITECTURE-SPINE.md) 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`](./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`](./schema/validator.md) ist ebenfalls eine textuelle Prüfinstruktion, kein deterministischer Validator.
- [`schema/wiki-compiler.md`](./schema/wiki-compiler.md) ist ein Markdown-Vertrag.
- [`adapters/claude/README.md`](./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`](./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`](./schema/compiler.md), Z. 426–439), dominiert aber aktuell [`wiki/log.md`](./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](./_bmad-output/implementation-artifacts/review-input-dryrun-2-1-pdf-radium.md), 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](./_bmad-output/implementation-artifacts/epic-3-retro-2026-08-24.md) 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`](./_bmad-output/implementation-artifacts/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](./_bmad-output/implementation-artifacts/epic-3-retro-2026-08-24.md), 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:

```text
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`](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/agent/index.ts#L161-L347); der Agentgraph in [`src/agent/index.ts`](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/agent/index.ts#L533-L634). Schreibzugriffe bleiben unter `openwiki/`, Claims-Sidecars sind vor generischen Agenttools verborgen und `.openwikiignore` begrenzt Lesezugriffe ([Backend-Grenzen](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/agent/docs-only-backend.ts#L141-L158)).

**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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/okf/index-sync.ts#L233-L249)). |
| 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/agent/prompts/code.ts#L64-L89)). |
| 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/claims/core/types.ts#L1-L34), [Mutationen](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/claims/core/mutations.ts#L39-L128)). 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/claims/evidence/repository/resolver.ts#L182-L247), [Relokation](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/claims/evidence/repository/resolver.ts#L287-L334)). |
| 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/okf/generated-provenance.ts#L60-L120)). |
| Trust / `verified` | **IMPLEMENTED**, eng | Machine-Event nach erfolgreicher Claim-Reconciliation und finalem Evidenzcheck; Human-/Process-Events werden erhalten ([Eligibility](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/claims/brains/code/session.ts#L456-L491)). 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/okf/frontmatter.ts#L183-L252)). |
| 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/ingestion/ingestion.ts#L65-L105), [Source Run](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/ingestion/ingestion.ts#L124-L208)). |
| Source Handling | **IMPLEMENTED** | Custom MCP, Git Repo, Gmail, Hacker News, LangSmith, Notion, Slack, Web Search und X sind registriert ([Registry](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/connectors/registry.ts#L12-L55)). 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/agent/utils.ts#L95-L180)). Git-Diff-zu-Page-Plan bleibt agentisch. |
| Claim Change Detection | **IMPLEMENTED** | Preflight löst Evidence neu auf und klassifiziert `stale`/`unresolved` ([Preflight](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/claims/brains/code/preflight.ts#L34-L108)); 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/visualize/graph.ts#L37-L129)); 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/agent/wiki-qa-subagents.ts#L4-L71)); 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/integrations/core/protocol.ts#L9-L96)); 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/config/constants.ts#L102-L115)). |
| OpenAI-compatible | **IMPLEMENTED** | beliebige HTTP(S)-Base-URL; Chat Completions standardmäßig, Responses und Streaming optional ([Konfiguration](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/config/constants.ts#L352-L358), [Modelbau](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/src/agent/index.ts#L1459-L1479)). |
| 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/examples/openwiki-update.yml#L17-L62). |
| 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](https://github.com/langchain-ai/openwiki/blob/6ffa7b6debaed25422398c73ccc4d21ad1438795/LICENSE#L1-L20)).
- **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:

```text
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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/README.md#L55-L80), [Dateiformat](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/README.md#L469-L490)). Das generische Frontmattermodell kennt nur <code>string &#124; string[]</code>. |
| OKF | **MISSING** | Kein Code-/Doku-Treffer für OKF; unterstützte OKF-Version: **keine**. `schema.md` steuert nur Type→Directory-Routing ([Schema Parser](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/wiki-schema.ts#L12-L92)). |
| Concepts | **IMPLEMENTED** | Page Types `source`, `entity`, `concept`, `comparison`, `query`, `synthesis`, `thesis`, `methodology`, `finding` ([Typen](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/wiki-page-types.ts#L1-L23)). |
| 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/sources-merge.ts#L1-L21), [Persistenz](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/sources-merge.ts#L187-L212)). 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/templates.ts#L69-L135)). |
| 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/ingest.ts#L1020-L1106)); optionaler dritter Reviewcall ([Review](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/ingest.ts#L1114-L1159)) 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/text-chunker.ts#L1-L89)); Checkpoints und Konsolidierung für lange Sources. |
| Cache | **IMPLEMENTED** | SHA-256-Skip plus Prüfung, ob erwartete Outputs weiter existieren ([Ingest Cache](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/ingest-cache.ts#L1-L29), [Cache Logic](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/ingest-cache.ts#L55-L151)). |
| 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/page-merge.ts#L94-L200)). 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src-tauri/src/commands/file_sync.rs#L19-L105)). |
| 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/stores/review-store.ts#L4-L102)). 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src-tauri/src/agent/types.rs#L18-L35), [Runtime](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src-tauri/src/agent/runtime.rs#L2923-L2969)). 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src-tauri/src/commands/search.rs#L327-L519)). |
| Vector Search | **IMPLEMENTED** | lokales chunk-level LanceDB v2; replace-by-page; frei konfigurierbarer OpenAI-kompatibler Embedding-Endpunkt ([Vector Store](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src-tauri/src/commands/vectorstore.rs#L349-L376)). |
| Knowledge Graph | **IMPLEMENTED**, heuristisch | aus Markdown-Wikilinks und Source-Overlap; Relevanz aus direct link, Source-Overlap, Adamic-Adar und Type Affinity ([Graph Relevance](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/graph-relevance.ts#L247-L286)). Kein RDF-/Ontologie-/Claimgraph. |
| Community Detection | **IMPLEMENTED** | reale Graphology-Louvain-Ausführung ([Analyse](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/wiki-graph-analysis.ts#L1-L76)). |
| Knowledge-Gap Detection | **IMPLEMENTED**, heuristisch | degree ≤ 1, Community Cohesion < 0,15 und Bridges über ≥ 3 Communities ([Insights](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/graph-insights.ts#L108-L192)). 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src-tauri/src/api_server.rs#L285-L370)). |
| MCP | **IMPLEMENTED**, desktopgebunden | Status, Projects, Set Project, Files, Read, Reviews, Search, Chat, Graph, Rescan, Embed ([MCP Tools](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/mcp-server/src/index.ts#L29-L187)). Desktop-App muss laufen; kein headless Daemon. |
| Model Provider | **IMPLEMENTED** | OpenAI, Anthropic, Google, Azure, Ollama, Custom, MiniMax und lokale CLI-Provider ([Store](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/stores/wiki-store.ts#L12-L52)). |
| 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/llm-providers.ts#L1052-L1113)); 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/llm-wiki.md#L62-L75)). 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/src/lib/wiki-graph.ts#L36-L40)); 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/mcp-server/src/project-binding.ts#L3-L37)). |

### 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](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/.github/workflows/ci.yml#L1-L62)). 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](https://github.com/nashsu/llm_wiki/releases)). Der lokale Clone war shallow; Contributorverteilung/Bus-Faktor wurde daher nicht belastbar bestimmt.
- **Lizenz:** GPL v3 laut Root-Lizenz und README ([LICENSE](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/LICENSE#L1-L4)); die genaue SPDX-Variante ist nicht eindeutig deklariert. Das MCP-Unterpaket deklariert MIT ([package.json](https://github.com/nashsu/llm_wiki/blob/889789c3218e8c7844e8515d5429a4e53b96fc19/mcp-server/package.json#L1-L24)), 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:

```mermaid
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

```text
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

```mermaid
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

```text
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

- [PRD](./_bmad-output/planning-artifacts/prds/prd-wow20-2026-08-14/prd.md) und adversarial Review
- [SPEC](./_bmad-output/specs/spec-wow20/SPEC.md)
- [Architecture Spine / AD-1–17](./_bmad-output/planning-artifacts/architecture/architecture-wow20-2026-08-14/ARCHITECTURE-SPINE.md)
- [Epics und Stories](./_bmad-output/planning-artifacts/epics.md)
- Epic-1/2/3-Contexts; kein allgemeines `project-context.md` vorhanden
- [Compilervertrag](./schema/compiler.md), [Validatorvertrag](./schema/validator.md), [Wiki-Compiler-Schema](./schema/wiki-compiler.md), Canonical Terms
- Claude-Adapterplatzhalter und alle Sandbox-/Gate-Harnesses
- aktuelle Sources unter `raw/`, Concepts, Indizes und `wiki/log.md`
- Epic-1-, Epic-2- und [Epic-3-Retrospektive](./_bmad-output/implementation-artifacts/epic-3-retro-2026-08-24.md)
- Deferred Work, Sprintstatus, Story-Specs und Dry-Run-Berichte

## Appendix B — Reproduzierbarkeit externer Befunde

- OpenWiki: [`langchain-ai/openwiki`](https://github.com/langchain-ai/openwiki), Commit [`6ffa7b6debaed25422398c73ccc4d21ad1438795`](https://github.com/langchain-ai/openwiki/commit/6ffa7b6debaed25422398c73ccc4d21ad1438795), MIT.
- `llm_wiki`: [`nashsu/llm_wiki`](https://github.com/nashsu/llm_wiki), Commit [`889789c3218e8c7844e8515d5429a4e53b96fc19`](https://github.com/nashsu/llm_wiki/commit/889789c3218e8c7844e8515d5429a4e53b96fc19), GPL-3.0.
- OKF: [`GoogleCloudPlatform/open-knowledge-format`](https://github.com/GoogleCloudPlatform/open-knowledge-format), Version 0.2 als untersuchte kanonische Spezifikation.