reconnaissance

偵察：情報収集と環境の把握

概要

すべての Heist は、情報収集から始まります。Underboss は Associates を派遣し、対象のコードベースとインフラストラクチャを詳細に調査させます。その成果物である偵察ドシエは、以降のすべてのフェーズに役立ちます。

トリガー

Don が構築または創作の意図を示したときに呼び出されます。

プロセス

ステップ 1：意図を分析する

Underboss は Don の依頼を解析し、次の点を特定します。

• 目的： 何を構築または変更するのか？
• 範囲： システムのどの部分が影響を受けるのか？
• 制約： 明示的な要件や制限はあるか？

ステップ 2：Associates を派遣する

情報収集のため、Associate サブエージェントを並行して派遣します。

サブエージェントの種類： すべての Associate の派遣に subagent_type: "associate" を使用します。"general" や "general-purpose" は使用しないでください。これらは Gangsta のインストール環境では有効ではありません。

グリーンフィールドモード（空またはほぼ空のワークスペース）

標準調査を派遣する前に、作業ディレクトリ内のファイル数を数えます（.git、docs/gangsta/、その他のメタディレクトリを除きます）。

トリガー： ワークスペースにソースファイルが 5 個未満、または認識可能なプロジェクトマニフェスト（package.json、requirements.txt、go.mod、Cargo.toml、pyproject.toml など）が存在しない場合。

トリガーが作動すると、偵察の目的は「既存のコードを調査する」から「アイデアを磨き上げる」へと移ります。標準的なコードベース調査も実施します（存在するわずかな内容を記録するため）が、中心ではなくなります。代わりに、次の Associates を並行して派遣します。

Associate のタスク	調査内容
アイデアの整理	Don の目的を Don 自身の言葉で言い換えます。解決しようとしている問題、その問題を抱えている人、Don が提示した根拠（あれば）を特定します。隠れた前提を明らかにします。
類似事例	インターネットを検索し、同じ問題や関連する問題を解決する既存のツール、ライブラリ、製品、論文を探します。類似事例ごとに、名称、機能、優れている点、劣っている点、ライセンス／ホスティングモデルを記載します。webfetch ツールを使用します。類似事例を少なくとも 3 件提示します。3 件未満しか見つからない場合は、その旨と、この分野の事例が少ない理由を説明します。
先行事例とパターン	関連する先行事例（プロトコル、データ形式、アルゴリズム、設計パターン、過去の試み、事後分析）をインターネットで検索します。出典（URL）を記載します。
制約とリスクの調査	この分野で既知の制約を列挙します。性能上限、セキュリティ上の懸念、規制、アクセシビリティ、プラットフォームの制限などが含まれます。出典を記載します。
コードベースの構造	（標準調査 — ワークスペースに存在するわずかな内容を調査します。）
台帳の検索	（標準調査。）
憲章	（標準調査。）

ドシエの Codebase Overview セクションは、空またはほぼ空の状態を簡潔に記述したものになります。ドシエの大部分は新しいセクションに移ります。詳しくは、以下の「グリーンフィールドドシエ形式」を参照してください。

グリーンフィールドドシエ形式（グリーンフィールドモードが作動した場合、標準形式に代わって使用）：

---
heist: <heist-name>
date: YYYY-MM-DD
status: pending-review
mode: greenfield
---

# Reconnaissance Dossier: <Heist Name>

## Objective
<What the Don wants to build — restated in Don's words, plus interpreted objective>

## Workspace State
<One paragraph: what currently exists. If empty, say "empty workspace — greenfield".>

## Idea Framing
- Problem: <the actual problem>
- Who has it: <audience>
- Evidence: <what the Don offered; if none, say "no evidence offered — to be grilled">
- Hidden assumptions:
  - <assumption> — risk if wrong: HIGH/MEDIUM/LOW

## Analogues
| Name | What it does | Strengths | Weaknesses | License/Hosting |
|------|--------------|-----------|-----------|-----------------|
| ... | ... | ... | ... | ... |

## Prior Art & Patterns
- <pattern / protocol / algorithm> — <URL> — relevance: <how it applies>

## Constraint & Risk Survey
- <constraint> — source: <URL>

## Existing Test Coverage
<Near-empty in greenfield mode — note what, if anything, exists.>

## Dependencies
<Near-empty in greenfield mode — list any the Don named.>

## Relevant Ledger Entries
### Applicable Insights
- <insight reference + summary>
### Applicable Negative Constraints
- NEVER <constraint> — Source: fails/YYYY-MM-DD-<topic>.md

## Risks and Unknowns
<Domain risks surfaced by the Constraint & Risk Survey; unknowns the analogues search could not resolve.>

## Recommended Scope
<Suggested boundaries — since there is no codebase to constrain scope, scope is the IDEA's own bounds: which analogue features to adopt, which to reject, which sub-problems are in/out.>

Don は通常どおりこのドシエを確認します。続行メニュー（ステップ 4）に変更はありません。

標準モード（既存のコードベース）

ワークスペースに実際のコードベース（ソースファイルが 5 個以上、または認識可能なプロジェクトマニフェストが存在する場合）が含まれている場合は、以下の標準調査を実施します。

