orquestra-mcp 1.38.0 → 1.40.0

package/README.md

@@ -1,6 +1,6 @@
 # orquestra-mcp
 
-Servidor MCP (Model Context Protocol) para Orquestra. Expone **100 tools**
+Servidor MCP (Model Context Protocol) para Orquestra. Expone **135 tools**
 que llaman a la API de `orquestra-infra`: lectura de contexto/dashboard/
 workspace/infra/paridad/listados, escritura de tareas/ideas/changelog/
 notas/docs/módulos/flujo/categorías/infra/proyectos, y corridas de QA —
@@ -133,6 +133,7 @@ crear/editar, sin `delete_*`:
 | Entidad | Tools | Notas |
 |---|---|---|
 | Tareas | `create_task`, `update_task` | `update_task` incluye `scope` — úsalo para resolver desfases de paridad |
+| Verificaciones por plataforma | `list_verifications`, `add_verification`, `update_verification`, `delete_verification`, `verify_with_agent` | Confirmaciones (humanas o de agente) de que la tarea quedó bien en web/iOS/Android/API — NO van en el checklist. La tarea no cierra con verificaciones abiertas y se cierra sola al aprobarse la última; `failed` (con `note`) la regresa a su estatus anterior. También: `verifications` en `create_task`, `waiveVerifications` en `update_task` (solo con confirmación del usuario) y `verificationId` en `create_agent_run` |
 | Ideas | `create_idea` | |
 | Changelog | `create_changelog_entry` | Estilo Keep a Changelog |
 | Notas | `create_note` | |
@@ -195,13 +196,15 @@ create/update sigue siendo criterio del agente y del humano.
 
 ## Estado
 
