ship-it

リリースする

承認済みプランから、記録された最終的なリリース状態に至るまで、実行を最後まで担います。リポジトリに新たな証拠が見つかり、重大な矛盾が生じない限り、決着済みのプロダクト上の判断を蒸し返してはいけません。

スコープと権限

ワークフローのデフォルトより、ユーザーが明示したスコープと適用される既存の権限を優先します。確立された規約に従って、許可された準備と元に戻せる作業を続けます。確認を求めるのは、重大な未決事項がある場合、または既に付与されていない権限が必要な場合に限ります。エンジニアリング上の安全策とアクセス制御を維持します。スキルが進行を妨げる場合は、該当する具体的な指示と実際の競合を特定し、独立して許可されている作業を続けます。

読み取り専用または変更禁止の依頼では、書き込みが明示的に許可されていない限り、プラン、状態、メモリ、設定、ナレッジの記録を作成または更新せず、チャットで調査結果を返します。古い成果物より現在のユーザーの修正を優先し、書き込みがスコープ内の場合に限り、それらの成果物を更新します。

必須の引き継ぎ

承認済みプラン、ブリーフ、エピソードの状態、調査結果の処置、ワークツリー、想定するベースブランチとリリース経路、検証要件、実装を委任するかどうかの判断を確認します。内容に食い違いがあれば、編集前に停止し、永続化された成果物間で整合性を取ります。

圧縮や中断の後は、エピソードの状態と現在の Git／PR の状態から復旧します。チャットの記憶からタスクを再構築してはいけません。

実行中にユーザーがスコープ、アーキテクチャ、ブランチの対象、検証、モニタリング、または完了処理を修正した場合は、続行前にその修正をエピソードの状態に記録します。影響がある場合はブリーフまたはプランとの整合性を取り、古くなった検証／レビューのフェーズだけを無効にします。ユーザーに同じ判断を繰り返させてはいけません。

実装の委任

明示されたタスクの選択、保存された implementation_delegation_default、それがない場合は auto の順に、never、auto、always を決定します。ユーザーまたはハーネスによる明示的な制限が優先されます。キックオフスキルの references/config.md に従い、プレイブックのコード担当ロールから各ワーカーを決定します。

auto でワーカーを選択した場合、またはモードが always の場合は、ワーカーの決定、実行マニフェスト、範囲を限定したディスパッチ、統合、一時成果物のクリーンアップについて、references/delegation.md を読みます。

• never：オーケストレーターが実装します。
• auto：fast と full のルートでは、オーケストレーターがレビュー担当に専念できるよう、コードの作成を委任します。その利点は行数の削減ではなく、レビューの分離です。独立したレーンが重複しないファイルを担当する場合に限り、プレイブックのスループットチェックポイントに沿って、さらに作業を分割します。tiny な変更は、レーンが本当に独立している場合を除き、オーケストレーターが担当します。
• always：範囲を限定したタスクを少なくとも1つ委任します。設定済みのワーカーを利用できない場合は停止します。

ワーカーには、ブリーフ、プラン、エピソードの状態、調査結果、リポジトリの指示、および簡潔な実行マニフェストへのパスを渡します。会話全体を送ってはいけません。共有スキーマ、順序付け、統合、最終検証はオーケストレーターが担当します。

ワークフロー

1. ワークツリー、ブランチ、ベース、変更の有無を確認します。無関係な作業は保持します。
2. 実装手順を、承認済みの計画項目および調査結果 ID に対応付けます。
3. テストファーストで進められる場合はそうしながら、要件を満たす最小限の変更を実装します。
4. すべてのワーカーの差分を確認し、スコープの拡大を却下します。
5. 実装中は対象を絞ったチェックを実行し、最終ヘッド SHA でリポジトリ全体の検証と受け入れ検証を行います。変更のない内容と環境については検証結果を再利用し、新しいワークフロー段階に移っただけでチェックを繰り返すのではなく、修正または統合後に影響を受けるチェックを再実行します。
6. 以下からレビュー方式を選択し、記録します。リスクが低く、小規模な差分では、簡潔さと正確性を確認する集中的なレビューを1回行う方式を使用できます。それ以外の空でない差分では、専用の ponytail-review に続けて code-review を実施します。
7. 選択したレビュー方式で見つかった簡潔さに関するすべての指摘に対応するか、明示的に処置を記録します。code-review の P0／P1 の指摘を解決し、P2 の指摘は解決するか、明示的に処置を記録します。エピソードの状態を更新します。
8. PR で提出する場合は、意図するベース、承認済みの成果物、最終検証、リスク、監視要件を指定し、Babysit モードで create-pr を実行します。直接提出が明示的に許可されている場合は、以下の直接提出契約に従います。
9. 返された提出記録が意図したローカル／リモートの参照先と一致し、該当する監視の証拠または具体的なブロッカーを含んでいることを確認します。
10. 終了状態に達するまでレビューのループを続け、その後、クローズアウトを行います。

