fix: literal_types 의 네 파서가 전각 숫자를 받아 같은 값이 두 표기로 갈린다

[SeoyunL]

요약

factlog/literal_types.py 의 네 파서가 모두 \d 로 숫자를 인식한다. 파이썬의 \d 는
유니코드 Nd 범주 전체에 매치하므로 전각 숫자가 조용히 파싱된다. 스칼라는 ASCII
표기와 같은 값이 나오는데 KB 가 저장하는 객체 문자열은 다르다. 그래서 같은 값이
문맥에 따라 하나로도, 둘로도 취급된다.

재현 (upstream/main c6d359d, Python 3.12 로 실측)

from factlog.literal_types import (
    parse_date, parse_number_scaled, parse_ordinal, parse_amount, DEFAULT_AMOUNT_UNITS,
)

parse_date('date(2020,1)')        # 20200101
parse_date('date(２０２０,１)')      # 20200101   <- 전각인데 통과, 같은 스칼라
parse_number_scaled('number(１２３)')            # 123000
parse_ordinal('ordinal(３)')                    # 3
parse_amount('１００억', DEFAULT_AMOUNT_UNITS)   # 10000000000

근거

factlog/literal_types.py:44-78 의 모든 수치 그룹이 \d 로 적혀 있다.

_DATE_RE           = re.compile(r"^(\d{4})[.\-/](\d{1,2})(?:[.\-/](\d{1,2}))?$")
_DATE_COMPOUND_RE  = re.compile(r"^date\(\s*(\d{4})(?:\s*,\s*(\d{1,2})...")
_NUMBER_RE         = re.compile(r"^-?\d[\d,]*(?:\.\d+)?$")
_ORDINAL_KO_RE     = re.compile(r"^제?(\d+)\s*(?:호|위|번|차|등|째)$")
_AMOUNT_RE         = re.compile(r"^(?P<num>-?\d[\d,]*(?:\.\d+)?) ?(?P<unit>\D+)$")

모듈 docstring 이 규정한 파서 계약은 "returns the canonical scalar, or None … never
guesses" 인데, 여기서는 정규화 없이 값을 받아들이면서 저장 문자열은 원문 그대로 둔다.
int() 가 전각을 받아주기 때문에 뒤따르는 변환도 예외 없이 통과한다.

코드베이스는 NFC 로 정규화하는데, NFC 는 전각 숫자를 접지 않는다(NFKC 만 접는다).
따라서 상류 어디에서도 두 표기가 합쳐지지 않는다.

영향

한 값이 세 갈래로 갈린다.

1. typed 관계 아래 — 그룹핑 키가 스칼라이므로 두 표기가 같은 값으로 병합된다.
   단일값 모순 검출·비교 규칙은 둘을 하나로 본다.
2. 객체 매치 질의 — 질의 상수는 저장 문자열과 대조되므로, ASCII 로 물으면 전각 행이
   조용히 미스한다. 검증된 부정(engine says no)과 구분되지 않는다.
3. typed 선언이 없는 관계 — 파서를 아예 타지 않으므로 두 표기가 별개 엔티티로
   남는다.

즉 "같은 값인가" 에 대한 답이 코드 경로마다 다르다. 심각도 중간 — 크래시는 없고
CJK 소스·PDF 변환·IME 전각 모드에서 유입되는 사고성 입력이 주된 경로다.

제안

두 방향 중 하나를 정책으로 선택해야 한다(둘 다 하면 안 된다).

• (A) 거부 — 수치 그룹을 [0-9] 로 좁혀 전각 값이 파싱되지 않게 한다. 값은 "does not
  parse" 경로로 떨어져 typed projection 경고와 entity_audit 의 malformed 보고에 드러난다.
  저장 문자열을 고쳐 쓰지 않으므로 데이터를 재작성하지 않는다. 다만 (3) 의 엔티티
  분리는 그대로 남는다.
• (B) 접기 — tools/merge_candidates.py 의 normalize_rows 에서 dedup 키 계산 전에
  전각을 ASCII 로 접는다(canonical_amount 가 이미 같은 자리에서 하는 일). 세 증상이
  한꺼번에 사라지지만 저장된 사실을 재작성하는 결정이다.

이 저장소가 --category 사전검증·silent-zero 가드에서 보인 규율(조용한 폴드보다 명시적
거부)을 따르면 (A) 가 일관된다. 어느 쪽이든 선택 자체가 문서화되어야 한다.

수용 기준

• 네 타입(date/number/ordinal/amount) 전각 입력에 대해 선택한 정책이 일관되게 적용된다.
• ASCII 입력의 기존 파싱 결과 불변(회귀 없음).
• (A) 선택 시: 전각 값이 사용자에게 보이는 경로(경고 또는 audit)로 최소 한 번 표면화된다.
• 네 타입 전각 케이스를 고정하는 단위 테스트.

