Backend / Auth / RBAC

역할 선택 mock boundary와 실제 인증 결정 분리

현재 APP은 로그인 제품이 아니라 Figma-first 화면 검증을 위한 role onboarding으로 시작합니다. 이 리포트는 지금 검증된 앱 boundary와 실제 Kotlin Spring auth/RBAC에서 결정해야 할 영역을 분리해 보여줍니다.

Current: onboarding role selection Covered: invalid role fallback Decision: auth provider / multi-role account
Role entry

Covered

테스트 온보딩에서 배출자, 배차담당자, 운전자, 처리자로 진입합니다.

Invalid role

Covered

잘못된 role route는 안전한 fallback 화면으로 돌아옵니다.

RBAC UI

Boundary only

실제 권한 승인 전까지 mock role boundary로만 다룹니다.

Backend

Decision

session/token, multi-role account, authorization policy는 아직 Open Decision입니다.

현재 검수 가능한 흐름

1

앱 실행

onboarding.role-select.screen에서 4개 role 진입 버튼을 확인합니다.

2

역할별 홈

선택한 role은 각 role home으로 이동하고, role별 bottom tab/CTA를 노출합니다.

3

잘못된 role route

role.invalid.screen은 온보딩 복귀 CTA로만 수렴합니다.

4

실제 auth 대기

로그인, 세션, multi-role 승인, backend authorization은 APP mock 범위 밖으로 유지합니다.

화면 evidence

앱 role onboarding
Role onboarding

테스트를 위한 4개 role 진입점.

ad hoc role selector
Ad hoc selector

초기 진입과 E2E bootstrap의 기준 화면.

invalid role screen
Invalid role

잘못된 route boundary의 fallback 화면.

invalid role fallback maestro evidence
Invalid role Maestro

fallback flow after screenshot.

dispatcher role home
Dispatcher home

role 선택 이후 분리된 홈 surface.

processor role home
Processor home

role별 UI 분리의 예시.

Open decision으로 남기는 이유

결정 항목APP에서 지금 하는 일후속 계약 필요 항목
auth provider구현하지 않음. role onboarding으로 화면 검증.provider, redirect/handoff, token/session 저장 정책.
multi-role account단일 앱에서 role route만 분리.한 계정이 여러 role을 가질 때 승인/전환 정책.
RBACrole별 UI 노출과 invalid role fallback만 검증.backend authorization, forbidden envelope, audit policy.
server datamock API/fixture를 화면 계약으로 사용.Kotlin Spring endpoint, status enum, pagination/permission shape.