Conecta tu código: cambia, revisa, aprueba, publica y revierte un código real

Escribe el nombre del proyecto, luego pega la dirección del repositorio (desde el botón verde Code de GitHub) y la rama desde la que se ejecuta el sitio, normalmente main. Elige cómo accede aiKit. Token de GitHub: un token de grano fino que creas en GitHub solo para este repositorio, con Contents en Read and write; va con una dirección https://. Clave de despliegue: un par de claves creado solo para este repositorio, cuya mitad pública agregas en Settings, Deploy keys del repositorio, con Allow write access marcado; va con una dirección git@. Repositorio público: solo lectura, así que los cambios aprobados no tendrían dónde guardarse; úsalo solo para explorar.

Tú pegas el token o la clave tú mismo. Se guarda cifrado en el motor de aiKit y nunca se vuelve a mostrar, a nadie. La página solo muestra una huella digital. Conectar el repositorio copia el código al motor y detecta qué tipo de proyecto es (Laravel, JavaScript o archivos estáticos). Nada del repositorio cambia.

También puedes conectar un proyecto que ya tienes: en su pestaña Alojamiento, el propietario ve Conecta tu código.

Tu propio servidor: el sitio se queda exactamente donde está. Escribe la dirección del servidor, el puerto SSH (normalmente 22), el usuario que usa aiKit (los pasos de configuración crean uno llamado aikit), la carpeta del sitio (para un sitio de Laravel Forge, /home/forge/tu-sitio.com), el comando de despliegue que el sitio ya usa (normalmente bash scripts/deploy.sh) y las páginas que deben responder después de cada publicación, una dirección completa por línea. Pega la clave privada del usuario del servidor (creada en el paso 1 de la configuración). Guarda y comprueba la conexión.

La primera vez que aiKit llega al servidor, muestra la huella digital del servidor y pregunta ¿Es este tu servidor? Compárala con lo que el servidor mostró en el paso 6 de la configuración. Pulsa Coincide solo si son idénticas; luego pulsa Conectar. A partir de entonces, un servidor distinto en esa dirección será rechazado. Cuando la comprobación pasa, la página indica qué versión está ejecutando el servidor en este momento.

Alojamiento de aiKit: aiKit compila y sirve el código por sí mismo, con una dirección gratuita para empezar. Ideal para sitios y front ends.

En Configuración del servidor, la página muestra ocho pasos para copiar y pegar, ya completados con tus valores; cada uno tiene un botón Copiar. Los pasos 1 y 8 se ejecutan en tu computadora, y los pasos 2 a 7 en el servidor, como usuario con sudo.

Lo que crean: un usuario sin contraseña y sin shell (paso 2). Su única clave está restringida a un pequeño script de control (pasos 3 y 5), que acepta exactamente dos comandos: status (qué versión se ejecuta y si el sitio está en modo de mantenimiento) y deploy de un commit exacto. Deploy se ejecuta como el usuario propio del sitio mediante una regla de sudo, comprueba que la rama en GitHub apunta a ese commit exacto y luego ejecuta tu script de despliegue existente sin cambios. El paso 4 establece permisos de carpeta para que el usuario solo llegue a la carpeta del sitio: no a los otros sitios de la misma carpeta personal, y nunca a .env. El paso 7 prueba todo y dice qué debes ver en cada línea, y el paso 8 prueba el usuario desde tu computadora antes de pegar su clave en aiKit.

Si un servidor aloja también otros negocios, aquí está la clave: el usuario de aiKit solo puede publicar este sitio y nada más. El código del sitio sigue ejecutándose como el usuario del sitio, igual que cuando publicas desde GitHub por tu cuenta, por eso cada cambio se revisa y los archivos delicados están protegidos.

Cuatro tarjetas arriba. Repositorio: el repositorio, la rama, el commit más reciente y el tipo de proyecto. Se ejecuta en: tu propio servidor (con el usuario y la última vez que respondió) o el alojamiento de aiKit. Versión publicada: la versión que ejecuta el sitio, quién la hizo y cuándo. Páginas: cuántas de las páginas que deben responder respondieron en la última revisión; Revisar ahora las visita de nuevo, y cualquier página que no respondió aparece debajo con lo que devolvió.

Debajo de las tarjetas: Solicitar un cambio (o el cambio que está abierto en este momento), Versiones, Registro de cambios, Archivos protegidos y, para el propietario, Conexión.

Escribe qué debe cambiar, indicando la página y lo que quieres ver, y pulsa Hacer el cambio. La tarjeta se convierte en Cambio #1 con progreso en vivo: obtener el código más reciente, los archivos que la IA lee y edita, y luego cada comprobación. La IA solo edita archivos; no ejecuta comandos. Hay un cambio abierto a la vez por proyecto, y cada solicitud cuenta para el límite de IA del proyecto.

