設計思想

Slipway は、ローカルでの AI 支援開発のための小さなガバナンス制御プレーンです。AI コーディングツールやプロジェクト管理ツール、Git を置き換えるものではありません。すべての変更をライフサイクル、現在の権威ファイル、そしてセッション終了後でも検証できる証跡に結びつけることで、エージェントの作業を可読なものにします。

原則

原則	意味
ローカルファースト	アクティブな状態と監査証跡はリポジトリ内に存在します。ホスト型サービスは後から役立つこともありますが、変更を理解するために必須ではありません。
単一の権威	change.yaml が現在のライフサイクル状態を所有します。ライフサイクルログは状態がどう変化したかを説明するだけで、現在の状態を置き換えるものではありません。
限定された自律性	エージェントは作業を前進させられますが、Slipway はゲート、ブロッカー、レビュー要件、完了準備の証明を明示します。
アダプターの薄さ	Claude、Codex、Copilot、Cursor、Kilo、Kiro、OpenCode、Pi、Qwen、Windsurf の各サーフェスは CLI へとルーティングします。これらが独立したガバナンスエンジンになってはなりません。
アーティファクトのトレーサビリティ	意図、調査、要件、決定、タスク、実行の証跡、レビューの証跡、アシュアランスは互いにつながったままです。
現在性のある検証	完了の主張は、現在の証跡が現在のワークトリーの状態を証明している場合にのみ有効です。

優位性の軸

Slipway の価値は単一のゲートにあるのではありません。すべてのガバナンス対象ステージが、エンジンが信頼するのではなく再導出する証跡を、複数の独立した軸にわたって所有している点にあります。各軸は誇張せず、実際の強制レベルに合わせて述べます。構造的なものは構造的に、実際に強制されるものはそのように扱います。隣接する spec、ワークフロー、スキルのツールキットも作業をうまく構造化しますが、それらはモデルに従うよう依頼することでプロセスを強制するのに対し、これらの軸はモデルが実行はできても書き換えられないコンパイル済みコードでチェックされる点が分かれ目です。

軸	強制レベル	一言で
1. 現在性が証明されたコンテキスト	監査/構造的	シーム単位の context_origin ラティスが、独立すべきステージがハンドルを共有したときにフェイルクローズドになる
2. 改ざんが明らかになる証跡	入力ダイジェスト（S3 証明書）＋構造的（実行）	現在の入力との一致は権威ある入力から再導出され、検証レコード自身の主張からは決して導かれない
3. 双方向の並列安全性	実際に強制される	ファイルが互いに素なウェーブ計画と、ディスパッチ後の 4 つの変更ファイル安全網
4. スコープ封じ込め	実際に強制される	target_files は、プランナー自身の TargetCoversPath 述語でチェックされる契約
5. ドリフトを認識した前方リカバリ	実際に強制される	前方のみのリオープン。next が修復を名前付きコマンドとして提示する
6. ローカルファーストで git ネイティブな監査	実際に強制される	change.yaml の権威に加え、追記専用で読み戻し検証される lifecycle.jsonl
7. リスク階層化されたガードレール	実際に強制される（フェイルクローズド）	センシティブドメインは高リスクチェックを要求し、バイパス・強制クローズ・自己証明のパスを得られない

実際の強制レベルを明確にすることが重要です。軸 3〜7 はエンジンが実際に強制するメカニズムであり、軸 2 は入力ダイジェストチェック（S3 レビュー証明書）と構造的な現在性（実行サマリ）を組み合わせています。軸 1 は意図的に監査/構造的レベルに位置づけられており、独立性を偽装するコストを引き上げますが、暗号学的な証明を主張するものではありません。以下のセクションでは、各軸のメカニズムと競合上の境界を示します。

1. 現在性が証明されたコンテキスト

