wow20/_bmad-output/planning-artifacts/architecture/architecture-wow20-2026-08-14/reviews/review-adversarial.md

---
name: Adversarial Review — ARCHITECTURE-SPINE.md (wiki-of-wikis-2026-08-14)
type: adversarial-review
adversary: independent
status: final
created: 2026-08-14
target:
  - ARCHITECTURE-SPINE.md
  - prd.md (prd-wow20-2026-08-14)
mandate: two mutually conformant units build incompatible systems
---

# Adversarial Review — Wiki of Wikis Architecture Spine

## 0. Auftrag & Methode

Dieser Review greift die Architektur grundsätzlich als Gegner an. Für jeden Finding wird
**ein Paar von Einheiten eine Ebene tiefer** konstruiert (zwei Producer, zwei Consumer,
Mensch vs. Agent), bei dem **jede Einheit jede AD buchstäblich befolgt** — und das Paar
dennoch inkompatible Systeme baut.

Der Spine verspricht in AD-17 ausdrücklich Schutz vor Last-Writer-Wins. Dieser Review zeigt,
dass der Schutz an mehreren Stellen konzeptionell verrutscht und durch neue oder
verschärfte Regeln geschlossen werden muss. Alle Findings nennen die beteiligten ADs und
die konkrete Close-Regel.

**Adversarial Verdict:** Der Spine beschreibt ein konsistentes Architektur-Layering,
aber er **pins keine der drei operativen Schnittstellen, an denen Producer und Producer
bzw. Producer und Consumer aufeinandertreffen**: (a) die Lease-/Koordinations-Semantik
(AD-17), (b) die Concept-ID-Normalisierung (AD-7) und (c) die Claim-Granularität der
Provenienz (AD-4/Q-1). Solange diese drei Unterspezifikationen bestehen, folgen zwei
konforme Einheiten garantiert mindestens einmal in einer von diesen Nachweisen zu
inkompatiblen Bundles.

---

## Findings

### F-1 [CRITICAL] — AD-17 definiert keinen Lease-Mechanismus; der Konflikt-Bewahrungsartefakt selbst (log.md) liegt außerhalb des Leases

**Beteiligte ADs:** AD-5, AD-6, AD-7, AD-14, AD-16, AD-17 (und deren Bind: NFR-7, FR-8, FFr-13)

**Konstruiertes Paar:**

- **Einheit 1**: Compiler-Run A (Claude-Adapter), Area `flowable/`. Liest AD-17 und realisiert
  „Lease auf dem eigenen Workspace" als Lock-Datei `.wofw/leases/flowable.lock` außerhalb von `wiki/`.
- **Einheit 2**: Compiler-Run B (Codex-Adapter) parallel, dieselbe Area. Realisiert „Lease"
  als Branch-Name `lease/flowable`. Auf einem zweiten Klon (FT-7 Portability erlaubt und
  fördert das).

Keine AD spezifiziert:

1. was ein Lease **ist** (Lockdatei? Branchname? Registry-Eintrag?),
2. wie Leases **klon-übergreifend** koordiniert werden (bei Local-First + Portability gibt es
   keinen gemeinsamen Koordinationszustand),
3. wie man ein Lease **atomar** erwirbt und wie Stale-Leases erkannt werden,
4. ob `log.md` / `index.md` an der Bundle-Wurzel **innerhalb oder außerhalb** eines
   area-skopierten Leases liegen.

