# NFR Requirements Plan — react-frontend-app

## Steps

- [x] Assess Security Baseline rule applicability for a static, no-backend React frontend
- [x] Determine performance expectations (Lighthouse-style targets, bundle size sensitivity)
- [x] Determine testing/tooling expectations (test runner, linting, formatting)
- [x] Determine routing fallback strategy for the FTP/static hosting target (NFR-4 follow-up) — AI recommendation: hash-based routing (see nfr-requirements.md)
- [x] Determine accessibility target level
- [x] Determine CI expectations for this iteration
- [x] Generate nfr-requirements.md and tech-stack-decisions.md

## Clarification Questions

Please answer each question by filling in the letter choice after the `[Answer]:` tag.

### Question 1: Performance target
Is there a specific performance target for this static marketing site (e.g. Lighthouse score, load time)?

A) No hard numeric target — just keep the bundle reasonably small and avoid obvious performance mistakes (code-splitting not required yet for a single page)
B) Target a Lighthouse Performance score of 90+ on the built production bundle
C) No performance requirements at all for this iteration
X) Other (please describe after [Answer]: tag below)

[Answer]: A

### Question 2: Testing tooling
Which testing setup should be used for this iteration (component/unit tests)?

A) Vitest + React Testing Library (natural fit with Vite)
B) Jest + React Testing Library
C) No automated tests for this iteration — only manual verification and a successful build
X) Other (please describe after [Answer]: tag below)

[Answer]: A

### Question 3: Linting / formatting
Should linting and formatting be configured as part of this setup?

A) Yes — ESLint (with React/TypeScript rules) + Prettier, configured and passing on the initial codebase
B) Only ESLint, no Prettier
C) Not needed for this iteration
X) Other (please describe after [Answer]: tag below)

[Answer]: A

### Question 4: Routing fallback strategy for FTP hosting (NFR-4 follow-up)
Since the target deployment is a plain FTP/static web host and TanStack Router is being set up now, which routing mode should be used to avoid future deep-link/404 problems on that kind of host?

A) Use TanStack Router's `hashHistory` (URLs like `/#/pakketten`) — works on any static host without server configuration, at the cost of slightly less clean URLs
B) Use browser `history` mode now and defer the FTP rewrite-rule (`.htaccess`) problem to Deployment Setup in the Operations phase, since there's only one route today
C) Not sure — let the AI recommend based on best practice for this hosting target
X) Other (please describe after [Answer]: tag below)

[Answer]: C

### Question 5: Accessibility target
What accessibility (a11y) target should this frontend meet?

A) WCAG 2.1 AA as a target (semantic HTML, sufficient color contrast for both themes, keyboard-operable theme toggle, aria labels per functional design)
B) No formal target — best-effort only, matching whatever the reference HTML already provides
X) Other (please describe after [Answer]: tag below)

[Answer]: B

### Question 6: CI for this iteration
Should a CI pipeline (e.g. GitHub Actions) running build/lint/test be set up as part of this iteration?

A) Yes — set up a basic CI workflow that runs install, lint, test, and build on every push
B) Not yet — CI can be addressed later, possibly during the Operations phase (Deployment Setup)
X) Other (please describe after [Answer]: tag below)

[Answer]: B

### Question: Security Baseline Rule Applicability
Given this is a static, no-backend marketing frontend (per requirements.md), most backend-oriented Security Baseline rules (SECURITY-01, 02, 05, 06, 07, 08, 11, 12, 13, 14, 15) will be marked **N/A**. The following rules ARE potentially applicable and need a decision on scope:
- SECURITY-04 (HTTP security headers) — depends on hosting; may need to be deferred to Deployment Setup if the FTP host doesn't support custom headers easily
- SECURITY-09 (hardening/misconfiguration) — mainly "no sample/demo pages", generic error handling for a client-side app
- SECURITY-10 (software supply chain) — dependency lock file + vulnerability scanning, applicable to any npm project
- SECURITY-13 (integrity) — Subresource Integrity (SRI) for the Google Fonts CDN `<link>` tags

How should these be handled for this iteration?

A) Address SECURITY-10 (lock file + `npm audit`/dependency scanning) and SECURITY-13 (SRI where feasible) now during Code Generation; defer SECURITY-04 (HTTP headers) to Deployment Setup since it depends on the final hosting choice; mark SECURITY-09 items as addressed via a standard production build (no demo pages, generic error boundary)
B) Defer ALL of these to the Operations phase (Deployment Setup / Production Readiness) — do not address any Security Baseline rule during Code Generation
X) Other (please describe after [Answer]: tag below)

[Answer]: A