すべてのステージは、自身が実行されたときの個別のコンテキストハンドル（context_origin:stage=<stage>=<handle>）を記録し、シーム単位の衝突ラティスが、独立すべき 2 つのステージがハンドルを共有したときにフェイルクローズドになります。対象はレビュアー対実装者、プラン監査者対プラン作成者、修正対それらいずれかです。リカバリでは、所有元のステージを新しいネイティブサブエージェントで再実行し、個別のハンドルを再発行させます。これは監査/構造的レベルです。ハンドルはホストが発行する文字列なので、ラティスはチェーンを単一の作成コンテキストへ折りたたむコストと可視性を引き上げますが、独立性の暗号学的証明ではありません。gsd と superpowers は新しいサブエージェントを起動します。Slipway はさらに独立性が保たれたかをチェックします。シーム単位のエッジモデル全体と残る制約については 独立性証明レベル を参照してください。

2. 改ざんが明らかになる証跡

現在の入力との一致は権威ある入力から計算され、検証レコード自身の主張からは計算されません。選択された S3 レビュー証明書は、エンジンが所有する入力ダイジェスト（コード差分、計画アーティファクト、タスクスコープのハッシュ、ラン サマリのバージョン）に紐づきます。唯一の権威ある完全スイートは、ピアが消費する共有のキーストーンではなく、終端の ship-verification ゲートが所有します。実行サマリにおけるタスク証跡の現在性は構造的（change_id、run_summary_version、task_id、guardrail_domain）であり、古いハッシュのみのサマリは陳腐とみなされ再生成されます。いずれの場合も、手で編集された判定やドリフトした入力は信頼されず、検出され名前が付けられます（required_skill_stale:<skill>:<input>）。エンジンは判定とランバージョンを刻印する唯一の主体であり続けます。どのゲートも自己刻印、再刻印、強制クローズのパスを追加しません。隣接ツールは、モデルが保守し自由に編集できる Markdown／YAML として状態を保存します。

3. 双方向の並列安全性

ウェーブプランナーは、決定論的なトポロジカルソートで、タスクを依存関係順かつファイルが互いに素なウェーブにバケット分けします。複数タスクのウェーブはデフォルトで並行実行されます（execution.parallelization: off でオプトアウト）。差別化要因となるもう半分はディスパッチ後の監査です。4 つのフェイルクローズドな安全網が、実際に記録された changed_files をチェックします。対象はスコープ逸脱、並列ウェーブのファイル重複、ディスパッチモードの欠落または正当化されていないディスパッチ、タスクごとの実行者ハンドルの欠落です。ディスパッチ自体はホスト駆動で（AI ホストがマテリアライズされた計画に従ってネイティブサブエージェントをファンアウトする）、Slipway は並行スケジューラを実行せず、結果として得られた証跡を検証します。並列化するピアはディスパッチ前に計画をチェックしますが、Slipway はその後にエージェントが実際に編集したものも監査します。

4. スコープ封じ込め

各タスクが tasks.md で宣言する target_files はスコープ契約であり、ウェーブプランナーが衝突検出に使うのと同じ TargetCoversPath 述語で評価されます。そのため「カバーする」と「衝突する」は単一の実装を共有します。契約外で記録された変更はフェイルクローズドになり（scope_contract_drift とその同類）、それぞれが実行可能な是正措置にマッピングされます。スコープ契約には明示された例外が 2 つあり、いずれも黙って適用されるのではなく validate／status／review --json 上で明示されます。1 つ目は artifacts/codebase/ 配下の永続的なコードベースマップです。それらのコンテキストファイルだけが汚れている場合、それらは scope_contract.changed_files から外れたまま scope_contract.exempt_context_files として明示されます。2 つ目は正直にゼロ変更の pass code タスクです。no_op_justification を伴う場合、変更ファイル要件から免除され、scope_contract.no_op_justified_tasks として明示されます。

5. ドリフトを認識した前方リカバリ

計画・コード・証跡が乖離したとき、ライフサイクルは変更をその場で、前方のみでリオープンします——ギャップを隠しうる後方への状態カスケードはなく、同一意図の S3 計画またはタスクの修正は、S2 が完了したままレビュー／修正にとどまります。ブロッカーは、1 つの主コマンドと、ブロッカーグループごとに 1 ステップを持つ RecoverySummary に投影され、読み取り専用の next／status／validate の JSON 上に表示されます。これによりエージェントは、非公開のシーケンスを推測するのではなく、次の前方アクションを直接読み取れます。エージェントが隠れたフローを暗記しているからこそ機能するリカバリは、機能ではなく製品の欠陥として扱われます。

