# Product Scope

| Metadata | Value |
|---|---|
| Status | Active |
| Owner | APP/기술 기준: 주우철 · Web/PC/backend/관측성: 정정일 |
| Last verified | 2026-07-10 KST |
| Supersedes | 2026-07-10 `MVP Scope` planning baseline |

이 문서는 ZERRO의 지속적인 제품 기능 범위를 Must/Should/Later로 정의한다. 기준 자료는 `ZERRO_Functional_Spec.xlsx`와 현재 Figma inventory다. Must/Should/Later 변경 시 관련 role 담당자와 mock API 영향 범위를 같이 확인한다.

현재 구현 상태와 다음 작업은 [`docs/70-progress/CURRENT.md`](../70-progress/CURRENT.md), 2026-07-10 시점의 구현·연결·검증 결과는 [`docs/70-progress/milestones/2026-07-10.md`](../70-progress/milestones/2026-07-10.md)에서 관리한다. 이 문서는 날짜별 완료 결과를 소유하지 않는다.

중요: Product Scope는 UI 품질을 최소 기능 수준으로 낮추는 문서가 아니다. 구현하는 APP/Web/PC 화면은 가능한 범위에서 production-level UI 후보로 만든다. UI 품질 목표, gate, 미흡한 부분은 [UI Production Readiness](UI_PRODUCTION_READINESS.md)를 따른다.

## Authority and References

1. `.specify/memory/constitution.md`
2. `docs/README.md`
3. 이 문서
4. `docs/10-product/FIGMA_INVENTORY.md`
5. `docs/60-requirements/`
6. `ZERRO_Functional_Spec.xlsx`

## Source Baseline

| Source | 내용 |
|---|---|
| `ZERRO_Functional_Spec.xlsx` | 사용자 매뉴얼 기반 기능명세 Draft v1 |
| `00_README` | 8개 문서, 419p, 기능성 분석 386p, 기능 그룹 179개, 역할 4개, 플랫폼 2개 |
| `02_기능명세_요약` | 179개 기능 그룹, role/platform/menu/action/dependency/source page |
| `03_화면인벤토리_페이지별` | 387개 page inventory row |
| `04_역할x기능매트릭스` | 100개 정규화 기능명과 7개 role-platform surface |
| `05_업무라이프사이클` | 12단계 업무 lifecycle |
| `docs/10-product/FIGMA_INVENTORY.md` | 구현 기준 Figma Page/Frame node |
| `docs/80-artifacts/figma/` | 2026-06-25 MCP refresh 기준 역할별 APP/PC reference screenshot과 icon board export |

## Historical Figma Visual Evidence Baseline

2026-06-25 Figma MCP refresh에서 사용자 제공 APP/PC/icon node를 직접 조회했다. 아래 표는 2026-07-10 planning baseline에서 사용한 화면 구조와 visual QA 기준을 보존하며, 현재 API shape 변경 근거는 아니다. 최신 구현 기준 node는 [Figma Inventory](FIGMA_INVENTORY.md), production-level UI 목표는 [UI Production Readiness](UI_PRODUCTION_READINESS.md)에서 관리한다.

| Surface | Node | Visual reference | 2026-07-10 planning baseline |
|---|---:|---|---|
| 배출자 APP | `112:1075` | `docs/80-artifacts/figma/112-1075/reference/overview.png` | 배출 현황, 배출 상세 상태, 반입 확인서 흐름 |
| 배차담당자 APP | `213:1232` | `docs/80-artifacts/figma/213-1232/reference/overview.png` | 배차 현황 metric, 배차하기, 반입 확인서, 협업 채팅 |
| 운전자 APP | `236:403` | `docs/80-artifacts/figma/236-403/reference/overview.png` | 배차 확인, 오늘 일정, 상차/하차 action, 담당자 연락 |
| 처리자 APP | `236:1859` | `docs/80-artifacts/figma/236-1859/reference/overview.png` | 입고/계근/승인 현황, 계근 등록, 사진 촬영, 처리 목록 |
| 채팅방 APP | `356:988` | `docs/80-artifacts/figma/356-988/reference/overview.png` | lifecycle card, 검색, 프로필/긴급 연락처 |
| 배출자 PC | `279:3813` | `docs/80-artifacts/figma/279-3813/reference/overview.png` | 배출자 dashboard, 배출 현황 calendar, 알람/채팅 side panel |
| 배차담당자 PC | `778:2203` | `docs/80-artifacts/figma/778-2203/reference/overview.png` | 배차 dashboard, 반입 의뢰서, 운반 관리, 차량 이력 |
| 처리자 PC | `838:1656` | `docs/80-artifacts/figma/838-1656/reference/overview.png` | 처리 dashboard, 계근 등록, 처리 실적, 올바로 전송 확인 |
| Icon set | `768:7677` | `docs/80-artifacts/figma/768-7677/ui/icon-board.svg` | APP/PC icon inventory 기준. Runtime import는 구현 PR에서 별도 확정 |

