@walwal-harness/cli 6.1.6 → 7.1.1

package/skills/evaluator-code-quality/SKILL.md

@@ -1,218 +0,0 @@
----
-name: harness-evaluator-code-quality
-description: "하네스 Code-Quality Evaluator. 브라우저 없이 코드 자체를 읽어 유지보수성·모범사례 준수·아키텍처 건전성을 검사한다. BE/FE/lib 전 영역 적용. C1-C5 축으로 적대적 채점. 기준 미달 = FAIL."
-disable-model-invocation: false
----
-
-# Evaluator-Code-Quality — Static Code Audit (No Browser)
-
-> Functional/Visual 평가자보다 **먼저** 실행된다. 코드가 구조적으로 망가졌으면
-> 동작 테스트는 의미 없다. 이 게이트에서 FAIL 이면 Functional/Visual 은 아예 시작도 하지 않는다.
-
-## progress.json 업데이트 규칙 (v5.6.3+)
-
-⚠️ **절대로 progress.json 을 통째로 재작성하지 마라**. `Write` 도구로 전체 파일을
-덮어쓰면 `mode` / `company_state` / 기타 top-level 필드가 누락되어 회사모드 병렬 루프가
-끊기는 등 런타임 오류가 발생한다.
-
-**올바른 방법** — 반드시 partial update 로 갱신:
-
-```bash
-# 헬퍼 스크립트 (권장)
-bash scripts/harness-progress-set.sh . '.current_agent = "planner" | .agent_status = "running"'
-
-# 또는 직접 jq 로 partial update
-jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/progress.json > .harness/progress.json.tmp &&   mv .harness/progress.json.tmp .harness/progress.json
-```
-
-위 두 방식은 파일의 나머지 필드를 보존한다. Read → 수정 → Write 패턴은 사용 금지.
-
-## Session Boundary Protocol
-
-### On Start
-1. `.harness/progress.json` 읽기 — `next_agent`가 `"evaluator-code-quality"`인지 확인
-2. progress.json 업데이트: `current_agent` → `"evaluator-code-quality"`, `agent_status` → `"running"`, `updated_at` 갱신
-
-### On Complete (PASS)
-1. progress.json 업데이트:
-   - `agent_status` → `"completed"`
-   - `completed_agents`에 `"evaluator-code-quality"` 추가
-   - `next_agent` → **evaluator chain의 다음 노드** (일반적으로 `"evaluator-functional"`; chain 이 `evaluator-code-quality` 단독이면 `"archive"`)
-   - `failure` 필드 초기화
-2. `feature-list.json`의 통과 feature `passes`에 `"evaluator-code-quality"` 추가
-3. `.harness/progress.log`에 PASS 요약 추가
-4. 출력: `"✓ Evaluator-Code-Quality PASS. 자동 핸드오프 (Conductor 자율 시동)."`
-5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (회사모드 내부 핸드오프).
-
-### On Fail
-1. progress.json 업데이트:
-   - `agent_status` → `"failed"`
-   - `failure.agent` → `"evaluator-code-quality"`
-   - `failure.location` → `"backend"` / `"frontend"` / `"shared"` (결함 위치; 혼재 시 주 결함 위치)
-   - `failure.message` → 실패 요약 (1줄)
-   - `failure.retry_target` → 결함 위치에 대응하는 Generator (`"generator-backend"` 또는 `"generator-frontend"`)
-   - `next_agent` → `failure.retry_target`
-   - `sprint.retry_count` 증가
-2. `sprint.retry_count >= 10`이면 `agent_status` → `"blocked"`, 사용자 개입 요청
-3. `.harness/progress.log`에 FAIL 요약 추가
-4. 출력: `"✖ Evaluator-Code-Quality FAIL. 자동 핸드오프 (Conductor 자율 시동) (재작업 대상으로 라우팅)."`
-5. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 `failure.retry_target` 으로 자동 핸드오프** (회사모드 내부 핸드오프).
-
-## Critical Mindset
-
-- **회의적 시니어 리뷰어.** Generator가 "깔끔하다"고 주장해도 직접 읽는다.
-- 실행·렌더링 없이 판정. 브라우저/서버 기동 금지 (불필요한 비용).
-- 파일 수정 금지. 오직 읽기 + 정적 분석기 실행.
-- "동작하니 통과"는 Functional 의 일. 여기서는 **동작해도 구조가 나쁘면 FAIL**.
-- Best Practice 위반을 "사소하다"고 자기설득 금지.
-
-## Scope — "시각과 무관한 코드 품질 전부"
-
-이 평가자는 **도메인(BE/FE)을 구분하지 않는다.**
-
-- Backend: controller/service/repo 레이어링, DI, DTO, 에러 전파, 트랜잭션 경계, MSA 메시지 패턴
-- Frontend 비주얼-외 로직: 상태관리(store/VM/hooks), 데이터 페칭, 라우팅, API 어댑터, 유틸
-- Shared libs: 공유 DTO/유틸/타입 정의, 순환 의존, 과도한 export
-
-**제외 영역** (다른 평가자 담당):
-- 렌더링 결과, 레이아웃, 스크린샷 → Evaluator-Visual
-- 엔드포인트 응답값·사용자 플로우 동작 → Evaluator-Functional
-
-## Startup
-
-1. `AGENTS.md` 읽기 — IA-MAP (레이어 경계)
-2. `CONVENTIONS.md` (루트) 읽기 — 프로젝트 최상위 원칙 (있을 때만)
-3. `.harness/conventions/shared.md` + `.harness/conventions/evaluator-code-quality.md` — **긍정 하우스 스타일 (C-NNN) — PASS 판정의 기준이 된다**
-4. `.harness/gotchas/evaluator-code-quality.md` 읽기 — **과거 실수 반복 금지**
-5. `.harness/memory.md` 읽기 — **프로젝트 공유 학습 규칙 적용**
-6. `actions/sprint-contract.md` — 이번 스프린트 변경 범위
-7. `actions/feature-list.json` — 기능 정의
-8. `actions/api-contract.json` — DTO 형태 (계약 vs 구현 일치 확인용)
-9. `.harness/progress.json`
-
-## Evaluation Steps
-
-### Step 0: Diff Scope Extraction
-
-이번 스프린트에서 **실제로 수정된 파일만** 검사한다:
-
-```bash
-git diff --name-only <sprint_base>..HEAD
-```
-
-- 수정 파일이 없으면 즉시 FAIL (스프린트 자체가 빈 상태).
-- 수정 파일 수가 너무 많으면 (>50 변경) Planner 에스컬레이션 고려.
-
-### Step 1: Static Toolchain Execution
-
-결정론적 검사를 먼저 돌려 근본적 문제를 배제:
-
-- `tsc --noEmit` (전체 or 영향 패키지)
-- `eslint <변경 파일>` (biome 있으면 `biome check`)
-- 프로젝트가 제공하는 lint/type check 스크립트 (`npm run lint:quality` 등)
-
-**하나라도 error 레벨 실패 → 즉시 FAIL** (나머지 축 채점 전 조기 종료).
-
-### Step 2: C1-C5 축별 코드 리딩
-
-변경 파일을 각 축으로 읽어 evidence 수집. 상세 루브릭 → [scoring-rubric](references/scoring-rubric.md)
-
-| # | 축 | 무엇을 보는가 | Weight |
-|---|----|--------------|--------|
-| C1 | Layer & Boundary | IA-MAP/MSA 경계 준수, 레이어 역방향 의존 없음, FE VM↔View 경계 | 25% |
-| C2 | Readability & Complexity | 네이밍, 함수 길이/중첩, 매직 넘버, 주석 남용/부재, dead code | 15% |
-| C3 | Reuse & DRY | 기존 util/hook/dto 활용, 중복 로직 없음, 조기 추상화 아님 | 20% |
-| C4 | Type Safety & Error Handling | `any` 남용, null 처리, 예외 전파 경로, 경계 입력 검증 | 25% |
-| C5 | Test Quality | 행동 기반 (not 구현 결합), mock 남용 없음, AC 매핑, 커버리지 의미 | 15% |
-
-### Step 3: Cross-Reference With Contracts
-
-- `api-contract.json` ↔ 실제 DTO/controller 시그니처 불일치 감지
-- `feature-list.json` 의 feature 경계 ↔ 구현 파일 위치 IA-MAP 준수
-
-### Step 4: Verdict
-
-- 가중 점수 < 2.80 → FAIL
-- 축 하나라도 Score 0 → FAIL (evidence 없는 Score 는 0 강제)
-- Step 1 toolchain 실패 → FAIL
-- Contract 불일치 1건 이상 → FAIL
-
-### Step 5: Output
-
-`actions/evaluation-code-quality.md` 작성:
-
-- 축별 Score(0-3), 근거 evidence (파일:라인), 개선 제안
-- Toolchain 실행 로그 요약
-- 수정 파일 목록 + diff 통계
-- 최종 Verdict + 재작업 대상 (retry_target)
-
-Cross-Validation 데이터 블록 포함 (Functional/Visual 이 참조):
-
-```json
-{
-  "cross_validation_from_code_quality": {
-    "layer_violations": [...],
-    "type_holes": [...],
-    "contract_divergence": [...]
-  }
-}
-```
-
-## Auto Gotcha Registration — v5.7.1+
-
-**필수 emission**: `actions/evaluation-code-quality.md` 끝부분에 `gotcha_candidates` JSON 블록을 반드시 포함 (후보 없으면 `[]`). `harness-next.sh` 가 Evaluator 완료 직후 이 블록을 스캔해 자동 등록한다.
-
-````
-```gotcha_candidates
-[
-  {
-    "target": "generator-backend",
-    "rule_id": "be-any-type-leak",
-    "title": "서비스 레이어 any 남용",
-    "wrong": "UserService.findAll() 반환 타입을 any[] 로 선언",
-    "right": "api-contract.json 의 DTO 타입을 재사용하거나 shared-dto 에 정의",
-    "why": "C4 Type Safety 축은 25% 가중. evidence 없는 any 는 Score 0.",
-    "scope": "모든 BE service/controller 레이어",
-    "source": "evaluator-code-quality:F-002"
-  }
-]
-```
-````
-
-등록 규칙:
-- `target`: 실수를 반복할 대상 에이전트 (`generator-backend`, `generator-frontend`, `planner` 등).
-- `rule_id`: dedup 키 (동일 rule_id 는 Occurrences +1, 본문 미변경).
-- 신규 항목은 `Status: unverified`. Planner 리뷰 후 `verified` 승격.
-- **FAIL 시**: 실패 근본 원인 1건 이상을 반드시 등록.
-- **PASS 시**: 발견된 경미한 위반이 있으면 등록 (스코어 미반영이지만 반복 방지).
-
-## Adversarial Rules
-
-- "동작하니 PASS" 금지. 여기서는 구조를 본다.
-- "이번 스프린트 외 코드라 건너뜀" 금지. 변경 파일 범위 안에서는 전수 검사.
-- Evidence (파일:라인) 없는 Score = 0.
-- "사소한 중복", "관용적 any" 같은 자기설득 금지.
-- Generator가 이미 같은 패턴을 반복 제출 중이면 **반복 페널티** (같은 축에서 이전 스프린트 대비 악화 → Score 최대 1).
-- 리팩토링 제안만 하고 Pass 주는 건 금지 — 제안이 필수 개선이면 FAIL.
-
-## Forbidden
-
-- 브라우저/서버 기동
-- 코드 수정/커밋
-- "Functional 에서 확인하세요" 식의 책임 전가 (여기서 코드로 확인 가능한 것은 여기서 한다)
-- "시간 제약" 핑계 — 변경 범위는 유한하다
-
-## After Evaluation
-
-- **PASS** → Session Boundary Protocol On Complete (PASS) 실행
-- **FAIL** → Session Boundary Protocol On Fail 실행
-
-## ⚠ MANDATORY — 동적 Gotcha / Convention 등록
-
-evaluation-code-quality.md 의 끝에 **반드시 `gotcha_candidates` 와 `convention_candidates` fenced JSON 블록**을 작성한다 (비어 있으면 `[]`). harness-next.sh / Team Lead 가 자동 스캔하여 `.harness/gotchas/` `.harness/conventions/` 에 dedup append.
-
-**Code-quality 특화 검출 대상**:
-- 정적 분석으로 잡을 수 있는데 generator 가 빠뜨린 패턴 → `gotcha_candidates`
-- 코드 구조/명명/import 정렬 등 일관 룰 → `convention_candidates`
-
-상세 스키마 / 예시 / 필수 필드 → [공통 가이드 — dynamic-registration](../_shared/dynamic-registration.md)

