tom/diana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Phase 4: implement full static site (Eleventy, 15 pages, CSS, JS)

Browse Source
This commit is contained in:
Tom Roth
2026-07-31 08:33:06 +02:00
parent ecbd9f94e5
commit 34f7f5a1f5
24 changed files with 5986 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
specification/02-architecture-decisions.md
View File

@@ -66,6 +66,25 @@ This file records stable architectural decisions and their rationale. Items here
- Each grouped page must contain enough unique content to serve its target keywords
- Internal linking from the Services hub must cover all sub-topics
## ADR-006 — Static site generator: Eleventy (11ty)
- **Status**: Accepted
- **Context**: The site has 15+ pages sharing a common nav, footer, and layout. Plain HTML would require copy-pasting these into every file, creating a maintenance burden when nav items change.
- **Decision**: Use **Eleventy 2.x** (`@11ty/eleventy`) as the static site generator with **Nunjucks** as the template language.
- **Rationale**:
- Produces pure static HTML files — no runtime dependency
- Nunjucks layout chaining and includes eliminate nav/footer duplication
- Simple data cascade for service pages (frontmatter-driven)
- Well-documented, widely used for exactly this use case
- `npm run build` outputs to `_site/` which Caddy serves directly
- **Alternatives considered**:
- Plain HTML: zero tooling but nav/footer must be duplicated in every file
- Hugo: fast but Go-based; less familiar template syntax
- Astro: more powerful but heavier; overkill for a content/lead-gen site
- **Consequences**:
- Node.js + npm required in the build environment (not at runtime)
- Output: `_site/` directory of static HTML, CSS, JS, and assets
- Caddy should serve from `_site/`
## ADR-005 — No analytics or tracking in v1
- **Status**: Accepted
- **Context**: Stakeholder decided against tracking for simplicity.

10
specification/99-open-questions.md
View File

@@ -43,14 +43,8 @@ This log tracks uncertainties and deferred decisions. Each item should be resolv
- **Rationale**: Carpentry and Mounting share the same installation/assembly search intent. Flooring touch-ups and Wood Refinishing share the same surface/finish search intent and existing image assets.
## OQ-7 — Thank-you page vs. in-page success state after form submission
- **Status**: Open — raised by `38-lead-capture-spec.md`
- **Question**: After a successful form submission, should the site stay on `/contact/` and show an in-page success state (Option A), or redirect to a dedicated `/thank-you/` page (Option B)?
- **Options**:
- **Option A (recommended for v1)**: In-page success state. Form is replaced by `FormFeedback (success)` component on `/contact/`. Simpler. No redirect. No extra page to maintain. Fits v1 since there is no analytics to track conversion events (ADR-005).
- **Option B**: Redirect to `/thank-you/`. Prevents back-button resubmission. Better for conversion tracking when analytics are added later. Requires a separate HTML page with `noindex`.
- **Recommendation**: Option A for v1. Revisit when/if analytics are added.
- **Blocking**: Implementation of `38-lead-capture-spec.md`.
- **Decision needed from**: Diana / project owner.
- **Status**: Resolved
- **Resolution**: Use **Option A — in-page success state**. Form is replaced by the `FormFeedback (success)` component on `/contact/`. No redirect, no `/thank-you/` page required. Revisit if analytics are added later.
## OQ-6 — Brand naming and domain
- **Status**: Resolved