presseportale/dev/changelog/Decision-Update_Changelog_Automatisierung_2026-10-04.md

# Decision-Update: Changelog und Newsroom-Artikel automatisieren

*Stand: 04.10.2026 · Projekt Presseportale (pressekonto.com / presseecho.de / businessportal24.com)*

---

## 1. Ziel

Jede Weiterentwicklung des Systems soll öffentlich sichtbar werden, ohne dass daraus eine eigene Schreibaufgabe entsteht. Zwei Ebenen, beide weitgehend aus dem Entwicklungsprozess heraus erzeugt:

1. **Changelog** auf pressekonto.com: kurz, datiert, vollständig für alles Sichtbare.
2. **Newsroom-Artikel** in einer eigenen Rubrik: nur für Neuerungen, die das Verhalten eines Nutzers ändern.

Der Changelog ist der Beweis, dass das Portal lebt. Für Rückkehrer aus den Reaktivierungswellen ist ein Eintrag von letzter Woche überzeugender als jede Formulierung in der Mail.

---

## 2. Bestätigte Entscheidungen

| Nr. | Entscheidung | Begründung |
|---|---|---|
| E1 | Zwei getrennte Ebenen (Changelog / Artikel), keine Mischform | Changelog darf granular sein, Artikel müssen selten bleiben |
| E2 | Changelog unter pressekonto.com/changelog, datumsbasiert, mit RSS-Feed | Niemand außer Kevin braucht Versionsnummern |
| E3 | Rubriken im Changelog: **Neu**, **Verbessert**, **Behoben**, **Sicherheit** | Sicherheit immer nur als Sammelzeile, siehe E5 |
| E4 | Erzeugung automatisiert aus Commits mit Kennzeichnung; Kevin liest gegen, streicht, gibt frei | Nebenprodukt der Arbeit statt zusätzlicher Aufgabe |
| E5 | Sicherheitskorrekturen erscheinen ausschließlich als „Sicherheitsverbesserungen eingespielt", nur nach dem Deploy, nie mit Beschreibung | Keine Landkarte für Angreifer, keine Verunsicherung für Nutzer |
| E6 | Artikel werden automatisiert aus freigegebenen Changelog-Einträgen erzeugt, nach festen Vorgaben (Abschnitt 4), und landen als unveröffentlichter Entwurf im Newsroom | Gleiche Logik wie beim Changelog: Entwurf automatisch, Freigabe manuell |
| E7 | Artikel nur bei Schwellenwert „Nutzer macht danach etwas anders"; kleinere Einträge werden zum Monatsrückblick gebündelt | Schutz vor Artikel-Inflation und Selbstdruck |
| E8 | Eigene Rubrik „Pressekonto" (Name final offen, siehe O1), eigenes Firmenprofil, klar als Eigenmeldung erkennbar | Keine Vermischung mit Kundenmeldungen |
| E9 | Artikel bekommen ein generisches Update-Bild aus eigenem Template (Portal-Logo, Wort „Update", Monat); kein Stockmaterial | Macht auf einen Blick klar, dass es um Portal-Updates geht; keine Bildrechtefrage |
| E10 | Eigene Artikel durchlaufen denselben Prüf- und Freigabeweg wie Kundenmeldungen | Glaubwürdigkeit; Scoring-Ergebnis ist zugleich Test des Scorings |
| E11 | Dezenter „Neu"-Hinweis im Admin von pressekonto.com, verlinkt auf die letzten Changelog-Einträge | Nutzer sehen Updates dort, wo sie arbeiten |
| E12 | Reaktivierungsmails verlinken künftig auf den Changelog statt auf die Startseite | Rückkehrer sehen sofort, was seit dem letzten Login passiert ist |
| E13 | Freigegebene Artikel werden automatisch in weitere Kanäle verteilt; Changelog-Einträge einzeln nie | Einzelne Einträge im Social-Feed wirken wie ein Bot |
| E14 | Nur kostenlose Kanäle: Bluesky, Mastodon, LinkedIn-Unternehmensseite für pressekonto; X und Threads bleiben außen vor | Kein Budget für Reichweitenexperimente, solange der Nutzen nicht belegt ist |
| E15 | Kevins persönliches LinkedIn-Profil ist **nicht** Teil dieser Pipeline | Gehört zum Markenaufbau Adametz Media, ein anderes Projekt mit anderen Regeln |
| E16 | Monatlicher E-Mail-Rückblick „Was ist neu" nur per Opt-in-Checkbox im Account, standardmäßig aus | Anti-Zombie: Wer es will, klickt; keine Diskussion über § 7 UWG |
| E17 | Benachrichtigungsmails an Pressekontakte bleiben rein informativ, kein Update-Hinweis in der Fußzeile | Sonst kippt die Mail zur Werbung ohne Einwilligung |
| E18 | Alle verteilten Links tragen UTM-Parameter; nach drei Monaten wird je Kanal entschieden: behalten oder abschalten | Reichweite wird gemessen, nicht vermutet |

---

## 3. Pipeline

### Stufe 1: Kennzeichnung im Commit

Nur Commits mit einem Changelog-Trailer werden berücksichtigt. Alles ohne Trailer bleibt intern.

```
feat(newsroom): Firmenprofil mit Newsroom-Ansicht

Changelog: Neu
Public: Unternehmen haben jetzt eine eigene Newsroom-Seite mit allen Meldungen.
```

```
fix(upload): Vorschau bricht bei Bildern über 5 MB ab

Changelog: Behoben
Public: Die Bildvorschau funktioniert jetzt auch bei großen Dateien.
```

```
fix(auth): Session-Fixation beim Magic-Link

Changelog: Sicherheit
```

Regeln:
- `Changelog:` Wert aus Neu / Verbessert / Behoben / Sicherheit.
- `Public:` ein Satz aus Nutzersicht. Fehlt er, formuliert der Generator einen Vorschlag aus dem Commit-Titel; bei **Sicherheit** wird `Public:` ignoriert und immer die Sammelzeile gesetzt.
- Interna (Dateinamen, Tabellen, Bibliotheken, Ticketnummern) gehören nie in `Public:`.
- Commits hinter einem Feature-Flag bekommen den Trailer erst beim Commit, der das Flag öffnet. Sonst erscheinen Features im Changelog, die noch niemand sieht.

### Stufe 2: Entwurf beim Deploy

Deploy-Hook (Ploi) sammelt alle Commits seit dem letzten Release-Tag, filtert auf Trailer, erzeugt pro Rubrik die Einträge und legt sie als **Changelog-Entwurf** mit Datum in der Datenbank ab. Der LLM-Schritt (siehe Vorgaben in Abschnitt 4) glättet nur die Formulierung; er erfindet keine Einträge und fasst mehrere Commits zum selben Feature zu einem Eintrag zusammen. Mehrere Sicherheits-Commits ergeben immer genau eine Sammelzeile.

### Stufe 3: Review und Freigabe

Im Admin: Liste der Entwurfseinträge, pro Eintrag streichen / umformulieren / Rubrik ändern / **artikelwürdig** markieren. Freigabe veröffentlicht den Changelog-Eintrag und aktualisiert den RSS-Feed. Zielaufwand: unter fünf Minuten pro Release.

### Stufe 4: Artikel-Entwurf

Für jeden als artikelwürdig markierten Eintrag erzeugt der Generator einen Artikel nach den Vorgaben in Abschnitt 4 und legt ihn als unveröffentlichte Meldung im Newsroom an. Bild wird aus dem Template erzeugt (Logo + „Update" + Monat, zwei bis drei Farbvarianten im Wechsel). Ein echter Screenshot kann manuell ergänzt werden, ist aber keine Voraussetzung.

**Monatsrückblick:** Liegen am Monatsende mindestens [N] freigegebene Einträge ohne eigenen Artikel vor, schlägt das System einen Sammelartikel „Was ist neu im [Monat]" vor.

### Stufe 5: Prüfung und Veröffentlichung

Der Artikel durchläuft die automatisierte Qualitätsprüfung wie jede Kundenmeldung. Freigabe manuell. Erstveröffentlichung auf **einem** Portal (siehe O2); eine Zweitveröffentlichung trägt die Referenzkennzeichnung wie bei Kunden.

---

## 4. Vorgaben für die Generatoren

### Changelog-Einträge
- Ein bis zwei Zeilen, Nutzersicht, Präsens, Verb am Anfang wo möglich („Zeigt jetzt …", „Behoben: …").
- Keine Dateinamen, Tabellen, Bibliotheken, Ticket- oder Commit-IDs, keine internen Projektnamen.
- Keine Bewertungen („deutlich schneller", „endlich"), keine Superlative.
- Sicherheit: immer exakt „Sicherheitsverbesserungen eingespielt."
- Sprache Deutsch. Englische Fassung nur, wenn O5 entschieden ist.

### Newsroom-Artikel
- 300 bis 500 Wörter, Titel ohne Ausrufezeichen, Untertitel mit dem konkreten Nutzen.
- Fester Aufbau in Fließtext, ohne Zwischenüberschriften als Labels: Was ist neu, für wen ist es gedacht, wo findet man es, Verweis auf den Changelog.
- Ton erklärend, aus Sicht des Nutzers, nüchtern. Keine Marketingvokabeln, keine Versprechen über künftige Features.
- Regeln aus „KI-Spuren entfernen" gelten: keine Gedankenstrich-Häufung, keine Dreierfiguren, keine Label-Doppelpunkt-Konstruktionen, keine Nominalisierungsketten.
- Der Artikel darf nur beschreiben, was im freigegebenen Changelog-Eintrag steht. Keine Ausschmückung mit Funktionen, die nicht genannt sind.
- Pressekontakt, Firmenprofil und Rubrik werden fest gesetzt, nicht generiert.

---

## 5. Verteilung in weitere Kanäle

### Was verteilt wird
Ausschließlich freigegebene Newsroom-Artikel und der Monatsrückblick. Quelle ist der RSS-Feed der Rubrik. Changelog-Einträge haben einen eigenen RSS-Feed für Abonnenten, werden aber nicht in soziale Kanäle gespielt.

### Kanäle (alle kostenlos)

| Kanal | Weg | Format | Zweck |
|---|---|---|---|
| Bluesky | n8n, offene API | Kurzfassung bis 300 Zeichen + Link | Deutsche Journalisten und Medienleute, wachsend |
| Mastodon | n8n, offene API | Kurzfassung bis 500 Zeichen + Link | Tech- und Medienpublikum, Nullaufwand |
| LinkedIn-Unternehmensseite pressekonto | n8n oder Buffer Free | Drei Sätze mit Frage am Ende + Link | Präsenz; Reichweite wird getestet, nicht vorausgesetzt |
| E-Mail-Rückblick | Aus dem Monatsartikel, Versand über bestehendes Mailsystem | Monatsartikel als Mail | Retention bei bestehenden Nutzern, nur Opt-in |

Nicht in der Pipeline: X (API kostenpflichtig), Threads (kein deutsches B2B-Publikum), Kevins persönliches LinkedIn-Profil (E15).

### Technik
- n8n selbst gehostet (Docker auf dem vorhandenen Mac mini), Workflow: RSS-Trigger → pro Kanal eine Kurzfassung erzeugen → posten → Log.
- Die Kurzfassungen erzeugt der Generator pro Kanal getrennt, mit leicht unterschiedlicher Formulierung. Identischer Text auf drei Plattformen ist als Kreuzposting sofort erkennbar.
- UTM-Schema: `utm_source=<kanal>&utm_medium=social&utm_campaign=update-<jahr>-<monat>`; für die Mail `utm_medium=email`.
- Ein Brand-Account pro Kanal (pressekonto), nicht je Portal. Drei Accounts pflegt niemand, auch nicht automatisch.
- Zugang zur LinkedIn-Seiten-API setzt eine Freigabe der App durch LinkedIn voraus; dauert erfahrungsgemäß. Fallback ist Buffer im kostenlosen Tarif, der die Seite ohne eigene API-Freigabe bedient.

### Opt-in für den E-Mail-Rückblick
Checkbox im Account: „Monatliche Produkt-Updates per E-Mail erhalten", Standard aus, jederzeit abwählbar, Abmeldelink in jeder Mail. Die Reaktivierungsmails weisen auf die Option hin. Kein Versand an Nutzer ohne gesetzten Haken, auch nicht unter Berufung auf § 7 Abs. 3 UWG.

---

## 6. Adversarial Review

**Commit-Disziplin ist die Sollbruchstelle.** Die Pipeline ist nur so gut wie die Trailer. Wird ein `Public:`-Satz schlampig geschrieben, steht die Schlamperei öffentlich. Gegenmaßnahme ist die Review-Stufe; die darf nie übersprungen werden, auch nicht bei Mini-Releases.

**Sicherheits-Leak über die Hintertür.** Ein Fix mit `Changelog: Behoben` statt `Sicherheit` beschreibt die Lücke öffentlich. Regel für den Generator: Enthält der Commit-Titel typische Begriffe (auth, session, token, csrf, xss, injection, permission, escape, sanitize, rate limit), wird der Eintrag automatisch auf **Sicherheit** gesetzt und im Review markiert. Zurückstufen nur bewusst.

**Der Generator halluziniert Features.** Deshalb die harte Regel, dass nur der Changelog-Eintrag Quelle des Artikels ist. Prüfpunkt im Review: Nennt der Artikel etwas, das nicht im Eintrag steht, wird er verworfen, nicht korrigiert.

**KI-Kennzeichnung der eigenen Texte.** Die Plattform hat eine Kennzeichnung für KI-erstellte Meldungen. Automatisch erzeugte Eigenartikel sind KI-erstellt. Entweder tragen sie die Kennzeichnung, oder Kevin bearbeitet sie vor der Freigabe so, dass redaktionelle Verantwortung erkennbar übernommen wurde. Beides ist vertretbar; was nicht geht, ist bei Kunden kennzeichnen und bei sich selbst nicht. Siehe O4.
Antowrt: Ich möchte alle Texte vorher bearbeiten und freigeben. Nichts soll automatisiert online gestellt werden.

**EU AI Act, Art. 50 Abs. 4.** Für KI-generierte Texte, die veröffentlicht werden, um die Öffentlichkeit zu informieren, gilt ab August 2026 eine Transparenzpflicht; ausgenommen sind Texte unter menschlicher Überprüfung mit redaktioneller Verantwortung. Die manuelle Freigabe deckt das vermutlich ab, aber die Frage gehört auf die Anwaltsagenda, weil sie dieselbe Mechanik betrifft, mit der Kundenmeldungen gekennzeichnet werden. Keine Rechtsberatung, Einordnung.

**Dünner Content im eigenen Haus.** 30 Changelog-Einträge im Monat sind gut, 30 Artikel wären das Gegenteil dessen, was gegenüber FMI gerade als Qualitätsmaßstab gesetzt wird. Schwellenwert und Monatsrückblick (E7) sind deshalb keine Komfortregeln, sondern Schutz der Positionierung.

**Behoben-Einträge als Vertrauensfrage.** Eine lange Behoben-Liste nach dem Relaunch kann wirken wie „da war viel kaputt". Das Risiko ist klein gegenüber dem Gewinn an Glaubwürdigkeit, aber die Formulierung sollte beschreiben, was jetzt funktioniert, nicht was vorher nicht ging.

**Tote Social-Accounts schaden mehr als keine.** Ein Bluesky-Account mit drei Posts aus dem Vorjahr wirkt wie ein verlassenes Portal. Deshalb E18: Nach drei Monaten ohne messbare Besucher wird der Kanal abgeschaltet und der Account gelöscht, nicht stehen gelassen.

**Automatisierte Posts erzeugen Rückfragen, die niemand beantwortet.** Wer auf Bluesky unter einem Update-Post eine Frage stellt, erwartet eine Antwort. Entweder prüft Kevin die Kanäle einmal pro Woche, oder die Posts enden mit „Fragen gern per Mail an …" und verweisen auf den Kanal, der tatsächlich gelesen wird.

**Doppelte Rolle auf LinkedIn.** Eine pressekonto-Unternehmensseite und Kevins persönliches Profil sind getrennte Vorhaben, aber dieselbe Plattform. Die Unternehmensseite darf nicht zum Hilfskanal für die persönliche Marke werden und umgekehrt. Trennung gilt für Inhalte, Tonfall und Verantwortung.

**Startzustand.** Ein leerer Changelog wirkt wie ein leeres Portal. Vor dem Livegang die Relaunch-Features der letzten Wochen als erste Einträge nachtragen (Backfill, datiert auf die tatsächlichen Deploys, soweit rekonstruierbar).

---

## 7. Offene Punkte nach Dringlichkeit

| Nr. | Punkt | Art | Dringlichkeit |
|---|---|---|---|
| O1 | Name der Rubrik: „Pressekonto", „In eigener Sache" oder „Portal-Updates" | Geschäftsentscheidung | vor Bau | 
#Portal-Updates
| O2 | Portal der Erstveröffentlichung für Eigenartikel (pressekonto.com-Blog oder eines der beiden Portale) | Geschäftsentscheidung | vor Bau |
#beide Portale, es wird ja gekennzeichnet per Canonial 
| O3 | Schwellenwert N für den Monatsrückblick (Vorschlag: 5) | Geschäftsentscheidung | vor Bau |
#Ganz klar ein Monatsrückblick. Wenn genug Inhalt auch in einem Monat da ist, sonst kann es auch mal alle zwei Monate sein.

| O4 | KI-Kennzeichnung bei automatisch erzeugten Eigenartikeln: kennzeichnen oder redaktionell überarbeiten | Geschäftsentscheidung, Rechtsbezug | vor erstem Artikel |
#Ich prüfe und überarbeite alle Erzeugn Artikel und gebe sie frei.
| O5 | Englische Fassung von Changelog und Artikeln, ja oder nein | Geschäftsentscheidung | Phase 2 |
#Hier bitte eine Empfehlung, Ich glaube, wir müssen das aufgrund der Zugriffe entscheiden
| O6 | Bild-Template: Farben, Format, Varianten | Gestaltung | vor erstem Artikel |
#bereite ich vor, Relativ einfaches Template mit dem Titel mit Logo und dem pressekonto farben
| O7 | Backfill der Relaunch-Features als Starteinträge | Umsetzung | vor Livegang |
#ja
| O8 | Art. 50 AI Act für Eigenmeldungen und Kundenmeldungen | Anwaltsagenda | nächster Anwaltstermin |
#ja
| O9 | Accounts anlegen: Bluesky, Mastodon (Instanz wählen), LinkedIn-Unternehmensseite pressekonto | Umsetzung | nach erstem Artikel |
#Bitte mit in den Entwicklungsplan aufnehmen
| O10 | n8n aufsetzen und Workflow RSS → Kanäle bauen; LinkedIn-API-Freigabe beantragen oder Buffer Free nutzen | Umsetzung | nach O9 |
#auch in den Entwicklungsplan mit aufnehmen
| O11 | Opt-in-Checkbox für den E-Mail-Rückblick im Account, Hinweis in den Reaktivierungsmails | Umsetzung | vor erstem Monatsrückblick |
#auf jeden Fall, ihr müsst dann auch noch mal genau sortiert werden. Es gibt ja bereits Abmeldungslisten Etc. 
| O12 | Wer beantwortet Rückfragen in den Social-Kanälen: wöchentlicher Blick oder Verweis auf E-Mail im Post | Geschäftsentscheidung | vor erstem Post |
#
| O13 | Impressumspflicht für die Social-Accounts (§ 5 DDG): Link zum Impressum im Profil hinterlegen | Umsetzung | beim Anlegen |
#ja siehe pressekonto

---

## 8. Revisit-Bedingungen

- Wenn die Review-Stufe regelmäßig länger als zehn Minuten pro Release dauert: Trailer-Konvention vereinfachen oder Generator-Vorgaben nachschärfen.
- Wenn mehr als zwei Artikel im Monat entstehen: Schwellenwert anheben.
- Wenn eigene Artikel das Scoring nicht bestehen: zuerst das Scoring prüfen, dann die Vorgaben.
- Wenn Nutzer den Changelog nachweislich nicht aufrufen (Zugriffe über drei Monate nahe null): „Neu"-Hinweis im Admin prüfen, nicht den Changelog einstellen.
- Wenn O4/O8 anders ausgeht als angenommen: Artikel-Generator pausieren, bis die Kennzeichnung geklärt ist.
- Drei Monate nach dem ersten verteilten Artikel: UTM-Auswertung je Kanal. Kanäle ohne messbare Besucher werden abgeschaltet und die Accounts gelöscht.
- Wenn ein Kanal kostenpflichtig wird oder seine API schließt: Kanal verlassen, nicht bezahlen.
- Wenn die Opt-in-Quote für den E-Mail-Rückblick nach sechs Monaten unter [X] % der aktiven Nutzer liegt: Platzierung der Checkbox prüfen, nicht den Standard auf „an" setzen.

---

## 9. Anti-Zombie-Check

| Grundsatz | Erfüllt? | Anmerkung |
|---|---|---|
| Keine versteckten Kosten | Ja | Keine Kostenfolge für Nutzer, keine laufenden Kosten für Kevin (E14) |
| Transparenz | Ja, verstärkt | Öffentlicher, datierter Changelog ist Transparenz in Reinform |
| Kein Dauerbetreuungsaufwand | Ja, wenn Pipeline steht | Review unter fünf Minuten pro Release; Verteilung läuft ohne Eingriff; offen bleibt O12 |
| Keine Vermischung von Eigen- und Kundeninteresse | Ja, bei E8 und E10 | Eigene Rubrik, gleicher Prüfweg |
| Keine ungefragte Kommunikation | Ja, bei E16 und E17 | Opt-in standardmäßig aus; Pressekontakt-Mails bleiben informativ |
| Ehrlichkeit über die eigene Arbeitsweise | Offen, O4 | KI-Kennzeichnung der eigenen Texte muss konsistent zur Kundenregel sein |