The Hit

The Hit: Execution and Parallel Coding

Overview

Workers and Crew Leads implement the Work Packages defined in the Execution Plan. Crews work simultaneously on their assigned territories, providing Reports (status updates) to the Underboss.

Trigger

Invoked after the Don approves the Execution Plan (Resource Development complete).

Process

Step 1: Underboss Distributes Work Packages

For each territory, the Underboss sends the Crew Lead:

• The territory definition
• The assigned Work Packages (ordered by dependency)
• The relevant Contract sections
• The applicable Constitution rules

Step 2: Crew Leads Dispatch Workers

Each Crew Lead (invoke gangsta:the-capo) processes their Work Packages:

1. For each independent Work Package, dispatch a Worker subagent with subagent_type: "soldier" (do NOT use "general" or "general-purpose" — these are not valid in a Gangsta Agents installation), providing:

   • The Work Package brief
   • The Contract clause being implemented
   • Applicable Negative Constraints
   • Territory conventions
   • Prevention reminder: Workers MUST NOT reproduce Gangsta-internal spec identifiers (FR-xxx, NFR-xxx, WP-xxx, where xxx is one or more digits) in source code, tests, comments, or documentation. This is prevention guidance, not a gate.
   • Technical-debt prevention brief (Laundering gate): Laundering will block the Heist on five technical-debt checks. Workers must build today to pass those checks tomorrow:
     1. Copy/paste: do not clone build_setup in 5+ lines across files. If two call sites share logic, extract a helper or parameterize the variation. The duplicate will be caught by jscpd (min-lines 5, min-tokens 35) in Laundering.
     2. Long files: target ≤ 300 source lines per file. Hard block at 500. If a Work Package forces a long file, the Contract must name it and the Don must pre-approve — otherwise split by responsibility.
     3. Test coverage: write tests for every new public function and every modified branch. Laundering compares against the pre-Heist coverage baseline; coverage on modified code may not drop. If the project has a coverage threshold in its config, the run must meet it.
     4. Clean architecture: imports flow downward through layers (domain → application → infrastructure → delivery); no business logic in controllers, route handlers, DB adapters, or network clients; one responsibility per file.
     5. Clean code: remove dead code before reporting; functions ≤ 50 lines (blank/comment excluded); nesting ≤ 4 levels via early returns; no magic numbers in production paths; identifiers must name themselves.
   • Worker Report must self-report against these five points. See Step 4.

2. Workers work in parallel within their territory (up to the allocated Worker count)

Step 3: TDD Enforcement

Every Worker MUST follow gangsta:drill-tdd — the full Red-Green-Refactor cycle:

1. Write failing test — Based on the acceptance criteria
2. Run test — Verify it fails for the right reason
3. Write minimal implementation — Just enough to pass the test
4. Run test — Verify it passes
5. Refactor against the technical-debt brief — during the Refactor phase, verify against the five Laundering-gate items: no copy/paste with existing code, file under the long-file threshold, tests cover the new code, imports flow downward, no dead code / long functions / deep nesting / magic numbers / unnamed identifiers. Laundering will block the Heist on any of these.
6. Report — Return Report to Crew Lead

A Worker that writes implementation before tests has its Report REJECTED.

Step 4: Report Collection

Each Worker returns a Report:

markdownCopy code
## 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:**

Step 5: Crew Lead Reviews Reports

The Crew Lead reviews each Report (invoke gangsta:the-capo):

• Acceptance criteria met?
• TDD cycle followed?
• Tests passing?
• Convention compliance?
• Technical-debt self-check present and plausible? A Worker that reports NONE for every box without justification is suspect — flag for audit. The self-check is the early-warning system; Laundering enforces the gate.

Accept, reject with feedback, or escalate.

Step 6: Status Rollup

Crew Leads report territory status to the Underboss. The Underboss synthesizes for the Don:

markdownCopy code
## 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

Step 7: Escalation Handling

When a Worker fails:

1. Crew Lead retries — Fresh Worker, same Work Package
2. Crew Lead escalates to Underboss — If retry fails or Contract is ambiguous
3. Underboss mini-Grilling — Single-pass: Devils-Advocate attacks the proposed fix, Don weighs in, Synthesizer produces revised Contract clause
4. Underboss escalates to Don — If beyond operational scope

Step 8: Completion

When all Crew Leads report territory completion:

1. Underboss verifies: all Work Packages accepted, all tests passing
2. Write the final checkpoint (status: completed, next-action: Proceed to Laundering)
3. Immediately invoke gangsta:laundering — do NOT ask the Don what to do next, do NOT pause, do NOT prompt for confirmation. (This auto-advance is an authorized exception — documented in using-gangsta at the "Never auto-advance" rule, and in the-sit-down.)

Checkpoint

Write checkpoint after each significant batch of Work Packages completes (not just at the end):

yamlCopy code
---
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 Compliance

• Introduction Rule: Workers dispatched through Crew Leads, no direct Worker communication
• Rule of Truth: Reports include actual test output, not claims
• Rule of Budget: Token usage tracked per Worker dispatch
• Spec is Law: Every implementation traces to a Contract clause via Work Package
• Technical-Debt Brief: Every Worker dispatch includes the five-point Laundering-gate brief; every Report includes a Technical-Debt Self-Check
• Rule of Availability: Checkpoint updated after each batch