システムマップによる計画

描画や構築の前に、共通理解を作りましょう。マップはシステムの動作を示し、チャットは議論を保持します。計画によって、製品を実装する許可が与えられることは決してありません。

計画を開始または再開する前に、計画ガイドを読んでください。ガイドには、ソース形式、パーツレコード、ナビゲーション、チェックが定義されています。ヘルパーのセットアップとコマンドについては、READMEを読んでください。

証拠から始める

会話内で保存されている唯一の.plan.jsonソースを継続します。その目標、決定事項、未解決の質問、現在の計画位置を読み取ります。既存の動作を説明する前に、関連するプロジェクトの証拠を調査します。ソースが大きい場合は、現在のパーツとその近隣のパーツのみを読み込みます。

新しい会話では、一意で説明的なソース名を選択してください。他の会話の計画を上書きしないでください。ソース計画が信頼できる情報源であり、生成された図面やマニフェストは編集可能な計画ではありません。

確認された事実、合意された計画、未知の事項、受け入れられていない提案を区別してください。証拠を引用してください。曖昧なラベルから以前の決定を推測したり、不足を埋めるために事実を捏造したりしないでください。

すべてのパーツについて、その1つの役割、入力、作業、結果、ルール、次の受け取り手、境界、証拠を記録します。ガイドで定義されたフィールド名を使用してください。

ストレージをアクションから分離してください。待機状態と作業を区別してください。各結果を次のパーツの期待される入力に接続してください。接続されたパーツを通して、1つの具体的な例をトレースしてください。

短いラベルと名前付き矢印を使用してください。子ページはその親パーツを説明します。明示的なdetail宛先を通じて接続し、名前の一致や推測されたリンクは使用しないでください。ツールの選択、設計上の質問、削除された機能に関するコメントはグラフに含めないでください。

まず現在の質問に答えてください。別の質問をする前に、確定した決定事項を読んでください。明確な変更要求は、無関係な決定を保持しながらソースを更新します。合意は、実際に提示された提案のみを受け入れます。

あるポイントを確定した後、次の意味のある未解決のパーツに進みます。その目的を説明し、根拠のあるアプローチを提案し、設計を変更する場合に1つの具体的な選択肢を尋ねます。計画をインタビューにしたり、「保存しました」で停止したりしないでください。

マイナーなデフォルトを提案としてラベル付けします。許可、プライバシー、コスト、事実の証拠について黙って決定しないでください。混乱を解決してから前進してください。重要な決定が残っていない場合は、準備状況を要約し、レビューまたは個別に承認された実装を提供してください。

計画を変更した後、それをビルドし、影響を受ける接続と子ページの意味を検査します。ブラウザアクセスが利用可能な場合は、図面とナビゲーションも検査します。利用できないチェックについては正直に報告してください。

ヘルパーテストは、構造と生成された出力をチェックしますが、システムの真実、実際のブラウザ操作、またはすべてのエージェントハーネスとの互換性はチェックしません。