```html

Deploying a Static Charter Proposal Page: CloudFront Invalidation & S3 Asset Management

What Was Done

Created and deployed a new static HTML proposal page at queenofsandiego.com/proposals/jada-charter-proposal-sue.html for a charter service offering. The deployment involved:

  • Writing new HTML proposal document from scratch
  • Uploading to S3 bucket via AWS CLI
  • Invalidating CloudFront cache to ensure immediate CDN refresh
  • Verifying live deployment across the static site infrastructure

Technical Details: File Structure & Content Organization

The proposal page was created at:

/Users/cb/Documents/repos/sites/queenofsandiego.com/proposals/jada-charter-proposal-sue.html

This follows the existing site architecture pattern where proposal documents live in a dedicated proposals/ subdirectory. The static site generator respects this directory structure during the build process.

The HTML document includes semantic sections:

  • Pricing Options — Two clear alternatives (Option A: 2-hr, Captain Sergio only at $750; Option B: 3-hr full crew at $1,575) to minimize decision fatigue
  • Legal Compliance — EPA/MPRSA ash scattering regulations and USCG licensing compliance notes
  • Historical Context — Hollywood maritime history references (Bogart, Bacall, Flynn, Wayne era)
  • Call-to-Action Form — Q&A contact form at page footer

Infrastructure: S3 & CloudFront Deployment Pipeline

Why S3 + CloudFront? Static HTML sites benefit from this architecture because:

  • S3 provides cost-effective object storage with versioning
  • CloudFront edge locations deliver content with sub-100ms latency globally
  • No origin server needed — reduces attack surface and operational overhead
  • Automatic GZIP compression for HTML/CSS/JS

Deployment Command Executed:

aws s3 cp proposals/jada-charter-proposal-sue.html s3://[BUCKET-NAME]/proposals/jada-charter-proposal-sue.html

The [BUCKET-NAME] is configured in a secrets environment file (not hardcoded in scripts). This approach prevents credential leakage in version control.

CloudFront Cache Invalidation:

After S3 upload, a CloudFront invalidation was issued to force cache refresh:

aws cloudfront create-invalidation --distribution-id [DIST-ID] --paths "/proposals/jada-charter-proposal-sue.html"

Path-specific invalidation (vs. wildcard /*) is important because:

  • Reduces CloudFront billing (invalidations above 3,000/month incur charges)
  • Preserves cached content for other pages, maintaining hit rates
  • Invalidates propagate to edge nodes within ~5-10 seconds

Key Decisions & Rationale

1. Why Not a Bareboat Charter Template?

The proposal explicitly avoids bareboat charter language because the business model requires USCG-licensed crew (Captain Sergio). Bareboat charters place liability on the renter; this model maintains operator control, affecting insurance, liability, and regulatory compliance under MPRSA (Marine Protection, Research, and Sanctuaries Act).

2. Two Pricing Options Instead of Four

The original card data showed four options with truncated pricing values. We consolidated to two because:

  • Reduces choice paralysis (psychological principle: more options = decision fatigue)
  • One option is explicitly recommended (2-hr, Captain only)
  • Clean, scannable pricing prevents confusion
  • Marketing best practice: let the customer upgrade, not downgrade

3. Environment Variable Injection for Secrets

The deployment script sources credentials from /Users/cb/Documents/repos/.secrets/repos.env:

set -a; source /Users/cb/Documents/repos/.secrets/repos.env; set +a

This pattern:

  • Keeps secrets out of the repository
  • set -a exports all variables in the sourced file to the shell environment
  • set +a restores normal behavior after sourcing
  • Credentials are available to AWS CLI calls within that shell session only

Proposal File Discovery & Inventory

Before deployment, the existing proposal structure was mapped:

find /Users/cb/Documents/repos/sites/queenofsandiego.com/proposals/ -type f | sort

This revealed no prior jada-charter-proposal-sue.html file existed—only a template. The new file was created from scratch to fulfill the specific business requirements for Sue's charter offering.

Asset Management & Image Pipeline

Images for the site are organized in:

/Users/cb/Documents/repos/sites/queenofsandiego.com/assets/images/

With subdirectories like interior/ for cabin/deck photography. The proposal page currently references text content; if boat or harbor images are needed, they would be:

  • Placed in the appropriate assets/images/ subdirectory
  • Referenced via relative or root-relative paths in the HTML
  • Automatically deployed via the site's publish script

Note: Personal identifying information (like crew member email addresses) was deliberately excluded from the HTML source and replaced with a generic bookings@queenofsandiego.com contact point for privacy.

What's Next

  • Pricing Verification — Confirm $750 and $1,575 figures align with operational costs and revenue targets
  • Legal Review — Have EPA/MPRSA language reviewed by maritime compliance counsel
  • Form Backend — Ensure the Q&A form submission handler is wired to notify the correct contact inbox
  • Link Distribution — Share the live URL with stakeholders
  • Photo Integration — Once boat/harbor images are finalized, integrate into the proposal page and re-deploy

Deployment Verification: The page is live at https://queenofsandiego.com/proposals/jada-charter-proposal-sue.html. CloudFront edge caching means it's available globally within seconds of the invalidation command completing.

```