Wiki-Layer

Der Wiki-Layer ist eine destillierte, LLM-gepflegte Wissensbasis über dem Suchindex — nach dem „LLM Wiki”-Muster von Andrej Karpathy : Statt bei jeder Anfrage Rohdokumente zu durchsuchen, pflegt ein AI-Agent kontinuierlich verlinkte Markdown-Seiten, die mit jeder Ingestion besser werden.

Das Format ist konform zum Open Knowledge Format (OKF v0.1) von Google (knowledge-catalog ) — Wikis sind damit als OKF-Bundles austauschbar. Die ProcessCube-Erweiterung darüber hinaus: deterministische Drift-Erkennung über Quellen-Provenienz.

Architektur

Die Arbeitsteilung ist strikt: Das SDK/die CLI macht die deterministische Buchhaltung (Ingest-Queue, Lint, Chronik, Rendering), ein AI-Agent macht die Destillation der Inhalte. Das SDK macht keine LLM-Calls.

Aufbau eines Wikis

Ein Wiki ist ein Ordner mit Markdown-Dateien — bewusst simpel und Obsidian-kompatibel:


wiki/
  KNOWLEDGE.md            # Schema: Konventionen und Workflows (type: Schema)
  index.md                # Inhaltsverzeichnis, deklariert okf_version: "0.1"
  log.md                  # Chronik: OKF-Datums-Gruppen, neueste zuerst
  <thema>/<seite>.md      # destillierte Konzept-Seiten

Jede Seite trägt Frontmatter mit dem OKF-Pflichtfeld type und der Quellen-Provenienz:


---
type: Concept
title: Timer-Events
description: Zeitgesteuerte Prozess-Starts in der Engine
timestamp: 2026-07-17T12:00:00Z
sources:
  - id: "docs:/abs/pfad/timer.md"     # Dokument-ID im Suchindex
    contentHash: "ab12…"              # Stand der Quelle bei Destillation
---
 
# Timer-Events
 
Destillat. Querverweise als [[engine/deployment]] oder als
OKF-Markdown-Link: [Deployment](/engine/deployment.md).

Der contentHash ist der Schlüssel zur Drift-Erkennung: Weicht der Hash der Rohquelle im Index vom Hash im Frontmatter ab, ist die Seite potenziell veraltet — deterministisch feststellbar, ohne LLM. Drift ist der wichtigste Fehlermodus LLM-gepflegter Wissensbasen.

Die drei Operationen

Operation	Werkzeug	Was passiert
Ingest	`wiki status` → Agent → `wiki lint`	Neue/geänderte Quellen destillieren, Provenienz-Hashes nachziehen
Query	`search --layer wiki`	Destillierte Seiten zuerst; gute Antworten fließen als neue Seiten zurück
Lint	`wiki lint` (CI/Cron)	Kaputte Links, Waisen, fehlender `type`, veraltete Quellen — Exit 1 bei Befunden

SDK-API


import { openWiki, buildWikiPagesPayload } from '@processcube-io/knowledge-sdk/wiki';
 
const wiki = openWiki('./wiki');
wiki.init();                        // Templates anlegen (idempotent)
wiki.status(store);                 // Ingest-Queue: [{id, state: 'new'|'changed', pages}]
wiki.lint(store);                   // LintFinding[] (broken-link, orphan-page, missing-type, stale-source, …)
wiki.upsertPage('engine/timer', frontmatter, body);
wiki.appendLog('ingest: timer destilliert');
 
// JSON-Payloads für UIs (gleiche Daten wie GET /api/wiki/*)
buildWikiPagesPayload(wiki, { docs: store });

Server: Browser-UI und JSON-API

pc knowledge serve --ui (bzw. der Standalone-/Docker-Server mit WIKI_DIR) liefert:

Route	Zweck
`GET /wiki`, `/wiki/p/<pfad>`, `/wiki/log`	Server-gerenderter Wiki-Browser (Sidebar, Provenienz-Fußzeile mit aktuell/veraltet-Badges, Suche)
`GET /api/wiki/pages`	Seitenliste mit `type`, `docId`, Stale-/Orphan-Markern
`GET /api/wiki/page?path=&linkBase=`	Seite mit Frontmatter, Markdown und gerendertem HTML
`GET /api/wiki/status`	Ingest-Queue + Lint-Befunde

Für React-Apps konsumiert die Komponente WikiBrowser aus @processcube-io/knowledge-sdk-ui genau diese JSON-API.

MCP-Tools für Agenten

pc knowledge serve registriert bei konfiguriertem Wiki vier Pflege-Tools, mit denen auch remote laufende Agenten das Wiki pflegen: knowledge_wiki_get_page, knowledge_wiki_upsert_page (OKF-konform inkl. type und Provenienz), knowledge_wiki_append_log und knowledge_wiki_status.

Auth in drei Stufen

Ohne — Default, Server bindet an 127.0.0.1 (lokale Entwicklung).
Fixer API-Key — --api-key bzw. KNOWLEDGE_API_KEY (CLI) / QMD_API_KEY (Docker). Agenten nutzen Authorization: Bearer oder X-API-Key; im Browser genügt einmalig ?key=<key> — der Server setzt ein HttpOnly-Cookie.
Auth-Plugin — --auth-plugin <modul.mjs> lädt ein eigenes ServeAuthPlugin. Über redirect und setCookie im Ergebnis ist ein kompletter OIDC-Code-Flow abbildbar, z.B. gegen die ProcessCube Authority.

CLI-Referenz

Die vollständige Befehlsreferenz inklusive Agent-Workflows steht unter CLI → Knowledge-Befehle; die Agent-Anleitungen liefert pc skill install knowledge.