the-sit-down

相談会：計画と仕様書の草案作成

概要

相談会では、ドン、コンシリエーレ、アンダーボスが契約を最終決定します。契約は、強盗計画を拘束する仕様書です。ここは「計画優先」のフェーズであり、コード生成は厳格に禁止されています。

トリガー

ドンがグリリングの合意事項を承認した後に実行されます（グリリング完了）。

絶対ルール

相談会中のコード生成は禁止です。

擬似コードも、「サンプルスニペット」も、「実装の草案」も禁止です。コードに見えるものは一切禁止です。コードを書いていることに気づいたら、停止してください。オメルタ法第5条に違反しています。

契約では、WHAT（何を）とWHY（なぜ）を定めます。実装の詳細であるHOW（どのように）は、リソース開発中に作成する作業パッケージに記載します。

フロー

digraph sit_down {
    "Synthesize inputs\n(Dossier + Grilling + Constitution)" [shape=box];
    "Propose 2-3 approaches" [shape=box];
    "Don approves approach?" [shape=diamond];
    "Draft the Contract" [shape=box];
    "Consigliere review\n(contradiction, ambiguity, completeness)" [shape=box];
    "Consigliere verdict?" [shape=diamond];
    "Don signs Contract?" [shape=diamond];
    "Invoke gangsta:resource-development" [shape=doublecircle];

    "Synthesize inputs\n(Dossier + Grilling + Constitution)" -> "Propose 2-3 approaches";
    "Propose 2-3 approaches" -> "Don approves approach?";
    "Don approves approach?" -> "Propose 2-3 approaches" [label="revise"];
    "Don approves approach?" -> "Draft the Contract" [label="approved"];
    "Draft the Contract" -> "Consigliere review\n(contradiction, ambiguity, completeness)";
    "Consigliere review\n(contradiction, ambiguity, completeness)" -> "Consigliere verdict?";
    "Consigliere verdict?" -> "Draft the Contract" [label="REJECT"];
    "Consigliere verdict?" -> "Don signs Contract?" [label="APPROVE"];
    "Don signs Contract?" -> "Draft the Contract" [label="changes requested"];
    "Don signs Contract?" -> "Invoke gangsta:resource-development" [label="signed"];
}

プロセス

ステップ 1：入力情報を統合する

入手可能なすべての情報を収集し、把握します。

• 偵察資料
• グリリングの合意事項、または入手可能な最善の合意事項
• プロジェクト憲章（戒律と否定的制約）
• 関連する台帳の記載事項

ステップ 2：2～3つのアプローチを提案する

仕様書を作成する前に、アンダーボスは問題に対する実行可能な異なるアプローチを2～3つドンに提示しなければなりません。各アプローチでは、次の内容を網羅してください。

### Approach A: <Name>
<One-sentence description>

**Pros:** <key advantages>
**Cons:** <key trade-offs>
**Risk:** HIGH / MEDIUM / LOW
**Best when:** <conditions that favour this approach>

ルール：

• アプローチは実質的に異なるものにしてください。同じ案のわずかな違いではいけません。
• 少なくとも1つは保守的で安全な案、もう1つはより大胆な案にしてください。
• コードや擬似コードは使わず、アーキテクチャとその根拠だけを示してください。

すべてのアプローチを提示した後、次のように尋ねてください。「どのアプローチで進めますか？　それとも調整をご希望ですか？」

この選択肢は、プラットフォーム標準のインタラクティブな選択ツール（OpenCode の question、Claude Code の AskUserQuestion）を使って提示してください。単にリストをプレーンテキストで提示して、返答を待つだけではいけません。そのようなツールがない場合に限り、プレーンテキストを使用します。

ドンが明示的に選択するまで、何も作成せずに待ってください。

• ドンが選択／承認した場合 → ステップ 3 に進みます
• ドンが修正を求めた場合 → 提案を更新して再提示します

ステップ 3：アンダーボスが契約の草案を作成する

承認されたアプローチをアーキテクチャの基盤として、正式な仕様書の草案を作成します。

契約には次の内容を含める必要があります。

---
heist: <heist-name>
date: YYYY-MM-DD
status: draft
signatories: []
---

# Contract: <Heist Name>

## Objective
<What is being built, in one paragraph>

## Requirements
### Functional Requirements
1. <FR-001> <Requirement>
2. <FR-002> <Requirement>
...

### Non-Functional Requirements
1. <NFR-001> <Requirement (performance, security, accessibility, etc.)>
...

## Architectural Decisions
<Key decisions from the Grilling consensus, with rationale>

## Grilling Conclusions
### Key Decisions
- <Decision>: <rationale>

### Rejected Alternatives
- <Alternative>: <why rejected>

### Unresolved Objections
- <Objection> — Risk: HIGH/MEDIUM/LOW — Mitigation: <if any>

## Applicable Constitution Rules
### Commandments
- <Commandment text> — Source: insights/<file>

### Negative Constraints
- NEVER <constraint> — Source: fails/<file>

## Acceptance Criteria
<How do we know the Heist is complete? Specific, testable criteria.>

## Out of Scope
<What this Heist explicitly does NOT cover>

## Open Risks
<From the Grilling — any unresolved objections with assessed risk>

ステップ 4：コンシリエーレがレビューする

仕様書の整合性レビューを依頼するため、gangsta:the-consigliere を呼び出します。

• 矛盾の確認
• 曖昧さの確認
• 完全性の監査
• 憲章との整合性
• セキュリティレビュー

コンシリエーレは次のいずれかの判定を返します。APPROVE、APPROVE WITH CONCERNS、REJECT。

REJECT の場合：アンダーボスはコンシリエーレのフィードバックに基づいて修正し、再レビューを依頼します。

ステップ 5：ドンが契約に署名する

契約をドンに提示します。

「強盗計画『』の契約がレビュー可能な状態になりました。コンシリエーレの判定：[verdict]。[懸念事項がある場合は列挙してください。] 承認しますか？」

ドンは次のいずれかを選択できます。

• 署名する — 契約が拘束力を持ちます。直ちに gangsta:resource-development を呼び出してください。次に何をするかドンに尋ねたり、一時停止したり、確認を求めたりしてはいけません。自動的に次へ進むことが必須です。
• 変更を求める — アンダーボスが修正します。ステップ 4 に戻り、コンシリエーレが再レビューします。
• 強盗計画を中止する — 中止します。以降のフェーズには進みません。

契約のフロントマターを更新します。

status: signed
signatories: [Don, Consigliere, Underboss]

出力

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

チェックポイント

---
heist: <heist-name>
phase: the-sit-down
status: completed
timestamp: <ISO 8601>
next-action: Proceed to Resource Development
artifacts:
  - docs/gangsta/<heist-name>/specs/YYYY-MM-DD-contract.md
---

オメルタ遵守チェック

• 仕様書は法：契約が拘束力のある仕様書となり、今後のすべてのフェーズは契約に準拠しなければなりません
• 真実のルール：すべての要件に、偵察資料の調査結果またはグリリングの合意事項を引用します
• 可用性のルール：契約とチェックポイントをファイルに保存します
• コード禁止：契約にコードブロックが一切含まれていないことを確認します