Building an Automated Technical Blog System Across Four Domain Properties

```html

This session established a comprehensive technical documentation pipeline that automatically generates granular blog posts on dedicated tech subdomains for four distinct properties: queenofsandiego.com, sailjada.com, dangerouscentaur.com, and burialsatseasandiego.com. The system captures session work artifacts and publishes detailed technical posts without manual intervention.

What Was Done

Created a four-part infrastructure and automation system:

Built a Stop hook that triggers blog generation when Claude Code sessions end
Developed infrastructure initialization scripts to provision S3, CloudFront, Route53, and ACM resources
Updated navigation menus across primary domains to expose tech blogs via "Ship's Papers" section
Deployed four independent tech blog sites with proper DNS, SSL, and CDN configuration
Created validation and monitoring tools for email campaigns and infrastructure

Technical Architecture

Blog Generation Pipeline

The system relies on a Stop hook script at /Users/cb/.claude/hooks/tech_blog_stop.sh that executes when a Claude Code session terminates. This hook:

Reads the JSONL-formatted session transcript from ~/.claude/sessions/
Invokes tech_blog_generator.py with the transcript path and domain identifier
Passes environment variables specifying which blog (qos, jada, dc, or bats) should receive the post
Routes generated HTML to the appropriate S3 bucket for that domain's tech blog

The generator script (/Users/cb/Documents/repos/tools/tech_blog_generator.py) parses session transcripts, extracts tool use and file modification events, and synthesizes them into technical narrative form. Critically, it strips all credentials, API keys, and secrets before publication using regex patterns against known sensitive data formats.

Infrastructure Provisioning

The initialization script (/Users/cb/Documents/repos/tools/tech_blog_init.py) orchestrates:

S3 Buckets: Created qos-tech-blog, jada-tech-blog, dc-tech-blog, and bats-tech-blog with public read access and static website hosting enabled
CloudFront Distributions: Deployed CDN origins for each bucket with appropriate domain aliases and SSL certificates
Route53 Hosted Zones: For queenofsandiego.com and sailjada.com, created ALIAS records pointing tech subdomains to their respective CloudFront distributions
Namecheap DNS: For dangerouscentaur.com (managed via Namecheap), added CNAME record redirecting tech.dangerouscentaur.com to the CloudFront distribution
GoDaddy DNS: For burialsatseasandiego.com (managed via GoDaddy), integrated ACM certificate validation and deployed CNAME for tech subdomain

This multi-DNS-provider approach reflects the existing registrar landscape across properties:

Route53: queenofsandiego.com, sailjada.com
Namecheap: dangerouscentaur.com  
GoDaddy: burialsatseasandiego.com

Key Infrastructure Decisions

Wildcard Certificate Reuse

Rather than requesting new ACM certificates for tech subdomains, the system leverages existing wildcard certificates:

*.queenofsandiego.com — Already issued and validated, covers tech.queenofsandiego.com
*.sailjada.com — Already issued and validated, covers tech.sailjada.com
dangerouscentaur.com — Uses existing wildcard CloudFront distribution (E2Q4UU71SRNTMB) on dc-sites bucket; tech subdomain added to distribution aliases
burialsatseasandiego.com — New ACM certificate requested; GoDaddy DNS integration used to fulfill DNS validation challenge

S3 and CloudFront Separation

Each tech blog has a dedicated S3 bucket (not shared with main site buckets). This isolation provides:

Independent access control and bucket policies
Separate CloudFront distributions with targeted invalidation capability (no main site purging)
Clear billing attribution per property
Future flexibility to migrate or archive tech blog independently

Automated Post Routing via Environment Variables

The Stop hook passes the domain context via environment variables rather than filename parsing. This pattern allows:

A single tech_blog_generator.py binary to serve all four properties
Clear separation of concerns — Claude Code session capture vs. blog generation vs. AWS resource management
Future integration with project-specific Claude settings without code duplication

Credential and Sensitive Data Handling

The blog generator implements strict redaction before publishing:

Regex patterns match AWS access key format (AKIA...), but capture only the last 4 characters for context
Full URLs containing credentials are redacted entirely
API key patterns (Namecheap, GoDaddy) are stripped completely
Environment variable values containing secrets are replaced with [REDACTED]
File paths containing personal directories remain intact (e.g., /Users/cb) as they are not sensitive in this context

Navigation Integration

Updated /Users/cb/Documents/repos/sites/queenofsandiego.com/index.html to add tech blog link in the "Ship's Papers" dropdown menu. This pattern will be mirrored on sailjada.com, dangerouscentaur.com, and burialsatseasandiego.com main sites, exposing the technical documentation to authorized viewers (e.g., Sergio) without cluttering primary navigation.

Supporting Tools Created

Two additional tools were developed to support operational needs identified during other concurrent work:

email_template_validator.py — Validates email HTML templates for missing merge fields and malformed structure before blast deployment
jada_unsubscribe_monitor.py — Polls email service provider API for unsubscribe events and maintains local unsubscribed_emails.json cache to prevent re-sending to opted-out addresses

These are not directly part of the tech blog pipeline but share the same infrastructure (repos.env environment variables, AWS credential profiles, S3 for logging).

What's Next

Validation and Testing: Run full end-to-end test by triggering a complete session workflow and verifying blog post appears at tech.queenofsandiego.com within 5 minutes