검수를 준비하는 수행사 담당자에게 요구사항마다 이행 상태를 보여주는 추적표를 내는 CLI입니다.

{"type":"object","properties":{"req_id":{"type":"string"},"normalized_req_id":{"type":"string"},"requirement_name":{"type":"string"},"status":{"type":"string","enum":["fulfilled","partial","missing","dropped","duplicate","out_of_scope"]},"evidence":{"type":"array","items":{"type":"object","properties":{"record_id":{"type":"string"},"kind":{"type":"string"},"match_rule":{"type":"string","enum":["id_exact","id_normalized","llm_suggested"]}},"required":["record_id","kind","match_rule"]}},"missing_stages":{"type":"array","items":{"type":"string"}},"report_line":{"type":"string"},"needs_owner_check":{"type":"boolean"},"owner_question":{"type":["string","null"]}},"required":["req_id","normalized_req_id","status","evidence","missing_stages","report_line","needs_owner_check"]}

[
  {
    "input_ref": "SFR-001 · 설계·구현·테스트 근거가 모두 있는 요구사항",
    "output": {
      "req_id": "SFR-001",
      "normalized_req_id": "SFR-1",
      "requirement_name": "입목벌채 허가 신청 접수",
      "status": "fulfilled",
      "evidence": [
        {
          "record_id": "DSN-101",
          "kind": "design",
          "match_rule": "id_exact"
        },
        {
          "record_id": "SRC-201",
          "kind": "code",
          "match_rule": "id_exact"
        },
        {
          "record_id": "TST-301",
          "kind": "test",
          "match_rule": "id_exact"
        }
      ],
      "missing_stages": [],
      "report_line": "SFR-001 입목벌채 허가 신청 접수: 설계서 2.1절, 접수 API 구현, 단위테스트 통과까지 근거가 모두 확인됩니다.",
      "needs_owner_check": false,
      "owner_question": null
    }
  },
  {
    "input_ref": "SFR-002 · ID 표기가 다르고 구현 기록은 본문으로만 이어지는 요구사항",
    "output": {
      "req_id": "SFR-002",
      "normalized_req_id": "SFR-2",
      "requirement_name": "신청서 첨부파일 검증",
      "status": "partial",
      "evidence": [
        {
          "record_id": "DSN-102",
          "kind": "design",
          "match_rule": "id_normalized"
        },
        {
          "record_id": "SRC-202",
          "kind": "code",
          "match_rule": "llm_suggested"
        }
      ],
      "missing_stages": [
        "test"
      ],
      "report_line": "SFR-002 신청서 첨부파일 검증: 설계서는 'SFR002' 표기로 연결됐고 구현 기록 AttachmentValidator 는 본문 대조로 이어진 후보라 담당자 확인이 필요하며, 테스트 기록이 없어 부분 이행입니다.",
      "needs_owner_check": true,
      "owner_question": "AttachmentValidator 가 SFR-002 첨부 검증 요구사항의 구현 산출물이 맞는지 확인해 주시고, 단위테스트 기록이 있으면 알려 주시기 바랍니다."
    }
  },
  {
    "input_ref": "SFR-009 · 다른 요구사항과 내용이 겹치는 중복 행",
    "output": {
      "req_id": "SFR-009",
      "normalized_req_id": "SFR-9",
      "requirement_name": "지급 대상 자격 확인",
      "status": "duplicate",
      "evidence": [],
      "missing_stages": [
        "design",
        "code",
        "test"
      ],
      "report_line": "SFR-009 지급 대상 자격 확인: SFR-006 지급 대상 자격 판정과 내용이 같아 중복으로 묶었고, 근거 산출물은 SFR-006 쪽에 달려 있습니다.",
      "needs_owner_check": true,
      "owner_question": "SFR-006 과 SFR-009 가 같은 요구사항인지, 검수 대상으로 어느 쪽을 남길지 확인해 주시기 바랍니다."
    }
  }
]

[자동 검증(규칙·결정론으로 채점)] 1) 스키마 통과: 출력이 위 JSON Schema 형식을 지키는지(status·evidence·missing_stages·report_line 필드 존재와 타입 확인). 2) 근거 존재: 각 evidence 의 record_id 가 deliverable_records 에 실제 있고 kind 가 그 기록의 kind 와 같은지(없는 산출물을 근거로 적는 것 차단). 3) 상태 일치: status 가 traceability_gold 의 expected_status 와 같은지, evidence 의 record_id 집합이 expected_evidence_ids 와 같은지. 4) 판정 정합: 세 단계 근거가 모두 있고 실패한 테스트가 없을 때만 fulfilled 이고, 근거가 하나도 없으면 missing 이며, change_status 가 '삭제' 인 요구사항은 missing 이 아니라 dropped 인지. 5) 후보 표시: match_rule 이 llm_suggested 인 근거가 하나라도 있으면 needs_owner_check 가 true 이고 owner_question 이 비어 있지 않은지(모델이 이어 붙인 근거가 확인 없이 이행으로 올라가지 않게 막습니다). [수동 검증(사람이 봐야 하는 것)] 6) 발주처 검수 담당 페르소나 2명이 report_line 과 확인 질문을 그대로 검수 자리에 낼 만한지 비동기 라벨 → 일치도 Cohen's κ(두 사람 판단이 우연 이상으로 일치하는 정도, 0~1) 하한 0.6 이상. 7) 부분 이행으로 판정된 요구사항 5% 표본을 사람이 열어, 설계서 내용이 실제로 그 요구사항을 담았는지 점검.