94 lines
3.1 KiB
Markdown
94 lines
3.1 KiB
Markdown
|
# AGENTS.md
|
||
|
|
|
||
|
|
## Goodwalk Consumer facing brand website
|
||
|
|
|
||
|
|
Convert the existing dog walking business website from WordPress/Elementor to a SvelteKit frontend served behind NGINX, with a PostgreSQL backend for editable text/content.
|
||
|
|
|
||
|
|
The visual design must remain almost identical to the current WordPress site.
|
||
|
|
|
||
|
|
# Goodwalk brand colours
|
||
|
|
#213021 - Goodwalk Green
|
||
|
|
#FFD100 - Goodwalk Yellow for buttons
|
||
|
|
|
||
|
|
## Non-negotiables
|
||
|
|
|
||
|
|
- Do not redesign the site.
|
||
|
|
- Preserve the same colours, fonts, spacing, layout, section order, and visual hierarchy.
|
||
|
|
- Any visual changes must be minimal and justified by technical necessity.
|
||
|
|
- Match the existing site as closely as possible, including mobile layout.
|
||
|
|
- Move all CSS into its own organised directory.
|
||
|
|
- Use SvelteKit for the frontend.
|
||
|
|
- Use PostgreSQL for editable site text/content.
|
||
|
|
- Use NGINX as the public web server/reverse proxy.
|
||
|
|
- Keep the stack suitable for Docker deployment.
|
||
|
|
|
||
|
|
## Frontend requirements
|
||
|
|
|
||
|
|
- Build with SvelteKit.
|
||
|
|
- Use component-based structure.
|
||
|
|
- Keep page layout faithful to the WordPress/Elementor original.
|
||
|
|
- CSS must not be scattered randomly inside components unless scoped component styling is genuinely clearer.
|
||
|
|
- Create a dedicated CSS structure, for example:
|
||
|
|
|
||
|
|
src/lib/styles/
|
||
|
|
base.css
|
||
|
|
variables.css
|
||
|
|
layout.css
|
||
|
|
typography.css
|
||
|
|
buttons.css
|
||
|
|
forms.css
|
||
|
|
sections.css
|
||
|
|
responsive.css
|
||
|
|
|
||
|
|
- Centralise colours, fonts, spacing, border radius, and shadows in variables.
|
||
|
|
- Do not introduce a new design system.
|
||
|
|
- Recreate the existing one cleanly.
|
||
|
|
|
||
|
|
## Backend/content requirements
|
||
|
|
|
||
|
|
- PostgreSQL should store editable text/content.
|
||
|
|
- Content should be structured so business owners can later edit:
|
||
|
|
- homepage hero text
|
||
|
|
- service descriptions
|
||
|
|
- pricing text if applicable
|
||
|
|
- about text
|
||
|
|
- contact details
|
||
|
|
- call-to-action text
|
||
|
|
- SEO title/description fields
|
||
|
|
|
||
|
|
## Migration approach
|
||
|
|
|
||
|
|
1. Inspect the existing WordPress/Elementor site.
|
||
|
|
2. Identify all pages, sections, colours, fonts, spacing, and content blocks.
|
||
|
|
3. Rebuild the frontend in SvelteKit.
|
||
|
|
4. Extract repeated UI into reusable components.
|
||
|
|
5. Move CSS into the dedicated styles directory.
|
||
|
|
6. Add PostgreSQL-backed content models.
|
||
|
|
7. Keep the first version visually static if needed, then wire content fields to the database.
|
||
|
|
8. Do not change wording unless explicitly asked.
|
||
|
|
|
||
|
|
## Quality bar
|
||
|
|
|
||
|
|
- The finished site should look like the current site, not a “modernised” reinterpretation.
|
||
|
|
- Prioritise visual fidelity over clever abstractions.
|
||
|
|
- Keep code clean, simple, and easy to maintain.
|
||
|
|
- Avoid unnecessary dependencies.
|
||
|
|
- Ensure the site works well on desktop and mobile.
|
||
|
|
- Use semantic HTML where practical.
|
||
|
|
- Keep accessibility in mind without altering the visual design.
|
||
|
|
|
||
|
|
## Docker/infra expectation
|
||
|
|
|
||
|
|
The final stack should support:
|
||
|
|
|
||
|
|
- SvelteKit frontend
|
||
|
|
- backend/API if needed
|
||
|
|
- PostgreSQL database - Might not be required, maybe a simple json file.
|
||
|
|
- NGINX reverse proxy
|
||
|
|
- environment-based configuration
|
||
|
|
- production-ready Docker Compose setup
|
||
|
|
|
||
|
|
## When uncertain
|
||
|
|
|
||
|
|
If a design detail is unclear, preserve the WordPress/Elementor behaviour as closely as possible.
|
||
|
|
Do not make creative design decisions without being asked.
|