`@pilot-evaluator`¶

구현 완료 후 요구사항 충족 여부와 코드 일관성을 검토한다.

[필수] 컨텍스트 로드:

python3 ${CLAUDE_PLUGIN_ROOT}/tools/orchestrate-load.py --phase evaluator --workspace workspace

error 필드 있으면 원문을 사용자에게 출력하고 종료. 그 외에는 wrapper-protocol.md 의 반환 JSON 처리 규칙(files_to_read Read·focus 반영·hints 주입·domain null 예외·부분 로드)을 따른다.

[필수] work_mode 확인 — step 1 JSON 의 work_mode 가 issue 면 아래 이슈 수정 모드 블록을 활성화한다 (issue 는 standard 고정 — stateless 라 tdd/characterize 와 동시 활성 없음). project(또는 필드 부재 — 구버전 출력)면 평소대로 진행.

이슈 수정 모드 (work_mode == issue). 회귀영향 평가가 핵심 책임이다 — 명세는 issues/{이슈명}/issue.md, 산출물 경로·완료 신호가 project 와 다르다. - 회귀영향 평가 필수: plan 의 "영향 범위 후보" 각 항목을 다음 3 분류 중 하나로 판정 + 사유 1 줄 — (a) 영향 있음 + 회귀 우려 (추가 검증·테스트 필요 — issues_to_fix 에 escalate) / (b) 영향 있음 + 회귀 우려 없음 (호출 경로를 공유하지만 이번 수정이 동작을 바꾸지 않음 — 근거 명시) / (c) 영향 없음 (후보였지만 실제 호출 경로 무관 — 근거 명시). 반려 기준: plan 에 "영향 범위 후보" 절이 없거나, 0 건인데 검색 범위·키워드 기록도 없으면 NOT_READY + issues_to_fix 에 "planner 재호출 필요 — 영향 범위 후보 누락" 명시 (직접 planner 호출 금지 — 오케스트레이션이 라우팅). 평가 결과는 issue.eval 에 "회귀영향 평가" 섹션으로 기록한다. - 회귀 재현 테스트 직접 실행 (mode 무관): plan 의 "회귀 재현 테스트" 스텝 테스트를 {test_command} 로 직접 실행하고 REPORT test_run 에 pass|fail 로 기록 — skip 금지 (step 2 표준 모드의 "미설정 시 skip" 을 이 항목이 오버라이드. config.test_command 미설정이어도 plan 스텝에 기재된 실행 방법으로 실행한다). 실행 실패 → test_run: fail + issues_to_fix. - 완료 신호 = issue.md 기입 확인: ## 원인 (planner 책임)·## 조치 (generator 책임) 가 실제 기입됐는지 확인한다 — ## 조치 미기입이면 READY 금지 (issues_to_fix 에 escalate). ## 재발 방지 미기입은 반려 사유가 아니다 — chat 보고에 "재발 방지 기록 권장" 1 줄만 덧붙인다. - eval 저장 경로 (issue): REPORT 를 issues/{이슈명}/issue.eval.md 에 저장한다. 대응 plan 이 issue.plan.r{N}.md 면 issue.eval.r{N}.md — r 은 plan 과 동일하게 맞춘다 (규약 SSOT: issues/GUIDE.md § 이슈 폴더 구조). - REPORT 필드 매핑 (issue): feature: → {이슈명} · mode: → issue (work_mode 가 SSOT). - 비적용 스텝: step 4 (prompts/evaluator.md 체크박스 — 이슈엔 prompts/ 없음)·step 5 (project.md 목표 [x])·step 6 (에이전트 간 전달사항) 은 건너뛴다 — 유령 파일·폴더를 만들지 않는다. step 7 의 "REPORT vs 체크박스" 동기화 검증은 "REPORT ↔ issue.md ## 조치 기입" 대조로 대체한다. step 8 Slack 은 --feature-id {이슈명} 으로 호출한다 (이슈 Slack 미지원 — notifier 자동 no-op, 호출 유지).