実装レビュー

combined は、リポジトリのポリシーで許可されている場合に限り、既存の確立されたパターンに沿った小規模な差分で、重大な曖昧さ、セキュリティ／データリスク、互換性への影響、または調整作業がない場合にのみ使用します。集中的な code-review では、不要な仕組みと正確性の両方を確認し、その理由と指摘を記録します。Ponytail がインストールされていなくても、この方式を妨げることはありません。スコープが拡大した場合は、方式を再評価します。

その他の空でない差分、またはユーザーやリポジトリから要求された場合は、separate を使用します。

1. ponytail-review には、最終差分、概要、承認済みの計画、リポジトリの指示を渡します。会話全体は渡しません。レビュー対象は、削除可能なコード、重複した処理経路、既存機能の再実装、推測に基づく抽象化や柔軟性、不要な依存関係、および規模を縮小する機会に限ります。要件と安全策は維持します。出力と、削除可能と見積もった行数の純減をエピソードの状態に記録します。
2. code-review は、同じヘッド SHA について、正確性、動作、回帰、アクセシビリティ、セキュリティ／プライバシー、互換性、信頼性、テストカバレッジをレビューします。Ponytail のレビューを、正確性の根拠として扱ってはいけません。

Ponytail で指摘がなければ、Lean already. Ship. と記録します。指摘があれば修正するか、その仕組みが必要である具体的な理由を記録します。変更後は、影響を受ける検証を再実行します。実装に重大な変更を加えた場合は、選択したレビュー方式を再実行します。コメント、書式、メタデータのみの編集では再実行しません。

separate レビューが必要で、ponytail-review を利用できない場合は、simplicity-review の delete、reuse、compress の手法を差分に適用する新しい子プロセスとして、簡潔さのレビューを実行します。代替したことを記録します。簡潔さのレビューを、正確性レビューにひそかに組み込んではいけません。

直接デリバリーの契約

ユーザーの現在の指示で明示的に許可されており、リポジトリのポリシーでも認められている場合に限り、PR を経由しない手順を使用してください。デリバリーの直前に、対象ブランチ、リモート、正確なコミットセット、現在の HEAD の検証、適用されるレビューの判定結果を確認してください。確認はツールによるチェックであり、すでに許可が明確な場合に、ユーザーへ再確認することではありません。共有履歴を書き換えずにデリバリーし、その後、リモートの対象 SHA と、必要な CI、デプロイ、または昇格の状態を読み戻して確認してください。意図したリモートの状態が検証できた場合に限り、ステータスを delivered-direct として記録してください。それ以外の場合は、正確な不一致または外部要因を添えて、ステータスを blocked として記録してください。

直接デリバリーでは create-pr を呼び出さないでください。デリバリー契約で必要とされ、利用可能な自動化で該当状態を監視できる場合に限り、ブランチまたはデプロイの監視を設定してください。直接の統合が検証された後は、「クローズアウト」で説明されているものと同じ Forest のクローズまたは保持の判断を行ってください。

原子的な PR と監視ゲート

以下をすべて記録するまで、PR の作成は完了していません。

• PR の URL と番号。
• head/base ブランチと head SHA。
• 初期のマージ可能性／チェック状態。
• 監視が必要な場合は、watch_status: active と監視の仕組みおよび ID、または正確な理由を添えた blocked。それ以外の場合は、許可の根拠を添えた not-applicable。
• 終了条件。

統合が、Git の祖先関係、意図した base に対する検証済みパッチ／集約の同等性、または正確なマージ済み PR head の証拠のいずれによって証明されているかを記録してください。マージ済み PR を根拠とする場合、クローズ対象の worktree と照合し、そのリポジトリ、番号、head SHA、base ブランチ、マージ済み状態を検証してください。追加のコミットがある場合は、それらが統合されたことも別途証明してください。upstream の追跡参照がないことだけでは、未公開の作業があるとは証明されません。正確なマージ済み PR head の証拠は公開済みであることを示せますが、古い証拠や一致しない証拠によって、Forest の未コミット変更または統合に関する保護措置を回避することはできません。

ユーザーから「監視していますか？」と聞かれた場合は、現在有効な監視記録を検証してください。意図、ToDo リスト、または以前に一度だけポーリングした結果を根拠に回答してはいけません。

