Antigravity DeveloperAI

DevTasks Control Plane

Estado operativo del sistema de scans, findings, triage arquitectónico y generación de dev tasks.

Esperando datos
Documentación

Operación

Acciones

Lanza pasos concretos o un ciclo operativo corto desde el dashboard.

Sin acciones ejecutadas en esta sesión.

Entrada unificada

Nueva petición técnica

Crea un work item manual que entrará en el mismo pipeline y pasará por Architect_Review.

Sin envíos en esta sesión.

KPIs

Resumen

Sincronizando métricas…

Observabilidad

Alertas

Workflow Health

Ejecución

Distribución

Findings por severidad

Distribución

Work items por estado

Distribución

Dev tasks por estado

Distribución

Work items por origen

Dispatch

Agent dispatches

Repo scans

Actividad reciente

ID Estado Findings Duración Inicio

Triage

Work items recientes

ID Título Estado Sev.

Entradas humanas

Telegram, email y dashboard

Canal Petición Solicitante Estado

Entrega

Dev tasks recientes

ID Título Estado Prioridad

Dispatch

Preparación a agente

ID Dev task Estado Branch

Documentación

Guía operativa del sistema

Volver arriba

Qué hace este sistema

Este cuadro de mando controla el pipeline completo de análisis arquitectónico automático del repositorio EstanisMoreno / Antigravity-SAAS-2006 sobre la rama main.

  1. Abre un repo_scan nuevo en la base de datos.
  2. Lista archivos analizables dentro de src y filtra .ts y .tsx.
  3. Descarga contenido del repo privado en GitHub y lo analiza con IA.
  4. Guarda hallazgos estructurados en repo_findings.
  5. Normaliza entradas humanas desde dashboard, Telegram y email hacia work_items consistentes.
  6. Hace triage con arquitecto IA y decide si un item necesita más info o debe pasar a ejecución.
  7. Crea dev_tasks con especificación técnica a partir de los work items viables.
  8. Prepara agent_dispatches con packet y prompt final para Codex / Antigravity.
  9. Deja trazabilidad de estados, tiempos, notas y errores.

Workflows y responsabilidad

  • Repo_Start_Scan: abre un scan y no analiza nada.
  • Repo_List_Files: selecciona archivos fuente analizables.
  • Repo_Analyze_Selected_Files: llama a IA, parsea findings e inserta en repo_findings.
  • Repo_Findings_To_WorkItems: deduplica con source_fingerprint y crea work_items.
  • Architect_Review: triage de work items nuevos.
  • Architect_Create_Dev_Task: crea dev_tasks y marca el work item como convertido.
  • Ingest_Work_Item: capa unificada de normalización e inserción para entradas humanas.
  • Telegram_Ingest_Request, Email_Ingest_Request y SaaS_User_Bug_Email_Ingest: adaptadores de entrada.
  • DevTasks_To_Antigravity: prepara packet y dispatch listo para agente.

Cómo proceder en operación normal

  1. Revisa el bloque de alertas para confirmar si hay scans abiertos, cola de review o cola de dev tasks.
  2. Usa Nueva petición técnica para introducir trabajo manual sin saltarte al arquitecto IA.
  3. Si el sistema está parado, pulsa Activar automatización.
  4. Para forzar ciclo completo, pulsa Activar y lanzar scan.
  5. Para abrir solo un scan manual, usa Nuevo scan.
  6. Vigila Workflow Health, la cola de dev tasks y la tabla de dispatches preparados.
  7. Si aparecen items en needs_info, revisa architect_notes y error_message antes de reintentar.

Ponerlo operativo desde cero

  1. Confirma que las credenciales de GitHub, PostgreSQL y OpenAI siguen válidas en n8n.
  2. Activa Repo_Start_Scan, Repo_List_Files, Repo_Findings_To_WorkItems, Architect_Review y Architect_Create_Dev_Task.
  3. Configura IMAP para los workflows de email y el endpoint/relay de Telegram si vas a usar esas entradas.
  4. Comprueba que Repo_Analyze_Selected_Files está accesible como subworkflow.
  5. Lanza un scan con Activar y lanzar scan.
  6. Envía una petición manual desde el dashboard para validar la entrada humana.
  7. Valida que el último repo_scan pasa de started a completed.
  8. Verifica crecimiento de repo_findings, work_items, dev_tasks y agent_dispatches en el dashboard.

Borrar todo e inicializar de nuevo

Esto es destructivo. Antes de hacerlo, pausa la automatización desde este dashboard para evitar que n8n vuelva a poblar datos mientras limpias las tablas.

Orden recomendado: primero agent_dispatches, después dev_tasks, luego work_items, después repo_findings y por último repo_scans.

begin;
delete from public.agent_dispatches;
delete from public.dev_tasks;
delete from public.work_items;
delete from public.repo_findings;
delete from public.repo_scans;
commit;

Tras la limpieza, reactiva la automatización y lanza un scan nuevo. Si necesitas reiniciar solo una fase, limpia únicamente la tabla afectada y los estados derivados que dependan de ella.

Ejemplos de uso

  • Scan diario automático: deja la automatización activa y revisa por la mañana las alertas y nuevas dev tasks.
  • Petición desde dashboard: escribe “divide ControlPlane.tsx y baja el warning de chunks grandes” y deja que el arquitecto lo triagee.
  • Bug por email: un usuario reporta “la pantalla se queda en blanco al iniciar sesión” y el sistema lo transforma en work item, review y dev task.
  • Telegram audio: una nota de voz transcrita entra al mismo pipeline que un mensaje de texto.
  • Revisión después de un refactor: ejecuta Nuevo scan tras un merge grande y observa findings recientes.
  • Arranque de sprint técnico: filtra work items triaged y consume las dev tasks creadas como input del equipo.

Lectura rápida de métricas

  • open_scans alto: hay scans sin cerrar o una ejecución interrumpida.
  • review_queue alta: falta capacidad en Architect_Review.
  • dev_task_queue alta: hay work items triaged aún sin convertir.
  • pending_dev_tasks alta: el sistema genera más trabajo del que se está ejecutando.
  • prepared_dispatches alta: hay tareas listas para enviar a Codex / Antigravity.

Fallos frecuentes y qué mirar

  • Si un scan queda abierto, revisa el cierre de Repo_Analyze_Selected_Files y el contador de findings.
  • Si no aparecen work items nuevos, revisa deduplicación por source_fingerprint.
  • Si Telegram audio no entra, revisa si el payload aporta voice_file_url o una transcripción ya resuelta.
  • Si email no genera trabajo, revisa mailbox IMAP, filtros y si el correo cae en el buzón esperado.
  • Si el arquitecto falla, consulta error_message y los casos marcados como needs_info.
  • Si faltan dev tasks, confirma que el work item está en triaged con proposed_action = convert_to_dev_task.
  • Si no aparecen dispatches, revisa DevTasks_To_Antigravity y el estado pending de la dev task.

Acceso interno

Introduce el token del dashboard