{
  "test_id": "T37",
  "verdict": "pass",
  "observed": "ServiceEntry scoped-mock-se(exportTo: ['.'], port 80)는 같은 네임스페이스(istio-vt-t37)의 client에는 cluster로 잡혔지만(--port 80 필터 기준 length=1), 다른 네임스페이스(istio-vt-t37-b)의 client-b에는 전혀 보이지 않았다(length=0). VirtualService leaky-vs-no-exportto를 exportTo 없이 적용하기 전에는 크로스 네임스페이스 호출이 crossns_before_vs=200이었으나, 적용 후에는 crossns_after_vs_leak=599로 다른 네임스페이스의 client-b까지 fault를 그대로 맞아 전역 누수가 확인됐다. exportTo: ['.']를 patch로 추가한 뒤에는 crossns_after_exportto_dot=200으로 복귀해 exportTo가 그 누수를 정확히 차단함을 확인했다. 참고로 --fqdn만으로 필터링했을 때는 동시에 떠 있는 다른 테스트(T47)의 별도 ServiceEntry(port 443, 같은 shared 호스트)가 섞여 client-b에서도 length=1로 나왔으나, --port 80을 추가해 우리 SE만 격리하자 기대대로 0이 나왔다(환경 오염이지 exportTo 동작의 반증이 아님)."
  ,
  "claims": [
    {
      "doc": "gw__note-egress-identity-without-mtls",
      "cid": "C3",
      "empirical": "supports-claim",
      "note": "ServiceEntry exportTo:['.']는 선언 ns에만 xDS로 노출되고 타 ns sidecar는 해당 cluster/route를 아예 받지 못함을 실측(own ns length=1, cross-ns length=0)으로 확인."
    },
    {
      "doc": "gw__note-egress-vs-scoping",
      "cid": "C1",
      "empirical": "supports-claim",
      "note": "VirtualService는 exportTo/gateways 생략 시 저장 namespace와 무관하게 mesh 전역(모든 sidecar)에 기본 적용되어 다른 ns에도 fault(599)가 누수됨을 확인했고, exportTo:['.'] 추가로 그 누수가 차단(200 복귀)됨도 확인."
    }
  ]
}