## Scope Principles

- Product Scope는 날짜별 완료 선언이 아니라 제품 기능의 지속적인 우선순위와 구현 경계를 관리한다.
- Must/Should 화면과 API 계약은 mock API first 기준으로 구체화하고 backend 구현으로 승격한다.
- Product Scope는 기능 scope 용어다. UI는 `빠르게 만든 임시 화면`이 아니라 production-level UI 후보를 목표로 한다.
- 기능 수가 많은 PC surface는 전체 기능을 한 번에 구현하지 않고 대표 lifecycle 검수 흐름에 필요한 화면부터 자른다.
- 회원가입, 권한 승인, 정산, 올바로 연계는 화면 진입과 상태 표현을 우선하고, 실제 provider/API 연동은 관련 계약과 운영 gate에서 확정한다.
- 모든 Must/Should 화면은 loading, empty, error, permission denied, success 상태 중 해당되는 상태를 가진다.

## Workbook Distribution

`02_기능명세_요약` 기준 기능 그룹 분포다.

| Role | Platform | 기능 그룹 수 | 주요 메뉴 |
|---|---|---:|---|
| 배출자 | APP | 18 | 관리, 배출, 로그인, 통계, 회원가입 |
| 배출자 | PC | 29 | 계약/정산/신고, 배출, 기본화면, 데이터/통계 |
| 배차담당자 | APP | 16 | 수집/운반, 관리, 로그인, 통계, 회원가입 |
| 배차담당자 | PC | 38 | 배차, 계약/정산/신고, 기본화면, 데이터/통계 |
| 운전자 | APP | 20 | 수집/운반 업무, 업무 예외, 로그인, 부가기능 |
| 처리자 | APP | 20 | 수집/운반, 관리, 처리, 로그인, 통계 |
| 처리자 | PC | 38 | 배차, 계약/정산/신고, 기본화면, 처리/통계 |

`수집/운반자`는 구현 문서에서 `배차담당자`로 부른다. 운전자는 별도 역할과 별도 앱 경험으로 유지하되, 실제 scaffold는 단일 Expo 앱 안의 별도 role route로 시작한다.

## Must / Should / Later

### Must

핵심 역할별 lifecycle과 제품 계약에 반드시 포함한다.

| Surface | Figma 기준 | Must 범위 | 대표 workbook 근거 | 담당 |
|---|---|---|---|---|
| 공통 온보딩/권한 | role별 로그인/관리 화면 | 자체 JWT 로그인/session restore/보유 role context, 사업자 조회·약관·담당 업무·사용자 승인 상태 UI. production 가입 승인·문자 인증·외부 auth provider는 later | lifecycle 1, 2, 회원가입 10개 기능 | 공동 |
| 배출자 APP | `배출자 app(112:1075)` | 배출 현황, 배출 신청, 배출 상세, 반입확인서 진입, 올바로 신고/미신고 표시 | 배출자 APP 18개 기능, 배출 메뉴 6개 | 주우철 |
| 배차담당자 APP | `배차 담당자 app(213:1232)` exact child Frames | 미배차/배차완료 현황, 배차하기, 배차 현황, 반입확인서 진입 | 수집/운반자 APP 16개 기능, 수집/운반 메뉴 8개 | 주우철 |
| 운전자 APP | `운전자 app(236:403)` exact child Frames | 오늘 운반건, 업무 시작/종료, 차량 선택, 경로 안내, 사진 등록, OCR 계근, 예외 상태 | 운전자 APP 20개 기능, 업무/예외 11개 | 주우철 |
| 처리자 APP | `처리자 app(236:1859)` exact child Frames | 입고/계근/승인 현황, 계근 등록, OCR 업로드, 입고 확인/승인, 처리 실적 진입 | 처리자 APP 20개 기능, 처리 메뉴 4개 | 주우철 |
| 채팅방 APP | `채팅방 app(356:988)` exact child Frames | 채팅 목록, 채팅 검색, lifecycle event card, 긴급 메시지 표시 | lifecycle 8 관제/현황, notification requirements | 공동 |
| 배차담당자 PC | `배차담당자 PC(778:2203)` | 미배차/배차완료 지표, 배차하기, 운반관리, 차량/운전자 할당, 배차 취소 상태 | 수집/운반자 PC 38개 기능, 배차 메뉴 15개 | 정정일 |
| 처리자 PC | `처리자 PC(838:1656)` | 입고 예정, 계근 대기, 신고 대기/완료, 계근 등록, 처리 실적 | 처리자 PC 38개 기능, 배차 13개, 처리/통계 5개 | 정정일 |
| 배출자 PC | `배출자 PC(279:3813)` | 배출 신청, 배출 현황, 계약 조회, 정산/증빙 조회, 사업장 기본 현황 | 배출자 PC 29개 기능, 계약/정산/신고 12개 | 정정일 |

