initial

.env.example

@@ -0,0 +1,30 @@
+# .env.example — Platzhalter für lokale Tests
+# Niemals echte Secrets in das Repo einchecken.
+
+# Metabase
+METABASE_URL=
+METABASE_USER=
+METABASE_PASSWORD=
+METABASE_CARD_ID=
+METABASE_DASHBOARD_ID=
+
+# Teamup
+TEAMUP_CALENDAR_BASE=https://api.teamup.com
+TEAMUP_CALENDAR_KEY=
+TEAMUP_API_KEY=
+TEAMUP_PUBLIC_URL=
+
+# DokuWiki (API bevorzugt)
+DOKUWIKI_API_URL=
+DOKUWIKI_API_TOKEN=
+WIKI_MEETING_NAMESPACE=teammeetings
+
+# Fallback / SSH (nur falls API nicht verfügbar)
+ALLINKL_SSH_HOST=
+ALLINKL_SSH_USER=
+ALLINKL_BASE_PATH=
+
+# Sonstiges
+TZ=Europe/Berlin
+# Optional: dry-run-Flag für Skripte
+DRY_RUN=true

INTEGRATIONSPLAN.md

@@ -0,0 +1,466 @@
+# Integrationsplan: Metabase & Teamup → DokuWiki (All-Inkl)
+
+## 1. Zielbild
+
+Automatisierter Ablauf jeden **1. des Monats um 03:00 Uhr**:
+
+1. Gitea Action startet ein Shell-Skript auf *Hobbybackend1*.
+2. Skript erzeugt:
+   - einen **Metabase-PDF-Export** einer Registerkarte (Dashboard/Frage),
+   - **zwei Teamup-Kalenderübersichten** als Bilder (jeweils eine Woche, über Datum definiert).
+3. Skript überträgt PDF/Bilder per SSH/SCP auf den **All-Inkl-Server** ins DokuWiki-Dateisystem.
+4. Skript erzeugt oder aktualisiert eine **DokuWiki-Seite für das Monatsmeeting**, welche die neuen Dateien referenziert.
+
+---
+
+## Verantwortlichkeiten
+
+- Owner / Betrieb: `it@hobbyhimmel.de` (Ansprechpartner für Ausfälle, Secrets & Deploy)
+- Maintainer (Skripte / Runner): Hobbybackend1-Admin (Repository-Owner)
+- DokuWiki-Admin: Wiki-Administrator (z. B. für API-Zugriff und Namespace-Setup)
+
+Hinweis: Für dieses Hobbyprojekt genügt eine schlanke Aufgabenverteilung — Owner ist primärer Kontakt für Störungen.
+
+
+## 2. Architektur & Datenfluss
+
+- **Gitea (Repository + Actions)**
+  - Enthält:
+    - Shell-Skript(e)
+    - ggf. Hilfsskripte (z. B. Node/Puppeteer-Renderer)
+    - GitHub-/Gitea-Action Workflow
+  - **Trigger:** `schedule` → monatlich.
+
+- **Hobbybackend1 (Docker-Host)**
+  - Stack: `metabase`
+    - Container: `metabase-metabase-1`
+  - Führt das Shell-Skript aus (über Gitea Action Runner).
+  - Headless-Browser (z. B. **Puppeteer / Playwright** in Docker oder lokal installiert) rendert:
+    - Metabase-Registerkarte export siehe https://www.metabase.com/docs/latest/api
+    - Teamup-Ansichten export siehe https://apidocs.teamup.com/docs/api/
+
+- **All-Inkl-Server (DokuWiki)**
+  - Per SSH erreichbar.
+  - Skript überträgt Dateien (`scp`/`rsync`) nach `data/media/...`.
+  - Skript erzeugt/aktualisiert `data/pages/...` mit DokuWiki-Seite für das entsprechende Monatsmeeting.
+
+---
+
+## 3. Voraussetzungen
+
+### 3.1. Infrastruktur
+
+1. **Gitea**
+   - Repository für das Skript (z. B. `hobbyhimmel/teammeeting-dokuwiki`).
+   - Gitea Action Runner auf *Hobbybackend1* konfiguriert.
+
+2. **Hobbybackend1**
+   - Zugriff auf Metabase-Container `metabase-metabase-1`.
+   - Node.js + Puppeteer/Playwright **oder** ein Docker-Image, das URLs per Headless-Browser in PDF/PNG rendert.
+   - Netzwerkzugriff auf:
+     - Metabase-URL (intern, z. B. `http://metabase-metabase-1:3000` oder über Hostname).
+     - Teamup-URLs.
+
+3. **All-Inkl / DokuWiki**
+   - SSH-Zugang: User + SSH-Key (passwortlos aus Skript verwendbar).
+   - Kenntnis der DokuWiki-Verzeichnisse (typischerweise):
+     - Seiten: `.../data/pages/...`
+     - Medien: `.../data/media/...`
+   - Namespace für Meetings, z. B. `:teammeetings:folien:`.
+
+### 3.2. Gitea-Secrets
+
+In Gitea als **Repository-Secrets** hinterlegen (Bezeichnungen Beispiel):
+
+- **Metabase**
+  - `METABASE_URL` – Basis-URL (intern von Hobbybackend1 aus erreichbar).
+  - `METABASE_USER` – Benutzer für Login.
+  - `METABASE_PASSWORD` – Passwort oder API-Key (je nach Login-Strategie).
+  - Optional: `METABASE_DASHBOARD_ID` oder `METABASE_CARD_ID`.
+
+- **Teamup**
+  - `TEAMUP_BASE_URL` – Basis-URL zum Kalender (inkl. Calendar-Key).
+  - Optional: `TEAMUP_API_KEY` – falls API genutzt wird.
+
+- **DokuWiki / All-Inkl**
+  - `ALLINKL_SSH_HOST` – z. B. `sshXXX.all-inkl.com`.
+  - `ALLINKL_SSH_USER` – SSH-User.
+  - `ALLINKL_USER` – All-Inkl-User.
+  - `ALLINKL_SSH_KEY` – privater SSH-Key (optional; häufig nicht nötig, wenn die DokuWiki-API verwendet wird). Wenn verwendet: als secret file oder String in Kombination mit `ssh-agent`.
+  - `ALLINKL_BASE_PATH` – Pfad zum DokuWiki, z. B. `/www/htdocs/<ALLINKL_USER>/wiki.neu.hobbyhimmel.de/data`.
+  - `ALLINKL_MEETING_NAMESPACE` – z. B. `teammeetings/folien` (Dateipfade ohne Doppelpunkt).
+  - Optional (bei API-Nutzung): `DOKUWIKI_API_URL` und `DOKUWIKI_API_TOKEN` (empfohlen statt direktem Dateizugriff)
+
+- **Allgemein**
+  - `TZ` – Zeitzone (z. B. `Europe/Berlin`), falls im Skript nötig.
+
+Hinweis zur Secret-Handhabung:
+- Für lokale Tests nutze eine `.env`-Datei (niemals einchecken). Beispiele stehen im Repo in einer `.env.example` (nur Platzhalter).
+- In Gitea die Secrets als Repository-Secrets anlegen. Verwende `DOKUWIKI_API_TOKEN` falls die API genutzt wird; `ALLINKL_SSH_KEY` wird nur beim Fallback über SSH benötigt.
+
+---
+
+## 4. Shell-Skript-Design
+
+### 4.1. Hauptaufgaben des Skripts
+
+1. **Datum & Kontext bestimmen**
+   - Ausführungsdatum ist immer der **1. des Monats**.
+   - Skript ermittelt:
+     - `YEAR` – aktuelles Jahr.
+     - `MONTH` – aktueller Monat (ggf. auch vorheriger Monat, je nach Reporting-Logik).
+   - Generiert z. B. einen Identifier `MEETING_ID="${YEAR}-${MONTH}"`.
+
+2. **Export Metabase**
+   - Aufruf eines Hilfsskripts (z. B. `render_metabase.sh` oder Node-Skript):
+     - Parameter: Dashboard-ID / Card-ID, Dateiname, ggf. Filter (z. B. Zeitraum).
+     - Ausgabe: `metabase-report-${MEETING_ID}.???` im lokalen Arbeitsverzeichnis.
+
+3. **Export Teamup → Kalenderbilder**
+   - Definition der **zwei Wochen**, die exportiert werden sollen:
+     - Es werden immer die ersten zwei Wochen des aktuellen Monats genommen.
+
+   - Für jede Woche:
+     - URL zu Teamup generieren (inkl. `startDate`, `endDate` oder ähnlichen Parametern).
+     - Ausgabe: `teamup-week1-${MEETING_ID}.png`, `teamup-week2-${MEETING_ID}.png`.
+
+4. **Transfer zum All-Inkl-Server**
+   - Medienpfad bestimmen, z. B.:  
+     `MEDIA_DIR="${ALLINKL_BASE_PATH}/data/media/${TEAM_MEETING_NAMESPACE}"`
+   - Falls nicht existent: per `ssh` Ordner anlegen.
+   - Dateien per `scp` oder `rsync -e ssh` kopieren:
+     - `metabase-report-${MEETING_ID}.pdf`
+     - `teamup-week1-${MEETING_ID}.png`
+     - `teamup-week2-${MEETING_ID}.png`.
+
+5. **DokuWiki-Seite erzeugen/aktualisieren**
+   - Seitenpfad bestimmen, z. B.:  
+     `PAGE_FILE="${WIKI_BASE_PATH}/data/pages/${WIKI_MEETING_NAMESPACE}/${MEETING_ID}.txt"`
+   - Per `ssh` Remote-Here-Doc schreiben:
+    Empfehlung: Wenn möglich die DokuWiki-API (`DOKUWIKI_API_URL` + `DOKUWIKI_API_TOKEN`) verwenden, statt direkt auf `data/pages` zu schreiben. API-Aufrufe sind robuster gegenüber Dateirechten/Ownership auf All-Inkl.
+
+    Beispiel (API, einfaches PUT via curl an ein Plugin / XML-RPC-Endpoint - anpassen je nach Wiki-Setup):
+
+    ```bash
+    curl -sS -X POST "${DOKUWIKI_API_URL}" \
+      -H "Authorization: Bearer ${DOKUWIKI_API_TOKEN}" \
+      -F "id=${WIKI_MEETING_NAMESPACE}:${MEETING_ID}" \
+      -F "text=$(cat newpage.txt)"
+    ```
+
+    Fallback (wenn API nicht möglich): per SSH/Here-Doc wie bisher. Achte hier auf korrekte Ownership/Encoding beim Schreiben nach `data/pages`.
+
+    Platzhalter `<DATUM_A>` und `<DATUM_B>` werden im Shell-Skript vor dem Upload ersetzt.
+
+### 4.2. Schnittstellen zum Headless-Browser
+
+- Generische Hilfsfunktionen, z. B.:
+
+  ```bash
+  render_metabase_pdf() {
+      local url="$1"   # z. B. "$METABASE_URL/dashboard/${METABASE_DASHBOARD_ID}?date=${MEETING_ID}"
+      local outfile="$2"
+      node scripts/render_pdf.js "$url" "$outfile"
+  }
+
+  render_url_to_png() {
+      local url="$1"
+      local outfile="$2"
+      node scripts/render_png.js "$url" "$outfile"
+  }
+  ```
+
+- `render_pdf.js` / `render_png.js` verwenden Puppeteer/Playwright, loggen sich ggf. bei Metabase ein und erzeugen die Dateien.
+
+---
+
+## 5. Gitea Action: Workflow-Definition
+
+### 5.1. Workflow-Datei `.gitea/workflows/monthly-report.yml`
+
+```yaml
+name: Monthly Metabase & Teamup Export
+
+on:
+  schedule:
+    - cron: '0 2 1 * *'
+  workflow_dispatch:
+
+jobs:
+  export-and-upload:
+    runs-on: hobbybackend1  # Label des Act-Runners
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: '20'
+
+      - name: Install dependencies
+        run: |
+          npm ci
+
+      - name: Run export script
+        env:
+          METABASE_URL: ${{ secrets.METABASE_URL }}
+          METABASE_USER: ${{ secrets.METABASE_USER }}
+          METABASE_PASSWORD: ${{ secrets.METABASE_PASSWORD }}
+          METABASE_DASHBOARD_ID: ${{ secrets.METABASE_DASHBOARD_ID }}
+
+          TEAMUP_BASE_URL: ${{ secrets.TEAMUP_BASE_URL }}
+          TEAMUP_API_KEY: ${{ secrets.TEAMUP_API_KEY }}
+
+          WIKI_SSH_HOST: ${{ secrets.WIKI_SSH_HOST }}
+          WIKI_SSH_USER: ${{ secrets.WIKI_SSH_USER }}
+          WIKI_SSH_KEY: ${{ secrets.WIKI_SSH_KEY }}
+          WIKI_BASE_PATH: ${{ secrets.WIKI_BASE_PATH }}
+          WIKI_MEETING_NAMESPACE: ${{ secrets.WIKI_MEETING_NAMESPACE }}
+
+          TZ: Europe/Berlin
+        run: |
+          mkdir -p ~/.ssh
+          echo "$WIKI_SSH_KEY" > ~/.ssh/id_rsa
+          chmod 600 ~/.ssh/id_rsa
+          ssh-keyscan "$WIKI_SSH_HOST" >> ~/.ssh/known_hosts
+
+          ./scripts/monthly_export.sh
+```
+
+> **Hinweis zur Zeit:**
+> - Gitea/Aktions-Cron läuft typischerweise in UTC.
+> - Wenn du 03:00 Uhr **Europe/Berlin** willst, musst du den `cron`-Wert ggf. anpassen (Sommer-/Winterzeit beachten). Beispiel oben `0 2 1 * *` wäre 03:00 MEZ, aber 04:00 MESZ – hier vorher genau prüfen.
+
+---
+
+## 6. Teamup: Wochenansichten als Bild
+
+### 6.1. URL-Strategie
+
+- Teamup erlaubt üblicherweise Links mit Datumsparametern, z. B.:
+  - `?view=week&date=YYYY-MM-DD` für eine Wochenansicht.
+- Das Skript berechnet:
+  - `WEEK1_DATE` – ISO-Datum (Montag der ersten gewünschten Woche).
+  - `WEEK2_DATE` – ISO-Datum (Montag der zweiten gewünschten Woche).
+
+- Für jede Woche wird eine URL gebaut:
+
+  ```bash
+  TEAMUP_URL_WEEK1="${TEAMUP_BASE_URL}?view=week&date=${WEEK1_DATE}"
+  TEAMUP_URL_WEEK2="${TEAMUP_BASE_URL}?view=week&date=${WEEK2_DATE}"
+  ```
+
+### 6.2. Rendering
+
+- Aufruf z. B.:
+
+  ```bash
+  render_url_to_png "$TEAMUP_URL_WEEK1" "teamup-week1-${MEETING_ID}.png"
+  render_url_to_png "$TEAMUP_URL_WEEK2" "teamup-week2-${MEETING_ID}.png"
+  ```
+
+- Im Headless-Browser-Skript wird:
+  1. Seite geladen.
+  2. Auf ausreichende Ladezeit gewartet.
+  3. `page.screenshot({ path: outfile, fullPage: true })` ausgeführt.
+
+---
+
+## 7. Test- & Rollout-Plan
+
+1. **Lokaler Test des Headless-Browsers**
+   - Auf Hobbybackend1 die Node-Skripte (`render_pdf.js` / `render_png.js`) mit Test-URLs ausprobieren.
+   - verifizieren, dass Metabase-Login und Teamup-Laden funktionieren.
+
+2. **SSH/Dateipfade testen**
+   - Manuell per `ssh` und `scp` eine Test-PDF und Test-PNG ins DokuWiki `data/media` übertragen.
+   - testweise eine Seite unter `data/pages` anlegen und im Browser prüfen.
+
+3. **Shell-Skript `monthly_export.sh` lokal laufen lassen**
+   - Mit Test-Umgebungsvariablen (ohne Gitea) ausführen.
+   - Prüfen, ob alle Schritte durchlaufen und Dateien in DokuWiki korrekt landen.
+
+4. **Gitea Action mit `workflow_dispatch`**
+   - Workflow manuell starten, Log-Ausgaben prüfen.
+   - Validieren, dass der Action Runner auf Hobbybackend1 das Skript erfolgreich ausführt.
+
+5. **Schedule aktiv beobachten**
+   - Nach dem ersten echten Lauf (1. des Monats) kontrollieren:
+     - Sind PDF/Bilder generiert?
+     - Ist die neue DokuWiki-Seite da und korrekt verlinkt?
+
+6. **Feinjustierung**
+   - Falls nötig: Cron-Zeit, Dateinamen, Seitentemplate, Wochenlogik (z. B. „nächste + übernächste Woche“) anpassen.
+
+---
+
+## Akzeptanzkriterien
+
+- Metabase-PDF existiert unter `${MEDIA_DIR}/metabase-report-${MEETING_ID}.pdf` und Dateigröße > 50 KB.
+- Zwei Teamup-PNGs existieren unter `${MEDIA_DIR}` und sind in der erzeugten DokuWiki-Seite verlinkt.
+- DokuWiki-Seite `${WIKI_MEETING_NAMESPACE}:${MEETING_ID}` ist im Wiki sichtbar und referenziert die Medien.
+- Action-Log zeigt Exit-Code 0; bei Fehlern wird ein Fehler-Log-Eintrag erzeugt und an `it@hobbyhimmel.de` gemeldet (oder als Issue im Repo dokumentiert).
+
+Diese Kriterien sind bewusst minimal gehalten und reichen für den Hobbybetrieb eines Vereins aus.
+
+
+## 8. Erweiterungen (optional)
+
+- Mehrere Metabase-Registerkarten / Dashboards pro Meeting.
+- Automatische Verlinkung aus einer Übersichtsseite (z. B. `:teammeetings:start`) auf die neuen Monatsseiten.
+- Fehlerreport per Mail oder in DokuWiki-Logseite, wenn Exports fehlschlagen.
+- Optionale Parameter, um das Skript für „ad hoc Exports“ außerhalb des Monatslaufes zu nutzen (z. B. `./monthly_export.sh 2025-03`).
+
+
+---
+
+## Umsetzung: Lokaler Testplan (Metabase, Teamup, DokuWiki)
+
+Ziel: Die drei beteiligten APIs lokal auf deinem PC (Windows, `cmd.exe`) testen und verifizieren, dass:
+- ein Metabase-Export erzeugt werden kann,
+- Teamup-Daten (oder Screenshots der Wochenansicht) erzeugt werden können,
+- eine DokuWiki-Seite erstellt/aktualisiert und Medien eingebunden werden können.
+
+Hinweis: Lege lokal eine `.env`-Datei an (niemals einchecken). Nutze eine `.env.example` im Repo mit Platzhaltern.
+
+Basic-Prüfwerkzeuge (lokal installieren/prüfen):
+- `curl` (Windows 10+ meist vorhanden),
+- `jq` (hilfreich für JSON-Auswertung),
+- `node` + `npm` (falls du Puppeteer/Playwright oder Node-Renderer nutzen willst),
+- optional `wkhtmltopdf`/Headless Chrome für Rendering.
+
+1) Metabase — lokaler API-Test
+
+Zweck: Authentifizieren und einen PDF- oder JSON-Export eines Dashboards/Cards abrufen.
+
+Vorgehen:
+- Voraussetzungen: Metabase ist von deinem PC aus erreichbar (z. B. via VPN oder Port-Forwarding auf `http://localhost:3000`).
+- Env-Variablen (Beispiel in `.env`):
+  - `METABASE_URL=http://localhost:3000`
+  - `METABASE_USER=...`
+  - `METABASE_PASSWORD=...`
+  - `METABASE_CARD_ID=123` (oder `METABASE_DASHBOARD_ID`)
+
+Schritte (vereinfachtes Beispiel):
+
+1. Auth (Session-Token) anfordern — Beispiel (ersetze Platzhalter):
+
+```cmd
+curl -s -X POST "%METABASE_URL%/api/session" -H "Content-Type: application/json" -d "{\"username\": \"%METABASE_USER%\", \"password\": \"%METABASE_PASSWORD%\"}"
+```
+
+2. Export anfragen (Beispiel: PDF-Export eines Cards/Dashboards). Je nach Metabase-Version kann der Pfad variieren. Beispiel-Form (Platzhalter):
+
+```cmd
+curl -s -X POST "%METABASE_URL%/api/card/%METABASE_CARD_ID%/query/pdf" -H "Content-Type: application/json" -H "X-Metabase-Session: <SESSION_TOKEN>" --output metabase-report.pdf
+```
+
+Validierung:
+- Datei `metabase-report.pdf` existiert und ist > 50 KB.
+- Öffne die Datei lokal im PDF-Viewer und prüfe, ob Daten sichtbar sind.
+
+Troubleshooting:
+- Auth schlägt fehl → Credentials prüfen, ggf. IP-Restrictions.
+- Endpoint nicht vorhanden → Metabase-Dokumentation zur API-Version prüfen (Session-API / Export-Endpoints variieren).
+
+2) Teamup — lokaler API-Test
+
+Zweck: Kalenderdaten per API abrufen oder Wochenansicht via Headless-Browser rendern.
+
+Vorgehen:
+- Env-Variablen:
+  - `TEAMUP_CALENDAR_BASE=https://api.teamup.com`
+  - `TEAMUP_CALENDAR_KEY=dein_calendar_key` (oder `TEAMUP_PUBLIC_URL` für Web-Rendering)
+  - Optional: `TEAMUP_API_KEY=...` falls benötigt
+
+API-Request (Events im Zeitraum abrufen) — Beispiel:
+
+```cmd
+curl -s -H "Teamup-Token: %TEAMUP_API_KEY%" "%TEAMUP_CALENDAR_BASE%/v2/calendars/%TEAMUP_CALENDAR_KEY%/events?startDate=2025-11-01&endDate=2025-11-14" | jq '.'
+```
+
+Alternativ (wenn du die Web-Ansicht als Bild willst):
+- Öffne die Wochen-URL (z. B. `%TEAMUP_PUBLIC_URL%?view=week&date=YYYY-MM-DD`) mit einem Headless-Renderer (Puppeteer) und erstelle `teamup-week1.png`.
+
+Validierung:
+- API: JSON-Antwort mit Events (Array) und HTTP 200.
+- Screenshot: `teamup-week1.png` ist vorhanden und lesbar.
+
+Troubleshooting:
+- 403/401 → API-Key oder Zugriff prüfen.
+- Keine Events → Zeitraum / Kalenderkey kontrollieren.
+
+3) DokuWiki — lokaler API-Test (empfohlen: API) oder SSH-Fallback
+
+Zweck: Eine Testseite erzeugen und Medien verlinken, um Upload & Sichtbarkeit zu prüfen.
+
+Vorgehen (API-Variante, wenn `DOKUWIKI_API_URL` + `DOKUWIKI_API_TOKEN` vorhanden):
+- Env-Variablen:
+  - `DOKUWIKI_API_URL=https://wiki.example.com/lib/exe/rest.php/bin/actions` (Beispiel – passe an)
+  - `DOKUWIKI_API_TOKEN=...`
+  - `WIKI_MEETING_NAMESPACE=teammeetings`
+  - `MEETING_ID=2025-11`
+
+Beispiel (allgemeines curl-Pattern; Plugin/Endpoint anpassen):
+
+```cmd
+set /p PAGE_TEXT=< newpage.txt
+curl -s -X POST "%DOKUWIKI_API_URL%" -H "Authorization: Bearer %DOKUWIKI_API_TOKEN%" -F "id=%WIKI_MEETING_NAMESPACE%:%MEETING_ID%" -F "text=%PAGE_TEXT%"
+```
+
+Wenn keine API verfügbar ist (SSH-Fallback):
+- Upload der Medien per `scp` oder `rsync -e ssh` in `${ALLINKL_BASE_PATH}/data/media/...` und Schreiben der Seite per SSH-Here-Doc (wie im Plan beschrieben).
+
+Validierung:
+- Nach API-Request: die Seite im Browser öffnen (z. B. `https://wiki.example.com/doku.php?do=show&id=%WIKI_MEETING_NAMESPACE%:%MEETING_ID%`) → HTTP 200 und sichtbarer Inhalt.
+- Medien sind im Wiki sichtbar und korrekt verlinkt.
+
+Troubleshooting:
+- API 401/403 → Token prüfen / Plugin aktivieren.
+- SSH-Fallback: Dateirechte und Ownership prüfen (All-Inkl kann hier beschränken).
+
+4) `.env.example` — minimale Variablen (Beispiel zum Anlegen)
+
+```
+# Metabase
+METABASE_URL=
+METABASE_USER=
+METABASE_PASSWORD=
+METABASE_CARD_ID=
+
+# Teamup
+TEAMUP_CALENDAR_BASE=
+TEAMUP_CALENDAR_KEY=
+TEAMUP_API_KEY=
+
+# DokuWiki (API bevorzugt)
+DOKUWIKI_API_URL=
+DOKUWIKI_API_TOKEN=
+WIKI_MEETING_NAMESPACE=teammeetings
+
+# Fallback/SSH (nur falls nötig)
+ALLINKL_SSH_HOST=
+ALLINKL_SSH_USER=
+ALLINKL_BASE_PATH=
+
+# TZ
+TZ=Europe/Berlin
+```
+
+5) Ablauf für lokale Durchführung (kurz)
+
+1. `.env` aus `.env.example` anlegen und mit echten (lokal gültigen) Werten füllen.
+2. Prüfe Tools: `curl --version`, `node --version` (falls Renderer benötigt), `jq --version`.
+3. Metabase-Test ausführen (Auth → Export → Datei prüfen).
+4. Teamup-Test ausführen (API → JSON prüfen oder Screenshot erzeugen).
+5. DokuWiki-Test ausführen (API → Seite prüfen). Falls API nicht vorhanden, teste SSH-Fallback.
+6. Wenn alle drei Tests grün sind, kannst du `monthly_export.sh` lokal im Dry-Run-Mode ausführen und anschließend per Gitea-Action in den Runner überführen.
+
+6) Minimal gewünschte Ergebnisse (zum Abhaken)
+- [ ] Metabase PDF lokal erzeugt und geprüft
+- [ ] Teamup-Daten/API oder Screenshots erzeugt und geprüft
+- [ ] DokuWiki-Seite erstellt/aktualisiert und Medien referenziert
+
+Wenn du möchtest, erstelle ich als nächstes eine `.env.example`-Datei im Repo und ein sehr kleines Shell-Skript-Skeleton (`./scripts/test_apis.sh`) mit den obenstehenden curl-Beispielen (ohne Secrets). Sag kurz Bescheid, ob ich das anlegen soll.
+