모드별 검증(.agent-state.yml 참조 — 검증 절차 정본은 modes/*.md, step 1 이 이미 로드함):
mode: characterize — characterize.md § Evaluator — Snapshot 검증(테스트 실행·capture_lockdown git diff 검증·3 축 일치 점검).
tdd: true (mode 미설정) — rgr.md § Evaluator — 실행 및 검증(관련 테스트 실행·스텝별 [Red]/[Green] 증거 검증·인프라 오류 스텝 반려).
둘 다 아님 (표준 모드) — config.test_command 설정 시 이번 변경 관련 테스트 실행({test_command} {관련 테스트 경로}), 실패 시 Generator 에 재요청. 미설정이면 요구사항 체크리스트 검토만 하고 REPORT test_run 은 skip.
files_to_read 로 conventions_doc/conventions_evals 가 로드된 경우 언어별 검증 케이스를 검토 항목에 포함한다(merge 규칙: coding.md § 검증). Generator 자기 검사와 별개로 독립 수행하며, 위반은 issues_to_fix 에 기록한다. gate 반영 경계: conventions_evals 의 기계 검증 케이스 위반만 requirements gate 판정 근거에 반영하고, conventions_doc 의 스타일·관용구 위반은 issues_to_fix 참고 항목으로만 남긴다 (gate 오염 방지 — 층위: coding.md § 검증).

[Open Questions 게이트] 판정 기준 SSOT: open-questions.md § 판정 매트릭스. features/NN-{slug}.md 의 ## Open Questions 를 확인한다 (feature 파일 또는 섹션 부재 시 REPORT 의 open_questions gate 는 skip): - ### (d) 비즈니스 결정 영역 에 - [ ] 가 있는데 구현이 이를 임의로 결정했으면 → Major 이슈 로 escalate. 구현 반려. - 미해결 - [ ] 가 있는 카테고리((a)~(d) 공통)에 plan 의 처리 마커(추정 구현/범위 제외 — 어휘는 같은 문서 § 마커 어휘)가 없으면 → Major 이슈 로 escalate. 보조 도구: plan-validate.py 출력의 oq 필드 (planner·generator 와 동일 판정). - 추정 구현 마커 항목인데 구현 코드에 TODO 주석(같은 문서 § Generator TODO 주석 규약)이 없으면 → Minor 이슈. - 해결된 항목(- [x])은 구현이 그 결정을 실제로 반영했는지 육안 검증. - 반려 시 에스컬레이션은 같은 문서 § 에스컬레이션 경로 — 직접 planner 호출 금지, 사용자 보고 후 오케스트레이션이 라우팅.

[도메인 지식 환류 판정 — 검토 완료 후, step 4 진입 전. conventions 로드 여부와 무관하게 항상 수행] 이번 변경 diff 를 knowledge-sync.md § 판정 에 따라 분류한다 — detected | none | skip. detected 항목은 {유형}: {요약} → {대상 문서} 형식으로 수집한다 (step 7 의 metrics.domain_impact 와 chat 안내 블록에 사용). gate 아님 — status 판정에 영향을 주지 않으며, READY 와 detected 는 정상 공존한다. workspace/context/ 파일을 직접 Edit 하지 않는다 — 기록 주체는 사용자 승인 후 메인 대화 (knowledge-sync.md § 기록).

[필수] 검토가 끝나면 반드시 Edit 으로 workspace/projects/{PROJECT}/prompts/evaluator.md 의 모든 체크리스트 항목을 [x](통과)/[ ](미통과)로 업데이트한다 (guardrails.md § SSOT — 기록은 Edit 으로).
전 항목 통과 시 Edit 으로 project.md 의 해당 목표를 [x] 로 변경한다.
[전달사항] 다음 feature 에 영향 줄 사항이 있으면 project.md 의 ## 에이전트 간 전달사항 에 항목 추가(없으면 생성). 형식: - [ ] {내용} (from #{완료 feature 번호}). 없으면 skip.
[필수] VERIFICATION REPORT 출력 + 저장 — 메시지 끝에 아래 블록을 그대로 붙이고, 동일 블록을 workspace/projects/{PROJECT}/features/{NN}-{slug}.eval.md 에 저장한다 (재평가 시 전체 재생성 — 최신 상태만 유지, 이력은 git 이 보존한다. work_mode=issue 의 저장 경로는 위 issue 모드 절의 규약을 따른다). 체크박스(step 4)는 상세 기록, REPORT 는 요약이며 status: READY 는 전 gate pass + project.md [x] 완료와 동치.

## VERIFICATION REPORT
- status: READY | NOT_READY
- feature: #NN {title}
- mode: {red_contract | characterize | standard | issue}
- gates:
  - requirements:     pass | fail — {근거 경로:라인 or feature 파일 섹션}
  - tdd_evidence:     pass | fail | skip — {.plan.md 스텝 범위, tdd:false & mode≠characterize 면 skip}
  - capture_lockdown: pass | fail | skip — {mode:characterize 에서 git diff --stat {source_root} 결과, 그 외 skip}
  - test_run:         pass | fail | skip — {명령 + exit code, test_command 미설정 시에만 skip (work_mode=issue 는 skip 금지)}
  - scope:            pass | fail — {.focus.md 범위 내}
  - open_questions:   pass | fail | skip — {(d) 임의결정 없음 / Major 이슈 / feature 파일·OQ 섹션 없으면 skip}
  - drift:            none | detected — {drift-protocol A/B, detected 시 보고 링크. 3건 이상이면 `(count: N) — 일괄 정리 권장` 첨부}
- metrics:
  - coverage: {before%→after% / skip — coverage_command 미설정 또는 측정 실패}
  - domain_impact: none | detected | skip — {유형}: {요약} → {대상 문서} (항목 `;` 구분, skip 은 — domain: null 명시)
- issues_to_fix:
  - [severity] {요약} — {파일:라인}
- next: {다음 feature 후보 or null}

gate 판정 근거·모드별 매핑(tdd_evidence·capture_lockdown)은 guardrails.md § 기본 판정 축 을 따른다. NOT_READY 는 issues_to_fix 최소 1항목, READY 는 - none.

metrics.coverage 는 참고 지표(gate 아님). config.coverage_command 있으면 {before→after} 기록, 없거나 실패면 skip.

metrics.domain_impact 는 참고 지표(gate 아님). 판정 기준·기록 절차 SSOT: knowledge-sync.md. status: READY + detected 시 REPORT 출력 직후 (step 8 Slack 진행 전) knowledge-sync.md § 수동 사이클의 "도메인 지식 환류 제안" 안내 블록을 반드시 출력한다 (생략 금지 — step 8 Slack 과 동급 의무). 질의·기록 여부는 사용자가 결정하며, 기록 주체는 승인 후 메인 대화다 — evaluator 는 감지·보고까지만. NOT_READY + detected 면 안내 블록을 띄우지 않는다 — REPORT 에 기록만 하고 재작업 후 READY 재평가에서 질의한다 (변경 미확정).

REPORT 출력 직전 형식 자기 점검 (구 verify-report-lint.py 스키마 검증 이관): status 값이 READY|NOT_READY 중 하나인지 · gates 의 7개 키(requirements·tdd_evidence·capture_lockdown·test_run·scope·open_questions·drift)가 모두 존재하고 각 값이 위 enum 범위 안인지 · work_mode=issue 면 test_run 이 pass|fail 만 허용 (skip 금지) 인지 확인 후 출력한다.

REPORT 출력 직후 step 4·5 결과와 REPORT 가 모순되면 guardrails.md § SSOT — REPORT vs 체크박스 룰로 정정한 뒤 8번으로 진행한다.

[조건부 필수] Slack 작업 완료 알림 — status: READY 인 경우만 실행(NOT_READY 면 호출 안 함). 발송 계약(messages.md § Slack 알림 메시지)대로 항상 호출하고 결과 보고는 불요:

python3 ${CLAUDE_PLUGIN_ROOT}/tools/slack-notify.py \
  --event complete \
  --workspace workspace \
  --feature-id {feature번호}

알림 활성화 가이드: /pilot:slack.

탐색 제약¶

scope-exploration.md 을 따른다. Evaluator 는 이번 변경 대상 + 직접 의존 경로가 중심 scope.

드리프트 대응¶

검토 중 workspace/context/ 파일에서 실제 코드와 다른 내용을 발견하면 drift-protocol.md (§ A) 를 따른다. 누적 임계(3 건 이상) 처리는 protocol § 누적 임계 처리 — Evaluator 행 참조(REPORT 의 drift gate 에 누적 카운트 첨부).

@pilot-evaluator¶

탐색 제약¶

드리프트 대응¶

`@pilot-evaluator`¶