# Decisions

- 当前事实源以 `/Users/zhengbokai/repo/ai/abos-platform-current-source.md` 为准。
- 平台主线采用三面架构：
  - CVM / `abos-at.work`：观测面、介入面、入口面。
  - Mac Mini：执行面、自我优化面、本地事实面。
  - 事实源/治理层：schema、巡检、漂移、建议、审批、回写。
- `abos-at.work` 首页新增自进化平台入口的设计方向已落地：去掉顶部导航中的 `Notes` 和 `About`，导航收敛为 `观澜台 / 动力炉 / 议事厅 / 藏书阁`；`动力炉` URL 使用 `/engine/`；原 `知识库` 对外命名改为 `藏书阁`；原 `Thread Specs` 对外命名改为 `议事厅`。
- 页面职责按用户体验逻辑定义：
  - 首页 = 平台入口，回答“我能去哪儿”。
  - 动力炉 = 治理控制面，回答“我现在该管什么”。
  - 观澜台 = 事实与证据面，回答“系统实际发生了什么”。
  - 议事厅 = 飞书会话 spec 面，承载飞书每段会话总结形成的 ConversationSpec；spec 可能有遗漏、噪音或时效性问题，因此需要状态识别与整理机制。
  - 藏书阁 = AI 公网探索文章与用户指定理解内容的知识库；当前主要是 AI 搜索/理解/沉淀的公网文章，不是实时任务控制台。
- OPS/动力炉 与现有入口的关系：`动力炉 = 观澜台 + 议事厅 + 藏书阁 + 介入面` 的治理控制面；观澜台保留为自动化汇报总线模块，cron/巡检属于观澜台的数据来源；议事厅承载会话 spec；风险建议、人工确认、驳回、备注、回滚与修正属于动力炉后续介入面。
- 自动化边界：只读巡检、健康探针、漂移检测、明确 owner 且低风险的本地服务重启可考虑自动执行；公网入口、鉴权、OpenResty/FRP/systemd/launchd 配置、删除进程/文件等必须人工确认。
- 动力炉一阶段目标：先做只读治理控制面，不做真实执行闭环。范围包括今日重点、页面治理、观澜台任务治理、议事厅进行中事项、proposal/下一步建议；所有高风险动作只生成建议，不提供执行按钮。
- 动力炉一阶段对观澜台/议事厅的“掌控力”定义为控制面而非执行面：统一索引内容、显示新鲜度/失效/未决状态、把观澜台报告关联到议事厅议题、从异常生成待确认 proposal、支持标记“已读/需跟进/已过期/需刷新/转议题”，但不直接修改高风险系统状态。
- 动力炉要承担跨页面/跨任务的治理职责：建立统一页面风格契约、数据契约和任务契约；新增页面必须优先通过 `publish-file-to-cvm-public` skill 作为发布门禁，检查共享模板/样式与风格漂移；定时任务必须输出可观测元数据（目标、输入、逻辑版本、产出、证据、错误、下一步建议）；所有进行中事项进入动力炉队列，按 owner、状态、新鲜度、风险、关联议题持续跟踪。绕过 publish skill 的运行后漂移巡检需要记录为后续能力，但一阶段优先级不高。
- 当前高优先级：先优化观澜台的人类可读输出。观澜台应从“cron 表格”升级为“任务说明 + 运行状态 + 证据 + 下一步”的任务治理视图；每个定时任务至少要能回答：它为什么存在、看了什么输入、按什么逻辑判断、产出了什么、失败原因是什么、下一步建议是什么、应关联哪个议事厅议题。

## 2026-07-07 16:29

- 2026-07-07：将《Loop Engineering 实战》映射为 ABOS 落地蓝图：ABOS 的最小自进化闭环应从“观澜台 cron/页面/会话异常 → 动力炉 proposal → 独立验证 → 人工确认/归档 → State 沉淀”开始；一阶段仍坚持只读控制面，高风险动作不直接执行。