검증할 수 있는 보고서와 대조 기준이 되는 원본 파일 목록을 조회합니다.

검증 작업의 출발점입니다. 여기서 얻은 파일명을 다른 도구에 넘깁니다.

Returns: 대상목록응답: 원본 엑셀 목록과 .docx 보고서 목록.

Examples: - 사용: "검증할 수 있는 보고서가 뭐가 있나요?" - 사용하지 않음: 이미 파일명을 알고 바로 검증할 때 → preview_verification_report

원본 엑셀을 읽어 정규화 사실표로 만들고 그 규모를 돌려줍니다.

제출본에는 주차 열이 없으므로 기준주차를 스탬프로 찍어 적재합니다. 모든 행은 자기 좌표(파일·시트·행)를 들고 다니며, 그것이 나중에 지적의 근거가 됩니다.

Returns: 원본데이터응답: 행 수, 주차별 과제 수, 미제출 과제코드 목록.

Examples: - 사용: "원본에 몇 개 과제가 들어와 있나요?" / "누가 안 냈나요?" - 사용하지 않음: 판정 5종이 필요할 때 → compute_baseline_findings

원본 데이터만으로 판정 5종(신규완료·지연·일정변경·역행·미제출)을 계산합니다.

이 도구는 보고서를 입력으로 받지 않습니다. 그것이 핵심입니다. 보고서를 보고 판정을 계산하면 보고서에 이끌려, 보고서에서 빠진 항목을 영영 찾지 못합니다.

판정은 날짜·완료여부 계산으로만 합니다. 담당자가 적은 이슈리스크 텍스트는 판정에 쓰지 않습니다 — 이슈를 적지 않은 지연 과제를 잡아내는 것이 이 도구의 존재 이유입니다.

Returns: 판정응답: 구분별 건수와 판정 목록. 각 판정은 원본 좌표를 갖습니다.

Examples: - 사용: "이번 주에 보고되어야 할 변동이 뭔가요?" - 사용하지 않음: 보고서와 대조하려면 → check_completeness / verify_claims

검증 대상 보고서(.docx)의 구조를 표와 문단으로 읽습니다.

각 표에 직전 제목을 붙여 돌려줍니다. "이 표가 무엇에 대한 표인가"를 알아야 지연 표에서 빠진 과제를 찾을 수 있기 때문입니다.

Returns: 보고서응답: 표별 제목·헤더·행수와 보고서에 등장한 과제코드 목록.

Examples: - 사용: "이 보고서에 어떤 표가 들어 있나요?" - 사용하지 않음: 값을 대조하려면 → extract_report_claims → verify_claims

보고서에서 원본과 대조 가능한 주장을 뽑습니다.

값은 원문 문자열 그대로 담습니다. 숫자로 바꾸거나 정규화하지 않습니다 — 62 를 62.0 으로 바꿔 놓으면 반올림 오류를 반올림 오류로 지적할 수 없습니다.

표 기반 보고서는 열 이름 → 필드 매핑으로 결정적으로 뽑힙니다. 추측이 개입하지 않으므로 같은 보고서는 항상 같은 주장을 냅니다.

미검증열 에는 의도적으로 검증하지 않는 열과 그 이유가 담깁니다. 조용히 건너뛰면 "전부 검증했다"로 읽히기 때문입니다.

Returns: 주장응답: 총 주장 수, 필드별 개수, 주장 목록(잘릴 수 있음).

Examples: - 사용: "보고서가 L-08 계획완료일을 뭐라고 적었나요?" (필드="계획완료일") - 사용하지 않음: 맞는지 틀리는지 판정하려면 → verify_claims

보고서의 값을 원본과 대조합니다. L1(원본에 없음) · L2(원본과 다름).

L1 만으로는 부족합니다. L-18 의 값을 L-19 행에 옮겨 적으면 두 값 다 원본에 존재하므로 L1 은 통과합니다. 과제코드까지 맞춰 보는 L2 만이 잡습니다.

한 번의 실수가 여러 값을 틀리게 만들므로 억제 규칙이 있습니다 — 원본에 없는 과제는 그 행의 다른 값을 대조하지 않고, 미제출 과제의 금주 값은 대조하지 않으며, 파생 값(증감·경과일)은 재료가 이미 지적되면 건너뜁니다. 한 번 잘못 적은 것을 두 건으로 보고하지 않기 위한 것입니다.

반올림(0.5 이내) 차이는 error 가 아니라 warning 입니다.

