検査と判断の境界

VibeProは、確認できる文脈と結果をレビューに渡します。変更の安全性を認定する製品でも、サンドボックスやリポジトリのアクセス制御を置き換える製品でもありません。

検査結果から分かること

• Specの参照検査で分かるのは、宣言したファイルや対応するアンカーが見つかることです。コードが要求を満たす証明ではありません。
• 検証結果は、コマンドを実行した結果です。何を確かめたかは、そのコマンドやテストの内容によります。
• レビュー記録は、確認内容と指摘を残すものです。記録するだけで、実際のレビューを代替することはできません。
• PR本文は、利用できる記録の要約です。生成できたことは、不足している作業の完了を意味しません。

利用者にとって正しい振る舞いか、安全か、確認が十分かは人が判断します。CIやリポジトリのルールも引き続き適用してください。

下書き、確定、指摘の扱い

「安全性を判定するゲートではない」とは、どんな入力でも受け付けるという意味ではありません。Specの確定には、GraphifyやStory診断を含むreadinessの条件があります。レビューを pass で記録するには、要約と .vibepro/ 外に実在する確認対象が必要です。具体的な問題を示す needs_changes・block のレビューがあっても、pr prepare はblocking状態と理由を要約して終了します。pr create はblockedの準備結果ではPR作成を実行せず、指摘が解消されるまで停止します。

違いはひとつの変更からPR準備までで説明しています。従来の広範なGate DAGや、必須のレビューライフサイクル管理は廃止しました。任意の設計判断DAGは助言であり、マージの許可を出すものではありません。

判断を記録しても、失敗が成功になるわけではない

判断記録には、選択、理由、担当者、根拠を残せます。残るリスクを受け入れたとしても、失敗したテストが成功に変わることはありません。元の結果を確認し、リポジトリのルールに従って判断してください。

普段のPR・リリース運用を使う

PRの承認、マージ、リリースには、通常のGit・GitHub運用を使います。pr prepare はPR本文用のサマリーを用意し、pr create は任意でGitHub CLIへ引き渡します。どちらも安全性の認定ではなく、VibeProがコードをマージすることもありません。

過去のリリースノートには廃止済みの仕組みも登場します。古い実行・ゲート手順ではなく、インストールした版のヘルプと現行の機能マップを確認してください。