Erst prüfen, dann sichtbar

Ein Agent hat eine gute Quelle gefunden, einen präzisen Claim formuliert und das wörtliche Zitat korrekt angegeben. Trotzdem ist die Änderung noch kein sichtbares Wissen. Der Vorschlag liegt als eigener, prüfbarer Zustand vor, und das System behandelt ihn genau so: als Kandidaten, dessen Übernahme eine bewusste menschliche Entscheidung verlangt. WikiKit bildet diese Trennung technisch ab.

Jede Wissensänderung endet zunächst in einem ChangeProposal – einem Änderungsvorschlag als dauerhaftem Datensatz, nicht als flüchtige Chat-Antwort. Leser sehen weiterhin die aktuell freigegebene Revision. Erst prüft ein Mensch den Vorschlag und entscheidet. Dabei prüft WikiKit Zustand und Ausgangsrevision und wendet den Änderungssatz atomar an.

Der Änderungsvorschlag ist ein dauerhafter Zustand

Ein Vorschlag besteht nicht aus einem Textdiff in einer temporären Datei, die nach der Session verschwindet. WikiKit archiviert Quellen unverändert, erzeugt daraus belegte Claims und hält jede Änderung als ChangeProposal fest. Dieser Datensatz bleibt vorhanden, adressierbar und prüfbar, bis ein Mensch entscheidet. Für Leser bleibt er bis zu dieser Prüfung unsichtbar.

flowchart LR
    S["Quelle oder Agent<br/>schlägt Änderung vor"] --> P["ChangeProposal<br/>dauerhafter Änderungsvorschlag"]
    P --> R{"menschliches<br/>Review"}
    R -->|approve| A["atomare Anwendung von Revision,<br/>Claims, Beziehungen, Entscheidungen,<br/>Space-Epoche und Webhook-Ereignissen"]
    R -->|reject| H["abgelehnt<br/>in Historie erhalten"]

Der Unterschied zu einem Entwurfsabsatz in derselben Wiki-Seite ist wesentlich. Ein Leser kann nie versehentlich die halbe neue Aussage finden: Normale Leseabfragen liefern den Vorschlag nicht aus, Review-Abfragen machen ihn prüfbar.

Diese Trennung lässt sich außerdem prüfen. Nach dem Einreichen darf der Vorschlag in normalen Leseabfragen nicht auftauchen; nach der Freigabe muss die daraus entstandene Revision dort sichtbar sein.

Ein Vorschlag trägt einen zusammenhängenden Änderungssatz

Ein Meeting kann eine bestehende Konzept-Seite verändern, einen neuen Claim hinzufügen und eine Entscheidung erzeugen. Drei unabhängige Vorschläge würden diesen Zusammenhang verlieren. Ein ChangeProposal trägt zusammengehörige Änderungen deshalb als einen Änderungssatz. Das folgende JSON ist ein vereinfachtes, illustratives Modell, kein dokumentierter API-Vertrag:

{
  "title": "Retry policy meeting",
  "summary": "Update retry budget and record the decision.",
  "source_ids": ["source_meeting_42"],
  "concepts": [
    {
      "slug": "retry-policy",
      "base_revision_id": "rev_3",
      "claims": 1
    }
  ],
  "decisions": [
    {
      "slug": "shared-retry-budget"
    }
  ]
}

Die prüfende Person sieht damit, dass Seitentext, Claim und Entscheidung auf dieselbe Quelle zurückgehen, und entscheidet über den Änderungssatz als Ganzes. Einen halb angewendeten Zustand – etwa eine sichtbare Entscheidung neben einer Konzept-Seite auf altem Stand – schließt die atomare Anwendung aus.

Wenn nur ein Teil richtig ist, wird der Vorschlag abgelehnt oder überarbeitet und neu eingereicht. Das klingt strenger als ein Inline-Edit, hält aber die freigegebene Revision konsistent.

Die Ausgangsrevision schützt vor verlorenen Änderungen

Zwischen Vorschlag und Review kann jemand anderes dasselbe Konzept freigeben. Der ältere Vorschlag basiert dann auf einem Stand, der nicht mehr aktuell ist. Ein blindes Apply würde die neuere Änderung überschreiben oder unbeabsichtigt zurücknehmen – still und ohne dass es jemand bemerkt.

