gspec 1.7.0 → 1.11.0

package/starters/features/contact-form.md

@@ -0,0 +1,147 @@
+---
+gspec-version: 1.8.0
+description: Validated contact form with email delivery and success feedback
+---
+
+# Contact Form
+
+## Overview
+
+A reusable contact form component that lets visitors submit a structured inquiry (name, email, optional phone, and message) which triggers a server-side email to the business. Without a contact form, visitors must manually compose an email or make a phone call — adding friction that can cause drop-off at the moment of highest intent.
+
+## Users & Use Cases
+
+**Primary users:** Prospective clients and general visitors who want to reach the business directly from the website.
+
+**Key use cases:**
+
+1. A prospective client finishes reviewing services and wants to describe their needs in a message without leaving the site or opening their email client.
+2. A visitor on a mobile device quickly fills in their name, email, and a short message using touch-friendly inputs and submits it in under a minute.
+3. A visitor submits the form and immediately sees confirmation that their message was received, giving them confidence to move on without follow-up.
+4. A visitor makes a validation error (e.g., malformed email) and corrects it in place without losing any of the text they already typed.
+
+## Scope
+
+**In scope:**
+
+- Self-contained, reusable form component that can be placed on any page (contact page, footer CTA, standalone route)
+- Required fields: name, email address, message body
+- Optional field: phone number
+- Client-side validation with inline error feedback
+- Submission to a server-side endpoint that sends the email
+- Clear success and error states after submission
+- Double-submission prevention
+- Hidden honeypot field for basic spam prevention
+- Accessible markup (labels, focus management, error announcements)
+- Responsive layout for mobile through desktop
+
+**Out of scope:**
+
+- The server-side email-sending endpoint itself (this feature defines the client-side form and its contract with the server; the endpoint is an infrastructure concern)
+- Email templates, recipient configuration, or transport provider selection
+- File attachments or media uploads
+- CAPTCHA or third-party bot detection services
+- Auto-reply or confirmation emails sent back to the submitter
+- Analytics or event tracking for form interactions
+- Multi-step or wizard-style form flows
+
+**Deferred ideas:**
+
+- Project type or inquiry category selector
+- Preferred contact time field
+- CAPTCHA integration if honeypot proves insufficient
+- Auto-save or draft persistence for partially completed forms
+- Confirmation email sent to the submitter after successful submission
+
+## Capabilities
+
+- [ ] **P0**: Visitor can fill in required fields (name, email, message) and submit the form
+  - Form renders name, email, and message fields, each with a visible label
+  - All three fields are required; form cannot be submitted with any of them empty
+  - On valid submission, form data is sent to a server-side endpoint as a structured payload
+  - After successful server response, a clear success message is displayed
+
+- [ ] **P0**: Form validates input and shows inline errors before submission
+  - Empty required fields show a "required" error when the visitor attempts to submit
+  - Email field validates format and shows a specific error for malformed addresses
+  - Errors appear inline next to or below the relevant field
+  - Existing field values are preserved when validation errors are displayed
+
+- [ ] **P0**: Form displays clear feedback for success and error outcomes
+  - On success, a thank-you or confirmation message replaces or overlays the form so the visitor knows the message was received
+  - On server error, an actionable error message is shown (e.g., "Something went wrong — please try again or contact us by phone")
+  - Feedback persists on screen until the visitor takes further action; it does not auto-dismiss
+
+- [ ] **P0**: Submit control is guarded to prevent double submissions
+  - The submit button is disabled (or the form is otherwise guarded) while a submission request is in flight
+  - A loading indicator is visible during the request so the visitor knows the form is processing
+
+- [ ] **P0**: Form is accessible
+  - Every input has a programmatically associated label
+  - Tab order follows a logical sequence through fields and the submit button
+  - Validation errors are announced to assistive technology (e.g., via live regions or focus management)
+  - Error messages are visible and not conveyed by color alone
+
+- [ ] **P1**: Visitor can optionally provide a phone number
+  - An optional phone number field is displayed with a clear indication that it is not required
+  - The form submits successfully with or without a phone number value
+  - If provided, the phone number is included in the payload sent to the server
+
+- [ ] **P1**: Form layout is responsive across device sizes
+  - On desktop, fields may be arranged in a multi-column layout where appropriate
+  - On mobile, all fields stack vertically with touch-friendly input sizes (minimum 44px tap targets)
+  - No horizontal scrolling at any viewport width
+  - Labels remain legible and inputs remain usable at all sizes
+
+- [ ] **P1**: Hidden honeypot field deters automated spam submissions
+  - A visually hidden field is included in the form markup
+  - The field is not visible or focusable to human users
+  - If the honeypot field contains a value on submission, the form either silently discards the submission or the server rejects it
+  - Legitimate users are never affected by the honeypot mechanism
+
+- [ ] **P1**: Key conversion pages include a call-to-action linking to the contact form
+  - Pages where visitors evaluate the business (e.g., Home, Services) include a CTA section near the bottom that directs visitors to the contact page
+  - The CTA includes a clear heading and a button or link to the contact page
+  - The CTA is visually distinct from surrounding content sections
+  - The CTA does not duplicate the full form — it links to the dedicated contact page where the form lives
+
+- [ ] **P2**: Form is a self-contained, reusable component
+  - The form can be embedded on different pages without code duplication
+  - Placement on a page does not require page-specific modifications to the form's internal logic
+  - The server endpoint URL is configurable (e.g., via props, config, or environment) rather than hardcoded
+
+## Dependencies
+
+- **Contact Page** ([contact-page.md](contact-page.md)): The contact page is the primary intended host for this form component. The form should integrate visually alongside the static contact details already specified in that feature.
+- **Form submission endpoint**: The form requires a backend that accepts the form payload and delivers the inquiry via email. This may be a server-side endpoint within the application or a third-party form service, depending on the stack's capabilities. Consult `gspec/stack.md` to determine the available approach.
+
+> **Compatibility note**: This feature requires a form submission endpoint. Static-only stacks with no server runtime must include a third-party form submission service (check `gspec/stack.md` Section 11 — Third-Party Integrations). Full-stack stacks with backend capabilities should implement a custom server endpoint (check `gspec/stack.md` Section 5 — Backend Stack). The form's payload contract (name, email, phone, message, honeypot) remains the same regardless of approach.
+
+## Assumptions & Risks
+
+**Assumptions:**
+
+- A server-side endpoint for receiving form submissions and sending email will be available at implementation time or will be built as a companion task.
+- A single, fixed set of fields (name, email, optional phone, message) is sufficient for all expected inquiry types.
+- The honeypot technique provides adequate spam prevention for the expected traffic level.
+
+**Open questions:**
+
+- Exact error response format from the server endpoint (status codes, error body structure) will be determined during implementation when the endpoint is built.
+
+**Key risks:**
+
+- **Server endpoint availability:** The form is inert without a functioning server endpoint. Mitigation: the form can be built and tested with a mock endpoint; the real endpoint can be connected later.
+- **Spam volume:** A honeypot field alone may not stop sophisticated bots. Mitigation: monitor submission volume post-launch; CAPTCHA integration is a deferred enhancement if needed.
+- **Email deliverability:** Submissions may be lost if the server-side email send fails silently. Mitigation: the server endpoint should return clear success/failure responses so the form can display accurate feedback to the visitor.
+
+## Success Metrics
+
+1. Visitors can successfully submit the form and receive visible confirmation on the first attempt when all fields are valid.
+2. Validation errors prevent submission of incomplete or malformed data, and visitors can correct errors without re-entering other fields.
+3. The form is usable and visually coherent on mobile devices (375px viewport) through desktop (1440px viewport).
+4. Spam submissions (honeypot-caught) account for the majority of bot traffic, with minimal false positives affecting legitimate users.
+
+## Implementation Context
+
+> This feature PRD is portable and project-agnostic. During implementation, consult the project's `gspec/profile.md` (target users, positioning), `gspec/style.md` (design system), `gspec/stack.md` (technology choices), and `gspec/practices.md` (development standards) to resolve project-specific context.

