dev: deploy.sh legt Changelog-Entwürfe an, Deploy-Notiz v1.13.0, Roadmap 6.6

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

dev/archive/betrieb/deploy-v1.13.0.md

@@ -0,0 +1,37 @@
+# Deploy v1.13.0 — Changelog
+
+**Stand:** 14.10.2026 · **Live bisher:** `v1.12.0` · Ablauf nach [git-deploy.md](../../betrieb/git-deploy.md), Abschnitte C und D.
+
+**Inhalt** (Roadmap [6.6](../../roadmap.md), [Decision-Update Changelog](../../changelog/Decision-Update_Changelog_Automatisierung_2026-10-04.md), Stufen 1 bis 3):
+
+- **Entwürfe beim Deploy:** `deploy.sh` ruft nach `up` den Befehl `php artisan changelog:collect <vorher> <neu>` auf. Aus den Commit-Zeilen `Changelog:`/`Public:` entstehen Entwürfe. Commits ohne diese Zeile bleiben intern, Sicherheit wird je Release zu einer Sammelzeile. Ein Fehler hier bricht den Deploy nicht ab.
+- **Admin ▸ Einstellungen ▸ Changelog** (nur `settings:manage`): gegenlesen, bearbeiten, Rubrik ändern, als artikelwürdig markieren, freigeben oder verwerfen. Alle Entwürfe eines Tages lassen sich auf einmal freigeben, Einträge auch von Hand anlegen.
+- **Öffentlich:** `pressekonto.com/changelog` und `/changelog/feed` (RSS). Auf presseecho und businessportal24 leitet die Adresse auf den Hub weiter.
+- **Kundenmenü:** „Was ist neu“, mit dem Kennzeichen „Neu“, solange ein freigegebener Eintrag höchstens 14 Tage alt ist.
+
+**Umfang:** **eine Migration** (`create_changelog_entries_table`, neue Tabelle, kein Eingriff in bestehende Tabellen), keine neuen `.env`-Werte, neue Assets (mitcommittet), Scheduler unverändert. Suite 2.564 grün, einer übersprungen; Larastan ohne Meldung.
+
+## Deploy
+
+```bash
+cd ~/pressekonto.com
+# DB-Backup wie üblich vorher, dann:
+bash dev/betrieb/deploy.sh v1.13.0 --migrations
+```
+
+`deploy.sh` läuft aus einer Kopie des **bisher ausgecheckten** Skripts. Beim Deploy von v1.13.0 fehlt der Changelog-Schritt also noch; er greift ab dem nächsten Release. Einmalig von Hand, je Release mit seinem Live-Datum, dazu der Nachtrag seit dem Relaunch:
+
+```bash
+php artisan changelog:collect v1.10.0 v1.11.0 --date=2026-10-13
+php artisan changelog:collect v1.11.0 v1.12.0 --date=2026-10-14
+php artisan changelog:collect v1.12.0 v1.13.0
+php artisan changelog:backfill
+```
+
+## Prüfungen danach
+
+- `/health` meldet `v1.13.0`.
+- Admin ▸ Changelog: Die Entwürfe stehen dort, die Nachträge mit dem Vermerk „Datum und Text prüfen“.
+- Einige Einträge freigeben, dann `pressekonto.com/changelog` öffnen, ebenso den Feed `/changelog/feed`.
+- `presseecho.de/changelog` leitet auf `pressekonto.com/changelog` weiter.
+- Im Kundenbereich steht „Was ist neu“ mit dem Kennzeichen „Neu“, sobald ein freigegebener Eintrag aus den letzten 14 Tagen existiert. Das Kennzeichen wird bis zu 10 Minuten zwischengespeichert.

dev/betrieb/deploy.sh

@@ -140,6 +140,17 @@ fi
 step "Wartungsmodus aus"
 php artisan up
 
