{
  "test_id": "T33",
  "verdict": "pass",
  "observed": "drain 조정 없이 replicas=1 backend를 --grace-period=0으로 강제 종료하면, HTTP/1.1 in-flight 요청(/delay/10)은 200으로 끝나지 않고 http_code=000, curl exit=28(operation timeout)로 client의 --max-time까지 그대로 행(hang)했다. HTTP/2(h2c prior-knowledge) 스트리밍 요청(/drip, duration=10)도 동일하게 exit=28로 타임아웃했으나, 헤더가 kill 이전에 이미 도착해 http_code=200이 기록된 채 바디만 멈췄다 — 두 경우 모두 502나 18/56/92류 exit code는 관찰되지 않았다. replicas=2(killobs-double)에서 한 replica만 강제 종료했을 때는 60회 루프 중 58회가 200, 2회만 503으로 나타나 실패가 거의 마스킹되었다. 참고로 h2c 자체가 이 환경에서 kill과 무관하게 baseline probe 5회 중 3회가 응답 없이 timeout되는 간헐적 불안정성을 보였다.",
  "claims": [
    {
      "doc": "gt__src-tests-walkthrough",
      "cid": "C8",
      "empirical": "supports-claim",
      "note": "drain 미조정 강제종료 시 in-flight 장기 요청이 깨끗이 완료되지 않고 http_code=000/exit=28로 끊겼다(LB측 마킹 경합은 외부 HAProxy 부재로 미검증, pod측 절반만 확인)."
    },
    {
      "doc": "gt__src-tests-walkthrough",
      "cid": "C9",
      "empirical": "inconclusive",
      "note": "이 테스트는 S1(조정 없음) 케이스만 실행했고 preStop/drain 조정이 있는 S2(improved) 시나리오는 구성/관측하지 않아 판단 불가."
    },
    {
      "doc": "gt__src-haproxy-walkthrough",
      "cid": "C1",
      "empirical": "supports-claim",
      "note": "경합의 pod측 절반(drain 시간이 사실상 0일 때 결과)만 재현 가능했고, drain 없음 → 요청 실패라는 방향은 일치. LB측 on-marked-down RST 절반은 외부 HAProxy가 없어 재현 불가."
    },
    {
      "doc": "gt__src-w1-big-picture",
      "cid": "C11",
      "empirical": "supports-correction",
      "note": "disruption이 5xx가 아니라 connection/exit code로 나타난다는 방향은 맞으나(HTTP/1.1에서 http_code=000, 5xx 아님), 실측 exit code는 28(timeout)이며 claim이 예시로 든 7/92/18 계열은 관찰되지 않아 그 구체적 코드 서술은 틀렸다(기존 verdict=incorrect와 부합)."
    },
    {
      "doc": "gt__src-w5-test-scenarios",
      "cid": "C2",
      "empirical": "refutes-claim",
      "note": "claim은 HTTP/1.1=502(상태코드 있음), HTTP/2=상태코드 없음(000)을 주장하나, 실측은 정반대에 가까웠다: HTTP/1.1은 http_code=000(상태코드 없음, 502도 아님)이었고 HTTP/2는 헤더가 먼저 도착해 http_code=200이 기록된 채 바디만 멈췄다. 프로토콜별 비대칭의 구체적 방향이 실측과 다르다."
    },
    {
      "doc": "blog:graceful-termination_quickstart",
      "cid": "C1",
      "empirical": "supports-claim",
      "note": "ungraceful kill 시 요청이 깨끗이 완주하지 못했고(exit=28, non-zero), claim의 '5xx 응답이나 exit≠0' 중 exit≠0 분기가 실측과 일치한다(5xx는 관찰 안 됨, 대신 000+hang)."
    },
    {
      "doc": "blog:graceful-termination_quickstart",
      "cid": "C7",
      "empirical": "refutes-claim",
      "note": "claim은 502(t≈8.25s)로 끊긴다고 구체적으로 서술하나, 실측은 502가 전혀 나타나지 않고 http_code=000, curl 자체의 --max-time(15s)까지 그냥 행(hang)했다."
    },
    {
      "doc": "blog:graceful-termination_quickstart",
      "cid": "C8",
      "empirical": "supports-claim",
      "note": "실패가 5xx HTTP 코드가 아니라 curl의 connection/timeout 에러(exit≠0=28, http_code 미기록=000)로 나타난다는 핵심 주장과 일치한다."
    },
    {
      "doc": "blog:graceful-termination_quickstart",
      "cid": "C9",
      "empirical": "refutes-claim",
      "note": "claim은 HTTP/2 스트리밍 kill 시 curl exit=92를 구체적으로 명시하나, 실측 exit code는 92가 아니라 28(operation timeout)이었다(헤더는 이미 수신되어 http_code=200 기록됨)."
    }
  ]
}