{
  "test_id": "T14",
  "verdict": "pass",
  "observed": "run 1의 두 confound을 모두 제거하고 재실험함. (1) FQDN 불일치: DestinationRule host를 svc.cluster.local로 교정해 outlierDetection이 실제 Envoy cluster에 정상 attach됨을 istioctl proxy-config로 확인. (2) fault.abort는 로컬 응답이라 outlier detection에 절대 반영되지 않으므로(T05에서 증명), VirtualService fault.abort를 완전히 제거하고 대신 mendhak/http-https-echo 대상에 실제 요청 헤더 'x-set-response-status-code: 503'을 보내 진짜 업스트림 5xx를 발생시킴 -- 트리거 직후 rq_error가 실제로 1 증가하고 health_flags가 /failed_outlier_check로 전환됨을 확인해 진짜 ejection이 발생했음을 검증. 처음에는 스펙 그대로 apply/trigger/check/loop를 각각 별도 kubectl exec로 실행했더니 15/15 200이 나왔으나, 사후 확인 결과 이미 health_flags가 healthy로 자연 복귀한 뒤였다 -- 별도 exec들의 왕복 지연이 20초 baseEjectionTime 창을 다 소모해버린 새로운 timing confound였음. 이를 교정하기 위해 트리거+15~18회 요청+health_flags 체크를 하나의 kubectl exec 셸 세션 안에 결합(client pod의 curl 컨테이너가 istio-proxy와 네트워크 네임스페이스를 공유하므로 localhost:15000 admin API에 직접 접근 가능)해 지연을 제거함. 최종 관측: health_flags가 연속으로 /failed_outlier_check였던 약 18초 전체 구간(20초 baseEjectionTime 이내) 동안 18/18 요청이 전부 HTTP 503, 바디는 정확히 'no healthy upstream', x-envoy-upstream-service-time 헤더 없음(업스트림에 도달조차 못한 Envoy 로컬 응답) -- 즉 단 하나의 예외도 없이 전체 차단됨. 창이 끝나 health_flags가 healthy로 자연 복귀하자 즉시 실제 업스트림 헤더/바디가 포함된 200이 재개됨. 결론: 단일 엔드포인트가 ejection되면 baseEjectionTime 동안 Envoy panic threshold의 개입 없이 트래픽이 100% 전체 차단되며, 이번 재실험은 완전히 confound가 제거된 상태에서 이를 일관되게(재현 2회) 관측함.",
  "claims": [
    {
      "doc": "blog:egress_destinationrule-fundamentals",
      "cid": "C5",
      "empirical": "supports-claim",
      "note": "'단일 엔드포인트 ejection = 전체 차단' 주장을 확인. 실제 업스트림 5xx로 진짜 ejection 상태를 유발한 뒤(fault.abort가 아닌 header 기반 트리거로 outlier detection이 실제로 카운트했음을 rq_error/health_flags로 검증), baseEjectionTime 20초 창 전체에서 18/18 요청이 전부 'no healthy upstream'(Envoy 로컬 응답, 업스트림 미도달)로 실패했고 예외 없음. run 1의 FQDN 불일치와 fault.abort 로컬 응답 confound를 모두 제거한 상태에서 얻은 결과라 신뢰도 높음."
    },
    {
      "doc": "gw__src-egress-tcp-bottlenecks",
      "cid": "C14",
      "empirical": "refutes-claim",
      "note": "'Envoy LB panic threshold가 단일 엔드포인트 ejection 상태를 무시하고 일부 트래픽을 구제한다'는 취지의 주장을 반증. healthy host 비율이 0%(1개 중 0개)로 기본 panic threshold(50%) 미만이었음에도, 20초 ejection 창 전체에서 단 한 건의 요청도 구제되지 않고 전부 'no healthy upstream'으로 실패함. 즉 이 클러스터/DestinationRule 설정(별도 loadBalancer.panicThreshold 커스터마이즈 없음)에서는 panic threshold override가 관측되지 않았음."
    }
  ]
}