# AWS-Migration-Readiness — Übergabepaket für Adesso

Stand: 2026-08-05. Angelegt auf Anweisung des Product Owners vom 05.08.2026.

## Warum dieses Verzeichnis leer aussieht

Vorgesehen sind achtzehn Dokumente. **Sie werden einzeln geschrieben, wenn der
Code sie hergibt** — nicht als Satz von Vorlagen.

Der Grund steht in der Anweisung selbst: „Diese Dokumente sollen den
tatsächlichen Code beschreiben, nicht nur ein theoretisches Zielbild."
Achtzehn Dateien mit Überschriften und Platzhaltern wären das Gegenteil davon.
Sie sähen aus wie ein Übergabepaket und wären keins — und ein Übergabepaket, das
Vollständigkeit vortäuscht, ist für Adesso schlechter als ein ehrlich
unvollständiges.

Diese Datei führt deshalb, was fehlt und was es dafür braucht. Wer eines der
Dokumente schreibt, streicht seine Zeile hier und verlinkt die Datei.

Das ist eine Abweichung von einer ausdrücklichen Anweisung (achtzehn benannte
Dateien) und wurde dem Product Owner am 05.08.2026 mit Begründung vorgelegt,
zusammen mit der Frage, ob das Gerüst trotzdem angelegt werden soll. Bis dahin
gilt diese Fassung. Ein Mittelweg wäre möglich: achtzehn Stubs, jeder mit einem
Verweis auf die Zeile hier statt mit Platzhaltertext — dann existieren die
Dateipfade, ohne Inhalt zu behaupten.

## Stand der achtzehn Dokumente

| Datei | Inhalt | Stand | Was fehlt, um es zu schreiben |
|---|---|---|---|
| `01_SYSTEM_CONTEXT.md` | System, Nutzer, Nachbarsysteme | offen | ableitbar aus `CLAUDE.md` und `docs/vendor-handover/` — kurzer Abgleich nötig |
| `02_DOMAIN_BOUNDARIES.md` | fachliche Grenzen, Module | offen | ADR-010/015 und `lib/*/index.ts`-Barrieren auswerten |
| `03_QAF_CORE_ARCHITECTURE.md` | der deterministische Kern | offen | `lib/qaf-differences/internal/` durchmessen: Eingänge, Ausgänge, Abhängigkeiten |
| `04_CANONICAL_DATA_CONTRACT.md` | kanonisches JSON als Migrationsgrenze | **teilweise vorhanden** | `baseline-inputs/03_QAF_Comparison_Canonical_Schema_v1.0.json` und `export-canonical.ts` verbinden; Versionierung und Rückwärtskompatibilität sind noch nicht beschrieben |
| `05_PERSISTENCE_PORTS.md` | die 13 geforderten Repository-Verträge | offen | **die Verträge existieren noch nicht.** Sie zu definieren ist Arbeit am Code, nicht Dokumentation. Nicht zu verwechseln mit `lib/repositories/**` und `lib/offline/repository.ts` — die gehören zum Offline-Zwischenspeicher für Planung und Bewertung, nicht zu QAF. Als Vorarbeit vorhanden: `lib/qaf-differences/internal/persistence-mapper.ts` (Zeilenform-Abbildung ohne Ein-/Ausgabe, also noch kein Vertrag mit austauschbarer Implementierung); der Datenzugriff läuft weiter über direkte `.from('qaf_…')`-Aufrufe in `app/qaf-differences/actions.ts` |
| `06_CURRENT_SUPABASE_ADAPTER.md` | Supabase als aktueller Adapter | offen | `lib/supabase/**` und die direkten Aufrufe aus UI-Komponenten erheben |
| `07_AUTHORIZATION_BOUNDARIES.md` | Autorisierung fachlich vs. RLS | **Grundlage vorhanden** | `docs/foundation/rls-*.md`, `supabase-migration-internal-open-access-model.sql`, `public.rls_access_class` |
| `08_FILE_STORAGE_CONTRACT.md` | Dateispeicher-Vertrag | offen | aktuelle Storage-Nutzung erheben |
| `09_DATABASE_OBJECT_INVENTORY.md` | Datenbankobjekte | **Grundlage vorhanden** | `MIGRATIONS.md`, `supabase/bootstrap/supabase-schema.sql`, `scripts/schema-drift/` |
| `10_MIGRATION_DEPENDENCIES.md` | Reihenfolge und Abhängigkeiten | offen | aus `MIGRATIONS.md` ableitbar |
| `11_CONFIGURATION_REFERENCE.md` | Umgebungsvariablen, Fail-fast | **Grundlage vorhanden** | `docs/foundation/environment-variables.md` und `lib/env-schema.ts` — eine validierte Konfigurationsschicht (zod über `@t3-oss/env-nextjs`, wirft beim Import, getestet in `lib/__tests__/env-schema.test.ts`, verdrahtet über `lib/env.ts` in `app/layout.tsx` und `lib/supabase/admin.ts`). Sie deckt 4 der 13 in `environment-variables.md` dokumentierten Variablen ab; zu beschreiben ist die Lücke, nicht die Schicht |
| `12_TEST_AND_GOLDEN_CORPUS.md` | Tests und Golden Corpus | **weitgehend vorhanden** | `qaf-v2/testinventar.md`, `qaf-v2/golden-corpus.md`, `qaf-v2/triage-env-gated-tests.md` zusammenführen |
| `13_DEPLOYMENT_AND_RUNTIME.md` | Deployment und Laufzeit | **Grundlage vorhanden** | `DEPLOYMENT.md`, `Dockerfile`, `docker-compose.yml` |
| `14_OBSERVABILITY.md` | Logging, Tracing, Healthchecks | offen | Sentry, OpenTelemetry, `lib/logger.ts` erheben |
| `15_MIGRATION_RUNBOOK.md` | Ablauf der Migration | offen | setzt 05, 10 und 13 voraus |
| `16_ROLLBACK_AND_RECOVERY.md` | Rücknahme | offen | setzt 10 und 15 voraus |
| `17_OPEN_DECISIONS_FOR_ADESSO.md` | offene Entscheidungen | **sinnvoll sofort** | die Liste wächst mit jedem Loop; erste Einträge unten |
| `18_ACCEPTANCE_CHECKLIST.md` | Abnahmeliste | offen | setzt alle übrigen voraus |

