Glossaire

Entités principales

Agent : Un travailleur IA doté d’une identité, d’un rôle, de skills et d’un adaptateur. Appartient à un seul espace de travail. L’acteur principal du système.

Adaptateur : L’exécuteur qui joue un tour d’agent. Deux sont livrés : Control Center (built-in) — le harnais en processus qui parle aux fournisseurs de modèles — et Claude Code par claude -p. Cursor, Codex, Anthropic, OpenAI et les autres sont des fournisseurs sur l’adaptateur intégré, et non des CLI distinctes. Voir Gérer les adaptateurs et les modèles.

Espace de travail : Le locataire d’isolation de niveau supérieur. Regroupe les agents, les dépôts, les espaces, les tickets, la mémoire et les pipelines. L’isolation est structurelle, et non conventionnelle : chaque espace de travail a son propre fichier SQLite (<dataDir>/<workspaceId>/workspace.db), de sorte qu’une lecture entre espaces de travail ne compile pas. Chaque route de l’application est préfixée par /workspaces/:workspaceId — voir la carte des routes.

Forge : Un hébergeur de code — GitHub, GitLab ou Bitbucket Cloud. La forge est une propriété de chaque dépôt, lue dans son dépôt distant origin au moment de l’enregistrement, et elle détermine l’adaptateur d’API et l’identifiant de ce dépôt. Un espace de travail peut contenir des dépôts sur les trois ; les surfaces d’agrégation (la boîte de réception, la file des PR) se déploient sur toutes les forges représentées et fusionnent les résultats, en isolant les échecs de sorte qu’une forge injoignable ne vide jamais les autres. Les forges diffèrent par ce qu’elles prennent en charge — voir le tableau des capacités dans Connecter un hébergeur de code.

Dépôt : Un dépôt Git enregistré dans un seul espace de travail. Propre à l’espace de travail — le même checkout enregistré dans deux espaces de travail correspond à deux lignes indépendantes avec deux identifiants ; l’identité d’un dépôt entre les espaces de travail passe par le chemin du système de fichiers, jamais par l’identifiant. L’enregistrement exige un arbre de travail git dont le dépôt distant origin pointe vers une forge prise en charge. Chaque dépôt porte cette forge (github / gitlab / bitbucket), qui détermine l’adaptateur d’API et l’identifiant utilisés pour lui.

Dépôt isolé : Un arbre de travail propre à un espace de travail, tiré d’un dépôt enregistré. Copie sur écriture par rift partout où ce natif est livré ; git worktree sous Windows. Provisionné par espace — chaque conversation de cet espace partage un seul checkout — de sorte que les agents ne modifient jamais la copie source.

Espace : Un conteneur de collaboration propre à un espace de travail, avec des participants humains et agents, un Mode persisté, un état de provisionnement et un SpaceKind (topic / agentPeer / system / pr / slack) qui décide de son découpage en sections, de sa mise en sourdine, de son badge et de sa récupération. Il possède les arbres de travail isolés que ses conversations partagent (copie sur écriture par rift ; git worktree sous Windows).

Conversation : Un flux de messages dans un espace, avec son propre identifiant, son historique et son contexte d’exécution d’agent. Les conversations d’un espace sont des pairs à plat — il n’existe aucun flux primaire ni « principal ». Chacune s’ouvre dans un onglet d’éditeur ; l’état non lu d’un espace les agrège toutes.

Fil : Une conversation dont anchorMessageId est défini : ancrée à un message d’une conversation sœur du même espace, avec un contexte d’agent neuf amorcé par ce message d’ancrage. Un seul niveau de profondeur — un fil ne s’ancre jamais à un fil.

Ticket : L’agrégat d’unité de travail. Neutre quant au fournisseur : local par défaut, avec des adaptateurs de synchronisation pour Linear, GitHub Issues, Jira Cloud et ClickUp — même si aucune surface de l’application ne crée de connexion de synchronisation. Prend en charge la hiérarchie, les liens et la délégation. L’attribution à un agent consigne la propriété et ne lance rien ; l’attribution à une équipe est l’exception (TeamRoutingService lance le responsable).

