woostack-bootstrap

woostack-bootstrap

概要

Bootstrap は、グリーンフィールドのプロジェクトを起点とするエントリーポイントです。要件を収集し、最新の技術とバージョンをリアルタイムで確認して、アーキテクチャとスコープの全体像を提示します。設計が明示的に承認されるまで、対象ディレクトリへの書き込みは行いません。対象の衝突チェックに合格した後、承認によって書き込みのブロックが解除されます。ローカルのスキャフォールドには、GitHub リポジトリ、アカウント、リモート URL、Project は必要ありません。

スタックはテンプレートから選ぶのではなく、動的な状態を保ちます。ユーザーが指定したスタックをプロジェクトの要件に照らして検証し、承認された各アプリを、そのアプリ固有のコードでスキャフォールドします。複数のアプリで同じコードが必要な場合に限り、パッケージとして抽出します。明示的に選択された GitHub Project には、承認済みの設計と依頼されたデリバリーノートを保存できますが、これは任意であり、書き込みを許可するものではありません。

基本原則： プロジェクトの要件に基づいて技術とバージョンをリアルタイムで確認し、記憶に頼らないこと。また、新しいコードベースを書き込む前に、承認済みの設計と衝突のない対象を確認すること。

呼び出し方法

/woostack-bootstrap <goal> で呼び出します。goal には、新しいコードベースを平易な言葉で説明します。

/woostack-bootstrap create a new mobile app for cataloging recipes
/woostack-bootstrap a SaaS dashboard with a marketing site and a billing API

goal は要件の収集と推奨のフェーズの起点となります。承認ではなく、保存される開発記録でもありません。

ルーティング

作業の慣習や履歴を引き継ぐ既存のコードベースがない場合に限り、bootstrap を使用します。空のリモートリポジトリを作業先として指定することはできますが、既存リポジトリに関する依頼は、要件収集、MCP の事前確認、プロジェクト作成に進む前に、次のとおり振り分けます。

• 未解決のバグ、リグレッション、インシデント、根本原因の調査 → 原因の診断には woostack-debug を使用します。欠陥が立証され、イシュープランが必要な場合は woostack-plan を使用します。
• 1 つのレビュー可能な PR に収まる範囲が限定された機能強化、リファクタリング、テスト作業（1 ファイルの依頼を含む）、または因果関係の証明があり、1 つのレビュー可能な PR に収まる承認済みの欠陥修正 → woostack-execute
• 複数の PR にまたがる機能やアーキテクチャ上の取り組み → woostack-plan

手順

1. 分類し、意図を把握します。 まず、新規開発か既存プロジェクトの拡張かを分類します。 範囲を限定した読み取り専用の対象検査により、 ファイルシステム手順 に従って対象の有無や競合を確認できますが、書き込み権限は付与されません。
2. 要件を収集します。 製品の目標、必要な利用面、規模、デプロイの制約、コンプライアンス／セキュリティ、連携、予算について、的を絞った質問をします。
3. 業界の最新情報を調査します。 Web 検索や npm view <pkg> version などのレジストリの最新情報を使い、要件を満たす最新のフレームワーク、ライブラリ、データベース、サービスを特定します。
4. 設計を提示します。 提供された実現可能な技術スタックを調査・検証してから、利用面、初期機能、技術的な決定、本番運用への準備状況、コストへの影響を含む、完全なアーキテクチャとスコープ案を1つ提示します。未解決の重要なトレードオフがある場合に限り、代替案を比較します。設計は会話／実行コンテキスト内にのみ保持します。リモートプロジェクト／Issue、ローカル仕様書や計画書、対象ディレクトリ、ブランチ、コミット、PR は作成しません。

提示した設計全体について、明確な承認が得られるまで待ちます。沈黙、最初の目標、技術スタックの希望、部分的な同意、またはエージェントによる承認の推測では、このゲートを通過できません。承認前に、公式 MCP の開発に関する変更を行ったり、開発成果物を作成したりしてはいけません。

5. ファイルシステムの書き込みバリアを通過します。 設計承認後に、正式な 競合確認手順 に従います。承認済みのスコープと実際に選択された対象は会話コンテキスト内に保持し、それらの代わりとなる実行記録、ハッシュ、マニフェストは作成しません。事前の検査で、新たな書き込み前チェックを省略することはできません。
6. 承認済みの設計を任意で公開します。 設計が承認され、対象の競合チェックに合格した後に限り、かつ呼び出し元が特定の GitHub Project を選択した場合に限って、共通の 成果物コントラクト を適用し、 Project コンテンツコントラクト を読み込み、 ブートストラップ公開手順 に従います。設計承認と競合／ファイルシステムの許可を得る前に、GitHub の操作を行ってはいけません。実際のスコープ、ID、機能、および読み戻しの規則に従って、選択された正確な Project を特定し、designApproved を追記して読み戻します。GitHub の結果が欠落、不完全、不明瞭、または不明な場合、明示的に成果物の一部として求められていない限り、この公開要求のみを停止します。成果物のテキストによってファイルシステムのバリアが解除されることはありません。
7. スキャフォールドを作成し、検証します。 references/bootstrap.md に従い、そこから参照されているすべてのアーキテクチャ、フレームワーク、インフラストラクチャ、実装の各コントラクトも含めて遵守します。リモートを明示的に要求された場合は、リポジトリ初期化手順に従ってローカル Git を初期化した後にのみ設定します。ユーザーが承認済みスコープ内で Woostack の採用またはプロジェクトガイダンスを選択した場合、またはローカルサポートを明示的に必要とする場合に限り、woostack-init を呼び出します。ドキュメントを作成する場合は、承認済みの製品／設計上の決定と、確認済みのスキャフォールドコマンドを渡し、要件の聞き取りを再度行ったり、スキャフォールドのスコープを拡張したりせずに、それらを再利用します。サポートのみの引き継ぎでは、Init のローカルサポートパスを直接選択します。引き継ぎ前に、選択した技術スタックで定義されているビルド、テスト、lint、フォーマット、起動の各チェックを実行します。

