agent-verify은(는) 무엇을 하나요?
구축한 것을 가장 저렴한 메커니즘으로 검증할 수 있게 만드세요. 기본값은 CLI를 통한 검증입니다. 모델은 ~20토큰 (PASS / FAIL: line)을 읽어야 하며, DOM 덤프나 스크린샷을 절대 읽지 않아야 합니다.
하나의 규칙
기능을 틀렸다고 증명할 수 있는 가장 가벼운 메커니즘을 사용하세요. 불가능할 때만 더 무거운 메커니즘으로 확장하세요.
인-프로세스 단언문 → CLI / curl + 종료 코드 → DB 테스트 (TAP) → 헤드리스 브라우저 (시각적 전용, 최후의 수단)
가장 저렴함 가장 비쌈
에이전트가 구축하는 것의 90% (로직, 데이터, API 계약, 흐름)는 브라우저 없이 검증 가능합니다. 브라우저는 픽셀에만 사용하세요.
루프 (기능별)
- 한 번 감지하세요.
scripts/detect-stack.sh를 실행하세요. 몇 줄로 테스트 러너와 스택을 출력합니다. 새 프레임워크를 강요하지 마세요. — 있는 것을 사용하세요. - 기능을 구축하세요.
- 스택의 인-프로세스/CLI 프리미티브를 사용하여 하나의 토큰 최소화 검사를 작성하세요 (
reference/stacks/참조). 검사는PASS또는 단일FAIL:줄을 출력해야 합니다. — 덤프는 절대 안 됩니다. VERIFICATION_MAP.md에 한 줄을 추가하세요:feature | command | pass-signal. 이것이 다음 번에 에이전트가 읽을 계약입니다.scripts/verify.sh [feature]를 실행하고 결과만 읽으세요. 로그가 아닌 결과를 편집 → 확인 → 반복하세요.
하지 말아야 할 것
- 로직, 데이터 또는 API 응답을 확인하기 위해 Playwright/브라우저를 사용하지 마세요. 이것이 이 스킬이 막으려는 토큰 누수입니다.
- TDD 의식을 규정하지 마세요. 어떤 검사가 이 기능을 증명하는지 표면화하세요. 절차가 아닙니다. (대상 컨텍스트 없는 절차는 측정 가능하게 역효과를 냅니다. —
reference/patterns.md참조.) - 원시 출력을 컨텍스트에 반환하지 마세요. 샌드박스에서 필터링하고 결과만 표면화하세요 (
console.log(result), 10k 행이 아닌). - 검사가 커지지 않도록 하세요. 하나의 기능, 하나의 빠르고 결정적인 검사.
VERIFICATION_MAP.md를 짧게 유지하세요. — 짧은 맵이 긴 맵보다 성능이 좋습니다.
출력 계약 (항상)
PASS auth-login
FAIL create-invoice: expected 201, got 500
종료 코드 0 = 모두 통과. 0이 아님 = 일부 실패. 이것이 모델이 필요한 전부입니다.
브라우저가 불가피한 경우
진정한 시각적 UI (레이아웃, 스타일링, 시각적 회귀)에만 해당되며, 그때도 가장 마지막에만 사용하세요. 그 경우에도: 한 번의 헤드리스 실행, PASS/FAIL 또는 diff 평결 반환 — 전체 스크린샷이나 DOM을 컨텍스트에 절대 넣지 마세요. reference/stacks/nextjs.md 참조.
파일
scripts/detect-stack.sh— 스택 + 러너 출력, 토큰 최소화.scripts/verify.sh— 매핑된 검사를 실행하고, 오직 PASS/FAIL + 실패 줄만 출력합니다.VERIFICATION_MAP.md— 짧은 기능→명령어 맵 (에이전트가 유지 관리).reference/stacks/— 복사-붙여넣기 레시피: FastAPI (인-프로세스 TestClient), Supabase (시드 + 리셋 + pgTAP), Next.js (라우트 핸들러 + 최후의 수단 시각적).reference/patterns.md— 토큰 최소화 검증 패턴 + 이에 대한 증거.reference/anti-patterns.md— 불안정한 테스트, 거짓 PASS, 과잉 엔지니어링 방지.templates/— 맵, FastAPI 테스트, Supabase 시드를 위한 시작점.