Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Migrating a Dormant Property Site into Multi-Property Analytics & Fixing OAuth Token Expiry in Scheduled Sync Jobs

Over the past development session, we consolidated a previously unused domain (86d.com) into an active multi-property analytics pipeline, debugged daemon orchestration health, and identified a critical OAuth token expiration blocking our Google Sheets sync automation. Here's what happened, why, and what needs attention next.

The 86d.com Domain Recovery

The domain 86d.com had been dormant for some time. Through a WHOIS lookup and Wayback Machine analysis, we confirmed it was registered but inactive. Rather than let it sit idle, we made a strategic decision: repurpose it as a content hub for the restaurant/service industry, specifically targeting the phrase "what does 86 mean" — a high-intent SEO query in the hospitality vertical.

Why this approach: Low-competition keyword with existing search volume, thematic fit with our portfolio (we run hospitality/booking sites), and the domain already had some historical backlink equity. Minimal effort to activate; maximum potential ROI.

File Structure & Deployment

The site was scaffolded in:

/Users/cb/Documents/repos/sites/86from.com/

Note the directory name: originally created as 86dfrom, then renamed to 86from.com to match our standard naming convention. This matters for asset paths and CI/CD references.

  • index.html — Primary landing page, heavily edited (~20 iterations to get SEO and UX right)
  • what-does-86d-mean — Dedicated content page targeting the core search query

All HTML files were deployed to an S3 bucket (exact bucket name omitted for security, but follows pattern s3://[domain]-prod/) and fronted with CloudFront for caching and geographic distribution. After each deploy, we invalidated the CloudFront distribution cache to force immediate propagation.

Google Analytics 4 Integration

The site needed analytics instrumentation to track traffic and user behavior. We integrated it into an existing GA4 property under the dangerouscentaur@gmail.com account, which already manages properties for other domains in our portfolio.

Technical workflow:

  1. Created /Users/cb/Documents/repos/tools/auth_ga.py — a Python utility to authenticate against the Google Analytics API and retrieve property metadata
  2. Used OAuth 2.0 with stored credentials (client_id and client_secret) to list all GA4 accounts and properties
  3. Pulled a full 7-day GA4 report for 86dfrom.com to verify data collection was working
  4. The auth tool leverages google-auth-oauthlib library, which was already installed in the environment

The decision to reuse existing client credentials rather than create new ones was deliberate: it reduces OAuth consent screen friction and keeps credential sprawl contained. All credentials are stored in a secrets directory with restricted file permissions (600).

Booking Widget Bug Fix

During index.html edits, we discovered a JavaScript parsing issue in an embedded booking widget. The widget used double-brace syntax (e.g., {{ variableName }}) for templating, which conflicted with how the browser was interpreting the script tag.

Root cause: Template syntax overlap. The widget was designed for server-side template rendering, but we were embedding it client-side without a pre-processing step.

Fix applied:

  • Located the booking widget JavaScript block within the HTML file (lines identified via grep and text search)
  • Replaced all {{ with { and }} with } inside the widget section only, preserving double-braces outside the booking context where they weren't problematic
  • Syntax-validated the JavaScript block to confirm no parsing errors
  • Deployed fixed version to staging CloudFront distribution first for testing
  • Embedded a version tag with model ID in a comment within the widget for future auditing

This surgical fix avoided rewriting the entire widget while solving the immediate parsing issue.

Jada-Agent Daemon Health & OAuth Token Expiry

We performed a comprehensive health check on the daemon orchestrator instance (IP: 34.239.233.28) running on AWS Lightsail. Instead of relying on a local SSH key (which wasn't stored locally), we used the Lightsail API to generate temporary SSH credentials via Session Manager, connected to the instance, and pulled metrics and logs.

Key findings:

  • Service status: jada-agent.service is active and has been running for 3+ days without restart
  • Resource utilization: CPU ~0.65% average, memory 144MB/914MB, disk 6.2GB/39GB (17% used) — all healthy
  • Session counts: 3 of 5 daily sessions consumed; two hit the 30-turn Claude API limit (exit code 1, non-fatal), one completed successfully and generated a needs-you task for crew page work
  • Critical issue: port_sheet_sync.py Google OAuth token is expired, causing all 30-minute syncs to fail with HTTP 400 Bad Request

The port sheet sync failure is not a daemon issue — it's a credential refresh problem. The Google OAuth token stored in the environment or secrets has been revoked or expired. This needs immediate re-authentication using the same pattern as the GA auth tool.

Infrastructure & Architecture Patterns

Our setup follows a multi-layered approach:

  • Static content: S3 + CloudFront (geo-distributed caching, automatic gzip compression, no server-side processing needed)
  • Analytics: Google Analytics 4 API (read-only data aggregation, OAuth 2.0 credentialed access)
  • Orchestration: AWS Lightsail instance running systemd service (jada-agent.service) with cron-based task polling and Claude API integration for agent-driven task execution
  • Secrets management: Local file-based storage with restrictive permissions (600) — suitable for dev/staging, should migrate to AWS Secrets Manager for production

Key Decisions Made

  1. Repurpose vs. retire: Activating 86d.com was a judgment call — the domain had residual authority and we had spare bandwidth. Worth the ROI.
  2. OAuth credential reuse: Consolidating GA credentials under one account reduces operational burden and improves auditability.
  3. Surgical widget fix: Fixing only the conflicting syntax rather than refactoring the entire widget minimized risk of introducing new bugs.
  4. Temp SSH keys via API: Using Lightsail's temporary credential API instead of managing persistent keys locally improves security posture.

What's Next

  • Port sheet OAuth: Re-authenticate the Google OAuth token for port_sheet_sync.py and update the stored credentials. Consider implementing token refresh logic to