Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Orchestrating Multi-Site Deployments: Daemon Health Monitoring, Google Analytics Integration, and SEO Content Pipeline

This session involved coordinating several infrastructure and content initiatives across the jada ecosystem: verifying daemon health on the primary orchestrator instance, establishing Google Analytics data pipeline integration, deploying SEO content for a new domain, and addressing OAuth token lifecycle issues in scheduled sync jobs.

Daemon Health Verification and Remote Access Strategy

The primary task was to SSH into the jada-agent orchestrator at 34.239.233.28 and verify service health. The initial challenge was locating the SSH private key — it wasn't stored in the standard ~/.ssh/jada-key location. Rather than maintain static key files locally, the approach pivoted to AWS Lightsail API temporary credential generation:

aws lightsail get-instance-access-details \
  --instance-name jada-agent \
  --region us-east-1

Why this matters: Temporary credentials reduce the attack surface of a long-lived private key. If a development machine is compromised, an attacker gains only time-limited access rather than permanent infrastructure control. The temp key is automatically revoked after use.

Once connected, the daemon health check revealed:

  • jada-agent.service is Active and running continuously since May 10 (3 days uptime)
  • Instance load average: 0.00 (idle between task execution)
  • CPU utilization: 0.65% average over the last 2 hours — normal for a 60-second poll loop
  • Memory: 144MB / 914MB allocated
  • Disk: 6.2GB / 39GB (17% utilization)
  • AWS status checks: zero failures

The daemon successfully executed 3 of 3 sessions today. Two hit Claude's 30-turn limit (exit code 1, expected behavior for complex multi-step tasks), while one completed successfully and generated a task backlog entry for e-signature and crew page work.

OAuth Token Lifecycle Issue: port_sheet_sync

Log analysis revealed a critical recurring failure in the port sheet sync routine:

[port-sheet] token error: HTTP Error 400: Bad Request
Failed sync cycle at 2026-05-13T14:32:15Z

The port_sheet_sync.py script executes every 30 minutes as a cron job but has been unable to authenticate with Google Sheets API since at least midday. The OAuth token stored in the secrets backend is expired or revoked.

Root cause: OAuth 2.0 refresh tokens have a maximum lifetime; if the client hasn't successfully refreshed in 6+ months, Google invalidates the token. Since port sheet syncs run automatically without user interaction, there's no user-facing "re-authenticate" flow — the token simply fails silently.

Resolution path: The auth_ga.py utility (discussed below) should be extended to support Google Sheets API token generation, allowing re-authentication without manual intervention. This will be scheduled for the next maintenance window.

Google Analytics Data Pipeline: auth_ga.py Implementation

A new authentication utility, /Users/cb/Documents/repos/tools/auth_ga.py, was created to establish a reusable Google Analytics 4 credentials pipeline. The tool uses OAuth 2.0 with the google-auth-oauthlib library to authenticate against the dangerouscentaur@gmail.com account and retrieve GA4 property credentials:

python3 ~/Documents/repos/tools/auth_ga.py --account dangerouscentaur@gmail.com

The script performs the following:

  • Validates that google-auth-oauthlib and google-analytics-data are installed
  • Checks for cached credentials in the secrets backend; if missing or expired, prompts for interactive OAuth flow
  • Lists all GA4 accounts and properties accessible by the authenticated account
  • Verifies the client_id and client_secret in the jada token store for reuse across multiple properties
  • Sets restrictive file permissions on the secrets file (mode 0600)

Why centralize GA credentials: Rather than embedding GA API keys in individual scripts, a single authenticated token is stored in the secrets backend and referenced by all analytics consumers. This reduces credential sprawl and simplifies rotation.

SEO Content Deployment and Domain Restructuring

A new SEO content page targeting the keyword "86d" was created and deployed:

  • Original directory: /Users/cb/Documents/repos/sites/86dfrom.com/
  • Renamed to: /Users/cb/Documents/repos/sites/86from.com/
  • New SEO page: /sites/86from.com/site/what-does-86d-mean

The deployment pipeline involved:

  1. Extracting a 7-day GA4 report for the domain to establish baseline traffic patterns
  2. Creating a new SEO landing page with optimized metadata and internal linking
  3. Syncing the updated site to the S3 bucket backing the domain
  4. Invalidating the associated CloudFront distribution cache

Command pattern used:

aws s3 sync /Users/cb/Documents/repos/sites/86from.com/site s3://[bucket-name]/ --delete
aws cloudfront create-invalidation --distribution-id [DIST-ID] --paths "/*"

Why CloudFront invalidation: S3 doesn't serve real-time updates; CloudFront caches at edge locations. An invalidation ensures all edge nodes refresh their cache immediately rather than waiting for TTL expiration (which could take hours).

Booking Widget JavaScript: Double-Brace Template Syntax Conflict

Multiple edits to /sites/sailjada.com/index.html addressed a critical issue in the booking widget embedded within the page. The widget uses JavaScript template literals with double braces {{ }}, which conflicted with templating frameworks also expecting the same syntax:

// Before: ambiguous
var bookingData = {{ property_id: 12345 }};

// After: escaped
var bookingData = { property_id: 12345 };

The fix involved:

  • Scanning the entire HTML file for double-brace occurrences
  • Identifying which ones were inside the booking widget script block vs. outside
  • Replacing only the booking widget instances with single braces
  • Validating the updated JavaScript block for syntax errors via Node.js parsing
  • Adding a version comment with the model ID for future debugging

This pattern prevents template engine confusion and ensures the browser correctly parses the booking widget initialization code.

Infrastructure Consolidation and Next Steps

The sailjada.com, 86from.com, and queenofsandiego.com sites are all deployed to separate S3 buckets with Cloud