# Writer-Inventar und P0-Entscheidung (AA-053)

Status: `BASELINE_PARTIAL`; Scan read-only mit privilegiertem Zugriff am 2026-08-29.

## Gemessene Writer-Konflikte

### `signals`

Technischer Zielowner: `signal_intake`; fachlicher Zielowner für Bewertungsfelder: `signal_intelligence`; redaktioneller Zielowner: `editorial_planning`.

Aktuell nachgewiesene Writerfamilien:

- `social-media-radar/signal_db.py` (Schema, Intake, Signal-Insert/Update)
- `social-media-radar/rss_intake.py`, `weather_intake.py`, `intake/meta_ads_intake.py` (Intake)
- `social-media-radar/aa045_schema.py` (Schema-/`source_runs`-Migration und Run-Metadaten)
- `social-media-radar/aa045_enrich.py`, `aa045f4_enrich.py`, `image_backfill.py`, `image_backfill_p8.py`, `image_refresh.py`, `gnews_image_backfill.py`, `og_backfill.py`, `multi_cluster.py`, `translate_backfill.py`, `cleanup_summaries.py` (Enrichment/technische Metadaten und Summary-Feld)
- `social-media-radar/dedup_cleanup.py`, `signal_decay.py` (Dedup-/Archivstatus)
- `social-media-radar/rescore.py`, `classification/signal_classifier.py`, `content_director.py`, `content_briefing.py` (fachliche/redaktionelle Felder)
- `social-media-radar/sma_content_worker.py` (Legacy-Content-Felder)
- `social-media-agent/app.py`, `social-media-agent/publish_ready.py` (UI-/Package-Nebenpfade)
- `social-media-radar/run_radar.sh` Inline-Backfill (technische Bildfelder)

Ergänzung nach privilegiertem Vollscan: `aa045_schema.py` und `cleanup_summaries.py` waren in der ursprünglichen Writerliste nicht explizit aufgeführt. Testdateien wurden nicht als Produktivwriter gewertet. `sma_content_worker.py` schreibt neben `content_drafts` auch `signals.publish_status`.

Befund: kein exklusiver Feldbesitz; `signals` ist der erste verbindliche Konsolidierungs- und Portkandidat. Physische Tabellentrennung ist hierfür nicht der erste Schritt.

### `content_drafts`

Aktuell nachgewiesene Writer:

- `social-media-agent/app.py`
- `social-media-agent/content_queue_patch.py`
- `social-media-radar/dedup_checker.py`
- `social-media-radar/sma_content_worker.py`

Befund: konkurrierende Legacy-Queue-/Draft-Pfade; vor einer Umschaltung muss ein einziger Content-Production-/Review-Writer festgelegt werden.

### `sma_core`-Runtime-/Editorial-Tabellen

`/sma_core` schreibt benannte Tabellenfamilien über Repositories und Services (`editorial_candidates`, `editorial_selection_runs`, `content_queue`, `content_workflows`, `content_revisions`, `content_packages`, `quality_*`, `approval_*`, `worker_runs`, `runtime_revision_jobs` usw.). Diese Pfade sind strukturell besser abgegrenzt, aber `repositories.py`, `services.py`, `history.py`, `selection.py` und `strategy.py` bleiben Split-/Owner-Prüfkandidaten.

Die privilegierte Schemaaufnahme der produktiven DB bestätigt die Tabellen-/Spaltenbasis: `/var/lib/sma-data/signals.db` enthält `signals` mit 96 Spalten, `content_drafts` mit 15 Spalten sowie die Core-Familien einschließlich `editorial_candidates`, `content_queue`, `content_workflows`, `quality_reviews`, `approval_events`, `publications`, `worker_runs` und `runtime_revision_jobs`.

## P0-Migrationsentscheidung

1. Keine fachliche Umschaltung, bevor die Writer auf Tabellen- und Feldebene vollständig aufgelöst sind.
2. Zuerst einen benannten Read-/Write-Port für `signals` charakterisieren; bestehende Skripte nur dahinter wrappen.
3. Technische Enrichment-Writes von Intelligence-/Editorial-Writes trennen.
4. Danach `content_drafts`/Queue als eigener Contract zwischen Editorial Planning, Content Production und Review & Release behandeln.
5. `app.py`-Routen bleiben zunächst Adapter; direkte Fach-SQL-Writes werden erst nach Route-Charakterisierung entfernt.
6. Jeder Structural-Schritt benötigt Disposable-DB-Contracttests, Shadow-Vergleich und negativen Eligibility-Test.

## Nicht als erledigt werten

Dieses Inventar beweist Writer-Präsenz und die Tabellen-/Spaltenexistenz, aber noch nicht Aufrufhäufigkeit, vollständige dynamische Spaltenabdeckung oder exklusive Tabellenbesitzer. Diese Punkte bleiben offene Phase‑0-Nacharbeit.