# Entwicklungsplan: Meldeverfahren v2 (Selbstbedienungs-Flow „PM melden")

**Stand:** 22.07.2026
**Grundlage:** `Lösch- und Änderungsanfragen.md` (Entscheidungsachse, Free/Paid-Matrix, §11 Self-Service-Ausbau) und `Pressemitteilung melden.md` (Vier-Spuren-Flow)
**Ziel:** Portal übernimmt den gesamten Post-Publication-Zustand selbst (connektar = write-once). Vier Spuren: Kleine Korrektur (frei), DSGVO-Anonymisierung (frei, Admin-Gate), Depublizierung (kostenpflichtig), Änderung (kostenpflichtig, KI-Freigabelauf).

---

## 0. Ist-Stand: Was bereits existiert (Bauen auf, nicht neu)

Die Codebasis enthält bereits ein **Meldeverfahren v0.1** und fast alle benötigten Bausteine. Der Plan ist ein **Ausbau**, kein Neubau.

| Baustein | Vorhanden | Relevante Dateien |
|---|---|---|
| Melde-Queue (DSGVO / Persönlichkeitsrecht / Meldung) | ✅ v0.1: Intake → Admin-Queue, manuelle Erledigung | `app/Models/LegalRequest.php`, `app/Enums/LegalRequestType.php`, `app/Enums/LegalRequestStatus.php` |
| Öffentliche Meldeformulare (Honeypot, Rate-Limit, DSA-Eingangsbestätigung `M-{id}`) | ✅ `melden/{way}` + PM-gebunden `/release/{slug}/rechtliches` | `app/Http/Controllers/Web/ReportFormController.php`, `app/Http/Controllers/LegalRequestController.php`, `routes/legal.php` |
| Admin-Queue „Recht & Compliance" (`can:compliance:manage`) | ✅ Status-Handling (open/in_progress/resolved/rejected), aber **keine Ausführungs-Aktionen** (kein Anonymisieren/Depublizieren aus der Queue) | `resources/views/livewire/admin/legal-requests/{index,show}.blade.php`, `routes/admin.php` |
| Magic-Link-Infrastruktur (sha256-Token, purpose, payload, TTL, Consume) | ✅ purposes `login`, `press_release_access` | `app/Models/MagicLink.php`, `app/Services/Auth/MagicLinkGenerator.php`, `app/Http/Controllers/Auth/MagicLinkConsumeController.php`, `app/Console/Commands/PurgeMagicLinks.php` |
| Depublizierung + Tombstone | ✅ `depublish()` → Archived + `depublished_at`, Detail-URL liefert **HTTP 410** Tombstone | `app/Services/PressRelease/PressReleaseService.php:394`, `app/Http/Controllers/Web/ReleaseDetailController.php`, `resources/views/web/release-tombstone.blade.php` |
| Bezahlte Depublizierung (Stripe-Checkout + Webhook-Fulfillment) | ✅ aber nur **eingeloggt** (`routes/customer.php:52`) | `app/Services/Billing/StripeCheckoutService.php:452`, `app/Listeners/ProcessStripeWebhook.php:475`, `app/Enums/SinglePurchaseType.php` |
| Credits (Ledger, atomar) | ✅ | `app/Services/Billing/CreditWalletService.php` |
| KI-Prüfung (grün/gelb/rot, Audit) | ✅ Klassifikation + Routing bei Erst-Freigabe; Re-Check nach Edit **ohne** Status-Wirkung | `app/Jobs/ClassifyPressRelease.php`, `PressReleaseService::routeByClassification():176`, `reprocessAfterContentChange():150`, `app/Models/KiAudit.php` |
| Hinterlegte Pressekontaktadresse | ✅ `Contact.email` (Pivot `press_release_contact`), Fallback `Company.email` | `app/Models/Contact.php`, `app/Models/Company.php` |
| Audit/Verlauf | ✅ `ActivityLog::record()` + `PressReleaseStatusLog` (mit `source`) | `app/Services/ActivityLog.php`, `app/Models/PressReleaseStatusLog.php` |
| connektar-Eingang | ✅ Legacy-API (`store()` → Review/KI bzw. Sofort-Publish), Bulk-Import mit `LegacyImportMap`-Skip-Guard | `app/Http/Controllers/Api/Legacy/LegacyPressReleaseController.php`, `app/Services/Import/PressReleaseImporter.php` |

**Fehlende Kernstücke (= dieser Plan):** Re-Sync-Sperre als PM-Flag, Anonymisierungs-Engine (Wortgrenzen-Replace + Diff), Magic-Link-Verifikation für das Meldeverfahren, Self-Service-Portal mit den vier Spuren, Admin-Ausführungsaktionen in der Queue, Gast-Checkout für Depublizierung/Änderung, Reversibilitätsfenster, verschlüsselte Alt-Wert-Snapshots mit Löschfrist.

---

## 1. Phasenübersicht