Pipeline : Un flux de travail fondé sur un DAG qui enchaîne des étapes (lancement d’agent, scripts, conditions). Défini par des modèles ; exécuté sous forme d’exécutions.

Objets valeur

AgentRole : Rôle énuméré (CEO, coder, reviewer, QA, designer, security, devops, PM, general). Détermine la personnalité, l’accès à la mémoire et la hiérarchie.

AgentSkills : Ensemble insensible à la casse d’identifiants de skills qui injectent le contexte pertinent dans les prompts au moment du lancement.

Source de skills : Un dépôt GitHub enregistré par espace de travail comme catalogue de skills. Non fiable par construction : les métadonnées du dépôt servent uniquement à l’affichage, et chaque installation passe la barrière d’analyse à refus par défaut avant qu’un contenu n’atteigne le disque ou un prompt. Voir installer et gérer des skills.

skills-lock.json : Le manifeste par espace de travail des skills installés : pour chacun, son dépôt source, son chemin dans le dépôt, le commit auquel il est épinglé et un condensé de contenu cumulé. Les installations, les mises à jour et les désinstallations le tiennent à jour ; verify_skills le vérifie contre le disque.

Passerelle d’exécution d’agent : Un point de terminaison en boucle locale sur cc_server qui applique la politique d’action à l’intérieur du bac à sable d’un agent. Chaque push GitHub d’un agent y est redirigé, vérifié par rapport à la règle Pousser vers un dépôt distant et transmis avec un jeton d’écriture que l’agent ne détient jamais ; les commandes Bash de Claude Code sont vérifiées via un hook sur le même point de terminaison. Voir Bac à sable et sécurité.

Mode : chat, plan, review ou orchestrate. Conservé par espace, de sorte qu’un même agent peut être dans des modes différents selon l’espace ; toutes les conversations d’un espace le partagent. Contrôle le prompt système, les règles d’écriture du bac à sable et la liste d’autorisation d’outils MCP. Le compositeur n’offre que chat, plan et orchestrate ; chat porte l’étiquette « Agent ».

SandboxBackend : microvm (une VM close — le seul backend doté d’une frontière de noyau, appliqué aux terminaux interactifs), native (Seatbelt sous macOS, bubblewrap sous Linux et WSL2) ou none. Sondé une fois au démarrage ; native est appliqué au lancement d’agent lorsqu’il est disponible, en enveloppant la CLI Claude Code et l’outil bash du harnais. Windows n’a pas de backend natif et Linux a besoin de bwrap et de socat, de sorte que les exécutions y sont sans enveloppe ; --sandbox off y renonce délibérément.

Rig : Une machine jetable qu’un agent pilote en temps réel — un navigateur ou un bureau Linux clos, un émulateur Android ou un simulateur iOS géré par l’hôte, ou un terminal clos. Observée en direct par sa propre voie à pleine résolution, avec la prise de contrôle imposée côté serveur. Propre à une conversation, de sorte que l’onglet humain et les appels browser_use / computer_use / mobile_use / ios_use de l’agent s’adressent à une même machine par défaut. Voir Rigs et enceintes.

Enceinte : La frontière plus forte des rigs appuyés par une VM — une frontière de noyau, un disque en couche jetable, une barrière réseau qui refuse par défaut et un courtier d’identifiants. Les rigs Android et iOS sont jetables, mais utilisent la mise en réseau gérée par l’hôte et ne revendiquent pas cette frontière. Piloter un rig passe par la classe de garde-fou enclosureControl.

RunCost : Décompte des jetons et des coûts (jetons d’entrée, jetons de sortie, coût estimé en cents) pour une seule exécution d’agent.

WakeReason : Pourquoi un agent a été lancé. Six valeurs : message d’un utilisateur, attribution d’un ticket, relance de récupération après un échec, ticket enfant terminé, battement de relance planifié et étape de pipeline.

Ports

SandboxPort : Gère le cycle de vie du bac à sable (probe, launch, events, exec, destroy).

CredentialBrokerPort : Émet des identifiants à portée limitée pour le lancement du bac à sable — en lecture seule pour l’environnement d’un agent, en écriture uniquement pour le chemin de push côté serveur — et les révoque au démontage.

