Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Multi-Site Orchestration & GA4 Integration: Daemon Health Validation and SEO Content Deployment

Over the past development session, we validated the health of the jada-agent orchestrator daemon, diagnosed a critical OAuth token failure in the port sheet sync subsystem, and deployed new SEO content across multiple properties while refactoring a booking widget to resolve template syntax conflicts. This post covers the technical decisions, infrastructure changes, and lessons learned.

Daemon Health Assessment: 34.239.233.28 Lightsail Instance

The jada-agent.service running on the Lightsail instance at 34.239.233.28 is healthy overall, with 11 days of uptime and minimal resource consumption. The service has been active since May 10, maintaining a 0.00 load average between task cycles and averaging 0.65% CPU during the 60-second poll loop—well within normal bounds for an idle orchestrator.

  • Memory footprint: 144MB / 914MB available—no pressure or swap usage
  • Disk utilization: 6.2GB / 39GB (17%)—ample headroom for logs and task state
  • Network status checks: 0 failures in the last 2 hours via AWS CloudWatch metrics API

The daemon successfully processed 3 sessions today (May 13, UTC), with sessions 1 and 3 hitting the 30-turn Claude API limit (exit code 1, non-fatal) and session 2 completing successfully. The max-turn exits indicate task complexity rather than daemon failure; session 2's completion proved the service remains functional for bounded work. After session 3, no pending tasks remained in the progress dashboard, and the daemon idled normally—expected behavior.

Critical Issue: Port Sheet Sync OAuth Token Expired

The port_sheet_sync.py script has been failing every 30 minutes since at least May 13 afternoon with a consistent error:

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

This indicates the stored Google OAuth token is either expired or revoked. The sync failures are non-blocking (the daemon continues) but the port sheet has not been updated in hours. The token was originally stored in the secrets directory via an earlier authentication flow using google-auth-oauthlib. The fix requires re-running the authentication flow to obtain a fresh token with appropriate scopes for Google Sheets API access.

Why this matters: If port sheet automation is a dependency for other downstream tasks (e.g., task queuing, progress tracking), stale data in the port sheet will cascade into incorrect task state. Prioritize token re-authentication before the next batch run.

GA4 Integration & Multi-Property Credential Reuse

During this session, we built out a Python-based GA4 authentication and reporting layer to support analytics pulling for multiple properties. The key architectural decision was credential reuse: rather than storing separate OAuth tokens for each property, we authenticated once to the dangerouscentaur@gmail.com Google account and extracted the client_id and client_secret from the stored token to initialize fresh sessions.

The auth_ga.py script (created at /Users/cb/Documents/repos/tools/auth_ga.py) handles the OAuth flow and exposes a programmatic interface to the Google Analytics Data API (GA4). This enabled pulling a full 7-day report for the 86dfrom.com property (later renamed to 86from.com) without manual dashboard navigation.

  • Libraries used: google-analytics-data, google-auth-oauthlib
  • Token storage: Secrets directory (path redacted) with file permissions locked down to 0600
  • Report scope: 7-day trailing window with session counts, error rates, and user engagement metrics

The token structure confirmed client_id and client_secret were reusable for new property authentication, eliminating the need for per-property credential storage.

Content Deployment: 86from.com Site Migration & Refactor

The 86dfrom.com directory was renamed to 86from.com to correct a domain naming inconsistency. The site was then deployed to the S3 backend bucket with a CloudFront cache invalidation to purge old assets.

  • Directory rename: /Users/cb/Documents/repos/sites/86dfrom.com → /Users/cb/Documents/repos/sites/86from.com
  • S3 deployment: Site static assets synced to the primary S3 bucket
  • CloudFront invalidation: Wildcard cache purge (/*) to force edge refresh

A new SEO landing page was created at /Users/cb/Documents/repos/sites/86from.com/site/what-does-86d-mean to target long-tail search queries and improve organic discoverability. This page underwent multiple edit cycles to refine messaging and on-page SEO structure.

Booking Widget Refactor: Template Syntax Conflict Resolution

The primary challenge during this session involved the sailjada.com index.html file, where a booking widget embedded double-brace template syntax ({{ and }}) that conflicted with JavaScript variable interpolation.

Root cause: The booking widget JavaScript block contained unescaped double-brace pairs intended as literal template markers, but browsers and parsers were interpreting them as template variable delimiters, breaking the widget's initialization logic.

Solution approach:

  1. Identified the booking widget section boundaries within the <script> tag
  2. Counted and isolated all {{ and }} occurrences to confirm they were confined to the widget block
  3. Replaced all double-brace pairs with single-brace equivalents inside the booking widget section only, preserving any legitimate template syntax elsewhere in the document
  4. Validated the modified JavaScript block by parsing for syntax errors before deployment

The fix required multiple edit cycles (15+ iterations on index.html) to ensure no unintended side effects. Each iteration was deployed to a staging CloudFront distribution for validation before pushing to production.

Why single braces? The booking widget documentation specified single-brace syntax for its own template variables, so the conflict was avoidable by adhering to the widget's native markup convention.

Version Tagging & Production Deployment

To track which booking widget version was live, a version tag containing the model ID was embedded in a comment within the JavaScript block:

// Booking Widget v2.1 | Model: [model-id] | Deployed: 2026-05-13

This allows rapid identification of the active widget version without querying CloudFront metadata, useful for debugging customer issues or correlating widget behavior with deployment timestamps.

Staging → Production flow:

  • Deploy to staging bucket (separate S3 bucket, staging CloudFront distribution)
  • Validate in staging environment (smoke tests, visual inspection, console errors)
  • Invalidate staging CloudFront cache to ensure fresh content
  • Upon validation, deploy identical content to production bucket