the-hit

ヒット：実行と並行コーディング

概要

ワーカーとクルーリーダーは、実行計画で定義されたワークパッケージを実装します。各クルーは割り当てられた担当領域で同時に作業し、アンダーボスにレポート（状況報告）を提出します。

トリガー

ドンが実行計画を承認した後に呼び出されます（リソース開発の完了後）。

プロセス

ステップ 1：アンダーボスがワークパッケージを配布する

各担当領域について、アンダーボスはクルーリーダーに次の内容を送ります。

• 担当領域の定義
• 割り当てられたワークパッケージ（依存関係の順）
• 関連する契約のセクション
• 適用される憲章の規則

ステップ 2：クルーリーダーがワーカーを派遣する

各クルーリーダー（gangsta:the-capo を呼び出す）は、自分のワークパッケージを処理します。

1. それぞれの独立したワークパッケージについて、次の内容を指定して subagent_type: "soldier" のワーカーサブエージェントを派遣します（Gangsta Agents のインストールでは "general" または "general-purpose" は有効ではないため、使用しないでください）。

   • ワークパッケージの概要
   • 実装する契約条項
   • 適用される禁止事項
   • 担当領域の規約
   • 再発防止の注意：ワーカーは、Gangsta 内部の仕様識別子（FR-xxx、NFR-xxx、WP-xxx。xxx は1桁以上の数字）をソースコード、テスト、コメント、ドキュメントに記載してはなりません。これは再発防止のための指針であり、ゲートではありません。
   • 技術的負債の予防ブリーフ（Laundering ゲート）： Laundering は、5つの技術的負債チェックで Heist をブロックします。ワーカーは、明日のチェックに合格できるよう、今日から備える必要があります。
     1. コピー＆ペースト： 複数のファイルにわたって build_setup を5行以上複製しないでください。2つの呼び出し箇所でロジックを共有する場合は、ヘルパーを抽出するか、差異をパラメーター化してください。重複は Laundering で jscpd（min-lines 5、min-tokens 35）によって検出されます。
     2. 長いファイル： ソース行数はファイルあたり300行以下を目標にしてください。500行でハードブロックされます。ワークパッケージの要件上、長いファイルが避けられない場合は、契約にそのファイルを明記し、ドンの事前承認を得てください。そうでなければ、責務ごとに分割してください。
     3. テストカバレッジ： 新しい公開関数と変更したすべての分岐に対してテストを書いてください。Laundering は実行前のカバレッジを基準として比較します。変更したコードのカバレッジを低下させてはなりません。プロジェクトの設定にカバレッジしきい値がある場合、実行結果がそのしきい値を満たす必要があります。
     4. クリーンアーキテクチャ： インポートはレイヤーを下向きに流れるようにします（ドメイン → アプリケーション → インフラストラクチャ → デリバリー）。コントローラー、ルートハンドラー、DB アダプター、ネットワーククライアントにビジネスロジックを置かず、1ファイルにつき1つの責務とします。
     5. クリーンコード： レポート前にデッドコードを削除してください。関数は50行以下（空行とコメントを除く）、早期リターンを使ってネストは4段階以下とします。本番コードの処理経路にマジックナンバーを使わず、識別子はその内容が分かる名前にしてください。
   • ワーカーレポートでは、この5項目に照らした自己評価を報告してください。ステップ4を参照してください。

2. ワーカーは、担当領域内で並行して作業します（割り当てられたワーカー数まで）。

ステップ 3：TDD の徹底

すべてのワーカーは、gangsta:drill-tdd に従い、Red-Green-Refactor サイクルを完全に実施しなければなりません。

1. 失敗するテストを書く — 受け入れ基準に基づいて作成します
2. テストを実行する — 想定どおりの理由で失敗することを確認します
3. 最小限の実装を書く — テストに合格するために必要な分だけ実装します
4. テストを実行する — 合格することを確認します
5. 技術的負債のブリーフに照らしてリファクタリングする — リファクタリング段階で、Laundering ゲートの5項目を確認します。既存コードとのコピー＆ペーストがないこと、ファイルが長さのしきい値未満であること、新しいコードがテストでカバーされていること、インポートが下向きに流れること、デッドコード・長い関数・深いネスト・マジックナンバー・名前のない識別子がないことを確認してください。これらのいずれかがあると、Laundering は Heist をブロックします。
6. 報告する — レポートをクルーリーダーに返します

