vibe64-dev/seed-nextjs

Genesis プロジェクトでの作業

Genesis は説明と検証のための伴走ツールです。コードベース、テスト、Git レビュー、またはコーディングエージェントを置き換えるものではありません。

新製品の方向性の確立

Blueprint がまだ製品の方向性を確立していない新しいプロジェクトでは、ユーザーが何を構築しているのか、誰または何がそれを使用または呼び出すのか、最初に観測可能な有用な成果は何かが明確になるまで、技術の調査やソースの作成を行わないでください。未解決の高影響度の質問のみを尋ねてください。返信は明示的に回答した内容のみを確認します。Stack の確認は製品の意図ではありません。

製品の方向性が明確になったら、選択された技術ガイダンス、またはカタログに一致するものがない場合は信頼できる技術ドキュメントの中から、1 つの最小実装パスを選択し、そのパスに必要なものだけを読んでください。代替案を調査したり、技術リポジトリ全体をクローンしたり、無関係なパッケージの内部を検査したり、1 つの具体的な障害が 1 つの正確な調査を必要とする場合を除き、調査を委任したりしないでください。

Genesis コマンドの実行

最初の Genesis 操作を実行する前に、呼び出し方法を解決してください。Genesis 操作や genesis --version を可用性の確認として使用しないでください。

1. リポジトリルートの package.json を読み取ります。マニフェストの name が genesis-compiler であるか、その dependencies、devDependencies、または optionalDependencies に正確な genesis-compiler キーが含まれている場合にのみ、Genesis をプロジェクト固定として扱います。
2. プロジェクト固定のリポジトリの場合、すべての Genesis CLI 操作を npm exec --no -- genesis <arguments> で呼び出します。これにより、別のパッケージを取得せずに実行されます。宣言されたパッケージがインストールされていない場合は、プロジェクトの依存関係が準備されていないことを報告し、別の Genesis バージョンにフォールバックしないでください。
3. それ以外の場合は、npm exec を試行しないでください。command -v genesis（または現在のシェルに相当する PATH ルックアップ）を実行します。実行可能ファイルが解決された場合は、genesis <arguments> を直接呼び出します。
4. どちらのソースも利用できない場合は、停止して Genesis が利用できないことを報告してください。ワークフロー指示を満たすためだけに Genesis をインストールまたは更新しないでください。

呼び出しの解決はルーチンです。Genesis がプロジェクト固定か PATH 上にあるかを説明したり、PATH の直接使用をフォールバックとして説明したりしないでください。呼び出しがどのように選択されたかについては、解決が失敗した場合、またはユーザーが明示的に尋ねた場合にのみ言及してください。

ユーザー向けの更新には、設定されたコラボレーションアプローチに従い、その技術的な深さと応答の長さを含めてください。具体的な進捗、発見、またはブロッカーを報告し、ガイダンスに従っていることを宣言しないでください。

明示的な技術選択の解決

外部の技術調査や実装の前に、ユーザーが明示的に技術、フレームワーク、言語、またはデータベースを名前指定し、それが選択されていない場合:

1. 最初の技術アクションとして Genesis の stack list 操作を実行します。
2. 1 つのカタログコンポーネントが選択と完全に一致する場合、次のように尋ねてください: 「<テクノロジー> は Genesis で利用可能です。このプロジェクトに追加し、公式ガイダンスを使用してアプリを準備しますか？」 その確認なしに stack add <piece...> を実行しないでください。
3. 確認された場合、コンポーネントを追加し、Genesis に宣言された依存関係のクロージャを適用させ、そのコンポーネントによって宣言された信頼できるエージェントスキルを同期させます。同じタスク内で stack add によって返された準備プロンプトに従ってください: 具体化された各プロジェクト契約を真にするか、完全なセクションを証拠に基づく現実で置き換えます。次に、context .、またはソースが存在する場合は関連するソースパスを実行し、該当するインストール済みスキルが存在すればそれをロードし、そのテクノロジー所有のガイダンスに従って実際のプロジェクト依存関係を準備します。コンポーネント ID からインストールコマンドを推測しないでください。
4. 辞退された場合、コンポーネントを追加せず、再度尋ねることもせずに続行します。カタログコンポーネントが一致しない場合、発明しないでください。そのテクノロジーが所有する信頼できるドキュメントを使用して通常どおり続行します。

コンテキストの確立

1. genesis/blueprint.md を読み、技術的でない製品の意図を理解します。
2. genesis/engineering.md を読み、選択されたエンジニアリングプロファイルとプロジェクト固有の要件を理解します。
3. genesis/stack.md を読み、選択された技術構成、リソース、および検証コマンドを理解します。
4. リクエストに関連するソースを見つけます。
5. ヘルパーまたはパブリック操作を追加する前に、Genesis の index <name-or-path> 操作を実行します。動作を既に所有している既存の関数がある場合は、それを再利用します。
6. 関連する Program の説明と選択された Stack コンテキストのために、Genesis の context <path...> 操作を実行します。
7. .agents/skills/ またはエージェント自身のインストール済みスキルカタログから、該当する技術スキルをロードします。

