diff --git a/README.md b/README.md
index 8875daf2..0fdb9fe8 100644
--- a/README.md
+++ b/README.md
@@ -1,628 +1,121 @@
-# Astro Starter Kit: Basics
+# Webstack Builders Corporate Website
 
-@TODO: See NOTES.md, this file is split between here and there. Consider using Nightwatch instead of Playwright for e2e testing.
+Production corporate website built with [Astro](https://astro.build), deployed on Vercel. This repo reflects how I approach production systems: strict code boundaries, layered quality gates, GDPR-compliant data handling, and tested infrastructure from the markdown pipeline through to transactional email.
 
-@TODO: See here for utility components like shortcodes: <https://docs.astro.build/en/reference/api-reference/#astroslotsrender>
+## What's Different About This Repo
 
-## Contributing & Git Workflow
+Most Astro sites are content-only. This one runs a full backend (Astro Actions, Turso/SQLite, Sentry, GDPR consent tracking, transactional email) alongside a content pipeline with 30+ remark/rehype plugins, all enforced by custom ESLint rules, multi-tier testing, and 12 CI/CD workflows.
 
-This repository uses branch protection and automated quality checks. See [docs/GIT_WORKFLOW.md](./docs/GIT_WORKFLOW.md) for complete details.
+## Architecture Highlights
 
-**Quick Start:**
+### Strict Client/Server Code Segregation
 
-```bash
-# Create a feature branch (required - cannot commit to main)
-git checkout -b feature/your-feature-name
-
-# Make changes and commit (hooks will run automatically)
-git commit -m "Your message"
-
-# Push and create a Pull Request
-git push -u origin feature/your-feature-name
-```
-
-**Branch Naming:**
-
-- `feature/*` - New features
-- `bugfix/*` - Bug fixes
-- `hotfix/*` - Critical production fixes
-- `infrastructure/*` - DevOps/CI/CD changes
-- `maintenance/*` - Dependency updates, refactoring
-- `content/*` - Content updates
-
-**Pre-commit Checks:**
-
-- Unit tests must pass
-- Branch name must follow conventions
-- Cannot commit directly to main
-
-### Local Development Server
-
-Use the helper script below to start Astro with `.env.development` automatically loaded:
-
-```bash
-npm run dev:env
-```
-
-The underlying `npm run dev` command remains unchanged for CI and Vercel; `dev:env` is just a convenience for local shells so API routes that depend on `process.env` (cron handlers, email providers, etc.) behave the same way they do in production.
-
-## Astro DB Workflows
-
-Astro DB schemas now live under `db/config.ts`. Applying those migrations requires `npx astro db push`; the regular `astro build` command never pushes schema changes for you. Keep local and remote pushes separate to avoid promoting unfinished changes:
-
-- **Local development / CI** – Point Astro DB at the file-based database via `ASTRO_DB_REMOTE_URL="file:./.astro/content.db"` and run `npx astro db push`. For convenience the `build:ci` script exports `ASTRO_DATABASE_FILE=./.astro/content.db` before invoking `astro build`, so `npm run build:ci` is the go-to command anywhere you need a build that reads the local snapshot (including GitHub Actions).
-- **Production Turso push** – Export your Turso connection details (`ASTRO_DB_REMOTE_URL` + `ASTRO_DB_APP_TOKEN`) and run `npx astro db push --remote`. The merge-to-main workflow should be the only automation that executes this command.
-- **Vercel deployments** – Set the build command to `npm run build -- --remote` so the build pipeline talks to Turso in read-only mode while still leaving schema promotion to the dedicated workflow.
-
-> `ASTRO_DATABASE_FILE` is evaluated before Astro loads `.env.*`, so put it directly in the shell invocation (e.g., `ASTRO_DATABASE_FILE=./.astro/content.db npm run build`) or reuse the provided `npm run build:ci` helper. Dropping the variable into `.env.development` or `.env.production` will not satisfy the build hook.
-
-### Build scripts
-
-- `npm run build` – Runs `astro build --remote`, hitting the production Turso database in read-only mode. Use this for Vercel deployments and any workflows that need to mirror production infrastructure.
-- `npm run build:ci` – Exports `ASTRO_DATABASE_FILE=./.astro/content.db` before delegating to `npm run build`, forcing the build to read from the local SQLite snapshot. Use this for local testing and the `Test` GitHub workflow so schema changes stay isolated until the Turso push workflow runs.
-
-## Fork PR Preview Deployments
-
-Preview deployments are intentionally restricted to pull requests from branches within this repository (non-fork PRs).
-
-Reason: our deployment pipeline runs in a privileged GitHub Actions context (it uses repository secrets for Vercel and has write permissions for checks/comments). Running those steps against forked PR commits would risk executing untrusted code with access to secrets.
-
-If we ever need fork PR preview deployments, implement a safer design first, such as:
-- Dual-checkout + `working-directory` (trusted checkout for local actions/tooling, untrusted checkout in a separate path for deploy input)
-- Artifact-based deploy (build/test in the untrusted workflow, upload a signed artifact, deploy the artifact in the trusted workflow)
-
-## Coding Standards
-
-### Component Architecture
-
-**Script Organization:**
-
-- Layouts (`src/layouts`) and pages (`src/pages`) must not contain `<script>` tags
-- Components must use `client.ts` for client-side code and `server.ts` for build-time code
-- Helper files in component folders must only be imported via `server.ts` or `client.ts`
-- The `src/lib` directory is exclusively for server-side code
-
-**Client-Side Execution:**
-
-- All client scripts must use the LoadableScript pattern and register with the loader system
-- No direct event listeners or immediate script execution in component templates
-- Component `<script>` tags should only import `client.ts` and call `registerScript()`
-
-**Build-Time Code:**
-
-- `server.ts` files contain functions used during the build process
-- Imports from `src/lib/helpers` are allowed in frontmatter
-- Node modules can be imported for build-time operations
-
-**Exception:** The inline theme script in `src/components/Head/index.astro` intentionally violates these rules to prevent flash of unstyled content (FOUS).
-
-## MDX Components
-
-The project includes custom components that can be used in MDX files for enhanced content:
-
-### Newsletter Signup Component
-
-Use the `<Signup>` component to add a newsletter signup form to your MDX content:
-
-```mdx
-<Signup
-  title="Stay Updated"
-  description="Get the latest articles and insights delivered to your inbox."
-  buttonText="Subscribe"
-  placeholder="Enter your email"
-/>
-```
-
-**Props:**
-
-- `title` (optional): Heading text for the signup form (default: "Newsletter Signup")
-- `description` (optional): Description text below the title (default: "Subscribe to get the latest updates and insights.")
-- `buttonText` (optional): Text for the submit button (default: "Subscribe")
-- `placeholder` (optional): Placeholder text for the email input (default: "Enter your email address")
-- `className` (optional): Additional CSS classes to apply
-
-### Tweet Embed Component
-
-Use the `<X>` component to embed tweets in your MDX content:
-
-```mdx
-<X
-  id="1234567890123456789"
-  author="username"
-  content="This is the tweet content..."
-  date="2024-01-15"
-  avatar="/path/to/avatar.jpg"
-/>
-```
-
-**Props:**
-
-- `id` (required): The tweet ID from the Twitter/X URL
-- `author` (optional): Twitter username (default: "Twitter User")
-- `content` (optional): Tweet text content (default: "Loading tweet...")
-- `date` (optional): Tweet date in YYYY-MM-DD format (default: current date)
-- `avatar` (optional): URL to user's avatar image (default: "/assets/images/default-avatar.png")
-- `className` (optional): Additional CSS classes to apply
-
-**Note:** To use these components in MDX files, make sure to import them at the top of your MDX file:
+Every interactive component follows a `client/` and `server/` folder convention. Client-side Lit web components live in `client/index.ts`; build-time logic lives in `server/index.ts`. The `src/lib/` directory is server-only by rule. This prevents accidental bundling of secrets or server dependencies into client code and makes the boundary auditable at a glance.
 
-```mdx
----
-# Your frontmatter here
----
+### Astro Actions as the Backend Layer
 
-import Signup from '../components/Newsletter/Signup.astro';
-import X from '../components/Tweet/index.astro';
+Server-side behavior uses [Astro Actions](https://docs.astro.build/en/guides/actions/) (`src/actions/`) instead of traditional API endpoints. Each action domain (contact, downloads, GDPR, newsletter, search, webmentions) encapsulates its own Zod validation schemas, domain logic, and error handling. A shared error handler (`actionsFunctionHandler.ts`) provides structured logging, Sentry forwarding with scrubbed PII, and consistent error codes.
 
-# Your Content
+### GDPR Consent and Privacy Architecture
 
-<Signup title="Join Our Newsletter" />
+Cookie consent state is managed via nanostores with persistent localStorage sync across multiple purpose categories (analytics, marketing, functional). Consent events are logged to Astro DB with data subject IDs, user agents, and privacy policy versions for audit compliance. The system includes debounced/coalesced API calls with retry logic, DSAR (Data Subject Access Request) workflows, and double-opt-in newsletter confirmation with expiring tokens.
 
-<X id="1234567890123456789" author="example" content="Check out this amazing post!" />
-```
-
-## Theme System
-
-The project uses a modern CSS custom properties-based theme system that supports light and dark themes, with extensibility for additional themes like seasonal variations.
-
-### Architecture
-
-The theme system consists of two main files that must be kept in sync:
-
-1. **`src/styles/themes.css`** - Pure CSS file containing all theme definitions using CSS custom properties
-2. **`src/lib/themes.ts`** - TypeScript registry defining available themes for the theme picker component
-
-### Adding a New Theme
-
-To add a new theme (e.g., a holiday theme), follow these steps:
-
-#### 1. Add CSS Variables in `src/styles/themes.css`
-
-Add a new CSS rule with the theme's custom colors following the pattern of existing themes in this file.
-
-#### 2. Register Theme in `src/lib/themes.ts`
-
-Add your theme to the themes array:
-
-```javascript
-export const themes = [
-  {
-    id: 'default',
-    name: 'Light',
-    description: 'Clean light theme with blue accents',
-    category: 'core'
-  },
-  {
-    id: 'dark',
-    name: 'Dark',
-    description: 'Dark theme with navy background',
-    category: 'core'
-  },
-  {
-    id: 'holiday',
-    name: 'Holiday',
-    description: 'Festive red and green theme for the holidays',
-    category: 'seasonal',
-    seasonal: true
-  }
-];
-```
-
-#### 3. Theme Properties
-
-Each theme object supports these properties:
-
-- **`id`** (required): Unique identifier used in the `data-theme` attribute
-- **`name`** (required): Display name shown in the theme picker
-- **`description`** (optional): Tooltip description for the theme
-- **`category`** (optional): Used for grouping themes ('core', 'seasonal', etc.)
-- **`seasonal`** (optional): Boolean flag marking temporary/seasonal themes
-
-### Theme Switching
-
-Themes are applied by setting the `data-theme` attribute on the document element:
-
-```javascript
-document.documentElement.setAttribute('data-theme', 'holiday');
-```
-
-The system also respects the user's system preference with `@media (prefers-color-scheme: dark)` for users who haven't explicitly chosen a theme.
-
-## Markdown Content Styling
-
-The project uses a Rehype plugin (`src/lib/markdown/rehype-tailwind-classes.ts`) to automatically apply Tailwind CSS classes to rendered Markdown content. This replaces the previous SCSS-based content styling system.
+### Sentry Integration (Client and Server)
 
-### Supported Markdown Elements
+Client-side Sentry respects GDPR consent before sending PII. The `beforeSend` handler filters known handled errors (downloads, newsletter, consent retries) to reduce noise. Server-side actions report errors with structured context (stage, fingerprint, input shape without raw PII). Source maps are uploaded per release for stack trace resolution.
 
-All standard Markdown elements are automatically styled with appropriate Tailwind classes:
+### Astro DB with Turso
 
-- **Paragraphs**: Proper spacing, readable font size, and line height
-- **Headings**: Typography hierarchy with serif fonts for h1-h3
-- **Links**: Underline effects with hover states
-- **Images/Videos**: Responsive sizing, centering, and shadows
-- **Lists**: Proper indentation and spacing
-- **Code**: Inline code highlighting and block code formatting
-- **Tables**: Full styling with borders and hover effects
-- **Blockquotes**: Left border accent with serif typography
+Schema lives in `db/config.ts` with four tables: `consentEvents`, `rateLimitWindows`, `dsarRequests`, and `newsletterConfirmations`. Composite indexes optimize consent history and GDPR request lookups. Local development uses a file-based SQLite snapshot; production reads from Turso, with schema promotion controlled by a dedicated CI workflow.
 
-### Vendor Plugin Support
+## Reusable Patterns for Astro Projects
 
-The Rehype plugin also handles specialized Markdown-it plugins:
+### Playwright E2E Framework
 
-#### Code Tabs (`code-tabs`)
+The E2E setup uses a page object model (POM) with a `BasePage` base class and domain-specific pages (PWA, Markdown, Newsletter). Fine-grained timeout management via `waitTimeouts.ts` (tinyUi, quickAssert, navigation) prevents both flakiness and masking of performance regressions. The config enforces serial execution (`workers: 1`) in CI, with HTML/JSON reporting and screenshot capture on failure.
 
-For tabbed code blocks created by markdown-it plugins:
+**Key files:** `playwright.config.ts`, `test/e2e/`
 
-```markdown
-<!-- This would be processed by a markdown-it plugin -->
-::: code-tabs
-@tab JavaScript
+### Rehype/Remark Pipeline with Robust Tests
 
-```js
-console.log('Hello, World!')
-```
-
-@tab TypeScript
-
-```ts
-const message: string = 'Hello, World!'
-console.log(message)
-```
-
-:::
-
-**Auto-applied classes**: Tab navigation, content panels, active states
-
-#### Expandable Details (`<details>`)
-
-For collapsible content sections:
-
-```markdown
-<details>
-<summary>Click to expand</summary>
-
-This content will be collapsible with proper styling.
-
-</details>
-```
+The markdown pipeline integrates 30+ plugins across remark and rehype stages, including custom plugins for code tabs, abbreviations, smartypants typography, grid tables, math (MathJax), diagrams (Mermaid), and accessible emoji. Each plugin is explicitly named for debugging. Testing is stratified into three tiers:
 
-**Auto-applied classes**: Cursor pointer, remove default markers, content indentation
+- **Unit tests**: isolated single-plugin behavior
+- **Integration tests**: multi-plugin interaction and conflict detection
+- **E2E tests**: full pipeline rendered in real pages via Playwright
 
-#### Named Code Blocks
+**Key files:** `src/lib/markdown/`, `astro.config.ts` (plugin chain)
 
-For code blocks with filename labels:
+### MJML Email Templating
 
-````markdown
-```js filename="example.js"
-const example = true
-```
-````
-
-**Auto-applied classes**: Filename positioning, background styling, opacity effects
-
-#### Share Highlight (`<share-highlight>`)
-
-For text selection sharing functionality:
-
-```html
-<share-highlight>
-Select this text to see sharing options
-</share-highlight>
-```
+Transactional emails use MJML templates compiled through Nunjucks for dynamic data injection. The compiler generates both HTML and plain-text outputs. Company metadata is injected from a centralized `contact.json` so branding stays consistent across all email types.
 
-**Auto-applied classes**: CSS custom properties for theming and interaction states
+**Key files:** `src/actions/utils/email/`
 
-### Migration from SCSS
+### Linting and Custom ESLint Rules
 
-This system replaces the previous `_content.css` and vendor SCSS files:
+Beyond standard TypeScript and Stylelint rules, the project includes custom ESLint plugins that enforce architectural patterns:
 
-- `src/styles/vendor/_codetab.css` → Integrated into Rehype plugin
-- `src/styles/vendor/_expandable.css` → Integrated into Rehype plugin
-- `src/styles/vendor/_namedCodeBlock.css` → Integrated into Rehype plugin
-- `src/styles/vendor/_shareHighlight.css` → Integrated into Rehype plugin
+- `enforce-centralized-events` &mdash; prevents inline event listener registration
+- `no-html-element-assertions` &mdash; blocks raw HTML assertions in E2E tests
+- `no-query-selector-outside-selectors` &mdash; forces DOM queries through centralized selector modules
 
-The styling is now applied automatically to all rendered Markdown content without needing to import or reference any CSS classes.
+Stylelint enforces modern CSS notation (short hex, angle notation for hue) and prohibits `!important` in favor of cascade layers.
 
-## CSS Fixes
+**Key files:** `eslint.config.ts`, `stylelint.config.mjs`
 
-- Make sure a fixed height header doesn't cover title text on page navigation
+### AI-Assisted Development Skills
 
-```css
-h2:target {
-  scroll-margin-top: var(--header-height);
-}
+Seven skill guides under `.github/skills/` encode tested domain patterns for CSS, JavaScript/TypeScript, testing, view transitions, markdown/Mermaid, and Astro documentation authoring. Each skill provides concrete rules and examples so that AI tools (and new contributors) produce output consistent with project conventions. Instruction files in `.github/instructions/` set global rules for theme colors and general coding standards.
 
-:is(h2, h3, h4):target {
-  scroll-margin-top: var(--header-height);
-}
-```
-
-Also, we can play around with units like ex, or lh for dynamic spacing:
-
-```css
-:target {
-  scroll-margin-top: calc(var(--header-height) + 1lh);
-}
-```
+**Key files:** `.github/skills/`, `.github/instructions/`
 
-This way, we get different offset based on the line-height of the target element which makes our spacing more dynamic.
+### Lit Web Components
 
-- Balance text in titles that span multiple lines
+Interactive UI uses Lit (`LitElement`) instead of a framework like React or Vue. Components use shadow DOM for encapsulation, declarative properties for reactive updates, and standard web component APIs. This avoids framework lock-in and produces smaller client bundles.
 
-```css
-h2 {
-  text-wrap: balance;
-}
-```
+### View Transitions
 
-- Match scroll bar color to page dark/light theme
+The site uses Astro View Transitions with `astro-vtbot` for debugging. Key components (ThemePicker, Footer, Meta) use `transition:persist` to maintain state across client-side navigations without re-initialization.
 
-Usually, websites switch between dark and light themes by assigning a class like dark or light to the body of the document. However, in our case, fixing the scrollbar requires applying the color-scheme property directly to the root element. Can we tackle this with CSS alone? Enter the `:has()` selector.
+### PWA and Offline Support
 
-```css
-:root:has(body.dark) {
-  color-scheme: dark;
-}
-```
+A Workbox service worker (`injectManifest` strategy) provides intelligent offline support with an offline fallback page. The manifest supports window controls overlay and maskable icons.
 
-## See An Error
+### Content Collections
 
-losst.pro has a modal that pops up for fixing mistakes:
+Content is organized into typed collections: articles, authors, case studies, clients, services, testimonials, and tags. A `test-fixtures/` directory enables markdown pipeline testing against real content structure.
 
-*Found a mistake in the text? Let me know about that. Highlight the text with the mistake and press Ctrl+Enter.*
+## CI/CD
 
-## Pages
+Twelve GitHub Actions workflows cover the full lifecycle:
 
-Any `.astro`, `.md`, or `.mdx` file anywhere within the `src/pages/` folder automatically became a page on your site.
+| Workflow | Purpose |
+|---|---|
+| `lint.yml` | TypeScript, ESLint, Stylelint, Prettier, Astro check |
+| `test.yml` | Vitest unit tests with local SQLite |
+| `playwright.yml` | E2E browser tests with retry and artifact capture |
+| `codeql.yml` | Static analysis for security vulnerabilities |
+| `dependency-review.yml` | License and vulnerability checks on PRs |
+| `deployment-preview.yml` | Vercel preview deploys for PRs |
+| `deployment-production.yml` | Vercel production deploys on merge to main |
+| `migrations-preview.yml` | Astro DB schema preview |
+| `migrations-production.yml` | Turso schema promotion |
+| `search.yml` | Search index rebuild |
+| `cron.yml` | Scheduled maintenance tasks |
+| `branch-protection.yml` | Branch naming and commit policy enforcement |
 
-## Navigation
-
-Astro uses standard HTML anchor elements to navigate between pages (also called routes), with traditional page refreshes.
-
-```astro
-<a href="/">Home</a>
-```
-
-## Layouts
-
-The `<slot>` element in an included layout will render any child elements between the `<Layout>` element used in pages
-
-## Get Markdown Frontmatter in a Layout
-
-```astro
----
-const { frontmatter } = Astro.props;
----
-<h1>{frontmatter.title}</h1>
-<p>Published on: {frontmatter.pubDate.slice(0,10)}</p>
-```
-
-## Globbing
-
-`src/pages/blog.astro`
-
-```astro
----
-import BaseLayout from '../layouts/BaseLayout.astro';
-import BlogPost from '../components/BlogPost.astro';
-const allPosts = Object.values(import.meta.glob('../pages/posts/*.md', { eager: true }));
-const pageTitle = "My Astro Learning Blog"
----
-<BaseLayout pageTitle={pageTitle}>
-  <ul>
-    {allPosts.map((post) => <BlogPost url={post.url} title={post.frontmatter.title} />)}
-  </ul>
-</BaseLayout>
-```
-
-`src/components/BlogPost.astro`
-
-```astro
----
-const { title, url } = Astro.props
----
-<li><a href={url}>{title}</a></li>
-```
-
-## Collections
-
-Use `getCollection` instead of a glob. Frontmatter is returned on the `data` key.
-
-```astro
----
-import { getCollection } from "astro:content";
-
-const allPosts = await getCollection("posts");
----
-<BlogPost url={`/posts/${post.slug}/`} title={post.data.title} />
-```
-
-## Tags
-
-Each blog post should have a Frontmatter tag item:
-
-`tags: ["blogging"]`
-
-`src/pages/tags/[tag].astro`
-
-```astro
----
-import BaseLayout from '../../layouts/BaseLayout.astro';
-import BlogPost from '../../components/BlogPost.astro';
-
-export async function getStaticPaths() {
-  const allPosts = Object.values(import.meta.glob('../posts/*.md', { eager: true }));
-
-  const uniqueTags = [...new Set(allPosts.map((post) => post.frontmatter.tags).flat())];
-
-  return uniqueTags.map((tag) => {
-    const filteredPosts = allPosts.filter((post) => post.frontmatter.tags.includes(tag));
-    return {
-      params: { tag },
-      props: { posts: filteredPosts },
-    };
-  });
-}
-
-const { tag } = Astro.params;
-const { posts } = Astro.props;
----
-<BaseLayout pageTitle={tag}>
-  <p>Posts tagged with {tag}</p>
-  <ul>
-    {posts.map((post) => <BlogPost url={post.url} title={post.frontmatter.title}/>)}
-  </ul>
-</BaseLayout>
-```
-
-## Get the currently focused element on the page in the console
-
-```bash
-document.activeElement
-```
-
-## Testing HTML with `html-validate` in Braid UI
-
-```typescript
-import '@testing-library/jest-dom';
-import 'html-validate/jest';
-import React from 'react';
-import { renderToStaticMarkup } from 'react-dom/server';
-import { BraidTestProvider } from '../../../entries/test';
-import { Button, IconSend } from '..';
-
-describe('Button', () => {
-  it('should render valid html structure', () => {
-    expect(
-      renderToStaticMarkup(
-        <BraidTestProvider>
-          <Button>Button</Button>
-          <Button icon={<IconSend />}>Button</Button>
-        </BraidTestProvider>,
-      ),
-    ).toHTMLValidate({
-      extends: ['html-validate:recommended'],
-    });
-  });
-});
-```
-
-## Run a single test
-
-```bash
-clear && TS_NODE_PROJECT="tsconfig.jest.json" yarn jest eleventy/nunjucksAsyncShortcodes/asyncImageHandler/utils.spec.js --projects test/jest/jest.config.node.ts
-```
-
-## Testing
-
-The project uses a dual testing setup:
-
-- **Unit Tests**: Vitest for testing individual functions and components
-- **E2E Tests**: Playwright for end-to-end browser testing
-
-### Running Tests
-
-**Run all tests (unit + e2e):**
-
-```bash
-npm test
-```
-
-**Run only unit tests:**
+## Quick Start
 
 ```bash
-npm run test:unit
+npm install
+npm run dev           # start dev server
+npm run build:ci      # build with local SQLite
+npm run test:unit     # vitest
+npm run test:e2e      # playwright
+npm run lint          # full lint suite
 ```
 
-**Run only e2e tests:**
+## Tech Stack
 
-```bash
-npm run test:e2e
-```
-
-**Run tests with coverage report:**
-
-```bash
-npm run test:coverage
-```
-
-### Code Coverage
-
-The project uses Vitest with the v8 coverage provider to generate comprehensive test coverage reports.
-
-**Viewing Coverage Reports:**
-
-After running `npm run test:coverage`, coverage reports are generated in multiple formats:
-
-1. **Console Output** - Summary displayed in terminal
-2. **HTML Report** - Interactive browsable report at `./coverage/index.html`
-3. **JSON Report** - Machine-readable at `./coverage/coverage-final.json`
-4. **LCOV Report** - Standard format for CI/CD tools at `./coverage/lcov.info`
-
-**To view the HTML coverage report in your browser:**
-
-```bash
-# After running coverage
-open coverage/index.html        # macOS
-xdg-open coverage/index.html    # Linux
-start coverage/index.html       # Windows
-```
-
-**Coverage Report Locations:**
-
-- All coverage reports are stored in the `./coverage` directory
-- The directory is automatically cleaned before each coverage run
-- Coverage includes: `src/**/*.{ts,tsx,astro}` and `scripts/**/*.ts`
-- Excludes: test files, type definitions, and test directories
-
-**Note:** The `coverage/` directory should be added to `.gitignore` to avoid committing generated reports.
-
-### Unit Test Structure
-
-Unit tests are located alongside their source files:
-
-- `src/**/*.spec.ts` - Component and library tests
-- `scripts/**/__tests__/*.spec.ts` - Build script tests
-
-Example test file locations:
-
-- `src/lib/helpers/formatDate.spec.ts`
-- `scripts/build/__tests__/favicon.spec.ts`
-
-## Snippet to search for string in project with exclude directories
-
-```bash
-clear && egrep -rnw './' --exclude-dir=node_modules --exclude-dir=.yarn --exclude-dir=yarn.lock --exclude-dir=public --exclude-dir=.cache -e 'searchString'
-```
-
-## Clear Jest's cache
-
-```bash
-npx jest --clearCache
-```
-
-## For install errors that report error installing sharp, recommended install. See `jest.setup.jsdom.ts`
-
-```bash
-npm install --platform=linux --arch=x64 sharp
-```
-
-## Check if a CSS selector is valid in the browser console
-
-```bash
-document.querySelector('.contact___callout-flex')
-```
-
-## Test the value of a CSS variable when using `calc()` in the browser console
-
-```bash
-document.getElementById('header__theme-icon').getBoundingClientRect().width
-```
-
-## Images
-
-Update the copyright notice in EXIF data when adding new images:
-
-```bash
-exiftool -Comment= -Copyright="© 2026 Webstack Builders, Inc." -CopyrightNotice="© 2026 Webstack Builders, Inc." src/content/**/* src/assets/**/* public/**/*
-```
+Astro, TypeScript, Lit, Tailwind CSS, Turso (libSQL), Sentry, Vercel, Playwright, Vitest, MJML, Workbox, GitHub Actions
diff --git a/src/actions/contact/responder.ts b/src/actions/contact/responder.ts
index d62dc99c..ee6a91d8 100644
--- a/src/actions/contact/responder.ts
+++ b/src/actions/contact/responder.ts
@@ -2,7 +2,10 @@ import { Buffer } from 'node:buffer'
 import { ActionsFunctionError } from '@actions/utils/errors'
 import acknowledgementTemplateContent from '@actions/contact/email/acknowledgement.mjml?raw'
 import messageTemplateContent from '@actions/contact/email/message.mjml?raw'
-import { compileEmailTemplate, createEmailTemplate } from '@actions/utils/email/templateCompiler'
+import {
+  compileEmailTemplate,
+  createImportedEmailTemplate,
+} from '@actions/utils/email/templateCompiler'
 import { escapeHtml, formatFileSize } from './utils'
 import type { ContactFormData, ContactTimeline, FileAttachment } from '@actions/contact/@types'
 
@@ -61,13 +64,13 @@ const readInputBoolean = (input: Record<string, unknown>, key: string): boolean
   return false
 }
 
-const contactMessageTemplate = createEmailTemplate(
-  new URL('./email/message.mjml', import.meta.url),
+const contactMessageTemplate = createImportedEmailTemplate(
+  'src/actions/contact/email/message.mjml',
   messageTemplateContent
 )
 
-const contactAcknowledgementTemplate = createEmailTemplate(
-  new URL('./email/acknowledgement.mjml', import.meta.url),
+const contactAcknowledgementTemplate = createImportedEmailTemplate(
+  'src/actions/contact/email/acknowledgement.mjml',
   acknowledgementTemplateContent
 )
 
diff --git a/src/actions/gdpr/entities/email.ts b/src/actions/gdpr/entities/email.ts
index bd9d4051..9c93e691 100644
--- a/src/actions/gdpr/entities/email.ts
+++ b/src/actions/gdpr/entities/email.ts
@@ -1,14 +1,17 @@
 import { Resend } from 'resend'
 import verificationTemplateContent from '@actions/gdpr/email/verification.mjml?raw'
 import { dsarVerificationEmailText } from '@actions/gdpr/email/dsarText'
-import { compileEmailTemplate, createEmailTemplate } from '@actions/utils/email/templateCompiler'
+import {
+  compileEmailTemplate,
+  createImportedEmailTemplate,
+} from '@actions/utils/email/templateCompiler'
 import { getResendApiKey, isProd } from '@actions/utils/environment/environmentActions'
 import { gdprReplyTo, gdprSender } from '@actions/utils/email/resendSenders'
 import { getSiteUrl } from '@actions/utils/environment/siteUrlActions'
 import { ActionsFunctionError } from '@actions/utils/errors/ActionsFunctionError'
 
-const verificationTemplate = createEmailTemplate(
-  new URL('../email/verification.mjml', import.meta.url),
+const verificationTemplate = createImportedEmailTemplate(
+  'src/actions/gdpr/email/verification.mjml',
   verificationTemplateContent
 )
 
diff --git a/src/actions/newsletter/email/confirmationHtml.ts b/src/actions/newsletter/email/confirmationHtml.ts
index ac5359fd..e7130f76 100644
--- a/src/actions/newsletter/email/confirmationHtml.ts
+++ b/src/actions/newsletter/email/confirmationHtml.ts
@@ -1,8 +1,8 @@
 import confirmationTemplateContent from './confirmation.mjml?raw'
-import { compileEmailTemplate, createEmailTemplate } from '@actions/utils/email/templateCompiler'
+import { compileEmailTemplate, createImportedEmailTemplate } from '@actions/utils/email/templateCompiler'
 
-const confirmationTemplate = createEmailTemplate(
-  new URL('./confirmation.mjml', import.meta.url),
+const confirmationTemplate = createImportedEmailTemplate(
+  'src/actions/newsletter/email/confirmation.mjml',
   confirmationTemplateContent
 )
 
diff --git a/src/actions/newsletter/email/welcomeHtml.ts b/src/actions/newsletter/email/welcomeHtml.ts
index 2188f6d3..17715b13 100644
--- a/src/actions/newsletter/email/welcomeHtml.ts
+++ b/src/actions/newsletter/email/welcomeHtml.ts
@@ -1,8 +1,8 @@
 import welcomeTemplateContent from './welcome.mjml?raw'
-import { compileEmailTemplate, createEmailTemplate } from '@actions/utils/email/templateCompiler'
+import { compileEmailTemplate, createImportedEmailTemplate } from '@actions/utils/email/templateCompiler'
 
-const welcomeTemplate = createEmailTemplate(
-  new URL('./welcome.mjml', import.meta.url),
+const welcomeTemplate = createImportedEmailTemplate(
+  'src/actions/newsletter/email/welcome.mjml',
   welcomeTemplateContent
 )
 
diff --git a/src/actions/utils/email/__tests__/templateCompiler.spec.ts b/src/actions/utils/email/__tests__/templateCompiler.spec.ts
index a6d95654..8ae61bed 100644
--- a/src/actions/utils/email/__tests__/templateCompiler.spec.ts
+++ b/src/actions/utils/email/__tests__/templateCompiler.spec.ts
@@ -6,7 +6,11 @@ import contactMessageTemplateContent from '../../../contact/email/message.mjml?r
 import exampleTemplateContent from '../__fixtures__/example.mjml?raw'
 import invalidTemplateContent from '../__fixtures__/invalid.mjml?raw'
 import withCommonDataTemplateContent from '../__fixtures__/with-common-data.mjml?raw'
-import { compileEmailTemplate, createEmailTemplate } from '../templateCompiler'
+import {
+  compileEmailTemplate,
+  createEmailTemplate,
+  createImportedEmailTemplate,
+} from '../templateCompiler'
 
 const exampleTemplate = createEmailTemplate(
   new URL('../__fixtures__/example.mjml', import.meta.url),
@@ -28,6 +32,11 @@ const withCommonDataTemplate = createEmailTemplate(
   withCommonDataTemplateContent
 )
 
+const importedExampleTemplate = createImportedEmailTemplate(
+  'src/actions/utils/email/__fixtures__/example.mjml',
+  exampleTemplateContent
+)
+
 describe('compileEmailTemplate', () => {
   it('compiles the moved contact message template from its imported source', async () => {
     const result = await compileEmailTemplate(contactMessageTemplate, {
@@ -90,6 +99,18 @@ describe('compileEmailTemplate', () => {
     expect(result.text).toContain('Contact Webstack Builders at support@webstackbuilders.com.')
   })
 
+  it('compiles imported template content from a stable source path', async () => {
+    const result = await compileEmailTemplate(importedExampleTemplate, {
+      htmlMessage: '<strong>Urgent</strong> message body',
+      items: ['Coffee Beans'],
+      name: 'Alex',
+    })
+
+    expect(result.html).toContain('Hello, Alex!')
+    expect(result.html).toContain('Coffee Beans')
+    expect(result.text).toContain('Urgent message body')
+  })
+
   it('throws ActionsFunctionError when MJML compilation reports errors', async () => {
     await expect(compileEmailTemplate(invalidTemplate)).rejects.toMatchObject({
       appCode: 'EMAIL_TEMPLATE_COMPILE_FAILED',
diff --git a/src/actions/utils/email/templateCompiler.ts b/src/actions/utils/email/templateCompiler.ts
index e6e3ee45..44bfe4af 100644
--- a/src/actions/utils/email/templateCompiler.ts
+++ b/src/actions/utils/email/templateCompiler.ts
@@ -230,7 +230,10 @@ const createPlainText = (html: string): string =>
 /**
  * Creates a bundle-safe template descriptor from imported MJML source.
  */
-export const createImportedEmailTemplate = createEmailTemplate
+export const createImportedEmailTemplate = (
+  sourcePath: string,
+  content: string
+): EmailTemplateSource => createEmailTemplate(sourcePath, content)
 
 /**
  * Renders imported MJML source with Nunjucks data and returns HTML plus plain text.