设计
Slipway 是一个面向本地 AI 辅助开发的轻量治理层。它不取代 AI 编码工具、项目追踪器或 Git，而是把每一次受治理的变更绑定到一条生命周期、一份当前权威文件，以及会话结束后仍可复查的证据，让 agent 的工作变得可审视。
完整设计文档见 设计哲学。本页只概述在判断是否要用 Slipway 时最该关注的几个概念。
| 原则 | 含义 |
|---|---|
| 本地优先 | 仓库中保存着活动状态和审计记录。 |
| 单一权威 | change.yaml 持有当前生命周期状态；日志负责说明它如何变化。 |
| 有限自治 | agent 可以推进工作，但 gate、阻塞项、评审和 done-ready 证明始终可见。 |
| 适配器要薄 | 宿主文件只负责把请求路由到 CLI，而不应自己变成独立的工作流引擎。 |
| 产物可审视 | 意图、调研、需求、决策、任务、证据、评审和保障之间保持连通。 |
| 时效性校验 | 只有当前证据能证明当前 worktree 状态时，完成才算有效。 |
为什么证据要重新推导
Section titled “为什么证据要重新推导”Slipway 不会仅因为某个文件写着 pass 就信任这个结论。它会从权威输入中推导证据时效性，比如当前 bundle、任务计划、执行运行版本、选定的评审集合、终态 ship-verification 套件运行结果，以及运行期任务证据。
正因如此，陈旧的证明会失败即停（fail-closed）。要恢复，得重新运行对应的阶段、评审者或任务证据路径，而不是给文件重新盖戳。
为什么 worktree 很重要
Section titled “为什么 worktree 很重要”受治理的变更通常绑定到专用 worktree。当前 worktree 才是行为载体。根检出、旧分支对比或归档的 bundle 可以辅助评审，但都替代不了来自所属 worktree、当前有效的 status、validate 和 next 输出。
为什么适配器是薄的
Section titled “为什么适配器是薄的”生成的 Claude、Codex、Copilot、Cursor、Kilo、Kiro、OpenCode、Pi、Qwen 和 Windsurf 文件帮助 AI 工具找到正确的命令或技能，但它们不拥有生命周期语义。如果生成的适配器与 CLI 出现分歧，刷新适配器，以当前 CLI 为准。