AUR CLI 路线图

app.py 目前是一个临时调试入口——功能可用但组织分散。后续计划将其升级为统一的 CLI 工具，命名为 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 的命名同时覆盖开发期与分发期，语义统一。方向已明确，只待逐步落地。