Resolve open questions; update all core specs

specification/02-architecture-decisions.md

@@ -2,53 +2,74 @@
 
 This file records stable architectural decisions and their rationale. Items here should remain valid even as implementation details evolve.
 
-## ADR-001 — Static website (SSG or plain static HTML) as the delivery model
+## ADR-001 — Static website as the delivery model
 - **Status**: Accepted
 - **Context**: Site is primarily informational/lead-capture, needs strong SEO, and is expected to change infrequently.
-- **Decision**: Build as a **static website** (pre-rendered HTML) suitable for hosting behind a reverse proxy.
+- **Decision**: Build as a **static website** (pre-rendered HTML) suitable for hosting behind a Caddy reverse proxy.
 - **Rationale**:
-  - SEO-friendly (indexable content)
+  - SEO-friendly (fully indexable content)
   - Fast and reliable on mobile
   - Low maintenance
 - **Alternatives considered**:
   - WordPress/CMS: easier editing but higher maintenance/security surface
   - SPA-only: SEO/performance risks and complexity
 - **Consequences**:
-  - Contact form delivery must be handled via a static-compatible approach (see ADR-002, TBD)
+  - Contact form delivery must be handled via a static-compatible approach (see ADR-002)
 
-## ADR-002 — Quote request form submission mechanism
-- **Status**: Proposed (blocked)
-- **Context**: Form is required (FR-1..FR-4), but the mechanism (email service, server endpoint, third-party form backend) is not yet selected.
-- **Decision**: TBD.
-- **Options to evaluate** (non-exhaustive):
-  1. Static form backend service (e.g., Netlify Forms / Formspree / Basin)
-  2. Self-hosted lightweight endpoint behind Caddy (out-of-scope per C-2 unless already existing)
-  3. Email link fallback (mailto) — likely insufficient for qualified leads
-- **Drivers**:
-  - Qualified lead capture
-  - Spam protection
-  - GDPR/cookie implications
-  - Operational simplicity
-- **Next step**: Resolve in `99-open-questions.md` and specify in `38-lead-capture-spec.md`.
+## ADR-002 — Form backend: existing AWS service
+- **Status**: Partially accepted (details pending)
+- **Context**: The site must collect quote request form submissions (FR-3, FR-5). The site is static, so a backend service is required.
+- **Decision**: Use an **existing AWS service** owned/operated by the stakeholder.
+- **Rationale**:
+  - Reuses existing infrastructure
+  - Avoids new third-party service dependencies
+- **Remaining open items** (blocking `38-lead-capture-spec.md`):
+  - Which AWS service is used (e.g. SES, API Gateway + Lambda)?
+  - What is the form submission endpoint URL?
+  - What spam protection is in place or expected (e.g. honeypot, reCAPTCHA, AWS WAF)?
+- **See also**: OQ-3
 
 ## ADR-003 — Mobile-first, performance-first design
 - **Status**: Accepted
 - **Context**: Most traffic is expected on mobile; SEO and conversion depend on usability and speed.
-- **Decision**: Adopt a **mobile-first** layout and performance budget mindset.
+- **Decision**: Adopt a **mobile-first** layout and performance budget mindset throughout.
 - **Rationale**:
-  - Improves conversion
+  - Improves conversion on mobile
   - Supports SEO (Core Web Vitals)
 - **Consequences**:
-  - Images must be optimized; avoid heavy JS
-  - Ensure accessible typography and tap targets
+  - Images must be optimized (sized, compressed, lazy-loaded); avoid heavy JavaScript
+  - Ensure accessible typography and touch-friendly tap targets
 
-## ADR-004 — SEO information architecture: one page per service
+## ADR-004 — Service pages: grouped by search intent for SEO
 - **Status**: Accepted
-- **Context**: SEO is important and services are distinct.
-- **Decision**: Create **separate service pages** for each service category listed in FR-8.
+- **Context**: Individual pages per service produce better SEO but only if pages have sufficient unique content. Some services (carpentry/mounting, flooring/wood refinishing) share search intent and image assets.
+- **Decision**: Organize service pages into **9 grouped pages** (down from 10+ individual items), grouped by search intent:
+
+  | Page | Slug | Services grouped |
+  |------|------|-----------------|
+  | Painting | `/services/painting/` | Interior & exterior painting, trim |
+  | Tile Setting | `/services/tile-setting/` | All tile types, all rooms |
+  | Drywall & Sheetrocking | `/services/drywall/` | Drywall, sheetrocking, patching |
+  | Minor Plumbing | `/services/plumbing/` | Sinks, toilets, showers |
+  | Minor Electrical | `/services/electrical/` | Lights, fans, fixtures |
+  | Carpentry & Mounting | `/services/carpentry-and-mounting/` | Carpentry, mounting, assembly |
+  | Flooring & Wood Refinishing | `/services/flooring/` | Flooring, decks, stairs, refinishing |
+  | Security & Safety Equipment | `/services/security-safety/` | Grab bars, locks, cameras |
+  | Boat Work | `/services/boat-work/` | Marine woodwork, paint, hardware |
+
 - **Rationale**:
-  - Supports service-intent keywords
-  - Improves internal linking and topical relevance
+  - Grouped pages have richer content and avoid thin-page SEO penalties
+  - Carpentry + Mounting share the installation/assembly search intent
+  - Flooring touch-ups + Wood Refinishing share the surface/finishing search intent and asset library
 - **Consequences**:
-  - Requires unique content per page (avoid duplicate/thin pages)
-  - Requires a services hub and internal navigation
+  - 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-005 — No analytics or tracking in v1
+- **Status**: Accepted
+- **Context**: Stakeholder decided against tracking for simplicity.
+- **Decision**: **No analytics scripts, no ad pixels, no cookie consent banner** in v1.
+- **Rationale**: Reduces complexity, avoids consent/privacy obligations at launch.
+- **Consequences**:
+  - No data-driven iteration on traffic or conversions at launch
+  - Adding analytics later will require revisiting privacy policy needs