Ecosistema de IA Pyrus — Infraestructura MCP

Este repositorio es el hogar de implementación y gobierno del servicio de infraestructura MCP de Pyrus y su equipo de ingeniería de IA de apoyo. También contiene la especificación arquitectónica y la hoja de ruta para el futuro Knowledge MCP, que es un servicio separado con su propio almacén de datos y ciclo de vida.

Límites del producto

AI clients / employees
        |
        +---------------------+
        |                     |
        v                     v
   Pyrus MCP             Knowledge MCP
   Pyrus actions         canonical knowledge
        |                     |
        v                     v
     Pyrus API          PostgreSQL/pgvector
        ^                     ^
        |                     |
        +------- PyrusBot ----+
             orchestration

Pyrus MCP

Un servicio externo de grado de producción que permite a empleados/anfitriones de IA autorizados realizar operaciones de Pyrus a través de MCP. Es desplegable de forma independiente y no debe depender de una estación de trabajo de desarrollador.

Knowledge MCP

Un servicio MCP separado para documentación versionada canónica, evidencia/linaje, incrustaciones semánticas, recuperación híbrida y publicación controlada a la Base de Conocimiento de Pyrus a través de Pyrus MCP.

PyrusBot

Una futura capa de orquestación/aplicación que consume ambos MCP. Puede convertirse posteriormente en un chatbot, CLI, utilidad web o adaptador de IDE sin cambiar los contratos de infraestructura.

Related MCP server: MCP Gateway

Prioridad actual

La preparación para producción de Pyrus MCP es lo primero. Knowledge MCP se especifica en paralelo pero se implementa después de que sus contratos sean aprobados. La integración de PyrusBot sigue a contratos de infraestructura estables.

Documentos normativos

• IMPLEMENTATION_PLAN.md — punto de entrada normativo de implementación.

• docs/architecture/system-architecture-v2.md — arquitectura completa del sistema.

• docs/architecture/contracts-v2.md — contratos de MCP, API de Pyrus, seguridad, webhook y Knowledge.

• docs/planning/production-roadmap-v2.md — hoja de ruta de fases y reglas de paralelización.

• tasks/registry.yaml — grafo de tareas ejecutable con propietarios, revisores, puertas y dependencias.

• contracts/pyrus-tool-catalog.yaml — catálogo de compatibilidad heredada recuperable; actualmente bloqueado hasta que se recupere la evidencia heredada.

• docs/qa/gates.md — puertas de aceptación de fusión/lanzamiento/producción.

• docs/ai-team/agent-registry.yaml — roles de ingeniería y autoridad.

Bloqueadores críticos actuales

1. El plan anterior hacía referencia a pyrus_mcp_tools_spec.json e inventory.json, pero esos artefactos no están presentes en el repositorio actual. El contrato heredado exacto debe recuperarse antes de declarar paridad 1:1.

2. El plan visible dice "61 herramientas", pero la lista agrupada actualmente visible no se reconcilia de forma independiente con ese número. El recuento y los nombres heredados exactos son, por lo tanto, una tarea de recuperación de contrato P0.

3. Un único SERVER_AUTH_TOKEN no es un modelo de autorización de producción multiusuario adecuado. El objetivo es autorización de portador compatible con MCP/OAuth, validación de audiencia, ámbitos, vinculación de inquilinos, revocación y auditoría.

4. SQLite es una opción de desarrollo local, no el sistema de registro de producción duradero.

Pila de ingeniería

Pyrus MCP

Política Python 3.11+; uv; FastMCP; Streamable HTTP; stdio para pruebas locales; Pydantic; httpx; pytest; Ruff; tipado estático; PostgreSQL; Redis opcional; Docker; GitHub Actions; gestión de secretos externa.

Knowledge MCP

Python + FastMCP; PostgreSQL + pgvector; almacenamiento de objetos para artefactos grandes/sin procesar; adaptador de proveedor de incrustaciones con registros de modelo/versión; trabajos de indexación/incrustación en segundo plano; Redis opcional; la misma disciplina de seguridad y observabilidad de producción.

Modelo de desarrollo

Cada elemento de implementación tiene un ejecutor principal, un revisor independiente y propietarios de puerta explícitos. Una tarea se divide siempre que contenga más de un resultado comprobable de forma independiente. Los nuevos descubrimientos crean tareas vinculadas en lugar de expandir silenciosamente el alcance.

El lanzamiento a producción está controlado por verificaciones de arquitectura, contrato, seguridad, QA, persistencia, observabilidad, puesta en escena y lanzamiento.

Comandos útiles

node scripts/dashboard-server.mjs
# Open http://localhost:4748/

El panel es una interfaz para el registro de tareas; el registro y los documentos anteriores siguen siendo la fuente de verdad.