Processor App / 처리자

입고 승인, 계근 OCR, 처리 실적의 backend boundary

처리자 flow는 APP mock 기준으로 입고 예정, 상세, 계근 등록, OCR 확인, 처리 실적 등록까지 이어집니다. 이 리포트는 현재 화면에서 확인 가능한 mock UX와 아직 Kotlin Spring/API 계약이 필요한 backend boundary를 분리합니다.

Entry: processor.home.section-detail.cta Maestro: processor-inbound / processor-weighing Status: APP mock covered, backend pending
Inbound approval

Mocked

입고 예정 목록, 상세, 승인 CTA, conflict notice가 APP surface에 있습니다.

Weighing OCR

Mocked

provider-pending, error/offline/retry, OCR 확인/수정 flow가 노출됩니다.

Treatment result

Mocked

처리 실적 등록과 duplicate/replay guard가 화면에서 설명됩니다.

Backend contract

Pending

conflict envelope, idempotency persistence, upload/OCR parsing은 후속 계약입니다.

검수용 UX 흐름

1

입고 예정 목록

processor.inbound.screen에서 오늘 입고 대상과 lifecycle-projected 건을 확인합니다.

2

입고 상세 / 승인

processor.inbound.detail.screen에서 입고 정보, conflict notice, replay guard를 확인합니다.

3

계근 OCR

processor.weighing.ocr.provider.* 상태가 provider 연결 전에도 사용자에게 숨겨지지 않습니다.

4

처리 실적

실제 backend idempotency 전까지 processor.backend.idempotency.pending과 duplicate guard로 설명합니다.

화면 evidence

처리자 입고 replay guard
Replay guard

중복 처리와 idempotency pending을 APP mock으로 설명합니다.

처리자 OCR provider pending
OCR pending

실제 OCR provider 없이도 pending state를 분리합니다.

처리자 OCR provider offline
OCR offline

현장 네트워크 불안정 시 offline branch를 표시합니다.

처리자 OCR 확인
OCR confirm

mock OCR 결과를 확인/수정하는 화면입니다.

처리 실적 완료
Treatment result

처리 실적 등록 완료 이후 lifecycle projection을 설명합니다.

processor inbound maestro after flow
Maestro after-flow

입고 flow deterministic proof의 마지막 화면입니다.

계약 분리

영역현재 APP 상태후속 backend/provider 결정
입고 승인 conflictprocessor.inbound.conflict.notice, empty/replay guard 노출Kotlin Spring conflict envelope, retry/replay response shape
계근 OCRprocessor.weighing.ocr.provider.pending/offline, retry/offline CTAOCR engine, upload body, parsing confidence schema
처리 실적 등록processor.backend.idempotency.pending, duplicate guard messageidempotency key persistence, duplicate submit response
파일/증빙provider-pending read-only UIS3/presigned upload, signed URL TTL, file viewer 권한