gspec 1.10.0 → 1.13.0

package/dist/cursor/gspec-stack.mdc

@@ -21,10 +21,10 @@ You should:
 
 - Output **ONLY** a single Markdown document
 - Save the file as `gspec/stack.md` in the root of the project, create the `gspec` folder if it doesn't exist
-- Begin the file with YAML frontmatter containing the gspec version:
+- Begin the file with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/cursor/gspec-style.mdc

@@ -23,10 +23,10 @@ You should:
 
 - Output **ONLY** a single Markdown document
 - Save the file as `gspec/style.md` in the root of the project, create the `gspec` folder if it doesn't exist
-- Begin the file with YAML frontmatter containing the gspec version:
+- Begin the file with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/opencode/gspec-analyze/SKILL.md

@@ -128,7 +128,7 @@ When updating specs to resolve a discrepancy:
 
 - **Surgical updates only** — change the minimum text needed to resolve the conflict
 - **Preserve format and tone** — match the existing document's style, heading structure, and voice
-- **Preserve `gspec-version` frontmatter** — do not alter or remove it
+- **Preserve `spec-version` frontmatter** — do not alter or remove it
 - **Do not rewrite sections** — if a one-line change resolves the conflict, make a one-line change
 - **Do not add changelog annotations** — the git history captures what changed
 

package/dist/opencode/gspec-architect/SKILL.md

@@ -42,10 +42,10 @@ All of these provide essential context. If any are missing, note the gap and mak
 
 - Output **ONLY** a single Markdown document
 - Save the file as `gspec/architecture.md` in the root of the project, create the `gspec` folder if it doesn't exist
-- Begin the file with YAML frontmatter containing the gspec version:
+- Begin the file with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/opencode/gspec-feature/SKILL.md

@@ -82,10 +82,10 @@ Feature PRDs are designed to be **portable across projects**. A feature spec wri
 - Output one or more Markdown documents — **one per feature**
 - Save each file to the `gspec/features/` folder in the root of the project, create it if it doesn't exist
 - Name each file based on the feature (e.g., `user-authentication.md`, `dashboard-analytics.md`)
-- Begin each file with YAML frontmatter containing the gspec version:
+- Begin each file with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/opencode/gspec-implement/SKILL.md

@@ -62,8 +62,9 @@ Present this summary to the user so they understand the starting point. If **all
    - Identify files to create or modify
    - Note dependencies on prior phases
    - Include an estimated scope (small/medium/large)
-3. **Define test expectations per phase** — For each phase, specify what tests will be run to verify correctness before moving on (unit tests, integration tests, build verification, etc.)
-4. **Present the plan** — Show the user the full phased plan with clear phase boundaries and ask for approval
+3. **Account for every unchecked capability** — The plan must explicitly place every unchecked capability from in-scope feature PRDs into a phase **or** list it under a "Proposed to Defer" section with a reason. No unchecked capability may be silently omitted from the plan. The user reviews and approves what gets deferred at plan approval time.
+4. **Define test expectations per phase** — For each phase, specify what tests will be run to verify correctness before moving on (unit tests, integration tests, build verification, etc.)
+5. **Present the plan** — Show the user the full phased plan with clear phase boundaries and ask for approval
 
 **Wait for user approval before proceeding to Phase 3.** The user may reorder phases, adjust scope, or split/merge phases.
 
@@ -109,7 +110,7 @@ Present a brief scaffold summary to the user before proceeding to feature implem
    b. **Follow the practices** — Adhere to coding standards, testing philosophy, pipeline structure, and conventions from `gspec/practices.md`
    c. **Follow the style** — Apply the design system, tokens, and icon library from `gspec/style.md`. The style is the single authority for icon library choices. Component libraries (e.g., shadcn/ui) are defined in `gspec/stack.md`.
    d. **Satisfy the requirements** — Trace each piece of code back to a functional requirement in the feature PRD (if available) or to the user's stated goals and the approved implementation plan
-3. **Mark capabilities as implemented** — After successfully implementing each capability, immediately update the feature PRD by changing its checkbox from `- [ ]` to `- [x]`. Do this incrementally as each capability is completed, not in a batch at the end. If a capability line did not have a checkbox prefix, add one as `- [x]`. This ensures that if the session is interrupted, progress is not lost. When updating gspec files, preserve existing `gspec-version` YAML frontmatter. If a file lacks frontmatter, add `---\ngspec-version: 1.10.0\n---` at the top.
+3. **Mark capabilities as implemented** — After successfully implementing each capability, immediately update the feature PRD by changing its checkbox from `- [ ]` to `- [x]`. Do this incrementally as each capability is completed, not in a batch at the end. If a capability line did not have a checkbox prefix, add one as `- [x]`. This ensures that if the session is interrupted, progress is not lost. When updating gspec files, preserve existing `spec-version` YAML frontmatter. If a file lacks frontmatter, add `---\nspec-version: v1\n---` at the top.
 4. **Run tests** — Execute the tests defined for this phase (and any existing tests to catch regressions). Fix any failures before proceeding.
 6. **Surface new gaps** — If implementation reveals new ambiguities, pause and consult the user rather than making silent assumptions
 7. **Pause and report** — After completing the phase and confirming tests pass, present a phase completion summary to the user:
@@ -129,8 +130,8 @@ After implementation:
 1. **Walk through each functional requirement** from the feature PRD (if available) or the approved implementation plan and confirm it's satisfied
 2. **Review against acceptance criteria** — For each capability in the feature PRDs, check that every acceptance criterion listed under it is satisfied. These sub-listed conditions are the definition of "done" for each capability. If any criterion is not met, the capability should not be marked `[x]`.
 3. **Check the Definition of Done** from `gspec/practices.md`
-4. **Note any deferred items** — Requirements that were intentionally postponed or descoped during implementation
-5. **Verify checkbox accuracy** — Confirm that every capability marked `[x]` in the feature PRDs is genuinely implemented and working. Confirm that capabilities left as `[ ]` were intentionally deferred. Present a final status summary:
+4. **Verify no unapproved deferrals** — Compare the final implementation against the approved plan. If any capability that was assigned to a phase was not implemented, **do not silently leave it unchecked**. Flag it to the user, explain why it wasn't completed, and get explicit approval before marking it as deferred. Only capabilities the user approved for deferral during planning (or explicitly approves now) may remain unchecked.
+5. **Verify checkbox accuracy** — Confirm that every capability marked `[x]` in the feature PRDs is genuinely implemented and working. Confirm that capabilities left as `[ ]` were approved for deferral by the user. Present a final status summary:
 
 > **Implementation Summary:**
 > - Feature X: 7/7 capabilities implemented (complete)
@@ -149,6 +150,7 @@ When you encounter something the specs don't fully cover during implementation:
 - **If the ambiguity is significant** (e.g., unclear user flow, missing data model, conflicting requirements), pause and consult the user rather than making silent assumptions
 - **Never silently implement unspecified behavior** that contradicts or significantly extends the original spec — ask first
 - **Never override explicit spec decisions** with your own preferences
+- **Never skip or descope a PRD capability without user approval** — ambiguity in *how* to implement something is not grounds for dropping it. If a capability seems too complex, unclear, or problematic, raise it with the user rather than omitting it
 
 ---
 
@@ -178,7 +180,7 @@ If the user specifies a feature, focus on that feature's **unchecked capabilitie
 
 ### When the user provides a prompt alongside existing features:
 
-The user's prompt takes priority for scoping. Use it to determine focus, and reference existing feature PRDs as supporting context rather than the sole driver.
+The user's prompt takes priority for scoping. Use it to determine focus, and reference existing feature PRDs as supporting context rather than the sole driver. However, if the user's prompt narrows scope such that some unchecked PRD capabilities will not be implemented this run, explicitly list those excluded capabilities in the plan under "Out of Scope for This Run" so the user can see what is being deferred and why.
 
 ---
 

package/dist/opencode/gspec-migrate/SKILL.md

@@ -5,7 +5,7 @@ description: Migrate existing gspec files to the current format when upgrading t
 
 You are a Technical Documentation Migration Specialist.
 
-Your task is to update existing gspec specification documents to match the current gspec format (version 1.10.0). You preserve all substantive content while ensuring documents follow the latest structural conventions.
+Your task is to update existing gspec specification documents to match the current spec format (spec-version v1). You preserve all substantive content while ensuring documents follow the latest structural conventions.
 
 ---
 
@@ -19,16 +19,17 @@ Scan the `gspec/` directory for all Markdown files:
 
 
 For each file, check the YAML frontmatter at the top of the file:
-- If the file starts with `---` followed by YAML content and another `---`, read the `gspec-version` field
+- If the file starts with `---` followed by YAML content and another `---`, read the `spec-version` field (also check for the legacy `gspec-version` field)
 - If no frontmatter exists, the file predates version tracking
-- If `gspec-version` matches `1.10.0`, the file is current — skip it
+- If `spec-version` matches `v1`, the file is current — skip it
+- If the file has `gspec-version` (old field name) instead of `spec-version`, it needs migration regardless of value
 
 Present an inventory to the user:
 
 > **gspec File Inventory:**
 > - `gspec/profile.md` — no version (needs migration)