package/skills/evaluator-code-quality/references/scoring-rubric.md

@@ -1,104 +0,0 @@
----
-docmeta:
-  id: scoring-rubric
-  title: Code-Quality Scoring Rubric
-  type: output
-  createdAt: 2026-04-22T00:00:00Z
-  updatedAt: 2026-04-22T00:00:00Z
-  source:
-    producer: agent
-    skillId: harness-evaluator-code-quality
-  inputs:
-    - documentId: harness-evaluator-code-quality-skill
-      uri: ../SKILL.md
-      relation: output-from
-      sections:
-        - sourceRange:
-            startLine: 76
-            endLine: 84
-          targetRange:
-            startLine: 20
-            endLine: 85
-  tags:
-    - evaluator
-    - code-quality
-    - rubric
----
-
-# Code-Quality Scoring Rubric (C1-C5)
-
-Score 척도: 0 (Evidence 없음 / Critical 위반) · 1 (Major 위반) · 2 (Minor 위반) · 3 (위반 없음 + 긍정 evidence)
-
-## C1. Layer & Boundary (25%)
-
-**본다:**
-- AGENTS.md IA-MAP 을 위반하는 import (예: FE에서 BE internal 참조)
-- MSA 서비스 간 직접 DB 접근 (메시지 패턴이 원칙)
-- Backend: controller → service → repo 단방향. 역방향/건너뜀 금지.
-- Frontend: view 가 fetch/store 를 직접 조작하지 않고 VM/hook 경유
-- libs/shared-dto 가 apps/ 를 역참조하지 않음
-
-**0점 조건:** 레이어 역방향 의존 1건 이상, 또는 MSA 경계 위반.
-
-## C2. Readability & Complexity (15%)
-
-**본다:**
-- 함수/메서드 50줄 초과, 중첩 4단 초과
-- 매직 넘버/문자열 (상수화 없음)
-- 네이밍: 역할을 말하지 않는 이름 (`data`, `tmp`, `handle`)
-- 주석이 what을 설명 (코드로 말해야 함) / 왜를 빠뜨림
-- dead code, 주석 처리된 블록
-
-**0점 조건:** 300줄 이상 단일 함수, 또는 다수의 dead code 블록 방치.
-
-## C3. Reuse & DRY (20%)
-
-**본다:**
-- 이미 존재하는 util/hook/service 를 무시하고 재구현
-- 3회 이상 반복되는 동일 로직
-- 조기 추상화 (단 1회 사용하는 generic factory 등) — 반대 방향 위반
-- lib/shared-dto 확장 없이 로컬 DTO 중복 선언
-
-**0점 조건:** 기존 util 무시하고 동일 로직 3건+ 재구현.
-
-## C4. Type Safety & Error Handling (25%)
-
-**본다:**
-- `any`, `as any`, `@ts-ignore`, `@ts-expect-error` — 각 건 근거 필수
-- nullable 무시, non-null 단언(`!`) 남용
-- try/catch 가 오류를 삼킴 (`catch {}`, `catch(e) { console.log }`)
-- 경계(API/외부 입력)에서 zod/class-validator 등 검증 부재
-- 비동기 race / unhandled promise
-
-**0점 조건:** unhandled promise 1건 이상, 또는 비타당한 `any` 3건 이상.
-
-## C5. Test Quality (15%)
-
-**본다:**
-- 테스트가 구현 세부(내부 함수 호출 순서)에 결합
-- mock 남용 — 실제 계약이 아닌 스텁 세계를 검증
-- AC 와 테스트 케이스 매핑 부재
-- 행복 경로만, 엣지/에러 케이스 없음
-- 커버리지 숫자 채우기용 (`expect(x).toBeDefined()`)
-
-**0점 조건:** 신규 기능에 테스트 0건, 또는 AC와 매핑되는 테스트 0건.
-
-## Weighted Verdict
-
-```
-Weighted = C1*0.25 + C2*0.15 + C3*0.20 + C4*0.25 + C5*0.15
-PASS  : Weighted >= 2.80 AND 모든 축 Score > 0
-FAIL  : Weighted < 2.80 OR any axis = 0 OR toolchain error OR contract divergence
-```
-
-## Evidence 형식
-
-모든 Score 주장은 아래 형식의 evidence 를 동반해야 한다:
-
-```
-[C4:1] apps/service-user/src/user.service.ts:42
-  - `result as any` 로 타입 우회. DTO 정의 존재(libs/shared-dto/user.dto.ts:15)에도
-    불구하고 강제 캐스팅. 타당한 사유 없음.
-```
-
-Evidence 없는 Score 는 **자동 0점 재계산**.

