Social-Media-Texte pro Antrag per LLM generieren #133
Labels
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: tobias/gwoe-antragspruefer#133
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Kontext
Aktuell werden Share-Texte für Threads/X/Mastodon clientseitig aus Score+Titel+Empfehlung zusammengebaut. Das ergibt generische Texte. Besser: das LLM generiert beim Analysieren einen spezifischen, schlagkräftigen Social-Text pro Medium.
Ziel
Pro Assessment werden zusätzliche Felder gespeichert:
share_threads— optimiert für Threads (max 500 Zeichen, Emojis, CTA, Hashtags)share_twitter— optimiert für X/Twitter (max 280 Zeichen, prägnant)share_mastodon— optimiert für Mastodon (max 500 Zeichen, sachlicher Ton)Implementierung
Umgesetzt + deployed. Backend war schon fertig (Modell-Felder
share_threads/twitter/mastodonseit längerem live, analyzer-Prompt fordert sie an, DB persistiert sie). Es fehlte nur der UI-Swap.Änderung: Neue JS-Funktion
_getShareText(item, platform)inapp/templates/index.html:item.shareTwitter/shareThreads/shareMastodon)_socialText(item)-Logik wenn Feld leer (ältere Assessments)Alle drei Share-Buttons (𝕏-Link, Threads-Link, Mastodon-Funktion) rufen jetzt
_getShareText().Live-Verifikation:
curl https://gwoe.toppyr.de/enthält 4×_getShareText.⏸ Annahme (async): Mastodon-Fallback nutzt jetzt das Lang-Format (
_socialText) statt des alten Kurz-Formats (_shareText). Default-Annahme: ein konsistentes Fallback-Format über alle Plattformen ist besser als plattform-spezifische Unterschiede. Falls das dir auffällt und nicht gewünscht: Mini-Fix (3 Zeichen) jederzeit möglich. Ich arbeite weiter.