# NFR Design Plan — Unit 1: Project Scaffold & Infrastructure

**Status**: Completed — NFR design patterns and logical components generated based on answers.

## Plan Checklist
- [x] Analyze NFR requirements artifacts (nfr-requirements.md, tech-stack-decisions.md)
- [x] Identify design pattern decisions needed for performance, a11y, testing, i18n, config
- [x] Generate context-appropriate multiple-choice questions per question-format-guide.md
- [x] Store this plan file
- [x] Wait for user completion of [Answer] tags
- [x] Validate answers, resolve any ambiguities
- [x] Generate nfr-design-patterns.md and logical-components.md artifacts

## NFR Design Questions

## Question 1
How should TanStack Router file-based routes be organized to achieve optimal code-splitting and keep the initial JS bundle as small as possible?

A) One route file per major feature (auth, dashboard, users, cms) with lazy-loaded layouts and components
B) Flat structure under src/routes/ with all routes co-located, relying on Vite's automatic tree-shaking and code-splitting
C) Hybrid approach: core shell and auth routes eager-loaded; feature modules (dashboard, users, cms) lazy-loaded via dynamic imports inside authenticated layout
X) Other (please describe after [Answer]: tag below)

[Answer]: A

## Question 2
What focus management and keyboard navigation pattern should be implemented for the admin UI (sidebar navigation + main content area) to satisfy the basic a11y requirement?

A) Rely entirely on browser default Tab order + shadcn/ui :focus-visible styles; add focus trap only for modals and dialogs
B) Implement roving tabindex for sidebar nav items + visible focus ring; standard Tab for main content
C) Full custom arrow-key navigation and type-ahead search inside the sidebar (desktop-app style)
X) Other (please describe after [Answer]: tag below)

[Answer]: A

## Question 3
How should MSW request handlers be organized to support auth flows, 401-intercept testing, and future feature mocks while keeping tests maintainable?

A) Centralized `src/mocks/handlers.ts` exporting domain-specific arrays (authHandlers, userHandlers, cmsHandlers) re-exported from index
B) Feature-scoped folders under `src/mocks/` (e.g. `auth/handlers.ts`, `users/handlers.ts`) with barrel re-exports
C) Inline MSW handlers defined directly inside each test file for maximum isolation
X) Other (please describe after [Answer]: tag below)

[Answer]: B

## Question 4
What strategy should be used for loading and switching between English and Dutch translations with react-i18next?

A) Eager-load both language JSON files at app bootstrap (small total size) and keep them in memory
B) Lazy-load only the active language JSON; switch language by dynamic import of the new locale file
C) Use i18next-http-backend to fetch translations from `/locales/{lng}/{ns}.json` on demand (no bundling)
X) Other (please describe after [Answer]: tag below)

[Answer]: B

## Question 5
How should RFC 9457 ProblemDetails responses be transformed into user-facing feedback (toasts/banners) while keeping the implementation simple?

A) Global error interceptor in ApiClient that maps ProblemDetails to a single shadcn/ui toast (title = title or status, description = detail)
B) Per-page or per-component error handling that decides toast vs. inline message based on context
C) Only show toasts for network errors and 5xx; 4xx errors are handled by form validation or redirect only
X) Other (please describe after [Answer]: tag below)

[Answer]: B

## Question 6
How should Vite environment variables (VITE_API_BASE_URL and future feature flags) be typed and validated?

A) Extend `vite-env.d.ts` with a typed `import.meta.env` interface and add optional Zod validation at runtime startup
B) Use TypeScript module augmentation for `import.meta.env` only; no runtime validation (trust .env files)
C) Fetch a `config.json` at bootstrap for all non-Vite-exposed settings; keep VITE_* vars minimal
X) Other (please describe after [Answer]: tag below)

[Answer]: A