test

테스트 실행

호출되면 바로 파이프라인을 시작한다. 단계가 바뀔 때 한 줄로 진행을 알린다.

대상: $ARGUMENTS

---

파이프라인 구조

테스트 실행 (Bash) → 결과 판독 (이 세션, 러너 요약 줄·종료코드)
                          │ 실패가 있으면
                          ▼
                    fix-bugs 위임 → 수정 반영 확인 → 재실행
                    (전부 통과 · 또는 아래 상한에서 중단)

---

1단계: 프로젝트 타입 감지 및 테스트 실행

프로젝트에 맞는 테스트 명령 실행:

# Python 프로젝트
pytest $ARGUMENTS -v --tb=short

# Node.js 프로젝트
npm test $ARGUMENTS

# Go 프로젝트
go test $ARGUMENTS ./...

# Rust 프로젝트
cargo test $ARGUMENTS

---

위임 수단이 없는 하네스 — 강등 경로

아래 subagent_type: 블록은 운송 수단일 뿐이고, 불변식은 블록의 prompt: 계약(검사 항목·출력 형식·완료 선언)이다. 쓸 수 있는 수단을 호스트에 확인하고 위에서부터 한 칸씩 내려간다: ① 네이티브 서브에이전트(블록 그대로) → ② 호스트의 다른 격리 위임 수단(에이전트 정의 본문 <플러그인 루트>/agents/<이름>.md 를 요약 없이 넘기고 뒤에 prompt: 를 붙인다 — 플러그인 루트 탐색은 skills/plan-task/references/task-tools-fallback.md §A. 회신 요약이 아니라 계약 산출물로 판정한다) → ③ 이 세션에서 같은 계약을 직접 수행. 수단이 없다고 단계를 건너뛰거나 하지 않은 위임을 했다고 보고하지 않는다. ③은 격리가 없다 — 판정을 요약으로 대체하지 말고 테스트 러너의 실제 마지막 줄을 그대로 인용한다(종료코드를 파이프로 죽이지 말 것).

2단계: 결과 검증

러너의 요약 줄과 종료 코드를 직접 읽어 통과/실패/스킵 수를 확정한다(별도 에이전트 불필요). 실패가 있으면 실패 출력을 그대로 3단계로 넘긴다 — 원인 분석은 fix-bugs 가 한다.

---

3단계: 실패 시 버그 수정

실패가 있으면 fix-bugs 에이전트로 수정한다. fix-bugs 는 isolation: worktree 라 수정이 격리 트리에 남는다 — 이 세션의 트리에서 재실행하면 옛 코드를 검증한다. 그래서 위임 뒤에 수정을 이 세션에 반영(에이전트가 돌려준 diff/브랜치를 적용·병합)한 다음에만 재실행한다. 반영 방법은 호스트와 rules/parallel-worktree.md 의 반환·통합 절을 따른다. 반영하지 못했으면 "수정 미반영 — 재실행 불가"로 보고하고 멈춘다(재실행 결과를 수정 효과로 읽지 않는다).

Task tool 사용:
subagent_type: fix-bugs
model: sonnet
prompt: |
  다음 테스트 실패를 수정해주세요:
  [실패한 테스트 출력]

  각 실패에 대해:
  1. 실패한 테스트명
  2. 에러 메시지
  3. 예상 vs 실제 값
  4. 코드 수정

---

재시도 상한 [건너뛰기 금지]

"전부 통과할 때까지"는 무한 루프다. 수정→반영→재실행을 최대 3회까지만 돌리고, 아래 중 하나면 그 자리에서 멈춰 현재 상태(남은 실패·시도한 수정·마지막 러너 출력)를 사용자에게 보고한다:

• 3회째 재실행에서도 실패가 남았다
• 무진전 2회 — 연속 두 번의 재실행에서 실패한 테스트 집합이 줄지 않았다(같거나 늘었다)
• 같은 테스트가 같은 메시지로 반복 실패한다(원인을 못 건드리고 있다는 신호다)

(rules/loop-engineering.md 의 안티-런어웨이 가드와 같은 취지다.)

---

출력 형식

테스트 결과

항목	결과
총 테스트	N개
통과	N개
실패	N개
스킵	N개

실패 상세 (있으면)

[테스트별 원인과 수정 방안]

수정 결과 (실패 시)

[fix-bugs 에이전트 적용 결과]