设计理念
Slipway 是一个面向本地 AI 辅助开发的小型治理层。它不取代 AI 编码工具、项目跟踪器或 Git，而是把每一次改动都绑定到一条生命周期、一份当前权威文件，以及会话结束后仍可审查的证据，让 agent 的工作变得可审视。
| 原则 | 含义 |
|---|---|
| 本地优先 | 活跃状态和审计轨迹都保存在仓库里。日后接入托管服务或许有用，但理解一次改动并不需要它。 |
| 单一权威 | change.yaml 拥有当前生命周期状态。生命周期日志解释状态如何变化，但不取代当前状态。 |
| 有界自治 | agent 可以推进工作，但 Slipway 会暴露关卡、阻塞项、评审要求以及可交付（done-ready）的凭证。 |
| 适配层保持轻薄 | Claude、Codex、Copilot、Cursor、Kilo、Kiro、OpenCode、Pi、Qwen 和 Windsurf 的接口只负责路由到 CLI，不应各自演变成独立的治理引擎。 |
| 产物可追踪 | 意图、调研、需求、决策、任务、执行证据、评审证据和保障文档始终彼此关联。 |
| 时效性校验 | 只有当前证据能证明当前 worktree 状态时，完成声明才成立。 |
Slipway 的价值不在于某一道关卡，而在于每个受治理的阶段都掌握着引擎重新推导而非直接信任的证据，并横跨多个相互独立的维度。每个维度都按其真实的执行层级陈述——结构层就是结构层，真正强制的就是真正强制——绝不夸大。相邻的规范、工作流和技能工具箱也能把工作组织得很好，区别在于：它们靠请求模型遵守来执行流程，而这些维度则在模型会运行、却无法改写的编译代码里完成校验。
| 维度 | 执行层级 | 一句话说明 |
|---|---|---|
| 1. 经过证明的当前上下文 | 审计/结构层 | 当必须独立的阶段共用同一个句柄时，按边界划分的 context_origin 格结构会失败即停 |
| 2. 防篡改证据 | 输入摘要（S3 证书）+ 结构层（执行） | 时效性从权威输入重新推导，绝不依赖校验记录自己的声明 |
| 3. 双向并行安全 | 真正强制 | 文件互斥的波次规划，外加四张派发后的已改文件安全网 |
| 4. 范围收敛 | 真正强制 | target_files 是一份契约，用规划器自身的 TargetCoversPath 谓词来校验 |
| 5. 感知漂移的前向恢复 | 真正强制 | 仅向前重开（forward-only reopen）；next 把修复投射为一条具名命令 |
| 6. 本地优先、git 原生审计 | 真正强制 | change.yaml 权威，外加只追加、回读校验的 lifecycle.jsonl |
| 7. 按风险分级的护栏 | 真正强制（失败即停） | 敏感领域必须通过高风险检查，且没有任何绕过、强制关闭或自我证明的通道 |
真实层级很重要：维度 3–7 是引擎真正强制的机制；维度 2 把输入摘要检查（S3 评审证书）与结构层时效性（执行摘要）混合在一起；维度 1 则刻意停留在审计/结构层——它抬高了伪造独立性的成本，但并不声称提供密码学证明。下面各小节分别给出每个维度的机制与竞争边界。
1. 经过证明的当前上下文
Section titled “1. 经过证明的当前上下文”每个阶段都会记录它运行时所处的、互不相同的上下文句柄（context_origin:stage=<stage>=<handle>）。当两个必须相互独立的阶段共用同一个句柄时，按边界划分的碰撞格结构会失败即停：评审者对实现者、计划审计者对计划作者、修复对二者中的任意一方。恢复方式是在一个全新的原生子 agent 里重跑该阶段的所属环节，让它重新发出一个不同的句柄。这属于审计/结构层：句柄是宿主发出的字符串，因此格结构抬高了把整条链坍缩进单一作者上下文的成本与可见性，但它不是独立性的密码学证明。gsd 和 superpowers 会派生全新的子 agent；Slipway 还会校验独立性是否真的成立。完整的逐边界模型与诚实的残留局限，见独立性证明层级。
2. 防篡改证据
Section titled “2. 防篡改证据”时效性从权威输入计算，而非来自校验记录自己的声明。选中的 S3 评审证书绑定到引擎自有的输入摘要（代码差异、规划产物、任务范围哈希以及 run-summary 版本）；那一份唯一权威的完整测试套件由终端 ship-verification 关卡拥有，而不是供各评审同侪共享使用的某块基石。执行摘要的任务时效性是结构层的（change_id、run_summary_version、task_id、guardrail_domain），仅含哈希的旧摘要会被视为过期并重新生成。无论哪种情况，被手工编辑过的裁决或漂移的输入都会被检测并具名（required_skill_stale:<skill>:<input>），而不是被信任。引擎始终是裁决和 run 版本的唯一盖章者；没有任何关卡新增自我盖章、重新盖章或强制关闭的通道。相邻工具把状态存为模型自行维护、可随意编辑的 Markdown/YAML。
3. 双向并行安全
Section titled “3. 双向并行安全”波次规划器用确定性的拓扑排序，把任务装入按依赖排序、文件互斥的波次；多任务波次默认并发运行（execution.parallelization: off 可退出）。真正与众不同的那一半是派发后的审计：四张失败即停的安全网检查实际记录下来的 changed_files——范围逃逸、并行波次的文件重叠、缺失或缺乏正当理由的派发模式、缺失的每任务执行者句柄。派发本身由宿主驱动（AI 宿主按已生成的计划扇出原生子 agent）；Slipway 不跑任何并发调度器，它校验产出的证据。会并行的同类工具只在派发前检查计划；Slipway 还会在事后审计 agent 实际改了什么。
4. 范围收敛
Section titled “4. 范围收敛”tasks.md 里每个任务声明的 target_files 都是一份范围契约，用波次规划器做冲突检测时同一个 TargetCoversPath 谓词来评估，因此“覆盖”和“冲突”共用同一份实现。契约之外的已记录改动会失败即停（scope_contract_drift 及其同类），每一种都映射到可操作的补救动作。范围契约有两类被公开声明的豁免项，二者都在 validate/status/review --json 上呈现，而不是被悄悄应用。其一是 artifacts/codebase/ 下的持久代码库地图：当只有那些上下文文件变脏时，它们不计入 scope_contract.changed_files，并以 scope_contract.exempt_context_files 呈现。其二是诚实地零改动的 pass code 任务：当它带有 no_op_justification 时，即豁免于变更文件要求，并以 scope_contract.no_op_justified_tasks 呈现。
5. 感知漂移的前向恢复
Section titled “5. 感知漂移的前向恢复”当计划、代码和证据出现分歧时，生命周期会就地且仅向前地重开改动——没有任何可能掩盖缺口的反向状态级联，同一意图的 S3 计划或任务修订停留在评审/修复阶段，而 S2 保持完成。阻塞项会投射成一个 RecoverySummary，含一条主命令以及每个阻塞分组一个步骤，呈现在只读的 next/status/validate JSON 上，让 agent 直接读到下一步的前向动作，而不必去推断私有的执行顺序。一种只因 agent 记住了隐藏流程才能奏效的恢复，被视为产品缺陷，而非特性。
6. 本地优先、git 原生审计
Section titled “6. 本地优先、git 原生审计”change.yaml 是唯一的当前权威；events/lifecycle.jsonl 是每个变更事件的只追加轨迹，以原子重写加写后回读校验的方式写入，并标注操作来源的接口（actor_kind，以及技能驱动步骤的 skill_id）。证据与代码一起存放在 artifacts/changes/ 下的受治理 bundle 中。理解一次改动不需要任何托管服务，因此审计轨迹默认是自主可控的，可被任何后来的人类或 AI 会话重新审查。生命周期日志只是审计证据——它从不取代 change.yaml 作为当前状态权威的地位。
7. 按风险分级的护栏
Section titled “7. 按风险分级的护栏”敏感领域——认证/鉴权、凭据/PII、资金流转、schema/数据迁移、不可逆操作以及外部 API 契约——失败即停更严格。在授予发布权之前，它们必须通过逐领域的高风险检查，在 S2 和 S3 两处都对敏感证据设关，且没有任何绕过、强制关闭或私有证明的通道。同一条对一次性改动很轻量的生命周期，对真正可能伤到你的改动毫不留情；light 预设会放松建议性层级，但绝不放松敏感领域的失败即停红线。
这种分离很关键。next、status 和 validate 可以重新计算就绪度，而不改动生命周期权威。run 和 done 是明确的改状态接口。生成的宿主文件帮助 AI 工具发现正确的动作，但 CLI 始终是执行权威。
Slipway 持久的设计通过它自身的权威边界来表达，而不是靠与上游工具持续比较。相邻的工作流和 agent 系统仍可作为有用的调研输入，但它们不定义 Slipway 的运行时契约。
| 边界 | Slipway 立场 |
|---|---|
| 运行时权威 | 让 change.yaml 作为当前状态权威，生命周期事件作为轨迹。 |
| 状态变更 | 让 next、status 和 validate 保持只读；把状态变更保留给 run、done 这类明确的变更命令。 |
| 适配层接口 | 把宿主文件作为交接辅助来生成。稳定契约是“生成路径 + CLI 命令”，而非宿主特定的治理状态。 |
| 安装指引 | 记录 Slipway 自有的发布与初始化路径，不把适配层安装当作治理的事实来源。 |
| 执行证据 | 把任务证据、评审证据和最终校验当作绑定到当前 run 的一等 Slipway 产物。 |
| 范围纪律 | 在合适时复用小型原语，但避免把车道调度器、仪表盘或项目管理运行时引入治理内核。 |
独立性证明层级
Section titled “独立性证明层级”Slipway 会使用一小组记录在校验引用上的独立性证明。它们位于一条刻意划定的层级边界上，设计上对这条边界诚实陈述，而非夸大。
| 证明 | 引擎强制什么 | 层级 |
|---|---|---|
由链路级独立性技能在共享 worktree 上发出的 context_origin:stage=<stage>=<handle>，其中所有选中的 S3 评审者都用 stage=review，S3 评审发现的修复在记录时用 stage=fix |
各边界所拥有的参与者句柄都存在且两两不同；选中的评审者按技能名分键，即便它们共用 review 这条总线阶段；记录的修复句柄必须与实现和评审者句柄都不同 |
审计/结构层——抬高伪造成本与可审计性，而非密码学证明 |
ship-verification 上的 closeout:reviewer_independence=pass |
Pattern-A 存在性，在终端发布记录上被引擎使用（缺失时为 ship_verification_reviewer_independence_missing） |
结构存在性 |
ship-verification 上的 closeout:assurance_complete=pass |
Pattern-A 存在性，证明 assurance.md 已完成（缺失时为 ship_verification_assurance_attestation_missing） |
结构存在性 |
终端排序 ship-verification >= 每个选中的 S3 同侪 |
终端发布记录的盖章时间在无序的选中评审集合之后或同时，因此该关卡能观察到最终的评审证据 | 真正强制的排序 |
degraded_dispatch_justification:wave=<n>:tool_unavailable=<detail> |
一次 degraded_sequential 派发必须配上一条工具不可用的正当理由 |
结构配对 |
每道关卡在 standard/strict 下以错误严重级失败即停，在 light 下为建议性——建议性通过 Pattern-A 省略实现（关卡在 light 下不返回阻塞项），而不是单设一条建议通道。没有任何关卡新增绕过、强制关闭或自我盖章的通道；引擎始终是唯一的裁决盖章者。
跨阶段 context-origin 格结构
Section titled “跨阶段 context-origin 格结构”context_origin:stage=<stage>=<handle> 是一套链路级的统一语法——由独立性技能在共享 worktree 上发出——贯穿整条受治理的链路。S3 使用一个选中的评审集合：规范评审和独立评审的评审者对每个 profile 都会被选中；当工作流 profile 要求代码质量评审时，代码质量评审加入；当引擎推导出的安全控制被选中时，安全评审加入。终端 ship-verification 关卡在这个集合收敛之后运行，并不属于它的同侪之一。每个选中的评审宿主都记录同一个 context_origin:stage=review=<handle> 总线令牌，但 R2 格结构按记录评审的技能名，而非按共享的 review 阶段，来给这些参与者分键。其他评审权参与者是 S2 波次的 executor，以及记录在评审者证据上的可选 S3 评审发现 fix 句柄；S1 audit_origin 由计划关卡拥有，不属于实时的 S3 评审边界。碰撞格结构按边界分别拥有，因此没有哪个阶段会去重复检查另一边界已经拥有的边：
选中评审者的时效性通过当前差异、规划产物和 run-summary 版本来分键；不存在供同侪使用的共享 suite-result 基石。那一份唯一权威的完整套件——以及任何护栏 SAST 基线——在同侪收敛之后由终端 ship-verification 关卡只跑一次，记录在它自己的证据上，而非某块同侪共享的记录上。
| 边界 | 拥有 | 边数 |
|---|---|---|
| 计划关卡（S1） | 仅本地的 audit_origin != plan_origin 边（计划审计作者 对 自审者） |
1 |
| 评审权 | {executor, fix} 之间的每条边，加上选中评审技能的键；S1 audit_origin 不是实时的 S3 参与者 |
随工作流 profile、选中的安全控制和可选 fix 句柄而变 |
| 发布权 | 没有额外的 context-origin 边；终端 ship-verification 关卡拥有终端排序不变式，加上评审者独立性与保障完成的存在性证明 |
0 |
当某个边界失败即停时，恢复方式是在一个全新的原生子 agent 里重跑该边界所属的阶段或选中的评审者，让它重新发出一个不同的 context_origin 句柄；引擎从不自我盖章、重新盖章、强制关闭，也不把未选中的安全证据当作隐藏的格结构参与者。
诚实的残留局限。 context_origin 格结构无法证明链路各阶段确实在彼此独立的上下文里运行，因为句柄是宿主发出的字符串——它与执行者派发句柄处于同一结构层级，而非独立性的密码学证明。真正不可伪造的“不同上下文”判别需要引擎签发的逐阶段 nonce，或一个生命周期事件边界(“方案 B”)，而这在本次改动的约束下不可行：独立性技能共享同一个 run 版本，时间戳单调性只能抓出顺序错误，而唯一零 schema 的 nonce 又是宿主可读的明文。所以这套格结构被呈现为审计/结构层——它让最廉价的“作者上下文坍缩”在每个所属边界上都变得可见且昂贵——而绝不当作“不同上下文”的密码学证明。
- Slipway 不会在没有受治理产物的情况下推断出一份完整的项目计划。
- Slipway 不会让 AI 工具生成的文件凌驾于 CLI 状态之上。
- 当评审、验收或保障证据缺失时,Slipway 不会把一次绿色测试运行当作通过的
ship-verification关卡。 - Slipway 不会把本地状态变更藏在只读命令背后。
一次受治理变更只有在 worktree、产物包、校验记录和生命周期状态全部一致时，才算完成。
- 目标在
intent.md和需求契约中得到表达。 - 实现文件和文档满足需求。
- 任务证据对当前执行 run 当前有效。
- 规范评审与质量评审记录通过。
- 终端
ship-verification关卡以当前有效的三级证据和那一份唯一权威的完整套件，证明所陈述的验收标准。 slipway done在达到 done-ready 结果后归档终端状态。