vlm-code-context-mcp

Un equipo de ingeniería de IA completo. Un paquete npm. Cero desperdicio de contexto.

📖 Guía de inicio — ¿Eres nuevo aquí? ¡Empieza por aquí!

Product Owner. Arquitecto. QA. Seguridad. Dos desarrolladores. Un Scrum Master. Un Gerente. Un desarrollador líder. Todos ejecutando sprints reales. Todos hablando con tu base de código. Todo dentro de una única base de datos SQLite.

npm install vlm-code-context-mcp
npx code-context-mcp setup .
npx code-context-dashboard ./context.db

Por qué existe esto

Cada herramienta de codificación de IA choca con el mismo muro: el modelo consume su ventana de contexto solo leyendo tu base de código antes de poder hacer algo útil. Luego la sesión termina, y la próxima vez empieza de cero.

El segundo problema es peor: no hay proceso. Obtienes una IA capaz que no tiene idea de qué se supone que debe construir, en qué orden o por qué.

vlm-code-context-mcp resuelve ambos. Pre-indexa todo tu proyecto en una base de datos SQLite estructurada para que los agentes consulten metadatos en lugar de código fuente sin procesar: 25 veces menos tokens, 26 veces menos datos en una base de código de 224 archivos. Y envuelve esa inteligencia en un equipo de scrum virtual completo que ejecuta ceremonias de sprint reales a través de 81 herramientas MCP, con puertas de fase, retrospectivas, seguimiento de velocidad y un panel de control en React en vivo.

Esto no es un rastreador de tareas con Claude añadido. Es un sistema operativo para el desarrollo impulsado por IA.

Lo que obtienes en 60 segundos

Step 1/4 — Indexing files into context.db...
  Indexed 25 files, 142 exports, 87 dependencies

Step 2/4 — Loading scrum schema...
  Created 10 scrum tables

Step 3/4 — Importing team from .claude/agents/...
  Loaded 9 agents, 3 sprints, 24 tickets

Step 4/4 — Writing .mcp.json...
  Configured MCP server entry

=== Setup complete! (my-project) ===

Luego abre el panel de control:

npx code-context-dashboard ./context.db
# Opens at http://localhost:3333

Eso es todo. Tu equipo de IA está listo. Sin claves API. Sin servicios externos. Sin dependencia de la nube. Todo vive en context.db.

El equipo

Cada agente tiene un rol definido, un prompt del sistema, acceso a herramientas limitado a sus responsabilidades y una puntuación de estado de ánimo derivada de la carga de tickets y el sentimiento de la retrospectiva. El sistema rastrea señales de agotamiento a través de los sprints.

El proceso de sprint

Los sprints se ejecutan a través de 10 fases aplicadas con verificaciones de puerta automatizadas:

preparation → kickoff → planning → implementation → qa → refactoring → retro → review → closed → rest

Las puertas son reales. El sprint no avanzará a QA hasta que los tickets estén asignados y estimados. No se cerrará hasta que se registren los hallazgos de la retrospectiva. La velocidad se rastrea automáticamente en cada sprint y aparece en el panel de control.

El panel de control

6 páginas. 68 componentes. Actualizaciones SSE en vivo.

Cada mutación (cambio de estado de ticket, actualización de estado de ánimo del agente, transición de fase de sprint) activa una actualización instantánea del panel de control a través del monitoreo de WAL de SQLite. Sin sondeo. Sin actualización manual.

• Tablero de Sprint — Kanban, vista de planificación, rastreador de puertas de QA, gráfico de burndown

• Explorador de Código — Árbol de archivos, grafo de dependencias, mapa de exportación/importación, historial de cambios

• Gestión de Proyectos — Cronograma de Gantt, rastreador de hitos, canal de descubrimiento, editor de visión

• Equipo — Tarjetas de salud del agente, tendencias de estado de ánimo, distribución de carga de trabajo

• Retrospectiva — Hallazgos por categoría, análisis de patrones entre sprints, seguimiento de acciones

• Marketing — Notas de la versión, posicionamiento, animación de visión de Remotion

📸 [captura de pantalla aquí]
📸 [captura de pantalla aquí]

La capa de puente

El problema más difícil en las herramientas de agentes es la comunicación bidireccional: lograr que la interfaz de usuario y la IA realmente hablen entre sí en tiempo real.

