{
  "test_id": "T29",
  "verdict": "fail",
  "observed": "workload-socket/credential-socket/workload-certs 3종 volumeMounts/volumes를 제거하고 sidecar.istio.io/inject=false로 재적용한 sds-broken pod의 istio-proxy 컨테이너는 즉시 크래시하지 않고 '1/2 Running, restartCount=0' 상태를 약 10분간 그대로 유지했으며, 이 기간 내내 'SDS grpc server for workload proxies failed to set up UDS: failed to listen on unix socket ...: bind: no such file or directory' 에러를 반복 로깅했다(문서가 인용한 문자열과 거의 일치하나 'for workload proxies' 등 추가 어구가 있어 완전한 축자 일치는 아님). istio-proxy에는 livenessProbe가 없고 readinessProbe(15s/threshold 4)와 startupProbe(1s/threshold 600)만 있어, startupProbe가 600회(약 600초) 연속 실패한 시점(t≈23:28:33Z)에야 kubelet이 컨테이너를 종료(reason=Completed, exitCode=0)시키고 재시작했다 — restartCount는 1로 증가했지만 종료~재시작 사이 backoff 지연은 0초였고, kubectl get pod의 STATUS 컬럼은 재시작 전후 내내 'Running'이었으며 단 한 번도 'CrashLoopBackOff'를 표시하지 않았다. 즉 실제 장애 양상은 '즉시 크래시루프'가 아니라 '약 10분 주기로 조용히 재시작되는 영구 NotReady 상태'였다.",
  "claims": [
    {
      "doc": "gt__src-manifests-walkthrough",
      "cid": "C15",
      "empirical": "refutes-claim",
      "note": "istio-proxy가 즉시 CrashLoopBackOff에 빠진다는 주장은 관찰과 다름 - 실제로는 크래시하지 않고 1/2 Running 상태로 약 10분간 지속되다 startupProbe 타임아웃으로 인해 0초 백오프로 조용히 재시작됨. kubectl STATUS는 계속 Running이었고 CrashLoopBackOff는 관찰되지 않음. 런타임 503이 아니라는 부분은 맞으나(트래픽 라우팅 실패가 아니라 기동 실패), 'CrashLoopBackOff' 프레이밍 자체는 반증됨."
    },
    {
      "doc": "gt__src-w3-igw-deployment",
      "cid": "C7",
      "empirical": "supports-claim",
      "note": "--previous 로그에서 SDS UDS bind 실패 에러(핵심 문구 'failed to set up UDS'와 'bind: no such file or directory' 모두 포함)가 실제로 확인됨. 다만 문서가 인용한 정확한 문자열과 달리 실제 메시지는 'SDS grpc server for workload proxies failed to set up UDS: failed to listen on unix socket ...: bind: no such file or directory'로, 'for workload proxies'와 'failed to listen on unix socket ...: listen unix ...:' 어구가 추가되어 있어 완전한 축자 일치는 아니고 의미상 일치임."
    }
  ]
}