設計
Slipway は、ローカルで AI を活用した開発のための小さなガバナンス制御プレーンです。 AI コーディングツール、プロジェクトトラッカー、Git のいずれを置き換えるものでもありません。すべてのガバナンス対象の変更を、ライフサイクル、現在の権威ファイル、そしてセッション終了後に検証できるエビデンスへ結び付けることで、エージェントの作業を可読なものにします。
完全な設計ドキュメントは 設計思想 を参照してください。このページでは、Slipway を使うかどうかを判断する際に最も重要な概念をまとめます。
| 原則 | 意味 |
|---|---|
| ローカルファースト | リポジトリがアクティブな状態と監査記録を保持する。 |
| 単一の権威 | change.yaml が現在のライフサイクル状態を所有し、ログがその変化の経緯を説明する。 |
| 制約された自律性 | エージェントは作業を進められるが、ゲート・ブロッカー・レビュー・完了準備の証跡は可視のまま保たれる。 |
| アダプターの薄さ | ホストファイルは、独立したワークフローエンジンになるのではなく、CLI へ処理を振り向ける。 |
| アーティファクトの追跡可能性 | インテント、リサーチ、要件、決定、タスク、エビデンス、レビュー、アシュアランスが互いに結び付いたままになる。 |
| 検証の現在性 | 完了が有効なのは、現在のエビデンスが現在のワークトリーの状態を証明している場合に限られる。 |
エビデンスを再導出する理由
Section titled “エビデンスを再導出する理由”Slipway は、ファイルに pass と書かれているというだけで判定を信頼することはありません。現在のバンドル、タスクプラン、実行ランバージョン、選択されたレビューセット、終端の ship-verification スイートの実行、ランタイムのタスクエビデンスといった権威ある入力から、現在性を導出します。
だからこそ、古くなった証跡はフェイルクローズします。回復手段は、ファイルの再スタンプではなく、それを所有するステージ、レビュアー、またはタスクエビデンスのパスを再実行することです。
ワークトリーが重要な理由
Section titled “ワークトリーが重要な理由”ガバナンス対象の変更は、専用のワークトリーに結び付くことがよくあります。現在のワークトリーが挙動の表面です。ルートのチェックアウト、古いブランチとの比較、アーカイブされたバンドルはレビューの助けにはなりますが、所有するワークトリーから得られる status、validate、next の出力の代わりにはなりません。
アダプターが薄い理由
Section titled “アダプターが薄い理由”生成された Claude、Codex、Copilot、Cursor、Kilo、Kiro、OpenCode、Pi、Qwen、Windsurf のファイルは、AI ツールが適切なコマンドやスキルを見つける助けになります。これらがライフサイクルのセマンティクスを所有することはありません。生成されたアダプターと CLI が食い違う場合は、アダプターを更新し、現在の CLI を信頼してください。