tk-drive

Drive の実行

ユーザーが /tk-drive、$tk-drive、またはソースを含むホストのスキルピッカーを 明示的に選択した場合にのみ開始します。ソースなしで再度呼び出された場合は、同じ会話内の 現在のソース、台帳、Git、リポジトリの根拠が、単一の approved または pending の実行を 明確に示している場合に限り再開します。一般的なリクエスト、成果物、新しい session によって Drive を開始または再開することはありません。

権限と不変条件

1 つの承認済み計画により、preparation、direct または delegated による単位実行、必須の 検証、承認済みの各単位につき 1 つの検証済み現在ブランチコミット、最大 3 回の 修正ラウンド、総合検証、最終化を行えます。push、PR、merge、tag、release、公開、履歴の書き換えは含みません。

Drive はコントローラーです。Delegated strategy では、プロダクト、テスト、設定の変更を 直接記述せず、範囲を限定した単位を新しい作業者に割り当てます。Direct strategy では、 現在のコンテキストが一時的にコントローラーの役割を離れ、承認された単一の単位の実行者となり、 凍結された担当パスのみを変更します。これはコントローラーの代替経路ではありません。このスキルはユーザーが呼び出すものであり、明示的な /tk-drive または $tk-drive の呼び出し自体が、ホストの user-requested AgentTool 条件を満たします。 Mechanical Git bookkeeping は、最終候補が合格した後に限り、コントローラーが担当できます。 ホストが利用可能な作業者を delegated strategy でディスパッチできない場合は、Blocked で 停止します。Direct strategy は承認済み計画の記録後に変更を開始するものであり、 作業者が利用できない場合の暗黙の代替経路ではありません。 Executor は、他のユーザー所有の TigerKit ワークフローをオーケストレーションしたり、呼び出したりしません。

ライフサイクル（Lifecycle）

Prepare -> Execute -> Close gaps -> Finalize

Drive がこのライフサイクルを管理します。Child receipt は内部資料であり、continue、 /clear、モデルの切り替え、2 回目の呼び出しを要求しません。ホスト／プロセスの 境界を越えた後は、cursor や lifecycle claim ではなく、新しい根拠から次の アクションを導きます。

情報源の優先順位

現在の会話での明示的なユーザー要件と、同じ会話内で確定した決定が、最も新しい 正式な情報源です。優先順位は次のとおりです。

현재 대화의 명시적 요구
> 같은 대화의 확정 결정
> 승인된 활성 run
> 현재 source와 일치하는 Ready 작업 문서
> 과거 terminal 문서와 durable prior-art

過去の Status: Pass 台帳や完了文書が、現在のリクエストに優先することはありません。現在の 会話が完全な情報源であり、目標・範囲・R/AC・検証義務を導き出せる場合は、過去の 文書が古かったり系譜が異なったりしていても、supersedes の根拠を記録し、現在の作業 文書 3 つを新しい系譜で発行します。現在の情報源が不完全・矛盾・危険である場合、 またはユーザーの決定が必要な場合に限り、Blocked とします。

作業者には、会話そのものではなく、現在の情報源を反映した自己完結型の作業文書を 渡します。したがって、過去の文書を読んだという理由だけで現在の要件を見落とすことはなく、 現在の情報源が会話内にあるという理由だけで作業文書の完全性チェックを省略することも ありません。

準備（Prepare）