Jede vorgeschlagene Revision bindet sich deshalb an ihre Ausgangsrevision. Bei der Freigabe vergleicht WikiKit sie mit der aktuellen Revision. Stimmen die Werte nicht überein, ist die Ausgangsbasis veraltet, und die Freigabe schlägt fehl, statt einen neueren Wissensstand still zu überschreiben. Als vereinfachtes Modell, nicht als Ausschnitt aus dem Repository:

function assertCurrentBase(proposedBase: string, currentRevision: string): void {
  if (proposedBase !== currentRevision) {
    throw new Error("stale proposal base revision");
  }
}

Der Fehler verlangt kein Raten. Nach einem Stale-Base-Konflikt muss außerhalb der fehlgeschlagenen Freigabe entschieden werden, ob die Änderung gegen die neue Basis neu erzeugt oder fachlich zusammengeführt wird.

Dieses Muster entspricht Optimistic Concurrency Control. Es hält den normalen Weg leichtgewichtig und erkennt den Konflikt genau beim Schreiben. Eine Sperre über die gesamte menschliche Reviewzeit – Stunden oder Tage – wäre unpraktisch.

Freigabe ist eine atomare Transaktion

Nach allen Prüfungen wendet WikiKit den Vorschlag in einer SQL-Transaktion an. Neue Revision, sichtbare Claims, Beziehungen, Entscheidungen, die Space-Epoche und die Webhook-Ereignisse wechseln gemeinsam. Scheitert ein Teil, bleibt der vorherige sichtbare Stand vollständig erhalten. Diese Zusammensetzung entspricht dem am 18. August 2026 geprüften Stand des Repositorys.

Als vereinfachte Skizze, nicht als tatsächliche Implementierung:

BEGIN;
-- verify proposal state and base revisions
-- activate staged concept revisions and claims
-- record reviewer, note, and timestamp
-- mark proposal approved
COMMIT;

Entscheidend ist das beobachtbare Ergebnis: Leser sehen vor dem Commit die alte vollständige Revision und danach die neue vollständige Revision. Einen Zwischenzustand mit halb angewendeten Claims gibt es nicht.

Auch die Webhook-Ereignisse entstehen in derselben Transaktion wie die übrigen Änderungen. Ein Freigabe-Ereignis kann damit nicht committet sein, während die zugehörige Revision fehlt – und umgekehrt.

Die Freigabegrenze ist keine Prompt-Anweisung

Eine Instruktion wie „Agenten dürfen nicht freigeben“ ist leicht zu übersehen – vom Agenten wie vom Menschen, der ihn konfiguriert. Die Trennung liegt deshalb im System, nicht im Prompt: Ein Agent darf Wissen vorschlagen und seine Einordnung begründen, den Änderungssatz kann er jedoch nicht selbst freigeben. Ein Agentenschlüssel mit knowledge:review kann keine Freigabe über die HTTP-Schnittstelle ausführen; die Entscheidung wird in der nativen Review-Form von einem Menschen getroffen. Erst diese bewusste Entscheidung wendet den Änderungssatz an.

Ein versteckter alternativer Schreibweg, der die Prüfung umgeht, würde dieses Modell entwerten. Deshalb führen Cockpit, HTTP und MCP in dieselbe Wissensdomäne und an dieselbe atomare Freigabegrenze.

Cockpit, HTTP und MCP führen zur selben Freigabegrenze

WikiKit ist headless in dem Sinn, dass die Wissens- und Review-Funktionen über API und MCP erreichbar sind – nicht in dem Sinn, dass es keine Oberfläche für Menschen gäbe. Das eingebaute Cockpit ist die menschliche Weboberfläche der Wissensdomäne. Dort prüft eine Person den offenen Änderungsvorschlag und trifft die Entscheidung.

Cockpit, HTTP und MCP enden an derselben Produktgrenze: Der ChangeProposal bleibt für Leser unsichtbar, bis ein Mensch ihn freigibt. Die Freigabe wendet Revision, Claims, Beziehungen, Entscheidungen, Space-Epoche und Webhook-Ereignisse gemeinsam in einer atomaren Transaktion an.

