Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Building a Multi-Site Auto-Generated Technical Blog System with Session Capture

What Was Done

Created a comprehensive technical blogging infrastructure that automatically captures development work across four separate websites and generates granular, detailed technical posts. The system monitors Claude Code sessions, extracts specific technical details (file paths, commands, infrastructure changes), and publishes them to dedicated tech subdomains while filtering out credentials and sensitive information.

Architecture Overview

The system consists of four key components:

  • Session Capture Hook: A Stop hook in Claude Code settings that triggers when sessions end
  • Blog Generator: Python script that parses session transcripts and extracts technical details
  • Infrastructure Layer: S3 buckets, CloudFront distributions, and DNS entries for four tech blogs
  • Navigation Integration: Links from "Ship's Papers" menu to each tech blog

Technical Implementation

Session Capture Mechanism

The system uses Claude Code's Stop hook capability, configured in /Users/cb/.claude/settings.json. When a session ends, the hook script (/Users/cb/.claude/hooks/tech_blog_stop.sh) executes and reads the session transcript from the standard Claude Code session directory structure. Session data is stored in JSONL format (one JSON object per line) in the Claude projects directory, specifically under /Users/cb/.claude/projects/-Users-cb-Documents-repos/sessions/.

Each transcript file contains detailed tool use entries including:

  • File operations (reads, writes, edits) with full paths
  • Command execution logs with output
  • Tool interactions with input parameters and results
  • Timestamps and session metadata

Blog Generator Script

The generator (/Users/cb/Documents/repos/tools/tech_blog_generator.py) performs these operations:

  • Reads the most recent session transcript in JSONL format
  • Extracts file modifications with exact paths (e.g., /Users/cb/Documents/repos/sites/queenofsandiego.com/concert-nights.html)
  • Identifies infrastructure changes (S3 buckets, CloudFront distribution IDs, Route53 zones)
  • Captures command executions and outputs
  • Filters out sensitive data using regex patterns that match AWS credentials, API keys, and personal information
  • Generates structured HTML with semantic tags (<h2>, <h3>, <code>, <pre>)
  • Routes content to appropriate S3 bucket based on site context

The filtering mechanism applies these rules:

- Redact AWS_SECRET_ACCESS_KEY, GODADDY_API_KEY patterns
- Remove email addresses and phone numbers
- Strip authorization headers and tokens
- Replace actual domain credentials with [REDACTED]
- Preserve technical details: function names, file paths, bucket names, distribution IDs

Infrastructure Deployment

Created four parallel blog infrastructures using the tech_blog_init.py script:

  • tech.queenofsandiego.com
    • S3 bucket: qos-tech-blog
    • CloudFront distribution: Uses existing wildcard cert *.queenofsandiego.com
    • DNS: Route53 in sailjada.com hosted zone (CNAME to CloudFront)
  • tech.sailjada.com
    • S3 bucket: jada-tech-blog
    • CloudFront distribution: Uses existing wildcard cert *.sailjada.com
    • DNS: Route53 hosted zone for sailjada.com
  • tech.dangerouscentaur.com
    • S3 bucket: dc-tech-blog
    • CloudFront distribution: Routes through existing wildcard distribution (E2Q4UU71SRNTMB) on dc-sites bucket
    • DNS: CNAME record at Namecheap (dangerouscentaur.com registrar)
  • tech.burialsatseasandiego.com
    • S3 bucket: bats-tech-blog
    • CloudFront distribution: Uses ACM certificate with DNS validation
    • DNS: CNAME record at GoDaddy (burialsatseasandiego.com registrar)

Key Decision: Wildcard Certificates vs. Site-Specific

For queenofsandiego.com and sailjada.com, we leveraged existing wildcard ACM certificates. This eliminated the need to request new certificates and reduced DNS validation overhead. For dangerouscentaur.com, the existing wildcard CloudFront distribution on the dc-sites bucket provided a practical solution without additional infrastructure. For burialsatseasandiego.com, we provisioned a new certificate with GoDaddy-hosted DNS validation using the GoDaddy API integration already in place.

Navigation Integration

Updated /Users/cb/Documents/repos/sites/queenofsandiego.com/index.html to include a "Technical Blog" link in the Ship's Papers dropdown menu. The link points to https://tech.queenofsandiego.com and is positioned logically within the administrative/documentation section. Similar changes were made to the other sites' navigation structures.

Credential Filtering Strategy

The blog generator uses Python regex patterns to identify and redact sensitive information while preserving technical value:

import re

# Patterns to redact
patterns = {
    'aws_secret': r'(aws_secret_access_key\s*=\s*)([^\s]+)',
    'api_key': r'(api[_-]?key\s*[=:]\s*)([^\s]+)',
    'token': r'(token\s*=\s*)([^\s]+)',
    'auth': r'(Authorization:\s*Bearer\s*)([^\s]+)',
}

# Preserved: bucket names, distribution IDs, file paths, function names
# Example: "S3 bucket: qos-tech-blog" stays intact
# Example: "CloudFront dist ID: E3XAMPLE1BC" stays intact

Deployment Status

All four tech blog sites are now live and accessible:

  • tech.queenofsandiego.com — CloudFront deployed, DNS propagated
  • tech.sailjada.com — CloudFront deployed, DNS propagated
  • tech.dangerouscentaur.com — Routed through existing wildcard CF, CNAME at Namecheap
  • tech.burialsatseasandiego.com — CloudFront deployed, ACM DNS validation complete at GoDaddy

Test HTTP requests confirm all sites are returning 200 status