`migration-manifest.json` (maschinenlesbar) setzt mindestens 05, 09 und 11
voraus — solange die Repository-Verträge nicht existieren, wäre es eine Liste
von Namen ohne Gegenstück im Code.

## Was ausdrücklich NICHT getan wird

Kein Infrastruktur-Großumbau, kein Austausch von Supabase gegen
AWS-Komponenten, keine erfundene AWS-Zielarchitektur. Insbesondere **nicht**
eigenmächtig festgelegt: RDS oder Aurora · S3-Bucket-Struktur · ECS, EKS oder
Lambda · Cognito oder ein anderer Identity Provider · EventBridge, SQS oder SNS
· Secrets- und Netzwerkarchitektur.

Solange Adesso beziehungsweise BMW keine verbindlichen Zielvorgaben liefern,
wären das Spekulationen, die später teuer zurückgebaut werden müssten. Die
Schnittstellen werden cloud-neutral definiert; Supabase wird als **aktueller
Adapter** geführt, nicht als Zielarchitektur.

## Erste offene Entscheidungen für Adesso und BMW

Das ist der Anfang von `17_OPEN_DECISIONS_FOR_ADESSO.md`, hier geführt, bis die
Datei entsteht.

1. **Zielarchitektur für Persistenz.** Ohne verbindliche Vorgabe bleiben die
   Repository-Verträge cloud-neutral. Sobald sie feststeht, sind die Adapter zu
   ergänzen.
2. **Identitäts- und Autorisierungsmodell.** Aktuell trägt Supabase-RLS einen
   Teil der Autorisierung. Das Zugriffsmodell (`open_business_data_model` gegen
   `protected_security_control_plane`) ist fachlich beschrieben und in einer
   Migration umgesetzt — in einer neuen Umgebung muss die fachliche
   Autorisierung im Domainmodell tragen, nicht die Datenbankschicht.
3. **Dateispeicher.** Anforderungen sind zu erheben, bevor ein Zielsystem
   gewählt wird.
4. **Aufbewahrung und Löschfristen** für QAF-Quelldateien und Vergleiche.
5. **Umgang mit dem Golden Corpus.** Die vier committeten Fixtures sind
   anonymisierte reale BMW-Formulare. Ob sie in einer BMW-eigenen Umgebung
   weiterhin anonymisiert bleiben müssen oder durch Originale ersetzt werden
   dürfen, ist eine BMW-Entscheidung — mit Folgen für die Testbarkeit.
6. **`MIG-001` und `MIG-002` haben keinen Loop.** Die Traceability-Matrix ordnet
   beide „Loop 17" zu, die Roadmap endet bei Loop 15. Inhaltlich gehören sie zu
   Loop 15 (V1-Paritätsmatrix, Feature Flags und Rollback) — beides unmittelbar
   migrationsrelevant. Die Zuordnung ist Baseline und wird nicht eigenmächtig
   verschoben; siehe `docs/qaf-v2/program-status.md`, Abschnitt „Anforderungen
   ohne Loop in der Roadmap".

## Was heute schon migrationsrelevant fertig ist

- **Kanonischer Export mit Determinismusnachweis.** Drei Läufe über dieselbe
  Eingabe ergeben denselben Hash; geprüft synthetisch *und* über die vier
  realen Fixtures (`tests/fixtures/qaf-golden/__tests__/determinismus.test.ts`).
  Der Test ist infrastrukturfrei — er liest eine Datei und hasht ein
  Ergebnisobjekt, ohne Supabase, Cloud oder Datenbank. Er überlebt die Migration
  unverändert.
- **Golden Corpus in CI.** Vier reale anonymisierte Fixtures liegen im
  Repository; die Abnahme braucht keinen Zugriff auf lokale Verzeichnisse.
  Adesso kann sie ohne die Umgebung des Vorentwicklers ausführen.
- **Testinventar mit gemessenen Zahlen.** `qaf-v2/testinventar.md` beziffert, was
  CI wirklich ausführt und was nicht — die Grundlage für
  `12_TEST_AND_GOLDEN_CORPUS.md`.