ains-ship

機械で確かめられることを先に済ませ、人には判断だけを渡す。人の確認時間がいちばん希少だからだ。結果は PR 本文の雛形 assets/pr-body.md に集める。

1. 決定的な検査

型、lint、テスト、秘密情報と依存の検査のうち、プロジェクトにあるものをすべて実行する。失敗したら ains-tdd で直して再実行する。通らない検査が残る変更は先へ進めない。

2. 受入条件ごとの証拠

spec.md の受入条件を1つずつ、書かれた検証方法で確かめ、pass / fail / 未検証 と証拠を書く。

• テストが受入条件を本当に主張しているかを読む
• 出力の文字列一致ではなく、要求した振る舞い（形式、性質、境界）で判定する
• すべての条件の期待結果を、利用者の操作、業務知識、既存の契約のいずれかと照らし、照合元を書く。仕様とテストは同じ誤解から作られうる。照らせなかったものは未検証にする
• 画面操作や業務フローに関わる変更は、実際の操作や業務責任者の確認が要るかを書く。テストが通ることと、利用者の問題を解くことは別だ
• Agent skills 節に現行仕様の置き場所があれば、変わった振る舞いを同じ PR で現行仕様に反映する

3. レビューと判定