既存のアプリケーションの最初の Stack 選択では、具体化されたコンポーネントの提案を受け入れる前に、実際のセットアップ、ビルド、および出力コマンドを検査します。選択されたコンポーネントは現在の基盤を説明します。古いソースをサイレントに移植することはありません。既存のコマンドが異なる場合は、実装を変更せずに、プロジェクト所有のコンシューマー操作全体（ホストの ## Workspace setup や ## Outputs など）を置き換えます。Genesis はこれらのセクションを不透明なテキストとして扱います。名前付きコンシューマーのみがその意味と実行を所有します。提案されたレシピがソースと一致するまで使用可能であると主張しないでください。

Program は簡潔で、誤りを含む可能性のある説明です。その Sources とオプションの Implementation マップはナビゲーションに役立ちますが、コード、テスト、およびランタイム動作を読むことの代わりにはなりません。

.genesis/machine-city.json は派生した詳細なファイル/関数マップです。.genesis/program-city.json は派生したより単純なサブシステム/操作マップです。どちらも権威や証明ではありません。どちらも git で無視され、Genesis の index 操作で再生成される可能性があります。

通常のローカル作業の実装

• Genesis によって提供される有効なエンジニアリングアプローチを適用します。すべての変更は、容易に推論でき、既知の要件を完全に満たす最小のターゲット実装である必要があります。過剰エンジニアリングや複雑化を避け、投機的な抽象化、レイヤー、依存関係、インフラストラクチャ、互換性パス、分散パターン、暗号化、またはその他の高度な機構を追加しないでください。
• 具体的な要件が不可避的に複雑さを必要とする場合、それを記述する前に停止してください。直接設計が不十分である理由と、提案される最小の追加複雑さを説明し、ユーザーにトレードオフの承認または明確化を求めてください。エンジニアリングアプローチを黙ってオーバーライドしないでください。
• 現在の Git ツリーで直接作業し、有用な編集を通常の diff で可視化したままにしてください。
• 実装が意図的に観測可能な製品動作を変更する場合、同じターンで Blueprint と影響を受ける Program モジュールを整合させてください。プライベートな再構築には、修正された Sources または情報提供の Implementation マップのみが必要で、説明の編集は必要ない場合があります。実装が意図的に対応するコマンドや機能を変更する場合、ホストの ## Outputs などのコンシューマー所有の操作宣言を正確に整合させてください。そこには機能メタデータと環境変数名のみを記録し、値やシークレットは決して記録しないでください。セクションを Genesis の動作として推測または実行しないでください。.genesis/ は、作成された製品の意図ではなく、置き換え可能な派生ナビゲーションデータとして扱ってください。
• 並列フレームワーク、永続化レイヤー、トランスポート、バリデーター、または UI システムを作成する代わりに、確立されたプロジェクトと技術の境界に従ってください。
• 利用できない外部リソースの値を発明したり、リテラルの環境変数名をデータとして渡したりしないでください。欠落しているリソースを報告し、有用な作業を保持してください。
• 実装を直接的で凝集性のあるものに保ってください。供給された Stack の Post-change ガイダンスがあれば、完了を報告する前に適用してください。これはこの実装ターンの一部であり、別のエージェントターンの要求ではありません。有用な場合に焦点を絞ったチェックを実行してください。

検証と報告

実装中に、変更に関連するチェックを選択してください。プロジェクトの検証ポリシーまたはユーザーの要求により、選択されたテクノロジーのワークスペース基盤が存在した後、Genesis の verify を通じて Stack の宣言された最終チェックを実行してください。アイテムの完了やセッションの再開は、それ自体で広範な検証実行を必要としません。完全な出力をローカルアーティファクトに保持し、終了ステータスを保存し、ログを展開する前にサマリーと関連する失敗の抜粋を読んでください。時間やトークンを節約するためにアサーションを弱めたり、必要なカバレッジを省略したりしないでください。未設定の結果は、宣言されたワークスペースまたはチェックがまだ存在しないことを意味します。失敗チェックではありません。完了を報告する前に、要求された観測可能な動作、必要な入力とリソース、宣言されたプロジェクト操作、焦点を絞った証拠を、実際に存在するものと比較してください。変更されたファイル、実際に実行されたチェック、証明されていないもの、およびまだ注意が必要なものを報告してください。実行されていないチェックが合格したことや、合格したチェックが製品全体を証明することを決して主張しないでください。

サブシステムの保守

変更がサブシステムの責任、Program メンバーシップ、またはデータの所有権/使用を追加、削除、または変更する場合、同じ実装ターンで genesis/subsystems.md を保守してください。関連コードを変更する前にマップを読んでください。明確に異なる責任が証明されない限り、既存のサブシステムを再利用してください。サブシステムごとに 1 つの Source Directory が必要であり、各 Program モジュールは正確に 1 回宣言します。Program フォルダ名はメンバーシップを決定しません。テーブル参照はスキーマ/マイグレーションに基づいてください。Genesis はデータベースを検査しません。これらの関連付けが変更されない場合、プライベートヘルパーの変更にはマップの編集は必要ありません。

genesis/subsystems.md が存在しない場合、または既存の説明済みアプリケーションで空の場合、実装の前に実際のソース、スキーマ、および既存の Program からそれを作成してください。これは通常の説明の採用であり、ブロッカーや再び許可を求める理由ではありません。既存の Program とソースを保持し、関連する責任を検査し、最小の真実のマップを完成させてください。初期化で空のファイルを作成することはできますが、その意味を記述するのはエージェントだけです。