Kevin Adametz 9692de581d dev: Changelog-Entscheidungen O1–O13 und E19–E21, Roadmap v1.8-Stand

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

2026-10-09 13:35:54 +00:00

18 KiB

Raw Permalink Blame History

Decision-Update: Changelog und Newsroom-Artikel automatisieren

Stand: 04.10.2026, Entscheidungen nachgetragen 09.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:

Changelog auf pressekonto.com: kurz, datiert, vollständig für alles Sichtbare.
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.sh (nach up, E21) 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. Entscheidung (O4): Alle Texte werden vorher bearbeitet und freigegeben. Nichts wird automatisiert online gestellt.

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 — Entscheidungen

Antworten des Betreibers vom 04.10. und 09.10.2026.

Nr.	Punkt	Entscheidung
O1	Name der Rubrik	„Portal-Updates“
O2	Portal der Erstveröffentlichung für Eigenartikel	Beide Portale, Erstquelle über die bestehende Canonical-Zuordnung (wie bei Kunden)
O3	Schwellenwert N für den Monatsrückblick	Ab 5 freigegebenen Einträgen monatlich, darunter wird der nächste Monat mit eingerechnet (dann alle zwei Monate). Der Rückblick soll nicht wirken, als werde ständig repariert: Er erscheint, wenn es Neuigkeiten gibt; Behobenes nur, wenn es für Nutzer spürbar war, Sicherheitskorrekturen nur als kurze Sammelzeile ohne Einzelheiten (E5, E19)
O4	KI-Kennzeichnung bei automatisch erzeugten Eigenartikeln	Jeder Artikel wird vom Betreiber überarbeitet und freigegeben, nichts geht automatisiert online
O5	Englische Fassung	Vorerst nur Deutsch. Nach drei Monaten anhand des Anteils englischer Seitenaufrufe in Umami neu entscheiden (setzt Umami im Portal voraus, Roadmap 3.6). Changelog-Zeilen sind kurz, eine spätere Übersetzung ist billig
O6	Bild-Template	Betreiber bereitet es vor: einfaches Template mit Titel, Logo und pressekonto-Farben
O7	Backfill der Relaunch-Features	Ja. Quelle: Release-Tags und das Protokoll in `dev/betrieb/git-deploy.md` (beschreibt jedes Release nutzernah)
O8	Art. 50 AI Act	Auf die Anwaltsagenda
O9	Accounts Bluesky, Mastodon, LinkedIn-Unternehmensseite	In die Roadmap (nach dem ersten Artikel)
O10	n8n und Workflow RSS → Kanäle, LinkedIn-API oder Buffer Free	In die Roadmap (nach O9)
O11	Opt-in-Checkbox für den E-Mail-Rückblick	Ja. Vorher mit den bestehenden Abmelde- und Sperrlisten abgleichen und festlegen, welche Liste für welche Mailart gilt
O12	Wer beantwortet Rückfragen in den Social-Kanälen	Jeder Post endet mit „Fragen gern per Mail an …“; kein wöchentlicher Kanalcheck nötig
O13	Impressum in den Social-Profilen	Ja, Link auf das Impressum von pressekonto

Ergänzende Entscheidungen 09.10.2026

Nr.	Entscheidung
E19	Tonfall: Changelog und Rückblick zeigen Neuigkeiten, kein Reparaturprotokoll. Behobenes erscheint nur, wenn es für Nutzer spürbar war, und beschreibt, was jetzt funktioniert. Sicherheitskorrekturen nur als Sammelzeile „Sicherheitsverbesserungen eingespielt.“
E20	Commit-Trailer `Changelog:`/`Public:` gelten ab sofort (ab v1.8), auch bevor die Pipeline gebaut ist — was nicht gekennzeichnet wird, muss später von Hand rekonstruiert werden
E21	Stufe 2 dockt in `dev/betrieb/deploy.sh` nach `up` an, nicht als Ploi-Hook (die Ploi-Hooks sind bewusst aus, `git-deploy.md` „Später: Changelog“)

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

18 KiB Raw Permalink Blame History