문제 해결

반환된 실행 식별자와 체크아웃 경로부터 확인하세요. 해당 실행이나 Log 항목을 열고 기록된 오류를 읽으세요. 준비 오류, 어설션 실패, 정리 실패는 각각 해결 방법이 다릅니다.

처음 실패한 단계 찾기

연결부터 정리까지 순서대로 확인하세요. 뒤 단계의 결과가 없다는 사실을 해석하기 전에 처음 실패한 단계를 해결하세요.

진행 상황을 얻으려고 같은 요청을 반복 제출하지 마세요. 반환된 식별자를 유지하고 해당 기록을 읽으세요. 입력을 수정했거나 의도적으로 다시 시도할 때 새 실행을 제출하면 됩니다.

에이전트가 연결되지 않음

원하는 앱이나 서버가 실행 중인지 확인하고 주소를 에이전트의 MCP URL과 비교하세요. HTTP 에이전트 Plugin은 54321, App Page Plugin은 54322 포트를 사용합니다. 개발 서버는 다른 포트와 데이터 디렉터리를 사용할 수 있습니다. 다른 인스턴스에 연결하면 정상 실행도 뷰어에서 누락된 것처럼 보일 수 있습니다.

플러그인 연결을 업데이트한 뒤 클라이언트를 새로 고치거나 새 에이전트 작업을 시작하세요. 같은 인스턴스에서 redpact settings describe --scope project --path /absolute/checkout을 실행하세요. 스킬 설치만으로 서버가 시작되지는 않습니다. 로컬 HTTP MCP 연결을 사용하세요. stdio 브리지는 제공하지 않습니다.

요청이 거부되면 의도한 로컬 호스트 이름과 브라우저 프록시가 Origin이나 Host를 바꿨는지 확인하세요. 로컬 요청 검사를 끄지 말고 엔드포인트를 수정하세요.

요청이 계속 대기 중임

Ask 요청은 사람이 연결된 앱의 정확한 웹 검토 화면에서 승인할 때까지 대기합니다. 모든 테스트 종류는 redpact runs show --kind KIND --id ID로 상태를 읽을 수 있습니다. 폴링이나 텍스트 동의는 승인하지 않습니다. 웹 뷰어를 사용할 수 없으면 제한을 알리고 요청을 대기 상태로 유지하세요. 오래된 revision이나 바뀐 검토 입력에는 새 검토나 새 요청이 필요하며 다른 설정을 대신 승인해서는 안 됩니다. 인터페이스가 확인 절차를 정의합니다.

프로젝트나 워크트리가 보이지 않음

인스턴스 projects의 절대 디렉터리와 redpact settings describe --scope project의 관찰 진단을 확인하세요. Git으로 연결된 체크아웃은 실제로 존재하고 Git에서 발견할 수 있어야 합니다. 삭제된 체크아웃은 이력이 남지만 실행할 수 없습니다.

rulesRoot와 projectRoot를 비교하세요. 공유 설정은 기본 체크아웃에 속합니다. 연결된 체크아웃의 사본을 편집해도 덮어쓰지 않습니다. 다른 체크아웃의 설정으로 대체하지 말고 이동했거나 누락된 기본 프로젝트 경로를 복구하세요.

설정 검증이나 저장이 안 됨

진단에 나온 파일과 필드 경로를 확인하세요. 흔한 원인은 중복 키, 알 수 없는 필드, 상대 경로가 아닌 경로, 누락된 Compose 서비스, 잘못된 의존성 종류입니다. isolated, shared-local, remote, mock만 허용됩니다.

JSON 구문 오류나 중복 키는 revision 기반 CLI settings repair를 사용하고 유효한 JSON의 필드 오류는 settings patch로 수정하세요. 저장 충돌 시 초안을 보존하고 현재 소스를 불러온 뒤 편집 내용을 조정하세요. 불러온 이후 다른 편집기가 파일을 바꿨을 수 있습니다. 실제 실행 체크아웃으로 redpact settings validate --scope project를 반복하세요.

검증은 통과하지만 준비가 실패함

