architecture

アーキテクチャ

必読： ../pack-shared/standards.md。ルールは AGENTS.md の Taste セクションと Architecture セクションです。このスキルには監査手順と例が含まれています。このスキルが呼び出されていないからといって、ルールを省略しないでください。

質問のスタイル： ../pack-shared/asking.md

構造カードを作成する前に、AGENTS.md の Taste セクションと Architecture セクションを適用してください。引用キーには、これらのセクションの見出しを使います。共有の 実行コンテキストを使用してください。

../pack-shared/subagents.mdに従い、Task サブエージェントで調査してください。重要な兄弟機能・サービス・フォルダーの検索には、必ず explorer Task を使用してください（メインは grep を実行しません）。独立したレーンは必ず並列で実行してください（レーンごとに Task を 1 つ割り当て、2 つまでという上限はありません）。調査結果を確認し、それをもとに構造カードを作成してから、その抜粋を後続のブリーフに含めます。調査するリポジトリがない、簡単なグリーンフィールド構造の場合に限り、Task を省略できます。アーキテクト担当のワーカーはありません。

親からすでに outcome、Done when、non-goals、locked decisions、Active Rules、current slice、lane が提供されている場合は、そのブリーフを再利用してください。

プロセス

1. 調査する。 並行するサービスを新たに作る前に、既存のサービスを再利用または拡張してください。特定の役割をすでに果たしているプリミティブがあれば、それを再利用してください。形が適切でない場合は、コピーせず、レーン内で指摘してください。次の点を記録します。
   • 同じ関心事（課金、認証など）を扱う既存サービス（まず再利用・拡張する）
   • それらのサービス内の既存プリミティブ／深いモジュール（特定の役割をすでに果たしている場合は再利用し、フォークしない）
   • レーン内にある形が不適切な既存コード（機能ごとにフォークされたドメインロジック、不適切な兄弟機能、配置が不適切なファイルなど）：コピーしない。現在のスコープで必要な場合に限り、動作を維持した移動を計画する
   • 類似機能がそれらのサービスをどのように呼び出しているか（公開 API のみかなど）
   • 既存のエントリーポイントのパターン（サービス、フック、クラス、モジュールなど）
   • 命名規則とインポートのスタイル
   • 兄弟機能が書き込み時に集約値を保存するのか、読み込み時に再計算するのか（前者を優先する）
   • 兄弟機能が公開書き込み時に ID と所有権をどのように確認しているか（そのヘルパーを再利用し、並行する認証経路を作らない）
   • リスト／クエリ経路がインデックス化・ページネーションされているか、またクエリが決定的か
2. チャットで Architecture セクションに基づく Structure カードを作成する（常に／書き込みがある場合／リストがある場合／大規模な機能の場合）。動作を維持するために必要な移動は、機能コードの作成前に記載します。
3. 該当するカードをインライン実行コンテキストに引き継ぎます。計画、ワークスペース、レジスター、その他エージェントが所有する成果物を作成または更新しないでください。構造上の未決事項は、/grill-me の Questions バッチ 1 回で解決します（../pack-shared/asking.mdに従ってください）。
4. カードに沿って実装する。 ファイルを作成する前に、所有するフォルダーを作成します（architecture:folders）。異なる用途のファイルが混在する親フォルダー（src/、app/、convex/、または無関係なファイルがすでに置かれているルートフォルダー）に、新しいファイルを追加しないでください。新しい機能コードを古い構造に継ぎ足す前に、移動や修正を行います。ドメインロジックはサービスに置き、機能からは公開関数のみを呼び出します。サービス内のプリミティブで深さを構築します。サービス内で公開書き込み時の ID と所有権を検証します。クエリは決定的にし、公開引数を検証します（taste:types-tell-the-truth）。環境変数名を新たに追加する前に、用途ごとに既存の変数を洗い出します（taste:reuse-env）。
5. 実装中にコードが散らかった場合、ドメインロジックが重複した場合、プリミティブがフォークされた場合、または以前のミスがあった場合でも、現在の受け入れ基準、Active Rules、または名前を挙げた指摘によって求められているときに限り、移動を行ってください。それ以外は、所有するフォルダー内で最小限の直接的な構造を維持し、チャットにフォローアップを記録します。異なる用途の兄弟機能を追加しようとしていますか？その場合はネストしてください。特別な手順は必要ありません。
6. 完了前に Architecture セクションのセルフチェックを実行します。

親がすでに次のステップを管理している場合

構造に関する判断を親のインラインコンテキストと Worker Brief に引き継ぎ、ユーザー向け UI には /design、非 UI には /implement を使います。必要な修正を親に返します。

これがユーザー向けの単発対応の場合

• 構造カードが承認済み → /task
• 規模、重複したサービス、フォークされたプリミティブ、対応漏れ、親が混在する ファイルダンプ、環境変数の同義語（SITE_URL が存在するのに FRONTEND_URL を使う）、または 書き込み経路の権限が未設定 → 受け入れの証拠 / /code-review