Initial commit: React frontend (SLP Software) + AIDLC workflow docs
Co-authored-by: Junie <junie@jetbrains.com>
This commit is contained in:
Junie
@@ -0,0 +1,131 @@
|
||||
# Execution Plan — React Frontend (SLP Software Marketing Site)
|
||||
|
||||
## Detailed Analysis Summary
|
||||
|
||||
### Change Impact Assessment
|
||||
- **User-facing changes**: Yes — the entire marketing site is user-facing; net-new capability is the red/purple theme switcher with persisted preference.
|
||||
- **Structural changes**: Yes (greenfield) — establishing the whole application structure (Vite + React + TypeScript, Tailwind, TanStack Router, TanStack Query, theming).
|
||||
- **Data model changes**: Minor — a small static data model for package/pricing content and a theme-token model; no backend data model yet.
|
||||
- **API changes**: None — no backend/API exists yet; TanStack Query is scaffolded but not wired to a real endpoint.
|
||||
- **NFR impact**: Yes — Security Baseline extension is enabled and must be assessed rule-by-rule for a static frontend; deployment target (FTP/static hosting) affects routing and build configuration.
|
||||
|
||||
### Risk Assessment
|
||||
- **Risk Level**: Low — greenfield, single static page, no backend, well-defined reference design to copy from.
|
||||
- **Rollback Complexity**: Easy — no production system yet; this is the initial build.
|
||||
- **Testing Complexity**: Simple — mostly component rendering/visual + a small amount of interaction logic (theme toggle, persistence).
|
||||
|
||||
## Workflow Visualization
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Start(["User Request"])
|
||||
|
||||
subgraph INCEPTION["INCEPTION PHASE"]
|
||||
WD["Workspace Detection<br/><b>COMPLETED</b>"]
|
||||
RA["Requirements Analysis<br/><b>COMPLETED</b>"]
|
||||
US["User Stories<br/><b>SKIPPED</b>"]
|
||||
WP["Workflow Planning<br/><b>IN PROGRESS</b>"]
|
||||
AD["Application Design<br/><b>SKIP</b>"]
|
||||
UG["Units Generation<br/><b>SKIP</b>"]
|
||||
end
|
||||
|
||||
subgraph CONSTRUCTION["CONSTRUCTION PHASE"]
|
||||
FD["Functional Design<br/><b>EXECUTE</b>"]
|
||||
NFRA["NFR Requirements<br/><b>EXECUTE</b>"]
|
||||
NFRD["NFR Design<br/><b>EXECUTE</b>"]
|
||||
ID["Infrastructure Design<br/><b>SKIP</b>"]
|
||||
CG["Code Generation<br/><b>EXECUTE</b>"]
|
||||
BT["Build and Test<br/><b>EXECUTE</b>"]
|
||||
end
|
||||
|
||||
subgraph OPERATIONS["OPERATIONS PHASE"]
|
||||
DS["Deployment Setup<br/><b>EXECUTE</b>"]
|
||||
MS["Monitoring Setup<br/><b>EXECUTE</b>"]
|
||||
PRV["Production Readiness Validation<br/><b>EXECUTE</b>"]
|
||||
end
|
||||
|
||||
Start --> WD
|
||||
WD --> RA
|
||||
RA --> US
|
||||
US --> WP
|
||||
WP --> AD
|
||||
AD --> UG
|
||||
UG --> FD
|
||||
FD --> NFRA
|
||||
NFRA --> NFRD
|
||||
NFRD --> ID
|
||||
ID --> CG
|
||||
CG --> BT
|
||||
BT --> DS
|
||||
DS --> MS
|
||||
MS --> PRV
|
||||
PRV --> End(["Complete"])
|
||||
|
||||
style WD fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style RA fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style US fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
|
||||
style WP fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style AD fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
|
||||
style UG fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
|
||||
style FD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style NFRA fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style NFRD fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style ID fill:#BDBDBD,stroke:#424242,stroke-width:2px,stroke-dasharray: 5 5,color:#000
|
||||
style CG fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style BT fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style DS fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style MS fill:#FFA726,stroke:#E65100,stroke-width:3px,stroke-dasharray: 5 5,color:#000
|
||||
style PRV fill:#4CAF50,stroke:#1B5E20,stroke-width:3px,color:#fff
|
||||
style Start fill:#CE93D8,stroke:#6A1B9A,stroke-width:3px,color:#000
|
||||
style End fill:#CE93D8,stroke:#6A1B9A,stroke-width:3px,color:#000
|
||||
style INCEPTION fill:#BBDEFB
|
||||
style CONSTRUCTION fill:#C8E6C9
|
||||
style OPERATIONS fill:#FFF59D
|
||||
|
||||
linkStyle default stroke:#333,stroke-width:2px
|
||||
```
|
||||
|
||||
Text alternative: Workspace Detection, Requirements Analysis and Workflow Planning are completed (green). User Stories is skipped (gray, dashed). Application Design and Units Generation are skipped (gray, dashed) in Inception. In Construction, Functional Design, NFR Requirements and NFR Design are set to execute (orange, dashed border denotes conditional-but-selected), Infrastructure Design is skipped (gray), while Code Generation and Build and Test always execute (green). In Operations, Deployment Setup and Monitoring Setup execute (orange) and Production Readiness Validation always executes (green) as the final wrap-up stage.
|
||||
|
||||
## Phases to Execute
|
||||
|
||||
### 🔵 INCEPTION PHASE
|
||||
- [x] Workspace Detection (COMPLETED)
|
||||
- [x] Requirements Analysis (COMPLETED)
|
||||
- [x] User Stories (SKIPPED — single visitor persona, low complexity, no acceptance-criteria ambiguity beyond what requirements.md already captures)
|
||||
- [x] Execution Plan (IN PROGRESS)
|
||||
- [ ] Application Design - SKIP
|
||||
- **Rationale**: No backend services or service-layer design needed. Component decomposition (Nav, Hero, PackageCard, ThemeProvider, etc.) is already outlined in requirements.md and will be finalized during Functional Design.
|
||||
- [ ] Units Generation - SKIP
|
||||
- **Rationale**: Single, straightforward unit of work (one React frontend application) — no decomposition into multiple units needed.
|
||||
|
||||
### 🟢 CONSTRUCTION PHASE (single unit: `react-frontend-app`)
|
||||
- [ ] Functional Design - EXECUTE
|
||||
- **Rationale**: New data models needed — theme/color-token model and static package/pricing content model — plus the component tree and route structure need to be defined before code generation.
|
||||
- [ ] NFR Requirements - EXECUTE
|
||||
- **Rationale**: Security Baseline extension is enabled and must be assessed rule-by-rule for applicability to a static, no-backend frontend (e.g. HTTP security headers, dependency/supply-chain scanning, Subresource Integrity for Google Fonts CDN links). Browser-support and deployment-target NFRs from requirements.md also need to be carried into concrete design decisions.
|
||||
- [ ] NFR Design - EXECUTE
|
||||
- **Rationale**: NFR Requirements is executing, so applicable NFR patterns (security headers config, lockfile/scanning setup) need to be incorporated into the design.
|
||||
- [ ] Infrastructure Design - SKIP
|
||||
- **Rationale**: No cloud infrastructure to design at this stage — the site is a static bundle. Concrete hosting/deployment mechanics (FTP upload, routing fallback strategy) are handled by Deployment Setup in the Operations phase.
|
||||
- [ ] Code Generation - EXECUTE (ALWAYS)
|
||||
- **Rationale**: Implementation planning and code generation needed to produce the actual React application.
|
||||
- [ ] Build and Test - EXECUTE (ALWAYS)
|
||||
- **Rationale**: Build, test, and verification needed across the (single) unit.
|
||||
|
||||
### 🟡 OPERATIONS PHASE
|
||||
- [ ] Deployment Setup - EXECUTE
|
||||
- **Rationale**: `Operations Configuration = Yes` (decided in Requirements Analysis). Deployment method (FTP/traditional web host, per NFR-4) needs concrete setup: build/export steps and upload process.
|
||||
- [ ] Monitoring Setup - EXECUTE
|
||||
- **Rationale**: `Operations Configuration = Yes`. Even for a static site, basic uptime/availability monitoring or analytics may be relevant — the stage will ask the user what's actually needed.
|
||||
- [ ] Production Readiness Validation - EXECUTE (ALWAYS once Operations phase is reached)
|
||||
- **Rationale**: Final wrap-up checklist for the feature.
|
||||
|
||||
## Estimated Timeline
|
||||
- **Total Stages**: 10 (2 skipped, 8 executed) across Inception (remaining), Construction, and Operations
|
||||
- **Estimated Duration**: Single focused session — small, well-scoped greenfield frontend
|
||||
|
||||
## Success Criteria
|
||||
- **Primary Goal**: A working, statically-buildable React application that reproduces the reference marketing page 1-to-1, with a red-default/purple-selectable theme switcher, scaffolded with TanStack Router and TanStack Query for future growth.
|
||||
- **Key Deliverables**: React + TypeScript + Vite + Tailwind project; theme system with persistence; ported page content/components; TanStack Router route shell; TanStack Query provider shell; build/test instructions; deployment instructions for FTP/static hosting; production readiness checklist.
|
||||
- **Quality Gates**: Successful production build; passing component/unit tests; applicable Security Baseline rules satisfied (or explicitly marked N/A with rationale).
|
||||
+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