-> - `gspec/stack.md` — version 1.0.3 (needs migration)
-> - `gspec/style.md` — version 1.10.0 (current, skipping)
+> - `gspec/stack.md` — gspec-version 1.0.3 (needs migration — old field name)
+> - `gspec/style.md` — spec-version v1 (current, skipping)
 > - `gspec/features/user-auth.md` — no version (needs migration)
 
 Ask the user to confirm which files to migrate, or confirm all.
@@ -63,21 +64,22 @@ For each file to migrate:
 5. **Add or update the frontmatter** — Ensure the file starts with:
    ```
    ---
-   gspec-version: 1.10.0
+   spec-version: v1
    ---
    ```
+   If the file has the old `gspec-version` field, rename it to `spec-version` and set the value to `v1`.
 6. **Present the proposed changes** to the user before writing. Show what sections are being reorganized, what is being added, and confirm no content is being lost.
 
 ### Phase 4: Verify — Confirm Migration
 
 After migrating all files:
 
-1. **Verify every migrated file** has the correct frontmatter
+1. **Verify every migrated file** has the correct frontmatter (`spec-version: v1`)
 2. **Verify no content was lost** — Briefly summarize what was preserved and any content that was relocated
 3. **Present a completion summary**:
 
 > **Migration Complete:**
-> - 4 files migrated to version 1.10.0
+> - 4 files migrated to spec-version v1
 > - 2 files were already current (skipped)
 > - Content preserved in all files
 > - Sections reorganized: [list any structural changes]
@@ -100,8 +102,9 @@ After migrating all files:
 
 **Frontmatter handling:**
 - If the file has no frontmatter, add it at the very top
-- If the file has frontmatter without `gspec-version`, add the field
-- If the file has an outdated `gspec-version`, update it
+- If the file has the old `gspec-version` field, rename it to `spec-version`
+- If the file has frontmatter without `spec-version`, add the field
+- If the file has an outdated `spec-version`, update it
 - Preserve any other frontmatter fields that may exist
 
 ---

package/dist/opencode/gspec-practices/SKILL.md

@@ -22,10 +22,10 @@ You should:
 
 - Output **ONLY** a single Markdown document
 - Save the file as `gspec/practices.md` in the root of the project, create the `gspec` folder if it doesn't exist
-- Begin the file with YAML frontmatter containing the gspec version:
+- Begin the file with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/opencode/gspec-profile/SKILL.md

@@ -22,10 +22,10 @@ You should:
 
 - Output **ONLY** a single Markdown document
 - Save the file as `gspec/profile.md` in the root of the project, create the `gspec` folder if it doesn't exist
-- Begin the file with YAML frontmatter containing the gspec version:
+- Begin the file with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/opencode/gspec-research/SKILL.md

@@ -162,7 +162,7 @@ After writing `gspec/research.md`, ask the user:
    - Assumptions & Risks (assumptions, open questions, key risks and mitigations)
    - Success Metrics
    - Implementation Context (standard portability note)
-   - Begin the file with YAML frontmatter: `---\ngspec-version: 1.10.0\n---`
+   - Begin the file with YAML frontmatter: `---\nspec-version: v1\n---`
 2. **Name the file** descriptively based on the feature (e.g., `gspec/features/csv-export.md`, `gspec/features/onboarding-wizard.md`)
 3. **Keep the PRD portable** — use generic role descriptions (not project-specific persona names), define success metrics in terms of the feature's own outcomes (not project-level KPIs), and describe UX behavior generically (not tied to a specific design system). The PRD should be reusable across projects.
 4. **Keep the PRD product-focused** — describe *what* and *why*, not *how*. Implementation details belong in the code, not the PRD.
@@ -178,10 +178,10 @@ After writing `gspec/research.md`, ask the user:
 
 - Save the primary output as `gspec/research.md` in the root of the project, create the `gspec` folder if it doesn't exist
 - If the user accepts feature generation (Phase 7), also save feature PRDs to `gspec/features/`
-- Begin `gspec/research.md` with YAML frontmatter containing the gspec version:
+- Begin `gspec/research.md` with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.
@@ -198,7 +198,7 @@ The `gspec/research.md` file must follow this structure:
 
 ```markdown
 ---
-gspec-version: 1.10.0
+spec-version: v1
 ---
 
 # Competitive Research

package/dist/opencode/gspec-stack/SKILL.md

@@ -22,10 +22,10 @@ You should:
 
 - Output **ONLY** a single Markdown document
 - Save the file as `gspec/stack.md` in the root of the project, create the `gspec` folder if it doesn't exist
-- Begin the file with YAML frontmatter containing the gspec version:
+- Begin the file with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/dist/opencode/gspec-style/SKILL.md

@@ -24,10 +24,10 @@ You should:
 
 - Output **ONLY** a single Markdown document
 - Save the file as `gspec/style.md` in the root of the project, create the `gspec` folder if it doesn't exist
-- Begin the file with YAML frontmatter containing the gspec version:
+- Begin the file with YAML frontmatter containing the spec version:
   ```
   ---