-100 tools: lectura (contexto, dashboard, workspace, infra, paridad, standup,
+135 tools: lectura (contexto, dashboard, workspace, infra, paridad, standup,
 sync report, setup guide, playbooks de etapa y de plataforma, catálogo de
 skills, search) + `list_*` de cada colección + creación/edición de tareas
-(con checklist, tiempo, adjuntos, merge), ideas (con comentarios), notas,
+(con checklist, verificaciones por plataforma, tiempo, adjuntos, merge), ideas (con comentarios), notas,
 docs, changelog (con corte de versión), módulos, flujo, categorías,
 infraestructura, proyecto, contenido (canales, campañas, contenido,
-Postproxy), agentes, skills y sugerencias + compuestas (init_project,
+Postproxy), agentes, skills, sugerencias y vínculos entre ítems
+(`link_items`/`unlink_items`/`list_relations`) + compuestas (init_project,
 apply_stage_playbook, apply_platform_playbook, install_skill). Sin
-`delete_*` salvo adjuntos e ítems de checklist. Publicado en npm como
+`delete_*` salvo adjuntos, ítems de checklist, verificaciones y vínculos
+(`unlink_items`). Publicado en npm como
 `orquestra-mcp` (unscoped) -- `npx orquestra-mcp setup`.

package/bin/orquestra-mcp.mjs

@@ -4,7 +4,7 @@ import { createServer } from '../src/server.mjs'
 import { runSetup } from '../src/setup.mjs'
 import { runVaultSync } from '../src/vaultSync.mjs'
 
-const HELP_TEXT = `orquestra-mcp -- Servidor MCP de Orquestra (127 tools)
+const HELP_TEXT = `orquestra-mcp -- Servidor MCP de Orquestra (132 tools)
 
 Uso:
   npx orquestra-mcp            Inicia el servidor MCP por stdio -- lo usa tu cliente

package/package.json

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

package/src/server.mjs

@@ -31,6 +31,16 @@ const TASK_TYPES = ['feature', 'bug', 'improvement', 'tech', 'docs', 'idea', 'de
 const ACTIVITY_TYPES = ['meeting', 'call', 'followup']
 const ACTIVITY_STATUSES = ['scheduled', 'done', 'cancelled']
 const TASK_PRIORITIES = ['high', 'medium', 'low']
+// Relaciones (ORQ-326) -- misma lista que orquestra-infra/schema/enums/RelationItemType.json.
+const RELATION_TYPES = ['task', 'activity', 'note', 'doc', 'idea']
+// Verificaciones por plataforma de una tarea (ORQ-319) -- ver
+// orquestra-infra/functions/api/lib/verifications.mjs para las reglas reales.
+const VERIFICATION_PLATFORMS = ['web', 'ios', 'android', 'api', 'other']
+const VERIFICATION_MODES = ['human', 'agent', 'either']
+const VERIFICATION_STATUSES = ['pending', 'passed', 'failed', 'waived']
+const VERIFICATION_PLATFORM_DESC = 'Plataforma donde se confirma: "web" | "ios" | "android" | "api" | "other". Una verificación por plataforma.'
+const VERIFICATION_INSTRUCTIONS_DESC = 'Pasos CONCRETOS para confirmar que quedó bien (qué abrir, qué hacer, qué se espera ver) -- ej. "En un iPhone físico con la build de TestFlight: abre Tareas, desliza una tarea a la izquierda y confirma que aparece Archivar". Nada genérico tipo "probar que funcione".'
+const VERIFICATION_MODE_DESC = '"human" (default: solo una persona puede confirmarla, ej. dispositivo físico), "agent" (la puede confirmar un agente con revisión con IA) o "either" (cualquiera de los dos).'
 const CHANGELOG_SECTIONS = ['Added', 'Changed', 'Deprecated', 'Removed', 'Fixed', 'Security']
 // 'postmortem' faltaba acá (gap preexistente, encontrado 12 ago 2026) --
 // mismo fix del lado de write.mjs en orquestra-infra.
@@ -100,10 +110,12 @@ Analítica y anuncios en un sitio web: antes de instalar o tocar Google Analytic
 Durante el trabajo normal de código, sin que el usuario te lo pida explícitamente y SIN ESPERAR a que lo mencione (si tienes esta tool disponible en la sesión, se usa por default en todo trabajo real, no solo cuando alguien dice "usa Orquestra"):
 - 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, en el estatus inicial del proyecto (ver list_statuses). Si no hay un proyecto default configurado para esta carpeta, no te rindas ahí -- usa get_workspace_summary para encontrar el proyecto correcto y pásalo explícito como projectId en cada llamada.
 - Orquestra es el ÚNICO lugar donde se planea y se lleva el avance del trabajo: el plan de pasos va como checklist de la tarea (add_checklist_item) y se marca con update_checklist_item conforme terminas cada uno. No lleves una lista de pendientes paralela en el chat, en archivos temporales ni en la herramienta de tareas de tu propio cliente -- se pierde al cerrar la sesión y el usuario no la ve. Si retomas trabajo en una sesión nueva, parte de la tarea y sus ítems pendientes (list_tasks + list_checklist_items), no de cero. Excepción: un cambio de un solo paso (renombrar algo, responder una pregunta) no necesita tarea.
-- Mientras trabajas, mueve la tarea por los estatus reales según avanzas (no la dejes en el inicial hasta el final). Al terminar, muévela a su estatus final con update_task y registra una entrada de changelog con create_changelog_entry -- así el usuario nunca tiene que documentar esto a mano. Si sabes en qué repo real estás trabajando (podés correr "git remote get-url origin" o ya lo sabes por la carpeta), pásalo SIEMPRE como "repo" ("owner/name") -- encontrado real (17 ago 2026): ni el hook local ni el GitHub Action ni la reconciliación de orquestra-infra lo estaban mandando pese a que el campo existe hace rato, así que ninguna entrada automática sabía de qué repo/plataforma venía. Si además la distribución de ese repo ya está identificada (ver list_distributions), pásala en "distributions" -- sin esto el changelog no puede filtrar/agrupar por plataforma.
+- Verificaciones por plataforma (distintas del checklist): cuando terminas código que necesita confirmación humana o en otra plataforma (probar en un iPhone/Android físico, revisar en la web en producción, pegarle al endpoint real desplegado...), NO lo agregues como ítem de checklist ni dejes la tarea abierta sin más. Registra UNA verificación por plataforma con instrucciones concretas (qué abrir, qué hacer, qué se espera ver) -- con add_verification, o con verifications en create_task si ya lo sabes al crearla -- y mueve la tarea a "En revisión" con un comment que diga qué falta confirmar. La tarea no se puede cerrar con verificaciones abiertas y se cierra SOLA cuando todas quedan aprobadas (update_verification status "passed"; si una falla, "failed" con note y la tarea regresa a su estatus anterior). El checklist es para trabajo; las verificaciones, para confirmar. Si la verificación tiene mode "agent"/"either" y hay un agente con revisión con IA, puedes encolarla con verify_with_agent. Nunca marques passed sin evidencia real de que se probó, y no uses waiveVerifications (ni status "waived") salvo que el usuario lo confirme explícito.
+- Mientras trabajas, mueve la tarea por los estatus reales según avanzas (no la dejes en el inicial hasta el final). Al terminar, muévela a su estatus final con update_task (o a "En revisión" si quedaron verificaciones por plataforma abiertas, ver arriba) y registra una entrada de changelog con create_changelog_entry -- así el usuario nunca tiene que documentar esto a mano. Si sabes en qué repo real estás trabajando (podés correr "git remote get-url origin" o ya lo sabes por la carpeta), pásalo SIEMPRE como "repo" ("owner/name") -- encontrado real (17 ago 2026): ni el hook local ni el GitHub Action ni la reconciliación de orquestra-infra lo estaban mandando pese a que el campo existe hace rato, así que ninguna entrada automática sabía de qué repo/plataforma venía. Si además la distribución de ese repo ya está identificada (ver list_distributions), pásala en "distributions" -- sin esto el changelog no puede filtrar/agrupar por plataforma.
 - Todo cambio de statusId vía update_task valida la transición (nextIds) y queda en el historial de la tarea -- pero ese historial no dice nada por sí solo. Manda SIEMPRE el parámetro "comment" cuando cambies statusId, explicando qué hiciste o por qué -- sin esto, el usuario ve que la tarea cambió pero no sabe por qué ni qué se hizo de verdad (encontrado real: quedaba invisible, a diferencia de cuando un humano mueve la tarjeta a mano en el kanban).
 - Conocimiento que sirve más allá de un proyecto (guías, procesos, decisiones transversales) va en la base del workspace: revisa list_knowledge antes de documentarlo de nuevo, créalo con create_knowledge o súbelo con promote_to_knowledge; lo de un solo proyecto sigue en notas/docs.
 - Reuniones, llamadas y seguimientos NO son tareas: son actividades (no se entregan, se programan y se registran). Usa log_activity para agendarlas o registrarlas, update_activity para marcarlas hechas con su resultado (outcome) y siguiente paso (nextStep), y list_activities para ver la agenda/bitácora -- nunca create_task con esos tipos. Si del siguiente paso sale trabajo real, eso sí es una tarea (create_task normal, con módulo y fecha).
+- Para dejar constancia de que una nota, doc, idea o tarea es DE una reunión/llamada (o de otra cosa del proyecto) -- "esta nota es de la reunión X", "esta tarea sale de este doc" --, vincúlalas con link_items en vez de meter la referencia como texto en la descripción/cuerpo; list_relations muestra todo lo relacionado de un ítem.
 - 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 una nota que vas a crear (create_note) es claramente sobre un módulo o una tarea específica -- por ejemplo durante un setup guiado donde acabas de crear ambos -- mándale moduleId/taskId para ligarla, en vez de dejarla suelta. No inventes la relación si no es clara.
 - create_changelog_entry SIEMPRE deja la entrada en Unreleased (nunca mandes version salvo que el usuario te haya dado un número real) -- cortar una versión es release_changelog_version, una acción DELIBERADA que solo se llama si el usuario la pide explícitamente ("cortá la versión", "hacé el release de X") o confirma un número/fecha real que vos propusiste. No la dispares solo porque terminaste una tarea o un lote de trabajo grande.
@@ -644,13 +656,18 @@ export function createServer() {
       resolvedCommitMessage: z.string().optional(),
       resolvedCommitUrl: z.string().optional(),
       resolvedCommitAt: z.number().optional().describe('Timestamp en ms del commit resolutor.'),
+      verifications: z.array(z.object({
+        platform: z.enum(VERIFICATION_PLATFORMS).describe(VERIFICATION_PLATFORM_DESC),
+        instructions: z.string().min(1).describe(VERIFICATION_INSTRUCTIONS_DESC),
+        mode: z.enum(VERIFICATION_MODES).optional().describe(VERIFICATION_MODE_DESC),
+      })).optional().describe('Verificaciones por plataforma desde la creación (mismo efecto que add_verification después). Son confirmaciones humanas o en otra plataforma ("probar en iPhone físico", "revisar en la web en producción"), NO pasos de trabajo -- esos van en el checklist. La tarea no se puede cerrar mientras alguna siga abierta, y se cierra sola cuando todas quedan aprobadas.'),
     }
   )
 
   registerUpdate(
     'update_task',
     '/v1/tasks',
-    'Edita una tarea existente (incluido su scope multiplataforma, para resolver desfases de paridad). Si cambias statusId, el server valida que la transición sea válida (nextIds del estatus actual -- ver list_statuses) y deja rastro en el historial de la tarea (quién/cuándo/de qué a qué) -- pásale SIEMPRE `comment` cuando cambies statusId para que ese rastro también diga QUÉ hiciste o POR QUÉ, no solo el cambio de id. No deja pasar a un estatus final (isFinal) con ítems del checklist sin terminar (400 "Quedan X de Y..."): marca primero los ítems que de verdad hiciste con update_checklist_item; usa completeChecklist:true solo si el usuario confirma que lo pendiente ya no aplica o ya está hecho.',
+    'Edita una tarea existente (incluido su scope multiplataforma, para resolver desfases de paridad). Si cambias statusId, el server valida que la transición sea válida (nextIds del estatus actual -- ver list_statuses) y deja rastro en el historial de la tarea (quién/cuándo/de qué a qué) -- pásale SIEMPRE `comment` cuando cambies statusId para que ese rastro también diga QUÉ hiciste o POR QUÉ, no solo el cambio de id. No deja pasar a un estatus final (isFinal) con ítems del checklist sin terminar (400 "Quedan X de Y..."): marca primero los ítems que de verdad hiciste con update_checklist_item; usa completeChecklist:true solo si el usuario confirma que lo pendiente ya no aplica o ya está hecho. Tampoco deja cerrar con verificaciones por plataforma abiertas (pending/failed, ver list_verifications): no cierres a mano -- deja la tarea en "En revisión" y se cierra sola cuando todas quedan aprobadas; waiveVerifications:true solo con confirmación explícita del usuario.',
     {
       title: z.string().optional(),
       description: z.string().optional(),
@@ -658,6 +675,7 @@ export function createServer() {
       priority: z.enum(TASK_PRIORITIES).optional(),
       statusId: z.string().optional(),
       completeChecklist: z.boolean().optional().describe('Solo junto con un statusId final: marca como hechos los ítems pendientes del checklist y cierra (queda comentado en la tarea). Sin esto, cerrar con checklist pendiente responde 400.'),
+      waiveVerifications: z.boolean().optional().describe('Solo junto con un statusId final: marca como omitidas ("waived", nota "Omitida al cerrar la tarea") las verificaciones abiertas y cierra (queda comentado en la tarea). Sin esto, cerrar con verificaciones pendientes o fallidas responde 400. NO lo uses salvo que el usuario confirme explícito que esas verificaciones ya no aplican -- lo normal es dejar la tarea en "En revisión" y que se cierre sola al aprobarse.'),
       categoryId: z.string().optional(),
       moduleId: z.string().optional(),
       dueDate: z.string().optional().describe('YYYY-MM-DD'),
@@ -881,6 +899,49 @@ export function createServer() {
     (args, projectId) => ({ projectId, status: args.status, type: args.type, moduleId: args.moduleId, from: args.from, to: args.to, limit: args.limit })
   )
 
+  // Relaciones (ORQ-326): vínculo manual NO dirigido entre dos cosas del proyecto. El server ordena el par y
+  // el id es determinístico (vincular dos veces no duplica). Ver orquestra-infra/functions/api/lib/relations.mjs.
+  registerRead(
+    'list_relations',
+    '/v1/relations',
+    'Sección "Relacionado" de una tarea, actividad (reunión/llamada/seguimiento), nota, doc o idea: junta los vínculos manuales (link_items, source "manual", con relationId para unlink_items) Y los que ya salen de campos existentes (nota de la tarea/minuta de la reunión, nota relacionada, ADR publicado, tarea que proviene de una nota, siguiente paso de una reunión, tareas ligadas a una idea -- source = esa etiqueta, relationId null, no se pueden quitar desde acá). Sin duplicados (el manual gana) y sin extremos borrados. No incluye menciones [[...]] -- esas van en get_backlinks.',
+    {
+      type: z.enum(RELATION_TYPES).describe('"activity" para reunión/llamada/seguimiento, "task" para cualquier otra tarea -- el server rechaza el tipo equivocado'),
+      id: z.string().describe('id del ítem (de list_tasks/list_activities/list_notes/list_docs/list_ideas)'),
+    },
+    (args, projectId) => ({ projectId, type: args.type, id: args.id })
+  )
+
+  registerCreate(
+    'link_items',
+    '/v1/relations',
+    'Vincula a mano dos cosas del mismo proyecto (tarea, actividad, nota, doc o idea) -- ej. "esta nota es de la reunión X", "esta tarea sale de este doc", "este doc documenta esa idea". El vínculo no tiene dirección (el orden a/b da igual, el server lo ordena) y es idempotente: vincular dos veces lo mismo no duplica (responde alreadyLinked). Saca los ids de list_tasks, list_activities, list_notes, list_docs y list_ideas; una reunión/llamada/seguimiento es "activity", no "task" (el server valida el tipo real y que ambos existan). No se puede vincular algo consigo mismo. Úsalo en vez de escribir "ver reunión X" en el texto.',
+    {
+      aType: z.enum(RELATION_TYPES).describe('Tipo del primer ítem'),
+      aId: z.string().describe('id del primer ítem'),
+      bType: z.enum(RELATION_TYPES).describe('Tipo del segundo ítem'),
+      bId: z.string().describe('id del segundo ítem'),
+    }
+  )
+
+  server.registerTool(
+    'unlink_items',
+    {
+      description: 'Quita un vínculo manual entre dos ítems (creado con link_items). relationId sale de list_relations (solo los de source "manual" tienen uno; los derivados de campos existentes no se quitan acá). No borra ninguno de los dos ítems. 404 si el vínculo ya no existe.',
+      inputSchema: {
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+        relationId: z.string().describe('relationId de list_relations, ej. "activity_abc__note_xyz"'),
+      },
+    },
+    async ({ projectId, relationId }) => {
+      try {
+        return textResult(await apiDelete(config, '/v1/relations', { projectId: resolveProjectId(projectId), id: relationId }))
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
   // Fusionar tareas (20 ago 2026) -- registradas directo con
   // server.registerTool (no registerCreate/registerUpdate) porque son
   // POST a `${path}/${id}/merge|unmerge`, no un CRUD estándar. Fusión
@@ -1404,6 +1465,112 @@ export function createServer() {
     }
   )
 
+  // Verificaciones por plataforma de una tarea (ORQ-319). Distintas del
+  // checklist: el checklist es TRABAJO de la tarea; una verificación es la
+  // CONFIRMACIÓN (humana o de un agente) de que quedó bien en una plataforma.
+  // Mismo criterio que el checklist -- dos ids dinámicos en la ruta, así que
+  // server.registerTool directo. Reglas reales (gate de cierre, cierre
+  // automático, regreso de estatus al fallar) viven en
+  // orquestra-infra/functions/api/lib/verifications.mjs.
+  registerRead(
+    'list_verifications',
+    '/v1/verifications',
+    'Lista las verificaciones por plataforma del proyecto (con taskId/shortCode/taskTitle/taskStatusId/assignedTo de su tarea). Por default solo las abiertas (pending + failed) de tareas que no están cerradas -- úsala para ver qué falta confirmar en cada plataforma (ej. "qué tengo que probar en iOS").',
+    {
+      status: z.enum(['open', 'pending', 'failed', 'passed', 'waived', 'all']).optional().describe('Default "open" (pending + failed, excluye tareas en estatus final/cancelado/archivado). "all" trae todo, incluidas tareas cerradas.'),
+      platform: z.enum(VERIFICATION_PLATFORMS).optional().describe('Filtra por plataforma'),
+    },
+    (args, projectId) => ({ projectId, status: args.status, platform: args.platform })
+  )
+
+  server.registerTool(
+    'add_verification',
+    {
+      description: 'Registra una verificación por plataforma en una tarea: algo que una persona (o un agente) tiene que CONFIRMAR después de que el código ya está hecho -- probar en un iPhone/Android físico, revisar en la web en producción, pegarle al endpoint real, etc. NO es un ítem de checklist (el checklist es trabajo por hacer). Una por plataforma, con instrucciones concretas. Después mueve la tarea a "En revisión": no se puede cerrar mientras haya verificaciones abiertas, y se cierra sola cuando todas quedan aprobadas.',
+      inputSchema: {
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+        taskId: z.string().describe('ID de la tarea'),
+        platform: z.enum(VERIFICATION_PLATFORMS).describe(VERIFICATION_PLATFORM_DESC),
+        instructions: z.string().min(1).describe(VERIFICATION_INSTRUCTIONS_DESC),
+        mode: z.enum(VERIFICATION_MODES).optional().describe(VERIFICATION_MODE_DESC),
+      },
+    },
+    async ({ projectId, taskId, ...body }) => {
+      try {
+        const data = await apiPost(config, `/v1/tasks/${taskId}/verifications`, { projectId: resolveProjectId(projectId), ...body })
+        return textResult(data)
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
+  server.registerTool(
+    'update_verification',
+    {
+      description: 'Edita o resuelve una verificación de una tarea. status: "passed" (aprobada), "failed" (falló -- exige note con lo que se vio), "waived" (omitida -- exige note con el motivo; solo si el usuario confirma que ya no aplica) o "pending" (re-verificar: limpia nota y resolución). Al resolver (passed/waived) la ÚLTIMA abierta, el server cierra la tarea solo si su estatus actual tiene un estatus final en sus transiciones y el checklist no tiene pendientes (la respuesta trae autoClosed:true); si no puede, comenta y avisa al responsable. Al marcar "failed", la tarea regresa a su estatus anterior (típico: En revisión → En progreso; ver movedBackTo en la respuesta) y se notifica al responsable. Marca passed solo con evidencia real de que se probó, nunca por suponer que funciona.',
+      inputSchema: {
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+        taskId: z.string().describe('ID de la tarea'),
+        verificationId: z.string().describe('ID de la verificación (ver list_verifications o la tarea)'),
+        status: z.enum(VERIFICATION_STATUSES).optional().describe('"pending" | "passed" | "failed" | "waived". failed y waived exigen note.'),
+        note: z.string().optional().describe('Obligatoria con status "failed" (qué falló) o "waived" (por qué se omite).'),
+        instructions: z.string().optional().describe(VERIFICATION_INSTRUCTIONS_DESC),
+        platform: z.enum(VERIFICATION_PLATFORMS).optional(),
+        mode: z.enum(VERIFICATION_MODES).optional().describe(VERIFICATION_MODE_DESC),
+      },
+    },
+    async ({ projectId, taskId, verificationId, ...body }) => {
+      try {
+        const data = await apiPatch(config, `/v1/tasks/${taskId}/verifications`, { projectId: resolveProjectId(projectId), id: verificationId, ...body })
+        return textResult(data)
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
+  server.registerTool(
+    'delete_verification',
+    {
+      description: 'Borra una verificación de una tarea (ej. se registró por error o en la plataforma equivocada). Si la verificación sigue aplicando pero no se va a hacer, no la borres: márcala "waived" con update_verification y una nota, para que quede rastro.',
+      inputSchema: {
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+        taskId: z.string().describe('ID de la tarea'),
+        verificationId: z.string().describe('ID de la verificación a borrar'),
+      },
+    },
+    async ({ projectId, taskId, verificationId }) => {
+      try {
+        const data = await apiDelete(config, `/v1/tasks/${taskId}/verifications`, { projectId: resolveProjectId(projectId), id: verificationId })
+        return textResult(data)
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
+  server.registerTool(
+    'verify_with_agent',
+    {
+      description: 'Encola una corrida de agente que confirma una verificación siguiendo sus instrucciones. Solo para verificaciones con mode "agent" o "either", y requiere un agente con revisión con IA activada (aiReviewEnabled). Sin agentId, el server elige el agente por la plataforma (web→"web", ios→"ios", android→"android", api→"node"). La corrida queda "queued": al terminar marca la verificación aprobada/fallida sola (inconclusa la deja pending con un comentario) -- nunca la des por aprobada sin confirmar con get_agent_run.',
+      inputSchema: {
+        projectId: z.string().optional().describe(PROJECT_ID_DESC),
+        taskId: z.string().describe('ID de la tarea'),
+        verificationId: z.string().describe('ID de la verificación a confirmar'),
+        agentId: z.string().optional().describe('Agente específico (ver list_agents) -- si no se manda, se resuelve por la plataforma de la verificación'),
+      },
+    },
+    async ({ projectId, taskId, verificationId, ...body }) => {
+      try {
+        const data = await apiPost(config, `/v1/tasks/${taskId}/verifications/${verificationId}/agent-run`, { projectId: resolveProjectId(projectId), ...body })
+        return textResult(data)
+      } catch (err) {
+        return errorResult(err)
+      }
+    }
+  )
+
   // Adjuntos (imágenes + código) en tasks/notes/ideas/docs -- mismo criterio
   // que checklist: entityType/entityId van en el path (dos segmentos
   // dinámicos), así que server.registerTool directo. Ver
@@ -2442,6 +2609,7 @@ export function createServer() {
     runnerId: z.string().optional().describe('Máquina específica -- si se manda, gana sobre la del agente resuelto'),
     taskId: z.string().optional().describe('Acota la revisión con IA (si el agente la tiene activada) a esta tarea en vez de "revisa todo el proyecto" -- útil para pedir "corre QA de esto que acabo de hacer". Sin efecto en los pasos de script (lint/test/build corren igual siempre). Para kind="screenshots" es además OBLIGATORIO en la práctica: es la tarea a la que se van a adjuntar solas las capturas al terminar la corrida -- sin taskId, las capturas se suben pero nadie las liga a nada. No combinar con moduleId.'),
     moduleId: z.string().optional().describe('Igual que taskId pero acota a un módulo completo. No combinar con taskId.'),
+    verificationId: z.string().optional().describe('Verificación de la tarea (requiere taskId) que esta corrida debe confirmar siguiendo sus instrucciones -- al terminar, el resultado la marca aprobada/fallida solo. Solo para verificaciones con mode "agent" o "either" y un agente con revisión con IA activada. Preferí verify_with_agent, que resuelve el agente por la plataforma.'),
   })
 
   server.registerTool(