Accéder à la documentation
Docs

Un Node est utile seul. Un graphe transforme le travail en système.

Kavor ne vous demande pas d'abandonner votre coding agent préféré, de masquer le terminal ni de transformer chaque décision en une nouvelle conversation. Il réunit participants, outils et contexte sur un même Canvas afin que vous puissiez voir qui travaille, avec quoi et dans quelles limites.

Chaque élément de premier plan sur ce Canvas est un Node. Un CodingAgent est un Node. Une Specification aussi. Sticky Note, Terminal, File et Trigger occupent le même espace parce qu'ils peuvent tous prendre part au travail, chacun avec une responsabilité différente.

Seul, un Node est déjà utile. Lorsque vous créez une Connection, cette utilité devient une capacité explicite. Lorsque plusieurs Connections forment un graphe, le contexte, l'exécution, la mémoire et la collaboration ne sont plus dispersés entre des fenêtres et des sessions isolées.

Voici le modèle :

Node → Connection → graphe → décision humaine

Cette séquence décrit la manière dont le travail acquiert une structure. Les Connections ne sont ni des flèches persistées ni une automatisation qui exécute la case suivante. Ce sont des relations visibles entre des Nodes.

Un Canvas peut associer intention durable, mémoire partagée, exécution, fichiers et cause planifiée sans masquer les participants ni leurs Connections.

Ce qu'une Connection change réellement

Une Connection répond à une question pratique : que peuvent faire ces deux Nodes ensemble ?

Selon la combinaison, elle peut permettre à un CodingAgent de travailler avec une Specification, d'écrire dans une Sticky Note, d'opérer un Terminal, de considérer un File comme une partie explicite du périmètre ou de dialoguer avec un autre CodingAgent. Elle peut aussi fournir à un Terminal le chemin canonique d'un File, ou réveiller à une heure définie un CodingAgent dont la session est active.

Dans le même temps, la Connection établit une limite :

  • des Nodes proches sur le Canvas n'obtiennent aucun accès l'un à l'autre ;
  • mentionner un Node dans un message n'accorde aucune capacité ;
  • toutes les combinaisons de Nodes ne sont pas prises en charge ;
  • un Guardrail peut restreindre une capacité accordée par la Connection ;
  • le graphe rend le contexte accessible, mais n'approuve pas automatiquement les actions.

Le résultat est moins magique et plus utile : vous pouvez inspecter la structure avant, pendant et après le travail.

Les six Nodes

CodingAgent : votre harness préféré comme participant du graphe

Un CodingAgent est le provider natif que vous utilisez déjà, exécuté dans sa propre interface de terminal. Au lieu de remplacer Claude Code, Codex ou Google Antigravity par une conversation générique, Kavor préserve l'expérience de chaque harness et l'installe sur le Canvas.

Chaque CodingAgent peut avoir un rôle clair. Le harness conserve ses options natives de provider, de modèle et de niveau d'effort lorsqu'il propose ces capacités. Vous pouvez garder un Spec Writer concentré sur les questions et les décisions, un Builder dédié à l'implémentation et un Reviewer chargé de mettre le résultat à l'épreuve.

Lorsque des CodingAgents sont connectés, ils peuvent échanger des messages asynchrones. Vous continuez à voir ces conversations dans le panneau Messages et pouvez intervenir si nécessaire. En les connectant à des Specifications, Files, Sticky Notes et Terminals, le graphe indique clairement quelles ressources participent au travail.

C'est le même harness, avec désormais un contexte et des capacités visibles.

Specification : une intention qui survit à la session

Une Specification consigne les décisions, le périmètre, les contraintes et les critères d'acceptation dans un Markdown durable. Elle peut décrire les fondations d'une architecture, une intégration, la modélisation d'un domaine, une fonctionnalité, un module ou une séquence délimitée de corrections.

Vous pouvez l'écrire manuellement ou la corédiger avec un CodingAgent. Pour les sujets difficiles, mieux vaut investir le meilleur raisonnement disponible avant l'implémentation. Réfléchir en profondeur à ce stade coûte généralement moins cher que de corriger les ambiguïtés ensuite.

Les Specifications ont un lifecycle. Draft sert à explorer et à décider. Ready indique que le contrat peut être implémenté. In progress, Blocked et Done rendent l'état du travail visible. Done n'a de sens que lorsque les critères d'acceptation sont réellement satisfaits.

Connectée à des agents aux rôles distincts, la même Specification peut guider celui qui écrit, celui qui implémente et celui qui révise, sans dépendre de la mémoire d'une seule conversation.

Sticky Note : une mémoire de travail partagée

Une Sticky Note est un post-it sur le Canvas. Vous pouvez y écrire des questions, des hypothèses, des décisions temporaires, des constats et les prochaines étapes comme dans n'importe quelle note rapide.

Connectée à un CodingAgent, elle gagne une deuxième paire de mains. L'agent peut tenir la note avec vous : rassembler les décisions ouvertes pendant l'élaboration d'une Specification, signaler un point qui mérite votre attention pendant l'implémentation ou répondre à « qu'as-tu déjà fait, que fais-tu et que feras-tu ensuite ? » sans enfouir cet état dans l'historique d'une conversation.

Les Sticky Notes sont adaptées à une mémoire informelle et visible. Lorsqu'une décision devient un contrat durable pour l'implémentation et la maintenance future, elle doit être promue en Specification au lieu de rester cachée pour toujours dans une note.

Terminal : une exécution qui reste visible

