Comment laisser un chat Claude proposer des changements de code GitNest que vous approuvez dans osFoundry

À la fin de ce guide, une conversation Claude connectée à osFoundry pourra lire un dépôt GitNest, chercher dans son code et y préparer des changements : une tâche, un commit de fichiers, un change set, la relance d'un check, une pull request. Rien de tout cela ne se produit quand Claude le demande. Chaque action arrive sous forme de proposition dans "Needs your approval" (en attente de votre approbation) dans osFoundry, avec les fichiers, la branche et le commit exact sur la carte, et ne s'exécute que lorsque vous cliquez sur Approve. Claude n'a aucun outil qui écrit lui-même dans le dépôt.

Qui fait quoi

Mise en place

1. Connecter le chat une fois

Si le chat Claude n'est pas encore connecté à osFoundry, cette partie suit le parcours habituel d'un connecteur personnalisé : créez une connexion sous l'icône de clé → Connected, ajoutez son adresse de serveur dans Claude comme connecteur personnalisé, puis approuvez un espace de travail. Anthropic décrit le côté Claude dans son guide des connecteurs personnalisés. La suite de ce guide suppose que la connexion affiche "Connected."

2. Placer le dépôt dans un projet

Une connexion ne voit jamais un dépôt GitNest d'elle-même. Le dépôt doit appartenir à un projet dont fait partie la connexion.

Ouvrez le dépôt dans GitNest et repérez la section Project. Son texte indique "Connected agents in this project can use approved GitNest read tools when their connection owner still has repository access." Seul le propriétaire du dépôt dispose du sélecteur ; les autres voient le nom du projet en texte simple. Choisissez le projet. osFoundry confirme avec "Repository project updated."

3. Ajouter la connexion à ce projet

De retour dans icône de clé → Connected, sélectionnez la connexion et, sous Projects, ajoutez-la au même projet. Les dépôts GitNest du projet suivent, avec ses notes, ses bases de connaissances et le reste du contenu synchronisé.

Ouvrez Tools. "All supported tools are on by default", et la liste affiche chaque outil avec des espaces à la place des underscores. Ceux de GitNest sont :

read gitnest repository        propose gitnest work
search gitnest code            propose gitnest change set
list gitnest work              propose gitnest server composition
read gitnest work              propose gitnest file import
list gitnest saved results     propose gitnest check rerun
list gitnest checks            propose gitnest native publication
                               propose gitnest provider publication

Exemple : La liste Tools d'une connexion Claude, tous activés par défaut

Si vous voulez que Claude s'arrête aux commits et ne prépare jamais de pull request, décochez les deux outils de publication et cliquez sur Save tools. Les propositions ont de toute façon besoin de votre approbation. Décocher signifie seulement que Claude ne peut même pas le demander.

4. Demander dans le chat

Dans la conversation Claude, activez le connecteur osFoundry depuis le menu + → Connectors et formulez votre demande en langage courant. Si vous avez ajouté le même serveur à Claude Code sous le nom osfoundry, les outils y apparaissent comme mcp__osfoundry__propose_gitnest_file_import, etc.

Une exécution réelle

Les noms d'outils et d'arguments ci-dessous sont ceux que le serveur d'osFoundry liste dans tools/list. Le dépôt, les prompts, les ID et les réponses sont du contenu d'exemple.

Exemple

Vous : Dans osFoundry, ajoute à demo-api un CONTRIBUTING.md qui explique comment
       lancer les tests (ils utilisent pytest dans tests/), et ouvre une tâche
       basse priorité pour le lier depuis le README.

Claude → list_granted_resources {}
       ← projet "API" · dépôt GitNest "demo-api"
Claude → read_gitnest_repository {"repository_id": "…"}
       ← dépôt natif, branche par défaut main
Claude → search_gitnest_code {"repository_id": "…", "query": "pytest", "branch": "main"}
       ← pyproject.toml: [tool.pytest.ini_options] · tests/test_limits.py: import pytest
Claude → propose_gitnest_file_import {"repository_id": "…", "branch": "main",
           "message": "Add CONTRIBUTING.md with test instructions",
           "files": [{"path": "CONTRIBUTING.md", "content": "# Contributing\n…"}],
           "idempotency_key": "…"}
       ← proposition en attente du propriétaire
Claude → propose_gitnest_work {"repository_id": "…",
           "title": "Link CONTRIBUTING.md from README", "priority": "low",
           "idempotency_key": "…"}
       ← proposition en attente du propriétaire

Claude : J'ai préparé deux propositions dans osFoundry : un commit qui ajoute
         CONTRIBUTING.md à main, et une tâche pour le lier depuis le README.
         Rien n'est encore commité. Les deux attendent votre approbation.

