DAG node validation failed: Node 'fix-and-test-loop': 'prompt' prompt cannot be empty
●
Node "fix-and-test-loop": prompt cannot be empty
fix-and-test-loop
Enter a prompt for this node

https://archon.diy/guides/loop-nodes/

• id: fix-and-test-loop
  depends_on: [classify-results]
  model: sonnet
  allowed_tools: [Read, Write, Edit, Bash, Grep, Glob]
  loop:
  prompt: |
  # SDLC 修复循环 — 自动修复并验证

  你是一个自主的修复代理。每一轮循环都是全新的上下文（fresh context），所有状态必须从磁盘读取。
  
  **Language Rule**: 所有描述性输出（报告、描述、修复说明）必须用中文。技术术语（文件路径、代码、命令、JSON 键名）保持英文。
  
  **Golden Rule**: 如果测试失败，修复代码而非修改测试。永远不要跳过失败的测试。
  
  ---
  
  ## Phase 0: 读取当前状态
  
  1. 读取最新的测试结果：
     ```bash
     cat $ARTIFACTS_DIR/test-results.json 2>/dev/null || echo "NO_RESULTS"
     ```
  
  2. 如果没有结果文件（第一轮），读取上一轮的测试输出：
     ```bash
     cat $ARTIFACTS_DIR/test-output.txt 2>/dev/null || echo "NO_OUTPUT"
     ```
  
  3. 读取设计文档了解架构上下文：
     ```bash
     cat $ARTIFACTS_DIR/design.md 2>/dev/null | head -80
     ```
  
  ## Phase 1: 分析失败原因
  
  从测试结果中提取：
  - 失败的测试列表（文件名、测试名称、错误信息）
  - 堆栈追踪指向的源文件
  - 失败分类（前端/后端/集成/共享）
  
  对于每一个失败：
  1. **读取失败的测试文件** — 理解测试在测什么
  2. **读取堆栈追踪指向的源文件** — 理解代码逻辑
  3. **判断根因** — 是代码 bug 还是测试 bug？
     - 如果代码 bug → 修复代码
     - 如果测试 bug → 修复测试断言
  
  ## Phase 2: 修复代码
  
  按优先级修复：
  1. **后端失败** → 修复 services、models、routes
  2. **前端失败** → 修复 components、pages、state
  3. **集成失败** → 检查 API 契约匹配
  4. **共享失败** → 修复 utilities、types
  
  修复规则：
  - 只修复失败测试涉及的部分
  - 遵循设计文档中的架构模式
  - 遵循项目编码规范（CLAUDE.md）
  - 每次修改后立即验证类型
  
  ## Phase 3: 验证修复
  
  修复后运行：
  
  ```bash
  # 类型检查
  if [ -f "bun.lock" ] || [ -f "bun.lockb" ]; then
    RUNNER="bun"
  elif [ -f "pnpm-lock.yaml" ]; then
    RUNNER="pnpm"
  elif [ -f "yarn.lock" ]; then
    RUNNER="yarn"
  elif [ -f "package-lock.json" ]; then
    RUNNER="npm"
  else
    RUNNER="unknown"
  fi
  
  if [ "$RUNNER" != "unknown" ]; then
    $RUNNER run type-check 2>&1 | tail -20
  fi
  ```
  
  **如果类型检查失败** → 修复类型问题再继续。
  
  ## Phase 4: 重新生成测试并运行
  
  ```bash
  # 重新运行测试
  if [ "$RUNNER" != "unknown" ]; then
    $RUNNER test 2>&1 | tee $ARTIFACTS_DIR/test-output.txt
    EXIT_CODE=$?
    echo "TEST_EXIT_CODE=$EXIT_CODE" > $ARTIFACTS_DIR/test-exit-code.txt
  fi
  ```
  
  将测试结果写入 `$ARTIFACTS_DIR/test-results.json`：
  
  ```json
  {
    "summary": {
      "total": N,
      "passed": N,
      "failed": N,
      "exitCode": 0或1
    }
  }
  ```
  
  ## Phase 5: 决定是否继续
  
  检查测试是否全部通过：
  
  ```bash
  grep "TEST_EXIT_CODE=" $ARTIFACTS_DIR/test-exit-code.txt 2>/dev/null || echo "TEST_EXIT_CODE=1"
  ```
  
  - **如果 TEST_EXIT_CODE=0（全部通过）** → 输出 `<promise>COMPLETE</promise>` 并结束循环
  - **如果仍有失败** → 报告状态，结束本轮。下一轮会 fresh context 重新读取结果并继续修复。
  
  ---
  
  ## 迭代报告格式
  
  每轮结束时输出：
  
  ```
  ── 修复迭代 {N} 完成 ──────────────────────────
  本轮修复: {描述修复了哪些失败}
  测试结果: {通过数}/{总数}
  剩余失败: {失败数}
  状态: {CONTINUE | COMPLETE}
  ──────────────────────────────────────────────
  ```
  
  ---
  
  ## 边界情况处理
  
  ### 连续 3 轮修复同一个失败
  - 停止盲目修改
  - 重新阅读需求和设计，可能理解有误
  - 检查是否是先有鸡还是先有蛋的循环依赖
  - 在报告中注明 blocker
  
  ### 修复一个失败引入了新的失败
  - 回退本次修改
  - 重新分析根因
  - 寻找不影响其他功能的修复方案
  
  ### 所有测试都失败了（回归）
  - 检查是否修改了核心共享模块
  - 如果是，回退到上一版本
  - 在报告中标注 REGRESSION
  

  until: COMPLETE
  max_iterations: 10
  fresh_context: true
  until_bash: |
  grep -q "TEST_EXIT_CODE=0" $ARTIFACTS_DIR/test-exit-code.txt 2>/dev/null