Parte 12

Reconstruya su entorno, no su memoria

La automatización más valiosa no siempre es una tarea de negocio. A veces es poder llegar a una cuenta de alojamiento nueva, colocar un Core pequeño, ejecutar una receta explícita y recuperar las herramientas y hábitos en los que confía.

Su entorno es una receta más estado

Los módulos instalados, paquetes de interfaz, scripts de inicio y preferencias describen cómo se comporta el terminal. Los archivos del proyecto y bases de datos son otra capa de estado. Separar ambas ideas facilita mucho migración y recuperación.

Anote qué debe recrearse automáticamente y qué debe restaurarse desde una copia de seguridad. Una receta de instalación describe herramientas y valores predeterminados seguros; no debe arrastrar datos de la aplicación ni credenciales a un servidor nuevo.

Antes de escribir la receta, inspeccione el entorno que ya usa

core muestra la imagen compacta de Core/UI/módulos, install -l lista módulos y paquetes instalados, include muestra el almacenamiento de paquetes de interfaz y upgrade -c comprueba versiones sin escribir.

Este inventario separa “creo que necesito estas herramientas” de una lista realmente reproducible. Elimine hábitos obsoletos antes de fijarlos de forma permanente en la automatización de instalación.

core

install -l

include

upgrade -c

`setup.lil` es un bootstrap de una sola vez, no un script de inicio permanente

El Core actual detecta un setup.lil regular junto a lil.php, lo ejecuta tras la autorización cuando corresponde y solo lo elimina cuando todos los statements tienen éxito. Si falta el Installer completo, Core puede obtenerlo y reanudar la operación original de instalación.

Mantenga explícita la preparación del entorno. Una instalación múltiple con install es compacta y legible; una versión exacta con -v sirve cuando necesita reproducir deliberadamente una configuración concreta. No guarde aquí contraseñas, claves privadas ni credenciales de bases de datos del proyecto.

install help history upgrade dir pwd md mf edit find stat hash run

`autoload.lil` sirve para pequeñas acciones recurrentes al iniciar sesión

run comprueba autoload.lil una vez por sesión autorizada y no lo elimina. Por eso sirve para checks ligeros o preparación del entorno que debe repetirse, no para instalación de una sola vez.

upgrade -auto check es un buen ejemplo: administra un pequeño bloque en autoload.lil y revisa actualizaciones una vez por sesión. El update automático es una política más fuerte y sigue siendo opt-in; en entornos importantes suele ser mejor comprobar, revisar y después actualizar.

upgrade -auto check

upgrade -info

Reproducibilidad significa saber qué libertad eligió

install <mod> selecciona la versión pública compatible actual; install <mod> -v <ver> solicita un número publicado concreto. Ambas formas siguen respetando la generación de Core activa y las dependencias del módulo.

Los hitos anteriores de la generación 1 se conservan únicamente como historial y ya no son objetivos de instalación. La versión compatible es la actual. A partir del próximo lanzamiento, las versiones numeradas se conservarán como objetivos exactos mientras no se retire expresamente una versión.

install hash -i

install hash -v 1.1.3

La interfaz del navegador es una capa de paquetes, no el entorno de ejecución de comandos

include gestiona paquetes componibles de CSS/JavaScript como lil, hotkeys y code. El modo de sesión es temporal; -s crea composición persistente en .lil.css y .lil.js.

La separación ayuda al mover servidores: los módulos PHP pueden funcionar correctamente aunque falte su UI preferida. Recupere primero la funcionalidad y luego la presentación. Si la capa de interfaz se confunde, kill -include restablece solo esa capa sin borrar Core.

include -l

include lil -i

include -lil -s

Una receta de instalación no está terminada hasta probarla en un entorno desechable

La mejor prueba es una instalación limpia: despliegue un Core nuevo, ejecute la receta y compare core, install -l y upgrade -c con el entorno que pretendía reproducir.

Así aparecen dependencias invisibles: un comando instalado manualmente meses atrás, un paquete de interfaz olvidado o una extensión disponible en un servidor y no en otro. La reproducibilidad se descubre reconstruyendo, no declarando.