Associate のタスク	調査内容
コードベースの構造	ファイルツリー、主要ディレクトリ、フレームワークの検出、エントリーポイント
既存のテスト	テストファイル、カバー範囲、テストフレームワーク、合格／不合格の状況
依存関係	package.json / requirements.txt / go.mod など、バージョン、既知の問題
ドキュメント	README、既存の仕様書、API ドキュメント、インラインドキュメント
台帳の検索	docs/gangsta/insights/ と docs/gangsta/fails/ を検索し、目的に一致するタグが付いた項目を探します
憲章	docs/gangsta/constitution.md を読み、該当する Commandments と Negative Constraints を確認します

ステップ 3：ドシエをまとめる

Associate からの報告をまとめ、構成化された偵察ドシエを作成します。

Dossier 形式（標準モード）

保存先：docs/gangsta/<heist-name>/recon/YYYY-MM-DD-recon-dossier.md

グリーンフィールドモードでは、上記で定義されているグリーンフィールド Dossier 形式を使用してください。

---
heist: <heist-name>
date: YYYY-MM-DD
status: pending-review
---

# Reconnaissance Dossier: <Heist Name>

## Objective
<What the Don wants to build/change>

## Codebase Overview
<Key files, directories, frameworks, patterns discovered>

## Existing Test Coverage
<What's tested, what's not, test framework and run command>

## Dependencies
<Key dependencies, versions, any concerns>

## Relevant Ledger Entries

### Applicable Insights
- <insight reference + summary>

### Applicable Negative Constraints
- NEVER <constraint> — Source: fails/YYYY-MM-DD-<topic>.md

## Risks and Unknowns
<Anything that couldn't be determined, areas of concern>

## Recommended Scope
<Suggested boundaries for the Heist based on the intel>

ステップ 4：Don に提示する

Dossier ファイル（ステップ 3）を保存し、その内容をチャットで Don に提示してください。

Dossier ファイルに、次へ進むためのメニューを含めないでください。 メニューはチャットメッセージのみです。Dossier の要約の後に Don へ提示してください。プラットフォーム標準のインタラクティブ選択ツール（OpenCode の question、Claude Code の AskUserQuestion）を使って提示してください。そのようなツールがない場合に限り、番号付きのプレーンテキストリストに切り替えてください。

必須ゲート — Sit-Down を省略してはいけません：

Sit-Down（仕様書の作成と Contract の締結）は必須フェーズです。Don が選択できるのは、その前に The Grilling を実施するかどうかのみです。ただし、Sit-Down 自体は必ず実施してください。

Don が Sit-Down の省略を求めた場合は、実装作業を開始する前に Contract が必要であることを説明し、以下のメニューを再提示してください。

次へ進むためのメニューには、必ず以下の選択肢のみを使用してください。言い換え、省略、短縮、選択肢の追加はしないでください。

How do you want to proceed?

  1. Approve the dossier + run The Grilling → Multi-agent debate on architecture, then The Sit-Down
  2. Approve the dossier + skip The Grilling → Proceed directly to The Sit-Down (spec drafting)
  3. Adjust scope — Add/remove anything from the phases before we commit
  4. Request more intel — Deploy Associates to dig deeper into a specific area

提示方法 — プレーンテキストではなく、プラットフォーム標準の選択ツールを使用してください：

• OpenCode では、question ツール（インタラクティブな選択 UI）を使って、以下の 4 つの選択肢を提示してください。番号付きリストをプレーンテキストでそのまま表示して回答を待ってはいけません。Don が選択肢をクリックできるよう、選択ツール経由で提示してください。
• Claude Code では、同じ 4 つの選択肢を AskUserQuestion ツールで提示してください。
• 現在のプラットフォームでインタラクティブな選択ツールが利用できない場合に限り、上記の番号付きプレーンテキストメニューに切り替えてください。

何らかのアクションを取る前に、Don が明示的に選択するのを待ってください。

• 選択肢 1 → gangsta:the-grilling を呼び出し、その後 gangsta:the-sit-down を呼び出す
• 選択肢 2 → gangsta:the-sit-down を呼び出す
• 選択肢 3 → スコープの変更点を確認し、Dossier を更新して再提示する
• 選択肢 4 → 対象を絞った Associates を派遣し、Dossier を更新して再提示する

仕様の完全性を保つため、上記のいずれかの選択肢に従ってください（Omerta Law 5）。

チェックポイント

Don の承認後（選択肢 1 または 2）、チェックポイントを作成してください：

---
heist: <heist-name>
phase: reconnaissance
status: completed
timestamp: <ISO 8601>
next-action: <"Proceed to The Sit-Down" | "Proceed to The Grilling">
artifacts:
  - docs/gangsta/<heist-name>/recon/YYYY-MM-DD-recon-dossier.md
---

Omerta 準拠状況

• Introduction Rule：Underboss が Associates を派遣し、Underboss が報告を回収する
• Rule of Availability：Dossier とチェックポイントをファイルに保存する
• Rule of Truth：Dossier 内のすべての主張に、具体的なファイル、行番号、Ledger のエントリー、または URL（グリーンフィールドモードの場合）を引用する。引用のない類似事例や先行事例に関する主張は無効です。
• Spec is Law：次へ進むためのメニューを指定どおりに提示する。選択肢の追加、削除、言い換えは禁止
• Mandatory Gate：Sit-Down は省略不可。The Hit または Resource Development に直接進む経路はありません
• Greenfield Mode：インターネット検索で見つけた類似事例や先行事例には、Dossier 内で URL を引用する必要があります。類似事例の捏造は Rule of Truth 違反です