the-hit

任务执行：执行与并行编码

概述

Worker 和 Crew Lead 会实现执行计划中定义的 Work Package。各 Crew 会同时在各自负责的区域开展工作，并向 Underboss 提交 Report（状态更新）。

触发条件

在 Don 批准执行计划后调用（资源开发完成）。

流程

步骤 1：Underboss 分发 Work Package

对于每个区域，Underboss 会向 Crew Lead 发送：

• 区域定义
• 分配的 Work Package（按依赖关系排序）
• 相关的 Contract 章节
• 适用的 Constitution 规则

步骤 2：Crew Lead 派遣 Worker

每位 Crew Lead（调用 gangsta:the-capo）处理其 Work Package：

1. 对每个独立的 Work Package，派遣一个 subagent_type: "soldier" 的 Worker 子 Agent（不要使用 "general" 或 "general-purpose"——它们在 Gangsta Agents 安装中无效），并提供：

   • Work Package 简述
   • 正在实现的 Contract 条款
   • 适用的 Negative Constraints
   • 区域约定
   • 预防提醒：Worker 不得在源代码、测试、注释或文档中复现 Gangsta 内部规范标识符（FR-xxx、NFR-xxx、WP-xxx，其中 xxx 为一位或多位数字）。这是预防指导，不是检查门槛。
   • **技术债务预防简报（洗钱门槛）：**Laundering 会通过五项技术债务检查来阻止 Heist。Worker 今天就必须构建好，以通过明天的检查：
     1. **复制/粘贴：**不要在多个文件中以 5 行或更多代码复制 build_setup。如果两个调用点共享逻辑，请提取辅助函数，或将差异参数化。Laundering 会通过 jscpd 检测重复代码（min-lines 5，min-tokens 35）。
     2. **长文件：**每个文件的源代码行数目标为 ≤ 300 行。达到 500 行会被硬性阻止。如果 Work Package 要求创建长文件，Contract 必须明确指出，且 Don 必须预先批准，否则应按职责拆分。
     3. **测试覆盖率：**为每个新增的公共函数和每个修改过的分支编写测试。Laundering 会与 Heist 前的覆盖率基线进行比较；修改代码的覆盖率不得下降。如果项目配置中设有覆盖率阈值，测试运行必须达到该阈值。
     4. **整洁的架构：**导入方向应沿层级向下（domain → application → infrastructure → delivery）；控制器、路由处理程序、数据库适配器或网络客户端中不得包含业务逻辑；每个文件只负责一项职责。
     5. **整洁的代码：**报告前移除死代码；函数 ≤ 50 行（不计空行和注释）；通过提前返回将嵌套层级控制在 ≤ 4 层；生产代码路径中不得使用魔法数字；标识符必须能清楚表明自身含义。
   • Worker Report 必须针对这五项进行自我报告。参见步骤 4。

2. Worker 在其所属区域内并行工作（人数不超过分配的 Worker 数量）

步骤 3：强制执行 TDD

每位 Worker 必须遵循 gangsta:drill-tdd，完成完整的 Red-Green-Refactor 循环：

1. 编写失败的测试——依据验收标准编写
2. 运行测试——确认测试因正确原因失败
3. 编写最少量实现——只编写足以通过测试的代码
4. 运行测试——确认测试通过
5. 根据技术债务简报进行重构——在 Refactor 阶段，根据五项 Laundering 门槛检查：不得与现有代码复制/粘贴，文件不得超过长文件阈值，测试必须覆盖新增代码，导入方向必须向下，不得有死代码、过长函数、深层嵌套、魔法数字或含义不明的标识符。任何一项不合格，Laundering 都会阻止 Heist。
6. 报告——向 Crew Lead 返回 Report

先写实现、后写测试的 Worker，其 Report 将被拒绝。

步骤 4：收集报告

每位 Worker 返回一份 Report：

## 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:** <issues, concerns, deviations, technical-debt risks for Laundering>

第 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——单轮处理：Devils-Advocate 攻击拟议的修复方案，Don 发表意见，Synthesizer 生成修订后的 Contract 条款
4. Underboss 向 Don 升级处理——超出运营范围时

第 8 步：完成

所有 Crew Lead 均报告各自辖区已完成时：

1. Underboss 验证：所有 Work Package 均已接受，所有测试均已通过
2. 写入最终检查点（status: 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 合规检查

• 引介规则：通过 Crew Lead 派遣 Worker，不得直接与 Worker 通信
• 真实报告规则：报告必须包含实际测试输出，而非口头声称
• 预算规则：跟踪每次派遣 Worker 的令牌用量
• 规范即法律：每项实现都必须通过 Work Package 追溯到某条 Contract 条款
• 技术债简报：每次派遣 Worker 都必须附上 Laundering 关卡简报的五个要点；每份报告都必须包含技术债自检
• 可用性规则：每批任务完成后更新检查点