Reihenfolge nach Nutzen und Abhängigkeit: Zuerst die Bausteine, die den **manuellen Interimsprozess** sofort absichern (Re-Sync-Sperre, Anonymisierung im Admin), dann Verifikation, dann die Self-Service-Spuren.

```
Phase 1  Datenmodell + Re-Sync-Sperre               ✅ umgesetzt 22.07.2026
Phase 2  Anonymisierungs-Engine + Admin-Ausführung   ✅ umgesetzt 22.07.2026
Phase 3  Magic-Link-Verifikation + Intake-Trichter   ✅ umgesetzt 22.07.2026
Phase 4  Spur A — Kleine Korrektur (self-service)   ✅ umgesetzt 22.07.2026 (panel-first)
Phase 5  Spur B — DSGVO-Einreichung (self-service → Admin-Gate)
Phase 6  Spur C — Depublizierung (Gast-Checkout + Reversibilitätsfenster)
Phase 7  Spur D — Änderung (Gast-Checkout + KI-Freigabelauf)
Phase 8  Querschnitt-Abschluss: Kommunikation, Auslieferungs-Checks, Doku
```

Jede Phase ist eigenständig deploybar; nach Phase 2 ist der Interims-Triage-Prozess (§4 des Konzepts) technisch vollständig unterstützt.

### Stand 22.07.2026 abends — was noch fehlt (Einstieg für morgen)

**Phasen 1–4 sind umgesetzt und getestet** (Details in den Phasen-Abschnitten). Offen:

