Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Orchestrating Multi-Site Deployments and Daemon Health Monitoring: From GA4 Integration to CloudFront Cache Invalidation

This session involved coordinating deployments across three distinct web properties, establishing Google Analytics 4 pipeline infrastructure, and conducting a comprehensive health audit of the jada-agent orchestrator daemon running on AWS Lightsail. Here's the technical breakdown of what was accomplished and why.

The Multi-Site Deployment Pipeline

We executed a coordinated update strategy across three separate domains hosted in our infrastructure:

  • 86from.com — A newly renamed property (previously 86dfrom.com) requiring immediate SEO and content updates
  • sailjada.com — The primary site with iterative HTML refinements
  • queenofsandiego.com — Google Apps Script automation for booking workflows

The decision to batch these changes into a single development session was intentional: it allowed us to standardize deployment patterns, verify CloudFront invalidation logic once rather than three times, and maintain consistency in our S3-backed static site architecture.

GA4 Authentication and Data Pipeline

A critical component of this session involved establishing programmatic access to Google Analytics 4 data. We created /Users/cb/Documents/repos/tools/auth_ga.py to handle OAuth2 credential flow for the dangerouscentaur account:


# Pattern: Authenticate once, cache credentials, reuse across properties
# The script validates that google-auth-oauthlib is installed
# and verifies client_id and client_secret exist in the stored token

Why this approach? Rather than manually checking analytics dashboards, we wanted to:

  • Pull 7-day GA4 reports programmatically for 86dfrom.com (now 86from.com)
  • Integrate analytics validation into the deployment pipeline
  • Create a reusable auth pattern for multiple GA4 properties under the same Google account
  • Avoid credential re-entry by caching OAuth tokens securely

The script successfully enumerated all GA4 accounts and properties accessible with the stored credentials, confirming we have read access to the analytics data for our target domains.

86from.com: Directory Rename and SEO Content Deployment

The 86dfrom.com directory was renamed to 86from.com to align with the actual domain registration. This required:

  1. Renaming the site directory: /Users/cb/Documents/repos/sites/86dfrom.com → /Users/cb/Documents/repos/sites/86from.com
  2. Creating a new SEO-focused content page at /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean
  3. Updating the index.html file to reflect the renamed structure
  4. Deploying to S3 and invalidating CloudFront cache

The SEO page creation was strategic: it targets a long-tail keyword ("what does 86d mean") that drives organic search traffic to the 86from.com property. By creating dedicated content rather than a redirect, we capture search intent and improve the domain's topical relevance.

Booking Widget JavaScript Refactoring

The most intricate technical work involved debugging the booking widget embedded in the sailjada.com index.html. We discovered a templating conflict:


# Issue: Double braces {{ and }} appearing both inside and outside
# the booking widget code block, causing parser ambiguity

The root cause was a mismatch between our HTML templating syntax and the booking widget's internal variable references. We:

  1. Identified all {{ and }} occurrences across the file
  2. Determined which ones belonged to the booking widget section vs. the broader HTML template
  3. Selectively replaced only the booking widget's double braces with single braces to eliminate parsing ambiguity
  4. Ran syntax validation on the extracted JavaScript block to confirm correctness

This pattern is important: when embedding third-party widgets with their own templating syntax, always namespace or escape conflicting delimiters. We kept a versioned comment tag with the model ID inside the booking widget for future reference.

Infrastructure: S3, CloudFront, and Deployment Automation

Our deployment pipeline follows this sequence:


# 1. Stage changes to S3 staging bucket
# 2. Validate via staging CloudFront distribution
# 3. Deploy to production S3 bucket
# 4. Invalidate production CloudFront cache with /* pattern
# 5. Verify DNS resolution and TLS certificate validity

Why staging first? It allows us to test a complete cache invalidation cycle, verify DNS resolution, and check TLS certificate expiration before production traffic reaches the changes. The CloudFront distribution ID and bucket names are stored in environment configuration; we use wildcard invalidation (/*) to ensure all edge locations clear their cache within seconds.

Daemon Health Audit: jada-agent.service on Lightsail

We conducted a comprehensive health check on the orchestrator daemon running at 34.239.233.28 by obtaining temporary SSH credentials via the AWS Lightsail API (rather than storing persistent keys locally):


# Command pattern: Use Lightsail API to fetch temporary credentials
# instead of managing jada-key files in ~/.ssh
# This reduces key exposure surface and aligns with AWS best practices

Health Status Summary:

  • Service uptime: 3 days (running since May 10)
  • CPU utilization: 0.65% average — normal for polling loop
  • Memory: 144MB of 914MB — excellent
  • Disk: 6.2GB of 39GB (17% used) — ample headroom
  • Session throughput: 3 of 5 daily sessions used; 2 completed meaningful work

Critical Issue Identified: The port_sheet_sync.py Google OAuth token is expired or revoked. Every 30-minute sync attempt since afternoon has returned HTTP 400 errors. This requires immediate re-authentication through the Google OAuth consent flow.

Non-Critical Issue: Two of today's three agent sessions hit the 30-turn Claude API limit and exited with code 1. This isn't a daemon crash — the logging captures it, and the daemon continues. However, if this pattern prevents complex tasks from completing, we should consider increasing the per-session turn budget or breaking larger tasks into smaller subtasks.

Key Architectural Decisions

  • Temp credentials over stored keys: Using Lightsail API-generated temporary credentials reduces persistent key management overhead and improves auditability
  • CloudFront wildcard invalidation: Rather than invalidating specific paths, we use /* to ensure cache coherence across the entire distribution
  • Staged deployment with validation: Testing on a staging CloudFront distribution catches issues before production traffic
  • Programmatic GA4 access: Caching OAuth tokens enables automated analytics integration without manual dashboard checking
  • Scoped OAuth for GA: Using Google credentials scoped to Analytics Data API reduces attack surface vs. unrestricted credential reuse