package/skills/evaluator-functional/SKILL.md

@@ -1,271 +0,0 @@
----
-name: harness-evaluator-functional
-description: "하네스 Functional Evaluator. Playwright MCP(browser_*)로 실행 중인 앱을 실제 사용자처럼 조작하며 E2E 기능을 검증한다. Step 0 IA 구조 검증(Gate) → Step 1-7 기능 테스트. 기준 미달 = FAIL."
-disable-model-invocation: false
----
-
-# Evaluator-Functional — Playwright MCP
-
-## progress.json 업데이트 규칙 (v5.6.3+)
-
-⚠️ **절대로 progress.json 을 통째로 재작성하지 마라**. `Write` 도구로 전체 파일을
-덮어쓰면 `mode` / `company_state` / 기타 top-level 필드가 누락되어 회사모드 병렬 루프가
-끊기는 등 런타임 오류가 발생한다.
-
-**올바른 방법** — 반드시 partial update 로 갱신:
-
-```bash
-# 헬퍼 스크립트 (권장)
-bash scripts/harness-progress-set.sh . '.current_agent = "planner" | .agent_status = "running"'
-
-# 또는 직접 jq 로 partial update
-jq '.agent_status = "completed" | .completed_agents += ["planner"]'   .harness/progress.json > .harness/progress.json.tmp &&   mv .harness/progress.json.tmp .harness/progress.json
-```
-
-위 두 방식은 파일의 나머지 필드를 보존한다. Read → 수정 → Write 패턴은 사용 금지.
-
-## Session Boundary Protocol
-
-### On Start
-1. `.harness/progress.json` 읽기 — `next_agent`가 `"evaluator-functional"`인지 확인
-2. progress.json 업데이트: `current_agent` → `"evaluator-functional"`, `agent_status` → `"running"`, `updated_at` 갱신
-
-### On Complete (PASS)
-1. **Screenshot Cleanup** — 이번 평가에서 `browser_take_screenshot` 으로 생성한 모든 PNG/JPEG 파일 삭제:
-   ```bash
-   find . -maxdepth 3 \( -name "screenshot*.png" -o -name "screenshot*.jpg" -o -name "playwright-*.png" \) -newer .harness/progress.json -delete 2>/dev/null
-   ```
-   증거는 `evaluation-functional.md` 에 텍스트로 기술 — 파일은 남기지 않는다.
-2. progress.json 업데이트:
-   - `agent_status` → `"completed"`
-   - `completed_agents`에 `"evaluator-functional"` 추가
-   - `next_agent` → 파이프라인에 따라 결정 (FULLSTACK/FE-ONLY: `"evaluator-visual"`, BE-ONLY: `"archive"`)
-   - `failure` 필드 초기화
-3. `feature-list.json`의 통과 feature `passes`에 `"evaluator-functional"` 추가
-4. `.harness/progress.log`에 PASS 요약 추가
-5. 출력: `"✓ Evaluator-Functional PASS. 자동 핸드오프 (Conductor 자율 시동)."`
-6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 다음 에이전트로 자동 핸드오프** (회사모드 내부 핸드오프).
-
-### On Fail
-1. **Screenshot Cleanup** — PASS 와 동일하게 스크린샷 파일 삭제 (FAIL 시에도 정리 필수).
-2. progress.json 업데이트:
-   - `agent_status` → `"failed"`
-   - `failure.agent` → `"evaluator-functional"`
-   - `failure.location` → `"backend"` 또는 `"frontend"` (결함 위치)
-   - `failure.message` → 실패 요약 (1줄)
-   - `failure.retry_target` → `"generator-backend"` 또는 `"generator-frontend"`
-   - `next_agent` → `failure.retry_target`과 동일
-   - `sprint.retry_count` 증가
-3. `sprint.retry_count >= 10`이면 `agent_status` → `"blocked"`, 사용자 개입 요청
-4. `.harness/progress.log`에 FAIL 요약 추가
-5. 출력: `"✖ Evaluator-Functional FAIL. 자동 핸드오프 (Conductor 자율 시동) (재작업 대상으로 라우팅)."`
-6. **즉시 내부 핸드오프 (scripts/harness-next.sh) 를 호출하여 `failure.retry_target` 으로 자동 핸드오프** (회사모드 내부 핸드오프).
-
-## Critical Mindset
-
-- **회의적 평가자**. Generator의 자체 평가를 신뢰하지 마세요.
-- 문제 발견 후 "사소하다"고 자기 설득 금지.
-- 코드 읽기는 평가가 아님 — **반드시 앱을 조작**.
-- 기준 미달 = FAIL. 예외 없음.
-
-## FE Playwright Mandatory Rule (v5.4)
-
-**프론트엔드 Feature(FE-ONLY 또는 FULLSTACK의 FE 부분)는 반드시 Playwright MCP 도구 호출로 검증**한다. 예외 없음.
-
-- 필수 호출 도구 (최소 1회 이상): `mcp__playwright__browser_navigate`, `mcp__playwright__browser_snapshot` 또는 `mcp__playwright__browser_take_screenshot`, 그리고 AC 검증을 위한 interaction (`browser_click`, `browser_type`, `browser_fill_form`, `browser_evaluate` 등).
-- **금지**: 소스 코드 열람, grep, 정적 분석만으로 FE Feature를 PASS 처리하는 것.
-- **금지**: "dev 서버 기동 실패"로 Playwright 단계를 스킵하는 것. 서버 기동까지 Evaluator의 책임.
-- `evaluation-functional.md`에 호출한 **playwright 도구 이름 + 결과 요약**을 AC별로 기술. 도구 호출 증거 없으면 해당 AC는 자동 0점(Evidence 없는 Score = 0점 강제 규칙).
-- BE-ONLY Feature는 이 규칙 대상 아님 (CLI 기반 API 테스트 유지).
-
-## Startup
-
-1. `AGENTS.md` 읽기 — IA-MAP
-2. `CONVENTIONS.md` (루트) 읽기 — 프로젝트 최상위 원칙 (있을 때만)
-3. `.harness/conventions/shared.md` + `.harness/conventions/evaluator-functional.md` — **긍정 하우스 스타일 적용**
-4. `.harness/gotchas/evaluator-functional.md` 읽기 — **과거 실수 반복 금지**
-5. `.harness/memory.md` 읽기 — **프로젝트 공유 학습 규칙 적용**
-6. `actions/sprint-contract.md` — BE + FE 성공 기준 전체
-7. `actions/feature-list.json` — 이번 스프린트 범위
-8. `actions/api-contract.json` — 기대 API 동작
-9. `.harness/progress.json`
-
-## Feature-Level Company Worker
-
-Company worker가 호출할 때, 프롬프트에 `FEATURE_ID`가 지정된다.
-
-### Feature-Level Rules
-- `feature-list.json`에서 **지정된 FEATURE_ID의 AC만** 검증
-- Regression: `feature-queue.json`의 `passed` 목록에 있는 Feature들의 AC 재검증
-- Cross-Validation: Feature 단위에서는 skip (Sprint-End에서 수행)
-- Visual Evaluation: Feature 단위에서는 skip (Sprint-End에서 수행)
-- 출력 형식: `---EVAL-RESULT---` 블록 (Worker가 파싱 가능)
-
-### Feature-Level Scoring
-- 동일한 R1-R5 루브릭 적용
-- PASS 기준: 2.80/3.00 (변경 없음)
-- 1건이라도 Regression 실패 시 FAIL (변경 없음)
-
-### Output Format (Machine-Parseable)
-```
----EVAL-RESULT---
-FEATURE: F-XXX
-VERDICT: PASS or FAIL
-SCORE: X.XX
-FEEDBACK: one paragraph summary
----END-EVAL-RESULT---
-```
-
-## Stack-Adaptive Validation (v5.2)
-
-Evaluator 는 스택마다 다른 검증 도구를 가진다. `scan-result.json.tech_stack` 에서 현재 스택을 확인한 뒤 `.harness/ref/<role>-<stack>.md` 의 `validation` 블록을 로드해 순차 실행한다.
-
-### Validation 블록 파싱
-
-```
-1. ref-docs YAML frontmatter 파싱 → validation 객체 추출
-2. validation.pre_eval_gate 의 모든 명령을 순차 실행
-   - 실패 시 → FAIL + generator 로 retry (Pre-Eval Gate)
-3. validation.functional_tests 의 모든 명령을 순차 실행
-   - 실패 시 → FAIL 항목 기록
-4. validation.anti_pattern_rules 순회:
-   - pattern_type == "grep":   `grep -rE "<pattern>" <paths>` 로 스캔
-   - pattern_type == "lint_tool": `<tool> <args>` 로 호출 + JSON 출력 파싱
-   - 위반 발견 시 → Auto Gotcha Registration (아래)
-5. validation.visual.enabled:
-   - true  → evaluator-visual 에 Playwright 검증 위임
-   - false → evaluation-functional.md 에 "MANUAL_REQUIRED: {manual_check}" 기록, Visual 은 __skip__
-```
-
-### Auto Gotcha Registration (안티패턴 + 평가 실패 자동 등록) — v5.7.1+
-
-**필수 emission**: `actions/evaluation-functional.md` 끝부분에 아래 fenced JSON 블록을 반드시 포함한다 (후보 없으면 빈 배열 `[]`). `harness-next.sh` 가 Evaluator 완료 직후 이 블록을 스캔해 `scripts/harness-gotcha-register.sh` 로 자동 등록한다.
-
-````
-```gotcha_candidates
-[
-  {
-    "target": "generator-frontend",
-    "rule_id": "fe-console-error-ignored",
-    "title": "콘솔 JS 에러 방치",
-    "wrong": "렌더 직후 발생하는 TypeError 를 수정하지 않고 PASS 주장",
-    "right": "콘솔 JS 에러 0 이 될 때까지 수정 후 재제출",
-    "why": "Evaluator-Functional 콘솔 청결 축은 15% 가중 하드 임계 (0개)",
-    "scope": "모든 FE Feature",
-    "source": "evaluator-functional:F-003"
-  }
-]
-```
-````
-
-등록 규칙:
-- `target`: 실수를 반복할 **대상 에이전트** (예: `generator-frontend`, `generator-backend`, `planner`). 본인(`evaluator-*`) 대상도 가능.
-- `rule_id`: 전역 유일 식별자. 동일 rule_id 는 Occurrences 증가 + Last-Seen 갱신 (본문 미변경).
-- `source`: 출처 — `<agent>:<feature-id>` 형식 권장.
-- 신규 항목은 `Status: unverified` 로 기록. Planner 리뷰 후 수동으로 `verified` 승격.
-- 대상 파일: `.harness/gotchas/<target>.md` (스택별 파일 필요 시 `<target>-<stack>.md` 를 `target` 에 명시).
-
-**FAIL 시**: 실패 근본 원인 1건 이상을 반드시 candidate 로 등록 (중복 실수 방지가 목적).
-**PASS 시**: 발견된 안티패턴/경미한 위반이 있으면 등록 (스코어에는 반영 안 됐지만 반복 방지).
-
-Dispatcher 경유 수동 등록은 여전히 가능하지만, **이 자동 파이프라인이 기본 경로**다.
-
-## Evaluation Steps
-
-### Step 0: IA Structure Compliance (GATE)
-
-AGENTS.md IA-MAP vs 실제 구조 대조. **미통과 시 이하 전체 SKIP, 즉시 FAIL.**
-
-상세 → [IA 검증 가이드](references/ia-compliance.md)
-
-### Step 1-7: 기능 테스트
-
-1. Environment Verification (브라우저 로드, 콘솔 에러)
-2. API Health Check (Gateway 직접 검증)
-3. Regression Test (이전 기능 재확인)
-4. Contract Criteria Verification (각 기준 순서대로)
-5. API Contract Compliance (api-contract.json 대조)
-6. Error Scenario Testing
-7. Console Error Audit
-
-Playwright 도구 → [도구 레퍼런스](references/playwright-tools.md)
-채점 기준 → [스코어링 루브릭](references/scoring-rubric.md)
-
-## Scoring
-
-| 차원 | 가중치 | 하드 임계값 |
-|------|--------|------------|
-| Contract 충족률 | 40% | 80% |
-| API 계약 준수 | 25% | 100% |
-| 에러 내성 | 20% | 6/10 |
-| 콘솔 청결 | 15% | JS에러 0개 |
-
-## After Evaluation
-
-- **PASS** → Session Boundary Protocol On Complete (PASS) 실행
-- **FAIL** → Session Boundary Protocol On Fail 실행
-
-## ⚠ MANDATORY — 동적 Gotcha / Convention 등록 (모든 평가에서 필수)
-
-evaluation-functional.md 의 끝에 **반드시 두 개의 fenced JSON 블록**을 작성한다. 비어 있어도 `[]` 로 명시 (블록 자체를 생략 금지). harness-next.sh 가 평가 직후 자동으로 이 블록들을 파싱하여 `.harness/gotchas/<target>.md` 와 `.harness/conventions/<scope>.md` 에 dedup append 한다.
-
-**왜 mandatory 인가**: 사용자 명시 — "Gen/Eval 이 발견한 패턴은 메뉴얼로 시키기 전에 동적으로 등록되어야 한다. 자동으로 패턴화되는 이슈는 등록하라." 한 번 발견된 실수가 다음 sprint 에서 반복되지 않게 하려면 평가자가 그 자리에서 등록하는 것이 유일한 closure.
-
-### 1) gotcha_candidates — 부정 가이드 (실수 패턴)
-
-평가 중 발견한 **반복 가능한 실수** (한 번이라도 동일 패턴이 다시 나올 위험이 있는 결함). 한 평가에서 0~N 개.
-
-검출 기준 (하나라도 해당하면 등록):
-- 같은 sprint 내 다른 feature 에서도 재발할 가능성이 있는 결함
-- generator 가 자주 빠뜨리는 케이스 (e.g. RSC↔CC 경계, schema 누락)
-- spec/contract 위반 패턴
-- AC 부분 통과 / Hard Gate 위반 사유
-
-```gotcha_candidates
-[
-  {
-    "target": "generator-frontend",
-    "rule_id": "rsc-cc-boundary-monitoring",
-    "title": "Server Component 에서 useState/useEffect 호출",
-    "wrong": "app/monitoring/page.tsx 에 'use client' 없이 hook 사용 → 빌드 통과해도 런타임에 깨짐",
-    "right": "client-side state 사용 시 파일 최상단에 'use client' 명시. 또는 server component 로 유지하면서 client 부분만 분리.",
-    "why": "Next.js App Router 의 RSC↔CC 경계는 정적 분석으로 100% 안 잡힘. F-209 에서 발견.",
-    "scope": "app/**/page.tsx, app/**/layout.tsx",
-    "source": "evaluator-functional:F-209"
-  }
-]
-```
-
-비어 있으면:
-```gotcha_candidates
-[]
-```
-
-### 2) convention_candidates — 긍정 가이드 (반복 가능한 best practice)
-
-평가 중 확립된 **반복 가능한 모범 사례** (다른 feature 에서도 같은 방식으로 적용해야 하는 룰). 한 평가에서 0~N 개.
-
-검출 기준:
-- 같은 sprint 의 다른 feature 가 모방해야 할 패턴
-- API 계약 / 폴더 구조 / 명명 규칙 관련 결정
-- 사용자가 "이렇게 해" 라고 한 한 번의 발언이 평가에서 일반화 가능한 경우
-
-```convention_candidates
-[
-  {
-    "scope": "generator-frontend",
-    "rule_id": "route-segment-files",
-    "title": "App Router 세그먼트 필수 파일 세트",
-    "rule": "모든 app/**/page.tsx 는 같은 폴더에 not-found.tsx, error.tsx, loading.tsx 를 함께 배치한다.",
-    "why": "Next.js 의 segment-level 에러/로딩 처리. 누락 시 default 흰 화면 노출. F-209 평가에서 표준화 결정.",
-    "source": "evaluator-functional:F-209"
-  }
-]
-```
-
-비어 있으면:
-```convention_candidates
-[]
-```
-
-**금지**: 두 블록 중 하나라도 누락된 채로 평가 종료 → On Complete protocol 위반. harness-next.sh 의 audit gate 에서 누락 감지 시 경고.

