```html

Building Multi-Domain Auto-Generated Technical Blog Infrastructure

This session focused on creating a comprehensive technical blog infrastructure that automatically captures and publishes detailed development work across four domains: tech.queenofsandiego.com, tech.dangerouscentaur.com, tech.sailjada.com, and tech.burialsatseasandiego.com. The system needed to be granular, capturing infrastructure changes, file modifications, and command executions in real-time—without exposing credentials.

Architecture Overview

The solution consists of three core components:

  • Stop Hook Script (/Users/cb/.claude/hooks/tech_blog_stop.sh): Executes when a Claude Code session ends, extracting session metadata and triggering blog generation
  • Blog Generator (/Users/cb/Documents/repos/tools/tech_blog_generator.py): Parses Claude session transcripts (JSONL format), sanitizes sensitive data, and generates HTML blog posts
  • Infrastructure Initialization (/Users/cb/Documents/repos/tools/tech_blog_init.py): Provisions S3 buckets, CloudFront distributions, and DNS records for each tech blog domain

Infrastructure Provisioning Strategy

We leveraged existing wildcard SSL certificates to minimize provisioning time:

  • *.queenofsandiego.com wildcard cert via AWS ACM (already issued)
  • *.sailjada.com wildcard cert via AWS ACM (already issued)
  • *.dangerouscentaur.com existing CloudFront wildcard distribution on dc-sites S3 bucket (distribution ID: E2Q4UU71SRNTMB)
  • burialsatseasandiego.com managed via GoDaddy DNS (requires ACM validation CNAME record)

For queenofsandiego.com and sailjada.com, we created dedicated S3 buckets following the pattern tech-[domain]-blog. Each bucket is configured with:

  • Static website hosting enabled on the subdomain (e.g., tech.queenofsandiego.com)
  • CloudFront distribution pointing to the S3 origin with appropriate cache behaviors
  • Route53 alias records mapping the subdomain to the CloudFront distribution

For dangerouscentaur.com, we reused the existing wildcard CloudFront distribution and added a CNAME record in Namecheap DNS pointing to the CloudFront domain.

Technical Implementation Details

Session Transcript Processing:

Claude Code sessions are captured in JSONL format within the .claude/projects directory. Each session file contains:

  • User messages and assistant responses
  • Tool use entries specifying file operations (read, write, edit)
  • Command executions with their context
  • Timestamps and session metadata

The blog generator parses this JSONL structure, extracting:

  • All file paths that were created or modified
  • Command invocations and their purposes
  • Changes to AWS resources (S3, CloudFront, Route53)
  • Infrastructure decisions and reasoning

Credential Sanitization:

Before publishing, the generator applies multiple filters to remove sensitive data:

  • Redacts strings matching regex patterns for API keys, tokens, and passwords
  • Filters environment variables that contain credentials (detected via common patterns like _KEY, _TOKEN, _SECRET)
  • Removes AWS access keys, session tokens, and certificate ARNs
  • Sanitizes domain credentials and API endpoints that could be exploited

This ensures technical depth without security risk—developers can see exact S3 bucket names and CloudFront distribution IDs, but not authentication material.

Stop Hook Integration:

The stop hook script is registered in Claude Code settings at /Users/cb/.claude/settings.json under the hooks configuration. When a session ends, the hook:

  1. Reads the completed session transcript from .claude/sessions/
  2. Determines the domain context from session notes or project metadata
  3. Invokes the blog generator with the transcript path and target domain
  4. Uploads the generated HTML to the appropriate S3 bucket
  5. Invalidates the CloudFront cache to ensure immediate publication

The hook ensures logs are written to /Users/cb/.claude/logs/ for debugging and audit purposes.

Navigation Integration

We updated the "Ship's Papers" menu on queenofsandiego.com to link to the technical blog. The HTML structure was modified in /Users/cb/Documents/repos/sites/queenofsandiego.com/index.html to add a new dropdown menu item pointing to https://tech.queenofsandiego.com. This pattern will be replicated for the other domains.

DNS Resolution and Propagation

We verified DNS nameserver configuration for each domain:

  • queenofsandiego.com and sailjada.com: Hosted in AWS Route53 with alias records for the tech blog subdomains
  • dangerouscentaur.com: Managed via Namecheap with CNAME records pointing to CloudFront
  • burialsatseasandiego.com: GoDaddy DNS with programmatic access via GoDaddy API credentials for CNAME validation records

ACM certificate validation for burialsatseasandiego.com was completed by adding the DNS validation CNAME record directly to GoDaddy's DNS zone.

Deployment Validation

We tested HTTP access to all four tech blog domains to confirm infrastructure was live:

  • CloudFront distributions were actively serving content from S3 origins
  • Certificate validation was successful for all domains
  • DNS propagation was complete within expected timeframes

Key Decisions and Rationale

  • Wildcard Certificates: Reusing existing wildcard certs reduced provisioning time from hours to minutes—no waiting for new cert issuance and validation.
  • Dedicated S3 Buckets: Separate buckets per domain allow independent scaling, access policies, and lifecycle rules if needed in the future.
  • CloudFront Caching: Configured with short TTLs on the root index to ensure new blog posts appear quickly, while static assets use longer cache periods.
  • JSONL Parsing: Claude's native session format is JSONL, making it ideal for structured parsing without external dependencies.
  • Programmatic DNS: Using API-