Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Diagnosing and Remediating the JADA Agent Daemon: OAuth Token Expiration, Turn Limits, and Multi-Site Deployment Coordination

Over the past development session, we performed comprehensive health diagnostics on the JADA orchestrator daemon running on AWS Lightsail (34.239.233.28), identified a critical OAuth token failure in the port sheet sync subsystem, and coordinated multi-site HTML/JavaScript refactoring across three separate domains. This post documents the specific infrastructure patterns, remediation steps, and architectural decisions made.

Health Check: Daemon Status and Metrics Collection

The jada-agent daemon (`jada-agent.service`) has been running continuously since May 10 with 11 days of cumulative uptime. Rather than relying on local SSH key storage, we used AWS Lightsail's temporary credential API to establish access:

# Generate temporary SSH certificate via Lightsail API
aws lightsail get-instance-access-details \
  --instance-name jada-orchestrator \
  --region us-east-1

# Extract certificate and write to temporary file
# Connect via OpenSSH with cert-based auth
ssh -i /tmp/jada_cert.pem ubuntu@34.239.233.28 \
  "systemctl status jada-agent.service"

Why this approach: Storing long-lived SSH keys locally introduces security risk. Lightsail's temporary credential rotation (typically 60–120 second TTL) provides just-in-time access that automatically expires. This is especially important when the key pair (`jada-key`) is not stored in the standard `~/.ssh/` directory.

Once connected, we collected CPU, memory, disk, and network metrics via CloudWatch API and local system inspection:

  • CPU utilization: 0.65% average over last 2 hours (polling loop baseline, no spikes)
  • Memory: 144MB / 914MB (15.8% utilization — healthy)
  • Disk: 6.2GB / 39GB (17% used — ample headroom for logs and task state)
  • Status checks: 0 failures in the past 2 hours
  • Uptime: 11 days without restart

Session Activity and Turn Limit Behavior

The daemon manages Claude-based agent sessions with a hard limit of 30 turns per session. Today (UTC), three sessions were initiated:

  • Session 1 (00:00): Hit max turns (30) → exit code 1
  • Session 2 (00:02): Completed successfully → processed e-signature and crew page blockers, queued a needs-you task
  • Session 3 (00:05): Hit max turns (30) → exit code 1

The exit code 1 on max-turns completion is logged as an error but does not crash the daemon. After session 3, no new tasks were pulled from the progress dashboard, indicating the daemon returned to its normal idle polling state (60-second loop interval).

Decision rationale: The 30-turn limit is a cost and latency control mechanism. Complex tasks (e.g., refactoring multi-file HTML/JS across three separate sites) that consume all 30 turns should ideally be broken into smaller subtasks. However, the successful session 2 completion proves the daemon can handle meaningful work within the limit. If this becomes a bottleneck, we can increase the turn limit or implement task decomposition logic in the task enqueue phase.

Critical Issue: `port_sheet_sync` OAuth Token Expiration

The most significant finding was a persistent authentication failure in the port sheet sync subsystem. Every 30-minute sync attempt since at least mid-afternoon has logged:

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

The script `/Users/cb/Documents/repos/tools/port_sheet_sync.py` uses a stored Google OAuth token to write booking data to a shared sheet. This token has expired or been revoked. Port sheet syncs have been blocked for an unknown duration.

Remediation path: We created `/Users/cb/Documents/repos/tools/auth_ga.py` to handle OAuth token refresh and re-authentication. The pattern:

# Usage (no credentials shown)
python3 ~/Documents/repos/tools/auth_ga.py --account [email] --scopes sheets

# This script:
# 1. Checks for existing valid token in secure storage
# 2. If expired, attempts refresh using stored refresh_token
# 3. If refresh fails, initiates OAuth 2.0 authorization flow
# 4. Writes new token to encrypted credentials file
# 5. Secures permissions to 0600 (owner read/write only)

The auth module can be reused across multiple Google API consumers (GA Data API, Sheets API, etc.) by parameterizing the scopes. We confirmed that the stored credentials already contain both `client_id` and `client_secret` for the dangerouscentaur service account, so new auth attempts can reuse those without manual entry.

Multi-Site Deployment Coordination: 86from.com, sailjada.com, queenofsandiego.com

In parallel with daemon diagnostics, a significant refactoring operation was executed across three separate S3-backed CloudFront distributions:

86from.com (formerly 86dfrom.com)

  • Reason for rename: SEO consolidation and domain consistency
  • Directory operation: `/Users/cb/Documents/repos/sites/86dfrom.com/` → `/Users/cb/Documents/repos/sites/86from.com/`
  • New content: Created `what-does-86d-mean` page (SEO targeting for domain query variations)
  • Deployment: S3 bucket sync + CloudFront cache invalidation

We performed DNS and TLS certificate validation for 86d.com to understand the existing infrastructure before deployment. Wayback Machine snapshots showed historical site structure, confirming the new SEO page targets a legitimate content gap.

sailjada.com

The `index.html` file underwent 16+ edit cycles during this session. Analysis of the final HTML revealed a critical JavaScript issue in the embedded booking widget:

// Problem: Double-brace template syntax conflicting with Handlebars
// Original (broken):
<script>
  var bookingConfig = {{propertyId: "123", locale: "en"}};
</script>

// Corrected:
<script>
  var bookingConfig = {propertyId: "123", locale: "en"};
</script>

Root cause: The `{{` and `}}` syntax is Handlebars template syntax. When minified or served through a template engine, these double braces cause parsing errors. We searched for all occurrences outside the booking widget section, confirmed they only appeared in the widget block, and replaced them with single braces in the JavaScript context.

Validation: We extracted the booking widget JavaScript block and syntax-checked it via Node.js to ensure no parsing errors remained. Then we:

  1. Deployed the corrected index.html to the staging S3 bucket
  2. Invalidated the staging CloudFront distribution cache (pattern: `/*`)
  3. Embedded a version