GitRepoInspectorPort : Extrait les métadonnées (propriétaire, dépôt, branche) d’un chemin de dépôt Git local.

EmbeddingPort : Produit des vecteurs d’embedding de texte à norme unitaire pour la recherche sémantique.

NotificationPort : Affiche des notifications de bureau natives en respectant le filtrage par catégorie et par route.

TicketProviderPort : Frontière indépendante du fournisseur vers un backend de billetterie (create, get, list, update, transition, assign).

PipelineEnginePort : Démarre une exécution de pipeline à partir d’un modèle, ce qui découple les appelants du moteur concret.

Services de domaine

AgentDispatchService : Lance des exécutions d’agent : provisionne les dépôts isolés, construit les prompts, crée les journaux d’exécution et renvoie les flux d’événements en direct.

TicketWorkflowService : Moteur de cycle de vie des tickets en domaine pur, avec un point de passage unique pour les mutations sous concurrence optimiste et l’application de l’isolation des espaces de travail. Le graphe de transitions qu’il impose ne lie que les agents et l’automatisation ; les changements pilotés par l’utilisateur dans l’interface passent force: true et le contournent. Il n’existe aucun répartiteur de tickets pour un agent assigné — AgentDispatchService détient le lancement, et attribuer un ticket à un agent ne démarre aucune exécution. Attribuer un ticket à une équipe est l’exception (TeamRoutingService lance le responsable).

PipelineEngine : Orchestre l’exécution : démarre les exécutions, planifie les étapes, persiste l’état, gère les routeurs, les jointures et la poursuite en cas d’échec, et reprend les exécutions en cours après un redémarrage.

PipelineTriggerDispatcher : S’abonne aux événements de domaine et démarre automatiquement les exécutions de pipeline correspondant aux déclencheurs activés.

MemoryAccessPolicy : Résout et applique les permissions de mémoire du rôle d’agent sur les domaines.

HarnessCostCalculator : Établit le prix de l’usage de jetons du harnais intégré en RunCost à partir du catalogue models.dev. Le lancement consigne ce décompte dans le journal d’exécution.

BudgetEnforcementService : Calcule les dépenses mensuelles par agent et un blocage avant lancement (checkInvocationBlock). Ce blocage n’est consulté que par les réconciliateurs de récupération (OrphanRunReaper, StrandedTicketReconciler), jamais par un lancement ordinaire d’un utilisateur ou d’un agent.

BudgetGovernanceService : Évalue les dépenses mensuelles par agent après chaque exécution — un seuil souple consigne un incident d’avertissement ; l’épuisement consigne un incident grave et bascule le cycle de vie de l’agent sur paused.

Événements

DomainEventBus : Bus de publication-abonnement diffusé en processus pour la communication entre fonctionnalités. Les événements sont typés ; les abonnés consomment des flux on<T>().

DomainEvent : Interface de base. Chaque événement porte occurredAt. Principales catégories : espace de travail et agent, PR et revue, messagerie, billetterie, pipeline, réunions et calendrier, identité, rigs, observabilité.

Réunions et calendrier

Réunion : Une séance de réunion enregistrée et transcrite localement. Capture le microphone et l’audio du système, transcrit sur l’appareil avec un modèle ASR au choix (Parakeet TDT v3 par défaut ; Parakeet TDT v2, Whisper large-v3-turbo et Whisper base.en sont des solutions de rechange), sépare les locuteurs et résume le tout en notes, tâches et décisions. Le modèle ASR choisi est installé de force au démarrage et les opérations d’enregistrement s’allument après un redémarrage. Propre à l’espace de travail ; reste sur la machine.

MeetingSegment : Une fenêtre d’audio transcrite, étiquetée par locuteur (me/them) avec une étiquette de diarisation et des décalages en millisecondes.

MeetingActionItem / MeetingDecision : Sorties structurées extraites par le pipeline de résumé et conservées sous forme de lignes distinctes. Les tâches peuvent être liées à un ticket.

CalendarEvent : Une entrée Google Calendar synchronisée, propre à un espace de travail et à un compte connecté. À distinguer d’une réunion : un événement est un engagement planifié ; une réunion est une séance enregistrée. Liée de façon biunivoque par un MeetingCalendarLink.

