AUR CLI 路线图

现在的 app.py 像个临时的调试开关——能用，但散。我们的想法是把它升级成一个正式的家伙，名字就叫 aur，统一管所有跟 app 打交道的活儿。

挼挼如是说

aur 是给 app 开发者用的瑞士军刀——开发的时候拿它调试、测试，分发的时候拿它打包、安装。它不碰 kernel 的事，那归别人管。

它要干什么

aur 就两摊事儿：

• 开发期：扫描应用、按配置加载、调命令、注入事件、手动走 tick
• 分发期：打包 .aur、安装应用、卸载应用、初始化配置

命名约定

一个名字用到底：

• CLI 叫 aur
• 包后缀叫 .aur
• 文档、帮助文案一股脑全对齐

它和现状的关系

好消息是——很多地基已经打好了，不用重来一遍：

• 目录扫描和 app 实例化已经能跑
• app 级配置管理已经有了
• 独立测试入口 app.py 已经在干活了
• 每个 app 都有自己的 README.md 和 config.example.json

所以我们不是要"推翻重写"，而是"收口整理"。

设计边界

aur 只管应用层和控制面——不碰大脑。

它该干的

• 知道有哪些可用 app
• 看一眼哪个 app 是开着的
• 直接调某个 app 的命令
• 塞一个测试事件进去
• 手动跑几次 tick
• 打包、安装、卸载 app

它不该干的

• 认知推理——那是 brain 的事
• 内核调度——那是 kernel 的事
• 系统级环境变量——自己管好自己的事

推荐的命令结构

命令	干什么
aur list	看看有哪些 app、谁在谁不在
aur run	按配置把启用的 app 拉起来
aur command	直接调某个 app 的命令
aur event	塞一个测试事件进去
aur tick	手动走几次 tick
aur config init	生成一份 apps/config.yaml
aur pack	打包成 .aur
aur install	装一个 .aur 包
aur uninstall	卸掉一个 app

.aur 包格式建议

第一版不用搞太复杂——zip 改个后辍就行。

一个最小可用的包至少得装这些：

• manifest.yaml
• __init__.py
• runtime.py
• README.md
• config.example.json
• aur.yaml

配置哲学

两层配置，各管各的：

配置位置	管什么
apps/config.yaml	平台视角：这个 app 开不开、怎么启
app-data/<package>/config.json	app 自己：我怎么理解我的配置

好处很明显：

• 平台只看"开没开、怎么开"
• app 自己管 "我的参数是什么意思"

分阶段落地

第一阶段

• 把 app.py 改成子命令结构
• 帮助文案全换成 aur

第二阶段

• 定 aur.yaml 的格式
• 定 .aur 里该放什么、怎么验

第三阶段

• 搞定 pack / install / uninstall
• 加个配置自动补全

第四阶段

• 加 --force、--purge-data
• 搞版本冲突处理
• 上校验和 / 签名

当前结论

aur 这个名字挺合适——开发期管用，分发期也用得上，一个名字兜底。现在差的不是方向，是时间。