Cuando termina, ves: la solicitud y quién la pidió; lo que la IA dice que hizo; las comprobaciones, cada una con una marca de verificación o una cruz y su resultado; botones Vista previa para las páginas revisadas; los archivos con Agregado, Cambiado o Eliminado, y una etiqueta Protegido cuando corresponde; y las diferencias, archivo por archivo, en verde para las líneas agregadas y en rojo para las líneas eliminadas. Esas diferencias son exactamente lo que se confirmará y publicará.

Aprobar e publicar (propietarios y creadores) guarda el cambio en la rama con un mensaje que indica quién lo pidió y quién lo aprobó, lo envía (nunca forzado: si alguien envió cambios mientras tanto, el cambio se marca como Desactualizado y no se publica nada), lo publica y revisa las páginas. Descartar elimina el cambio tras una confirmación; no se publicó nada. Los revisores pueden leerlo todo, pero no pueden pulsar ninguno de los dos.

Después de que pasen las comprobaciones es un ajuste en Conexión, Comprobaciones y revisión. Esperar aprobación es la opción predeterminada. Publicar automáticamente publica un cambio por sí solo solo cuando todas las comprobaciones pasaron y no cambió ningún archivo protegido; en cualquier otro caso, sigue esperando.

En un proyecto de Laravel, las comprobaciones son: cada archivo PHP modificado se analiza correctamente (php -l); cada vista Blade se compila (php artisan view:cache); el front end se compila (npm run build); y la aplicación se inicia en una prueba con una base de datos SQLite desechable, migrada y con datos de ejemplo del repositorio, donde cada página que la prueba debe abrir en Páginas responde 200. Se ejecutan en el motor de aiKit, nunca en tu servidor ni contra tu base de datos en vivo. El archivo .env del proyecto nunca se copia ni se lee; la prueba usa ajustes desechables.

Una comprobación fallida bloquea Aprobar. Solo el propietario puede marcar Publicar aunque las comprobaciones hayan fallado, en el caso de una comprobación que falló por un motivo que no afecta al sitio en vivo.

Vista previa abre la aplicación modificada de la prueba en una pestaña nueva, con datos de prueba y formularios desactivados. Se detiene 15 minutos después de su último uso y termina cuando el cambio se aprueba o se descarta.

La IA no toca los archivos protegidos. La lista incluye, para empezar: migraciones que ya se ejecutaron en el sitio en vivo (todas las migraciones de la versión en vivo, ya que cada publicación las ejecuta), nuevas migraciones (cambiarían la base de datos en vivo en la siguiente publicación), el script de publicación y los archivos de dependencias (composer.json, composer.lock, package.json, package-lock.json). Cada entrada indica el motivo. El propietario añade un archivo o carpeta (config/** significa todo lo que hay dentro de config) con un motivo, elimina entradas y pulsa Guardar archivos protegidos.

Para cambiar un archivo protegido a propósito, el propietario marca Permitir archivos protegidos para esta solicitud. El cambio entonces muestra qué archivos protegidos tocó, y solo el propietario puede aprobarlo, tras marcar Sí, publicar los cambios en archivos protegidos. Un creador que no marque nada no tiene acceso a archivos protegidos.

Los archivos .env, las claves privadas y auth.json están en un nivel más estricto: nunca se leen, nunca se cambian, nunca forman parte de un diff, y nadie puede desactivar esto.

La primera vez que aiKit llega a tu servidor, registra lo que el servidor ejecuta como la versión 1, Antes de aiKit, para que incluso la primera publicación de aiKit pueda revertirse. Después, cada publicación es una versión numerada: Cambio (un cambio aprobado; su nombre abre ese cambio), Volver a publicar o Reversión, con su confirmación, quién la hizo, su estado (En vivo, Anterior, En vivo pero con páginas fallando, Publicación fallida), cuántas páginas respondieron y el registro de publicación. aiKit guarda las últimas 5.

Publicar el código más reciente publica lo que sea más nuevo en la rama en este momento, tras una confirmación, por ejemplo cuando alguien envió una corrección directamente.

Revertir a esta, en una versión anterior, crea una confirmación nueva cuyos archivos son exactamente los de esa versión, la envía y la publica de la forma habitual, y después revisa las páginas. El historial nunca se reescribe, así que la reversión también puede revertirse.

Cada solicitud con su número, la petición, quién la pidió, quién la aprobó o descartó, cuándo y en qué estado está. Pulsa una fila para abrir ese cambio con sus comprobaciones y su diff; la dirección incluye ?change=<id>, así que puedes compartir el enlace con tu equipo.