101 lines
8.5 KiB
Markdown
101 lines
8.5 KiB
Markdown
# Requirements — React Frontend (SLP Software Marketing Site)
|
|
|
|
## Intent Analysis Summary
|
|
|
|
- **User Request**: Build a React frontend for SLP Software. Two static HTML reference designs exist in `References/` (`slp-software.html` = purple accent, `slp-software-rood.html` = red accent) that are the same design with only a different accent color. Red must become the primary/default theme; the purple theme must remain selectable (this selectability is new, not present in the original static designs). All other content/layout must be ported 1-to-1 into React. Start with a static site, but built as React. For later use: TanStack Router and TanStack Query should be used where needed. The AI-DLC workflow must be used to set this up.
|
|
- **Request Type**: New Project (Greenfield)
|
|
- **Scope Estimate**: Single Component — one marketing/landing page rebuilt as a React application, plus supporting theming infrastructure
|
|
- **Complexity Estimate**: Simple to Moderate — the visual/content scope is a single static page, but a full modern tooling skeleton (Vite, TypeScript, TanStack Router, TanStack Query, Tailwind CSS, theming) is being set up for future growth
|
|
- **Requirements Depth**: Standard
|
|
|
|
## Reference Design Analysis
|
|
|
|
Both reference files were compared byte-for-byte (`Compare-Object`). They are **identical in structure, markup, and copy**; the only differences are CSS custom property values used for theming:
|
|
|
|
| Variable | Purple (`slp-software.html`) | Red (`slp-software-rood.html`) |
|
|
|---|---|---|
|
|
| `--bg` | `#0E1220` | `#140C0E` |
|
|
| `--surface` | `#151A2C` | `#1F1315` |
|
|
| `--surface-2` | `#1B2138` | `#291719` |
|
|
| `--line` | `#262E4A` | `#402226` |
|
|
| `--text` | `#E9EBF5` | `#F5EAEB` |
|
|
| `--muted` | `#98A0BA` | `#B69C9F` |
|
|
| `--accent` | `#8B7CFF` | `#E04848` |
|
|
| `--accent-soft` | `rgba(139,124,255,.14)` | `rgba(224,72,72,.16)` |
|
|
| `--accent-line` | `rgba(139,124,255,.35)` | `rgba(224,72,72,.40)` |
|
|
| Hero radial gradients, badge/button text color, `#pakketten` gradient | purple-tinted values | red-tinted values |
|
|
|
|
Page structure (both files, identical):
|
|
1. **Nav** — logo ("SLP.Software"), links (Pakketten / Werkwijze / Over), CTA ("Start project")
|
|
2. **Hero** — eyebrow label, H1, lead paragraph, animated code line with blinking caret, two CTA buttons
|
|
3. **Pakketten (Packages)** — 3 pricing cards (Landingspagina €300, Website €750 — featured, Maatwerk — quote-based)
|
|
4. **Werkwijze (Process)** — 3-step process (intake, bouwen, live)
|
|
5. **Over (About)** — company description + tech stack panel
|
|
6. **Contact** — contact box with mailto CTA
|
|
7. **Footer** — copyright + mono tagline
|
|
|
|
## Functional Requirements
|
|
|
|
### FR-1: Page Content Parity
|
|
The React application MUST reproduce all sections, copy, structure, and visual layout of the reference designs 1-to-1: Nav, Hero, Pakketten, Werkwijze, Over, Contact, Footer. All Dutch marketing copy, package prices (€300 / €750 / "Op maat"), and the contact e-mail address (`info@slpsoftware.nl`) are copied exactly as-is from the reference HTML for this iteration; this content is expected to be replaced by dynamically fetched data in a future iteration (see FR-5).
|
|
|
|
### FR-2: Componentization
|
|
The page MUST be decomposed into reusable React components (e.g. `Nav`, `Hero`, `PackagesSection`, `PackageCard`, `ProcessSection`, `AboutSection`, `ContactSection`, `Footer`) rather than a single monolithic page component.
|
|
|
|
### FR-3: Theme Switching
|
|
- The site MUST default to the **red** theme on first load.
|
|
- The **purple** theme MUST remain selectable by the visitor via a visible UI control (e.g. a toggle/switcher in the nav).
|
|
- The chosen theme MUST be persisted in the browser (`localStorage` or equivalent) so it is remembered on return visits; if no stored preference exists, red is used.
|
|
- Theme values MUST be implemented so that both palettes (and any future palette) can be added without duplicating component markup — i.e. only the color tokens change, not the structure.
|
|
|
|
### FR-4: Preserved Micro-Interactions
|
|
All existing micro-interactions from the reference designs MUST be preserved: the blinking caret animation in the hero code line, `:hover` / `:focus-visible` states on links, cards and buttons, and smooth-scroll behavior for in-page anchor navigation (respecting `prefers-reduced-motion`).
|
|
|
|
### FR-5: Forward-Looking Data Layer (Preparation Only)
|
|
- TanStack Router MUST be set up and wired into the application shell, even though the initial scope has effectively a single route (`/`). Route structure should be organized so that adding routes later is straightforward.
|
|
- TanStack Query MUST be installed and configured (e.g. `QueryClientProvider` at the app root) as part of this iteration's skeleton, in preparation for a future iteration where package/content data is fetched from a backend instead of being hardcoded. No actual network data-fetching is required yet — static data (matching FR-1) is used as the source for now, structured so it can be swapped for a TanStack Query hook later with minimal changes.
|
|
|
|
## Non-Functional Requirements
|
|
|
|
### NFR-1: Tooling & Language
|
|
- Build tool: **Vite**
|
|
- Language: **TypeScript**
|
|
- UI library: **React**
|
|
|
|
### NFR-2: Styling
|
|
- **Tailwind CSS** is used as the utility CSS framework to re-implement the reference visuals.
|
|
- The color palette (red default / purple alternate) MUST be modeled as design tokens (e.g. CSS custom properties consumed via Tailwind theme config, or a Tailwind theme extension keyed by a `data-theme` attribute/class) so that switching a single token set changes the whole site's palette, mirroring how the reference designs use `:root` CSS variables.
|
|
|
|
### NFR-3: Browser Support
|
|
Modern evergreen browsers only (latest Chrome, Firefox, Edge, Safari). No legacy/IE-adjacent support required. This matches the reference design's use of modern CSS features (`backdrop-filter`, `clamp()`, CSS custom properties).
|
|
|
|
### NFR-4: Deployment Target
|
|
The build output MUST remain a plain static bundle (HTML/CSS/JS, no Node.js server required at runtime) so it can be deployed to a traditional web host via FTP/manual upload. This has a design implication for TanStack Router: once more than one route exists, either hash-based routing or host-level rewrite rules (e.g. `.htaccess`) will be needed for direct-link/deep-link support on a plain static FTP host — to be finalized during Application Design / Infrastructure Design when routing needs are concrete.
|
|
|
|
### NFR-5: Operations Phase
|
|
This feature WILL go through the Operations phase after Construction (deployment setup + monitoring setup + production readiness validation).
|
|
|
|
## Extension Configuration
|
|
|
|
| Extension | Enabled | Notes |
|
|
|---|---|---|
|
|
| **Security Baseline** | Yes | Enforced as blocking constraints. Most backend-oriented rules (auth, API validation, network config, encryption at rest, etc.) are expected to be **N/A** for this static, no-backend marketing site — applicability will be re-assessed rule-by-rule at each stage (e.g. HTTP security headers via hosting/CDN config, dependency lock file & vulnerability scanning, Subresource Integrity for the Google Fonts CDN links). |
|
|
| **Property-Based Testing** | No | Skipped — this is a largely static, UI-only marketing site with no significant business logic. |
|
|
|
|
## Out of Scope (for this iteration)
|
|
|
|
- Real backend/API integration for package/content data (prepared for via TanStack Query, but not implemented)
|
|
- Multiple routes/pages beyond the single landing page
|
|
- CMS or admin interface for editing content
|
|
- Analytics/tracking integration
|
|
- Automated deployment pipeline details (handled in the Operations phase)
|
|
|
|
## Open Design Considerations (to resolve later, not blocking)
|
|
|
|
- Exact mechanism for FTP-safe client-side routing once multiple routes exist (hash routing vs. `.htaccess` rewrites) — Application Design / Infrastructure Design.
|
|
- Exact shape of the future data-fetching layer (API contract) that TanStack Query will eventually call — deferred until a backend exists.
|
|
|
|
## Summary
|
|
|
|
This is a greenfield React frontend for SLP Software's marketing site. The visual and content scope is a straightforward 1-to-1 port of an existing static HTML/CSS design (available in two color variants). The key net-new requirement beyond the reference designs is a red-default / purple-selectable theme switcher with persisted preference. The project is set up with Vite + React + TypeScript + Tailwind CSS, and is scaffolded from day one with TanStack Router and TanStack Query to support future growth, even though the current scope has a single route and static data. Security Baseline is enforced; Property-Based Testing is skipped; the Operations phase will run after Construction.
|