brainclaw confidentialité

Des analytics uniquement si tu dis oui.

Le site fonctionne sans analytics. Si tu acceptes, on les utilise pour comprendre ce qui aide vraiment et ce qui bloque. Pas de pub. Pas de revente. Pas de dark patterns.

Détails de confidentialité

concepts

bclaw_work et bclaw_context — la boucle quotidienne

Les deux points d'entrée de façade que vous appelez 10 fois par jour. bclaw_work démarre une session, pose un claim sur un périmètre et renvoie le contexte en une seule fois. bclaw_context récupère des vues mémoire ciblées sans cérémonie.

La grammaire canonique (bclaw_find / get / create / update / remove / transition) est la surface CRUD universelle — mais vous ne la sollicitez pas pour chaque interaction. bclaw_work et bclaw_context sont les deux façades que vous appelez le plus souvent. Ensemble, elles couvrent le démarrage du travail, la lecture de l’état et la reprise après une pause.

bclaw_work — démarrer le travail

Un seul appel remplace trois anciens (session-start, claim-create, get-context). L’agent passe son intention et le périmètre qu’il souhaite toucher :

bclaw_work intent=execute scope="src/auth/" task="Refactor JWT verify"

Ce qui se passe en interne :

  1. Ouverture de session — session_id frappé, identité de l’agent résolue, empreinte hôte estampillée.
  2. Construction du contexte mémoire — les décisions, contraintes, traps, claims actifs, handoffs ouverts et tout plan touchant le périmètre sont filtrés + classés + tronqués pour respecter un budget de taille de prompt.
  3. Claim créé — le périmètre est réservé ; les conflits apparaissent immédiatement si un autre agent est déjà dans les mêmes fichiers.
  4. Worktree automatique — lorsque le projet est multi-agent, brainclaw crée un worktree Git isolé sous ~/.brainclaw/worktrees/<project-hash>/ afin que les modifications de cet agent n’entrent pas en conflit avec le worktree d’un autre.

La valeur de retour est compacte par défaut (drapeaux d’état, id de claim, id de session, id de plan) — passez compact: false si vous souhaitez également le dump mémoire complet.

Intentions

IntentQuand l’utiliser
executeVous travaillez. Défaut pour presque tous les appels.
consultVous voulez du contexte mais n’avez pas l’intention d’écrire — aucun claim n’est créé.
resumeVous reprenez après une pause — recherche le contexte de session/handoff précédent pour le même périmètre.
reviewVous êtes sur le point d’examiner le travail de quelqu’un d’autre — récupère le contexte de handoff + diff.

bclaw_context — vues mémoire ciblées

Une fois qu’une session est ouverte, bclaw_context récupère la tranche mémoire dont vous avez besoin sans refaire toute la cérémonie de session.

bclaw_context kind=memory path="src/auth/"     # décisions/pièges/plans pertinents pour le périmètre
bclaw_context kind=board                        # claims actifs, plans, handoffs sur l'espace de travail
bclaw_context kind=delta since=sess_abc123      # ce qui a changé depuis une session précédente
bclaw_context kind=execution                    # environnement local, outils d'agent, serveurs MCP

Choisissez le type qui correspond à la question :

  • kind=memory — “Qu’est-ce que je dois savoir sur CE périmètre avant d’éditer ?” Classé, budgétisé pour le prompt, filtré par périmètre.
  • kind=board — “Quel est l’état du projet MAINTENANT ?” Claims actifs, plans en cours, handoffs ouverts sur l’espace de travail. Utile pour les orchestrateurs et à la fin de la session.
  • kind=delta — “Qu’est-ce qui a changé depuis ma dernière visite ?” Passez un session_id précédent et vous obtenez uniquement les nouvelles décisions / traps / plans / handoffs.
  • kind=execution — “Quels outils et quelles surfaces cette machine possède-t-elle ?” CLI d’agent détectés, serveurs MCP, compétences, OS, shells.

Accès inter-projets

Les deux façades acceptent un argument project optionnel qui route l’appel vers un projet lié (cross_project_links de brainclaw link list ou un enfant de chaîne de magasin d’espace de travail) :

bclaw_get      entity=trap id=trp_abc project=brainclaw-site
bclaw_context  kind=memory project=brainclaw-cloud
bclaw_coordinate intent=assign targetAgents=[claude-code] project=brainclaw-site task="..."

L’identité est résolue par l’appelant ; les écritures + l’audit atterrissent dans la cible. Les noms de projets inconnus lèvent une erreur — pas de repli silencieux. Le CLI expose la même fonctionnalité que --project <name>. Voir travail de fonctionnalité parallèle pour le modèle d’orchestrateur.

Pourquoi des façades plutôt que du CRUD brut

Les six verbes canoniques sont uniformes mais verbeux pour la boucle quotidienne. Une façade comme bclaw_work fait en un seul appel ce qui serait autrement : bclaw_create entity=session → bclaw_context kind=memory → bclaw_create entity=claim → bclaw_get entity=plan id=…. Même résultat, quatre fois les allers-retours.

Utilisez les façades pour la boucle quotidienne. Basculez sur la grammaire canonique lorsque vous avez besoin d’une entité spécifique que les façades n’exposent pas, ou lorsque vous scriptiez une capture hors bande (une runtime_note, un candidat, une contrainte).