Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Deploying Multi-Site Content Infrastructure with GA4 Analytics Integration and Daemon Health Monitoring

This session involved a complex orchestration of content deployment, Google Analytics 4 integration, and infrastructure health monitoring across multiple properties. We'll walk through the technical decisions, architecture patterns, and specific implementation details that emerged during this development cycle.

What Was Done

  • Established GA4 authentication pipeline for analytics data extraction
  • Deployed three distinct web properties to S3 with CloudFront distribution invalidation
  • Fixed JavaScript template syntax errors in booking widget code
  • Monitored and diagnosed jada-agent orchestrator daemon health across a 3-day uptime window
  • Identified and documented OAuth token expiration affecting downstream sync processes

Technical Details: GA4 Integration Architecture

The analytics pipeline required establishing OAuth 2.0 authentication to access Google Analytics 4 data. The approach involved creating a Python-based authentication module at /Users/cb/Documents/repos/tools/auth_ga.py that handles the credential exchange and token refresh cycle.

Rather than embedding credentials directly in scripts, the system stores service account tokens in a secured configuration directory and uses the google-auth-oauthlib library to refresh tokens programmatically. This pattern allows multiple properties to share authentication context while maintaining credential isolation. The token structure itself was validated to ensure it contained both client_id and client_secret fields necessary for reuse across different GA4 properties.

The authentication workflow proceeds as follows:

# Pseudo-code pattern (no actual credentials)
python3 ~/Documents/repos/tools/auth_ga.py --account user@gmail.com
# Returns: Valid token stored in secured config directory
# Subsequent queries use this token to pull GA4 reports

Once authenticated, the system queries GA4 accounts and properties accessible under the authenticated account. For the 86dfrom.com property, we successfully extracted 7-day reporting data including session counts, user engagement metrics, and error rates. The GA Data API (v1beta) allows dimensional and metric queries, enabling detailed traffic analysis without manual dashboard navigation.

Content Deployment and Site Restructuring

The session involved managing three separate website properties across S3 buckets with CloudFront distribution acceleration:

86from.com Property Migration

The directory structure was reorganized from 86dfrom.com to 86from.com to align with DNS records. The site contains:

  • /Users/cb/Documents/repos/sites/86from.com/site/index.html — primary landing page
  • /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean — SEO content page

The SEO page was newly created as a separate content asset targeting keyword variations. After edits, the entire directory was deployed to its S3 bucket with subsequent CloudFront cache invalidation using path-based patterns to ensure fresh content delivery within seconds rather than waiting for TTL expiration.

sailjada.com Main Property

The primary sailjada.com index.html underwent extensive iteration (16 edits during this session). Changes focused on structuring landing page elements and optimizing for conversion funnel clarity. This property serves as the primary user-facing domain and required multiple refinement cycles before achieving desired layout and content hierarchy.

queenofsandiego.com Booking Automation

The BookingAutomation.gs file (Google Apps Script) was modified to fix booking widget rendering. The issue involved double-brace template syntax conflicting with Google Sheets function evaluation.

Booking Widget JavaScript Template Syntax Fix

A critical bug emerged in the booking automation widget: double-brace notation {{ }} was being interpreted as Google Sheets formula syntax rather than JavaScript template literals. This caused parsing errors when the script attempted to render dynamic booking data.

The solution involved surgical replacement of template syntax specifically within the booking widget section while preserving standard Google Sheets function calls elsewhere in the script. The workflow:

  • Identified exact line numbers containing the booking widget JavaScript block
  • Extracted the JavaScript source for isolated syntax validation
  • Replaced conflicting {{ }} syntax with single braces or alternative template approaches
  • Verified the modified JavaScript parsed without errors using Node.js or browser DevTools
  • Embedded version tags with model identifiers into code comments for deployment tracking

This pattern—localizing syntax fixes to specific functional blocks rather than global replacement—prevented breaking changes to unrelated sheet formulas while fixing the widget rendering issue.

Infrastructure: jada-agent Daemon Monitoring

The orchestrator daemon running on AWS Lightsail instance 34.239.233.28 required health verification. Direct SSH access using stored key material was unavailable, necessitating a multi-layered diagnostic approach:

AWS Systems Manager Session Manager Alternative

Rather than relying on stored SSH keys, the session used AWS Lightsail's temporary credential API to generate short-lived access certificates. This approach requires:

  • IAM permissions for lightsail:GetInstanceAccessDetails
  • Valid AWS credentials in local environment
  • OpenSSH client configured to accept certificate-based authentication
# Retrieve temporary access credentials via Lightsail API
aws lightsail get-instance-access-details --instance-name jada-agent-prod --region us-east-1
# Response includes temporary SSH private key valid for limited window
# SSH with certificate: ssh -i temp-key ubuntu@34.239.233.28

Daemon Health Findings

Once connected, the diagnostic revealed:

  • Service Status: jada-agent.service active and running continuously since May 10 (3+ days uptime)
  • Resource Utilization: CPU ~0.65% average (normal for 60-second polling loop), memory 144MB/914MB, disk 6.2GB/39GB (17% utilization)
  • Daily Activity: 3 of 5 available sessions consumed; 2 sessions hit the 30-turn Claude limit (exit code 1), 1 session completed successfully
  • System Load: 0.00 load average indicating idle state between task pickups; no CPU spikes detected in 2-hour metrics window

Critical Issue: OAuth Token Degradation

The port_sheet_sync.py script, which synchronizes booking data back to Google Sheets every 30 minutes, was failing with consistent HTTP 400 errors. The root cause: the Google OAuth token used by that script had expired or been revoked. This prevented the sync cycle from completing for at least 12+ hours.

The fix requires re-authentication using the same credential refresh pattern as the GA4 integration, but targeting the Google Sheets API scope instead of Analytics scope.

Key Decisions and Rationale

Why separate auth scripts instead of monolithic module? Each property and integration has different OAuth scopes and token refresh requirements. Separating auth_ga.py from booking-related auth allows independent token management and makes credential rotation less risky—rotating one token doesn't cascade to unrelated integrations.

Why temporary SSH keys instead of