第 12

重建你的环境，而不是依赖记忆

最有价值的自动化不一定是业务任务。有时真正重要的是：来到新的托管账户，放下一个小 Core，运行一份明确的流程，然后恢复你信任的工具和工作习惯。

你的环境由方案和状态共同组成

已安装模块、界面包、启动脚本和偏好设置描述终端如何工作。项目文件与数据库属于另一层状态。把这两类东西分开，会让迁移和恢复简单很多。

写清楚哪些内容应该自动重建，哪些必须从备份恢复。安装方案应描述工具和安全默认值，而不是偷偷把应用数据或凭据带到新主机。

编写方案之前，先盘点你现在真正使用的环境

core 给出紧凑的 Core、UI 与模块概览，install -l 列出已安装模块和包，include 显示界面包的存储状态，upgrade -c 则在不写入的情况下检查版本。

这份清单区分“我好像需要这些工具”和真正可复现的工具清单。把已经没用的习惯删掉，再考虑是否让安装自动化永久保留它。

core

install -l

include

upgrade -c

`setup.lil` 是一次性引导安装，不是永久启动脚本

当前 Core 会发现 lil.php 旁边的普通 setup.lil，需要时在授权后运行，并且只有所有命令都成功才删除。如果完整 Installer 不存在，Core 可以先取得它，再继续原来的安装操作。

让安装过程保持明确。批量install 足够紧凑、也容易阅读；如果你明确需要锁定方案，可以使用精确 -v 发布版本。密码、私钥和项目专用数据库凭据不应该写进这个文件。

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

`autoload.lil` 用于每次会话开始时的小型重复动作

run 在每个已授权会话中检查一次 autoload.lil，而且不会删除它。因此它适合轻量检查或需要重复的环境准备，而不是一次性安装。

upgrade -auto check 是一个好例子：它在 autoload.lil 中管理一个小配置块，每个会话检查一次更新。自动更新是更强的策略，仍需主动启用；重要环境往往更适合先检查、审查，再更新。

upgrade -auto check

upgrade -info

可复现意味着知道自己选择了哪种自由度

install <mod> 安装当前兼容的公开版本；install <mod> -v <ver> 请求一个明确的已发布版本号。两种形式都会继续遵守当前 Core 代际和模块依赖关系。

第一代早期里程碑仅作为历史记录保留，不再作为安装目标；当前版本是受支持的安装点。从下一次正式发布开始，带版本号的正式版本将继续作为精确安装目标保留，除非某个版本被明确撤回。

install hash -i

install hash -v 1.1.3

浏览器界面是包层，不是命令运行环境

include 管理 lil、hotkeys、code 等可组合 CSS/JavaScript 包。会话模式是临时的；-s 会在 .lil.css 和 .lil.js 中创建持久组合。

迁移主机时，这种分层很有价值：即使喜欢的 UI 包没有恢复，PHP 命令模块仍可能完全正确。先恢复功能，再恢复外观。如果界面层出问题，kill -include 只重置这一层，不会删除 Core。

include -l

include lil -i

include -lil -s

安装方案没有在干净环境测试过，就还没有完成

最好的证明是全新安装：部署全新 Core，运行流程，然后用 core、install -l、upgrade -c 与你想复现的环境进行比较。

这个测试会暴露隐性依赖——几个月前手工安装的命令、忘记记录的界面包，或只在某个主机上存在的扩展。可复现性不是宣称出来的，而是在重建中被验证的。