land-branch

ブランチを完了する

依頼された結果を確定し、ブランチを準備して、その結果を実行します。

不変条件

REUSE EVIDENCE BOUND TO THE CURRENT REVISION.
FALL BACK TO VERIFICATION WHEN THAT EVIDENCE IS ABSENT OR STALE.
NEVER DELETE WORK WITHOUT LITERAL CONFIRMATION.

エージェントが作成した PR のタイトルと本文は、レビュー担当者が真実を判断するための情報として維持します。パッケージ承認ループはなく、.skills/pr-packages/ ツリーもありません。

1. 意図を確定する

次の順序で確認し、最初に意図が確定した段階で止めます。

1. ユーザーの依頼に明示された意図：pr、merge、keep、discard、block（「PR を開く」のような一般的な表現も該当します）；
2. ヘッドブランチに既存の PR がある → pr；
3. docs/agents/project.md の Default landing action: の値が pr、merge、keep のいずれかである；
4. 短い質問を 1 つする：「PR、ローカルマージ、それともブランチを保持しますか？」

discard や block を推測してはいけません。明示されたアクションはすでにユーザーが選択したものです。2 つ目の選択肢メニューを表示してはいけません。

完了条件： アクションが 1 つだけ確定していること。

2. ローカルで準備する

必須：prepare.md を読み込み、Author commits まで、その後 pr と merge の場合は Ship guard と Sequence the branch into verifiable units の各セクションに従ってください。 そこでベースを確定し、メモ化します。PR の文面を作成するのは pr の場合のみです。

シーケンス化では、意図的に履歴を書き換えます。レビュー担当者は順序を読むため、その順序で主張を示す必要があります。これは破壊的な変更ではなく、アンカー付きの操作です。prepare.md では、まず復旧可能な先端を記録します。残存コミットや書き換えによる HEAD の変更があると、以前の完了レシートは古くなります。このフォールバックを担当するのはステップ 3 です。そのため、シーケンス化はここで行い、証拠の確立後には決して行いません。

完了条件： ベース、規約、コンテキスト、チケット、コミットが確定し、ブランチがアンカーを記録したうえで順序立てられ、対象範囲内の追跡対象残存項目が未処理のまま残っていないこと。

3. 境界を越える証拠を確立する

このステップは pr と merge にのみ適用されます。keep、discard、block では、ブランチが検証済みであるとは主張しません。

必須：../../execution/execute-common/close-receipt.md を読み込み、その固定検証手順を .skills/<CODE>/close-receipt.md に対して実行します。

• 有効なレシート： 使用します。同等の検証、トレーサビリティ、レビュー、受け入れ確認を再実行してはいけません。
• レシートがない、または古い： 必須サブスキル：prove-claim を使ってすべての検証コマンドを実行し、audit-trace を新たに実行します。ユーザー向けの動作が現在のリビジョンで試されていない場合、必須サブスキル：validate-feature を使います。失敗によって保留されるのは pr と merge のみです。失敗した証拠を報告し、keep、discard、block は選択可能な状態にしておきます。

このセッションに貼り付け可能な形式で保存されたブロックがある場合は、それらを再掲し、/record-debt を明記します。これらが境界通過を妨げることはありません。

完了条件： pr／merge に対して、現在のリビジョンで有効なレシート、または新たに取得したすべて成功のフォールバック証拠があること。または、境界通過を正直に保留していること。

4. 環境を検出する

GIT_DIR=$(cd "$(git rev-parse --git-dir)" && pwd -P)
GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" && pwd -P)

状態	意味
equal	通常のチェックアウト — worktree のクリーンアップは不要
differ, named branch	リンクされた worktree — 来歴を確認したクリーンアップを適用
differ, detached HEAD	外部管理のワークスペース — ローカルマージもクリーンアップも行わない

prepare.md でメモ化したベースを使ってください。トポロジーから再選択してはいけません。

5. 設定された境界のみを記録する

docs/agents/project.md に ## Decision boundaries があれば読みます。プレースホルダーではない行が land-branch:<action> または land-branch:* に一致する場合に限り、記録が必要です。セクションがない場合、または一致する行がない場合は、記録は不要です。

一致する行がある場合、副作用が発生する前に、必須サブスキルとして record-verdict を使い、確定した判定、境界の種類、ティア／述語の事実、永続的な証拠をインラインで記録します。公開に失敗した場合、設定された境界の通過は保留されます。keep の記録は決して出力してはいけません。

完了条件： 記録が設定されていないか、必須の記録が公開済みであること。

6. 確定したアクションを実行する

PR

prepare.md の Author PR text を読み込みます（必須サブスキル：speak-outer を使用してください）。 ブランチをプッシュします。シーケンス処理で公開済みブランチを書き換えた場合は --force-with-lease を使用し、 メモ化したベースに対する PR を作成または更新します。タイトルと本文はプロセスの一時ファイルからバイト列として渡し、 シェル入力として補間してはいけません。ワークツリーは維持します。