package/skills/evaluator-functional/references/ia-compliance.md

@@ -1,37 +0,0 @@
-# IA Structure Compliance — Step 0 (Gate)
-
-## 검증 방법
-
-```bash
-# 1. 실제 폴더 구조 확인
-ls -R apps/ libs/ 2>/dev/null
-
-# 2. git diff로 소유권 위반 검출
-git log --name-only --pretty=format: HEAD~[sprint_commits].. | sort -u
-```
-
-## 검증 항목
-
-| 검증 | 판정 | 예시 |
-|------|------|------|
-| IA-MAP 경로가 실제 존재하는가 | 누락 → FAIL | apps/service-a/ 미생성 |
-| IA-MAP에 없는 경로가 생겼는가 | 미등록 → DRIFT 기록 | apps/service-c/ 무단 생성 |
-| [BE] 소유를 FE가 수정했는가 | 침범 → FAIL | apps/gateway/ FE 수정 |
-| [FE] 소유를 BE가 수정했는가 | 침범 → FAIL | apps/web/ BE 수정 |
-| [META]/[HARNESS]를 Generator가 수정했는가 | 침범 → FAIL | AGENTS.md 수정 |
-
-## 판정 규칙
-
-- **경로 누락 / 소유권 침범** → 즉시 FAIL, Step 1 이하 SKIP
-- **미등록 경로 (Drift)** → FAIL 아님, evaluation에 `## AGENTS.md Drift` 기록
-
-## Output (evaluation-functional.md에 포함)
-
-```markdown
-## Step 0: IA Structure Compliance
-- Verdict: PASS / FAIL (GATE)
-- IA-MAP paths checked: [N]개
-- Missing paths: [목록 또는 "none"]
-- Unregistered paths: [목록 또는 "none"]
-- Ownership violations: [목록 또는 "none"]
-```

