📃 docs: 完成重设计，准备开始实现新env

statements/2.md

@@ -0,0 +1,16 @@
+1. 用--modules
+2. 扁平结构
+3. 作为独立模块默认启用（因为有可能后续项目稳定后会把所有程序编译为无需额外环境依赖的二进制可执行文件，甚至是使用rust重写程序）
+4. 参数用逗号分隔
+
+我的新想法：
+
+1. 弃用check，仅保留ensure，
+    - 因为不论是有明确的配置文件指定了具体环境模块配置的情况，
+    - 或者是单独使用模块参数忽略掉配置是否启用，
+    - 都说明有明确的对指定模块的使用意图，
+    - 我希望只要执行了就默认为预期是目标环境可用，
+    - 所以仅保留ensure，若检测到不可用就自动尝试修复，修复成功后可用正常输出反馈告知LLM环境可用即可
+2. 但是使用list时依然显示其模块能力情况，有些模块可能没办法支持ensure，
+3. 只有使用--all选项时，不进行ensure操作，仅检测，
+    - 使用all时对所有已启用的模块仅执行check操作，报告其可用性

statements/3.md

@@ -0,0 +1,10 @@
+1. 默认all的范围是所有配置文件中已配置为启用的模块
+    - 若环境配置文件中没有配置启用列表，则输出警告，然后对所有aid env支持的可用模块进行检测（即使环境配置文件中没有任何相关配置）
+    - 若环境配置文件中设置了启用列表，想要对所有模块进行检测就必须先用list获取支持的模型的信息，然后用指定模块列表参数执行检测
+2. 若模块ensure失败，或是仅支持check无法ensure却检测到环境不可用
+    - 如果该模块是环境配置文件中指定了启用的模块，输出错误，应停下并报告用户需要解决环境问题
+    - 如果是没有在启用列表中的，不论是all参数还是指定模块参数触发的，都只输出警告信息
+3. 使用指定模块参数时，不需要考虑是否配置启用，都执行即可（不过输出的是警告还是错误取决于是否启用）
+    - 所以环境检测模块要考虑到仅有自己的模块名可知的情况，真实配置不可知全靠检测，
+        - 比如gcc、java、python、flutter、android这样的，看命令是否可用，还有一些相关的环境变量是否已正确配置即可
+        - 但如果是py的虚拟环境这种必须指定虚拟环境目录路径的，nodejs这种要先在工作目录（有些项目中需要运行npm但不在项目根目录而是在某个子目录下，此时没有具体目录路径无法检测）做了npm install有了node_modules才能正常运行的，在没有具体配置数据（指该模块独立配置数据例如[env.venv]而非该模块是否启用）但指定了其模块进行check/ensure时，应输出警告然后不执行检测等任何其他该模块行为，