ドラフトではなく、レビュー可能な状態で開いてください — --draft を省略し、デフォルトでドラフトになるツールには draft: false を渡し、 ドラフトとして開かれた PR があればレビュー可能な状態にしてください。ドラフトは完了ではありません。prepare.md の Post the verdict に従ってステップ 3 の証拠を PR に投稿し、tickets.md の After the PR opens に従ってチケット一式を移動します。 その後、URL を報告して終了します。CI の監視には /tend-pr を指定し、ここで待たないでください。待つと次のブランチが停滞し、 後続のプッシュで再実行されるコミットに実行回数を浪費します。

ローカルマージ

明示的な意図がある場合に限り、このアクションを実行します。メインリポジトリのルートから：

git checkout "<base>" && git pull && git merge "<feature-branch>"

マージ結果は新しいリビジョンです。クリーンアップの前に、そのリビジョンに対して完全な検証スイートを実行します。 失敗した場合は、ワークツリーとブランチを維持し、失敗を報告します。成功した場合はステップ 7 を適用し、git branch -d で フィーチャーブランチを削除します。

維持

ブランチ名とワークツリーのパスを報告します。何も変更しません。

破棄

完全に削除されるブランチ、コミット、ワークツリーのパスを列挙します。ユーザーに discard という語をそのまま入力するよう求めます。 「yes」や「confirm」では承認になりません。確認後、ステップ 7 を適用し、git branch -D で削除します。

ブロック

終了時のブロック理由を報告し、ブランチはそのまま残します。

完了条件： 解決されたアクションが完了するか、具体的な失敗を伴って実行が見送られたこと。

7. ワークツリーのクリーンアップ

ローカルマージの成功後、または破棄の確認後に限り適用します。

• .worktrees/ または worktrees/ 配下のワークツリー、あるいは .isolate-workspace/ または isolate-workspace/ 配下に残ったツリーのみを削除します。
• ハーネスが所有するワークスペースや外部管理のワークスペースは削除しないでください。
• 削除の前にメインリポジトリのルートへ cd し、その後 git worktree prune を実行します。

8. 作業を完結させる

PR またはマージ後に、フィーチャーの Status: を確認します。

Status	Action
Draft	承認がないことを報告し、状態を移行しない
Approved / In-progress + すべてのタスクにチェック済み + トレースがクリーン + 完了の証拠あり	必須サブスキル：realign-spec を使用
Approved / In-progress + 証拠が一部のみ	不足している証拠を報告
Implemented / Shipped、ドリフトなし	スキップ
Implemented / Shipped、ドリフトあり	必須サブスキル：realign-spec を使用

PR、マージ、または維持の場合、複数タスクやリスクのあるパスが含まれていれば /understand <range> を指定します。 これは任意であり、解決されたアクションを見送る理由にはなりません。

注意すべき兆候

• 現在のリビジョンに有効なレシートですでに証明されているチェックを再実行する
• ベース、HEAD、クリーンなツリー状態、または必須スロットが条件を満たしていないレシートを信頼する
• ユーザーがすでに明確な意思を示しているのに、選択メニューを表示する
• サンプル、調査資料、チーム向けブリーフ、または負債記録を理由にPR／マージを保留する
• 一致するプロジェクト境界設定が存在しないのに、意思決定記録を公開する
• 「これを取り込んで」という指示から、ローカルでのマージ、破棄、またはブロックを推測する
• マージ後の結果が検証に合格する前に、ワークツリーを削除する
• 破壊的操作の確認で、文字どおりの discard 以外を受け入れる
• 復旧可能なアンカーを先に記録せずに、ブランチを書き換える
• 実行系タスクのコミットを書き換え、判定結果と判定対象を切り離す
• 書き換え前に確立された証拠を再利用する
• .skills/pr-packages/ に書き込む、またはPRテキストの承認ループを追加する
• scripts/ship-guard.sh が lockfile、generated、または out-of-plan の行をまだ出力しているのに、プッシュする

考え	実際のところ
「HEADがまったく同じでも、最新であるには再実行が必要」	レシートはそのリビジョンに証明を結び付けます。作業を再実行するのではなく、その結び付きを検証してください。
「認証パスがあるなら、サンプリングをブロックする必要がある」	サンプリングは人の注意を割り当てるものです。レビューと承認の後は参考情報として扱います。
「PRを開くのは、メニュー上の好みでしかない」	それは明確な意思表示です。証拠が揃ったら実行してください。
「境界を越えるたびに、個別の記録が必要」	プラットフォームの履歴をデフォルトとし、独自の記録はプロジェクトポリシーで選択された場合にのみ作成します。