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

name, type, adversary, status, created, target, mandate

name	type	adversary	status	created	target	mandate
Adversarial Review — ARCHITECTURE-SPINE.md (wiki-of-wikis-2026-08-14)	adversarial-review	independent	final	2026-08-14	ARCHITECTURE-SPINE.md prd.md (prd-wow20-2026-08-14)	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 ü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.