Beide Einheiten mutieren `wiki/flowable/timers.md` mit unterschiedlichen Synthesen, committen
ihre Branches und führen nach main zusammen. Git auto-mergt getrennte Hunks textuell:
Die Datei enthält anschließend **beide** Synthesen ungeprüft nebeneinander — ein stiller
semantischer Merge. **Genau das verbietet AD-16** („Konflikte explizit erhalten, nie
stillschweigend auflösen"), aber die Verletzung entsteht durch den Koordinationsmechanismus
selbst, nicht durch Regelfolgefehler einer Einheit. Jede Einheit hat jede AD eingehalten.

Zusätzlich, und schärfer: Der einzige Ort, der einen Konflikt bewahren soll (`log.md`, AD-16
und AD-17 Rule 4), liegt an der Bundle-Wurzel und damit **außerhalb jedes area-skopierten
Leases**. Zwei Producer, die beide einen Konflikt dokumentieren, schreiben beide nach
`log.md` kandidierend — **on log.md itself herrscht Last-Writer-Wins**. Der
Konflikt-Bewahrungsmechanismus ist damit selbst die Stelle, an der Arbeit still
überschrieben wird.

**Close-Regeln (neu/verschärft):**

- **AD-17a (Lease-Vertrag):** AD-17 muss definieren, was ein Lease ist und wie er erworben
  wird — gegen einen **eindeutigen Commit-Objektwert** (Merge-Base-Disziplin) und über einen
  einzigen, deterministischen Mechanismus (z. B. Branch-Prefix-Konvention `lease/<area>/<id>`
  ergänzt um eine Lockdatei **semantisch identisch realisiert** in jedem Adapter; die
  Realisierung darf nicht pro Adapter frei wählbar sein).
- **AD-17b (Lease-Scope):** Das Lease muss ausdrücklich `wiki/` **inklusive `log.md`,
  `index.md` und aller Wurzel-Dateien** abdecken („Root-Scope"), sonst ist der
  Bewahrungsartefakt wehrlos.
- **AD-17c (Kein stiller Auto-Merge):** Zwei Branches, die denselben Concept-Pfad modifiziert
  haben, dürfen **nicht** per textuellem Git-Auto-Merge zusammengeführt werden. Die
  Zusammenführung ist Compiler-vermittelt und durchläuft die AD-16-Klassifikation — mit
  explizitem `log.md`-Eintrag, falls die Inhalte nicht identisch sind.
- **AD-17d (Lease-Held darf nicht committen „vergessen"):** Entweder Time-to-Live + Registrierung
  des Leases im Clon-Wurzelzustand oder Regel, dass unveröffentlichte Leases nach
  Run-Abbruch als stale gelten und `raw/` (immutable, AD-3) die Wiederherstellungsbasis ist.

---

### F-2 [CRITICAL] — AD-7 pinnt die Concept-ID nicht eindeutig: zwei Consumer/Producer rechnen denselben Baum auf zwei ID-Räume ab

**Beteiligte ADs:** AD-7, AD-8, AD-9, AD-14 (Renames als semantische Änderung), Bind FR-5/FR-6/FR-9–FR-12

**Konstruiertes Paar:**

- **Einheit 1** (Produzent, z. B. Codex-Adapter): schreibt einen Link als `[timers](flowable/timers)` —
  OKF-Stil, bundle-relativ, ohne `.md`, im Sinne der „Consistency Conventions — Concept identity:
  relativer OKF-Dateipfad **ohne** `.md`".
- **Einheit 2** (Produzent, z. B. Claude-Adapter): schreibt denselben Link als `[timers](flowable/timers.md)` —
  „normale Markdown-Links" (AD-8) mit Dateiendung.

Beide Links sind in Markdown gültig. Ob sie dieselbe Concept-ID bezeichnen, hängt von einer
Endungs-Normalisierung ab, die **nirgends** festgeschrieben ist:

1. **Endung:** `timers` vs `timers.md` — eine Einheit liest die ID mit, die andere ohne.
2. **`index.md`:** AD-9 zeigt `spring/index.md`. Ist dessen Concept-ID `spring`, `spring/index`
   oder `spring/`? Nicht beantwortet. Link-Traversierung bricht je nach Default verschieden.
3. **Case & Dateisystem:** `Timers.md` vs `timers.md` auf einem case-sensitiven System sind zwei
   Concept-IDs für dasselbe fachliche Wissen.
4. **Area-Zuordnung:** AD-7 definiert die ID als den Pfad, aber **nicht, wohin ein fachliches
   Thema gehört**. Producer A legt „Timers"-Wissen unter `flowable/timers` an, Producer B unter
   `spring/timers`. Beide erzeugen „eigenständige Konzeptwesen" (FR-5) — beide AD-konform, ein
   Duplikat. AD-5 schützt das vorhandene Konzept sogar („nur betroffene Concepts verändern"),
   verschärft also die Vervielfachung statt sie zu verhindern.
5. **Rename-Kaskade:** AD-7 erklärt Renames zu semantischen Änderungen — damit ist ein
   Umbenennen **erlaubt und erforderlich**, um die ID zu ändern, aber jede andere Einheit, die
   die alte ID gecacht hat (bewusst oder im Prompt-Kontext), aktualisiert sich nicht und
   referenziert ins Leere.

Beide Einheiten befolgen AD-7 buchstäblich und verwalten über denselben Baum **zwei
inkompatible ID-Räume**.

**Close-Regeln:**

- **AD-7a (ID-Normalisierung):** genau eine kanonische Form festschreiben, z. B.
  `Kleinbuchstaben`, Pfad relativ zur Bundleroot, ohne Endung, `index.md` → Area-Pfad,
  keine Trailendepunkte. Mit Beispieltabelle (`flowable/timers`, `spring`, `spring/testing`).
- **AD-7b (Link-Form):** AD-8 muss die eine erlaubte Linkform festlegen (bundle-relativ mit
  oder ohne Endung — eine davon, nicht beides).
- **AD-7c (Area-Zuordnung):** eine Zuordnungsregel für „wohin gehört ein Thema" ergänzen
  (Relevanzbestimmung ist AD-17-Anhang bereits auf textuelle Mittel festgelegt; dieselbe
  textuelle Determiniertheit muss auch die **Ziel-Area** determinieren, z. B. via
  bestehendem `index.md`-Link oder Toplevel-Kollision-Halten an bestehenden Pfaden).
- **AD-7d (Rename-Verträglichkeit):** Rename = neues Objekt + expliziter
  Redirect-/Deprecation-Eintrag im `log.md` (oder `references/`-Konvention von OKF), damit
  alte IDs maschinell ausfindig gemacht werden können.

---

### F-3 [HIGH] — AD-4/Q-1 verankern Provenienz nur auf Concept-Ebene; ein Consumer kann belegte von kontextuellen Aussagen nicht mechanisch unterscheiden

**Beteiligte ADs:** AD-4 (ASSUMPTION), Q-1, AD-13, Bind FR-3/FR-7/FR-8/NFR-7, FT-5, SM-3

**Konstruiertes Paar:**

- **Einheit 1** (Compiler): erzeugt ein synthetisiertes Concept (Synthese aus A und B gemäß
  AD-4/FR-7). Im Frontmatter stehen `sources:` mit den **mitgeführten** Source-Verweisen
  (AD-4: „relevante Source-Provenienz in das resultierende Concept übernehmen"). Der Body
  mischt drei belegte Claims mit zwei reinen Inferenz-Umformulierungen. Der Compiler erfüllt
  damit FT-5 und SM-3 buchstäblich („ein erzeugtes Concept kann auf Sources zurückgeführt
  werden" — Concept-Ebene).
- **Einheit 3** (strenger Consumer, auch ein LLM-Agent): liest dasselbe Bundle und kann pro
  Satz **keine** Grounding-Granularität mechanisch erkennen. Der Frontmatter-`sources`-Block
  gilt für das ganze Dokument; Inference-Formulierungen sehen identisch „belegt" aus.

Beide Einheiten sind AD-konform. Die **Belegstärke** der konsumierten Aussagen divergiert
jedoch: Ein strenger Consumer verwirft Inferenzen als unbelegt, ein laxer Consumer behandelt
sie als evidential. Q-1 beantwortet nur, ob ein generiertes Concept ein anderes generiertes
Concept als **alleinige** Provenienz verwenden darf („No") — es installiert damit keinerlei
maschinell prüfbare Regel auf **Aussage- oder Blockebene**. NFR-7 („Graceful Partial
Knowledge", Unsicherheit explizit) wird auf Concept-Ebene deklariert, aber nie in einer
satzgranularen Struktur erzwingbar.

**Close-Regeln:**

- **AD-4a (Claim-Granularität):** Provenienz muss pro behauptender Einheit (Block/Absatz)
  referenzierbar sein, nicht nur pro Concept. Mindestform: jede belegte Aussage trägt einen
  Inline-Verweis auf `raw/`-Evidenz; Kontext-/Synthese-Umformulierungen erhalten explizit
  einen Kontext-Marker („aus <Concept-Pfad> übernommen, nicht selbst belegt").
- **AD-4b (Sources-Ziel):** `sources`-Einträge dürfen auf `raw/` oder auf extern referenzierte
  Evidenz verweisen, **nie** auf einen `wiki/...`-Concept-Pfad (Wiki-Links bleiben AD-8;
  Provenienz und Beziehung werden formatseitig disambiguiert).
- **AD-4c (Q-1 verbindlich):** die Annahme „ein generiertes Concept darf nie ein anderes
  generiertes Concept als *einzige* Provenienz führen" wird von einer ASSUMPTION in eine
  Regel überführt und in die (geplante) `schema/wiki-compiler.md`-Validierung aufgenommen.

---

### F-4 [HIGH] — AD-16 vs. AD-17: die Klassifikation „CONTRADICTING vs. CORRECTING" entscheidet, wer das Auflösungs-Artefakt besitzt — und ist nicht arbitrierbar

**Beteiligte ADs:** AD-16, AD-17 Rule 2/4, AD-15, AD-5, FR-8/FR-13, NFR-7

**Konstruiertes Paar:**

- **Einheit 1**: klassifiziert eine neue Quelle als CONTRADICTING → lässt den Concept-Bereich
  **unangetastet**, dokumentiert den Disagreement in `log.md` (AD-16 wörtlich).
- **Einheit 2**: klassifiziert **dieselbe** Quelle als CORRECTING → **revidiert** das
  Concept (AD-16 erlaubt „CORRECTING → revise existing knowledge").

Beide Handlungen sind AD-16-konform. Die Kategorien sind „konzeptionell" (AD-16 verzichtet
explizit auf eine interne Datenstruktur und damit auch auf ein deterministisches
Entscheidungskriterium). Die Adversarität liegt darin, dass die Klassifikation **besitzt**,
was passiert: CONTRADICTING → Bewahrung, CORRECTING → Revision. Wer das Auflösungs-Artefakt
(Concept **oder** log.md) besitzt, hängt damit an der Willkür derselben Einheiten, die auch
die Schiedsrichter sein sollen. Das Lease- und Konvergenz-Modell (AD-17 Rule 4) kann hier
nicht arbitrieren, weil „produktiver Nutzen/Beitrag" als Auflösungsprinzip aufgerufen wird,
bevor überhaupt eine gemeinsame Bestimmung darüber existiert, ob ein Beitrag überhaupt
anzurühren ist. Ergebnis: Ein Paar aus einem bewahrenden und einem revidierenden Producer
ist nach allen ADs legal — und eine der beiden feindlichen Bundles stammt aus einer AD-16-
konformen Einheit, deren Arbeit von der anderen Einheit als „wirksam ersetzt" gilt.

**Close-Regeln:**

- **AD-16a (Default-Vorspann):** deterministische Vorgabe, z. B. „bei Widerspruch gilt
  Standard-Bewahrung (CONTRADICTING), sofern die neue Quelle nicht mit expliziter Evidenz die
  alte strikt ersetzt; andernfalls CORRECTING mit dokumentierter Ersetzungslogik".
- **AD-16b (Klassifikations-Pflicht):** die Klassifikation inkl. Begründung muss **im selben
  Artefakt** wie die Mutation landen (log.md-Eintrag angebunden an den mutierten Concept-Pfad),
  damit die Auflösungs-Entscheidung reproduzierbar und damit die Ownership auditierbar ist.

---

### F-5 [MEDIUM] — AD-17 Rule 2 schützt nur den *committed* Input; der dirty Working Tree eines Producers wird von anderer Einheit still zerstört (AD-15/FR-13-Loch)

**Beteiligte ADs:** AD-17 Rule 2, AD-6 (Mutation), AD-5, AD-15, Q-2, FR-13, AD-14

**Konstruiertes Paar:**

- **Einheit 1** (Mensch): bearbeitet direkt ein Concept (`wiki/flowable/timers.md`), nach
  AD-15/Q-2 ausdrücklich erlaubt, **noch nicht committet** (dirty working tree).
- **Einheit 2** (Compiler, AD-10-agent-unabhängig): liest gemäß AD-17 Rule 2 **nur committed
  Inhalte** → die menschliche Änderung ist de jure kein Input. Nach AD-6 Mutation läuft der
  Adapter in die Arbeitskopie, und der Adapter-Mechanismus (checkout/rebase/clean) trifft auf
  die dirty Datei.

Die Spannung: Rule 2 verhindert, dass uncommittete Inhalte „Input" werden — sie verhindert
**nicht**, dass der Mechanismus der anderen Einheit (Rebase/Checkout/Clean im eigenen
Adapter-Vokabular) die **uncommittete Arbeitskopie** der Einheit 1 genauso still entfernt.
Ein Rebase/Checkout in Run B wirft die uncommittete Datei von Einheit 1 ohne Git-Konflikt und
ohne log.md-Eintrag weg. Damit wird FR-13 („menschliche Inhalte nicht allein wegen fehlender
Herkunft entfernen") und AD-15 verletzt, ohne dass Einheit 2 irgendeine AD gebrochen hat.

**Close-Regeln:**

- **AD-17e (Dirty-Tree-Schutz):** vor jeder Mutation muss der Producer die Arbeitskopie für
  den zu mutierenden Bereich prüfen; nicht-committete, fremde Änderungen sind zu schützen
  (stash/divert in eine geschützte Scratch-Zone), und jeder verdrängte uncommittete Inhalt ist
  in `log.md` zu dokumentieren.
- **AD-14/AD-17f (Commit-Grenze als einzige Mutationsgrenze):** die Mutation darf nur auf
  Verzeichnis/Commit-Ebene wirken, die eine fremde dirty Arbeit nie als Side-Effekt von
  checkout/rebase löscht.

---

### F-6 [MEDIUM] — AD-1/FR-9 binden an „OKF 0.2", aber der Spine bindet weder das Feld-Subset noch den Validator; Spine-Artefakte (log.md) sind nicht OKF-tippbar

**Beteiligte ADs:** AD-1, FR-9, AD-16 (log.md), AD-9 (index.md), AD-10, NFR-5, FT-1, Consistency-Conventions „Errors: kein erfolgreicher Run bei ungültigem Bundle"

**Konstruiertes Paar:**

- **Einheit 1** (Claude-Adapter): emittiert `sources: [raw/foo.md, raw/bar.md]` (Liste von
  Strings).
- **Einheit 2** (Codex-Adapter): emittiert OKF-Map-/Objekt-Form bzw. deklariert
  `okf_version: "0.2"` nur in der Bundleroot-`index.md` (PRD § 13 nennt beides „optional").

Beide behaupten OKF-0.2-Konformität. Es gibt **keinen Validator** (siehe Consistency
Conventions: „kein erfolgreicher Run bei ungültigem Bundle" — aber ungültig *worum*?). Der
Spine verweist auf `schema/wiki-compiler.md`, aber dieser Ordner ist im Structural Seed nur
Dekoration und wird von **keiner** AD als verbindliches Artefakt gebunden. AD-10 verbietet
Adaptern abweichende Knowledge-Semantik — ohne objektives Validitätsprädikat ist „abweichend"
nicht entscheidbar.

Zweitens sind **Spine-eigene Artefakte** nicht OKF-getippt:

- `log.md` (AD-16): eine nicht gesperrte `.md`-Datei. OKF verlangt, dass nicht gesperrte
  Bundledateien ein `type` tragen. `log.md` hat keines — entweder ist das Bundle
  OKF-inkonform, oder log.md ist ein undefinierter Concept-Typ, sodass zwei Consumer uneins
  sind, ob es ein Concept ist.
- `index.md` als Discovery-Ebene (AD-9): OKF lässt Bundleroot-`index.md` mit
  `okf_version` optional zu; AD-9 macht sie faktisch zur Pflicht-Discovery — das ist eine
  Spine-Konvention über OKF hinaus, deren Consumer-Verträglichkeit ungeprüft ist.

Damit bleibt FT-1/NFR-5 („keine Runtime", „Read ohne Prozess") nur oberflächlich erhalten:
Nicht-Runtime gilt für das **Lesen von Markdown**; das **Verstehen** der Spine-Konventionen
(log.md-Semantik, Lease-Marker, index-Discovery) setzt Interpretationswissen voraus, das zwei
Consumer unterschiedlich ausführen. Lesbarkeit ≠ Konformität.

**Close-Regeln:**

- **AD-1a (Schema-Bindung):** `schema/wiki-compiler.md` wird als **verbindlich** gebunden:
  Es pinnt (i) das exakte OKF-0.2-Feld-Subset (sources-Form als Liste vs. Map, generiert/verified,
  status), (ii) `log.md` als dokumentiertes Artefakt **mit eigenem `type`**, (iii) die
  index-Discovery-Regel, (iv) die OKF-Validitätsprädikate.
- **AD-1b (Validator-Regel):** eine Regel, wie Konformität **geprüft** wird (auch wenn der
  Validator selbst bis D-3 als Agent-Instruktion lebt): „kein erfolgreicher Run bei
  OKF-invalidem Bundle laut schema/wiki-compiler.md".
- **NFR-5/AD-1c (FT-1 mechanisch):** FT-1 wird als Regel formuliert: „Entferne alle
  Runtime-Komponenten; der Reader benötigt nur Markdown + eine statisch abgelegte
  Konventions-Kurzfassung, um Anzahl, Bedeutung und Grounding aller Artefakte (incl. log.md)
  eindeutig zu bestimmen."

---

### F-7 [MEDIUM] — AD-17 Rule 4: „produktiver Nutzen als Auflösungs-Prinzip" ist nicht entscheidbar; zwei Merge-Autoritäten lösen denselben Konflikt gegensätzlich auf

**Beteiligte ADs:** AD-17 Rule 4, AD-16, AD-14, PRD OQ-4 (Konflikt-Auflösung)

**Konstruiertes Paar:**

- **Einheit 1** (Merge-Autorität / Maintainer A): führt den Konflikt in `flowable/timers.md`
  zugunsten von Quelle A auf, dokumentiert die Ablehnung von Quelle B in `log.md`.
- **Einheit 2** (Merge-Autorität / Maintainer B): führt denselben Konflikt zugunsten von
  Quelle B auf, dokumentiert die Ablehnung von Quelle A in `log.md`.

Beide sind AD-16/AD-17-konform (Konflikt explizit erhalten, offengelegt). Das Prinzip
„produktiver Nutzen/Beitrag zählt als Auflösungs-Prinzip" ist aber **weder mechanisch noch
authoritativ bestimmt**: Es sagt nichts darüber, wer entscheidet und anhand welcher
beobachtbaren Kriterien. Zwei voneinander unabhängige Merge-Läufe über demselben Git-Zustand
produzieren unterschiedliche Bundles, beide konform. Damit ist die Reproduzierbarkeit des
Bundles (eine Kernanforderung aus FT-7 / SM-1) nicht gegeben — derselbe Git-Zustand kann zu
zwei kanonisch gültigen, aber inkompatiblen Bundles führen.

**Close-Regeln:**

- **AD-17g (Auflösungs-Autorität):** festlegen, **wer** eine AD-16-Kollision auflöst
  (MVP: der Compiler-Run, der das Lease hält, nach AD-16a-Default; menschliche Eskalation nur
  bei Nicht-Entscheidbarkeit), und dass die Auflösung an denselben Commit/dieselbe
  Log-Dokumentation gebunden ist (Kryptominimal: Commit-Hash + Klassifikation im Eintrag).
- **AD-17h (Determinismus-Kontrakt):** über demselben Git-Zustand und derselben Input-Menge
  müssen zwei unabhängige Läufe **denselben** Bundle-Zustand erzeugen (als expliziter
  Fitness-Test analog FT-6), andernfalls ist die AD-16-Klassifikation nicht deterministisch
  genug.

---

## 3. Querschnitt-Lücken und wo Autorität fehlt

Die Findings reihen sich in ein Muster: **der Spine beschreibt die Data-Ebene präzise und
delegiert die Koordination an „den ausführenden Adapter", ohne dem Adapter einen
deterministischen Vertrag zu geben.**

- **D-3 / D-7 / D-1 bleiben offen**, während die Konformität des Bundles (F-6) davon abhängt,
  dass der Validator irgendwann existiert. Solange der Validator liegt, ist „OKF-konform"
  eine Behauptung, kein Prädikat.
- **PRD OQ-4** (welche Konflikte darf der Compiler selbst auflösen) ist im Spine als
  AD-17 Rule 4 nur scheinbar beantwortet — sie beantwortet das *woran*, nicht das *wer* (F-7).
- **Q-1** im Spine („Current assumption: No") hat bisher keine Regelwirkung (F-3).
- **Q-2** (dürfen Menschen generierte Concepts direkt editieren?) ist für die
  Dirty-Tree-Kollision (F-5) relevant, da der Spine mit „verhindert nicht menschengemachte
  Edits" eine Koexistenz erlaubt, ohne die Koexistenz zu koordinieren.

---

## 4. Empfohlener Regel-Katalog (neu/verschärft)

| # | Regel | Ersetzt/ergänzt | Schließt |
|---|---|---|---|
| R1 | Lease-Vertrag (Mechanismus, Commit-Bindung, stalo) | AD-17a–17d | F-1 |
| R2 | Root-Scope des Leases inkl. `log.md`/`index.md` | AD-17b | F-1 |
| R3 | Kein textueller Git-Auto-Merge über identischen Concept-Pfad; Merge nur über AD-16-Klassifikation | AD-17c | F-1 |
| R4 | Eine kanonische Concept-ID-Normalisierungsform + eine erlaubte Linkform | AD-7a/7b | F-2 |
| R5 | Deterministische Area-Zuordnung für neue Concepts | AD-7c | F-2 |
| R6 | Rename als neues Objekt + Redirect/Deprecation in log.md | AD-7d | F-2 |
| R7 | Claim-granulare Provenienz; `sources` nie auf `wiki/`-Pfade; Q-1 → Regel | AD-4a–4c | F-3 |
| R8 | AD-16-Generalvorschrift: Bewahrung als Default; Klassifikation publik, an Mutation gebunden | AD-16a/16b | F-4, F-7 |
| R9 | Dirty-Tree-Schutz; Commit-Grenze als Mutationsgrenze; Verdrängung dokumentieren | AD-17e/17f | F-5 |
| R10 | `schema/wiki-compiler.md` verbindlich; log.md-tipbar; FT-1 mechanisch | AD-1a–1c | F-6 |
| R11 | Auflösungs-Autorität + Determinismus-Contract (gleicher Zustand → gleiches Bundle) | AD-17g/17h | F-7 |

---

*Ende des Adversarial Reviews.*