参照資料（必要に応じて読み込み）

ファイル	定義内容
references/decisions.md	質問票のガイドと、設計確認を明示的に行う手順
references/bootstrap.md	衝突を回避したブートストラップと、任意の GitHub 公開
references/architecture.md	アプリ内のコード配置、任意の共有パッケージ、命名規則
references/frameworks.md	バージョン解決のルール、アプリ単位の依存関係、注意事項
references/infrastructure.md	本番運用に向けたパターン：ホスティング、CI/CD、環境変数、マイグレーション、可観測性
references/patterns.md	標準的な実装パターン。テストに関する正規のガイダンスは Execute にあります
references/development.md	リポジトリの正規の管理元、保持データ、ルーティング、ブランチモデル

厳守事項

これらは譲れない要件です。違反すると、帰属が不明確で、壊れているか、仕様からずれやすいプロジェクトになります。

• ブラウンフィールドのルーティング。 診断のみの依頼は読み取り専用の Debug に、課題の計画は Plan に、承認済みの範囲内で行う機能拡張、リファクタリング、テスト、修正は Execute に割り当てます。Execute は、証拠が十分な場合はインラインで、修正に先立って不具合の原因を特定します。
• 明示的な承認までは成果物を作成しない。 要件、調査、選択肢、設計は実行コンテキスト内にとどめます。設計承認ゲートを通過する前に、リモートプロジェクト、更新、課題、ドキュメント、ローカルの仕様書や計画書、対象ディレクトリ、ブランチ、コミット、PR を作成してはいけません。
• 書き込み前に承認を得る。 ファイルシステムのバリアに従います。初期の読み取り専用調査や GitHub の操作記録によって、変更が許可されることはありません。
• リモートでの作業はオプトインです。 ローカルのみのスキャフォールドでは GitHub を呼び出さず、アカウント、Project、リモート URL、push、PR も必要ありません。ローカル成果物の要件を満たすために、リポジトリ名を推測したり、リモートリソースを作成したりしてはいけません。リモート設定や公開が依頼された場合は、許可されたネイティブの GitHub 機能、またはホスト認証済みの gh のみを使用し、正確な識別情報、安定した変更 ID、完全なページネーション、独立した読み戻しを行います。ドキュメント、独自のトランスポート、リポジトリ認証情報、環境変数のトークンへのフォールバック、別の権限元は使用しません。
• 公開の失敗はその範囲内にとどめます。 アクセス権がない場合や結果が不明・不完全な場合、依頼された公開はできません。ただし、公開が成果物の一部として明示的に依頼されていない限り、別途承認済みの成果物を作成しないスキャフォールドまで妨げるものではありません。直接読み戻していない公開を、完了したと主張してはいけません。廃止された旧設定やデータは不透明なユーザーデータとしてディスク上に保持し、アクティブな設定から除外したうえで、その境界で廃止について案内します。インポートしてはいけません。
• 常に最新バージョンをリアルタイムで解決します。 記憶にあるハードコードされたバージョンは使用しません。調査と正確なバージョン解決の際に、レジストリをリアルタイムで照会します。
• 共有されるまではコードをアプリ内に置きます。 references/architecture.md に従います。新しいコードは、それを所有するアプリ内に置き、複数のアプリで同じ実装または契約が必要になった場合にのみパッケージとして切り出します。
• 検証されていない状態でリリースしません。 選択したスタックのビルド、lint、テスト、フォーマット、起動チェックがすべて成功するまでは、ブートストラップの完了を宣言してはいけません。
• 決定事項を記録します。 引き継ぎ時に、最終的なスタックの選択、解決済みのバージョン、その理由、開発手順をプロジェクトルートの README.md に記載します。任意の成果物へのリンクは、明示的に選択され、検証済みの場合に限って含めます。

SPEC_VERSION

6.0.0 — ローカルファーストのグリーンフィールドブートストラップ：リモートを必須としない承認ゲート付きスキャフォールディングと、任意の GitHub Project への直接公開。