+# Changelog-Entwürfe aus den Commit-Zeilen `Changelog:`/`Public:` (Decision-
+# Update Changelog, Stufe 2, E21). Veröffentlicht wird nichts; Freigabe im
+# Admin ▸ Changelog. Ein Fehler hier bricht den Deploy nicht ab.
+step "Changelog-Entwurf"
+if [[ "$previous" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+    php artisan changelog:collect "$previous" "$tag" \
+        || echo "!! Changelog-Entwurf nicht angelegt, der Deploy ist trotzdem live. Nachholen: php artisan changelog:collect $previous $tag" >&2
+else
+    echo "Vorheriger Stand ($previous) ist kein Tag. Von Hand: php artisan changelog:collect <vorheriger Tag> $tag"
+fi
+
 step "Version"
 php artisan about --only=pressekonto
 

dev/betrieb/git-deploy.md

@@ -290,14 +290,21 @@ oder mit root-Zugang, danach `php-fpm8.4 -t` und erst dann neu laden.
 …/public/api/ is forbidden` (dort liegt die API-Spezifikation `v1.yml`, ein Aufruf
 von genau `/api/` bekommt 403). Ein Zugriffsprotokoll für die Site führt Ploi nicht.
 
-## Später: Changelog
+## Changelog
 
-Der Changelog-Entwurf
+Seit `v1.13.0` legt `deploy.sh` nach `up` die Changelog-Entwürfe an
 ([Decision-Update](../changelog/Decision-Update_Changelog_Automatisierung_2026-10-04.md),
-Stufe 2) dockt in `deploy.sh` nach `up` an. Ein Artisan-Befehl liest die Commits
-zwischen dem vorherigen und dem neuen Tag. Die liegen jetzt auf dem Server vor.
-Daraus legt er die Entwürfe an. Der LLM-Schritt läuft als Queue-Job, damit ein
-Ausfall des Anbieters keinen Deploy abbricht.
+Stufe 2): `php artisan changelog:collect <vorheriger Tag> <neuer Tag>` liest die
+Commits dazwischen und macht aus den Zeilen `Changelog:` (Neu, Verbessert,
+Behoben, Sicherheit) und `Public:` (ein Satz aus Nutzersicht) je einen Entwurf.
+Commits ohne `Changelog:` bleiben intern, Sicherheit wird je Release zu einer
+Sammelzeile. Ein Fehler bricht den Deploy nicht ab; nachholen mit demselben
+Befehl, er legt nichts doppelt an. Freigabe im Admin ▸ Changelog, öffentlich
+unter `pressekonto.com/changelog` und `/changelog/feed`.
+
+Die Zeilen stehen irgendwo in der Commit-Nachricht, am besten direkt vor
+`Co-Authored-By`. Git zählt nur den letzten Absatz als Trailer — der Befehl
+liest deshalb die ganze Nachricht.
 
 ## Protokoll
 

dev/roadmap.md

@@ -52,7 +52,8 @@ oder Release versehen.
 | v1.9.0/v1.9.1 | 13.10. | Boost als „Gebuchte Platzierung“ mit Erklärung, „Aktuell“ statt „Top-Auswahl“, Admin-Aktion „Boost beenden“, `audit:admins` |
 | v1.10.0 | 13.10. | Trichter misst Verwaltungsseite, Anforderung und Firma bei der Einlösung; Admin ▸ Reports ▸ Wachstum; Umami-Anbindung (`umami:report`, `growth:report`) |
 | v1.11.0 | 13.10. | Newsroom-Seite mit Kasten „Diesen Newsroom verwalten“; Firmenseiten „Firma & Newsroom“ mit Link zum öffentlichen Newsroom |
-| v1.12.0 | (Deploy offen) | Veröffentlichungs- und Ablehnungsmail: Anmeldelink an die Adresse der Mail (`/zugang`), ohne Konto und Passwort |
+| v1.12.0 | 14.10. | Veröffentlichungs- und Ablehnungsmail: Anmeldelink an die Adresse der Mail (`/zugang`), ohne Konto und Passwort |
+| v1.13.0 | (Deploy offen) | Changelog: Entwürfe beim Deploy, Freigabe im Admin, `pressekonto.com/changelog` mit RSS, „Was ist neu“ im Kundenmenü |
 
 ---
 
@@ -171,7 +172,7 @@ aber nirgends belegt.
 | 6.3 | **3.3 Agenturmodell:** mehrere Firmen unter einem Konto, abgeleitet aus den 1.102 Sammeladressen. Danach 3.4 gezielte Ansprache kleiner Agenturen. | Roadmap Nutzergewinnung | L |
 | 6.4 | **3.2 Branchen-Digest** mit Double-Opt-in (löst auch 4.3). | Roadmap Nutzergewinnung | M |
 | 6.5 | Newsletter-Kampagnenmodul: U05–U07 umsetzen, bevor `NEWSLETTER_SENDING_ENABLED` eingeschaltet wird. | [Entwicklungsplan Audit E9/E23](archive/2026-09-audit/ENTWICKLUNGSPLAN.md) | M |
-| 6.6 | **Changelog-Pipeline — als Nächstes.** Entscheidungen O1–O13 und E19–E21 getroffen (09.10.). Zuerst Stufen 1–3: Seite `/changelog` mit RSS, Entwurf aus `deploy.sh` nach `up` (nicht als Ploi-Hook), Freigabe im Admin, „Neu“-Hinweis im Admin (E11), Backfill seit Go-Live (O7). Stufen 4/5 (Artikel) brauchen das Bild-Template (O6, Betreiber); Social-Kanäle (O9, O10) erst nach dem ersten Artikel. **Achtung E20:** Die Trailer `Changelog:`/`Public:` fehlen in allen 31 Commits seit v1.7.0 — v1.8.0 bis v1.9.1 kommen beim Backfill aus dem Protokoll in `git-deploy.md`; ab jetzt jeder nutzersichtbare Commit mit Trailer. | [Decision-Update Changelog](changelog/Decision-Update_Changelog_Automatisierung_2026-10-04.md) | L |
+| 6.6 | **Changelog-Pipeline — Stufen 1–3 gebaut für v1.13.0 (14.10.2026):** `changelog:collect` in `deploy.sh` nach `up` (Entwürfe aus `Changelog:`/`Public:`, liest die ganze Commit-Nachricht), Admin ▸ Changelog zum Freigeben, `pressekonto.com/changelog` mit RSS, Kundenmenü „Was ist neu“ mit Neu-Kennzeichen (E11), Nachtrag seit dem Relaunch als Entwurf (`changelog:backfill`, O7 — Datum und Text gegenlesen). **Offen:** Stufen 4/5 (Artikel in der Rubrik „Portal-Updates“, braucht das Bild-Template O6), Monatsrückblick (O3), Opt-in-Rückblick per Mail (O11, E16), Link aus den Reaktivierungsmails (E12), Social-Kanäle (O9/O10). Kein LLM-Schritt: Die `Public:`-Sätze werden beim Commit formuliert, umformuliert wird im Admin. | [Decision-Update Changelog](changelog/Decision-Update_Changelog_Automatisierung_2026-10-04.md) | M (Rest) |
 | 6.7 | Betriebsüberwachung **Phase 2** (Validierungsfehler, Schritt-Tracking, Umami-Events, „Problem melden“, Geschäftstrichter) und **Phase 3** (Kennzahlen, Alarme bei ausbleibender Aktivität, Seite „Betrieb & Nutzung“, Morgenmail). Entscheidungen M4–M9 bestätigen. | [Monitoring-Plan](betrieb/monitoring-plan.md) | L |
 | 6.8 | Bildrechte: Block I C2PA (ab 26.10.), I.5 XMP in Varianten, Block J Bilder im Newsroom (Kontingent-Entscheidung), I.6 Re-Sync-Sperre erst wenn ein API-Partner Bilder liefert. | [Bildrechte-Plan](bildrechte/bildkennzeichnung-entwicklungsplan-2026-09-21.md) | L |
 | 6.9 | API v1: Rückkanal bei Ablehnung (Status-Feld oder Webhook, S6). | [API-Parität](betrieb/api-legacy-paritaet.md) | M–L |