Un Terminal maintient le shell dans le même Workspace visuel. Vous pouvez passer d'un terminal à l'autre, suivre un log, exécuter des vérifications ou rester connecté à une machine distante sans perdre le Canvas qui l'entoure.

Lorsqu'un CodingAgent est connecté, vous pouvez travailler ensemble dans le même Terminal. L'agent peut inspecter l'output, exécuter des commandes lorsque cela est permis, suivre une exécution corrélée et contribuer à un diagnostic. La saisie humaine reste prioritaire, et un Guardrail peut rendre la Connection accessible en lecture seule.

Files et Specifications peuvent également fournir leurs chemins au Terminal par l'intermédiaire de variables d'environnement. Un Trigger peut remettre une commande planifiée directement à une session active du shell.

Le Terminal ne masque pas l'exécution derrière une automatisation opaque. Le processus, la commande et le résultat restent visibles.

File : un fichier qui participe au Canvas

Un File est un fichier. L'intérêt consiste à rendre sa source canonique visible et explicite dans le graphe.

Connecté à un CodingAgent, il peut délimiter le fichier à lire, à réviser ou à modifier. Sur le Canvas, il peut aussi garder un texte, une image ou un PDF sous vos yeux pendant que vous organisez le reste du travail.

Connecté à un Terminal, le chemin absolu du File peut être exposé par une variable d'environnement. Vous pouvez ainsi utiliser visuellement un script, un fichier SQL, une configuration ou un autre support comme entrée d'une commande, sans recopier de chemins entre les fenêtres.

Le File ne devient pas une pièce jointe jetable. Il reste la véritable source dans le filesystem.

Trigger : une cause visible d'activité

Un Trigger planifie une action dans le temps. Il peut remettre une commande à un Terminal, comme le cron du système d'exploitation, ou envoyer un prompt clair à un CodingAgent dont la session est active.

Sa valeur augmente lorsque la cible est déjà connectée à d'autres Nodes. Un Trigger peut réveiller un agent chargé d'inspecter un File, d'exécuter des vérifications dans un Terminal, d'écrire un rapport dans une Sticky Note et de demander une révision indépendante à un autre CodingAgent.

C'est ainsi qu'une heure dans le calendrier peut donner naissance à un petit système autonome ou semi-autonome. Le Trigger lance l'activité ; le graphe apporte le contexte, les outils, la mémoire et la collaboration.

Le Trigger ne décide pas seul de ce qui mérite d'être fait, n'élargit pas les permissions, ne démarre pas une session que vous avez laissée arrêtée et ne possède qu'une seule cible directe : un CodingAgent ou un Terminal.

Lorsque les Nodes forment un graphe

La valeur du Canvas apparaît lorsque chaque Node possède une responsabilité et que les Connections expriment un besoin réel. Trois graphes illustrent cette progression.

De l'intention à la révision

Specification → Builder → Reviewer → décision humaine

La Specification conserve le contrat. Le Builder implémente. Le Reviewer compare le résultat aux critères d'acceptation. Une Sticky Note préserve les constats et les décisions de travail ; un Terminal fournit des preuves telles que les tests et les vérifications.

Les Connections n'exécutent pas automatiquement cette séquence. Elles rendent les participants et les capacités nécessaires accessibles au sein d'un même graphe.

Maintenance planifiée

Trigger → Maintainer

Le Maintainer est connecté à un File contenant les données d'entrée, à un Terminal pour exécuter les vérifications, à une Sticky Note pour consigner le rapport et à un Reviewer pour obtenir une évaluation indépendante.

Le Trigger remet le prompt à l'heure configurée lorsque Kavor est en cours d'exécution et que la session de la cible est active. Le CodingAgent travaille avec le contexte et les limites qu'il possédait déjà. À votre retour dans le Workspace, vous pouvez consulter les résultats, les messages et les preuves.

Commande opérationnelle supervisée

Trigger → Terminal

Un File contenant du SQL ou un script fournit son chemin au Terminal par une variable d'environnement. Le Trigger remet la commande planifiée à la session active. Un CodingAgent connecté au Terminal peut aider à analyser le résultat, tandis que vous gardez le processus sous les yeux.

Ce graphe automatise une cause et une exécution sans prétendre que le système connaît à lui seul le sens du succès.

Commencez par le travail, pas par le nombre de Nodes

Un Canvas plus grand n'est pas automatiquement meilleur. Commencez par la plus petite structure qui rend le résultat vérifiable :

  1. définissez ce qui doit se produire ;
  2. ajoutez une Specification lorsque des décisions, un périmètre ou des critères doivent survivre ;
  3. choisissez un CodingAgent et attribuez-lui un rôle clair ;
  4. connectez un File lorsque le périmètre concret doit être explicite ;
  5. connectez un Terminal lorsque la tâche exige une exécution ou des preuves ;
  6. utilisez une Sticky Note lorsque l'humain et l'agent doivent partager une mémoire de travail ;
  7. ajoutez un autre CodingAgent lorsqu'une révision indépendante ou un travail parallèle améliore réellement le résultat ;
  8. ajoutez un Trigger lorsque le temps constitue une cause légitime de l'activité.

L'objectif n'est pas de remplir le Canvas. Il s'agit de construire un système assez petit pour être compris et assez complet pour préserver l'intention, l'exécution, les preuves et la décision.

Pour aller plus loin

Dernière révision 7 août 2026Vérifié avec Kavor 1.3.0Partager un avis sur la documentation
Modifier cette page