Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Orchestrating Multi-Site Deployments with GA4 Integration and Daemon Health Monitoring

This session involved coordinating infrastructure across multiple customer sites, implementing Google Analytics 4 data pipeline automation, and diagnosing health issues in the jada-agent orchestrator daemon running on AWS Lightsail. The work spanned authentication workflows, static site deployments, and real-time monitoring—all while maintaining isolation between production and staging environments.

What Was Done

  • Built and debugged Google Analytics 4 authentication pipeline in auth_ga.py
  • Deployed new SEO content to 86from.com with CloudFront invalidation
  • Fixed JavaScript template syntax errors in booking widget across multiple sites
  • Diagnosed jada-agent daemon health on Lightsail instance (34.239.233.28)
  • Identified and documented OAuth token expiration issue affecting port sheet sync
  • Set up GA4 data extraction for analytics reporting

Google Analytics 4 Integration Architecture

The session revealed a need to pull GA4 analytics data programmatically for multiple properties. Rather than relying on manual dashboard access, we implemented an authentication-first approach using the Google Auth library and GA Data API.

Authentication Flow:

  • Created /Users/cb/Documents/repos/tools/auth_ga.py to handle OAuth 2.0 credential management
  • Reused existing client_id and client_secret from the jada daemon's stored token (dangerouscentaur@gmail.com account)
  • Verified google-auth-oauthlib library was available in the Python environment
  • Implemented credential caching to avoid repeated auth flows
  • Locked down secrets file permissions immediately after credential storage

Data Access:

Once authenticated, we queried GA4 properties under the dangerouscentaur account and pulled 7-day reports for 86dfrom.com (which was subsequently renamed to 86from.com). This allowed us to confirm traffic patterns and validate that analytics tracking was active post-deployment.

Static Site Deployment Pipeline

The 86dfrom.com property underwent significant updates during this session, requiring careful orchestration across storage and CDN layers.

Directory Restructuring:

The project directory was renamed from /Users/cb/Documents/repos/sites/86dfrom.com to /Users/cb/Documents/repos/sites/86from.com. This change reflected a naming correction; all subsequent deployments targeted the updated path.

Content Updates:

  • Modified index.html across multiple iterations to refine messaging and layout
  • Created new SEO-focused content page at what-does-86d-mean directory
  • Validated all changes locally before deployment

Booking Widget JavaScript Fix:

Multiple sites (sailjada.com and queenofsandiego.com) contained template syntax errors where double braces {{ }} were used outside of their intended booking widget context. These conflicted with the widget's own template engine.

Issue: The booking widget uses double-brace template variables. When the surrounding HTML also used double braces (likely from a previous templating system), the parser became confused about scope and context.

Solution:

  • Identified all double-brace occurrences in /Users/cb/Documents/repos/sites/sailjada.com/index.html
  • Determined which braces were outside the booking widget section
  • Replaced offending {{ }} with single braces { } in non-widget areas
  • Extracted the booking widget JavaScript block and syntax-validated it independently
  • Deployed corrected version to staging bucket first
  • Invalidated staging CloudFront cache before pushing to production

S3 and CloudFront Deployment:

All static assets were deployed to their respective S3 buckets (naming convention: s3://[domain]-web), followed by CloudFront invalidation to clear edge cache. The staging bucket was used for pre-production validation to catch issues before they reached production CDN edges.

Jada-Agent Daemon Health Assessment

The orchestrator daemon running on Lightsail instance 34.239.233.28 required health verification and troubleshooting. Since the private SSH key was not stored locally, we used AWS Lightsail's temporary credential API to obtain ephemeral SSH access.

Access Method:

  • Attempted direct key lookup in ~/.ssh/ — not found
  • Checked repos.env for key path references — empty
  • Used AWS Lightsail API to retrieve temporary key via get-instance-access-details
  • Wrote temp key to local file, connected with standard OpenSSH, then removed temp credentials

Daemon Status Overview:

  • jada-agent.service: Active and running since May 10 (3+ days uptime)
  • System load: 0.00 — essentially idle between task executions
  • CPU utilization: 0.65% average, no spikes detected in 2-hour monitoring window
  • Memory: 144MB / 914MB (15% utilization) — healthy
  • Disk: 6.2GB / 39GB (17% used) — ample headroom for logs and state
  • Network status checks: 0 failures in last 2 hours

Task Processing Activity:

The daemon consumed 3 of 5 available daily sessions. Session 2 completed successfully and generated a needs-you task for manual review. Sessions 1 and 3 hit the 30-turn Claude context limit and exited with code 1—not a crash, but a graceful termination after exhausting the turn budget. The daemon correctly logged these as errors and remained running.

Critical Issue Found: OAuth Token Expiration

The port_sheet_sync.py script, which synchronizes booking data to Google Sheets every 30 minutes, has been failing consistently with:

[port-sheet] token error: HTTP Error 400: Bad Request

The OAuth token for this service is expired or revoked. Port sheet syncs have not executed since at least mid-afternoon. This requires immediate re-authentication of the Google service account token used by that script.

Key Decisions and Architecture Patterns

  • Credential Reuse: Rather than creating separate GA4 credentials, we reused the existing client_id/client_secret from the jada daemon's authenticated token. This reduces credential surface area and simplifies rotation.
  • Staging-First Validation: CloudFront deployments went to staging first to catch JavaScript parsing and template syntax errors before they reached production edges.
  • Ephemeral SSH Access: Instead of storing long-lived SSH keys locally, we used Lightsail's temporary