Konfiguration
Der Kontodienst gehört zu OHarness Cloud. Der Client kennt nur dessen öffentlichen Origin, nicht das Supabase-Projekt oder den API-Schlüssel des Composio-Projekts.
| Ort | Zuständigkeit |
|---|---|
~/.oharness/config.json | Allgemeine Laufzeiteinstellungen: Modelle, Berechtigungen, Logging, Sync |
~/.oharness/cloud.json | Optionale öffentliche Cloud-Adresse: { "siteUrl": "https://oharness.ai" } |
~/.oharness/plugins.json | { "runtimePlugins": [...] }; optional plugins für deklarative Bundles |
~/.oharness/mcp.json | { "mcpServers": { ... } }; Connector-Änderungen aus der Web-Oberfläche landen hier |
| Umgebung/Secrets des Cloud-Deployments | Supabase-Konfiguration und plattformeigene Dienstschlüssel |
| Anmeldedatenspeicher | Anmeldedaten des Nutzers; in keiner der obigen Konfigurationsdateien |
OHARNESS_HOME leitet alle vier Client-Dateien um. Standard ist der offizielle Cloud-Origin; selbst gehostete oder Entwicklungs-Overrides nutzen OHARNESS_SITE_URL, dann cloud.json, dann den mitgelieferten öffentlichen Origin. HTTP ist nur für Loopback-Entwicklung erlaubt. Repository-Konfiguration kann weder den Cloud-Origin wählen noch Runtime-Plugin-Code laden. Programmatisch unterstützt Harness.create({ config, runtimePlugins }) weiterhin explizit übergebene Konfigurationen.
Memory
Dauerhafte Notizen werden unter memory in config.json (oder in der oharness.config.json eines Projekts) konfiguriert: Limits, Abruf pro Nachricht und automatische Extraktion. Projektnotizen liegen als Markdown unter <project>/MEMORY/; projektübergreifende Nutzernotizen unter ~/.oharness/memory/user/. Die Sync-Zustimmung und maschinenlokale Indizes bleiben im Nutzerverzeichnis. Eine Projektkonfiguration darf den Abruf feinjustieren oder die Extraktion abschalten, aber nur die eigene Konfiguration des Nutzers kann die Extraktion einschalten, da sie sein Modellguthaben verbraucht. Memory listet jede Einstellung auf.
Artefakte
Eine Sitzung in einem registrierten Projekt speichert jedes Artefakt unter <project>/ARTIFACTS/: die neueste Revision als einfache Datei (ARTIFACTS/blue-field.html), die von ihr ersetzten Revisionen unter ARTIFACTS/.versions/<name>/v<N>.<ext>. Eine Sitzung kann mehrere Artefakte erzeugen, jedes als eigene Datei; derselbe Name aus einer anderen Sitzung erhält ein Suffix (blue-field-2.html). Wer die oberste Datei in einem Editor bearbeitet, ändert, was das Panel anzeigt. ~/.oharness/storage/artifact/<session>.jsonl bleibt der Index – welche Sitzung was erzeugt hat, dazu Version und Sync-Felder jeder Revision – ohne den Inhalt. Das Löschen einer Sitzung entfernt den Index und lässt die Dateien im Projekt. Sitzungen außerhalb eines registrierten Projekts sowie Rasterbilder behalten ihren Inhalt wie bisher im Index. Inhalte, die zuvor inline erfasst wurden, wandern beim nächsten Öffnen der Sitzung ins Projekt.
Sync
Das selbst gehostete Ziel und die Sitzungs-Anmeldeinformation gehören ausschließlich in die config.json des Nutzers:
{
"sync": {
"url": "https://sync.example.com",
"token": "opaque-session-token",
"enabled": true
}
}
Die aktuelle Rangfolge ist sync.url des Nutzers, dann OHARNESS_SYNC_URL, dann das eingebaute offizielle Ziel. Repository-Konfiguration kann URL, Token oder Team nicht setzen, weil ein geklontes Repository sonst Verläufe umleiten könnte; sie darf Sync nur abschalten oder Ausschlüsse hinzufügen. Starten Sie OHarness nach einer Änderung des Ziels neu. Siehe Eigenen Sync-Server betreiben, um den mitgelieferten Dienst bereitzustellen, und Sync-Protokoll, um einen kompatiblen zu implementieren.
Kompatible Migration
Bestehende Abschnitte in config.json werden nur als Fallback gelesen, solange ihre separate Datei fehlt. Eine vorhandene separate Datei ist maßgeblich, auch eine leere Plugin-Liste oder eine leere MCP-Map. Das alte account.siteUrl wird akzeptiert; alte Supabase-Felder nutzt der Client nicht mehr.
npm run config:migrate # Preview filenames only; no secrets printed
npm run config:migrate -- --apply # Back up, split, then clean the old sections
Die Migration erhält nicht betroffene Einstellungen und überschreibt keine bereits aufgeteilten Dateien. Sie legt ein privates Backup config.before-split.<id>.json an und schreibt die allgemeine Konfiguration zuletzt. Dateien werden atomar mit Modus 0600 ersetzt. Bearbeiten Sie die Konfiguration nicht während der Migration, und führen Sie nicht mehrere Migrationsprozesse gleichzeitig aus. Das Backup kann alte Anmeldedaten enthalten: Halten Sie es privat und löschen Sie es nach der Prüfung selbst. Die Migration ändert nie Anmeldedaten und autorisiert keine Apps.
Konto-Transport
Die Browser-Anmeldung nutzt weiterhin Cloud /auth/desktop und /api/desktop/exchange. Refresh und der OTP-Fallback im Terminal nutzen jetzt /api/desktop/auth/refresh, /otp und /verify. Aktualisieren Sie Cloud, bevor Sie einen aktualisierten Client neu starten. Eine ältere Cloud liefert einen expliziten Fehler; der Client weicht nicht auf direkte Supabase-Aufrufe aus.
Cloud nutzt sein konfiguriertes Auth-Projekt, validiert Eingaben, begrenzt Anfragen und Antwortgrößen und gibt nur Sitzungsfelder zurück. Tokens werden nie geloggt oder in Fehler aufgenommen. Anfragen werden nicht automatisch wiederholt; Antworten sind no-store. Neu erhaltene Anmeldedaten speichern ihren Cloud-Origin; wer ihn ändert, muss sich vor dem nächsten Refresh erneut anmelden. Alte Anmeldedaten übernehmen diesen Origin beim ersten erfolgreichen Refresh gegen die aktuelle vertrauenswürdige Cloud-Adresse.
Das Ratenlimit des Cloud-Endpunkts gilt pro Prozess. Produktivumgebungen sollten zusätzlich ein gemeinsames Ratenlimit am Edge durchsetzen. Die Supabase-Einstellungen der Website bleiben im Cloud-Projekt; für diese Migration sind keine Änderungen am Datenbankschema nötig.
Der gehostete Cloud-Connector hält den Composio-Schlüssel und die App-Allowlist in Cloud. Sein eingebautes Runtime-Plugin connector-cloud zeigt im Web-Chat Autorisierungskarten an und setzt das wartende Tool nach verifizierter Verknüpfung fort. plugins.json steuert den Plugin-Schalter; es enthält keine Plattform-Anmeldedaten.