reconnaissance

侦察：情报与环境测绘

概述

每次 Heist 都始于收集情报。Underboss 会派遣 Associate 对目标代码库和基础设施进行详细调查。调查结果将汇总为一份侦察档案，为后续所有阶段提供依据。

触发条件

当 Don 表达构建或创作意图时触发。

流程

步骤 1：分析意图

Underboss 会解析 Don 的请求，确定：

• 目标： 要构建或更改什么？
• 范围： 系统的哪些部分会受到影响？
• 限制： 是否有明确的要求或限制？

步骤 2：派遣 Associate

并行派遣 Associate 子 Agent 收集情报。

子 Agent 类型： 所有 Associate 派遣都使用 subagent_type: "associate"。请勿使用 "general" 或 "general-purpose"——这些在 Gangsta 安装中均无效。

Greenfield 模式（工作区为空或几乎为空）

在派遣标准调查人员之前，统计工作目录中的文件数（排除 .git、docs/gangsta/ 和其他元目录）。

触发条件： 工作区包含少于 5 个源文件，或没有可识别的项目清单文件（package.json、requirements.txt、go.mod、Cargo.toml、pyproject.toml 等）。

触发后，侦察目标将从“调查现有代码”转为“打磨 IDEA”。仍会执行标准代码库调查（以记录现有的少量内容），但它不再是重点。应改为并行派遣以下 Associate：

Associate 任务	调查内容
构思梳理	用 Don 自己的话重述 Don 的目标。明确要解决的问题、遇到该问题的人，以及 Don 提供的证据（如有）。指出隐藏的假设。
类似方案	在互联网上搜索解决相同或相近问题的现有工具、库、产品或论文。对于每个类似方案，说明名称、功能、做得好的地方、做得不足的地方，以及许可证/托管模式。使用 webfetch 工具。至少提供 3 个类似方案；如果少于 3 个，请说明这一点并解释相关领域为何缺少此类方案。
先前成果与模式	在互联网上搜索相关的先前成果：协议、数据格式、算法、设计模式、过往尝试、事后分析。注明来源（URL）。
约束与风险调查	列举该领域已知的约束：性能上限、安全问题、法规、无障碍要求、平台限制。注明来源。
代码库结构	（标准调查——工作区中现有的少量内容。）
Ledger 搜索	（标准调查。）
宪章	（标准调查。）

档案中的 Codebase Overview 部分将简要说明工作区为空或几乎为空的状态。档案的主体将改为新的部分——见下文的 Greenfield 档案格式。

Greenfield 档案格式（触发 Greenfield 模式时，替代标准格式）：

---
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 文档、内联文档
Ledger 搜索	搜索 docs/gangsta/insights/ 和 docs/gangsta/fails/，查找标签与目标匹配的条目
宪章	阅读 docs/gangsta/constitution.md，了解适用的戒律和禁止性约束

步骤 3：汇总档案

将 Associate 的报告整理为结构化的侦察档案。

档案格式（标准模式）

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

在 Greenfield 模式下，请改用上文定义的 Greenfield 档案格式。

---
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

保存档案文件（第 3 步），然后在聊天中向 Don 呈交其内容。

不要在档案文件中包含继续菜单。 菜单仅作为聊天消息使用——在呈交档案摘要后，再向 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 工具（交互式选择界面）呈现这四个选项。不要直接以纯文本显示编号列表并等待——应通过选择工具呈现，让 Don 点击所选方案。
• 在 Claude Code 中，使用 AskUserQuestion 工具呈现相同的四个选项。
• 只有在当前平台不支持交互式选择工具时，才使用上文的纯文本编号菜单作为后备方案。

等待 Don 明确选择后再采取任何行动。

• 选择 1 → 调用 gangsta:the-grilling，然后调用 gangsta:the-sit-down
• 选择 2 → 调用 gangsta:the-sit-down
• 选择 3 → 澄清范围变更，更新档案，然后重新呈现
• 选择 4 → 派遣有针对性的 Associates，更新档案，然后重新呈现

请从以上选项中选择一个继续，以维护规格的完整性（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 合规性

• 引介规则：由 Underboss 派遣 Associates，并由 Underboss 收集报告
• 可用性规则：档案和检查点已保存到文件
• 真实性规则：档案中的所有断言均引用具体文件、行号、Ledger 条目或 URL（Greenfield 模式）。未注明来源的类比／先前成果断言均无效。
• 规格即法律：严格按规定呈现继续菜单——不得添加、删除或改述选项
• 必经关卡：绝不跳过 Sit-Down——不得存在直接进入 The Hit 或 Resource Development 的路径
• Greenfield 模式：互联网搜索（类比、先前成果）必须在档案中附上 URL 引用；捏造类比违反真实性规则