1. 完全なソースと適用されるリポジトリ指示を読みます。まず、現在の対象チェックアウトで git rev-parse --show-toplevel を実行してリポジトリルートを確認し、その結果を <repository-root> に置き換えて、次の4つの絶対パスを導出してすべて読みます。 <repository-root>/.tigerkit/drive.md、<repository-root>/.tigerkit/spec.md、 <repository-root>/.tigerkit/tickets.md、<repository-root>/.tigerkit/implement.md。 オプションの <repository-root>/.tigerkit/session.md がある場合は、モデルルーティングのソースとして読みます。ただし、欠落していること自体は作業文書をブロックする理由として扱いません。 drive.md が所有するのは進捗、承認、レシートのみです。詳細な要件と指示は3つの作業文書にのみ記載します。まず、現在の会話ソースの識別子と明示的な指示を固定し、過去の終了済み文書は先行根拠として分類します。 文書ルールと 作業者ソースルールに従い、現在のソースが完全であれば、欠落している文書と古い／系譜が一致しない終了済み文書から、新しい Pending 作業文書を発行し、supersedes を記録します。ユーザーが提示された計画を承認したら、その文書を Ready に更新します。現在のソースが不完全・矛盾・危険である場合、または文書が Pending で未承認の場合に限り、正確な状態で Blocked にし、作業者の割り当てや製品の変更は行いません。ブランチ、ベースライン HEAD、作業ツリー、pre-existing の変更パス、および関連する永続的な先行根拠を最大7件まで記録します。
2. 根拠と安全な既定値に基づいて、元に戻せる曖昧さを解消します。重要なコントローラーの選択、その根拠、および動作を変える代替案をすべて記録します。ユーザーが所有する決定によって安全な実行計画が妨げられる場合に限り、tk-grill-me を呼び出します。質問が pending の間は、🙋 drive > grill-me · 応答必要 を出力し、作業者をディスパッチしません。限定的な比較で当該決定を確定できる場合に限り、tk-prototype を使用します。
3. 現在のソース識別子と置き換えの系譜、スコープ、除外事項、凍結されたユーザー向けリテラル、検証義務を含む Ready の要件と受け入れ基準を作成します。
4. 独立して検証可能な 1..N の単位、依存関係グラフ、ウェーブを導き出します。結合している単位や不確実な単位は直列化します。ホストがすでに分離されたチェックアウト／作業ツリーを提供している場合に限り、独立性が証明された単位を並列化します。スケジューラーを作成したり、変更可能な作業ツリーを作業者間で同時に共有したりしません。
5. テスト／検査を分類します。browser-visible の AC がある場合は、正確なシナリオ、対象、機密情報を含まない認証モード、前提条件、制限事項を計画し、検証を tk-browser-verify に handoff します。その AC に開発サーバーが必要な場合は、正確な command／cwd／対象 URL／auth mode／readiness 条件もあわせて引き渡します。Drive／controller／worker／direct executor はブラウザツールや開発サーバーを直接起動・待機・終了しません。サーバーの PID／port／log／readiness とクリーンアップは tk-browser-verify が所有し、verifier の結果が出るまで commit しません。それ以外は not-required として記録します。必須の headless auth を使用できない場合、または verifier handoff がない場合は、mutation の前に Unverifiable とします。
6. worker-dispatch.md に従って各単位の実行 strategy と最小 model を選択します。チケットですでに確定している model／effort があれば計画メタデータとして使用し、黙って上書きしません。隔離されていない bounded known-pattern の場合は、セッションモデルを維持する strategy=direct を優先して推奨します。新しいコンテキスト・隔離・レビュー担当者への handoff・設計中心の推論が必要な場合は、根拠を添えて delegated を推奨します。Delegated では、現在のホスト section がある .tigerkit/session.md の routing を、skills/tk-drive/references/worker-dispatch.md#session-model-routing の正規の schema で検証して使用します。ファイルまたは現在のホスト section がなく、3つの class の制御値がすべて確認できる場合は、正確なネストされた block を自ら .tigerkit/session.md に草案として作成し、Status: Pending にします。既存の不完全な block や競合する block は上書きせず、修正案を提案します。routing_state=review-required を記録し、ユーザーが草案を確認・承認するまでは、ファイル以外の worker、製品、Git、remote を変更しません。承認後に限り Status: Ready に変更し、reread して検証します。実行可能な delegated 単位の承認には、model class、selector、effort、routing ソースがすべて表示されている必要があり、欠落があれば Blocked とします。general-purpose の implementer と、新しいタスクのレビュー担当者をペアにして使用し、返却ラベルは tier 判定に使用しません。Model class／selector／effort の選択は delegated 専用です。Direct の承認と台帳には、cheapest | standard | strongest の tier をどのラベルでも付けず、model_class=n/a、requested_selector=n/a、ホストが公開するセッションの realized_model または unavailable、reasoning_effort=inherited を記録します。
7. ledger.md に従い、.tigerkit/drive.md の現在の進行状態をアトミックに置き換えて読み直し、簡潔な承認画面を1つ提示します。Ledger には、現在のソース識別子、supersedes の対象、リポジトリの状態、4つの作業文書と任意のセッションパスおよび状態、文書の status／lineage check、承認スナップショット、単位／dispatch／検証レシートのみを記載します。Goal、スコープ、凍結されたリテラル、R／AC、実装指示は3つの作業文書が所有し、不明な値は unavailable とします。👍 Recommendation: には strategy、model class、selector、effort、ルーティングソースを含めます。ユーザーがこの計画を承認することが、direct strategy の明示的な承認となります。別途 direct の確認は求めません。これは独立したライフサイクル出力ではなく、承認の根拠となるものです。 承認の質問が作業の境界です。🙋 drive · 응답 필요 と正確に 1 つの 👍 Recommendation: を表示します。 承認は表示されたスナップショットにのみ適用されます。重要なソース、範囲、ブランチ/head、 リモートの状態、検証の前提条件、取り消せない判断にドリフトが生じた場合、承認は無効になり、Prepare に戻ります。 計画に変更がなければ、日常的な 2 回目の承認は求めません。

