Configuration

Le service de comptes appartient à OHarness Cloud. Le client ne connaît que son origine publique, ni le projet Supabase ni la clé API du projet Composio.

Emplacement	Rôle
`~/.oharness/config.json`	Préférences runtime générales : modèles, permissions, journalisation, synchronisation
`~/.oharness/cloud.json`	Adresse Cloud publique optionnelle : `{ "siteUrl": "https://oharness.ai" }`
`~/.oharness/plugins.json`	`{ "runtimePlugins": [...] }` ; `plugins` optionnel pour les bundles déclaratifs
`~/.oharness/mcp.json`	`{ "mcpServers": { ... } }` ; les modifications de connecteurs depuis le Web y sont écrites
Environnement/secrets du déploiement Cloud	Configuration Supabase et clés de service détenues par la plateforme
Magasin d'identifiants	Identifiants de connexion de l'utilisateur ; aucun des fichiers de configuration ci-dessus

OHARNESS_HOME redirige les quatre fichiers client. L'origine Cloud officielle est la valeur par défaut ; pour l'auto-hébergement ou le développement, les remplacements passent par OHARNESS_SITE_URL, puis cloud.json, puis l'origine publique fournie avec le package. HTTP n'est autorisé que pour le développement en loopback. La configuration d'un dépôt ne peut ni choisir l'origine Cloud ni charger du code de plugin runtime. Harness.create({ config, runtimePlugins }) en programmation accepte toujours des configurations fournies explicitement.

Mémoire

Les notes durables se configurent sous memory dans config.json (ou dans le oharness.config.json d'un projet) : limites, rappel par message et extraction automatique. Les notes de projet sont stockées en Markdown sous <project>/MEMORY/ ; les notes utilisateur communes à tous les projets sous ~/.oharness/memory/user/. Le consentement à la synchronisation et les index propres à la machine restent dans le répertoire utilisateur. Une configuration de projet peut régler le rappel ou désactiver l'extraction, mais seule la configuration propre à l'utilisateur peut activer l'extraction, puisqu'elle consomme son crédit de modèle. Mémoire liste tous les paramètres.

Artefacts

Une session dans un projet enregistré sauvegarde chaque artefact sous <project>/ARTIFACTS/ : la révision la plus récente sous forme de fichier simple (ARTIFACTS/blue-field.html), les révisions qu'elle a remplacées sous ARTIFACTS/.versions/<name>/v<N>.<ext>. Une session peut créer plusieurs artefacts, chacun dans son propre fichier ; le même nom venant d'une autre session reçoit un suffixe (blue-field-2.html). Modifier le fichier principal dans un éditeur change ce qu'affiche le panneau. ~/.oharness/storage/artifact/<session>.jsonl reste l'index — quelle session a créé quoi, ainsi que la version et les champs de synchronisation de chaque révision — sans le contenu. Supprimer une session retire l'index et laisse les fichiers dans le projet. Les sessions hors d'un projet enregistré, ainsi que les images matricielles, conservent leur contenu dans l'index comme avant. Le contenu enregistré en ligne avant ce changement est déplacé dans le projet à la prochaine ouverture de la session.

Synchronisation

La destination auto-hébergée et l'identifiant de session ne doivent figurer que dans le config.json de l'utilisateur :

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

L'ordre de priorité actuel est sync.url de l'utilisateur, puis OHARNESS_SYNC_URL, puis la destination officielle intégrée. La configuration d'un dépôt ne peut définir ni l'URL, ni le token, ni l'équipe, car un dépôt cloné pourrait alors rediriger les transcriptions ; elle peut seulement désactiver la synchronisation ou ajouter des exclusions. Redémarrez OHarness après avoir changé la destination. Consultez Faire tourner votre propre serveur de synchronisation pour déployer le service fourni et Protocole de synchronisation pour en implémenter un compatible.

Migration compatible

Les sections existantes de config.json ne sont lues qu'en solution de repli, tant que leur fichier séparé est absent. Un fichier séparé existant fait foi, y compris une liste de plugins vide ou une table MCP vide. L'ancien account.siteUrl est accepté ; les anciens champs Supabase ne sont plus utilisés par le client.

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

La migration préserve les préférences sans rapport et n'écrase pas les fichiers séparés existants. Elle enregistre une sauvegarde privée config.before-split.<id>.json et écrit la configuration générale en dernier. Les fichiers sont remplacés de façon atomique avec le mode 0600. Ne modifiez pas la configuration pendant la migration et ne lancez pas plusieurs processus de migration à la fois. La sauvegarde peut contenir d'anciens identifiants : gardez-la privée et supprimez-la vous-même après vérification. La migration ne modifie jamais les identifiants de connexion et n'autorise aucune application.

Transport du compte

La connexion via le navigateur utilise toujours /auth/desktop et /api/desktop/exchange de Cloud. Le rafraîchissement et le repli OTP dans le terminal passent désormais par /api/desktop/auth/refresh, /otp et /verify. Mettez à jour Cloud avant de redémarrer un client mis à jour. Un Cloud plus ancien renvoie une erreur explicite ; le client ne se rabat pas sur des appels Supabase directs.

Cloud utilise son projet d'authentification configuré, valide les entrées, limite les requêtes et la taille des réponses, et ne renvoie que les champs de session. Les tokens ne sont jamais journalisés ni inclus dans les erreurs. Les requêtes ne sont pas relancées automatiquement ; les réponses sont no-store. Les identifiants nouvellement obtenus enregistrent leur origine Cloud ; en changer impose de se reconnecter avant tout rafraîchissement. Les anciens identifiants acquièrent cette origine au premier rafraîchissement réussi auprès de l'adresse Cloud de confiance actuelle.

La limite de débit de l'endpoint Cloud s'applique par processus. Les déploiements de production doivent aussi imposer une limite de débit partagée en périphérie. Les paramètres Supabase du site web restent dans le projet Cloud ; cette migration ne nécessite aucune modification du schéma de base de données.

Le connecteur cloud hébergé conserve la clé Composio et la liste des applications autorisées dans Cloud. Son plugin runtime intégré connector-cloud affiche les cartes d'autorisation dans le chat Web et relance l'outil en attente après une liaison vérifiée. plugins.json contrôle l'activation du plugin ; il ne contient aucun identifiant de la plateforme.

← Fournisseurs et modèles Permissions →