Para desarrollo, QA, webs y servidores
GoTool lee tu proyecto entero —PHP, TypeScript, JavaScript, Go, SQL y lo de alrededor—, lo dibuja, lo prueba y te dice lo que va a fallar antes de subirlo. Y vigila su seguridad, en tu equipo y en el servidor: tu WordPress, tus contenedores, la máquina. Sin tocar tu código.
Un binario de unos 20 MB para Mac, Windows y Ubuntu, sin nada que instalar al lado · versión 0.49.1
Un programa que se lee tu proyecto como lo haría alguien que acaba de llegar —qué rutas tiene, qué pantallas, qué servicios, qué tablas y quién llama a quién— y como lo miraría quien quiere entrar: qué se ha cambiado sin que nadie lo sepa y qué está abierto. No es un editor más ni sustituye a tu CI: es lo que pasa entre los dos, y lo que pasa después.
gotool abre el IDE del proyecto: el dibujo, el código, los casos de uso, las pruebas, git y una terminal, también la de tus servidores, dentro de GoTool. Su 🛡 junta toda su seguridad: tu código, su configuración, tus librerías, tu Docker y tu WordPress. Y le contesta a Claude Code lo que pregunte del proyecto (gotool mcp).
gotool servidor vigila los proyectos y sus webs, sus WordPress, sus contenedores y la máquina donde corren. Abre los tickets solo cuando algo falla o cambia sin que nadie lo diga, y los reparte entre el equipo. Varios proyectos y varias personas, cada una con su acceso.
1 · Entender y probar
Lee el código sin ejecutarlo y sin instalar nada en el proyecto. Lo que saca lo guarda fuera de él.
Clases, funciones y lo que llama cada una. Symfony: rutas con #[Route], comandos, servicios, Doctrine. composer.json, su lock y vendor/.
React, Angular e Ionic (rutas, módulos, guards, componentes, servicios y sus llamadas a la API), Node y Capacitor. package.json, tsconfig y node_modules/.
Paquetes, tipos, métodos e interfaces, y quién las cumple. Las rutas de net/http, chi, gin, echo y fiber. go.mod y go.sum.
Las tablas que nombra el código y, si le das acceso, la base de datos de verdad: MySQL, PostgreSQL o Supabase, siempre en sólo lectura.
Los scripts de sh, el Dockerfile, compose, GitHub Actions y los .env (con las claves tapadas): quién llama a quién y qué variable usa cada fichero.
Pruebas: vitest, jest, mocha, playwright, phpunit, pest, go test y ng test. Calidad: phpstan, psalm, phpmd, phpcs, eslint, tsc, go vet, staticcheck y golangci-lint. Las que ya tenga el proyecto: no instala ninguna.
Todo desde el mismo sitio. Lo que ejecuta (pruebas, casos de uso, calidad) es lo que el proyecto ya tiene; lo demás, sólo lo lee.
Por dónde se entra (rutas, comandos, tareas), qué se ve y qué servicios y tablas hay detrás. A la izquierda lo que usa cada cosa; a la derecha, quién la usa. Doble clic y estás en su código.
Ejecuta una función con los datos que le des y enseña, al lado de cada línea, el valor de cada variable y por dónde ha pasado. En PHP, JavaScript/TypeScript y Go, con dobles para lo de fuera (la base de datos, una API).
Pasa las pruebas con la herramienta del proyecto, fichero a fichero, y guarda por dónde pasa cada una: sabes qué prueba toca qué línea y qué se queda sin probar.
Lo que dicen los ficheros de configuración contra lo que hay: la carpeta que falta, la plantilla que no existe, el paquete que no está. Con el porqué y la línea.
Si cada fichero pasa o no: errores de sus herramientas, complejidad, cobertura. Lo pedido, lo instalado, lo que tiene versión nueva y los fallos conocidos de cada librería (OSV).
La lee en sólo lectura, la guarda en DBML y la compara con el contrato o con una foto anterior. Dice qué tabla o columna usa el código y no existe.
gotool comprobar dice si un cambio puede subir: pruebas, calidad, dependencias, el plano y la seguridad. gotool push lo comprueba, pasa los casos de uso y, si todo sale bien, hace tu mismo git push; después sigue GitHub Actions paso a paso.
En el servidor de pruebas: la prueba que falla, el error del registro, el fichero cambiado a mano, la web que deja de contestar. Con su fichero y su línea; la extensión de Chrome y la de VS Code los llevan a donde trabajas.
Claude Code pregunta a GoTool lo que necesita del proyecto. Y gotool reparar pide a Claude el arreglo de un ticket en una copia aparte: pasa las pruebas y te deja el parche y el porqué. Tu código no cambia.
2 · Vigilar la seguridad
Las dos preguntas que GoTool se hace de cada WordPress, de cada contenedor y de cada máquina. La primera es si ya ha entrado alguien; la segunda, si la seguridad está tan floja que es cuestión de tiempo. Cada respuesta, con de dónde sale y qué hacer.
uploads/, mu-plugins nuevos, código de puerta trasera, y administradores nuevos o scripts metidos en las entradas (con su base de datos, sólo en lectura)..php, un .sh, un programa que no estaba./tmp, mineros, y conexiones que parecen un shell inverso.WP_DEBUG, APP_DEBUG, Django, Flask, Express), claves de ejemplo o en el código, CORS abierto.--privileged, con el socket de Docker dentro o sin límites; imágenes :latest.xmlrpc.php, debug.log, copias de wp-config.php, .git; cabeceras, https y TLS viejos.En el servidor, cada 15 minutos, y en tu equipo al abrir el 🛡 del proyecto. Las huellas oficiales de wordpress.org y los fallos de wpvulnerability.net, guardados para no depender de que contesten. También Bedrock.
Docker y Podman, por un intermediario de sólo lectura: cómo corre cada uno y lo que ha cambiado dentro. El Dockerfile y el compose, con la guía de contenedores; y las imágenes con trivy o grype si los tienes.
Puertos, cortafuegos, usuarios, keys, sudo, lo que arranca solo, el sistema al día y la escalada de privilegios. La primera vez, una foto para revisar; desde ahí, cada cambio es ticket. Cada hallazgo con su CWE y su técnica de MITRE ATT&CK.
El centinela aprende siete días lo normal de cada proceso y cada contenedor. Después, un destino nuevo es ticket; un shell o una herramienta de red que llama fuera, los puertos de minería o Tor, siempre alto. En WordPress, qué plugin hace cada llamada.
SQL montado a mano, XSS, el certificado sin comprobar, secretos en el código, con su CWE y su categoría OWASP. Y lo que dice cada proyecto de sí mismo: PHP, Symfony, Laravel, Node, Next, Django y Flask, cada regla con su fuente.
gotool npm ci y gotool composer install bajan las librerías en una carpeta aparte y sin ejecutar nada; miran malware, fallos conocidos y lo nuevo de cada versión, y sólo entonces pasan al proyecto.
Lo mismo en tu equipo que en el servidor: casi todos montan su Docker con su WordPress, lo prueban y lo suben. Mejor saberlo antes.
Una lista de fallos no arregla nada. GoTool la pone donde se ve, dice de quién es cada uno y comprueba que de verdad se ha arreglado.
En Inicio, cuántos fallos graves tiene cada proyecto, de tus servidores y de tu equipo. En la pestaña 🛡 Lo grave, la lista entera; en el 🛡 de cada proyecto, todo lo suyo.
Pendiente, hecho o finalizado. Quien lo arregla dice «hecho» y GoTool lo comprueba en su siguiente vuelta: si sigue ahí, vuelve a pendiente. Lo que es de esperar se cierra con su porqué.
Si usáis Jira Cloud, un fallo se crea como ticket desde el 🛡, sin claves ni IPs. Cuando Jira lo da por terminado, GoTool lo comprueba como siempre.
gotool comprobar y gotool push paran por un secreto que vas a subir, un WordPress tocado, código nuevo en un contenedor o el modo depuración encendido.
Entre escribir el código y que el CI/CD lo pase hay un hueco: entenderlo, probarlo y saber qué se rompe. Y después de subirlo hay otro: saber si alguien lo ha tocado. Los dos los llenan hoy personas a mano. GoTool se los da hechos.
Y todos miran lo mismo: el mismo dibujo, el mismo caso, el mismo fallo con su estado. Quien lo encuentra dice «está aquí»; quien lo arregla lo abre, lo ve y dice «hecho».
Hechas con proyectos de ejemplo: una tienda en Angular/Ionic, otra en Go y otra en PHP, y un WordPress de prueba tocado a propósito. Pulsa una para verla en grande.
Ninguna enseña código de nadie: son proyectos hechos para probar GoTool.
.env y las keys salen tapadas.Con un proyecto tuyo de prueba, en tu ordenador. No hace falta servidor.
Escríbenos abajo y te mandamos el de tu sistema (Mac, Windows o Ubuntu) con su SHA256. Es un fichero: no hay instalador.
Doble clic (o gotool en la terminal) y elige la carpeta del proyecto. Antes de nada te enseña su vistazo: qué hay, cuántas líneas y qué parece. Sólo lee.
Pulsa «Comenzar proyecto»: lo lee entero y lo dibuja. Sube de nivel para ver más y haz doble clic en cualquier caja para ir a su código.
En 🧪, «pasarlas»: usa la herramienta del proyecto y te dice cuáles pasan, cuáles no y por dónde pasa cada una.
Abre un servicio, pestaña «Casos de uso», dale unos datos y ▶. Cada línea con sus valores; lo de fuera lo dobla GoTool.
Abre el 🛡 del proyecto: su seguridad, con cada fallo y su estado. Y gotool comprobar: lo que pararía un push y lo que sólo avisa.
Con un proyecto de prueba o una copia, nunca contra producción: GoTool no cambia tu código, pero las pruebas y los casos de uso ejecutan el tuyo de verdad.
¿Quieres probarlo, tienes un equipo, unos WordPress o unos servidores que vigilar, o una pregunta? Escríbenos y te contestamos desde info@gotool.run.
Gracias: lo hemos recibido. Te contestamos desde info@gotool.run.
No se ha podido enviar. Escríbenos directamente a info@gotool.run.
Falta algo: tu nombre, un correo válido y el mensaje.