Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

Automating Charter Operations: Managing the July 4 JADA Cruise from DynamoDB to Print

What Was Done

On July 3, 2026, we coordinated final delivery of a July 4 evening charter (7 PM–10 PM departure) by automating the ops flow from DynamoDB retrieval through trip sheet/waiver deployment and orchestrating manifest collection from the charter organizer. The workflow moved the charter from initial DDB staging into crew-ready print form, validated payment status, and initiated guest-list collection from the organizer via SMS and email.

Technical Details: The Charter Ops Flow

JADA's charter workflow follows a defined five-step pattern (documented in CHARTER-WORKFLOW.md):

  • Step A: Calendar parse (Google Calendar → raw event data)
  • Step B: DDB record creation in jada-crew-dispatch table (us-east-1 region)
  • Step C: Trip sheet generation and crew notification
  • Step D: Manifest + guest list confirmation from organizer
  • Step E: Final crew assignments and dock briefing

For the July 4 charter, the record was already in DDB under the key charter-dylan-osborne-jul4-7pm with attributes including:

  • organizer: Dylan Osborne (crew contact, not Bob Dylan—important distinction for ops)
  • crew_call_time: Initially unset; corrected to 18:00 (6 PM dock muster)
  • payment_status: Pending Zelle deposit verification
  • description: Updated to reflect "Zelle deposit" vs. previous payment method
  • trip_sheet_url: Generated and deployed to public print CDN

The DDB record is authoritative for crew data across all downstream tools—it's the single source of truth that trip sheet generation, crew pages, and manifest requests all reference.

Trip Sheet and Waiver Deployment to Print CDN

Trip sheet and waiver PDFs were generated from templates in /Users/cb/icloud-jada-ops/state/dylan-jul4-trip-sheet.html and corresponding waiver file, then deployed to the public print path.

The public print URL pattern is queenofsandiego.com/print/[charter-key]/trip-sheet.html and .../waiver.pdf, served via CloudFront distribution. This URL scheme allows crew (like Daniela, who prints all charter docs) and organizers to access documents without authentication, but the underlying S3 bucket in the JADA ops account remains private.

Before deployment, we verified:

  • Trip sheet contact block was clean (Dylan's phone, no stale payment lines)
  • Crew call time reflected the corrected 18:00 muster from DDB
  • Canonical manifest request template was included (crew sees the request copy, organizer receives the editable version)

Both documents were uploaded via AWS CLI (aws s3 cp with the queenofsandiego profile) to the staging bucket, then Route53 alias records pointed queenofsandiego.com/print to the CloudFront distribution for public access.

Manifest Workflow: Organizer Collection

The manifest is the critical choke point: it must be populated by the organizer (Dylan) because he controls the guest list. Our workflow sends two versions:

  • Canonical (read-only): Delivered to crew (e.g., captain, Daniela) to show expected structure
  • Editable template: Sent to Dylan with instructions to fill guest names, return via email or SMS

The canonical manifest request copy is stored at /Users/cb/icloud-jada-ops/drafts/DRAFT-dylan-jul4-manifest-request.txt and includes the required fields (guest name, age, boat position) and submission deadline (noon on July 4).

Payment Verification and Ledger Reconciliation

Dylan's account showed a pending Zelle deposit. We corrected the DDB description field to reflect "Zelle deposit" (vs. the previous payment method notation) and verified the balance via ledger.py:

python3 ledger.py --charter dylan-osborne-jul4-7pm --receipt

This command pulled the entry from ledger.json, confirmed the balance, and recorded the deposit transaction in contacts.csv (the crew contact registry that feeds crew pages and trip sheets).

Communication Orchestration: SMS and Email

We used two channels to ensure message delivery:

  • SMS (via send-sms utility): Lightweight notifications to Dylan (on the JADA business line) with the captain-can't-leave-the-dock-until-paid directive, guest-list deadline, and photo code link
  • Email (via AWS SES with jada_google.py): Verified prior morning email had already covered the full guest-list request and payment status; resent print links to Daniela with apology line in case of delivery gaps

SMS delivery was initially blocked by AppleEvent timeout (Messages.app not running), so we relaunched the Messages process and retried. Both final sends were confirmed "Sent to" by the SMS utility.

Key Decisions and Rationale

Why DDB is authoritative: Crew data (call times, payment status, crew assignments) must have a single source of truth. DDB is fast to query, transactional, and feeds all downstream tools (trip sheet generator, crew pages, SMS notifications). Any change to crew_call_time or payment status flows through DDB first, not through manual edits to email drafts.

Why manifest collection is organizer-driven: The guest list is opaque to JADA operations—only Dylan knows who's coming. Rather than bottleneck on organizer latency, we send the request template and deadline upfront, so Dylan can return names asynchronously. The crew only needs the final manifest hours before departure.

Why crew call time was flagged: The initial DDB record had no crew_call_time set. Crew pages (which guide deck muster) render this field; missing it would cause crew to arrive without a clear boarding window. We set 18:00 based on the 7 PM departure time (standard 1-hour pre-dock window for a 7–10 PM cruise).

Why two trip sheet copies were sent: Daniela (crew) needs the captain's copy for dock reference. A second copy in the dock stairs serves as a backup for crew arriving early. Both are identical print files, just deployed in two physical locations.

Infrastructure Summary

  • DynamoDB: jada-crew-dispatch table (us-east-1), charter-based key schema
  • S3: Private ops bucket with queenofsandiego AWS profile for uploads
  • CloudFront: Distribution for queenofsandiego.com/print (public, no auth required)
  • Route53: Alias record routing queenofsandiego.com/print to CloudFront distribution
  • AWS SES: Email relay for charter notifications and manifest requests
  • Ledger storage: ledger.json (authoritative transaction log) + ledger.csv export for ops review

What's Next

As of July 3, 11 PM: Dylan has received the guest-list request (via SMS and prior email). His deadline is noon on July 4 to return guest names. The moment names arrive, the manifest generator (fed by the DDB record + Dylan's guest list) will produce the final PDF, which will be deployed to the same print path and crew notified.

Crew assignments (captain, mates) remain on hold in DDB pending final crew availability confirmation. Once Dylan's manifest arrives, those assignments will be finalized and crew pages will re-render with full details.