6. ローカルファーストで git ネイティブな監査

change.yaml は唯一の現在の権威です。events/lifecycle.jsonl はすべての変更イベントの追記専用トレースで、アトミックな書き換えとして書き込まれ、書き込み後の読み戻し検証が行われ、操作したサーフェス（actor_kind、スキル駆動のステップでは skill_id）でタグ付けされます。証跡は artifacts/changes/ 配下のガバナンス対象バンドルの中で、コードのそばに存在します。変更を理解するためにホスト型サービスを必要とするものは何もないため、監査証跡はデフォルトで主権的であり、後の人間や AI セッションが再検証できます。ライフサイクルログは監査証跡にすぎません——現在状態の権威としての change.yaml を置き換えることは決してありません。

7. リスク階層化されたガードレール

センシティブドメイン——認証/認可、資格情報/PII、金銭フロー、スキーマ/データ移行、不可逆な操作、外部 API 契約——はより強くフェイルクローズドになります。これらは、出荷承認の前にドメインごとの高リスクチェックを要求し、センシティブな証跡を S2 と S3 の両方でゲートし、バイパス・強制クローズ・非公開証明のパスを一切得られません。使い捨ての変更と同じライフサイクルでも、実際に被害につながりうる変更には厳格に適用されます。light プリセットは助言レベルを緩和しますが、センシティブドメインのフェイルクローズド基準は決して緩めません。

アーキテクチャモデル

この分離が重要です。next、status、validate は、ライフサイクルの権威を変更せずに準備状態を再計算できます。run と done は明示的な変更サーフェスです。生成されたホストファイルは AI ツールが正しいアクションを見つけるのを助けますが、CLI が実行の権威であり続けます。

設計の境界

Slipway の永続的な設計は、上流ツールとの継続的な比較ではなく、自身の権威境界によって表現されます。隣接するワークフローやエージェントのシステムは依然として有用な研究の入力となりますが、Slipway のランタイム契約を定義するものではありません。

境界	Slipway の立場
ランタイム権威	change.yaml を現在状態の権威とし、ライフサイクルイベントをトレースとして保つ。
状態変更	next、status、validate を読み取り専用に保ち、状態変更は run や done のような明示的な変更コマンドに限定する。
アダプターサーフェス	ホストファイルをハンドオフの補助として生成する。安定した契約は、ホスト固有のガバナンス状態ではなく、生成されるパスと CLI コマンドである。
インストールの案内	アダプターのインストールをガバナンスの信頼できる情報源にすることなく、Slipway が所有するリリースと初期化のパスを文書化する。
実行の証跡	タスクの証跡、レビューの証跡、最終検証を、現在のランに紐づく第一級の Slipway アーティファクトとして扱う。
スコープ規律	適合する場合は小さなプリミティブを再利用するが、レーンスケジューラ、ダッシュボード、プロジェクト管理ランタイムをガバナンスカーネルへ取り込むことは避ける。

独立性証明レベル

Slipway は、検証参照に記録された小さな独立性証明の集合を消費します。これらは意図的なレベル境界の上に位置し、設計はその境界を誇張せず正直に述べます。

証明	エンジンが強制するもの	レベル
共有ワークトリー上でチェーン全体の独立性スキルが発行する 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	assurance.md が完全であることを示す Pattern-A の存在（欠落時は 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 ラティス

