El DOM Explorer y el Code Graph muestran toda la base de código como un grafo de dependencias interactivo y, en proyectos web, los elementos DOM reales conectados con el comportamiento que desencadenan.

DOM Explorer & Code Graph

El grafo de dependencias del código

El Code Graph visualiza los archivos del proyecto como nodos conectados por imports. Los archivos se agrupan automáticamente en comunidades según los patrones de importación, de modo que los límites naturales de los módulos se ven de un vistazo sin dibujarlos a mano.

• God nodes — archivos con un número desproporcionadamente alto de dependencias, buenos candidatos para dividirse.
• Dead code — archivos sin aristas entrantes (no importados por nada), que probablemente pueden eliminarse con seguridad.
• Dependencias circulares — grupos de archivos que se importan entre sí, lo que complica la refactorización.

Qué son los atributos data-aitm

En proyectos web, AITM mapea además los elementos DOM reales mediante un atributo data-aitm="MODULE.ELEMENT" en cada elemento interactivo (botón, campo de entrada, contenedor). Este código vincula el elemento visible con su comportamiento en el código — la función manejadora, la ruta de destino o la llamada a API que desencadena — y con el Behavioral Contract que documenta ese comportamiento.

Cadenas de clic a efecto

Cuando un elemento con data-aitm lleva también data-action, AITM registra qué efecto causa hacer clic en él — abrir un modal, navegar, llamar a una API o emitir un evento de socket. Estas cadenas "clic → efecto" forman un mapa aparte junto al grafo de dependencias de archivos, y la IA las lee antes de tocar un elemento de la interfaz para comprender el radio de impacto de un cambio antes de realizarlo.

Selectores E2E con autorreparación

Como cada código data-aitm se almacena en la base de datos junto con su selector DOM actual, las pruebas E2E pueden localizar un elemento por su código estable en lugar de un frágil selector CSS/XPath. Cuando la estructura del DOM cambia, el mapa se vuelve a resolver automáticamente en la siguiente ejecución del Pipeline, de modo que las pruebas no quedan rotas solo porque se renombró una clase o se movió una etiqueta.