```html

Building Automated Technical Blog Infrastructure Across Four Domain Properties

Overview

This session implemented a comprehensive automated technical blogging system that captures granular development work across four domain properties: queenofsandiego.com, sailjada.com, dangerouscentaur.com, and burialsatseasandiego.com. The system auto-generates technical blog posts from Claude session transcripts, maintains separate tech blog deployments for each property, and integrates documentation into existing site navigation.

What Was Done

Core System Components

  • Blog Generator Engine (/Users/cb/Documents/repos/tools/tech_blog_generator.py): Python application that parses Claude session transcripts (JSONL format), extracts tool use and file modification events, and generates granular technical blog posts with HTML output
  • Infrastructure Initialization (/Users/cb/Documents/repos/tools/tech_blog_init.py): Automated deployment script that provisions S3 buckets, CloudFront distributions, DNS records, and ACM certificates for each tech blog subdomain
  • Stop Hook Integration (/Users/cb/.claude/hooks/tech_blog_stop.sh): Claude Code hook that triggers automatically when sessions end, captures the session transcript, generates a blog post, and deploys it to the appropriate domain
  • Claude Code Settings Integration (/Users/cb/.claude/settings.json): Updated configuration to register the stop hook and enable automatic blog generation on session completion

Site Navigation Updates

The ship's papers navigation menu on queenofsandiego.com was updated to include a "Technical Blog" link that routes to tech.queenofsandiego.com, providing transparency into development work and infrastructure changes for stakeholders like Sergio.

Technical Details: Infrastructure Architecture

Multi-Domain Deployment Pattern

Each of the four properties received identical infrastructure:

  • S3 Origin Buckets:
    • qos-sites-tech-blog (queenofsandiego.com)
    • jada-sites-tech-blog (sailjada.com)
    • dc-sites-tech-blog (dangerouscentaur.com)
    • bats-sites-tech-blog (burialsatseasandiego.com)
  • CloudFront Distributions: Each bucket fronted by a CloudFront distribution with automatic cache invalidation on post publish
  • SSL/TLS Certificates:
    • Wildcard certs already existed for *.queenofsandiego.com and *.sailjada.com (AWS Certificate Manager)
    • New cert provisioned for *.dangerouscentaur.com with DNS validation via Namecheap
    • New cert provisioned for burialsatseasandiego.com with DNS validation via GoDaddy API integration
  • DNS Configuration:
    • Route53 CNAME records for queenofsandiego.com and sailjada.com properties
    • Namecheap CNAME record for dangerouscentaur.com tech blog subdomain
    • GoDaddy API integration for burialsatseasandiego.com (using stored API credentials)

Session Capture and Post Generation

The stop hook mechanism works as follows:

  1. Claude Code session terminates, triggering tech_blog_stop.sh
  2. Hook reads the session transcript from ~/.claude/sessions/ (JSONL format)
  3. Calls tech_blog_generator.py with session path and property identifier
  4. Generator parses transcript, extracting:
    • File modifications with timestamps and paths
    • Tool use events (AWS API calls, DNS changes, etc.)
    • Commands executed with sanitization for credentials
    • User context and reasoning from agent notes
  5. Generates HTML blog post with granular technical details
  6. Uploads to property-specific S3 bucket (index.html or timestamped post file)
  7. Invalidates CloudFront distribution cache

Key Architectural Decisions

Why Separate Buckets Instead of Unified Infrastructure

Although all four properties share similar infrastructure patterns, separate S3 buckets and CloudFront distributions were chosen for:

  • Cost Tracking: Each domain's tech blog traffic and storage costs are independently measurable
  • Access Control: Bucket policies can be restricted by property (useful if different stakeholders manage different properties)
  • Failure Isolation: An issue with one tech blog doesn't cascade to others
  • DNS Flexibility: Each property uses its respective DNS provider (Route53, Namecheap, GoDaddy), so separate distributions simplify CNAME configuration

Why GoDaddy API Integration for burialsatseasandiego.com

Unlike the other properties, burialsatseasandiego.com is registered at GoDaddy (not AWS Route53 or Namecheap). Instead of manual DNS updates, the infrastructure script uses GoDaddy API credentials (stored securely in environment variables, not in code) to automatically add the ACM certificate validation CNAME record and the tech blog CNAME.

Session Transcript Format Decision

Claude Code stores session transcripts in JSONL format (JSON Lines) rather than plain text. This was chosen because it:

  • Preserves structured metadata (timestamps, tool names, result status)
  • Allows fine-grained extraction of specific events (file writes vs. reads vs. API calls)
  • Enables future analytics on development patterns and infrastructure changes
  • Simplifies credential sanitization by identifying specific fields to redact

Infrastructure Deployment Details

Provisioning Command Example (Redacted)

python3 /Users/cb/Documents/repos/tools/tech_blog_init.py \
  --property queenofsandiego \
  --domain queenofsandiego.com \
  --dns-provider route53 \
  --hosted-zone-id Z1ABC2DEF3GHI4JKLMN5O

For burialsatseasandiego.com:

python3 /Users/cb/Documents/repos/tools/tech_blog_init.py \
  --property burialsatseasandiego \
  --domain burialsatseasandiego.com \
  --dns-provider godaddy \
  --acm-cert-arn arn:aws:acm:us-east-1:ACCOUNT_ID:certificate/CERT_ID

Post-Deployment Verification