release-verificationlisted

# リリース後テスト **配布された成果物が、利用者の環境で受け入れ条件を満たすことを確かめる。** マージ前の検証では踏めない経路がある。実物のデータ、サービス一式、導入済みの環境、 配布の手続きそのもの。これらは取り込み前には用意できない。 ## `quality-gates` との境界 | | `quality-gates` | この Skill | | --- | --- | --- | | 対象 | 取り込み前の差分 | 配布された成果物 | | 実行する場所 | 開発の作業ツリー | 利用者が受け取るのと同じ導入経路をたどった環境 | | 何を示すか | 退行を出していないこと | 受け入れ条件を利用者の環境で満たすこと | | いつ | 完了報告の前 | 版の配布が終わった後 | `quality-gates` の段階 4（結合・端から端まで）も取り込み前の検証である。この Skill は その先を扱う。 ## 開始条件 **版の配布が終わっていること。** 配布の手続き（版の更新・タグ・公開）は直前の工程である `release` が行う。それを終え、利用者が受け取れる状態になってから実行する。マージ直後に 実行すると、配布の過程で壊れるものが対象から外れる。 配布の形は対象によって変わる。開始できるかは、次のどれが済んだかで判断する。 | 配布の形 | 開始できる時点 | | --- | --- | | パッケージ・プラグイン | 版を公開し、利用者が取得できるようになった時点 | | サービス | 対象の系へ反映が終わった時点 | | デスクトップ・モバイルアプリ | 配布物が置かれた時点。ストアを経るものは審査を通った時点 | | 手順・設定の変更 | 利用者へ配った時点 | **配布の段階ごとに行う。** 検証への配布の後は検証環境で、本番への配布の後は本番で確かめる。 **検証で確かめたことは本番で確かめたことにならない。** 環境が違えばデータも設定も違い、 配布の手続きそのものも別に走る。どちらを対象にした検証かを記録へ書く。 ## 入力 新しく基準を作らない。次の 2 つを受け取る。 | 入力 | どこから | | --- | --- | | 受け入れ条件 | `requirements-design` が作った仕様 | | 未検証の項目 | `quality-gates` の完了報告の「未検証の項目」 | **「未検証の項目」がこの工程の主対象になる。** マージ前に実施できなかった条件は、 ここで実施するか、実施しない理由を残すかのどちらかにする。 ## 手順 ### 1. 対象の版を確かめ、利用者と同じ導入をやり直す **手元の作業ツリーではなく、導入経路をたどった側を見る。** Claude Code のプラグインの形では、 次を打ち、結果 JSON の `status` を見る。 ```bash python3 "$SCRIPTS/release-verification-steps.py" verify-install --ref <develop|main> --expect <版> \ [--plugins ndf,...] [--runtimes claude,codex,kiro] --root . ``` 隔離した HOME で ref から導入し、導入された版と、前の正式版のタグから変わったファイルの中身が ref と一致するか、利用者の HOME