ship

ship - プルリクエスト段階

不変条件

• 引き継ぎ前に、必ずタスクを TASKS.md の Ready To Ship に進め、トラッカーを再度読み込んで、行が移動したことを確認します。トラッカーが古いままだと、後続処理やヘッドレスセッションが停止します。
• 中間段階がスキップされていた場合は、自己修復します。タスクが Approved にないことを理由に中断してはいけません。現在のセクションを検出し、Skipped Stages のリストを記録して、プルリクエスト本文と引き継ぎ文に明記します。
• プルリクエストを作成する前に、利用可能な出荷前チェックを実行します。
• 自動マージは行いません。
• リリースバージョンに関する作業は release 段階で行います。

ランタイムアダプターでは、この段階がスラッシュコマンド、メニューアクション、または自然言語によるスキル呼び出しとして提供される場合があります。移植可能な段階名は ship です。

ワークフロー

1. AGENTS.md を読みます。
2. タスク ID を特定し、タスクドキュメントを読みます。
3. 永続的な成果物（下表を参照）を確認して Skipped Stages を算出します。現在の TASKS.md のセクションからスキップされた段階を推測してはいけません。古くなりやすいのがトラッカーそのものなので、トラッカーを信用すると問題が再発します。
4. 出荷前チェックは引き続き有用です。成果物が不足していても出荷は妨げられません。不足分を明記するだけです。
5. プロジェクトまたはタスクに記載されている出荷前チェックを実行します。
6. 変更されたファイルを確認し、意図しない編集やシークレットがないか調べます。
7. 差分からオペレーター手順を算出します（下記を参照）。タスクドキュメントからコピーしてはいけません。
8. 適切なブランチを作成するか、既存のブランチを再利用します。
9. タスクドキュメント、テストレポート、Skipped Stages の説明、Operator Steps へのリンクを含むプルリクエストを作成します。
10. タスクを TASKS.md の Ready To Ship に移動し、現在配置されているセクションから行を削除します。
11. TASKS.md を再度読み込み、タスクの行が Ready To Ship の下にあり、以前のセクションにはないことを確認します。行が想定したセクションにない場合、移動が漏れているので、引き継ぎ前に編集します。

（これは Edit の失敗ではなく、モデルが手順を忘れることを検証するものです。この確認は簡単で、トラッカーが古くなる最も一般的な原因を検出できます。）

スキップされた段階の検出

トラッカーのセクションではなく、永続的な成果物から検出します。トラッカーは古い可能性があります。正しい情報源は成果物です。

段階	この成果物が存在する場合に「実行済み」とみなす
implement	タスクドキュメントに Implementation Notes セクションがある
simplify	タスクドキュメントに Result: PASS または FAIL を含む Quality Gate Notes セクションがある
test	docs/testing/{ID}-{task-name}.md が存在する
document	docs/learnings/{ID}-{task-name}.md が存在する、またはこのタスクに関連する機能ドキュメント／ガイドが更新されている

成果物がない段階は「スキップ」とします。スキップされた段階をプルリクエスト本文と引き継ぎに記載します。

オペレーター手順（算出）

マージだけでは変更が適用されない場合（個別にデプロイされる関数、サービス、ワーカー、マイグレーション、設定など）は、差分から必要な作業を導き出します。

• デプロイ： デプロイ可能な各エントリーポイントについて、差分がそのエントリーポイントまたはそこから推移的にインポートされるモジュールを変更しているか確認します。共有モジュールを変更すると、それをインポートするすべてのデプロイ対象に影響します。明白なものだけでなく、すべて列挙します。
• すでに稼働中か： プロジェクトでデプロイ状態を読み取り専用で確認できる場合（各デプロイ対象に到達する最後のコミットとデプロイ日時またはバージョンの比較など）は、各対象についてデプロイ済みか「デプロイが必要」かを報告します。
• マイグレーション／設定／データ： 適用順に列挙します。プロジェクトで必要な場合は、データ書き込みをオーナー実行として明記します。

結果をプルリクエスト本文に記載します。必要な作業がない場合は、「None: merge is enough」と記載します。

出荷前チェック

次のような、利用可能なプロジェクトチェックを実行します。

pnpm build
pnpm typecheck
pnpm lint
pnpm test

対象プロジェクトで利用できるコマンドを使用します。コマンドが利用できない場合は、スキップしたこととその理由を記録します。

プルリクエスト本文

## Summary

- {Change summary}

## Verification

- {Command or report}

## Skipped Stages

- {Comma-separated list, or "None"}

## Operator Steps

- {Computed deploys (with already-live status if checkable), migrations, config; or "None: merge is enough"}

## Post-Deploy Checks

- {Each `post-deploy` acceptance check and `Deferred` test check: the exact command/query and the expected result, or "None"}

## Workflow References

- Task: docs/task/{ID}-{task-name}.md
- Test report: docs/testing/{ID}-{task-name}.md or N/A
- Feature docs: {path or N/A}

引き継ぎ

Ship preparation complete for task {ID}
Task status: Ready To Ship (verified in TASKS.md)
Skipped stages: {list or "None"}
PR: {url}
Post-deploy checks pending: {count, listed in the PR, or "None"}
Next stage after merge (and deploy): run the post-deploy checks, then release