01
通用闭环
Owner → Contract → State → Failure → Observe → Verify
这六步覆盖一个跨进程功能从设计到可维护的最小闭环。跳过其中任何一步，通常会在重启、异常或二次修改时还债。
像修建一条管线：先确定谁管理，再规定接头、流体储存、泄漏处理、仪表和压力测试。
02
场景 A
新增 Provider：先做能力矩阵，再接创建链
定义 provider id/preset、命令发现、参数 tokenization、权限/模型、resume、hook/status、数据目录和退出语义。然后再让 UI 只展示真实支持项。
- 01Shared：AgentProvider 类型与 preset。
- 02Main：spawnAgentCore、环境、恢复与错误归一。
- 03Renderer：能力驱动的表单与状态提示。
- 04验证：空格路径、多行 prompt、缺少 CLI、旧版本、恢复失败、Windows。
03
场景 B / C
新增 IPC 或持久字段：契约必须在三层同时闭合
Preload 类型、exposed API、Main handler、Renderer 调用只是最短链；还要补输入校验、权限、错误类型、事件回流、迁移、重启水合与删除语义。
- 01IPC request/response 使用可序列化 DTO，避免泄漏 Electron/Node 对象。
- 02Main 重新校验路径、id 与枚举，不信任 Renderer。
- 03若操作长时运行，返回 operation id 并发事件，不让一个 invoke 无限等待。
- 04持久字段增加 migration、默认策略、导入导出与降级读取。
ARCHITECTURE NOTE
完成标准不是“Happy path 能跑”，而是“重启后仍正确、失败后可解释、取消后无孤儿资源”。