Was vor der Freigabe geprüft wird

Für die Freigabe müssen mindestens Quelle, Claim, Geltungsbereich und Diff geprüft werden: Trägt die archivierte Quelle die Aussage tatsächlich, ist der Claim enger oder weiter gefasst als sein Zitat, und passt die Änderung zur aktuellen Ausgangsrevision? Diese Checkliste ist redaktionell. Technisch erzwingt WikiKit außerdem die beschriebenen Zustands- und Basisprüfungen sowie die menschliche Entscheidung vor der Sichtbarkeit.

Bei einer Ablehnung hilft ein konkreter Hinweis wie „die Quelle deckt nur den Legacy-Client ab; das Subjekt enger fassen“ mehr als ein bloßes „falsch“. Ein abgelehnter Vorschlag wird kein sichtbares Wissen; der nächste Vorschlag kann aus dem Fehler lernen, ohne dass die Ablehnung selbst zu einem Claim wird.

Doppelte Freigaben scheitern

Netzwerkfehler sind gerade beim Approve heikel. Der Client kann die Verbindung verlieren, obwohl der Server bereits committed hat, und ein unbedachter Retry darf keine zweite Revision erzeugen. Zusätzlich zur Prüfung der Ausgangsrevision verhindert der bereits entschiedene Vorschlagsstatus eine zweite Anwendung. Eine bereits getroffene Entscheidung wird durch einen wiederholten Aufruf nicht dupliziert; der zweite Versuch endet in einem Fehler statt in einer zweiten Anwendung.

Review-Fehler bleiben begrenzt

Menschliche Freigabe garantiert keine fehlerfreie Aussage. Sie macht Verantwortung und Korrekturweg sichtbar. Wird ein falscher Claim später entdeckt, entsteht ein neuer Vorschlag, der ihn bestreitet, enger fasst oder stilllegt – und der wieder durch dieselbe Prüfung läuft. Der aktuelle Stand wird nicht heimlich rückdatiert.

Die Freigabeschranke verhindert keine fachlichen Fehlentscheidungen. Sie ist ein kontrollierter Übergang, an dem Fehler erkannt, begrenzt und später korrigiert werden können.

Eine wachsende Warteschlange ist ein Prozessproblem

Eine Freigabeschranke kann zum Ablageort werden, wenn niemand offene Vorschläge prüft. Eine wachsende Warteschlange kann auf zu viele belanglose Einreichungen, fehlende Zuständigkeit oder zu groß geschnittene Vorschläge hinweisen. Ein Grund für automatische Freigaben ist sie nicht. Die passende Korrektur liegt im Prozess: Auswahl enger machen, Zuständigkeit klären, Vorschläge kleiner schneiden oder feste Reviewzeiten einplanen. Die technische Schranke bleibt bestehen.

Die Kosten der Freigabeschranke

Review fügt Reibung hinzu. Die Freigabe erhöht die Wartezeit, verhindert aber, dass ein Agentenvorschlag ohne menschliche Entscheidung sichtbar wird. Der schnelle Weg bleibt schnell: Quellen einreichen, suchen und Vorschläge erzeugen. Nur der Übergang zu gemeinsam geltendem Wissen verlangt eine Entscheidung – von einem Menschen.

Für kleine Teams kann dieselbe Person Quelle und Vorschlag prüfen. Ein zusätzliches Vier-Augen-Prinzip lässt sich für sensible Domains außerhalb dieser technischen Freigabegrenze organisieren. WikiKit liefert dafür den dauerhaften ChangeProposal, die Bindung an die Ausgangsrevision und die atomare Freigabe; die genaue Governance bleibt beim Space.

Das Review garantiert keine Qualität und ist dennoch kein optionaler Prozessschritt. Deshalb bleibt die Freigabe beim Menschen: Agenten dürfen den ChangeProposal nur bis an diese Grenze führen.

Weiterführende Quellen

• WikiKit auf GitHub
• WikiKit README, Stand 18. August 2026
• WikiKit Architektur, Stand 18. August 2026
• PostgreSQL Transaction Isolation
• Wissen, das die Session überlebt

Wie fandest du diesen Beitrag?

Kommentare