3f7b3a9cf2
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.
69 lines
2.4 KiB
Markdown
69 lines
2.4 KiB
Markdown
# Insufficient Evidence Query Suggestions
|
|
|
|
## Problem
|
|
|
|
Operators can reach a case where external search has run, but the evidence is still too thin to make a confident approval, hold, or rejection decision. Today the console shows raw evidence and query history, but it does not suggest a concrete next action when the evidence is insufficient.
|
|
|
|
## Goal
|
|
|
|
Add a lightweight workbench guide that detects insufficient evidence and generates safe follow-up query suggestions. The system must not run external searches automatically. It should only prepare likely useful queries and let the operator decide whether to execute one.
|
|
|
|
## User Experience
|
|
|
|
When the selected case has weak or sparse evidence, the evidence workbench shows a "근거 보강 추천" panel above the evidence groups. The panel explains that the current evidence is insufficient and shows a few suggested Naver query buttons.
|
|
|
|
Clicking a suggestion:
|
|
|
|
- switches to the workbench query tab;
|
|
- fills the existing manual query input;
|
|
- selects the normalized operator search provider;
|
|
- leaves execution to the operator through the existing submit button.
|
|
|
|
If evidence is already sufficient, the panel stays hidden.
|
|
|
|
## Evidence Sufficiency Rule
|
|
|
|
The first version uses a conservative client-side heuristic:
|
|
|
|
- direct image/page matches are strong evidence;
|
|
- Naver or Google searchable evidence is supporting evidence;
|
|
- a case is insufficient when it has no strong direct match or has fewer than two searchable evidence items;
|
|
- query suggestions are only shown when there is at least some indication that search has run, such as query history, provider state, or searchable evidence.
|
|
|
|
This avoids blocking decisions and avoids adding backend state.
|
|
|
|
## Query Generation
|
|
|
|
Suggestions are generated from the selected submission title and deduplicated against existing query history. The initial templates are:
|
|
|
|
- title
|
|
- title + " 저작권"
|
|
- title + " 공식"
|
|
- title + " 이미지 출처"
|
|
|
|
The list is capped at four suggestions.
|
|
|
|
## Scope
|
|
|
|
In scope:
|
|
|
|
- static operator GUI markup, script, and styles;
|
|
- client-side insufficient evidence assessment;
|
|
- query suggestion rendering;
|
|
- click behavior that fills the manual query form;
|
|
- static tests for the UI contract.
|
|
|
|
Out of scope:
|
|
|
|
- automatic external search execution;
|
|
- backend API changes;
|
|
- hard decision blocking;
|
|
- machine-learned query generation.
|
|
|
|
## Verification
|
|
|
|
Run the operator static suite:
|
|
|
|
```powershell
|
|
python -m pytest tests\operator_gui\test_static_workbench.py
|
|
```
|