Konfiguracja

Usługa kont należy do OHarness Cloud. Klient zna tylko jej publiczny origin, a nie projekt Supabase ani klucz API projektu Composio.

Lokalizacja	Odpowiedzialność
`~/.oharness/config.json`	Ogólne preferencje środowiska uruchomieniowego: modele, uprawnienia, logowanie, synchronizacja
`~/.oharness/cloud.json`	Opcjonalny publiczny adres Cloud: `{ "siteUrl": "https://oharness.ai" }`
`~/.oharness/plugins.json`	`{ "runtimePlugins": [...] }`; opcjonalnie `plugins` dla deklaratywnych pakietów
`~/.oharness/mcp.json`	`{ "mcpServers": { ... } }`; tu zapisują się zmiany konektorów z interfejsu Web
Środowisko/sekrety wdrożenia Cloud	Konfiguracja Supabase i klucze usług należące do platformy
Magazyn danych uwierzytelniających	Dane logowania użytkownika; żaden z powyższych plików konfiguracyjnych

OHARNESS_HOME przekierowuje wszystkie cztery pliki klienta. Domyślny jest oficjalny origin Cloud; nadpisania dla własnego hostingu i rozwoju korzystają kolejno z OHARNESS_SITE_URL, potem cloud.json, potem z dołączonego publicznego originu. HTTP jest dozwolone tylko przy rozwoju na loopbacku. Konfiguracja repozytorium nie może wybrać originu Cloud ani ładować kodu wtyczek uruchomieniowych. Programowe Harness.create({ config, runtimePlugins }) nadal obsługuje jawnie przekazane konfiguracje.

Pamięć

Trwałe notatki konfiguruje się w sekcji memory w config.json (lub w oharness.config.json projektu): limity, przywoływanie przy każdej wiadomości i automatyczna ekstrakcja. Notatki projektu leżą jako Markdown w <project>/MEMORY/; notatki użytkownika wspólne dla projektów — w ~/.oharness/memory/user/. Zgoda na synchronizację i lokalne indeksy maszyny zostają w katalogu użytkownika. Konfiguracja projektu może dostroić przywoływanie lub wyłączyć ekstrakcję, ale włączyć ekstrakcję może tylko własna konfiguracja użytkownika, bo zużywa ona jego środki na modele. Pamięć wymienia wszystkie ustawienia.

Artefakty

Sesja w zarejestrowanym projekcie zapisuje każdy artefakt w <project>/ARTIFACTS/: najnowszą rewizję jako zwykły plik (ARTIFACTS/blue-field.html), a rewizje, które zastąpiła, w ARTIFACTS/.versions/<name>/v<N>.<ext>. Sesja może utworzyć kilka artefaktów, każdy we własnym pliku; ta sama nazwa z innej sesji dostaje sufiks (blue-field-2.html). Edycja pliku najwyższego poziomu w edytorze zmienia to, co pokazuje panel. ~/.oharness/storage/artifact/<session>.jsonl pozostaje indeksem — która sesja co utworzyła oraz pola wersji i synchronizacji każdej rewizji — bez treści. Usunięcie sesji usuwa indeks i zostawia pliki w projekcie. Sesje poza zarejestrowanym projektem oraz obrazy rastrowe, jak dotąd, trzymają treść w indeksie. Treść zapisana wcześniej inline przenosi się do projektu przy następnym otwarciu sesji.

Synchronizacja

Docelowy serwer hostowany samodzielnie i dane uwierzytelniające sesji należą wyłącznie do config.json użytkownika:

{
  "sync": {
    "url": "https://sync.example.com",
    "token": "opaque-session-token",
    "enabled": true
  }
}

Obecna kolejność pierwszeństwa: sync.url użytkownika, potem OHARNESS_SYNC_URL, potem wbudowany oficjalny cel. Konfiguracja repozytorium nie może ustawić URL, tokenu ani zespołu, bo pozwoliłoby to sklonowanemu repozytorium przekierować transkrypcje; może jedynie wyłączyć synchronizację lub dodać wykluczenia. Po zmianie celu uruchom OHarness ponownie. Zobacz Własny serwer synchronizacji, aby wdrożyć dołączoną usługę, oraz Protokół synchronizacji, aby zaimplementować zgodną.

Zgodna migracja

Istniejące sekcje config.json są czytane tylko jako rezerwa, dopóki brakuje ich osobnego pliku. Istniejący osobny plik jest rozstrzygający, także pusta lista wtyczek czy pusta mapa MCP. Starsze account.siteUrl jest akceptowane; starszych pól Supabase klient już nie używa.

npm run config:migrate             # Preview filenames only; no secrets printed
npm run config:migrate -- --apply  # Back up, split, then clean the old sections

Migracja zachowuje niezwiązane preferencje i nie nadpisuje istniejących rozdzielonych plików. Zapisuje prywatną kopię zapasową config.before-split.<id>.json, a ogólną konfigurację zapisuje na końcu. Pliki są podmieniane atomowo z trybem 0600. Nie edytuj konfiguracji równolegle z migracją i nie uruchamiaj kilku procesów migracji. Kopia zapasowa może zawierać stare dane uwierzytelniające: trzymaj ją w prywatności i usuń ją sam po weryfikacji. Migracja nigdy nie zmienia danych logowania ani nie autoryzuje aplikacji.

Transport konta

Logowanie w przeglądarce nadal korzysta z /auth/desktop i /api/desktop/exchange w Cloud. Odświeżanie i zapasowe OTP w terminalu korzystają teraz z /api/desktop/auth/refresh, /otp i /verify. Zaktualizuj Cloud przed ponownym uruchomieniem zaktualizowanego klienta. Starsza wersja Cloud zwraca jawny błąd; klient nie wraca do bezpośrednich wywołań Supabase.

Cloud korzysta ze skonfigurowanego projektu uwierzytelniania, waliduje dane wejściowe, ogranicza liczbę zapytań i rozmiar odpowiedzi i zwraca tylko pola sesji. Tokeny nigdy nie trafiają do logów ani komunikatów o błędach. Zapytania nie są automatycznie ponawiane; odpowiedzi mają no-store. Nowo uzyskane dane uwierzytelniające zapisują swój origin Cloud; jego zmiana wymaga ponownego zalogowania przed odświeżeniem. Starsze dane uwierzytelniające uzyskują ten origin przy pierwszym udanym odświeżeniu względem bieżącego zaufanego adresu Cloud.

Limit zapytań endpointu Cloud działa na proces. Wdrożenia produkcyjne powinny dodatkowo egzekwować wspólny limit zapytań na brzegu. Ustawienia Supabase strony pozostają w projekcie Cloud; ta migracja nie wymaga zmian w schemacie bazy danych.

Hostowany konektor w chmurze trzyma klucz Composio i listę dozwolonych aplikacji w Cloud. Jego wbudowana wtyczka uruchomieniowa connector-cloud pokazuje karty autoryzacji w czacie Web i wznawia czekające narzędzie po zweryfikowanym powiązaniu. plugins.json steruje przełącznikiem wtyczki; nie zawiera żadnych danych uwierzytelniających platformy.

← Dostawcy i modele Uprawnienia →