Initial commit: React frontend (SLP Software) + AIDLC workflow docs
Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
Junie
+117
@@ -0,0 +1,117 @@
|
||||
# Requirements Clarification Questions — React Frontend
|
||||
|
||||
Please answer each question by filling in the letter choice after the `[Answer]:` tag.
|
||||
|
||||
## Question 1: Scope of this first iteration
|
||||
The request says "start with setting up a static website, but as React". What should be included in this first delivery?
|
||||
|
||||
A) Only the landing page content that is already in the reference designs (nav, hero, pakketten, werkwijze, over, contact, footer), rebuilt 1-on-1 as React components
|
||||
B) The reference page content, plus routing scaffolding (TanStack Router) even though there is only one route today
|
||||
C) The reference page content, plus a full project skeleton including TanStack Router AND TanStack Query wired up (even though there is no data-fetching need yet)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
## Question 2: Tooling / build setup
|
||||
Which React tooling stack should be used to set up the project?
|
||||
|
||||
A) Vite + React + TypeScript (fast dev server, widely used with TanStack)
|
||||
B) Vite + React (JavaScript, no TypeScript)
|
||||
C) Next.js (React framework with built-in routing — note: overlaps with TanStack Router, so would need a decision on which router to use)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 3: Styling approach
|
||||
The reference designs use hand-written CSS with CSS custom properties (`:root { --bg; --accent; ... }`) for theming. How should styling be implemented in React?
|
||||
|
||||
A) Keep plain CSS (CSS Modules or global CSS) using the same CSS custom properties, so the color palette stays swappable exactly like the reference
|
||||
B) Move to CSS-in-JS (e.g. styled-components / vanilla-extract)
|
||||
C) Move to a utility CSS framework (e.g. Tailwind CSS), re-implementing the visuals with utility classes
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
## Question 4: Color theme switching mechanism
|
||||
You want red as the default/primary theme, with the purple theme selectable as an addition to the reference designs. How should the user select the theme?
|
||||
|
||||
A) A visible UI toggle/switcher on the site (e.g. in the nav) that lets visitors switch between "Rood" and "Paars" at runtime
|
||||
B) Only a developer-facing mechanism for now (e.g. a config value or environment variable) — no visible UI control yet, visible switcher can be a later iteration
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 5: Theme persistence
|
||||
If a visible theme switcher is added (Question 4 = A), should the chosen theme be remembered between visits?
|
||||
|
||||
A) Yes — persist the choice in the browser (e.g. localStorage) so it's remembered on return visits
|
||||
B) No — theme resets to red (default) on every page load/visit
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 6: Content fidelity vs. placeholders
|
||||
The reference designs contain real Dutch marketing copy (package prices, e-mail address `info@slpsoftware.nl`, etc.). Should this content be copied 1-on-1?
|
||||
|
||||
A) Yes — copy all text, prices, and contact details 1-on-1 exactly as in the reference HTML
|
||||
B) Copy the structure/layout 1-on-1, but replace specific business content (prices, e-mail) with placeholders to be finalized later
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A, this will be replaced with data fetching later, but for now use the data from the designs
|
||||
|
||||
## Question 7: Interactivity already present in the reference
|
||||
The reference HTML has a couple of small interactive/dynamic bits (a blinking caret animation in the hero code line, `:hover`/`:focus-visible` states, smooth scroll anchor links). Should these be preserved as-is?
|
||||
|
||||
A) Yes — preserve all existing visual micro-interactions exactly (blinking caret, hover states, smooth scroll)
|
||||
B) Preserve hover/focus states, but drop the blinking caret animation
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question 8: Target deployment / hosting
|
||||
Is there a specific hosting target already in mind for this static React site (relevant later for build output configuration)?
|
||||
|
||||
A) Not decided yet — keep the build generic (static output, deployable anywhere)
|
||||
B) Static hosting / CDN (e.g. Netlify, Vercel, Cloudflare Pages, GitHub Pages)
|
||||
C) Traditional web host via FTP/manual upload (as hinted by the `demo-setup` / on-premises style deployment)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
## Question 9: Browser/device support baseline
|
||||
What is the minimum browser/device support baseline for this site?
|
||||
|
||||
A) Modern evergreen browsers only (latest Chrome, Firefox, Edge, Safari) — matches the reference's use of modern CSS (backdrop-filter, clamp, etc.)
|
||||
B) Broader legacy support required (older browsers, e.g. older Safari/IE-adjacent) with graceful degradation
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question: Security Extensions
|
||||
Should security extension rules be enforced for this project?
|
||||
|
||||
A) Yes — enforce all SECURITY rules as blocking constraints (recommended for production-grade applications)
|
||||
B) No — skip all SECURITY rules (suitable for PoCs, prototypes, and experimental projects, or for a marketing-only static site with no backend/user data)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
|
||||
## Question: Property-Based Testing Extension
|
||||
Should property-based testing (PBT) rules be enforced for this project?
|
||||
|
||||
A) Yes — enforce all PBT rules as blocking constraints
|
||||
B) Partial — enforce PBT rules only for pure functions and serialization round-trips
|
||||
C) No — skip all PBT rules (suitable for this kind of largely static, UI-only marketing site with no significant business logic)
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: C
|
||||
|
||||
## Question: Operations Phase
|
||||
Should this feature go through the Operations phase after Construction (setting up deployment and monitoring)?
|
||||
|
||||
A) Yes — run the Operations phase after Construction (deployment + monitoring setup)
|
||||
B) No — stop after Build and Test (deployment/monitoring are out of scope for this feature)
|
||||
C) Not sure yet — ask me again after the Construction phase
|
||||
X) Other (please describe after [Answer]: tag below)
|
||||
|
||||
[Answer]: A
|
||||
@@ -0,0 +1,100 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user