実行（Execute）

依存関係の各ウェーブに、凍結された戦略を適用します。Delegated 単位は新しい general-purpose 実装担当者が受け持ち、direct 単位は現在のコンテキストが唯一の 境界を限定した実行者として受け持ちます。 Executor には、ID/goal、正確な R/AC、ソース/チケットの範囲、範囲/exclusion、関連 パスと、現在の対象 checkout で解決した <repository-root>/.tigerkit/ 以下の 4 つの 絶対パス、検証義務、ブランチ/head/diff の所有権を渡します。 Direct 単位は subagent を spawn せず、focused test とセルフレビューの後、候補を controller に返します。Delegated 単位は dispatch 前にホストの作業者 capability と承認済み session selector を確認し、native model control に明示します。実装担当者には task brief/report のパスを渡し、質問・実装・focused test・セルフレビュー・commit の後に短い report を 受け取ります。その後、新しい general-purpose レビュアーに diff package を渡し、 Spec compliance と Task quality の 2 つの verdict を受け取るまでは delegated 単位を完了として扱いません。各 delegated 作業者の後に、要求した selector とホストが公開した realized model receipt を記録し、公開されていない値は unavailable とします。general-purpose が返されること自体は 失敗ではありません。次の不変条件を守ります。

candidate -> required tests/checks/browser verifier -> Close gaps
          -> bounded fresh correction when needed -> one verified unit commit

必須 verifier は commit 前に最終候補を対象として実行します。検証済みの所有パスのみを stage し、pre-existing のユーザー変更を保持します。Direct 単位の隔離された gap は、同じ凍結単位と所有パスの範囲内で現在の実行者が解消し、delegated 単位の gap は新しい corrective 作業者を dispatch して、影響を受けた義務を再度 実行します。最大 3 round を優先します。不足しているコンテキストは model upgrade なしで 補います。立証された推論の失敗がある場合に限り、1 段階強い新しい 作業者を 1 回だけ使用します。失敗が変わらない、原因を隔離できない、競合する、 または範囲を広げる状態が繰り返される場合は、変更を停止します。

統合の競合は、独立性の判断が誤っていたことを意味します。影響を受けた単位を 直列化するか、再度 Prepare します。作業者が意味的なマージを独自に作成する ことはありません。隔離、統合順序、stale-base/conflict detection、クリーンアップは Drive が所有します。

ギャップを解消する（Close gaps）

承認済みの各 R/AC について、観察された根拠を satisfied、missing、partial、 unverifiable のいずれかに分類します。Acceptance に関連する範囲/exclusion、 単位、verifier、外部に表示される動作、commit/ancestry、dirty パスの 所有権、根拠の鮮度のみを確認します。その acceptance の事実と無関係な 発見事項は省略します。

根拠だけでは確信を持って判定できない場合は、同じ狭い R/AC brief を 使用する、より強力な新しい非変更レビュアーを最大 1 回 dispatch します。 ユーザー/リポジトリのポリシーが独立レビューを要求する場合に限り、利用可能な built-in または third-party レビュアーを使用します。Required review を利用できない 場合は Unverifiable です。すべての修正は、引き続き新しい corrective 作業者に 割り当てます。

最終化（Finalize）

Delegated 単位が 1 つでもある場合、または承認済み計画が独立した最終レビューを要求する場合に限り、 新しい general-purpose 全ブランチレビュアーを 1 回 dispatch し、全体の diff の Spec/AC と 品質を確認します。すべての direct 実行では aggregate checks とセルフレビューのみを使用します。delegated レビューで発見事項があった場合は、新しい corrective 作業者 1 人と、範囲を限定した re-review 1 回のみを実施し、 重要な残存事項は Blocked のままにします。 すべての verified 単位の commit 後に、aggregate R/AC のトレーサビリティ、リポジトリの check、 ancestry、exclusion、鮮度を再確認します。Unit commit、verifier/gap の 根拠、修正ラウンド、総合結果、復旧の事実を含めるように .tigerkit/drive.md を更新します。成功でない場合は変更を凍結し、 non-success-finalization.md に従います。

成功した場合は、簡潔な動作結果、役立つ単位 commit、1～4 個の総合検証、 正確に Status: Pass を出力します。実行中の terminal 応答を出力するのは Drive のみです。Child receipt、raw log、dispatch model、 progress marker は省略します。