context_origin:stage=<stage>=<handle> は、共有ワークトリー上で独立性スキルが発行する、ガバナンスチェーン全体にまたがる単一のチェーン全体グラマーです。S3 は選択されたレビュー集合を用います。spec レビューと independent レビューのレビュアーはすべてのプロファイルで選択されます。code-quality レビューは、ワークフロープロファイルが code-quality レビューを要求するときに加わります。security レビューは、エンジンが導出した security コントロールが選択されたときに加わります。終端の ship-verification ゲートはこの集合が収束した後に実行され、そのピアの 1 つではありません。選択されたすべてのレビューホストは同じ context_origin:stage=review=<handle> ワイヤトークンを記録しますが、R2 ラティスはそれらの参加者を、共有された review ステージではなく記録元のレビュースキル名でキーします。他のレビュー権威の参加者は、レビュアー証跡に記録される S2 ウェーブの executor と、任意の S3 レビュー所見 fix ハンドルです。S1 の audit_origin はプランゲートが所有し、ライブの S3 レビューシームには属しません。衝突ラティスはシームごとに所有されるため、あるシームがすでに所有するエッジを別のステージが再チェックすることはありません。

選択されたレビュアーの現在性は、現在の差分、計画アーティファクト、ラン サマリのバージョンを通じてキーされます。ピアが消費する共有のスイート結果キーストーンはありません。唯一の権威ある完全スイート——および任意のガードレール SAST ベースライン——は、ピアが収束した後に終端の ship-verification ゲートが一度だけ実行し、ピア共有のレコードではなく自身の証跡に記録します。

シーム	所有するもの	エッジ
プランゲート（S1）	ローカルの audit_origin != plan_origin エッジのみ（プラン監査の作成者対自己監査の監査者）	1
レビュー権威	{executor, fix} 間のすべてのエッジに加え、選択されたレビュースキルのキー。S1 の audit_origin はライブの S3 参加者ではない	ワークフロープロファイル、選択された security コントロール、任意の fix ハンドルによって可変
出荷権威	追加の context-origin エッジなし。終端の ship-verification ゲートが終端順序の不変条件と、レビュアー独立性およびアシュアランス完了の存在証明を所有する	0

シームがフェイルクローズドになったときのリカバリは、所有元のステージまたは選択されたレビュアーを新しいネイティブサブエージェントで再実行し、個別の context_origin ハンドルを再発行させることです。エンジンは自己刻印、再刻印、強制クローズを決して行わず、選択されていない security 証跡を隠れたラティス参加者として扱うこともありません。

残る制約。 context_origin ラティスは、チェーンの各ステージが本当に独立したコンテキストで実行されたことを証明できません。ハンドルがホスト発行の文字列だからです。これは実行者ディスパッチハンドルと同じ構造的レベルであり、独立性の暗号学的証明ではありません。真に偽造不可能な個別コンテキストの識別には、エンジンが発行するステージごとのノンスか、ライフサイクルイベント境界（「Option B」）が必要ですが、これは本変更の制約内では実現不可能です。独立性スキルはラン バージョンを共有し、タイムスタンプの単調性は順序の誤りしか捉えられず、唯一のスキーマレス ノンスはホストが読み取り可能な平文です。そのためラティスは監査/構造的レベルとして提示され、所有するすべてのシームにわたって、最も安価な作成コンテキストの折りたたみを可視かつ高コストにします。暗号学的な個別コンテキスト証明としては決して提示されません。

非目標

• Slipway は、ガバナンス対象のアーティファクトなしに完全なプロジェクト計画を推論しません。
• Slipway は、AI ツールが生成したファイルを CLI の状態に対して権威あるものにしません。
• Slipway は、レビュー・受け入れ・アシュアランスの証跡が欠けているとき、グリーンなテスト実行を ship-verification ゲートの合格として扱いません。
• Slipway は、ローカルの状態変更を読み取り専用コマンドの背後に隠しません。

完了とみなされる条件

ガバナンス対象の変更が完了したとみなされるのは、ワークトリー、アーティファクトバンドル、検証レコード、ライフサイクル状態がすべて一致したときだけです。

1. 目的が intent.md と要件契約に表現されている。
2. 実装ファイルとドキュメントが要件を満たしている。
3. タスクの証跡が現在の実行ランと一致している。
4. spec レビューと品質レビューのレコードが合格している。
5. 終端の ship-verification ゲートが、現在の入力に合った 3 レベルの証跡と唯一の権威ある完全スイートで、述べられた受け入れ基準を証明している。
6. 完了準備の結果の後、slipway done が終端状態をアーカイブする。