Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Building an Automated Technical Blog Pipeline for Multi-Site Infrastructure

This session involved architecting and deploying a comprehensive system to automatically generate granular technical blog posts documenting all infrastructure and code changes across four main sites: queenofsandiego.com, sailjada.com, dangerouscentaur.com, and burialsatseasandiego.com. The goal was to create a transparent audit trail of technical work that could be reviewed by stakeholders without exposing credentials.

What Was Done

  • Created an automated blog generation system triggered on Claude Code session stops
  • Deployed infrastructure for four new technical blog subdomains using S3, CloudFront, and DNS
  • Integrated blog generator hooks into Claude Code's session management
  • Configured DNS across Route53 (queenofsandiego.com, sailjada.com) and GoDaddy (burialsatseasandiego.com)
  • Added "Technical Blog" links to Ship's Papers navigation on main sites
  • Identified and flagged incorrect hero images on burialsatseasandiego.com for replacement
  • Performed Google Analytics audit across all properties

Technical Architecture

The solution consists of three core components:

1. Blog Generator Engine

Created /Users/cb/Documents/repos/tools/tech_blog_generator.py which:

  • Parses Claude session transcripts in JSONL format from ~/.claude/sessions/
  • Extracts tool use entries (file modifications, AWS API calls, DNS changes)
  • Sanitizes all output to remove credentials, API keys, and sensitive data
  • Generates granular HTML posts documenting exact file paths, resource names, and decisions
  • Determines target blog based on modified repository paths and domain context
  • Formats timestamps and cross-references infrastructure changes

The generator reads session transcripts as JSONL where each line contains tool use events with parameters. It filters for relevant operations:

- File writes/edits with full paths
- AWS CloudFormation/CLI executions  
- Route53 DNS record changes
- S3 bucket operations
- CloudFront invalidations
- ACM certificate validations

2. Infrastructure Initialization

Created /Users/cb/Documents/repos/tools/tech_blog_init.py which provisions identical infrastructure for each tech blog:

  • S3 Buckets: tech-queenofsandiego-com, tech-sailjada-com, tech-dangerouscentaur-com, tech-burialsatseasandiego-com
  • CloudFront Distributions: One per bucket with wildcard certificate support
  • DNS Records: CNAME or ALIAS records pointing to CloudFront origins
  • ACM Certificates: Leveraged existing wildcard certs (*.queenofsandiego.com, *.sailjada.com) or requested new ones

For queenofsandiego.com and sailjada.com, existing wildcard ACM certificates were used, avoiding additional validation overhead. For dangerouscentaur.com, the system detected and reused the existing wildcard CloudFront distribution E2Q4UU71SRNTMB on the dc-sites S3 bucket. For burialsatseasandiego.com (hosted at GoDaddy), the system created a Route53 hosted zone and added ACM DNS validation records via GoDaddy API integration.

3. Session Stop Hook

Created /Users/cb/.claude/hooks/tech_blog_stop.sh which:

  • Executes automatically when Claude Code sessions terminate
  • Retrieves the just-completed session transcript
  • Invokes the blog generator with the transcript path
  • Uploads generated HTML to appropriate S3 bucket
  • Invalidates CloudFront cache to publish immediately
  • Logs all activity to ~/.claude/logs/tech_blog_hooks.log

The hook is registered in /Users/cb/.claude/settings.json under the session hooks configuration, ensuring it runs on every session stop without requiring manual intervention.

Infrastructure Deployment Details

DNS Configuration Strategy:

  • queenofsandiego.com / sailjada.com: Route53 hosted zones with ALIAS records pointing to CloudFront distributions. Leveraged existing wildcard ACM certificates.
  • dangerouscentaur.com: CNAME record at Namecheap DNS pointing to existing CloudFront distribution (detected from dc-sites bucket configuration).
  • burialsatseasandiego.com: GoDaddy-hosted DNS with CNAME for tech subdomain. New Route53 hosted zone created for delegated DNS control, with ACM certificate validated via GoDaddy API integration using stored credentials.

CloudFront Configuration: All distributions use:

  • S3 origins with origin access control (not legacy OAI)
  • Default cache TTL of 3600 seconds (1 hour) for index.html
  • Longer TTLs for static assets (CSS, JS, images)
  • Compression enabled for text-based content
  • HTTP to HTTPS redirect

Integration with Existing Sites

Updated Ship's Papers navigation across all four main sites by adding a new menu item:

<li><a href="/tech/">Technical Blog</a></li>

This links to /tech/ paths which are configured as subdomain aliases (e.g., tech.queenofsandiego.com redirects to the technical blog S3 origin). This approach avoids modifying the main site's routing structure.

Content Sanitization

The blog generator implements multi-layer credential scrubbing:

  • Regex filtering for AWS access key patterns, GoDaddy API keys, and token formats
  • Removal of environment variable values while preserving variable names
  • Masking of email addresses and phone numbers
  • Redaction of S3 paths containing sensitive naming patterns

File paths, function names, and infrastructure resource names are preserved because they're non-sensitive and essential for technical documentation.

Key Decisions

Why Wildcard Certificates? Using existing *.queenofsandiego.com and *.sailjada.com wildcard ACM certificates meant zero additional validation overhead. For burialsatseasandiego.com, creating a new certificate was necessary but validated through GoDaddy's API to automate the DNS challenge.

Why Session-Stop Hooks? Triggering blog generation at session completion ensures every piece