wreck-it: 사용자가 버그를 발견하기 전에 앱을 망가뜨리세요은(는) 무엇을 하나요?
WRECK은 아래에서 npx @miyanishar/wreck-it을 의미합니다. CLI는 결정적 작업(설정, 발견, 스윕, 퍼징, 페이지 속도, 부하, 결과, 점수, 보고서, 테스트)을 수행합니다. 사용자는 Playwright MCP를 통해 브라우저를 제어하고, 퍼소나를 실행하며, 버그를 판단하고 코드까지 추적합니다.
보고서만 생성합니다. 실행 중에는 버그를 수정하지 마세요. 사용자가 보고서 이후에 요청하는 경우에만 수정하세요.
규칙 (항상)
- 로컬 전용. CLI는 로컬이 아닌 대상을 거부합니다. 사용자가 원격 대상을 소유하고 있다고 말하는 경우에만
--i-own-this를 전달하세요. - 가짜 데이터만. 테스트 계정, 가짜 이름, 실제 개인 정보나 결제 데이터는 절대 사용하지 마세요. 생성하는 항목의 이름을
wreck-it ...으로 지정하고 로그에 기록하세요:WRECK run created "<what>" --by <persona>(보고서에 정리 목록이 포함됩니다). - 쓰기 전에 물어보세요. Preflight의
safety.ask가 질문 목록을 제공합니다: 호스팅된(종종 프로덕션) 데이터베이스, 라이브 Stripe 키, 읽을 수 있는 받은 편지함이 없는 이메일, 유료 AI/SMS 호출. 일반 사용자 패스 전에 하나의 메시지로 모두 질문하고, 각 "예"를.wreck-it/config.json에 기록하세요 (allowRemoteDb,testEmail,allowSideEffects). 데이터베이스가 프로덕션이면 중단하고 앱을 개발 프로젝트로 연결하도록 제안하세요. - 돈과 메시지. Stripe 테스트 키(카드
4242 4242 4242 4242)로만 결제하세요. 라이브 키로는 결제 단계에서 중단하세요. 허용되지 않는 한 플로우당 AI/SMS/이메일 작업을 최대 2~3회만 트리거하세요.fuzz와load는 해당 엔드포인트를 자체적으로 건너뜁니다. - 이메일.
WRECK email new의 주소로 가입하고,example.com은 절대 사용하지 마세요. 로컬 받은 편지함이 있으면 직접 링크를 읽으세요 (WRECK email read --to <address>). 그렇지 않으면 사용자에게 링크를 요청하거나 "건너뜀: 읽을 수 있는 받은 편지함 없음"으로 표시하세요. - 공유 로그인 유지. 다른 단계에서 사용하는 저장된 세션의 계정에서 절대 로그아웃, 삭제 또는 비밀번호를 변경하지 마세요. Supabase 및 많은 앱에서 로그아웃하면 해당 사용자의 모든 세션이 종료됩니다. 로그아웃 및 삭제 테스트는 임시 계정으로 마지막에 수행하세요.
집중 실행 (하나의 기능)
사용자가 하나의 기능이나 플로우를 지정하면 ("checkout 테스트", "/wreck focus signup"), 몇 분 안에 해당 기능만 테스트하세요:
WRECK run init --focus "<feature>",WRECK discover,WRECK setup --dry-run,WRECK preflight --wait 5를 실행하고 1단계에서와 같이 처리하세요. 기능이 필요로 하는 경우에만 로그인(2단계)하세요. 기능이 데이터를 쓰는 경우에만safety.ask질문을 하세요.- 범위 설정.
discovery.json과 코드에서 기능의 페이지와 API 라우트(예:/cart,/checkout,/api/cart,/api/orders)를 나열하세요. 사용자에게 한 줄로 범위를 알려주세요. - 테스트 (해당되지 않는 퍼소나와 단계는 건너뛰고
skipped로 표시):- 일반 사용자로 기능을 탐색한 다음, 전화기에서 급한 초보자로(더블 클릭, 잘못된 형식, 중간에 뒤로 가기) 탐색하세요. 해당되는 탐색 스킬 체크리스트 행(합계, 영속성, 삭제, 오류 메시지)을 확인하세요.
WRECK sweep --record --only <pages…>및WRECK fuzz --record --only <api routes…>.- 이 기능의 폼에 대해서만 혼돈 스킬의 적대적 입력, 이중 제출, 탐색 및 네트워크 결함.
- 기능에 자체 페이지가 있는 경우
WRECK perf --record <pages…>.
- 모든 결과를 재현하고 추적(9단계)한 다음
WRECK report && WRECK gen-tests를 실행하세요. 보고서는 집중 실행으로 표시됩니다: "readiness"가 아닌 "feature score"라고 말하세요.
파이프라인
단계를 WRECK run stage <stage> running|done|skipped|failed로 표시하세요. 결과는 진행하면서 저장됩니다.
1. 설정 및 사전 점검
WRECK run init # --fresh는 이전 실행 결과를 폐기합니다
WRECK discover
WRECK setup --dry-run # 설치된 항목, 누락된 항목
WRECK preflight --wait 5
setup --dry-run이 설치할 항목을 나열하면 보여주고 한 번 물어보세요. 예라고 하면WRECK setup을 실행하세요. MCP 서버가 추가된 경우 사용자가 에이전트를 다시 시작한 후에만 브라우저 도구가 나타납니다: 그렇게 말하고 그동안 CLI 전용 실행을 제안하세요.- 브라우저 도구가 "Browser ... is not installed"라고 말하는 경우:
WRECK setup --skip playwright-mcp devtools-mcp를 실행한 다음 다시 시도하세요. - 사전 점검 종료 코드 4(앱에 연결할 수 없음): 백그라운드에서
devScript를 시작한 다음WRECK preflight --wait 60을 실행하세요. 종료 코드 3(대상 거부됨): 중단하고 설명하세요. .wreck-it/config.json이 없으면{"baseUrl": "http://localhost:3000"}을 생성하세요 (실제 포트 사용).- CLI 전용 실행 (브라우저 도구 없음):
sweep --record,fuzz --record,perf --record, 7단계 및 보고서를 실행하고personas,normal,explore,chaos는 건너뛰었다고 표시하고 이유를 설명하세요. 앱을 클릭했다고 절대 가장하지 마세요.
2. 로그인
- Google, GitHub, SSO, 호스팅된 로그인, 매직 링크, 2FA (
discovery.json에auth.sso가 설정되었거나 비밀번호 필드가 없는 경우): 사용자에게 "브라우저 창이 열립니다. 테스트 사용자로 로그인하세요. 로그인하면 자동으로 닫힙니다."라고 말하세요.WRECK login을 실행하세요 (최대 10분 대기, 긴 타임아웃 사용). 출력에check: valid가 표시되어야 합니다. 두 사용자 확인의 경우WRECK login --label second를 요청하세요. 새 계정 확인의 경우--label fresh를 요청하거나 건너뛰었다고 표시하세요. - 이메일 및 비밀번호: 테스트 계정을 가입하고(또는 사용자의 계정 사용) config에
"accounts": [{"label": "main", "email": "...", "password": "..."}]을 추가하세요. - 그 이후부터:
sweep,fuzz,perf는 자체적으로 로그인합니다. 브라우저에서 로그인된 페이지를 방문하기 전에browser_set_storage_state를{"filename": ".wreck-it/auth/<label>.json"}로 호출하세요. 로그인 상태에서 기록된 결과에는"auth": "<label>"과 로그인 후 시작 단계가 포함됩니다. - 사전 점검 또는
WRECK login --check가expired라고 표시하면 사용자에게login을 다시 실행하도록 요청하세요.
3. 퍼소나
wreck-personas 스킬을 사용하세요.
4–5. 일반 사용자, 그다음 퍼소나
wreck-explore 스킬을 사용하세요. Claude Code 플러그인에서는 최대 3개의 퍼소나를 wreck-persona 하위 에이전트로 병렬 실행할 수 있습니다(각각 wreck-browser-1..3). 그동안 직접 브라우저를 사용하지 말고 6단계 전에 모두 완료될 때까지 기다리세요. 다른 에이전트에서는 퍼소나를 하나씩 실행하세요.
6. 혼돈
wreck-chaos 스킬(스윕, API 퍼즈, 적대적 입력, 이중 제출, 탐색, 네트워크 결함, 세션 변조, 키보드)을 사용하세요.
7. 페이지 속도 및 부하
wreck-load 스킬을 사용하세요.
8. 보안
v1에서는 해당 없음: WRECK run stage security skipped.
9. 재현, 그다음 추적
WRECK finding list: 새 컨텍스트에서 모든 ? 결과를 재생하고 다시 나타나면 reproduced: true로 설정하세요(재현되지 않은 결과는 점수 없음). 그런 다음 source가 없는 모든 재현된 결과에 대해 wreck-trace 스킬을 사용하세요.
10. 보고서
보고서를 생성하기 전에 각 재현된 브라우저 결과에 실제 실패를 보여주는 스크린샷이 있는지 확인하세요. CLI 스윕의 결과도 다시 확인하세요. references/recording-findings.md의 스크린샷 지침을 따르세요. 저장된 이미지 파일이 존재하는지 확인하고 누락된 스크린샷 경고를 해결하세요. API 전용 또는 부하 결과는 요청/메트릭 증거를 대신 사용할 수 있습니다. 스크린샷이 적용되지 않거나 캡처할 수 없는 경우 설명하세요.
마지막 결과 업데이트 후 보고서와 테스트를 생성하세요. 이후 결과를 변경하면 결과를 제시하기 전에 둘 다 다시 생성하세요. references/regression-tests.md를 읽으세요. 보존된 사양 경고를 검사하고 해당 테스트를 업데이트된 결과와 조정하세요. 재생성은 의도적으로 에이전트 편집과 fixture를 유지합니다. 버그가 있는 앱에 대해 지원되는 사양을 실행하고 실패가 의도된 단언에 도달하는지 확인하세요. 보고서에 건너뜀, 설정 실패, 시간 초과 또는 확인되지 않은 테스트를 공개하세요. 수정된 복사본이 있는 경우 동일한 사양에 대해 테스트도 수행하세요.
WRECK report && WRECK gen-tests && WRECK run stage report done
탐색 중 (4–6단계)
references/recording-findings.md에 정확히 설명된 대로 버그를 기록하세요:WRECK finding add, 구조화된 단계, 역할/레이블 대상, 올바른 동작을 설명하는 단언, 그런 다음 새 컨텍스트에서 재생하고reproduced: true로 설정하세요.- 각 탐색 후,
browser_evaluate를 통해 기이함 스크립트(WRECK oddity-script, 한 번)를 실행하고browser_console_messages및browser_network_requests(4xx/5xx)를 확인하세요. 또한 스크립트가 판단할 수 없는 항목(깨진 레이아웃, 안내 없는 빈 상태, 끝없는 스피너, 죽은 버튼, 일관성 없는 날짜나 가격)도 확인하세요. 실제 문제를oddity로 기록하세요. - 커버리지 기록:
WRECK run visit <route> --persona <name>.
최종 메시지
간략하게: 점수와 등급, "먼저 수정할 사항" 결과와 file:line, 심각도별 개수, 완료되지 않은 단계, 경로 .wreck-it/report.html, .wreck-it/report.md, tests/wreck-it/, 그리고 npx playwright test tests/wreck-it. 상위 결과를 수정하겠다고 제안하고 예를 기다리세요.
버그를 제시할 때 결과 ID와 설명 옆에 관련 스크린샷을 첨부하세요. 채팅의 이미지 첨부 지원 또는 실제 저장된 파일 경로가 있는 Markdown 이미지를 사용하세요. 보고서 경로만으로는 증거를 보여주지 않습니다. 상위 결과를 채팅에 스크린샷과 함께 제시하고 전체 집합은 보고서에 보관하세요. 이미지를 사용할 수 없거나 적용할 수 없는 경우 이유를 설명하고 대신 요청, 추적 또는 메트릭을 링크하세요. 저장된 shots/... 경로는 .wreck-it/에 상대적으로 해석하세요.
채팅에 포함하는 각 브라우저 결과에 대해 다음 형식을 사용하세요 (예제를 실제 결과와 확인된 절대 이미지 경로로 바꾸세요):
**WR-007 — 장바구니 소계가 수량을 무시함** (`lib/cart.ts:19`)
$79.99 항목 3개는 총 $239.97이어야 하지만 페이지에 $79.99로 표시됩니다.

보내기 전에 제시할 각 이미지를 열고 실제로 표시하는 상태와 값을 설명하세요. 제시하는 각 브라우저 결과에 이미지 첨부 또는 이미지 포함이 있는지 확인하세요. 이미지 파일 이름 목록이나 스크린샷이 저장되었다는 진술은 첨부가 아닙니다. 더 적은 결과를 증거와 함께 제시하고 전체 보고서를 링크하여 응답을 간결하게 유지하세요. 나머지 브라우저 결과는 해당 보고서에 남기고 채팅에 그림 없는 목록을 추가하지 마세요.
