reason

Reason

一時的で、ステートレスで、成果物を持ちません。Reason は状態を変更せず、自身に変更権限やドメイン上の権限を与えることもなく、スコア、確信度、投票を付けずに、相談結果だけを出力します。成果物、受け入れ、完了、実装に関する判断は、タスクの担当者が保持します。

Checkpoints

適用の判断基準は、タスクの規模やファイル数ではなく、判断の余地、不確実性、結果の重大さです。アプローチを選ぶ、証拠やトレードオフを評価する、または機械的なチェックでは確定できない結果を主張する作業では、アプローチを確定する前、失敗や方針変更の後、結果を提示する前に、Reason に相談する必要があります。作業の根拠となるツール、調査、本人確認、または封印の失敗は、すべて失敗です。相談を検討することや、検証していない内容を肯定することは相談ではありません。確信があることや、もっともらしい選択肢が一つあることも免除の理由にはなりません。担当者自身には見えない盲点があるためです。定型的な編集、通常の技術的な修正、判断が完了した計画の適用など、判断すべきことが残っていない作業はチェックポイントを省略します。計画との矛盾が見つかった場合は、計画の担当者に差し戻します。

各相談は、結果の重大さに応じた範囲で一度だけ行います。対象は、現在の目標、提案、または結果と、その権限と証拠、そして相談によって変更される可能性のある行動です。重要な判断では、最も有力な反対意見を示し、盲点を検証し、判断の根拠となるすべての前提を確認します。相談の最後に、検討した主張または判断、検証したリスク、そして次のいずれか一つの結論を明記した、1〜2行の結果を見える形で示します。結論は、重大な異議、証拠不足、ユーザーからの入力が必要、または重大な懸念なしのいずれかです。批判を無理に作り出したり、その結果を永続化したりしてはいけません。Reason は再検討すべき点とその理由を説明し、担当者はそれを評価し、根拠のある不足を修正します。再帰、パネル、自動的な呼び出しの連鎖は禁止です。各相談では、何が重要な判断にあたるか、結果をどこに記載するか、未解決の結論に何が必要かを確認するため、Results を読みます。担当者は、Checkpoint trace に従ってチェックポイントを報告します。

Branches

判断が必要な懸念を担当する、最小のブランチを選びます。ブランチは内部で分類を変更してもかまいません。ブランチに入る際は、ユーザー向けの結果の形式を定めたリファレンスを読みます。

• decide: 目標、証拠、対立、原因、選択肢、前提、または失敗が未解決で、正当化できる次の行動がない場合：decide の詳細。
• challenge: 具体的な提案または結果がある場合：challenge の詳細。ここでは、新たな批判的検討者に説明を依頼すべきタイミングも示します。
• ask: 証拠や範囲を限定した調査では導き出せない、ユーザーが決めるべき重要な事実、選択、好み、ポリシー、許可、リスク許容度、範囲、権限、または運用ルールによって進捗が左右される場合：ask の詳細。

どのような結果も、承認や正しさの証明にはなりません。