Betreiber-Konsole (Ops-App)

Die Verwaltung von Bug- und Feature-Meldungen läuft in einer eigenständigen Betreiber-App, getrennt von der Endnutzer-App. So bleiben Endnutzer- und Betreiber-Oberfläche klar auseinander.

Betreiber-Konsole mit Kennzahlen, „Zuletzt bewegt“, Live-Aktivitätsfeed und Filtern

Zugang

URL: https://ops.tagwerk.dornblut.de (lokal testbar über ?ops=1).
Abgesichert durch Cloudflare Access (Zero Trust): erst E-Mail-Login, dann der normale Tagwerk-Login. Nur Konten mit dem Betreiber-Recht (is_operator, getrennt von is_admin) sehen die Konsole.
Technisch derselbe Build wie die Haupt-App, ausgeliefert als zweiter Worker tagwerk-ops; die Betreiber-Shell wird per Hostname erkannt.

Als App installieren

Die Ops-App ist eine eigene PWA „Tagwerk Ops“ (eigenes Icon). In Chrome/Edge erscheint das Install-Symbol in der Adressleiste. Wichtig hinter Cloudflare Access: Das Manifest wird mit crossorigin="use-credentials" geladen, damit der Access-Cookie mitgeht — sonst blockt der Login-Redirect die Installierbarkeit.

Die Konsole

Übersicht mit Kennzahlen, „Zuletzt bewegt“, „Offen nach Bereich“, „Meistgewünscht“ und einem Aktivitäts-Feed (was wann passiert ist, mit Sprung ins Ticket und GitHub-Link).
Liste mit Filtern (Status, Bereich, Schweregrad) und Board (Kanban): Ziehen ändert den Status, Ablegen auf eine Karte führt als Duplikat zusammen.
Detail mit Steuerzeile (Status/Schweregrad/Priorität/Bereich/Version), Analyse-Sachstand, Architektur-/Test-Notizen, Kommentaren (intern / an Melder / aus GitHub), Änderungshistorie mit Zeitstempeln und Verknüpfungen.
Live: Konsole, Detail und „Meine Meldungen“ aktualisieren sich in Echtzeit (Supabase postgres_changes, RLS-gefiltert — Betreiber sehen alle, Melder nur Eigenes); ein Polling bleibt als Reserve.
Hilfe: eigenes Menü mit „Nach Updates suchen“ und Versionshistorie.

GitHub-Zwei-Wege-Sync

Über eine GitHub App (tagwerk-feedback-sync) sind Meldungen und GitHub-Issues verbunden:

Export (Einweg-Anlage): Aus einem Ticket ein Issue erzeugen — mit Vorschau des exakten, redigierten Textes. Keine Umgebungsdaten, Screenshots oder Namen verlassen Tagwerk.
Import / „Sync jetzt“: Issues werden als Tickets gespiegelt (Titel, Text, Art, Status, Close-Grund) — inklusive Kommentare und Metadaten (Zuständige, Meilenstein, 👍). Ein Webhook (HMAC-signaturgeprüft) übernimmt Änderungen in Echtzeit.
Kommentare beidseitig, inkl. Bearbeiten/Löschen; Betreiber-Kommentare landen als „Aus Tagwerk: …“ am Issue (schleifensicher).
Rücksync Status: Wird ein exportiertes Ticket in Tagwerk geschlossen/wieder geöffnet, folgt das GitHub-Issue automatisch.
Löschen: GitHub-Delete entfernt bzw. entkoppelt das Ticket; eine Ignore-Liste verhindert Wieder-Import.
Konfliktregel: Tagwerk führt — für bekannte, aus Tagwerk stammende Meldungen wird nie der Tagwerk-Status überschrieben.

Secrets der Edge Functions: GITHUB_APP_ID, GITHUB_APP_INSTALLATION_ID, GITHUB_APP_PRIVATE_KEY, GITHUB_REPO und (für den Import) GITHUB_WEBHOOK_SECRET.

Auto-Deploy

Die Haupt-App deployt Cloudflare über die Git-Integration. Der Ops-Worker hängt dort nicht dran und wird über den GitHub-Workflow deploy-ops.yml bei jedem Push automatisch deployt. Nötige Repo-Secrets:

CLOUDFLARE_API_TOKEN — Token mit „Edit Cloudflare Workers“ (Account-Ressource = eigenes Konto, Zone = dornblut.de).
CLOUDFLARE_ACCOUNT_ID — die Cloudflare-Account-ID.

Ohne diese Secrets überspringt der Workflow den Deploy sauber (grün), statt fehlzuschlagen. Manuell geht es weiterhin per npm run build && npx wrangler deploy --env ops.