Dans osFoundry, l'en-tête affiche "Claude research proposes GitNest file changes", et le panneau de la connexion liste les deux sous "Needs your approval". La carte du commit indique "Commit GitNest files in demo-api", puis "Commit to branch: main", le message de commit et un "Review all proposed files (1)" replié qui se déplie sur le CONTRIBUTING.md complet. En dessous : "Expires …", Approve and create, Decline.

Exemple : Une proposition de publication GitNest sous Needs your approval

Un second prompt, sur un change set qui existe déjà :

Exemple

Vous : Le change set rate-limit est-il au vert ? Si integration a échoué, relance-le,
       et une fois qu'il passe, prépare-le en pull request.

Claude → list_gitnest_work {"repository_id": "…", "kind": "changes"}
       ← "Rate-limit fix" · version 3
Claude → list_gitnest_checks {"repository_id": "…", "change_set_id": "…"}
       ← commit composé 9c1e47a… : unit réussi · integration échoué (terminé)
Claude → propose_gitnest_check_rerun {"repository_id": "…", "change_set_id": "…",
           "check_name": "integration", "expected_change_set_version": 3,
           "expected_composition_oid": "9c1e47a…", "idempotency_key": "…"}
       ← proposition en attente du propriétaire
  … vous approuvez la relance, elle passe …
Claude → propose_gitnest_native_publication {"repository_id": "…", "change_set_id": "…",
           "expected_change_set_version": 3,
           "expected_composition_oid": "9c1e47a…", "idempotency_key": "…"}
       ← proposition en attente du propriétaire

Regardez ce que Claude doit envoyer. La relance comme la publication nomment la version du change set et le commit composé que Claude a vus. Si quelqu'un recompose le change set avant votre clic, la version ou le commit que vous approuveriez n'est plus celui de la carte, et la revérification d'osFoundry au moment de l'approbation refuse de l'exécuter.

Ce que chaque carte vous demande d'approuver

Les cartes qui concernent un change set portent "Change set: … · expected version N", "Reviewed commit: …" et un lien "Review change set before approving" qui l'ouvre dans GitNest. Les deux cartes de publication ajoutent chacune une ligne sur ce qui va se passer, par exemple "Approval creates a publication branch and opens a pull request in this native repository."

Où passe la limite

La connexion de Claude ne peut pas écrire dans GitNest. Les routes d'écriture de GitNest refusent les accès à portée agent (denyAgentScope dans les routes GitNest d'osFoundry), et les outils Connected ne les appellent pas. Un chat Claude peut seulement déposer une proposition, et c'est osFoundry qui exécute l'action après votre approbation, enregistrée avec la connexion comme source. Il n'existe ainsi qu'un seul chemin pour toute écriture d'un agent, et vous pouvez l'auditer.

L'approbation est revérifiée au moment du clic. osFoundry contrôle à nouveau que la connexion est toujours active, que le dépôt est toujours dans un projet auquel appartient la connexion, que vous détenez toujours le rôle sur le dépôt et que la proposition n'a pas expiré. Pour une composition, une relance ou une publication, il vérifie aussi la version du change set et le commit, et pour une publication, la politique de risque du dépôt, les checks obligatoires et la branche cible. Une proposition refusée, expirée ou périmée ne s'exécute pas. Chaque outil propose prend un idempotency_key : un appel que Claude répète après une réponse perdue ne constitue donc pas une seconde demande.

Rien n'est déployé ici. Le plus loin qu'aille une proposition, c'est une pull request : une PR GitNest native, ou une PR brouillon sur GitHub ou GitLab. Le merge, et tout ce qu'il déclenche, reste entre vos mains dans GitNest ou chez le fournisseur.

Votre token de fournisseur Git n'atteint jamais Claude. Une PR chez le fournisseur utilise le compte que vous avez lié dans osFoundry, au moment de l'approbation, et ne pousse que la branche dédiée du change set, jamais vos autres refs.

Les lectures sont bornées volontairement. search_gitnest_code renvoie des extraits de lignes plafonnés, jamais de fichiers binaires ni de fichiers entiers. Les lectures de work, d'exécutions et de résultats enregistrés omettent les liaisons locales et les identifiants. Pour modifier un fichier existant, collez son contenu actuel dans le chat afin que Claude puisse proposer la nouvelle version complète. Ajouter de nouveaux fichiers fonctionne directement à partir des extraits.

Et ensuite

Commencez par l'écriture la plus petite : demandez à Claude de proposer un seul nouveau fichier, comme un CONTRIBUTING.md, puis ouvrez la carte et dépliez "Review all proposed files" avant d'approuver. La façon dont GitNest gère lui-même le clone, le push et les tokens d'accès est décrite sur la page GitNest.