-  gspec-version: 1.10.0
+  spec-version: v1
   ---
   ```
   The frontmatter must be the very first content in the file, before the main heading.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "gspec",
-    "version": "1.10.0",
+    "version": "1.13.0",
     "description": "Install gspec specification commands for Claude Code, Cursor, and other AI tools",
     "main": "bin/gspec.js",
     "type": "module",
@@ -12,7 +12,6 @@
         "dist/",
         "commands/",
         "templates/",
-        "starters/",
         "README.md"
     ],
     "scripts": {

package/templates/spec-sync.md

@@ -21,6 +21,6 @@ These specs define what the product is, how it should look, what technology it u
 
 5. **Announce spec updates** — When you update a spec, briefly mention what changed and why in your response. Never silently modify specs.
 
-6. **Preserve frontmatter** — gspec files use YAML frontmatter with a `gspec-version` field. Preserve it when editing. If a file lacks frontmatter, leave it as-is.
+6. **Preserve frontmatter** — gspec files use YAML frontmatter with a `spec-version` field. Preserve it when editing. If a file lacks frontmatter, leave it as-is.
 
 7. **Don't create new foundation specs** — Only update existing spec files. If you believe a new spec document is needed, suggest it to the user rather than creating it yourself.

package/starters/features/about-page.md

@@ -1,98 +0,0 @@
----
-gspec-version: 1.8.0
-description: Company story, mission, team bios, and values section
----
-
-# About Page
-
-## Overview
-
-A static About page that tells the story of the business and communicates its mission. The page gives visitors a sense of who is behind the brand, why the business exists, and what it stands for — building trust and credibility beyond the service offerings presented on the home page.
-
-## Users & Use Cases
-
-**Primary users:** Prospective clients evaluating the business before making contact.
-
-**Key use cases:**
-
-1. A prospective client wants to understand the people and values behind the business before deciding to engage, so they visit the About page to assess credibility and alignment.
-2. A referral wants to learn more about the company's background and story to confirm the recommendation they received.
-3. A visitor who has reviewed the services offered navigates to the About page to understand the mission and philosophy that drives those services.
-
-## Scope
-
-**In scope:**
-
-- Company story section explaining the background and origin of the business
-- Mission or purpose statement section articulating why the business exists and what it stands for
-- Responsive layout that works across desktop, tablet, and mobile devices
-- Static content coded directly into the page
-
-**Out of scope:**
-
-- Team member bios, headshots, or leadership profiles
-- Calls-to-action, contact forms, or conversion elements
-- Company timeline or milestones visualization
-- Client testimonials or social proof
-- Dynamic or CMS-managed content
-
-**Deferred ideas:**
-
-- Team or leadership section with bios and photos
-- Company values displayed as distinct visual cards or icons
-- Historical timeline or key milestones section
-- Awards, certifications, or accreditations display
-
-## Capabilities
-
-- [ ] **P0**: Company story section communicates the background and origin of the business
-  - Section includes a heading and one or more paragraphs of narrative text
-  - Content is readable and well-structured without feeling like a wall of text
-  - Section is visually distinct from the mission section
-
-- [ ] **P0**: Mission or purpose statement section articulates why the business exists
-  - Mission statement is presented with visual emphasis (e.g., larger text, distinct styling) to differentiate it from the narrative story
-  - Statement is concise and scannable — ideally 1-3 sentences
-  - Section is visually separated from the company story section
-
-- [ ] **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 at all sizes
-
-- [ ] **P1**: Page structure supports scannability
-  - Clear visual hierarchy guides the visitor through the content in a logical order
-  - Sections are separated with adequate spacing to avoid a dense, text-heavy appearance
-  - Page can be skimmed in under 15 seconds to get the gist of the business
-
-- [ ] **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 About 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 defined story or background narrative that can be summarized for the page.
-- A mission or purpose statement exists or can be drafted prior to implementation.
-- Static content is acceptable; content updates will be infrequent and handled by developers.
-
-**Key risks:**
-
-- **Content readiness:** The page depends on finalized copy for the company story and mission statement. Mitigation: use realistic placeholder content during development so layout and structure can be validated independently.
-- **Text-heavy appearance:** An About page with only narrative content can feel dense and uninviting. Mitigation: ensure the design uses adequate spacing, visual hierarchy, and section separation to maintain readability.
-
-## Success Metrics
-
-1. Visitors can identify the company's story and mission within 15 seconds of viewing the page.
-2. The page renders correctly and is fully usable across desktop, tablet, and mobile viewports.
-3. Content is structured into clearly distinct sections (story and mission) with visible separation.
-
-## 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-form.md

@@ -1,147 +0,0 @@
----
-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.