CalendarAccount : Un compte Google connecté, par espace de travail et par e-mail. Les jetons de rafraîchissement OAuth sont conservés côté serveur sous les clés google_* dans <dataDir>/secrets.json et n’atteignent jamais un client ; le flux d’authentification par code d’appareil se termine sur le serveur. Un indicateur authExpiredAt pilote la bannière de reconnexion.

Termes d’architecture

Clean Architecture : Règle de dépendance : Presentation → Application/Providers → Domain ← Infrastructure. Le domaine n’importe rien de l’infrastructure.

Ports et adaptateurs : Le domaine définit des interfaces abstraites (les ports) ; l’infrastructure fournit les implémentations concrètes (les adaptateurs). La racine de composition les relie.

Noyau partagé : Entités, objets valeur, ports et services de core/domain/ partagés par 3 fonctionnalités ou plus.

Feature-first : Le code est organisé par domaine métier (agents, pipelines, messagerie) plutôt que par couche technique.

Multijoueur, identité et vélocité

Principal : Une valeur scellée qui unifie les humains et les agents en une seule abstraction d’acteur — UserPrincipal(userId) ou AgentPrincipal(agentId). Chaque message, ticket, revue, plan et journal d’exécution est attribué par l’entremise d’un Principal.

Utilisateur : Une identité humaine, conservée dans global.db et donc globale à tous les espaces de travail. Le principal qui crée un espace de travail en devient le propriétaire — inscrit dans Workspace.ownerUserId avec une ligne d’appartenance de rôle propriétaire dans la même opération. Les autres se joignent par invitation ou par SSO.

WorkspaceMember / WorkspaceRole : Une ligne d’appartenance qui lie un utilisateur à un espace de travail selon un rôle (owner / admin / member / viewer / guest). C’est l’appartenance — et non une clé d’appairage — qui constitue la frontière d’accès. Les autorisations par dépôt empêchent l’appartenance de donner plus de privilèges que la forge.

ParticipantPresence : Signalement éphémère propre à un principal (état, position, curseur, frappe, état en direct de l’agent et coût en cours). Jamais persisté ; concentré par le serveur ; filtré selon l’autorisation de dépôt avant la diffusion.

Mode suivi : Cliquez sur un avatar pour suivre sa vue jusqu’à ce que vous agissiez, puis détachez-vous. Fonctionne pour les humains comme pour les agents (« regarder un agent travailler »).

Réglage d’autonomie : Un réglage par espace et par agent — propose-only / act-with-approval / act-freely — mis en œuvre comme profil nommé au-dessus du magasin de garde-fous d’actions.

ActionClass : Un ensemble fermé de 13 classes d’effet (fileDelete, gitPush, prCreate, networkEgress, processSpawn, enclosureControl, …). Chaque outil modificateur déclare ses classes ; le moteur de garde-fous résout allow / prompt / deny par portée (espace > agent > espace de travail > préréglage de mode > valeur par défaut intégrée).

WriteLedger / clé d’idempotence : Chaque mutation porte une clé d’idempotence générée par le client (UUIDv7, par action logique). Le registre propre à l’espace de travail déduplique avant l’exécution du gestionnaire ; une reprise renvoie le résultat d’origine identique au bit près. Rend la reconnexion et le multi-client sûrs par construction.

Boîte de réception « Needs me » : Une file qui traverse tous les piliers, avec une règle stricte — un élément n’apparaît que s’il bloque quelque chose (un agent, une fusion, une synchronisation) ou s’il sollicite explicitement l’opérateur.

Plan Studio : La surface de planification interactive — des plans en DAG typé et modifiables, avec coût, temps et risque par étape, et une approbation partielle.

Calcul de revue : Le calcul de revue d’une PR côté serveur (cohortes dérivées du graphe, diagrammes typés, diffs visuels, diffs de contrat d’API, verrous multi-axes) servi par review_studio.* et intégré à l’onglet Revue.

Espace de revue : L’unique espace qui soutient une PR (mode review, type pr), créé de façon idempotente et lié à la PR par une ReviewSpaceAssociation. Chaque relecteur y consigne ses remarques, et c’est ce qui les rend comparables ; son arbre de travail isolé contient la PR extraite à sa référence de tête.