package/starters/features/contact-page.md

@@ -0,0 +1,103 @@
+---
+gspec-version: 1.8.0
+description: Contact page layout with form, location map, and business info
+---
+
+# Contact Page
+
+## Overview
+
+A static Contact page that displays the business's contact information so visitors can easily find how to get in touch. Without a clear, dedicated contact page, prospective clients may leave the site rather than search for scattered contact details — making this a critical conversion-support page.
+
+## Users & Use Cases
+
+**Primary users:** Prospective clients ready to reach out to the business.
+
+**Key use cases:**
+
+1. A prospective client has reviewed the services and about page and is now ready to make contact — they navigate to the Contact page to find an email address or phone number.
+2. A visitor needs the business's physical address to visit in person or send correspondence.
+3. A returning client needs to quickly look up the business's phone number or email without digging through old communications.
+
+## Scope
+
+**In scope:**
+
+- Display of core contact details: email address, phone number, and physical address
+- Clear, scannable layout that makes each contact method immediately visible
+- Responsive layout that works across desktop, tablet, and mobile devices
+- Static content coded directly into the page
+
+**Out of scope:**
+
+- Contact form or message submission functionality (separate feature)
+- Embedded map or location visualization
+- Live chat, chatbot, or real-time messaging
+- Social media links or feeds
+- Business hours display
+- CMS-managed or dynamically loaded content
+
+**Deferred ideas:**
+
+- Embedded interactive map showing the business location
+- Business hours section
+- Social media profile links
+- Multiple office or branch locations
+
+## Capabilities
+
+- [ ] **P0**: Page displays the business email address
+  - Email address is visible without scrolling on desktop viewports
+  - Email is rendered as a clickable `mailto:` link that opens the visitor's default email client
+  - Email address is displayed as readable text (not hidden behind an icon or "Email Us" label alone)
+
+- [ ] **P0**: Page displays the business phone number
+  - Phone number is visible and formatted for readability
+  - Phone number is rendered as a clickable `tel:` link that initiates a call on mobile devices
+  - Phone number is displayed as readable text
+
+- [ ] **P0**: Page displays the business physical address
+  - Full mailing address is displayed in a standard, readable format
+  - Address is presented as plain text (not solely as an image)
+
+- [ ] **P0**: Page is fully responsive across common device sizes
+  - Layout adapts cleanly to desktop (1024px+), tablet (768px), and mobile (375px) viewports
+  - No horizontal scrolling on any viewport
+  - Contact details remain legible and tappable at all sizes
+
+- [ ] **P1**: Contact details are scannable and visually organized
+  - Each contact method (email, phone, address) is visually distinct and separated
+  - A visitor can identify all available contact methods within 5 seconds of viewing the page
+  - Clear labels or headings distinguish each contact method
+
+- [ ] **P2**: Semantic page structure supports accessibility
+  - Page uses proper heading hierarchy (single h1, logical h2/h3 nesting)
+  - Interactive elements (links) are keyboard-navigable and have accessible labels
+  - Sufficient color contrast for all text elements
+
+## Dependencies
+
+- **Home Page** ([home-page.md](home-page.md)): The Contact page is a secondary page that visitors typically navigate to from the home page. Navigation between pages should be consistent.
+
+## Assumptions & Risks
+
+**Assumptions:**
+
+- The business has a single set of contact details (one email, one phone number, one address) to display.
+- Contact information is stable and changes infrequently; developer-managed updates are acceptable.
+- Static content is acceptable for the initial version.
+
+**Key risks:**
+
+- **Content readiness:** The page requires finalized contact details before launch. Mitigation: use realistic placeholder content during development so layout and structure can be validated independently.
+- **Spam exposure:** Displaying email addresses and phone numbers as plain text exposes them to automated scraping. Mitigation: accept this tradeoff for usability in the initial version; obfuscation techniques can be added later if spam becomes a problem.
+
+## Success Metrics
+
+1. Visitors can identify at least one contact method (email, phone, or address) within 5 seconds of viewing the page.
+2. The page renders correctly and is fully usable across desktop, tablet, and mobile viewports.
+3. All clickable contact methods (`mailto:` and `tel:` links) function correctly on their respective devices.
+
+## Implementation Context
+
+> This feature PRD is portable and project-agnostic. During implementation, consult the project's `gspec/profile.md` (target users, positioning), `gspec/style.md` (design system), `gspec/stack.md` (technology choices), and `gspec/practices.md` (development standards) to resolve project-specific context.

