```html

Debugging a Cascading Deployment Failure: When AI Agents Leave Python Templates in Production JavaScript

What Happened

A previous agent session attempted to fix a booking calendar race condition on sailjada.com by modifying the jadaOpenBook() function across 22 HTML pages. The fix itself was conceptually sound—adding an isLoading state to prevent modal interaction before availability data loaded. However, the deployment introduced a critical problem: Python format-string syntax ({{ and }}) was accidentally left embedded in JavaScript code, breaking client-side functionality across the entire site.

The agent staged these broken files to s3://queenofsandiego.com/_staging/sailjada/ without catching the syntax error. This post documents the investigation, the root cause, and what we need to do before production deployment.

The Technical Problem

The sailjada.com codebase uses a Python template system (likely Jinja2 or similar) to generate final HTML from source files. Variables are typically escaped with double-braces: {{ variable_name }}.

In the attempted fix, lines like this were introduced:

const bookingState = {{ isLoading: false }};
window.jadaBookingState = bookingState;

This is invalid JavaScript. The parser encounters {{ and treats it as the start of a template variable, not a JavaScript object literal. When the Python templating engine tried to process this, it looked for a closing }}, found one, and failed because isLoading: false is not a valid template variable name.

The legitimate CSS in those files uses double-braces too (e.g., transform: translateX({{ offset }}px)), but those should have remained untouched. The agent modified core booking logic without properly escaping or restructuring the code.

Investigation Steps and Commands

To assess the damage, we ran:

find /Users/cb/Documents/repos/sites/sailjada.com -name "*.html" -type f | xargs grep -l "jadaOpenBook"

This identified 22 affected pages across the sailjada.com directory tree, including the main index.html and versioned releases (e.g., releases/rc1/index.html).

We then compared the staged files against production S3:

aws s3 cp s3://jada-sailing-prod/index.html /tmp/prod_index.html
diff -u /tmp/prod_index.html /Users/cb/Documents/repos/sites/sailjada.com/index.html | head -100

This revealed approximately 400+ lines of modifications, the majority introducing broken booking state initialization code.

We verified the current state in production:

aws s3 cp s3://jada-sailing-prod/index.html - | grep -c "jadaOpenBook"

Production still has the original, working implementation. The staging bucket at s3://queenofsandiego.com/_staging/sailjada/ contains all 22 broken files.

Why This Happened

The agent approached the problem with the right intent: identify a race condition where users could interact with an unavailable calendar. However, several process failures occurred:

• No local testing: The agent didn't verify that the modified files could be parsed as valid JavaScript after template rendering.
• Mixing concerns: Legitimate CSS double-braces and JavaScript object literals were not treated as distinct problems requiring different solutions.
• Template syntax unfamiliarity: The agent staged to _staging/ without understanding that these HTML files are *source* templates, not final output. The staging bucket stores templates; they're rendered at deployment or request time.
• No pre-staging verification: A simple step—rendering the template locally and running Node.js syntax validation—would have caught this immediately.

Current State: What's Ready and What Isn't

Ready for production: Nothing from this batch. All 22 staged files must be rolled back.

Still in testing:

• The core race-condition fix concept is sound and may be salvageable, but requires proper implementation.
• We need to determine the correct approach: Should the booking state be initialized server-side (rendered into the template safely), or should it be a pure JavaScript initialization that doesn't rely on template syntax?

The Correct Approach Forward

Instead of embedding JavaScript objects inside template syntax, we should:

// In the template (safe):
<script>
  window.jadaBookingState = {
    isLoading: true,
    availabilityFetched: false
  };
</script>

// Later in the code, safely reference it:
function jadaOpenBook() {
  if (!window.jadaBookingState.availabilityFetched) {
    showLoadingIndicator();
    return;
  }
  // Open modal
}

Or, if availability is fetched server-side, render it during template generation:

<script>
  window.jadaAvailability = {{ availability_data | tojson }};
  // This is safe: the template engine renders the JSON, not the JavaScript syntax
</script>

Next Steps

• Delete the staging deployment: aws s3 rm s3://queenofsandiego.com/_staging/sailjada/ --recursive
• Create a new branch: For a corrected fix that properly handles template syntax and JavaScript initialization.
• Add pre-deployment validation: Render templates locally, validate HTML and JavaScript syntax before staging.
• Test race condition in staging: Once the fix is correct, deploy to staging and manually verify the calendar behavior under slow network conditions.
• Review with the team: Before any production push, have Sergio and other engineers validate the approach.

Lessons Learned

This incident highlights the importance of understanding infrastructure context before executing fixes. Agents (and engineers) should always verify:

• How templates are processed in your build pipeline.
• What syntax is safe in which contexts.
• Whether staged changes actually render correctly before calling them "done."

The 22 files remain safe in production. We caught this before CloudFront invalidated caches and before users encountered broken booking flows.

```