1. **Phase 5 — Spur B strukturiert:** Das DSGVO-Anliegen im verifizierten Web-Bereich ist bisher Freitext; geplant ist das strukturierte Schwärzungsformular (Felder + Varianten) mit Pflicht-Diff aus `AnonymizationService::preview()`, das den fertigen Schwärzungsauftrag in die Admin-Queue legt (Admin-Editor vorbefüllt).
2. **Phase 6 — Spur C Gast-Checkout:** 35-€-Checkout für Magic-Link-Verifizierte (ohne Login); Reversibilitätsfenster-Hinweis („umkehrbar bis …", `legal.reversal_window_days`); **`lockSync()` auch im bestehenden Webhook-Fulfillment `fulfillDepublication()` nachrüsten** (bezahlte Panel-Depublizierung setzt die Sperre bisher nicht!).
3. **Phase 7 — Spur D Checkout:** 10 € (`billing.change_price_cents` anlegen), Gast + Panel; nach Zahlung KI-Freigabelauf auf Pending-Payload (grün/gelb → live, rot → kein Verbrauch, erneut einreichbar). Ersetzt den Interim-Weg „Change-Anfrage in die Queue".
4. **Spur A im Web-Pfad:** Korrektur-Formular (CorrectionService-Engine) auch für Magic-Link-Verifizierte statt Queue-Anfrage; Bestätigungsmail an die Kontaktadresse.
5. **Phase 8 — Querschnitt:** connektar-Template-Stopp in allen Texten prüfen, `noindex` im Tombstone verifizieren, zweistufige Eskalations-Mailtexte (Ablehnung mit Aufsichtsbehörden-Hinweis), Doku-Abgleich.
6. **Ops:** Dev-DB-Migration (`sync_locked_at`-ALTER auf `press_releases`, FULLTEXT-bedingt langsamer Tabellen-Copy) lief am Abend des 22.07. noch; danach `php artisan migrate` für die restlichen Migrationen (`magic_links`-Enum) ausführen. Test-DB ist vollständig migriert, alle 41 Legal-Tests grün.
7. **Konfig-Feinjustierung (22.07. abends):** `correction_max_distance_percent` auf **5 %** und `corrections_per_week` auf **1** verschärft (statt 15 %/2 aus E5). Dazu im Service die **Mini-Edit-Ausnahme**: Änderungen ≤ 2 Zeichen gelten immer als klein — sonst würde bei kurzen Titeln ein einzelner Tippfehler die Prozent-Grenze reißen.

---

## Phase 1 — Datenmodell + Re-Sync-Sperre ✅ **umgesetzt (22.07.2026)**

**Warum zuerst:** „Jede Mutation setzt die Re-Sync-Sperre" ist strukturell zwingend (§7), sonst überschreibt ein Re-Import jede Anonymisierung — das wäre ein DSGVO-Verstoß nach erfolgter Löschung.

### 1.1 Migrationen ✅

- ✅ `press_releases`: `sync_locked_at` (nullable timestamp) + `sync_lock_reason` (string) — `2026_07_22_151506_add_sync_lock_to_press_releases_table.php`. **Umsetzungshinweis:** Wegen des FULLTEXT-Index kann MySQL hier nicht INSTANT arbeiten (voller Tabellen-Copy, ~175k Zeilen); die Migration nutzt deshalb **ein kombiniertes ALTER** für beide Spalten statt zweier Blueprint-Einzelstatements und verzichtet auf `after()`-Positionierung. Merkregel für spätere Migrationen an `press_releases`: Spalten-Adds immer bündeln.
- ✅ `legal_requests` erweitert — `2026_07_22_151507_add_meldeverfahren_fields_to_legal_requests_table.php`:
  - Neue `LegalRequestType`-Cases: `Correction` (Spur A), `Depublication` (Spur C), `Change` (Spur D). `Dsgvo` bleibt Spur B.
  - Neue Spalten: `verified_at`, `verification_method` (Enum `LegalRequestVerificationMethod`: `magic_link`/`manual`/`logged_in`), `single_purchase_id` (FK, Spur C/D), `executed_at`.
  - Diff-/Schwärzungsdaten kommen in `payload` (json, existiert) — Nutzung ab Phase 4/5.
- ✅ Neue Tabelle `press_release_redaction_snapshots` (`2026_07_22_151507_create_..._table.php`) + Modell `PressReleaseRedactionSnapshot` mit `capture()` (Cast `encrypted:array`, `purge_after` aus `config('legal.snapshot_retention_days')`), Scope `dueForPurge()` und Factory. → Reversibilität ohne Klartext-Altwerte im Log; Test sichert ab, dass der Klartext nie unverschlüsselt in der DB liegt.

### 1.2 Re-Sync-Sperre durchsetzen ✅

- ✅ `PressRelease::lockSync(string $reason)` + `isSyncLocked()` — idempotent (erste Sperre bleibt maßgeblich), schreibt Verlaufs-Eintrag (neuer `ActivityType::SyncLock`, Badge rot). Wird von **jeder** Meldeverfahren-Mutation aufgerufen (Phasen 2, 4, 5, 6, 7).
- ✅ `PressReleaseImporter`: gesperrte PMs werden **auch bei `--force`** übersprungen (Guard `isSyncLocked()` vor `updateOrCreate`, zählt als „Übersprungen").
- ℹ️ `LegacyPressReleaseController`: kein Guard nötig — die Legacy-API hat heute **keinen Update-Pfad** (`store()` legt immer neu an, `show()` liest nur). Sollte je ein Update-Endpunkt entstehen, gehört der `sync_locked_at`-Check (→ `409`/`423`) dorthin.

### 1.3 Tests ✅ (`tests/Feature/Legal/SyncLockTest.php`, 5 Tests grün)

- ✅ `lockSync()`: Felder gesetzt, Verlaufs-Eintrag, idempotent (zweiter Aufruf ändert nichts).
- ✅ Importer überspringt gesperrte PM trotz `--force` (Schwärzung bleibt erhalten); ungesperrte PM wird weiter aktualisiert.
- ✅ Snapshot: Klartext liegt nie unverschlüsselt in der DB, `purge_after` aus Config, `dueForPurge()`-Scope.
- Angrenzende Bestandstests (Importer-Datumslogik, LegalRequest, ActivityLog — 23 Tests) weiter grün; Pint sauber.

---

## Phase 2 — Anonymisierungs-Engine + Admin-Ausführung ✅ **umgesetzt (22.07.2026)**

**Ziel:** Der Admin kann aus der bestehenden Queue (`admin/legal-requests/show`) eine DSGVO-Anfrage tatsächlich **ausführen** statt nur „resolved" zu klicken. Das trägt sofort die Referenzfälle Huraux/Gleue/Rambo.

### 2.1 Service `App\Services\PressRelease\AnonymizationService` ✅

- ✅ `preview(PM, Begriffe, Ersetzungswert)`: Pflicht-Vorschau ohne Mutation — Treffer + Nachher-Wert je Feld (`title`, `subtitle`, `text`, `boilerplate_override`, `keywords`; `teaser_*` sind Integer und entfallen). Genutzt von Admin (Phase 2), wiederverwendbar im Self-Service (Phase 5).
- ✅ Ersetzung über Wortgrenzen: **Unicode-Lookarounds** (`(?<![\pL\pN])…(?![\pL\pN])`) statt `\b`, damit Umlaute korrekt begrenzen — „Max" zerlegt „maximal" nicht, „Mustermanns" bleibt ohne explizite Variante stehen. Case-insensitive, längste Begriffe zuerst. Ersetzungswert default `[entfernt]`, nie Leerstring.
- ✅ `execute()`: Transaktion — verschlüsselter Snapshot (`capture()`: Felder, Kontakt-IDs, Bild-/Anhang-Metadaten, Begriffe) → Replace → Kontakt-Pivot lösen (optional) → markierte **Bilder/Anhänge** soft-löschen, auf public-Disk zusätzlich Dateien inkl. Varianten physisch löschen (sonst per Direkt-URL erreichbar) → `lockSync()` → Sitemap-Cache aller Hosts invalidieren (interne Suche liest live) → `ActivityLog` (neuer Typ `Anonymization`) **ohne Alt-Werte und ohne Schwärzbegriffe**.
- ✅ Kein KI-Gate, kein Credit-Abzug — der Service berührt weder Klassifikations-Routing noch `CreditWalletService`.

### 2.2 Admin-Queue ausgebaut (`admin/legal-requests/show`) ✅

- ✅ Panel „Anonymisierung (Schwärzung)" bei `type=dsgvo`/`personal_rights` mit PM-Bezug und offenem Status: Schwärzbegriffe (ein Begriff/Variante pro Zeile), Ersetzungswert, Checkbox „Kontakt-Zuordnungen lösen", Bild-Auswahl → **Pflicht-Vorschau** (Ausführen-Button erscheint erst danach; Ausführen ohne Vorschau wird serverseitig abgewiesen) → „Anonymisieren ausführen" oder **„Stattdessen depublizieren"** (Matrix-Test §1/§2 menschlich; Vanity-PM → Depublizierung als milderes Restmittel).
- ✅ Depublizieren-Aktion: `PressReleaseService::depublish()` + `lockSync()` + Aktenvermerk über `admin_note`; setzt `executed_at` + `resolved`. Deckt den Fallback „Kanal tot" (Huraux) ab — Admin führt nach manueller Prüfung aus, umkehrbar (Status-Restore, `published_at` bleibt).
- ✅ Detail zeigt `verification_method`/`verified_at` („nicht verifiziert" bis Phase 3) und `executed_at`. Queue-Index-Spalte folgt mit Phase 3, wenn Verifikation real befüllt wird.

### 2.3 Purge-Command ✅

✅ `snapshots:purge` (`PurgeRedactionSnapshots`, Scope `dueForPurge()`), Scheduler täglich 03:10 mit `withoutOverlapping` + Failure-Alert in `routes/console.php`.

### 2.4 Tests ✅ (9 neue Tests grün)

- ✅ `AnonymizationServiceTest`: Wortgrenzen/Varianten/Genitiv, Vorschau mutiert nicht, Snapshot verschlüsselt (Klartext weder im DB-Rohwert noch im Verlauf), Kontakte gelöst, Sperre gesetzt, Bilder soft-gelöscht + public-Dateien entfernt, Purge-Command löscht nur fällige Snapshots.
- ✅ `AdminLegalRequestExecutionTest`: Vorschau→Ausführen-Happy-Path, Ausführen ohne Vorschau abgewiesen, Depublizieren-Alternative, verboten ohne `compliance:manage`.
- Angrenzende Suiten (37 Tests: Legal, Admin-Grenzen, ActivityLog) weiter grün; Pint sauber.

---

## Phase 3 — Magic-Link-Verifikation + Intake-Trichter ✅ **umgesetzt (22.07.2026)**

**Ziel:** Die Meldeseite wird vom Kontaktformular zum **Deflektions-Trichter**: URL einfügen → System schlägt hinterlegten Kontakt nach → Magic-Link an diesen → verifizierter Zugang zur Anliegen-Auswahl.

### 3.1 Intake ✅ (`PressReleaseReportController`, Routen `melden/pm*` in `routes/web.php`)

- ✅ Neue Seite „PM melden/ändern" (`web/melden-pm.blade.php`): URL-Feld → `matchPublishedRelease()` → bei PM-Fund + Pressekontakt-Mail (`PressRelease::pressContactEmail()`: PM-Kontakt via Pivot, Fallback Firmen-Adresse, ohne PortalScope) Magic-Link-Versand. Vier-Anliegen-Tabelle mit Kosten **vorab** auf der Seite (Anti-Zombie). Callout-Einstieg auf der bestehenden `melden`-Übersichtsseite.
- ✅ Adresse **nie angezeigt/übernommen** — nur maskiert („p***@firma.example").
- ✅ Kanal tot: Hinweis mit Link auf das bestehende manuelle Formular (`melden/kontaktdaten`) — dort verifiziert der Admin anhand eines Nachweises (§6-Fallback, Ausführung über Phase 2). *(Bewusst kein neues Formular — der DSA-Weg existiert bereits.)*
- ✅ Rate-Limits: pro IP (5/h) **und** pro PM (`legal.report_links_per_day` = 3/Tag) + Honeypot + `throttle:10,1`.

### 3.2 Magic-Link ✅

- ✅ `MagicLinkGenerator::createReportLink()`: purpose `press_release_report` (**Enum-Migration** `2026_07_22_171134_add_report_purpose_to_magic_links_table.php` — `purpose` ist ein DB-Enum!), payload `{press_release_id, contact_email}`, `user_id` = PM-Owner, TTL `legal.report_link_ttl_hours` = 72; ältere unverbrauchte Report-Links derselben PM werden entwertet.
- ✅ Mailable `PressReleaseReportLink` (queued, `afterCommit`) mit Hinweis „kein Anliegen gestartet? → ignorieren".
- ✅ Consume-Route (`melden/pm/verifizieren/{token}`, throttled): atomares Claim (Muster `MagicLinkConsumeController`) → Session-Marker (`legal.report_session_minutes` = 60) → Anliegen-Auswahl. Kein Login.
- ✅ Eingeloggter Creator: POST `me.press-releases.report` (prüft `accessibleBy`, `verification_method=logged_in`), Button „Ändern/Melden" auf der Kunden-PM-Detailseite (nur published).

### 3.3 Anliegen-Auswahl ✅ (`web/melden-pm-anliegen.blade.php`)

- ✅ Vier Spuren mit Kosten-Labels (kostenlos / kostenlos / 35 € / 10 €) + Beschreibung; Auswahl erzeugt `LegalRequest` mit `type`, `verified_at`, `verification_method`, `requester_email` = Kontaktadresse; Eingangsbestätigung (`LegalRequestReceived`) + Operator-Mail. Bremse „1 offene Anfrage pro PM/Typ" beim Store durchgesetzt.
- ℹ️ **Interim bis Phase 4–7:** Alle vier Spuren landen zunächst als verifizierte Anfragen in der Admin-Queue (DSGVO/Depublizierung dort seit Phase 2 direkt ausführbar). Seiten-Text verspricht ehrlich: kostenpflichtige Anliegen erst nach Zahlungsaufforderung, keine Kosten ohne Bestätigung. Die Self-Service-Ausführung (Spur A sofort, C/D mit Checkout) ersetzt das schrittweise.
- ✅ Lang-Keys `static.pm_report.*` in `lang/de` + `lang/en`.

### 3.4 Tests ✅ (`PressReleaseReportFlowTest`, 10 Tests grün)

Link geht an hinterlegte, nie an Formular-Adresse (maskiert); unbekannte URL abgelehnt; toter Kanal → manueller Fallback; Rate-Limit pro PM; Consume nur einmal; Anliegen landet verifiziert in der Queue; Doppel-Anfrage geblockt; Session-Pflicht; Owner-Einstieg; Fremd-User 403.

---

## Phase 4 — Spur A: Kleine Korrektur (kostenlos, sofort) ✅ **umgesetzt (22.07.2026, panel-first)**

**Bestätigte Entscheidung:** Korrekturen gehen **sofort live** (kein Admin-Gate), landen im Verlauf und sind über den verschlüsselten Snapshot **rückgängig machbar**.

- ✅ `CorrectionService` (`app/Services/PressRelease/CorrectionService.php`):
  - `classify()`: relative Änderungsdistanz je Feld (`title`, `subtitle`, `text`, `keywords`), Gate ≤ `legal.correction_max_distance_percent` (15 %, E5). **Hybrid-Metrik:** kurze Felder zeichenbasiert (ein Tippfehler im Titel bleibt „klein"), lange Texte wortbasiertes Levenshtein-DP (PHPs `levenshtein()` ist auf 255 Bytes begrenzt); Vergleich auf `strip_tags`-Basis — reine Markup-Änderungen zählen nicht. Der Nutzer wählt die Einstufung **nie selbst**.
  - `apply()`: Snapshot (Rückgängig-Basis) → Felder schreiben (Text durch `PressReleaseHtmlSanitizer`) → `lockSync()` → `LegalRequest` (`correction`, `resolved`+`executed_at`, verifiziert) → Verlauf (`ActivityType::Correction`) → Sitemap-Cache → `reprocessAfterContentChange()` (Re-Score ohne Status-Wirkung, kein Freigabelauf).
  - Bremse: `legal.corrections_per_week` = 2 (DB-basiert über ausgeführte Correction-Requests, auditierbar).
  - `restoreSnapshot()`: spielt Vorher-Stand zurück (Felder + Kontakte; Bilder nur wenn Dateien noch existieren), Sperre bleibt, Verlaufs-Eintrag.
- ✅ **Panel-Abschnitt „Änderung & Korrektur"** (Kunden-PM-Detail, direkt über Depublikation): ein Einstieg, Formular vorbefüllt → Pflicht-Vorschau zeigt Einstufung + Distanz je Feld → **klein**: „Kostenlos speichern — sofort live"; **groß**: „Als kostenpflichtige Änderung einreichen (10 €)" — Interim bis zum Phase-7-Checkout: erzeugt verifizierte `Change`-Anfrage in der Admin-Queue (Doppel-Bremse), Zahlungsaufforderung folgt.
- ✅ **Admin-Rückgängig**: Button „Rückgängig machen (Snapshot)" in der Queue bei ausgeführten Anfragen mit Snapshot (gilt für Korrektur **und** Anonymisierung, bis zur Löschfrist) — Anfrage geht zurück auf „In Bearbeitung".
- ✅ Gemeinsame Cache-Invalidierung nach `App\Support\WebCaches::forgetSitemaps()` extrahiert (genutzt von Correction + Anonymization).
- ✅ Tests (11 neue, alle grün): Tippfehler klein / Umschreibung groß / Markup-only = keine Änderung, Sofort-Live mit Snapshot+Sperre+Verlauf, Zu-groß-Abwehr, Wochen-Bremse, Restore (Service + Admin-UI), kein Credit-Bezug, Panel-Happy-Paths, Vorschau-Pflicht.
- ℹ️ **Noch offen aus Phase 4:** dieselben Formulare im verifizierten Web-Bereich (Magic-Link-Besucher) — aktuell erzeugt Spur A dort noch eine Queue-Anfrage; die `CorrectionService`-Engine ist dafür wiederverwendbar. Nutzer-Bestätigungsmail nach Korrektur bewusst weggelassen (Owner sieht das Ergebnis sofort im Panel), für den Web-Pfad nachrüsten.

## Phase 5 — Spur B: DSGVO-Einreichung self-service → Admin-Gate

- Formular: Strukturfelder zum Leeren angeboten + Freitext-Schwärzwerte inkl. Varianten → Pflicht-Diff (Preview aus `AnonymizationService::preview()`) → **Einreichung** (nicht Ausführung): `LegalRequest` `type=dsgvo`, payload = Schwärzungsauftrag, Status `open`.
- Admin-Queue zeigt den vorbereiteten Diff (Phase-2-Editor, vorbefüllt) → Admin bestätigt **anonymisieren** oder wählt **depublizieren** → `AnonymizationService::execute()` bzw. `depublish()` + Snapshot.
- Bestätigungsmail an Antragsteller bei Einreichung (Fristbeginn dokumentiert, Vorgangsnummer `M-{id}`) und bei Ausführung.
- **Wording:** In der UI „Schwärzung/Entfernung personenbezogener Daten", nicht „Anonymisierung im DSGVO-Vollsinn" (Guardrail — nicht überversprechen).
- Bremse: 1 offene Anfrage pro PM/Typ (Logik existiert konzeptionell in `LegalRequestStatus::isOpen()` — beim Store durchsetzen).
- Tests: Einreichung erzeugt keinen Datenbank-Write an der PM; Ausführung nur durch Admin; nie Credits.

## Phase 6 — Spur C: Depublizierung (35 €, Gast-Checkout, umkehrbar)

- **Wiederverwendung:** `StripeCheckoutService::forDepublication()` + `ProcessStripeWebhook::fulfillDepublication()` existieren. Neu ist der **Gast-Pfad**: Checkout ohne Login aus dem verifizierten Bereich.
  - Variante (empfohlen): `SinglePurchase` ohne `user_id`-Zwang bzw. auf PM-Owner gebucht, `legal_request_id` als Referenz; Stripe-Session mit `customer_email` = verifizierte Kontaktadresse. Webhook-Fulfillment bleibt identisch (idempotent, row-locked).
- Nach Zahlung: `depublish()` → Tombstone (410 + noindex existiert) → `lockSync()` → `LegalRequest` `resolved`/`executed_at` → Bestätigungsmail mit Hinweis auf Suchindex-Trägheit (Cache-Aktualisierung bei Google dauert — Textbaustein).
- **Reversibilitätsfenster:** `depublished_at` + `config('legal.reversal_window_days')` (Standard **14 Tage**, E3): innerhalb der Frist Wiederherstellung über Admin (Snapshot nicht nötig — Status-Restore reicht, `published_at` bleibt). Hinweis im Bestätigungsschritt vor Zahlung („umkehrbar bis …").
- Preis: 35 € live via `config('billing.depublication_price_cents')` (existiert). Die systemische 25-Credit-Variante für eingeloggte Kunden bleibt unberührt — aber Test sichert ab, dass der **DSGVO-Pfad (Spur B) nie** in diesen Checkout mündet.
- Tests: Gast-Checkout-Fulfillment, Reversibilitätsfenster, Tombstone + Sitemap-Ausschluss.

## Phase 7 — Spur D: Änderung (10 €, KI-Freigabelauf)

- Preis: **10 €** (E1), neuer Config-Wert `billing.change_price_cents` = 1000.
- Formular: neuen Text/Feldwerte eingeben (Voll-Editor light, analog `customer/press-releases/edit`-Formularregeln aus `ProvidesPressReleaseFormRules`) → Preis anzeigen → Gast-Checkout (`SinglePurchaseType`-Case `Change`, `adHocLineItem`-Muster).
- Nach Zahlung: Änderung in **Entwurfs-Kopie/Pending-Payload** halten (nicht direkt live), dann `ClassifyPressRelease` auf den neuen Inhalt:
  - **grün/gelb** → Änderung anwenden, PM bleibt/wird published, `lockSync()`, Kauf auf `Consumed`, Mail „live".
  - **rot** → abgelehnt, Änderung verworfen, **kein Verbrauch** (E2): Kauf bleibt un-konsumiert, Antragsteller kann mit überarbeitetem Text erneut einreichen ohne erneut zu zahlen; Mail mit Ablehnungsgrund.
- KiAudit-Trail entsteht automatisch über den bestehenden Job.
- Tests: rot verwirft ohne PM-Änderung; grün wendet an; Webhook-Idempotenz.

## Phase 8 — Querschnitt-Abschluss

1. **Template-/Text-Stopp connektar (Sofortmaßnahme §7):** Alle Frontend-/Mail-Texte prüfen (`melden*`-Views, Mail-Templates, `lang/`-Strings): kein Verweis mehr auf „kostenfreier Weg über connektar"; Ersatz: Verweis auf die neue Meldeseite. *(Antwortvorlagen außerhalb des Systems sind organisatorisch zu ändern — nicht Teil des Codes, im Rollout-Termin erwähnen.)*
2. **Auslieferungs-Checkliste (§5) verifizieren:** Tombstone 410 ✅, `noindex` im Tombstone-View prüfen/ergänzen, Sitemap schließt Archived aus (Scope `visibleInArchive` prüfen) + Cache-Invalidierung nach Mutation, interne Suche (FULLTEXT auf `press_releases` — liest live, kein Rebuild nötig; Test ergänzen), **RSS/Feeds: existieren noch nicht, sind aber geplant** (E8) — beim künftigen Feed-Feature zwingend: Archived/anonymisierte PMs ausschließen und Feed-Cache bei Meldeverfahren-Mutationen invalidieren (Anforderung dort einplanen).
3. **Eskalationsstufen-Texte:** Mail-Vorlagen zweistufig — Angebots-/Eingangsmail ohne Aufsichtsbehörden-Hinweis, Ablehnungsmail (aus Admin-Queue `reject()`) mit Art.-12-Pflichthinweis. Textbausteine in `lang/`.
4. **Doku:** kurzer Abschnitt in `docs/konzept/` bzw. Update dieses Ordners; `CLAUDE.md` unberührt.
5. **Gesamt-Testlauf:** `vendor/bin/sail artisan test --compact` + Pint.

---

## 2. Getroffene Entscheidungen (bestätigt 22.07.2026)

| # | Entscheidung | Umsetzung im Plan |
|---|---|---|
| **E1** | Zwei getrennte Preise: **35 €** = komplette Depublizierung einer PM (Spur C), **10 €** = Änderung einer PM (Spur D) | Spur C: `billing.depublication_price_cents` (existiert); Spur D: neuer Config-Wert `billing.change_price_cents` = 1000 → Phase 7 |
| **E2** | Bei KI-„rot" **kein Verbrauch** — es wird nichts abgezogen | Kauf bleibt un-konsumiert (Status nicht `Consumed`); der Antragsteller kann mit überarbeitetem Text erneut in den Freigabelauf, ohne erneut zu zahlen → Phase 7 |
| **E3** | Reversibilitätsfenster als **Config-Variable, Standard 14 Tage** | `legal.reversal_window_days` = 14 → Phase 6 |
| **E4** | Snapshot-Löschfrist als **Config-Variable, Standard 30 Tage** | `legal.snapshot_retention_days` = 30; bestimmt `purge_after` → Phasen 1.1 / 2.3 |
| **E5** | Levenshtein-Schwellwert Spur A als Config-Variable; Start 15 %, am 22.07. abends auf **5 %** verschärft (+ Mini-Edit-Ausnahme ≤ 2 Zeichen) | `legal.correction_max_distance_percent` = 5, `legal.corrections_per_week` = 1 → Phase 4 |
| **E6** | Spur B bleibt **admin-gegated**; Automatisierung später bei guter Kalibrierung | Wie geplant → Phasen 2 / 5 |
| **E7** | Magic-Link-TTL/Session: **bestehende System-Mechanik wiederverwenden** | Kein Sondersystem — `MagicLinkGenerator`-Muster mit purpose-spezifischer TTL wie bei `login`/`press_release_access`; TTL des Report-Links als Config-Wert analog der vorhandenen Defaults → Phase 3 |
| **E8** | **RSS/Feeds werden in Zukunft entwickelt** | Anforderung fürs künftige Feed-Feature vorgemerkt: Archived/anonymisierte PMs ausschließen, Feed-Cache bei Meldeverfahren-Mutationen invalidieren → Phase 8 / Abschnitt 3 |

## 3. Nicht-Code-Punkte aus den Konzeptdokumenten (zur Nachverfolgung, außerhalb dieses Plans)

- Anwaltsagenda §10 (Unentgeltlichkeits-Grenze, UWG connektar, Realnamen-Änderung, Art. 19 Syndication, AI-Act-Co-Betreiber).
- Syndication-Vertrag mit connektar (Änderungs-/Löschpropagierung, Art.-19-Zuständigkeit einfordern).
- Externe Antwortvorlagen (Mail-Templates außerhalb des Systems) vom connektar-Verweis befreien.
- **RSS/Feed-Feature** (künftige Entwicklung, E8): muss Archived/anonymisierte PMs ausschließen und die Re-Sync-Sperre bzw. Mutationen des Meldeverfahrens respektieren (Cache-Invalidierung).

## 4. Testing & Qualität (durchgehend)

- Pest-Feature-Tests je Phase (Konventionen: `RefreshDatabase` global, `RolesAndPermissionsSeeder` im `beforeEach`, Factories `PressRelease::factory()->published()->forPortal(...)`; Vorbilder: `tests/Feature/Billing/DepublicationTest.php`, `tests/Feature/LegalRequestTest.php`, `tests/Feature/Admin/AdminPressReleaseActionsTest.php`).
- Kritische Invarianten als eigene Tests: (a) DSGVO-Pfad zieht **nie** Credits/Checkout, (b) jede Mutation setzt `sync_locked_at`, (c) Importer/API respektieren die Sperre, (d) ActivityLog enthält keine Klartext-Altwerte, (e) Magic-Link geht nie an Formular-Adresse.
- `vendor/bin/sail bin pint --dirty` vor jedem Abschluss.

## Änderungshistorie

| Datum | Änderung |
|---|---|
| 22.07.2026 | Erstfassung auf Basis Ist-Stand-Analyse der Codebasis (Meldeverfahren v0.1, Magic-Link-, Depublizierungs- und Billing-Infrastruktur) |
| 22.07.2026 (rev. 2) | Entscheidungen E1–E8 bestätigt und eingearbeitet: Spur D = 10 €, Depublizierung = 35 €; kein Verbrauch bei KI-rot; Reversibilitätsfenster 14 Tage / Snapshot-Frist 30 Tage / Levenshtein 15 % jeweils per Config; Magic-Link nutzt bestehende Mechanik; RSS/Feeds als künftiges Feature vorgemerkt |
| 22.07.2026 (rev. 3) | **Phase 1 umgesetzt:** 3 Migrationen, `lockSync()`/`isSyncLocked()`, Importer-Guard (auch `--force`), `LegalRequestType`-Cases + `LegalRequestVerificationMethod`, Snapshot-Modell mit `capture()`/Factory, `ActivityType::SyncLock`, Config E3–E5 in `config/legal.php`, 5 neue Pest-Tests grün. Erkenntnisse: Legacy-API hat keinen Update-Pfad (API-Guard entfällt vorerst); Spalten-Adds an `press_releases` wegen FULLTEXT-Index immer als ein kombiniertes ALTER (voller Tabellen-Copy, kein INSTANT) |
| 22.07.2026 (rev. 4) | **Phase 2 umgesetzt:** `AnonymizationService` (Unicode-Wortgrenzen-Replace, Pflicht-`preview()`, transaktionales `execute()` mit Snapshot/Kontakt-Detach/Bild-Löschung/Sperre/Sitemap-Invalidierung), Admin-Queue-Panel Anonymisieren/Depublizieren mit Pflicht-Vorschau, `ActivityType::Anonymization`, `snapshots:purge` + Scheduler, 9 neue Pest-Tests grün |
| 22.07.2026 (rev. 5) | Admin-Schwärzungs-Editor: kompletter PM-Inhalt als kopierbare Vorschau (vorher/nachher in einem Block), Ersetzungswert vorbefüllt. **Phase 3 umgesetzt:** Intake `melden/pm` (Kosten-Tabelle vorab, Honeypot, IP+PM-Rate-Limits), `createReportLink` + Enum-Migration `press_release_report`, Mailable, atomare Verifikation mit Session-Marker, Anliegen-Auswahl erzeugt verifizierte Queue-Anfragen (Bremse 1 offene Anfrage/PM/Typ), toter-Kanal-Fallback auf manuelles Formular, Owner-Einstieg aus dem Kunden-Panel, Lang-Keys de/en, 10 neue Pest-Tests grün |
| 22.07.2026 (rev. 6) | **Phase 4 umgesetzt (panel-first, Entscheidung: sofort live + rückgängig machbar):** `CorrectionService` mit Hybrid-Levenshtein-Gate (Zeichen kurz / Wörter lang, strip_tags-Basis), Panel-Abschnitt „Änderung & Korrektur" über der Depublikation (ein Einstieg, System stuft klein/groß ein; groß = Interim-Queue-Anfrage bis Phase-7-Checkout), Wochen-Bremse per Config, Snapshot-Restore im Admin (Korrektur + Anonymisierung), `ActivityType::Correction`, `WebCaches::forgetSitemaps()` extrahiert, 11 neue Pest-Tests grün |
| 22.07.2026 (rev. 7) | Konfig verschärft (5 % / 1 Korrektur pro Woche) + Mini-Edit-Ausnahme ≤ 2 Zeichen im Gate; Abschnitt „Stand & was noch fehlt" für den Wiedereinstieg ergänzt; Tagescommit |