[SeoyunL]

정정: "(A) 는 데이터를 재작성하지 않는다" 가 amount compound 에서 정확하지 않고, 수용 기준 3번도 조건부다.

(A) 는 literal_types.py 밖 네 경로를 바꾼다

본문 제안 (A) 를 "저장 문자열을 건드리지 않는다" 로 요약했는데, _AMOUNT_COMPOUND_RE 를 좁히면 canonical_amount 가 함께 좁아져 파일 밖에서 네 가지가 바뀐다. 이미 저장된 데이터는 어느 쪽이든 불변이지만, 그 밖의 서술은 정밀화가 필요하다.

실측 (upstream/main c6d359d → 수정본):

canonical_amount('amount(１００,억)')  : 'amount(１００,"억")'  ->  None
_canonical_value('amount(１００,억)')  : 'amount(１００,"억")'  ->  'amount(１００,억)'
humanize('amount(１００,"억")')        : '１００억'             ->  'amount(１００,"억")'

1. tools/merge_candidates.py:321 dedup 키 — canonical_amount 가 None 이 되어 bare/quoted 두 표기가 더는 한 행으로 합쳐지지 않는다. 새로 머지되는 전각 행은 저장 문자열이 따옴표 정준형으로 재작성되지 않고 원문 그대로 남는다.
2. factlog/common.py:1743 _canonical_value — 질의 미스. 기존 KB 에 저장된 amount(１００,"억") 를 amount(１００,억) 로 물으면 이제 미스한다. 정책 (A) 하에서 amount(１００,억) 은 유효한 amount 항이 아니므로 정준화 대상이 없다 — 의도된 결과이지만, 본문이 지적한 "검증된 부정과 구분되지 않는다" 가 여기에 그대로 적용된다. 본문 증상 (2) 가 이 하위 케이스에서는 개선이 아니라 악화다.
3. humanize — 전각 compound 는 렌더링 대신 원문 그대로 반환된다(표시 전용).
4. tools/check_conflicts.py:113 _group_key — 게이트가 뒤집힌다. 전각 값이 ("raw", 원문) 으로 떨어져 ASCII 쌍둥이(("scalar", …))와 갈리므로, 같은 주어의 단일값 관계에서 두 값이 되어 check_conflicts 가 exit 1 을 낸다. 경고가 아니라 게이트 실패다. 네 경로 중 초록을 빨강으로 뒤집는 유일한 것이다.

전각 값이 있는 기존 KB 는 소스를 ASCII 로 고쳐 재수집하면 둘 다 해소된다. 레포에 CHANGELOG 가 없어 docs/reference/typed-relations.md(+.en.md)에 적었다.

수용 기준 3번은 조건부로만 성립한다

"거부된 값이 사용자에게 보이는 경로로 최소 한 번 표면화된다" 를 무조건으로 썼는데, 실제 표면화 경로는 둘이고 그 사이에 구멍이 하나 있다.

관계 선언	표면화
typed (⊆ attribute)	common._project_typed_relations stderr 경고 ✓
attribute 이지만 typed 아님	entity_audit 의 declared_literals — 플래그 없는 정렬 목록. 구멍
attribute 선언 없음	entity_audit 의 literal_suspects stderr ✓

_project_typed_relations 는 spec 이 없는 관계를 경고 없이 continue 한다. 가운데 칸에서는 100억 과 １００억 이 정렬상 멀리 떨어져 나란히 보이지도 않는다. 본문 영향 (3)(두 표기가 별개로 남음)이 이 범위에서 그대로 남는다.

AC3 문구가 "경고 또는 audit" 이고 "최소 한 번" 이므로 PR 은 충족으로 보되, 이 구멍은 잔여 증상으로 명시했다.

(A) 를 지지하는 근거를 하나 더 찾았다

factlog/cli.py:1762-1764 의 factlog status 경로는 이미 원문 객체로 conflict 를 센다. 반면 tools/check_conflicts.py 만 스칼라로 병합해 0 을 보고한다 — 두 경로가 현재 서로 모순이고, 전각을 거부하면 그 불일치가 해소된다. 본문에 없던 논거다.

구현 메모

• 좁힐 대상은 정규식 9개 / \d 출현 21회다(본문에 개수를 적지 않았지만 기록해 둔다).
• re.ASCII 플래그로 한 번에 처리하면 안 된다 — \s 까지 좁혀 date(2020,<U+3000>1) 이 조용히 깨진다.
• _AMOUNT_RE 의 \D+ 단위 그룹은 유지해야 한다. \D 가 Nd 여집합이라 전각이 단위로 새지 않는다.
• tools/entity_audit.py 의 _LITERAL_RE 는 좁히지 말아야 한다. 좁히면 전각 값이 audit 에서도 사라져 위 표의 세 번째 표면화 경로가 닫힌다.