harness-exec

Harness 任务执行（Generator）

上下文管理: ✅ 保持当前上下文，但采用轻量级上下文策略

核心原则：依赖磁盘文件，不依赖对话记忆

每个任务的上下文来源：
1. spec文档（如 `[DATA_MODEL_DOC]`, `[API_CONTRACT_ROOT]`）→ 直接 Read 文件
2. 前置任务的产出 → Read 磁盘上已生成的代码文件，不是回忆对话历史
3. Generator模板 → 内化规则，不需要每次重新加载全文

❌ 错误：在上下文中保留前5个任务的完整对话过程
✅ 正确：每个任务只 Read 它直接依赖的已生成文件

指令

执行当前 Sprint 中的下一个（或指定的）任务。

输入参数

$ARGUMENTS — 可选，指定任务ID（如 "T009"）或 "batch"。不指定则自动取进度文件中的下一个未完成任务。

执行步骤

1. 定位任务:

   • 找到最新的 sprint-*-progress.md 文件
   • 如果用户指定了任务ID，执行该任务
   • 否则找到第一个状态为 [ ] 的行（包括 🚧 批次门禁行）
   • ⛔ 批次门禁规则: 如果下一个 [ ] 行是 🚧 批次门禁，必须先执行 L1 Step 4 验证并标记通过，才能继续后续任务。不得跳过门禁行去执行下一个普通任务。门禁行的执行方式见步骤 4 中 Step 4 的说明。

2. 加载最小上下文（关键：只读必要文件，从磁盘读不从记忆读）:

   判断任务类型，按类型加载：

   任务类型	从 spec 文档读	从磁盘已生成文件读
   数据迁移	[DATA_MODEL_DOC]（仅相关对象段落）	无
   数据模型	[DATA_MODEL_DOC]（仅相关对象段落）	对应迁移/结构定义（确认字段与约束）
   业务逻辑单元	[API_CONTRACT_ROOT]（对应接口） + spec.md（对应验收场景）	依赖的数据模型/业务接口（确认字段和方法签名）
   接口入口	[API_CONTRACT_ROOT]（对应接口）	依赖的业务逻辑单元（确认方法签名）
   用户界面接口适配	[API_CONTRACT_ROOT]（对应接口）	无（直接按契约生成）
   用户界面页面/组件	spec.md（对应验收场景）	对应的用户界面接口适配（确认可用函数）
   提示模板	spec.md（相关场景描述）	无

3. 执行 Generator（TDD 流程）:

   根据 .harness/prompts/generator.md 中对应模板执行。 含业务逻辑的任务必须遵循 TDD：

   Step 1 — Red:   先写测试，定义预期行为，确认测试失败
   Step 2 — Green: 写最小实现代码，使测试通过
   Step 3 — Refactor: 重构代码，保持测试通过
   

   不含业务逻辑的任务（数据迁移、配置、数据模型、传输对象）不要求 TDD。

4. 执行 Evaluator Level 1 — CI 门禁（强制，自动化）:

   模拟 CI/CD 流水线，按顺序执行，任一步失败则阻断，不得进入 L2：

   ┌─────────────────────────────────────────────────────┐
   │ Step 1: 单元测试（门禁）                              │
   │                                                     │
   │ [TEST_COMMAND]                                      │
   │                                                     │
   │ ⛔ 阻断规则:                                         │
   │ - 任务含业务逻辑但无测试文件 → FAIL（未完成）           │
   │ - 任何测试失败 → FAIL                                │
   │ - 测试不通过不得进入下一步                             │
   ├─────────────────────────────────────────────────────┤
   │ Step 2: 编译                                        │
   │                                                     │
   │ [BUILD_COMMAND]                                     │
   │ [TYPECHECK_COMMAND]（如项目需要独立类型检查）           │
   ├─────────────────────────────────────────────────────┤
   │ Step 3: Lint                                        │
   │                                                     │
   │ [LINT_COMMAND] 无 ERROR                              │
   ├─────────────────────────────────────────────────────┤
   │ Step 4: 应用启动 + 集成验证（批次完成时执行）             │
   │                                                     │
   │ 4a. 启动项目依赖服务（如适用）→ 依赖健康                │
   │ 4b. [APP_START_COMMAND] → health UP + 数据迁移 OK     │
   │ 4c. [UI_START_COMMAND] → 页面可访问                   │
   │ 4d. 接口集成: 读取 [API_CONTRACT_ROOT] 构造真实请求     │
   │     对已实现的每个接口验证正常+异常路径                │
   │                                                     │
   │ ⛔ 编译通过 ≠ 能启动，启动成功 ≠ 功能可用              │
   │ 触发时机: 每个批次完成后 / Sprint Checkpoint           │
   └─────────────────────────────────────────────────────┘
   
   全部 ✅ → 进入 Level 2
   任一 ❌ → 进入 Corrector（最多3轮），3轮后仍失败则阻塞报告