codex F4·4.2·4.3·4.5:
- 내보내기 메모가 마지막 비어 있지 않은 메모라 반려(메모)→승인(무메모) 뒤 지원자용 CSV 에
반려 사유가 나갔다 → 마지막 판정의 메모만.
- 보류·반려→승인 시 그 판정이 만든 주의 후보를 자동 철회(excluded, 감사 기록). 운영자가
승격한 확정 항목은 손대지 않고 감사에만 남긴다.
- 철회·제외된 항목에 걸려 있던 다른 케이스의 저장된 일치 행을 contributed=False 로 퇴역시키고
리스코어 — 스코어러는 항목 상태가 아니라 저장된 행을 읽는다. 기존 exclude 경로에도 적용.
- 재보류·재반려가 excluded/confirmed 항목을 되살리지 않는다.
verify.ps1: ruff clean, 674 passed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
codex F1: 보류·반려로 자동 생성된 주의 후보(watchlist)와의 일치가 확정 항목과 같은 80/high 를
받아, 검색 장애로 보류한 정상 이미지의 재제출이 알려진 권리 대상처럼 올라왔다.
① 스코어러: knowledge_entry_status == watchlist 는 별도 축 40/20(상한 40, 단독 medium),
확정(승격·수동 등록)만 80. 한 줄 요약도 '주의 후보 일치 0.95' 로 구분한다.
② 스토어: record_decision(held) 가 has_coverage_gap()(실패·일일 한도 미수행)이면 주의 후보를
만들지 않고 감사에 '검색 대기 (주의 후보 미생성)' 를 남긴다. 반려는 커버리지와 무관하게 생성.
가이드·PROJECT_MAP 갱신, 다이어그램 태그 v7 재생성(manifest 5종).
verify.ps1: ruff clean, 672 passed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
docs/operations/review-guide.md 의 6단계를 3레인(읽기·근거 확인 / 판정 / 기준 DB 에 남는 것)
workflow 로: 한 줄 요약 → 점수 구성 → 증거 열기 → 근거 표시 → 판정 → 다음 미심사.
분기는 미수행 하한(보류 후 재분석)과 판정 뒤 DB(주의 후보 자동 · 클리어 기준 등록 수동).
첫 안은 4레인·3항목 카드로 1440x900 에서 127px 넘쳐 레인 병합·제목 한 줄·카드 2항목으로
압축했고, 노드 폭 148 로 높이 예산(종횡비 1.52)을 맞췄다. validate 9/9 showcase,
visual-check 4개 뷰포트 containment pass, manifest 5종 갱신. rebuild 스크립트·manifest
갱신기 목록에 등록, PROJECT_MAP 표 추가. 문서·다이어그램만 변경.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
기존 operator-review-workflow 다이어그램은 시스템 흐름(폴더→분석→채점)이라 운영자의 질문
'어떻게 심사하고 무엇을 보는가'에 답하지 못했다. docs/operations/review-guide.md 로 다시 쓴다:
한 건 심사 6단계, 한 줄 요약의 신호와 판정 무게, 승인/보류/반려 기준과 뒤에 일어나는 일
(보류·반려 → 주의 후보, 승인은 DB 에 안 남으니 클리어 기준 등록 별도), 반려 사유 프리셋,
키보드, 일괄 처리, 헷갈리는 것, 종료 루틴. 콘솔 라벨은 index.html 문자열로 대조.
문서만 변경 — 코드·테스트 무변경.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
코퍼스 DB 로 실 콘솔을 띄워 보니 큐의 '상위 근거' 칸이 '구글 visually s... 구글 페이지
with ...'(사유 원문 둘을 잘라 붙인 것)이었고 증거 제목도 '구글 full image match found' 로
절반 영어였다.
스코어러가 점수 계산과 별개로 집계(_Tally)해 riskBreakdown.headline 에
'웹 완전일치 사본 4곳 · 식별 가능 인물 · 이름 있는 검색 승격 2건 · 라벨 9개' 를 싣는다.
순서는 예산표, 웹은 가장 강한 뷰만 호스트 수(곳)로, 등록 일치·클리어 이력·미수행·실패·
신뢰 출처 제외까지 한 줄. 큐 행과 케이스 요약 보드의 첫 줄이 이것으로 바뀌고
headline 없는 옛 케이스만 예전 배치. formatReason 에 Vision 매치 4종·검색결과 사본·
기준 DB 유사도 한국어 매핑. 요약 보드 첫 줄은 word-break: keep-all 로 구 단위 줄바꿈.
점수·밴드 변화 없음(SCORER_VERSION 유지). 실렌더로 큐·케이스 확인.
verify.ps1: ruff clean, 663 passed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
배포 판단에서 파일럿 전 유일한 차단으로 꼽은 구멍. 네이버 일일 한도 100 = 20장이라
21장째부터 검색이 SEARCH_SKIPPED 0점·무사유로 빠져 점수가 낮게 나왔다.
정책 거절 사유 중 하루 안에서 케이스마다 달라지고 어디에도 안 보이는 하나(usage limit
reached)만 v5 의 실패 하한 30 에 합류시키고 사유에 '<provider> 미수행 — <사유>' 를 남긴다.
disabled 는 키 미설정 배포와 비상 차단이 같은 사유를 쓰고 둘 다 콘솔 providerState 에
보이므로 그대로 0점·무사유 — 하한을 걸면 키 없는 배포의 큐 전체가 medium 이 된다(기본
스토어 테스트가 잡아냈다). 거버넌스 스위치(compliance·metadata logging·online mode)도 0.
라운드트립은 신선 점수·사유를 재현한다(provider 는 domain 으로 복원). 다이어그램 태그 v6.
verify.ps1: ruff clean, 657 passed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
첫 실측이 보인 원인은 축 예산의 합(245 vs 상한 100)이었다. 캡 없는 두 축만 캡하는
시뮬레이션(80/50, 60/40)으로는 20/20 이 그대로 100 이라 총합 기준으로 다시 짰다.
예산: 등록 권리 대상 일치 80(단독 high) · 웹 존재 40(검색결과 사본 유사도·Vision 매치·
CSE 페이지가 제공자 무관 한 풀, 뷰 강도로만 40/30/10) · 인물 30/10 · 이름 있는 검색
승격 15 · 라벨 10 → 등록 제외 최대 95. 외부 검색 실패는 +30/행 가산 대신 medium 하한.
검색결과 사본 행은 knowledge_entry_id 부재 + url/source_evidence_ids 로 웹 풀에 간다.
격자 432: high 92→75%, 포화 80→44%(남은 포화는 전부 등록 강한 일치 조합), 웹 신호만
high 13/24→0/24. 실이미지 20장 리스코어: 100점 20→0, 구별 점수 1→4(75/80/92/95),
밴드는 전부 high 유지(전부 웹에 있는 인물 사진 — medium/low 임계는 여전히 미검증).
다이어그램 spec 3종 v5 + 재생성(archify 2.17). operator-review-workflow 는 새
desktop-readability 검사에 HEAD 그대로 걸려 노드 폭 132→124 로 통과시켰고, 그 확대로
1440x900 세로 13px 넘침이 남는다(visual-check containment) — INDEX 에 기록.
verify.ps1: ruff clean, 654 passed.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
sample/ 20장을 별도 DB 로 시드해 이 프로젝트 최초의 실이미지 측정을 했다.
증거 1,615행(Vision 809 + 네이버 692)이 붙었고 결과는 20장 전부 100점/high 다.
탐지는 정상이다 — 15장은 웹에서 완전일치(similarity 1.00) 사본이 발견됐고
4장은 근사일치다. 문제는 밴드가 아니라 순서가 없다는 것이다. 큐 기본 정렬이
riskScore 내림차순인데 전부 100 이라 정렬이 no-op 이고, 운영자는 구별되지 않는
20건을 받는다.
근본 원인은 축별 예산의 합이다.
인물 35
웹 게시 60 (캡 있음)
웹 엔티티 20 (캡 있음)
검색결과 유사도 캡 없음 — 장당 평균 216
네이버 승격 캡 없음 — 장당 평균 70
앞의 세 축만 더해도 115 로 이미 상한 100 을 넘는다. v2~v4 가 축을 하나씩
캡했지만 합을 한 번도 보지 않았다 — 어제 만든 432조합 격자가 high 92% /
포화 80% 를 보고했는데 실이미지에서는 100% 다.
캡 없는 두 축에 캡을 씌우는 것으로는 안 된다. 지문 80/네이버 50 과 60/40 을
실제 코퍼스 데이터로 시뮬레이션했으나 20/20 이 그대로 100 이었다. 축 예산을
총합 기준으로 재배분해야 하고 그것은 제품 결정이라 임의로 하지 않았다.
검색결과 유사도가 +80/건 무제한인 것은 v2 가 고친 것과 같은 논리 오류다.
같은 이미지가 웹에 있다는 하나의 사실을 발견된 URL 수만큼 세고 있다.
코퍼스 한계: 20장 전부 웹 유통 인물 사진이라 low 기대군이 0건이다. 이
코퍼스로는 medium/low 임계를 검증할 수 없다(lowBandRejectionRate 분모 0).
첫 시도는 내 스크립트가 .env 로딩(__main__.py:70)을 빠뜨려 프로바이더가 전부
비활성이었다. 외부 호출 0콜이라 쿼터 손실은 없었고, 그 무효 런이 부수적으로
두 가지를 알려줬다 — 웹 증거가 0건이어도 인물만으로 35/medium 이 되고,
external_skipped 는 점수에도 사유에도 뜨지 않아 키 만료나 쿼터 고갈이 조용히
지나간다.
sample/ 과 corpus/ 를 gitignore 에 넣었다. 저작권 실이미지가 납품 저장소를
따라가면 안 된다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
SCORER_VERSION 이 v1 에서 v4 까지 갔는데 v3(제공자별 풀링)와 v4(신뢰 출처)는
밴드 분포를 한 번도 측정하지 않고 나갔다. 2026-08-08 평가가 쓴 224조합 하네스는
저장소에 남아 있지 않고, 그 문서의 두 수치(174/224=77.7% 와 82.6%)가 서로 맞지
않아 격자가 달랐음을 시사한다 — 과거 숫자와 비교 가능한 재현은 불가능하다.
그래서 격자를 스크립트에 명시적으로 고정해 새 기준선으로 삼는다.
scripts/score_distribution.py 432조합 전수, 사람 없이 돈다
scripts/sweep_thresholds.py 판정 시점 스냅샷 기준 임계 스윕
docs/operations/calibration-corpus.md 코퍼스 절차
실측 결과(v4, 432조합):
신뢰출처 미등록 신뢰출처 등록
high 92% 63%
100점 포화 80% 38%
웹 신호만으로 high 13/24 0/24
두 가지가 드러났다.
1. v2 가 세운 "웹 존재만으로는 high 가 되지 않는다" 원칙이 이미 깨져 있다.
presence 풀(최대 60)과 entity 풀(최대 20)이 각각 임계 아래로 캡되지만 합은
캡되지 않아, full+partial + 엔티티 1개만으로 80/high 가 된다.
2. v3 의 제공자별 풀링이 그 경향을 키웠다. 독립 제공자가 하나 더 있으면 웹 전용
조합의 high 가 4/12 -> 9/12, 전체 high 가 88% -> 97% 가 된다. 교차 확증이
high 에 닿아야 한다는 v3 의 의도대로 동작한 결과지만 총량 통제가 없다.
대응 후보(웹 유래 점수 총합 상한)는 적용하지 않았다. 적용하면 또 한 번의
미측정 변경이 되고, 이번 실측이 바로 그 패턴을 지적한 것이기 때문이다.
결정 후 진행한다 — 적용 시 SCORER_VERSION 을 올리고 이 표를 다시 측정한다.
이 격자는 신호 축을 균등 샘플링하므로 실제 큐 분포가 아니다. 92% 는 "실제 큐의
92% 가 high"라는 뜻이 아니고 임계가 맞는지도 말해주지 않는다. 구조적 거동의
기준선일 뿐이다.
임계 검증은 실이미지 30~50장과 **사람의 판정**이 있어야 성립한다. 내가 판정을
만들면 도구의 밴드를 내 라벨과 대조하는 꼴이라 아무것도 검증되지 않는다.
sweep_thresholds.py 는 그때를 위한 도구이고, 지금은 usable pairs 0 을 정직하게
보고한다(가짜 판정 6건을 넣은 사본 DB 로 출력 동작은 확인했다).
검증: ruff clean, pytest 645 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
승인·보류는 A/H 한 키에 자동 다음 케이스 이동까지 되는데 반려만 메모가
필수라 흐름이 끊겼다. R 은 메모 필드에 포커스만 줬고, 입력 중에는 전역
단축키가 막히므로(J/K 가 글자로 들어가면 안 되니 의도된 동작) 거기서부터는
마우스로만 제출할 수 있었다. 저작권 심사에서 법적으로 가장 중요한 판정이
가장 느린 경로였다.
R 사유 선택 모드 (프리셋에 1~9 번호가 보인다)
1~9 그 사유로 즉시 반려 + 다음 미심사 케이스로
M 직접 입력으로 전환
Esc 취소
메모 안에서 Ctrl+Enter 자유 서술 반려 제출
화면의 번호가 곧 눌러야 할 키다. 프리셋 칩에 키 배지를 붙여 단축키를 외우지
않아도 되게 했다.
숫자는 사유 선택 모드 안에서만 의미를 갖는다. 모드 밖에서 숫자에 의미를 주면
잘못 누른 키 하나로 반려가 나간다 — 되돌릴 수 있는 동작이지만 주의목록 항목을
만들고 감사에 남으므로 사고로 일어나서는 안 된다. 가드가 숫자 분기보다 먼저
오는지를 테스트가 위치로 확인한다.
프리셋이 하나도 없으면 고를 것이 없으므로 모드를 열지 않고 예전처럼 메모
필드로 보낸다.
실렌더(Playwright 1440x900, 실제 서버 + 부트스트랩 스텁):
R -> 2 {"decision":"rejected","memo":"라이선스 확인 불가로 반려"}
메모 + Ctrl+Enter {"decision":"rejected","memo":"자유 서술 사유"}
콘솔 에러 0.
검증: ruff clean, pytest 645 passed (정적 3건 추가).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
이건 내가 만든 부채를 갚는 커밋이다. 스코어러에 풀 상한(v2/v3)과 신뢰 출처
제외(v4)를 넣으면서 증거 개수와 점수의 간극이 그 어느 때보다 벌어졌는데,
그 이유가 화면 어디에도 없었다. 운영자가 숫자를 믿지 못하면 그 우선순위는
우선순위가 아니고, 그러면 앞의 두 기능이 오히려 불신을 만든다.
ScoreResult.breakdown 을 신설했다. reasons 가 "어떤 증거가 말했는가"라면
breakdown 은 "그래서 몇 점인가"다.
지식DB 지문 매칭 80
웹 게시 (google) 60 원래 125 · 상한 60
웹 엔티티 라벨 20 원래 114 · 상한 20
신뢰 출처 posar.info 3행 제외
합계 115점이 상한 100에 걸렸습니다 — 이 구간의 케이스는 서로 구별되지 않습니다
마지막 줄이 특히 중요하다. 100 에 걸린 케이스들은 서로 구별되지 않으므로
우선순위 판단에 쓸 수 없는데, 지금까지는 그 사실이 숨어 있었다.
자리는 증거 요약과 증거 목록 사이다 - "51개 증거"를 읽은 직후, 목록을 훑기
직전이 바로 그 질문이 생기는 지점이다.
점수는 하나도 바뀌지 않는다. 계산 흐름에 기록만 붙였고 기존 스코어러 테스트
31건이 그대로 통과한다. 가중치·버킷·밴드가 불변이므로 SCORER_VERSION 은 v4 를
유지한다(설명을 추가하는 것은 스탬프 규칙의 대상이 아니다).
분해 합계가 항상 점수와 일치하는지를 테스트로 고정했다. 분해가 점수와 다른
이야기를 하면 그건 분해가 아니라 또 하나의 주장이 된다.
실렌더(Playwright 1440x900): 패널이 의도한 자리에 서고 콘솔 에러 0.
검증: ruff clean, pytest 642 passed (스코어러 5건 + 정적 1건 추가).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
8/8 실효성 평가가 "운영자 되먹임이 순증 노동"이라고 적은 항목이다. 스코어러는
점수를 만든 행이 표시돼야 점수를 내려놓는데, 단건 API(/api/evidence/{id}/status)
하나뿐이라 실 DB 제출물 하나를 100 에서 35 로 내리려면 google 증거 51행을
개별로 눌러야 했다. 되먹임이 노동보다 비싸면 아무도 되먹이지 않는다.
증거 그룹 헤더의 개수 옆에 [전부 무관] 을 붙이고, POST /api/evidence/status-batch
를 신설했다.
서버는 한 트랜잭션, 리스코어 1회, 감사 이벤트 1건으로 묶는다. 감사 부분은 그
자체로 중요하다 — 이건 한 번의 운영자 동작이고, 51건을 쓰면 동작을 잘못
표현할 뿐 아니라 500행 감사 캡을 클릭 한 번에 먹는다. 행별 who/when/note 는
각 증거 payload 에 그대로 남으므로 개별 행이 설명 불가가 되지는 않는다.
원자성: 남의 제출물 증거 id 가 섞이면 아무것도 쓰지 않고 전체가 실패한다.
절반만 표시된 상태로 끝나면 운영자는 무엇이 반영됐는지 알 수 없다.
상한은 500 이다. 일괄 판정 상한(200)보다 큰 이유는 단위가 다르기 때문이다 —
그쪽은 케이스 수고 이쪽은 한 케이스 안의 증거 행 수다.
그룹 액션은 irrelevant(무관)로 보낸다. 행별 "미사용" 버튼은 false_positive
(오탐)에 매핑돼 있는데, 한 제공자의 결과 전체를 오탐이라 단정하는 것은 과한
주장이다. 점수 효과는 같고(스코어러는 둘 다 건너뛴다) 주장만 정직해진다.
확인 대화는 두지 않았다. 이 동작은 행마다 되돌릴 수 있고, 여기서 줄이려는
것이 바로 그 클릭이다. 되돌릴 수 없는 느낌이 드는 것은 판정이고 확인 대화는
거기에만 있다.
실렌더(Playwright 1440x900, 실제 서버): 51행 그룹에서 1타로
{"status":"irrelevant","evidence_ids":[51개]} 전송, 콘솔 에러 0.
검증: ruff clean, pytest 636 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
8/8 실효성 평가가 "남은 것: 신뢰출처 판정 자체. 목록만 정해지면
cleared_reference 와 같은 패턴으로 바로 붙는다"로 남겨둔 항목이다. 전제였던
"호스트가 저장 시점에 파괴되는" 문제는 9/18 에 고쳤고, 저장 위치는 지식DB 로
정해졌다.
지식DB 의 trusted_host 항목 — 이름이 호스트, 별칭이 같은 주체의 다른 도메인
신뢰 철회는 기존 활성/비활성 수명주기 그대로 (두 번째 스위치를 만들지 않는다)
핵심은 **행 단위 제외**라는 것이다. 케이스 단위로 끄면 자사 사본이 있다는
이유로 스크래퍼 게시까지 덮인다. 실측: 우리 CDN 완전일치 + 블로그 게시가 같이
있을 때 신뢰 등록 전 80/high, 등록 후 35/medium — 블로그만 남는다.
제외된 행은 점수에서 빠지되 사유로는 남는다("신뢰 출처 posar.info — 위험
점수에서 제외"). 증거 목록에는 그 행이 그대로 보이므로, 왜 점수가 증거보다
조용한지 운영자에게 말해주지 않으면 도구를 불신하게 된다.
경계 처리:
서브도메인은 같은 주체다 (cdn.posar.info)
posar.info.evil.test 는 접미사가 아니라 다른 도메인이다
점 없는 값은 무시한다 — "com" 하나가 웹 전체를 신뢰 처리하면 안 된다
엔티티 라벨은 영향 없다 — "어디에 떠 있나"가 아니라 "무엇이 찍혔나"다
신선한 CSE 행은 host 키가 없어 domain(displayLink)에서 해석한다
호스트 해석이 store_serialization._result_host 와 따로 사는 이유는 층 때문이다.
analysis 는 server 를 import 할 수 없고, 한쪽은 값을 영속화하고 다른 쪽은
운영자 목록과 대조한다. 우선순위는 같게 맞추고 그 사실을 양쪽 주석에 적었다.
빈 목록이면 v3 과 동작이 같다. 등록하지 않은 배포는 아무것도 달라지지 않는다.
다이어그램 사실 게이트(9/21 신설)가 v3 -> v4 를 3개 다이어그램에서 자동으로
잡았다. 스펙을 고치고 rebuild-diagrams.ps1 로 재생성했다 — 게이트의 첫 실사용이고
의도대로 동작했다.
검증: ruff clean, pytest 632 passed (스코어러 7건 + 스토어 3건 추가).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
8/8 실효성 평가의 결론은 "검색·기록 노동은 줄여주나 심사 건수는 전혀 못 줄인다"
였다. 이 커밋은 그 축을 직접 건드리는 첫 기능이다.
중복 탐지는 이 도구에서 실증으로 검증된 유일한 판별 기능이다 — 재저장(JPEG q90)
/80%축소/50%축소/밝기+10% 변형 24건 중 24건 그룹핑, 같은 24건에서 SHA-256
완전일치는 0건. 그런데 그 결과를 쓰는 곳이 없었다. 서버는 store_duplicates.py
에서 priorDecisions 와 conflicting 을 계산해 내려보내는데, 콘솔은 그것을 큐
배지의 title 속성에만 넣었다. 마우스를 올린 사람만 "이거 지난주에 반려한
이미지"임을 알 수 있었고, 재제출은 처음부터 다시 심사됐다.
서버는 건드리지 않았다. 자리만 옮겼다.
큐 배지 "동일 이미지 3건 · 선례 반려" (title 이 아니라 본문에)
판정 패널 결정 메모 바로 위에 선례 배너 + [선례 승계] 1타
승계는 별도 판정 경로를 만들지 않는다. 메모를 채워 기존 setDecision 을 그대로
타므로 반려 메모 필수 검사 · 판정 시점 스냅샷 · 감사 이벤트가 유지되고, 승계
사실은 메모로 감사에 남는다("선례 승계: 동일 이미지 SUB-OLD1, SUB-OLD2 와 같은
판정").
판정 불일치는 승계 대상이 아니다. 같은 이미지에 서로 다른 판정이 있다는 것은
자동 처리할 상황이 아니라 사람이 봐야 하는 신호이므로, conflicting 이면 버튼을
아예 내지 않고 색을 갈라 표시한다.
실렌더 확인(Playwright 1440x900, 실제 서버 + 부트스트랩 스텁):
세 상태(승계 가능 / 판정 불일치 / 선례 없음)의 배너 문구와 버튼 유무가 의도대로,
승계 클릭 시 POST 본문이 위 메모 그대로, 콘솔 에러 0, 가로 오버플로 없음.
검증: ruff clean, pytest 622 passed (정적 3건 추가).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
감사 에이전트가 낸 수치를 그대로 부채 표에 옮겼는데, 저장소에 사실로 박히는
값이라 직접 재현해 확인했다.
architecture 라벨 임계: 19·20자 통과, 21·22자 하드 실패 — 주장대로였다.
lifecycle 캐스케이드: 상태 1개 + 전이 1개 추가에 오류 5건, 그중 손대지 않은
기존 t-reject 관련이 3건. 표에는 4건으로 적혀 있었다.
검증 조건(waiting 레인 col 1)도 함께 적어 다음 사람이 같은 실측을 재현할 수
있게 했다. 캐스케이드가 실재한다는 결론은 그대로다.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
용도를 내부 문서로 못박았다. 고객 인수물이 아니므로 납품 품질 기준을 적용하지
않는다 — 감사에서 나온 한글 폰트 미번들과 영어 뷰어 UI 는 archify 한계라 spec
으로는 못 고치는데, 사내 머신에는 한글 폰트가 있으므로 low 로 내렸다. 승격
조건(그 둘이 먼저 blocker)을 PROJECT_MAP 다이어그램 절에 적어 두었다.
그 위에 두 번째 게이트를 올린다. 기존 test_diagram_sync 가 "산출물이 spec 보다
낡았나"를 본다면, test_diagram_facts 는 "spec 이 코드보다 낡았나"를 본다.
그림에는 코드에서 뽑은 상수가 라벨과 카드 문장으로 하드카피돼 있어서,
SCORER_VERSION 을 올리거나 믹스인을 하나 추가하면 코드는 통과하고 그림만
조용히 틀려졌다. CLAUDE.md 가 그 값들을 규칙으로 못박아 두었는데 정작 같은
값을 그린 다이어그램에는 보호가 없었다.
SCORER_VERSION · SCHEMA_VERSION · 믹스인 개수 · app-*.js 개수 · 바디 상한
· 인증 실패 10회/60초 · 프롬프트 12행 상한 · 풀 상한 60/20 · 기본 모델
· 런타임 의존성 3종
"지문 유사도 0.9+ -> 80점" 은 이름 있는 상수가 아니라 risk_scoring 안의 인라인
리터럴이라, import 대신 실제로 채점해서 확인한다. 라벨이 주장하는 값과 스코어러가
내는 값이 같은지를 직접 본다.
차단을 실증했다 — SCORER_VERSION v3->v4 로 3건, MAX_PROMPT_EVIDENCE 12->16 으로
2건이 실패한다. 영향받는 다이어그램 전부에서 잡힌다.
발견 가능성도 정리했다. 감사에서 "3.3MB 산출물이 어떤 문서 색인에도 없다"가
나왔으므로 README 색인에 등재하고, PROJECT_MAP 까지 가지 않아도 되도록
docs/diagrams/README.md 에 직접 수정 금지·재생성 명령·CSP 주의를 두었다.
검증: ruff clean, pytest 619 passed (사실 게이트 +19).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
감사에서 나온 결론은 "그림은 지금 정확하지만 정확함을 지킬 장치가 없다" 였다.
코드 유래 리터럴 18개가 전부 코드와 일치하고 deliver 는 바이트 결정적인데,
드리프트를 막는 게이트·테스트·훅이 0개였고 문서에 적힌 재생성 절차는 그대로는
실행되지 않았다 — `archify` 실행 파일은 PATH 에 없고 실제로는 저장소 밖 전역
스킬을 node 로 불러야 한다. 다음 사람은 첫 명령에서 막혔을 것이다.
scripts/rebuild-diagrams.ps1 validate -> deliver -> visual-check -> manifest
scripts/update_diagram_manifest.py 수신증의 단일 작성자
docs/diagrams/manifest.json spec/html sha256 + generator 버전
tests/test_diagram_sync.py 게이트 14건
게이트는 브라우저도 Node 도 archify 도 없이 돈다. 산출물이 바이트 결정적이라
수신증 대조만으로 충분하고, 그래서 폐쇄망 CI 에서도 돈다. 두 사고 시나리오를
실제로 만들어 차단을 확인했다 — HTML 의 단어 하나를 고치면 html sha 가,
spec 의 태그 하나를 고치면 spec sha 가 어긋나 verify 가 실패한다. 노드 id 가
HTML 에 data-node-id 로 박히므로 의미적 연결도 함께 본다.
git 위생 두 건도 같이 정리했다. *.visual-check.json 이 개발 머신 절대 경로와
크롬 설치 경로를 평문으로 담은 채 미추적·비ignore 상태였다(24개) — 납품
저장소가 removable media 로 건너가는 구조라 한 번 커밋되면 제거가 어렵다.
그리고 15,000줄 생성 HTML 을 텍스트로 머지하려 드는 것을 막았다.
재생성해도 4종 sha256 이 전부 불변이라 바이트 결정성을 다시 확인했다.
감사에서 나온 나머지 부채(한글 폰트 미번들, 영어 뷰어 UI, architecture 좌표
하드코딩, lifecycle 손튜닝 8개소, 콘솔 CSP 비호환)는 PROJECT_MAP 부채 표와
다이어그램 절에 등재했다. 폰트와 UI 는 archify 쪽 한계라 spec 으로는 못 고친다.
검증: ruff clean, pytest 600 passed (게이트 +14).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
아키텍처 · 운영자 심사 워크플로 · 제출물 상태 전이를 신설하고, 기존 증거
데이터 흐름까지 4종의 범례를 한글화했다. 렌더러 기본 범례가 "User UI /
Agent logic / Context-trace" 나 "policy / PII" 처럼 타 도메인 문구였다 —
legend.entries 로 라벨만 바꿨고 종류와 개수는 그대로다.
system-architecture 폐쇄망 경계와 그 밖의 외부 검색 API. 나가는 경로는
store_remote_fetch 하나뿐이고 앞에 호출 게이트가 있다
operator-review-workflow 4레인(제출·자동·심사·차단). 비상 차단이 걸려도
커버리지 부족 표시로 심사가 이어지는 경로 포함
submission-lifecycle 분석 실패와 보류가 종료가 아니라 분석 중으로
돌아오는 두 고리, 판정 후 보존 상태
작성 중 내린 고도 판단 두 개를 남긴다.
아키텍처에서 analyzer/scorer 를 "분석 · 채점" 한 컴포넌트로 합쳤다. 이
고도에서 그 분리는 엣지를 벌지 못하고, store 노드에 엣지 7개가 몰려
통로가 부족해졌다. 채점 내부는 dataflow 다이어그램이 담당한다.
라이프사이클에서 "재분석 요청"을 상태에서 뺐다. decisionStatus 값이 아니라
운영자 액션이고, 보류가 같은 의미를 담아 긴 복귀 엣지를 하나로 줄인다.
검증: 4종 모두 showcase 통과(아티팩트 검사 9/9 · 합성 오류 0 · 경고 0),
visual-check 통과(1440x900 · 2048x1320 각 Light/Dark, 오버플로 0).
html sha256 — dataflow a62f0f5c / architecture f5a4b6e1 /
workflow 402914a3 / lifecycle 62e934a3
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
수집 → 경계 검사 → 정규화·채점 → 영속화 → 소비 5단으로, 9/18 리뷰 수정에서
나온 불변식을 그림으로 고정한다.
제공자별 풀·버킷(RiskScorer v3) · 라운드트립이 원 점수를 재현
(_evidence_payload <-> _domain_evidence_from_ui) · host 는 저장 시 해석하고
복원 시 우선 반환 · 지식DB 지문 매칭이 풀링 밖 유일한 high 승격 경로
작성 중 확인한 사실도 반영했다: 프로덕션 LLM 경로는 영속화된 payload 를
_domain_evidence_from_ui 로 복원해 넣는다(store_operations.py:487). 그래서
프롬프트가 host 를 보는 것은 복원 경로 덕분이다 — analysis/evidence_enrichment.py
의 EvidenceEnricher 는 테스트에서만 쓰인다.
소스는 evidence-dataflow.dataflow.json (archify dataflow v1). 그림을 고치려면
JSON 을 고쳐 재생성한다. 산출물은 자체 완결 HTML 로 외부 요청이 없다.
검증: archify showcase 통과(아티팩트 검사 9/9 · 합성 오류 0 · 경고 0),
visual-check 통과(1440x900 · 2048x1320 각 Light/Dark, 오버플로 0,
최소 투영 텍스트 6.71px >= 6px). html sha256 268f3352 (822,655 B).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
INDEX 에 반증 1건 포함 결과를 기록하고, PROJECT_MAP 부채 표에 "테스트가 로컬
ollama 에 실접속" 항목을 추가했다 — 이번 작업에서 발견했지만 15건 범위 밖이라
수정하지 않았다. 풀 캘리브레이션 부채 행의 v2 표기도 v3(제공자별)로 갱신.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
P1 3번("매칭 호스트 기반 신뢰출처 구분")을 착수하며 전제를 검증했더니 틀렸다.
호스트는 "이미 저장돼 있고 점수만 안 쓰는" 게 아니라 저장 시점에 파괴되고
있었다.
google_custom_search.py:240,296 이 실호스트(displayLink)를 data["domain"] 에
넣는데, store_serialization.py:298 이 data["provider"] 를 우선하므로 그 값이
API 이름으로 덮어써진다. Vision·Naver 는 호스트를 아예 안 넣고 URL 만 준다.
결과적으로 저장된 모든 행의 domain 이 "google" 이고, LLM 프롬프트 12줄이 전부
domain=google 이었다 — 저작권 심사에서 가장 결정적인 "어디에 떠 있나"를 모델도
운영자도 볼 수 없었다. 같은 케이스의 payload 55행 중 41행이 url 을 갖고 있는데도.
domain 필드는 재사용할 수 없다. provider 커버리지 동기화와 CSE 쿼리 시그니처
매칭이 그 값을 키로 쓰고(store_serialization.py:195, 599) 콘솔도 provider
라벨로 렌더한다. 그래서 host 를 별도 키로 신설했다.
_result_host(): data["domain"] 이 provider 와 다르면 그것을, 아니면 결과/페이지
URL 에서 호스트를 파싱한다. www 제거·소문자화. 파싱 실패는 "호스트 없음"이지
영속화 실패가 아니다.
점수에는 영향이 없다 — RiskScorer 는 domain 도 host 도 읽지 않는다. 증거 id 도
안 바뀐다: _evidence_id 는 도메인 객체의 data 를 해싱하고 payload 를 해싱하지
않으므로 payload 키 추가가 id 를 움직이지 않는다.
PROMPT_DATA_FIELDS 의 domain -> host. 화이트리스트 크기는 그대로.
콘솔은 증거 카드 제목 줄에 monospace host-chip 을 붙인다. 기존 저장 행에는 host
키가 없으므로 evidenceHost() 가 저장된 URL 에서 파생한다 — 292행 마이그레이션도,
bootstrap 마다 행당 파싱도 필요 없다(렌더되는 행만 지나간다).
실렌더 검증(127.0.0.1:9512, 실 DB)에서만 드러난 레이아웃 결함 2건을 고쳤다.
코드 리딩으로는 보이지 않았다.
1) 긴 CDN 호스트(cloudfront-ap-northeast-1.images.arcpublishing.com)가 제목 줄
폭을 다 먹어, evidence-title 의 overflow-wrap:anywhere 와 결합해 제목이 한
글자씩 세로로 깨졌다. 칩을 max-width 20ch 로 묶고 제목에 flex:1 1 auto 를 줘
남는 폭을 갖게 했다.
2) 그 수정 후에는 반대로 biz.chosun.com(14자)까지 잘렸다. 칩을 flex:0 0 auto 로
고정했다 — 제목("구글 full image match found")은 전 행이 동일한 상용구이고
호스트가 그 행의 실제 내용이므로, 들어갈 수 있는 호스트가 잘리는 쪽이 잘못이다.
최종: 칩 82개 전부 유효 호스트 형태(TLD com/edu/hk/jp/kr/net/org), 가시 칩 41개 중
잘리는 것 4개(모두 20자 초과 CDN), 콘솔 에러 0.
PROVENANCE 배점은 보류한다. 두 조건이 다 안 맞는다. (a) detect_screen_capture 의
카테고리가 geometry 와 subtitle_band 둘뿐인데 2개를 요구하므로 라벨의 실제 의미는
"geometry AND 자막"이고, 자막 없는 방송 캡처는 구조적으로 도달 불가다 — 임계를
낮추는 게 아니라 독립적인 세 번째 신호가 필요하고 그건 새 탐지기다. 한계를 실측과
함께 상수 옆에 기록했다. (b) "새 탐지 신호는 0점 라벨로 출시한 뒤 decision_stats
상관을 보고 가중치 부여"가 2026-07-25 결정이고, 판정 0건인 지금 배점하면 그 결정을
위반한다.
신뢰출처 판정 자체는 "어느 도메인이 우리 것/라이선스 계약처인가"라는 운영자
데이터가 있어야 한다. 호스트가 살아났으므로 목록만 정해지면 cleared_reference 와
같은 패턴(점수 0 + 사유 노출)으로 붙는다.
테스트 4건 추가. pytest 574 passed(착수 전 570), 린트 클린.
기능 실효성 평가에서 확정된 판별력 붕괴를 고친다. 신호조합 224개 전수에서
77.7% 가 high, 56% 가 정확히 100점에 붙고 low 는 3.6% 뿐이었다. 큐 기본 정렬이
riskScore 내림차순인데 전건이 100 이면 정렬이 no-op 이므로, 점수가 운영자에게
주는 우선순위 정보가 0비트였다.
동인은 하나가 아니라 둘이었고 둘 다 "같은 사실을 여러 행으로 센다"는 같은
형태다.
라벨 풀 (WEB_ENTITY_MAX_POINTS = 20)
category 없는 raw Vision 웹 엔티티가 이름별 버킷이라 서로 dedup 되지 않고
round(40*conf) 씩 무한 누적됐다. Vision 은 maxResults=10 이라 모든 이미지에
라벨을 붙이므로, 이미지 매칭이 0건이어도 0.8 짜리 라벨 3개면 100/high 였고
웹에 전혀 없는 오리지널 사진이 66/medium 이었다. 모집단 전체에 상수로
존재하는 신호는 판별에 기여할 수 없다. medium 임계(30) 아래로 묶어 라벨이
케이스를 물들일 수는 있어도 밴드를 정하지는 못하게 했다.
category(character/celebrity/work) 가 붙은 엔티티는 풀에서 제외한다 — 그것은
raw 라벨이 아니라 권리 분류이고 엔티티별 +45 를 유지한다. 조사 단계에서
"test_two_distinct_web_entities_stack_into_high_risk 가 이 동작을 고정하므로
함께 개정해야 한다"고 봤으나 틀렸다. 그 테스트는 category 있는 엔티티를
다루므로 두 분기를 가르면 개정 없이 통과한다.
웹 존재 풀 (WEB_PRESENCE_MAX_POINTS = 60)
Vision 응답 1회가 "이 이미지가 웹에 있다"는 하나의 사실을 full / partial /
page / visual 4개 상관된 뷰로 동시에 보고하는데, 스코어러가 이를 독립 신호로
합산해 45+35+35+10 = 125 -> 상한 100 이 됐다. 널리 게시된 평범한 이미지와
명백한 침해물이 같은 100/high 로 수렴한 이유다. high 임계(70) 아래로 묶었다.
원칙: 웹에 존재한다는 사실만으로는 high 가 되지 않는다. high 가 되려면 두
번째 종류의 신호(인물, 지식DB 지문 매칭, 승격된 검색 히트)가 필요하다. 존재
자체는 침해가 아니고 그 판단은 운영자의 몫이다.
측정 (224조합, v1 -> v2)
웹 신호만으로 high 가 되는 조합 2/7 -> 0/7
100점 포화 66.5% -> 51.3%
웹에 없는 오리지널 사진, 라벨만 100/high -> 20/low
이미 안전 확인한 자산(cleared) 100/high -> 20/low
웹 존재 광범위(4개 매치 타입) 100/high -> 60/medium
완전일치 사본 + 식별가능 인물 80/high -> 80/high (불변)
명백한 침해(전 신호) 100/high -> 100/high (불변)
전체 high 비율은 82.6% -> 76.3% 로 크게 안 움직인다. 이 격자는 신호 축을 균등
샘플링하므로(지식DB 강매칭이 1/4) 실제 큐 분포의 대리값이 아니며, 실 DB 6건도
100x4 -> 95x4 로 밴드가 바뀌지 않는다 — 그 4건은 전부 "완전일치 사본 + 인물"
이라 high 가 맞다. 고친 것은 거짓 high 이지 진짜 high 가 아니다.
두 상한은 신호의 구조적 성질에서 나온 값이지 캘리브레이션 결과가 아니다.
판정 30~50건이 쌓이면 decision_stats 교차표로 임계와 함께 재조정해야 한다.
라운드트립 버킷 보존 테스트(test_review_fixes.py)는 신뢰도 1.0 에서 두 엔티티가
모두 캡에 붙어 성질이 가려졌다. 검증 대상은 점수가 아니라 엔티티 이름 버킷이
직렬화를 넘어 살아남는가이므로, 풀 아래(신뢰도 0.2)에서 재작성하고 동일 엔티티
반복이 여전히 1건으로 접히는지도 함께 본다.
테스트 5건 추가. pytest 570 passed(착수 전 565), 린트 클린.
"이 도구가 실제 업무에 도움이 되는가"를 6축으로 조사하고 축마다 결론을
반증시켰다(docs/reviews/2026-08-08-utility-assessment.md). 결론은 "검색·기록
노동은 줄여주나 심사 건수는 못 줄인다"이고, 그 과정에서 실행으로 확정된
P0 결함 4건을 여기서 고친다. 판별력 붕괴(P1)는 별도 작업이다.
폴더 정리가 판정 기록을 지웠다 (sqlite_store.py)
_prune_missing_submission_files 가 원본 파일이 없는 submission 행을 판정
여부와 무관하게 delete 했고, foreign_keys=on 이라 evidence 가 cascade 로
함께 사라졌다. 심사 끝난 이미지를 아카이브로 옮기는 평범한 운영 행위가
승인/반려를 DB 와 내보내기 양쪽에서 지운다. 실증: rejected 판정 후
export 1행 -> 파일 제거 -> submissions 0행 / evidence 0행 / export 0행.
판정된 케이스는 파일이 없어도 보존하고 assetMissing 마커를 남긴다. 마커가
필요한 이유는 이 스윕이 매 리로드마다 돌기 때문이다 — 표시 없이 보존만
하면 같은 감사 이벤트가 리로드마다 쌓여 500행 캡을 먹는다.
비상 차단 스위치가 아무것도 막지 않았다 (store_enrichment.py)
emergency_disable_external_providers 는 DB 의 enabled/operatorDisabled 만
쓰는데 자동 보강 경로가 그 플래그를 아예 읽지 않았다. 게이트가 걸린 곳은
수동 검색뿐이라, 버튼을 눌러도 폴더 리로드·업로드·rerun-enrichment 가
그대로 Naver/Google 로 나갔다. 스텁 어댑터 대조실험에서 CONTROL 5회 /
차단 후 5회로 완전히 동일했다.
_external_calls_blocked(provider_id) 를 신설해 자동 외부 호출 5개 경로에
배선했다: auto naver, auto CSE, rerun Vision, 얼굴 크롭 웹탐지, 시드 배치
(후자는 ExternalApiPolicy(disabled=True) 로 전환).
enabled 가 아니라 operatorDisabled 를 본다. enabled 는 연결성/헬스에도
반응하므로 운영자가 멈추라고 한 적 없는 트래픽까지 죽인다. 얼굴 크롭은
생체 파생물을 전송하므로 상위 게이트에 의존하지 않고 독립 게이트를 건다.
생체 크롭이 보존기간을 넘겨 살아남았다 (store_backup.py)
스냅샷이 face-crops 를 통째로 담는데 프루닝은 나이가 아니라 개수 10개
기준이라, 90일에 파기됐어야 할 크롭이 암호화 없는 zip 안에 남았다. 복구는
더 나빴다 — copyfileobj 로 새로 쓰므로 mtime 이 리셋되고, purge 가 mtime 을
보므로 파기 대상이 복구 직후부터 다시 90일을 살았다.
스냅샷에서 제외하고, 복구 시에도 레거시 아카이브의 크롭을 건너뛴다. 크롭은
원본에서 재분석으로 재생성되므로 손실 비용이 없다.
오프라인 설치 문서가 계약 위반 모델을 지목했다 (offline-install.md)
qwen2.5:0.5b-instruct 반입을 지시했는데, 같은 리포가 이 모델을 55.7초 +
프롬프트 형식 예시 반향(출력 계약 위반)으로 기록해 두고 기본값을 7b 로
고정해 뒀다. 문서대로 반입하면 타깃에서 요약이 조용히 죽는다. 모델명을
정정하고, 반입물 목록에 없던 ollama 바이너리와 GPU 전제를 추가했으며,
"env 를 비우면 LLM 없이 돈다"는 서술을 실측으로 정정했다 — 실제로는
127.0.0.1:11434 로 폴백해 provider 가 enabled=True 로 보고된다.
회귀 테스트 3건 추가. pytest 565 passed(착수 전 562), 린트 클린.
세션 진입 문서가 없어 41.6k 라인 · 70모듈 구조를 매번 재발견하고 있었다.
- CLAUDE.md: 진입점 + 이 프로젝트에만 해당하는 규칙(폐쇄망 의존성 금지,
app-*.js 로드 순서 계약, SCORER_VERSION 갱신 의무, 직렬화 라운드트립 불변식,
LLM 은 실모델로 프로브, cp949 비ASCII 출력 주의)
- docs/PROJECT_MAP.md: 파일·라우트·스키마 위치, app-*.js 로드 순서, 알려진 부채
- README: verify 명령, app-*.js 구조, 인증 스로틀 동작 설명
7/11 리메디에이션 체크리스트를 코드와 대조해 갱신했다. 미체크 항목 중 6건은
이미 수정돼 있었고(naver 멀티페이지 쿼터, #10 Origin/Referer CSRF, env_file
BOM, daily-limit fail-open, __main__ 경로 앵커링, 그리고 Batch 8 전체가
Batch 6 과 중복) 각 줄에 확인 근거를 남겼다. 남은 미체크는 전부 근거가 기재된
명시적 연기다.
실모델 프로브에서 인용 검증만으로는 못 잡는 실패 모드가 드러났다.
## 형식 예시 반향(template echo)
qwen2.5:0.5b 는 프롬프트의 형식 예시를 그대로 돌려주면서(claim text 가
"<한국어 문장>") 실제 라벨 12개를 전부 인용했다. 집합 포함 검사는 이것을
완벽히 통과시킨다 — 인용은 전부 진짜이기 때문이다. 결과적으로 완전히 비어
있는 출력이 "근거 있음" 판정을 받았다.
그라운딩 검증은 "인용이 진짜인가"와 "내용이 진짜인가"를 둘 다 봐야 한다.
형식 예시 문자열을 llm_prompts 의 상수로 두고 그 반향을 거부한다. 앵글
브래킷으로 감싼 다른 스탠드인도 같은 실패로 취급한다.
가짜 transport 테스트로는 이 결함을 잡을 수 없었다 — 스크립트된 응답은
언제나 잘 만들어진 JSON 이기 때문이다.
## 기본 모델
저장된 실제 증거(제출물 #3, 54행 중 12행 선별, 프롬프트 1,507자)로 GPU
타깃에서 측정:
qwen2.5:0.5b-instruct 55.7s 형식 예시 반향, 계약 위반
qwen2.5:7b 8.8s 계약 준수, claim 2 + 확인필요 1 <- 채택
qwen3:8b 35.7s 계약 준수, thinking 모델이라 4배 느림
3b 는 빌드 머신에 없고 7b 는 이미 있어 에어갭 반입 비용이 0 이다. 브레인스토밍
문서의 "7B 는 인터랙티브 불가" 는 CPU 전제였고 이 배포에는 해당하지 않는다.
pytest 517 passed.
두 갈래의 작업이 한 커밋에 들어 있다. llm_assistance.py 에서 T0-4 가 앞선
작업의 프롬프트 수정을 대체했기 때문에(프롬프트 리터럴이 llm_prompts.py 로
이동), 분리하려면 실제로 존재한 적 없는 중간 상태를 만들어야 한다.
## (1) 앞서 진행 중이던 review-intelligence 작업
- decision_stats(): 위험밴드 x 실제판정 교차표 + 캘리브레이션 지표
- cleared_reference 지식엔트리 타입: 이전에 클리어된 이미지 매칭은 +80 이
아니라 0점 긍정 신호
- LLM 요약 본문 영속화(_evidence_payload 에 summary/sourceUrls) — 그전까지
요약이 저장되지 않아 운영자에게 한 번도 보인 적이 없었다
- 운영자 GUI 반영
## (2) 실사용 투입 전 T0 — 첫 판정 이후에는 소급 불가한 것들
- T0-1 initialRiskScore/initialRiskBand/scorerVersion 각인.
_rescore_submission 이 12곳에서 riskScore 를 덮어쓰므로 저장된 점수는 늘
왕복 점수였고, 그것을 재채점과 비교하는 테스트는 항상 통과하는 빈 테스트다.
레거시 행은 scorerVersion="legacy" 로 표시만 하고 점수를 날조하지 않는다.
- T0-2 얼굴검출 Haar -> YuNet, 인물 등급(identifiable/background) 도입.
기존의 평평한 +35 는 사람이 찍힌 모든 사진을 medium 문턱 위로 올려 밴드
분포를 붕괴시켰다(실측 high 4 / medium 2 / low 0). 등급은 payload 라운드
트립으로 보존한다 — 잃으면 재채점마다 조용히 +35 로 되돌아간다.
가중치는 models/(gitignore) 에 두고 offline-install.md 에 sha256 반입 절차.
가중치가 없으면 Haar 로 강등하고 1회만 경고한다.
- T0-3 판정 시점 피처 스냅샷. 큐가 riskScore 내림차순이고 화면이 점수를 먼저
보여준 뒤 판정을 받으므로, 스냅샷 없이 모은 라벨은 "이 근거가 반려를
예측한다"가 아니라 "운영자가 내가 보여준 점수에 동의했다"를 기록한다.
- T0-4 모델/프롬프트 버전 + latency_ms 스탬프. latency_ms 는 _evidence_id
해시에서 제외한다 — 포함하면 같은 요약이 재생성될 때마다 id 가 바뀐다.
## (3) 임베딩 저장 금지 정책 개정
금지의 취지는 생체 식별이지 이미지 유사도가 아니므로 범위를 좁힌다.
장면 임베딩(전체 이미지 의미 벡터)을 이미지 유사도 판정에 한해 허용하되
얼굴 마스킹 / 인물 지배 프레임 제외 / 목적 제한 / 별도 저장 클래스 /
연쇄 삭제 5조건을 assert_scene_embedding_allowed 로 강제한다. 마스킹 증명이
없으면 거부한다 — 누락은 마스킹을 건너뛴 것과 구별할 수 없다.
얼굴 임베딩 금지는 landmarks/face_descriptor/face_encoding 추가로 강화.
pytest 502 passed (착수 전 463).
- Add the 2026-07-24 multi-agent review report (43 confirmed findings, runtime
smoke, feature proposals with judge scores) and the implementation checklist
tracking what was done vs. deliberately deferred (with reasons).
- Record the batch-decision decision: the v1 "no bulk approve/reject" GUI-spec
restriction is revised, not silently overridden, and lists the guardrails that
made lifting it acceptable.
- Fix the README `python -m rights_filter.server` invocation (needs
PYTHONPATH=src) and start a docs/INDEX.md continuity log.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E6GD9gxUtfUiVB3JHejGpU
- Add the 2026-07-11 multi-agent project-review report and the remediation
checklist (per-item status, with deferred items and their rationale).
- offline-install: document Ollama model and Playwright Chromium transfer, a
hash-verified lock, --only-binary, and correct the egress note (image
comparison fetches arbitrary SSRF-guarded public URLs, not only API hosts).
Add requirements.txt (numpy/opencv-python-headless/pillow — the only
third-party runtime imports) and requirements-dev.txt, plus an offline
install runbook. Ignore .coverage and wheelhouse/.
- Bundle Pretendard Variable woff2 locally (air-gapped safe, no CDN)
and switch UI/stamp font stacks to it; preload in index.html
- Replace the forensic-dossier paper theme with a flat neutral cool
palette: single teal accent, white cards, no noise texture, and
zero linear/radial gradients (per design contract)
- Restore the product-purpose top-bar block and its CSS, drop the
unused global search form, and strip the stray UTF-8 BOM
- Re-skin queue hover/selection, eyebrows, nav rail, chips, and
empty states to the neutral palette; tabular numerals for numbers
- Regenerate ui-overhaul final audit artifacts: zero horizontal
overflow across 8 views at 1440x900 and 390x844, Pretendard active
Design spec: docs/superpowers/specs/2026-06-11-operator-console-clean-review-ui-design.md
Plan: docs/plans/2026-06-11-001-feat-operator-console-clean-review-ui-plan.md
Tests: 358 passed (full suite incl. browser smoke)
Image rights / copyright detection system: SQLite store, HTTP app,
search integrations (Naver, Google Custom Search, Google Cloud Vision
web detection), image analysis (fingerprints, face/person detection,
evidence enrichment, risk scoring), an admin/review layer, governance
and retention policies, batch jobs, and a browser-based operator GUI.
This baseline incorporates a full code-review remediation pass
(46 fixes; 358 tests passing). Highlights:
CRITICAL
- Prevent evidence cascade-delete during the schema-constraint
migration by disabling FK enforcement around the table rebuild.
Security
- Sandbox served media (neutralize stored XSS from uploaded/collected
SVGs) via CSP + nosniff on the untrusted media routes.
- Strip embedded EXIF/GPS from external image derivatives before they
are sent to third-party APIs.
- Return a clean 404 (not an uncaught StopIteration) for PATCH on an
unknown provider.
Correctness
- LLM-summary failures no longer add +30 to the risk score.
- Decode only explicit JS escapes so Korean image URLs are not mangled.
- Consume search quota only after a successful request.
- Naver/Google adapters map responses inside the failure boundary, so a
malformed response degrades to evidence instead of crashing enrichment.
- Domain-aware provider attribution; face-box IoU de-duplication; count
searches (not result items); per-box crop isolation; clamp evidence
confidence and Google CSE num; real submittedEpoch; and more.
Robustness
- Offline LLM connect fast-fails (short connect timeout) so seed/reload
requests are not stalled; full read timeout preserved for generation.
- Malformed numeric env vars fall back to defaults instead of crashing
startup.
Performance
- Per-submission evidence reads (no full-table scan per rescore),
audit-log LIMIT, lazy active-store lookup, hoisted timestamps.
Tests
- ~24 regression tests added pinning the above fixes.
Runtime data (data/, outputs/, *.sqlite3, *.log), secrets (.env), and
node_modules are gitignored.