package/starters/features/home-page.md

@@ -0,0 +1,103 @@
+---
+gspec-version: 1.8.0
+description: Hero section, service highlights, testimonials, and CTA
+---
+
+# Home Page
+
+## Overview
+
+A home page for a professional services business that introduces the brand, communicates its value proposition, and presents its service offerings. The page serves as the primary entry point for prospective clients researching the business, giving them enough information to understand what the firm does and why it is credible.
+
+## Users & Use Cases
+
+**Primary users:** Prospective clients visiting the website for the first time.
+
+**Key use cases:**
+
+1. A prospective client arrives from a search engine and needs to quickly understand what the business does and whether it is relevant to their needs.
+2. A referral visits the site to validate the recommendation they received, looking for professionalism and evidence of expertise.
+3. A returning visitor navigates back to the home page to review service offerings before engaging further.
+
+## Scope
+
+**In scope:**
+
+- Hero banner section with headline, supporting text, and optional imagery
+- Value proposition section summarizing the firm's core differentiators
+- Services overview section listing the primary service offerings with brief descriptions
+- Responsive layout that works across desktop, tablet, and mobile devices
+- Static content coded directly into the page
+
+**Out of scope:**
+
+- Calls-to-action, buttons, or conversion flows (handled by a separate feature)
+- Blog, news, or dynamic content feeds
+- Client portal or authenticated experiences
+- Search engine optimization tooling or analytics integration
+
+**Deferred ideas:**
+
+- Testimonials or social proof section
+- Team or leadership section
+- Partner or client logo bar
+- Animation or scroll-based interactions
+
+## Capabilities
+
+- [ ] **P0**: Hero banner displays a prominent headline and supporting text that communicates what the business does
+  - Headline and supporting text are visible immediately on page load without scrolling
+  - Text is legible across viewport sizes (desktop, tablet, mobile)
+  - Section accommodates an optional background image or visual element
+
+- [ ] **P0**: Value proposition section presents 2-4 core differentiators of the business
+  - Each differentiator has a short title and brief description
+  - Differentiators are visually distinct and scannable (not a wall of text)
+  - Section is visually separated from the hero and services sections
+
+- [ ] **P0**: Services overview section lists the primary service offerings
+  - Each service has a name and a brief description (1-3 sentences)
+  - Services are presented in a consistent, repeatable layout pattern
+  - The section accommodates 3-6 service items without feeling cluttered
+
+- [ ] **P0**: Page is fully responsive across common device sizes
+  - Layout adapts cleanly to desktop (1024px+), tablet (768px), and mobile (375px) viewports
+  - No horizontal scrolling on any viewport
+  - Text remains readable and images scale appropriately at all sizes
+
+- [ ] **P1**: Page loads quickly with static content
+  - Page is usable within 2 seconds on a standard broadband connection
+  - Images are appropriately sized and optimized for web delivery
+
+- [ ] **P2**: Semantic page structure supports accessibility
+  - Page uses proper heading hierarchy (single h1, logical h2/h3 nesting)
+  - Images include descriptive alt text
+  - Content is navigable via keyboard
+
+## Dependencies
+
+None. This is a foundational page with no dependencies on other features.
+
+## Assumptions & Risks
+
+**Assumptions:**
+
+- The business has established branding (name, logo, colors) available for use.
+- Service offerings are defined and can be summarized in 1-3 sentences each.
+- Static content is acceptable for the initial version; content updates will be infrequent and handled by developers.
+
+**Key risks:**
+
+- **Content readiness:** The page cannot launch without finalized copy for the hero, value proposition, and services sections. Mitigation: use realistic placeholder content during development so layout and structure can be validated independently.
+- **Scope creep into conversion flows:** Without clear CTAs, stakeholders may push to add contact forms or booking widgets to this feature. Mitigation: CTA functionality is explicitly scoped to a separate feature.
+
+## Success Metrics
+
+1. Visitors can identify the business name, what it does, and its core services within 10 seconds of landing on the page.
+2. The page renders correctly and is fully usable across desktop, tablet, and mobile viewports.
+3. Page load time is under 2 seconds on a standard broadband connection.
+4. All content sections (hero, value proposition, services) are present and display without layout issues.
+
+## Implementation Context
+
+> This feature PRD is portable and project-agnostic. During implementation, consult the project's `gspec/profile.md` (target users, positioning), `gspec/style.md` (design system), `gspec/stack.md` (technology choices), and `gspec/practices.md` (development standards) to resolve project-specific context.