빈 Compose 목록은 조회용으로 유효하지만 관리되는 환경에서는 environment_unconfigured를 발생시킵니다. 애플리케이션의 Compose 파일을 추가하거나 단위 테스트만 필요하다면 단위 테스트 명령 경로를 사용하세요.

Docker 사용 가능 여부, CLI, 빌드·이미지 오류, 공개 TCP 포트, 수신 인터페이스, healthcheck 진단을 확인하세요. URL 선언만으로 애플리케이션이 해당 포트에서 수신하지는 않습니다. 컨테이너 주소는 Compose 이름을 사용하고 두 컨테이너 러너는 해석된 tests.env URL을 사용합니다.

공통 설정에 비어 있지 않은 시작 서비스와 의존성별 고정 정의를 작성하세요. 바인딩은 활성 서비스를 대상으로 하며 두 의존성이 같은 변수를 쓸 수 없습니다. 설정을 참고하세요.

자격 증명이 누락됨

애플리케이션 값은 Project Dependencies에, 러너 값은 Project settings에 명시적인 문자열로 입력하세요. 입력 카드나 별도 자격 증명 저장소는 없습니다. 설정을 참고하세요.

변수 이름, 대상 서비스와 의존성 종류를 확인하세요. 서버 환경 값을 대신 사용하지 않습니다. 값을 교체한 뒤 새 테스트를 실행하세요. 실행 중인 환경은 시작 당시의 값을 계속 사용합니다.

이전 환경을 재사용할 수 없음

테스트 환경 재사용과 독립 준비는 지원하지 않습니다. 새 실행으로 현재 입력의 새 임시 환경을 준비하세요. Project Container는 별도의 수동 점검을 지원합니다. 독립 관리 서비스에는 shared-local 또는 remote 종류를 사용합니다. 이전 실행 증거는 보존됩니다.

어설션 전에 테스트가 실패함

수집·import 오류와 어설션 실패를 구분하세요. 통합 테스트 경로는 tests.directory 기준이며 요청한 테스트 경로는 정확해야 합니다. 헬퍼와 허용된 고정 버전 패키지 입력을 번들 안에 두세요. 수집 제한은 50개 파일, 파일당 200 KB, 전체 2 MB, 방문 항목 5000개입니다. 심볼릭 링크는 거부합니다. 수집기는 .ts, .js, .json 파일과 루트의 pnpm-lock.yaml을 포함하며 다른 확장자는 건너뜁니다. 수집된 파일 중 지원하지 않는 경로나 패키지·설정 입력이 있으면 제출이 거부될 수 있습니다. 요청한 테스트 이름은 .test.ts, .test.js, .spec.ts, .spec.js 중 하나로 끝나야 합니다.

단위 테스트 실행용 Dockerfile은 소스를 /workspace로 복사하고 의존성을 설치하며 /bin/sh를 제공해야 합니다. 설정된 cwd와 명령을 확인하세요. 컨테이너는 호스트에 설치된 의존성을 상속하지 않습니다. 빌드나 시작 오류는 어설션 실패를 입증하지 않습니다.

실행이 시간 또는 메모리 제한을 초과함

기록된 이유를 읽으세요. 개별 테스트 제한 시간은 기본값이 2048 MiB와 600초인 Global Settings의 실행 제한과 다릅니다. 정당한 작업에 필요한 한도를 늘리기 전에 반복문, 감시 명령, 과도한 워커, 메모리 증가를 확인하세요.

resourceLimit이 있다면 적용 임계값, 감지 출처, 종료 확인을 기록합니다. 강제 종료되면 최종 케이스 보고나 스크린샷이 남지 않을 수 있습니다. OOM 텍스트만으로 외부에서 감지한 위반을 입증하지는 않습니다. 적용 범위와 플랫폼 요구 사항은 리소스 제한을 참고하세요.

결과나 스크린샷이 보이지 않음

실행 ID, 프로젝트, 실행 체크아웃, 인스턴스가 일치하는지 확인하세요. 파일 관찰은 테스트를 실행하지 않습니다. 로컬 명령의 터미널 출력은 제출된 Redpact 증거가 아닙니다.

