# Architektur-Challenge: Vier Wege, elf Kriterien

Stand: 03.08.2026 · Basis: ausgeführter Loop 0 (nicht Dokumentenlage) ·
`main` = `d639c0b`, 6.916 Tests grün, HICE-Reproduktion 4/4, Determinismus belegt.

Auftrag Schritt 7: die Empfehlung Strangler-V2 ausdrücklich challengen.

## Die vier Alternativen

**A — Weiterbau der bestehenden Lösung.** Langseite behalten, Lücken
(Übersetzungsmodule, D15-17, R-03) direkt einbauen, Export nachrüsten.

**B — Strangler-V2 auf bestehendem Kern** (Paket-Empfehlung). Kern behalten
und konsolidieren, kanonischer JSON als Systemgrenze, neue Oberfläche
dagegen, V1 bis Parität.

**C — Vollständiger Rewrite.** Kern und UI neu, Spec als Bauplan.

**D — Modulare Alternative.** Sofortige Zerlegung in packages/-Monorepo
(qaf-workbook-reader, qaf-domain, …, Spec §47) mit neuer UI darüber.

## Bewertung (0–10 je Kriterium, aus Loop-0-Evidenz begründet)

| Kriterium | A | B | C | D |
|---|---:|---:|---:|---:|
| Erhalt der deterministischen Logik | 9 | 9 | 2 | 7 |
| QAF-Abdeckung (8.8/9.1/Zeilen/G60/Multi) | 7 | 8 | 3 | 7 |
| Unterstützung 1–6 QAFs | 3 | 8 | 8 | 8 |
| Nachvollziehbarkeit (Provenienz, Traceability) | 5 | 9 | 4 | 8 |
| Testbarkeit | 5 | 8 | 5 | 9 |
| Migrationsrisiko (10 = risikoarm) | 8 | 7 | 1 | 3 |
| Entwicklungsaufwand (10 = gering) | 7 | 5 | 1 | 2 |
| UX (Zielbild erreichbar) | 3 | 9 | 9 | 9 |
| Performance (6-QAF-Ziel) | 4 | 7 | 6 | 7 |
| Security (Bestand erhalten) | 9 | 9 | 3 | 8 |
| Langfristige Wartbarkeit | 3 | 8 | 7 | 9 |
| **Summe** | **63** | **87** | **49** | **77** |

## Warum die Zahlen so stehen (die tragenden Argumente)

### Gegen C (Rewrite) — das stärkste Loop-0-Ergebnis

Die ADR-Revisionsbedingung („reproduzierbarer, nicht wirtschaftlich behebbarer
Kernmangel") ist NICHT eingetreten — das Gegenteil: Der Kern hat die
HICE-Referenz beim ersten Versuch exakt reproduziert (Δ +12,9631, Brücke
schließt, zwei Läufe ein Hash). Die teuersten Lernkurven sind bezahlt und
TESTBAR bezahlt: SBM-1-statt-82-Köpfe, #N/A-Verschachtelung, BIFF-Shim,
Parameteridentität, ehrliche Reconciliation (13/97/784/0). Ein Rewrite
öffnet all das neu, gegen 77.949 Zeilen mit ~6.900 Tests. C fällt.

### Gegen A (Weiterbau) — strukturell, nicht kosmetisch

Die vier größten Lücken sind in der bestehenden Struktur nicht gut lösbar:

1. Der Export IST die Ansicht (clientseitig, „identisch zur Ansicht") —
   ein kanonischer Vertrag braucht die Umkehrung der Abhängigkeit.
2. Das A–F-Set braucht ein persistiertes ComparisonSet-Modell — batch.ts
   wählt heute konstruktionsbedingt EIN Paar je Gruppe.
3. 22 harte Modus-Gates außerhalb der Registry + 18-Sektionen-Registry
   erzwingen die Langseite für jeden Vergleichstyp.
4. UI-Monolithen (1.743/1.809 Z.) + actions.ts (4.771 Z.) machen jede
   dieser Änderungen im Bestand teuer und riskant.

A konserviert genau die Probleme, deretwegen Kais den Auftrag gegeben hat.

### Gegen D (Monorepo-Zerlegung jetzt) — richtiges Ziel, falscher Zeitpunkt

Die Package-Struktur (§47) ist als ZIELBILD gut, aber als ERSTER Schritt
verkehrt: Sie verschiebt Wochen in Build-Infrastruktur, bevor eine einzige
fachliche Lücke schließt. Der Kern hat bereits eine Barrel-Disziplin
(internal/ + index.ts); die Deep-Import-Verstöße (11 Dateien) sind zählbar
und einzeln behebbar. D ist als spätere Phase VON B erreichbar — B schließt
D nicht aus, D verzögert aber alles, was B sofort liefert.

### Für B — mit drei Schärfungen aus dem Audit

Die Paket-Empfehlung hält der Prüfung stand, wird aber konkreter:

1. **Loop 5 ist billiger als geplant** (B-04): storage_key-Spalte existiert,
   Originale liegen im Bucket. Kein Schema-Umbau — Befüllen + Reparse-Pfad
   + Bestands-Rückverknüpfung über Storage-Listing.
2. **Der 19/24-Konflikt ist eine Governance-Entscheidung, kein Bug** (B-01):
   19 = golden-file-treu, 24 = Spec-Erweiterung. Loop 6 beschließt die 24
   und ergänzt die 5 fehlenden Bereiche; `html_companion` wird explizit
   entschieden (Empfehlung: nicht in den kanonischen Vertrag, Ableitung wie
   presentation_package).
3. **Vorgezogene Hygiene:** Das wirkungslose Lint-Gate (61 vorbestehende
   Errors, continue-on-error) gehört als eigener Schritt in Loop 0/1 —
   sonst ertrinken neue V2-Fehler im Bestand. Mindestens: Fehlerstand
   einfrieren (Baseline-Datei), neue Errors blocken.

## Entscheidung

**Strangler-V2 auf dem vorhandenen deterministischen Kern — bestätigt durch
ausgeführten Audit, nicht nur übernommene Dokumentenlage.** Details im ADR
(`decisions/ADR-000-baseline-und-bestaetigung.md`).

Revisionsbedingung bleibt: Nur ein neues ADR mit reproduzierbarem, nicht
wirtschaftlich behebbarem Kernmangel aus Loop 0–2 kippt die Entscheidung.
Loop 0 hat das Gegenteil belegt.