# AA-053 – Structural-Migrationsreihenfolge

Diese Reihenfolge ist eine technische Arbeitsentscheidung auf Basis der Phase‑0‑Befunde. Sie ändert noch kein Fachverhalten.

1. **Writer-/Route-Baseline abschließen:** Tabellen, Spalten, SQL-Writes, Flask-Routen, CLI und dynamische Imports vollständig erfassen.
2. **Architekturtests einführen:** Scope-/Importgrenzen, verbotene Legacy-Ausnahmen, Brand-Isolation und direkte Route-SQL als zunächst gemessene Regeln.
3. **Signal-Intake-Port:** `signal_db.py` und technische Backfills hinter benannte Ports kapseln; keine neue Relevanzlogik.
4. **Eligibility-Fassade:** vorhandene Relevanz-/Safety-Entscheidung charakterisieren, unveränderlichen Snapshot persistierbar machen, Downstream noch nicht semantisch ändern.
5. **Editorial-Port:** Director und Briefing trennen; einheitliche `EditorialDecision`-/`ContentBrief`-Verträge.
6. **Content-/Package-Fassade:** `publish_ready.py` hinter Production-/Quality-/Review-Ports legen; Verhalten per Shadow vergleichen.
7. **Operator Experience:** `app.py` in App-Factory, Blueprints und Application Services entkoppeln; Route-SQL schrittweise entfernen.
8. **Core-Fitness:** `repositories.py`, `services.py`, `history.py`, `matching.py`, `selection.py`, `scoring.py`, `strategy.py` nach Besitz und Lebenszyklus splitten oder wrappen.
9. **Runtime-Konsolidierung:** erst nach Beobachtung einen benannten Daily Job und die aktivierten Workerpfade vereinheitlichen; kein zweiter Scheduler.
10. **Legacy-Abbau:** erst nach Nichtnutzungsnachweis, Beobachtungsfrist, Backup und Rollback-Anleitung.

## Gate für jeden Schritt

Baseline grün → Charakterisierung → Contracttests → Structural-Änderung → lokale Tests → Architekturtests → Shadow/Compare → HTTP-/Job-Nachweis → Rollback-Nachweis → Beobachtung.

Behavioral-Änderungen, Policy-/Scoring-/Safety-Änderungen und externe Delivery bleiben separate Aufträge.