NFR Design Plan — Unit 1: Project Scaffold & Infrastructure

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

Plan Checklist

Analyze NFR requirements artifacts (nfr-requirements.md, tech-stack-decisions.md)
Identify design pattern decisions needed for performance, a11y, testing, i18n, config
Generate context-appropriate multiple-choice questions per question-format-guide.md
Store this plan file
Wait for user completion of Answer tags
Validate answers, resolve any ambiguities
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)

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)

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)

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)

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)

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)

3.9 KiB Raw Blame History