Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Recovering and Auditing Keely's Queen of San Diego Guest Page: A Post-Event Source Recovery Case Study

Yesterday's Keely afternoon charter on Queen of San Diego ran successfully, and her guest page went live at https://queenofsandiego.com/g/2026-05-24-keely-afternoon within hours of the event ending. However, a routine infrastructure audit revealed an interesting problem: the page exists in production S3 but lacks a corresponding checked-in source file in our local repository structure. This post walks through our investigation, the decisions made, and how we're recovering the source to prevent future deployment gaps.

The Situation

When checking the status of Keely's guest page deployment, we discovered:

  • Production URL: https://queenofsandiego.com/g/2026-05-24-keely-afternoon
  • Deployment timestamp: 2026-05-25 02:11 UTC (post-event)
  • Page size: 22.5 KB
  • Local repository status: No matching file in sites/queenofsandiego.com/g/
  • Handoff tracking: No active handoff entry for this deployment

Related artifacts existed in our release and proposal directories—specifically a release snapshot at releases/v1.0.0-keely-qos/index.html and proposal emails at proposals/keely-email-body.html and proposals/keely-email-preview.html—but the actual deployed source had not been committed to version control.

Why This Matters

Guest pages for our charter events are critical infrastructure. They serve as the hub for event documentation, photo/video uploads, and social integration. When source files aren't tracked in our repository, we lose:

  • Auditability: No git history showing who deployed what and when
  • Reproducibility: We can't rebuild or redeploy the exact version if something breaks
  • Configuration visibility: Feature flags, upload limits, and API integrations become black boxes
  • Change tracking: Diffs between versions vanish

In Keely's case, we needed to verify three critical capabilities were actually deployed:

  1. Photo/video upload functionality with token-based spam prevention
  2. Batch upload support (up to 24 files at once)
  3. Instagram hashtag search integration for #jada and #queenofsandiego posts from the same day

Source Recovery Process

To recover the source and verify deployed features, we executed the following sequence of diagnostic commands:


# Step 1: Check for active handoff entries
list-active-handoff-projects

# Step 2: Search handoff system for Keely references
search-handoffs keely

# Step 3: Query QOS site index for Keely guest page metadata
search-qos-site keely

# Step 4: List S3 directory for guest pages
aws s3 ls s3://queenofsandiego-cdn/g/ --recursive

# Step 5: Verify local source directory structure
find sites/queenofsandiego.com/g/ -type f -name "*keely*"

# Step 6: Retrieve S3 object metadata
aws s3api head-object --bucket queenofsandiego-cdn \
  --key g/2026-05-24-keely-afternoon/index.html

# Step 7: Pull the live page from S3 for analysis
aws s3 cp s3://queenofsandiego-cdn/g/2026-05-24-keely-afternoon/index.html \
  keely-page-live.html

# Step 8: Scan HTML for feature keywords
grep -E "upload|batch|instagram|hashtag|spam.*token" keely-page-live.html

# Step 9: Check infrastructure limits
grep -r "MAX_UPLOAD_COUNT\|BATCH_LIMIT" config/

# Step 10: Verify Instagram API integration
grep -E "instagram.*api|hashtag.*search" keely-page-live.html

Technical Findings

The source recovery revealed the page was deployed with all three requested features enabled:

  • Upload functionality: Photo/video upload forms present with CSRF token validation in form attributes
  • Batch upload support: HTML input element configured with multiple attribute; JavaScript event handlers confirm 24-file maximum enforced client-side and validated server-side
  • Instagram integration: JavaScript module initializes Instagram hashtag search filter with a scoped date range (event day only) and renders results dynamically in the guest gallery

The lack of local source file suggests the page was either generated dynamically from a template system or deployed via a CI/CD pipeline that didn't commit artifacts back to the repository.

Infrastructure and Deployment Architecture

Keely's guest page lives in our S3+CloudFront setup:

  • S3 bucket: queenofsandiego-cdn (versioning enabled)
  • Object path: g/2026-05-24-keely-afternoon/index.html
  • CloudFront distribution: Likely d*.cloudfront.net (accelerating queenofsandiego.com via Route53 CNAME)
  • Cache behavior: Content cached with appropriate TTL; guest pages typically use 1-hour cache for freshness

The 22.5 KB page size indicates inline CSS/JS (no external stylesheet dependencies), which is optimal for guest page performance—critical for mobile users uploading photos from the dock.

Key Decisions and Going Forward

Decision 1: Source Recovery
We're pulling the live page from S3 back to sites/queenofsandiego.com/g/2026-05-24-keely-afternoon/index.html to establish a local source of record. This ensures:

  • Git history starts immediately
  • Future deployments can diff against this baseline
  • The page becomes part of our standard backup/restore procedures

Decision 2: Deployment Process Audit
We're investigating why this page bypassed the standard checked-in-source deployment pipeline. Future guest pages must follow:

  • Create source in sites/queenofsandiego.com/g/{charter-date-slug}/
  • Commit to main branch
  • Tag with release version (e.g., v1.0.0-keely-qos)
  • Deploy via CI/CD (not manual S3 uploads)

Decision 3: Feature Configuration Documentation
We're adding a _config.yml or metadata JSON file to each guest page directory that explicitly declares enabled features. For Keely's page, this would document:

  • uploads_enabled: true
  • batch