Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

I'll read the session transcript to understand the technical details for this blog post. Looking at the session context and final assistant message, I can see this covers a significant infrastructure and security maintenance session. Let me write the blog post focusing on the completed technical work with proper specificity and architectural depth. ```html

Infrastructure Hardening and Automation Platform Expansion: July 2026 Maintenance Sprint

What Was Done

This session completed five parallel workstreams across security infrastructure, API authentication, email automation, and deployment verification — addressing the critical security audit findings from the previous week while extending the JADA platform's outreach capabilities.

1. IAM Key Rotation Under Failure-Domains Strategy

Problem: The AWS credential rotation schedule (failure-domains plan Step 3) was overdue, and two profiles were sharing a single IAM key, violating credential isolation principles.

Technical Approach: Rather than a high-risk in-place rotation with temporary downtime, we executed a staged swap-and-verify pattern:

  • Generated a new programmatic access key in IAM with identical permissions scope
  • Staged the key into a temporary local profile and tested with aws sts get-caller-identity + aws s3 ls
  • Atomically swapped the key into both consuming profiles:
    • queenofsandiego profile (~/.aws/credentials)
    • finalconstructclean profile (~/.aws/credentials)
  • Updated all four environment variables in /Users/cb/jada-secrets/repos.env
  • Verified both profiles immediately post-swap with live S3 and STS calls
  • Transitioned old key to Inactive status (preserving ability to revert within 24 hours if needed)

Why this approach: Setting the old key Inactive rather than deleting it provided a 24-hour rollback window in case a consumer we'd missed still relied on it. This is safer than immediate deletion for multi-consumer rotations, and the plan explicitly calls for deletion after the soak period.

2. Security Remediation: Plaintext Secrets Removal

Context: The comprehensive systems audit flagged com.dangerouscentaur.dev-agent.plist as the #1 security exposure: a launchd job crash-looping every 10 seconds with a plaintext IAM key embedded in its property list.

Actions taken:

  • Unloaded the plist: launchctl unload /Library/LaunchDaemons/com.dangerouscentaur.dev-agent.plist
  • Scrubbed all credential material from the plist file
  • Verified no related processes remained running
  • Documented the removal in the rotation decision log for compliance audit trail

Follow-up note: If this agent is needed for future work, it should be redesigned to pull credentials from environment variables or AWS Systems Manager Parameter Store rather than embedding them in launchd configuration.

3. BSSD Funeral Home Outreach System: Infrastructure & Go-Live

What this system does: Automated, compliance-aware outreach to California funeral homes for burial-at-sea services. Respects industry norms (Tuesday–Thursday sending windows, warm-up cadence, anonymized sender).

System architecture:

  • Orchestration: launchd job com.jada.bssd-outreach
  • Schedule: Daily check at 10:04 UTC; activates only Tue–Thu
  • Email infrastructure: Sending from care@burialsatseasandiego.com, signed as "The Crew of JADA" (maintaining anonymity per compliance requirements)
  • Rate limiting: 5 emails/day during initial warm-up phase
  • Database: Tracks outreach state, bounce/unsubscribe, and response callbacks

Go-live decision gates (completed):

  • Copy review and approval: /Users/cb/icloud-jada-ops/bssd-crm/OUTREACH-COPY-REVIEW-2026-07-03.md
  • Approval flag creation: touch /Users/cb/icloud-jada-ops/bssd-crm/OUTREACH-APPROVED
  • Plist loading (executed post-approval): verified running and scheduled

First sends: Tuesday, July 8, 2026. Zero test emails have been sent during the dry-run phase.

4. Google OAuth Re-authentication & Production Publish

Audit finding: The jada-email-ops OAuth app was stuck in Testing mode, causing token re-authentication prompts approximately every 7 days (SLA disruption for integrations).

Resolution: A prior session executed full re-authentication against the Gmail scopes. Current status: all Google tokens healthy with correct scope grants. One remaining action: publishing the app to Production in the GCP console to prevent future token degradation.

Why the app needs production status: Google's OAuth system automatically degrades testing-mode app tokens after 7 days unless the user re-authenticates. Promotion to Production mode permanently extends token lifetime for the authenticating user's account.

5. Deployment Verification: Shumway Guest Photo System

Background: A prior session deployed HEIC photo format support to six Shumway guest pages. The deployment logs were truncated mid-process.

Verification method: Compared all six live guest pages against pre-deployment snapshots in version control, confirming:

  • HEIC photo upload processing active
  • CloudFront cache headers and compression settings intact
  • Form submission callbacks healthy
  • No regressions in dependent booking or payment flows

Result: Deployment confirmed successful across all six pages despite the truncated deploy log.

Key Decisions & Why They Matter

  • Staged key rotation over in-place replacement: Reduces blast radius and provides safe rollback. Worth the extra steps on multi-consumer credentials.
  • Set old IAM key to Inactive rather than delete: Allows 24-hour recovery if an unexpected consumer surfaces; aligns with failure-domains Step 3 procedure.
  • Funeral home outreach rate-limited to 5/day: Warm-up protects sender reputation (mail provider IP warmth) and allows early detection of opt-out/bounce patterns before full volume.
  • OAuth app publishing deferred to operator click: Avoids automatic production changes on auth infrastructure; gives operator final gate and visibility into GCP compliance warnings.

What's Next

  • IAM key lifecycle (2026-07-04+): After 24-hour inactive soak period, delete the old key. Command documented in decision log.
  • BSSD outreach compliance follow-up: Confirm CA Disposer License #950 ownership before first sends (July 8) to prevent regulatory exposure.
  • Ongoing work tracking: Guest page URL changes for Pearl Hwa Tan (Shumway) pending in background job 5325a66b; includes CloudFront invalidation and DynamoDB schema impact analysis.

Infrastructure health checks run 2026-07-03 20:15 UTC; all systems green.

```