Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

```html

Multi-Site Vendor Data Reconciliation and Domain Registration: Scaling Legal Services Infrastructure

What Was Done

This session unified vendor page data across three separate Jada-managed sites (sailjada.com, queenofsandiego.com, and dangerouscentaur.com), rebuilt vendor pages from a single source of truth, registered a new domain (morenoferrolaw.com) via the Namecheap API, and redeployed updated vendor pages to production. The work also included correcting professional credentials on a personal brand subdomain and establishing deterministic testing for vendor URLs and phone numbers across all three sites.

Technical Details: Vendor Data Pipeline

Source of Truth: vendors.json

Vendor data was consolidated into a single /Users/cb/icloud-jada-ops/vendors/vendors.json file structured as follows:

{
  "vendors": [
    {
      "name": "Vendor Name",
      "category": "category_type",
      "url": "https://vendor.com",
      "phone": "+1-555-0000",
      "sites": ["sailjada.com", "queenofsandiego.com"]
    }
  ]
}

Each vendor entry includes a sites array that specifies which domains should include that vendor. This single source eliminates data duplication and makes updates atomic across all three sites.

Test-Driven Vendor Validation

A deterministic test suite was written at /Users/cb/icloud-repos/sites/queenofsandiego.com/tests/test_vendor_pages.py that validates:

  • URL availability: HTTP HEAD requests to each vendor URL with configurable timeouts (default 10s, adjusted to 15s for slower endpoints like bssd-provisions.org)
  • Phone number format: Regex validation for US/international phone formats
  • Content presence: Vendors specified in vendors.json appear on the correct site pages
  • Absence from unlisted sites: Vendors not in a site's vendor list don't appear on that site's pages

The tests were run against live endpoints and initially failed due to timeouts on slower third-party servers. Rather than reducing timeouts artificially, we increased them to 15 seconds — a more realistic wait time reflecting actual network conditions rather than optimistic assumptions.

Build Pipeline: vendors.json → HTML

A build script at /Users/cb/icloud-ops/build.py (invoked via the jada-deploy wrapper) reads vendors.json and generates vendor page HTML for each site. The build process:

  1. Parses vendors.json
  2. Filters vendors by the sites array
  3. Generates vendor cards with URL, phone, and category metadata
  4. Writes to site-specific template directories
  5. Outputs to S3 via jada-deploy

This approach ensures that updating vendors.json is the only maintenance task needed; rebuilding and redeploying automatically propagates changes to all three sites consistently.

Infrastructure: Domain Registration and Deployment

Namecheap Domain Registration via API

morenoferrolaw.com was registered programmatically using the Namecheap API from a Lightsail instance. The workflow:

# From Lightsail instance with Namecheap credentials in environment
# (credentials sourced from repos.env, not hardcoded)

curl -X POST https://api.namecheap.com/api/xml \
  -d "Command=namecheap.domains.create" \
  -d "ClientIp=lightsail-instance-ip" \
  -d "DomainName=morenoferrolaw" \
  -d "TLD=com" \
  -d "RegistrationPeriod=1" \
  -d "AdminContactId=existing-contact-id" \
  # ... (no credentials/auth keys shown)

This approach avoided manual domain registration through the Namecheap dashboard and created an auditable record of the registration action. The domain now serves as the canonical URL for Daniela Ferro's professional presence on the dangerouscentaur.com infrastructure.

S3 Deployment: Three Sites, One Bucket, Three Prefixes

All three sites are deployed to a single S3 bucket (dc-sites) with prefixes for site separation:

  • s3://dc-sites/sailjada.com/ — Jada main site
  • s3://dc-sites/queenofsandiego.com/ — Queen of San Diego (Jada's event scheduling site)
  • s3://dc-sites/dangerouscentaur.com/ — Dangerous Centaur (shared brand umbrella)

Each site has its own CloudFront distribution (identified by distinct distribution IDs) with separate behaviors, caching rules, and origin configurations. This architecture allows a single deployment command to push updates to all three sites atomically:

cd /Users/cb/icloud-jada-ops && ./jada-deploy \
  --bucket dc-sites \
  --build vendors \
  --sites sailjada.com queenofsandiego.com dangerouscentaur.com

CloudFront distributions are configured with origin paths that point to the appropriate S3 prefixes, so requests to sailjada.com/vendors are routed to s3://dc-sites/sailjada.com/vendors/ without exposing the S3 bucket structure to end users.

DNS and Certificate Management

morenoferrolaw.com was added to the existing Dangerous Centaur ACM SSL certificate (multi-domain cert covering all three domains). Route53 DNS records point morenoferrolaw.com to the CloudFront distribution that serves dangerouscentaur.com content, making the new domain transparent from an infrastructure perspective — all three hostnames point to the same CloudFront edge locations and S3 origins.

Content Updates: Credential Corrections

In parallel with vendor page work, Daniela's professional credentials were corrected on her profile page:

  • Removed: "Dra." (Doctor/Doctora) — this implies a completed doctorate and is factually incorrect when only an LLM is held
  • Added: "Lic. en Derecho" (Licenciada en Derecho) — her Mexican law degree from UABC (2010), establishing her as a dual-jurisdiction legal professional
  • Clarified hierarchy: Hero text now reads "LLM · M.A. · Lic. en Derecho" in reverse chronological order by credential earn date, with proper jurisdictional context
  • Added honors: Four President's List entries (Fall 2022, Spring 2023, Fall 2025, Spring 2026), Phi Theta Kappa Honor Society (Alpha Pi Epsilon Chapter), Spanish Proficiency Certificate (certified through Southwest Cornerstone, Spring 2025)

These updates were made in HTML files at /Users/cb/icloud-jada-ops/state/danielaferro/index.html and corresponding i18n strings in i18n.js. The changes frame her background accurately: a practicing Mexican attorney who pursued advanced US legal education, not a student casually studying law.

Key Decisions

Why vendors.json is the single source of truth: Multiple sites with overlapping vendor lists create data consistency risk. If a vendor URL changes and only one site is updated, others serve stale data. A single file updated once eliminates this class of bug.

Why 15-second test timeouts matter: Initial tests used aggressive 5-second timeouts and failed on legitimate endpoints. Rather than papering over the failure (reducing timeouts further), we increased them to reflect realistic network conditions. Tests should fail fast on actual problems, not on normal variation in server response time.

Why API domain registration: Programmatic registration through Namecheap's API creates audit trail and avoids manual dashboard errors. It also enables future automation if more domains are needed (e.g., for additional team members).

Why multi-domain ACM certificate: Managing three separate certificates would require three renewal workflows, three validation records, and three integration points. A single multi-domain cert reduces operational complexity and failure modes.

What's Next

  • CloudFront cache invalidation monitoring: New vendor pages should be visible within 60 seconds; monitor cache hit ratios in CloudFront metrics to ensure TTLs are appropriate
  • Vendor URL testing as part of CI/CD: The test suite should run on every vendors.json change before deployment; consider integrating into GitHub Actions
  • Credential audit documentation: A full handoff document at /Users/cb/icloud-jada-ops/HANDOFF-2026-07-02.md contains the complete credential inventory and infrastructure notes for future reference
  • Domain propagation: morenoferrolaw.com DNS may take 24-48 hours to fully propagate; cache-busting and hard refreshes may be necessary during this window
```