package/starters/features/responsive-navbar.md

@@ -0,0 +1,113 @@
+---
+gspec-version: 1.8.0
+description: Responsive navigation bar with mobile hamburger menu
+---
+
+# Responsive Navbar
+
+## Overview
+
+A persistent, top-of-viewport navigation bar that anchors the site identity on the left and presents navigation destinations on the right, adapting its layout across viewport sizes. Without a consistent navigation element, visitors must rely on back buttons or memorized URLs to move between pages — increasing friction and reducing discoverability of key sections.
+
+## Users & Use Cases
+
+**Primary users:** All site visitors navigating between pages.
+
+**Key use cases:**
+
+1. A first-time visitor lands on any page and uses the navbar to discover and navigate to other sections of the site without scrolling back to the top or returning to the home page.
+2. A visitor on a mobile device taps the hamburger menu to access the full set of navigation destinations that would otherwise not fit in the narrow viewport.
+3. A visitor on any page clicks the site identity (icon/name) in the navbar to return to the home page as a familiar orientation point.
+4. A visitor scrolls down a long page and uses the pinned navbar to navigate elsewhere without scrolling back to the top.
+
+## Scope
+
+**In scope:**
+
+- Site identity element (icon and/or name) pinned to the left side of the navbar, functioning as a home link
+- Horizontal navigation links displayed on the right side at wider viewports
+- Hamburger menu trigger that replaces the horizontal links at narrow viewports, revealing a flat list of all navigation destinations
+- Sticky positioning so the navbar remains visible during scrolling
+- Responsive transition between expanded links and collapsed hamburger menu
+
+**Out of scope:**
+
+- Context-aware action slots (edit/view toggles, page-specific controls) — handled by individual page features
+- Nested or multi-level dropdown menus within the hamburger
+- Search bar or search functionality within the navbar
+- User account controls, login/logout, or authentication-related UI
+- Notification badges or indicators
+- Breadcrumb navigation
+
+**Deferred ideas:**
+
+- Animated transitions for hamburger menu open/close
+- Active state highlighting for the current page's link
+- Dropdown sub-menus for grouped navigation at desktop widths
+- Secondary navbar or sub-navigation bar below the primary navbar
+
+## Capabilities
+
+- [ ] **P0**: Site identity element is displayed on the left side of the navbar and links to the home page
+  - An icon, name, or combination of both is visible on the left edge of the navbar at all viewport sizes
+  - Clicking or tapping the identity element navigates to the home page
+  - The identity element has an accessible label describing its purpose as a home link
+
+- [ ] **P0**: Navigation destinations are displayed as horizontal links on the right side at wide viewports
+  - All defined navigation destinations are visible as individual, clickable links
+  - Links are displayed in a consistent, stable order
+  - Each link navigates to the correct destination page
+
+- [ ] **P0**: Navigation destinations collapse into a hamburger menu at narrow viewports
+  - A recognizable hamburger icon (three horizontal lines or equivalent) replaces the horizontal links below a defined breakpoint
+  - Tapping the hamburger icon reveals a flat list of all navigation destinations
+  - Tapping a destination in the list navigates to that page
+  - Tapping the hamburger icon again or navigating away closes the menu
+
+- [ ] **P0**: Navbar remains pinned to the top of the viewport during scrolling
+  - The navbar stays visible at the top of the screen as the user scrolls down the page
+  - Page content scrolls beneath the navbar without overlapping or obscuring it
+  - The navbar does not cause content at the top of the page to be hidden behind it on initial load
+
+- [ ] **P0**: Navbar is fully responsive across common device sizes
+  - Layout adapts cleanly to desktop (1024px+), tablet (768px), and mobile (375px) viewports
+  - The site identity element remains visible and legible at all sizes
+  - No horizontal scrolling is introduced by the navbar at any viewport width
+
+- [ ] **P1**: Hamburger menu is accessible to keyboard and screen reader users
+  - The hamburger trigger is keyboard-focusable and activatable via Enter or Space
+  - The expanded menu can be navigated with keyboard (Tab, Escape to close)
+  - The trigger has an accessible label (e.g., "Navigation menu") that communicates its purpose
+  - Screen readers announce the expanded/collapsed state of the menu
+
+- [ ] **P2**: Navigation destination order remains stable across viewport transitions
+  - The sequence of links in the expanded horizontal layout matches the sequence in the hamburger menu
+  - Resizing the viewport does not reorder or drop navigation destinations
+
+## Dependencies
+
+- **Home Page** ([home-page.md](home-page.md)): The site identity element links to the home page; the home page must exist as a navigation destination.
+
+## Assumptions & Risks
+
+**Assumptions:**
+
+- The site has a defined identity (icon, name, or both) available for use in the navbar.
+- Navigation destinations are statically defined and change infrequently; developer-managed updates are acceptable.
+- The number of navigation destinations is small enough (3-6 items) that a flat list in the hamburger menu is sufficient without grouping or nesting.
+
+**Key risks:**
+
+- **Content overflow at medium viewports:** If the number of navigation links grows, the horizontal layout may overflow before reaching the narrow-viewport breakpoint. Mitigation: define the responsive breakpoint based on content width rather than a fixed pixel value, or set a maximum number of supported links in the horizontal layout.
+- **Sticky positioning conflicts:** The pinned navbar may conflict with other fixed or sticky elements on the page (e.g., cookie banners, chat widgets). Mitigation: establish a clear stacking order convention so the navbar's layer priority is predictable.
+
+## Success Metrics
+
+1. Visitors can navigate to any primary page from any other page using the navbar without scrolling to the top of the page.
+2. The navbar renders correctly with site identity visible and links accessible across desktop, tablet, and mobile viewports.
+3. On narrow viewports, the hamburger menu reveals all navigation destinations and each link functions correctly.
+4. The navbar remains visible and functional during page scroll on all supported viewport sizes.
+
+## Implementation Context
+
+> This feature PRD is portable and project-agnostic. During implementation, consult the project's `gspec/profile.md` (target users, positioning), `gspec/style.md` (design system), `gspec/stack.md` (technology choices), and `gspec/practices.md` (development standards) to resolve project-specific context.