_template.txt

@@ -0,0 +1,42 @@
+// Template-Hinweis:
+// Platzhalter, die vom Skript ersetzt werden können:
+// %MEETING_ID%  -> z. B. 2025-11
+// %YYYY-MM-DD%  -> Datum der Seite / Meeting-Datum
+// %LETZTER_MONAT% -> z. B. "Oktober 2025"
+// %WEEK1_DATE% / %WEEK2_DATE% -> ISO-Datum (Montag) für Teamup-Wochenansichten
+// Das Script `monthly_export.sh` ersetzt diese Platzhalter vor Upload.
+
+~~SLIDESHOW hobbyhimmel~~
+====== Team Meeting %YYYY-MM-DD% ======
+
+==== Hobbyhimmel Stuttgart ====
+
+===== Bild des Monats =====
+
+Füge hier das aktuelle Bild des Monats ein
+
+===== Agenda =====
+  * Thekendienst
+  * Nutzungen
+  * Was war im %LETZTER_MONAT%
+  * geplante Aktionen
+  * zu klären
+  * ...
+
+
+===== Thekendienst diese Woche =====
+{{url>%TEAMUP_PUBLIC_URL%?view=w&date=%WEEK1_DATE%}}
+
+===== Thekendienst nächste Woche =====
+{{url>%TEAMUP_PUBLIC_URL%?view=w&date=%WEEK2_DATE%}}
+
+
+===== Nutzungen =====
+
+===== Nutzungen (Historie) =====
+
+===== Was war im %LETZTER_MONAT% =====
+
+===== geplante Aktionen =====
+
+===== zu Klären =====