{
  "test_id": "T20",
  "verdict": "fail",
  "observed": "순수 TCP connect 실패(포트 59999, 서비스에 정의되지 않은 포트)의 access log에서는 upstream_transport_failure_reason 필드가 예상대로 비어 있었다(response_flags=UF,URX, upstream_cluster=PassthroughCluster). 그러나 mTLS mode mismatch(서버 PeerAuthentication STRICT + 클라이언트 DestinationRule tls.mode=DISABLE)를 재현했을 때도 이 필드는 동일하게 비어 있었다(response_code=503, response_flags=UC, response_code_details=upstream_reset_before_response_started{connection_termination}) — 이는 harness-notes가 지시한 svc.homelab.local 호스트로 최초 실행했을 때(DestinationRule이 실제로는 attach되지 않고 PassthroughCluster로 폴백)와, DNS 도메인 혼선을 배제하기 위해 실제 등록된 svc.cluster.local 호스트로 DestinationRule을 correction하여 outbound|80||echo...cluster.local을 통해 정상 attach된 상태로 재확인했을 때 모두 동일하게 재현되었다. 즉 클라이언트가 DISABLE로 인해 TLS 핸드셰이크 자체를 시도하지 않으므로(raw_buffer transport socket), 서버가 평문을 파싱하지 못해 연결을 리셋해도 클라이언트 측 upstream_transport_failure_reason에는 채울 TLS 에러가 없다.",
  "claims": [
    {
      "doc": "xds__note-envoy-routing-chain-debugging",
      "cid": "C14",
      "empirical": "refutes-claim",
      "note": "이 필드가 mTLS mode mismatch에서 TLS 에러 문자열로 채워진다는 예측은, DISABLE-vs-STRICT처럼 클라이언트가 TLS 핸드셰이크를 아예 시도하지 않는 흔한 mTLS 불일치 유형에서는 성립하지 않음(비어 있음, TCP 실패와 구분 불가). UF/실패 신호만으로 mTLS를 단정하면 안 된다는 취지는 오히려 강화되나, '필드가 채워지면 mTLS로 확정 가능'이라는 판별 능력 주장 자체는 반박됨."
    },
    {
      "doc": "xds__src-xds-layers-and-diagnosis",
      "cid": "C8",
      "empirical": "refutes-claim",
      "note": "동일 관측을 공유. UPSTREAM_TRANSPORT_FAILURE_REASON은 실제 TLS 핸드셰이크 시도(ClientHello 교환) 중 실패해야만 채워지는 필드이며, tls.mode=DISABLE처럼 핸드셰이크 자체가 없는 mTLS 불일치에서는 순수 TCP 실패와 로그상 구분되지 않음이 두 번(DNS 도메인 혼선 있는 원 스펙 실행 + cluster.local로 교정한 control 실행) 모두 확인됨."
    }
  ]
}