orquestra-mcp 1.3.0 → 1.4.1

package/README.md

@@ -1,9 +1,10 @@
 # orquestra-mcp
 
-Servidor MCP (Model Context Protocol) para Orquestra. Expone **35 tools**
+Servidor MCP (Model Context Protocol) para Orquestra. Expone **38 tools**
 que llaman a la API de `orquestra-infra`: lectura de contexto/dashboard/
-workspace/infra/paridad/listados, y escritura de tareas/ideas/changelog/
-notas/docs/módulos/flujo/categorías/infra/proyectos — un agente puede
+workspace/infra/paridad/listados, escritura de tareas/ideas/changelog/
+notas/docs/módulos/flujo/categorías/infra/proyectos, y corridas de QA —
+un agente puede
 prácticamente todo lo que un humano hace en la web, directo desde la
 conversación. `get_setup_guide` documenta el orden recomendado para
 configurar/sincronizar un proyecto completo sin crear duplicados.
@@ -185,12 +186,11 @@ create/update sigue siendo criterio del agente y del humano.
 
 ## Estado
 
-35 tools: 8 de lectura (contexto/tasks/search + dashboard/workspace/infra/
-paridad/playbook) + 6 `list_*` + `get_setup_guide` + 18 de creación/
-edición (tasks/ideas/changelog/notes/docs + módulos/flujo/categorías/
-servicios/entornos/distribuciones) + 2 compuestas (init_project,
-apply_stage_playbook). No hay `delete_*`, ni `update_idea`/`update_note`/
-`update_doc`/`update_changelog_entry` todavía. Distribuido por ahora vía
-path local o `npx github:ajuarez93/orquestra-mcp` — publish a npm como
-`orquestra-mcp` queda pendiente (requiere crear el scope `orquestra` en
-npmjs.com).
+38 tools: 9 de lectura (contexto/tasks/search + dashboard/workspace/infra/
+paridad/setup guide/stage playbook) + 6 `list_*` + 19 de creación/edición
+(tasks/ideas/changelog/notes/docs + módulos/flujo/categorías/servicios/
+entornos/distribuciones/proyecto) + 2 de QA (create_qa_run/get_qa_run) +
+2 compuestas (init_project, apply_stage_playbook). No hay `delete_*`, ni
+`update_idea`/`update_note`/`update_doc`/`update_changelog_entry`
+todavía. Publicado en npm como `orquestra-mcp` (unscoped) -- `npx
+orquestra-mcp setup`.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "orquestra-mcp",
-  "version": "1.3.0",
-  "description": "Servidor MCP de Orquestra -- 35 tools para leer y escribir tareas, ideas, changelog, infraestructura y más desde un agente de IA",
+  "version": "1.4.1",
+  "description": "Servidor MCP de Orquestra -- 38 tools para leer y escribir tareas, ideas, changelog, infraestructura, QA y más desde un agente de IA",
   "type": "module",
   "bin": {
     "orquestra-mcp": "./bin/orquestra-mcp.mjs"

package/src/server.mjs

@@ -50,13 +50,15 @@ const SERVER_INSTRUCTIONS = `Este server conecta con Orquestra, la app de gesti
 Al empezar una sesión de trabajo en este proyecto, llama una vez a get_project_context para saber en qué fase está, qué tareas hay abiertas/vencidas/bloqueadas y qué se hizo recientemente. Úsalo como contexto de fondo, no lo repitas en cada mensaje.
 
 Si get_project_context devuelve un proyecto vacío (sin módulos ni tareas), es la primera vez que se usa este MCP aquí -- pero "vacío en Orquestra" NO significa "recién empezado en la realidad". Antes de ofrecer nada, pregúntale al usuario: ¿este proyecto es una idea nueva, o ya existe y solo lo estás conectando por primera vez? Según la respuesta:
-- Si es una idea nueva: llama a get_setup_guide y ofrece un playbook de etapa "pre" (get_stage_playbook + apply_stage_playbook).
-- Si ya existe y está avanzado: usa update_project para poner la fase real (mvp/v1/beta/producción, no "idea"), crea una distribution por cada plataforma real que te mencione, y ofrece el playbook de etapa "build" en vez de "pre" -- no le apliques la plantilla de idea/diseño a un proyecto que ya está en desarrollo activo.
+- Si es una idea nueva: llama a get_setup_guide y ofrece un playbook de etapa "pre" (get_stage_playbook + apply_stage_playbook) -- ahí sí basta con eso, el proyecto de verdad no tiene nada más que sincronizar todavía.
+- Si ya existe y está avanzado: NO te limites a update_project ni a las distributions -- eso es solo el primer paso, no el trabajo completo. Llama a get_setup_guide y recorre sus 9 pasos en orden real (estatus/flujo, categorías, infraestructura completa -- servicios Y entornos, no solo distribuciones --, módulos, tareas, ideas, notas, changelog, docs), usando list_* de cada uno antes de crear para no duplicar. No asumas ni dejes vacío lo que no puedas inferir del código -- pregúntale al usuario los servicios/entornos reales, los módulos o áreas de trabajo, y las tareas pendientes reales que tenga en mente. Ofrece el playbook de etapa "build" (no "pre") solo como plantilla de módulo+tareas inicial, no como sustituto de sincronizar el resto.
 
 Durante el trabajo normal de código, sin que el usuario te lo pida explícitamente:
 - Si te pide una funcionalidad o arreglo real (no una pregunta rápida ni exploración de código sin cambios), revisa con list_tasks/search si ya existe una tarea relacionada; si no, créala con create_task antes de empezar a trabajar.
 - Al terminar, mueve la tarea de estatus con update_task y registra una entrada de changelog con create_changelog_entry -- así el usuario nunca tiene que documentar esto a mano.
 - Antes de crear un módulo/estatus/categoría/servicio/entorno/distribución, revisa con el list_* correspondiente que no exista ya uno con ese nombre.
+- Si tienes acceso al repo real de una distribución (ej. puedes correr "git remote get-url origin" en ese código), llena repoUrl en create_distribution/update_distribution sin preguntar -- es solo informativo, no requiere credenciales. Esto es distinto de conectar el repo con PAT para el changelog automático (Workspace → Conexiones en orquestra-web): eso sí es un paso deliberado del usuario, con una credencial real -- nunca lo hagas tú solo ni sugieras que ya está conectado por haber llenado repoUrl.
+- No todas las tareas necesitan una corrida de QA -- clasifica antes de disparar una: cambios que afectan comportamiento real (features, bugs, UI, lógica de negocio, endpoints/API) sí la necesitan; cambios que no alteran comportamiento (docs, comentarios, refactors sin cambio funcional, config/tooling interno, notas/reuniones/ideas) no. Si decides que sí, llama a create_qa_run en la rama real de ese trabajo y deja la tarea en "En revisión" -- NUNCA la muevas a "Listo" ni digas que "QA lo revisó" sin haber confirmado con get_qa_run un estatus terminal "passed" de verdad (las corridas son asíncronas, tardan minutos en otra máquina). Si tarda, dile al usuario que quedó en cola (con el runId) y que confirmas cuando termine -- no lo des por hecho nunca.
 
 No le preguntes al usuario por workspaceId ni projectId -- ya están configurados. Solo pregúntale por el proyecto si tiene más de uno y no queda claro a cuál te refieres.
 
@@ -495,6 +497,7 @@ export function createServer() {
     stack: z.array(z.string()).optional(),
     version: z.string().optional().describe('Versión en store'),
     reviewVersion: z.string().optional().describe('Build en revisión -- apps'),
+    repoUrl: z.string().optional().describe('URL del repo de este código (ej. de "git remote get-url origin") -- solo informativo, no requiere credenciales. Distinto de conectar el repo con PAT (eso es Workspace → Conexiones, un paso deliberado del usuario, nunca lo hagas solo).'),
   })
   registerUpdate('update_distribution', '/v1/distributions', 'Edita una distribución existente.', {
     label: z.string().optional(),
@@ -512,8 +515,39 @@ export function createServer() {
     stack: z.array(z.string()).optional(),
     version: z.string().optional(),
     reviewVersion: z.string().optional(),
+    repoUrl: z.string().optional().describe('URL del repo de este código -- solo informativo, no requiere credenciales.'),
   })
 
+  // ═══ QA (módulo de runners -- ver orquestra-qa-agent) ═══════════════════════
+  // Asíncronas: una corrida puede tardar minutos en otra máquina. Ver
+  // SERVER_INSTRUCTIONS para la regla de no asumir "passed" sin confirmar.
+
+  registerCreate('create_qa_run', '/v1/qa/runs', 'Dispara una corrida de QA (lint/tests/build/E2E según el stack) en la rama indicada. El proyecto necesita QA activado (Workspace → QA + sección QA del proyecto) o falla explícito. La corrida queda "queued" -- nunca asumas que pasó, confirma con get_qa_run.', {
+    branch: z.string().optional().describe('Rama a probar -- default: la configurada para el proyecto, o "main"'),
+    commit: z.string().optional(),
+    trigger: z.enum(['manual', 'push', 'schedule']).optional().describe('Default: manual'),
+    runnerId: z.string().optional().describe('Máquina específica -- default: la configurada para el proyecto, o cualquiera disponible'),
+  })
+
+  server.registerTool(
+    'get_qa_run',
+    {
+      description: 'Consulta el estatus real de una corrida de QA por id (queued|running|passed|failed|error|cancelled, con steps y summary). Única forma válida de confirmar un resultado -- nunca lo des por hecho.',
+      inputSchema: {
+        runId: z.string().describe('ID de la corrida, devuelto por create_qa_run'),
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+      },
+    },
+    async ({ runId, projectId }) => {
+      try {
+        const data = await apiGet(config, `/v1/qa/runs/${runId}`, { projectId: resolveProjectId(projectId) })
+        return textResult(data)
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
   // ═══ COMPUESTAS (nivel C) ═══════════════════════════════════════════════════
 
   server.registerTool(