QA-Checkliste B-G vertieft (Nachpruefung 10.07.)

- Alle referenzierten Beleg-Tests verifiziert, Suite 1156 gruen
- B-G um Features 07.-10.07. ergaenzt: Kontakt-Queue/-Widget,
  Ablehnungsbegruendung, KI-Kennzeichnung (Submit/API/Label),
  Tarifwechsel, Add-ons, USt/eVatR, Rechnungsseite, Depublikation
  komplett, PM-Tracking, Boersenticker, Monitoring-Alerts
- Frontend-Umbau-Vorbehalt in F aufgehoben (Umbau committet 09.07.)
- Befund dokumentiert: Page-Data-Cache ohne Publish-Invalidierung
  (max. 5 Min. Verzug, bewusster Tradeoff, kein Blocker)
- Release-Plan: naechste-Schritte-Block nachgezogen

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

dev/release/entwicklungsplan-release.md

@@ -41,9 +41,9 @@ R2.2+R2.3 erledigt: Hub-Landing komplett ueberarbeitet (datengetriebenes Tarif-G
 **Ausgangslage:** Arbeitsbaum ist aufgeraeumt — der gesamte WIP ist in 7 Commits auf `fix/zeitzone-europe-berlin` (~187 vor `main`), Suite gruen (1149). Uncommittet bleiben nur bewusst: `sidebar.blade.php` (User), der `docs/`-Mount + `config/pressekonto.code-workspace`, zwei Dev-Screenshots.
 
 **Als Naechstes in meiner Hand (kein externer Input noetig), Empfehlung in dieser Reihenfolge:**
-1. **QA-Checkliste B–G vertiefen** (`qa-checkliste.md`) — Abschnitte Admin-Backend, Customer-Panel, Billing, API, Frontend, Betrieb gegen den aktuellen Code durchgehen und konkretisieren, was wirklich nur noch manuell/Staging bleibt. Reine Pruef-/Doku-Arbeit, gut fuer den Einstieg.
-2. **R4.3 Dedup** (optional, „nur wenn Zeit") — Release-Card vereinheitlichen, Industrie-Icon-Map → Config, Inline-SVGs → Icon-Set. Kein Blocker.
-3. **R6.5 optional:** die drei `user_filter_presets`-Migrations zusammenfuehren (Hygiene vor Go-Live).
+1. ~~**QA-Checkliste B–G vertiefen**~~ **erledigt 10.07.:** alle Beleg-Tests verifiziert (Suite 1156 gruen), B–G um die Features 07.–10.07. ergaenzt (KI-Kennzeichnung, Tracking, Kontakt-Queue, Tarifwechsel, eVatR, Monitoring u. a.), Frontend-Umbau-Vorbehalt in F aufgehoben. Neuer (unkritischer) Befund: Page-Data-Cache ohne Publish-Invalidierung, max. 5 Min. Verzug auf Home/Kategorie — dokumentiert, kein Blocker. Jetzt sind die manuellen Browser-/Staging-Durchgaenge (User) dran.
+2. **R4.3 Dedup** (optional, „nur wenn Zeit") — Release-Card-Varianten (feed-item, focus-hero, focus-side-item, feed-top-item) vereinheitlichen, Inline-SVGs (13 Web-Komponenten) → Icon-Set; Industrie-Icon-Map hat der Frontend-Umbau bereits erledigt. Kein Blocker.
+3. ~~**R6.5 optional:** die drei `user_filter_presets`-Migrations zusammenfuehren~~ **gegenstandslos (10.07.):** es existiert nur noch eine konsolidierte Migration.
 
 **Wartet auf Dich / extern (nicht durch mich abschliessbar):** R6.5 Branch merge + Release-Tag (Dein Go; Push ist erfolgt) · R1.2 Stripe-Live · R1.4 Preisfreigabe · R1.5 Refund-Entscheidung · (~~R2.5 legal-request-Texte~~ erledigt 10.07., Wortlaut aus freigegebenem Meldeverfahren) · R5.4 Favicons · R6.3 Staging-Rehearsal · R6.4 Go-Live-Kette · Postfach `info@pressekonto.com` · anwaltliche Freigabe.
 

dev/release/qa-checkliste.md

@@ -1,11 +1,16 @@
-# Manuelle QA-Checkliste (R6.1) — Stand 06.07.2026
+# Manuelle QA-Checkliste (R6.1) — Stand 10.07.2026
 
 Quelle: `dev/migration 2026/06-FEATURES-SCOPE.md` §15, aktualisiert auf den echten
 Funktionsstand. **Vorprüfung 06.07. (Claude):** Jeder Punkt wurde gegen Code und
 Testsuite geprüft; „Automatisiert belegt" heißt: der Flow ist End-to-End auf
 HTTP-/Service-Ebene durch grüne Tests abgedeckt — manuell bleibt die visuelle
-Abnahme im Browser. Testzugänge lokal: `admin@pressekonto.test` / `password`
-(Admin), `test@example.com` / `password` (Customer, Seeder).
+Abnahme im Browser. **Nachprüfung 10.07. (Claude):** alle referenzierten
+Beleg-Tests existieren, Suite 1156 grün; Abschnitte B–G um die seit 06.07.
+gebauten Features ergänzt (KI-Kennzeichnung, PM-Tracking, Kontakt-Queue,
+Tarifwechsel, eVatR, Monitoring, Börsenticker, Page-Cache); der
+Frontend-Umbau ist seit 09.07. committet — die dadurch blockierten visuellen
+Abnahmen (F) sind entsperrt. Testzugänge lokal: `admin@pressekonto.test` /
+`password` (Admin), `test@example.com` / `password` (Customer, Seeder).
 
 Empfohlene Reihenfolge: erst lokal durchklicken, dann dieselbe Liste beim
 Staging-Rehearsal (R6.3) mit echtem Datenbestand wiederholen.
@@ -24,41 +29,57 @@ Staging-Rehearsal (R6.3) mit echtem Datenbestand wiederholen.
 - [ ] **PM-Workflow Admin**: Create → Draft → Publish → Mail an Autor → sichtbar im Frontend — Automatisiert: `Admin/AdminPressReleaseActionsTest`, `Admin/AdminPressReleaseSchedulingTest`, `Admin/AdminPressReleaseShowTest`. Manuell: einmal komplett, Frontend-Sichtbarkeit auf beiden Spokes prüfen.
 - [ ] **Recht & Compliance-Queue** — Automatisiert: `LegalRequestTest`, `Web/ReportFormTest` (Vorgangsnummern, Eingangsbestätigung). Manuell: Meldung über /melden/rechtswidrig absenden → taucht mit M-Nummer in der Queue auf → erledigen.
 - [ ] **Admin-Statuswechsel/Depublikation sichtbar** — Automatisiert: `Billing/DepublicationTest` (Tombstone 410). Manuell: depublizierte PM im Frontend aufrufen (Entfernt-Hinweis statt Inhalt).
+- [ ] **Kontakt-Queue** (neu 09.07.) — Web-Kontakt-Widget (`contact-launcher`) persistiert Anfragen zusätzlich zur Brand-Mail in `contact_messages`. Automatisiert: `Web/ContactFormTest`, `Admin/ContactMessagesAdminTest`. Manuell: Anfrage übers Widget absenden → erscheint in der Admin-Queue, Status auf „erledigt" setzen.
+- [ ] **Ablehnungsbegründung im Editor** (UX-Runde 07.07.) — Ablehnung mit Begründung direkt im Admin-Editor; Kunde sieht die Begründung an der PM. Automatisiert: `Admin/AdminPressReleaseShowTest` (Rejection-Banner mit letzter Begründung). Manuell: einmal ablehnen und Kundenansicht prüfen.
 
 ## C. Customer-Panel
 
-- [ ] **PM-Workflow Customer**: Create → Draft → Submit → Admin sieht zur Prüfung — Automatisiert: `PressReleaseBookingGateTest` (Submit-Gate), `PressReleaseQuotaTest`, `PressReleaseWithdrawalWaiverTest` (Archiv-Hinweis T2neu). Manuell: einmal komplett inkl. Submit-Modal (4 Schalter).
+- [ ] **PM-Workflow Customer**: Create → Draft → Submit → Admin sieht zur Prüfung — Automatisiert: `PressReleaseBookingGateTest` (Submit-Gate), `PressReleaseQuotaTest`, `PressReleaseWithdrawalWaiverTest` (Archiv-Hinweis T2neu), `PressReleaseAiDeclarationTest` (KI-Pflicht-Deklaration Art. 50 KI-VO, neu 09.07.). Manuell: einmal komplett inkl. Submit-Modal — jetzt inkl. KI-Deklaration für Text/Bilder; ohne Deklaration muss der Submit blocken. Editor-UX neu (09.07.): Kategorie in der Schreibfläche, Bild-Upload als Modal-Flow — visuell abnehmen.
 - [ ] **Image-Upload**: mehrere Bilder, Preview-Flag, Rechteangaben — Automatisiert: `PressReleaseImageLicenseTest`, `SyncPressReleaseImagesTest`, Api-Upload: `Api/V1/PressReleaseImageApiTest` (16 MB, jpg/png/webp). Manuell: Drag&Drop, Sortierung, Preview-Wechsel visuell.
 - [ ] **Company-Logo-Upload** — Automatisiert: `SecurityHardeningTest` (ImageService, kein SVG/XSS). Manuell: Logo hochladen, Varianten in Firmenübersicht + Newsroom prüfen.
 - [ ] **Blacklist blockiert Publish** — Automatisiert: `PressReleaseBlacklistTest`. Manuell: PM mit Blacklist-Wort einreichen → automatische Ablehnung mit Begründung.
-- [ ] **Buchungsseite komplett**: Abo, Einzel-PM, Credits, Unternehmer-Checkbox (T1neu) — Automatisiert: `Billing/BookingsPageTest`, `Billing/CheckoutFlowTest`, `CreditTopupTest`. Manuell: Modal-Optik, USt-Aufschlüsselung, Checkbox-Zwang.
+- [ ] **Buchungsseite komplett**: Abo, Einzel-PM, Credits, Unternehmer-Checkbox (T1neu) — Automatisiert: `Billing/BookingsPageTest`, `Billing/CheckoutFlowTest`, `CreditTopupTest`. Manuell: Modal-Optik, USt-Aufschlüsselung, Checkbox-Zwang; Buchungs-/Verlängerungsdatum des Abos wird angezeigt (`SubscriptionPeriodResolver`, 09.07. — braucht Stripe-Daten, also Staging).
+- [ ] **Tarifwechsel im Buchungs-Modal** (neu 07.07.) — Abo-Swap mit anteiliger Verrechnung, Downgrade ohne Gutschrift erst zum Periodenende, Kontingent-Sperre beim Wechsel. Automatisiert: `Billing/CheckoutFlowTest`. Manuell auf Staging: Upgrade + Downgrade je einmal durchspielen.
+- [ ] **Add-ons Boost/Veröffentlichungsnachweis** — Buchung über Credits an der PM-Seite; Add-ons-Modal statt Toast bei fehlendem Guthaben (07.07.). Automatisiert: `BoostServiceTest`, `ProofPdfAndExtraPmTest`, `PressReleaseShowAddonsTest`. Manuell: Boost buchen, Nachweis-PDF herunterladen.
+- [ ] **PM-Statistiken sichtbar** (neu 10.07.) — Kachel „Aufrufe" + „Geteilt" (mit Kanal-Aufschlüsselung) auf der Kunden-PM-Seite. Automatisiert: `Web/PressReleaseTrackingTest`. Manuell: PM im Frontend aufrufen/teilen → Zahlen steigen.
 
 ## D. Billing & Stripe (Staging mit Stripe-Testmode)
 
 - [ ] **Stripe-Checkout End-to-End inkl. Webhook** — Automatisiert: `Billing/CheckoutFlowTest`, `Billing/StripeWebhookProcessingTest`, `CreditTopupTest` (Gutschrift genau einmal). Manuell auf Staging: echter Testmode-Checkout (Karte 4242…), Webhook via `stripe listen`, Buchung erscheint im Panel.
+- [ ] **USt korrekt** (vervollständigt 07.07.) — `automatic_tax` in der Checkout-Session, STR-Rechnungsspiegelung liest USt aus `total_taxes`, Profil-Rechnungsadresse ist Stripe-Rechnungsempfänger (Wallet-Daten überschreiben nicht). Automatisiert: `Billing/StripeWebhookProcessingTest`, `Billing/VatResolverTest`. Manuell auf Staging: Checkout mit DE-Adresse → 19 % ausgewiesen; Rechnung zeigt USt.
+- [ ] **USt-ID-Prüfung eVatR** (neu 08.07.) — vor jeder Buchung gegen EU-VIES geprüft, Stripe-Tax-IDs abgeglichen; eigene USt-IdNr. aus `BILLING_OWN_VAT_ID` [EXTERN: Live-Wert]. Automatisiert: `Billing/VatIdValidationServiceTest`. Manuell auf Staging: Buchung mit gültiger + ungültiger USt-ID.
+- [ ] **Rechnungsseite Kunde** (07.07.) — listet neue STR-/MAN-Rechnungen (STR verlinkt ins Stripe-Portal), Altsystem-Archiv nur für Bestandskunden. Automatisiert: `CustomerPortalTest`, `PanelConsolidationTest`. Manuell: Sichtprüfung mit einem Konto mit beiden Rechnungskreisen.
 - [ ] **Rechnungen**: STR-Kreis (Stripe/Billing-Portal) + MAN-Kreis (`billing:generate-manual-invoices`) — Automatisiert: `Billing/InvoiceNumberGeneratorTest`, `Billing/ManualInvoiceGenerationTest`. Manuell: Rechnung im Stripe-Billing-Portal abrufbar.
 - [ ] **Grandfathering**: Alt-Abo wird korrekt angezeigt/weiterberechnet, Bestandskunde sieht keinen Buchungs-Hinweis — Automatisiert: `Billing/GrandfatherLegacySubscriptionsTest`, `Billing/HasActiveBookingTest`, `Billing/LegacyBundleTest`. Manuell: mit echtem Grandfather-User nach dem Staging-Import (R6.3).
 - [ ] **Rechnungsadressen der Bestandskunden** (Befund 06.07.: ohne Adresse überspringt der MAN-Lauf die Vereinbarung → Bestandsschutz läuft am Periodenende aus) — Automatisiert: `Billing/LegacyBillingAddressImportTest`. Manuell nach Staging-Import: `legacy:import-billing-addresses --dry-run` prüfen, echter Lauf, dann die im Report gelisteten Kunden (leere/unparsebare Alt-Adressen) manuell nachpflegen oder anschreiben.
 - [ ] **Legacy-Rechnungen im Archiv** (Admin + Customer, PDF) — Automatisiert: `Admin/AdminLegacyInvoiceArchiveTest`, `LegacyInvoiceArchiveCommandTest`. Manuell: PDF-Download eines Altbelegs.
-- [ ] **Depublikations-Checkout** (35 € netto) — Automatisiert: `Billing/DepublicationTest`. Manuell auf Staging: einmal komplett bis Tombstone.
+- [ ] **Depublikations-Checkout** (35 € netto, O6) — Kauf wird als eingelöst markiert, erzeugt Rechnung + Bestätigungs-Mail (08.07.); abgebrochener Checkout blockiert nicht (07.07.). Automatisiert: `Billing/DepublicationTest`. Manuell auf Staging: einmal komplett bis Tombstone (410) inkl. Rechnung + Mail.
 
 ## E. API v1
 
 - [ ] **`POST /v1/press-releases` mit Sanctum-Token** — Automatisiert: `Api/V1/PressReleaseApiTest`, `PressReleaseSubmitApiTest`, `PressReleaseImageApiTest`, `CustomerDataApiTest`. Manuell: Token im Kundenkonto erzeugen (setzt aktive Buchung voraus), curl-Workflow aus der /api-Doku durchspielen.
 - [ ] **Legacy-API-Übernahme** (geändert 06.07., User-Entscheidung): Importierte Alt-Schlüssel bleiben gültig — als Bearer, per `X-ApiKey`/`api_key` und auf den `/service/…`-Pfaden; nur unbekannte Keys bekommen 410 mit Migrationshinweis. Automatisiert: `Api/LegacyApiCompatibilityTest`, `ApiAccessSecurityAndLoggingTest`. Manuell nach Staging-Import: `legacy:import-api-keys --dry-run` prüfen (lokal: 406 Keys), dann echter Lauf; einen echten Alt-Key gegen `/service/pressreleases` testen.
 - [ ] **Rate-Limit 60/min** — Automatisiert: abgedeckt. Manuell: entfällt.
+- [ ] **KI-Deklaration auch via API erzwungen** (neu 09.07.) — Submit ohne KI-Deklaration liefert einen Validierungsfehler (zentral in `PressReleaseService`, `AiDeclarationRequiredException` im API-Controller gemappt). Automatisiert: `PressReleaseAiDeclarationTest`. Manuell: entfällt; beim API-Kunden-Mailing (R6.4) auf das neue Pflichtfeld hinweisen.
 
 ## F. Frontend Spokes + Hub
 
 - [ ] **Alter `/thumbnails/...`-Link redirectet** — **Lücke am 06.07. gefunden und geschlossen** (Scope-Doku führte den Redirect fälschlich als „ANGEPASST"): `LegacyMediaRedirectController`, Tests `Web/LegacyMediaRedirectTest`. Manuell nach Staging-Import: 2–3 echte Alt-URLs aus dem Live-Portal stichprobenartig aufrufen.
 - [ ] **Legacy-.html-Redirects** (Startseite, FAQ, Newsrooms, Detail-URLs) — Automatisiert: `Web/LegacyRedirectTest`. Manuell: Stichprobe mit echten Alt-URLs nach Staging-Import.
-- [ ] **Kategorieseite + Veröffentlichen-Landing visuell abnehmen** (Frontend-Konzept-Doku führt sie noch als „offen", Code existiert) — Automatisiert: `Web/CategoryPageTest`, `Web/VeroeffentlichenPageTest`/`StaticPagesTest`. Manuell: visuelle Abnahme — **Achtung: Web-Frontend wird gerade umgebaut (User, 06.07.), Abnahme erst danach.**
+- [ ] **Kategorieseite + Veröffentlichen-Landing visuell abnehmen** — Automatisiert: `Web/CategoryPageTest`, `Web/VeroeffentlichenPageTest`/`StaticPagesTest`. Manuell: visuelle Abnahme — **entsperrt: der Frontend-Umbau ist seit 09.07. committet** (Spokes/Hub-Umbau, `contact-launcher`).
+- [ ] **PM-Tracking im Frontend** (neu 10.07.) — Aufrufe-Anzeige in der Meta-Zeile der Detailseite, Teilen-Buttons melden den Kanal (LinkedIn/X/E-Mail/Link kopieren). Automatisiert: `Web/PressReleaseTrackingTest`. Manuell: Detailseite aufrufen (Zähler steigt), einmal teilen → Ereignis in der „Geteilt"-Kachel des Kunden.
+- [ ] **Öffentliches KI-Label** (neu 09.07.) — PMs mit deklariertem KI-Grad tragen das Transparenz-Label (`portal/ai-public-label`, Einreicher-Stimme). Automatisiert: `PressReleaseAiDeclarationTest`. Manuell: eine PM mit KI-Deklaration veröffentlichen und Label auf der Detailseite prüfen.
+- [ ] **Melde-Zeile unter jedem Artikel (T13)** — Automatisiert: `Web/ReleaseDetailTest`/`LegalRequestTest` (Formular + Vorgangsnummer). Manuell: Links „Inhalt melden"/„Eigene Daten entfernen" an einer PM durchklicken; Hinweistexte sind final (R2.5, 10.07.).
+- [ ] **Kontakt-Widget (contact-launcher)** — schwebendes Widget ersetzt das Kontakt-Modal (09.07.), speist Brand-Mail + Admin-Queue. Automatisiert: `Web/ContactFormTest`. Manuell: auf Hub + beiden Spokes öffnen und absenden.
+- [ ] **Börsenticker** — `live-ticker` zeigt nur echte Daten (Yahoo Finance via `market:refresh`, alle 15 Min.) und blendet sich ohne Daten aus. Automatisiert: `Web/MarketDataTest`. Manuell auf Staging: nach erstem `market:refresh`-Lauf sichtbar; ohne Netz/Fehler kein leerer Ticker.
+- [ ] **Page-Data-Cache: Aktualität** (09.07.) — Home/Kategorie cachen 5 Min. ohne explizite Invalidierung; eine frisch publizierte PM darf bis zu 5 Min. brauchen, bis sie auf Home/Kategorie erscheint (Detailseite sofort). Automatisiert: `Web/PageDataCacheTest`. Manuell: Verhalten einmal bewusst beobachten — falls störend, Invalidierung beim Publish nachrüsten (kein Blocker).
 - [ ] **Rechtsseiten auf allen drei Domains** (Impressum, AGB, Datenschutz, Richtlinien, Melden, Kündigung) — Automatisiert: `Web/StaticPagesTest`, `Web/HubStaticPageShellTest`, `Legal/LegalDocumentTest`. Manuell: Sichtprüfung Hub + beide Spokes, Links im Footer.
 - [ ] **Sitemap/robots je Host** — Automatisiert: `Web/SitemapRobotsTest`. Manuell: /sitemap.xml und /robots.txt auf allen drei Hosts aufrufen.
 
 ## G. Betrieb (Staging/Live, Ops)
 
-- [ ] **Scheduler greift** — Vorgeprüft 06.07.: `schedule:list` zeigt 6 Tasks (magic-links:purge, press-releases:purge-drafts, publish-scheduled, billing:generate-manual-invoices, reset-monthly-quota, market:refresh). Manuell auf Staging: Cron-Eintrag + `php artisan schedule:run` + `queue:work` laufen (Runbook WS-7).
+- [ ] **Scheduler greift** — Vorgeprüft 06.07., erneut 10.07.: `schedule:list` zeigt 6 Tasks (magic-links:purge, press-releases:purge-drafts, publish-scheduled, billing:generate-manual-invoices, reset-monthly-quota, market:refresh). Manuell auf Staging: Cron-Eintrag + `php artisan schedule:run` + `queue:work` laufen (Runbook WS-7).
+- [ ] **Monitoring-Alerts (R5.3, neu 09.07.)** — alle 6 Scheduler-Tasks mit `->onFailure()`, Queue-`failing`-Listener; Alerts gehen als `Log::critical` + Mail an `MONITORING_ALERT_EMAIL` (Fallback `LEGAL_CONTACT_EMAIL`), Schalter `MONITORING_ALERTS_ENABLED`. Automatisiert: `OperationalAlertTest`. Manuell auf Staging: `MONITORING_ALERT_EMAIL` setzen, einen Task absichtlich fehlschlagen lassen (z. B. DB kurz weg) → Mail kommt; `LOG_STACK=daily` prüfen (Rotation 14 Tage).
 - [ ] **KI-Queue**: PM einreichen → Worker klassifiziert, kein Stau in `jobs`/`failed_jobs` — Automatisiert: `PressReleaseClassificationJobTest`. Manuell: mit echtem `OPENAI_API_KEY` auf Staging.
 - [ ] **Mail-Zustellung real** (nicht `log`), Absender/SPF/DKIM — nur Staging/Live [EXTERN].
 - [ ] **Umami**: `UMAMI_ENABLED=true` erst beim Go-Live; danach Snippet je Domain im Quelltext prüfen (`Web/UmamiSnippetTest` sichert die IDs).
@@ -67,10 +88,17 @@ Staging-Rehearsal (R6.3) mit echtem Datenbestand wiederholen.
 
 - **Import-Rehearsal** gegen produktiven Snapshot → eigener Punkt **R6.3** [EXTERN: Server/Snapshot].
 - **Newsletter Double-Opt-In End-to-End**: bewusst **vertagt** (Release-Plan „Bewusst NICHT im Plan": echte Newsletter-Sync bleibt No-Op; R0.3 macht das Binding nur ehrlich). Die API v1 legt Subscriptions unbestätigt an (`is_confirmed=false` + Token) — ein Bestätigungs-/Versandweg existiert noch nicht. Vor Aktivierung des Newsletters: DOI-Flow bauen. Kein öffentliches Anmeldeformular verlinkt → kein Launch-Blocker.
-- **Frontend-Redesign-Abnahme**: Web-Frontend (Startseiten, Feeds, Kategorie) ist am 06.07. in Arbeit (User) — visuelle Abnahme + betroffene Web-Tests nach Abschluss des Umbaus.
+- ~~**Frontend-Redesign-Abnahme**~~ — Umbau seit 09.07. committet; die visuelle Abnahme ist damit regulärer Teil von Abschnitt F.
 
 ## Befunde der Vorprüfung 06.07.
 
 1. **/thumbnails-Redirect fehlte** (Scope-Doku behauptete „ANGEPASST") → gebaut + getestet (siehe F).
 2. **Newsletter-DOI unvollständig** → bewusst vertagt, dokumentiert (siehe oben).
 3. Alles Übrige aus §15 ist durch die grüne Suite (957 Tests) auf Funktionsebene belegt; offen ist die **visuelle bzw. operative Abnahme** im Browser und auf Staging.
+
+## Nachprüfung 10.07.
+
+1. Alle referenzierten Beleg-Tests existieren; Suite **1156 grün** (5065 Assertions).
+2. B–G um die Features vom 07.–10.07. ergänzt: Kontakt-Queue + Widget, Ablehnungsbegründung, KI-Kennzeichnung (Submit-Pflicht, API, öffentliches Label), Tarifwechsel/Downgrade, Add-ons, USt/`automatic_tax`, eVatR, Rechnungsseite STR/MAN, Depublikations-Kauf komplett, PM-Tracking (Aufrufe + Shares), Börsenticker, Monitoring-Alerts (R5.3), Buchungs-/Verlängerungsdatum.
+3. Frontend-Umbau-Vorbehalt in F aufgehoben (Umbau committet 09.07.) — Kategorieseite/Veröffentlichen-Landing sind zur Abnahme frei.
+4. Einziger neuer Befund: **Page-Data-Cache ohne Publish-Invalidierung** — Home/Kategorie können einer frischen PM bis zu 5 Min. hinterherhängen (TTL 300 s). Als bewusster Tradeoff dokumentiert (siehe F); bei Bedarf Invalidierung beim Publish nachrüsten, kein Launch-Blocker.