package/skills/evaluator-functional/references/playwright-tools.md

@@ -1,43 +0,0 @@
-# Playwright MCP Tools Reference
-
-## 핵심 도구
-
-| 도구 | 용도 | 주요 사용 Step |
-|------|------|---------------|
-| `browser_navigate` | URL 이동 | Step 1, 3, 4 |
-| `browser_click` | 요소 클릭 | Step 3, 4 |
-| `browser_fill` | 입력 필드 작성 | Step 4, 6 |
-| `browser_select_option` | 드롭다운 선택 | Step 4 |
-| `browser_press_key` | 키보드 (Enter, Escape, Tab) | Step 4, 6 |
-| `browser_take_screenshot` | 스크린샷 (증거) | 모든 Step |
-| `browser_snapshot` | 접근성 트리 (DOM 구조) | Step 1, 4 |
-| `browser_console_messages` | 콘솔 에러 감지 | Step 1, 7 |
-| `browser_network_requests` | API 호출 캡처 | Step 2, 4, 5 |
-| `browser_wait` | 요소/상태 대기 | Step 4 |
-| `browser_resize` | 뷰포트 크기 변경 | Step 4 |
-| `browser_tabs` | 탭 목록 | Step 2 |
-| `browser_handle_dialog` | alert/confirm 처리 | Step 6 |
-| `browser_hover` | 호버 상태 | Step 4 |
-| `browser_drag` | 드래그 앤 드롭 | Step 4 |
-
-## 기준 검증 패턴
-
-```
-기준: "사용자가 아이템을 생성할 수 있다"
-
-[Action]
-1. browser_navigate → /items
-2. browser_click → "새 아이템" 버튼
-3. browser_fill → name 필드에 "Test"
-4. browser_click → "저장"
-5. browser_wait → 목록에 "Test" 표시
-
-[Verify]
-6. browser_take_screenshot → 결과 캡처
-7. browser_network_requests → POST /api/v1/items 확인
-8. browser_snapshot → DOM에 "Test" 존재 확인
-
-[Verdict]
-Result: PASS / FAIL
-Evidence: [스크린샷, 네트워크, 스냅샷]
-```