# NFR Design Questions — Unit 3: frontend-cms-page Please answer each question by filling in the letter after the `[Answer]:` tag. If none of the options match, choose the last option (Other) and describe your preference. --- ## Question 1 Where should the Zod form schemas for `AddCmsInstanceDialog` and `SetStatusDialog` live? Context: `src/lib/schemas/auth.ts` holds shared auth schemas (used by LoginPage, SetupPage, InviteCompletePage, and tested in `auth.test.ts`). `InviteUserDialog` defines its schema inline. A) **Inline in each component file** — `addInstanceSchema` defined inside `AddCmsInstanceDialog.tsx`, `setStatusSchema` inside `SetStatusDialog.tsx`. Pragmatic: each schema is single-use and lives next to the form that uses it. Consistent with `InviteUserDialog.tsx` pattern. B) **Centralised in `src/lib/schemas/cms.ts`** — Both schemas exported from a single module, tested separately in `src/lib/schemas/cms.test.ts`. Consistent with the `auth.ts` pattern; schemas are independently testable. C) Other (please describe after [Answer]: tag below) [Answer]: C, I want all schemas to live in the src/lib/schemas folder. Do it also for schemas that are inlin or otherwise not in that directory to make it consistent and easy to find. --- ## Question 2 How should hook-level API errors be surfaced to the component? Context: TanStack Query exposes `mutation.error` on the mutation object. Two approaches are used in this project: A) **`mutation.error` prop** — component reads `mutation.error` directly and passes `{ message: mutation.error.message }` to `FormErrorBanner`. Pattern used by `InviteUserDialog` (`inviteUser.error`). No extra state. B) **Local `useState(null)`** — component owns a `serverError` string, set in the mutation `onError` callback. Pattern used by `LoginPage`. Allows custom i18n error messages per status code (e.g. 409 Conflict → "Name already in use"). C) Other (please describe after [Answer]: tag below) [Answer]: B, also make it consistent accross the projects if possible.