Building a Multi-Site Technical Blog Engine with Auto-Generated Session Transcripts

```html

This session implemented an automated technical documentation system that captures development work across four domains (queenofsandiego.com, sailjada.com, dangerouscentaur.com, and burialsatseasandiego.com) and publishes granular, detailed blog posts to tech subdomains. The system transforms Claude Code session transcripts into searchable technical narratives.

What Was Done

Created a tech_blog_generator.py script that parses Claude Code JSONL session transcripts and generates HTML blog posts
Built tech_blog_init.py to provision S3 buckets, CloudFront distributions, and DNS records for four tech blog sites
Implemented a Stop hook (tech_blog_stop.sh) that automatically generates and publishes blog posts at session end
Integrated tech blog navigation into Ship's Papers menu on each primary domain
Set up infrastructure for tech.queenofsandiego.com, tech.sailjada.com, tech.dangerouscentaur.com, and tech.burialsatseasandiego.com
Configured DNS records across Route53 (sailjada.com, queenofsandiego.com), Namecheap (dangerouscentaur.com), and GoDaddy (burialsatseasandiego.com)

Technical Architecture

Session Transcript Processing

Claude Code stores session data in ~/.claude/projects/ as JSONL files containing tool uses, command execution, and conversation history. The blog generator:

Reads the session transcript from the active Claude Code project directory
Parses tool use entries to extract file modifications (created/edited paths)
Extracts command executions and their results
Filters out sensitive data: credentials, API keys, passwords, tokens, and personal information
Groups changes by logical components (infrastructure, frontend, backend, tools)
Generates semantic HTML with proper heading hierarchy and code blocks
Uploads to the appropriate tech blog S3 bucket with unique slug based on timestamp

Infrastructure Deployment Pattern

Each tech blog uses a consistent three-layer architecture:

Storage: S3 bucket (e.g., tech-queenofsandiego-blog) configured with static website hosting
Distribution: CloudFront distribution with origin pointing to S3, caching optimized for HTML/CSS/JS
DNS: CNAME or A record pointing to CloudFront distribution domain

Wildcard ACM certificates were already in place (*.queenofsandiego.com and *.sailjada.com in AWS Certificate Manager), so CloudFront distributions could be created immediately with HTTPS.

Domain-Specific DNS Strategy

Different domains use different DNS providers, requiring provider-specific configuration:

queenofsandiego.com & sailjada.com: Route53 hosted zones; created CNAME records pointing to CloudFront distributions
dangerouscentaur.com: Namecheap DNS; created CNAME record tech.dangerouscentaur.com → CloudFront distribution
burialsatseasandiego.com: GoDaddy DNS; requested ACM DNS validation CNAME, then created blog CNAME record

Key Implementation Details

Stop Hook Integration

The Stop hook (~/.claude/hooks/tech_blog_stop.sh) executes when a Claude Code session ends:

#!/bin/bash
# On session stop:
# 1. Detect which site(s) were modified in the session
# 2. Call tech_blog_generator.py with current transcript path
# 3. Upload generated HTML to appropriate tech blog S3 buckets
# 4. Invalidate CloudFront caches
# 5. Log operation to hook.log

This ensures every development session automatically produces a blog post without requiring manual intervention.

Credential Filtering

The generator implements multi-layer credential filtering:

Redacts patterns matching AWS key formats, API tokens, bearer tokens
Strips GoDaddy API credentials, Namecheap API keys, and environment variable secrets
Removes email addresses and phone numbers from command output
Preserves domain names, IP addresses (as needed for DNS discussion), and infrastructure resource IDs (S3 buckets, CloudFront dist IDs, hosted zone IDs)
Keeps function/method names, file paths, and technical details that provide engineering value

Blog Generator Output

Generated posts include:

Title: Specific, descriptive summary of work performed
Summary section: High-level overview of changes
Files modified: Complete list with exact paths, organized by type
Commands executed: Full command names and key arguments (credentials redacted)
Technical decisions: Why certain approaches were chosen
Infrastructure changes: Exact resource names, IDs, configurations
Metadata: Session timestamp, word count, file modification count

Posts are published as YYYY-MM-DD-slug.html files with full HTML boilerplate, making them immediately viewable in a browser.

Navigation Integration

Updated Ship's Papers menu on each domain to include a "Technical Blog" link pointing to the tech subdomain. For example, on queenofsandiego.com's index.html, added a navigation item that links to https://tech.queenofsandiego.com/, visible in the dropdown alongside existing links to Events, Mother's Day specials, and other content.

Multi-Domain Coordination

The system tracks which domains were active in a session (by detecting modifications to files in sites/queenofsandiego.com/, sites/sailjada.com/, etc.) and publishes blog posts only to affected tech blogs. A single session might generate posts across multiple tech blogs if work touched multiple primary domains.

Why This Approach

Automated capture: No manual blogging; transcripts are the primary record of work
Granular detail: Every file change and command is captured; no high-level summarization that loses context
Credential safety: Sensitive data is programmatically stripped before publication
Persistent searchable record: Engineering decisions and infrastructure changes are documented for future reference and audits
Transparency: Sergio and the team can see exactly what was built, when, and why
Scalable: Adding a fifth domain requires only updating the config file; the system handles the rest

What's Next

Monitor the first few auto-generated posts for quality and false-positive credential redactions