テストを書く前に実装を行ったワーカーのレポートは却下されます。

ステップ 4：レポートの収集

各ワーカーはレポートを返します。

## Report: <WP-ID>
**Status:** success | failure | blocked
**TDD Cycle:**
- Test written: YES/NO
- Test failed first: YES/NO
- Implementation written: YES/NO
- Test passes: YES/NO
**Changes:**
- <file path>: <created/modified>
**Technical-Debt Self-Check:**
- Copy/paste: NONE | <file pair + reason if duplicated>
- Long files (longest created/modified): <N> lines
- Test coverage: <new/modified public functions and branches covered — list any uncovered>
- Clean architecture: <layer of each modified file + direction of any new import>
- Clean code: <functions >50 lines? nesting >4? magic numbers? dead code? — list any>
**Test Output:**

``` **Notes:** ``` ### ステップ 5：Crew Lead がレポートをレビューする

Crew Lead は各レポートをレビューします（gangsta:the-capo を呼び出します）。

• 受け入れ基準を満たしていますか？
• TDD サイクルに従っていますか？
• テストはパスしていますか？
• 規約に準拠していますか？
• 技術的負債のセルフチェックが含まれており、妥当な内容ですか？ 根拠もなくすべての項目に「なし」と報告する Worker は疑わしいため、監査対象としてフラグを立てます。セルフチェックは早期警告システムであり、Laundering がゲートを適用します。

承認するか、フィードバックを添えて却下するか、エスカレーションします。

ステップ 6：ステータスの集約

Crew Lead は担当領域のステータスを Underboss に報告します。Underboss は Don 向けに情報をまとめます。

## Heist Progress: <Heist Name>

| Territory | Completed | In Progress | Failed | Budget Used |
|-----------|-----------|-------------|--------|-------------|
| Frontend  | 3/5       | 1           | 1      | 60%         |
| Backend   | 4/4       | 0           | 0      | 45%         |
| ...       |           |             |        |             |

**Overall:** <N>/<Total> Work Packages complete

ステップ 7：エスカレーションへの対応

Worker が失敗した場合：

1. Crew Lead が再試行する — 新しい Worker に同じ Work Package を割り当てます
2. Crew Lead が Underboss にエスカレーションする — 再試行が失敗した場合、または Contract が曖昧な場合
3. Underboss がミニ Grilling を実施する — 1 回のパスで実施します。Devils-Advocate が提案された修正を攻撃し、Don が意見を述べ、Synthesizer が Contract の条項を改訂します
4. Underboss が Don にエスカレーションする — 運用範囲を超える場合

ステップ 8：完了

すべての Crew Lead が担当領域の完了を報告したら：

1. Underboss が確認します：すべての Work Package が承認され、すべてのテストがパスしていること
2. 最終チェックポイントを書き込みます（ステータス：completed、next-action：Proceed to Laundering）
3. 直ちに gangsta:laundering を呼び出します。次に何をすべきか Don に尋ねたり、一時停止したり、確認を求めたりしてはいけません。（この自動進行は、using-gangsta の「Never auto-advance」ルールと the-sit-down に記載された、認可済みの例外です。）

チェックポイント

最後だけでなく、Work Package のまとまった一群が完了するたびにチェックポイントを書き込みます。

---
heist: <heist-name>
phase: the-hit
status: in-progress | completed
timestamp: <ISO 8601>
next-action: <Continue Hit | Proceed to Laundering (auto)>
completed-wps: [WP-001, WP-002, ...]
pending-wps: [WP-003, ...]
failed-wps: [WP-004, ...]
artifacts:
  - <list of modified/created files>
---

Omerta の遵守

• 紹介ルール：Worker は Crew Lead を通じて派遣し、Worker と直接やり取りしない
• 真実のルール：レポートには主張ではなく、実際のテスト出力を含める
• 予算のルール：Worker の派遣ごとにトークン使用量を記録する
• 仕様は法律：すべての実装を Work Package を通じて Contract の条項に紐付ける
• 技術的負債のブリーフ：Worker の派遣ごとに 5 項目の Laundering ゲート向けブリーフを含め、すべてのレポートに技術的負債のセルフチェックを含める
• 可用性のルール：各バッチの後にチェックポイントを更新する