基线：先让任务有统一语义
V1 架构选择一个 TypeScript 包承载 Kernel、Decision Engine、Executor、Task Repository 与 Capability Catalog。外部只依赖命令与事件接口，项目本身不用导入 Harness。这样控制层可移除，已经交付的代码仍是普通 Git 内容。1
这是一项范围取舍：先建立本地可解释路由、持久任务、审批和交付，不同时建设 Web UI、常驻 daemon 与远程集群。
宿主控制：模型不能代替用户审批
提交 7bf9d47 的主题是收紧宿主控制边界。固定阅读修订中的 MCP 测试明确区分模型工具与用户命令：MCP 可以提交结果、观察和恢复任务，审批与暂停、取消、调整需求的用户入口不直接开放给模型。2
这类修订没有增加一个新角色，而是校准谁有权发出哪种命令。代价是自动流程可能停下来等用户，收益是权限来源可追溯。
恢复：先重查资格，再继续工作
三个相邻修订分别处理恢复时的角色重校验、跨宿主调用方资格，以及执行资格与独立性的保留：
| 提交 | 公开提交主题 | 阅读重点 |
|---|---|---|
e1239ff | revalidate executor roles on resume | 恢复不能只相信旧角色分配 |
11a3bb4 | qualify cross-host resume callers | 新宿主必须具备接续资格 |
fff0281 | preserve eligibility and independence on resume | 接续任务不能损失原有资格与独立性约束 |
上述表格记录提交主题，不把每条提交标题当成全面验收证明。匹配修订中的跨宿主测试检查同一任务、重新取得的租约与交接文档；预算测试另行检查 deadline 不因暂停而延长。3
恢复因此可以概括为：重建事实、重查资格、重新取得推进权。它不是重新开一个没有历史约束的执行窗口。
安装与配置：把宿主差异显式化
阅读基线 1f2270e 加入生命周期安装与 provider 配置。README 记录安装、升级、卸载、自检和 Skill 逐项审核；自定义执行器 provider 在受信任的全局配置中声明，项目与任务配置不能覆盖这项连接边界。4
这是集成入口的演进，不是本次网站工作进行过安装的记录。安装会影响宿主 Skill、MCP 与 CLI，因此不能为了写文章而在用户环境中顺手执行。
下一阶段需要什么证据
现有设计要求六类端到端场景，包括普通对话保持临时状态、研究任务、低风险修改、高风险评审、跨宿主恢复和 Skill 信任边界。后续能力应以这些可观察契约为起点，而不是靠新增角色数量衡量成熟度。5
| 待持续核验的问题 | 足够有意义的证据 |
|---|---|
| 两个真实宿主的事件语义是否一致 | 固定 CLI 版本与认证条件下的独立 smoke |
| 恢复后权限是否仍正确 | 资格变化、旧审批失效与租约冲突场景 |
| 交付能否安全停止 | 动作进行中的取消与工作区并发冲突 |
| 预算是否限制了整个任务 | 暂停、恢复、返工后的累计消耗断言 |
这些是继续验证的方向，不是新功能承诺或交付日期。机制见技术页，已有测试的具体边界见实验验证。
来源与范围
本文截止 1f2270eaa31ba099837375bfcdfd162c8f31f1b9，不声称覆盖之后的开发。本次未逐个检出历史版本或重跑其验收，提交主题只用于说明演进顺序。