src/bridge/ implementa un hook PreToolUse que conecta Claude Code con el panel de control. Las acciones en cola en la interfaz de usuario son procesadas por la sesión de Claude Code en ejecución. Esto es lo que hace que el equipo se sienta vivo en lugar de un tablero estático.

Esto todavía se está consolidando. Las PR son bienvenidas.

Eficiencia de contexto

Medido en la propia base de código de este proyecto (224 archivos, 54K líneas, 2.1 MB):

Metodología: tarea de "entender y modificar una función": localizar archivos relevantes, entender exportaciones/importaciones/dependientes, revisar cambios recientes. Sin MCP, el agente lee ~20 archivos sin procesar (promedio de 9,200 caracteres cada uno). Con MCP, consulta metadatos estructurados a través de search_files, find_symbol y get_file_context: resúmenes, listas de exportación y grafos de dependencias en lugar de código fuente sin procesar.

El primer índice cuesta más: los archivos deben leerse para generar metadatos. Cada consulta posterior es 25 veces más barata. Punto de equilibrio después de 1 uso. Los ahorros aumentan con el tamaño de la base de código: un proyecto de 25 archivos ve una reducción de 3x, este proyecto de 224 archivos ve una reducción de 25x.

De un vistazo

Historial del proyecto

Construido completamente a través de su propio proceso de scrum. El equipo virtual ha completado 22 hitos, 69 sprints productivos y 211 tickets que suman 534 puntos de historia con una velocidad continua de ~20 pts/sprint.

Hallazgos de retrospectiva en 19 sprints

Qué salió bien (patrones principales):

• Enfoque de descubrimiento primero eliminó constantemente la implementación desperdiciada. Probar 3-4 enfoques antes de escribir código ahorró días de retrabajo (S59, S65, S68).

• Ejecución paralela de agentes redujo drásticamente el tiempo de implementación. 4 agentes trabajando en tickets independientes simultáneamente mientras el hilo principal coordinaba (S59, S65, S67).

• Investigación antes de codificar detectó callejones sin salida temprano. S68 eliminó 3 enfoques de puente candidatos (tuberías con nombre, sockets unix, suscripciones a recursos MCP) en horas en lugar de días.

• Patrón de migración de esquema (tabla schema_versions) hizo que los cambios incrementales en la base de datos fueran seguros y repetibles. Cero regresiones en 7 adiciones de esquema (S53, S55).

• Auditoría de seguridad en paralelo detectó 2 hallazgos ALTOS antes de que se enviara cualquier código (S68). Ejecutar auditorías junto con la implementación, no después, es el patrón correcto.

Qué salió mal (patrones principales):

• Pruebas marcadas como HECHO sin ejecutarlas. Los agentes escribieron pruebas pero no pudieron ejecutarlas: la verificación de compilación debe ocurrir antes de marcar como HECHO (S61, S65, S66).

• Fallos de prueba preexistentes crearon ruido que enmascaraba regresiones reales. Las pruebas obsoletas de cambios de esquema antiguos seguían apareciendo (S53, S67, S68).

• La velocidad de descubrimiento fue engañosa. S56 tenía 46sp comprometidos pero todos los tickets eran solo documentación. Los puntos de descubrimiento deben rastrearse por separado de la implementación.

• Títulos de ticket genéricos sin descripciones o criterios de aceptación hicieron imposible el QA. Cada ticket necesita un alcance concreto (S53).

• Deuda técnica de frontend acumulada — componentes de más de 800 LOC, más de 850 estilos en línea, cero pruebas. Debería haberse abordado antes (S59).

Intentar a continuación (próximos pasos):

• Ejecutar npm run build después de que cada agente termine, antes de marcar el ticket como HECHO (S65, S66, S67).

• Agregar criterios de aceptación a cada ticket en el momento de la creación (S55).

• Verificar el estado actual antes de crear tickets de corrección: algunos ya estaban resueltos (S58).

• Cada nueva herramienta write-MCP debe activar una notificación SSE: agregar como elemento de lista de verificación (S53).

• Implementar canales para una señalización de puente basada en push real cuando la API se estabilice (S68).

• Rastrear los puntos de descubrimiento por separado de la velocidad de implementación (S56).