bootstrap-brownfield

既存プロジェクトのブートストラップ

SDD の計画前に、既存製品のアーキテクチャを調査します。

ハーネスの調査

../nextstage-harness/references/harness-discovery.md を参照してください。{harness_root}/rules/*.md からルールを読み込みます。まず architecture-rules.md を読んでください。レガシー環境では、{harness_root} が存在しない場合に限り .cursor/rules/*.mdc を使用します。ハーネスルールがある場合は、調査結果を標準ルールと照合します。ルールがない場合、チェックは参考情報です。

使用するタイミング

• 「既存プロジェクトを分析して」／「既存プロジェクトのブートストラップ」
• コードはあるものの requirements.md がないリポジトリで、初めて SDD の計画を立てるとき
• レガシーコードで requirements-generator を実行する前

ワークフロー

ステップ 1 — 構成の検出

{product_root} の下を確認します（レガシーな構成の場合はリポジトリのルートも確認し、不整合を記録します）。

バックエンドの手掛かり： composer.json、artisan、モジュール構成の app/Modules/、docker-compose.yml、.env.example

フロントエンドの手掛かり： package.json、tsconfig.json、src/modules/、cypress/、バンドラーの設定

構成： backend/ と frontend/ に分かれたモノレポか、単一のアプリか

ステップ 2 — モジュールのマッピング

ドメインを一覧表示します。

• バックエンド：モジュール、コントローラー、モデル、モジュールごとのマイグレーション
• フロントエンド：モジュールごとのページ、ストア、サービス

ステップ 3 — ルールへの準拠（任意）

ハーネスルールがある場合は、バックエンドのモジュール構成、マルチテナント対応、フロントエンドのパターン、テストについて照合します。各行に ✅／⚠️／❌ を付けます。

ハーネスルールがない場合は、技術スタックに依存しないチェックを使用します。

ステップ 4 — レポート

{product_root}/docs/context/brownfield-map.md を作成または更新します。

# Architectural map — brownfield bootstrap

**Date:** {date}

## Identified stack

- Backend: ...
- Frontend: ...
- Database, cache, queues, E2E tooling

## Backend modules

| Module | Controllers | Models | Migrations | Tests |

## Frontend modules

| Module | Pages | Stores | E2E |

## Rule adherence

{tables when rules exist}

## Gaps (priority)

1. Critical ...
2. Medium ...

## Recommendations for next planning

- ...

ステップ 5 — 提示

3〜5 個の箇条書きで要約し、重大なギャップを強調したうえで、バージョン計画を開始するか、ギャップを確認するかを尋ねます。

重要なルール

• 読み取り専用 — コードは変更しません
• レポートは {product_root}/docs/context/ の下にのみ作成します
• brownfield-map.md をコンテキストとして requirements-generator に渡します
• 既存のマップがある場合は、重複させずに更新します

関連スキル

• codebase-reverse-spec — ビジネス動作の抽出（ブートストラップより詳細）
• requirements-generator — ブートストラップ後の次のステップ
• clarify-requirements — スコープがまだ曖昧な場合