slp-modular-cms/aidlc-docs/features/cms-frontend/construction/plans/unit-6-functional-design-plan.md

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

• Step 1: Analyze unit context and existing code patterns
• Step 2: Generate questions, collect answers
• Step 3: Create domain-entities.md
• Step 4: Create business-rules.md
• Step 5: Create business-logic-model.md
• Step 6: Create frontend-components.md
• 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)

---

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)

---

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)

---

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)

---

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)

---

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)

---

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)