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.

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

Repo scans

Actividad reciente

ID Estado Findings Duración Inicio

Triage

Work items recientes

ID Título Estado Sev.

Entrega

Dev tasks recientes

ID Título Estado Prioridad

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. Convierte findings nuevos en work_items sin duplicados semánticos.
  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. 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: entrada manual para bugs, ideas o tickets externos.

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. Si el sistema está parado, pulsa Activar automatización.
  3. Para forzar ciclo completo, pulsa Activar y lanzar scan.
  4. Para abrir solo un scan manual, usa Nuevo scan.
  5. Vigila el panel Workflow Health y las tablas de actividad reciente.
  6. 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. Comprueba que Repo_Analyze_Selected_Files está accesible como subworkflow.
  4. Lanza un scan con Activar y lanzar scan.
  5. Valida que el último repo_scan pasa de started a completed.
  6. Verifica crecimiento de repo_findings, work_items y dev_tasks 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 dev_tasks, después work_items, luego repo_findings y por último repo_scans. 

begin;
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.
  • Revisión después de un refactor: ejecuta Nuevo scan tras un merge grande y observa findings recientes.
  • Triage manual: usa Ingest_Work_Item cuando el origen no viene del repo, por ejemplo un bug de soporte.
  • 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.

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 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.

Acceso interno

Introduce el token del dashboard