### Should

Must 흐름을 닫은 뒤 우선 확장한다.

| 범위 | 이유 |
|---|---|
| 사용자 권한 관리의 목록/승인 상태 | workbook 전 role에서 반복되며 RBAC 검증에 필요 |
| 계약 등록/갱신 상세 form 일부 | 배출 신청/반입의뢰서가 계약 데이터에 의존 |
| ZERRO 리포트 다운로드 진입 | 배출자/처리자/배차담당자 통계 흐름의 공통 진입 |
| 정산서/거래내역 목록 | PC role에서 반복되는 핵심 확인 업무 |
| 올바로 오류/신고 상태 표시 | 실제 연동은 later지만 규제 대응 UI가 핵심 가치 |

### Later

현재 Must/Should 구현에서 제외하거나 read-only placeholder로 둔다. placeholder는 숨기지 않고 disabled reason, empty state, UX flow index, PR note 중 하나로 사용자가 인지할 수 있게 표시한다.

| 범위 | 제외 이유 |
|---|---|
| production 가입 승인/문자 인증/외부 auth provider | 자체 JWT login/signup endpoint와 APP session binding은 존재하지만 운영 가입 승인, 문자 인증, 외부 provider flow는 later |
| production 올바로 API 연동 | Open API protocol mapping과 local adapter는 존재하나 테스트 계정, HALF MODE 실측, 운영 credential이 미확정 |
| production OCR engine 연동 | local fake OCR과 Google Cloud Vision smoke는 존재하나 production credential/runtime adapter, benchmark, confidence threshold가 미확정 |
| 정산 다운로드 파일 생성 | backend 저장소/파일 정책과 연결 |
| production monitoring provider | UI 품질과 별개로 배포/운영 단계에서 provider와 alert ownership 결정 |
| offline 저장/재전송 | 운전자 proof queue 대상·한도·복구·충돌 정책은 승인됐고, `expo-sqlite`/app-private file 구현과 process-death·실기기 검증은 pending |

## Representative Review Flow

Product Scope는 아래 역할 간 흐름을 한 번에 설명할 수 있어야 한다.

1. 배출자가 배출 신청을 만들고 올바로 신고/미신고 상태를 확인한다.
2. 배차담당자가 미배차 요청을 보고 운전자/차량을 배정한다.
3. 운전자가 오늘 운반건에서 업무를 시작하고 사진/OCR 계근을 등록한다.
4. 처리자가 입고/계근을 확인하고 처리 실적 또는 처리확인서 흐름으로 진입한다.
5. 채팅방에는 신청, 배차, 하차, 리포트/처리 상태가 lifecycle card로 남는다.
6. PC 화면에서는 동일 handover가 배출자, 배차담당자, 처리자 관점에서 다르게 보인다.

## Mock API Baseline Checklist

- Surface별 Must 화면이 mock fixture로 동작한다.
- workbook lifecycle 12단계 중 Product Scope가 다루는 단계가 endpoint 또는 placeholder로 추적된다.
- 모든 주요 action은 mock endpoint 또는 local event handler를 가진다.
- role별 visible/hidden/disabled 상태가 `docs/10-product/RBAC_MATRIX.md`와 맞는다.
- mock response는 schema parse를 통과한다.
- Playwright와 AI Computer Use로 핵심 검수 흐름을 확인한다.
- 기준선 이후 contract 변경은 PR 본문에 변경 이유와 영향 surface를 적는다.
- UI 품질 미흡 또는 placeholder는 `docs/10-product/UI_PRODUCTION_READINESS.md`와 role별 coverage 문서에 남긴다.

## Open Decisions

- Must 화면 중 실제 demo 순서와 발표 강조점
- APP store/build 분리를 실제로 해야 하는지 여부. 현재 Product Scope는 단일 Expo 앱 기준이다.
- 실제 가입, 초대, 비밀번호 찾기와 OAuth/SMS/SSO provider 범위
- multi-company active context, `duties[]` enum과 role별 업무 조합, 업체 관리자 승인 권한 범위
- production realtime broker topology, replay/idempotency, Expo Push delivery/receipt/retry와 production credential, 알림 탭의 role/session 복구
- production media/document signed URL, retention/deletion, OCR provider benchmark

## Change Control

- Must 범위에서 기능을 빼려면 `docs/70-progress/CURRENT.md`와 PR 본문에 이유를 남긴다.
- Should 범위를 Must로 올리면 관련 mock endpoint와 RBAC row를 같이 추가한다.
- Later 범위는 구현하지 않더라도 화면 placeholder나 disabled reason이 필요한지 확인한다.