Rebuild your environment, not your memory
The most valuable automation is not always a business task. Sometimes it is the ability to arrive at a new hosting account, place a small Core, run one explicit recipe and recover the tools and habits you trust.
Your environment is a recipe plus state
Installed modules, interface packages, startup scripts and preferences describe how the terminal behaves. Project files and databases are a different layer of state. Keeping those ideas separate makes migration and recovery much easier.
Write down what must be recreated automatically and what must be restored from backup. A setup recipe should describe tools and safe defaults; it should not smuggle application data or credentials into a new host.
Before writing a recipe, inspect the environment you already use
This inventory is the difference between “I think I need these tools” and a reproducible bill of materials. Remove obsolete habits before you preserve them in installation automation.
coreinstall -lincludeupgrade -c`setup.lil` is a one-time bootstrap, not a permanent startup script
Current Core notices a regular setup.lil beside lil.php, runs it after authorization when needed, and removes it only after every statement succeeds. If the full Installer is not present, Core can fetch it and resume the original install operation.
Keep setup explicit. Installing several modules in one
install help history upgrade dir pwd md mf edit find stat hash run`autoload.lil` is for small recurring session-start actions
autoload.lil once per authorized session and does not delete it. That makes it suitable for lightweight checks or environment preparation that should repeat, not for one-time installation.
autoload.lil and checks updates once per session. Automatic update is a stronger policy and remains opt-in; important environments are often better served by check first, review, then update.
upgrade -auto checkupgrade -infoReproducibility means knowing which freedom you chose
Earlier generation-1 milestones shown in History are reference-only and are no longer installation targets. The current release is the supported target. From the next published release onward, numbered releases are intended to remain available as exact targets unless a release is explicitly withdrawn.
install hash -iinstall hash -v 1.1.3The browser interface is a package layer, not the command runtime
hotkeys and .lil.css and .lil.js composition.
This separation is valuable when moving hosts: PHP command modules can be correct even if your preferred UI package is absent. Rebuild functionality first, then presentation. If the interface layer becomes confused,
include -linclude lil -iinclude -lil -sA setup recipe is not finished until you test it somewhere disposable
The best proof is a clean installation: deploy a fresh Core, run the recipe, then compare
Testing the recipe catches invisible dependencies — the command you installed manually months ago, the interface package you forgot about, or the extension available on one host but not another. Reproducibility is discovered by rebuilding, not by declaring.
coreinstall -lupgrade -cKeep this as a script
This is a deliberately small setup.lil. Place it beside a fresh lil.php when you want Core to install this toolset once. Core removes setup.lil only after complete success, so a failed setup remains inspectable and retryable.
#lil
install help history upgrade dir pwd md mf edit find stat hash run