package/starters/features/services-page.md

@@ -0,0 +1,103 @@
+---
+gspec-version: 1.8.0
+description: Service offerings with descriptions, icons, and pricing tiers
+---
+
+# Services Page
+
+## Overview
+
+A dedicated Services page that presents the business's service offerings in detail beyond the brief overview on the home page. Prospective clients who are evaluating whether the business can meet their specific needs require more than a one-line summary — this page gives each service enough space to communicate what it involves and why it matters, helping visitors self-qualify before making contact.
+
+## Users & Use Cases
+
+**Primary users:** Prospective clients evaluating the business's service offerings in detail.
+
+**Key use cases:**
+
+1. A prospective client clicks through from the home page services overview to understand a specific service in more depth before deciding to reach out.
+2. A visitor comparing multiple firms reviews the Services page to assess breadth and relevance of offerings against their needs.
+3. A referral who was told the business handles a specific type of work visits the Services page to confirm that service is offered and understand what it entails.
+
+## Scope
+
+**In scope:**
+
+- Individual section for each service with a heading and short descriptive paragraph (3-5 sentences)
+- Introductory text at the top of the page framing the overall service offering
+- Support for 3-6 service items
+- Responsive layout that works across desktop, tablet, and mobile devices
+- Static content coded directly into the page
+
+**Out of scope:**
+
+- Pricing, rates, or cost information
+- Calls-to-action, contact forms, or conversion elements (handled by a separate feature)
+- Individual dedicated pages per service
+- Case studies, project examples, or portfolio items tied to services
+- Dynamic or CMS-managed content
+- Filtering, search, or categorization of services
+
+**Deferred ideas:**
+
+- Individual service detail pages linked from each service section
+- Icons or illustrations accompanying each service
+- Client testimonials or case studies associated with specific services
+- Service comparison table or feature matrix
+- FAQ section addressing common questions about the services
+
+## Capabilities
+
+- [ ] **P0**: Page displays an introductory section framing the overall service offering
+  - Section includes a heading and a brief paragraph (1-3 sentences) that sets context for the services listed below
+  - Introductory text is visible immediately on page load without scrolling on desktop viewports
+  - Section is visually distinct from the individual service sections
+
+- [ ] **P0**: Each service is presented with a heading and descriptive paragraph
+  - Each service has a clear, distinct heading (service name)
+  - Each service includes a descriptive paragraph of 3-5 sentences explaining what the service involves and the value it provides
+  - Services are presented in a consistent, repeatable layout pattern
+  - The page accommodates 3-6 services without feeling cluttered or requiring excessive scrolling
+
+- [ ] **P0**: Page is fully responsive across common device sizes
+  - Layout adapts cleanly to desktop (1024px+), tablet (768px), and mobile (375px) viewports
+  - No horizontal scrolling on any viewport
+  - Text remains readable and sections are well-spaced at all sizes
+
+- [ ] **P1**: Services are visually scannable and well-structured
+  - A visitor can identify all available services by name within 10 seconds of viewing the page
+  - Each service section is visually separated from adjacent sections with adequate spacing
+  - Clear visual hierarchy distinguishes service headings from descriptive text
+
+- [ ] **P2**: Semantic page structure supports accessibility
+  - Page uses proper heading hierarchy (single h1, logical h2/h3 nesting)
+  - Content is navigable via keyboard
+  - Sufficient color contrast for all text elements
+
+## Dependencies
+
+- **Home Page** ([home-page.md](home-page.md)): The home page includes a services overview section. The Services page expands on that overview. Navigation between pages should be consistent, and the home page services section should link to this page for visitors wanting more detail.
+
+## Assumptions & Risks
+
+**Assumptions:**
+
+- The business has 3-6 defined service offerings that can each be described in 3-5 sentences.
+- Service offerings are stable and change infrequently; developer-managed updates are acceptable.
+- The brief home page services overview is sufficient as a summary, and this page serves as the next level of detail without needing individual service pages.
+
+**Key risks:**
+
+- **Content readiness:** Each service requires a descriptive paragraph beyond what the home page provides. Mitigation: use realistic placeholder content during development so layout and structure can be validated independently.
+- **Redundancy with home page:** Visitors may feel the Services page duplicates the home page overview if the additional detail is not meaningfully different. Mitigation: ensure the home page overview uses shorter summaries (1-2 sentences) while this page provides fuller descriptions (3-5 sentences) with distinct value-oriented content.
+
+## Success Metrics
+
+1. Visitors can identify all available services by name within 10 seconds of viewing the page.
+2. Each service description provides enough detail that a visitor can determine whether the service is relevant to their needs without contacting the business.
+3. The page renders correctly and is fully usable across desktop, tablet, and mobile viewports.
+4. All service sections display in a consistent layout without visual issues or excessive whitespace.
+
+## Implementation Context
+
+> This feature PRD is portable and project-agnostic. During implementation, consult the project's `gspec/profile.md` (target users, positioning), `gspec/style.md` (design system), `gspec/stack.md` (technology choices), and `gspec/practices.md` (development standards) to resolve project-specific context.