Returns: 지적응답: L1·L2 지적 목록. 각 지적은 보고서 좌표와 원본 좌표를 갖습니다.

Examples: - 사용: "보고서 숫자가 원본과 맞나요?" - 사용하지 않음: 빠진 항목을 찾으려면 → check_completeness

원본에서 나와야 할 판정이 보고서에 빠졌는지 봅니다 (L3).

이 검사가 이 도구의 존재 이유입니다. 사람이 주간보고에서 틀리는 것은 대개 숫자가 아니라 안 쓴 항목입니다. 틀린 숫자는 눈에 띄지만 없는 줄은 눈에 띄지 않습니다.

언급 여부를 두 수준에서 봅니다. 상세 표가 있으면 표에 없는 과제코드가 누락이고, 집계만 했으면 건수가 원본과 맞는지 봅니다 — 집계만 하고 개별 항목을 나열하지 않는 것은 정상적인 보고 방식이기 때문입니다.

Returns: 지적응답: L3 지적 목록. 보고서에 없는 항목이므로 보고서 좌표는 비어 있고 원본 좌표만 채워집니다.

Examples: - 사용: "빠뜨린 지연 과제가 있나요?" - 사용하지 않음: 적힌 값이 맞는지 보려면 → verify_claims

값은 맞지만 서술이 데이터와 어긋나는 후보를 표시합니다 (L4).

64일 지연된 과제를 "순조롭게 진행 중"이라고 쓴 보고서는 숫자가 전부 정확합니다. L1·L2·L3 어디에도 걸리지 않는데, 읽는 사람은 완전히 잘못된 인상을 받습니다.

이 검사는 판단하지 않고 표시만 합니다. 그 서술이 부적절한지는 문맥에 달렸고 기계는 그 차이를 모릅니다. 그래서 결과는 항상 warning 이며 저장을 막지 않습니다. 확신하지 못하는 검사에 차단 권한을 주면 정상 보고서가 막히고, 사람이 검사기를 꺼 버립니다.

표는 보지 않습니다. 표의 칸은 값이고 값의 정합은 L2 소관입니다.

Returns: 지적응답: L4 후보 목록. error 는 구조적으로 나올 수 없습니다.

Examples: - 사용: "지연된 과제를 괜찮다고 써 놓은 데가 있나요?" - 사용하지 않음: 숫자 대조 → verify_claims

네 계층을 모두 돌려 지적 목록과 저장 대상, 승인 요청 문장을 돌려줍니다.

이 도구 하나로 L1·L2·L3·L4 전부를 검사합니다. 중간 도구들은 "왜 그렇게 판정했는지"를 사람에게 보여줄 때 씁니다.

승인토큰 은 지적 내용에서 계산됩니다. 지적이 하나라도 달라지면 토큰이 달라지므로, 사용자가 확인한 내용과 저장될 내용이 같다는 것을 보장할 수 있습니다.

approval_request 문장을 사용자에게 그대로 보여 주고, 명시적으로 승인받은 뒤에만 save_approved_verification 을 호출하십시오.

Returns: 미리보기응답: 지적 목록, 저장 경로, 승인토큰, 지금 쓸 수 있는 결론 후보.

Examples: - 사용: "이 보고서 검증해 주세요" - 사용하지 않음: 사용자 승인 없이 저장 → 절대 금지

사용자가 승인한 검증 결과를 파일로 저장합니다. 유일한 쓰기 도구입니다.

사용자가 명시적으로 승인한 뒤에만 호출하십시오. 승인 없이 호출하지 마십시오.

저장하는 것은 지적 기록입니다. 보고서를 고치지 않습니다. 그래서 error 가 있다는 이유만으로 저장을 막지는 않습니다 — 오히려 error 가 있을 때 기록이 가장 필요합니다.

두 경우에만 거부합니다.

1. 승인토큰이 현재 지적 내용과 맞지 않을 때. 사람이 확인하지 않은 내용이 파일로 남는 것을 막습니다. preview_verification_report 를 다시 호출하십시오.

2. error 가 있는데 결론을 '통과' 로 적으려 할 때. 그것은 기록이 아니라 거짓입니다. '보류' 또는 '반송' 을 쓰십시오.

Returns: 저장응답: 저장 경로와 기록된 결론.

Examples: - 사용: 사용자가 "보류로 저장해 주세요"라고 승인한 뒤 - 사용하지 않음: 미리보기를 보여 주기 전 / 승인 문구가 없을 때