Cómo hacer que un chat de Claude proponga cambios de código en GitNest que tú apruebas en osFoundry

Al terminar, una conversación de Claude conectada a osFoundry podrá leer un repositorio de GitNest, buscar en su código y preparar cambios: una tarea, un commit de archivos, un change set, el reintento de un check o un pull request. Nada de eso ocurre cuando Claude lo pide. Cada acción llega como propuesta en "Needs your approval" (pendiente de tu aprobación) dentro de osFoundry, con los archivos, la rama y el commit exacto en la tarjeta, y solo se ejecuta cuando haces clic en Approve. Claude no tiene ninguna herramienta que escriba directamente en el repositorio.

Quién hace qué

	Lado de Claude	Lado de osFoundry
Inicio de sesión	Tu cuenta de Claude, sin cambios	Tu cuenta de osFoundry aprobó la conexión una vez
Qué puede ver	Lo que devuelven las herramientas de lectura	Los repositorios de GitNest asignados a un proyecto en el que está la conexión
Leer código	search_gitnest_code: fragmentos de líneas acotados	Sin archivos binarios, sin volcados de archivos completos, sin credenciales ni vínculos locales
Cambiar código	Siete herramientas propose_gitnest_…	Una propuesta por llamada, esperándote
Quién aprueba	Nadie en el lado de Claude	Tú, el propietario de la conexión, mientras conserves el rol en el repositorio
Quién escribe	Nada	osFoundry ejecuta la acción aprobada, atribuida a la conexión
Tokens del proveedor	Nunca se envían	Tu cuenta vinculada de GitHub/GitLab solo se usa cuando apruebas un PR del proveedor

Configuración

1. Conecta el chat una vez

Si el chat de Claude todavía no está conectado a osFoundry, esa parte es el flujo normal de conector personalizado: crea una conexión en el icono de la llave → Connected, añade su dirección de servidor en Claude como conector personalizado y aprueba un espacio de trabajo. Anthropic explica el lado de Claude en su guía de conectores personalizados. El resto de esta guía da por hecho que la conexión dice "Connected."

2. Mete el repositorio en un proyecto

Una conexión nunca ve un repositorio de GitNest por sí sola. El repositorio tiene que pertenecer a un proyecto en el que esté la conexión.

Abre el repositorio en GitNest y busca la sección Project. Su texto dice "Connected agents in this project can use approved GitNest read tools when their connection owner still has repository access." Solo el propietario del repositorio ve el selector; los demás ven el nombre del proyecto como texto simple. Elige el proyecto. osFoundry lo confirma con "Repository project updated."

3. Añade la conexión a ese proyecto

De vuelta en el icono de la llave → Connected, selecciona la conexión y, en Projects, añádela al mismo proyecto. Los repositorios de GitNest del proyecto vienen con ella, junto con sus notas, bases de conocimiento y el resto del contenido sincronizado.

Abre Tools. "All supported tools are on by default", y la lista muestra cada herramienta con espacios en lugar de guiones bajos. Las de GitNest son:

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

Ejemplo: La lista de Tools de una conexión de Claude, todas activadas por defecto

Si quieres que Claude se quede en los commits y nunca prepare un pull request, desmarca las dos herramientas de publicación y haz clic en Save tools. Las propuestas necesitan tu aprobación de todos modos. Desmarcarlas solo significa que Claude ni siquiera puede pedirlo.

4. Pídelo en el chat

En la conversación de Claude, activa el conector de osFoundry desde el menú + → Connectors y pide lo que quieras en lenguaje normal. Si añadiste el mismo servidor a Claude Code con el nombre osfoundry, ahí las herramientas aparecen como mcp__osfoundry__propose_gitnest_file_import y similares.

Una ejecución real

Los nombres de herramientas y de argumentos de abajo son los que lista el servidor de osFoundry en tools/list. El repositorio, los prompts, los IDs y las respuestas son contenido de ejemplo.

Ejemplo

Tú: En osFoundry, añade a demo-api un CONTRIBUTING.md que explique cómo
    ejecutar los tests (usan pytest en tests/), y abre una tarea de baja
    prioridad para enlazarlo desde el README.

Claude → list_granted_resources {}
       ← proyecto "API" · repositorio de GitNest "demo-api"
Claude → read_gitnest_repository {"repository_id": "…"}
       ← repositorio nativo, rama por defecto 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": "…"}
       ← propuesta esperando al propietario
Claude → propose_gitnest_work {"repository_id": "…",
           "title": "Link CONTRIBUTING.md from README", "priority": "low",
           "idempotency_key": "…"}
       ← propuesta esperando al propietario

Claude: He preparado dos propuestas en osFoundry: un commit que añade
        CONTRIBUTING.md a main y una tarea para enlazarlo desde el README.
        Todavía no hay nada commiteado. Las dos esperan tu aprobación.

En osFoundry, la cabecera muestra "Claude research proposes GitNest file changes", y el panel de la conexión lista ambas en "Needs your approval". La tarjeta del commit dice "Commit GitNest files in demo-api", luego "Commit to branch: main", el mensaje del commit y un "Review all proposed files (1)" plegado que se despliega con el CONTRIBUTING.md completo. Debajo: "Expires …", Approve and create y Decline.

Ejemplo: Una propuesta de publicación de GitNest en Needs your approval

