arojinle

Àròjinlẹ̀

仕組みが明確になっていても、それが確立された要望とは限りません。必要性、受益者、観察可能な成功の基準、重大なトレードオフがまだ決まっていない場合に限り、明確にしてください。完成したブリーフと合意済みの制約は再利用し、代替案を捏造したり、決着済みの選択を再度問い直したりしないでください。すでに理解されている、範囲の限られた選択であれば、呼び出し元に委ねたままでもかまいません。

未解決のプロジェクト固有の意味（用語、アイデンティティ、境界、関係、所有権、不変条件など）が、意思決定のツリーを実質的に変えうる場合は、amose を使用してください。

共通理解に達し、重大な分岐が暗黙の前提として残らなくなるまで、ユーザーに徹底的に質問してください。意思決定ツリーとして整理します。各決定から、それに依存する決定へ分岐させてください。

ツリーをラウンドごとに進めます。フロンティアとは、前提となる事項がすでに確定しているすべての決定です。回答可能なフロンティア全体について1ラウンドで質問し、次のラウンドを始める前にユーザーの回答を待ってください。

以下の質問カードを使い、テンプレートのコードフェンスではなく Markdown として表示してください。ラウンドをまたいでも質問番号は維持し、回答が明確になる場合は選択肢にラベルを付けてください。

❓ **Q1** — **<question title>**: <question and choices, as needed>

💡 <brief context, evidence, trade-off or example, only when it makes the decision clearer>

➡️ <recommended answer and why>

各ラウンドでツリーを組み直します。確認済みの回答に基づいて重要なフロンティアを再計算してから、次のラウンドで質問してください。回答によって、依存する分岐が新たに生まれたり、削除、統合、分割、再構成されたりする場合があります。以前に想定したツリーをそのまま進めないでください。

抽象的な選択肢をユーザーが判断できない場合は、小さな例で選択を具体化するか、adanwo を使って直接体験してもらい、その反応を踏まえて再開してください。繰り返し質問しても、ユーザーがまだ持っていない経験を補うことはできません。解釈案は、確認されるまでは暫定のものとして扱ってください。

同じラウンド内に、別の未解決の質問への回答に依存する質問を含めないでください。

事実を調べるのはあなたの役割であり、ユーザーの役割ではありません。範囲の限られた事実は直接確認してください。前提事項を調査するための独立した作業が進行している間に、独立したフロンティアの質問を今すぐ行い、その証拠に依存する質問だけを待たせてください。真に発見不可能な第三者の入力が重大なフロンティアを左右する場合は、不足している入力を明示し、独立した質問を続けてください。その入力の収集が作業範囲内であれば、回答可能な質問をそのまま返すか、受け手向けの文面作成に実質的な利点があり、利用可能な場合は oro を使ってください。文面を作成しても、送信が許可されたことにはならず、返信が承認に変わることもありません。

独立した専門性やコンテキストによって調整コストを十分に補える場合に限り、範囲の限られた分析、調査、または専門家による作業を委任してください。簡潔な所見と根拠へのリンクを返してください。

実質的な前提調査には iwadi を使用し、情報源の取得には該当するプロジェクトまたはホストの機能を使用してください。同じインタビューを続けてください。証拠が不完全なら、それに依存する前提事項は確定しません。

フロンティアでの選択に信頼できる選択肢が複数あり、独立した基準が少なくとも2つ、推奨案を実質的に変えうる場合は、その決定に特化した簡潔な評価基準を使ってください。まず必須条件を適用し、その決定に重要な基準だけを導き出してください。決定的な要因、最も有力な信頼できる代替案、重要な反証を示してください。些細な選択やすでに決定済みの選択に対して点数を捏造したり、平均点で必須条件の不適合を覆い隠したりしないでください。評価基準は推奨を裏付けるためのものであり、決定するのはあくまでユーザーです。

探索や方向性の策定が必要な場合は、探索モードで atona を使用してください。具体的な選択を明確にするために使い捨てのプロトタイプが有効な場合は、adanwo を使用してください。

決定するのはあくまでユーザーです。推奨、生成された選択肢、比較評価、プロトタイプの観察結果を、暗黙のうちに確認済みの事項へとすり替えないでください。

共通認識を可視化する

計画や提案する方針については、意味のある最初の提案からhtml-artifactを使います。取り組みの継続的なビューがある場合は、その担当者を通じて再利用します。ない場合は、引き継ぎ用に維持します。質問は会話内に残します。その他の範囲が限定された意思決定では、必要に応じて視覚的な資料を使います。

重要な変更があったら、依存する質問に進む前に、同じHTML計画内で意思決定とその提示内容を更新します。同等のMarkdown版は作成しません。代替案、厳格なゲート、不確実性、反証となる情報を残します。最終確認の前に、統合したビューを提示します。利用できない場合はその不足を報告し、独立した事実確認を続けます。

重要な検討事項が残っていないと判断する前に、現在のツリーを見直し、重大な前提、分岐の欠落、矛盾する意思決定、明示されていない依存関係がないかを確認します。

この見直しを経て未解決の重要な分岐がなくなり、必要なビューが最新で、ユーザーが共通認識を確認した場合にのみ完了とします。同じ呼び出し元に、確認済みの意思決定、重要な前提と証拠、選択を左右した意思決定変更につながる代替案・基準、明示的な保留事項と再検討条件、次の成果境界を返します。計画のHTMLロケーターとリビジョンも渡します。新たに明らかになったドメイン、事実、技術上の不足点は、競合するワークフローを開始せずに返します。arojinle内でデリバリーを実行しないでください。