- Entender el patrón editar → verificar → aprobar.
- Separar permisos de escritura y permisos de verificación.
- Diseñar un MCP interno sin regalar llaves del repo.
El error típico
El agente edita código, dice “ya está” y nadie ejecuta el proyecto desde cero. Puede haber dependencias rotas, tests que no corren, variables de entorno ausentes o un build que solo funcionaba en su contexto. MCP sirve para convertir esa intuición en un proceso verificable.
# Flujo recomendado 1. Agente editor: - crea rama - aplica cambios - abre PR con resumen y riesgos 2. Agente/verificador: - clona el repo en carpeta limpia - instala dependencias - ejecuta lint, tests y build - adjunta logs al PR 3. Humano o policy: - aprueba solo si la verificación pasa
Diseño de permisos
- GitHub MCP: crear rama, commit y PR; nunca force-push a `main`.
- Verify MCP: clone fresco, install, lint, test, build y logs.
- Secrets: no pasar `.env` reales al verificador si no hacen falta.
- Red: limitar salidas externas si el proyecto no las necesita.
- Logs: guardar comando, exit code, versión de Node/Python y resumen.
{
"tool": "verify_repo",
"input": {
"repo": "github.com/empresa/app",
"branch": "agent/fix-login",
"commands": ["npm ci", "npm run lint", "npm test", "npm run build"],
"timeout_seconds": 900
},
"output": {
"status": "failed",
"failed_command": "npm test",
"exit_code": 1,
"log_url": "https://..."
}
}Fuentes oficiales
Si has guardado la evidencia de esta lección, continúa con «Governance MCP». Si no, repite la comprobación antes de avanzar.