#239 수정(PR #240) 을 릴리스로 컷한다. 사용자 표면(서브커맨드·플래그·config
키·wire 스키마)에 변화가 없어 patch 로 판정했다. 규칙 문면상으로는 minor 로
읽히는 지점이 있으므로 근거를 Cargo.toml 주석과 릴리스 노트 앞머리에 남겼다.
릴리스 노트를 두 관점으로 사실검증하면서 **이미 머지된 HOTFIXES 항목의 사실
오류 두 개**가 드러나 함께 고쳤다.
1. "폭이 한 자릿수인 입력은 폭 0 인 특징맵이 된다" — 실제로는 폭 4 이하만
실패한다. 세 줄 아래 표(5~48 전부 성공)와 스스로 모순이었다. 이슈 본문의
표현을 그대로 물려받은 것이다.
2. "이미 인식된 87 개 영역을 통째로 잃고 있었다" — 87 은 수정 **후** 나오는
영역 수다. 계측으로 확인: Clickpath_Analysis.png 은 박스를 119 개 검출하고,
수정 전에는 그중 3 개를 인식한 시점에 중단됐다
(`ABORT regions_already_recognized=3 of detected_boxes=119`). 약 29 배
과장이었고, 하필 "이미 인식한 것까지 버려진다" 는 기제를 설명하는 자리라
숫자가 논지를 떠받치고 있었다.
릴리스 노트에서 추가로 바로잡은 것:
- 컴파일 가드는 "올리면 실패" 가 아니라 "16 을 넘기면 실패" 다. 6~16 은 그대로
빌드되고 테스트도 통과한다.
- "16 으로 하면 폭 5~15 를 새로 버린다" 는 근거가 정반대였다. 말뭉치 240 개
파일을 계측해 직접 확인: 세션에 투입된 박스 10,991 개 중 폭 5~16 은 403 개,
그중 글자를 뱉은 것은 0 개이고 글자가 처음 나오는 폭은 17 이다. 5 를 고른
이유는 손실이 아니라 상수 이름과 주석이 거짓이 되지 않기 때문이다.
- "실패했던 문서만 다시 OCR 된다" 는 무조건문이 아니다. OCR 파생 캐시는
v0.31.0 에 들어왔는데 이미지 parser_version 은 v0.28.0 이후 안 바뀌었으므로,
v0.31.0 이전에 색인하고 그 뒤 재처리된 적 없는 KB 는 캐시가 비어 성공했던
이미지까지 전부 다시 돈다.
- 피해 집계를 절차 맨 뒤(5번)에 둬서, 순서대로 따르면 세기 전에 색인해 버리고
창이 영구히 닫혔다. 0 번으로 올리고 "반드시" 로 바꿨다.
- `_external/` 로 넣은 문서는 `.kebabignore` 때문에 workspace 색인이 방문하지
않으므로 자동 재색인 대상이 아니다.
- `pdf_ocr_events` 대안 쿼리는 30 일 보관 정리를 받고 `'ocr_error'` 가 모든 OCR
실패를 받는 통칭이라 상한이다. 0 이 나와도 안 당한 게 아니다.
- doc_id 가 전부 바뀌면 저장해 둔 인용과 integrations/claude-code 스킬처럼
doc_id 를 들고 있는 소비자가 헛번호가 된다.
- patch 판정 문단이 규칙의 patch 조항을 인용하지 않아 논거가 유리해 보였다.
"문면상으로는 minor 이고 그럼에도 X 를 이유로 patch" 로 고쳤다.
- 머리글 수치(11,867 / 65,764 / 11.8%)가 이 저장소에서 재현 불가라 출처를
이슈 #239 로 밝히고, 본문 실측(15.0%)과 기준이 다름을 명시했다.
- SQL 을 어디에 대고 돌리는지 실행 줄을 붙였다.
검증: 워크스페이스 1301 passed / 0 failed / 64 ignored,
clippy --workspace --all-targets -- -D warnings 무경고.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
altair823
a80f0ae0e3