Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

I'll transform the completed inventory into a technical blog post for your engineering audience.

Estate-Wide Web Property Audit: 60+ Domains, Three Deployment Patterns, and a Crawler-Blocking Bug Across a Dozen Sites

What Was Done

On 2026-07-04, I conducted a complete inventory of every web property in the JADA estate—from revenue-primary charter sites to client-hosted studios, campaign microsites, and internal operations dashboards. Using estate_map, estate_search, and estate_read against the canonical icloud-jada-ops repository, combined with a live sweep of response codes across all domains, I documented 60+ distinct properties, their deployment pipelines, and critical TODO/broken items. The goal: understand what exists, where it lives, how it's deployed, and what's silently broken.

Why This Matters

The estate had grown organically over years—revenue sites, brand expansions, client work, and side ventures, each with its own deployment surface, credential scope, and maintenance surface area. Without a single source of truth, critical broken items (like unsubscribe.queenofsandiego.com returning 400 during CAN-SPAM compliance reviews) stay dark until an audit surfaces them. Documenting the actual state—not the intended state—lets us prioritize by impact and identify patterns worth fixing once, estate-wide.

Three Core Deployment Patterns

Pattern 1: JADA Hub + Subdomains (S3 + CloudFront)
The primary revenue sites and internal ops tools all deploy through the same pipeline:

  • ~/bin/jada-deploy (profile: queenofsandiego) pushes code to S3 buckets: sailjada.com, queenofsandiego.com, shipcaptaincrew.queenofsandiego.com
  • CloudFront distributions cached in front (e.g., distribution EPF415U2AO8B3 for the crew site)
  • Service subpaths use CachingDisabled for dynamic content: /print/*, /g/* (guest pages), /api/*
  • Internal tools (helm., progress., ops., channels.) all sit under queenofsandiego.com subdomains with 401-gating where appropriate

Pattern 2: Templated Brand-Expansion Factory
The queenof-cities cluster (12 city sites under a shared deploy) follows the same S3 + CloudFront pattern but with per-city template rendering:

  • Source lives in /Users/cb/icloud-repos/sites/queenof-cities/ with its own CLAUDE.md and infrastructure docs
  • Single S3 bucket qos-city-sites, single CloudFront distribution E176JRMB92GPAJ
  • Critical gap: every city page is marked noindex, so zero organic SEO accrues despite real build effort

Pattern 3: Dangerouscentaur Studio Cluster
A separate credential surface for CB's web design/dev work, hosting 15+ client sites and internal products:

  • Per-site S3 buckets under dc-sites/ namespace + individual CloudFront distributions
  • Some clients (e.g., expertyachtdelivery.com) have their own IAM users
  • Different credential scope from JADA, but same deployment topology

Critical Infrastructure Findings

Crawler-Blocking Bug (Affects 12+ Properties)
A systematic issue: /robots.txt and /sitemap.xml return 403 across dangerouscentaur sites (ambercadaver.com, aych.dangerouscentaur.com, chuckladd.com, emildanila.com, shipyard, etc.) and multiple Rady Shell concert funnels (bobdylan., brandicarlile., gipsykings., etc.). This is likely a bucket-policy gap preventing crawlers from accessing public content, and it's suppressing organic traffic from SEO engines estate-wide. One policy fix would resolve it across the entire cluster.

Deployment Gaps and Missing Scaffolding

  • burialsatseasandiego.com — highest revenue-per-charter property, but zero ICM infrastructure (no CLAUDE.md, CONTEXT.md, or deployment docs). Google Business Profile unclaimed 9 days after SEO cutover. 76-contact funeral-home CRM untouched.
  • quickdumpnow.com — booking form not wired to backend Lambda; dashboard returns empty arrays. Marketing shell only. qdn-clean-load LaunchAgent broken (missing ANTHROPIC_API_KEY in launchd environment).
  • dragonbodyguards.com — intake Lambda and deploy script fully written but never deployed; every contact form is still bare mailto:

Broken Items with Compliance Risk
unsubscribe.queenofsandiego.com returns 400. The unsubscribe watcher is down until Google re-auth, and this is CAN-SPAM-relevant—email blasts could face legal exposure if unsubscribe fails silently.

Dead/Orphaned Properties
adamcherrycomics.com (root), hatifus.org, test.dangerouscentaur.com`, and salejada.com (a likely defensive typo-squat) all return 000 or 404. Candidates for cleanup queue if not defensive registrations.

Key Decisions and Trade-offs

Why inventory now? The estate's complexity has outpaced documentation. Individual sites have deployment docs (e.g., queenof-cities has its own infra.md), but the cross-estate patterns and failure modes were invisible without a unified view. Keeping this inventory in the canonical jada-ops repository (not on a wiki) ensures it stays close to the source of truth and can be updated as deploy pipelines evolve.

What's Next

  • One S3 bucket-policy fix: Allow crawler access to /robots.txt and /sitemap.xml across the dangerouscentaur and Rady Shell clusters. Cheap, high-leverage, affects 12+ properties.
  • CAN-SPAM compliance: Fix unsubscribe.queenofsandiego.com before the next blast send.
  • Cleanup queue: Confirm with CB whether salejada.com, hatifus.org, and test.dangerouscentaur.com are defensive registrations before letting them lapse.

The full inventory is saved in /Users/cb/icloud-jada-ops/reports/2026-07-04-web-property-inventory-all-domains-in-the-estate.md — grouped by function, with deployment pipeline and TODO/broken items per property.