프로젝트 Screenshots는 유지되는 project 캡처 타깃을 보여줍니다. worktree 타깃은 실행 이력에 남으며 유지되는 스크린샷을 대체하지 않습니다. 현재 목록은 타깃별 가장 최근 성공 완료 실행을 우선하며 성공 전에는 완료된 실행을 사용합니다. 정확한 실패 시도나 과거 캡처는 Runs에서 확인하세요.

새 Playwright 실행은 비교 기준 없이 선택한 체크아웃을 한 번 실행합니다. 아티팩트가 없다면 첨부 파일이 생성되지 않았거나 보고 완료 전에 실행이 끝났을 수 있습니다. 기록된 케이스와 오류를 읽으세요.

실행 후 정리가 실패함

정리 상태와 테스트 결과를 별도로 읽으세요. 테스트는 자동 정리와 내부 복구를 유지합니다. 정리 오류는 실행 ID와 함께 보고하세요. 공개 취소와 테스트 환경 종료는 제공하지 않으며 수동 Container 제어는 수동 리소스에만 적용됩니다. 실행 증거는 계속 보존됩니다.

워크트리 Playwright 초안 정리는 명시적인 작업이며 사용 중이거나 수정되었거나 기록되지 않은 파일을 거부할 수 있습니다. 강제로 삭제하지 말고 파일을 보존한 채 보고된 조건을 해결하세요. 초안 정리가 성공해도 기록된 소스와 아티팩트는 남습니다.

예시: 설정은 통과했는데 애플리케이션 URL 요청이 실패함

먼저 환경 준비가 완료됐는지 확인하세요. 이미지 빌드나 서비스 healthcheck가 실패했다면 HTTP 단언부터 고칠 상황이 아닙니다.

준비가 성공했다면 테스트의 변수명과 tests.env를 비교하세요. APP_URL을 사용하는 예제가 BASE_URL이라는 바인딩을 자동으로 읽지는 않습니다. 바인딩이 애플리케이션의 실제 내부 포트와 공개된 TCP 포트를 가리키는지, 서비스가 접근 가능한 인터페이스에서 수신하는지 확인하세요.

다음으로 테스트에서 URL을 만드는 부분을 살펴보세요. app 같은 Compose 호스트명은 내부 서비스 이름이며 Vitest가 사용할 호스트 주소가 아닙니다. 컨테이너 주소나 이전 실행의 호스트 포트를 복사하지 말고 해석된 서비스 URL을 사용하세요. 입력을 고친 뒤 새 실행을 제출하고 비교를 위해 원래 실패를 남겨 두세요.

예시: Tests에 파일이 보이지만 통과 결과가 없음

소스 목록과 실행 이력은 서로 다른 질문에 답합니다. 경로가 설정한 패턴과 일치하면 한 번도 실행하지 않은 현재 파일도 목록에 표시될 수 있습니다.

fileCommand가 없는 Unit은 설정한 명령이 해당 테스트를 포함하는지 확인하세요. fileCommand를 사용하면 설정한 패턴과 선택한 실행 범위를 확인하세요. 소스 미리보기 선택으로 실행 파일이 선택되지는 않습니다. Integration은 제출한 소스 번들과 요청한 테스트 경로를 확인하세요. Playwright는 파일이 정확히 하나의 타깃과 일치하는지, 의도한 워크트리에서 그 타깃을 실행했는지 확인하세요. 소스가 보인다는 사실을 성공의 근거로 삼지 말고 실행 결과 기록을 여세요.

문제 보고

Redpact 버전이나 커밋, 인스턴스 주소, 체크아웃 경로, 실행 ID, 테스트 종류, 진단, 실패 단계(준비·실행·정리)를 포함하세요. Log의 복사 작업은 기록된 실행 텍스트를 제공합니다. 공유 전에 검토하고 시크릿 값, 비공개 설정 저장소, 관련 없는 프로젝트 내용은 제외하세요.