Un segundo prompt, sobre un change set que ya existe:

Ejemplo

Tú: ¿El change set de rate-limit está en verde? Si integration falló,
    reinténtalo y, cuando pase, déjalo listo como pull request.

Claude → list_gitnest_work {"repository_id": "…", "kind": "changes"}
       ← "Rate-limit fix" · versión 3
Claude → list_gitnest_checks {"repository_id": "…", "change_set_id": "…"}
       ← commit compuesto 9c1e47a…: unit aprobado · integration fallido (terminado)
Claude → propose_gitnest_check_rerun {"repository_id": "…", "change_set_id": "…",
           "check_name": "integration", "expected_change_set_version": 3,
           "expected_composition_oid": "9c1e47a…", "idempotency_key": "…"}
       ← propuesta esperando al propietario
  … apruebas el reintento, pasa …
Claude → propose_gitnest_native_publication {"repository_id": "…", "change_set_id": "…",
           "expected_change_set_version": 3,
           "expected_composition_oid": "9c1e47a…", "idempotency_key": "…"}
       ← propuesta esperando al propietario

Fíjate en lo que Claude tiene que enviar. Tanto el reintento como la publicación nombran la versión del change set y el commit compuesto que Claude vio. Si alguien vuelve a componer el change set antes de que hagas clic, la versión o el commit que aprobarías ya no es el de la tarjeta, y la nueva comprobación de osFoundry en el momento de aprobar se niega a ejecutarlo.

Qué te pide aprobar cada tarjeta

Herramienta	Título de la tarjeta	Botón	Qué hace la aprobación
propose_gitnest_work	Create GitNest work	Approve and create	Crea un Todo y un work item de GitNest
propose_gitnest_change_set	Create GitNest draft change set	Approve and create	Crea un change set en borrador a partir de resultados de ejecución guardados. No se compone ni se publica nada
propose_gitnest_server_composition	Compose GitNest change set	Approve and create	Compone el change set en el servidor tras volver a comprobar su versión
propose_gitnest_file_import	Commit GitNest files	Approve and create	Hace commit de hasta 20 archivos UTF-8 (200 KB en total) en la rama de la tarjeta
propose_gitnest_check_rerun	Retry GitNest check	Approve retry	Vuelve a encolar un check terminado para esa versión y ese commit
propose_gitnest_native_publication	Publish GitNest pull request	Approve and publish	Crea una rama de publicación y abre un pull request en el repositorio nativo
propose_gitnest_provider_publication	Open a draft GitHub or GitLab pull request	Approve and publish	Hace push solo de la rama de ese change set con tu cuenta de proveedor vinculada y abre un PR en borrador

Las tarjetas que se refieren a un change set llevan "Change set: … · expected version N", "Reviewed commit: …" y un enlace "Review change set before approving" que lo abre en GitNest. Las dos tarjetas de publicación añaden una línea cada una sobre lo que va a pasar, por ejemplo "Approval creates a publication branch and opens a pull request in this native repository."

Dónde está el límite

La conexión de Claude no puede escribir en GitNest. Las rutas de escritura propias de GitNest rechazan el acceso con alcance de agente (denyAgentScope en las rutas de GitNest de osFoundry), y las herramientas de Connected no las llaman. Un chat de Claude solo puede registrar una propuesta, y es osFoundry quien ejecuta la acción después de que la apruebes, registrada con la conexión como origen. Así hay un único camino para cualquier escritura de un agente, y puedes auditarlo.

La aprobación se vuelve a comprobar en el momento del clic. osFoundry verifica de nuevo que la conexión sigue activa, que el repositorio sigue en un proyecto al que pertenece la conexión, que sigues teniendo el rol en el repositorio y que la propuesta no ha caducado. Para una composición, un reintento o una publicación también comprueba la versión del change set y el commit, y para la publicación, la política de riesgo del repositorio, los checks obligatorios y la rama de destino. Una propuesta rechazada, caducada u obsoleta no se ejecuta. Todas las herramientas propose reciben un idempotency_key, así que una llamada que Claude repite tras perder la respuesta no cuenta como una segunda petición.

Aquí no se despliega nada. Lo más lejos que llega una propuesta es un pull request: un PR nativo de GitNest o un PR en borrador en GitHub o GitLab. Hacer merge, y todo lo que un merge dispare, queda en tus manos en GitNest o en el proveedor.

Tu token del proveedor de Git nunca llega a Claude. Un PR del proveedor usa la cuenta que vinculaste en osFoundry, en el momento de aprobar, y solo hace push de la rama dedicada del change set, nunca de tus otras refs.

Las lecturas están acotadas a propósito. search_gitnest_code devuelve fragmentos de líneas limitados, nunca archivos binarios ni archivos completos. Las lecturas de work, ejecuciones y resultados guardados omiten los vínculos locales y las credenciales. Para cambiar un archivo existente, pega su contenido actual en el chat para que Claude pueda proponer la nueva versión completa. Añadir archivos nuevos funciona directamente a partir de los fragmentos.

Siguiente paso

Prueba primero la escritura más pequeña: pide a Claude que proponga un solo archivo nuevo, como un CONTRIBUTING.md, y luego abre la tarjeta y despliega "Review all proposed files" antes de aprobar. Cómo gestiona GitNest el clone, el push y los tokens de acceso está en la página de GitNest.