Nœud de revue : L’unité structurée d’une remarque de revue par IA : type (bug, suggestion, recommendation, question, ticket), priorité P0–P3, triplet de triage catégorie/gravité/effort, ancrage de fichier et de ligne, correction suggérée facultative et score de confiance. Consigné avec add_review_node ; le verdict est calculé à partir des nœuds, et non de la prose.

Consensus-ready : L’état d’un nœud de revue atteint uniquement lorsqu’un relecteur pair confirme une remarque — un agent ne peut pas confirmer la sienne. Le bouton Publier sur GitHub de l’onglet Revue envoie chaque remarque ouverte restante (selection: all_open) ; l’outil MCP publish_review_to_github se limite toujours par défaut aux remarques confirmées par un pair.

Niveau de revue : Politique de l’espace de travail (light, balanced, thorough) qui règle quels relecteurs se déploient (seul l’agent engineer ; +qa+architect ; +security+perf) et où s’affichent les remarques sous le seuil. Ne supprime jamais une remarque.

Axe de revue : Une des cinq voies de notation par revue : correctness, security et testGap tirés des remarques des relecteurs ; visual et apiContract déterministes. Les axes verrouillés s’intègrent au verdict et ne peuvent que le rendre plus sévère — un verrou partial ou unavailable retient le verdict au lieu de le laisser passer.

Verdict de revue : ship, hold ou block. Toute remarque P0 dont la confiance est ≥ 0,7 donne block ; tout autre P0 ou tout P1 donne hold ; sinon ship. Un axe verrouillé qui échoue force block et ne peut pas être mis en minorité par les remarques.

Flotte et évaluations

cc_worker : Un binaire exécuteur de flotte sans interface, en Dart pur. S’apparie à un cc_server, déclare ses capacités d’hôte, tire les tâches louées, les exécute et renvoie les événements de processus en flux. Ne détient aucun état durable — un serveur qui fait autorité, N exécutants sans cervelle.

JobSpec : La spécification typée de tout ce qui est exécutable (exécution d’agent, étape de pipeline, index de code, rendu golden, benchmark, lot d’évaluations).

Suite d’évaluation : Une définition d’évaluation propre à un espace de travail (prompt, agent et mode cibles, grilles d’évaluation). Cinq suites de départ s’amorcent à la création d’un espace de travail ; Observabilité → Qualité les répertorie.

Déploiement et clients

Architecture de client léger : Aucun client n’ouvre la base de données ; un processus cc_server sans interface détient les données et les sert par RPC WebSocket. Chaque client (bureau, web, téléphone) est un moteur de rendu au-dessus de cette unique connexion RPC.

cc_server : Le binaire serveur sans interface (Dart pur, sans moteur Flutter). Détient la base de données Drift/SQLite, sert le repo-RPC par WebSocket et exécute les services d’arrière-plan (pipelines, MCP, réconciliateurs).

ServerConnectionMode : Comment le bureau joint son serveur — local (lancer un cc_server sur cette machine, la valeur par défaut) ou remote (en joindre un ailleurs). Le client web est toujours remote.

RemoteRpcClient : Le client JSON-RPC indépendant du transport que tout client léger utilise pour parler à son serveur — par WSS, par boucle locale ou par le relais à courtier.

Portée de l’espace de travail par appel : Le serveur est sans état — il n’existe aucune liaison d’espace de travail par session, de sorte que plusieurs clients sur un même serveur ne partagent jamais d’« espace de travail courant ». Chaque repo/call et sub/subscribe propre à un espace de travail doit porter workspace_id dans ses arguments ; un identifiant absent ou non enregistré est refusé avant qu’une base de données ne s’ouvre. L’accès est ensuite filtré par l’appartenance à l’espace de travail et par le rôle, et non par la session.

cc_remote : Le client léger pour téléphone — une PWA web Flutter qui pilote la flotte à distance par le relais à courtier, avec une politique d’outils qui refuse par défaut.

cc_signaling_server : Un courtier relais WebSocket sans état qui héberge des salles à accès sur invitation — un relais simple qui ne transmet que des trames scellées de bout en bout, ne détient aucune donnée d’application et ne voit jamais le secret d’appairage.