comvenio-cli

Das offizielle Comvenio Club-CLI. Nutzer authentifizieren sich ausschließlich über den Comvenio-OAuth-Flow im Systembrowser. Das CLI erhält dafür einen eigenen Public Client und die vom MCP getrennte Ressource https://mcp.comvenio.app/cli. Skripte, CI und Server melden sich mit einem Maschinen-Grant an (COMVENIO_CLIENT_ID, COMVENIO_CLIENT_SECRET), den ein Vereinsadmin in den Vereinseinstellungen unter „Automation“ anlegt.

Befehle: login, logout, whoami, action list|call|confirm, agent chat, finance und help. Gearbeitet wird über die Actions des Connectors; comvenio action list zeigt, was die Anmeldung freigibt. Jeder Command kennt --json und --help. Die klassischen Domänenbefehle (club, member, event, … schema) gibt es nicht mehr; ein Aufruf endet mit USAGE_ERROR und dem Verweis auf comvenio action list.

Der Agent, der dieses CLI bedient, liest AGENTS.md — dort steht die Domänensprache (Enums, Felder, Workflows) inkl. dem News- und Galerie-Workflow. Die kompakte Gesamtübersicht steht in docs/cli-reference.md.

Stack: Bun + cac + TypeScript.

Bereitstellung und Lizenz

Dieses Repository stellt den Quellcode öffentlich bereit. Das CLI wird nicht als npm-Paket veröffentlicht und ist ausschließlich für die Verwendung mit Comvenio-Diensten und einem gültigen Comvenio-Zugang bestimmt.

Die Comvenio CLI Source-Available License erlaubt Download, Installation und Verwendung für Comvenio. Sie ist keine Open-Source-Lizenz und erlaubt insbesondere keine eigenständige Weitervermarktung oder Verwendung mit anderen Diensten.

Installation

bun install
bun run build        # erzeugt die Binary "comvenio" (bzw. comvenio.exe auf Windows)

Die Binary ist eigenständig (bun build --compile) — keine Bun-Laufzeit nötig, um sie auszuführen.

Status des Remote-MCP-Servers

Die Root-Kommandos bun run build und bun run start gehören zum weiterhin einsatzfähigen CLI. Sie bauen beziehungsweise starten nicht den Remote-MCP-Server. Für Railway legt railway.json deshalb explizit diese getrennten Kommandos fest:

bun run build:mcp
bun run start:mcp

Der MCP-Prozess bindet an 0.0.0.0:$PORT; ohne Railway-Portvorgabe gilt lokal Port 8080. GET /health dient als Railway-Healthcheck. Die von Railway bereitgestellte Domain und der offizielle Healthcheck-Host healthcheck.railway.app werden automatisch in die Host-Allowlist aufgenommen.

Der Remote-MCP unter apps/mcp-server enthält den Streamable-HTTP-Kern und einen ausführbaren Produktions-Bootstrap. Der Produktionskandidat full_connector_v1 veröffentlicht 330 aus dem ausführbaren Runtime-Katalog abgeleitete Tools: zwölf minimierte Public-Reads, fünf geschützte Self-Service-Tools, den Club-Agent-Dialog, 307 freigegebene K7–K13-Fachaktionen, den zentralen Bestätigungsaufruf und zwei explizite Widget-Projektionen. Neben Verbindung, Rechten und sichtbaren Aktionen liefert cv_my_tasks_read die persönlichen Aufgaben im gewünschten Zeitraum. cv_my_task_reminder_write zeigt, setzt oder löscht eine frei gewählte Aufgaben-Erinnerung ausschließlich für den verbundenen Nutzer. Verein, Mitglied und Empfänger werden serverseitig aus OAuth, Backend-Actor und JWT-Subjekt abgeleitet; die Tools akzeptieren dafür keine Club-, Mitglieds-, Benutzer- oder Empfänger-ID. Event/Kalender, News, Mitgliederverwaltung, Buchung und die universelle Wirkungsvorschau sind die fünf beworbenen Widget-Ressourcen. Mitglieder- und Buchungsansichten leiten den Verein aus OAuth ab; kritische Schreibaktionen bleiben an den zentralen Bestätigungs- und Idempotenzflow gebunden. Der kleinere personal_productivity_v1-Umfang bleibt als expliziter Fallback erhalten, ist aber nicht der Produktions-Submission-Scope. Der maschinenlesbare Stand steht in integrations/release/release-gate-report.json.

Der Prozess startet bewusst fail-closed. /health ist nur die technische Liveness. /ready bleibt HTTP 503, solange Auth-/Role-Upstreams oder die exakt gepinnten OpenAI-/Anthropic-CIMD-Registrierungen fehlen. Geschützte Tools werden erst nach OAuth-Introspection, kurzlebigem Actor-Token, expliziter Vereinsbindung und aktuellem Self-Capability-Read sichtbar; das Fachbackend prüft RBAC weiterhin autoritativ. Der Log-Service ist kein MCP-Upstream.

Persönliche Aufgaben und das Setzen oder Löschen der eigenen Aufgaben-Erinnerung benötigen nur den minimalen OAuth-Scope task.read. task.write bleibt fachlichen Änderungen am gemeinsamen Aufgabenobjekt vorbehalten. Fehlt task.read bei einer bestehenden Verbindung, bleibt das RBAC-freigegebene Tool auffindbar und löst beim ersten Aufruf eine standardisierte insufficient_scope-Challenge für den OAuth-Step-up aus. Nach der Zustimmung setzt ChatGPT denselben Vorgang ohne manuelle Scope-Pflege fort. Ein Scope-Verlust während eines bereits begonnenen Aufrufs liefert dieselbe Challenge erneut. Der kurzlebige Backend-Actor-Token wird an den task-service weitergereicht; dessen Mitgliedschafts- und RBAC-Prüfung bleibt verbindlich. Der Automation-Service übernimmt Verein und Abteilung aus der autorisierten Aufgabe und der Notify-Service adressiert nur den aktuellen JWT-sub. Vor dem Versand werden aktuelle Reminder-Generation, Aufgabe und aktive Mitgliedschaft erneut geprüft; ersetzte, gelöschte oder widerrufene Reminder werden fail-closed verworfen.

Der kanonische Produktions-Origin liegt hinter dem bestehenden Cloudflare-Worker comvenio-api-gateway. Der gemeinsame Endpoint für ChatGPT und Claude lautet https://mcp.comvenio.app/mcp. Die Railway-Domain https://comvenio-cli-production.up.railway.app bleibt ausschließlich technischer Origin. Eingereicht wird der Connector erst, wenn der neue Commit dort ausgerollt wurde, /health HTTP 200 und /ready HTTP 200 liefern sowie OAuth-Discovery, Widerruf und Provider-Handshakes produktiv belegt sind.

This is the beginning of the README. Read the rest at the original. Read the full README ↗