# Unit of Work Plan — CMS Frontend

## Context
Unit decomposition is derived directly from the Workflow Planning and Application Design stages. No additional questions are needed — all decomposition decisions were already made:
- **Decomposition approach**: Sequential units ordered by dependency (infrastructure → auth → layout → features)
- **Team alignment**: Single developer — no cross-team boundaries needed
- **Technical considerations**: All units deploy as one SPA + one backend API
- **Code organization**: Monorepo-style, `frontend/` at solution root

## Planning Checklist
- [x] Context analyzed (execution-plan.md + application-design.md)
- [x] Unit boundaries confirmed by user (via Workflow Planning approval)
- [x] Story-to-unit mapping defined
- [x] unit-of-work.md generated
- [x] unit-of-work-dependency.md generated
- [x] unit-of-work-story-map.md generated

## Unit Definitions
| Unit | Name | Scope |
|------|------|-------|
| 0 | Backend Prerequisites | .NET backend changes: CORS, httpOnly cookie, TokenResponse DTO with `name` |
| 1 | Project Scaffold & Infrastructure | Vite init, TanStack Router, shadcn/ui, Tailwind v4, ApiClient, AuthContext, ThemeProvider, ErrorBoundary, .env |
| 2 | Authentication Pages | LoginPage, SetupPage, InviteCompletePage, ProtectedRoute, RoleGuard, InitGuard |
| 3 | Layout & Navigation | AppLayout, Sidebar (role-filtered), responsive layout |
| 4 | Dashboard | DashboardPage, AvailabilityStatusBadge, useAvailabilityStatus |
| 5 | User Management | UsersPage, InviteUserDialog, useUsers, useInviteUser, useValidateInvitation, useCompleteSetup |
| 6 | Remaining Pages & Docs | ProfilePage, SettingsPage, CmsPage, NotFoundPage, AccessDeniedPage, README.md frontend section |