CRM API — Endpunkt-Referenz

Arc OS — The Orchestration System für KI-Teams

Allgemeine Informationen

Authentifizierung

Alle Endpunkte (außer /docs/*) erfordern einen JWT-Token im Header Authorization: Bearer <token>.

Für SSE- und WebSocket-Verbindungen wird der Token über den Query-Parameter ?token=<JWT> übermittelt.

Autorisierungsfehler

Endpunkte nach Kategorien

Konto und Einstellungen

Onboarding + Trial Credits (Phase 50.1)

Onboarding Checklist (Phase 54.1, Issue #56)

Post-Wizard-5-Schritt-Engagement-Checkliste. Jeder Schritt (workers, cli, skill, bot, issue) akzeptiert den Status completed oder skipped. Mutationen sind idempotent: Ein erneuter identischer POST gibt denselben State zurück, ohne einen Duplikateintrag in activity_log zu schreiben. Replay setzt den State nicht zurück, entfernt nur dismissed_at — das UI zeigt das Panel erneut mit demselben Fortschritt.

SSOT für Funnel-Metriken (Phase 54.6 / Issue #61) — Events in activity_log (event_type LIKE 'onboarding_%'). Tabelle onboarding_progress — Derived Cache: UI rendert mit einer Abfrage statt durch Event-Aggregation.

Beta Feedback (Phase 53.3)

POST /feedback — Body-Validierung: type ∈ {bug,feature,other}, title ≤200 Zeichen, description ≤5000 Zeichen. Erfolg → {ok: true, type, title}. Telegram-Ping wird formatiert als 🐞/💡/📝 New <type> feedback ... From: <user> Title: <title> + erste 400 Zeichen der Beschreibung.

Das Floating-Widget in FeedbackWidget.jsx (CRM Dashboard) überträgt automatisch browser (UA + Viewport + Locale) und project (technical_name des aktiven Projekts).

Beta Invites (Phase 52.1, nur Admin)

Auth-Flow-Update: POST /api/auth/register erfordert nun das Feld invite_code (Phase 52.1 Closed Beta). Ohne Code → 403 {error: "invite_required"}. Ungültiger/bereits verwendeter Code → 403 {error: "invalid_invite"}.

Billing (Phase 51)

Plan-Limits (OR-Semantik):

• Free: 1 Projekt UND 5 Worker
• Min ($4.99/mo): 5 Projekte ODER 25 Worker gesamt
• Max ($11.99/mo): 20 Projekte ODER 150 Worker gesamt

402-Response bei POST /onboarding/setup oder POST /projects/:name/workers, wenn das Limit überschritten wird: { error: "plan_limit_reached", reason: "projects_limit"|"workers_limit", current, limit, plan, message }

Admin-User (role=admin) umgehen die Plan-Limit-Prüfung vollständig — sie sind Operatoren, keine zahlenden Mandanten.

Beta-Tester (subscriptions.plan='beta', Phase 52 F&F) umgehen das ebenfalls — unbegrenzte Anzahl an Projekten/Worker plus alle Max-Features. Wird manuell zugewiesen: UPDATE subscriptions SET plan='beta' WHERE user_id=?.

Bugfix (Issue #25): POST /projects/create (Quick Start, Phase 50.2) schlug zuvor mit ownerChatId is not defined wegen eines Tippfehlers fehl — behoben, der Audit-Actor wird jetzt korrekt eingetragen.

Bugfix (Issue #26): allocatePort() für neue Projekte prüft jetzt echte TCP-Bindings (ss -tln) statt nur die Registry. Zuvor konnte ein Port zurückgegeben werden, der von einem Nicht-Registry-Dienst belegt war (NotebookLM Bridge :19213, interne Bridges) → Workspace-Bot schlug mit EADDRINUSE fehl.

Auth-Flow (Phase 50.1): /api/auth/register und /api/auth/login geben nun JWT auch für unverified E-Mails zurück + Flag needs_verification: true. Sensitive Aktionen (Trial Grant, Billing, Invites) prüfen email_verified separat. Rate-Limit bei Registrierung: 3 / IP / 24h.

Projekte (9 Endpunkte)

POST /projects/create — Body:

{
  "technical_name": "string",
  "displayName": "string",
  "description": "string",
  "icon": "string",
  "color": "string"
}

GET /projects/:name/logs — Query: category, lines

GET /projects/:name/metrics — Query: since, until

Worker (11 Endpunkte)

POST /projects/:name/workers — Body:

{
  "label": "string",
  "icon": "string",
  "type": "terminal | telegram",
  "model": "string",
  "max_turns": 20,
  "tools": ["Read", "Write", "Bash"],
  "system_prompt": "string",
  "focus_dirs": ["src/", "docs/"]
}

max_turns standardmäßig 20 (zuvor 5, was den Fehler "Reached max turns" bei mehrstufigen Dialogen mit Tool Calls verursachte).

POST /projects/:name/restart — Query: worker_id

Dateien und Speicher (8 Endpunkte)

GET /projects/:name/files — Query: path

GET /projects/:name/files/read — Query: path, raw

Skills (18 Endpunkte)

Projekt-Skills

Globaler Marketplace

Evolution und Updates

Skill-Forks

Chat und Nachrichten

Wiki (4 Endpunkte)

Analytik (4 Endpunkte)

Marketplace und Sage (8 Endpunkte)

Speicher und Knowledge

Dokumentation (global, ohne Auth)

GET /docs/tree — Query: lang (optional)

• Sucht zunächst docs/public/<lang>/index.md, Fallback auf docs/public/index.md
• Response enthält: sections, files, served_lang, is_fallback, requested_lang

GET /docs/file — Query: path (erforderlich), lang (optional)

• Auflösungsreihenfolge: docs/public/<lang>/<path> → docs/public/<path> (EN-Fallback)
• Response enthält: path, content, size, modified, served_lang, is_fallback, requested_lang
• 403 bei Path Traversal, 404 bei fehlender Datei
• Phase 52.1.3 — lang-Parameter für ukrainische Übersetzung hinzugefügt

System

Fehlercodes

GitHub Integration (Phase 49.3)

Unterstützte Events: push, pull_request, workflow_run, issues. Benachrichtigungen werden an den Telegram-Account des Projekteigentümers weitergeleitet.

Account Security (Phase 45.4)

Sicherheit

• Multi-Tenancy: Jeder :name-Endpunkt prüft die Eigentümerschaft über chatId aus dem JWT
• Projektname-Validierung: ^[a-zA-Z0-9][a-zA-Z0-9_-]*$ (max. 64 Zeichen)
• Path-Traversal-Schutz: safePath() auf allen user-kontrollierten Pfaden
• Datei-Upload: max. 100MB, blockierte Erweiterungen (.exe, .bat, .sh)
• CORS: Origin-Whitelist über CRM_ALLOWED_ORIGINS
• SSRF-Schutz: Allowlist auf handleScoutAnalyze — nur HTTPS + erlaubte Hosts
• Interne Endpunkte: Lehnen Anfragen mit Proxy-Headern ab (X-Forwarded-For, X-Real-IP)
• At-Rest-Verschlüsselung (Phase 45): API-Keys und Chat-Nachrichten werden AES-256-GCM verschlüsselt
• Security-Header: Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff
• PII-Sanitization: E-Mails, API-Keys, JWTs werden automatisch aus JSONL-Logs geschwärzt

Phase 53.13 — Type-Safety-Baseline (2026-05-10)

Keine Verhaltensänderung der Endpunkte — nur interne Typen. tsc --noEmit blockiert jetzt Push/CI:

• ChildBot-Interface in shared/routes/_utils.ts konsolidiert (3× Duplikate zusammengeführt). bot_username, heartbeat_file, health_endpoint, status als optional markiert — bilden Runtime-State ab (DB-enriched Workspace-Einträge fehlen diese oft).
• requireAdmin() in shared/routes/system.ts gibt jetzt Response | { userId } statt { ok, ... } zurück — einfacheres Narrowing via instanceof Response. Externes Verhalten (401/403-Codes, Response-Bodies) unverändert.
• workers.ts DEFAULT_WORKERS verlor as const (für Kompatibilität mit mutablen Callsites); Body-Parsing für tools / focus_dirs jetzt strikt über Array.isArray statt ||-Fallback.

Phase 53.15 — Sentinel Sprint 1 (2026-05-10)

Verhaltensänderungen bei Auth- und Admin-Endpunkten (Sentinel Audit P0-Fixes):

• POST /api/auth/login — wenn requires2fa=true, lautet die Response jetzt {requires2fa: true, challenge_token} statt {requires2fa: true, userId}. Das Frontend muss challenge_token im nächsten Schritt übergeben.
• POST /api/auth/2fa/login — Body-Form: {challenge_token, code} statt {userId, code}. Token ist einmalig, 5-min TTL. Ohne gültigen Token gibt der Endpunkt 401 "Invalid or expired challenge — restart login" zurück. Per-userId-Rate-Limit: 5 Versuche / 15 min → 429.
• POST /api/crm/skills + PUT /api/crm/skills/:id + DELETE /api/crm/skills/:id + POST /api/crm/skill-updates/:id/approve + POST /api/crm/skill-updates/:id/reject — nur Admin. Kein Admin → 403 Forbidden — admin only. Ohne Auth → 401.
• Nginx-Rate-Limit auf /api/auth/* — 5 req/min/IP (burst=10 nodelay → 429). Dasselbe auf /api/webhooks/github (30 req/min/IP, burst=20).
• HSTS — Header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload wird nun bei jeder HTTPS-Response gesendet. HTTP-Anfragen → 301-Redirect auf HTTPS.
• X-Frame-Options: DENY statt SAMEORIGIN.

Phase 53.21 — Sentinel P2 Batch 2 (2026-05-12)

• POST /api/crm/feedback — erfordert jetzt, dass der Aufrufer Zugriff auf das angegebene body.project hat (canAccessProject-Prüfung). Nicht-Eigentümer des Projekts → 403 "Project not accessible". Leeres/fehlendes project ist weiterhin erlaubt (globales Feedback).
• POST /api/internal/trial/consume — Body-Form geändert: {project, owner_id, tokens} statt {project, tokens}. owner_id ist Pflichtfeld, wird gegen projects.owner_id in der DB verifiziert. 404 bei unbekanntem Projekt, 403 bei Owner-Mismatch. Der Aufrufer (child-bot/claude-runner.ts) propagiert ARC_TRIAL_OWNER env, das von worker-spawn.ts injiziert wird.

Phase 53.18 — tmux Secret-Leak-Fix (2026-05-11)

Keine Verhaltensänderung der Endpunkte — nur Refactoring interner Spawn-Pfade.

• POST /api/crm/onboarding/setup (über shared/routes/onboarding.ts:startWorkspaceBot) — Die Methode zum Starten des Workspace-Mode Child-Bots wurde von bash -c "export X='val'; bun run bot.ts" auf tmux -e VAR=val ... bun run bot.ts umgestellt. Token-Werte landen nicht mehr in /proc/PID/cmdline. Extern: 0 Änderungen (Response-Body, Status-Codes, Verhalten identisch).

Phase 53.16 — Sentinel Sprint 2 (2026-05-10)

Verhaltensänderungen der Endpunkte nach Hardening von 13 × P1:

• OAuth-Callback — Redirect-URL verwendet jetzt #token= Fragment statt ?token= Query (Sentinel P1-8). Das Frontend liest aus window.location.hash (mit Fallback auf ?token= für einen Deploy-Zyklus).
• /api/crm/analytics/activity + /api/crm/analytics/sidebar — Query ist jetzt nach owner_id des eingeloggten Users eingegrenzt. Nicht-Admins sehen nur ihre eigenen Projekte. Zuvor wurden die ersten 80 Zeichen jeder Assistant-Nachricht + Projektnamen + Worker-IDs aller Mandanten geleakt (Sentinel P1-4).
• PUT /api/crm/projects/:name/files/save — isProtectedPath()-Prüfung hinzugefügt. .env / CLAUDE.md / .git/* / .claude/* geben jetzt 403 "Protected path" zurück (zuvor konnten diese überschrieben werden) (Sentinel P1-3).
• POST /api/crm/projects/:name/files/mkdir + /files/create — body.name mit .., ., /, \ → 400. safePath() wird nach join() erneut ausgeführt (Sentinel P1-2).
• /ws/local-bridge — JWT chatId wird beim Upgrade gespeichert. Init-Nachricht mit project_name, das nicht dem User gehört → close 1008 Forbidden — project not accessible. Zuvor konnte jeder User eine Bridge auf ein fremdes Projekt initiieren (Sentinel P1-5).
• CSP — Frontend-HTML (über docker/nginx.conf) sendet jetzt striktes CSP: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https:; font-src 'self' data:; connect-src 'self' https://arc-os.co wss://arc-os.co; frame-ancestors 'none'; base-uri 'self'; form-action 'self'. API-JSON-CSP verlor 'unsafe-inline' (Sentinel P1-10).
• extractChatId interner Helper — verifiziert jetzt die Token-Signatur vor dem Dekodieren (Sentinel P1-6, Defense-in-Depth für zukünftige skipAuth-Routen).
• Recovery Key verschlüsseltes Format — neue Keys werden als v2:<base64-salt>:<payload> gespeichert (per-Key 16-Byte zufälliger Salt). Alte Keys (ohne v2:-Präfix) funktionieren über Legacy-Fallback (Sentinel P1-13).
• CEO_CHAT_ID — jetzt Env-First (mit Warning-Fallback auf bot_registry). Hardcodierter Wert 474903718 aus 6 Dateien entfernt (Sentinel P1-14).
• Nginx X-Forwarded-For — Überschreiben statt Anhängen in allen 17 Callsites (Sentinel P1-11). clientIp-Helper liest das LETZTE XFF-Segment (Sentinel P1-7).

Phase 55 — Cosmic Editorial Login (2026-05-13)

Neue Endpunkte für Magic-Link-Sign-in:

• POST /api/auth/magic-link/request — Body { email }. Generiert einen 10-min Single-Use-Token in ephemeral_tokens (Typ magic_link), sendet Link https://<host>/?magic_token=<token> über den E-Mail-Anbieter. Anti-Enumeration: immer 200 OK mit Body { ok: true, message: "If the account exists, a magic link has been sent" } (auch wenn die E-Mail nicht existiert). Rate-Limit: 3/min pro (IP+E-Mail) + 5/10min pro E-Mail — derselbe Vertrag wie forgot-password. Fehlerpfad wird mit Timing-Pad versehen.
• POST /api/auth/magic-link/verify — Body { token }. Verbraucht Single-Use-Token, gibt bei Erfolg { ok: true, token: <jwt>, userId } zurück oder 401 "Invalid or expired magic link". Side Effect: user.email_verified = true + last_login wird aktualisiert (Inbox-Proof = Verifikation).

EphemeralTokenType-Union erweitert: enthält nun "magic_link" neben den bestehenden Typen oauth_state / password_reset / email_verification / tfa_challenge.

Das Frontend (CosmicCard.jsx) verarbeitet den magic-State (60-s-Resend-Countdown) und den ?magic_token=-URL-Parameter (Auto-Consume → Login → Erfolgsanimation).

Phase 56 — AI Interop / Project Context Export (2026-05-13)

Nur-für-Eigentümer-Export eines sanitizierten Projekt-Snapshots als .md zur Übergabe an externe KI-Systeme (Gemini / ChatGPT / Perplexity / Claude.ai).

• GET /api/crm/projects/:name/context-export — Params: include=section1,section2,... (Sections: identity / workers / architecture / issues / activity / commits / learnings; Standard = alle 7), scanOnly=true|false, activityHours=N (1-720, Standard 168), commitLimit=N (1-200, Standard 20), issueStatus=open|closed|all. Nur für Eigentümer — Admin-Rolle umgeht dies NICHT (by Design). CEO-Bypass funktioniert. Gibt zurück: { project, exportedAt, filename: "<project>-context-YYYY-MM-DD.md", scanOnly, sections, markdown, findings, stats, alertFired, preferences }. Schwärzt automatisch kritische Findings, außer preferences.auto_redact_critical = false. Nicht-scanOnly-Ausführungen schreiben in export_audit_log.
• GET /api/crm/projects/:name/exports — Audit-Liste (nur Eigentümer). Params: limit=N (1-200, Standard 50). Gibt zurück: { project, exports: [{ id, owner_id, exported_at, sections[], findings_critical/high/medium/low, bytes }] }.
• GET /api/crm/projects/:name/settings/export — Einstellungen lesen (nur Eigentümer). Gibt zurück: { project_name, always_include_emails, auto_redact_critical, notify_on_export, updated_at }.
• PATCH /api/crm/projects/:name/settings/export — Einstellungen aktualisieren (nur Eigentümer). Body akzeptiert jede Teilmenge von { always_include_emails, auto_redact_critical, notify_on_export } (Booleans). Gibt aktualisierte Einstellungen zurück.
• GET /api/crm/analytics/exports — Aggregierte Statistiken (Auth erforderlich, kein Owner-Gate — Analytics-Karte). Param: hours=N (1-720, Standard 168). Gibt zurück: { total, byProject: [{ project_name, n, last }], severitySums: { critical, high, medium, low } }.

Alert: Wenn der Eigentümer innerhalb von 24h mehr als 3 Exporte durchführt UND prefs.notify_on_export = true (Standard OFF) — geht logActivity("export_alert", ...) über die bestehende Phase-53.10-TG-Notify-Pipeline (alertFired: true im Response-Body).

Multi-Tier-Scanner (shared/secret-scanner.ts) — Tier 1 Regex (PATTERN_REGISTRY aus PII-Sanitizer), Tier 2 Shannon-Entropie ≥4,5 Bits/Zeichen auf ≥20-Zeichen-Runs, Tier 3 Kontext-Heuristiken (key=/token:/secret=/password=). Whitelist: UUID / Git SHA / SHA-256 / wiederholte Zeichen / kurzes Hex / Low-Entropy-Base58. Severity-Tiers (critical/high/medium/low). Performance: <500 ms / 1 MB.

DB-Migration 024 — Tabellen export_audit_log + export_preferences.

Phase 57 — Platform Einstellungen (Sentinel #103 Follow-up, 2026-05-15)

Super-Admin-Secret-Management über das CRM-UI statt SSH/edit-.env/paste-in-chat. Backend-MVP (Stage 1 von 4 Stages). Alle Endpunkte sind durch requireAdmin gesichert (Phase 53.15) — gibt 403 Forbidden — admin only für Nicht-Admins zurück, 401 Unauthorized ohne JWT.

• GET /api/crm/platform/settings — gibt zurück: { items: [{ name, label, description, testable, restartTargets[], set, preview, length, lastRotated, lastRotatedBy }] }. Allowlist mit 9 Keys (ANTHROPIC_API_KEY, PLATFORM_ANTHROPIC_KEY, GITHUB_CLIENT_ID/SECRET, GOOGLE_CLIENT_ID/SECRET, MASTER_BOT_TOKEN, CITADEL_BOT_TOKEN, RESEND_API_KEY). Geschwärzter Preview: prefix(12)…suffix(4) + Länge. Vollständiger Wert verlässt den Server nie.
• PUT /api/crm/platform/settings/:name — Body { value: string ≥ 8 Zeichen }. Schreibt atomar in den Vault über storeSecret(name, value) + Audit-Zeile. 400 wenn Name nicht in der Allowlist; 400 wenn value < 8 Zeichen; 500 bei Vault-Schreibfehler.
• POST /api/crm/platform/settings/:name/test — Verifiziert gegen SaaS-API. Anthropic → GET /v1/models mit x-api-key; TG → getMe; Resend → /api-keys. OAuth-Client-Secrets sind standalone nicht testbar → 501. Gibt zurück: { ok: bool, reason?: string, detail?: string }. 8-Sekunden-Timeout über AbortController.
• POST /api/crm/platform/settings/:name/restart — Bun.spawn(["nohup", "bash", "-c", "sleep 1 && tmux kill-session ... && bash start-*.sh"], { detach: true }) auf gebundene tmux-Sitzungen. Detached, damit ein Master-Restart die In-Flight-Response nicht abbricht. Gibt zurück: { ok: true, restarted: [sessions], note }.
• GET /api/crm/platform/audit?limit=50&key=ANTHROPIC_API_KEY — Aktuelle Audit-Log-Einträge, neueste zuerst (Limit auf 500 gedeckelt). Optionaler Key-Filter.

Strikte Ausschlussliste NEVER_EXPOSE: CRM_SECRET (JWT-Signing) + SECRET_ENCRYPTION_KEY (Vault-Meta-Key) — selbst eine Admin-Anfrage mit gültigem Token gibt 400 "not managed" zurück. Audit-Log append-only (kein UPDATE/DELETE-Handler), jede Aktion (inkl. fehlgeschlagene) schreibt eine Zeile mit IP + UA + E-Mail.

DB-Migration 026 — Tabelle platform_audit_log. Stage 2 (Frontend PlatformSettings.jsx) — shipped 2026-05-15 (cbc8bac): Admin-only Card-Grid + Rotate-Modal (<input type="password"> + Retype-Confirm) + Audit-Drawer; Sidebar-Eintrag gefiltert nach userRole === "admin", abgerufen von /api/auth/me.

Polish (2026-05-15, Commit 56191b0) — Platform-Einstellungen-UI-Restrukturierung. GET /api/crm/platform/settings-Response-Items erhalten 5 neue Felder: category (anthropic|oauth|telegram|email), usedIn (string[] — Dateien/Flows, die den Key verwenden), getFromUrl (wo ein frischer Wert abgerufen werden kann), effectAfterRotate, riskIfLeaked. Vom Frontend verwendet, um 4 sektionierte Card-Gruppen + kollapsierbare Hilfe-Panels pro Card mit strukturiertem Kontext zu rendern (Used in / Get from / Effect / Risk). Keine Verhaltensänderung bei den Mutator-Endpunkten (PUT/POST/restart/test).

Refactor (2026-05-16) — shared/routes/platform.ts internes Cleanup. 39 Zeilen entfernt (16 hinzugefügt), keine Änderung der öffentlichen API-Oberfläche. PUT/POST/restart/test/audit-Endpunkt-Signaturen und Responses unverändert. Hier dokumentiert, da der Doc-Coverage-Pre-Push-Gate bei jedem shared/routes/*.ts-Diff auslöst.

Rückdatierte Aktivität (#117, 2026-05-16) — POST /api/mcp/issues/:project/:id/log akzeptiert nun das optionale Feld ts (ISO-8601-String). Wird von arc retro-Rekonstruktion verwendet, damit historische Einträge mit ihren ursprünglichen Zeitstempeln landen. Zukünftig datierte Werte werden innerhalb von addActivity() stillschweigend auf jetzt gedeckelt (Schutz vor Versehen). Ungültiges ISO → 400.

Stage 3 (2026-05-15) — Hot-Reload von OAuth- und Resend-Secrets ohne Neustart. shared/auth.ts loadOAuthConfig() liest jetzt getSecret("GITHUB_CLIENT_ID/SECRET" | "GOOGLE_CLIENT_ID/SECRET") pro Aufruf statt process.env. Callsites in master-bot/routes/auth.ts riefen bereits getOAuthConfig() pro Request auf → 0 Callsite-Änderungen. RESEND_API_KEY ist bereits Hot-Reload über shared/email.ts:47. Verhaltensänderung: PUT /api/crm/platform/settings/{GITHUB_CLIENT_ID|GITHUB_CLIENT_SECRET|GOOGLE_CLIENT_ID|GOOGLE_CLIENT_SECRET|RESEND_API_KEY} tritt jetzt mit dem nächsten Request in Kraft, erfordert keinen Neustart. restartTargets für diese 5 Keys ist leer → Restart-Schaltfläche im UI ausgeblendet. Edge Case: Ein OAuth-Flow mit einem vor der Rotation ausgestellten State-Token kann beim Code-Exchange beim Callback eine 400 erhalten — User-Retry löst das. ANTHROPIC_API_KEY, PLATFORM_ANTHROPIC_KEY, MASTER_BOT_TOKEN, CITADEL_BOT_TOKEN erfordern weiterhin einen Neustart (werden beim Child-Bot-Spawn / TG-Long-Poll-Init gelesen).

Phase 57.3.5 Cleanup (2026-05-16) — MANAGED_KEYS-Allowlist von 9 auf 6 reduziert. Entfernt: ANTHROPIC_API_KEY (Operatoren verwenden jetzt den einheitlichen PLATFORM_ANTHROPIC_KEY für Trial-Credits und Platform-Inferenz; .env-Fallback funktioniert weiterhin für Legacy-Code-Pfade, bis Sage/Karpathy migrieren), CITADEL_BOT_TOKEN (Per-Projekt-Bot gehört zu child:<name>:token-Vault-Einträgen, verwaltet durch den Worker-Onboarding-Flow — nicht durch Platform Einstellungen). MASTER_BOT_TOKEN umbenannt: Label → "Telegram — System Monitor Bot", Beschreibung → "Server-Health-Alerts + On-Demand-Status-Probes (nur Admin, kein Chat-Bot)". Phase 58 wird die Monitoring-Schleife hinzufügen (Push-Alerts für Worker-Crash / Disk / RAM / SSH-Brute-Force / CF-Bypass + /status, /health, /errors, /restart-Befehle). Finales Set: PLATFORM_ANTHROPIC_KEY + GITHUB×2 + GOOGLE×2 + MASTER_BOT_TOKEN + RESEND_API_KEY (refs #103).

Phase 63 — UI/UX Konsolidierung + Token-Usage-Tracking (2026-05-21, #148)

Neuer Endpunkt:

• POST /api/internal/usage/log (nur loopback) — schreibt eine Zeile in token_usage_log. Body: { project_name, owner_id, worker_id?, input_tokens, output_tokens, cache_tokens, total_tokens }. Wird von child-bot/bot.ts als fire-and-forget nach jedem Claude-Aufruf aufgerufen (callClaudeOnce + callWorker text path). Kein Auth-Header erforderlich — /api/internal/* ist nur von localhost erreichbar und wird von nginx für externe Anfragen blockiert.
• GET /api/crm/account/usage — Token-Usage-Verlauf für den autorisierten Benutzer (s. Tabelle Onboarding oben).

Änderungen in claude-runner.ts:

• callClaudeOnce + callWorker text path: jetzt immer --output-format json (vorher text für non-trial). JSON-Parse extrahiert result als Output-Text und usage für das Logging. Trial-Consume-Flow unverändert.
• Neuer logUsage? Dep in ClaudeRunnerDeps — Callback (workerId, { input, output, cache }) => void.

UI-Änderungen (kein API):

• UserDropdown: UsageCard-Komponente mit Total-Tokens + "Details →" beim Öffnen; Warning-Dot auf Avatar wenn Trial-Balance < 20%.
• BillingPage: Token-Usage-Sektion mit Totals-Bar + 50-Zeilen-Tabelle. Enterprise-Plan (in Entwicklung). details-Toggle auf jeder Karte.
• OnboardingProgressPill: Als Inline-Header-Dropdown neu gestaltet (kein Modal-Wizard mehr).
• WorkerSelector: Semantische --worker-{role} CSS-Vars statt Tailwind-Chart-Tokens.