Edición en Markdown

AI-translated from English; not yet reviewed by a fluent editor.

# Inspeccionar el comportamiento de una aplicación Electron con REA

> REA traza módulos y límites de Electron en una aplicación local. Esta guía muestra cómo seguir una función a partir de pruebas y comprobar su comportamiento por separado.

By BIG CHANGE Editorial

Published: 2026-10-14T04:55:21.558Z
Updated: 2026-10-14T04:55:21.558Z
Canonical: https://bigchange.ai/blog/rea-static-electron-app-inspection-guide

![Conceptual charcoal illustration of an external storage drive beside a desktop monitor showing unlabeled file-tree and code-like lines.](https://bigchange.ai/api/media/file/rea-local-artifact-inspection-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual REA interface, application finding or runtime result is depicted.

REA puede trazar una aplicación JavaScript o Electron local a partir de archivos que tengas autorización para inspeccionar, aunque no dispongas de su árbol de código fuente. El resultado útil es una cadena de evidencias sobre un comportamiento: qué módulo lo expone, dónde una llamada cruza el límite entre procesos y qué partes aún requieren una comprobación aparte. Esta guía usa la [documentación actual del proyecto REA](https://github.com/morluto/rea/blob/main/README.md), revisada el 14 de octubre de 2026. BIG CHANGE no ejecutó REA en ninguna aplicación.

## El gran cambio

- **Qué cambió:** REA proporciona a un agente de programación un mapa estructurado de módulos, importaciones, mapas de fuentes, rutas e IPC de Electron a partir de un directorio de la aplicación o un ASAR suministrado. Cada hallazgo puede enlazar con los archivos que lo produjeron.
- **Por qué importa:** Un desarrollador que investiga una función puede seguir una API con nombre o un canal IPC en la aplicación empaquetada antes de decidir qué revisar manualmente. Así la pregunta es más acotada y las pruebas resultan más fáciles de comprobar.
- **Qué conviene vigilar:** Las rutas estáticas son candidatas, no pruebas de que la aplicación las siga durante el uso. Una afirmación sobre un comportamiento concreto aún requiere una observación o prueba independiente en el objetivo autorizado.

## Antes de empezar

Este recorrido está dirigido a quien posee una aplicación JavaScript o Electron local, o tiene permiso para inspeccionarla. Necesitas el directorio de la aplicación extraído o su archivo `app.asar` y una ruta absoluta. El [manifiesto del paquete](https://github.com/morluto/rea/blob/main/package.json) indica `rea-agents` versión **6.4.0** y requiere Node.js 22.19 o posterior en la rama 22.x, 24.11 o posterior en la 24.x, o la versión 26 o posterior. También hace falta npm. En Linux, el análisis estático de JavaScript/Electron de REA requiere un proceso compatible con procps `ps` de REA `PATH` para comprobar la propiedad de procesos, como explica su [guía de instalación](https://github.com/morluto/rea/blob/main/docs/installation.md#linux-owned-process-prerequisite). Son requisitos del host de REA, distintos de los que pueda necesitar la aplicación objetivo.

El flujo estático de JavaScript no requiere Hopper, Ghidra, IDA, un navegador ni un proceso Electron en ejecución. Esas herramientas pertenecen a otros flujos de REA. Comprueba que tienes permiso para inspeccionar el objetivo y conserva una copia de los archivos originales para poder identificar exactamente qué artefacto produjo cada resultado. Usa el [`morluto/rea` repositorio oficial](https://github.com/morluto/rea) o el paquete npm enlazado desde él; un repositorio con nombre parecido no acredita su procedencia.

## 1. Configurar REA o usar la CLI puntual

Para un agente de programación conectado, el [comando de configuración documentado](https://github.com/morluto/rea/blob/main/README.md#quick-start) es:

```sh
npx rea-agents setup
```

Revisa los cambios que propone para la configuración del agente, aprueba los que quieras y reinícialo. Si solo necesitas inspeccionar desde un terminal, el comando documentado siguiente invoca el paquete para esa ejecución. `@latest` selecciona la versión vigente cuando lo ejecutas; registra la versión resuelta junto con las pruebas porque los detalles de salida pueden variar. La versión 6.4.0 indicada arriba es la que mostraba el manifiesto al revisar este artículo el 14 de octubre.

## 2. Analizar los archivos suministrados

Sustituye la ruta de ejemplo por la ruta absoluta de la carpeta autorizada de la aplicación o de su ASAR:

```sh
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --json > app-evidence.json
```

La [guía de la CLI](https://github.com/morluto/rea/blob/main/docs/cli.md) advierte que la Evidence completa puede ser muy extensa. Guárdala en un archivo y después consulta un resumen o la vista de un módulo elegido. Evita pegar todo el resultado en un prompt. Si el comando falla, conserva el error y la ruta objetivo para diagnosticarlo; un código de salida cero también puede coincidir con cobertura parcial, avisos o hallazgos sin resolver. En Windows, el README muestra una ruta como `"D:/apps/example"`.

La [referencia de reconstrucción de artefactos](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) indica que esta operación lee los archivos seleccionados como datos sin ejecutar la aplicación. Inventaría las rutas y huellas de los artefactos, analiza el JavaScript y TypeScript disponible y señala posibles puntos de entrada, importaciones, mapas de fuentes, rutas, endpoints de red, enlaces entre preload y renderer de Electron, `contextBridge` API, llamadas y manejadores IPC, y solicitudes de complementos nativos. El resultado esperado es un registro Evidence con un grafo, un resumen estático de Electron, cobertura y limitaciones. Un `.node` es una relación que hay que inspeccionar, no una decodificación de ese módulo nativo.

## 3. Seguir una función concreta

Elige una función cuyo nombre puedas localizar, como una acción de menú o un método de API expuesto. Anota su nombre visible para el usuario y busca en el resultado de REA el módulo correspondiente, el canal IPC literal o la ruta. Sigue las ubicaciones de código en orden: llamada del renderer o la página, puente preload, transmisión IPC, manejador correspondiente del proceso principal y luego la operación de archivo o servicio que invoca. El [ejemplo CSV de Electron](https://rea.tools/guides/javascript/) de REA muestra este patrón con `notes.exportCsv()` , el canal `notes:export` y un escritor del proceso principal. Esos nombres pertenecen a la aplicación de ejemplo; la tuya tendrá otros.

Para cada enlace, registra la huella del artefacto, ruta, ubicación y qué muestra realmente el código. Distingue un canal literal asociado a un manejador de uno calculado o una asociación ambigua. Revisa los campos de cobertura y limitaciones antes de considerar ausente un módulo o manejador. REA advierte que archivos mal formados o no disponibles, bytes auxiliares de ASAR ausentes, expresiones sin resolver y análisis acotados pueden dejar relaciones desconocidas. Un mapa de fuentes puede revelar nombres del código original, pero la herramienta no promete recuperar el árbol fuente original.

## 4. Comprobar el comportamiento de forma independiente

Formula una afirmación falsable a partir de la ruta estática, por ejemplo: «esta acción invoca este canal y el manejador escribe este tipo de archivo». Después, en un entorno de prueba aprobado, realiza solo esa acción y observa el resultado directamente: el archivo creado, un estado modificado o una traza recogida con tus propios permisos. Registra la versión de la aplicación, la huella del artefacto, los pasos y el resultado observado. Si no tienes autorización para ejecutar la aplicación, limita la afirmación a la ruta de código estática. El ejemplo de REA dice expresamente que la ruta inferida puede comprobarse con una captura en ejecución; el grafo estático por sí solo no muestra qué rama se ejecutó.

La comprobación es satisfactoria cuando otro desarrollador puede localizar los mismos puntos del código, ver los límites de la asociación estática y repetir tu verificación acotada. Un comando de análisis exitoso por sí solo no verifica el comportamiento en ejecución ni demuestra una reimplementación fiel de la aplicación.

## Si el resultado está incompleto

Primero comprueba que la ruta apunta a un directorio extraído completo o a un ASAR y que los `.asar.unpacked` archivos complementarios necesarios están presentes. Revisa la cobertura y los diagnósticos de REA; una fuente ausente o fallida es desconocida, no un resultado negativo. Para una aplicación grande, la [referencia](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) documenta selecciones `--source-path` exactas, aunque los archivos no seleccionados quedan fuera del análisis. Si una coincidencia literal de IPC es ambigua o el canal se calcula, inspecciona los archivos citados y acota la pregunta. Si la ambigüedad continúa, consérvala en las notas finales.

El código de REA tiene licencia MIT, pero el software objetivo y cualquier motor externo de análisis mantienen sus propias licencias y condiciones. El análisis estático procesa los archivos objetivo localmente. Si envías los hallazgos de REA a un agente de programación, el proveedor del modelo tiene su propia política de datos; evita transmitir secretos o resultados patentados hasta que tu organización autorice ese uso. Comprueba las condiciones y los costes del agente y de cualquier motor opcional. El procedimiento y la versión del paquete se revisaron el **14 de octubre de 2026** y se basan en la documentación.

## Sources

- [README de REA](https://github.com/morluto/rea/blob/main/README.md) — Identidad oficial, configuración, comando de análisis JS, salida, requisitos de Node y ps en Linux, procesamiento local y límites de privacidad.
- [Manifiesto del paquete REA](https://github.com/morluto/rea/blob/main/package.json) — rea-agents 6.4.0 y rango requerido de Node.
- [Guía de análisis de JavaScript y Electron](https://rea.tools/guides/javascript/) — Ejemplo práctico para seguir renderer, preload e IPC hasta un manejador del proceso principal; los registros de ejemplo son de REA 4.1.0.
- [Reconstrucción de artefactos JavaScript](https://github.com/morluto/rea/blob/main/docs/javascript-artifact-reconstruction.md) — Alcance estático, selección de fuentes, integridad, cobertura y semántica de rutas sin resolver.
- [CLI y Evidence](https://github.com/morluto/rea/blob/main/docs/cli.md) — Comando CLI, gran volumen de Evidence y límites de los códigos de salida.
- [Guía de instalación de REA](https://github.com/morluto/rea/blob/main/docs/installation.md) — El requisito de ps compatible con procps en Linux incluye expresamente el análisis estático de JavaScript/Electron e incluye recomendaciones de recuperación.