# Functional Design Plan — Unit 6: Profile, Settings & CMS Placeholder

**Status**: 🚧 In Progress

## Unit Context

**Unit**: Unit 6 — Profile, Settings & CMS Placeholder
**Type**: Frontend (React/TypeScript) + Documentation
**Depends on**: Unit 3 (AppLayout, RoleGuard), Unit 4 (useAvailabilityStatus, AvailabilityStatusBadge)
**Stories Covered**:
- US-15: View own profile
- US-16: View availability status in settings
- US-17: Access denied to System Settings for non-Owners
- US-20: View CMS management placeholder

**Key Deliverables** (from unit-of-work.md):
```
frontend/src/routes/
├── profile.tsx               # ProfilePage: read-only user info
├── settings.tsx              # SettingsPage: Owner-only, availability + placeholders
├── cms.tsx                   # CmsPage: Owner-only placeholder
├── 403.tsx                   # AccessDeniedPage
└── $404.tsx                  # NotFoundPage

README.md                     # Frontend Development section added
```

**Key Observations**:
- These are the final frontend pages; all shared infrastructure (ApiClient, AuthContext, AppLayout, RoleGuard) is already in place
- `useAvailabilityStatus` from Unit 4 can be reused directly in SettingsPage
- RoleGuard (from Unit 2) is already implemented; `/settings` and `/cms` need Owner-only guards
- The 403 and 404 pages can be pure presentational components (no data fetching)
- Routes `403.tsx` and `$404.tsx` need to be registered in the TanStack Router route tree

---

## Functional Design Steps

- [x] Step 1: Analyze unit context and existing code patterns
- [x] Step 2: Generate questions, collect answers
- [x] Step 3: Create `domain-entities.md`
- [x] Step 4: Create `business-rules.md`
- [x] Step 5: Create `business-logic-model.md`
- [x] Step 6: Create `frontend-components.md`
- [x] Step 7: Present completion message and await approval

---

## Questions

Please fill in the letter after each `[Answer]:` tag.

---

### Question 1: ProfilePage — displayed fields

The ProfilePage (US-15) should show the logged-in user's own information. Which fields should be displayed?

A) Name, Email, Role — three read-only fields sourced from AuthContext (no API call needed)
B) Name, Email, Role, Member Since (created date) — four fields; requires a `GET /api/v1/Users/{id}` or `/me` endpoint to fetch the date
C) Name, Email, Role, and a "Change Password" button (button can be a placeholder/not yet functional)
D) Other (please describe after [Answer]: tag below)

[Answer]: C, but only Role is read-only

---

### Question 2: ProfilePage — editability

Should the ProfilePage support editing any of the displayed information, or is it strictly read-only for now?

A) Strictly read-only — no edit capability in this unit (recommended — keeps scope minimal; edits can be a future feature)
B) Allow editing the display name only — inline edit with save
C) Allow editing email and/or name — full form
D) Other (please describe after [Answer]: tag below)

[Answer]: C

---

### Question 3: SettingsPage — availability section interaction

The SettingsPage (US-16) includes an availability section. Should it allow changing the availability mode, or just display the current status?

A) Display + change: show current mode with controls to switch between Online / Maintenance / Offline, and optionally set a custom message (recommended — Settings is the management location; Dashboard is read-only view)
B) Display only: show current availability status, link/note that says "Manage via API or a future admin tool"
C) Other (please describe after [Answer]: tag below)

[Answer]: A

---

### Question 4: SettingsPage — placeholder sections

Beyond the availability section, what placeholder sections should SettingsPage include to indicate planned future features?

A) One generic placeholder: "More settings coming soon"
B) Two placeholders: "Module Management" and "System Configuration" — with "Coming soon" labels
C) Three placeholders: "Module Management", "System Configuration", and "Branding / Theme" — styled as locked cards
D) Other (please describe after [Answer]: tag below)

[Answer]: C

---

### Question 5: CmsPage — placeholder content

The CmsPage (US-20) is an Owner-only placeholder. What should it display?

A) A simple "CMS coming soon" message with an icon and brief description of what will be here (recommended — clear intent without overdesigning)
B) A styled empty state card with a title "Content Management System" and a description of planned capabilities
C) Just a heading: "Content Management" with "Under construction" text
D) Other (please describe after [Answer]: tag below)

[Answer]: A

---

### Question 6: 403 AccessDeniedPage — navigation options

When a user hits a route they don't have permission for (e.g., a non-Owner accessing `/settings`), what should the 403 page offer?

A) Heading "Access Denied" + message explaining the page requires a higher role + "Back to Dashboard" button (recommended — clear and actionable)
B) Heading + message + "Go Back" (browser back) + "Back to Dashboard" buttons
C) Heading + message only — no navigation buttons (user uses browser back)
D) Other (please describe after [Answer]: tag below)

[Answer]: A

---

### Question 7: 404 NotFoundPage — navigation options

When a user navigates to a route that doesn't exist, what should the 404 page offer?

A) Heading "Page Not Found" + brief message + "Back to Dashboard" button (recommended)
B) Heading + message + "Go Back" (browser back) + "Back to Dashboard" buttons
C) Heading + message only
D) Other (please describe after [Answer]: tag below)

[Answer]: A

---

### Question 8: Unit test scope

Which parts of Unit 6 should have unit tests?

A) ProfilePage (renders correct user fields from AuthContext) + SettingsPage (availability display/interaction) + 403 page (renders message + navigation) + 404 page (renders message + navigation)
B) SettingsPage only — the other pages are too simple to warrant tests
C) All pages including CmsPage — full test coverage for the final unit
D) Other (please describe after [Answer]: tag below)

[Answer]: C