対応可能なレビューまたは CI のフィードバックがある場合は、キックオフの Babysit プレイブックを実行してください。現在の HEAD に適用されることを確認し、許可された範囲内でのみ修正し、検証し、プッシュし、状態を更新して、監視を再開してください。記録済みの land 許可がある場合に限り、キックオフの Shipping プレイブックを通じてマージしてください。

デリバリー状態

• ready-to-merge：現在の HEAD はマージ可能で、必要なチェック／レビューに合格しているか、意図的に省略されており、対応が必要な指摘事項は残っていません。受け入れられたデリバリー経路が PR の準備完了をもって終了する場合に限り、これを終端状態とします。land 許可のあるエピソード、またはマージまで追跡する管理対象 worktree では、これはマイルストーンであり、監視は静かに継続します。
• merged：マージと最終 SHA が検証済みです。必要な worktree のクローズまたは保持の判断、およびその他のクローズアウト証拠を記録した後、エピソードは終端状態になります。
• delivered-direct：PR を経由せず、明示的に許可されたリモートの対象と最終 SHA が検証済みであり、必要なデリバリー監視とクローズアウトも完了しています。
• canceled：ユーザーまたはリポジトリの所有者が、作業を明示的にキャンセルしました。
• blocked-external：具体的な外部要因によって進行できず、必要な次の担当者／アクションとともに記録されています。

チェックが保留中のオープン PR は、終端状態ではありません。

クローズアウト

最終検証、PR の状態、該当する場合はデプロイ／プロモーションの状態、未解決の制約、永続的なアーティファクトの保存場所、タスク記録の照合、一時アーティファクトのクリーンアップ、作業ツリーの処置を記録します。

管理対象の作業ツリーを閉じる際は、作成元のバックエンド（T3、Forest、または git）を通じてのみ行い、統合が確認済みであるか、ユーザーまたはリポジトリのポリシーでクローズが許可されている場合に限ります。スカッシュマージでは明示的なリモートの証拠が必要な場合があります。祖先関係の不一致を、未マージと取り違えないでください。

クローズアウト時には、対象の作業ツリーと現在の所有者を改めて確認し、該当する最新の明示的なタスク指示、または保存済みのユーザーによるクローズ／保持の判断を特定して、その出典を記録します。所有するタスクと、それに関連するターミナル／プロセスが、対象の正確なパスを現在使用しているか確認し、その確認と結果を記録します。古いアクティビティのタイムスタンプは、非アクティブである証拠にはなりません。稼働中かどうか判断できない場合は、所有者への引き継ぎまたは確認で解決するまで一時的に保持します。一時保持する場合は、所有者と再確認のトリガー（review/testing complete または merge）を記録し、そのトリガー発生後の再確認を、指名した所有者またはフォローアップに引き継ぐか、該当する権限を持つ監視を維持します。稼働中の作業ツリーはクローズできません。

バックエンドが Forest の場合は、各クローズ用 CLI のコマンド名、解決された実行ファイルのパス、報告されたバージョンをエピソードの状態に記録します。forest close の前に、無視対象の名前を列挙し（例：git ls-files --others --ignored --exclude-standard）、リポジトリの指示または対象を絞った確認で特定された関連する名前のみを調べ、関連する固有の証拠／設定を許可された永続的な保存先に保持し、コピーした内容をハッシュで検証します。秘密情報の内容は表示せず、名前とハッシュを記録します。

統合が確認済みで、コミットされていない作業またはプッシュされていない作業がない場合は、forest close を実行し、Forest の状態、git worktree list --porcelain、正確なディスク上のパスを記録します。一部のみ、または未検証のクローズは closure-blocked のままとし、所有者、内容、ブランチ、監視を維持して、失敗した対象を記録します。保存された Forest のベースが見つからない、または解決できない場合は、クローズをブロックします。ローカルで解決可能なベースの復元がすでに許可されている場合に限り復元し、Forest のクローズ確認を再実行します。PR のメタデータから Forest の状態を推測したり、書き換えたりしないでください。未解決の変更と保持に関する判断は維持します。クローズの権限がない場合に限り、一度だけ確認を求めます。必要な判断またはクローズが保留中のまま、最終クローズアウトを行わないでください。

エピソードの状態に基づいて、簡潔な最終レポートを返します。エピソードの実際の終了条件に達した後は、監視を稼働したままにしないでください。クリーンアップが未解決のマージ済み PR は、未解決の処理がこのタスクの担当である一時保持の再確認を含め、まだ終了状態ではありません。クローズの確認、恒久的な保持、または明示的な再確認の引き継ぎ後は、ユーザーが追加の監視を求めていない限り、監視を停止します。監視が対象範囲外の場合は、監視を設定しないでください。