Installations- & Einrichtungsanleitung

Beginne mit postctl, indem du das Binary kompilierst und deinen lokalen Entwickler-Arbeitsbereich initialisierst.

Systemanforderungen

• Betriebssystem: macOS, Linux oder Windows (WSL empfohlen).
• Go-Toolchain: Go 1.22 oder höher auf deinem System installiert.
• SQLite: Lokale SQLite-Clientbibliothek (der CGO-freie Treiber ist direkt einkompiliert).

Automatische Einrichtung in einem Schritt

Der einfachste Weg, die Anwendung, Datenbanken und Abhängigkeiten zu initialisieren, ist die Ausführung des interaktiven Setup-Skripts:

chmod +x setup.sh
./setup.sh

Das Setup-Skript führt folgende Schritte aus:

1. Überprüfung deiner lokalen Go-Umgebung.
2. Herunterladen der benötigten Pakete (einschließlich Bubble Tea, Cobra und SQLite).
3. Kompilieren des Produktions-Binaries postctl.
4. Erstellen des Konfigurationsverzeichnisses unter ~/.config/postctl/.
5. Generieren einer Standard-config.yaml und einer leeren SQLite-Datenbank.

Manuelle Kompilierung

Wenn du die Anwendung lieber manuell kompilieren möchtest, führe folgende Befehle aus:

# Abhängigkeiten herunterladen
go mod download

# Binary mit eingebetteten Assets bauen
go build -o postctl main.go

# Hilfe-Befehl zur Überprüfung ausführen
./postctl --help

Konfigurationsverzeichnis

Die Anwendung erstellt und erwartet Dateien im Benutzerkonfigurationsverzeichnis: ~/.config/postctl/

• config.yaml: Enthält alle deine globalen Standardeinstellungen, KI-Konfigurationen und Plattform-API-Zugangsdaten.
• postctl.db: Die lokale SQLite-Datenbank, die Kampagnen, Post-Status, Verläufe und verschlüsselte Zugangsdaten speichert.

📝 Vim / Neovim externer Editor-Flow

In der interaktiven Terminal-UI kannst du deinen terminal-nativen Texteditor (wie Neovim oder Vim) starten, um Beitragstext zu bearbeiten, Vorlagen anzupassen oder Metadaten spontan zu ändern.

Editor aufrufen

1. TUI-Dashboard starten: ./postctl tui
2. Zu einem Beitrag oder einer Kampagne navigieren und e drücken, um das Bearbeitungsformular zu öffnen.
3. Im Fokus auf den Body oder ein beliebiges Textfeld ctrl+v drücken.
4. Der TUI-Prozess pausiert, und dein Terminal startet deinen konfigurierten Editor (liest $EDITOR, fällt sonst auf nvim oder vim zurück).

Aufbau der Vorlagendatei

Vim öffnet eine temporäre Datei im Markdown-Format. Sie enthält drei getrennte Blöcke:

1. Interaktiver Hilfe-Block (HTML-Kommentare)

<!--
 postctl Editor Help (TWITTER)
 ==================================
 [Zeichen-Lineal (max. 280 Zeichen pro Tweet)]
 000      030      060      090      120      150      180      210      240      270 280!
 |--------|--------|--------|--------|--------|--------|--------|--------|--------|-|

 Aktueller Thread-Status:
   Tweet 1: 220 Zeichen (60 übrig) [✓]
   Tweet 2: 110 Zeichen (170 übrig) [✓]

 HINWEIS: Dieser Hilfe-Block wird beim Speichern automatisch entfernt.
 Schreibe deinen Beitragstext unterhalb dieses Kommentars:
-->

Dieser Block aktualisiert sich dynamisch nach den Limits deiner Zielplattform (280 für Twitter, 300 für Bluesky, 500 für Mastodon). Er wird beim Speichern automatisch entfernt.

2. YAML-Frontmatter-Block

---
platform: twitter
campaign: launch-2026
schedule: 2026-06-25 15:00:00
images: ["logo.png"]
---

Bidirektionale Synchronisierung: Du kannst diese Werte direkt in Vim bearbeiten. Änderungen an Kampagnenname, Zielplattform, Zeitstempel oder Bilderliste aktualisieren beim Zurückkehren sofort die TUI-Formularfelder.

3. Inhaltskörper

Der Beitragstext beginnt nach dem abschließenden ----Frontmatter-Trenner. Schreibe deinen Beitrag in Standard-Markdown.

Für mehrteilige Beiträge trenne jeden Abschnitt mit einer Zeile, die nur --- enthält.

🖼️ Bildpfad-Auflösung & Plattform-Uploads

Verwalte und binde Medien-Assets nahtlos über lokale Dateireferenzen ein.

Wie Bildpfade aufgelöst werden

Wenn du in deinem Beitrags-Frontmatter einen Dateinamen oder Pfad angibst (z. B. images: ["dashboard-screenshot.png"]), führt postctl eine Fallback-Suche in folgender Reihenfolge durch:

1. Absolutpfad-Prüfung: Ist es ein literaler Pfad auf deinem System? (z. B. /Users/user/Pictures/screenshot.png)
2. Relativ zum Markdown-Dokument: Wenn du eine Datei aus /code/posts/announcement.md importiert hast, wird /code/posts/dashboard-screenshot.png geprüft.
3. Aktuelles Arbeitsverzeichnis (CWD): Prüft den Ordner, aus dem heraus du den postctl-Befehl gestartet hast.
4. Globales Standard-Bildverzeichnis: Prüft das in defaults.image_dir in deiner ~/.config/postctl/config.yaml angegebene Verzeichnis.

Plattformspezifisches Upload-Verhalten

Jede Plattform-API handhabt Medien-Uploads unterschiedlich, was durch die Treiber-Schichten automatisch abstrahiert wird:

• LinkedIn (natives Hosting): Bilder werden als rohe Binär-Assets zu LinkedIn hochgeladen. Die API registriert den Upload, führt ein PUT aus und verknüpft die resultierende URN (z. B. urn:li:digitalmediaAsset:...) mit deinem Beitrag.
• Twitter / X (natives Hosting): Bilder werden an den Twitter-v1.1-Media-Upload-Endpunkt hochgeladen, um eine media_id zu erhalten, die dem v2-Tweet angehängt wird.
• Mastodon / Bluesky (nativ): Mediendateien werden zu Plattform-Attachment-Endpunkten hochgeladen (oder als Blob-Records bei Bluesky AT Protocol) und mit dem Status verknüpft.
• Threads (Meta-HTTPS-Anforderung): Die Threads-API erlaubt keine binären lokalen Uploads. Stattdessen erwartet sie eine öffentliche HTTPS-URL (z. B. https://yourdomain.com/assets/screenshot.png), von der der Meta-Crawler das Bild abruft. Beim Veröffentlichen auf Threads hoste deine Bilder in einer externen Cloud (S3, R2, Imgur) und referenziere diese HTTPS-URL im Frontmatter.

Twitter/X API Setup Guide für postctl

Dieses Dokument beschreibt Schritt für Schritt, wie du die Authentifizierung für Twitter/X in postctl einrichtest.

Es stehen dir zwei Optionen zur Verfügung:

• Option A: Cookie-basierte Authentifizierung (Kostenlos, aber inoffiziell) – Nutzt deine bestehende Browsersitzung. Kostenlos, aber fehleranfällig und mit Risiko einer Kontosperrung.
• Option B: Offizielle API (Kostenpflichtig & Empfohlen) – Nutzt die offizielle Twitter API (erfordert ein bezahltes Abonnement ab ca. $100/Monat oder prepaid API-Credits). Der sichere, stabile Weg.

Option A: Cookie-basierte Authentifizierung (Kostenlos, aber inoffiziell)

Diese Methode simuliert eine echte Browser-Sitzung, indem sie deine Anmelde-Cookies verwendet. Sie ist vollkommen kostenlos und erfordert keine Einrichtung im Twitter Developer Portal.

[!WARNING] Inoffizielle Umgehungsmethode (Risiko von Kontosperrung): Die Cookie-basierte Authentifizierung simuliert eine Web-Sitzung. Diese Methode ist fehleranfällig, verstößt gegen die Nutzungsbedingungen (ToS) von X/Twitter und kann zur Sperrung deines Kontos führen. Der einzig offizielle und sichere Weg zum Posten ist die Verwendung der kostenpflichtigen API (Option B).

• postctl versucht, durch Header-Imitation und künstliche Pausen (5 Sekunden zwischen Beiträgen) das Risiko zu minimieren, bietet aber keine Garantie.
• X verlangt zwingend auch das twid-Cookie (deine User-ID). Trage daher stets den kompletten Cookie-String oder beide Cookies (auth_token und ct0) ein.

Schritt 1: Komplette Browser-Cookies auslesen

Der einfachste Weg ist, den gesamten Cookie-Header einer beliebigen Anfrage zu kopieren:

1. Öffne deinen Webbrowser, gehe auf x.com und stelle sicher, dass du eingeloggt bist. (Am besten einmal aus- und wieder einloggen, um die Sitzung frisch zu starten).
2. Öffne die Entwicklertools (F12 oder Cmd + Option + I).
3. Wechsle auf den Reiter Network (Netzwerk).
4. Lade die Seite einmal neu (F5 oder Cmd + R).
5. Klicke in der Liste der Netzwerkanfragen auf eine beliebige Anfrage zu x.com (z. B. home oder einen GraphQL-Request).
6. Suche im rechten Bereich unter Request Headers (Anfrage-Header) nach der Zeile cookie:.
7. Kopiere den gesamten langen Wert (er fängt meist mit guest_id=... oder kdt=... an und enthält alle Cookies).
8. Suche zusätzlich in den Cookies den Wert für ct0 (dein ca. 160-stelliger CSRF-Token) heraus und kopiere ihn ebenfalls.

Schritt 2: In postctl einrichten

Wir empfehlen die Schnelleinrichtung per Einzeiler im Terminal. Ersetze die Platzhalter durch deine kopierten Werte:

./postctl config setup twitter --cookie "HIER_DER_GESAMTE_KOPIERTE_COOKIE_STRING" --ct0 "HIER_NUR_DER_CT0_WERT"

(Hinweis: Falls du das interaktive Setup über ./postctl config setup twitter startest und Option 2 wählst, kannst du bei der Abfrage nach dem auth_token ebenfalls den gesamten langen Cookie-String einfügen).

🛠️ Fehlerbehebung bei Cookie-Fehlern / Automatisierungswarnungen

Sollte beim Veröffentlichen eines Tweets ein GraphQL-Fehler wie empty tweet ID returned... oder der Fehler 226 (This request looks like it might be automated...) auftreten, greift postctl automatisch auf einen Headless-Browser-Fallback zurück:

1. Automatischer Browser-Start: postctl startet im Hintergrund unsichtbar Google Chrome (mittels chromedp), lädt deine Cookies (auth_token & ct0), navigiert zur Web-Oberfläche von X, befüllt den Composer (inklusive Threads und Medien-Uploads) und klickt auf “Posten”.
2. Voraussetzung: Google Chrome muss auf deinem System installiert sein (wird auf macOS standardmäßig in /Applications gesucht).
3. Abgelaufene Session-Cookies: Wenn auch der Headless-Browser scheitert, sind in der Regel deine Cookies abgelaufen. Wiederhole einfach Schritt 1 und trage die neuen Cookies ein.

Option B: Offizielle API (Kostenpflichtig & Empfohlen)

Wenn du ein offizielles Entwickler-Konto besitzt und die monatlichen API-Kosten tragen möchtest, kannst du die Standard-OAuth-Authentifizierung nutzen.

[!IMPORTANT] Kostenhinweis (Stand 2026): Twitter/X bietet für neu erstellte Developer-Accounts keinen kostenlosen Schreibzugriff (Free Tier) mehr an. Um über die offizielle Schnittstelle zu posten, ist ein kostenpflichtiger API-Zugang (z. B. Basic Tier für ca. $100/Monat oder prepaid Credits) im Developer Portal erforderlich.

Schritt 1: App im Developer Portal konfigurieren

1. Gehe auf das Twitter Developer Portal und melde dich an.
2. Erstelle ein neues Projekt und eine neue App in deinem Portal-Dashboard.
3. Navigiere in den App Settings zu User authentication settings und klicke auf Set up:
   • App Type: Wähle Web App, Automated App or Bot.
   • App Permissions: Wähle Read and Write (wichtig für Schreibrechte).
   • Type of App: Wähle Native App oder Single Page App (für OAuth 2.0 PKCE).
   • Callback URI / Redirect URL: Trage exakt http://localhost:8753/callback ein.
   • Website URL: Trage deine eigene Website oder https://github.com/aeon022/postctl ein.
4. Speichere die Einstellungen und kopiere die angezeigte Client ID und das Client Secret an einen sicheren Ort.

Schritt 2: Schlüssel hinterlegen

# Client ID eintragen
./postctl config set twitter.client_id "DEINE_CLIENT_ID"

# Client Secret eintragen
./postctl config set twitter.client_secret "DEIN_CLIENT_SECRET"

Schritt 3: Authentifizierung durchführen

./postctl auth twitter

Es öffnet sich ein Browserfenster, in dem du der App den Zugriff erlaubst. Nach erfolgreichem Login speichert postctl dein verschlüsseltes Access- und Refresh-Token.

LinkedIn API Setup Guide für postctl

Dieses Dokument beschreibt Schritt für Schritt, wie du eine LinkedIn-Entwickler-App erstellst, diese auf das moderne OpenID Connect (OIDC) migrierst und deine Zugangsdaten für postctl einrichtest.

1. Entwickler-App auf LinkedIn erstellen

1. Gehe zum LinkedIn Developer Portal.
2. Melde dich mit deinem persönlichen LinkedIn-Konto an.
3. Klicke auf Create App:
   • App Name: Gib deiner App einen Namen (z. B. postctl-publisher).
   • LinkedIn Page: Verknüpfe die App mit deiner LinkedIn-Unternehmensseite oder erstelle eine temporäre Seite (Pflichtfeld).
   • App Logo: Lade das generierte Logo aus postctl/icons (oder ein anderes quadratisches Bild) hoch.
   • Legal Terms: Stimme den Bedingungen zu und klicke auf Create app.

2. Produkte hinzufügen (Sehr wichtig!)

Standardmäßig hat eine neue LinkedIn-App keine Berechtigungen für Beitrags-Postings. Seit August 2023 hat LinkedIn die alten Berechtigungen (r_liteprofile) abgelöst. Du musst die folgenden Produkte aktivieren:

1. Gehe in deiner App zum Reiter Products.
2. Suche nach Share on LinkedIn und klicke auf Request access (dies wird in der Regel sofort genehmigt).
3. Suche nach Sign In with LinkedIn using OpenID Connect (nicht das veraltete Sign In with LinkedIn) und aktiviere dieses, um den modernen OIDC-Login freizuschalten.

3. Authentifizierungs-Einstellungen konfigurieren

1. Gehe zum Reiter Auth.
2. Scrolle zum Bereich OAuth 2.0 settings:
   • Füge unter Authorized Redirect URLs folgenden Callback hinzu: http://localhost:8753/callback
   • Klicke auf Update.
3. Überprüfe im Bereich OAuth 2.0 scopes, ob dir nun folgende Scopes angezeigt werden:
   • openid, profile, w_member_social, email.

4. Client ID & Client Secret kopieren

1. Bleibe im Reiter Auth.
2. Kopiere im Bereich Application credentials die Client ID und das Client Secret.

5. In postctl konfigurieren

Nutze das CLI, um die Zugangsdaten in deiner config.yaml zu speichern (nutze das lokale Binary ./postctl):

# Client ID konfigurieren
./postctl config set linkedin.client_id "DEINE_CLIENT_ID"

# Client Secret konfigurieren
./postctl config set linkedin.client_secret "DEIN_CLIENT_SECRET"

Überprüfe die Einstellungen:

./postctl config show

6. Verbindung herstellen (Auth Flow)

Starte den Authentifizierungs-Flow:

./postctl auth linkedin

1. Es öffnet sich automatisch ein Browserfenster, das dich auffordert, deiner App den Zugriff auf dein LinkedIn-Profil zu erlauben.
2. Nach Klick auf Zulassen/Allow wirst du zum lokalen Webserver weitergeleitet.
3. Das CLI fängt das Token über den OIDC-Flow ab, ermittelt die Benutzer-ID (über /v2/userinfo), verschlüsselt das Access Token und speichert es in der lokalen SQLite-Datenbank.
4. Du bist nun bereit, Beiträge auf LinkedIn zu veröffentlichen!

Threads (Meta) API Setup Guide für postctl

Dieses Dokument beschreibt detailliert, wie du Zugriff auf die offizielle Threads API erhältst, deine App im Meta Developer Portal konfigurierst und die Authentifizierung für postctl einrichtest.

1. Meta Developer App erstellen

1. Gehe zum Meta Developer Portal und melde dich an.
2. Klicke oben rechts auf Meine Apps und dann auf App erstellen (Create App):
   • Wähle als App-Typ Anderes (Other) und klicke auf Weiter.
   • Wähle als App-Typ Verbraucher (Consumer) oder einen Typ, der dir Zugriff auf die Threads/Instagram API ermöglicht.
   • Vergib einen Namen für deine Anwendung (z. B. postctl-threads-app).
   • Klicke auf App erstellen (Ggf. musst du dein Facebook-Passwort eingeben).

2. Threads API hinzufügen

1. Scrolle im Dashboard deiner erstellten App nach unten zu Produkt hinzufügen (Add Products to Your App).
2. Suche nach Threads API und klicke auf Einrichten (Set Up).
3. Die App befindet sich nun im Entwicklungsmodus (In Development) – das ist perfekt und wichtig für die lokale Entwicklung.

3. Callback-URLs konfigurieren (Wichtig: Pflichtfelder & HTTPS!)

Meta erzwingt für die Threads API eine sichere HTTPS-Verbindung. Gleichzeitig weigert sich das Dashboard, Änderungen zu speichern, wenn Deinstallations- oder Lösch-URLs fehlen.

1. Klicke in der linken Navigationsleiste unter Threads API auf Threads-Einstellungen (Threads Settings) oder gehe zu Anwendungsfälle (Use Cases) ➔ Auf Threads API zugreifen ➔ Anpassen / Einstellungen.
2. Konfiguriere dort die folgenden drei Felder:
   • Callback-URLs umleiten (Valid OAuth Redirect URIs): https://localhost:8753/callback (Wichtig: https statt http!)
   • Callback-URL deinstallieren (Uninstall Callback URL): https://localhost:8753/uninstall (oder https://example.com/uninstall als Platzhalter)
   • Callback-URL löschen (Delete Callback URL): https://localhost:8753/delete (oder https://example.com/delete als Platzhalter)
3. Klicke unten rechts auf Speichern (Save).

4. App-Rollen & Tester-Einladung einrichten (Wichtig!)

Da sich deine App im Entwicklungsmodus befindet, kann sie nur von Benutzern authentifiziert werden, die explizit als Tester registriert sind.

Schritt A: Tester im Meta-Dashboard hinzufügen

1. Klicke in der linken Navigationsleiste auf App-Rollen (App Roles / das Personen-Symbol) ➔ Rollen (Roles).
2. Scrolle ganz nach unten zum Bereich Threads-Tester (Threads Testers).
3. Klicke auf Threads-Tester hinzufügen (Add Threads Testers).
4. Gib den exakten Instagram/Threads-Benutzernamen des Kontos ein, mit dem du später posten willst, und klicke auf Bestätigen.

Schritt B: Einladung in Instagram annehmen

Die Einladung muss von deinem Threads-Konto manuell bestätigt werden:

1. Logge dich im Desktop-Browser auf Instagram.com mit dem entsprechenden Account ein.
2. Gehe auf dein Profil ➔ Klicke auf das Zahnrad-Symbol (Einstellungen).
3. Navigiere in der linken Leiste zu Apps und Websites (Apps and Websites).
4. Klicke oben auf den Reiter Tester-Einladungen (Tester Invites).
5. Dort wird dir die Einladung deiner App (z. B. postctl-threads-app) angezeigt. Klicke auf Akzeptieren (Accept).

5. App ID & App Secret abrufen

1. Gehe in der linken Navigationsleiste auf App-Einstellungen (App Settings) ➔ Standard (Basic).
2. Kopiere die App-ID (App ID).
3. Kopiere den App-Geheimschlüssel (App Secret / erfordert Klick auf Anzeigen und Passworteingabe).

6. In postctl konfigurieren

Speichere deine Threads-Zugangsdaten über dein Terminal ab (verwende ./postctl für das lokale Binary):

# App-ID eintragen
./postctl config set threads.app_id "DEINE_APP_ID"

# App Secret eintragen
./postctl config set threads.app_secret "DEIN_APP_SECRET"

Überprüfe deine Konfiguration:

./postctl config show

7. Verbindung herstellen (Auth Flow)

Führe den Auth-Flow aus:

./postctl auth threads

1. Dein Standardbrowser öffnet sich und leitet dich zum Threads-Anmeldedialog weiter.
2. Melde dich mit deinem Threads-Account an und erlaube den Zugriff auf deine Profildaten und Medien (threads_basic und threads_content_publish).
3. Nach dem Login leitet dich Meta zurück zu https://localhost:8753/callback.
4. Umgang mit der SSL-Warnung im Browser:
   • Da der lokale Server von postctl zur Verschlüsselung ein temporäres, selbstsigniertes SSL-Zertifikat nutzt, wird dein Browser die Warnung „Dies ist keine sichere Verbindung“ (oder NET::ERR_CERT_AUTHORITY_INVALID) anzeigen.
   • Das ist völlig normal und sicher, da die Kommunikation nur lokal auf deinem Mac stattfindet.
   • Klicke im Browser-Fenster auf „Erweitert“ (oder Details anzeigen) und wähle „Weiter zu localhost (unsicher)“.
5. Sobald du darauf klickst, empfängt postctl das Zugriffstoken, tauscht es im Hintergrund in ein 60 Tage gültiges Long-Lived Token um und speichert es verschlüsselt in der SQLite-Datenbank.
6. Im Terminal erscheint die Erfolgsmeldung! Du bist nun bereit, Beiträge auf Threads zu posten.

🦋 Bluesky- & Mastodon-Einrichtungsanleitung

Erfahre, wie du postctl mit Bluesky (über das AT Protocol) und Mastodon-Instanzen verbindest.

1. Bluesky-Integration

Bluesky nutzt das dezentrale AT Protocol. Statt komplexem OAuth kommen sichere App-Passwörter zum Einsatz.

Schritt A: App-Passwort erstellen

1. Melde dich in deinem Browser bei deinem Bluesky-Konto an.
2. Gehe zu Settings ➔ App Passwords.
3. Klicke auf Create App Password, gib ihm einen Namen (z. B. postctl-cli) und kopiere das generierte Passwort (sieht meist aus wie xxxx-xxxx-xxxx-xxxx).

Schritt B: postctl konfigurieren

Konfiguriere deinen Handle und dein App-Passwort:

# Handle konfigurieren
./postctl config set bluesky.handle "yourname.bsky.social"

# App-Passwort konfigurieren
./postctl config set bluesky.app_password "xxxx-xxxx-xxxx-xxxx"

Schritt C: Authentifizieren

./postctl auth bluesky

Das CLI testet die Verbindung, ruft dein Profil ab und speichert die Sitzungs-Tokens in deiner SQLite-Datenbank. Bluesky-Beiträge unterstützen bis zu 300 Zeichen.

2. Mastodon-Integration

Mastodon unterstützt föderierte Instanzen und registriert Client-Zugangsdaten pro Instanz.

Schritt A: Instanz-URL konfigurieren

Standardmäßig verbindet sich postctl mit https://mastodon.social. Bist du auf einer anderen Instanz, konfiguriere sie zuerst:

./postctl config set mastodon.instance_url "https://fosstodon.org"

Schritt B: Authentifizieren

Starte den Login-Ablauf:

./postctl auth mastodon

1. Das CLI prüft, ob auf dieser Instanz bereits eine Client-Anwendung existiert. Falls nicht, registriert es automatisch eine neue App namens postctl auf deiner Instanz.
2. Ein Browserfenster öffnet sich und bittet dich, die App zu autorisieren.
3. Melde dich an und klicke auf Authorize.
4. Die Tokens werden abgerufen und sicher in deiner lokalen DB gespeichert. Mastodon-Beiträge unterstützen bis zu 500 Zeichen.

🤖 Facebook-Einrichtungsanleitung

Konfiguriere die automatisierte Veröffentlichung auf Facebook-Business-/Creator-Seiten über Meta-Graph-API-Tokens.

Facebook-Integration

Facebook-Beiträge werden über Meta-Graph-API-Tokens direkt an Business-/Creator-Seiten gesendet.

Schritt A: App im Meta-Portal erstellen

1. Gehe zum Meta Developer Portal.
2. Erstelle eine App vom Typ Business oder Other.
3. Konfiguriere die OAuth-Redirect-URL: http://localhost:8753/callback
4. Gehe zu Settings ➔ Basic und kopiere deine App ID und dein App Secret.
5. Ermittle die Ziel-Facebook-Page-ID (zu finden in den "Info"-Angaben deiner Facebook-Seite).

Schritt B: In der Konfiguration speichern

./postctl config set facebook.app_id "YOUR_FB_APP_ID"
./postctl config set facebook.app_secret "YOUR_FB_APP_SECRET"
./postctl config set facebook.page_id "YOUR_FB_PAGE_ID"

Schritt C: Authentifizierung ausführen

./postctl auth facebook

Bestätige die Anfrage, um das Verwalten und Veröffentlichen von Seiten zu autorisieren. Das Zugriffs-Token wird gegen ein dauerhaftes Seiten-Zugriffs-Token eingetauscht und sicher gespeichert.

postctl — Spezifikation

Überblick

postctl ist ein in Go geschriebenes TUI-CLI-Tool, das Social-Media-Beiträge und Blogartikel über Twitter/X, LinkedIn, Threads, Mastodon, Bluesky, Facebook, Telegram, Discord, Reddit, Dev.to, Hashnode und Medium hinweg verwaltet. Beiträge werden als Markdown-Dateien verfasst, in eine lokale SQLite-Datenbank importiert, in einer Terminal-UI vorgeschaut und über Plattform-APIs veröffentlicht — sofort oder nach Zeitplan.

User Stories

Als Solo-Entwickler / Indie Hacker:

• Ich will Beiträge als Markdown-Dateien in meinem Repo schreiben
• Ich will vorschauen, wie ein Twitter-Thread aussehen wird, bevor ich poste
• Ich will Beiträge für optimales Timing über Zeitzonen hinweg einplanen
• Ich will denselben Inhalt mit einem Befehl auf mehreren Plattformen posten
• Ich will sehen, was ich wann gepostet habe
• Ich will eine Zeichenzahl-Prüfung vor dem Posten (280 Zeichen pro Tweet)

Als KI-Assistent (Claude, GPT, Antigravity):

• Ich will korrekt formatierte Markdown-Beiträge erstellen
• Ich will das Posten über CLI-Befehle auslösen
• Ich will Beitragsstatus und -verlauf prüfen können
• Ich will den kompletten Workflow durchgängig ohne menschliches Eingreifen ausführen (außer Freigabe)
• Ich will strukturierte JSON-Ausgabe für alle Befehle, um Ergebnisse zu parsen
• Ich will einen Dry-Run-Modus, um alles zu prüfen, bevor es verbindlich wird

Prinzip: KI als Operator

postctl ist darauf ausgelegt, dass KI es bedient — nicht nur Text generiert.

Die meisten Social-Media-Tools behandeln KI als Copywriting-Feature — “KI schreibt deine Bildunterschrift”. postctl behandelt KI als Operator des gesamten Tools. Der Mensch legt die Strategie fest und gibt frei; die KI führt aus.

Workflow: KI bedient, Mensch gibt frei

Mensch: "Poste den neuen Orbiter-v0.3.66-Release"
   ↓
KI (Claude/GPT):
   1. Schreibt Beiträge als Markdown-Dateien (alle Plattformen, DE+EN)
   2. postctl import ./posts/
   3. postctl list --format json          → zeigt Entwürfe
   4. "Hier sind 8 fertige Beiträge. Prüfen?"
   ↓
Mensch: "LinkedIn DE ändern, sonst passt es"
   ↓
KI:
   5. Bearbeitet die Datei, importiert neu
   6. postctl campaign post orbiter-v0366 --dry-run
   7. "Dry Run erfolgreich. Posten?"
   ↓
Mensch: "go"
   ↓
KI:
   8. postctl campaign post orbiter-v0366
   9. "Gepostet. 4/4 Twitter, 2/2 LinkedIn, 2/2 Threads. IDs: ..."

Designanforderungen für den KI-Betrieb

1. Alle Befehle müssen nicht-interaktiv funktionieren — keine Prompts, kein “bist du sicher?”, keine interaktiven Menüs. Flags steuern alles.
2. --format json bei allen Befehlen — strukturierte Ausgabe, die KI parsen kann. Standard ist menschenlesbar, --format json liefert maschinenlesbar.
3. --dry-run bei allen verändernden Befehlen — KI kann ohne Nebenwirkungen vorschauen. Mensch gibt frei, dann führt KI ohne --dry-run aus.
4. Exit-Codes — 0 = Erfolg, 1 = Validierungsfehler, 2 = API-Fehler, 3 = Auth-Fehler. KI liest Exit-Codes, nicht nur die Ausgabe.
5. Idempotente Importe — postctl import zweimal auszuführen dupliziert keine Beiträge. KI kann nach Bearbeitungen ohne Aufräumen neu importieren.
6. Wiederherstellung nach Teilfehlern — schlägt Tweet 3/5 fehl, setzt postctl post <id> --resume dort fort, wo es aufgehört hat. KI muss den Zustand nicht manuell verfolgen.
7. Kein Browser nötig — der OAuth-Flow nutzt einen Localhost-Callback, aber nach der Authentifizierung läuft alles rein über die CLI. KI muss nie einen Browser öffnen.
8. Batch-Operationen — postctl campaign post <name> postet alle Beiträge einer Kampagne. KI muss nicht über einzelne Beiträge loopen.

Beispiel für JSON-Ausgabe

$ postctl list --format json
{
  "posts": [
    {
      "id": "orbiter-v0366-twitter-en",
      "platform": "twitter",
      "type": "thread",
      "status": "draft",
      "tweets": 5,
      "images": 2,
      "chars": [245, 220, 180, 260, 190],
      "valid": true
    }
  ],
  "total": 8,
  "by_status": {"draft": 8, "posted": 0, "scheduled": 0}
}

$ postctl post orbiter-v0366-twitter-en --format json
{
  "ok": true,
  "platform": "twitter",
  "tweets_posted": 5,
  "thread_id": "1234567890",
  "urls": ["https://x.com/gerwinweiher/status/1234567890"]
}

Kern-Workflows

1. Import-Workflow

Markdown-Dateien → postctl import → SQLite-DB
                                    ↓
                              Beiträge mit Status "draft"

Eingabe: Verzeichnis mit .md-Dateien mit YAML-Frontmatter Verarbeitung:

• Frontmatter parsen (platform, type, language, campaign, schedule, images)
• Body in Tweets zerlegen (Trennung bei ## Tweet N-Überschriften)
• Reply-Abschnitt erkennen (## Reply)
• Validieren: Zeichenzahl pro Tweet (≤280), Bildpfade existieren
• Deterministische ID aus Dateiname + Plattform erzeugen
• In SQLite einfügen/aktualisieren (Upsert auf ID)

Ausgabe: Beiträge in der DB mit Status draft oder scheduled (falls schedule:-Frontmatter vorhanden)

2. Vorschau-Workflow

postctl (ohne Argumente) → TUI
                      ↓
              Dashboard → Beitragsliste → Detailansicht
                                        ↓
                                   Tweet-für-Tweet-Vorschau
                                   mit Zeichenzahl + Bildindikatoren

3. Post-Workflow

postctl post <id> → Aus DB laden → Validieren → API-Aufruf → Status aktualisieren
                                                ↓
                                          Zuerst Bilder hochladen
                                          Dann Text mit Media-IDs posten
                                          Bei Threads: sequenziell posten,
                                          als Antwort auf vorherige Tweet-ID

Ablauf beim Thread-Posten:

1. Alle Bilder hochladen → Media-IDs erhalten
2. Tweet 1 posten → Tweet-ID erhalten
3. Tweet 2 als Antwort auf Tweet 1 posten → Tweet-ID erhalten
4. Tweet 3 als Antwort auf Tweet 2 posten → …
5. Reply-Tweet als Antwort auf den letzten Tweet posten
6. DB aktualisieren: status = “posted”, platform_id = erste Tweet-ID

Fehlerbehandlung:

• Schlägt Tweet N fehl: Beitrag als “partial” markieren, letzte erfolgreiche Tweet-ID speichern
• Wiederholung: ab dem fehlgeschlagenen Tweet fortsetzen (erfolgreiche nicht erneut posten)
• Bei Rate-Limit: warten und mit exponentiellem Backoff wiederholen

4. Zeitplan-Workflow

postctl schedule <id> "2026-06-23 09:00"
       ↓
  DB aktualisieren: status = "scheduled", scheduled_at = Zeitstempel
       ↓
  Scheduler-Daemon greift zur richtigen Zeit
       ↓
  Wie der Post-Workflow

Scheduler:

• Läuft als Hintergrund-Goroutine, während die TUI offen ist
• Läuft auch als postctl daemon im Headless-Modus
• Prüft alle 30 Sekunden auf fällige Beiträge
• Postet in Reihenfolge von scheduled_at

5. Auth-Workflow

postctl auth twitter
       ↓
  Browser öffnen → Twitter-OAuth-Zustimmungsseite
       ↓
  Lokaler HTTP-Server auf :8753 fängt den Callback ab
       ↓
  Code gegen Token tauschen
       ↓
  Verschlüsseltes Token in SQLite speichern

Markdown-Formatspezifikation

Frontmatter-Felder

Body-Format

Einzelbeitrag (LinkedIn, Threads):

---
platform: linkedin
type: single
---

Der gesamte Beitragstext kommt hierher.
Mehrere Absätze werden unterstützt.

Thread (Twitter):

---
platform: twitter
type: thread
images:
  - screenshots/01-dashboard.png
---

## Tweet 1

Inhalt des ersten Tweets. Keine Links hier, wegen algorithmischer Reichweite.

## Tweet 2

Zweiter Tweet. Bild anhängen: screenshots/01-dashboard.png

## Tweet 3

Inhalt des dritten Tweets.

## Reply

Links und Hashtags kommen in den Selbst-Reply.
github.com/aeon022/orbiter

#opensource #webdev

Regeln:

• ## Tweet N trennt in einzelne Tweets
• ## Reply wird als Antwort auf den letzten Tweet gepostet
• Bildzuordnung: erstes Bild in der images:-Liste geht an Tweet 2, zweites an Tweet 3, usw. Alternativ inline mit <!-- image: filename.png -->
• Zeichenzahl: ≤280 pro Tweet (URLs zählen als 23 Zeichen, nach Twitters t.co)
• Leere Tweets werden übersprungen

Plattform-API-Details

Twitter/X v2

Auth: OAuth 2.0 mit PKCE

GET https://twitter.com/i/oauth2/authorize
  ?client_id=...
  &redirect_uri=http://localhost:8753/callback
  &scope=tweet.read+tweet.write+users.read+offline.access
  &response_type=code
  &code_challenge=...
  &code_challenge_method=S256
  &state=...

Tweet posten:

POST https://api.twitter.com/2/tweets
Authorization: Bearer <token>
Content-Type: application/json

{"text": "...", "media": {"media_ids": ["..."]}, "reply": {"in_reply_to_tweet_id": "..."}}

Medien hochladen (v1.1 — weiterhin erforderlich):

POST https://upload.twitter.com/1.1/media/upload.json
Content-Type: multipart/form-data

media_data=<base64>

LinkedIn v2

Beitrag:

POST https://api.linkedin.com/v2/ugcPosts
Authorization: Bearer <token>

{
  "author": "urn:li:person:<id>",
  "lifecycleState": "PUBLISHED",
  "specificContent": {
    "com.linkedin.ugc.ShareContent": {
      "shareCommentary": {"text": "..."},
      "shareMediaCategory": "IMAGE",
      "media": [{"status": "READY", "media": "<asset-urn>"}]
    }
  },
  "visibility": {"com.linkedin.ugc.MemberNetworkVisibility": "PUBLIC"}
}

Bild-Upload (2 Schritte):

1. Registrieren: POST /v2/assets?action=registerUpload → liefert Upload-URL + Asset-URN
2. Hochladen: PUT <upload-url> mit binären Bilddaten

Threads (Meta Graph API)

Container erstellen:

POST https://graph.threads.net/v1.0/<user_id>/threads
  ?media_type=TEXT
  &text=...
  &access_token=...

Veröffentlichen:

POST https://graph.threads.net/v1.0/<user_id>/threads_publish
  ?creation_id=<container_id>
  &access_token=...

Fehlerbehandlungs-Strategie

Nicht-Ziele (v1)

• Kein Web-Dashboard
• Keine Mehrbenutzer-/Team-Funktionen
• Keine eingebaute Bildgenerierung
• Kein automatisches Cross-Posting (explizit pro Plattform)

Erfolgsmetriken

• 20 Markdown-Beiträge in <1 Sekunde importieren
• Einen 6-Tweet-Thread mit 2 Bildern in <10 Sekunden posten
• TUI rendert mit 60fps im Standard-Terminal
• Einzelnes Binary, <20MB, keine Laufzeit-Abhängigkeiten
• Läuft unter macOS, Linux, Windows

Zukünftige Features (v2+)

Hinweis: Alles in diesem Abschnitt ist eine zukunftsgerichtete Idee, keine Zusage und kein aktuell verkauftes Produkt. postctls tatsächliches Preismodell ist heute die einmalige missionctl-Bundle-Lizenz (Polar.sh), beschrieben auf der Preise-Seite — nicht die Abo-Stufen, die unten skizziert sind.

postctl generate

KI generiert Beiträge aus einer URL oder einem Markdown-Artikel.

• Eingabe: URL, Markdown-Datei oder freier Text
• Ausgabe: Thread-Entwurf + LinkedIn-Beitrag + Threads-Beitrag als Markdown
• Nutzt die Claude-API, OpenAI-API oder Ollama (lokal)
• Nutzer prüft und bearbeitet vor dem Posten

postctl repurpose

Nimmt einen bestehenden Beitrag und konvertiert ihn für andere Plattformen.

• Dev.to-Artikel → Twitter-Thread + LinkedIn + Threads
• Twitter-Thread → LinkedIn-Langbeitrag
• Passt Länge, Ton und Hashtags automatisch an

postctl analytics

Holt Engagement-Daten von den APIs nach dem Posten.

• Likes, Retweets, Impressions (Twitter)
• Reaktionen, Kommentare (LinkedIn)
• Ermittelt beste Posting-Zeiten
• Terminal-Dashboard mit Sparklines

postctl template

Vorgefertigte Beitragsstrukturen.

• postctl template launch — Produkt-Launch-Ankündigung
• postctl template feature — Feature-Update-Thread
• postctl template thought — Thought-Leadership-Beitrag
• Erzeugt eine Markdown-Datei mit Platzhaltern

Ökosystem-Vision

postctl ist Teil eines Content-Loops:

Orbiter (Erstellen) → postctl (Verteilen) → Analytics (Lernen) → Orbiter (Verbessern)

1. Content in Orbiter schreiben (Blogbeiträge, Seiten)
2. Beiträge als Markdown exportieren/generieren
3. postctl verteilt auf Twitter, LinkedIn, Threads
4. Analytics zeigt, was funktioniert
5. Erkenntnisse fließen in den nächsten Content-Zyklus

Langfristig: orbiter export --to-postctl als Integration.

Projekt-Setup

Repository: ~/Developing/Projects/postctl
Module:     github.com/aeon022/postctl
License:    MIT

Go Tutorial — postctl

Dieses Tutorial führt dich durch Go anhand des postctl-Projekts. Jede Phase baut ein Feature und lehrt neue Go-Konzepte.

Kurs-Konzept

Dieses Tutorial wird parallel zum Projekt geschrieben und kann als bezahlter Kurs veröffentlicht werden:

• Format: Video-Serie (Screen Recording + Voiceover) + geschriebenes Tutorial
• Titel: “Build a real CLI tool in Go — from zero to production”
• Zielgruppe: Entwickler die Go lernen wollen anhand eines echten Projekts
• Teaser: Phase 1 + 2 gratis als Blog-Posts auf Dev.to (Traffic + Leads)
• Vollversion: Phase 3-7 als bezahlter Kurs ($49-79)
• Plattform: eigene Seite (Lemon Squeezy) oder Udemy
• Sprachen: Deutsch (primär) + Englisch

Jede Phase endet mit einer Challenge — einer Aufgabe die der Lerner selbst löst bevor er die Lösung sieht.

Voraussetzungen

# Go installieren
brew install go

# Version prüfen (1.22+)
go version

# Editor: VS Code + Go Extension (gopls)
code --install-extension golang.go

Phase 1: Hello Go — Projekt Setup

Was wir bauen

Grundgerüst mit Cobra CLI: postctl version, postctl help

Go-Konzepte

• Go Modules: Dependency Management (go.mod)
• Packages: Code-Organisation in Ordnern
• func main(): Entry Point
• fmt.Println: Output
• Strings: String Formatting mit fmt.Sprintf

Schritte

# 1. Projekt erstellen
mkdir postctl && cd postctl
go mod init github.com/aeon022/postctl

# 2. Cobra installieren
go get github.com/spf13/cobra@latest

# 3. Datei erstellen
mkdir -p cmd

main.go — Entry Point:

package main

import "github.com/aeon022/postctl/cmd"

func main() {
    cmd.Execute()
}

cmd/root.go — Root Command:

package cmd

import (
    "fmt"
    "os"

    "github.com/spf13/cobra"
)

// Version — wird beim Build gesetzt
var Version = "dev"

var rootCmd = &cobra.Command{
    Use:   "postctl",
    Short: "Social media posting from the terminal",
    Long:  "postctl manages social media posts from Markdown files.\nTwitter/X, LinkedIn, and Threads — from one CLI.",
}

// Execute — wird von main() aufgerufen
func Execute() {
    if err := rootCmd.Execute(); err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
}

func init() {
    // Version subcommand
    rootCmd.AddCommand(&cobra.Command{
        Use:   "version",
        Short: "Print version",
        Run: func(cmd *cobra.Command, args []string) {
            fmt.Printf("postctl %s\n", Version)
        },
    })
}

# Testen
go run . version
# → postctl dev

# Binary bauen
go build -o postctl .
./postctl version

🎓 Gelernt

• go mod init erstellt ein Modul
• go get installiert Dependencies
• package main + func main() = Programm-Start
• Cobra strukturiert CLI Commands als Baumstruktur
• &cobra.Command{} = Pointer zu einem Struct

Phase 2: Structs & Models — Datenstruktur

Was wir bauen

Post-Datenmodell: Post, Tweet, Campaign Structs

Go-Konzepte

• Structs: Custom Types
• Felder + Tags: JSON/YAML Tags für Serialisierung
• Methoden: Funktionen auf Structs
• Slices: Dynamische Arrays
• Enums via Konstanten: const StatusDraft = "draft"

Code

internal/models/post.go:

package models

import "time"

// Status-Konstanten
const (
    StatusDraft     = "draft"
    StatusScheduled = "scheduled"
    StatusPosted    = "posted"
    StatusFailed    = "failed"
    StatusPartial   = "partial"
)

// Platform-Konstanten
const (
    PlatformTwitter  = "twitter"
    PlatformLinkedIn = "linkedin"
    PlatformThreads  = "threads"
)

// Post repräsentiert einen Social-Media-Post
type Post struct {
    ID          string    `json:"id" yaml:"id"`
    Platform    string    `json:"platform" yaml:"platform"`
    Type        string    `json:"type" yaml:"type"`           // thread, single, article
    Language    string    `json:"language" yaml:"language"`
    Campaign    string    `json:"campaign" yaml:"campaign"`
    Title       string    `json:"title" yaml:"title"`
    Tweets      []Tweet   `json:"tweets" yaml:"tweets"`       // Für Threads
    Body        string    `json:"body" yaml:"body"`            // Für Singles
    Images      []string  `json:"images" yaml:"images"`
    Tags        []string  `json:"tags" yaml:"tags"`
    Status      string    `json:"status" yaml:"status"`
    ScheduledAt *time.Time `json:"scheduled_at" yaml:"schedule"`
    PostedAt    *time.Time `json:"posted_at" yaml:"posted_at"`
    PlatformID  string    `json:"platform_id" yaml:"platform_id"`
    Error       string    `json:"error" yaml:"error"`
    SourceFile  string    `json:"source_file" yaml:"source_file"`
    CreatedAt   time.Time `json:"created_at" yaml:"created_at"`
    UpdatedAt   time.Time `json:"updated_at" yaml:"updated_at"`
}

// Tweet ist ein einzelner Tweet in einem Thread
type Tweet struct {
    Index   int    `json:"index"`
    Content string `json:"content"`
    Image   string `json:"image"`   // Optionaler Bild-Pfad
    IsReply bool   `json:"is_reply"` // Letzter Tweet = Reply mit Links
}

// CharCount gibt die Zeichenanzahl zurück (URLs = 23 Zeichen)
func (t Tweet) CharCount() int {
    // Vereinfacht — Twitter zählt URLs als 23 Zeichen
    return len([]rune(t.Content))
}

// IsValid prüft ob der Tweet innerhalb des Limits ist
func (t Tweet) IsValid() bool {
    return t.CharCount() <= 280
}

// Campaign gruppiert Posts
type Campaign struct {
    Slug     string
    Posts    []Post
    Posted   int
    Drafts   int
    Scheduled int
}

# Kompiliert? 
go build ./internal/models/

🎓 Gelernt

• Structs sind Go’s “Klassen” (ohne Vererbung)
• json:"name" Tags steuern JSON-Serialisierung
• *time.Time = Pointer, kann nil sein (= optional)
• []Tweet = Slice von Tweets (dynamisches Array)
• Methoden: func (t Tweet) CharCount() int — Methode auf Tweet
• []rune(s) konvertiert String zu Unicode-Zeichen (für korrekte Länge)

Phase 3: Markdown Parser — Dateien einlesen

Was wir bauen

postctl import ./posts/ — liest Markdown-Dateien und erstellt Posts

Go-Konzepte

• File I/O: os.ReadFile, filepath.Walk
• String-Manipulation: strings.Split, strings.TrimSpace
• Regular Expressions: regexp.MustCompile
• Error Handling: if err != nil { return err }
• YAML Parsing: External Package
• Unit Tests: func TestParseTweets(t *testing.T)

🎓 Gelernt

• os.ReadFile liest eine ganze Datei
• filepath.Walk iteriert über Verzeichnisse
• strings.SplitN(s, "---", 3) splittet Frontmatter
• regexp.MustCompile für Pattern Matching
• t.Run("name", func(t *testing.T) { ... }) für Sub-Tests
• Error Handling ist explizit — kein try/catch

Phase 4: SQLite Store — Daten speichern

Go-Konzepte

• Interfaces: Store Interface definieren
• SQL: database/sql Standard-Paket
• Prepared Statements: SQL Injection verhindern
• Migrations: Schema-Versionierung
• defer: Resource Cleanup (defer db.Close())

🎓 Gelernt

• interface{} definiert Verhalten, nicht Struktur
• defer führt Code am Funktions-Ende aus (wie finally)
• db.QueryRow().Scan(&var) liest Werte direkt in Variablen
• _ ignoriert Return-Werte die du nicht brauchst

Phase 5: TUI — Terminal Interface

Go-Konzepte

• Bubbletea Elm-Architektur: Model → Update → View
• tea.Msg: Message-basierte Kommunikation
• tea.Cmd: Async Side-Effects
• Lipgloss: Styling mit Methoden-Chaining
• Composition: Kleine Komponenten zusammenbauen

Bubbletea Grundprinzip

// Model hält den State
type model struct {
    posts    []models.Post
    cursor   int
    selected string
}

// Init — wird einmal aufgerufen
func (m model) Init() tea.Cmd {
    return nil // Keine initiale Aktion
}

// Update — reagiert auf Events
func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
    switch msg := msg.(type) {
    case tea.KeyMsg:
        switch msg.String() {
        case "q", "ctrl+c":
            return m, tea.Quit
        case "up", "k":
            if m.cursor > 0 { m.cursor-- }
        case "down", "j":
            if m.cursor < len(m.posts)-1 { m.cursor++ }
        }
    }
    return m, nil
}

// View — rendert den Screen (wird bei jedem Update aufgerufen)
func (m model) View() string {
    s := "Posts:\n\n"
    for i, p := range m.posts {
        cursor := " "
        if i == m.cursor { cursor = ">" }
        s += fmt.Sprintf("%s %s [%s]\n", cursor, p.Title, p.Status)
    }
    s += "\n↑↓ navigate · q quit"
    return s
}

🎓 Gelernt

• Elm-Architektur: unidirektionaler Datenfluss
• switch msg := msg.(type) = Type Switch (Go’s Pattern Matching)
• tea.Cmd für async Operationen (API Calls etc.)
• Lipgloss: lipgloss.NewStyle().Bold(true).Foreground(lipgloss.Color("#8b7cf8"))

Phase 6: APIs — Twitter, LinkedIn, Threads

Go-Konzepte

• HTTP Client: http.NewRequest, http.Client.Do
• OAuth 2.0: Authorization Code Flow mit PKCE
• Goroutines: go func() { ... }()
• Channels: ch := make(chan Result)
• Context: ctx, cancel := context.WithTimeout(ctx, 10*time.Second)
• encoding/json: Request/Response Bodies
• Interfaces: Platform Interface für alle Plattformen

Platform Interface

type Platform interface {
    Name() string
    Auth(ctx context.Context) error
    Post(ctx context.Context, post *models.Post) (string, error)  // returns platform ID
    UploadImage(ctx context.Context, path string) (string, error) // returns media ID
    IsAuthenticated() bool
}

🎓 Gelernt

• Interfaces in Go sind implizit — kein implements
• Goroutines sind leichtgewichtig (~8KB Stack)
• Channels synchronisieren Goroutines
• context.Context für Timeouts und Cancellation
• json.NewDecoder(resp.Body).Decode(&result) parsed HTTP Response

Phase 7: Scheduler & Polish

Go-Konzepte

• Ticker: time.NewTicker(30 * time.Second)
• Select: select { case <-ticker.C: ... case <-quit: return }
• Graceful Shutdown: signal.Notify(quit, os.Interrupt)
• Build Tags: go build -ldflags "-X cmd.Version=1.0.0"
• Cross-Compilation: GOOS=linux GOARCH=amd64 go build

🎓 Gelernt

• select wartet auf mehrere Channels gleichzeitig
• signal.Notify fängt Ctrl+C ab
• Go cross-compiled ohne Extra-Tools
• Ein Binary für alles — keine Runtime-Dependencies

Zusammenfassung: Go vs. JavaScript/TypeScript

Ressourcen

• Go Tour — interaktives Tutorial
• Go by Example — Snippets für jedes Konzept
• Effective Go — Idiomatisches Go
• Bubbletea Docs — TUI Framework
• Charm Examples — TUI Beispiele