requirement-convergence

name	requirement-convergence
description	変更が生むべき成果と、そこへ至るために提案された要件を切り分け、ユーザーが除外したものを記録し、コストを構造からバンドで見積もる。要件がワークフローに入った時点、設計を始める前、または「どこまでやるか/スコープ外は何か/やる価値があるか」が言及された時に使用。

要件収束

目的

要件は、膨らんだ状態、曖昧な状態、狙う成果を外した状態で届く。能力の高いモデルはその3つをまとめて筋の通った計画に組み直し、忠実に作り上げてしまう — 求められたものが間違っていたときに、求められたとおりのものを届けることになる。

このスキルは何を作るかを収束させる。どう作るか、そして変更にどのドキュメントが必要かは、何を作るかが決まった後に定める。

収束フィールド

フィールド	通過条件
outcome	観測可能な結果が1つ。それに寄与しない要件は余剰である。
requirements[]	作る対象に関わる各項目に current-state または desired-future のラベルが付いている。
nonGoals[]	ユーザーが挙げたもの。または、除外すべきものはないとユーザーが述べたこと。
cost	バンド1つと、それを決めた構造上の根拠、および残っている不明点。

cost は粗いバンドであり、作業計画書がスケジュールの根拠にする工数見積ではない — 要件の段階では人日を支えられない。その不明点は、大きさよりも判断上の重みを持つ。

評価依頼、推測的なアイデア、指定された実装手段に分類された依頼シグナルは、収束中の判断材料として扱う。requirements[] や永続的なドキュメントに入れるのは、ユーザーが明示的に採用したものだけとする。

各フィールドは自身の readiness ラベルを持つ: ready、weak、weak-but-explicit（weak だが、未解決のまま残すことにユーザーが同意した状態）。weak-but-explicit を設定できるのはユーザーだけである。該当する全フィールドが ready または weak-but-explicit になった時点で、要件は収束したとみなす。

フィールドごとの判断ルール: references/criteria.md。

ヒアリングプロトコル

聞き出す作業と判定の両方をオーケストレーターが担う。アナライザーが出したスコープとコストのエビデンスを用い、リポジトリからは答えられないプロダクト上の選択のみを尋ねる。アナライザーを再実行するのは、回答が分析対象または必要なスコープエビデンスを変える場合のみとする。

開始前に以下のステップを登録し、完了ごとにその根拠を記録する:

ステップ	行うこと	完了の根拠
1	分析が出したスコープの事実を述べ、そこから要件について何が言えるかを分けて示す	事実が、その出所となった分析出力とともに列挙されている
2	ready に達していないフィールドについて、1メッセージあたり最大2問で質問する	ready に達していないフィールドごとに1問
3	各回答をそのフィールドの値として記録する	値が、ユーザーが選択した選択肢、またはユーザーが述べた言い回しになっている
4	記録した値がまだ通過条件を満たさない場合は1度だけ聞き直し、2度目の回答のままでよいとユーザーが同意した時点でそのフィールドを weak-but-explicit とする	記録された回答が2つ、またはそこで止めることへのユーザーの同意
5	各フィールドを通過条件に照らして判定し、完成した記録を下流へ渡す	全フィールドにラベルが付いた収束記録

保存プロトコル

保持先	保持する内容	書き込む主体
オーケストレーターの収束記録	全フィールドとその readiness ラベル	オーケストレーター
PRD の 成功基準 と Out of Scope	outcome、およびユーザーが挙げた nonGoals	PRD を所有するエージェント
Design Doc の Requirement Convergence	PRD がない場合は上と同じ内容。加えて weak-but-explicit のまま残ったフィールドは常にここへ記録する	Design Doc を所有するエージェント

どちらのドキュメントも生成しないフローでは、記録を自身のコンテキストで次のステップへ運ぶ。

参照プロトコル（下流の消費者向け）

1. プロンプトから収束記録を読む。
2. nonGoals は今回の変更から除外し、desired-future 要件を作る対象として扱う。採用されていない評価依頼、推測的なアイデア、指定された実装手段は下流の作業を生まない。評価した選択肢を判断の履歴として残せるのは、承認済みADRがそれを扱う場合だけである。
3. weak-but-explicit のフィールドは、確定した判断ではなく記録された未解決の論点として扱い、作業がその解決に依存する場合はエスカレーションする。

品質チェックリスト

• 質問の前にスコープの事実を提示した
• nonGoals がユーザーから出たもの、または除外すべきものはないとユーザーが述べたものになっている
• 該当する全フィールドが ready、またはユーザーの同意による weak-but-explicit になっている

References

• references/criteria.md — フィールドごとの判断ルール、コストの入力、チャレンジの強度、手段すり替えの検出