#Service 与 Kernel 架构

项目 Service 持有一个 Kernel 执行环境。CMD、TUI 和 MCP 连接这个环境，不各自保存一套 Run 或 Stage State。

Host 准备固定执行策略，Operations 接受请求，Runtime 创建 Run 并推进 Step，Execution 执行 Code/Agent，Access 检查每次能力使用的权限与有效期。Host 只向 Operations 提供所需端口；修改 Run 统一经过带操作回执的 admit，等待结果是独立的观察操作。只有 Runtime 决定下一步路由；Execution 和 Access 不依赖 Runtime 的实现。

操作接受与执行完成是两件事：操作回执说明准入结果，Run 快照说明当前进展。观察连接断开不取消执行，也不重放请求。人类等待先保存问题，再对外发布；先保存已接受回答，再继续执行。Agent 等待只持久化恢复边界，进程内 claim 无法跨重启恢复。

实际提交引用和未完成活动独立于可选的模型统计。Run 已停止时，先前接受的外部操作仍可能尚未结束，此时 settled 为 false。独占 Run 在这些活动结束前仍占用项目，暂停状态也保留占用。服务关闭后，新操作在修改状态前被拒绝，已有回执仍可在该实例中查询。终态检查点保留为只读历史；结果不确定的外部副作用不会自动重放。

模型适配保留 Tool 的能力绑定；Tool 返回后不能继续写入 State。委派 Tool 的回执包含执行后的检查结果，同一请求重试保持相同的成功或失败结果。恢复校验由 Runtime 提供独立入口，Host 的离线镜像恢复不需要构造执行器。

开发 Loom 使用 @intloom/loom-sdk 与 intloom build。Kernel 保持私有并随 CLI 打包。具体状态归属、依赖方向和恢复约束见 Kernel 契约。

另见执行资源、生命周期、恢复和 ProjectClient。